I noticed your email address on a list serve related to technology and web development. With your permission, we
would like to send you information regarding new web tools and utilities based on your interests. Please click the
following link and opt-in to our product updates and e-newsletter, click here: http://216.133.228.90/cm/
Cordially,
Victor Black
If you would like to be removed from our database, please click here: http://216.133.228.90/cm/remove.cgi
From jack@oratrix.nl Tue Aug 21 15:56:32 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 21 Aug 2001 16:56:32 +0200 Subject: [Python-Dev] Putting a builtin module into a package Message-ID: <20010821145632.7CC15303181@snelboot.oratrix.nl> Is there a way to put a builtin module into a package, or should I really not want to do this? It seems that if in the module init() routine I call Py_InitModule("Carbon.Res") and if I put the module into _PyImport_Inittab as "Carbon.Res" things sort-of work, at first glance. Or should I rename the module to an underscore name and simply put a wrapper module in the package? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From skip@pobox.com (Skip Montanaro) Tue Aug 21 16:58:34 2001 From: skip@pobox.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 21 Aug 2001 10:58:34 -0500 Subject: [Python-Dev] Putting a builtin module into a package In-Reply-To: <20010821145632.7CC15303181@snelboot.oratrix.nl> References: <20010821145632.7CC15303181@snelboot.oratrix.nl> Message-ID: <15234.34090.225332.420431@beluga.mojam.com> Jack> Or should I rename the module to an underscore name and simply put Jack> a wrapper module in the package? This seems the safest (and the sanest) to me. I realize you're thinking mostly about MacOS, but putting object files inside packages that are otherwise Python code makes the whole package platform-dependent. In general, it would prevent system administrators from installing the Lib/site-packages directory tree on a shared filesystem like NFS. In your package __init__.py file you might want to check for the existence of any object modules and raise ImportError as early as possible. Skip From DavidA@ActiveState.com Tue Aug 21 20:01:18 2001 From: DavidA@ActiveState.com (David Ascher) Date: Tue, 21 Aug 2001 12:01:18 -0700 Subject: [Python-Dev] copy, len and the like as 'object' methods? Message-ID: <3B82AFFE.652A19F5@ActiveState.com> I just came back from teaching Python on a cruise ship attended by mostly Perl folks. It was an interesting experience teaching Python with Randal in the audience =). One issue that came up is some of the lack of uniformity on what things are statements, methods and built-in functions. In the long-term version of the type/class unification work, things like int() become class constructors, which makes beautiful sense. The fact that int() calls __int__ methods fits nicely with type conversion mechanisms. However, there are a few things which still seem oddballish: copy.copy(), copy.deepcopy(), len() These basically call magic methods of their arguments (whether tp_slots or __methods__), and many languages implement them strictly as object methods. str() and repr() are a little weird -- I'm not sure which one will gain 'class constructor' status when the type/class unification work is done -- from the definition I'd say repr() should win, but the name is quite unfortunate given its new role... Guido, thoughts? Summary: Should copy, deepcopy and len be added as object methods? And if yes, how? Not all objects are copyable or measurable. Interfaces seem the right way to do this, but interfaces aren't in the plans so far that I know... What about a stringification method? --david From gstein@lyra.org Tue Aug 21 21:40:36 2001 From: gstein@lyra.org (Greg Stein) Date: Tue, 21 Aug 2001 13:40:36 -0700 Subject: [Python-Dev] PEP 268 - Extended HTTP functionality and WebDAV Message-ID: <20010821134036.J13229@lyra.org> I've completed my first draft of PEP 268 and am seeking feedback. http://python.sourceforge.net/peps/pep-0268.html My next step is to begin implementing the 'httpx' module and rejiggering the 'davlib' module. This work will occur in the /nondist/sandbox/ area (probably under a Lib subdir there). This work is intended to go into Python 2.2. Possibly appearing in time for 2.2a3, but 2.2b1 at the latest. Cheers, -g -- Greg Stein, http://www.lyra.org/ From jack@oratrix.nl Tue Aug 21 22:41:31 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 21 Aug 2001 23:41:31 +0200 Subject: [Python-Dev] Re: [Pythonmac-SIG] Java-Python Extension In-Reply-To: Message by Jim Harrison , Tue, 21 Aug 2001 16:27:00 -0400 , Message-ID: <20010821214136.3C982162E06@oratrix.oratrix.nl> Python-dev-ils: this just came in on the Pythonmac-SIG. Did anyone have a look at this already? Recently, Jim Harrison said: > Here's something that might have implications for cross-platform GUI > development in Python (something recently discussed on the list)... > > "JPE is a seamless, complete, and efficient integration of Java and standard > Python (C Python). JPE provides Java access to Python's native extension, > and Java's Swing to Python developers." > > http://sourceforge.net/projects/jpe/ The mind boggles... This person (at least: there seems to be only one person in the developer group right now) has apparently hung a complete Python interpreter inside a JVM and written all the glue code. I have no time to look into this further, but from a quick inspection of the CVS tree it looks as though it it reasonably complete. It definitely looks a lot better than many of the vaporware 1-person projects you can find on sourceforge... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From barry@scottb.demon.co.uk Wed Aug 22 00:21:53 2001 From: barry@scottb.demon.co.uk (Barry Scott) Date: Wed, 22 Aug 2001 00:21:53 +0100 Subject: [Python-Dev] PEP 265 - Sorting Dictionaries by Value In-Reply-To: <4.3.2.7.2.20010820215632.00cb69e0@pop.kcnet.com> Message-ID: <000201c12a98$0fe70b00$060210ac@private> Seems to me that the problem is the sort method of lists is lacking not that dictionaries need some special smarts. I'd look to improve sort for some common cases where sort and lambda are deemed to hard. (Is using lambda a definition of hard?) If lambda is used you would solve the problem with: >>> items = d.items() >>> items.sort( lambda a, b: cmp( b[1], a[1] ) ) What if you interpret the parameter of sort: * - do as today * callable - do as today * int - sort by index into sequence * string - sort by this field of object If you had the improved sort you could: >>> items = d.items() >>> items.sort( 1 ) >>> items.reverse() BArry > For example, given an occurrence count of: > > >>> d = {'a':2, 'b':23, 'c':5, 'd':17, 'e':1} > > we might do: > > >>> items = d.items() > >>> items = [(v, k) for (k, v) in items] > >>> items.sort() > >>> items.reverse() # so largest is first > >>> items = [(k, v) for (v, k) in items] > > resulting in: > > >>> items > [('b', 23), ('d', 17), ('c', 5), ('a', 2), ('e', 1)] > From guido@python.org Wed Aug 22 01:43:33 2001 From: guido@python.org (Guido van Rossum) Date: Tue, 21 Aug 2001 20:43:33 -0400 Subject: [Python-Dev] PEP 265 - Sorting Dictionaries by Value In-Reply-To: Your message of "Wed, 22 Aug 2001 00:21:53 BST." <000201c12a98$0fe70b00$060210ac@private> References: <000201c12a98$0fe70b00$060210ac@private> Message-ID: <200108220043.UAA24429@cj20424-a.reston1.va.home.com> > Seems to me that the problem is the sort method of lists is lacking > not that dictionaries need some special smarts. Hear, hear. > I'd look to improve sort for some common cases where sort and lambda > are deemed to hard. (Is using lambda a definition of hard?) > > If lambda is used you would solve the problem with: > > >>> items = d.items() > >>> items.sort( lambda a, b: cmp( b[1], a[1] ) ) > > What if you interpret the parameter of sort: > > * - do as today > * callable - do as today > * int - sort by index into sequence > * string - sort by this field of object Or better still, list.sort() wouldn't need to be changed at all if there was a standard library module to create compison routines, e.g. from __future__ import nested_scopes def cmp_by_index(i): return lambda a, b: cmp((a[i], a), (b[i], b)) # etc. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Wed Aug 22 01:48:15 2001 From: guido@python.org (Guido van Rossum) Date: Tue, 21 Aug 2001 20:48:15 -0400 Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: Your message of "Tue, 21 Aug 2001 12:01:18 PDT." <3B82AFFE.652A19F5@ActiveState.com> References: <3B82AFFE.652A19F5@ActiveState.com> Message-ID: <200108220048.UAA24452@cj20424-a.reston1.va.home.com> > I just came back from teaching Python on a cruise ship attended by > mostly Perl folks. It was an interesting experience teaching Python > with Randal in the audience =). Tell us more... > One issue that came up is some of the lack of uniformity on what things > are statements, methods and built-in functions. In the long-term > version of the type/class unification work, things like int() become > class constructors, which makes beautiful sense. The fact that int() > calls __int__ methods fits nicely with type conversion mechanisms. Except that __int__ is poorly defined -- sometimes it is used as a precision-losing number cast (e.g. int(3.5) returns 3), sometimes it is an exact conversion (e.g. int("3")). > However, there are a few things which still seem oddballish: > > copy.copy(), copy.deepcopy(), len() > > These basically call magic methods of their arguments (whether tp_slots > or __methods__), and many languages implement them strictly as object > methods. Yes, it's an old Python choice. OO zealots don't like it much, but it has the advantage that you don't have to introduce methods right away. Too late to change. > str() and repr() are a little weird -- I'm not sure which one will gain > 'class constructor' status when the type/class unification work is done > -- from the definition I'd say repr() should win, but the name is quite > unfortunate given its new role... Guido, thoughts? str() has won -- in part because of its name, in part because it is the "copy constructor", returning a string input unchanged. > Summary: Should copy, deepcopy and len be added as object methods? And > if yes, how? Not all objects are copyable or measurable. Interfaces > seem the right way to do this, but interfaces aren't in the plans so far > that I know... > > What about a stringification method? I'd say leave it alone (we're getting enough complaints about "gratuitous" language changes as it is, and the changes we've committed to have very good reasons). --Guido van Rossum (home page: http://www.python.org/~guido/) From grant.griffin@iowegian.com Wed Aug 22 14:32:57 2001 From: grant.griffin@iowegian.com (Grant Griffin) Date: Wed, 22 Aug 2001 08:32:57 -0500 Subject: [Python-Dev] PEP 265 - Sorting Dictionaries by Value In-Reply-To: References: <4.3.2.7.2.20010820215632.00cb69e0@pop.kcnet.com> Message-ID: <4.3.2.7.2.20010822081617.00dcab00@pop.kcnet.com> At 08:43 AM 8/21/2001 +0200, Peter Funk wrote: >Grant Griffin: > > PEP: 265 > > Title: Sorting Dictionaries by Value >[...] > > 1) Is this useful enough to justify the feature/code bloat? (Tim has > > suggested that this might be a hard sell to Guido, so if you like it in > > whatever form, let's hear from you!) > >I think, this is feature bloat. IMHO using dictionaries as counters >for something is only one very special application of this generic >basic data structure. > >A standard library module containing a class derived from >dictionary should be able to fullfill this 'batteries included' wish. >The documentation of the builtin type dictionary could contain >pointers to useful derived classes, so that newbies seeking such >a feature have a better chance to find it. That's not a bad idea, and if that's how this turns out, I will think it had turned out well. However, the problem I see with a class-based approach is that this is such a small thing that I'm not even sure how to write a class for it that isn't more grandiose than it deserves. (Tim's suggestion might help here by expanding the scope of the idea .) In comparison, the simplest of my proposals--the one I'm favoring at the moment--is just to add a boolean parameter to items: items(values_first=0) This basically avoids the need for the tuple swap: >>> items = [(v, k) for (k, v) in items] and it's somewhat faster in the sort-by-values case, because the tuples are built in the right order rather than being built in the wrong order, then swapped. So, in terms of feature bloat, we have one new parameter. And in terms of code bloat, we have what I estimate to be 4-15 lines of C (depending on whether you optimize on speed or size.) I guess my sense is that the bloat is small enough to be worth it. thanks, =g2 From guido@python.org Wed Aug 22 15:15:37 2001 From: guido@python.org (Guido van Rossum) Date: Wed, 22 Aug 2001 10:15:37 -0400 Subject: [Python-Dev] PEP 265 - Sorting Dictionaries by Value In-Reply-To: Your message of "Wed, 22 Aug 2001 08:32:57 CDT." <4.3.2.7.2.20010822081617.00dcab00@pop.kcnet.com> References: <4.3.2.7.2.20010820215632.00cb69e0@pop.kcnet.com> <4.3.2.7.2.20010822081617.00dcab00@pop.kcnet.com> Message-ID: <200108221415.KAA27226@cj20424-a.reston1.va.home.com> > However, the problem I see with a class-based approach is that this > is such a small thing that I'm not even sure how to write a class > for it that isn't more grandiose than it deserves. Believe me, adding a new method to a heavily-used built-in object is much more grandiose than adding a library module. In addition to "15 lines of code" we need to update the documentation, add a few lines to the test suite, add code to Jython mimicking the feature; 30 books will be a little more out of date, and so on. --Guido van Rossum (home page: http://www.python.org/~guido/) From DavidA@ActiveState.com Wed Aug 22 17:27:09 2001 From: DavidA@ActiveState.com (David Ascher) Date: Wed, 22 Aug 2001 09:27:09 -0700 Subject: [Python-Dev] copy, len and the like as 'object' methods? References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> Message-ID: <3B83DD5D.3260BC9C@ActiveState.com> Guido van Rossum wrote: > > > I just came back from teaching Python on a cruise ship attended by > > mostly Perl folks. It was an interesting experience teaching Python > > with Randal in the audience =). > > Tell us more... Not much to tell. Randal was polite in my class and didn't interrupt too much =). There were some interesting discussions between Paul Prescod, Cameron Laird, Damian Conway, Mark-Jason Dominus, Randal and myself about Perl 6, which is looking more and more like Python from what I can tell. The most interesting bit of knowledge I learned is that the $, % and @ characters have a name -- they are sigils. And their use is going to change in Perl 6 to be consistent across contexts, as they'll be bound with the variable. Soon I may be able to say that "If Python hadn't been around, Perl 6 would be my language of choice". > Except that __int__ is poorly defined -- sometimes it is used as a > precision-losing number cast (e.g. int(3.5) returns 3), sometimes it > is an exact conversion (e.g. int("3")). Actually, that doesn't bother me -- the definition which works well is "convert yourself to an integer". The fact that the float object decided to consider that as a truncation is possibly a bug in the float object's decision, but __int__ is still 'convert to int, however you (the type) see fit'. > Yes, it's an old Python choice. OO zealots don't like it much, but it > has the advantage that you don't have to introduce methods right > away. Too late to change. I wasn't suggesting that we change it. Only that we add methods to the objects, much like we added string methods but kept the string module. > str() has won -- in part because of its name, in part because it is > the "copy constructor", returning a string input unchanged. Ah, subtle point I had missed. > I'd say leave it alone (we're getting enough complaints about > "gratuitous" language changes as it is, and the changes we've > committed to have very good reasons). Again, I wasn't considering getting rid of old builtins. We're going to be adding new methods to all of the types anyway (since they'll derive from object), so I was just suggesting that len or length be an alias for __len__. A minor issue at most. Cheers, --david From guido@python.org Wed Aug 22 17:40:45 2001 From: guido@python.org (Guido van Rossum) Date: Wed, 22 Aug 2001 12:40:45 -0400 Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: Your message of "Wed, 22 Aug 2001 09:27:09 PDT." <3B83DD5D.3260BC9C@ActiveState.com> References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> Message-ID: <200108221640.f7MGejt29123@odiug.digicool.com> > Again, I wasn't considering getting rid of old builtins. We're going to > be adding new methods to all of the types anyway (since they'll derive > from object), so I was just suggesting that len or length be an alias > for __len__. Hm, but this would violate TOOWTDI. --Guido van Rossum (home page: http://www.python.org/~guido/) From Samuele Pedroni Wed Aug 22 17:46:52 2001 From: Samuele Pedroni (Samuele Pedroni) Date: Wed, 22 Aug 2001 18:46:52 +0200 (MET DST) Subject: [Python-Dev] PEP 252, PEP 253 and jython issues Message-ID: <200108221647.SAA28110@core.inf.ethz.ch> FYI I'm up to finish with the whole picture tour of PEP 252/PEP 253 wrt to pontential jython issues. My head has not exploded but I'm a bit worried: - on one hand for the amount of work that seems necessary on Jython side (but that's our problem) - on the other hand by some design tangle: how to mostly preserve the codebase, how to make the life for advanced users easy and natural, how to follow the spec. I hope both that I'm just not clever enough and I have overlooked things wrongly ... Here is an outline: high-probably non-issues: descr stuff up to backward compatibility with non doc/ supported stuff top elements of the type/metatype hiearchies. potential issues (design tangles): "layout/inheritance scheme for types/subclassed types": - subclassing of types (in java, in Jython) - multiple inheritance in the context of type subclassing - mro - potential mismatch between concrete subclassing (how Jython is coded and probably users hope to do subclassing) and "delegation" (how CPython is coded) - interdipendence between object behaviours in CPython, and Jython codebase and typical idioms - how super/dynamic binded behaviour should be invoked? from C/Python/Java tomorrow will follow a filled-in version. regards, Samuele Pedroni. From DavidA@ActiveState.com Wed Aug 22 17:55:54 2001 From: DavidA@ActiveState.com (David Ascher) Date: Wed, 22 Aug 2001 09:55:54 -0700 Subject: [Python-Dev] copy, len and the like as 'object' methods? References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> <200108221640.f7MGejt29123@odiug.digicool.com> Message-ID: <3B83E41A.DC0DE5D@ActiveState.com> Guido van Rossum wrote: > > > Again, I wasn't considering getting rid of old builtins. We're going to > > be adding new methods to all of the types anyway (since they'll derive > > from object), so I was just suggesting that len or length be an alias > > for __len__. > > Hm, but this would violate TOOWTDI. So do string methods =). --da From paulp@ActiveState.com Wed Aug 22 18:39:39 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Wed, 22 Aug 2001 09:39:39 -0800 Subject: [Python-Dev] copy, len and the like as 'object' methods? References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> Message-ID: <3B83EE5B.CEB38C48@ActiveState.com> David Ascher wrote: > >... > > Not much to tell. Randal was polite in my class and didn't interrupt > too much =). Randal was polite in general but there was a point where he interjected: "And you say *Perl* has a lot of special cases? Python seems to have just as many!" These "function syntaxed methods" are one example but there are others. Some of the others are convenient (e.g. special casing of non-tuples after %) and some are backwards compatibility issues. Also, every time we'd point to a feature of Python (OO syntax, exception handling, generators, *) that was clearly better than Perl, Randal claimed it was already slated to be fixed for Perl 6. We suggested he print t-shirts with that refrain. > ... There were some interesting discussions between Paul > Prescod, Cameron Laird, Damian Conway, Mark-Jason Dominus, Randal and > myself about Perl 6, which is looking more and more like Python from > what I can tell. My sense was "Second System Syndrome" but Damian Conway is confident that they don't have that problem. * from my point of view it seemed that we agreed that Python was better than Perl at almost everything but then I didn't sit in on Damian's "Data Munging" talk. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook From jeremy@zope.com Wed Aug 22 18:52:06 2001 From: jeremy@zope.com (Jeremy Hylton) Date: Wed, 22 Aug 2001 13:52:06 -0400 (EDT) Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: <3B83EE5B.CEB38C48@ActiveState.com> References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> <3B83EE5B.CEB38C48@ActiveState.com> Message-ID: <15235.61766.827878.699521@slothrop.digicool.com> >>>>> "PP" == Paul Prescod writes: PP> My sense was "Second System Syndrome" but Damian Conway is PP> confident that they don't have that problem. Isn't that one of the signs of the second system effect? <0.5 wink> Did he offer any reason for his confidence? Jeremy From James_Althoff@i2.com Wed Aug 22 19:11:51 2001 From: James_Althoff@i2.com (James_Althoff@i2.com) Date: Wed, 22 Aug 2001 11:11:51 -0700 Subject: [Python-Dev] copy, len and the like as 'object' methods? Message-ID: David Ascher wrote: >Again, I wasn't considering getting rid of old builtins. We're going to >be adding new methods to all of the types anyway (since they'll derive >from object), so I was just suggesting that len or length be an alias >for __len__. (While admittedly being an OO zealot ;-) I too would be pleased to see a len/length method. And I really enjoy using the new string methods. Thanks for adding them! :-) Jim From paulp@ActiveState.com Wed Aug 22 19:35:23 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Wed, 22 Aug 2001 10:35:23 -0800 Subject: [Python-Dev] copy, len and the like as 'object' methods? References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> <200108221640.f7MGejt29123@odiug.digicool.com> Message-ID: <3B83FB6B.5AF81238@ActiveState.com> Guido van Rossum wrote: > > > Again, I wasn't considering getting rid of old builtins. We're going to > > be adding new methods to all of the types anyway (since they'll derive > > from object), so I was just suggesting that len or length be an alias > > for __len__. > > Hm, but this would violate TOOWTDI. I am not an OO zealot but I am a consistency zealot. Calling a function that just turns around and calls a method is somewhat confusing and increasingly out of step with all of the other languages that support OO. I would appreciate if you could put this on the long-term fixes list and then you could choose an appropriate time when the howls of pain would be subdued. It really isn't in the same class as the division change because it is easy to interpret old code in the old way. We could support the "preferred syntax" and the "legacy syntax" indefinitely and there would still only one RIGHT way to do it. (just like you could still throw strings as exceptions but you aren't supposed to...) -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook From DavidA@ActiveState.com Wed Aug 22 19:44:36 2001 From: DavidA@ActiveState.com (David Ascher) Date: Wed, 22 Aug 2001 11:44:36 -0700 Subject: [Python-Dev] copy, len and the like as 'object' methods? References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> <3B83EE5B.CEB38C48@ActiveState.com> <15235.61766.827878.699521@slothrop.digicool.com> Message-ID: <3B83FD94.515D871@ActiveState.com> Jeremy Hylton wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> My sense was "Second System Syndrome" but Damian Conway is > PP> confident that they don't have that problem. > > Isn't that one of the signs of the second system effect? <0.5 wink> > > Did he offer any reason for his confidence? I think the fundamental source of their confidence lay in Randal's answer when I challenged the claim that they would write translators which would automatically translate 95% of Perl5 code to Perl6: "If we're smart enough to write Perl5, we can do this". I think it glosses over a lot of important issues, but this isn't the forum to discuss it. Perl6 is being defined pretty much as the kitchen sink -- any cool feature from any cool language is going to be supported. Paul and I are skeptical about the ability to make that a coherent whole, but then again Perl doesn't really claim coherence, from what I can tell. Perl6 will have generators, coroutines but not continuations, higher-order functions, etc. etc. At the same time, they're trying to fix some of the issues which made Perl4/5 hard to learn, such as sigil mutability, etc. It's designed by committees (30 or so?), on the assumption that integration is a smaller issue than designing each 'feature' well. It's an interesting project to watch from the outside. There is also apparently a real split between people who are involved in Perl6 and those who aren't at all. I did have a very interesting chat w/ Damian Conway -- he said that Perl6 is already succeeding because it's revitalized the Perl5 community, and that there are lots of high-quality modules added to CPAN inspired by the Perl6 discussions. It also makes me a little jealous -- Perl manages to be a place where significant progress is made in the libraries as distinct from the core. In Pythonia, there is too much emphasis among the elite (us =) on adding features to the core as opposed to library modules, IMO. Related is the fact that much 'cutting-edge' work in Perl is written in Perl, while most of the cutting edge stuff in Pythonia is done in C. Some of that relates to the almost infinite mutability of the Perl engine by Perl itself, which is not a design goal of Python's -- we don't want 'just anyone' adding new keywords, for example. Still, there is room for exploration and prototyping there which we don't have such easy access to. --david From barry@zope.com Wed Aug 22 19:55:49 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 22 Aug 2001 14:55:49 -0400 Subject: [Python-Dev] RELEASED: Python 2.2a2 is out! Message-ID: <15236.53.399240.678090@yyz.digicool.com> We've released Python 2.2a2, the second alpha for Python 2.2, for your enjoyment, education, and edification. Download it from: http://www.python.org/2.2/ Give it a good try, and report what breaks to the bug tracker: http://sourceforge.net/bugs/?group_id=5470 New features in this release include: - Tim Peters developed a brand new Windows installer using Wise 8.1, generously donated to us by Wise Solutions. - The floor division operator // has been added as outlined in PEP 238. The / operator still provides classic division (and will until Python 3.0) unless "from __future__ import division" is included, in which case the / operator will provide true division. - The type/class unification (PEP 252-253) was integrated into the trunk and is not so tentative any more (the exact specification of some features is still tentative). A lot of work has done on fixing bugs and adding robustness and features (performance still has to come a long way). - Lots of bug fixes, contributed patches, and other stuff. See the Misc/NEWS file in the distribution, or see the release notes on SourceForge: http://sourceforge.net/project/shownotes.php?release_id=49302 As usual, Andrew Kuchling is writing a gentle introduction to the most important changes (currently excluding type/class unification), titled "What's New in Python 2.2": http://www.amk.ca/python/2.2/ There is an introduction to the type/class unification at: http://www.python.org/2.2/descrintro.html Thanks to everybody who contributed to this release, including all the 2.2 alpha 1 testers! Enjoy! -Barry & Guido From paulp@ActiveState.com Wed Aug 22 19:56:33 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Wed, 22 Aug 2001 10:56:33 -0800 Subject: [Python-Dev] copy, len and the like as 'object' methods? References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> <3B83EE5B.CEB38C48@ActiveState.com> <15235.61766.827878.699521@slothrop.digicool.com> Message-ID: <3B840061.A55BA194@ActiveState.com> Jeremy Hylton wrote: > > >>>>> "PP" == Paul Prescod writes: > > PP> My sense was "Second System Syndrome" but Damian Conway is > PP> confident that they don't have that problem. > > Isn't that one of the signs of the second system effect? <0.5 wink> > > Did he offer any reason for his confidence? Nothing directly to that question (we ran out of time). But overall of the Perl guys said things like: a) we're got a bunch smart people working on it (Larry, Damian, Dan, etc.) b) everything we're doing has been done somewhere before so it isn't research (e.g. generators, proper exception handling, decent OO syntax, etc.) c) Perl 5 is a pretty complex system and people of similar caliber built that so why should Perl 6 be any different d) Perl 6's implementation will be so much cleaner than Perl 5's that integration of parts will be a lot easier. e) we've set up all of these working groups to parallelize development and that will help alot too. http://www.perl.com/pub/a/2000/09/perl6mail.html I think that they are way too optimistic, but there were a few things I learned that at least hinted in directions of sanity: Perl 5 support may be provided through some sort of dual interpreter model rather than trying to write a single interpreter that supports both. Dual interpreters are pretty well understood (pyperl, jpe, Perl.NET etc.) So "full backwards compatibility" may be possible using that trick. And Damian is trying to talk Larry out of a strict requirement that the Perl compiler be written in Perl. Also, as David just said, you have to remember that Python people have a much higher bar of coherence to jump over than the Perl guys. If they put a bunch of random stuff in the language in a way that didn't really feel right together -- then it would be just like Perl 5 only with more features. Whereas we spend a week debating how the 'yield' keyword should interact with the 'def' keyword. Damian also said that Perl 6 has to be faster than Perl 5 or nobody will use it. Neil Bauman asked him why Perl wasn't being written in Perl (Neil's opinion is that Perl is literally the greatest language ever created). Damian responded with a great quote: "Performance. If Performance wasn't an issue, I'd probably write Perl 6 in Python or something like it with wonderfully beautiful OO abstractions and it would run like a dog." -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook From akuchlin@mems-exchange.org Wed Aug 22 20:07:46 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 22 Aug 2001 15:07:46 -0400 Subject: [Python-Dev] Library development In-Reply-To: <3B83FD94.515D871@ActiveState.com>; from DavidA@ActiveState.com on Wed, Aug 22, 2001 at 11:44:36AM -0700 References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> <3B83EE5B.CEB38C48@ActiveState.com> <15235.61766.827878.699521@slothrop.digicool.com> <3B83FD94.515D871@ActiveState.com> Message-ID: <20010822150746.A21476@ute.mems-exchange.org> On Wed, Aug 22, 2001 at 11:44:36AM -0700, David Ascher wrote: >which would automatically translate 95% of Perl5 code to Perl6: "If >we're smart enough to write Perl5, we can do this". I think it glosses "We let our code base deteroriate into an incomprehensible mess of code, and damn it, we can do it again!" >libraries as distinct from the core. In Pythonia, there is too much >emphasis among the elite (us =) on adding features to the core as >opposed to library modules, IMO. Related is the fact that much >'cutting-edge' work in Perl is written in Perl, while most of the >cutting edge stuff in Pythonia is done in C. Some of that relates to *Yes*. That's mostly why I've been drifting away from python-dev, too; the core is becoming more and more dull, the new features are more and more esoteric, and the more interesting action is in Python-based applications and libraries. As a bonus, if I work on a standalone package, I don't need to worry if a change is going to screw up the X thousands of Python users; only the much smaller pool of users of the package is at risk, and it's easier to decide to break things or provide backwards compatibility. >new keywords, for example. Still, there is room for exploration and >prototyping there which we don't have such easy access to. Tools/compiler lets you try out language modifications, though, so it's equally possible to do that with Python (witness PTL). We just don't do that very much, that's all. --amk From barry@scottb.demon.co.uk Wed Aug 22 20:19:40 2001 From: barry@scottb.demon.co.uk (Barry Scott) Date: Wed, 22 Aug 2001 20:19:40 +0100 Subject: [Python-Dev] PEP 265 - Sorting Dictionaries by Value In-Reply-To: <200108221415.KAA27226@cj20424-a.reston1.va.home.com> Message-ID: <000701c12b3f$642ab8e0$060210ac@private> Of course you'd still have to update the docs to point the folks to the useful comparison functions to use with sort. Barry > -----Original Message----- > From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On > Behalf Of Guido van Rossum > Sent: 22 August 2001 15:16 > To: Grant Griffin > Cc: Peter Funk; python-dev@python.org > Subject: Re: [Python-Dev] PEP 265 - Sorting Dictionaries by Value > > > > However, the problem I see with a class-based approach is that this > > is such a small thing that I'm not even sure how to write a class > > for it that isn't more grandiose than it deserves. > > Believe me, adding a new method to a heavily-used built-in object is > much more grandiose than adding a library module. In addition to "15 > lines of code" we need to update the documentation, add a few lines to > the test suite, add code to Jython mimicking the feature; 30 books > will be a little more out of date, and so on. > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > From barry@scottb.demon.co.uk Wed Aug 22 20:25:05 2001 From: barry@scottb.demon.co.uk (Barry Scott) Date: Wed, 22 Aug 2001 20:25:05 +0100 Subject: [Python-Dev] PEP 265 - Sorting Dictionaries by Value In-Reply-To: <200108220043.UAA24429@cj20424-a.reston1.va.home.com> Message-ID: <000801c12b40$25ae3640$060210ac@private> Oh I like that! > Or better still, list.sort() wouldn't need to be changed at all if > there was a standard library module to create compison routines, e.g. > > from __future__ import nested_scopes > > def cmp_by_index(i): > return lambda a, b: cmp((a[i], a), (b[i], b)) How should all the variations be handled? * uses a naming convention and create the functions one by one? cmp_by_index_accending - sort low to high at index n cmp_by_index_decending - sort high to low at index n cmp_by_field_accending - sort low to high at field n cmp_by_field_decending - sort high to low at field n ... case blind, case sensitive versions... * have a make_cmp function that takes a description and build the cmp function on demand? Would the description be a string with keywords in it? "index=4,accending field=5,case-blind,decending" sort by index 4 accending then by field=5 case blind comparison. Barry From guido@python.org Wed Aug 22 20:38:25 2001 From: guido@python.org (Guido van Rossum) Date: Wed, 22 Aug 2001 15:38:25 -0400 Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: Your message of "Wed, 22 Aug 2001 09:39:39 -0800." <3B83EE5B.CEB38C48@ActiveState.com> References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> <3B83EE5B.CEB38C48@ActiveState.com> Message-ID: <200108221938.f7MJcPj29382@odiug.digicool.com> > My sense was "Second System Syndrome" but Damian Conway is confident > that they don't have that problem. Yeah, right. It has second system syndrome written all over it. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From barry@zope.com Wed Aug 22 20:38:33 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 22 Aug 2001 15:38:33 -0400 Subject: [Python-Dev] copy, len and the like as 'object' methods? References: Message-ID: <15236.2617.169057.464118@anthem.wooz.org> >>>>> "JA" == James Althoff writes: JA> (While admittedly being an OO zealot ;-) I too would be JA> pleased to see a len/length method. I have to admit I miss them too sometimes. ;) From Greg.Wilson@baltimore.com Wed Aug 22 20:36:21 2001 From: Greg.Wilson@baltimore.com (Greg Wilson) Date: Wed, 22 Aug 2001 15:36:21 -0400 Subject: [Python-Dev] Re: copy, len and the like as 'object' methods? Message-ID: <930BBCA4CEBBD411BE6500508BB3328F3A8ECC@nsamcanms1.ca.baltimore.com> FWIW, David's 'len()' methods would definitely make Python easier to teach --- just about every beginner types 'x.len()' instead of 'len(x)' over and over during their first two or three exercises. Greg ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From guido@python.org Wed Aug 22 20:46:01 2001 From: guido@python.org (Guido van Rossum) Date: Wed, 22 Aug 2001 15:46:01 -0400 Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: Your message of "Wed, 22 Aug 2001 11:11:51 PDT." References: Message-ID: <200108221946.f7MJk1j29412@odiug.digicool.com> > David Ascher wrote: > >Again, I wasn't considering getting rid of old builtins. We're going to > >be adding new methods to all of the types anyway (since they'll derive > >from object), so I was just suggesting that len or length be an alias > >for __len__. James Althoff: > (While admittedly being an OO zealot ;-) I too would be pleased to see a > len/length method. And I really enjoy using the new string methods. > Thanks for adding them! :-) While it will admittedly take a while, the intention of string methods was to eventually phase out the string module. So TOOWTDI is only violated during the transition. If we decide to add a len() method, we'll also have to decide to (eventually) get rid of len(), or we'd violate TOOWTDI *permanently*. Personally, I don't think that the "problem" this change is addressing is worth asking everybody to change their code -- so we'd have live with len(x) and x.len() as viable ways to ask for x's length *forever*, violating TOOWTDI permanently. I don't like that. (You may disagree, but at least I have thought about it and I can explain my motivation. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From dan@sidhe.org Wed Aug 22 20:57:34 2001 From: dan@sidhe.org (Dan Sugalski) Date: Wed, 22 Aug 2001 15:57:34 -0400 Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: <200108221938.f7MJcPj29382@odiug.digicool.com> References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> <3B83EE5B.CEB38C48@ActiveState.com> Message-ID: <5.1.0.14.0.20010822155714.08b95330@tuatha.sidhe.org> At 03:38 PM 8/22/2001 -0400, Guido van Rossum wrote: > > My sense was "Second System Syndrome" but Damian Conway is confident > > that they don't have that problem. > >Yeah, right. It has second system syndrome written all over it. :-) You underestimate the amount of black-hearted cynicism we can muster. ;-P Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk From dan@sidhe.org Wed Aug 22 20:57:01 2001 From: dan@sidhe.org (Dan Sugalski) Date: Wed, 22 Aug 2001 15:57:01 -0400 Subject: [Python-Dev] Library development In-Reply-To: <20010822150746.A21476@ute.mems-exchange.org> References: <3B83FD94.515D871@ActiveState.com> <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> <3B83EE5B.CEB38C48@ActiveState.com> <15235.61766.827878.699521@slothrop.digicool.com> <3B83FD94.515D871@ActiveState.com> Message-ID: <5.1.0.14.0.20010822155219.08c3a4b0@tuatha.sidhe.org> At 03:07 PM 8/22/2001 -0400, Andrew Kuchling wrote: >On Wed, Aug 22, 2001 at 11:44:36AM -0700, David Ascher wrote: > >which would automatically translate 95% of Perl5 code to Perl6: "If > >we're smart enough to write Perl5, we can do this". I think it glosses > > "We let our code base deteroriate into an incomprehensible >mess of code, and damn it, we can do it again!" Now, now, let's not throw stones. :) >*Yes*. That's mostly why I've been drifting away from python-dev, >too; the core is becoming more and more dull, the new features are >more and more esoteric, and the more interesting action is in >Python-based applications and libraries. As a bonus, if I work on a >standalone package, I don't need to worry if a change is going to >screw up the X thousands of Python users; only the much smaller pool >of users of the package is at risk, and it's easier to decide to break >things or provide backwards compatibility. Is this a bad thing, though? C's not changed much in the past decade or two, but look at how much more canned functionality's available now than in, say, 1980. (Heck, add Perl, Python, and Ruby to the list of C's canned functionality if you like) Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk From dan@sidhe.org Wed Aug 22 20:51:59 2001 From: dan@sidhe.org (Dan Sugalski) Date: Wed, 22 Aug 2001 15:51:59 -0400 Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: <3B83FD94.515D871@ActiveState.com> References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> <3B83EE5B.CEB38C48@ActiveState.com> <15235.61766.827878.699521@slothrop.digicool.com> Message-ID: <5.1.0.14.0.20010822153946.08c02de8@tuatha.sidhe.org> At 11:44 AM 8/22/2001 -0700, David Ascher wrote: >Jeremy Hylton wrote: > > > > >>>>> "PP" == Paul Prescod writes: > > > > PP> My sense was "Second System Syndrome" but Damian Conway is > > PP> confident that they don't have that problem. > > > > Isn't that one of the signs of the second system effect? <0.5 wink> > > > > Did he offer any reason for his confidence? > >I think the fundamental source of their confidence lay in Randal's >answer when I challenged the claim that they would write translators >which would automatically translate 95% of Perl5 code to Perl6: "If >we're smart enough to write Perl5, we can do this". I think it glosses >over a lot of important issues, but this isn't the forum to discuss it. Randal's confidence is based in some part on the fact that he's watching other people do it, and it's a lot easier to be confident that way. :) I, on the other hand, am nervous as all hell, honestly. (OTOH I feel the same way about raising my kids) Perl 5 to perl 6 isn't that tough though (we do chunks of Python and Ruby to perl 5, after all), and we do have a full-featured perl 5 parser handy. It's as much a task of either reimplementing the perl 5 C-based parser in perl as part of the perl 6 parser front-end (Non-trivial, but not rocket science either) or build a perl 5 bytecode->perl 6 bytecode translator, which is significantly easier. Or just teach the perl 5 parser to spit out a syntax tree, which it pretty much does already. >Perl6 is being defined pretty much as the kitchen sink -- any cool >feature from any cool language is going to be supported. > >It's designed by committees (30 or so?), on the >assumption that integration is a smaller issue than designing each >'feature' well. Forgive the snippage, but the above two quotes are directly related. Perl 6 the language is *not* being designed by committees, though parts of it look that way from the outside. There's exactly one person responsible for the design of perl 6--Larry. Damian's feeding a lot of interesting ideas to him, but Larry's ultimately responsible for putting together a coherent whole. The committee setup at the beginning was designed to let the people who had an interest in a particular topic get together and flesh out a proposal or four for Larry, but we made no promises that the proposals would see the light of day unchanged in the final language design. The internals design is being handled by a small group of folks, about six, each of us with a different area of competence. We're working things out so we have some good walls between components so they can be implemented semi-separately and in parallel. Part of me would like to have the "design by committee" feel stand until we pull the rabbit out of the hat later, but that might convince people that committee design can actually work in large projects and, well, we have enough of that nonsense around as it is. >I did have a very interesting chat w/ Damian Conway -- he said that >Perl6 is already succeeding because it's revitalized the Perl5 >community, FWIW, the success does spread beyond perl. If nothing else, there's a fair amount of "Perl can do that? Well, then, so can *my* language!" feeling amongst folks who feel strongly about languages and such. (Can't imagine who that'd be... :) Perl's doing more, which is prompting folks to do more in other languages, as a tit for tat thing if nothing else. And most any time you add functionality, everybody wins. Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk From skip@pobox.com (Skip Montanaro) Wed Aug 22 21:01:30 2001 From: skip@pobox.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 22 Aug 2001 15:01:30 -0500 Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: <3B83FD94.515D871@ActiveState.com> References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> <3B83EE5B.CEB38C48@ActiveState.com> <15235.61766.827878.699521@slothrop.digicool.com> <3B83FD94.515D871@ActiveState.com> Message-ID: <15236.3994.507401.287832@beluga.mojam.com> David> It also makes me a little jealous -- Perl manages to be a place David> where significant progress is made in the libraries as distinct David> from the core. In Pythonia, there is too much emphasis among the David> elite (us =) on adding features to the core as opposed to library David> modules, IMO. Related is the fact that much 'cutting-edge' work David> in Perl is written in Perl, while most of the cutting edge stuff David> in Pythonia is done in C. I think there is a lot of emphasis in the Python community on getting the platform "right". That leads to long debates about the correct way to do division, for instance. Also, Python is more platform-independent than Perl, so more work is necessary in the core to make and keep it that way. In addition, check out "man perlguts". The first statement begins This document attempts to describe how to use the Perl API, ... No hedging is necessary in either the Python C API manual or the Python Extending and Embedding manual. In fact, in the Extending and Embedding manual begins It is quite easy to add new built-in modules to Python, if you know how to program in C. So the problem you describe is is clearly Guido fault. He made Python's internals too clean. If he would have obfuscated the internals more, more people would have been drawn to the libraries (or repelled by the internals). ;-) On the flip side, I also think there is a lot of cool stuff going on in the library sector. You don't hear about it as much in part because Python doesn't have an equivalent to CPAN. I'm not talking just about the cataloging part (Vaults of Parnassus), but the build part (distutils) and automatic mirroring/dependency checking/download part (for which Python has, as yet, nothing remotely like it). That makes the barrier to use of libraries (and thus use by a critical mass) not in the core that much higher. There are how many Python Server Pages like things? They probably all have some very nifty features, but tend to be used by rather small pockets of people, at least relative to the overall segment of the Python community doing webish stuff. I'm not entirely sure why that's the case, but I suspect it has to do in part with the barrier to discovering, downloading, and installing these packages. Skip From paulp@ActiveState.com Wed Aug 22 21:45:57 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Wed, 22 Aug 2001 13:45:57 -0700 Subject: [Python-Dev] More feedback from script scape Message-ID: <3B841A05.F292DD5B@ActiveState.com> Something else I heard at script scape is that for simple extensions (wrappers around C code) Perl has not only caught up to Python but surpassed it thanks to inline::C, inline::Python etc. As soon as you move to doing anything complicated with the interpreter internals, Python wins again, but it still annoys me that Perl has leapfrogged us in wrapping simplicity! -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook From paulp@ActiveState.com Wed Aug 22 22:03:42 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Wed, 22 Aug 2001 14:03:42 -0700 Subject: [Python-Dev] Perl5->Perl6 References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> <3B83EE5B.CEB38C48@ActiveState.com> <15235.61766.827878.699521@slothrop.digicool.com> <5.1.0.14.0.20010822153946.08c02de8@tuatha.sidhe.org> Message-ID: <3B841E2E.C3B462C8@ActiveState.com> Dan Sugalski wrote: > >... > > Perl 5 to perl 6 isn't that tough though (we do chunks of Python and Ruby > to perl 5, after all), and we do have a full-featured perl 5 parser handy. You guys are really focused on the syntax, but to me, the difficult things to handle are subtle *semantic* changes. That's why I said in another message that a two-interpreter system might be the easiest route. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook From dan@sidhe.org Wed Aug 22 22:17:12 2001 From: dan@sidhe.org (Dan Sugalski) Date: Wed, 22 Aug 2001 17:17:12 -0400 Subject: [Python-Dev] Perl5->Perl6 In-Reply-To: <3B841E2E.C3B462C8@ActiveState.com> References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> <3B83EE5B.CEB38C48@ActiveState.com> <15235.61766.827878.699521@slothrop.digicool.com> <5.1.0.14.0.20010822153946.08c02de8@tuatha.sidhe.org> Message-ID: <5.1.0.14.0.20010822170534.08c50170@tuatha.sidhe.org> At 02:03 PM 8/22/2001 -0700, Paul Prescod wrote: >Dan Sugalski wrote: > > > >... > > > > Perl 5 to perl 6 isn't that tough though (we do chunks of Python and Ruby > > to perl 5, after all), and we do have a full-featured perl 5 parser handy. > >You guys are really focused on the syntax, but to me, the difficult >things to handle are subtle *semantic* changes. That's why I said in >another message that a two-interpreter system might be the easiest >route. Well, as I've had some Python (and Java) folks happily point out, perl doesn't have any well-defined semantics anyway. :) Seriously, we've a reasonably comprehensive test suite now with perl 5, and a very large code base with expected behavior to draw on to test the conversion. Much of the perl 5->perl 6 transition is strictly syntactic. It's possible that some of perl 5's undefined edge behaviour won't translate, but that'll only be because Larry's decided not to make it translate. Anything else is a bug, and one to be squashed. (We're not losing turing-completeness--perfect execution of past behaviour isn't unattainable) This isn't, after all, the first, or second, or even third time we've done this. The version number's 6 for a reason... Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk From gstein@lyra.org Wed Aug 22 23:29:42 2001 From: gstein@lyra.org (Greg Stein) Date: Wed, 22 Aug 2001 15:29:42 -0700 Subject: huge sig (was: Re: [Python-Dev] Re: copy, len and the like as 'object' methods?) In-Reply-To: <930BBCA4CEBBD411BE6500508BB3328F3A8ECC@nsamcanms1.ca.baltimore.com>; from Greg.Wilson@baltimore.com on Wed, Aug 22, 2001 at 03:36:21PM -0400 References: <930BBCA4CEBBD411BE6500508BB3328F3A8ECC@nsamcanms1.ca.baltimore.com> Message-ID: <20010822152941.E15670@lyra.org> Euh... that .sig is *way* bigger than your message. And it doesn't really apply to a public forum, now does it? :-) Cheers, -g On Wed, Aug 22, 2001 at 03:36:21PM -0400, Greg Wilson wrote: > FWIW, David's 'len()' methods would definitely make Python easier > to teach --- just about every beginner types 'x.len()' instead of > 'len(x)' over and over during their first two or three exercises. > > Greg > > > ----------------------------------------------------------------------------------------------------------------- > The information contained in this message is confidential and is intended > for the addressee(s) only. If you have received this message in error or > there are any problems please notify the originator immediately. The > unauthorized use, disclosure, copying or alteration of this message is > strictly forbidden. Baltimore Technologies plc will not be liable for direct, > special, indirect or consequential damages arising from alteration of the > contents of this message by a third party or as a result of any virus being > passed on. > > In addition, certain Marketing collateral may be added from time to time to > promote Baltimore Technologies products, services, Global e-Security or > appearance at trade shows and conferences. > > This footnote confirms that this email message has been swept by > Baltimore MIMEsweeper for Content Security threats, including > computer viruses. > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From aahz@rahul.net Wed Aug 22 23:48:54 2001 From: aahz@rahul.net (Aahz Maruch) Date: Wed, 22 Aug 2001 15:48:54 -0700 (PDT) Subject: [Python-Dev] Deprecation of the string module In-Reply-To: <200108221946.f7MJk1j29412@odiug.digicool.com> from "Guido van Rossum" at Aug 22, 2001 03:46:01 PM Message-ID: <20010822224855.31B8FE8C7@waltz.rahul.net> Guido van Rossum wrote: > > While it will admittedly take a while, the intention of string methods > was to eventually phase out the string module. So TOOWTDI is only > violated during the transition. I'm glad to see that you're using the past tense with regard to your intentions for the string module. (I'm phrasing this as a joke, but I'm utterly serious.) -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista I don't really mind a person having the last whine, but I do mind someone else having the last self-righteous whine. From barry@zope.com Wed Aug 22 23:53:05 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 22 Aug 2001 18:53:05 -0400 Subject: [Python-Dev] More feedback from script scape References: <3B841A05.F292DD5B@ActiveState.com> Message-ID: <15236.14289.311782.621168@anthem.wooz.org> >>>>> "PP" == Paul Prescod writes: PP> Something else I heard at script scape is that for simple PP> extensions (wrappers around C code) Perl has not only caught PP> up to Python but surpassed it thanks to inline::C, PP> inline::Python etc. As soon as you move to doing anything PP> complicated with the interpreter internals, Python wins again, PP> but it still annoys me that Perl has leapfrogged us in PP> wrapping simplicity! How about a PEP, Paul?! I've no clue what inline::C or inline::Python do, and no time to learn about it, but if you have a good grasp of them, try to think about how those ideas might translate to Python. A PEP on simplifying extension writing would be welcome. -Barry From paulp@ActiveState.com Wed Aug 22 23:53:53 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Wed, 22 Aug 2001 15:53:53 -0700 Subject: [Python-Dev] copy, len and the like as 'object' methods? References: <200108221946.f7MJk1j29412@odiug.digicool.com> Message-ID: <3B843801.BA1D8541@ActiveState.com> Guido van Rossum wrote: > >... > > While it will admittedly take a while, the intention of string methods > was to eventually phase out the string module. So TOOWTDI is only > violated during the transition. Why wouldn't a similar strategy work for length and string attributes? >... > Personally, I don't think that the "problem" this change is addressing > is worth asking everybody to change their code -- so we'd have live > with len(x) and x.len() as viable ways to ask for x's length > *forever*, violating TOOWTDI permanently. I don't like that. How was the string methods problem more serious than this one? I'm not trying to be difficult: I really don't perceive a difference. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook From ping@lfw.org Thu Aug 23 00:05:23 2001 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 22 Aug 2001 16:05:23 -0700 (PDT) Subject: [Python-Dev] Inline code in other languages In-Reply-To: <15236.14289.311782.621168@anthem.wooz.org> Message-ID: On Wed, 22 Aug 2001, Barry A. Warsaw wrote: > I've no clue what inline::C or inline::Python do, I went and checked this out after reading Paul's message. It seems the basic idea is that the Inline module will take a string containing C code, parse out the function declarations, generate the appropriate wrapper functions, compile an extension module to produce a .so file in a temporary directory, and dynamically load it on the spot. Functions with convertible argument and return types become subroutines callable from Perl. Quite slick. The end result is that you can say: use Inline C => 'void greet() { printf("Hello world!\n"); }'; greet; ...and have this work. This takes a long time the first time you do it, but the text of the inline code is MD5-hashed and the .so file is left lying around, so it's fast the next time around. It should be pretty feasible to do this for Python, i think, provided the sys module provides enough details about how Python was compiled and installed. -- ?!ng From paulp@ActiveState.com Thu Aug 23 00:10:58 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Wed, 22 Aug 2001 16:10:58 -0700 Subject: [Python-Dev] More feedback from script scape References: <3B841A05.F292DD5B@ActiveState.com> <15236.14289.311782.621168@anthem.wooz.org> Message-ID: <3B843C02.6EFEC933@ActiveState.com> "Barry A. Warsaw" wrote: > >... > > How about a PEP, Paul?! > > I've no clue what inline::C or inline::Python do, and no time to learn > about it, but if you have a good grasp of them, try to think about how > those ideas might translate to Python. A PEP on simplifying extension > writing would be welcome. I have only a superficial understanding which I can convey in this email. If you think my superficial understanding is worth PEP-ing, then I can do that. http://inline.perl.org/ Okay, remember in the old days when you did inline assembly in C code? You did that because assembly was a speedup over C and there were a few things you could do in assembly but not in C (e.g. talk directly to devices and registers by memory address). Fast forward to the present. Why do you use C extensions? 1. Speedup 2. Direct access to stuff that has a C API. So why not inline C in Python (or Perl)? use Inline C => <<'END_C'; void greet() { printf("Hello, world\n"); } END_C greet(); This does what you would expect. But what's going on under the hood? 1. Inline pseudo-parses the C code and looks for function and parameter declarations. 2. Inline generates the wrapper code that Python programmers usually either write by hand or get SWIG to do. 3. Inline generates a dynamic library in a special "cache" directory using MakeMaker, the system C compiler, etc. 4. Inline loads the library it just created as a Perl extension module. You (the user) invoke all of this stuff just by running the program. Inline doesn't recompile over and over again because it uses MD5 to recognize that the thing has already been compiled. Inline does have a strategy for dealing with modules that is supposed to be distributed instead of just used locally. It essentially compiles the code once and then you ask an external program to package it as a source or binary distribution. I suggest you skim the examples in this article: http://www.perl.com/pub/a/2001/02/inline.html You'll see: * calling win32 functions without using distutils or MakeMaker explicitly * writing a C program that behaves as if it were a script (no build step) * embedding Python in Perl and other weird stuff that will make you feel like your "head has just been wrapped around a brick". (quote from the article) -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook From paulp@ActiveState.com Thu Aug 23 00:19:19 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Wed, 22 Aug 2001 16:19:19 -0700 Subject: [Python-Dev] Inline code in other languages References: Message-ID: <3B843DF7.31198022@ActiveState.com> Ka-Ping Yee wrote: > >... > > It should be pretty feasible to do this for Python, i think, provided > the sys module provides enough details about how Python was compiled > and installed. I agree! The fundamental advantage of inline is that you don't have to worry about refcounts and PyObjects but you also don't have to learn to use SWIG. (SWIG might be helpful under the covers as the wrapper generator technology...) It also removes the whole build step from projects that want to wrap C code. This makes C extension wrapping much more Pythonic. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook From guido@python.org Thu Aug 23 00:17:33 2001 From: guido@python.org (Guido van Rossum) Date: Wed, 22 Aug 2001 19:17:33 -0400 Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: Your message of "Wed, 22 Aug 2001 15:53:53 PDT." <3B843801.BA1D8541@ActiveState.com> References: <200108221946.f7MJk1j29412@odiug.digicool.com> <3B843801.BA1D8541@ActiveState.com> Message-ID: <200108222317.TAA30578@cj20424-a.reston1.va.home.com> > > While it will admittedly take a while, the intention of string methods > > was to eventually phase out the string module. So TOOWTDI is only > > violated during the transition. > > Why wouldn't a similar strategy work for length and string attributes? It hardly worked for string methods (see Aahz's response). > >... > > Personally, I don't think that the "problem" this change is addressing > > is worth asking everybody to change their code -- so we'd have live > > with len(x) and x.len() as viable ways to ask for x's length > > *forever*, violating TOOWTDI permanently. I don't like that. > > How was the string methods problem more serious than this one? It was motivated by the advent of Unicode, which required us to think more OO. AFAICT, the len() method proposal is just an attempt to be more OO, and to avoid being made fun of by a bunch of Perlers. I don't care about #1, and it's naive to think that solving one issue will avoid #2. Any change like this has a *huge* cost to the community (just reread the division thread). > I'm not trying to be difficult: I really don't perceive a difference. I do -- see above. --Guido van Rossum (home page: http://www.python.org/~guido/) From James_Althoff@i2.com Thu Aug 23 00:52:40 2001 From: James_Althoff@i2.com (James_Althoff@i2.com) Date: Wed, 22 Aug 2001 16:52:40 -0700 Subject: [Python-Dev] copy, len and the like as 'object' methods? Message-ID: Guido wrote: >AFAICT, the len() method proposal is just an attempt to be more OO, >and to avoid being made fun of by a bunch of Perlers. I don't care >about #1, and it's naive to think that solving one issue will avoid >#2. I agree that it isn't so important to be swayed by #1 and #2 above. But there is a #3. I've introduced over fifty programmers (coming from Java) to Jython and a high percentage trip over this initially (momentarily, at least ;-). It doesn't take much to get past it, obviously, but it's a little nicer not to stumble to begin with. (my final 2 cents worth :-) Jim From paulp@ActiveState.com Thu Aug 23 00:54:21 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Wed, 22 Aug 2001 16:54:21 -0700 Subject: [Python-Dev] copy, len and the like as 'object' methods? References: <200108221946.f7MJk1j29412@odiug.digicool.com> <3B843801.BA1D8541@ActiveState.com> <200108222317.TAA30578@cj20424-a.reston1.va.home.com> Message-ID: <3B84462D.230FFF3F@ActiveState.com> Guido van Rossum wrote: > >... > > AFAICT, the len() method proposal is just an attempt to be more OO, > and to avoid being made fun of by a bunch of Perlers. I don't care > about #1, and it's naive to think that solving one issue will avoid > #2. OO is merely accidental. The real goal is to be more consistent. Python is a language that uses methods for polymorphism so consistency pushes towards methods. If Python were Scheme and had an OO appendage in the middle of its standard library I'd dislike that too. The only reason Perlers come into the picture is because they are pointing out that we claim to be consistent but in this case are not. And the only reason any of us care about consistency is because inconsistency has a cost in education and memorization...and according to Greg Wilson he's seen it first-hand in this case. (I personally had more experience with confusion over string functions instead of string methods) > Any change like this has a *huge* cost to the community (just reread > the division thread). Division is a special case. There is a big difference between re-purposing existing syntax and adding new methods to existing objects. If one is clearly the "new, better" way and the other is historical, then the books document the new way and most users eventually forget that the old way even exists. e.g. string exceptions, string.functions, UserDict (after type-class), regex, etc. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook From ping@lfw.org Thu Aug 23 01:04:23 2001 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 22 Aug 2001 17:04:23 -0700 (PDT) Subject: [Python-Dev] Re: copy, len and the like as 'object' methods? In-Reply-To: <3B84462D.230FFF3F@ActiveState.com> Message-ID: On Wed, 22 Aug 2001, Paul Prescod wrote: > OO is merely accidental. The real goal is to be more consistent. Python > is a language that uses methods for polymorphism so consistency pushes > towards methods. Hmm. And what of, say, abs(-3)? Should that be -3.abs()? Would you also argue for [1, 2, 3].repr() and "abc".hash()? Where do you draw the line? Maybe my habits are too ingrained at this point, but i kind of like the boundary between __methods__ and ordinary methods... it would somehow bug me to have all these methods like abs, len, hash crowding in on my ordinary-method namespace. -- ?!ng From barry@zope.com Thu Aug 23 01:52:25 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 22 Aug 2001 20:52:25 -0400 Subject: [Python-Dev] Re: Inline code in other languages References: <15236.14289.311782.621168@anthem.wooz.org> Message-ID: <15236.21449.231509.725435@anthem.wooz.org> >>>>> "KY" == Ka-Ping Yee writes: KY> ...and have this work. This takes a long time the first time KY> you do it, but the text of the inline code is MD5-hashed and KY> the .so file is left lying around, so it's fast the next time KY> around. KY> It should be pretty feasible to do this for Python, i think, KY> provided the sys module provides enough details about how KY> Python was compiled and installed. Slick indeed! I don't see much that's beyond Python's grasp. The syntax of course would be more Pythonic, but you could probably put all this in a module, hook it up with distutils, and hack out something rough in a day or two. Tim will port it to Windows along with a frozen cygwin gcc compiler in a huge frozen binary. Viola! -Barry From barry@zope.com Thu Aug 23 01:55:25 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 22 Aug 2001 20:55:25 -0400 Subject: [Python-Dev] More feedback from script scape References: <3B841A05.F292DD5B@ActiveState.com> <15236.14289.311782.621168@anthem.wooz.org> <3B843C02.6EFEC933@ActiveState.com> Message-ID: <15236.21629.394538.234568@anthem.wooz.org> >>>>> "PP" == Paul Prescod writes: PP> I have only a superficial understanding which I can convey in PP> this email. If you think my superficial understanding is worth PP> PEP-ing, then I can do that. >From what you and Ping described, I doubt it needs to be PEP'd. It could all be done in a module, without any impact on the language I'd imagine. -Barry From ping@lfw.org Thu Aug 23 02:02:46 2001 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 22 Aug 2001 18:02:46 -0700 (PDT) Subject: [Python-Dev] Re: Inline code in other languages In-Reply-To: <15236.21449.231509.725435@anthem.wooz.org> Message-ID: > Slick indeed! I don't see much that's beyond Python's grasp. The > syntax of course would be more Pythonic, Perhaps: import inline inline.C(''' void greet(char* str) { printf("%s, %s, %s, lovely %s\n", str, str, str, str); } ''') from inline.C import greet greet('spam') ...? -- ?!ng From paulp@ActiveState.com Thu Aug 23 02:08:40 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Wed, 22 Aug 2001 18:08:40 -0700 Subject: [Python-Dev] Re: copy, len and the like as 'object' methods? References: Message-ID: <3B845798.7505DC91@ActiveState.com> Ka-Ping Yee wrote: > >... > > Hmm. And what of, say, abs(-3)? Should that be -3.abs()? The former is more in-line with traditional mathematical notation. I think that counts for something. And anyhow, abs is not fully polymorphic so it is a little bit of a different case. > Would you also argue for [1, 2, 3].repr() and "abc".hash()? Yes. But hashing and repring are done much less often than taking the length. So I wouldn't worry about them...in this round anyhow. Plus repr has a first-class syntax so the function is kind of redundant already! > Where do you draw the line? If a function takes a single argument that is a Python object and immediately dispatches to a magic method, and it is "important" enough to be a builtin, then it should probably just be a method. What is the point of hiding what is really going on -- a method call! > Maybe my habits are too ingrained > at this point, but i kind of like the boundary between __methods__ > and ordinary methods... it would somehow bug me to have all these > methods like abs, len, hash crowding in on my ordinary-method > namespace. I can appreciate that your tastes are different from mine...in fact I said something similar to David when he first suggested it to me but on reflection it seemed such a subtle thing when compared against the weirdness of the definition of len: def len(obj): return obj.__length__() It does a little bit more but not much! If you put that in a module you wrote you would consider it a little bit bizarre, useless and confusing. Plus it is another indirection which saps a tiny bit of performance for nothing. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook From skip@pobox.com (Skip Montanaro) Thu Aug 23 02:13:43 2001 From: skip@pobox.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 22 Aug 2001 20:13:43 -0500 Subject: [Python-Dev] More feedback from script scape In-Reply-To: <15236.21629.394538.234568@anthem.wooz.org> References: <3B841A05.F292DD5B@ActiveState.com> <15236.14289.311782.621168@anthem.wooz.org> <3B843C02.6EFEC933@ActiveState.com> <15236.21629.394538.234568@anthem.wooz.org> Message-ID: <15236.22727.471154.470699@beluga.mojam.com> BAW> From what you and Ping described, I doubt it needs to be PEP'd. It BAW> could all be done in a module, without any impact on the language BAW> I'd imagine. Agreed. I believe it's the same with Perl's Inline module. In fact, I first encountered it about a year ago when trying to figure out how to write Mason components in Python. I seem to recall that the author(s) wrote Inline as a lark. Skip From barry@zope.com Thu Aug 23 02:20:51 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 22 Aug 2001 21:20:51 -0400 Subject: [Python-Dev] Re: Inline code in other languages References: <15236.21449.231509.725435@anthem.wooz.org> Message-ID: <15236.23155.857942.461104@anthem.wooz.org> >>>>> "KY" == Ka-Ping Yee writes: >> Slick indeed! I don't see much that's beyond Python's grasp. >> The syntax of course would be more Pythonic, KY> Perhaps: | import inline | inline.C(''' | void greet(char* str) | { | printf("%s, %s, %s, lovely %s\n", str, str, str, str); | } | ''') | from inline.C import greet | greet('spam') KY> ...? Works for me! -Barry From DavidA@ActiveState.com Thu Aug 23 02:28:57 2001 From: DavidA@ActiveState.com (David Ascher) Date: Wed, 22 Aug 2001 18:28:57 -0700 Subject: [Python-Dev] copy, len and the like as 'object' methods? References: <200108221946.f7MJk1j29412@odiug.digicool.com> <3B843801.BA1D8541@ActiveState.com> <200108222317.TAA30578@cj20424-a.reston1.va.home.com> Message-ID: <3B845C59.5DF822A4@ActiveState.com> Guido van Rossum wrote: > AFAICT, the len() method proposal is just an attempt to be more OO, > and to avoid being made fun of by a bunch of Perlers. I don't care > about #1, and it's naive to think that solving one issue will avoid > #2. Actually, I couldn't care less about #1 or #2. Paul and I hold our own against Perl folks every day =), and I'm not a fan of pure-OO'ness. I do try to make _learning_ Python as easy as possible, and inconsistencies such as this one do get in the way. People who learn the language ask things like "how do I make a copy of something?" and the answer to that is currently quite complicated. It just gets in the way, and it wastes synapses. My only point is that if the language were to be designed today, my guess is that those things would be methods (or interfaces :-). --david From paulp@ActiveState.com Thu Aug 23 02:43:21 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Wed, 22 Aug 2001 18:43:21 -0700 Subject: [Python-Dev] PyInline References: <3B841A05.F292DD5B@ActiveState.com> <15236.14289.311782.621168@anthem.wooz.org> <3B843C02.6EFEC933@ActiveState.com> <15236.21629.394538.234568@anthem.wooz.org> <15236.22727.471154.470699@beluga.mojam.com> Message-ID: <3B845FB9.2C165BD2@ActiveState.com> Skip Montanaro wrote: > > BAW> From what you and Ping described, I doubt it needs to be PEP'd. It > BAW> could all be done in a module, without any impact on the language > BAW> I'd imagine. > > Agreed. I believe it's the same with Perl's Inline module. In fact, I > first encountered it about a year ago when trying to figure out how to write > Mason components in Python. I seem to recall that the author(s) wrote > Inline as a lark. Yes but Inline has grown into an all-consuming obsession. He left his job at ActiveState to pursue it "full time". There is even an Inline t-shirt. Inline won an award for best new module at the Perl conference. Outside of Perl 6, it is probably the biggest new thing in the Perl world. It isn't as trivial as you think. It is essentially a superset of SWIG's Python-related functionality. Don't forget that an important part of it is trying to autodetect types. It quickly gets into figuring out structs and then classes and then templates and then madness ensues. Obviously you have to decide how much you are going to support and just require "compliant" wrappers for the rest. Using SWIG might allow you to offload a bunch of that effort for PyInline::C. Plus, there is Inline::C, Inline::Python, Inline::Fortran, Inline::ASM, Inline::Java, etc. http://search.cpan.org/search?mode=module&query=Inline%3a%3a Finally, you have to think hard about how the thing interacts with binary distributions for people without compilers. That includes a hefty chunk of Python's user base. This is much more important than the other two points. I don't want to discourage anyone thinking about tackling it but I also want to give you a reasonable sense of what needs to be implemented. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook From beazley@cs.uchicago.edu Thu Aug 23 03:16:02 2001 From: beazley@cs.uchicago.edu (David Beazley) Date: Wed, 22 Aug 2001 21:16:02 -0500 (CDT) Subject: [Python-Dev] Inline and SWIG In-Reply-To: References: Message-ID: <15236.26466.84309.855339@gargoyle.cs.uchicago.edu> > > It isn't as trivial as you think. It is essentially a superset of SWIG's > Python-related functionality. Don't forget that an important part of it > is trying to autodetect types. It quickly gets into figuring out structs > and then classes and then templates and then madness ensues. Obviously > you have to decide how much you are going to support and just require > "compliant" wrappers for the rest. Using SWIG might allow you to offload > a bunch of that effort for PyInline::C. I've looked briefly at Inline and agree that it's a pretty nifty approach. However, usability aside, it's got a number of pretty major limitations once you start getting into structure wrapping, C++ classes, and other advanced types of extension wrapping. I think a common misconception about wrapper generation tools in general is that it's just a matter of hacking up a quick parser and throwing something together in a couple of days. The *real* problem IMHO is actually trying to figure out how to properly handle all of the facets of the C/C++ type system (pointers, references, qualifiers, classes, templates, typedef, inheritance, multiple inheritance, member pointers, pass by value, etc.) and how that's supposed to hook into Python. What's worse, if you get *ANY* part of the type system wrong, everything becomes a hellish nightmare later (and I can speak from personal experience on this :-). We've been working on an upcoming major new SWIG release for quite some time now and about 80% of that work has been related to redesigning the internal type system. Maybe this sort of thing is obvious to everyone else and I'm missing some trivial point, but I sure haven't found the C++ type system to be this totally trivial thing I could just hack up in a few days and stick in a code generator! In any case, I think the coolest thing about Inline is the ability to add small little bits of C code on-the-fly without having to restart the interpreter. That's a pretty neat trick that would probably be useful in the context of working with larger C extensions. I'm not sure I'd want to build a huge 400 function C extension module with that kind of approach, but something like that would definitely be useful for prototyping and adding code on the fly. I almost wonder if something like SWIG could be used behind the scenes to do code generation for something like that. Cheers, Dave From ping@lfw.org Thu Aug 23 03:25:49 2001 From: ping@lfw.org (Ka-Ping Yee) Date: Wed, 22 Aug 2001 19:25:49 -0700 (PDT) Subject: [Python-Dev] Re: Inline and SWIG In-Reply-To: <15236.26466.84309.855339@gargoyle.cs.uchicago.edu> Message-ID: On Wed, 22 Aug 2001, David Beazley wrote: > I've looked briefly at Inline and agree that it's a pretty nifty > approach. However, usability aside, it's got a number of pretty major > limitations once you start getting into structure wrapping, C++ > classes, and other advanced types of extension wrapping. I think the audiences are different. SWIG is for taking an existing library of C or C++ code and making it available in Python. It seems to me that Inline is about making multiple languages available to a programmer while the programmer is writing new code. I agree with you that the first task is much, much harder. However, there is also a useful payoff from the second. -- ?!ng From beazley@cs.uchicago.edu Thu Aug 23 03:31:00 2001 From: beazley@cs.uchicago.edu (David Beazley) Date: Wed, 22 Aug 2001 21:31:00 -0500 (CDT) Subject: [Python-Dev] Re: Inline and SWIG In-Reply-To: References: <15236.26466.84309.855339@gargoyle.cs.uchicago.edu> Message-ID: <15236.27364.304751.836868@gargoyle.cs.uchicago.edu> Ka-Ping Yee writes: > I think the audiences are different. SWIG is for taking an existing > library of C or C++ code and making it available in Python. It seems > to me that Inline is about making multiple languages available to a > programmer while the programmer is writing new code. I agree with you > that the first task is much, much harder. However, there is also a > useful payoff from the second. Definitely! I saw a demo of Inline when I visited Activestate awhile back and was blown away ("You mean you can do that?!?"). Pretty neat stuff. Cheers, Dave From guido@python.org Thu Aug 23 03:29:35 2001 From: guido@python.org (Guido van Rossum) Date: Wed, 22 Aug 2001 22:29:35 -0400 Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: Your message of "Wed, 22 Aug 2001 16:54:21 PDT." <3B84462D.230FFF3F@ActiveState.com> References: <200108221946.f7MJk1j29412@odiug.digicool.com> <3B843801.BA1D8541@ActiveState.com> <200108222317.TAA30578@cj20424-a.reston1.va.home.com> <3B84462D.230FFF3F@ActiveState.com> Message-ID: <200108230229.WAA31882@cj20424-a.reston1.va.home.com> > OO is merely accidental. The real goal is to be more consistent. Python > is a language that uses methods for polymorphism so consistency pushes > towards methods. If Python were Scheme and had an OO appendage in the > middle of its standard library I'd dislike that too. > > The only reason Perlers come into the picture is because they are > pointing out that we claim to be consistent but in this case are not. > And the only reason any of us care about consistency is because > inconsistency has a cost in education and memorization...and according > to Greg Wilson he's seen it first-hand in this case. (I personally had > more experience with confusion over string functions instead of string > methods) > > > Any change like this has a *huge* cost to the community (just reread > > the division thread). > > Division is a special case. There is a big difference between > re-purposing existing syntax and adding new methods to existing objects. > > If one is clearly the "new, better" way and the other is historical, > then the books document the new way and most users eventually forget > that the old way even exists. e.g. string exceptions, string.functions, > UserDict (after type-class), regex, etc. I see nothing that you didn't say before. Nothing to sway me to set the wheels in motion to make this particular change. My position remains "it ain't broken, so don't fix it." --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Thu Aug 23 03:33:02 2001 From: guido@python.org (Guido van Rossum) Date: Wed, 22 Aug 2001 22:33:02 -0400 Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: Your message of "Wed, 22 Aug 2001 18:28:57 PDT." <3B845C59.5DF822A4@ActiveState.com> References: <200108221946.f7MJk1j29412@odiug.digicool.com> <3B843801.BA1D8541@ActiveState.com> <200108222317.TAA30578@cj20424-a.reston1.va.home.com> <3B845C59.5DF822A4@ActiveState.com> Message-ID: <200108230233.WAA31918@cj20424-a.reston1.va.home.com> > Actually, I couldn't care less about #1 or #2. Paul and I hold our own > against Perl folks every day =), and I'm not a fan of pure-OO'ness. I > do try to make _learning_ Python as easy as possible, and > inconsistencies such as this one do get in the way. This one seems to be something that you stumble over once, and then get used to. > People who learn the language ask things like "how do I make a copy of > something?" and the answer to that is currently quite complicated. It > just gets in the way, and it wastes synapses. Maybe they are asking the wrong question. I think that copying isn't all that important in Python -- that's why it's in a module. > My only point is that if the language were to be designed today, my > guess is that those things would be methods (or interfaces :-). Sure. But they're not so broken as to warrant a redesign. There are more important battles. --Guido van Rossum (home page: http://www.python.org/~guido/) From grant.griffin@iowegian.com Thu Aug 23 03:47:56 2001 From: grant.griffin@iowegian.com (Grant Griffin) Date: Wed, 22 Aug 2001 21:47:56 -0500 Subject: [Python-Dev] PEP 265 - Sorting Dictionaries by Value In-Reply-To: <200108221415.KAA27226@cj20424-a.reston1.va.home.com> References: <4.3.2.7.2.20010820215632.00cb69e0@pop.kcnet.com> <4.3.2.7.2.20010822081617.00dcab00@pop.kcnet.com> Message-ID: <4.3.2.7.2.20010822212254.00cbd220@pop.kcnet.com> At 10:15 AM 8/22/2001 -0400, Guido van Rossum wrote: > > However, the problem I see with a class-based approach is that this > > is such a small thing that I'm not even sure how to write a class > > for it that isn't more grandiose than it deserves. > >Believe me, adding a new method to a heavily-used built-in object is >much more grandiose than adding a library module. In addition to "15 >lines of code" we need to update the documentation, add a few lines to >the test suite, add code to Jython mimicking the feature; 30 books >will be a little more out of date, and so on. I guess I don't see how this one is different from any other feature change to Python in that regard: they all require code, tests, and docs. The only real logistical advantage I can see for implementing it as module is that the port to Jython would be virtually free. Aside from that, it seems like adding a new module (in any form) would cause much _more_ bloat overall in terms of SLOCs, tests and documentation. For example, a new library module would get a doc page of its own, but a single new Boolean parameter added to items() could be documented by a footnote on the "Mapping Types" page, e.g., "If the 'values_first' parameter is set to true, the item tuples returned are in (value, key) order rather than the default (key, value) order." The test suite for the new parameter could be just a line or two which would compare the values-first items of a test dictionary to the expected list. So, in total, my preferred suggestion, "items(values_first=0)", (which actually isn't a _new_ method!) would cause bloat on the order of: 15 lines of C (and Java) 1 sentence of documentation 3 lines of test code and best of all!: 0 __future__ statements And as for making 30 books a little more out of date...well...if Tim O'Reilly doesn't give me a big wet kiss for that, I'm gonna demand he refund the $54.95 I just paid for the Second Edition of "Programming Python" . =g2 From greg@cosc.canterbury.ac.nz Thu Aug 23 03:57:37 2001 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Thu, 23 Aug 2001 14:57:37 +1200 (NZST) Subject: [Python-Dev] PEP 265 - Sorting Dictionaries by Value In-Reply-To: <4.3.2.7.2.20010822081617.00dcab00@pop.kcnet.com> Message-ID: <200108230257.OAA04095@s454.cosc.canterbury.ac.nz> Grant Griffin : > items(values_first=0) Or perhaps a separate method called smeti() :-) Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From greg@cosc.canterbury.ac.nz Thu Aug 23 04:01:49 2001 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Thu, 23 Aug 2001 15:01:49 +1200 (NZST) Subject: [Python-Dev] PEP 265 - Sorting Dictionaries by Value In-Reply-To: <000801c12b40$25ae3640$060210ac@private> Message-ID: <200108230301.PAA04098@s454.cosc.canterbury.ac.nz> Barry Scott : > How should all the variations be handled? def order(index = None, field = None, descending = 0): ... Examples: from sorting import order x.sort(order(index = 3)) x.sort(order(field = "customer_name", descending = 1)) The next step is to allow sort() itself to take the same keyword parameters directly: x.sort(index = 3) x.sort(field = "customer_name", descending = 1) Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From DavidA@ActiveState.com Thu Aug 23 04:31:55 2001 From: DavidA@ActiveState.com (David Ascher) Date: Wed, 22 Aug 2001 20:31:55 -0700 Subject: [Python-Dev] Re: Inline and SWIG References: <15236.26466.84309.855339@gargoyle.cs.uchicago.edu> <15236.27364.304751.836868@gargoyle.cs.uchicago.edu> Message-ID: <3B84792B.7DDF7C1B@ActiveState.com> Note that I know of at least two if not three different inline-like projects for Python. One is the compiler module in scipy (Eric Jones & Travis Oliphant): http://scipy.net/cgi-bin/viewcvs.cgi/~checkout~/scipy/compiler/doc/readme?rev=1.2&content-type=text/plain One is the stuff that Pat Miller from LLNL presented at OSCON in San Diego, which sounded similar in spirit (alas, I missed the talk, and don't know anything about its availability -- Pat?), and there was a third one which I heard mentioned but don't know any details about. Eric, do you remember what I'm talking about? I'd recommend that people track down the authors of those modules, as I do think there is a great opportunity there. (I take credit for inspiring Eric Jones by mentioning Inline:: to him in Long Beach =). --david ascher From tim.one@home.com Thu Aug 23 04:32:50 2001 From: tim.one@home.com (Tim Peters) Date: Wed, 22 Aug 2001 23:32:50 -0400 Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: <200108230233.WAA31918@cj20424-a.reston1.va.home.com> Message-ID: [David Ascher] > My only point is that if the language were to be designed today, my > guess is that those things would be methods (or interfaces :-). [Guido] > Sure. Say what?! What kind of stupid-ass language spells the len() function as if it were a method? That's carrying consistency to an irrational extreme -- trust your decade-old intuition on this one (which was challenged no later than 9 years ago on the same ground). > But they're not so broken as to warrant a redesign. There are > more important battles. Proof: every thread bloats in inverse proportion to its true importance. So there . incisively y'rs - tim From DavidA@ActiveState.com Thu Aug 23 04:45:07 2001 From: DavidA@ActiveState.com (David Ascher) Date: Wed, 22 Aug 2001 20:45:07 -0700 Subject: [Python-Dev] copy, len and the like as 'object' methods? References: <200108221946.f7MJk1j29412@odiug.digicool.com> <3B843801.BA1D8541@ActiveState.com> <200108222317.TAA30578@cj20424-a.reston1.va.home.com> <3B845C59.5DF822A4@ActiveState.com> <200108230233.WAA31918@cj20424-a.reston1.va.home.com> Message-ID: <3B847C43.2082509E@ActiveState.com> Guido van Rossum wrote: > > > Actually, I couldn't care less about #1 or #2. Paul and I hold our own > > against Perl folks every day =), and I'm not a fan of pure-OO'ness. I > > do try to make _learning_ Python as easy as possible, and > > inconsistencies such as this one do get in the way. > > This one seems to be something that you stumble over once, and then > get used to. I don't disagree, but people have said the same thing about case-sensitivity, integer division, and Perl. =) > > People who learn the language ask things like "how do I make a copy of > > something?" and the answer to that is currently quite complicated. It > > just gets in the way, and it wastes synapses. > > Maybe they are asking the wrong question. I think that copying isn't > all that important in Python -- that's why it's in a module. I'm tired of this argument, so I'll quit. I'll just say that IMO students can't ask the wrong questions. The body of knowledge that they bring to the table is perfectly valid. They're trying to 'grok' a large complicated system, and the questions they ask reflect steps in understanding. FWIW, I only talk about copying after I've discussed references in depth, since that makes the argument you mention more convincing. I only half buy the argument myself, however, since the elegance of the presentation is always marred by having to explain such oddities, no matter how smoothly I finagle it. I see much of Python's recent evolution as getting rid of wrinkles in the system. I just pointed out a wrinkle, that's all. Note that I started with a question, and I'll accept that you don't want to change it. Next topic. --david From tim.one@home.com Thu Aug 23 05:06:28 2001 From: tim.one@home.com (Tim Peters) Date: Thu, 23 Aug 2001 00:06:28 -0400 Subject: [Python-Dev] Cuddly constants seek loving, stable home Message-ID: __future__.py now contains this abomination: try: import new as _new # for CO_xxx symbols except ImportError: # May happen during build class _new: CO_NESTED = 0x0010 CO_GENERATOR_ALLOWED = 0x1000 CO_FUTURE_DIVISION = 0x2000 "new" turned out to be a bad module to hold these constants, despite that that's where they belong (i.e., along with the function that creates new code objects), first because "new" wasn't always built "in time" on Unixy boxes, and second because "new" isn't available at all in restricted mode. So they can't live in "new", but duplicating their values by hand is also unbearable. "sys" is the only other module I see where they *might* fit, but they don't really belong there (indeed, trying to make a case that they do is a lot like arguing "len" should be a method ). So I propose a new builtin module, _sysconsts. The underscore is to announce its obscure internal nature. I propose only to expose the CO_xxx #defines at the start, but of course others could be added. Any objections? ain't-worth-a-pep-unless-there-are-ly y'rs - tim From guido@python.org Thu Aug 23 05:07:22 2001 From: guido@python.org (Guido van Rossum) Date: Thu, 23 Aug 2001 00:07:22 -0400 Subject: [Python-Dev] Cuddly constants seek loving, stable home In-Reply-To: Your message of "Thu, 23 Aug 2001 00:06:28 EDT." References: Message-ID: <200108230407.AAA00339@cj20424-a.reston1.va.home.com> > So I propose a new builtin module, _sysconsts. The underscore is to > announce its obscure internal nature. I propose only to expose the CO_xxx > #defines at the start, but of course others could be added. +1 on the concept, +0 on the name. Maybe _sysconst (singular)? --Guido van Rossum (home page: http://www.python.org/~guido/) From tim.one@home.com Thu Aug 23 05:17:45 2001 From: tim.one@home.com (Tim Peters) Date: Thu, 23 Aug 2001 00:17:45 -0400 Subject: [Python-Dev] Cuddly constants seek loving, stable home In-Reply-To: <200108230407.AAA00339@cj20424-a.reston1.va.home.com> Message-ID: [Tim, proposes a new _sysconst module] [Guido] > +1 on the concept, +0 on the name. Maybe _sysconst (singular)? Ya, that's what I said -- you must have suffered an email error . the-singular-is-certainly-easier-to-pronounce-ly y'rs - tim From esr@snark.thyrsus.com Thu Aug 23 05:12:56 2001 From: esr@snark.thyrsus.com (Eric S. Raymond) Date: Thu, 23 Aug 2001 00:12:56 -0400 Subject: [Python-Dev] Cuddly constants seek loving, stable home In-Reply-To: ; from tim.one@home.com on Thu, Aug 23, 2001 at 12:06:28AM -0400 References: Message-ID: <20010823001256.A3031@thyrsus.com> Tim Peters : > So I propose a new builtin module, _sysconsts. The underscore is to > announce its obscure internal nature. I propose only to expose the CO_xxx > #defines at the start, but of course others could be added. > > Any objections? +0. -- Eric S. Raymond I don't like the idea that the police department seems bent on keeping a pool of unarmed victims available for the predations of the criminal class. -- David Mohler, 1989, on being denied a carry permit in NYC From guido@python.org Thu Aug 23 05:40:39 2001 From: guido@python.org (Guido van Rossum) Date: Thu, 23 Aug 2001 00:40:39 -0400 Subject: [Python-Dev] Near Final PEP 237 - Unifying Long Integers and Integers Message-ID: <200108230440.AAA00660@cj20424-a.reston1.va.home.com> Please comment on a new version of PEP 237: http://python.sourceforge.net/peps/pep-0237.html I've updated a few parts of the PEP for more accuracy and to reflect more implementation details. I've had very few negative responses to this PEP, and quite a few positive, so I'm assuming this is not controversial and we can follow the transition plan described in the PEP. Only phase A of the transition plan will be implemented in Python 2.2. I've implemented phase A completely, and tentatively checked it into CVS; unless a major showstopper is brought up I will release it with Python 2.2a3 (it didn't make it into 2.2a2). Please use the SF bug tracker to report bugs in the implementation. Please mail comments on the PEP to python-dev@python.org or to me. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim.one@home.com Thu Aug 23 06:47:45 2001 From: tim.one@home.com (Tim Peters) Date: Thu, 23 Aug 2001 01:47:45 -0400 Subject: [Python-Dev] Near Final PEP 237 - Unifying Long Integers and Integers In-Reply-To: <200108230440.AAA00660@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > ... > I've had very few negative responses to this PEP, and quite a few > positive, so I'm assuming this is not controversial and we can follow > the transition plan described in the PEP. Only phase A of the > transition plan will be implemented in Python 2.2. FYI, there have been no negatives on c.l.py either, and at least two positives -- but it's barely been discussed at all yet. I changed the subject line of the one thread that drifted into it to contain "PEP 237". +1 from me. From greg@cosc.canterbury.ac.nz Thu Aug 23 07:01:28 2001 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Thu, 23 Aug 2001 18:01:28 +1200 (NZST) Subject: [Python-Dev] Inline and SWIG In-Reply-To: <15236.26466.84309.855339@gargoyle.cs.uchicago.edu> Message-ID: <200108230601.SAA04304@s454.cosc.canterbury.ac.nz> David Beazley : > I've looked briefly at Inline and agree that it's a pretty nifty > approach. However, usability aside, it's got a number of pretty major > limitations once you start getting into structure wrapping, C++ > classes, and other advanced types of extension wrapping. Indeed, you've put your finger on what seems like the biggest problem with the current crop of semi-automatic extension generators. I don't think there is ever going to be a completely automatic solution to this, because, once you get beyond the basic types like ints, floats and strings, there is no unique mapping between Python types and C types. While the tool could provide some sort of default translation for arbitrary types, it's unlikely to be what you need to interface directly with some existing C library you're trying to wrap. So you're faced with writing a lot of tedious and error-prone code for messing with PyObjects and reference counts. I've had some ideas floating around in my head for a while concerning what to do about this. The key observation is that such code usually spends a lot more lines manipulating Python data than it does C data, which leads me to the conclusion that C is the wrong language to write it in. What's the right language? One that's good at manipulating Python objects. Which language is the best at doing that? Why, Python, of course. But not just Python, because we need to be able to manipulate C data structures as well. So we need a language that looks like Python at one end and C at the other... Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From ping@lfw.org Thu Aug 23 09:37:51 2001 From: ping@lfw.org (Ka-Ping Yee) Date: Thu, 23 Aug 2001 01:37:51 -0700 (PDT) Subject: [Python-Dev] Re: Cuddly constants seek loving, stable home In-Reply-To: Message-ID: On Thu, 23 Aug 2001, Tim Peters wrote: > So I propose a new builtin module, _sysconsts. The underscore is to > announce its obscure internal nature. I propose only to expose the CO_xxx > #defines at the start, but of course others could be added. Just a suggestion, but how about sys.consts? Like os.path, as in sys.consts.CO_NESTED, sys.consts.CO_FUTURE_DIVISION, etc. So there's only one new object in sys, and it can contain the weird internal stuff. :) (Errr... the names are rather weird. CO_NESTED_SCOPES, CO_TRUE_DIVISION, and CO_GENERATORS would be better. If i had my druthers it would be CO_* constant FUTURE_* constant __future__ symbol CO_NESTED_SCOPES FUTURE_NESTED_SCOPES nested_scopes CO_GENERATORS FUTURE_GENERATORS generators CO_TRUE_DIVISION FUTURE_TRUE_DIVISION true_division instead. If CO_NESTED, why not CO_TRUE? If CO_GENERATORS_ALLOWED, why not CO_NESTED_SCOPES_ALLOWED?) Anyway. Hmm, as a side thought, perhaps keywords and tokens should go here too (sys.keywords, sys.tokens) instead of having to keep separate .py files in sync with the interpreter core. -- ?!ng From fredrik@pythonware.com Thu Aug 23 09:06:56 2001 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 23 Aug 2001 10:06:56 +0200 Subject: [Python-Dev] PEP 268 - Extended HTTP functionality and WebDAV References: <20010821134036.J13229@lyra.org> Message-ID: <00bf01c12bae$c03cd2c0$0900a8c0@spiff> greg wrote: > I've completed my first draft of PEP 268 and am seeking feedback. > > http://python.sourceforge.net/peps/pep-0268.html looks good to me. > My next step is to begin implementing the 'httpx' module and rejiggering the > 'davlib' module. This work will occur in the /nondist/sandbox/ area > (probably under a Lib subdir there). excellent! From fredrik@pythonware.com Thu Aug 23 09:17:51 2001 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 23 Aug 2001 10:17:51 +0200 Subject: [Python-Dev] Re: copy, len and the like as 'object' methods? References: <930BBCA4CEBBD411BE6500508BB3328F3A8ECC@nsamcanms1.ca.baltimore.com> Message-ID: <00c001c12bae$c053b620$0900a8c0@spiff> greg wilson wrote: > FWIW, David's 'len()' methods would definitely make Python easier > to teach --- just about every beginner types 'x.len()' instead of > 'len(x)' over and over during their first two or three exercises. my students don't -- so it's probably a bug in your training material, not in Python ;-) cheers /F From larsga@garshol.priv.no Thu Aug 23 09:41:14 2001 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 23 Aug 2001 10:41:14 +0200 Subject: [Python-Dev] Re: Inline code in other languages In-Reply-To: <15236.21449.231509.725435@anthem.wooz.org> References: <15236.14289.311782.621168@anthem.wooz.org> <15236.21449.231509.725435@anthem.wooz.org> Message-ID: * Barry A. Warsaw | | Slick indeed! I don't see much that's beyond Python's grasp. The | syntax of course would be more Pythonic, [...] Why not make it import C files, instead of putting them inline? I guess you very often want to reuse the C functions in several different places anyway, and you'd mostly want to have includes and stuff as well. This way you can also get rid of the MD5-ing and just use ordinary modification times to figure out what needs to be recompiled. You can't inline pieces smaller than functions anyway, and to me the mix between Python and C code looks very ugly. --Lars M. From Paul.Moore@atosorigin.com Thu Aug 23 10:12:45 2001 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Thu, 23 Aug 2001 10:12:45 +0100 Subject: [Python-Dev] Re: copy, len and the like as 'object' methods? Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AFA3@UKRUX002.rundc.uk.origin-it.com> > I can appreciate that your tastes are different from > mine...in fact I said something similar to David when he > first suggested it to me but on reflection it seemed such > a subtle thing when compared against the weirdness of the > definition of len: > > def len(obj): > return obj.__length__() > > It does a little bit more but not much! A strange thought, but with the advent of type/class unification and the 'object' base class, is it possible to inject new methods into the 'object' type at runtime, allowing: def len(self): return self.__length__() object.len = len This would seem quite slick (or is that "sick" :-), but it makes the language seem more mutable than might be healthy... (Or is 'object' not this mutable...? Must try 2.2a2 and see...) Paul. From simon@netthink.co.uk Thu Aug 23 10:52:41 2001 From: simon@netthink.co.uk (Simon Cozens) Date: Thu, 23 Aug 2001 10:52:41 +0100 Subject: [Python-Dev] Perl5->Perl6 In-Reply-To: <5.1.0.14.0.20010822170534.08c50170@tuatha.sidhe.org> References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> <3B83EE5B.CEB38C48@ActiveState.com> <15235.61766.827878.699521@slothrop.digicool.com> <5.1.0.14.0.20010822153946.08c02de8@tuatha.sidhe.org> <5.1.0.14.0.20010822170534.08c50170@tuatha.sidhe.org> Message-ID: <20010823105241.B8531@netthink.co.uk> On Wed, Aug 22, 2001 at 05:17:12PM -0400, Dan Sugalski wrote: > Seriously, we've a reasonably comprehensive test suite now with perl 5, and > a very large code base with expected behavior to draw on to test the > conversion. Much of the perl 5->perl 6 transition is strictly syntactic. Also don't forget that we have a prototype of Perl 6 which implements pretty much everything that Larry has specified in Apocalypses 1 and 2. It is a patch of nearly 200 lines to the current Perl 5 interpreter. We're not changing *that* drastically, folks. From gmcm@hypernet.com Thu Aug 23 11:37:04 2001 From: gmcm@hypernet.com (Gordon McMillan) Date: Thu, 23 Aug 2001 06:37:04 -0400 Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: <3B847C43.2082509E@ActiveState.com> Message-ID: <3B84A490.15494.5052EA06@localhost> [Guido] > > Maybe they are asking the wrong question. I think that copying > > isn't all that important in Python -- that's why it's in a > > module. [David] > I'm tired of this argument, so I'll quit. I'll just say that IMO > students can't ask the wrong questions. Not to prolong it, but Guido's comment made me realize that I haven't imported copy in years. Haven't written a clone() method in years, either, despite the fact that coming from Java and C++ that was one of my favorite methods. get-yourself-a-big-stick-and-teach-'em-Zen-ly y'rs - Gordon From skip@pobox.com (Skip Montanaro) Thu Aug 23 14:11:42 2001 From: skip@pobox.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 23 Aug 2001 08:11:42 -0500 Subject: [Python-Dev] Inline caveat Message-ID: <15237.270.649981.730739@beluga.mojam.com> There is, of course, a definite downside to Inline. Your code will get harder to read and maintain because you and whoever else has to maintain your code has to be familiar with all the languages you are inlining. Skip From thomas.heller@ion-tof.com Thu Aug 23 14:27:05 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu, 23 Aug 2001 15:27:05 +0200 Subject: [Python-Dev] Inline caveat References: <15237.270.649981.730739@beluga.mojam.com> Message-ID: <034801c12bd7$4dabc3f0$e000a8c0@thomasnotebook> > There is, of course, a definite downside to Inline. Your code will get > harder to read and maintain because you and whoever else has to maintain > your code has to be familiar with all the languages you are inlining. > > Skip This is more an argument against mixed language programming than against Inline. Inline makes it easier (a no-brainer) to locate the code which has to be changed, to determine what has to be recompiled, where (and how) it has to be installed, and so on. I've played a little bit with the idea and I certainly like it. Thomas From guido@python.org Thu Aug 23 14:24:52 2001 From: guido@python.org (Guido van Rossum) Date: Thu, 23 Aug 2001 09:24:52 -0400 Subject: [Python-Dev] Re: copy, len and the like as 'object' methods? In-Reply-To: Your message of "Thu, 23 Aug 2001 10:12:45 BST." <714DFA46B9BBD0119CD000805FC1F53B01B5AFA3@UKRUX002.rundc.uk.origin-it.com> References: <714DFA46B9BBD0119CD000805FC1F53B01B5AFA3@UKRUX002.rundc.uk.origin-it.com> Message-ID: <200108231324.JAA01440@cj20424-a.reston1.va.home.com> > A strange thought, but with the advent of type/class unification and the > 'object' base class, is it possible to inject new methods into the 'object' > type at runtime, allowing: > > def len(self): > return self.__length__() > object.len = len No you can't. Built-in types are immutable. Two reasons: they're shared between multiple interpreters, and it would encourage modules to modify a built-in type to suit their own needs, which it might break other modules. --Guido van Rossum (home page: http://www.python.org/~guido/) From gstein@lyra.org Thu Aug 23 14:59:07 2001 From: gstein@lyra.org (Greg Stein) Date: Thu, 23 Aug 2001 06:59:07 -0700 Subject: [Python-Dev] PEP 265 - Sorting Dictionaries by Value In-Reply-To: <200108230301.PAA04098@s454.cosc.canterbury.ac.nz>; from greg@cosc.canterbury.ac.nz on Thu, Aug 23, 2001 at 03:01:49PM +1200 References: <000801c12b40$25ae3640$060210ac@private> <200108230301.PAA04098@s454.cosc.canterbury.ac.nz> Message-ID: <20010823065907.W16727@lyra.org> On Thu, Aug 23, 2001 at 03:01:49PM +1200, Greg Ewing wrote: > Barry Scott : > > > How should all the variations be handled? > > def order(index = None, field = None, descending = 0): Lose the last arg... call them ascending() and descending(). Sorting already implies an "order" so that name is redundant >... > from sorting import order > > x.sort(order(index = 3)) > x.sort(order(field = "customer_name", descending = 1)) from sorting import ascending, descending x.sort(ascending(index = 3)) x.sort(descending(field = 'customer_name')) > The next step is to allow sort() itself to take the same > keyword parameters directly: > > x.sort(index = 3) > x.sort(field = "customer_name", descending = 1) eek... no :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Aug 23 15:03:00 2001 From: gstein@lyra.org (Greg Stein) Date: Thu, 23 Aug 2001 07:03:00 -0700 Subject: [Python-Dev] Re: Cuddly constants seek loving, stable home In-Reply-To: ; from ping@lfw.org on Thu, Aug 23, 2001 at 01:37:51AM -0700 References: Message-ID: <20010823070259.X16727@lyra.org> On Thu, Aug 23, 2001 at 01:37:51AM -0700, Ka-Ping Yee wrote: > On Thu, 23 Aug 2001, Tim Peters wrote: > > So I propose a new builtin module, _sysconsts. The underscore is to > > announce its obscure internal nature. I propose only to expose the CO_xxx > > #defines at the start, but of course others could be added. > > Just a suggestion, but how about sys.consts? Like os.path, as in > sys.consts.CO_NESTED, sys.consts.CO_FUTURE_DIVISION, etc. So there's > only one new object in sys, and it can contain the weird internal stuff. :) +1 -0 on a new module. Just make sys.consts some kind of attributed object. >... > Hmm, as a side thought, perhaps keywords and tokens should go here too > (sys.keywords, sys.tokens) instead of having to keep separate .py files > in sync with the interpreter core. +1 ... Good call. That would toss some of the synchronization problems with those files today. Cheers, -g -- Greg Stein, http://www.lyra.org/ From skip@pobox.com (Skip Montanaro) Thu Aug 23 15:19:20 2001 From: skip@pobox.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 23 Aug 2001 09:19:20 -0500 Subject: [Python-Dev] Inline caveat In-Reply-To: <034801c12bd7$4dabc3f0$e000a8c0@thomasnotebook> References: <15237.270.649981.730739@beluga.mojam.com> <034801c12bd7$4dabc3f0$e000a8c0@thomasnotebook> Message-ID: <15237.4328.899938.564006@beluga.mojam.com> >> There is, of course, a definite downside to Inline. Your code will >> get harder to read and maintain because you and whoever else has to >> maintain your code has to be familiar with all the languages you are >> inlining. Thomas> This is more an argument against mixed language programming Thomas> than against Inline. Certainly. Today, you have to keep the various bits of code written in different languages separate. Inline certainly lowers that barrier and makes it feasible to do some spot optimizations quickly. For example, several years ago I needed to be able to compute the distance between two lat/longs. I wrote: def distance(ll1, ll2): dlat = ll1[0] - ll2[0] longdist = (ll1[1] - ll2[1]) * math.fabs(math.cos(DEGTORAD*dlat)) return math.sqrt(MILESPERDEGLAT**2 * (dlat*dlat+longdist*longdist)) This turned out to be too slow and I wound up writing a C extension that exposed just that one function. An Inline module would have been the perfect solution to this problem (assuming it could figure out the shared library needed to be linked with -lm). Thomas> Inline makes it easier (a no-brainer) to locate the code which Thomas> has to be changed, to determine what has to be recompiled, where Thomas> (and how) it has to be installed, and so on. Yes, but my original assertion still stands. With C and Python in separate modules, I can tell people "pay no attention to the man behind the curtain" (that being the C code). With the C code right there in the midst of your Python code it's pretty hard to ignore the fact that the man is not behind the curtain and he's flashing you. ;-) Skip From barry@zope.com Thu Aug 23 15:29:53 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 23 Aug 2001 10:29:53 -0400 Subject: [Python-Dev] Re: Cuddly constants seek loving, stable home References: <20010823070259.X16727@lyra.org> Message-ID: <15237.4961.597225.931722@anthem.wooz.org> >>>>> "KY" == Ka-Ping Yee writes: KY> Just a suggestion, but how about sys.consts? Like os.path, as KY> in sys.consts.CO_NESTED, sys.consts.CO_FUTURE_DIVISION, etc. KY> So there's only one new object in sys, and it can contain the KY> weird internal stuff. :) +1. It's much better to qualify them in a subpackage or object than put them in sys's top level namespace. -Barry From guido@python.org Thu Aug 23 15:32:20 2001 From: guido@python.org (Guido van Rossum) Date: Thu, 23 Aug 2001 10:32:20 -0400 Subject: [Python-Dev] Inline caveat In-Reply-To: Your message of "Thu, 23 Aug 2001 15:27:05 +0200." <034801c12bd7$4dabc3f0$e000a8c0@thomasnotebook> References: <15237.270.649981.730739@beluga.mojam.com> <034801c12bd7$4dabc3f0$e000a8c0@thomasnotebook> Message-ID: <200108231432.f7NEWKr05785@odiug.digicool.com> > > There is, of course, a definite downside to Inline. Your code will get > > harder to read and maintain because you and whoever else has to maintain > > your code has to be familiar with all the languages you are inlining. > > > > Skip > This is more an argument against mixed language programming > than against Inline. > Inline makes it easier (a no-brainer) to locate the code which > has to be changed, to determine what has to be recompiled, > where (and how) it has to be installed, and so on. > > I've played a little bit with the idea and I certainly > like it. > > Thomas If the alternative is writing an extension module, the inline approach sounds viable to me. I could also imagine auto-wrapping existing C functions based on parseable function signatures. I believe VB supports this. Dangerous, but powerful, and very useful in the right hands. It seems to me that the important idea here is to break away from building and distributing a separate extension module, which gets you in the edit-compile-link-test-run loop that Python tries to avoid. Rather than requiring an expert who knows how to download, build, install and use SWIG or how to write Python extensions, all the expertise is automated. Getting this to work on Windows for the average Windows user would be a big hassle, limiting the portability and therefore the usefulness. Of course, Jython already has all this, thanks to Java's introspection capabilities. I wonder if the new C++ standard makes enough run-time type information able to be able to pull of the same trick? --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@acm.org Thu Aug 23 15:31:57 2001 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 23 Aug 2001 10:31:57 -0400 (EDT) Subject: [Python-Dev] Inline caveat In-Reply-To: <15237.270.649981.730739@beluga.mojam.com> References: <15237.270.649981.730739@beluga.mojam.com> Message-ID: <15237.5085.898843.495797@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > There is, of course, a definite downside to Inline. Your code will get > harder to read and maintain because you and whoever else has to maintain > your code has to be familiar with all the languages you are inlining. Inline::K, anyone? ;-) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From barry@zope.com Thu Aug 23 15:36:54 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 23 Aug 2001 10:36:54 -0400 Subject: [Python-Dev] Inline caveat References: <15237.270.649981.730739@beluga.mojam.com> Message-ID: <15237.5382.431639.149435@anthem.wooz.org> >>>>> "SM" == Skip Montanaro writes: SM> There is, of course, a definite downside to Inline. Your code SM> will get harder to read and maintain because you and whoever SM> else has to maintain your code has to be familiar with all the SM> languages you are inlining. It's also harder to maintain because it's harder to edit and debug. Maybe all them fancy IDEs you youngin's use can easily support editing mutiple different languages in the same file, but if so, let me know! The tools/editors/debuggers I'm familiar with don't deal with any of that very well, if at all. You have a similar problem trying to knit HTML and Python together, as is proven by the proliferation of such approaches (e.g. DTML, PTL, HTMLgen, etc., etc.). It's bearable for one-liners and small bits of intermingling, but anything large than a line or two gets pretty unweildy pretty fast. -Barry From guido@python.org Thu Aug 23 15:43:37 2001 From: guido@python.org (Guido van Rossum) Date: Thu, 23 Aug 2001 10:43:37 -0400 Subject: [Python-Dev] Re: Cuddly constants seek loving, stable home In-Reply-To: Your message of "Thu, 23 Aug 2001 10:29:53 EDT." <15237.4961.597225.931722@anthem.wooz.org> References: <20010823070259.X16727@lyra.org> <15237.4961.597225.931722@anthem.wooz.org> Message-ID: <200108231443.f7NEhb505947@odiug.digicool.com> > >>>>> "KY" == Ka-Ping Yee writes: > > KY> Just a suggestion, but how about sys.consts? Like os.path, as > KY> in sys.consts.CO_NESTED, sys.consts.CO_FUTURE_DIVISION, etc. > KY> So there's only one new object in sys, and it can contain the > KY> weird internal stuff. :) > > +1. It's much better to qualify them in a subpackage or object than > put them in sys's top level namespace. +0. It's the better solution but I bet it's more work to code it than _sysconst. I'm not volunteering, and I want Tim to have time to help with the type/class unification, which is behind schedule. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@acm.org Thu Aug 23 15:44:16 2001 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 23 Aug 2001 10:44:16 -0400 (EDT) Subject: [Python-Dev] Re: Cuddly constants seek loving, stable home In-Reply-To: <20010823070259.X16727@lyra.org> References: <20010823070259.X16727@lyra.org> Message-ID: <15237.5824.599253.83454@cj42289-a.reston1.va.home.com> Greg Stein writes: > +1 > > -0 on a new module. Just make sys.consts some kind of attributed object. Agreed. pyexpat just creates new module objects and fills them in for things like error codes. > +1 ... Good call. That would toss some of the synchronization problems with > those files today. Yep. The existing modules could import * from those new objects so that backward compatibility is retained. The advantage of the current approach, however, is that we don't end up with a bunch of initialization code that ends up sticking around as part of the process. Not a real problem for Unix or Windows, but it might be on embedded platforms like the Palm. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fdrake@acm.org Thu Aug 23 16:03:20 2001 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 23 Aug 2001 11:03:20 -0400 (EDT) Subject: [Python-Dev] Re: Cuddly constants seek loving, stable home In-Reply-To: <200108231443.f7NEhb505947@odiug.digicool.com> References: <20010823070259.X16727@lyra.org> <15237.4961.597225.931722@anthem.wooz.org> <200108231443.f7NEhb505947@odiug.digicool.com> Message-ID: <15237.6968.594854.181777@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > +0. It's the better solution but I bet it's more work to code it than > _sysconst. I'm not volunteering, and I want Tim to have time to help > with the type/class unification, which is behind schedule. One interesting thing about these modules is that the executable C code is no longer needed once the modules has been initialized (similar to the code object for a module; it creates things and then goes away). Perhaps there should be a C equivalent. When the shared-object importer loads a .so/.dll/.pyd, it looks for init and calls that, and then keeps the object loaded. Perhaps a second name could be checked for, build , which indicates that the initialized module has no dependencies on the C code, which which case the .so/.dll/.pyd gets unloaded after the build returns. Another possibility is to simply regenerate token.py and symbol.py whenever token.h and graminit.h change. That can be driven by make so they don't fall out of sync with the rest of the grammar. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From skip@pobox.com (Skip Montanaro) Thu Aug 23 16:41:49 2001 From: skip@pobox.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 23 Aug 2001 10:41:49 -0500 Subject: [Python-Dev] Inline caveat In-Reply-To: <15237.5085.898843.495797@cj42289-a.reston1.va.home.com> References: <15237.270.649981.730739@beluga.mojam.com> <15237.5085.898843.495797@cj42289-a.reston1.va.home.com> Message-ID: <15237.9277.750760.986482@beluga.mojam.com> >> There is, of course, a definite downside to Inline. Your code will >> get harder to read and maintain because you and whoever else has to >> maintain your code has to be familiar with all the languages you are >> inlining. Fred> Inline::K, anyone? ;-) I was actually thinking more about Inline::Intercal. ;-) Skip From thomas.heller@ion-tof.com Thu Aug 23 16:58:08 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu, 23 Aug 2001 17:58:08 +0200 Subject: [Python-Dev] Inline caveat References: <15237.270.649981.730739@beluga.mojam.com> <034801c12bd7$4dabc3f0$e000a8c0@thomasnotebook> <200108231432.f7NEWKr05785@odiug.digicool.com> Message-ID: <052201c12bec$675bf300$e000a8c0@thomasnotebook> [Guido, about Inline] > If the alternative is writing an extension module, the inline approach > sounds viable to me. > > I could also imagine auto-wrapping existing C functions based on > parseable function signatures. I believe VB supports this. > Dangerous, but powerful, and very useful in the right hands. Isn't this the calldll approach? > It seems to me that the important idea here is to break away from > building and distributing a separate extension module, which gets you > in the edit-compile-link-test-run loop that Python tries to avoid. > Rather than requiring an expert who knows how to download, build, > install and use SWIG or how to write Python extensions, all the > expertise is automated. > > Getting this to work on Windows for the average Windows user would be > a big hassle, limiting the portability and therefore the usefulness. My prototype writes a xxx.c file, and uses distutils to build an extension module of it. The only requirement is a working VC++ compiler. Thomas From cgw@alum.mit.edu Thu Aug 23 17:27:31 2001 From: cgw@alum.mit.edu (Charles G Waldman) Date: Thu, 23 Aug 2001 11:27:31 -0500 Subject: [Python-Dev] Re: Inline::caveat In-Reply-To: References: Message-ID: <15237.12019.841104.61849@nyx.dyndns.org> > It's also harder to maintain because it's harder to edit and debug. > > Maybe all them fancy IDEs you youngin's use can easily support editing > mutiple different languages in the same file, but if so, let me know! > The tools/editors/debuggers I'm familiar with don't deal with any of > that very well, if at all. I agree that debugging any Inline code is going to be difficult (it's already tricky enough debugging C modules generated by SWIG), but as far as editor support goes - the "fancy IDE" of choice (XEmacs, of course) actually can support such mixed-language editing, once you've loaded up the appropriate elisp and done some customization... Have you seen the "MMM" package? MMM stands for "Multiple Major Modes" which allows you to have, just like the name suggests, multiple major modes within one buffer. I have used this successfully for editing HTML with embedded JavaScript (although I hate to admit that I have written such junk!). You can get it at: http://members.tripod.com/gchen2/xemacs/ This package seems to be little-known. Maybe it should be added to the XEmacs package database? (I'll bring this up on xemacs-beta) FWIW, -C From barry@zope.com Thu Aug 23 18:33:29 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 23 Aug 2001 13:33:29 -0400 Subject: [Python-Dev] Re: Inline::caveat References: <15237.12019.841104.61849@nyx.dyndns.org> Message-ID: <15237.15977.879565.852317@anthem.wooz.org> >>>>> "CGW" == Charles G Waldman writes: CGW> Have you seen the "MMM" package? MMM stands for "Multiple CGW> Major Modes" which allows you to have, just like the name CGW> suggests, multiple major modes within one buffer. I have CGW> used this successfully for editing HTML with embedded CGW> JavaScript (although I hate to admit that I have written such CGW> junk!). You can get it at: CGW> http://members.tripod.com/gchen2/xemacs/ Except that trying to download the actual mmm.el.gz file it puts me into a Tripod infloop. I can't actually get at the file. Can you send me a copy? CGW> This package seems to be little-known. Maybe it should be CGW> added to the XEmacs package database? (I'll bring this up on CGW> xemacs-beta) Indeed, it sounds cool. -Barry From thomas.heller@ion-tof.com Thu Aug 23 18:49:40 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu, 23 Aug 2001 19:49:40 +0200 Subject: [Python-Dev] Inline and SWIG References: <200108230601.SAA04304@s454.cosc.canterbury.ac.nz> Message-ID: <05c601c12bfb$fcd46c50$e000a8c0@thomasnotebook> From: "Greg Ewing" > David Beazley : > > > I've looked briefly at Inline and agree that it's a pretty nifty > > approach. However, usability aside, it's got a number of pretty major > > limitations once you start getting into structure wrapping, C++ > > classes, and other advanced types of extension wrapping. > > Indeed, you've put your finger on what seems like the > biggest problem with the current crop of semi-automatic > extension generators. > > I don't think there is ever going to be a completely > automatic solution to this, because, once you get beyond > the basic types like ints, floats and strings, there is > no unique mapping between Python types and C types. > > While the tool could provide some sort of default > translation for arbitrary types, it's unlikely to be > what you need to interface directly with some existing > C library you're trying to wrap. So you're faced with > writing a lot of tedious and error-prone code for messing > with PyObjects and reference counts. > > I've had some ideas floating around in my head for a > while concerning what to do about this. The key > observation is that such code usually spends a lot > more lines manipulating Python data than it does C > data, which leads me to the conclusion that C is the > wrong language to write it in. > > What's the right language? One that's good at manipulating > Python objects. Which language is the best at doing > that? Why, Python, of course. But not just Python, > because we need to be able to manipulate C data > structures as well. So we need a language that looks > like Python at one end and C at the other... I've written (well, it's not finished and maybe never will) an extension allowing to create or wrap and manipulate C structures and unions from Python. The basics are similar to an OO-ified struct module, but the format codes are extensible. It even handles the Microsoft TypeInfo structures, which are full of recursions. Makes a pretty good pair with a calldll-like extension module. Thomas From paulp@ActiveState.com Thu Aug 23 19:31:29 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Thu, 23 Aug 2001 11:31:29 -0700 Subject: [Python-Dev] Inline and SWIG References: <200108230601.SAA04304@s454.cosc.canterbury.ac.nz> Message-ID: <3B854C01.A20AE630@ActiveState.com> Greg Ewing wrote: > >... > > What's the right language? One that's good at manipulating > Python objects. Which language is the best at doing > that? Why, Python, of course. But not just Python, > because we need to be able to manipulate C data > structures as well. So we need a language that looks > like Python at one end and C at the other... You are describing inline. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook From paulp@ActiveState.com Thu Aug 23 19:36:11 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Thu, 23 Aug 2001 11:36:11 -0700 Subject: [Python-Dev] Re: Inline code in other languages References: <15236.14289.311782.621168@anthem.wooz.org> <15236.21449.231509.725435@anthem.wooz.org> Message-ID: <3B854D1B.1DA8191C@ActiveState.com> Lars Marius Garshol wrote: > >... > > Why not make it import C files, instead of putting them inline? I > guess you very often want to reuse the C functions in several > different places anyway, and you'd mostly want to have includes and > stuff as well. If you want to reuse a C function then you put it in a seperate file and use #include to include it. Allowing inline code is a choice...the programmer can choose to modularize if it helps him or her. I think there is a reason PHP is so much more popular than DTML-like solutions (duck!). > This way you can also get rid of the MD5-ing and just use ordinary > modification times to figure out what needs to be recompiled. MD5-ing is more reliable anyhow. Some build systems (e.g. CONS, SCONS) are moving from mod times to build times anyhow. > You can't inline pieces smaller than functions anyway, and to me the > mix between Python and C code looks very ugly. Beauty is in the eye of the beholder....I think that forcing stuff into separate files for aesthetic or philosophical reasons is severe. Ultimately there is an important usability benefit in allowing inlining (and I'll refer again to the amazing popularity of PHP). -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook From thomas.heller@ion-tof.com Thu Aug 23 19:48:36 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu, 23 Aug 2001 20:48:36 +0200 Subject: [Python-Dev] Customizing the binding of attributes Message-ID: <064201c12c04$37dfa6e0$e000a8c0@thomasnotebook> In Python 2.2, is it possible to customize the binding of class attributes, to emulate the normal behaviour of methods (function -> unbound method -> bound method)? I think I have read something about this, but I can't find it anymore. Thomas From guido@python.org Thu Aug 23 20:23:42 2001 From: guido@python.org (Guido van Rossum) Date: Thu, 23 Aug 2001 15:23:42 -0400 Subject: [Python-Dev] Customizing the binding of attributes In-Reply-To: Your message of "Thu, 23 Aug 2001 20:48:36 +0200." <064201c12c04$37dfa6e0$e000a8c0@thomasnotebook> References: <064201c12c04$37dfa6e0$e000a8c0@thomasnotebook> Message-ID: <200108231923.f7NJNg307631@odiug.digicool.com> > In Python 2.2, is it possible to customize the binding > of class attributes, to emulate the normal behaviour > of methods (function -> unbound method -> bound method)? > > I think I have read something about this, but I can't > find it anymore. I'm not sure what you are asking about, but let me give an example. You can write an auxiliary class that "describes" an instance attribute. Instances of this "descriptor" class are stored in a class dict. The descriptor class implements a method __get__ which is called in two situations: (a) when a class attribute is retrieved, .__get__(None, ) is called; this can return an unbound method (b) when an instance attribute is retrieved, .__get__( , References: <200108230601.SAA04304@s454.cosc.canterbury.ac.nz> <05c601c12bfb$fcd46c50$e000a8c0@thomasnotebook> Message-ID: <15237.22789.951079.581327@grendel.digicool.com> Thomas Heller writes: > Makes a pretty good pair with a calldll-like extension module. I guess calldll is very different from the dl module, which has documentation. Is anyone up to writing docs for calldll? I've CC'd to the Doc-SIG since there may be volunteers there ;-) -- please remove python-dev from doc-related followups. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From gward@python.net Thu Aug 23 21:17:45 2001 From: gward@python.net (Greg Ward) Date: Thu, 23 Aug 2001 16:17:45 -0400 Subject: [Python-Dev] Putting a builtin module into a package In-Reply-To: <15234.34090.225332.420431@beluga.mojam.com>; from skip@pobox.com on Tue, Aug 21, 2001 at 10:58:34AM -0500 References: <20010821145632.7CC15303181@snelboot.oratrix.nl> <15234.34090.225332.420431@beluga.mojam.com> Message-ID: <20010823161745.A2375@gerg.ca> On 21 August 2001, Skip Montanaro said: > > Jack> Or should I rename the module to an underscore name and simply put > Jack> a wrapper module in the package? > > This seems the safest (and the sanest) to me. I realize you're thinking > mostly about MacOS, but putting object files inside packages that are > otherwise Python code makes the whole package platform-dependent. I think Jack was talking about *built-in* extensions, not .so (or .pyd) files. Dynamically loaded extensions are indeed easy -- you just put 'em in the package directory, and it Just Works. Yes, this means that people maintaining a multi-architecture installation have to have prefix != external-prefix, but they already do: /usr/bin/python is platform-specific! Greg -- Greg Ward - Unix bigot gward@python.net http://starship.python.net/~gward/ I just read that 50% of the population has below median IQ! From paulp@ActiveState.com Thu Aug 23 22:12:32 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Thu, 23 Aug 2001 14:12:32 -0700 Subject: [Python-Dev] Perl5->Perl6 References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> <3B83EE5B.CEB38C48@ActiveState.com> <15235.61766.827878.699521@slothrop.digicool.com> <5.1.0.14.0.20010822153946.08c02de8@tuatha.sidhe.org> <5.1.0.14.0.20010822170534.08c50170@tuatha.sidhe.org> <20010823105241.B8531@netthink.co.uk> Message-ID: <3B8571C0.4ABCEDC5@ActiveState.com> Simon Cozens wrote: > >... > > Also don't forget that we have a prototype of Perl 6 which implements pretty > much everything that Larry has specified in Apocalypses 1 and 2. > > It is a patch of nearly 200 lines to the current Perl 5 interpreter. > > We're not changing *that* drastically, folks. According to Damian there will be generators and a first-class class syntax and method getters/setters and metaclasses and optional static type declarations and ... Larry just hasn't got to the heavy part of the Camel book. :-) -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook From Samuele Pedroni Thu Aug 23 22:56:42 2001 From: Samuele Pedroni (Samuele Pedroni) Date: Thu, 23 Aug 2001 23:56:42 +0200 (MET DST) Subject: [Python-Dev] PEP 252, PEP 253 and jython issues Message-ID: <200108232156.XAA09481@core.inf.ethz.ch> Hi. OK, here is my major concern Given the following three types subclassed in Pyhon: class A(CSpecialList): ... class B(list): ... class C(A,B): ... where CSpecialList is a subtype of list written in C. Now the old mro would be: C A CSpecialList list object B list object that translate to the new mro C A CSpecialList B list object The question is it possible for CSpecialList for the code that define for example sq_ass_slice to use sq_slice code in a safe manner? (AFAIK listobject does something similar) And how can safely CSpecialList invoke a "super" behaviour, it is safe for it to refer to the behaviour offered by list. In principle given the mro e.g. a __getslice__ redefined in B should shadow such a behaviour? A natural way to design PEP252, and PEP253 for Jython would be start to start from the equation: object = org.python.core.PyObject then it is necessary to build a class that truly correspond to the type metatype, actually jython fakes using the metatype used for Java Classes for that. It would make sense to use Java subclassing to implement type subclassing, at least at layout level this does not clash with the multiple inheritance rule in best_base. And actually is also how Jython now works: for example PyList extends PySequence that extends PyObject. But than there is the issue of method resolution order: from the viewpoint of Python code we can implement anything, not that easy ... But the at the Java level, where we construct types, the codebase uses the normal single inheritance of java and the codebase is full of super.foo invocations and of methods that cross-call each other (potentially overriden) versions, and this happen also for behaviour that correspond to the slots/ __foo__ special methods of CPython. That's why the two questions are important? regards. From neilh@scintilla.org Thu Aug 23 23:15:53 2001 From: neilh@scintilla.org (Neil Hodgson) Date: Fri, 24 Aug 2001 08:15:53 +1000 Subject: [Python-Dev] Re: Inline::caveat References: <15237.12019.841104.61849@nyx.dyndns.org> Message-ID: <012b01c12c21$2e332050$0acc8490@neil> Charles G Waldman: > ... but as > far as editor support goes - the "fancy IDE" of choice (XEmacs, of > course) actually can support such mixed-language editing, once you've > loaded up the appropriate elisp and done some customization... How do you find the language boundaries to enable mixed language editing or debugging? If Python gets an inline module, I'd hope to see enough lexical clues so that an editor can work out where the C++ is so it can be treated as C++. Neil From greg@cosc.canterbury.ac.nz Thu Aug 23 23:55:00 2001 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Fri, 24 Aug 2001 10:55:00 +1200 (NZST) Subject: [Python-Dev] Inline and SWIG In-Reply-To: <3B854C01.A20AE630@ActiveState.com> Message-ID: <200108232255.KAA04393@s454.cosc.canterbury.ac.nz> Paul Prescod : > You are describing inline. No, I'm not describing Inline, that's the point. I have some fairly detailed ideas on what I am describing, but this message is too small to contain them... As a brief example, the Inline::C example posted earlier would look something like this: cdef printf(char *,...): extern def hello(s): printf("Hello, world, %s\n", s) But that's way too simple an example to really convey anything. More later... Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From gstein@lyra.org Fri Aug 24 03:30:00 2001 From: gstein@lyra.org (Greg Stein) Date: Thu, 23 Aug 2001 19:30:00 -0700 Subject: [Python-Dev] Re: Cuddly constants seek loving, stable home In-Reply-To: <200108231443.f7NEhb505947@odiug.digicool.com>; from guido@python.org on Thu, Aug 23, 2001 at 10:43:37AM -0400 References: <20010823070259.X16727@lyra.org> <15237.4961.597225.931722@anthem.wooz.org> <200108231443.f7NEhb505947@odiug.digicool.com> Message-ID: <20010823193000.N26054@lyra.org> On Thu, Aug 23, 2001 at 10:43:37AM -0400, Guido van Rossum wrote: > > >>>>> "KY" == Ka-Ping Yee writes: > > KY> Just a suggestion, but how about sys.consts? Like os.path, as > > KY> in sys.consts.CO_NESTED, sys.consts.CO_FUTURE_DIVISION, etc. > > KY> So there's only one new object in sys, and it can contain the > > KY> weird internal stuff. :) >... > +0. It's the better solution but I bet it's more work to code it than > _sysconst. I'm not volunteering, and I want Tim to have time to help > with the type/class unification, which is behind schedule. Hmm... that sounds a lot like trading off expediency for Rightness. If it is the better solution, then that should be done. If you don't want Tim to work on it, then that is a different problem. It could be done later, or a volunteer could step up to do it. It isn't exactly a time critical change, now is it? Cheers, -g -- Greg Stein, http://www.lyra.org/ From beazley@cs.uchicago.edu Fri Aug 24 03:26:09 2001 From: beazley@cs.uchicago.edu (David Beazley) Date: Thu, 23 Aug 2001 21:26:09 -0500 (CDT) Subject: [Python-Dev] Near Final PEP 237 - Unifying Long Integers and Integers In-Reply-To: References: Message-ID: <15237.47937.50866.571629@gargoyle.cs.uchicago.edu> Guido van Rossum writes: > Please comment on a new version of PEP 237: > > Please mail comments on the PEP to python-dev@python.org or to me. > The PEP looks good to me. Can I make a very small C API feature request? (assuming this hasn't been implemented already). Since "integers" can now have arbitrary precision and can represent large unsigned values, can you add three new format characters to PyArg_ParseTuple() and Py_BuildValue() for the C datatypes "unsigned int", "unsigned long", and "unsigned long long"? The "u" and "l" namespace is a little crowded (and I don't think you would want to break that). However, here's one idea: 'I' - unsigned int (consistent with H and B) 'p' - unsigned long ('p' is for positive) 'P' - unsigned long long Cheers, Dave From jeremy@zope.com Fri Aug 24 03:59:30 2001 From: jeremy@zope.com (Jeremy Hylton) Date: Thu, 23 Aug 2001 22:59:30 -0400 (EDT) Subject: [Python-Dev] Re: Cuddly constants seek loving, stable home In-Reply-To: <20010823193000.N26054@lyra.org> References: <20010823070259.X16727@lyra.org> <15237.4961.597225.931722@anthem.wooz.org> <200108231443.f7NEhb505947@odiug.digicool.com> <20010823193000.N26054@lyra.org> Message-ID: <15237.49938.566295.179733@slothrop.digicool.com> >>>>> "GS" == Greg Stein writes: GS> It isn't exactly a time critical change, now is it? Not any more time critical than documenting the new httplib API . speaking-as-an-expert-on-putting-off-documentation-ly y'rs, Jeremy From tim.one@home.com Fri Aug 24 04:31:57 2001 From: tim.one@home.com (Tim Peters) Date: Thu, 23 Aug 2001 23:31:57 -0400 Subject: [Python-Dev] Re: Cuddly constants seek loving, stable home In-Reply-To: <15237.49938.566295.179733@slothrop.digicool.com> Message-ID: Something that might change your views about Elegance here: calling these particular constants "cuddly" was intended to be ironic. If *any* program uses one of these, I can pretty much guarantee it will eventually break. They're not part of a public API. The two current uses (__future__ and pyassem) are part of the implementation of the core, and just happen to be coded in Python. For that reason I'm -1 on putting these particular constants in a location with an inviting name, or making their own names prettier, etc etc -- I'm even -1 on documenting them (outside of comments in the internal C header file where they're #define'd). Rather than argue about it, I'm going to revert the changes to new and __future__, backing off to defining them by hand in __future__.py. doesn't-stop-anyone-else-from-doing-the-right-thing-later-just-think- twice-about-how-right-it-is-ly y'rs - tim From eric@scipy.org Fri Aug 24 04:05:57 2001 From: eric@scipy.org (eric jones) Date: Thu, 23 Aug 2001 23:05:57 -0400 Subject: [Python-Dev] Re: Inline and SWIG References: <15236.26466.84309.855339@gargoyle.cs.uchicago.edu> <15236.27364.304751.836868@gargoyle.cs.uchicago.edu> <3B84792B.7DDF7C1B@ActiveState.com> Message-ID: <003701c12c49$b33bf3d0$c27ba8c0@ericlaptop> The scipy.compiler modules (www.scipy.org) is aimed at Numeric arrays and is slightly different than inlining C code in that it translates a Python Numeric expression to C++(blitz++ arrays), compiles the result to a function, and calls it automatically. It figures out the array types the local name space, and keeps up with the compiled module after the first compile so that they don't have to be compiled again. The entire process was greatly eased by Jeremy AST stuff, distutils, and blitz++. The most up-to-date description of it is here: http://www.scipy.org/site_content/tutorials/compiler_notes Much of this machinery is identical to what is needed for inline C, and I've tinkered with it a little. It looks like it won't be extremely hard (famous last words...) to handle inlining of numeric looping code. The limited focus on numerical stuff gets around many of the hairy issues involved with handling lists of arbitrary types, and got a usable tool out the door quickly. Luckily it also attacks the most expensive part of scientific codes and provides 2-10 speed-up over Numeric array expressions. I'd like to circle out from the numeric-only approach and tackle some of the more difficult typing issues after the numeric stuff all works. Any input on this thing is welcome. Patrick Miller's PyCOD is another compiler that takes a different approach to compiling (processing bytecodes). It's a little more ambitious than scipy.compiler because it handles more than just numeric expressions. I don't know what its release status is either. The other compiler project I know about is Psyco discussed here: http://aspn.activestate.com/ASPN/Mail/Message/609552 It sounds extremely cool and is the most ambitious of the three. Not sure how it affects inline C though. Seems more like this aims to make inline C obsolete before it even exists. > I'd recommend that people track down the authors of those modules, as I > do think there is a great opportunity there. (I take credit for > inspiring Eric Jones by mentioning Inline:: to him in Long Beach =). Heck, if you'll sign up to add support for array broadcasting, I'll name it scipy.da_compiler... eric ----- Original Message ----- From: "David Ascher" To: "David Beazley" Cc: "Ka-Ping Yee" ; ; ; ; Sent: Wednesday, August 22, 2001 11:31 PM Subject: Re: [Python-Dev] Re: Inline and SWIG > Note that I know of at least two if not three different inline-like > projects for Python. > > One is the compiler module in scipy (Eric Jones & Travis Oliphant): > > http://scipy.net/cgi-bin/viewcvs.cgi/~checkout~/scipy/compiler/doc/readme?re v=1.2&content-type=text/plain > > One is the stuff that Pat Miller from LLNL presented at OSCON in San > Diego, which sounded similar in spirit (alas, I missed the talk, and > don't know anything about its availability -- Pat?), and there was a > third one which I heard mentioned but don't know any details about. > Eric, do you remember what I'm talking about? > > I'd recommend that people track down the authors of those modules, as I > do think there is a great opportunity there. (I take credit for > inspiring Eric Jones by mentioning Inline:: to him in Long Beach =). > > --david ascher From thomas.heller@ion-tof.com Fri Aug 24 08:00:31 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri, 24 Aug 2001 09:00:31 +0200 Subject: [Python-Dev] Customizing the binding of attributes References: <064201c12c04$37dfa6e0$e000a8c0@thomasnotebook> <200108231923.f7NJNg307631@odiug.digicool.com> Message-ID: <09f401c12c6a$7717ab80$e000a8c0@thomasnotebook> From: "Guido van Rossum" > I'm not sure what you are asking about, but let me give an example. > You can write an auxiliary class that "describes" an instance > attribute. Instances of this "descriptor" class are stored in a class > dict. The descriptor class implements a method __get__ which is > called in two situations: > > (a) when a class attribute is retrieved, .__get__(None, ) > is called; this can return an unbound method > > (b) when an instance attribute is retrieved, .__get__( , is called; this can return a bound method > > Does this help? > Yes, thanks. Exactly what I meant. You only forgot to mention that the descriptor class must derive from object: is this intended? I needed this to write class X: method = myinstancemethod(func) instead of class X: pass X.method = new.instancemethod(func, None, X) where myinstancemethod is the descriptor class, and func is any callable object (maybe a function implemented in C). Two additional comments: - Shouldn't (my)instancemethod be a builtin? Similar to staticmethod and classmethod? - The following seems to be a bug (remember, I'm on Windows): C:\>c:\python22\python.exe Python 2.2a2 (#22, Aug 22 2001, 01:24:03) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class myinstancemethod(object): ... def __init__(self, func): ... self.func = func ... def __get__(self, inst, klass=None): ... import new ... return new.instancemethod(self.func, inst, klass) ... >>> class X: ... meth = myinstancemethod(lambda *x: x) ... >>> X().meth of <__main__.X instance at 007C7F04>> >>> X().meth() (<__main__.X instance at 007E80E4>,) >>> X.meth Traceback (most recent call last): File " ", line 1, in ? SystemError: NULL object passed to Py_BuildValue Thomas From guido@python.org Fri Aug 24 10:08:48 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 24 Aug 2001 05:08:48 -0400 Subject: [Python-Dev] Near Final PEP 237 - Unifying Long Integers and Integers In-Reply-To: Your message of "Thu, 23 Aug 2001 21:26:09 CDT." <15237.47937.50866.571629@gargoyle.cs.uchicago.edu> References: <15237.47937.50866.571629@gargoyle.cs.uchicago.edu> Message-ID: <200108240908.FAA03478@cj20424-a.reston1.va.home.com> > Since "integers" can now have arbitrary precision and can represent > large unsigned values, can you add three new format characters to > PyArg_ParseTuple() and Py_BuildValue() for the C datatypes "unsigned int", > "unsigned long", and "unsigned long long"? > > The "u" and "l" namespace is a little crowded (and I don't think you > would want to break that). However, here's one idea: > > 'I' - unsigned int (consistent with H and B) > 'p' - unsigned long ('p' is for positive) > 'P' - unsigned long long Good idea. I've added this to the SF bug tracker as a feature request. Hopefully someone will submit a patch too! --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Fri Aug 24 11:03:34 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 24 Aug 2001 06:03:34 -0400 Subject: [Python-Dev] Customizing the binding of attributes In-Reply-To: Your message of "Fri, 24 Aug 2001 09:00:31 +0200." <09f401c12c6a$7717ab80$e000a8c0@thomasnotebook> References: <064201c12c04$37dfa6e0$e000a8c0@thomasnotebook> <200108231923.f7NJNg307631@odiug.digicool.com> <09f401c12c6a$7717ab80$e000a8c0@thomasnotebook> Message-ID: <200108241003.GAA04383@cj20424-a.reston1.va.home.com> > From: "Guido van Rossum" > > I'm not sure what you are asking about, but let me give an example. > > You can write an auxiliary class that "describes" an instance > > attribute. Instances of this "descriptor" class are stored in a class > > dict. The descriptor class implements a method __get__ which is > > called in two situations: > > > > (a) when a class attribute is retrieved, .__get__(None, ) > > is called; this can return an unbound method > > > > (b) when an instance attribute is retrieved, .__get__( , > is called; this can return a bound method > > > > Does this help? From: "Thomas Heller" > Yes, thanks. Exactly what I meant. You only forgot to mention that > the descriptor class must derive from object: is this intended? Yes, almost all new features require you to switch to new-style classes; the classic class implementation is left unchanged (as much as possible) for compatibility. In particular, classic classes can't define __get__ to the effect above. These descriptors semi-work as class attributes of classic classes, but the corresponding __set__ feature does not, because classic classes *always* store in __dict__ upon assignment; new-style classes first look for a descriptor implementing __set__ (really the C dispatch function tp_descr_set) and use that to override the default assignment. > I needed this to write > > class X: > method = myinstancemethod(func) > > instead of > > class X: > pass > X.method = new.instancemethod(func, None, X) > > where myinstancemethod is the descriptor class, and func > is any callable object (maybe a function implemented in C). > > Two additional comments: > > - Shouldn't (my)instancemethod be a builtin? Similar to > staticmethod and classmethod? Yes. I just checked this in. The new name is 'getset' unless you have a better idea. > - The following seems to be a bug (remember, I'm on Windows): > > C:\>c:\python22\python.exe > Python 2.2a2 (#22, Aug 22 2001, 01:24:03) [MSC 32 bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> class myinstancemethod(object): > ... def __init__(self, func): > ... self.func = func > ... def __get__(self, inst, klass=None): > ... import new > ... return new.instancemethod(self.func, inst, klass) > ... > >>> class X: > ... meth = myinstancemethod(lambda *x: x) > ... > >>> X().meth > of <__main__.X instance at 007C7F04>> > >>> X().meth() > (<__main__.X instance at 007E80E4>,) > >>> X.meth > Traceback (most recent call last): > File " ", line 1, in ? > SystemError: NULL object passed to Py_BuildValue Yup. Thanks! Try this patch: *** typeobject.c 2001/08/22 19:24:42 2.43 --- typeobject.c 2001/08/24 10:05:25 *************** *** 2806,2811 **** --- 2806,2815 ---- Py_INCREF(self); return self; } + if (obj == NULL) + obj = Py_None; + if (type == NULL) + type = Py_None; return PyObject_CallFunction(get, "OOO", self, obj, type); } --Guido van Rossum (home page: http://www.python.org/~guido/) From Samuele Pedroni Fri Aug 24 11:16:28 2001 From: Samuele Pedroni (Samuele Pedroni) Date: Fri, 24 Aug 2001 12:16:28 +0200 (MET DST) Subject: [Python-Dev] jython issues and PEP 252, PEP 253 Message-ID: <200108241016.MAA07882@core.inf.ethz.ch> Hi. I'm feeling a bit annoying and I don't like that. I'm not in hurry for a answer for my questions on PEP253 and PEP252 but were them at least parseable, did they make sense? or are too vague, and underdetailed should I bring more elements in the picture? regards, Samuele Pedroni. From jack@oratrix.nl Fri Aug 24 11:48:02 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 24 Aug 2001 12:48:02 +0200 Subject: [Python-Dev] Inline and SWIG In-Reply-To: Message by David Beazley , Wed, 22 Aug 2001 21:16:02 -0500 (CDT) , <15236.26466.84309.855339@gargoyle.cs.uchicago.edu> Message-ID: <20010824104802.B28D0303181@snelboot.oratrix.nl> > The *real* problem IMHO is actually > trying to figure out how to properly handle all of the facets of the > C/C++ type system (pointers, references, qualifiers, classes, > templates, typedef, inheritance, multiple inheritance, member > pointers, pass by value, etc.) and how that's supposed to hook into > Python. And at this time I customarily put in my plug for bgen. Bgen is far ahead of SWIG in this respect, and completely customizable in Python. It will definitely not do all the things you specify, but it'll do a lot more than SWIG, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From guido@python.org Fri Aug 24 13:54:10 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 24 Aug 2001 08:54:10 -0400 Subject: [Python-Dev] PEP 252, PEP 253 and jython issues In-Reply-To: Your message of "Thu, 23 Aug 2001 23:56:42 +0200." <200108232156.XAA09481@core.inf.ethz.ch> References: <200108232156.XAA09481@core.inf.ethz.ch> Message-ID: <200108241254.IAA05377@cj20424-a.reston1.va.home.com> > OK, here is my major concern > > Given the following three types subclassed in Pyhon: > class A(CSpecialList): ... > > class B(list): ... > > class C(A,B): ... > > where CSpecialList is a subtype of list written in C. > > Now the old mro would be: > > C A CSpecialList list object B list object > > that translate to the new mro > > C A CSpecialList B list object Correct. > The question is it possible for CSpecialList for the code that define > for example sq_ass_slice to use sq_slice code in a safe manner? > (AFAIK listobject does something similar) I'm not 100% sure I understand this question, but CSpecialList can certainly override sq_ass_slice. Then, if it wants to call self.__slice__ (in Python terms) it could call obj->ob_type->tp_as_sequence->sq_slice -- this would call C's obj->ob_type->tp_as_sequence->__slice__ if it had one. > And how can safely CSpecialList invoke a "super" behaviour, it is safe > for it to refer to the behaviour offered by list. In principle > given the mro e.g. a __getslice__ redefined in B should shadow > such a behaviour? I don't know if cooperative super calls are possible at the C level. I certainly didn't define an API for this. I didn't define a Python level API either, but I know how to o it and it can even be coded in Python. Hm, I guess that makes it a theoretical possibility at the C level. I don't expect this to be a common use pattern though (famous last words :-). > A natural way to design PEP252, and PEP253 for Jython would > be start to start from the equation: > > object = org.python.core.PyObject Yes. > then it is necessary to build a class that truly correspond to the type > metatype, actually jython fakes using the metatype used for Java Classes for > that. > > It would make sense to use Java subclassing to implement > type subclassing, at least at layout level this does not clash with > the multiple inheritance rule in best_base. So you would rule out multiple inheritance of types? Fine with me, but you may regret this a few yearsfrom now (when we all code multiple inheritance all the time :-). > And actually is also how Jython now works: for example > PyList extends PySequence that extends PyObject. And that's how it should be. > But than there is the issue of method resolution order: from the viewpoint > of Python code we can implement anything, not that easy ... > > But the at the Java level, where we construct types, the codebase uses the > normal single inheritance of java and the codebase is full of super.foo > invocations and of methods that cross-call each other (potentially overriden) > versions, and this happen also for behaviour that correspond to the slots/ > __foo__ special methods of CPython. > > That's why the two questions are important? I see. CPython doesn't have this problem (yet) because it doesn't use inheritance at the C level. I propose that you just try to live with this. A safe rule would be to require that all Python classes in a given inheritance graph should derive from the same C/Java class. I don't know if we should enforce this or just warn about it in the documentation. I don't want to force you to call a cooperative super method at the Java level -- it would be very slow, I suspect... --Guido van Rossum (home page: http://www.python.org/~guido/) From nas@python.ca Fri Aug 24 14:32:22 2001 From: nas@python.ca (Neil Schemenauer) Date: Fri, 24 Aug 2001 06:32:22 -0700 Subject: [Python-Dev] Customizing the binding of attributes In-Reply-To: <200108241003.GAA04383@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Aug 24, 2001 at 06:03:34AM -0400 References: <064201c12c04$37dfa6e0$e000a8c0@thomasnotebook> <200108231923.f7NJNg307631@odiug.digicool.com> <09f401c12c6a$7717ab80$e000a8c0@thomasnotebook> <200108241003.GAA04383@cj20424-a.reston1.va.home.com> Message-ID: <20010824063222.A12847@glacier.fnational.com> Guido van Rossum wrote: > In particular, classic classes can't define __get__ to the effect > above. Why __get__() and __set__() and not get() and set()? Neil From Samuele Pedroni Fri Aug 24 14:57:25 2001 From: Samuele Pedroni (Samuele Pedroni) Date: Fri, 24 Aug 2001 15:57:25 +0200 (MET DST) Subject: [Python-Dev] Comments: PEP 252, PEP 253 and jython issues Message-ID: <200108241357.PAA16863@core.inf.ethz.ch> Thanks for the answers, I'm happy the questions were parseable, Here are some comments, I think they may be meanigful also for CPython > > The question is it possible for CSpecialList for the code that define > > for example sq_ass_slice to use sq_slice code in a safe manner? > > (AFAIK listobject does something similar) > > I'm not 100% sure I understand this question, but CSpecialList can > certainly override sq_ass_slice. Then, if it wants to call > self.__slice__ (in Python terms) it could call > obj->ob_type->tp_as_sequence->sq_slice -- this would call C's > obj->ob_type->tp_as_sequence->__slice__ if it had one. I overlooked this, I think we can implement that also in Jython. An important point: should that be the only way to use a Python level exposed and overridable method from C code, is that left to the programmer ? The problem is that with the new mro possibly independently C defined things get interleaved with Python level code, so I imagine that the effect should be a bit disciplined ... I saw that list_ass_slice calls list_slice directly, is that OK? > > And how can safely CSpecialList invoke a "super" behaviour, it is saf > > for it to refer to the behaviour offered by list. In principle > > given the mro e.g. a __getslice__ redefined in B should shadow > > such a behaviour? > > I don't know if cooperative super calls are possible at the C level. > I certainly didn't define an API for this. I didn't define a Python > level API either, but I know how to o it and it can even be coded in > Python. Hm, I guess that makes it a theoretical possibility at the C > level. > > I don't expect this to be a common use pattern though (famous last > words :-). But it is certainely a pattern that a writer of Jython types would expect to use. The problem is still that C/Java stuff with the new mro get interleaved with Python level behaviour. IMHO you would better discipline this and also the above point . I don't know if there is some GUI toolkit that implement inheritance using C and not some language enforcing OO like C++, etc. Other OO languages like Smalltalk, Self, or Java allow only to define primitives or single methods to add lowel-level functionality, they don't try to allow subtyping at that level, the previous scenario in Python where you could define just opaque types, and in particular your C code never/normally got interleaved with Python behaviour was on that line. At worst you could say that you allow subtyping but not code sharing, but then even a C method for an object should be very careful using another overridable method of the very same object. OK you could say: that's C level, everybody should care for herself, but with Java we cannot do the same. > > It would make sense to use Java subclassing to implement > > type subclassing, at least at layout level this does not clash with > > the multiple inheritance rule in best_base. > > So you would rule out multiple inheritance of types? Fine with me, > but you may regret this a few yearsfrom now (when we all code multiple > inheritance all the time :-). No it is ruled out at Java level, not Jython level. But it is not also ruled out in CPython at C level? > > But than there is the issue of method resolution order: from the viewpoint > > of Python code we can implement anything, not that easy ... > > > > But the at the Java level, where we construct types, the codebase uses the > > normal single inheritance of java and the codebase is full of super.foo > > invocations and of methods that cross-call each other (potentially overriden) > > versions, and this happen also for behaviour that correspond to the slots/ > > __foo__ special methods of CPython. > > > > That's why the two questions are important? > > I see. CPython doesn't have this problem (yet) because it doesn't use > inheritance at the C level. see above. > I propose that you just try to live with > this. Related e.g. to Zope porting projects there have been a lot of pressure on jython-dev regarding how to code new types and metaclasses, A Jython type writer expect to be able to use Java naturally (i.e. use inheritance), for that, so the situation isn't that easy, is not even easy with the current codebase, because given the new mro one can even put some Python behaviour between: PyList PythonLevelCode and PyObject :-( (*) > A safe rule would be to require that all Python classes in a > given inheritance graph should derive from the same C/Java class. I That would mean that all C/Java behaviour is always only at the top of the mro, right? I had the same idea because this would make my life easier. A problem: some of the Zope porters reported that there are classes that inherits from more than a single ExtensionClass in Zope :-( don't know if that is true. (**) > don't know if we should enforce this or just warn about it in the > documentation. It would make our (jython-dev) life easier and avoid some impredictable problem even with CPython and code sharing, but see previous note (**) > I don't want to force you to call a cooperative super > method at the Java level -- it would be very slow, I suspect... Yes ... very slow and we would have to use that also at the very core of the hierarchy, see (*) but the problem is more complicated, in Java given three classes C extends B extends A and a method m C.m overrides B.m overrides A.m there is not direct way (even using reflection) to apply B.m behaviour to a C object, unless the programmer has left some hook in C using super or in B ( a method B_m e.g.). ... complicated :( regards. From guido@python.org Fri Aug 24 15:04:43 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 24 Aug 2001 10:04:43 -0400 Subject: [Python-Dev] Customizing the binding of attributes In-Reply-To: Your message of "Fri, 24 Aug 2001 06:32:22 PDT." <20010824063222.A12847@glacier.fnational.com> References: <064201c12c04$37dfa6e0$e000a8c0@thomasnotebook> <200108231923.f7NJNg307631@odiug.digicool.com> <09f401c12c6a$7717ab80$e000a8c0@thomasnotebook> <200108241003.GAA04383@cj20424-a.reston1.va.home.com> <20010824063222.A12847@glacier.fnational.com> Message-ID: <200108241404.KAA05644@cj20424-a.reston1.va.home.com> > Guido van Rossum wrote: > > In particular, classic classes can't define __get__ to the effect > > above. > > Why __get__() and __set__() and not get() and set()? Because they're mapped to the dispatch slots tp_descr_get and tp_descr_set. (Note that PEP 252 has get() and set() in some places, like the C API section. This is a mistake.) --Guido van Rossum (home page: http://www.python.org/~guido/) From Samuele Pedroni Fri Aug 24 15:21:14 2001 From: Samuele Pedroni (Samuele Pedroni) Date: Fri, 24 Aug 2001 16:21:14 +0200 (MET DST) Subject: [Python-Dev] Afterthoughts: PEP 252, PEP 253 and jython issues Message-ID: <200108241421.QAA18057@core.inf.ethz.ch> Yes, I'm thinking furiously. GvR > A safe rule would be to require that all Python classes in a GvR > given inheritance graph should derive from the same C/Java class. I > That would mean that all C/Java behaviour is always only at the top > of the mro, right? > > I had the same idea because this would make my life easier. > > A problem: some of the Zope porters reported that there are classes > that inherits from more than a single ExtensionClass in Zope :-( > don't know if that is true. (**) Oops, this is already a problem with the actual best_base rule, I don't know if my reinterpretation is OK, but doesn't it basically states that all C types subclassed by a new C level class should be in a subtyping relationship that means: with A isa list isa object B isa special_list isa list isa object C isa object class D(A,B,C): ... is OK but with Z isa Cbadboy isa object then class D(Z,A) isn't allowed. but if that is already *not* *a* *problem* then I think the rule could be not that bad ... regards. From guido@python.org Fri Aug 24 15:35:45 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 24 Aug 2001 10:35:45 -0400 Subject: [Python-Dev] Comments: PEP 252, PEP 253 and jython issues In-Reply-To: Your message of "Fri, 24 Aug 2001 15:57:25 +0200." <200108241357.PAA16863@core.inf.ethz.ch> References: <200108241357.PAA16863@core.inf.ethz.ch> Message-ID: <200108241435.KAA05784@cj20424-a.reston1.va.home.com> > Thanks for the answers, I'm happy the questions were parseable, > Here are some comments, I think they may be meanigful also for CPython > > > > The question is it possible for CSpecialList for the code that define > > > for example sq_ass_slice to use sq_slice code in a safe manner? > > > (AFAIK listobject does something similar) > > > > I'm not 100% sure I understand this question, but CSpecialList can > > certainly override sq_ass_slice. Then, if it wants to call > > self.__slice__ (in Python terms) it could call > > obj->ob_type->tp_as_sequence->sq_slice -- this would call C's > > obj->ob_type->tp_as_sequence->__slice__ if it had one. > I overlooked this, I think we can implement that also in Jython. > > An important point: should that be the only way to use a Python level > exposed and overridable method from C code, is that left > to the programmer ? I'm not sure I understand this question. Can you give an example? I don't expect that calling into Python from C will be very common. There are ways to call any Python object from C if you need to. > The problem is that with the new mro possibly independently C defined > things get interleaved with Python level code, > so I imagine that the effect should be a bit disciplined ... I don't expect this to happen regularly. if you count on this I think you're on really thin ice. > I saw that list_ass_slice calls list_slice directly, is that OK? It's certainly safe -- any subclass of list will share the same structure lay-out (this is enforced by the subclassing machinery) so the list_slice call will find the object properly inititialized. There are lots of places where the C code doesn't bother to look for overridden methods -- the PyDict_* API is a common example. I have no intention of fixing this. > > > And how can safely CSpecialList invoke a "super" behaviour, it is saf > > > for it to refer to the behaviour offered by list. In principle > > > given the mro e.g. a __getslice__ redefined in B should shadow > > > such a behaviour? > > > > I don't know if cooperative super calls are possible at the C level. > > I certainly didn't define an API for this. I didn't define a Python > > level API either, but I know how to o it and it can even be coded in > > Python. Hm, I guess that makes it a theoretical possibility at the C > > level. > > > > I don't expect this to be a common use pattern though (famous last > > words :-). > > But it is certainely a pattern that a writer of Jython types would expect > to use. The problem is still that C/Java stuff with the new mro > get interleaved with Python level behaviour. If you think this will be a problem in Jython, you may have to provide a fast efficient Java-level "cooperative super" operation. > IMHO you would better discipline this and also the above point . What do you mean by "discipline"? > I don't know if there is some GUI toolkit that implement inheritance > using C and not some language enforcing OO like C++, etc. Sorry, I don't understand the relevance of this? > Other OO languages like Smalltalk, Self, or Java allow only to define > primitives or single methods to add lowel-level functionality, > they don't try to allow subtyping at that level, the previous > scenario in Python where you could define just opaque types, > and in particular your C code never/normally got interleaved with Python > behaviour was on that line. Well, if you like that better, maybe I should remove the instructions for subclassing at the C level? :-) My intention is to make the maximum number of different paradigms usable in Python. You can do cooperative multiple inheritance, but only of all your classes are designed with cooperation in mind. If some class uses C-level (or Java-level) inheritance and is not written cooperatively, you have to be a little careful using it as a base class in a cooperatively written class. I don't want to enforce cooperative coding at the Python level either: the "BaseClass.method(self, args)" approach is still valid, but you have to beware of the consequences. > At worst you could say that you allow subtyping but not code sharing, > but then even a C method for an object should be very careful using > another overridable method of the very same object. I definitely have to support code sharing. I think subclassing at the C level is useful to create variations of built-in objects with additional properties, e.g. numbers with additional operations or formatting parameters, dictionaries with certain restrictions on the keys, etc. I don't think such subclasses should be used in complex multiple inheritance lattices. > OK you could say: that's C level, everybody should care for herself, > but with Java we cannot do the same. Why not? > > > It would make sense to use Java subclassing to implement > > > type subclassing, at least at layout level this does not clash with > > > the multiple inheritance rule in best_base. > > > > So you would rule out multiple inheritance of types? Fine with me, > > but you may regret this a few yearsfrom now (when we all code multiple > > inheritance all the time :-). > No it is ruled out at Java level, not Jython level. > But it is not also ruled out in CPython at C level? Mostly because I don't provide a way to create multiple base classes. That would not be hard to add though -- if there's demand. > > > But than there is the issue of method resolution order: from the > > > viewpoint of Python code we can implement anything, not that > > > easy ... > > > > > > But the at the Java level, where we construct types, the > > > codebase uses the normal single inheritance of java and the > > > codebase is full of super.foo invocations and of methods that > > > cross-call each other (potentially overriden) versions, and this > > > happen also for behaviour that correspond to the slots/ __foo__ > > > special methods of CPython. > > > > > > That's why the two questions are important? > > > > I see. CPython doesn't have this problem (yet) because it doesn't use > > inheritance at the C level. > see above. > > > I propose that you just try to live with this. > Related e.g. to Zope porting projects there have been a lot of > pressure on jython-dev regarding how to code new types and > metaclasses, A Jython type writer expect to be able to use Java > naturally (i.e. use inheritance), for that, so the situation isn't > that easy, is not even easy with the current codebase, because given > the new mro one can even put some Python behaviour between: > > PyList PythonLevelCode and PyObject :-( (*) Just sa no. :-) > > A safe rule would be to require that all Python classes in a > > given inheritance graph should derive from the same C/Java class. I > That would mean that all C/Java behaviour is always only at the top > of the mro, right? If you mean at the end, yes. > I had the same idea because this would make my life easier. Sounds good to me. > A problem: some of the Zope porters reported that there are classes > that inherits from more than a single ExtensionClass in Zope :-( > don't know if that is true. (**) Me neither. But the problem is probably shallow -- Zope mostly uses mixins of various sorts, so these classes probably don't override stuff -- they just define new methods. (I haven't looked at what it would take to replace ExtensionClass with the new metaclasses, but that's definitely on the agenda.) > > don't know if we should enforce this or just warn about it in the > > documentation. > It would make our (jython-dev) life easier and avoid some impredictable > problem even with CPython and code sharing, > but see previous note (**) So enforce it and see how it turns out in practice. > > I don't want to force you to call a cooperative super > > method at the Java level -- it would be very slow, I suspect... > Yes ... very slow and we would have to use that also at the very core > of the hierarchy, see (*) > but the problem is more complicated, in Java given three classes > > C extends B extends A > and a method m > C.m overrides B.m overrides A.m > > there is not direct way (even using reflection) > to apply B.m behaviour to a C object, unless > the programmer has left some hook in C using super > or in B ( a method B_m e.g.). I guess C.m has to call super.m to invoke B.m, right? Does this mean that the following can't be made to work? class C(list): def add_spam(self): return list.append(self, "spam") It's legal Python (although in general questionable style of course). > ... complicated :( :-( --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Fri Aug 24 15:52:28 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 24 Aug 2001 10:52:28 -0400 Subject: [Python-Dev] Afterthoughts: PEP 252, PEP 253 and jython issues In-Reply-To: Your message of "Fri, 24 Aug 2001 16:21:14 +0200." <200108241421.QAA18057@core.inf.ethz.ch> References: <200108241421.QAA18057@core.inf.ethz.ch> Message-ID: <200108241452.KAA05961@cj20424-a.reston1.va.home.com> > Yes, I'm thinking furiously. See if I can keep up with you. :-) > GvR > A safe rule would be to require that all Python classes in a > GvR > given inheritance graph should derive from the same C/Java class. I > > > That would mean that all C/Java behaviour is always only at the top > > of the mro, right? > > > > I had the same idea because this would make my life easier. > > > > A problem: some of the Zope porters reported that there are classes > > that inherits from more than a single ExtensionClass in Zope :-( > > don't know if that is true. (**) > Oops, this is already a problem with the actual best_base rule, > I don't know if my reinterpretation is OK, but doesn't it > basically states that all C types subclassed by a new C level class > should be in a subtyping relationship that means: > > with > A isa list isa object > B isa special_list isa list isa object > C isa object > > class D(A,B,C): ... is OK > > but with > > Z isa Cbadboy isa object > > then class D(Z,A) isn't allowed. Correct. You can't multiply inherit from two types that have a different structure layout. The C code must be able to safely cast a PyObject* to a PyListObject* or a Cbadboy* and if those don't have the same structure it's not safe. The implementation restricts this pretty effectively I believe. (You can't multiply inherit from list and dictionary, but you can from list and xxsubtype.spamlist.) > but if that is already *not* *a* *problem* then I think the rule could > be not that bad ... What do you mean by "already *not* *a* *problem*"? I hope "it is already forbidden". And "the rule" refers back to my proposal quoted above with "GvR >", right? --Guido van Rossum (home page: http://www.python.org/~guido/) From Samuele Pedroni Fri Aug 24 16:50:05 2001 From: Samuele Pedroni (Samuele Pedroni) Date: Fri, 24 Aug 2001 17:50:05 +0200 (MET DST) Subject: [Python-Dev] Comments2: PEP 252, PEP 253 and jython issues Message-ID: <200108241550.RAA21561@core.inf.ethz.ch> [GvR] > > > The problem is that with the new mro possibly independently C defined > > things get interleaved with Python level code, > > so I imagine that the effect should be a bit disciplined ... > > I don't expect this to happen regularly. if you count on this I think > you're on really thin ice. No I'm not counting on that, I'm worried about this scenario A subclasses object and redefines __getattr__ B subclasses list then class C(B,A): ... will have the following mro: C B list A object In Jython codebase hypothetically but possibly list could contains calls like: __getattr__(...) and super.__getattr__ now A is in between list and object: what is the right thing here? I don't expect or invite users to do that, but your rules allow A to end up in that position in the mro, your philosophy seems to be this is thin ice and so let it be ... > > I saw that list_ass_slice calls list_slice directly, is that OK? > > It's certainly safe -- any subclass of list will share the same > structure lay-out (this is enforced by the subclassing machinery) so > the list_slice call will find the object properly inititialized. > > There are lots of places where the C code doesn't bother to look for > overridden methods -- the PyDict_* API is a common example. I have no > intention of fixing this. Fine with that, but ... > > > Other OO languages like Smalltalk, Self, or Java allow only to define > > primitives or single methods to add lowel-level functionality, > > they don't try to allow subtyping at that level, the previous > > scenario in Python where you could define just opaque types, > > and in particular your C code never/normally got interleaved with Python > > behaviour was on that line. > > Well, if you like that better, maybe I should remove the instructions > for subclassing at the C level? :-) No, I'm just saying that you are moving from a world were you had docume ntable C black-boxes and clear Python semantics, to a world where (but you say that would be rare) you can have Python code whose behaviour depends on very fine-grained decision inside C code. On one side your rules make it very easy to interleave Python and C code in the mro, on the other hand I agree that will be rarely done by the wary user because it's just surprise-land, don't know about the unwary ... > > My intention is to make the maximum number of different paradigms > usable in Python. You can do cooperative multiple inheritance, but > only of all your classes are designed with cooperation in mind. If > some class uses C-level (or Java-level) inheritance and is not written > cooperatively, you have to be a little careful using it as a base > class in a cooperatively written class. I don't want to enforce > cooperative coding at the Python level either: the > "BaseClass.method(self, args)" approach is still valid, but you have > to beware of the consequences. Do you feel is that a good thing, especially if new-style classes become the default? It is not a rethoric question, Python is becoming a little single dispatch CLOS with a MOP, descriptors etc but CLOS has only next-method and strange beasts like method combinators and don't allow to interleave low-level coded behaviour in the class mro. > > > At worst you could say that you allow subtyping but not code sharing, > > but then even a C method for an object should be very careful using > > another overridable method of the very same object. > > I definitely have to support code sharing. I think subclassing at the > C level is useful to create variations of built-in objects with > additional properties, e.g. numbers with additional operations or > formatting parameters, dictionaries with certain restrictions on the > keys, etc. I don't think such subclasses should be used in complex > multiple inheritance lattices. Better to enforce that? > > > OK you could say: that's C level, everybody should care for herself, > > but with Java we cannot do the same. > > Why not? Because users would like writing Jython types to become easier, and be possible using Java OOP model, without surprises, or undocumented subtlities, any deviation is an hard sell because Java has already an OOP model. >> > > > It would make sense to use Java subclassing to implement > > > > type subclassing, at least at layout level this does not clash with > > > > the multiple inheritance rule in best_base. > > > > > > So you would rule out multiple inheritance of types? Fine with me, > > > but you may regret this a few yearsfrom now (when we all code multiple > > > inheritance all the time :-). > > > No it is ruled out at Java level, not Jython level. > > But it is not also ruled out in CPython at C level? > > Mostly because I don't provide a way to create multiple base classes. > That would not be hard to add though -- if there's demand. But this is a path that Jython could not follow. > > see above. > > > > > I propose that you just try to live with this. > > > Related e.g. to Zope porting projects there have been a lot of > > pressure on jython-dev regarding how to code new types and > > metaclasses, A Jython type writer expect to be able to use Java > > naturally (i.e. use inheritance), for that, so the situation isn't > > that easy, is not even easy with the current codebase, because given > > the new mro one can even put some Python behaviour between: > > > > PyList PythonLevelCode and PyObject :-( (*) > > Just sa no. :-) See above. > > > > A safe rule would be to require that all Python classes in a > > > given inheritance graph should derive from the same C/Java class. I > > > That would mean that all C/Java behaviour is always only at the top > > of the mro, right? > > If you mean at the end, yes. Of course. > > > I had the same idea because this would make my life easier. > > Sounds good to me. > > > A problem: some of the Zope porters reported that there are classes > > that inherits from more than a single ExtensionClass in Zope :-( > > don't know if that is true. (**) > > Me neither. But the problem is probably shallow -- Zope mostly uses > mixins of various sorts, so these classes probably don't override > stuff -- they just define new methods. (I haven't looked at what it > would take to replace ExtensionClass with the new metaclasses, but > that's definitely on the agenda.) > > > > don't know if we should enforce this or just warn about it in the > > > documentation. > > > It would make our (jython-dev) life easier and avoid some impredictable > > problem even with CPython and code sharing, > > but see previous note (**) > > So enforce it and see how it turns out in practice. It's probably the best solution, at least for Jython, and could even make sense for CPython (see above points) > > > I don't want to force you to call a cooperative super > > > method at the Java level -- it would be very slow, I suspect... > > > Yes ... very slow and we would have to use that also at the very core > > of the hierarchy, see (*) > > but the problem is more complicated, in Java given three classes > > > > C extends B extends A > > and a method m > > C.m overrides B.m overrides A.m > > > > there is not direct way (even using reflection) > > to apply B.m behaviour to a C object, unless > > the programmer has left some hook in C using super > > or in B ( a method B_m e.g.). > > I guess C.m has to call super.m to invoke B.m, right? Yup. > > Does this mean that the following can't be made to work? > > class C(list): > def add_spam(self): > return list.append(self, "spam") > > It's legal Python (although in general questionable style of course). Yes, it can be made to work (it already works for Java subclassing and type subclassing would be some flavor of that), but the point is that your Java stuff should be at the top of the mro. Because then you can insert some hooks using super. regards. From guido@python.org Fri Aug 24 18:09:37 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 24 Aug 2001 13:09:37 -0400 Subject: [Python-Dev] super() In-Reply-To: Your message of "Fri, 24 Aug 2001 18:55:38 +0200." <021001c12cbd$9a182800$e000a8c0@thomasnotebook> References: <021001c12cbd$9a182800$e000a8c0@thomasnotebook> Message-ID: <200108241709.NAA13060@cj20424-a.reston1.va.home.com> Thomas Heller wrote (in private email, responding to a checkin message): > From: "Guido van Rossum" > > Add 'super', another new object type with magical properties. > > > > super(type) -> unbound super object > > super(type, obj) -> bound super object; requires isinstance(obj, type) > > > > Typical use to call a cooperative superclass method: > > > > class C(B): > > def meth(self, arg): > > super(C, self).meth(arg); > > Shouldn't that be > class C(B): > def meth(self, arg): > super(B, self).meth(arg) > ^ > to call B.meth(self, arg)? > > Thomas No. Good question, though! You have to pass your *own* class so that this finds the right super-method when multiple inheritance involving a "diamond" diagram. You may want to read the section on Method resolution order in PEP 253 first. Look at this example: class A(object): def meth(self, a): return "A.meth(%r)" % a print A().meth(1) class B(A): def __init__(self): self.__super = super(B, self) def meth(self, a): return "B.meth(%r) -> " % a + self.__super.meth(a) print B().meth(2) class C(A): __dynamic__ = 1 def meth(self, a): return "C.meth(%r) -> " % a + self.__super.meth(a) C._C__super = super(C) print C().meth(3) class D(C, B): def meth(self, a): return "D.meth(%r) -> " % a + super(D, self).meth(a) print D().meth(4) # D.meth(4) -> C.meth(4) -> B.meth(4) -> A.meth(4) D has the following inheritance graph: A ^ ^ / \ / \ / \ / \ C B ^ ^ \ / \ / \ / \ / D When you have a C or B instance, C.meth's super references A. But when you have a D instance, C.meth's super references B! In other words, D.meth calls C.meth calls B.meth calls A.meth. This is why you need to pass self to super() -- it needs the __mro__ sequence of the instance. Remember that D.__mro__ == (D,C,B,A,object). C.meth calls super(C, D()).meth. This looks for C in D.__mro__, and then starts searching for meth at the next class -- finding B.meth. If you wonder *why* the MRO is designed this way, imagine that meth() does some sort of saving to disk. Each subclass saves its own stuff and then calls the save method of its base class. Without the behavior described above, D.save() would have to call C.save() and B.save(), but this would call A.save() twice! This is part of a pattern called cooperative class design, described in the book Putting Metaclasses to Work (for a reference, see PEP 253). --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Fri Aug 24 18:36:59 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 24 Aug 2001 13:36:59 -0400 Subject: [Python-Dev] Comments2: PEP 252, PEP 253 and jython issues In-Reply-To: Your message of "Fri, 24 Aug 2001 17:50:05 +0200." <200108241550.RAA21561@core.inf.ethz.ch> References: <200108241550.RAA21561@core.inf.ethz.ch> Message-ID: <200108241736.NAA14289@cj20424-a.reston1.va.home.com> [SP] > > > The problem is that with the new mro possibly independently C > > > defined things get interleaved with Python level code, so I > > > imagine that the effect should be a bit disciplined ... > > > [GvR] > > > > I don't expect this to happen regularly. if you count on this I > > think you're on really thin ice. [SP] > No I'm not counting on that, I'm worried about this scenario > > A subclasses object and redefines __getattr__ > B subclasses list > > then class C(B,A): ... > > will have the following mro: > > C B list A object > > In Jython codebase hypothetically but possibly list could contains > calls like: > > __getattr__(...) > and super.__getattr__ This is Java code, right? > now A is in between list and object: what is the right thing here? Just say that this is what happens. The MRO is inconsistent in this case. > I don't expect or invite users to do that, but your rules allow A to > end up in that position in the mro, your philosophy seems to be > this is thin ice and so let it be ... Exactly. > > > I saw that list_ass_slice calls list_slice directly, is that OK? > > > > It's certainly safe -- any subclass of list will share the same > > structure lay-out (this is enforced by the subclassing machinery) so > > the list_slice call will find the object properly inititialized. > > > > There are lots of places where the C code doesn't bother to look > > for overridden methods -- the PyDict_* API is a common example. I > > have no intention of fixing this. > Fine with that, but ... > > > > Other OO languages like Smalltalk, Self, or Java allow only to > > > define primitives or single methods to add lowel-level > > > functionality, they don't try to allow subtyping at that level, > > > the previous scenario in Python where you could define just > > > opaque types, and in particular your C code never/normally got > > > interleaved with Python > > > behaviour was on that line. > > > > Well, if you like that better, maybe I should remove the > > instructions for subclassing at the C level? :-) > No, I'm just saying that you are moving from a world were you had > documentable C black-boxes and clear Python semantics, to a world > where (but you say that would be rare) you can have Python code > whose behaviour depends on very fine-grained decision inside C code. I would recommend that C programmers not indulge in this. They should continue to write C types that can be treated as black boxes. The C-level single inheritance is best seen as code sharing. > On one side your rules make it very easy to interleave Python and C > code in the mro, on the other hand I agree that will be rarely done > by the wary user because it's just surprise-land, don't know about > the unwary ... On the third hand, if a C programmer *wants* to write a class with the proper cooperative super calling, they can do so, it's just a bit clumsy. Should I provide a C API to make this easier? I doubt that it will be used much. If there's demand, it can be added later. > > My intention is to make the maximum number of different paradigms > > usable in Python. You can do cooperative multiple inheritance, > > but only of all your classes are designed with cooperation in > > mind. If some class uses C-level (or Java-level) inheritance and > > is not written cooperatively, you have to be a little careful > > using it as a base class in a cooperatively written class. I > > don't want to enforce cooperative coding at the Python level > > either: the "BaseClass.method(self, args)" approach is still > > valid, but you have to beware of the consequences. > Do you feel is that a good thing, especially if new-style classes become > the default? Time will tell. I expect that some people will design vast cooperative class hierarchies. I expect that other people will stick to single inheritance or very simple-minded uses of multiple inheritance (for example, they could use the mix-in pattern that was about the only sensible use of multiple inheritance with classic classes). Anyway, I expect new classes won't become the default until Python 3.0. > It is not a rethoric question, Python is becoming a little single > dispatch CLOS with a MOP, descriptors etc but CLOS has only > next-method and strange beasts like method combinators and don't > allow to interleave low-level coded behaviour in the class mro. Nothing new: classic classes already allow you to cheat or mess up in various ways by not calling your superclass method. > > > At worst you could say that you allow subtyping but not code > > > sharing, but then even a C method for an object should be very > > > careful using another overridable method of the very same > > > object. > > > > I definitely have to support code sharing. I think subclassing at > > the C level is useful to create variations of built-in objects > > with additional properties, e.g. numbers with additional > > operations or formatting parameters, dictionaries with certain > > restrictions on the keys, etc. I don't think such subclasses > > should be used in complex multiple inheritance lattices. > Better to enforce that? Why? I can think of situations where you have a MRO like this: C list B object but where B doesn't override anything that list might use. In fact, this is the typical mix-in situation. I don't want to forbid this. > > > OK you could say: that's C level, everybody should care for > > > herself, but with Java we cannot do the same. > > > > Why not? > Because users would like writing Jython types to become easier, Do you mean writing Jython types in Java, or in Python? > and be possible using Java OOP model, without surprises, or > undocumented subtlities, any deviation is an hard sell because Java > has already an OOP model. Recommend strongly that they stick to single inheritance for types implemented in Java -- that should do the trick. > > > > > It would make sense to use Java subclassing to implement > > > > > type subclassing, at least at layout level this does not > > > > > clash with the multiple inheritance rule in best_base. > > > > > > > > So you would rule out multiple inheritance of types? Fine > > > > with me, but you may regret this a few yearsfrom now (when we > > > > all code multiple inheritance all the time :-). > > > > > No it is ruled out at Java level, not Jython level. > > > But it is not also ruled out in CPython at C level? > > > > Mostly because I don't provide a way to create multiple base > > classes. That would not be hard to add though -- if there's > > demand. > But this is a path that Jython could not follow. Correct -- another reason why it's not a good idea to encourage this. What you could do though, even in Jython, is simulate everything that goes on in a class statement: build your own dict, populate it with function objects, and then call type.__new__(name, bases, dict). Voila, instant class. :-) > > > see above. > > > > > > > I propose that you just try to live with this. > > > > > Related e.g. to Zope porting projects there have been a lot of > > > pressure on jython-dev regarding how to code new types and > > > metaclasses, A Jython type writer expect to be able to use Java > > > naturally (i.e. use inheritance), for that, so the situation > > > isn't that easy, is not even easy with the current codebase, > > > because given the new mro one can even put some Python behaviour > > > between: > > > > > > PyList PythonLevelCode and PyObject :-( (*) > > > > Just sa no. :-) > See above. Sorry, my context stack just overflowed. If this is still an issue, please start over. :-) [snip] > > > I had the same idea because this would make my life easier. > > > > Sounds good to me. > > > > > A problem: some of the Zope porters reported that there are > > > classes that inherits from more than a single ExtensionClass in > > > Zope :-( don't know if that is true. (**) > > > > Me neither. But the problem is probably shallow -- Zope mostly > > uses mixins of various sorts, so these classes probably don't > > override stuff -- they just define new methods. (I haven't looked > > at what it would take to replace ExtensionClass with the new > > metaclasses, but that's definitely on the agenda.) > > > > > > don't know if we should enforce this or just warn about it in > > > > the documentation. > > > > > It would make our (jython-dev) life easier and avoid some > > > impredictable problem even with CPython and code sharing, but > > > see previous note (**) > > > > So enforce it and see how it turns out in practice. > It's probably the best solution, at least for Jython, > and could even make sense for CPython (see above points) Good. We seem to agree. > > > > I don't want to force you to call a cooperative super method > > > > at the Java level -- it would be very slow, I suspect... > > > > > Yes ... very slow and we would have to use that also at the very > > > core of the hierarchy, see (*) but the problem is more > > > complicated, in Java given three classes > > > > > > C extends B extends A > > > and a method m > > > C.m overrides B.m overrides A.m > > > > > > there is not direct way (even using reflection) > > > to apply B.m behaviour to a C object, unless > > > the programmer has left some hook in C using super > > > or in B ( a method B_m e.g.). > > > > I guess C.m has to call super.m to invoke B.m, right? > Yup. > > Does this mean that the following can't be made to work? > > > > class C(list): > > def add_spam(self): > > return list.append(self, "spam") > > > > It's legal Python (although in general questionable style of course). > Yes, it can be made to work (it already works for Java subclassing > and type subclassing would be some flavor of that), but the point is > that your Java stuff should be at the top of the mro. Because then > you can insert some hooks using super. > > regards. I hope this discussion so far has been helpful -- I have to pack for my trip and will soon be off to San Francisco until next Wednesday. --Guido van Rossum (home page: http://www.python.org/~guido/) From mwh@python.net Fri Aug 24 19:09:53 2001 From: mwh@python.net (Michael Hudson) Date: 24 Aug 2001 14:09:53 -0400 Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: Paul Prescod's message of "Wed, 22 Aug 2001 10:56:33 -0800" References: <3B82AFFE.652A19F5@ActiveState.com> <200108220048.UAA24452@cj20424-a.reston1.va.home.com> <3B83DD5D.3260BC9C@ActiveState.com> <3B83EE5B.CEB38C48@ActiveState.com> <15235.61766.827878.699521@slothrop.digicool.com> <3B840061.A55BA194@ActiveState.com> Message-ID: <2m7kvtcosu.fsf@starship.python.net> Paul Prescod writes: > Neil Bauman asked him why Perl wasn't being written in Perl (Neil's > opinion is that Perl is literally the greatest language ever > created). Damian responded with a great quote: "Performance. If > Performance wasn't an issue, I'd probably write Perl 6 in Python or > something like it with wonderfully beautiful OO abstractions and it > would run like a dog." Tell them to use ocaml. Cheers, M. -- You have run into the classic Dmachine problem: your machine has become occupied by a malevolent spirit. Replacing hardware or software will not fix this - you need an exorcist. -- Tim Bradshaw, comp.lang.lisp From mwh@python.net Fri Aug 24 19:11:53 2001 From: mwh@python.net (Michael Hudson) Date: 24 Aug 2001 14:11:53 -0400 Subject: [Python-Dev] Re: copy, len and the like as 'object' methods? In-Reply-To: Paul Prescod's message of "Wed, 22 Aug 2001 18:08:40 -0700" References: <3B845798.7505DC91@ActiveState.com> Message-ID: <2m4rqxcopi.fsf@starship.python.net> Paul Prescod writes: > > Would you also argue for [1, 2, 3].repr() and "abc".hash()? > > Yes. But hashing and repring are done much less often than taking the > length. Note that this is an argument for keeping len(o) over o.len() - at least you bump into it early. Reminds me of what Laura Creighton said about the results of her case-sensitivity survey. Cheers, M. -- First of all, email me your AOL password as a security measure. You may find that won't be able to connect to the 'net for a while. This is normal. The next thing to do is turn your computer upside down and shake it to reboot it. -- Darren Tucker, asr From mwh@python.net Fri Aug 24 19:17:58 2001 From: mwh@python.net (Michael Hudson) Date: 24 Aug 2001 14:17:58 -0400 Subject: [Python-Dev] PEP 264 In-Reply-To: "Tim Peters"'s message of "Wed, 15 Aug 2001 17:24:20 -0400" References: Message-ID: <2m1ym1cofd.fsf@starship.python.net> "Tim Peters" writes: > [Michael Hudson] > > I *think* I'm done coding for implementing PEP 264; patch at: > > > > http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043 > > &group_id=5470 > > > > I've also done a first draft of docs. > > > > The reason for mentioning this is I'm off on holiday tomorrow, so if > > you want changes before the proposed date for 2.2a2, you've got aobut > > 12 hours to tell me about it. > > Thanks, Michael! I was out sick yesterday, but intend to get on this > tonight. You should enjoy your vacation! If it's a disaster, I'll probably > villify you on python-dev, but will fix it anyway . Thank you in turn for fixing all my cock-ups! I'd just like to note in passing that I considered most of the places the CO_* constants ended up in the last week, and rejected them as too gross. My idea was that __future__.generators.compiler_flag was to be the *only* (Python) name for CO_GENERATORS_ALLOWED (for example). Are there problems with this (other than the fact that you have to make sure two sets of magic numbers match up - but you have to edit __future__.py when you add a new future feature anyway...). I should probably add some words to the PEP on this topic, anyway. Cheers, M. -- ... when all the programmes on all the channels actually were made by actors with cleft pallettes speaking lines by dyslexic writers filmed by blind cameramen instead of merely seeming like that, it somehow made the whole thing more worthwhile. -- HHGTG, Episode 11 From mwh@python.net Fri Aug 24 19:23:23 2001 From: mwh@python.net (Michael Hudson) Date: 24 Aug 2001 14:23:23 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.227,2.228 In-Reply-To: Tim Peters's message of "Fri, 17 Aug 2001 15:11:30 -0700" References: Message-ID: <2my9o9b9lw.fsf@starship.python.net> Tim Peters writes: > ! /* XXX Warn if (supplied_flags & PyCF_MASK_OBSOLETE) != 0? */ I think not. If, as I *think*, all code objects compiled in 2.2 have ob.co_flags & __future__.nested_scopes.compiler_flag non-zero, then, eg., idle will compile all code typed interactively (after the first line, anyway) with __future__.nested_scopes.compiler_flag in the supplied_flags argument to compile(). This could be wormed around, obviously, but I don't see the point. Cheers, M. From Samuele Pedroni Fri Aug 24 19:28:50 2001 From: Samuele Pedroni (Samuele Pedroni) Date: Fri, 24 Aug 2001 20:28:50 +0200 (MET DST) Subject: [Python-Dev] nightmare: PEP 252, PEP 253 and jython issues Message-ID: <200108241829.UAA26901@core.inf.ethz.ch> [GvR] > > > now A is in between list and object: what is the right thing here? > > Just say that this is what happens. The MRO is inconsistent in this > case. > > > I don't expect or invite users to do that, but your rules allow A to > > end up in that position in the mro, your philosophy seems to be > > this is thin ice and so let it be ... > > Exactly. I wish I would not feel uneasy with that > > On the third hand, if a C programmer *wants* to write a class with the > proper cooperative super calling, they can do so, it's just a bit > clumsy. Should I provide a C API to make this easier? I doubt that > it will be used much. If there's demand, it can be added later. I hope there will not be. GvR> I don't think such subclasses GvR> should be used in complex multiple inheritance lattices. > > > Better to enforce that? > > Why? I can think of situations where you have a MRO like this: > > C list B object > > but where B doesn't override anything that list might use. In fact, > this is the typical mix-in situation. I don't want to forbid this. OK, I see. (*) GVR> So enforce it and see how it turns out in practice. > > > It's probably the best solution, at least for Jython, > > and could even make sense for CPython (see above points) > > Good. We seem to agree. Yup but I see your point (*) so probably I can't. [me] *bad-guy-java* > > > > Yes ... very slow and we would have to use that also at the very > > > > core of the hierarchy, see (*) but the problem is more > > > > complicated, in Java given three classes > > > > > > > > C extends B extends A > > > > and a method m > > > > C.m overrides B.m overrides A.m > > > > > > > > there is not direct way (even using reflection) > > > > to apply B.m behaviour to a C object, unless > > > > the programmer has left some hook in C using super > > > > or in B ( a method B_m e.g.). > > I hope this discussion so far has been helpful -- I have to pack for > my trip and will soon be off to San Francisco until next Wednesday. > Yes it was, thanks but I overlooked a central point, namely *bad-guy-java* I fear, because of it, we have to code all the built-in types this way, class SpamType { ... SpamTypes__foo__ { ... } ... __foo__ { } } Or find other slower ways, otherwise no descrs for them A nightmare :-( regards. From guido@python.org Fri Aug 24 19:44:05 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 24 Aug 2001 14:44:05 -0400 Subject: [Python-Dev] nightmare: PEP 252, PEP 253 and jython issues In-Reply-To: Your message of "Fri, 24 Aug 2001 20:28:50 +0200." <200108241829.UAA26901@core.inf.ethz.ch> References: <200108241829.UAA26901@core.inf.ethz.ch> Message-ID: <200108241844.OAA14685@cj20424-a.reston1.va.home.com> [snip] [SP] > *bad-guy-java* > > > > > Yes ... very slow and we would have to use that also at the very > > > > > core of the hierarchy, see (*) but the problem is more > > > > > complicated, in Java given three classes > > > > > > > > > > C extends B extends A > > > > > and a method m > > > > > C.m overrides B.m overrides A.m > > > > > > > > > > there is not direct way (even using reflection) > > > > > to apply B.m behaviour to a C object, unless > > > > > the programmer has left some hook in C using super > > > > > or in B ( a method B_m e.g.). > [snip] > I overlooked a central point, namely *bad-guy-java* > > I fear, because of it, we have to code all the built-in types this way, > > > class SpamType { > > ... SpamTypes__foo__ { ... > } > > ... __foo__ { } > > } > > Or find other slower ways, otherwise no descrs for them As long as the slowness only applies when someone invokes SpamType.__foo__(x), that's acceptable. --Guido van Rossum (home page: http://www.python.org/~guido/) From thomas.heller@ion-tof.com Fri Aug 24 19:57:04 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri, 24 Aug 2001 20:57:04 +0200 Subject: [Python-Dev] Customizing the binding of attributes References: <064201c12c04$37dfa6e0$e000a8c0@thomasnotebook> <200108231923.f7NJNg307631@odiug.digicool.com> <09f401c12c6a$7717ab80$e000a8c0@thomasnotebook> <200108241003.GAA04383@cj20424-a.reston1.va.home.com> Message-ID: <03cf01c12cce$90822d20$e000a8c0@thomasnotebook> [I wrote] > > - Shouldn't (my)instancemethod be a builtin? Similar to > > staticmethod and classmethod? > > Yes. I just checked this in. The new name is 'getset' unless you > have a better idea. I wasn't talking about your getset object (which is already mentioned in the PEP), I was thinking of an 'instancemethod' object, which would accept any callable (for example a *function* implemented in an extension module), and convert it into an unbound or bound method when retrieved from a class or an instance. Something like class instancemethod(object): def __init__(self, callable): self.callable = callable def __get__(self, inst, klass=None): import new return new.instancemethod(self.callable, inst, klass) only faster ;-) Thomas From guido@python.org Fri Aug 24 20:49:42 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 24 Aug 2001 15:49:42 -0400 Subject: [Python-Dev] Customizing the binding of attributes In-Reply-To: Your message of "Fri, 24 Aug 2001 20:57:04 +0200." <03cf01c12cce$90822d20$e000a8c0@thomasnotebook> References: <064201c12c04$37dfa6e0$e000a8c0@thomasnotebook> <200108231923.f7NJNg307631@odiug.digicool.com> <09f401c12c6a$7717ab80$e000a8c0@thomasnotebook> <200108241003.GAA04383@cj20424-a.reston1.va.home.com> <03cf01c12cce$90822d20$e000a8c0@thomasnotebook> Message-ID: <200108241949.PAA16386@cj20424-a.reston1.va.home.com> > I wasn't talking about your getset object (which is already mentioned > in the PEP), I was thinking of an 'instancemethod' object, > which would accept any callable (for example a *function* > implemented in an extension module), and convert it into an unbound > or bound method when retrieved from a class or an instance. > Something like > > class instancemethod(object): > def __init__(self, callable): > self.callable = callable > > def __get__(self, inst, klass=None): > import new > return new.instancemethod(self.callable, inst, klass) > > only faster ;-) I believe the (unbound) instance method type itself has this functionality, except it has no working constructor. I will fix that (not today :-). --Guido van Rossum (home page: http://www.python.org/~guido/) From Samuele Pedroni Fri Aug 24 20:54:07 2001 From: Samuele Pedroni (Samuele Pedroni) Date: Fri, 24 Aug 2001 21:54:07 +0200 (MET DST) Subject: [Python-Dev] nightmare: PEP 252, PEP 253 and jython issues Message-ID: <200108241954.VAA29770@core.inf.ethz.ch> [GvR] > > [SP] > > *bad-guy-java* > > > > > > Yes ... very slow and we would have to use that also at the very > > > > > > core of the hierarchy, see (*) but the problem is more > > > > > > complicated, in Java given three classes > > > > > > > > > > > > C extends B extends A > > > > > > and a method m > > > > > > C.m overrides B.m overrides A.m > > > > > > > > > > > > there is not direct way (even using reflection) > > > > > > to apply B.m behaviour to a C object, unless > > > > > > the programmer has left some hook in C using super > > > > > > or in B ( a method B_m e.g.). > > > [snip] > > I overlooked a central point, namely *bad-guy-java* > > > > I fear, because of it, we have to code all the built-in types this way, > > > > > > class SpamType { > > > > ... SpamTypes__foo__ { ... > > } > > > > ... __foo__ { } > > > > } > > > > Or find other slower ways, otherwise no descrs for them > > As long as the slowness only applies when someone invokes > SpamType.__foo__(x), that's acceptable. Not that simple, *bad-guy-java* is really nasty given your design for PEP 252 and PEP 253, you should put some hook to overridable behaviour or completely give up with Java OOP ... but it's our problem, your design up to my mro concerns is clearly is sound. But Jython 2.2 will be a major challenge. Samuele. From tim.one@home.com Fri Aug 24 23:26:13 2001 From: tim.one@home.com (Tim Peters) Date: Fri, 24 Aug 2001 18:26:13 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.227,2.228 In-Reply-To: <2my9o9b9lw.fsf@starship.python.net> Message-ID: > ! /* XXX Warn if (supplied_flags & PyCF_MASK_OBSOLETE) != 0? */ [Michael Hudson] > I think not. > > If, as I *think*, all code objects compiled in 2.2 have > > ob.co_flags & __future__.nested_scopes.compiler_flag > > non-zero, then, eg., idle will compile all code typed interactively > (after the first line, anyway) with > __future__.nested_scopes.compiler_flag in the supplied_flags argument > to compile(). This could be wormed around, obviously, but I don't see > the point. Your belief was true of 2.2a1 but not of 2.2a2. For 2.2a1, Guido simply turned on nested_scopes by default (and so every code object had CO_NESTED set). For 2.2a2, Jeremy returned from paternity leave and took away the *possibility* of turning nested scopes off. As a result, the *only* reference to CO_NESTED now in the C part of Python is in the #define of PyCF_MASK_OBSOLETE, and Python itself never sets CO_NESTED. That's part of what I meant when I said (in a different recent thread) that any piece of code using these flags is eventually going to get surprised: these implementation details are as internal and transient as they get. This isn't critical now, but I can't help but notice that we've got 8 bit positions assigned in the co_flags int. One is meaningless in 2.2a2 (CO_NESTED), and two more will eventually become meaningless (CO_GENERATOR_ALLOWED and CO_FUTURE_DIVISION). I'm not worried about running out of "real" co_flags bits, but so long as we're stuck *also* using co_flags to communicate-- from caller to dynamically-compiled callee --which still-optional future-features are in effect, we burn another bit position every time we dream up a future-feature with semantic content. So, but later rather than sooner, I expect we're going to have to recycle these temporary future-feature co_flags bits. When that happens, it may be prudent to *warn* about obsolete flag values for a release cycle (before recycling them), for the benefit of insane people who can't restrain themselves from playing with undocumented bits . From tim.one@home.com Fri Aug 24 23:41:05 2001 From: tim.one@home.com (Tim Peters) Date: Fri, 24 Aug 2001 18:41:05 -0400 Subject: [Python-Dev] PEP 264 In-Reply-To: <2m1ym1cofd.fsf@starship.python.net> Message-ID: [Michael Hudson] > Thank you in turn for fixing all my cock-ups! There were few -- it turned out to take much longer than "it should have" for reasons I don't want to bother recounting now, but rest assured there was plenty of blame to go around. Not nearly so much blame as glory, though . > I'd just like to note in passing that I considered most of the places > the CO_* constants ended up in the last week, and rejected them as too > gross. My idea was that > > __future__.generators.compiler_flag > > was to be the *only* (Python) name for CO_GENERATORS_ALLOWED (for > example). Are there problems with this (other than the fact that you > have to make sure two sets of magic numbers match up - but you have to > edit __future__.py when you add a new future feature anyway...). The problem is that nobody is going to *remember* the subtleties. IIRC, almost every bug I tracked down was due to *someone* neglecting to fiddle all the places that needed to be fiddled when changing future-flags. So The Rule I implemented was two-fold: 1. If possible, remove the need to remember at all (e.g., that was done for PyEval_MergeCompilerFlags, which hadn't been updated to know about CO_FUTURE_DIVISION (a bug), but was still uselessly merging CO_NESTED (a waste)). 2. When not possible, guarantee that a dumb-ass global editor search will find all "conceptual" uses of a CO_xxx flag name. #2 is why __future__.py contains the names "CO_NESTED" etc. Since it's not possible to hide the need entirely, it's imperative to make the dumbest approach imaginable likely to succeed for the next time, when the novelty has warn off and nobody quite remembers anymore exactly what needs to be done. pyassem.py (in the Compiler package) does the same thing. > I should probably add some words to the PEP on this topic, anyway. I don't think it's needed; at this point the bugs have all been shamed into good behavior by the relentless application of simple good taste . From skip@pobox.com (Skip Montanaro) Fri Aug 24 23:52:08 2001 From: skip@pobox.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 24 Aug 2001 17:52:08 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.227,2.228 In-Reply-To: References: <2my9o9b9lw.fsf@starship.python.net> Message-ID: <15238.55960.530563.607085@cb40507-c.elmhst1.il.home.com> Tim> This isn't critical now, but I can't help but notice that we've got Tim> 8 bit positions assigned in the co_flags int.... Tim> So, but later rather than sooner, I expect we're going to have to Tim> recycle these temporary future-feature co_flags bits. I asked about reserving three bits to specify the virtual machine the codestring is meant to be executed on. ;-) Skip From nas@python.ca Sat Aug 25 02:05:58 2001 From: nas@python.ca (Neil Schemenauer) Date: Fri, 24 Aug 2001 18:05:58 -0700 Subject: [Python-Dev] shutting up tmpnam, tempnam, link warnings Message-ID: <20010824180558.A14251@glacier.fnational.com> If you're using a recent version of GNU libc you know what I mean. They are annoying as hell and there seems to be no way to disable them cleanly. Here's a hack: cd /lib perl -pe 's/gnu\.warning\.(tempnam|tmpnam|tmpnam_r)/gnu.wanting.\1/g' \ < libc-2.2.3.so > /tmp/libc-2.2.3.so cp -b /tmp/libc-2.2.3.so libc-2.2.3.so No warranty implied. :-) Neil From esr@thyrsus.com Sat Aug 25 00:51:56 2001 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 24 Aug 2001 19:51:56 -0400 Subject: [Python-Dev] Negative index in insert() Message-ID: <20010824195156.A1787@thyrsus.com> Given >>> a = [1, 2, 3, 4] because >>> a[-2] -3 I expected that a.insert(-2, 0) would yield [1, 2, 0, 3, 4]. It was a rude shock to discover that >>> a [0, 1, 2, 3, 4] In fact I think this may be the nastiest surprise Python has handed me since I started using it. The reference manual says "same as s[i:i] = [x] if i >= 0" which of course doesn't cover the i < 0 case. David Beasley's reference says "Inserts x at index i" which sounds like the behavior I was expecting but didn't get. Is this a deliberate design choice, an oversight, or a plain bug? If it's a choice, it's damn poorly documented -- this deserves at least a footnote in the list methods table. If it's an oversight or bug, I volunteer to fix it. -- Eric S. Raymond "America is at that awkward stage. It's too late to work within the system, but too early to shoot the bastards." -- Claire Wolfe From Greg.Wilson@baltimore.com Sat Aug 25 16:05:00 2001 From: Greg.Wilson@baltimore.com (Greg Wilson) Date: Sat, 25 Aug 2001 11:05:00 -0400 Subject: [Python-Dev] %b formatting Message-ID: <930BBCA4CEBBD411BE6500508BB3328F3A8F0F@nsamcanms1.ca.baltimore.com> Patch 455076 adds "%b" (binary) formatting for integers and long integers to both strings and unicodes. As this is my first time hacking on the Python source, I'd be grateful for comments. Thanks, Greg p.s. apologies for the length of the signature --- it's another joy of corporate life :-( ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From mwh@python.net Sat Aug 25 17:42:12 2001 From: mwh@python.net (Michael Hudson) Date: 25 Aug 2001 12:42:12 -0400 Subject: [Python-Dev] Re: copy, len and the like as 'object' methods? In-Reply-To: Michael Hudson's message of "24 Aug 2001 14:11:53 -0400" References: <3B845798.7505DC91@ActiveState.com> <2m4rqxcopi.fsf@starship.python.net> Message-ID: <2mr8u03xcr.fsf@starship.python.net> Michael Hudson writes: > Reminds me of what Laura Creighton said about the results of her > case-sensitivity survey. As Aahz has reminded me, it was Sheila King. -- languages shape the way we think, or don't. -- Erik Naggum, comp.lang.lisp From tim.one@home.com Sun Aug 26 05:08:18 2001 From: tim.one@home.com (Tim Peters) Date: Sun, 26 Aug 2001 00:08:18 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.227,2.228 In-Reply-To: <15238.55960.530563.607085@cb40507-c.elmhst1.il.home.com> Message-ID: [Skip Montanaro] > I asked about reserving three bits to specify the virtual machine the > codestring is meant to be executed on. ;-) Not a problem -- CO_GENERATOR is the only "real" new co_flag added in years, in 10 years we've only defined 5 real co_flags total, and there are no PEPs on the table that would need another one. So you may as well ask for 27 VM bits . From tim.one@home.com Sun Aug 26 07:14:15 2001 From: tim.one@home.com (Tim Peters) Date: Sun, 26 Aug 2001 02:14:15 -0400 Subject: [Python-Dev] Negative index in insert() In-Reply-To: <20010824195156.A1787@thyrsus.com> Message-ID: [Eric S. Raymond] > Given > > >>> a = [1, 2, 3, 4] > > because > > >>> a[-2] > -3 > > I expected that a.insert(-2, 0) would yield [1, 2, 0, 3, 4]. It was a > rude shock to discover that > > >>> a > [0, 1, 2, 3, 4] > > In fact I think this may be the nastiest surprise Python has > handed me since I started using it. I never noticed it, but agree it's strange. Did you open a feature request on SourceForge? Note that array objects (created by the array module) share this behavior. > The reference manual says "same as s[i:i] = [x] if i >= 0" which > of course doesn't cover the i < 0 case. Which formally means its behavior is undefined. > David Beasley's reference says "Inserts x at index i" which sounds like > the behavior I was expecting but didn't get. Ya, so file a bug report with David . > Is this a deliberate design choice, an oversight, or a plain bug? If > it's a choice, it's damn poorly documented -- this deserves at least a > footnote in the list methods table. If it's an oversight or bug, I > volunteer to fix it. Only Guido *may* be able to say for sure. Plausible: the behavior for i<0 was deliberate at the start, and when Python *grew* negative indices (it didn't always accept them), fear of incompatibility prevented changing .insert behavior (in the other cases where negative indices "grew a meaning", the old behavior was to raise an exception; but .insert accepted them silently). Digging thru CVS, the current behavior for i<0 has always been that way (since listobject.c rev 1.1); and the "if i >= 0" qualifier was added to libtypes.tex a bit over 6 years ago, with checkin comment correct description of list.insert() Hard call! I agree it should change, but if it breaks code the "but it was formally undefined" comeback doesn't really warm peoples' hearts. first-one-to-suggest-a-future-stmt-dies-ly y'rs - tim From gstein@lyra.org Sun Aug 26 07:17:35 2001 From: gstein@lyra.org (Greg Stein) Date: Sat, 25 Aug 2001 23:17:35 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects stringobject.c,2.124,2.125 In-Reply-To: ; from bwarsaw@users.sourceforge.net on Fri, Aug 24, 2001 at 11:32:08AM -0700 References: Message-ID: <20010825231735.B2111@lyra.org> On Fri, Aug 24, 2001 at 11:32:08AM -0700, Barry Warsaw wrote: >... > + PyObject * > + PyString_FromFormat(const char *format, ...) > + { > + va_list vargs; > + > + #ifdef HAVE_STDARG_PROTOTYPES > + va_start(vargs, format); > + #else > + va_start(vargs); > + #endif > + return PyString_FromFormatV(format, vargs); > + } For safety/propriety, you should call va_end() on the vargs variable. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sun Aug 26 07:21:47 2001 From: gstein@lyra.org (Greg Stein) Date: Sat, 25 Aug 2001 23:21:47 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects stringobject.c,2.124,2.125 In-Reply-To: ; from bwarsaw@users.sourceforge.net on Fri, Aug 24, 2001 at 11:32:08AM -0700 References: Message-ID: <20010825232147.C2111@lyra.org> On Fri, Aug 24, 2001 at 11:32:08AM -0700, Barry Warsaw wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory usw-pr-cvs1:/tmp/cvs-serv13719/Objects > > Modified Files: > stringobject.c >... > + end: > + _PyString_Resize(&string, s - PyString_AsString(string)); You could use: s - PyString_AS_STRING(string) Cheers, -g -- Greg Stein, http://www.lyra.org/ From esr@thyrsus.com Sun Aug 26 07:30:40 2001 From: esr@thyrsus.com (Eric S. Raymond) Date: Sun, 26 Aug 2001 02:30:40 -0400 Subject: [Python-Dev] Negative index in insert() In-Reply-To: ; from tim.one@home.com on Sun, Aug 26, 2001 at 02:14:15AM -0400 References: <20010824195156.A1787@thyrsus.com> Message-ID: <20010826023040.A32589@thyrsus.com> Tim Peters : > I never noticed it, but agree it's strange. Did you open a feature request > on SourceForge? Feature request? Heck, if Guido green-lights this I'll fix it myself. I haven't looked at the code yet but I'll be deeply surprised if it takes me longer than half an hour to nail this bug. > Hard call! I agree it should change, but if it breaks code the "but it was > formally undefined" comeback doesn't really warm peoples' hearts. If we're going to "fix" division, we sure ought to fix this. I've grown so used to Python being a smooth, consistent tool that fits comfortably in my hand that I found this really quite shocking. -- Eric S. Raymond "Both oligarch and tyrant mistrust the people, and therefore deprive them of arms." --Aristotle From esr@snark.thyrsus.com Sun Aug 26 10:11:46 2001 From: esr@snark.thyrsus.com (Eric S. Raymond) Date: Sun, 26 Aug 2001 05:11:46 -0400 Subject: [Python-Dev] Generalizing "in" to pairs of sequences Message-ID: <200108260911.f7Q9BkD30038@snark.thyrsus.com> This seems to be my week to ask simple, stupid questions. Is there any good semantic or philosophical reason that these aren't legal? >>> "ab" in "cabcd" 1 >>> "xy" in "cabcd" 0 >>> (1, 2) in (0, 1, 2, 3) 1 >>> (9, 8) in (0, 1, 2, 3) 0 Proposed -- the following definition of "in" as a binary operation on sequence types: a is "in" b if a occurs as a subsequence of b. I'd like to see Python support this mainly to get rid of the following common but ugly idiom: if b.find(a) > -1: # Do one thing else: # Do another It's really easy to forget and miscode the guard "if b.find(a):". By contrast, see how much clearer this is: if a in b: # Do one thing else: # Do another Thoughts? -- Eric S. Raymond I don't like the idea that the police department seems bent on keeping a pool of unarmed victims available for the predations of the criminal class. -- David Mohler, 1989, on being denied a carry permit in NYC From ping@lfw.org Sun Aug 26 10:25:31 2001 From: ping@lfw.org (Ka-Ping Yee) Date: Sun, 26 Aug 2001 02:25:31 -0700 (PDT) Subject: [Python-Dev] Re: Generalizing "in" to pairs of sequences In-Reply-To: <200108260911.f7Q9BkD30038@snark.thyrsus.com> Message-ID: On Sun, 26 Aug 2001, Eric S. Raymond wrote: > This seems to be my week to ask simple, stupid questions. > > Is there any good semantic or philosophical reason that these aren't legal? Yes. > >>> "ab" in "cabcd" > 1 > >>> "xy" in "cabcd" > 0 > >>> (1, 2) in (0, 1, 2, 3) > 1 > >>> (9, 8) in (0, 1, 2, 3) > 0 The current meaning of "in" is: Given a sequence b, a is "in" b if a is an element of b. Your "subsequence" interpretation would conflict with this meaning. Here's current behaviour: >>> "ab" in ("ab", "cd") 1 >>> "ab" in ("a", "b", "c", "d") 0 >>> (1, 2) in ((0, 1), (1, 2), (2, 3)) 1 >>> (1, 2) in (0, 1, 2, 3) 0 "in" cannot have both meanings. -- ?!ng "Computers are useless. They can only give you answers." -- Pablo Picasso From ping@lfw.org Sun Aug 26 10:39:55 2001 From: ping@lfw.org (Ka-Ping Yee) Date: Sun, 26 Aug 2001 02:39:55 -0700 (PDT) Subject: [Python-Dev] Re: Negative index in insert() In-Reply-To: Message-ID: Eric S. Raymond wrote: > >>> a = [1, 2, 3, 4] [...] > I expected that a.insert(-2, 0) would yield [1, 2, 0, 3, 4]. It was a > rude shock to discover that > > >>> a > [0, 1, 2, 3, 4] If this is fixed, i think we should do a complete job of it and make sure exceptions are raised when the index is out of range. Notice (in current Python): >>> a = [1, 2, 3, 4] >>> a.insert(999, 0) >>> a [1, 2, 3, 4, 0] >>> a.insert(-999, 0) >>> a [0, 1, 2, 3, 4, 0] So what's happening is that Python is silently clipping the index to [0..n]. To bring this in line with indexing behaviour, it should not only interpret values in the range [-n..n], but also raise IndexError when the value is outside of [-n..n]. (Compare to pop() -- the behaviour i'm suggesting is exactly what pop() does, except that the range for pop() is [-n..n-1].) This has the potential for breaking code, and so the transition should probably be done with a minor-version's worth of warning, but i think if we're going to change it we should make it right. When this is done, i believe we'll be down to exactly two ways of handling sequence indices -- (a) x and y are silently clipped to [-n..n-1] *only* in an [x:y]-style slice (b) in all other cases, an IndexError is raised if the index is out of range and these two cases are easy to separate and explain, and all will be consistent in its interpretation of negative numbers. Such simplicity would be nice to have. -- ?!ng "Computers are useless. They can only give you answers." -- Pablo Picasso From ping@lfw.org Sun Aug 26 11:43:06 2001 From: ping@lfw.org (Ka-Ping Yee) Date: Sun, 26 Aug 2001 03:43:06 -0700 (PDT) Subject: [Python-Dev] Re: Negative index in insert() Message-ID: On Sun, 26 Aug 2001, Ka-Ping Yee wrote: > (a) x and y are silently clipped to [-n..n-1] > *only* in an [x:y]-style slice Sorry -- of course i meant [-n..n] here. -- ?!ng From esr@thyrsus.com Sun Aug 26 11:54:37 2001 From: esr@thyrsus.com (Eric S. Raymond) Date: Sun, 26 Aug 2001 06:54:37 -0400 Subject: [Python-Dev] Re: Generalizing "in" to pairs of sequences In-Reply-To: ; from ping@lfw.org on Sun, Aug 26, 2001 at 02:25:31AM -0700 References: <200108260911.f7Q9BkD30038@snark.thyrsus.com> Message-ID: <20010826065437.A8269@thyrsus.com> Ka-Ping Yee : > Your "subsequence" interpretation would conflict with this meaning. > Here's current behaviour: > > >>> "ab" in ("ab", "cd") > 1 > >>> "ab" in ("a", "b", "c", "d") > 0 > >>> (1, 2) in ((0, 1), (1, 2), (2, 3)) > 1 > >>> (1, 2) in (0, 1, 2, 3) > 0 > > "in" cannot have both meanings. You're right. But since a string can't be an element of a string, the case I'm really interested in would still work. -- Eric S. Raymond "Both oligarch and tyrant mistrust the people, and therefore deprive them of arms." --Aristotle From ping@lfw.org Sun Aug 26 12:01:01 2001 From: ping@lfw.org (Ka-Ping Yee) Date: Sun, 26 Aug 2001 04:01:01 -0700 (PDT) Subject: [Python-Dev] Re: Generalizing "in" to pairs of sequences In-Reply-To: <20010826065437.A8269@thyrsus.com> Message-ID: On Sun, 26 Aug 2001, Eric S. Raymond wrote: > You're right. But since a string can't be an element of a string, the > case I'm really interested in would still work. It's arguable. A character can indeed be an element of a string, and in Python characters are one-character strings. So this violates x in s <=> there exists i such that s[i] == x You could argue that strings should have special behaviour for "in" to support the common case of finding a substring; then you would have to argue on grounds of "practicality beats purity". I might support the argument on grounds of practicality beating purity, but i'd have to think carefully about violating the above definition. I can see that "substring in string" would be very convenient, but then if char in '0123456789': ... would suddenly have a very different meaning -- it would succeed for char = '12'. -- ?!ng From skip@pobox.com (Skip Montanaro) Sun Aug 26 17:36:52 2001 From: skip@pobox.com (Skip Montanaro) (Skip Montanaro) Date: Sun, 26 Aug 2001 11:36:52 -0500 Subject: [Python-Dev] can anonymous bug reports/patches be squelched? Message-ID: <15241.9636.961594.597780@beluga.mojam.com> I noticed a bsddbmodule report today and checked it out. An anonymous submitter had reported a bug with bsddbmodule.c. Martin responded with "try --without-libdb" and asked the person to report whether that helped. Two weeks later, after no response from the submitter (how would he have seen it?), Jeremy closed the bug. That was the right thing to do under the circumstances, but I would if there's some way to not allow anonymous bug reports and patches. It seems almost impossible to actually get a response back to the submitter in such cases, so I don't see how you can have a useful dialog about the report/patch. Skip From fdrake@acm.org Sun Aug 26 17:43:23 2001 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Sun, 26 Aug 2001 12:43:23 -0400 Subject: [Python-Dev] can anonymous bug reports/patches be squelched? In-Reply-To: <15241.9636.961594.597780@beluga.mojam.com> References: <15241.9636.961594.597780@beluga.mojam.com> Message-ID: <15241.10027.588676.942551@grendel.digicool.com> Skip Montanaro writes: > That was the right thing to do under the circumstances, but I would if > there's some way to not allow anonymous bug reports and patches. It seems > almost impossible to actually get a response back to the submitter in such > cases, so I don't see how you can have a useful dialog about the > report/patch. Anonymous means the submitter was not logged in, but appearantly they have an option to leave an email address (which is not shown, which is fine). I don't think there's a requirement for an email address, though, and I don't see any way for us to determine if they left one. If there were a way to *require* an email address, or at least determine if there was one, I'd be satisfied. Not allowing anonymous reports at all would not be very good; many of them have proved useful (it doesn't matter who reports a typo in the docs, just that it gets assigned to me). -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From mwh@python.net Sun Aug 26 19:41:39 2001 From: mwh@python.net (Michael Hudson) Date: 26 Aug 2001 14:41:39 -0400 Subject: [Python-Dev] PEP 264 In-Reply-To: "Tim Peters"'s message of "Fri, 24 Aug 2001 18:41:05 -0400" References: Message-ID: <2m4rqu4qak.fsf@starship.python.net> "Tim Peters" writes: > [Michael Hudson] > > I'd just like to note in passing that I considered most of the places > > the CO_* constants ended up in the last week, and rejected them as too > > gross. My idea was that > > > > __future__.generators.compiler_flag > > > > was to be the *only* (Python) name for CO_GENERATORS_ALLOWED (for > > example). Are there problems with this (other than the fact that you > > have to make sure two sets of magic numbers match up - but you have to > > edit __future__.py when you add a new future feature anyway...). > > The problem is that nobody is going to *remember* the subtleties. IIRC, > almost every bug I tracked down was due to *someone* neglecting to fiddle > all the places that needed to be fiddled when changing future-flags. So The > Rule I implemented was two-fold: [schnipp] OK, I see. In this spirit, wouldn't it be better to define the PyCF_MASK and PyCF_MASK_OBSOLETE flags in the same place as the CO_* flags they're made up of? Cheers, M. -- Richard Gabriel was wrong: worse is not better, lying is better. Languages and systems succeed in the marketplace to the extent that their proponents lie about what they can do. -- Tim Bradshaw, comp.lang.lisp From greg@cosc.canterbury.ac.nz Mon Aug 27 00:20:06 2001 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Mon, 27 Aug 2001 11:20:06 +1200 (NZST) Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: <2m7kvtcosu.fsf@starship.python.net> Message-ID: <200108262320.LAA04767@s454.cosc.canterbury.ac.nz> Michael Hudson : > Paul Prescod writes: > > Damian responded with a great quote: "...If > > Performance wasn't an issue, I'd probably write Perl 6 in Python or > > something like it with wonderfully beautiful OO abstractions and it > > would run like a dog." At least it would eliminate all the "why is Python slower than Perl" ng questions. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From skip@pobox.com (Skip Montanaro) Mon Aug 27 03:01:32 2001 From: skip@pobox.com (Skip Montanaro) (Skip Montanaro) Date: Sun, 26 Aug 2001 21:01:32 -0500 Subject: [Python-Dev] Where are locals initialized? Message-ID: <15241.43516.529415.828023@beluga.mojam.com> I'm probably just too tired to be looking at this right now, but I'm having no luck figuring out just where local variables are initialized. In 1.5.2 eval_code2 is called with all the bits and pieces needed to create a frame and does so. In 2.1 eval_frame is called with an already initialized frame. Either way I expected to see a call to PyFrame_LocalsToFast in or around PyFrame_New, but the places where I see it don't seem like the logical place (to my misfiring brain anyway). Any pointers appreciated, Skip From barry@zope.com Mon Aug 27 04:07:30 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 26 Aug 2001 23:07:30 -0400 Subject: [Python-Dev] Re: Generalizing "in" to pairs of sequences References: <20010826065437.A8269@thyrsus.com> Message-ID: <15241.47474.461384.774856@anthem.wooz.org> ESR> You're right. But since a string can't be an element of a ESR> string, the case I'm really interested in would still work. KY> It's arguable. A character can indeed be an element of a KY> string, and in Python characters are one-character strings. KY> So this violates KY> x in s <=> there exists i such that s[i] == x KY> You could argue that strings should have special behaviour for KY> "in" to support the common case of finding a substring; then KY> you would have to argue on grounds of "practicality beats KY> purity". And against TOOWTDI: >>> 'cabcd'.find('ab') >= 0 1 >>> 'cabcd'.find('xx') >= 0 0 -Barry From barry@zope.com Mon Aug 27 04:08:33 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 26 Aug 2001 23:08:33 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects stringobject.c,2.124,2.125 References: <20010825231735.B2111@lyra.org> Message-ID: <15241.47537.351411.119384@anthem.wooz.org> >>>>> "GS" == Greg Stein writes: GS> For safety/propriety, you should call va_end() on the vargs GS> variable. Good catch! I meant to add that after noticing the original code didn't contain it, and after double checking with the Linux manpage for va_start. I touched so much other code I forgot to go back and add that call. Will do so now... GS> You could use: s - PyString_AS_STRING(string) Good call. The original code had the former, but you're right that this is better. Thanks, -Barry From ask@valueclick.com Mon Aug 27 10:51:27 2001 From: ask@valueclick.com (Ask Bjoern Hansen) Date: Mon, 27 Aug 2001 02:51:27 -0700 (PDT) Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: <15236.3994.507401.287832@beluga.mojam.com> Message-ID: On Wed, 22 Aug 2001, Skip Montanaro wrote: [...] > libraries (and thus use by a critical mass) not in the core that much > higher. There are how many Python Server Pages like things? #$&$&%. Don't worry; even if we only look at those on CPAN we have more templating systems in Perl than you would ever want to count. > They probably all have some very nifty features, but tend to be > used by rather small pockets of people, at least relative to the > overall segment of the Python community doing webish stuff. > I'm not entirely sure why that's the case, but I suspect it has > to do in part with the barrier to discovering, downloading, and > installing these packages. Nah, some things just have to be implemented and reimplemented and reimplemented and reimplemented in slightly different ways. :-) - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com From alex_c@MIT.EDU Mon Aug 27 12:41:26 2001 From: alex_c@MIT.EDU (Alex Coventry) Date: 27 Aug 2001 07:41:26 -0400 Subject: [Python-Dev] Re: Generalizing "in" to pairs of sequences In-Reply-To: barry@zope.com's message of "Sun, 26 Aug 2001 23:07:30 -0400" References: <15241.47474.461384.774856@anthem.wooz.org> Message-ID: Sometimes I find myself wishing that strings had a method "substringp" that would do basically what Eric wants, like >>> 'cabcd'.substringp('ca') 1 >>> 'cabcd'.substringp('xx') 0 substringp would probably be the wrong name for it, though. Alex. From barry@zope.com Mon Aug 27 14:51:03 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 27 Aug 2001 09:51:03 -0400 Subject: [Python-Dev] Re: Generalizing "in" to pairs of sequences References: <15241.47474.461384.774856@anthem.wooz.org> Message-ID: <15242.20551.521357.800605@anthem.wooz.org> >>>>> "AC" == Alex Coventry writes: AC> Sometimes I find myself wishing that strings had a method AC> "substringp" that would do basically what Eric wants, like >> 'cabcd'.substringp('ca') AC> 1 >> 'cabcd'.substringp('xx') AC> 0 AC> substringp would probably be the wrong name for it, though. Hmm, "hassubstring()"? not-implying-a-vote-on-adding-such-a-method-ly y'rs, -Barry From jeremy@zope.com Mon Aug 27 15:27:17 2001 From: jeremy@zope.com (Jeremy Hylton) Date: Mon, 27 Aug 2001 10:27:17 -0400 (EDT) Subject: [Python-Dev] Where are locals initialized? In-Reply-To: <15241.43516.529415.828023@beluga.mojam.com> References: <15241.43516.529415.828023@beluga.mojam.com> Message-ID: <15242.22725.241556.803488@slothrop.digicool.com> It's in PyEval_EvalCodeEx(). Look for the SETLOCAL() macro. The code in lines 2305 to 2494 is all dealing with function arguments. Jeremy From nas@python.ca Mon Aug 27 17:23:49 2001 From: nas@python.ca (Neil Schemenauer) Date: Mon, 27 Aug 2001 09:23:49 -0700 Subject: [Python-Dev] python generator design bug? Message-ID: <20010827092349.A23538@glacier.arctrix.com> Eric Kidd thinks so: http://www.advogato.org/person/emk/ Here's an excerpt: [...] there's a subtle bug in the Python design. Consider tree traversal: def inorder(t): if (t.left != None): for (node in inorder(t.left)): yield node yield t if (t.right != None): for (node in inorder(t.right)): yield node If you study this carefully, you'll see that (unless the optimizer intervenes), Python has turned a perfectly good O(N) tree traversal into an O(N log N) traversal. Thoughts? Neil From guido@python.org Mon Aug 27 17:38:15 2001 From: guido@python.org (Guido van Rossum) Date: Mon, 27 Aug 2001 12:38:15 -0400 Subject: [Python-Dev] Re: Generalizing "in" to pairs of sequences In-Reply-To: Your message of "Sun, 26 Aug 2001 04:01:01 PDT." References: Message-ID: <200108271638.MAA25363@cj20424-a.reston1.va.home.com> > On Sun, 26 Aug 2001, Eric S. Raymond wrote: > > You're right. But since a string can't be an element of a string, the > > case I'm really interested in would still work. > > It's arguable. A character can indeed be an element of a string, and > in Python characters are one-character strings. So this violates > > x in s <=> there exists i such that s[i] == x > > You could argue that strings should have special behaviour for "in" > to support the common case of finding a substring; then you would have > to argue on grounds of "practicality beats purity". > > I might support the argument on grounds of practicality beating purity, > but i'd have to think carefully about violating the above definition. > > I can see that "substring in string" would be very convenient, but then > > if char in '0123456789': ... > > would suddenly have a very different meaning -- it would succeed for > char = '12'. We *could* allow this for strings, but not for other sequences. For strings, type(s[0]) == type(s), and this avoids the ambiguity. The fact that currently ``noncharacter in string'' raises an exception makes it relatively painess to add semantics for it. But I'll have to think about why I ruled it out originall. I'll track down Eric here at LinuxWorld and discuss it with him, if we find time. --Guido van Rossum (home page: http://www.python.org/~guido/) From esr@thyrsus.com Mon Aug 27 19:01:34 2001 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 27 Aug 2001 14:01:34 -0400 Subject: [Python-Dev] Re: Generalizing "in" to pairs of sequences In-Reply-To: <15242.20551.521357.800605@anthem.wooz.org>; from barry@zope.com on Mon, Aug 27, 2001 at 09:51:03AM -0400 References: <15241.47474.461384.774856@anthem.wooz.org> <15242.20551.521357.800605@anthem.wooz.org> Message-ID: <20010827140134.A7687@thyrsus.com> Barry A. Warsaw : > AC> substringp would probably be the wrong name for it, though. > > Hmm, "hassubstring()"? How about "contains"? E.g. if a.contains(b): # do stuff -- Eric S. Raymond (Those) who are trying to read the Second Amendment out of the Constitution by claiming it's not an individual right (are) courting disaster by encouraging others to use the same means to eliminate portions of the Constitution they don't like. -- Alan Dershowitz, Harvard Law School From esr@thyrsus.com Mon Aug 27 19:08:10 2001 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 27 Aug 2001 14:08:10 -0400 Subject: [Python-Dev] Re: Generalizing "in" to pairs of sequences In-Reply-To: <200108271638.MAA25363@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Aug 27, 2001 at 12:38:15PM -0400 References: <200108271638.MAA25363@cj20424-a.reston1.va.home.com> Message-ID: <20010827140810.B7687@thyrsus.com> Guido van Rossum : > We *could* allow this for strings, but not for other sequences. > For strings, type(s[0]) == type(s), and this avoids the ambiguity. > The fact that currently ``noncharacter in string'' raises an exception > makes it relatively painess to add semantics for it. But I'll have to > think about why I ruled it out originall. I'll track down Eric here > at LinuxWorld and discuss it with him, if we find time. Alas, due to a massive screwup by IDG that I only discovered two days ago, I won't be at LinuxWorld this time. Which bites; I was really looking forward to going. -- Eric S. Raymond "The bearing of arms is the essential medium through which the individual asserts both his social power and his participation in politics as a responsible moral being..." -- J.G.A. Pocock, describing the beliefs of the founders of the U.S. From James_Althoff@i2.com Mon Aug 27 19:17:25 2001 From: James_Althoff@i2.com (James_Althoff@i2.com) Date: Mon, 27 Aug 2001 11:17:25 -0700 Subject: [Python-Dev] copy, len and the like as 'object' methods? Message-ID: Tim Peters wrote: >Say what?! What kind of stupid-ass language spells the len() function as if >it were a method? That's carrying consistency to an irrational extreme -- Well, only those stupid-ass, irrational, and extremist languages that include classes and methods as an integral and uniform part of the language from the very beginning, I guess. The "stupid-ass, irrational, extremist" side is merely saying that mylist.append(x) mylist.length() mylist.extend(y) mylist.length() is more sensible (easier for new-to-python programmers to discover, more consistent, more mainstream) than mylist.append(x) len(mylist) mylist.extend(y) len(mylist) and that len(mylist) as syntactic sugar for mylist.__len__() is sugar that adds no value compared to just doing the straightforward thing of writing mylist.length() or mylist.len(). But you all clearly like spelling it len(mylist) and it's already there, so ... whatever. Jim From tim.one@home.com Mon Aug 27 20:03:00 2001 From: tim.one@home.com (Tim Peters) Date: Mon, 27 Aug 2001 15:03:00 -0400 Subject: [Python-Dev] python generator design bug? In-Reply-To: <20010827092349.A23538@glacier.arctrix.com> Message-ID: [Neil Schemenauer] > Eric Kidd thinks so: > > http://www.advogato.org/person/emk/ > > Here's an excerpt: > > [...] there's a subtle bug in the Python design. Consider tree > traversal: > > def inorder(t): > if (t.left != None): > for (node in inorder(t.left)): > yield node > yield t > if (t.right != None): > for (node in inorder(t.right)): > yield node > > If you study this carefully, you'll see that (unless the optimizer > intervenes), Python has turned a perfectly good O(N) tree traversal > into an O(N log N) traversal. > > Thoughts? Replied to this before on c.l.py (but to David Eppstein): http://aspn.activestate.com/ASPN/Mail/Message/624273 enumerate-a-btree-and-"log(n)"-is-1-ly y'rs - tim From tim.one@home.com Mon Aug 27 21:00:36 2001 From: tim.one@home.com (Tim Peters) Date: Mon, 27 Aug 2001 16:00:36 -0400 Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: Message-ID: [Tim, giving his " " key a rest] > Say what?! What kind of stupid-ass language spells the len() function as > if it were a method? That's carrying consistency to an irrational > extreme -- [James_Althoff@i2.com] > Well, only those stupid-ass, irrational, and extremist languages that > include classes and methods as an integral and uniform part of > the language from the very beginning, I guess. I was more than half joking, but not entirely. > The "stupid-ass, irrational, extremist" side is merely saying that > > mylist.append(x) > mylist.length() > mylist.extend(y) > mylist.length() > > is more sensible (easier for new-to-python programmers to discover, > more consistent, more mainstream) Of course that's what they're saying, although "mainstream" is debatable: pure-OO languages aren't exactly mainstream, and Python isn't a pure-OO language. It doesn't follow that Python is mainstream, but neither does it follow that ".length()" isn't an eyesore . > But you all clearly like spelling it len(mylist) and it's already > there, so > ... whatever. I wouldn't want to write math.pi.sin() either -- functional notation for pure (referentially transparent; side-effect free) functions has a long and fine tradition, in and out of computer languages, and I *think* "get the length of some list", not "list, of all the things I may ask you for, in this case I want your length". It simply reads better to me as a function. Guido said he'd do it the other way had he to do it over, so I'll have to rest on "it's already there". From jack@oratrix.nl Mon Aug 27 21:09:28 2001 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 27 Aug 2001 22:09:28 +0200 Subject: [Python-Dev] CVS tags, unix Python and MacPython Message-ID: <20010827200933.7A2FCB5E00@oratrix.oratrix.nl> Folks, I need some good ideas on how to organize tag names for MacPython releases. When the MacPython repository was still separate things were fairly simple: when I did a MacPython release what ended up in the source tree was simply the (correctly tagged) Mac subtree from that repository and whatever happened to be current in the main repository (usually a couple of weeks newer than the corresponding unix release), with one or two files modified. When the repositories were merged I switched over to using the same tags as the unix release used. This has sort-of worked for the 2.1.1 release, although with some grumblings of the people doing the unix 2.1.1 release. Things will get worse with the 2.2a2 release, as there are a couple of things that I definitely want in there that aren't finished yet, so it'll be at least another week until I'm done, and moreover I'll have to be making a few (minor) mods to files outside the Mac subtree. This problem will continue for as long as MacPython stays alive (unless everyone is willing to delay all distributions until I'm done with MacPython too:-). I can see 3 possible solutions, I'd like to hear what people think is the best course of action (and what the powers-that-be sanction): - I can move the "r22a2" tag for the specific files. I don't think I like this solution (despite its simplicity) because the files in question are used by the OSX unix build too. - I can add an "r22a2-mac" tag all over the tree. - I can add an "r22a2" tag to the Mac subtree only, check out the whole r22a2 tagged Python tree and manually check out those files for which I need newer versions. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From tim.one@home.com Mon Aug 27 23:10:53 2001 From: tim.one@home.com (Tim Peters) Date: Mon, 27 Aug 2001 18:10:53 -0400 Subject: [Python-Dev] PEP 264 In-Reply-To: <2m4rqu4qak.fsf@starship.python.net> Message-ID: [Michael Hudson] > OK, I see. In this spirit, wouldn't it be better to define the > PyCF_MASK and PyCF_MASK_OBSOLETE flags in the same place as the CO_* > flags they're made up of? -0. I don't see that it matters. Wouldn't object if someone else wanted to, but they appear to make most sense where they are, next to the decl of the PyCompilerFlags struct (the "CF" in PyCF_MASK refers to Compiler Flags, not Code Flags -- these bits are doing double-duty in 2.2a2). From guido@python.org Tue Aug 28 18:03:08 2001 From: guido@python.org (Guido van Rossum) Date: Tue, 28 Aug 2001 13:03:08 -0400 Subject: [Python-Dev] CVS tags, unix Python and MacPython In-Reply-To: Your message of "Mon, 27 Aug 2001 22:09:28 +0200." <20010827200933.7A2FCB5E00@oratrix.oratrix.nl> References: <20010827200933.7A2FCB5E00@oratrix.oratrix.nl> Message-ID: <200108281703.NAA01931@cj20424-a.reston1.va.home.com> > - I can move the "r22a2" tag for the specific files. I don't think I > like this solution (despite its simplicity) because the files in > question are used by the OSX unix build too. That would be bad. > - I can add an "r22a2-mac" tag all over the tree. This sounds good to me. > - I can add an "r22a2" tag to the Mac subtree only, check out the > whole r22a2 tagged Python tree and manually check out those files for > which I need newer versions. It's up to you. --Guido van Rossum (home page: http://www.python.org/~guido/) From barry@scottb.demon.co.uk Tue Aug 28 19:41:53 2001 From: barry@scottb.demon.co.uk (Barry Scott) Date: Tue, 28 Aug 2001 19:41:53 +0100 Subject: [Python-Dev] copy, len and the like as 'object' methods? In-Reply-To: Message-ID: <000601c12ff1$1b0571d0$060210ac@private> > Tim said: > I *think* "get the > length of some list", not "list, of all the things I may ask you for, in > this case I want your length". It simply reads better to me as a function. length of list and type len(list) read the file and type file.read() maybe thinking... list how long are you list.length() file I want to read you file.read() BArry From tim.one@home.com Tue Aug 28 20:01:47 2001 From: tim.one@home.com (Tim Peters) Date: Tue, 28 Aug 2001 15:01:47 -0400 Subject: [Python-Dev] FW: PyInline Released: Put C source code directly "inline" with your Python! Message-ID: FYI. I haven't checked it out. -----Original Message----- From: python-list-admin@python.org [mailto:python-list-admin@python.org]On Behalf Of Ken Simpson Sent: Tuesday, August 28, 2001 2:06 PM To: python-list@python.org Subject: PyInline Released: Put C source code directly "inline" with your Python! The PyInline module allows you to put source code from other programming languages directly "inline" in a Python script or module. The code is automatically compiled as needed and then loaded for immediate access from Python. In short, PyInline lets you do things like this: from PyInline import C import __main__ # Let's put some C code "inline" with our Python: x = C.Builder(code=""" #include void ja(char *str) { printf("Just another %s hacker\n", str); } """, targetmodule=__main__) # Add C methods to the __main__ module. x.build() ja("Inline") --- PyInline is the Python equivalent of Brian Ingerson's Inline module for Perl (http://inline.perl.org), which was awarded the "Best Module" award at this year's Perl Conference. More information about PyInline can be found at the PyInline home page on SourceForge: http://pyinline.sourceforge.net To discuss PyInline further, please join the pyinline-discuss mailing list at http://lists.sourceforge.net/lists/listinfo/pyinline-discuss -- http://mail.python.org/mailman/listinfo/python-list From barry@zope.com Tue Aug 28 21:52:30 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 28 Aug 2001 16:52:30 -0400 Subject: [Python-Dev] Re: Generalizing "in" to pairs of sequences References: <15241.47474.461384.774856@anthem.wooz.org> <15242.20551.521357.800605@anthem.wooz.org> <20010827140134.A7687@thyrsus.com> Message-ID: <15244.1166.351735.428963@anthem.wooz.org> >>>>> "ESR" == Eric S Raymond writes: >> substringp would probably be the wrong name for it, though. >> Hmm, "hassubstring()"? ESR> How about "contains"? E.g. | if a.contains(b): | # do stuff Heh, and from there it's a small leap to a.__contains__(b), a.k.a. "b in a". Sneaky Eric, very sneaky. :) -Barry From esr@thyrsus.com Tue Aug 28 22:20:15 2001 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 28 Aug 2001 17:20:15 -0400 Subject: [Python-Dev] Re: Generalizing "in" to pairs of sequences In-Reply-To: <15244.1166.351735.428963@anthem.wooz.org>; from barry@zope.com on Tue, Aug 28, 2001 at 04:52:30PM -0400 References: <15241.47474.461384.774856@anthem.wooz.org> <15242.20551.521357.800605@anthem.wooz.org> <20010827140134.A7687@thyrsus.com> <15244.1166.351735.428963@anthem.wooz.org> Message-ID: <20010828172015.C7227@thyrsus.com> Barry A. Warsaw : > ESR> How about "contains"? E.g. > > | if a.contains(b): > | # do stuff > > Heh, and from there it's a small leap to a.__contains__(b), a.k.a. > "b in a". > > Sneaky Eric, very sneaky. :) You know, that didn't consciously occur to me. Which only goes to show that my unconscious mind is even *more* evil...BWAHAHAHAHAA! -- Eric S. Raymond Society in every state is a blessing, but government even in its best state is but a necessary evil; in its worst state an intolerable one; for when we suffer, or are exposed to the same miseries *by a government*, which we might expect in a country *without government*, our calamities is heightened by reflecting that we furnish the means by which we suffer." -- Thomas Paine From m.favas@per.dem.csiro.au Wed Aug 29 01:59:29 2001 From: m.favas@per.dem.csiro.au (Mark Favas) Date: Wed, 29 Aug 2001 08:59:29 +0800 Subject: [Python-Dev] Change from "config.h" to "pyconfig.h" may be a ticking #include bomb Message-ID: <3B8C3E71.A9A4C0BA@per.dem.csiro.au> Some little while ago, Python 2.2's "configure" started to produce pyconfig.h rather than config.h (a good thing). "make install" installs this file into /usr/local/include/python2.2 where it can be used by extensions, etc. However, any config.h file produced and installed before the change to pyconfig.h remains in /usr/local/include/python2.2. I've also been building the XML extension. Only when building this extension on a brand new Python 2.2 platform did I find that XML's extension/expat/lib/xmlparse.c #include's rather than (probably not the only extension that does this). Old 2.2 installations found the old config.h file and compiled without error, although they should have been using pyconfig.h. To pick up this sort of bug, perhaps "make install" should attempt to remove config.h if it exists in the target include directory? -- Mark Favas - m.favas@per.dem.csiro.au CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA From jack@oratrix.nl Wed Aug 29 13:29:51 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 29 Aug 2001 14:29:51 +0200 Subject: [Python-Dev] test_threaded_import Message-ID: <20010829122951.A22DC303181@snelboot.oratrix.nl> I spent the last couple of days hunting for the bug in MacPython threaded import, but it turned out the bug is in the test harness. (I did find another serious bug in the process, so the time wasn't wasted, but still) The problem is that test_threaded_import cannot run inside an "import". It knows this, and so does regrtest, so they run the test after the import by calling test_threaded_import.test_main(), which does the actual test. All good and fine if you run regrtest as a main script from the commandline, but of course it breaks if you run autotest, or if you "import regrtest" in an interactive window, because in these cases the import in the main thread already holds the lock. I can simply add an "if not verbose", as in test_socketserver, but that isn't really the problem. Does anyone know a better solution? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From tim.one@home.com Wed Aug 29 20:03:12 2001 From: tim.one@home.com (Tim Peters) Date: Wed, 29 Aug 2001 15:03:12 -0400 Subject: [Python-Dev] test_threaded_import In-Reply-To: <20010829122951.A22DC303181@snelboot.oratrix.nl> Message-ID: [Jack Jansen] > I spent the last couple of days hunting for the bug in MacPython > threaded import, but it turned out the bug is in the test harness. > (I did find another serious bug in the process, so the time wasn't > wasted, but still) Hmm! You originally said this test hung "about 30% of the time", and didn't respond when I asked how you ran it. Given the way you are running it, it should have hung 100% of the time. So something here is still muddy. > The problem is that test_threaded_import cannot run inside an > "import". It knows this, and so does regrtest, so they run the test > after the import by calling test_threaded_import.test_main(), which > does the actual test. > > All good and fine if you run regrtest as a main script from the > commandline, Or if you run test_threaded_import directly (leaving regrtest out of it). > but of course it breaks if you run autotest, So it does! I've never done that. > or if you "import regrtest" in an interactive window, Are you sure about that? Works fine for me, and should work fine. > because in these cases the import in the main thread > already holds the lock. It shouldn't hurt anything to import regrtest -- it's not until regrtest.main() gets invoked that a problem can occur. > I can simply add an "if not verbose", as in test_socketserver, > but that isn't really the problem. Does anyone know a better > solution? I don't like that either -- test_socketserver almost never gets run on my box simply because it's an oddball. For the same reason I'm sure the test_exceptions part of test_math never gets run on anyone's box. Assuming you were suffering an illusion when saying "import regrest in an interactive window" doesn't work, I'd be content to special-case the snot out of autotest, like so: Index: test_threaded_import.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_threaded_import.py,v retrieving revision 1.2 diff -c -r1.2 test_threaded_import.py *** test_threaded_import.py 2001/05/22 18:28:25 1.2 --- test_threaded_import.py 2001/08/29 18:53:38 *************** *** 6,12 **** # randrange, and then Python hangs. import thread ! from test_support import verbose critical_section = thread.allocate_lock() done = thread.allocate_lock() --- 6,12 ---- # randrange, and then Python hangs. import thread ! from test_support import verbose, TestSkipped critical_section = thread.allocate_lock() done = thread.allocate_lock() *************** *** 32,37 **** --- 32,41 ---- def test_main(): # magic name! see above global N, done + import sys + for modname in sys.modules: + if modname.find('autotest') >= 0: + raise TestSkipped("can't run from autotest") done.acquire() for N in (20, 50) * 3: if verbose: From jack@oratrix.nl Wed Aug 29 21:16:43 2001 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 29 Aug 2001 22:16:43 +0200 Subject: [Python-Dev] test_threaded_import In-Reply-To: Message by "Tim Peters" , Wed, 29 Aug 2001 15:03:12 -0400 , Message-ID: <20010829201648.9ED5115F546@oratrix.oratrix.nl> Recently, "Tim Peters" said: > Hmm! You originally said this test hung "about 30% of the time", and didn't > respond when I asked how you ran it. Given the way you are running it, it > should have hung 100% of the time. So something here is still muddy. Elementary, my dear Watson. I do a "make install", which runs the regression tests twice, succeeding both times. Then I do "python" and "import autotest", at which point it fails, thereby failing approximately 30% of the time. Of course, not being Sherlock Jansen, I didn't realise autotest!=regrtest for this:-) > > or if you "import regrtest" in an interactive window, > > Are you sure about that? Works fine for me, and should work fine. Sherlock Peters, you're absolutely right, of course:-) The regrtest ran afoul of the small stack space for threads in MacPython (for which I checked in a fix this afternoon). I didn't try it again when that bug was fixed. I'll apply your patch, which seems to fix the problem fine for the time being. Still, there's three issues that I think need to be solved at some point: - the fact that you (or some other thread) are holding the import lock is one of the few Python state bits that are not open to introspection. - There may be denial of service attacks possible with this if a 16 year old scriptkiddy can think of a way to exploit it in a restricted interpreter. - The whole idea that a process deadlocked on semaphore locks is completely uninterruptible also smells bad. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From tim.one@home.com Thu Aug 30 00:42:59 2001 From: tim.one@home.com (Tim Peters) Date: Wed, 29 Aug 2001 19:42:59 -0400 Subject: [Python-Dev] test_threaded_import In-Reply-To: <20010829201648.9ED5115F546@oratrix.oratrix.nl> Message-ID: [Jack Jansen] > ... > Elementary, my dear Watson. I do a "make install", which runs the > regression tests twice, succeeding both times. Then I do "python" and > "import autotest", at which point it fails, thereby failing > approximately 30% of the time. Of course, not being Sherlock Jansen, I > didn't realise autotest!=regrtest for this:-) Ah, a signficant digits error. Had you said "approximately 33% of the time", or even "approximately 3e1%", I would have guessed instantly . > ... > I'll apply your patch, which seems to fix the problem fine for the > time being. Still, there's three issues that I think need to be solved > at some point: > - the fact that you (or some other thread) are holding the import lock > is one of the few Python state bits that are not open to > introspection. The patch below adds introspection, sufficient to avoid special-casing autotest. Guido? I'd upload the patch to SF instead, but, as you've (Jack) noted, that's a black hole <0.9 wink>. > - There may be denial of service attacks possible with this if a 16 > year old scriptkiddy can think of a way to exploit it in a > restricted interpreter. Someone else will have to worry about that; in a world where a 20-character regexp can take centuries to match, I don't take DOS from a general-purpose programming language seriously. > - The whole idea that a process deadlocked on semaphore locks is > completely uninterruptible also smells bad. That's threads for you: start a thread, risk a deadlock. There's no portable way to interrupt a thread waiting on a lock, and, e.g., no *safe* way at all on Windows short of killing the whole process. Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.185 diff -c -r2.185 import.c *** Python/import.c 2001/08/13 23:05:44 2.185 --- Python/import.c 2001/08/29 23:25:28 *************** *** 138,143 **** --- 138,151 ---- static long import_lock_thread = -1; static int import_lock_level = 0; + static PyObject * + imp_lock_held(PyObject *self, PyObject *args) + { + if (!PyArg_ParseTuple(args, ":lock_held")) + return NULL; + return PyInt_FromLong(import_lock_thread != -1); + } + static void lock_import(void) { *************** *** 179,184 **** --- 187,200 ---- #define lock_import() #define unlock_import() + static PyObject * + imp_lock_held(PyObject *self, PyObject *args) + { + if (!PyArg_ParseTuple(args, ":lock_held")) + return NULL; + return PyInt_FromLong(0); + } + #endif /* Helper for sys */ *************** *** 2339,2350 **** --- 2355,2373 ---- The module name must include the full package name, if any.\ "; + static char doc_lock_held[] = "\ + lock_held() -> 0 or 1\n\ + Return 1 if the import lock is currently held.\n\ + On platforms without threads, return 0.\ + "; + static PyMethodDef imp_methods[] = { {"find_module", imp_find_module, 1, doc_find_module}, {"get_magic", imp_get_magic, 1, doc_get_magic}, {"get_suffixes", imp_get_suffixes, 1, doc_get_suffixes}, {"load_module", imp_load_module, 1, doc_load_module}, {"new_module", imp_new_module, 1, doc_new_module}, + {"lock_held", imp_lock_held, 1, doc_lock_held}, /* The rest are obsolete */ {"get_frozen_object", imp_get_frozen_object, 1}, {"init_builtin", imp_init_builtin, 1}, From guido@python.org Thu Aug 30 16:01:24 2001 From: guido@python.org (Guido van Rossum) Date: Thu, 30 Aug 2001 11:01:24 -0400 Subject: [Python-Dev] canned response added Message-ID: <200108301501.f7UF1OQ18292@odiug.digicool.com> At Jack's suggestion, I've used a canned response "Missing upload" to the Bugs and Patches trackers at SourceForge. This should save us a bit of time dealing with this annoying SF bug. --Guido van Rossum (home page: http://www.python.org/~guido/) From fredrik@pythonware.com Thu Aug 30 18:15:07 2001 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 30 Aug 2001 19:15:07 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _sre.c,2.63,2.64 References: Message-ID: <007601c13177$539e0a20$42fb42d5@hagrid> sjoerd wrote: > > Modified Files: > _sre.c > Log Message: > Removed unreachable return to silence SGI compiler. > > ! /* shouldn't end up here */ > ! return SRE_ERROR_ILLEGAL; > } > > --- 1141,1145 ---- > } > > ! /* can't end up here */ > } I hate stuff like this: that line was there to make sure *I* don't mess up when developing SRE, not to deal with potentially broken compilers or misfired electrons. isn't there any way to tell the SGI compiler to stop whining about this? From tim@zope.com Thu Aug 30 19:50:15 2001 From: tim@zope.com (Tim Peters) Date: Thu, 30 Aug 2001 14:50:15 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _sre.c,2.63,2.64 In-Reply-To: <007601c13177$539e0a20$42fb42d5@hagrid> Message-ID: >> _sre.c >> Log Message: >> Removed unreachable return to silence SGI compiler. >> >> ! /* shouldn't end up here */ >> ! return SRE_ERROR_ILLEGAL; >> } >> >> --- 1141,1145 ---- >> } >> >> ! /* can't end up here */ >> } [Fredrik Lundh] > I hate stuff like this: that line was there to make sure *I* don't > mess up when developing SRE, not to deal with potentially broken > compilers or misfired electrons. > > isn't there any way to tell the SGI compiler to stop whining about > this? I've had better luck x-platform with, e.g., assert(!"can't get here"); /* !string is always false */ In non-debug builds, it vanishes so there's nothing for the compiler to gripe about; while in debug builds most compilers don't do enough flow analysis to realize there *is* something to gripe about. Overall, it would be more useful if SGI compilers in particular produced: C00666: Warning: -O may produce buggy code. after every executable line . From skip@pobox.com (Skip Montanaro) Fri Aug 31 06:51:35 2001 From: skip@pobox.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 31 Aug 2001 00:51:35 -0500 Subject: [Python-Dev] timeoutsocket.py Message-ID: <15247.9703.69434.567507@beluga.mojam.com> I just submitted a feature request to add Tim O'Malley's timeoutsocket.py module to the Python distribution. Please have a look at http://sourceforge.net/tracker/index.php?func=detail&aid=457114&group_id=5470&atid=105470 and comment if you like. Skip From sjoerd.mullender@oratrix.com Fri Aug 31 10:08:19 2001 From: sjoerd.mullender@oratrix.com (Sjoerd Mullender) Date: Fri, 31 Aug 2001 11:08:19 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _sre.c,2.63,2.64 In-Reply-To: Your message of Thu, 30 Aug 2001 14:50:15 -0400. References: Message-ID: <20010831090820.9BFC7301382@bireme.oratrix.nl> Well, there is the possibility to add -woff 1110 to the compiler command line. However, I don't agree that this is whining and I wouldn't like to see any warnings suppressed like this. Warnings signal a potential bug, any so does this one. If the flow of control did reach this particular line, the compiler would also give a warning, namely that the function has both return value and return void (or words to that effect). I use the compiler in non-debug mode (-g option, no -O option), and I do get these warnings, so some compilers do do enough flow control in non-debug mode. On Thu, Aug 30 2001 "Tim Peters" wrote: > >> _sre.c > >> Log Message: > >> Removed unreachable return to silence SGI compiler. > >> > >> ! /* shouldn't end up here */ > >> ! return SRE_ERROR_ILLEGAL; > >> } > >> > >> --- 1141,1145 ---- > >> } > >> > >> ! /* can't end up here */ > >> } > > [Fredrik Lundh] > > I hate stuff like this: that line was there to make sure *I* don't > > mess up when developing SRE, not to deal with potentially broken > > compilers or misfired electrons. > > > > isn't there any way to tell the SGI compiler to stop whining about > > this? > > I've had better luck x-platform with, e.g., > > assert(!"can't get here"); /* !string is always false */ > > In non-debug builds, it vanishes so there's nothing for the compiler to > gripe about; while in debug builds most compilers don't do enough flow > analysis to realize there *is* something to gripe about. > > Overall, it would be more useful if SGI compilers in particular produced: > > C00666: Warning: -O may produce buggy code. > > after every executable line . > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > -- Sjoerd Mullender From gward@python.net Fri Aug 31 14:15:07 2001 From: gward@python.net (Greg Ward) Date: Fri, 31 Aug 2001 09:15:07 -0400 Subject: [Python-Dev] Re: Negative index in insert() In-Reply-To: ; from ping@lfw.org on Sun, Aug 26, 2001 at 02:39:55AM -0700 References: Message-ID: <20010831091507.A15968@gerg.ca> On 26 August 2001, Ka-Ping Yee said: > If this is fixed, i think we should do a complete job of it and > make sure exceptions are raised when the index is out of range. [...] > This has the potential for breaking code, and so the transition > should probably be done with a minor-version's worth of warning, > but i think if we're going to change it we should make it right. By "minor version" do you mean 2.2 -> 2.3, or 2.2 -> 2.2.1? I presume the former -- we're not allowed to make incompatible changes on point releases anymore! Of course, this implies a f***** statement. (I'm not going to say the word, Tim said the first one who does dies...) Greg -- Greg Ward - just another /P(erl|ython)/ hacker gward@python.net http://starship.python.net/~gward/ If you and a friend are being chased by a lion, it is not necessary to outrun the lion. It is only necessary to outrun your friend. From gward@python.net Fri Aug 31 14:35:19 2001 From: gward@python.net (Greg Ward) Date: Fri, 31 Aug 2001 09:35:19 -0400 Subject: [Python-Dev] PEP 250 Message-ID: <20010831093519.A16031@gerg.ca> Thomas -- have you been following the saga of patch #449054, part of the PEP 250 implementation. If I understand things correctly, this patch only partly implements PEP 250 -- the rest is waiting on a change to bdist_wininst. What's the status of this change? Going to make it in? Please see http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id=5470 if you haven't already... Greg -- Greg Ward - geek-at-large gward@python.net http://starship.python.net/~gward/ Just because you're paranoid doesn't mean they *aren't* out to get you. From akuchlin@mems-exchange.org Fri Aug 31 15:48:43 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 31 Aug 2001 10:48:43 -0400 Subject: [Python-Dev] CVS: python/dist/src/Modules _sre.c,2.63,2.64 In-Reply-To: <20010831090820.9BFC7301382@bireme.oratrix.nl>; from sjoerd.mullender@oratrix.com on Fri, Aug 31, 2001 at 11:08:19AM +0200 References: <20010831090820.9BFC7301382@bireme.oratrix.nl> Message-ID: <20010831104842.D30221@ute.mems-exchange.org> On Fri, Aug 31, 2001 at 11:08:19AM +0200, Sjoerd Mullender wrote: >any so does this one. If the flow of control did reach this >particular line, the compiler would also give a warning, namely that >the function has both return value and return void (or words to that >effect). Your compiler might, but I don't know if Fredrik's will, and for the SRE code Fredrik's compiler is more important. Perhaps Tim's suggested assert() can fix things so that both of you are happy. --amk From thomas.heller@ion-tof.com Fri Aug 31 15:53:50 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri, 31 Aug 2001 16:53:50 +0200 Subject: [Python-Dev] PEP 250 References: <20010831093519.A16031@gerg.ca> Message-ID: <017a01c1322c$bf558fd0$e000a8c0@thomasnotebook> From: "Greg Ward" > Thomas -- > > have you been following the saga of patch #449054, part of the PEP 250 > implementation. If I understand things correctly, this patch only > partly implements PEP 250 -- the rest is waiting on a change to > bdist_wininst. What's the status of this change? Going to make it in? Sure, will do it before 2.2a3. That's Sep 19, right? Looking at the patch again, it seems sufficient to install into lib/site-packages if sys.version >= 2.2. No fiddling with loading python at runtime, importing distutils.sysconfig, and so on in bdist_wininst. Thomas From guido@python.org Fri Aug 31 20:28:25 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 31 Aug 2001 15:28:25 -0400 Subject: [Python-Dev] Would it make sense to issue an extra alpha next week? Message-ID: <200108311928.PAA21836@cj20424-a.reston1.va.home.com> When I was updating the NEWS file this morning, I realized that we've already added a truckload of nifty stuff in the 9 days since 2.2a2 was released: int overflows return longs, classic division warnings, subclassing builtins, super, getset, two fixes to float literals, the new GC API, and PyString_FromFormat[V]. I expect that I'll be concentrating on documentation for the type/class unification next. While writing the first piece of documentation, I realized that, sadly, several more advanced things aren't available in 2.2a2 yet. The next alpha is planned for Sept. 19, almost three weeks off still. Does anybody object against the release of an extra release, 2.2a3, around Sept. 5? We could do 2.2a4 on Sept. 19, or a week later if the schedule gets too crowded. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim.one@home.com Fri Aug 31 20:29:02 2001 From: tim.one@home.com (Tim Peters) Date: Fri, 31 Aug 2001 15:29:02 -0400 Subject: [Python-Dev] -Dwarn, long->double overflow (was RE: [Python-checkins] CVS: python/dist/src/Misc NEWS,1.219,1.220) In-Reply-To: Message-ID: [Guido] > + + A new command line option, -D , is added to control run-time > + warnings for the use of classic division. > ... > + Using -Dwarn issues a run-time warning about all uses of classic > + division for int, long, float and complex arguments. I'm unclear on why we warn about classic division when a float or complex is involved: C:\Code\python\PCbuild>python -Dwarn Python 2.2a2+ (#22, Aug 31 2001, 14:36:57) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> 2./3. __main__:1: DeprecationWarning: classic float division 0.66666666666666663 >>> Given that this is going to return the same result even in Python 3.0, what is it warning me about? That is, as an end user, I'm being warned about behavior I can't do anything about, and behavior that Python isn't going to change anyway. Different issue: I would like to add OverflowError when coercion of long to float yields a senseless result. PEP 238 mentions this as a possibility, and >>> from __future__ import division >>> x = 1L << 3000 >>> x/(2*x) -1.#IND >>> really sucks. For that matter, >>> float(1L << 3000) 1.#INF >>> has always sucked; future division just makes it suck harder . Any objections to raising OverflowError here? Note this is a bit painful for a bogus reason: PyFloat_AsDouble returns a double, and nothing in the codebase now checks it for a -1.0 error return (despite that it can already produce one). So half the effort would be repairing code currently ignoring the possibility of error. Third issue: I don't see a *good* reason for the future-division x/(2*x) above not to return 0.5. long_true_divide could be made smart enough to do that (more generally, to return a good float approximation whenever the true result is representable as a float). From guido@python.org Fri Aug 31 20:39:21 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 31 Aug 2001 15:39:21 -0400 Subject: [Python-Dev] Re: -Dwarn, long->double overflow (was RE: [Python-checkins] CVS: python/dist/src/Misc NEWS,1.219,1.220) In-Reply-To: Your message of "Fri, 31 Aug 2001 15:29:02 EDT." References: Message-ID: <200108311939.PAA21883@cj20424-a.reston1.va.home.com> > [Guido] > > + + A new command line option, -D , is added to control run-time > > + warnings for the use of classic division. > > ... > > + Using -Dwarn issues a run-time warning about all uses of classic > > + division for int, long, float and complex arguments. > > I'm unclear on why we warn about classic division when a float or complex is > involved: > > C:\Code\python\PCbuild>python -Dwarn > Python 2.2a2+ (#22, Aug 31 2001, 14:36:57) [MSC 32 bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> 2./3. > __main__:1: DeprecationWarning: classic float division > 0.66666666666666663 > >>> > > Given that this is going to return the same result even in Python 3.0, what > is it warning me about? That is, as an end user, I'm being warned about > behavior I can't do anything about, and behavior that Python isn't going to > change anyway. Sorry, I should have explained the intention. This warning is intended for perusal by a tool (yet to create) that reads the warnings and can automatically fix your code by inserting the proper future division statements and/or replace / by //. The tool parses the source looking for / operators. For each / it sees if it has corresponding warnings, and if so, if the warnings are consistent (only int/long or only float/complex), it does the right thing. If all / operators in a module have at least one warning, it assumes that it has full coverage, and it adds a future division statement to the module. If there are some / operators for which it doesn't have any warnings, it asks the user to create a better test case. For this, it needs to know about float and complex divisions as well. > Different issue: I would like to add OverflowError when coercion of > long to float yields a senseless result. PEP 238 mentions this as a > possibility, and > > >>> from __future__ import division > >>> x = 1L << 3000 > >>> x/(2*x) > -1.#IND > >>> > > really sucks. For that matter, > > >>> float(1L << 3000) > 1.#INF > >>> > > has always sucked; future division just makes it suck harder . > > Any objections to raising OverflowError here? Sounds OK to me. > Note this is a bit painful for a bogus reason: PyFloat_AsDouble returns a > double, and nothing in the codebase now checks it for a -1.0 error return > (despite that it can already produce one). So half the effort would be > repairing code currently ignoring the possibility of error. > > > Third issue: I don't see a *good* reason for the future-division > > x/(2*x) > > above not to return 0.5. long_true_divide could be made smart enough to do > that (more generally, to return a good float approximation whenever the true > result is representable as a float). Sure, but I also don't see a good reason to make this a priority. It's a "don't care" corner of the language to me. --Guido van Rossum (home page: http://www.python.org/~guido/) From gward@python.net Fri Aug 31 21:33:29 2001 From: gward@python.net (Greg Ward) Date: Fri, 31 Aug 2001 16:33:29 -0400 Subject: [Python-Dev] PEP 250 In-Reply-To: <017a01c1322c$bf558fd0$e000a8c0@thomasnotebook>; from thomas.heller@ion-tof.com on Fri, Aug 31, 2001 at 04:53:50PM +0200 References: <20010831093519.A16031@gerg.ca> <017a01c1322c$bf558fd0$e000a8c0@thomasnotebook> Message-ID: <20010831163329.A16507@gerg.ca> On 31 August 2001, Thomas Heller said: > Sure, will do it before 2.2a3. That's Sep 19, right? The sooner the better -- this is a "priority 9" patch! > Looking at the patch again, it seems sufficient to install into > lib/site-packages if sys.version >= 2.2. No fiddling with loading python > at runtime, importing distutils.sysconfig, and so on in bdist_wininst. Sure, whatever. Up to your best judgment; I've never actually looked at the C++ code that's compiled into that big blob of binary data in bdist_wininst.py. The C++ probably wouldn't mean much more to me than the binary blob does. ;-) Greg -- Greg Ward - Unix geek gward@python.net http://starship.python.net/~gward/ My opinions may have changed, but not the fact that I am right. From tim.one@home.com Fri Aug 31 22:40:18 2001 From: tim.one@home.com (Tim Peters) Date: Fri, 31 Aug 2001 17:40:18 -0400 Subject: [Python-Dev] RE: -Dwarn, long->double overflow (was RE: [Python-checkins] CVS: python/dist/src/Misc NEWS,1.219,1.220) In-Reply-To: <200108311939.PAA21883@cj20424-a.reston1.va.home.com> Message-ID: [Tim] >> I'm unclear on why we warn about classic division when a float >> or complex is involved: [Guido] > ... > This warning is intended for perusal by a tool (yet to create) that > reads the warnings and can automatically fix your code by inserting > the proper future division statements and/or replace / by //. Got it now. Thanks! Cool idea, BTW. >> I would like to add OverflowError when coercion of long to float >> yields a senseless result. > Sounds OK to me. Anyone else object? >> Third issue: I don't see a *good* reason for the future-division >> >> x/(2*x) >> >> above not to return 0.5 [when x is a large long]. > Sure, but I also don't see a good reason to make this a priority. > It's a "don't care" corner of the language to me. Then I'll leave it alone, but I can't understand this view (it's not like we can claim we're victims of the platform C or libm here -- nonsense results in such cases are on our heads, and an implementation that settles for total loss of information when 53 good bits are obviously possible is at best careless). From gstein@lyra.org Fri Aug 31 22:54:05 2001 From: gstein@lyra.org (Greg Stein) Date: Fri, 31 Aug 2001 14:54:05 -0700 Subject: [Python-Dev] Would it make sense to issue an extra alpha next week? In-Reply-To: <200108311928.PAA21836@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Aug 31, 2001 at 03:28:25PM -0400 References: <200108311928.PAA21836@cj20424-a.reston1.va.home.com> Message-ID: <20010831145405.F3654@lyra.org> +1 On Fri, Aug 31, 2001 at 03:28:25PM -0400, Guido van Rossum wrote: > When I was updating the NEWS file this morning, I realized that we've > already added a truckload of nifty stuff in the 9 days since 2.2a2 was > released: int overflows return longs, classic division warnings, > subclassing builtins, super, getset, two fixes to float literals, the > new GC API, and PyString_FromFormat[V]. > > I expect that I'll be concentrating on documentation for the > type/class unification next. While writing the first piece of > documentation, I realized that, sadly, several more advanced things > aren't available in 2.2a2 yet. > > The next alpha is planned for Sept. 19, almost three weeks off still. > > Does anybody object against the release of an extra release, 2.2a3, > around Sept. 5? We could do 2.2a4 on Sept. 19, or a week later if the > schedule gets too crowded. > > --Guido van Rossum (home page: http://www.python.org/~guido/) -- Greg Stein, http://www.lyra.org/RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4