views:

360

answers:

4

Hello folks:

I am learning IronPython along wiht Python. I'm curious what kinds of tasks you tend to use IronPython to tackle more often than standard .NET languages.

Thanks for any example.

+7  A: 

One example that is a perfect match for IronPython is when you want to include scriptability in your application. I have been working on systems where the user can interact with the whole application class model directly through the in-app python scripting layer and it allows for a great deal of flexibility for advanced users.

A tangible example is when you want to expose "hooks" in the application where the user can customize the business rules (say, do a custom broker fee calculation when a new trade is created in a trading system for instance).

Edit per request: here is a simple (mocked-upped) example. When a user creates a new trade in the system, the system checks if the following Python function is defined, and if present, the trade gets the result of the function as a fee added to it before it is committed to the database:

def calculate_broker_fee(trade):
    fee = 0.043 # default value
    if trade.exchange in ["SWX", "EURONEXT"] and \
        trade.instrument.instrument_type == "Bond":
        fee = trade.quantity*0.00234
    return fee
Rickard
Could you share some of your code snippet to let me catch more concretely?
Ricky
@Rickaed: you means "calculate_broker_fee" is maintained by users to customize thier needs?
Ricky
Yep, it sure is. If the function is not there, then the system uses its internal default calculation (written in C++ in this case, typically C# in the IronPython case), but if the user needs the custom calculation he/she can provide it.
Rickard
It should be noted that the implementation of these kind of hooks is made extremely easy with DotNet / DLR compared to regular CPython where the C-based API is a little bit more clunky.Another nice thing is that it is easy to provide support for other DLR-languages like IronRuby, allowing the user to write customizations in a language he/she is familiar with.
Rickard
@Rickard: IronPython can run IronRuny?
Ricky
No, but the DLR (Dynamic Language Runtime) which is the backbone these dynamic languages (providing code generation, syntax trees and nice APIs for accesing them from the static languages [such as C#] amongst other things) has an API which is quite transparent with regards to which dynamic language you use. So the effort of calling either IronPython OR IronRuby from say C# is not much greater than the effort to just have support for IronPython.
Rickard
+3  A: 

In the day job, it's my standard language for those little bits of build process that are too much for .bat files and not heavyweight enough to demand a separate executable; this includes anything that could use a little bit of XML processing or reflection -- generating Wix files with systematic handling of 32 and 64 bit installs, for example. It beats out PowerShell in this role because IronPython is an XCOPY install onto build machines.

It's also very useful for prototyping fragments of code against unfamiliar or complex APIs (WMI and Active Directory being the usual ones for me), or diagnosing problems in code using those APIs (like sniffing out the oddities that happen when you're on the domain controller, rather than elsewhere).

Steve Gilham
Could you give more concrete examples over your explanation?
Ricky
Rather than copy wholesale, here are a couple of my blog posts on the subject : http://stevegilham.blogspot.com/2009/07/ironpython-for-build-scripting.html fir the former and http://stevegilham.blogspot.com/2007/09/watching-files-registry-keys-from-net.html for the latter
Steve Gilham
@Steve: thanks a lot
Ricky
A: 

Created a load tool for a MS Group Chat Server plugin. The GC API is in C#. I wrapped that into a dll and had FePy load it. The main application, configuration scripts etc are all in FePy.

Vijay Mathew
+4  A: 

I've just deployed my IronPython Point-of-Sales service application at the beginning of this month. The service application is a RESTful http server serving query & transactional request to .NET WinForms client. With help of some remoting library, the service application is purely implemented in IronPython.

In my opinion, Python is undoubtly the best language to code complex business logics. Here are my reasons.

  1. The language is very expressive. I could come up with endless ideas for internal DSL that make my business logic shorter and simpler to understand.

  2. It's interactive. Trouble-shooting and logic testing can be done interactively.

  3. It's dynamic. It's freedom. No xml configuration. No plumbing. No compile.

  4. I can work in my favorite editor.

Most skeptics alway mention "code-completion" and "debugger". Well I miss them sometimes. However, I'm aware that I deliberately gave up those conveniences in favor to, a much more important factor, comprehensibility. With proper unit-testing and logging, I'd pick IronPython over any languages for my business logics.

updated:

Sometimes, I experiment and log user issues with Ironpython Script that act as if being a client like this:

>> from boon.service import client
>> CASH_PAYMENT_TYPE = '000000011'
>> cl = client.Client('http://pos-server/bin?posB2K')
>> cl.connect('user', 'password')
>> order = cl.workspace('pos.Order')
>> order.load('1312')
>> payments = order.dataset.Tables['POS_PAYMENTS']
>> payments.Rows[0]['PAYMENT_TYPE_ID'] = CASH_PAYMENT_TYPE
>> order.save()

Sometimes, I investigate bugs by scripting server object like this:

>> from boon import pos
>> pos.register_pos_service(debug=True)
>> from boon.service import get_instance
>> possvc = get_instance('pos')
>> print possvc.store['POS_PAYMENTS'] \
..   .where(lambda r: r.POS_HD_ID == 1312) \
..   .include('PAYMENT_TYPE_ID', 'PAY_AMT') \
..   .list()
[('000000011', 1520)]

You may find the code not too elegance since I prefer to based my work on ADO.NET DataSet. It's simpler for Windoows Forms client, however.

Sake
+1. I prefer IronPython over C# for everything .NET. For all the reasons above.
codeape
@Sake: Could you proivde articles regarding point (2)? Thx.
Ricky