I have a problem with this example code: from BookService import BookDictionary booksWrittenByBookerPrizeWinners = [] for book in BookDictionary.GetAllBooks: if "Booker Prize" in book.Author.MajorAwards: booksWrittenByBookerPrizeWinners.append(book.Title) booksWrittenByBookerPrizeWinners First, the variable names seem intentionally ugly, but I'm not going to worry about that. What really bugs me is BookDictionary.GetAllBooks without making it callable. The prefixing verb Get would imply a function, and Python distinguishes itself from Ruby (per Martelli) by making a sharp distinction between a function *named* and a function *called*. Perhaps its just an unfortunate naming issue, i.e. GetAllBooks is really to be thought of as an iterable, not a function call. Under the hood, there might be some property, i.e. if it has to consult a database (whatever BookService does). But in that case, I'd really prefer a function with no arguments, a callable in other words. Anyway, as you can see, I'm unhappy with this code. Plus there's a clear typo in the next sentence: "In this case, assume that the .NET framework implements a class, BookDictionary, in a module called BookService, and publishes an interface into which IronPython scripts can be sent and exectuted." I've edited Wikipedia before, but hesitate to dive in on this one without more seasoning (comments?). Kirby
On 5/6/06, kirby urner <kirby.urner@gmail.com> wrote:
I have a problem with this example code:
from BookService import BookDictionary
booksWrittenByBookerPrizeWinners = [] for book in BookDictionary.GetAllBooks: if "Booker Prize" in book.Author.MajorAwards: booksWrittenByBookerPrizeWinners.append(book.Title) booksWrittenByBookerPrizeWinners
First, the variable names seem intentionally ugly, but I'm not going to worry about that.
There is a style of programming where you spell out what you're doing in graphic detail, as opposed to just declaring var x,y,z; def foo(x,y): return z style of minimalist programming. Most Python code is somewhere in between, but when using an external system (dotNet in your example, PyObjC in my experience), it makes sense to have the python code reflect the style of the main library/framework that you're using (or wrap it out of sight altogether, the way PyGUI tries to do). What really bugs me is
BookDictionary.GetAllBooks without making it callable. The prefixing verb Get would imply a function, and Python distinguishes itself from Ruby (per Martelli) by making a sharp distinction between a function *named* and a function *called*.
In Java, rather than properties, they have the JavaBeans naming convention. According to this convention, getters are named getFoo() -> foo, and setters are named setFoo(foo) -> void. In most of the dotNet code I've seen, you can take Java (or SVG, or whatever system they're imitating this month) and make it initCap (getFoo() becomes GetFoo()). Since Jython treats the JavaBeans calling conventions as properties, I assume IronPython is doing something similar. Although in that case, you should be able to just write AllBooks rather than GetAllBooks (although both ways might work).
Perhaps its just an unfortunate naming issue, i.e. GetAllBooks is really to be thought of as an iterable, not a function call. Under the hood, there might be some property, i.e. if it has to consult a database (whatever BookService does). But in that case, I'd really prefer a function with no arguments, a callable in other words.
Anyway, as you can see, I'm unhappy with this code.
Plus there's a clear typo in the next sentence:
"In this case, assume that the .NET framework implements a class, BookDictionary, in a module called BookService, and publishes an interface into which IronPython scripts can be sent and exectuted."
I've edited Wikipedia before, but hesitate to dive in on this one without more seasoning (comments?).
I think you should freely change the obvious typo, but not the code unless you've tried to run it and found it does not actually work. I don't have IronPython, or any intention to install or run it, so take anything I say about it with a large grain of salt. --Dethe
Kirby _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
In Java, rather than properties, they have the JavaBeans naming convention. According to this convention, getters are named getFoo() -> foo, and setters are named setFoo(foo) -> void. In most of the dotNet code I've seen, you can take Java (or SVG, or whatever system they're imitating this month) and make it initCap (getFoo() becomes GetFoo()). Since Jython treats the JavaBeans calling conventions as properties, I assume IronPython is doing something similar. Although in that case, you should be able to just write AllBooks rather than GetAllBooks (although both ways might work).
Yes, I'm somewhat familiar with JavaBeans. It wasn't the naming conventions that bothered me so much, as using Get... but not making it a callable. I gather some more feedback. Not a high priority.
I think you should freely change the obvious typo, but not the code unless you've tried to run it and found it does not actually work. I don't have IronPython, or any intention to install or run it, so take anything I say about it with a large grain of salt.
--Dethe
OK. Kirby
On Mon, 2006-05-08 at 09:32 -0700, Dethe Elza wrote: <snip>
I don't have IronPython, or any intention to install or run it, so take anything I say about it with a large grain of salt.
Wondering why you won't touch IronPython? It looks like it has the potential to span what currently takes C/C++ plus SWIG plus Python, but puts it into one framework, and may run more quickly than the other. It also runs under Mono on many OSes and .NET on Windows. Is it because it has touched the hands of Microsoft? It is "open source" (in as far as the shared source license looks open), and Microsoft has (so far) been very faithful to replicating CPython's behavior. If it had generic cross-platform graphics, or were embedded in a browser, then it sounds like it might be just the right Python for doing many educational projects mentioned on this list in the last few weeks. -Doug
--Dethe
-- Douglas S. Blank Computer Science Assistant Professor Bryn Mawr College (610)526-6501 http://cs.brynmawr.edu/~dblank
Wondering why you won't touch IronPython? It looks like it has the potential to span what currently takes C/C++ plus SWIG plus Python, but puts it into one framework, and may run more quickly than the other. It also runs under Mono on many OSes and .NET on Windows. Is it because it has touched the hands of Microsoft? It is "open source" (in as far as the shared source license looks open), and Microsoft has (so far) been very faithful to replicating CPython's behavior. If it had generic cross-platform graphics, or were embedded in a browser, then it sounds like it might be just the right Python for doing many educational projects mentioned on this list in the last few weeks.
CPython does what I need. Mono/dotNet is the answer to problems I don't have. My main platform is OS X, and PyObjC bridges quite nicely between Cocoa and CPython. It's not just the "hand of Microsoft," though I admit I don't particularly like doing business with unrepentant convicted monopolists, but I don't have much use for Jython most of the time either. When I have to use Java for something, Jython is the ticket, but that happens less and less these days. Using a huge VM designed for statically compiled languages to run dynamic languages on is a neat trick, it's cool that it can be done, but it's not something I actually see much point in using over CPython's own VM. I'm not trying to start a religious war or make (much) of a statement here, just saying it's not for me. --Dethe
-Doug
--Dethe
-- Douglas S. Blank Computer Science Assistant Professor Bryn Mawr College (610)526-6501 http://cs.brynmawr.edu/~dblank
On 5/9/06, Dethe Elza <delza@livingcode.org> wrote:
days. Using a huge VM designed for statically compiled languages to run dynamic languages on is a neat trick, it's cool that it can be done, but it's not something I actually see much point in using over CPython's own VM.
In the case of the CLR, I think it *was* designed with dynamic languages in mind, but Jim Hugunin thought it wouldn't prove out, and Python would make an excellent case study showing why. To his surprise, the CLR proved worthy, and IronPython was born. I assume Mono could run on OS X. http://www.mono-project.com/Mono:OSX However, to be realistic, the current almost-out-of-beta IronPython requires .NET 2.0. I'm pretty sure it doesn't run on the most current production version of Mono yet, although I could be wrong and would be happy to be corrected. http://www.mono-project.com/Mono_Project_Roadmap I could try it myself, but am steeped in Panda3D for now. I feel pretty confidant that Mono and .NET will be a cross-platform solution favored by many Python developers, including those looking for control over the kinds of OpenGL-type applications we've been brainstorming here on edu-sig. Kirby
Kirby spake: <snip>
However, to be realistic, the current almost-out-of-beta IronPython requires .NET 2.0. I'm pretty sure it doesn't run on the most current production version of Mono yet, although I could be wrong and would be happy to be corrected.
IronPython does run under Mono, at least basically, and is getting better every week. Of course, both Mono and IronPython are changing rapidly, but I think later this year they will both be usable together.
http://www.mono-project.com/Mono_Project_Roadmap
I could try it myself, but am steeped in Panda3D for now.
I feel pretty confidant that Mono and .NET will be a cross-platform solution favored by many Python developers, including those looking for control over the kinds of OpenGL-type applications we've been brainstorming here on edu-sig.
I will be beginning such a project soon, and will keep you abreast of the pros, cons, gotchas, and goodies. -Doug
Kirby
participants (4)
-
dblank＠brynmawr.edu -
Dethe Elza -
Douglas S. Blank
-
kirby urner