From guido at python.org Thu Nov 1 00:02:23 2007 From: guido at python.org (Guido van Rossum) Date: Wed, 31 Oct 2007 16:02:23 -0700 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: <4729064B.80802@canterbury.ac.nz> References: <4729064B.80802@canterbury.ac.nz> Message-ID: On 10/31/07, Greg Ewing wrote: > Guido van Rossum wrote: > > @property > > def encoding(self): > > return self._encoding > > > > @propset(encoding) > > def encoding(self, value=None): > > if value is not None: > > unicode("0", value) # Test it > > self._encoding = value > > That's reasonably nice, although I'm not sure about the > name "propset" -- it sounds like a repair kit for an > aircraft. Maybe something like "setproperty" would be > better. I'm open for a naming contest. > But there's something that bothers me about the whole > propery mechanism -- there's no straightforward way for > a property accessor to call the inherited version from > a base class. Isn't there? You can just use super() ISTR, though I haven't had the need myself and don't recall the exact syntax. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From greg.ewing at canterbury.ac.nz Thu Nov 1 00:06:22 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 01 Nov 2007 12:06:22 +1300 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: <4729064B.80802@canterbury.ac.nz> Message-ID: <47290A6E.3000000@canterbury.ac.nz> Guido van Rossum wrote: > Isn't there? You can just use super() ISTR, That may work, now that I come to think about it. However, super() is not a complete solution, because it doesn't let you choose which inherited method to call in a multiple inheritance situation. -- Greg From pje at telecommunity.com Thu Nov 1 00:19:35 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 31 Oct 2007 19:19:35 -0400 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: <47290A6E.3000000@canterbury.ac.nz> References: <4729064B.80802@canterbury.ac.nz> <47290A6E.3000000@canterbury.ac.nz> Message-ID: <20071031232716.D738F3A405B@sparrow.telecommunity.com> At 12:06 PM 11/1/2007 +1300, Greg Ewing wrote: >Guido van Rossum wrote: > > Isn't there? You can just use super() ISTR, > >That may work, now that I come to think about it. > >However, super() is not a complete solution, because >it doesn't let you choose which inherited method >to call in a multiple inheritance situation. Er, TheRightBase.propname.fget(self)? From guido at python.org Thu Nov 1 00:36:42 2007 From: guido at python.org (Guido van Rossum) Date: Wed, 31 Oct 2007 16:36:42 -0700 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: <47290A6E.3000000@canterbury.ac.nz> References: <4729064B.80802@canterbury.ac.nz> <47290A6E.3000000@canterbury.ac.nz> Message-ID: On 10/31/07, Greg Ewing wrote: > Guido van Rossum wrote: > > Isn't there? You can just use super() ISTR, > > That may work, now that I come to think about it. > > However, super() is not a complete solution, because > it doesn't let you choose which inherited method > to call in a multiple inheritance situation. Yes, that's the point of super(). if you want more control, you can just get the property object out of the class you want -- super() doesn't have supernatural powers, all it does is pick the class for you. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) From python at rcn.com Thu Nov 1 00:45:05 2007 From: python at rcn.com (Raymond Hettinger) Date: Wed, 31 Oct 2007 19:45:05 -0400 (EDT) Subject: [Python-Dev] Declaring setters with getters Message-ID: <20071031194505.AAO44984@ms19.lnh.mail.rcn.net> > I'm not sure about the name "propset" ... >Maybe something like "setproperty" would be better. I think not. Saying "setproperty" has too many ambiguous mental parsings. When does "set" take place -- assigning a value to a property is different defining the property itself. Is "set" a verb so that we're talking about a property of sets/frozensets. Is "set" a completed action so that the property has been set. Let's stick with "propset" which has precedent as an svn action and serves as a short, simple mnemonic to the functionality. Also, I find that these unique words are easier to search for. I once co-owned a magazine called Know Your Boston and it was very difficult for clients to find using Google. Raymond From fdrake at acm.org Thu Nov 1 02:38:27 2007 From: fdrake at acm.org (Fred Drake) Date: Wed, 31 Oct 2007 21:38:27 -0400 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: <20071031174852.9CAB33A40A4@sparrow.telecommunity.com> <20071031185816.2A9AA3A405B@sparrow.telecommunity.com> Message-ID: On Oct 31, 2007, at 4:28 PM, Guido van Rossum wrote: > Given how rarely supporting deletions matters enough to write extra > code, we can just say that *when using @propset* your setter function > needs to have a default value for the argument or otherwise support > being called with one or two arguments. It's definitely unusual, but the logic is typically very different; conflating the method in Python doesn't really feel "right" to me. I've been using Philipp von Weitershausen's "rwproperty" quite happily: http://pypi.python.org/pypi/rwproperty/ It uses the names "getproperty", "setproperty", and "delproperty", which feel reasonable when I use them (always referenced using the module), like so: class Thing(object): @rwproperty.setproperty def attribute(self, value): # ... If I had to choose built-in names, though, I'd prefer "property", "propset", "propdel". Another possibility that seems reasonable (perhaps a bit better) would be: class Thing(object): @property def attribute(self): return 42 @property.set def attribute(self, value): self._ignored = value @property.delete def attribute(self): pass -Fred -- Fred Drake From aahz at pythoncraft.com Thu Nov 1 02:51:47 2007 From: aahz at pythoncraft.com (Aahz) Date: Wed, 31 Oct 2007 18:51:47 -0700 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: <4729064B.80802@canterbury.ac.nz> References: <4729064B.80802@canterbury.ac.nz> Message-ID: <20071101015147.GA10203@panix.com> On Thu, Nov 01, 2007, Greg Ewing wrote: > > But there's something that bothers me about the whole propery > mechanism -- there's no straightforward way for a property accessor to > call the inherited version from a base class. > > Wrapping property accessors up in decorators makes this worse. At > least when the accessors are declared as separate functions you have > a chance of grabbing an inherited one and calling it. But if they're > buried inside property descriptors with no other reference to them, > it's a lot harder to get hold of one. That's why the property delegates to a normal method. (Kudos to Martelli for the idea.) -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ "Typing is cheap. Thinking is expensive." --Roy Smith From barry at python.org Thu Nov 1 03:23:11 2007 From: barry at python.org (Barry Warsaw) Date: Wed, 31 Oct 2007 22:23:11 -0400 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: <20071031135743.AAO18248@ms19.lnh.mail.rcn.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 31, 2007, at 2:14 PM, Guido van Rossum wrote: > On 10/31/07, Raymond Hettinger wrote: >>> I'd like to make this [propset] a standard built-in, >> >> +1 -- I find this to be an attractive syntax >> >>> I'd also like to change property so that the doc >>> string defaults to the doc string of the getter. >> >> +1 -- This should also be done for classmethod, >> staticmethod, and anything else that wraps functions. > > With this level of support, it could be implemented by this afternoon! > (and backported to 2.4 within a week. ;-) I know you're joking about the backporting. Neal, no sneaking this into 2.5.2 now! :) BTW, +1 on this. I like Fred's suggestion of property.set(). - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRyk4kHEjvBPtnXfVAQJ5SQP/Z4uofrSz0L5hgHvaC5MmGlFqxO2O/i8q pZUurzbcRENCXhKSat5+qymyfOWyeO9rCgUbHq81af5tyUIDt9uo+6JxtBwVniEN Fcc3qMmjNhBi9if1Rn1S8jTG0AC3KEHuL4qZmghAY7Lz4/8jOjtQmAWubJ+LmQlE hxN+sdYqkm8= =gA2F -----END PGP SIGNATURE----- From steven.bethard at gmail.com Thu Nov 1 03:43:20 2007 From: steven.bethard at gmail.com (Steven Bethard) Date: Wed, 31 Oct 2007 20:43:20 -0600 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: <20071031174852.9CAB33A40A4@sparrow.telecommunity.com> <20071031185816.2A9AA3A405B@sparrow.telecommunity.com> Message-ID: On 10/31/07, Fred Drake wrote: > If I had to choose built-in names, though, I'd prefer "property", > "propset", "propdel". Another possibility that seems reasonable > (perhaps a bit better) would be: > > class Thing(object): > > @property > def attribute(self): > return 42 > > @property.set > def attribute(self, value): > self._ignored = value > > @property.delete > def attribute(self): > pass +1 on this spelling if possible. Though based on Guido's original recipe it might have to be written as:: @property.set(attribute) def attribute(self, value): self._ignored = value STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy From tjreedy at udel.edu Thu Nov 1 04:25:04 2007 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 31 Oct 2007 23:25:04 -0400 Subject: [Python-Dev] Declaring setters with getters References: <20071031194505.AAO44984@ms19.lnh.mail.rcn.net> Message-ID: "Raymond Hettinger" wrote in message news:20071031194505.AAO44984 at ms19.lnh.mail.rcn.net... |> I'm not sure about the name "propset" ... | >Maybe something like "setproperty" would be better. | | I think not. Saying "setproperty" has too many ambiguous mental parsings. When does "set" take place -- assigning a value to a property is different defining the property itself. Is "set" a verb so that we're talking about a property of sets/frozensets. Is "set" a completed action so that the property has been set. | | Let's stick with "propset" which has precedent as an svn action and serves as a short, simple mnemonic to the functionality. | | Also, I find that these unique words are easier to search for. I once co-owned a magazine called Know Your Boston and it was very difficult for clients to find using Google. 'propset' would have the virtue of following 'property' in the alpha listing of functions in the manual. From glyph at divmod.com Thu Nov 1 07:58:52 2007 From: glyph at divmod.com (glyph at divmod.com) Date: Thu, 01 Nov 2007 06:58:52 -0000 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: <20071031174852.9CAB33A40A4@sparrow.telecommunity.com> <20071031185816.2A9AA3A405B@sparrow.telecommunity.com> Message-ID: <20071101065852.31054.475271064.divmod.xquotient.56@joule.divmod.com> As long as we're all tossing out ideas here, my 2?. I vastly prefer this: On 02:43 am, steven.bethard at gmail.com wrote: >On 10/31/07, Fred Drake wrote: >> @property.set >> def attribute(self, value): >> self._ignored = value to this: > @property.set(attribute) > def attribute(self, value): > self._ignored = value since I don't see any additional expressive value in the latter, and it provides an opportunity to make a mistake. The decorator syntax's main value, to me, is eliminating the redundancy in: def foo(): ... foo = bar(foo) eliminating the possibility of misspelling "foo" one of those three times. and removing a lot of finger typing. The original proposal here re-introduces half of this redundancy. I think I can see why Guido did it that way - it makes the implementation a bit more obvious - but decorators are already sufficiently "magic" that I wouldn't mind a bit more to provide more convenience, in what is apparently just a convenience mechanism. And, since everyone else is sharing their personal current way of idiomatically declaring dynamic properties, here's mine; abusing the "class" statement instead of decorators: from epsilon.descriptor import attribute class Stuff(object): class foo(attribute): "you can put a docstring in the obvious place" def set(self, value): print 'set foo!' self._foo = value + 4 def get(self): return self._foo + 3 s = Stuff() s.foo = 0 print 's.foo:', s.foo I'd be glad of a standard, accepted way to do this though, since it's really just a spelling issue and it would be nice to reduce the learning curve between all the different libraries which define dynamic attributes. From duncan.booth at suttoncourtenay.org.uk Thu Nov 1 12:28:09 2007 From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth) Date: Thu, 1 Nov 2007 11:28:09 GMT Subject: [Python-Dev] Declaring setters with getters References: <20071031174852.9CAB33A40A4@sparrow.telecommunity.com> <20071031185816.2A9AA3A405B@sparrow.telecommunity.com> Message-ID: "Steven Bethard" wrote in news:d11dcfba0710311943u3f6fe4b1x12f1ee659ea51823 at mail.gmail.com: > On 10/31/07, Fred Drake wrote: >> If I had to choose built-in names, though, I'd prefer "property", >> "propset", "propdel". Another possibility that seems reasonable >> (perhaps a bit better) would be: >> >> class Thing(object): >> >> @property >> def attribute(self): >> return 42 >> >> @property.set >> def attribute(self, value): >> self._ignored = value >> >> @property.delete >> def attribute(self): >> pass > > +1 on this spelling if possible. Though based on Guido's original > recipe it might have to be written as:: > > @property.set(attribute) > def attribute(self, value): > self._ignored = value > It *can* be written as Fred suggested: see http://groups.google.co.uk/group/comp.lang.python/browse_thread/thread/b442d08c9a019a8/8a381be5edc26340 However that depends on hacking the stack frames, so the implementation probably isn't appropriate here. From guido at python.org Thu Nov 1 15:01:42 2007 From: guido at python.org (Guido van Rossum) Date: Thu, 1 Nov 2007 07:01:42 -0700 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: <20071101065852.31054.475271064.divmod.xquotient.56@joule.divmod.com> References: <20071031174852.9CAB33A40A4@sparrow.telecommunity.com> <20071031185816.2A9AA3A405B@sparrow.telecommunity.com> <20071101065852.31054.475271064.divmod.xquotient.56@joule.divmod.com> Message-ID: On 10/31/07, glyph at divmod.com wrote: > As long as we're all tossing out ideas here, my 2?. I vastly prefer > this: > > On 02:43 am, steven.bethard at gmail.com wrote: > >On 10/31/07, Fred Drake wrote: > > >> @property.set > >> def attribute(self, value): > >> self._ignored = value > > to this: > > @property.set(attribute) > > def attribute(self, value): > > self._ignored = value > > since I don't see any additional expressive value in the latter, and it > provides an opportunity to make a mistake. I was expecting this would be brought up, but that just ain't gonna happen. If you don't repeat the name, the decorator has to root around in the surrounding scope, which is fraught with peril. Solutions based on sys._getframe() have been around for years (e.g. several the Cookbook recipes) and if I had approved of that technique I would have adopted one long ago. However I don't approve of it. It has always been and will always continue to be my position that these are semantically unkosher, because it means that you can't wrap them in convenience functions or invoke them in different contexts, and that means that the semantics are hard to explain. If you really want another argument, repeating the property name actually does have an additional use case: you can have a read-only property with a corresponding read-write property whose name differs. E.g. class C(object): @property def encoding(self): return ... @propset(encoding) def encoding_rw(self, value): ... c = C() c.encoding = "ascii" # Fails c.encoding_rw = "ascii" # Works I've seen people do this in the filesystem: a read-only version that may be cached or replicated, and a separate writable version. Reading the writable version works too, of course. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From barry at python.org Thu Nov 1 18:23:26 2007 From: barry at python.org (Barry Warsaw) Date: Thu, 1 Nov 2007 13:23:26 -0400 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: <20071031174852.9CAB33A40A4@sparrow.telecommunity.com> <20071031185816.2A9AA3A405B@sparrow.telecommunity.com> <20071101065852.31054.475271064.divmod.xquotient.56@joule.divmod.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 1, 2007, at 10:01 AM, Guido van Rossum wrote: > On 10/31/07, glyph at divmod.com wrote: >> As long as we're all tossing out ideas here, my 2?. I vastly prefer >> this: >> >> On 02:43 am, steven.bethard at gmail.com wrote: >>> On 10/31/07, Fred Drake wrote: >> >>>> @property.set >>>> def attribute(self, value): >>>> self._ignored = value >> >> to this: >>> @property.set(attribute) >>> def attribute(self, value): >>> self._ignored = value >> >> since I don't see any additional expressive value in the latter, >> and it >> provides an opportunity to make a mistake. > > I was expecting this would be brought up, but that just ain't gonna > happen. If you don't repeat the name, the decorator has to root around > in the surrounding scope, which is fraught with peril. Solutions based > on sys._getframe() have been around for years (e.g. several the > Cookbook recipes) and if I had approved of that technique I would have > adopted one long ago. It's also not as if you're writing some string value the second time, so any typos in the name will be caught early on. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRyoLjnEjvBPtnXfVAQKcHAQAt8cmfJa93nVMX4/cIUTzUvke2LMhiKbj 5auo/TlymK6GMrKCLSpIOVfxMboj0tf5RqL8oS72OS6w6K+jlBiVFRZPf0NQtO1s WXsKDR/tw5B8iiTsoi8CRASsbEBetTrHIa5WqWqYbNk1sE7GNGTK4kIGoMd1txyp IdhLvYSJK7Q= =v4I7 -----END PGP SIGNATURE----- From glyph at divmod.com Thu Nov 1 18:26:52 2007 From: glyph at divmod.com (glyph at divmod.com) Date: Thu, 01 Nov 2007 17:26:52 -0000 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: <20071031174852.9CAB33A40A4@sparrow.telecommunity.com> <20071031185816.2A9AA3A405B@sparrow.telecommunity.com> <20071101065852.31054.475271064.divmod.xquotient.56@joule.divmod.com> Message-ID: <20071101172652.20560.1018917668.divmod.xquotient.27@joule.divmod.com> On 02:01 pm, guido at python.org wrote: >On 10/31/07, glyph at divmod.com wrote: >>As long as we're all tossing out ideas here, my 2?. I vastly prefer >>this: >> >> @property.set >>to this: >> > @property.set(attribute) >I don't approve of it. It has always been and will always >continue to be my position that these are semantically unkosher, >because it means that you can't wrap them in convenience functions or >invoke them in different contexts, and that means that the semantics >are hard to explain. Point taken. >If you really want another argument, repeating the property name >actually does have an additional use case: you can have a read-only >property with a corresponding read-write property whose name differs. I don't actually have this use-case, but it does make the actual semantics of the provided argument a bit clearer to me. It's not an implementation detail of fusing the properties together, it's just saying which property to get the read accessor from. This is a minor nit, as with all decorators that take an argument, it seems like it sets up a hard-to-debug error condition if you were to accidentally forget it: @property def foo(): ... @property.set def foo(): ... would leave you with 'foo' pointing at something that wasn't a descriptor at all. Is there a way to make that more debuggable? From guido at python.org Thu Nov 1 18:35:31 2007 From: guido at python.org (Guido van Rossum) Date: Thu, 1 Nov 2007 10:35:31 -0700 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: <20071101172652.20560.1018917668.divmod.xquotient.27@joule.divmod.com> References: <20071031174852.9CAB33A40A4@sparrow.telecommunity.com> <20071031185816.2A9AA3A405B@sparrow.telecommunity.com> <20071101065852.31054.475271064.divmod.xquotient.56@joule.divmod.com> <20071101172652.20560.1018917668.divmod.xquotient.27@joule.divmod.com> Message-ID: On 11/1/07, glyph at divmod.com wrote: > This is a minor nit, as with all decorators that take an argument, it > seems like it sets up a hard-to-debug error condition if you were to > accidentally forget it: > > @property > def foo(): ... > @property.set > def foo(): ... > > would leave you with 'foo' pointing at something that wasn't a > descriptor at all. Is there a way to make that more debuggable? Yes, if you remember my initial post, it contained this line: assert isinstance(prop, property) And even without that, accessing prop.fget would fail immediately; so instead of a non-functioning property, you get an exception at class definition time. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From pje at telecommunity.com Thu Nov 1 18:38:16 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 01 Nov 2007 13:38:16 -0400 Subject: [Python-Dev] Explicit frame ref? (was Re: Declaring setters with getters) In-Reply-To: References: <20071031174852.9CAB33A40A4@sparrow.telecommunity.com> <20071031185816.2A9AA3A405B@sparrow.telecommunity.com> <20071101065852.31054.475271064.divmod.xquotient.56@joule.divmod.com> Message-ID: <20071101174024.23AAB3A40AE@sparrow.telecommunity.com> At 07:01 AM 11/1/2007 -0700, Guido van Rossum wrote: >However I don't approve of it. It has always been and will always >continue to be my position that these are semantically unkosher, >because it means that you can't wrap them in convenience functions or >invoke them in different contexts, and that means that the semantics >are hard to explain. This is semi-random tangent, but what if there was a way to explicitly refer to the current frame as a function argument? Then, the implicitness that creates these problems becomes explicit, instead. As it happens, I write virtually all my frame-oriented decorators to take a 'frame' argument anyway, and only guess when it's not supplied. So, having a convenient way to pass the argument would be the only thing needed. Unfortunately, to be really useful, the name or symbol used would have to be more compact than the name or other data that you planned to get from the frame in the first place. "sys._getframe()" itself, for example, is way too long of a string. Even shortening this to something like 'here()' still seems too inconvenient, but to go any less than that invites the use of line-noise for syntax. Oh well, it was worth a try. From status at bugs.python.org Thu Nov 1 19:06:09 2007 From: status at bugs.python.org (Tracker) Date: Thu, 1 Nov 2007 18:06:09 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071101180609.09CBE78347@psf.upfronthosting.co.za> ACTIVITY SUMMARY (10/25/07 - 11/01/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1314 open (+21) / 11538 closed (+22) / 12852 total (+43) Open issues with patches: 415 Average duration of open issues: 683 days. Median duration of open issues: 773 days. Open Issues Breakdown open 1310 (+21) pending 4 ( +0) Issues Created Or Reopened (43) _______________________________ Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmcl 10/25/07 http://bugs.python.org/issue1327 created eanxgeek feature request: force BOM option 10/25/07 http://bugs.python.org/issue1328 created jgsack Different 3.0a1 exit behavior 10/25/07 CLOSED http://bugs.python.org/issue1329 created MrJean1 Fix truncate on Windows, this time for real 10/26/07 CLOSED http://bugs.python.org/issue1330 created tiran py3k, patch More fixes for Windows 10/26/07 CLOSED http://bugs.python.org/issue1331 created tiran py3k, patch threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi 10/26/07 http://bugs.python.org/issue1332 created delwarl merge urllib and urlparse functionality 10/26/07 http://bugs.python.org/issue1333 created techtonik IDLE - Fix several highlighting bugs 10/26/07 http://bugs.python.org/issue1334 created taleinat patch bytesiterator patch 10/26/07 CLOSED http://bugs.python.org/issue1335 created tiran subprocess.Popen hangs when child writes to stderr 10/26/07 http://bugs.python.org/issue1336 created jba Tools/msi/msi.py does not work with PCBuild8 10/26/07 http://bugs.python.org/issue1337 created kevinwatters pickling bytes? 10/26/07 http://bugs.python.org/issue1338 created gvanrossum py3k smtplib starttls() should ehlo() if it needs to 10/26/07 http://bugs.python.org/issue1339 created fenner correction for test_tempfile in py3k on Windows 10/28/07 CLOSED http://bugs.python.org/issue1340 reopened gvanrossum correction for test_fileinput in py3k on Windows 10/26/07 CLOSED http://bugs.python.org/issue1341 created amaury.forgeotdarc patch Crash on Windows if Python runs from a directory with umlauts 10/27/07 http://bugs.python.org/issue1342 created tiran XMLGenerator: nice elements 10/27/07 http://bugs.python.org/issue1343 created panzi subprocess.communication doc could use clarification 10/27/07 http://bugs.python.org/issue1344 created dsturtevant Fix for test_netrc on Windows 10/27/07 http://bugs.python.org/issue1345 created tiran patch Error using >>> from OpenGL.GLUT import * 10/27/07 CLOSED http://bugs.python.org/issue1346 created neuralsensor BaseHTTPServer writing strings to bytes interface 10/28/07 CLOSED http://bugs.python.org/issue1347 created janssen py3k, patch httplib closes socket, then tries to read from it 10/28/07 http://bugs.python.org/issue1348 created janssen py3k, patch more uses of ord() in plat-mac/ic.py 10/28/07 CLOSED http://bugs.python.org/issue1349 created janssen py3k, patch IDLE - CallTips enhancement - show full doc-string in new window 10/28/07 http://bugs.python.org/issue1350 created taleinat patch Add getsize() to io instances 10/28/07 http://bugs.python.org/issue1351 created tiran Preliminary stderr patch 10/28/07 CLOSED http://bugs.python.org/issue1352 created tiran mp4 missing from mimetypes.py 10/29/07 CLOSED http://bugs.python.org/issue1353 created kraft windows installer problem 10/29/07 http://bugs.python.org/issue1354 created rajar xml.dom refers to PyXML, which is no longer maintained 10/29/07 http://bugs.python.org/issue1355 created whooey1830 3.0a1 Solaris w/ SUN C/C++ 10/29/07 CLOSED http://bugs.python.org/issue1356 created MrJean1 3.0a1 make test Error on Solaris w/ SUN C/C++ 10/29/07 CLOSED http://bugs.python.org/issue1357 created MrJean1 Compile error on OS X 10.5 10/29/07 http://bugs.python.org/issue1358 created andres py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape 10/29/07 CLOSED http://bugs.python.org/issue1359 reopened gvanrossum Queue.get() can't be interrupted with Ctrl-C unless timed out 10/30/07 CLOSED http://bugs.python.org/issue1360 created piro please close: hashlib uses OpenSSL which is much slower than Aar 10/30/07 CLOSED http://bugs.python.org/issue1361 created Omnifarious Simple mistake in http://docs.python.org/tut/node6.html 10/30/07 CLOSED http://bugs.python.org/issue1362 created dmazz python 2.4.4 fails on solaris (sun4u sparc SUNW,Sun-Fire-880) 10/30/07 http://bugs.python.org/issue1363 created theoryno3 os.lstat documentation error 10/31/07 CLOSED http://bugs.python.org/issue1364 created billiejoex bytes() constructor 10/31/07 CLOSED http://bugs.python.org/issue1365 created tiran popen spawned process may not write to stdout under windows 10/31/07 http://bugs.python.org/issue1366 created pmezard mkdir+chdir problem in multiple threads 10/31/07 CLOSED http://bugs.python.org/issue1367 created anonyprog Bug tracker link in about tutorial page is wrong 11/01/07 CLOSED http://bugs.python.org/issue1368 created ksjohnson Reference to Python24 path in Python 2.5 doc 11/01/07 CLOSED http://bugs.python.org/issue1369 created ksjohnson Issues Now Closed (37) ______________________ PEP 3137 patch (repr, names, parser) 23 days http://bugs.python.org/issue1247 gvanrossum patch Strange Python hangup 16 days http://bugs.python.org/issue1255 kakacek IDLE does not start if windows environment variable containing ' 17 days http://bugs.python.org/issue1262 kbk os.environ.pop doesn't work 10 days http://bugs.python.org/issue1287 georg.brandl Fixes for profile/cprofile 6 days http://bugs.python.org/issue1302 tiran py3k, patch Remove os.tmpnam() and os.tempnam() 2 days http://bugs.python.org/issue1318 gvanrossum patch py3k: file.truncate() changes the file position 1 days http://bugs.python.org/issue1323 gvanrossum patch r58034 breaks building _ctypes with the upstream libffi. 1 days http://bugs.python.org/issue1324 theller patch Different 3.0a1 exit behavior 5 days http://bugs.python.org/issue1329 gvanrossum Fix truncate on Windows, this time for real 1 days http://bugs.python.org/issue1330 gvanrossum py3k, patch More fixes for Windows 0 days http://bugs.python.org/issue1331 gvanrossum py3k, patch bytesiterator patch 0 days http://bugs.python.org/issue1335 gvanrossum correction for test_tempfile in py3k on Windows 1 days http://bugs.python.org/issue1340 gvanrossum correction for test_fileinput in py3k on Windows 3 days http://bugs.python.org/issue1341 gvanrossum patch Error using >>> from OpenGL.GLUT import * 3 days http://bugs.python.org/issue1346 nnorwitz BaseHTTPServer writing strings to bytes interface 3 days http://bugs.python.org/issue1347 janssen py3k, patch more uses of ord() in plat-mac/ic.py 3 days http://bugs.python.org/issue1349 janssen py3k, patch Preliminary stderr patch 4 days http://bugs.python.org/issue1352 georg.brandl mp4 missing from mimetypes.py 0 days http://bugs.python.org/issue1353 gvanrossum 3.0a1 Solaris w/ SUN C/C++ 0 days http://bugs.python.org/issue1356 gvanrossum 3.0a1 make test Error on Solaris w/ SUN C/C++ 0 days http://bugs.python.org/issue1357 gvanrossum py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape 0 days http://bugs.python.org/issue1359 gvanrossum Queue.get() can't be interrupted with Ctrl-C unless timed out 0 days http://bugs.python.org/issue1360 piro please close: hashlib uses OpenSSL which is much slower than Aar 0 days http://bugs.python.org/issue1361 facundobatista Simple mistake in http://docs.python.org/tut/node6.html 1 days http://bugs.python.org/issue1362 georg.brandl os.lstat documentation error 2 days http://bugs.python.org/issue1364 billiejoex bytes() constructor 0 days http://bugs.python.org/issue1365 gvanrossum mkdir+chdir problem in multiple threads 1 days http://bugs.python.org/issue1367 gvanrossum Bug tracker link in about tutorial page is wrong 0 days http://bugs.python.org/issue1368 georg.brandl Reference to Python24 path in Python 2.5 doc 0 days http://bugs.python.org/issue1369 georg.brandl Logic Variable Thread Synchronization 1630 days http://bugs.python.org/issue738948 georg.brandl threading.Thread.join() cannot be interrupted by a Ctrl-C 952 days http://bugs.python.org/issue1167930 gvanrossum Ctrl+C for copy does not work when caps-lock is on 713 days http://bugs.python.org/issue1356720 kbk Module uuid: reduce pickle footprint 486 days http://bugs.python.org/issue1516327 gvanrossum patch Module uuid: functions for retrieving MAC addres 486 days http://bugs.python.org/issue1516330 gvanrossum patch "Really print?" Dialog 170 days http://bugs.python.org/issue1717170 taleinat patch Errors in site.py not reported properly 82 days http://bugs.python.org/issue1771260 gvanrossum py3k Top Issues Most Discussed (10) ______________________________ 38 Different 3.0a1 exit behavior 5 days closed http://bugs.python.org/issue1329 12 threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi 7 days open http://bugs.python.org/issue1332 8 platform.dist() has unpredictable result under Linux 8 days open http://bugs.python.org/issue1322 7 IDLE - patch Delegator to support callables 23 days open http://bugs.python.org/issue1252 6 Enhanced tabbed pane widget 326 days open http://bugs.python.org/issue1612746 6 Preliminary stderr patch 4 days closed http://bugs.python.org/issue1352 6 feature request: force BOM option 7 days open http://bugs.python.org/issue1328 5 Compile error on OS X 10.5 3 days open http://bugs.python.org/issue1358 5 3.0a1 make test Error on Solaris w/ SUN C/C++ 0 days closed http://bugs.python.org/issue1357 5 correction for test_tempfile in py3k on Windows 1 days closed http://bugs.python.org/issue1340 From facundobatista at gmail.com Thu Nov 1 19:09:56 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Thu, 1 Nov 2007 15:09:56 -0300 Subject: [Python-Dev] None in arguments to "".find and family of functions Message-ID: Hello people! I'm following the issue 1259 (http://bugs.python.org/issue1259) It basically says that this should be ok: "'asd'.find('s', None, None)", as the documentation says that "start" and "end" arguments behaves like in slices (right now it gives a TypeError). I created a patch, that solves the problem presented in that patch, as is suggested by Barry A. Warsaw. The patch touches three files: - Lib/test/string_tests.py: The test cases for this. - Objects/stringobject.c: Here I modified the string_find_internal() function, for PyArg_ParseTuple to not call directly to PyEval_SliceIndex: I just call it if the function received an argument and is not None. - Objects/unicodeobject.c: Here I needed to make the same in unicode_find(), unicode_rfind(), unicode_index(), and unicode_rindex(), so I created another function called _ParseTupleFinds(), for this family of functions, which handles the arguments and returns the needed info for each function. All the tests pass ok, I'm sending this mail to see if anybody could please review the patch before I apply it, as this is the first patch that I create in C. Feel free to ignore this mail if the patch is ok, :) Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From tony at PageDNA.com Thu Nov 1 19:26:52 2007 From: tony at PageDNA.com (Tony Lownds) Date: Thu, 1 Nov 2007 11:26:52 -0700 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: <20071101172652.20560.1018917668.divmod.xquotient.27@joule.divmod.com> References: <20071031174852.9CAB33A40A4@sparrow.telecommunity.com> <20071031185816.2A9AA3A405B@sparrow.telecommunity.com> <20071101065852.31054.475271064.divmod.xquotient.56@joule.divmod.com> <20071101172652.20560.1018917668.divmod.xquotient.27@joule.divmod.com> Message-ID: <8C10DB18-8227-4A22-A426-232A324F211F@PageDNA.com> On Nov 1, 2007, at 10:26 AM, glyph at divmod.com wrote: > This is a minor nit, as with all decorators that take an argument, > it seems like it sets up a hard-to-debug error condition if you were > to accidentally forget it: > > @property > def foo(): ... > @property.set > def foo(): ... > > would leave you with 'foo' pointing at something that wasn't a > descriptor at all. Is there a way to make that more debuggable? How about this: give the property instance a method that changes a property from read-only to read-write. No parens, no frame magic. As a small bonus, the setter function would not have to be named the same as the property. class A(object): @property def foo(self): return 1 @foo.setter def set_foo(self, value): print 'set:', value -Tony From facundobatista at gmail.com Thu Nov 1 20:13:26 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Thu, 1 Nov 2007 16:13:26 -0300 Subject: [Python-Dev] Python tickets summary In-Reply-To: <4720E7FF.7080404@ronadam.com> References: <46F1B6FD.70007@ronadam.com> <471F7881.1070605@ronadam.com> <4720E7FF.7080404@ronadam.com> Message-ID: 2007/10/25, Ron Adam : > Clicking on one of the filter links changes the title back. (No Keyword, > Patch, P3K) Fixed, this was a bug, :( > I think the keyword and keywords interface can be improved. Do you have > any plans in that direction? Surely! But, no, I have no plans to do it, as I can not make cgi scripts in my hosting, so these pages are statics, generated every night, and that's all... > How do you get the data the page is built from? Parsing the results of http://bugs.python.org/ Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From guido at python.org Thu Nov 1 20:17:22 2007 From: guido at python.org (Guido van Rossum) Date: Thu, 1 Nov 2007 12:17:22 -0700 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: <8C10DB18-8227-4A22-A426-232A324F211F@PageDNA.com> References: <20071031185816.2A9AA3A405B@sparrow.telecommunity.com> <20071101065852.31054.475271064.divmod.xquotient.56@joule.divmod.com> <20071101172652.20560.1018917668.divmod.xquotient.27@joule.divmod.com> <8C10DB18-8227-4A22-A426-232A324F211F@PageDNA.com> Message-ID: -1. Looks like more magic, not less, to me. On 11/1/07, Tony Lownds wrote: > > On Nov 1, 2007, at 10:26 AM, glyph at divmod.com wrote: > > This is a minor nit, as with all decorators that take an argument, > > it seems like it sets up a hard-to-debug error condition if you were > > to accidentally forget it: > > > > @property > > def foo(): ... > > @property.set > > def foo(): ... > > > > would leave you with 'foo' pointing at something that wasn't a > > descriptor at all. Is there a way to make that more debuggable? > > How about this: give the property instance a method that changes a > property from read-only to read-write. > No parens, no frame magic. As a small bonus, the setter function would > not have to be named the same as the > property. > > class A(object): > @property > def foo(self): > return 1 > > @foo.setter > def set_foo(self, value): > print 'set:', value > > -Tony > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From greg.ewing at canterbury.ac.nz Thu Nov 1 23:01:55 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 02 Nov 2007 11:01:55 +1300 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: <4729064B.80802@canterbury.ac.nz> <47290A6E.3000000@canterbury.ac.nz> Message-ID: <472A4CD3.5020503@canterbury.ac.nz> Guido van Rossum wrote: > if you want more control, you can just get the property object out of > the class you want You're quite right. I was thinking that getting the property would trigger the access machinery, but of course you're getting it from the class rather than the instance, so that doesn't happen. -- Greg From greg.ewing at canterbury.ac.nz Thu Nov 1 23:10:20 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 02 Nov 2007 11:10:20 +1300 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: <20071031174852.9CAB33A40A4@sparrow.telecommunity.com> <20071031185816.2A9AA3A405B@sparrow.telecommunity.com> Message-ID: <472A4ECC.8030009@canterbury.ac.nz> Fred Drake wrote: > @property > def attribute(self): > return 42 > > @property.set > def attribute(self, value): > self._ignored = value Hmmm... if you were allowed general lvalues as the target of a def, you could write that as def attribute.set(self, value): ... -- Greg From greg.ewing at canterbury.ac.nz Thu Nov 1 23:11:48 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 02 Nov 2007 11:11:48 +1300 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: <20071031194505.AAO44984@ms19.lnh.mail.rcn.net> References: <20071031194505.AAO44984@ms19.lnh.mail.rcn.net> Message-ID: <472A4F24.9090404@canterbury.ac.nz> Raymond Hettinger wrote: > Let's stick with "propset" which has precedent as an svn action and > serves as a short, simple mnemonic to the functionality. But if we're going to have "propset", it raises the question of why there isn't a "propget". -- Greg From pje at telecommunity.com Fri Nov 2 00:00:06 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 01 Nov 2007 19:00:06 -0400 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: <472A4F24.9090404@canterbury.ac.nz> References: <20071031194505.AAO44984@ms19.lnh.mail.rcn.net> <472A4F24.9090404@canterbury.ac.nz> Message-ID: <20071101225721.C38623A40AC@sparrow.telecommunity.com> At 11:11 AM 11/2/2007 +1300, Greg Ewing wrote: >Raymond Hettinger wrote: > > Let's stick with "propset" which has precedent as an svn action and > > serves as a short, simple mnemonic to the functionality. > >But if we're going to have "propset", it raises the question >of why there isn't a "propget". Which can be eliminated by having property.setter, especially in the form: @property def foo(self): ... @foo.setter def foo(self, value): ... @foo.deleter def foo(self): ... This even preserves Guido's "read-only + read-write" use case, and saves us a builtin. From guido at python.org Fri Nov 2 01:39:34 2007 From: guido at python.org (Guido van Rossum) Date: Thu, 1 Nov 2007 17:39:34 -0700 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: <20071101225721.C38623A40AC@sparrow.telecommunity.com> References: <20071031194505.AAO44984@ms19.lnh.mail.rcn.net> <472A4F24.9090404@canterbury.ac.nz> <20071101225721.C38623A40AC@sparrow.telecommunity.com> Message-ID: On 11/1/07, Phillip J. Eby wrote: > At 11:11 AM 11/2/2007 +1300, Greg Ewing wrote: > >Raymond Hettinger wrote: > > > Let's stick with "propset" which has precedent as an svn action and > > > serves as a short, simple mnemonic to the functionality. > > > >But if we're going to have "propset", it raises the question > >of why there isn't a "propget". > > Which can be eliminated by having property.setter, especially in the form: > > @property > def foo(self): > ... > > @foo.setter > def foo(self, value): > ... > > @foo.deleter > def foo(self): > ... > > This even preserves Guido's "read-only + read-write" use case, and > saves us a builtin. Although it begs the question what happened to @foo.getter. I'm only +0 on this -- I can't quite pinpoint what's wrong with it but it doesn't fell 100% right. Maybe I just need to sleep on it. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at acm.org Fri Nov 2 02:18:52 2007 From: fdrake at acm.org (Fred Drake) Date: Thu, 1 Nov 2007 21:18:52 -0400 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: <20071031135743.AAO18248@ms19.lnh.mail.rcn.net> Message-ID: <39985474-4A9C-4226-B7F3-920AEB49A154@acm.org> On Oct 31, 2007, at 10:23 PM, Barry Warsaw wrote: > BTW, +1 on this. I like Fred's suggestion of property.set(). Thanks! Of all the proposals that have been presented, I still like that the best. Guido's use case of wanting to give the r/w property a different name than the r/o property is a good one, though I've not run across it myself. I'd be satisfied with passing in the origin property, though I'd want to be able to do that for the get method as well as the set and delete methods. That would better support being able to extend a property in a derived class. For example: class Base(object): @property def attribute(self): return 42 class Derived(Base): @property.get(Base.__dict__["attribute"]) def attribute(self): self.do_something() return super(Derived, self).attribute What I don't like is the difficulty of getting the raw descriptor from the base class. It would be good to be able to say: class Derived(Base): @property.get(Base.attribute) def attribute(self): self.do_something() return super(Derived, self).attribute I doubt that's all that hard to achieve, at least for a known property type. To support descriptors of completely different types, the syntax from the first example may be required unless some other crutch is added. -Fred -- Fred Drake From skip at pobox.com Fri Nov 2 02:53:55 2007 From: skip at pobox.com (skip at pobox.com) Date: Thu, 1 Nov 2007 20:53:55 -0500 Subject: [Python-Dev] Does Python need a file locking module (slightly higher level)? In-Reply-To: References: <18204.38001.562050.157197@montanaro.dyndns.org> <2C9CF122-7954-434C-BFCA-CB5AC0B229F3@python.org> <18205.27378.432540.931896@montanaro.dyndns.org> <95064092-825F-4D3E-A2D4-6309248A6247@python.org> <18210.18858.361196.95168@montanaro.dyndns.org> Message-ID: <18218.33587.350511.718472@montanaro.dyndns.org> > The API and almost all test cases are defined in a _FileLock base > class. You could (in theory at least) subclass it to provide locking > through some other shared resource like a database and not have to > write and or many other test cases. Okay, this is up on my website: http://www.webfast.com/~skip/python/ It took me a little longer to implement than I thought because I decided to implement an SQLite-based _FileLock subclass, mostly as a proof-of-concept. I'm still waiting for the name "lockfile" to free up in PyPI to put it there. Skip From fdrake at acm.org Fri Nov 2 03:53:56 2007 From: fdrake at acm.org (Fred Drake) Date: Thu, 1 Nov 2007 22:53:56 -0400 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: <39985474-4A9C-4226-B7F3-920AEB49A154@acm.org> References: <20071031135743.AAO18248@ms19.lnh.mail.rcn.net> <39985474-4A9C-4226-B7F3-920AEB49A154@acm.org> Message-ID: <38445525-06FF-499E-986A-A417C1895218@acm.org> On Nov 1, 2007, at 9:18 PM, Fred Drake wrote: > Thanks! Of all the proposals that have been presented, I still like > that the best. I've attached a quick hack of an implementation, just to play with it and see how it feels. Here's an example use: from property import property class Base(object): @property def attribute(self): print("Base.attribute (getter)") return 42 @property.get(attribute) def rwattribute(self): print("Base.rwattribute (getter)") return self.attribute * 2 @property.set(rwattribute) def rwattribute(self, value): print("Base.rwattribute (setter)") self.saved = value class Derived(Base): @property.get(Base.attribute) def roattribute(self): print("Derived.roattribute (getter)") return self.attribute / 2 -Fred -- Fred Drake -------------- next part -------------- A non-text attachment was scrubbed... Name: property.py Type: text/x-python-script Size: 863 bytes Desc: not available Url : http://mail.python.org/pipermail/python-dev/attachments/20071101/70cb9f1c/attachment.bin -------------- next part -------------- From ncoghlan at gmail.com Fri Nov 2 11:23:58 2007 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 02 Nov 2007 20:23:58 +1000 Subject: [Python-Dev] Request for inclusion in 2.5.2 (5-for-1) In-Reply-To: <19C5D86A-8534-4DB7-934C-CEE94003BB79@gmail.com> References: <19C5D86A-8534-4DB7-934C-CEE94003BB79@gmail.com> Message-ID: <472AFABE.1070900@gmail.com> Mike Klaas wrote: > http://bugs.python.org/issue1705170: reproduced. Conjecture as to > why it is occurring, but I don't know the guts well enough to propose > a decent fix. I've fixed this on the trunk (I'm afraid I have no opinion on the patch you're interested in though. Neal - where does the 2.5 branch stand at the moment? This would be a simple fix to slip into 2.5.2 if there's still time. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From duncan.booth at suttoncourtenay.org.uk Fri Nov 2 11:22:13 2007 From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth) Date: Fri, 2 Nov 2007 10:22:13 +0000 (UTC) Subject: [Python-Dev] Declaring setters with getters References: <20071031174852.9CAB33A40A4@sparrow.telecommunity.com> <20071031185816.2A9AA3A405B@sparrow.telecommunity.com> <472A4ECC.8030009@canterbury.ac.nz> Message-ID: Greg Ewing wrote: > Fred Drake wrote: >> @property >> def attribute(self): >> return 42 >> >> @property.set >> def attribute(self, value): >> self._ignored = value > > Hmmm... if you were allowed general lvalues as the target of a > def, you could write that as > > def attribute.set(self, value): > ... > Dotted names would be sufficient rather than general lvalues. I like this, I think it looks cleaner than the other options, especially if you write both getter and setter in the same style: attribute = property() def attribute.fget(self): return 42 def attribute.fset(self, value): self._ignored = value From guido at python.org Fri Nov 2 14:57:49 2007 From: guido at python.org (Guido van Rossum) Date: Fri, 2 Nov 2007 06:57:49 -0700 Subject: [Python-Dev] Request for inclusion in 2.5.2 (5-for-1) In-Reply-To: <19C5D86A-8534-4DB7-934C-CEE94003BB79@gmail.com> References: <19C5D86A-8534-4DB7-934C-CEE94003BB79@gmail.com> Message-ID: On 10/31/07, Mike Klaas wrote: > Issue http://bugs.python.org/issue1663329 details an annoyance in the > subprocess module that has affected several users, including me. > Essentially, closing hundreds of thousands of file descriptors by > round-tripping through the python exception machinery is very slow, > taking hundreds of milliseconds and at times many seconds. The > proposed fix is to write this loop in c. The c function is but a > handful of lines long. I purposefully kept the implementation > trivial so that it will work on all unix variants (there is another > issue that contains a super-duper optimization for AIX, and other > possibilities exist for Solaris, but the simple fix yields a ten-fold > speedup everywhere but windows, so I didn't think that it was worth > the complexity). > > Though technically relating only to performance, I consider this a > bug-fix candidate as mysterious multi-second delays when launching a > subprocess end up making the functionality of close_fds unusable on > some platform configurations (namely, those with high MAX_FD set). > > It would be great to see this is 2.5.2. Understanding that issue > evaluation takes significant effort, I've done some evaluation/triage > on other open tickets: Thanks for doing these! Since people are already jumping on those bugs but nobody has voiced an opinion on your own patch, let me say that I think it's a good patch, and I want it in 2.6, but I'm reluctant to add it to 2.5.2 as it goes well beyond a bugfix (adding a new C API and all that). -- --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Fri Nov 2 15:19:10 2007 From: guido at python.org (Guido van Rossum) Date: Fri, 2 Nov 2007 07:19:10 -0700 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: <20071031174852.9CAB33A40A4@sparrow.telecommunity.com> <20071031185816.2A9AA3A405B@sparrow.telecommunity.com> <472A4ECC.8030009@canterbury.ac.nz> Message-ID: On 11/2/07, Duncan Booth wrote: > Greg Ewing wrote: > > > Fred Drake wrote: > >> @property > >> def attribute(self): > >> return 42 > >> > >> @property.set > >> def attribute(self, value): > >> self._ignored = value > > > > Hmmm... if you were allowed general lvalues as the target of a > > def, you could write that as > > > > def attribute.set(self, value): > > ... > > > Dotted names would be sufficient rather than general lvalues. > > I like this, I think it looks cleaner than the other options, especially if > you write both getter and setter in the same style: > > attribute = property() > > def attribute.fget(self): > return 42 > > def attribute.fset(self, value): > self._ignored = value Sorry, you have just entered Python 4000 territory. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From status at bugs.python.org Fri Nov 2 19:06:08 2007 From: status at bugs.python.org (Tracker) Date: Fri, 2 Nov 2007 18:06:08 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071102180608.B5D7E7833F@psf.upfronthosting.co.za> ACTIVITY SUMMARY (10/26/07 - 11/02/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1315 open (+15) / 11541 closed (+21) / 12856 total (+36) Open issues with patches: 417 Average duration of open issues: 683 days. Median duration of open issues: 775 days. Open Issues Breakdown open 1311 (+15) pending 4 ( +0) Issues Created Or Reopened (36) _______________________________ pickling bytes? 10/26/07 http://bugs.python.org/issue1338 created gvanrossum py3k smtplib starttls() should ehlo() if it needs to 10/26/07 http://bugs.python.org/issue1339 created fenner correction for test_tempfile in py3k on Windows 10/28/07 CLOSED http://bugs.python.org/issue1340 reopened gvanrossum correction for test_fileinput in py3k on Windows 10/26/07 CLOSED http://bugs.python.org/issue1341 created amaury.forgeotdarc patch Crash on Windows if Python runs from a directory with umlauts 10/27/07 http://bugs.python.org/issue1342 created tiran XMLGenerator: nice elements 10/27/07 http://bugs.python.org/issue1343 created panzi subprocess.communication doc could use clarification 10/27/07 http://bugs.python.org/issue1344 created dsturtevant Fix for test_netrc on Windows 10/27/07 http://bugs.python.org/issue1345 created tiran patch Error using >>> from OpenGL.GLUT import * 10/27/07 CLOSED http://bugs.python.org/issue1346 created neuralsensor BaseHTTPServer writing strings to bytes interface 10/28/07 CLOSED http://bugs.python.org/issue1347 created janssen py3k, patch httplib closes socket, then tries to read from it 10/28/07 http://bugs.python.org/issue1348 created janssen py3k, patch more uses of ord() in plat-mac/ic.py 10/28/07 CLOSED http://bugs.python.org/issue1349 created janssen py3k, patch IDLE - CallTips enhancement - show full doc-string in new window 10/28/07 http://bugs.python.org/issue1350 created taleinat patch Add getsize() to io instances 10/28/07 http://bugs.python.org/issue1351 created tiran Preliminary stderr patch 10/28/07 CLOSED http://bugs.python.org/issue1352 created tiran mp4 missing from mimetypes.py 10/29/07 CLOSED http://bugs.python.org/issue1353 created kraft windows installer problem 10/29/07 http://bugs.python.org/issue1354 created rajar xml.dom refers to PyXML, which is no longer maintained 10/29/07 http://bugs.python.org/issue1355 created whooey1830 3.0a1 Solaris w/ SUN C/C++ 10/29/07 CLOSED http://bugs.python.org/issue1356 created MrJean1 3.0a1 make test Error on Solaris w/ SUN C/C++ 10/29/07 CLOSED http://bugs.python.org/issue1357 created MrJean1 Compile error on OS X 10.5 10/29/07 http://bugs.python.org/issue1358 created andres py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape 10/29/07 CLOSED http://bugs.python.org/issue1359 reopened gvanrossum Queue.get() can't be interrupted with Ctrl-C unless timed out 10/30/07 CLOSED http://bugs.python.org/issue1360 created piro please close: hashlib uses OpenSSL which is much slower than Aar 10/30/07 CLOSED http://bugs.python.org/issue1361 created Omnifarious Simple mistake in http://docs.python.org/tut/node6.html 10/30/07 CLOSED http://bugs.python.org/issue1362 created dmazz python 2.4.4 fails on solaris (sun4u sparc SUNW,Sun-Fire-880) 10/30/07 http://bugs.python.org/issue1363 created theoryno3 os.lstat documentation error 10/31/07 CLOSED http://bugs.python.org/issue1364 created billiejoex bytes() constructor 10/31/07 CLOSED http://bugs.python.org/issue1365 created tiran popen spawned process may not write to stdout under windows 10/31/07 http://bugs.python.org/issue1366 created pmezard mkdir+chdir problem in multiple threads 10/31/07 CLOSED http://bugs.python.org/issue1367 created anonyprog Bug tracker link in about tutorial page is wrong 11/01/07 CLOSED http://bugs.python.org/issue1368 created ksjohnson Reference to Python24 path in Python 2.5 doc 11/01/07 CLOSED http://bugs.python.org/issue1369 created ksjohnson Doc changes left over after mega-merge from trunk 11/01/07 CLOSED http://bugs.python.org/issue1370 created gvanrossum Two bsddb tests temporarily commented out in py3k branch 11/01/07 CLOSED http://bugs.python.org/issue1371 created gvanrossum py3k zlibmodule.c: int overflow in PyZlib_decompress 11/02/07 http://bugs.python.org/issue1372 created PeterW patch turn off socket timeout in test_xmlrpc 11/02/07 CLOSED http://bugs.python.org/issue1373 created hupp py3k, patch Issues Now Closed (32) ______________________ PEP 3137 patch (repr, names, parser) 23 days http://bugs.python.org/issue1247 gvanrossum patch IDLE does not start if windows environment variable containing ' 17 days http://bugs.python.org/issue1262 kbk os.environ.pop doesn't work 10 days http://bugs.python.org/issue1287 georg.brandl Different 3.0a1 exit behavior 5 days http://bugs.python.org/issue1329 gvanrossum correction for test_tempfile in py3k on Windows 1 days http://bugs.python.org/issue1340 gvanrossum correction for test_fileinput in py3k on Windows 3 days http://bugs.python.org/issue1341 gvanrossum patch Error using >>> from OpenGL.GLUT import * 3 days http://bugs.python.org/issue1346 nnorwitz BaseHTTPServer writing strings to bytes interface 3 days http://bugs.python.org/issue1347 janssen py3k, patch more uses of ord() in plat-mac/ic.py 3 days http://bugs.python.org/issue1349 janssen py3k, patch Preliminary stderr patch 4 days http://bugs.python.org/issue1352 gvanrossum mp4 missing from mimetypes.py 0 days http://bugs.python.org/issue1353 gvanrossum 3.0a1 Solaris w/ SUN C/C++ 0 days http://bugs.python.org/issue1356 gvanrossum 3.0a1 make test Error on Solaris w/ SUN C/C++ 0 days http://bugs.python.org/issue1357 gvanrossum py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape 0 days http://bugs.python.org/issue1359 gvanrossum Queue.get() can't be interrupted with Ctrl-C unless timed out 0 days http://bugs.python.org/issue1360 piro please close: hashlib uses OpenSSL which is much slower than Aar 0 days http://bugs.python.org/issue1361 facundobatista Simple mistake in http://docs.python.org/tut/node6.html 1 days http://bugs.python.org/issue1362 georg.brandl os.lstat documentation error 2 days http://bugs.python.org/issue1364 billiejoex bytes() constructor 0 days http://bugs.python.org/issue1365 gvanrossum mkdir+chdir problem in multiple threads 1 days http://bugs.python.org/issue1367 gvanrossum Bug tracker link in about tutorial page is wrong 0 days http://bugs.python.org/issue1368 georg.brandl Reference to Python24 path in Python 2.5 doc 0 days http://bugs.python.org/issue1369 georg.brandl Doc changes left over after mega-merge from trunk 0 days http://bugs.python.org/issue1370 gvanrossum Two bsddb tests temporarily commented out in py3k branch 0 days http://bugs.python.org/issue1371 gregory.p.smith py3k turn off socket timeout in test_xmlrpc 0 days http://bugs.python.org/issue1373 gvanrossum py3k, patch Logic Variable Thread Synchronization 1630 days http://bugs.python.org/issue738948 georg.brandl threading.Thread.join() cannot be interrupted by a Ctrl-C 952 days http://bugs.python.org/issue1167930 gvanrossum Ctrl+C for copy does not work when caps-lock is on 713 days http://bugs.python.org/issue1356720 kbk Module uuid: reduce pickle footprint 486 days http://bugs.python.org/issue1516327 gvanrossum patch Module uuid: functions for retrieving MAC addres 486 days http://bugs.python.org/issue1516330 gvanrossum patch "Really print?" Dialog 170 days http://bugs.python.org/issue1717170 taleinat patch Errors in site.py not reported properly 82 days http://bugs.python.org/issue1771260 gvanrossum py3k Top Issues Most Discussed (10) ______________________________ 33 Different 3.0a1 exit behavior 5 days closed http://bugs.python.org/issue1329 10 threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi 8 days open http://bugs.python.org/issue1332 7 Preliminary stderr patch 4 days closed http://bugs.python.org/issue1352 6 Enhanced tabbed pane widget 327 days open http://bugs.python.org/issue1612746 6 feature request: force BOM option 8 days open http://bugs.python.org/issue1328 6 IDLE - patch Delegator to support callables 24 days open http://bugs.python.org/issue1252 5 datetime module missing some important methods 243 days open http://bugs.python.org/issue1673409 5 Doc changes left over after mega-merge from trunk 0 days closed http://bugs.python.org/issue1370 5 Compile error on OS X 10.5 4 days open http://bugs.python.org/issue1358 5 3.0a1 make test Error on Solaris w/ SUN C/C++ 0 days closed http://bugs.python.org/issue1357 From mike.klaas at gmail.com Fri Nov 2 19:07:53 2007 From: mike.klaas at gmail.com (Mike Klaas) Date: Fri, 2 Nov 2007 11:07:53 -0700 Subject: [Python-Dev] Request for inclusion in 2.5.2 (5-for-1) In-Reply-To: References: <19C5D86A-8534-4DB7-934C-CEE94003BB79@gmail.com> Message-ID: On 2-Nov-07, at 6:57 AM, Guido van Rossum wrote: > > Since people are already jumping on those bugs but nobody has voiced > an opinion on your own patch, let me say that I think it's a good > patch, and I want it in 2.6, but I'm reluctant to add it to 2.5.2 as > it goes well beyond a bugfix (adding a new C API and all that). Thanks for looking at it! Is there a better way of exposing some c-helper code for a stdlib module written in python? It seems that the canonical pattern is to write a separate extension module called _ and import the functionality from there, but that seemed like a significantly more invasive patch. Might it help to tack on the helper function in posix only, deleting it from the os namespace? Thanks again, -Mike From guido at python.org Fri Nov 2 19:20:41 2007 From: guido at python.org (Guido van Rossum) Date: Fri, 2 Nov 2007 11:20:41 -0700 Subject: [Python-Dev] Request for inclusion in 2.5.2 (5-for-1) In-Reply-To: References: <19C5D86A-8534-4DB7-934C-CEE94003BB79@gmail.com> Message-ID: On 11/2/07, Mike Klaas wrote: > On 2-Nov-07, at 6:57 AM, Guido van Rossum wrote: > > > Since people are already jumping on those bugs but nobody has voiced > > an opinion on your own patch, let me say that I think it's a good > > patch, and I want it in 2.6, but I'm reluctant to add it to 2.5.2 as > > it goes well beyond a bugfix (adding a new C API and all that). > > Thanks for looking at it! > > Is there a better way of exposing some c-helper code for a stdlib > module written in python? It seems that the canonical pattern is to > write a separate extension module called _ and import the > functionality from there, but that seemed like a significantly more > invasive patch. No, what you did was the right thing. It just doesn't feel like a bugfix to me. > Might it help to tack on the helper function in posix only, deleting > it from the os namespace? No. Why are yo so insistent on having this in 2.5.2? You can't force folks who use your code to upgrade (e.g. OSX Leopard was just shipped with 2.5.1). -- --Guido van Rossum (home page: http://www.python.org/~guido/) From skip at pobox.com Sat Nov 3 12:50:50 2007 From: skip at pobox.com (skip at pobox.com) Date: Sat, 3 Nov 2007 06:50:50 -0500 Subject: [Python-Dev] Does Python need a file locking module (slightly higher level)? In-Reply-To: <18218.33587.350511.718472@montanaro.dyndns.org> References: <18204.38001.562050.157197@montanaro.dyndns.org> <2C9CF122-7954-434C-BFCA-CB5AC0B229F3@python.org> <18205.27378.432540.931896@montanaro.dyndns.org> <95064092-825F-4D3E-A2D4-6309248A6247@python.org> <18210.18858.361196.95168@montanaro.dyndns.org> <18218.33587.350511.718472@montanaro.dyndns.org> Message-ID: <18220.24730.725459.404076@montanaro.dyndns.org> skip> Okay, this is up on my website: skip> http://www.webfast.com/~skip/python/ And on PyPI: http://pypi.python.org/pypi/lockfile/ Skip From martin at v.loewis.de Sat Nov 3 14:42:01 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 03 Nov 2007 14:42:01 +0100 Subject: [Python-Dev] Special file "nul" in Windows and os.stat In-Reply-To: <4866bea60710311231k59ae883dy6ff984e8b9e7ab35@mail.gmail.com> References: <4720161F.7040306@v.loewis.de> <4866bea60710301156k6a4ac17as7dcdcb4949ca4c08@mail.gmail.com> <47279DBA.1090400@v.loewis.de> <4866bea60710311231k59ae883dy6ff984e8b9e7ab35@mail.gmail.com> Message-ID: <472C7AA9.3070808@v.loewis.de> >> That doesn't really answer the question, though - you merely state >> that Python 2.4 calls the CRT, but then my question is still what >> kernel32 functions are called to have stat on NUL succeed. >> > > I'm not 100% (it calls it through a function pointer and I'm not sure > I tracked it down correctly), but I think it calls it through the C > stat() function. In other words, it doesn't use any kernel32 functions > directly, it calls the stat() that's exported from the MSVCRT. Sure - but what does stat then do when passed NUL? > GetFileAttributes() doesn't return those, just the FAT filesystem > attributes. GetFileSize and GetFileTime fail. Ok, so how does msvcrt stat() manage to fill these fields if those functions fail? Regards, Martin From status at bugs.python.org Sat Nov 3 19:06:13 2007 From: status at bugs.python.org (Tracker) Date: Sat, 3 Nov 2007 18:06:13 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071103180613.2C09778329@psf.upfronthosting.co.za> ACTIVITY SUMMARY (10/27/07 - 11/03/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1316 open (+15) / 11546 closed (+20) / 12862 total (+35) Open issues with patches: 417 Average duration of open issues: 683 days. Median duration of open issues: 777 days. Open Issues Breakdown open 1312 (+15) pending 4 ( +0) Issues Created Or Reopened (36) _______________________________ correction for test_tempfile in py3k on Windows 10/28/07 CLOSED http://bugs.python.org/issue1340 reopened gvanrossum Fix for test_netrc on Windows 10/27/07 http://bugs.python.org/issue1345 created tiran patch Error using >>> from OpenGL.GLUT import * 10/27/07 CLOSED http://bugs.python.org/issue1346 created neuralsensor BaseHTTPServer writing strings to bytes interface 10/28/07 CLOSED http://bugs.python.org/issue1347 created janssen py3k, patch httplib closes socket, then tries to read from it 10/28/07 http://bugs.python.org/issue1348 created janssen py3k, patch more uses of ord() in plat-mac/ic.py 10/28/07 CLOSED http://bugs.python.org/issue1349 created janssen py3k, patch IDLE - CallTips enhancement - show full doc-string in new window 10/28/07 http://bugs.python.org/issue1350 created taleinat patch Add getsize() to io instances 10/28/07 http://bugs.python.org/issue1351 created tiran Preliminary stderr patch 10/28/07 CLOSED http://bugs.python.org/issue1352 created tiran mp4 missing from mimetypes.py 10/29/07 CLOSED http://bugs.python.org/issue1353 created kraft windows installer problem 10/29/07 http://bugs.python.org/issue1354 created rajar xml.dom refers to PyXML, which is no longer maintained 10/29/07 http://bugs.python.org/issue1355 created whooey1830 3.0a1 Solaris w/ SUN C/C++ 10/29/07 CLOSED http://bugs.python.org/issue1356 created MrJean1 3.0a1 make test Error on Solaris w/ SUN C/C++ 10/29/07 CLOSED http://bugs.python.org/issue1357 created MrJean1 Compile error on OS X 10.5 10/29/07 http://bugs.python.org/issue1358 created andres py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape 10/29/07 CLOSED http://bugs.python.org/issue1359 reopened gvanrossum Queue.get() can't be interrupted with Ctrl-C unless timed out 10/30/07 CLOSED http://bugs.python.org/issue1360 created piro please close: hashlib uses OpenSSL which is much slower than Aar 10/30/07 CLOSED http://bugs.python.org/issue1361 created Omnifarious Simple mistake in http://docs.python.org/tut/node6.html 10/30/07 CLOSED http://bugs.python.org/issue1362 created dmazz python 2.4.4 fails on solaris (sun4u sparc SUNW,Sun-Fire-880) 10/30/07 http://bugs.python.org/issue1363 created theoryno3 os.lstat documentation error 10/31/07 CLOSED http://bugs.python.org/issue1364 created billiejoex bytes() constructor 10/31/07 CLOSED http://bugs.python.org/issue1365 created tiran popen spawned process may not write to stdout under windows 10/31/07 http://bugs.python.org/issue1366 created pmezard mkdir+chdir problem in multiple threads 10/31/07 CLOSED http://bugs.python.org/issue1367 created anonyprog Bug tracker link in about tutorial page is wrong 11/01/07 CLOSED http://bugs.python.org/issue1368 created ksjohnson Reference to Python24 path in Python 2.5 doc 11/01/07 CLOSED http://bugs.python.org/issue1369 created ksjohnson Doc changes left over after mega-merge from trunk 11/01/07 CLOSED http://bugs.python.org/issue1370 created gvanrossum Two bsddb tests temporarily commented out in py3k branch 11/01/07 CLOSED http://bugs.python.org/issue1371 created gvanrossum py3k zlibmodule.c: int overflow in PyZlib_decompress 11/02/07 http://bugs.python.org/issue1372 created PeterW patch turn off socket timeout in test_xmlrpc 11/02/07 CLOSED http://bugs.python.org/issue1373 created hupp py3k, patch IDLE - minor FormatParagraph bug fix 11/02/07 http://bugs.python.org/issue1374 created taleinat patch hotshot IndexError when loading stats 11/02/07 http://bugs.python.org/issue1375 created ratsberg uu module catches a wrong exception type 11/02/07 CLOSED http://bugs.python.org/issue1376 created billiejoex test_import breaks on Linux 11/02/07 http://bugs.python.org/issue1377 created gvanrossum fromfd() and dup() for _socket on WIndows 11/03/07 http://bugs.python.org/issue1378 created roudkerk patch reloading imported modules sometimes fail with 'parent not in sy 11/03/07 http://bugs.python.org/issue1379 created Paul Pogonyshev patch Issues Now Closed (36) ______________________ decode_unicode doesn't nul-terminate 60 days http://bugs.python.org/issue1098 georg.brandl allow subclassing of bytes type 46 days http://bugs.python.org/issue1171 gvanrossum py3k, patch test fixes for immutable bytes change 43 days http://bugs.python.org/issue1184 gvanrossum py3k, patch PEP 3137 patch (repr, names, parser) 23 days http://bugs.python.org/issue1247 gvanrossum patch IDLE does not start if windows environment variable containing ' 17 days http://bugs.python.org/issue1262 kbk Different 3.0a1 exit behavior 5 days http://bugs.python.org/issue1329 gvanrossum correction for test_tempfile in py3k on Windows 1 days http://bugs.python.org/issue1340 gvanrossum correction for test_fileinput in py3k on Windows 3 days http://bugs.python.org/issue1341 gvanrossum patch Error using >>> from OpenGL.GLUT import * 3 days http://bugs.python.org/issue1346 nnorwitz BaseHTTPServer writing strings to bytes interface 3 days http://bugs.python.org/issue1347 janssen py3k, patch more uses of ord() in plat-mac/ic.py 3 days http://bugs.python.org/issue1349 janssen py3k, patch Preliminary stderr patch 5 days http://bugs.python.org/issue1352 loewis mp4 missing from mimetypes.py 0 days http://bugs.python.org/issue1353 gvanrossum 3.0a1 Solaris w/ SUN C/C++ 0 days http://bugs.python.org/issue1356 gvanrossum 3.0a1 make test Error on Solaris w/ SUN C/C++ 0 days http://bugs.python.org/issue1357 gvanrossum py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape 0 days http://bugs.python.org/issue1359 gvanrossum Queue.get() can't be interrupted with Ctrl-C unless timed out 0 days http://bugs.python.org/issue1360 piro please close: hashlib uses OpenSSL which is much slower than Aar 0 days http://bugs.python.org/issue1361 facundobatista Simple mistake in http://docs.python.org/tut/node6.html 1 days http://bugs.python.org/issue1362 georg.brandl os.lstat documentation error 2 days http://bugs.python.org/issue1364 billiejoex bytes() constructor 0 days http://bugs.python.org/issue1365 gvanrossum mkdir+chdir problem in multiple threads 1 days http://bugs.python.org/issue1367 gvanrossum Bug tracker link in about tutorial page is wrong 0 days http://bugs.python.org/issue1368 georg.brandl Reference to Python24 path in Python 2.5 doc 0 days http://bugs.python.org/issue1369 georg.brandl Doc changes left over after mega-merge from trunk 0 days http://bugs.python.org/issue1370 gvanrossum Two bsddb tests temporarily commented out in py3k branch 0 days http://bugs.python.org/issue1371 gregory.p.smith py3k turn off socket timeout in test_xmlrpc 0 days http://bugs.python.org/issue1373 gvanrossum py3k, patch uu module catches a wrong exception type 1 days http://bugs.python.org/issue1376 gvanrossum Logic Variable Thread Synchronization 1630 days http://bugs.python.org/issue738948 georg.brandl threading.Thread.join() cannot be interrupted by a Ctrl-C 952 days http://bugs.python.org/issue1167930 gvanrossum Ctrl+C for copy does not work when caps-lock is on 713 days http://bugs.python.org/issue1356720 kbk Module uuid: reduce pickle footprint 486 days http://bugs.python.org/issue1516327 gvanrossum patch Module uuid: functions for retrieving MAC addres 486 days http://bugs.python.org/issue1516330 gvanrossum patch "Really print?" Dialog 170 days http://bugs.python.org/issue1717170 taleinat patch PyHeapTypeObject fix 114 days http://bugs.python.org/issue1752184 gvanrossum py3k, patch Errors in site.py not reported properly 82 days http://bugs.python.org/issue1771260 gvanrossum py3k Top Issues Most Discussed (10) ______________________________ 13 Different 3.0a1 exit behavior 5 days closed http://bugs.python.org/issue1329 11 Preliminary stderr patch 5 days closed http://bugs.python.org/issue1352 8 datetime module missing some important methods 244 days open http://bugs.python.org/issue1673409 6 Enhanced tabbed pane widget 328 days open http://bugs.python.org/issue1612746 6 IDLE - patch Delegator to support callables 25 days open http://bugs.python.org/issue1252 5 Doc changes left over after mega-merge from trunk 0 days closed http://bugs.python.org/issue1370 5 Compile error on OS X 10.5 5 days open http://bugs.python.org/issue1358 5 3.0a1 make test Error on Solaris w/ SUN C/C++ 0 days closed http://bugs.python.org/issue1357 5 correction for test_tempfile in py3k on Windows 1 days closed http://bugs.python.org/issue1340 5 Trailing slash in sys.path cause import failure 16 days open http://bugs.python.org/issue1293 From status at bugs.python.org Sun Nov 4 19:06:07 2007 From: status at bugs.python.org (Tracker) Date: Sun, 4 Nov 2007 18:06:07 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071104180607.919077827E@psf.upfronthosting.co.za> ACTIVITY SUMMARY (10/28/07 - 11/04/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1316 open (+11) / 11549 closed (+19) / 12865 total (+30) Open issues with patches: 416 Average duration of open issues: 684 days. Median duration of open issues: 778 days. Open Issues Breakdown open 1311 (+11) pending 5 ( +0) Issues Created Or Reopened (30) _______________________________ mp4 missing from mimetypes.py 10/29/07 CLOSED http://bugs.python.org/issue1353 created kraft windows installer problem 10/29/07 http://bugs.python.org/issue1354 created rajar xml.dom refers to PyXML, which is no longer maintained 10/29/07 http://bugs.python.org/issue1355 created whooey1830 3.0a1 Solaris w/ SUN C/C++ 10/29/07 CLOSED http://bugs.python.org/issue1356 created MrJean1 3.0a1 make test Error on Solaris w/ SUN C/C++ 10/29/07 CLOSED http://bugs.python.org/issue1357 created MrJean1 Compile error on OS X 10.5 10/29/07 http://bugs.python.org/issue1358 created andres py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape 10/29/07 CLOSED http://bugs.python.org/issue1359 reopened gvanrossum Queue.get() can't be interrupted with Ctrl-C unless timed out 10/30/07 CLOSED http://bugs.python.org/issue1360 created piro please close: hashlib uses OpenSSL which is much slower than Aar 10/30/07 CLOSED http://bugs.python.org/issue1361 created Omnifarious Simple mistake in http://docs.python.org/tut/node6.html 10/30/07 CLOSED http://bugs.python.org/issue1362 created dmazz python 2.4.4 fails on solaris (sun4u sparc SUNW,Sun-Fire-880) 10/30/07 http://bugs.python.org/issue1363 created theoryno3 os.lstat documentation error 10/31/07 CLOSED http://bugs.python.org/issue1364 created billiejoex bytes() constructor 10/31/07 CLOSED http://bugs.python.org/issue1365 created tiran popen spawned process may not write to stdout under windows 10/31/07 http://bugs.python.org/issue1366 created pmezard mkdir+chdir problem in multiple threads 10/31/07 CLOSED http://bugs.python.org/issue1367 created anonyprog Bug tracker link in about tutorial page is wrong 11/01/07 CLOSED http://bugs.python.org/issue1368 created ksjohnson Reference to Python24 path in Python 2.5 doc 11/01/07 CLOSED http://bugs.python.org/issue1369 created ksjohnson Doc changes left over after mega-merge from trunk 11/01/07 CLOSED http://bugs.python.org/issue1370 created gvanrossum Two bsddb tests temporarily commented out in py3k branch 11/01/07 CLOSED http://bugs.python.org/issue1371 created gvanrossum py3k zlibmodule.c: int overflow in PyZlib_decompress 11/02/07 http://bugs.python.org/issue1372 created PeterW patch turn off socket timeout in test_xmlrpc 11/02/07 CLOSED http://bugs.python.org/issue1373 created hupp py3k, patch IDLE - minor FormatParagraph bug fix 11/02/07 http://bugs.python.org/issue1374 created taleinat patch hotshot IndexError when loading stats 11/02/07 http://bugs.python.org/issue1375 created ratsberg uu module catches a wrong exception type 11/02/07 CLOSED http://bugs.python.org/issue1376 created billiejoex test_import breaks on Linux 11/02/07 http://bugs.python.org/issue1377 created gvanrossum py3k fromfd() and dup() for _socket on WIndows 11/03/07 http://bugs.python.org/issue1378 created roudkerk patch reloading imported modules sometimes fail with 'parent not in sy 11/03/07 CLOSED http://bugs.python.org/issue1379 created Paul Pogonyshev py3k, patch fix for test_asynchat and test_asyncore on pep3137 branch 11/03/07 CLOSED http://bugs.python.org/issue1380 created hupp py3k, patch cmath is numerically unsound 11/03/07 http://bugs.python.org/issue1381 created inducer py3k-pep3137: patch for test_ctypes 11/04/07 CLOSED http://bugs.python.org/issue1382 created amaury.forgeotdarc py3k, patch Issues Now Closed (39) ______________________ decode_unicode doesn't nul-terminate 60 days http://bugs.python.org/issue1098 georg.brandl allow subclassing of bytes type 46 days http://bugs.python.org/issue1171 gvanrossum py3k, patch test fixes for immutable bytes change 43 days http://bugs.python.org/issue1184 gvanrossum py3k, patch PEP 3137 patch (repr, names, parser) 23 days http://bugs.python.org/issue1247 gvanrossum patch IDLE does not start if windows environment variable containing ' 17 days http://bugs.python.org/issue1262 kbk Different 3.0a1 exit behavior 5 days http://bugs.python.org/issue1329 gvanrossum correction for test_tempfile in py3k on Windows 1 days http://bugs.python.org/issue1340 gvanrossum correction for test_fileinput in py3k on Windows 3 days http://bugs.python.org/issue1341 gvanrossum patch Error using >>> from OpenGL.GLUT import * 3 days http://bugs.python.org/issue1346 nnorwitz BaseHTTPServer writing strings to bytes interface 3 days http://bugs.python.org/issue1347 janssen py3k, patch more uses of ord() in plat-mac/ic.py 3 days http://bugs.python.org/issue1349 janssen py3k, patch Preliminary stderr patch 5 days http://bugs.python.org/issue1352 loewis mp4 missing from mimetypes.py 0 days http://bugs.python.org/issue1353 gvanrossum 3.0a1 Solaris w/ SUN C/C++ 0 days http://bugs.python.org/issue1356 gvanrossum 3.0a1 make test Error on Solaris w/ SUN C/C++ 0 days http://bugs.python.org/issue1357 gvanrossum py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape 0 days http://bugs.python.org/issue1359 gvanrossum Queue.get() can't be interrupted with Ctrl-C unless timed out 0 days http://bugs.python.org/issue1360 piro please close: hashlib uses OpenSSL which is much slower than Aar 0 days http://bugs.python.org/issue1361 facundobatista Simple mistake in http://docs.python.org/tut/node6.html 1 days http://bugs.python.org/issue1362 georg.brandl os.lstat documentation error 2 days http://bugs.python.org/issue1364 billiejoex bytes() constructor 0 days http://bugs.python.org/issue1365 gvanrossum mkdir+chdir problem in multiple threads 1 days http://bugs.python.org/issue1367 gvanrossum Bug tracker link in about tutorial page is wrong 0 days http://bugs.python.org/issue1368 georg.brandl Reference to Python24 path in Python 2.5 doc 0 days http://bugs.python.org/issue1369 georg.brandl Doc changes left over after mega-merge from trunk 0 days http://bugs.python.org/issue1370 gvanrossum Two bsddb tests temporarily commented out in py3k branch 0 days http://bugs.python.org/issue1371 gregory.p.smith py3k turn off socket timeout in test_xmlrpc 0 days http://bugs.python.org/issue1373 gvanrossum py3k, patch uu module catches a wrong exception type 1 days http://bugs.python.org/issue1376 gvanrossum reloading imported modules sometimes fail with 'parent not in sy 1 days http://bugs.python.org/issue1379 Paul Pogonyshev py3k, patch fix for test_asynchat and test_asyncore on pep3137 branch 0 days http://bugs.python.org/issue1380 tiran py3k, patch py3k-pep3137: patch for test_ctypes 0 days http://bugs.python.org/issue1382 tiran py3k, patch Logic Variable Thread Synchronization 1630 days http://bugs.python.org/issue738948 georg.brandl threading.Thread.join() cannot be interrupted by a Ctrl-C 952 days http://bugs.python.org/issue1167930 gvanrossum Ctrl+C for copy does not work when caps-lock is on 713 days http://bugs.python.org/issue1356720 kbk Module uuid: reduce pickle footprint 486 days http://bugs.python.org/issue1516327 gvanrossum patch Module uuid: functions for retrieving MAC addres 486 days http://bugs.python.org/issue1516330 gvanrossum patch "Really print?" Dialog 170 days http://bugs.python.org/issue1717170 taleinat patch PyHeapTypeObject fix 114 days http://bugs.python.org/issue1752184 gvanrossum py3k, patch Errors in site.py not reported properly 82 days http://bugs.python.org/issue1771260 gvanrossum py3k Top Issues Most Discussed (10) ______________________________ 11 Preliminary stderr patch 5 days closed http://bugs.python.org/issue1352 9 Different 3.0a1 exit behavior 5 days closed http://bugs.python.org/issue1329 8 datetime module missing some important methods 245 days open http://bugs.python.org/issue1673409 6 Enhanced tabbed pane widget 329 days open http://bugs.python.org/issue1612746 5 Doc changes left over after mega-merge from trunk 0 days closed http://bugs.python.org/issue1370 5 Compile error on OS X 10.5 6 days open http://bugs.python.org/issue1358 5 3.0a1 make test Error on Solaris w/ SUN C/C++ 0 days closed http://bugs.python.org/issue1357 5 Trailing slash in sys.path cause import failure 17 days open http://bugs.python.org/issue1293 4 cmath is numerically unsound 1 days open http://bugs.python.org/issue1381 4 os.lstat documentation error 2 days closed http://bugs.python.org/issue1364 From status at bugs.python.org Mon Nov 5 19:06:05 2007 From: status at bugs.python.org (Tracker) Date: Mon, 5 Nov 2007 18:06:05 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071105180605.5AFA9780AC@psf.upfronthosting.co.za> ACTIVITY SUMMARY (10/29/07 - 11/05/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1323 open (+16) / 11552 closed (+19) / 12875 total (+35) Open issues with patches: 421 Average duration of open issues: 682 days. Median duration of open issues: 784 days. Open Issues Breakdown open 1317 (+15) pending 5 ( +0) Issues Created Or Reopened (35) _______________________________ Compile error on OS X 10.5 10/29/07 http://bugs.python.org/issue1358 created andres py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape 10/29/07 CLOSED http://bugs.python.org/issue1359 reopened gvanrossum Queue.get() can't be interrupted with Ctrl-C unless timed out 10/30/07 CLOSED http://bugs.python.org/issue1360 created piro please close: hashlib uses OpenSSL which is much slower than Aar 10/30/07 CLOSED http://bugs.python.org/issue1361 created Omnifarious Simple mistake in http://docs.python.org/tut/node6.html 10/30/07 CLOSED http://bugs.python.org/issue1362 created dmazz python 2.4.4 fails on solaris (sun4u sparc SUNW,Sun-Fire-880) 10/30/07 http://bugs.python.org/issue1363 created theoryno3 os.lstat documentation error 10/31/07 CLOSED http://bugs.python.org/issue1364 created billiejoex bytes() constructor 10/31/07 CLOSED http://bugs.python.org/issue1365 created tiran popen spawned process may not write to stdout under windows 10/31/07 http://bugs.python.org/issue1366 created pmezard mkdir+chdir problem in multiple threads 10/31/07 CLOSED http://bugs.python.org/issue1367 created anonyprog Bug tracker link in about tutorial page is wrong 11/01/07 CLOSED http://bugs.python.org/issue1368 created ksjohnson Reference to Python24 path in Python 2.5 doc 11/01/07 CLOSED http://bugs.python.org/issue1369 created ksjohnson Doc changes left over after mega-merge from trunk 11/01/07 CLOSED http://bugs.python.org/issue1370 created gvanrossum Two bsddb tests temporarily commented out in py3k branch 11/01/07 CLOSED http://bugs.python.org/issue1371 created gvanrossum py3k zlibmodule.c: int overflow in PyZlib_decompress 11/02/07 http://bugs.python.org/issue1372 created PeterW patch turn off socket timeout in test_xmlrpc 11/02/07 CLOSED http://bugs.python.org/issue1373 created hupp py3k, patch IDLE - minor FormatParagraph bug fix 11/02/07 http://bugs.python.org/issue1374 created taleinat patch hotshot IndexError when loading stats 11/02/07 http://bugs.python.org/issue1375 created ratsberg uu module catches a wrong exception type 11/02/07 CLOSED http://bugs.python.org/issue1376 created billiejoex test_import breaks on Linux 11/02/07 http://bugs.python.org/issue1377 created gvanrossum py3k fromfd() and dup() for _socket on WIndows 11/03/07 http://bugs.python.org/issue1378 created roudkerk patch reloading imported modules sometimes fail with 'parent not in sy 11/03/07 CLOSED http://bugs.python.org/issue1379 created Paul Pogonyshev py3k, patch fix for test_asynchat and test_asyncore on pep3137 branch 11/03/07 CLOSED http://bugs.python.org/issue1380 created hupp py3k, patch cmath is numerically unsound 11/03/07 http://bugs.python.org/issue1381 created inducer py3k-pep3137: patch for test_ctypes 11/04/07 CLOSED http://bugs.python.org/issue1382 created amaury.forgeotdarc py3k, patch Backport abcoll to 2.6 11/04/07 http://bugs.python.org/issue1383 created baranguren patch Windows fix for inspect tests 11/04/07 http://bugs.python.org/issue1384 created tiran py3k, patch hmac module violates RFC for some hash functions, e.g. sha512 11/04/07 http://bugs.python.org/issue1385 created jowagner patch py3k-pep3137: patch to ensure that all codecs return bytes 11/04/07 CLOSED http://bugs.python.org/issue1386 created amaury.forgeotdarc py3k, patch py3k-pep3137: patch for hashlib on Windows 11/04/07 CLOSED http://bugs.python.org/issue1387 created amaury.forgeotdarc py3k, patch py3k-pep3137: possible ref leak in ctypes 11/05/07 CLOSED http://bugs.python.org/issue1388 created tiran py3k py3k-pep3137: struct module is leaking references 11/05/07 http://bugs.python.org/issue1389 created tiran py3k toxml generates output that is not well formed 11/05/07 http://bugs.python.org/issue1390 created drtomc Adds the .compact() method to bsddb db.DB objects 11/05/07 http://bugs.python.org/issue1391 created gregory.p.smith patch, rfe py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeEr 11/05/07 http://bugs.python.org/issue1392 created tiran py3k, patch Issues Now Closed (37) ______________________ decode_unicode doesn't nul-terminate 60 days http://bugs.python.org/issue1098 georg.brandl allow subclassing of bytes type 46 days http://bugs.python.org/issue1171 gvanrossum py3k, patch test fixes for immutable bytes change 43 days http://bugs.python.org/issue1184 gvanrossum py3k, patch PEP 3137 patch (repr, names, parser) 23 days http://bugs.python.org/issue1247 gvanrossum patch Different 3.0a1 exit behavior 5 days http://bugs.python.org/issue1329 gvanrossum Error using >>> from OpenGL.GLUT import * 3 days http://bugs.python.org/issue1346 nnorwitz BaseHTTPServer writing strings to bytes interface 3 days http://bugs.python.org/issue1347 janssen py3k, patch more uses of ord() in plat-mac/ic.py 3 days http://bugs.python.org/issue1349 janssen py3k, patch Preliminary stderr patch 5 days http://bugs.python.org/issue1352 loewis mp4 missing from mimetypes.py 0 days http://bugs.python.org/issue1353 gvanrossum 3.0a1 Solaris w/ SUN C/C++ 0 days http://bugs.python.org/issue1356 gvanrossum 3.0a1 make test Error on Solaris w/ SUN C/C++ 0 days http://bugs.python.org/issue1357 gvanrossum py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape 0 days http://bugs.python.org/issue1359 gvanrossum Queue.get() can't be interrupted with Ctrl-C unless timed out 0 days http://bugs.python.org/issue1360 piro please close: hashlib uses OpenSSL which is much slower than Aar 0 days http://bugs.python.org/issue1361 facundobatista Simple mistake in http://docs.python.org/tut/node6.html 1 days http://bugs.python.org/issue1362 georg.brandl os.lstat documentation error 2 days http://bugs.python.org/issue1364 billiejoex bytes() constructor 0 days http://bugs.python.org/issue1365 gvanrossum mkdir+chdir problem in multiple threads 1 days http://bugs.python.org/issue1367 gvanrossum Bug tracker link in about tutorial page is wrong 0 days http://bugs.python.org/issue1368 georg.brandl Reference to Python24 path in Python 2.5 doc 0 days http://bugs.python.org/issue1369 georg.brandl Doc changes left over after mega-merge from trunk 0 days http://bugs.python.org/issue1370 gvanrossum Two bsddb tests temporarily commented out in py3k branch 0 days http://bugs.python.org/issue1371 gregory.p.smith py3k turn off socket timeout in test_xmlrpc 0 days http://bugs.python.org/issue1373 gvanrossum py3k, patch uu module catches a wrong exception type 1 days http://bugs.python.org/issue1376 gvanrossum reloading imported modules sometimes fail with 'parent not in sy 1 days http://bugs.python.org/issue1379 Paul Pogonyshev py3k, patch fix for test_asynchat and test_asyncore on pep3137 branch 0 days http://bugs.python.org/issue1380 tiran py3k, patch py3k-pep3137: patch for test_ctypes 0 days http://bugs.python.org/issue1382 tiran py3k, patch py3k-pep3137: patch to ensure that all codecs return bytes 0 days http://bugs.python.org/issue1386 tiran py3k, patch py3k-pep3137: patch for hashlib on Windows 0 days http://bugs.python.org/issue1387 tiran py3k, patch py3k-pep3137: possible ref leak in ctypes 1 days http://bugs.python.org/issue1388 tiran py3k Logic Variable Thread Synchronization 1630 days http://bugs.python.org/issue738948 georg.brandl threading.Thread.join() cannot be interrupted by a Ctrl-C 952 days http://bugs.python.org/issue1167930 gvanrossum Module uuid: reduce pickle footprint 486 days http://bugs.python.org/issue1516327 gvanrossum patch Module uuid: functions for retrieving MAC addres 486 days http://bugs.python.org/issue1516330 gvanrossum patch PyHeapTypeObject fix 114 days http://bugs.python.org/issue1752184 gvanrossum py3k, patch Errors in site.py not reported properly 82 days http://bugs.python.org/issue1771260 gvanrossum py3k Top Issues Most Discussed (10) ______________________________ 10 Preliminary stderr patch 5 days closed http://bugs.python.org/issue1352 8 datetime module missing some important methods 246 days open http://bugs.python.org/issue1673409 6 py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeE 0 days open http://bugs.python.org/issue1392 6 Different 3.0a1 exit behavior 5 days closed http://bugs.python.org/issue1329 5 cmath is numerically unsound 2 days open http://bugs.python.org/issue1381 5 Doc changes left over after mega-merge from trunk 0 days closed http://bugs.python.org/issue1370 5 Compile error on OS X 10.5 7 days open http://bugs.python.org/issue1358 5 Trailing slash in sys.path cause import failure 18 days open http://bugs.python.org/issue1293 4 toxml generates output that is not well formed 1 days open http://bugs.python.org/issue1390 4 os.lstat documentation error 2 days closed http://bugs.python.org/issue1364 From p.f.moore at gmail.com Mon Nov 5 23:05:01 2007 From: p.f.moore at gmail.com (Paul Moore) Date: Mon, 5 Nov 2007 22:05:01 +0000 Subject: [Python-Dev] Summary of Tracker Issues In-Reply-To: <20071105180605.5AFA9780AC@psf.upfronthosting.co.za> References: <20071105180605.5AFA9780AC@psf.upfronthosting.co.za> Message-ID: <79990c6b0711051405o1031cf9nf57b8dd34e9f899b@mail.gmail.com> On 05/11/2007, Tracker wrote: > > ACTIVITY SUMMARY (10/29/07 - 11/05/07) > Tracker at http://bugs.python.org/ These seem to be getting sent out daily at the moment. Is that right? Paul. From facundobatista at gmail.com Tue Nov 6 16:04:59 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Tue, 6 Nov 2007 12:04:59 -0300 Subject: [Python-Dev] Special file "nul" in Windows and os.stat In-Reply-To: <472C7AA9.3070808@v.loewis.de> References: <4720161F.7040306@v.loewis.de> <4866bea60710301156k6a4ac17as7dcdcb4949ca4c08@mail.gmail.com> <47279DBA.1090400@v.loewis.de> <4866bea60710311231k59ae883dy6ff984e8b9e7ab35@mail.gmail.com> <472C7AA9.3070808@v.loewis.de> Message-ID: 2007/11/3, "Martin v. L?wis" : > > GetFileAttributes() doesn't return those, just the FAT filesystem > > attributes. GetFileSize and GetFileTime fail. > > Ok, so how does msvcrt stat() manage to fill these fields if those > functions fail? Beyond the question to this specific question, I do not like the inconsistency of windows with itself during time and versions. As Mask Hammond said, I think that we should rely on what windows is saying to us as strict as possible. If windows change its behaviour, ok, I do not think that we need to "patch" these behaviour holes. What do you think? Is a mistake to adhere to windows behaviour? Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From martin at v.loewis.de Tue Nov 6 19:00:33 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 06 Nov 2007 19:00:33 +0100 Subject: [Python-Dev] Special file "nul" in Windows and os.stat In-Reply-To: References: <4720161F.7040306@v.loewis.de> <4866bea60710301156k6a4ac17as7dcdcb4949ca4c08@mail.gmail.com> <47279DBA.1090400@v.loewis.de> <4866bea60710311231k59ae883dy6ff984e8b9e7ab35@mail.gmail.com> <472C7AA9.3070808@v.loewis.de> Message-ID: <4730ABC1.4070104@v.loewis.de> > As Mask Hammond said, I think that we should rely on what windows is > saying to us as strict as possible. If windows change its behaviour, > ok, I do not think that we need to "patch" these behaviour holes. > > What do you think? Is a mistake to adhere to windows behaviour? We certainly should rely on the Windows behavior. The next question then is: What exactly *is* "the Windows behavior". Windows is not just inconsistent across versions, but apparently so even within a single version. IIUC, GetFileAttributes and FindFirstFile both claim that NUL exists, whereas GetFileAttributesEx claims that it doesn't exist, all in a single version, and all is Windows API. Please understand that Python 2.4 *also* adheres to Windows behavior. Regards, Martin From status at bugs.python.org Tue Nov 6 19:06:04 2007 From: status at bugs.python.org (Tracker) Date: Tue, 6 Nov 2007 18:06:04 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071106180604.E13217833D@psf.upfronthosting.co.za> ACTIVITY SUMMARY (10/30/07 - 11/06/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1323 open (+16) / 11557 closed (+19) / 12880 total (+35) Open issues with patches: 419 Average duration of open issues: 683 days. Median duration of open issues: 785 days. Open Issues Breakdown open 1318 (+16) pending 5 ( +0) Issues Created Or Reopened (35) _______________________________ python 2.4.4 fails on solaris (sun4u sparc SUNW,Sun-Fire-880) 10/30/07 http://bugs.python.org/issue1363 created theoryno3 os.lstat documentation error 10/31/07 CLOSED http://bugs.python.org/issue1364 created billiejoex bytes() constructor 10/31/07 CLOSED http://bugs.python.org/issue1365 created tiran popen spawned process may not write to stdout under windows 10/31/07 http://bugs.python.org/issue1366 created pmezard mkdir+chdir problem in multiple threads 10/31/07 CLOSED http://bugs.python.org/issue1367 created anonyprog Bug tracker link in about tutorial page is wrong 11/01/07 CLOSED http://bugs.python.org/issue1368 created ksjohnson Reference to Python24 path in Python 2.5 doc 11/01/07 CLOSED http://bugs.python.org/issue1369 created ksjohnson Doc changes left over after mega-merge from trunk 11/01/07 CLOSED http://bugs.python.org/issue1370 created gvanrossum Two bsddb tests temporarily commented out in py3k branch 11/01/07 CLOSED http://bugs.python.org/issue1371 created gvanrossum py3k zlibmodule.c: int overflow in PyZlib_decompress 11/02/07 http://bugs.python.org/issue1372 created PeterW patch turn off socket timeout in test_xmlrpc 11/02/07 CLOSED http://bugs.python.org/issue1373 created hupp py3k, patch IDLE - minor FormatParagraph bug fix 11/02/07 http://bugs.python.org/issue1374 created taleinat patch hotshot IndexError when loading stats 11/02/07 http://bugs.python.org/issue1375 created ratsberg uu module catches a wrong exception type 11/02/07 CLOSED http://bugs.python.org/issue1376 created billiejoex test_import breaks on Linux 11/02/07 http://bugs.python.org/issue1377 created gvanrossum py3k fromfd() and dup() for _socket on WIndows 11/03/07 http://bugs.python.org/issue1378 created roudkerk patch reloading imported modules sometimes fail with 'parent not in sy 11/03/07 CLOSED http://bugs.python.org/issue1379 created Paul Pogonyshev py3k, patch fix for test_asynchat and test_asyncore on pep3137 branch 11/03/07 CLOSED http://bugs.python.org/issue1380 created hupp py3k, patch cmath is numerically unsound 11/03/07 http://bugs.python.org/issue1381 created inducer py3k-pep3137: patch for test_ctypes 11/04/07 CLOSED http://bugs.python.org/issue1382 created amaury.forgeotdarc py3k, patch Backport abcoll to 2.6 11/04/07 http://bugs.python.org/issue1383 created baranguren patch Windows fix for inspect tests 11/04/07 CLOSED http://bugs.python.org/issue1384 created tiran py3k, patch hmac module violates RFC for some hash functions, e.g. sha512 11/04/07 CLOSED http://bugs.python.org/issue1385 created jowagner py3k py3k-pep3137: patch to ensure that all codecs return bytes 11/04/07 CLOSED http://bugs.python.org/issue1386 created amaury.forgeotdarc py3k, patch py3k-pep3137: patch for hashlib on Windows 11/04/07 CLOSED http://bugs.python.org/issue1387 created amaury.forgeotdarc py3k, patch py3k-pep3137: possible ref leak in ctypes 11/05/07 CLOSED http://bugs.python.org/issue1388 created tiran py3k py3k-pep3137: struct module is leaking references 11/05/07 CLOSED http://bugs.python.org/issue1389 created tiran py3k toxml generates output that is not well formed 11/05/07 http://bugs.python.org/issue1390 created drtomc Adds the .compact() method to bsddb db.DB objects 11/05/07 http://bugs.python.org/issue1391 created gregory.p.smith patch, rfe py3k-pep3137: issue warnings / errors on str(bytes()) and simila 11/05/07 CLOSED http://bugs.python.org/issue1392 created tiran py3k, patch function comparing lacks NotImplemented error 11/05/07 http://bugs.python.org/issue1393 created Paul Pogonyshev simple patch, improving unreachable bytecode removing 11/05/07 http://bugs.python.org/issue1394 created Paul Pogonyshev patch py3k: duplicated line endings when using read(1) 11/06/07 http://bugs.python.org/issue1395 created amaury.forgeotdarc py3k-pep3137: patch for mailbox 11/06/07 http://bugs.python.org/issue1396 created tiran py3k, patch py3k-pep3137: failing unit test test_bsddb 11/06/07 http://bugs.python.org/issue1397 created tiran py3k Issues Now Closed (34) ______________________ decode_unicode doesn't nul-terminate 60 days http://bugs.python.org/issue1098 georg.brandl allow subclassing of bytes type 46 days http://bugs.python.org/issue1171 gvanrossum py3k, patch test fixes for immutable bytes change 43 days http://bugs.python.org/issue1184 gvanrossum py3k, patch PEP 3137 patch (repr, names, parser) 23 days http://bugs.python.org/issue1247 gvanrossum patch Different 3.0a1 exit behavior 5 days http://bugs.python.org/issue1329 gvanrossum Fix for test_netrc on Windows 9 days http://bugs.python.org/issue1345 tiran py3k, patch Error using >>> from OpenGL.GLUT import * 3 days http://bugs.python.org/issue1346 nnorwitz BaseHTTPServer writing strings to bytes interface 3 days http://bugs.python.org/issue1347 janssen py3k, patch more uses of ord() in plat-mac/ic.py 3 days http://bugs.python.org/issue1349 janssen py3k, patch Preliminary stderr patch 5 days http://bugs.python.org/issue1352 loewis os.lstat documentation error 2 days http://bugs.python.org/issue1364 billiejoex bytes() constructor 0 days http://bugs.python.org/issue1365 gvanrossum mkdir+chdir problem in multiple threads 1 days http://bugs.python.org/issue1367 gvanrossum Bug tracker link in about tutorial page is wrong 0 days http://bugs.python.org/issue1368 georg.brandl Reference to Python24 path in Python 2.5 doc 0 days http://bugs.python.org/issue1369 georg.brandl Doc changes left over after mega-merge from trunk 0 days http://bugs.python.org/issue1370 gvanrossum Two bsddb tests temporarily commented out in py3k branch 0 days http://bugs.python.org/issue1371 gregory.p.smith py3k turn off socket timeout in test_xmlrpc 0 days http://bugs.python.org/issue1373 gvanrossum py3k, patch uu module catches a wrong exception type 1 days http://bugs.python.org/issue1376 gvanrossum reloading imported modules sometimes fail with 'parent not in sy 1 days http://bugs.python.org/issue1379 Paul Pogonyshev py3k, patch fix for test_asynchat and test_asyncore on pep3137 branch 0 days http://bugs.python.org/issue1380 tiran py3k, patch py3k-pep3137: patch for test_ctypes 0 days http://bugs.python.org/issue1382 tiran py3k, patch Windows fix for inspect tests 2 days http://bugs.python.org/issue1384 tiran py3k, patch hmac module violates RFC for some hash functions, e.g. sha512 2 days http://bugs.python.org/issue1385 jowagner py3k py3k-pep3137: patch to ensure that all codecs return bytes 0 days http://bugs.python.org/issue1386 tiran py3k, patch py3k-pep3137: patch for hashlib on Windows 0 days http://bugs.python.org/issue1387 tiran py3k, patch py3k-pep3137: possible ref leak in ctypes 1 days http://bugs.python.org/issue1388 tiran py3k py3k-pep3137: struct module is leaking references 1 days http://bugs.python.org/issue1389 gvanrossum py3k py3k-pep3137: issue warnings / errors on str(bytes()) and simila 1 days http://bugs.python.org/issue1392 tiran py3k, patch Logic Variable Thread Synchronization 1630 days http://bugs.python.org/issue738948 georg.brandl Module uuid: reduce pickle footprint 486 days http://bugs.python.org/issue1516327 gvanrossum patch Module uuid: functions for retrieving MAC addres 486 days http://bugs.python.org/issue1516330 gvanrossum patch PyHeapTypeObject fix 114 days http://bugs.python.org/issue1752184 gvanrossum py3k, patch Errors in site.py not reported properly 82 days http://bugs.python.org/issue1771260 gvanrossum py3k Top Issues Most Discussed (10) ______________________________ 15 py3k-pep3137: issue warnings / errors on str(bytes()) and simil 1 days closed http://bugs.python.org/issue1392 8 datetime module missing some important methods 247 days open http://bugs.python.org/issue1673409 8 Preliminary stderr patch 5 days closed http://bugs.python.org/issue1352 7 py3k: duplicated line endings when using read(1) 1 days open http://bugs.python.org/issue1395 7 toxml generates output that is not well formed 2 days open http://bugs.python.org/issue1390 5 Windows fix for inspect tests 2 days closed http://bugs.python.org/issue1384 5 cmath is numerically unsound 3 days open http://bugs.python.org/issue1381 5 Doc changes left over after mega-merge from trunk 0 days closed http://bugs.python.org/issue1370 5 Trailing slash in sys.path cause import failure 19 days open http://bugs.python.org/issue1293 4 hmac module violates RFC for some hash functions, e.g. sha512 2 days closed http://bugs.python.org/issue1385 From facundobatista at gmail.com Tue Nov 6 19:32:26 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Tue, 6 Nov 2007 15:32:26 -0300 Subject: [Python-Dev] Special file "nul" in Windows and os.stat In-Reply-To: <4730ABC1.4070104@v.loewis.de> References: <4720161F.7040306@v.loewis.de> <4866bea60710301156k6a4ac17as7dcdcb4949ca4c08@mail.gmail.com> <47279DBA.1090400@v.loewis.de> <4866bea60710311231k59ae883dy6ff984e8b9e7ab35@mail.gmail.com> <472C7AA9.3070808@v.loewis.de> <4730ABC1.4070104@v.loewis.de> Message-ID: 2007/11/6, "Martin v. L?wis" : > We certainly should rely on the Windows behavior. The next question then > is: What exactly *is* "the Windows behavior". Windows is not just > inconsistent across versions, but apparently so even within a single > version. +1 for QOTW > IIUC, GetFileAttributes and FindFirstFile both claim that NUL exists, > whereas GetFileAttributesEx claims that it doesn't exist, all in a > single version, and all is Windows API. > > Please understand that Python 2.4 *also* adheres to Windows behavior. So, in Py2.4 we adhered to windows behaviour in one way, and in 2.5 we adhere to windows behaviour in other way. As Windows is inconsistant with itself, we got a behaviour change.... right? If yes, we have three paths to follow... leave 2.5 as is and say that the behaviour change is ok (windows fault), change 2.5 to use the same API than 2.4 and get the same behaviour, or hardwire the behaviour for this set of special files... What do you think we should do? Thanks! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From rschroev_nospam_ml at fastmail.fm Tue Nov 6 18:38:17 2007 From: rschroev_nospam_ml at fastmail.fm (Roel Schroeven) Date: Tue, 06 Nov 2007 18:38:17 +0100 Subject: [Python-Dev] Special file "nul" in Windows and os.stat In-Reply-To: <472C7AA9.3070808@v.loewis.de> References: <4720161F.7040306@v.loewis.de> <4866bea60710301156k6a4ac17as7dcdcb4949ca4c08@mail.gmail.com> <47279DBA.1090400@v.loewis.de> <4866bea60710311231k59ae883dy6ff984e8b9e7ab35@mail.gmail.com> <472C7AA9.3070808@v.loewis.de> Message-ID: Martin v. L?wis schreef: >>> That doesn't really answer the question, though - you merely state >>> that Python 2.4 calls the CRT, but then my question is still what >>> kernel32 functions are called to have stat on NUL succeed. >>> > Sure - but what does stat then do when passed NUL? AFAIK then it doesn't fill in the size and time fields of the structure (or sets them to a useless/invalid value). (See http://msdn2.microsoft.com/en-us/library/14h5k7ff(vs.71).aspx) > >> GetFileAttributes() doesn't return those, just the FAT filesystem >> attributes. GetFileSize and GetFileTime fail. > > Ok, so how does msvcrt stat() manage to fill these fields if those > functions fail? See above: if stat() (_stat() actually) is called on NUL (or another device), I don't think it does anything useful with these fields. -- The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom. -- Isaac Asimov Roel Schroeven From martin at v.loewis.de Tue Nov 6 20:37:21 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 06 Nov 2007 20:37:21 +0100 Subject: [Python-Dev] Special file "nul" in Windows and os.stat In-Reply-To: References: <4720161F.7040306@v.loewis.de> <4866bea60710301156k6a4ac17as7dcdcb4949ca4c08@mail.gmail.com> <47279DBA.1090400@v.loewis.de> <4866bea60710311231k59ae883dy6ff984e8b9e7ab35@mail.gmail.com> <472C7AA9.3070808@v.loewis.de> <4730ABC1.4070104@v.loewis.de> Message-ID: <4730C271.8010908@v.loewis.de> > If yes, we have three paths to follow... leave 2.5 as is and say that > the behaviour change is ok (windows fault), change 2.5 to use the same > API than 2.4 and get the same behaviour, or hardwire the behaviour for > this set of special files... As you said before, we should avoid hardwiring things. > What do you think we should do? I think we should try to follow the behavior of 2.4. To do that, we still have to find out what precisely the behavior of 2.4 is (and then perhaps we might decide to not follow it when we know what it is). Unfortunately, it seems that none of us is both capable and has sufficient time to research what the 2.4 behavior actually is; I'd like to emphasize that I think no changes should be made until the behavior is fully understood, which it currently isn't. So I suggest to take no action until somebody comes along who has both the time and the knowledge to resolve the issue. Regards, Martin From facundobatista at gmail.com Tue Nov 6 20:40:42 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Tue, 6 Nov 2007 16:40:42 -0300 Subject: [Python-Dev] Special file "nul" in Windows and os.stat In-Reply-To: <4730C271.8010908@v.loewis.de> References: <4720161F.7040306@v.loewis.de> <4866bea60710301156k6a4ac17as7dcdcb4949ca4c08@mail.gmail.com> <47279DBA.1090400@v.loewis.de> <4866bea60710311231k59ae883dy6ff984e8b9e7ab35@mail.gmail.com> <472C7AA9.3070808@v.loewis.de> <4730ABC1.4070104@v.loewis.de> <4730C271.8010908@v.loewis.de> Message-ID: 2007/11/6, "Martin v. L?wis" : > Unfortunately, it seems that none of us is both capable and has > sufficient time to research what the 2.4 behavior actually is; > I'd like to emphasize that I think no changes should be made until > the behavior is fully understood, which it currently isn't. > > So I suggest to take no action until somebody comes along who > has both the time and the knowledge to resolve the issue. Yes, I can try things on Windows, but don't have a development enviroment there, so I'll leave the bug open. Thanks everybody! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From martin at v.loewis.de Tue Nov 6 20:51:10 2007 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Tue, 06 Nov 2007 20:51:10 +0100 Subject: [Python-Dev] Special file "nul" in Windows and os.stat In-Reply-To: References: <4720161F.7040306@v.loewis.de> <4866bea60710301156k6a4ac17as7dcdcb4949ca4c08@mail.gmail.com> <47279DBA.1090400@v.loewis.de> <4866bea60710311231k59ae883dy6ff984e8b9e7ab35@mail.gmail.com> <472C7AA9.3070808@v.loewis.de> Message-ID: <4730C5AE.9090505@v.loewis.de> >> Sure - but what does stat then do when passed NUL? > > AFAIK then it doesn't fill in the size and time fields of the structure > (or sets them to a useless/invalid value). > > (See http://msdn2.microsoft.com/en-us/library/14h5k7ff(vs.71).aspx) What specifically on that page tells me how the fields get filled for NUL? If you are referring to the "if path refers to a device..." sentence: how does it determine that NUL is a device? > See above: if stat() (_stat() actually) is called on NUL (or another > device), I don't think it does anything useful with these fields. You mean, it does nothing documented... AFAICT from the code, it always fills in something. Regards, Martin From p.f.moore at gmail.com Tue Nov 6 21:42:31 2007 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 6 Nov 2007 20:42:31 +0000 Subject: [Python-Dev] Special file "nul" in Windows and os.stat In-Reply-To: <4730C5AE.9090505@v.loewis.de> References: <4720161F.7040306@v.loewis.de> <4866bea60710301156k6a4ac17as7dcdcb4949ca4c08@mail.gmail.com> <47279DBA.1090400@v.loewis.de> <4866bea60710311231k59ae883dy6ff984e8b9e7ab35@mail.gmail.com> <472C7AA9.3070808@v.loewis.de> <4730C5AE.9090505@v.loewis.de> Message-ID: <79990c6b0711061242w13c23900t907fe8bf2154fcdb@mail.gmail.com> On 06/11/2007, "Martin v. L?wis" wrote: > > See above: if stat() (_stat() actually) is called on NUL (or another > > device), I don't think it does anything useful with these fields. > > You mean, it does nothing documented... AFAICT from the code, it always > fills in something. >From my reading of the CRT source code, _stat() uses FindFirstFile(). This in turn appears to return a valid result on "nul" - win32api.FindFile, which is a thin wrapper round FindFirstFile etc, returns >>> win32api.FindFiles("nul") [(32, , , , 0L, 0L, 0L, 0L, 'nul ', '')] 32 is FILE_ATTRIBUTE_ARCHIVE, the times are the epoch, and everything else is null. This is on my machine, using the Windows Server 2003 SP1 CRT source code. How consistent it is across versions, or anything else, I can't say :-( Paul. From rschroev_nospam_ml at fastmail.fm Tue Nov 6 21:52:00 2007 From: rschroev_nospam_ml at fastmail.fm (Roel Schroeven) Date: Tue, 06 Nov 2007 21:52:00 +0100 Subject: [Python-Dev] Special file "nul" in Windows and os.stat In-Reply-To: <4730C5AE.9090505@v.loewis.de> References: <4720161F.7040306@v.loewis.de> <4866bea60710301156k6a4ac17as7dcdcb4949ca4c08@mail.gmail.com> <47279DBA.1090400@v.loewis.de> <4866bea60710311231k59ae883dy6ff984e8b9e7ab35@mail.gmail.com> <472C7AA9.3070808@v.loewis.de> <4730C5AE.9090505@v.loewis.de> Message-ID: Martin v. L?wis schreef: >>> Sure - but what does stat then do when passed NUL? >> AFAIK then it doesn't fill in the size and time fields of the structure >> (or sets them to a useless/invalid value). >> >> (See http://msdn2.microsoft.com/en-us/library/14h5k7ff(vs.71).aspx) > > What specifically on that page tells me how the fields get filled > for NUL? If you are referring to the "if path refers to a device..." > sentence: Yes, I was > how does it determine that NUL is a device? I'm not sure. I suppose it just calls GetFileSize() etc. The docs for GetFileSize() say "You cannot use the GetFileSize function with a handle of a nonseeking device such as a pipe or a communications device. To determine the file type for hFile, use the GetFileType function." GetFileType() on its turn returns one of: FILE_TYPE_UNKNOWN: The type of the specified file is unknown. FILE_TYPE_DISK: The specified file is a disk file. FILE_TYPE_CHAR: The specified file is a character file, typically an LPT device or a console. FILE_TYPE_PIPE: The specified file is either a named or anonymous pipe. But I don't know where it is specified which names refer to devices. I tried to query all device names with QueryDosDevice() (with a very simple C program; I can give you the code though I doubt it's useful), but that returns 208 names (on my system); much more than the LPT1, CON, NUL etc. It also includes stuff like, on my system, "Dritek_KB_Filter", "Sony Ericsson T610 Series Bluetooth (TM) Modem #2" etc. I've tried calling _stat() on those names and it returns -1 meaning "File not found". That behavior is clearly different from CON, NUL etc. I thought I've seen the complete list on MSDN some time before, but I can't find it now. >> See above: if stat() (_stat() actually) is called on NUL (or another >> device), I don't think it does anything useful with these fields. > > You mean, it does nothing documented... AFAICT from the code, it always > fills in something. Yes, it returns 0xffffffff in the time fields and 0 in the size field (at least on my system, Windows XP SP1). I made another small C++ program to see what _stat() does (again, I can give you the code if you want). With a normal file: $ ./stat stat.cpp gid 0 atime 1194169674 = 2007-11-04T10:47:54 ctime 1194167463 = 2007-11-04T10:11:03 dev 2 ino 0 mode 0x81b6 mtime 1194381734 = 2007-11-06T21:42:14 nlink 1 rdev 2 size 1342 uid 0 With a device: $ ./stat NUL gid 0 atime 4294967295 = invalid time ctime 4294967295 = invalid time dev 2 ino 0 mode 0x81b6 mtime 4294967295 = invalid time nlink 1 rdev 2 size 0 uid 0 (The $ and ./ is because I ran the program from an msys shell) (it says "invalid time" because localtime() returns NULL) In summary, I'm afraid all of this doesn't really help very much... -- The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom. -- Isaac Asimov Roel Schroeven From martin at v.loewis.de Tue Nov 6 21:56:06 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 06 Nov 2007 21:56:06 +0100 Subject: [Python-Dev] Special file "nul" in Windows and os.stat In-Reply-To: <79990c6b0711061242w13c23900t907fe8bf2154fcdb@mail.gmail.com> References: <4720161F.7040306@v.loewis.de> <4866bea60710301156k6a4ac17as7dcdcb4949ca4c08@mail.gmail.com> <47279DBA.1090400@v.loewis.de> <4866bea60710311231k59ae883dy6ff984e8b9e7ab35@mail.gmail.com> <472C7AA9.3070808@v.loewis.de> <4730C5AE.9090505@v.loewis.de> <79990c6b0711061242w13c23900t907fe8bf2154fcdb@mail.gmail.com> Message-ID: <4730D4E6.6060502@v.loewis.de> >>From my reading of the CRT source code, _stat() uses FindFirstFile(). > This in turn appears to return a valid result on "nul" - > win32api.FindFile, which is a thin wrapper round FindFirstFile etc, > returns > >>>> win32api.FindFiles("nul") > [(32, , , > , 0L, 0L, 0L, 0L, 'nul > ', '')] Ok. I would still like to avoid calling FindFirstFile *first*, i.e. "normally" use GetFileAttributesEx first, and only fall back to FindFirstFile if that gives an error. Such fallback already occurs if the GetFileAttributesEx error was ERROR_SHARING_VIOLATION. So is there any good way to determine that the GetFileAttributesError was caused by using a "reserved" file name. It seems that the error is ERROR_INVALID_PARAMETER, but that would also be issued if you have an otherwise-invalid file name (e.g. one including wild cards), right? > This is on my machine, using the Windows Server 2003 SP1 CRT source > code. How consistent it is across versions, or anything else, I can't > say :-( Thanks, that helps already. Regards, Martin From scott+python-dev at scottdial.com Wed Nov 7 02:03:57 2007 From: scott+python-dev at scottdial.com (Scott Dial) Date: Tue, 06 Nov 2007 20:03:57 -0500 Subject: [Python-Dev] Special file "nul" in Windows and os.stat In-Reply-To: <4720161F.7040306@v.loewis.de> References: <4720161F.7040306@v.loewis.de> Message-ID: <47310EFD.5090109@scottdial.com> Martin v. L?wis wrote: >> So, the question is what we should do?: > > Before this question can be answered, I think we need to fully > understand what precisely is happening in 2.4, and what precisely > is happening in 2.5. > Seeing this thread drag on was enough to get me to find out what changed. The implementation of "os.stat" has been changed. In 2.4.4, _stati64/_wstati64 were called directly, but in 2.5.1, a new pair of functions were wrote win32_stat/win32_wstat. _stati64/_wstati64 (as others have noted) fallback onto the use of FindFirstFile. win32_stat/win32_wstat use some functions called Py_GetFileAttributesExA/Py_GetFileAttributesExW which ultimately use GetFileAttributesA/GetFileAttributesW. The change to this implementation is r42230 with the Misc/NEWS comment saying: - Use Win32 API to implement os.stat/fstat. As a result, subsecond timestamps are reported, the limit on path name lengths is removed, and stat reports WindowsError now (instead of OSError). As to the specifics of what FindFirstFile* does with the values, I tested this quickly with ctypes on 'nul' (or any of the other special files): cAlternameFileName: cFileName: nul dwFileAttributes: 32 dwReserved0: 0 dwReserved1: 0 ftCreationTime: (dwLowDateTime: 0, dwHighDateTime: 0) ftLastAccessTime: (dwLowDateTime: 0, dwHighDateTime: 0) ftLastWriteTime: (dwLowDateTime: 0, dwHighDateTime: 0) nFileSizeHigh: 0 nFileSizeLow: 0 In order to keep the higher accuracy timestamps for normal files and to maintain the old behavior, my recommendation would be that the existing implementation of win32_stat/win32_wstat be extended to use FindFileFirst if GetFileAttributes* fails. I would be willing to do the legwork for such a patch if everyone agrees this is the appropriate solution. * As an aside, Martin, I find the argument that "hard-wiring is bad" to be against what is actually occurring in the posixmodule. For that matter, the S_IFEXEC flag is hardwired to path in (*.bat, *.cmd, *.exe, *.com) despite the fact that the platform says it is really anything in the list of os.getenv('PATHEXT'), but I suppose that is a bug for another day. -Scott -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From martin at v.loewis.de Wed Nov 7 07:24:01 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 07 Nov 2007 07:24:01 +0100 Subject: [Python-Dev] Special file "nul" in Windows and os.stat In-Reply-To: <47310EFD.5090109@scottdial.com> References: <4720161F.7040306@v.loewis.de> <47310EFD.5090109@scottdial.com> Message-ID: <47315A01.7010508@v.loewis.de> > In order to keep the higher accuracy timestamps for normal files and to > maintain the old behavior, my recommendation would be that the existing > implementation of win32_stat/win32_wstat be extended to use > FindFileFirst if GetFileAttributes* fails. I would be willing to do the > legwork for such a patch if everyone agrees this is the appropriate > solution. That, in general, might be wrong. os.stat("*.txt") should fail, even though FindFirstFile will succeed when passed that string. That was my primary motivation for not using FindFirstFile by default: it may succeed even if the string being passed does not denote a file name. > * As an aside, Martin, I find the argument that "hard-wiring is bad" to > be against what is actually occurring in the posixmodule. For that > matter, the S_IFEXEC flag is hardwired to path in (*.bat, *.cmd, *.exe, > *.com) despite the fact that the platform says it is really anything in > the list of os.getenv('PATHEXT'), but I suppose that is a bug for > another day. No. See the source of the C library - the algorithm Python uses now is (or should be) the same as the one of the C library. Of course, you may argue that then msvcrt has the same bug. Regards, Martin From tjreedy at udel.edu Wed Nov 7 07:36:27 2007 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 7 Nov 2007 01:36:27 -0500 Subject: [Python-Dev] Special file "nul" in Windows and os.stat References: <4720161F.7040306@v.loewis.de> <4866bea60710301156k6a4ac17as7dcdcb4949ca4c08@mail.gmail.com> <47279DBA.1090400@v.loewis.de> <4866bea60710311231k59ae883dy6ff984e8b9e7ab35@mail.gmail.com> <472C7AA9.3070808@v.loewis.de> <4730ABC1.4070104@v.loewis.de> <4730C271.8010908@v.loewis.de> Message-ID: ""Martin v. L?wis"" wrote in message news:4730C271.8010908 at v.loewis.de... |> If yes, we have three paths to follow... leave 2.5 as is and say that | > the behaviour change is ok (windows fault), change 2.5 to use the same | > API than 2.4 and get the same behaviour, or hardwire the behaviour for | > this set of special files... | | As you said before, we should avoid hardwiring things. | | > What do you think we should do? | | I think we should try to follow the behavior of 2.4. To do that, we | still have to find out what precisely the behavior of 2.4 is (and | then perhaps we might decide to not follow it when we know what it | is). | | Unfortunately, it seems that none of us is both capable and has | sufficient time to research what the 2.4 behavior actually is; | I'd like to emphasize that I think no changes should be made until | the behavior is fully understood, which it currently isn't. | | So I suggest to take no action until somebody comes along who | has both the time and the knowledge to resolve the issue. Perhaps a note should be added to the docs that the 'existence' of 'nul', etc, is inconsistent in Windows and hence, at present, in Python. In part, it seems to me, that anyone doing Windows-specific stuff should decide for themselves whether 'nul' exists for their purposes or not. Hence the problem should only arise when receiving a filename from an external source. Maybe the special Windows module should have an 'isdevice' function if it does not already to test such. I agree that there are more generally useful things for you to do. Windows is sometimes a maddening platform to work on. tjr From scott+python-dev at scottdial.com Wed Nov 7 08:09:23 2007 From: scott+python-dev at scottdial.com (Scott Dial) Date: Wed, 07 Nov 2007 02:09:23 -0500 Subject: [Python-Dev] Special file "nul" in Windows and os.stat In-Reply-To: <47315A01.7010508@v.loewis.de> References: <4720161F.7040306@v.loewis.de> <47310EFD.5090109@scottdial.com> <47315A01.7010508@v.loewis.de> Message-ID: <473164A3.60800@scottdial.com> Martin v. L?wis wrote: >> In order to keep the higher accuracy timestamps for normal files and to >> maintain the old behavior, my recommendation would be that the existing >> implementation of win32_stat/win32_wstat be extended to use >> FindFileFirst if GetFileAttributes* fails. I would be willing to do the >> legwork for such a patch if everyone agrees this is the appropriate >> solution. > > That, in general, might be wrong. os.stat("*.txt") should fail, even > though FindFirstFile will succeed when passed that string. > Sorry, I meant to imply that we would guard FindFirstFile in the same manner that _stati64 and friends do already (using strpbrk/wcspbrk to search for "?*" in the path). At that point, you have essentially duplicated the CRT code with the added improvement of using GetFileAttributes* to retrieve the high-precision timestamps. So, I think my opinion has changed now to say: first, use GetFileAttributes*, and if that fails use _stati64/_wstati64. > That was my primary motivation for not using FindFirstFile by default: > it may succeed even if the string being passed does not denote a file > name. While I understand your reasoning, I thought we were letting the platform decide what are and are not files. This bug appeared because we are imposing our own notion of what a file is or is not, probably only by ignorance of the differences of GetFileAttribute* and FindFirstFile. So, my suggestion is basically a compromise of keeping higher precision timestamps for paths where GetFileAttribute* works and retaining the old behavior for all others. > >> * As an aside, Martin, I find the argument that "hard-wiring is bad" to >> be against what is actually occurring in the posixmodule. For that >> matter, the S_IFEXEC flag is hardwired to path in (*.bat, *.cmd, *.exe, >> *.com) despite the fact that the platform says it is really anything in >> the list of os.getenv('PATHEXT'), but I suppose that is a bug for >> another day. > > No. See the source of the C library - the algorithm Python uses now is > (or should be) the same as the one of the C library. Of course, you > may argue that then msvcrt has the same bug. > I concede and apologies, I didn't read the code for converting attributes to mode flags. I don't imagine (m)any people care about this flag on the win32 platform anyways. -Scott -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From nnorwitz at gmail.com Wed Nov 7 08:18:35 2007 From: nnorwitz at gmail.com (Neal Norwitz) Date: Tue, 6 Nov 2007 23:18:35 -0800 Subject: [Python-Dev] Request for inclusion in 2.5.2 (5-for-1) In-Reply-To: <472AFABE.1070900@gmail.com> References: <19C5D86A-8534-4DB7-934C-CEE94003BB79@gmail.com> <472AFABE.1070900@gmail.com> Message-ID: Mike, thanks for reviewing the bugs and for creating a patch. Good work! On Nov 2, 2007 2:23 AM, Nick Coghlan wrote: > Mike Klaas wrote: > > http://bugs.python.org/issue1705170: reproduced. Conjecture as to > > why it is occurring, but I don't know the guts well enough to propose > > a decent fix. > > I've fixed this on the trunk (I'm afraid I have no opinion on the patch > you're interested in though. > > Neal - where does the 2.5 branch stand at the moment? This would be a > simple fix to slip into 2.5.2 if there's still time. I'm not sure if this was before my last status mail. We are hoping to get a release candidate out in a week or two. I agree with Guido that this isn't a bugfix and therefore shouldn't be backported to 2.5. n From martin at v.loewis.de Wed Nov 7 10:00:36 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 07 Nov 2007 10:00:36 +0100 Subject: [Python-Dev] Special file "nul" in Windows and os.stat In-Reply-To: <473164A3.60800@scottdial.com> References: <4720161F.7040306@v.loewis.de> <47310EFD.5090109@scottdial.com> <47315A01.7010508@v.loewis.de> <473164A3.60800@scottdial.com> Message-ID: <47317EB4.4050307@v.loewis.de> > Sorry, I meant to imply that we would guard FindFirstFile in the same > manner that _stati64 and friends do already (using strpbrk/wcspbrk to > search for "?*" in the path). At that point, you have essentially > duplicated the CRT code with the added improvement of using > GetFileAttributes* to retrieve the high-precision timestamps. So, I > think my opinion has changed now to say: first, use GetFileAttributes*, > and if that fails use _stati64/_wstati64. No. We want to phase out usage of the standard C library wherever we can. Duplicating its logic is fine. Also, I don't think Python should implement its own logic of what a valid file name is - the approach of using strpbrk is flawed. IIRC, some version of the CRT (or some other C library) used GetFileAttributes to determine whether a file name is valid. > While I understand your reasoning, I thought we were letting the > platform decide what are and are not files. This bug appeared because we > are imposing our own notion of what a file is or is not, probably only > by ignorance of the differences of GetFileAttribute* and FindFirstFile. > So, my suggestion is basically a compromise of keeping higher precision > timestamps for paths where GetFileAttribute* works and retaining the old > behavior for all others. Sure, but I really dislike the string parsing that the CRT does (and I don't want to go back to using the CRT for stat-like calls). Regards, Martin From martin at v.loewis.de Wed Nov 7 10:33:54 2007 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 07 Nov 2007 10:33:54 +0100 Subject: [Python-Dev] Special file "nul" in Windows and os.stat In-Reply-To: References: <4720161F.7040306@v.loewis.de> <4866bea60710301156k6a4ac17as7dcdcb4949ca4c08@mail.gmail.com> <47279DBA.1090400@v.loewis.de> <4866bea60710311231k59ae883dy6ff984e8b9e7ab35@mail.gmail.com> <472C7AA9.3070808@v.loewis.de> <4730ABC1.4070104@v.loewis.de> <4730C271.8010908@v.loewis.de> Message-ID: <47318682.3030902@v.loewis.de> > Perhaps a note should be added to the docs that the 'existence' of 'nul', > etc, is inconsistent in Windows and hence, at present, in Python. That is a statement that I want to get better confirmation on also. What is the precise condition where Windows (or perhaps just Python?) would claim that nul exists? > In part, it seems to me, that anyone doing Windows-specific stuff should > decide for themselves whether 'nul' exists for their purposes or not. No. The intention of os.path.exists clearly is that if it says that it exists, there is a high chance that you can subsequently open it, and vice versa. Of course, there are other issues, such as timing and permissions, but in general, Python applications should not have to "bypass" the standard library with platform-specific knowledge. It's somewhat unfortunate that os.path.exists() is implemented on top of stat(2), which does much more than finding out whether the file exists. Alas, it is the POSIX tradition that this "ought" to work, so this strategy is just a fact of life. I don't know what the actual use case is for testing "existence" of "nul", but I guess a "natural" problem is that the user says she wants to create a file named "nul", and the application checks whether this is a new file name, which it isn't (it exists in every directory, if I understand correctly). Regards, Martin From ncoghlan at gmail.com Wed Nov 7 13:37:38 2007 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 07 Nov 2007 22:37:38 +1000 Subject: [Python-Dev] Request for inclusion in 2.5.2 (5-for-1) In-Reply-To: References: <19C5D86A-8534-4DB7-934C-CEE94003BB79@gmail.com> <472AFABE.1070900@gmail.com> Message-ID: <4731B192.4040205@gmail.com> Neal Norwitz wrote: > On Nov 2, 2007 2:23 AM, Nick Coghlan wrote: >> Neal - where does the 2.5 branch stand at the moment? This would be a >> simple fix to slip into 2.5.2 if there's still time. > > I'm not sure if this was before my last status mail. We are hoping to > get a release candidate out in a week or two. It was more than a week but less than two weeks after your last status message, but you hadn't said anything yet about freezing the branch to cut a release candidate - hence my question :) > I agree with Guido that this isn't a bugfix and therefore shouldn't be > backported to 2.5. I was actually referring to the contextmanager bug with that comment - I was just a little vague with my pronouns. All sorted now though. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From status at bugs.python.org Wed Nov 7 19:06:05 2007 From: status at bugs.python.org (Tracker) Date: Wed, 7 Nov 2007 18:06:05 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071107180605.E81D17832B@psf.upfronthosting.co.za> ACTIVITY SUMMARY (10/31/07 - 11/07/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1322 open (+15) / 11560 closed (+17) / 12882 total (+32) Open issues with patches: 418 Average duration of open issues: 684 days. Median duration of open issues: 786 days. Open Issues Breakdown open 1317 (+15) pending 5 ( +0) Issues Created Or Reopened (32) _______________________________ Bug tracker link in about tutorial page is wrong 11/01/07 CLOSED http://bugs.python.org/issue1368 created ksjohnson Reference to Python24 path in Python 2.5 doc 11/01/07 CLOSED http://bugs.python.org/issue1369 created ksjohnson Doc changes left over after mega-merge from trunk 11/01/07 CLOSED http://bugs.python.org/issue1370 created gvanrossum Two bsddb tests temporarily commented out in py3k branch 11/01/07 CLOSED http://bugs.python.org/issue1371 created gvanrossum py3k zlibmodule.c: int overflow in PyZlib_decompress 11/02/07 http://bugs.python.org/issue1372 created PeterW patch, 64bit turn off socket timeout in test_xmlrpc 11/02/07 CLOSED http://bugs.python.org/issue1373 created hupp py3k, patch IDLE - minor FormatParagraph bug fix 11/02/07 http://bugs.python.org/issue1374 created taleinat patch hotshot IndexError when loading stats 11/02/07 http://bugs.python.org/issue1375 created ratsberg uu module catches a wrong exception type 11/02/07 CLOSED http://bugs.python.org/issue1376 created billiejoex test_import breaks on Linux 11/02/07 http://bugs.python.org/issue1377 created gvanrossum py3k fromfd() and dup() for _socket on WIndows 11/03/07 http://bugs.python.org/issue1378 created roudkerk patch reloading imported modules sometimes fail with 'parent not in sy 11/03/07 CLOSED http://bugs.python.org/issue1379 created _doublep py3k, patch fix for test_asynchat and test_asyncore on pep3137 branch 11/03/07 CLOSED http://bugs.python.org/issue1380 created hupp py3k, patch cmath is numerically unsound 11/03/07 http://bugs.python.org/issue1381 created inducer py3k-pep3137: patch for test_ctypes 11/04/07 CLOSED http://bugs.python.org/issue1382 created amaury.forgeotdarc py3k, patch Backport abcoll to 2.6 11/04/07 http://bugs.python.org/issue1383 created baranguren patch Windows fix for inspect tests 11/04/07 CLOSED http://bugs.python.org/issue1384 created tiran py3k, patch hmac module violates RFC for some hash functions, e.g. sha512 11/04/07 CLOSED http://bugs.python.org/issue1385 created jowagner py3k py3k-pep3137: patch to ensure that all codecs return bytes 11/04/07 CLOSED http://bugs.python.org/issue1386 created amaury.forgeotdarc py3k, patch py3k-pep3137: patch for hashlib on Windows 11/04/07 CLOSED http://bugs.python.org/issue1387 created amaury.forgeotdarc py3k, patch py3k-pep3137: possible ref leak in ctypes 11/05/07 CLOSED http://bugs.python.org/issue1388 created tiran py3k py3k-pep3137: struct module is leaking references 11/05/07 CLOSED http://bugs.python.org/issue1389 created tiran py3k toxml generates output that is not well formed 11/05/07 http://bugs.python.org/issue1390 created drtomc Adds the .compact() method to bsddb db.DB objects 11/05/07 http://bugs.python.org/issue1391 created gregory.p.smith patch, rfe py3k-pep3137: issue warnings / errors on str(bytes()) and simila 11/05/07 CLOSED http://bugs.python.org/issue1392 created tiran py3k, patch function comparing lacks NotImplemented error 11/05/07 http://bugs.python.org/issue1393 created _doublep simple patch, improving unreachable bytecode removing 11/05/07 http://bugs.python.org/issue1394 created _doublep patch py3k: duplicated line endings when using read(1) 11/06/07 http://bugs.python.org/issue1395 created amaury.forgeotdarc py3k py3k-pep3137: patch for mailbox 11/06/07 CLOSED http://bugs.python.org/issue1396 created tiran py3k, patch py3k-pep3137: failing unit test test_bsddb 11/06/07 http://bugs.python.org/issue1397 created tiran py3k Can't pickle partial functions 11/07/07 http://bugs.python.org/issue1398 created danhs XML codec 11/07/07 http://bugs.python.org/issue1399 created doerwalter patch Issues Now Closed (32) ______________________ decode_unicode doesn't nul-terminate 60 days http://bugs.python.org/issue1098 georg.brandl allow subclassing of bytes type 46 days http://bugs.python.org/issue1171 gvanrossum py3k, patch test fixes for immutable bytes change 43 days http://bugs.python.org/issue1184 gvanrossum py3k, patch PEP 3137 patch (repr, names, parser) 23 days http://bugs.python.org/issue1247 gvanrossum patch Trailing slash in sys.path cause import failure 20 days http://bugs.python.org/issue1293 gvanrossum patch Fix for test_netrc on Windows 9 days http://bugs.python.org/issue1345 tiran py3k, patch Preliminary stderr patch 5 days http://bugs.python.org/issue1352 loewis os.lstat documentation error 2 days http://bugs.python.org/issue1364 billiejoex mkdir+chdir problem in multiple threads 1 days http://bugs.python.org/issue1367 gvanrossum Bug tracker link in about tutorial page is wrong 0 days http://bugs.python.org/issue1368 georg.brandl Reference to Python24 path in Python 2.5 doc 0 days http://bugs.python.org/issue1369 georg.brandl Doc changes left over after mega-merge from trunk 0 days http://bugs.python.org/issue1370 gvanrossum Two bsddb tests temporarily commented out in py3k branch 0 days http://bugs.python.org/issue1371 gregory.p.smith py3k turn off socket timeout in test_xmlrpc 0 days http://bugs.python.org/issue1373 gvanrossum py3k, patch uu module catches a wrong exception type 1 days http://bugs.python.org/issue1376 gvanrossum reloading imported modules sometimes fail with 'parent not in sy 1 days http://bugs.python.org/issue1379 _doublep py3k, patch fix for test_asynchat and test_asyncore on pep3137 branch 0 days http://bugs.python.org/issue1380 tiran py3k, patch py3k-pep3137: patch for test_ctypes 0 days http://bugs.python.org/issue1382 tiran py3k, patch Windows fix for inspect tests 2 days http://bugs.python.org/issue1384 tiran py3k, patch hmac module violates RFC for some hash functions, e.g. sha512 2 days http://bugs.python.org/issue1385 jowagner py3k py3k-pep3137: patch to ensure that all codecs return bytes 0 days http://bugs.python.org/issue1386 tiran py3k, patch py3k-pep3137: patch for hashlib on Windows 0 days http://bugs.python.org/issue1387 tiran py3k, patch py3k-pep3137: possible ref leak in ctypes 1 days http://bugs.python.org/issue1388 tiran py3k py3k-pep3137: struct module is leaking references 1 days http://bugs.python.org/issue1389 gvanrossum py3k py3k-pep3137: issue warnings / errors on str(bytes()) and simila 1 days http://bugs.python.org/issue1392 tiran py3k, patch py3k-pep3137: patch for mailbox 0 days http://bugs.python.org/issue1396 gvanrossum py3k, patch Error on handling nan 1637 days http://bugs.python.org/issue737648 mike.verdone Logic Variable Thread Synchronization 1630 days http://bugs.python.org/issue738948 georg.brandl Module uuid: reduce pickle footprint 486 days http://bugs.python.org/issue1516327 gvanrossum patch Module uuid: functions for retrieving MAC addres 486 days http://bugs.python.org/issue1516330 gvanrossum patch contextmanager eats StopIteration 199 days http://bugs.python.org/issue1705170 ncoghlan PyHeapTypeObject fix 114 days http://bugs.python.org/issue1752184 gvanrossum py3k, patch Top Issues Most Discussed (10) ______________________________ 15 py3k: duplicated line endings when using read(1) 2 days open http://bugs.python.org/issue1395 15 py3k-pep3137: issue warnings / errors on str(bytes()) and simil 1 days closed http://bugs.python.org/issue1392 15 toxml generates output that is not well formed 3 days open http://bugs.python.org/issue1390 14 Trailing slash in sys.path cause import failure 20 days closed http://bugs.python.org/issue1293 8 datetime module missing some important methods 248 days open http://bugs.python.org/issue1673409 6 Preliminary stderr patch 5 days closed http://bugs.python.org/issue1352 5 contextmanager eats StopIteration 199 days closed http://bugs.python.org/issue1705170 5 py3k-pep3137: patch for mailbox 0 days closed http://bugs.python.org/issue1396 5 Windows fix for inspect tests 2 days closed http://bugs.python.org/issue1384 5 cmath is numerically unsound 4 days open http://bugs.python.org/issue1381 From walter at livinglogic.de Wed Nov 7 18:53:06 2007 From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=) Date: Wed, 07 Nov 2007 18:53:06 +0100 Subject: [Python-Dev] XML codec? Message-ID: <4731FB82.8020001@livinglogic.de> I have a patch ready (http://bugs.python.org/issue1399) that adds an XML codec. This codec implements encoding detection as specified in http://www.w3.org/TR/2004/REC-xml-20040204/#sec-guessing and could be used for the decoding phase of an XML parser. Other use cases are: The codec could be used for transcoding an XML input before passing it to the real parser, if the parser itself doesn't support the encoding in question. A text editor could use the codec to decode an XML file. When the user changes the XML declaration and resaves the file, it would be saved in the correct encoding. I'd like to have this codec in 2.6 and 3.0. Any comments? Servus, Walter From martin at v.loewis.de Thu Nov 8 07:05:48 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Thu, 08 Nov 2007 07:05:48 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <4731FB82.8020001@livinglogic.de> References: <4731FB82.8020001@livinglogic.de> Message-ID: <4732A73C.4000803@v.loewis.de> > Any comments? -1. First, (as already discussed on the tracker,) "xml" is a bad name for an encoding. How would you encode "Hello" "in xml"? Then, I'd claim that the problem that the codec solves doesn't really exist. IOW, most XML parsers implement the auto-detection of encodings, anyway, and this is where architecturally this functionality belongs. For a text editor, much more useful than a codec would be a routine (say, xml.detect_encoding) which performs the auto-detection. Finally, I think the codec is incorrect. When saving XML to a file (e.g. in a text editor), there should rarely be encoding errors, since one could use character references in many cases. Also, the XML spec talks about detecting EBCDIC, which I believe your implementation doesn't. Regards, Martin From walter at livinglogic.de Thu Nov 8 12:54:18 2007 From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=) Date: Thu, 08 Nov 2007 12:54:18 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <4732A73C.4000803@v.loewis.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> Message-ID: <4732F8EA.6010605@livinglogic.de> Martin v. L?wis wrote: >> Any comments? > > -1. First, (as already discussed on the tracker,) "xml" is a bad name > for an encoding. How would you encode "Hello" "in xml"? Then how about the suggested "xml-auto-detect"? > Then, I'd claim that the problem that the codec solves doesn't really > exist. IOW, most XML parsers implement the auto-detection of encodings, > anyway, and this is where architecturally this functionality belongs. But not all XML parsers support all encodings. The XML codec makes it trivial to add this support to an existing parser. Furthermore encoding-detection might be part of the responsibility of the XML parser, but this decoding phase is totally distinct from the parsing phase, so why not put the decoding into a common library? > For a text editor, much more useful than a codec would be a routine > (say, xml.detect_encoding) which performs the auto-detection. There's a (currently undocumented) codecs.detect_xml_encoding() in the patch. We could document this function and make it public. But if there's no codec that uses it, this function IMHO doesn't belong in the codecs module. Should this function be available from xml/__init__.py or should be put it into something like xml/utils.py? > Finally, I think the codec is incorrect. When saving XML to a file > (e.g. in a text editor), there should rarely be encoding errors, since > one could use character references in many cases. This requires some intelligent fiddling with the errors attribute of the encoder. > Also, the XML > spec talks about detecting EBCDIC, which I believe your implementation > doesn't. Correct, but as long as Python doesn't have an EBCDIC codec, that won't help much. Adding *detection* of EBCDIC to detect_xml_encoding() is rather simple though. Servus, Walter From status at bugs.python.org Thu Nov 8 19:06:09 2007 From: status at bugs.python.org (Tracker) Date: Thu, 8 Nov 2007 18:06:09 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071108180609.B00417833F@psf.upfronthosting.co.za> ACTIVITY SUMMARY (11/01/07 - 11/08/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1319 open (+18) / 11570 closed (+19) / 12889 total (+37) Open issues with patches: 419 Average duration of open issues: 686 days. Median duration of open issues: 785 days. Open Issues Breakdown open 1314 (+18) pending 5 ( +0) Issues Created Or Reopened (37) _______________________________ Doc changes left over after mega-merge from trunk 11/01/07 CLOSED http://bugs.python.org/issue1370 created gvanrossum Two bsddb tests temporarily commented out in py3k branch 11/01/07 CLOSED http://bugs.python.org/issue1371 created gvanrossum py3k zlibmodule.c: int overflow in PyZlib_decompress 11/02/07 http://bugs.python.org/issue1372 created PeterW patch, 64bit turn off socket timeout in test_xmlrpc 11/02/07 CLOSED http://bugs.python.org/issue1373 created hupp py3k, patch IDLE - minor FormatParagraph bug fix 11/02/07 http://bugs.python.org/issue1374 created taleinat patch hotshot IndexError when loading stats 11/02/07 http://bugs.python.org/issue1375 created ratsberg uu module catches a wrong exception type 11/02/07 CLOSED http://bugs.python.org/issue1376 created billiejoex test_import breaks on Linux 11/02/07 CLOSED http://bugs.python.org/issue1377 created gvanrossum py3k fromfd() and dup() for _socket on WIndows 11/03/07 http://bugs.python.org/issue1378 created roudkerk patch reloading imported modules sometimes fail with 'parent not in sy 11/03/07 CLOSED http://bugs.python.org/issue1379 created _doublep py3k, patch fix for test_asynchat and test_asyncore on pep3137 branch 11/03/07 CLOSED http://bugs.python.org/issue1380 created hupp py3k, patch cmath is numerically unsound 11/03/07 http://bugs.python.org/issue1381 created inducer py3k-pep3137: patch for test_ctypes 11/04/07 CLOSED http://bugs.python.org/issue1382 created amaury.forgeotdarc py3k, patch Backport abcoll to 2.6 11/04/07 http://bugs.python.org/issue1383 created baranguren patch Windows fix for inspect tests 11/04/07 CLOSED http://bugs.python.org/issue1384 created tiran py3k, patch hmac module violates RFC for some hash functions, e.g. sha512 11/04/07 CLOSED http://bugs.python.org/issue1385 created jowagner py3k py3k-pep3137: patch to ensure that all codecs return bytes 11/04/07 CLOSED http://bugs.python.org/issue1386 created amaury.forgeotdarc py3k, patch py3k-pep3137: patch for hashlib on Windows 11/04/07 CLOSED http://bugs.python.org/issue1387 created amaury.forgeotdarc py3k, patch py3k-pep3137: possible ref leak in ctypes 11/05/07 CLOSED http://bugs.python.org/issue1388 created tiran py3k py3k-pep3137: struct module is leaking references 11/05/07 CLOSED http://bugs.python.org/issue1389 created tiran py3k toxml generates output that is not well formed 11/05/07 http://bugs.python.org/issue1390 created drtomc Adds the .compact() method to bsddb db.DB objects 11/05/07 http://bugs.python.org/issue1391 created gregory.p.smith patch, rfe py3k-pep3137: issue warnings / errors on str(bytes()) and simila 11/05/07 CLOSED http://bugs.python.org/issue1392 created tiran py3k, patch function comparing lacks NotImplemented error 11/05/07 http://bugs.python.org/issue1393 created _doublep simple patch, improving unreachable bytecode removing 11/05/07 http://bugs.python.org/issue1394 created _doublep patch py3k: duplicated line endings when using read(1) 11/06/07 http://bugs.python.org/issue1395 created amaury.forgeotdarc py3k py3k-pep3137: patch for mailbox 11/06/07 CLOSED http://bugs.python.org/issue1396 created tiran py3k, patch py3k-pep3137: failing unit test test_bsddb 11/06/07 http://bugs.python.org/issue1397 created tiran py3k Can't pickle partial functions 11/07/07 CLOSED http://bugs.python.org/issue1398 created danhs XML codec 11/07/07 http://bugs.python.org/issue1399 created doerwalter patch Py3k's print() flushing problem 11/07/07 http://bugs.python.org/issue1400 created wojtekwalczak py3k urllib2 302 POST 11/07/07 http://bugs.python.org/issue1401 created andresriancho Interpreter cleanup: order of _PyGILState_Fini and PyInterpreter 11/07/07 http://bugs.python.org/issue1402 created ronaldoussoren py_compile and compileall need unit tests 11/08/07 http://bugs.python.org/issue1403 created tiran py3k warnings module bug: BytesWarning: str() on a bytes instance 11/08/07 CLOSED http://bugs.python.org/issue1404 created tiran patch Garbage collection not working correctly in Python 2.3 11/08/07 CLOSED http://bugs.python.org/issue1405 created pythonmeister Use widechar api for os.environ 11/08/07 http://bugs.python.org/issue1406 created theller py3k, patch Issues Now Closed (34) ______________________ test_glob fails with UnicodeDecodeError 72 days http://bugs.python.org/issue1042 tiran rfe test_email failed 67 days http://bugs.python.org/issue1086 tiran rfe py3k os.popen result is not iterable, patch attached 67 days http://bugs.python.org/issue1087 tiran patch decode_unicode doesn't nul-terminate 60 days http://bugs.python.org/issue1098 georg.brandl Problems with the msi installer - python-3.0a1.msi 64 days http://bugs.python.org/issue1110 tiran No tests for inspect.getfullargspec() 63 days http://bugs.python.org/issue1127 tiran py3k, patch Should itertools.count work for arbitrary integers? 53 days http://bugs.python.org/issue1165 rhettinger py3k allow subclassing of bytes type 46 days http://bugs.python.org/issue1171 gvanrossum py3k, patch test fixes for immutable bytes change 43 days http://bugs.python.org/issue1184 gvanrossum py3k, patch Trailing slash in sys.path cause import failure 20 days http://bugs.python.org/issue1293 gvanrossum patch Fix for test_netrc on Windows 9 days http://bugs.python.org/issue1345 tiran py3k, patch Preliminary stderr patch 5 days http://bugs.python.org/issue1352 loewis Doc changes left over after mega-merge from trunk 0 days http://bugs.python.org/issue1370 gvanrossum Two bsddb tests temporarily commented out in py3k branch 0 days http://bugs.python.org/issue1371 gregory.p.smith py3k turn off socket timeout in test_xmlrpc 0 days http://bugs.python.org/issue1373 gvanrossum py3k, patch uu module catches a wrong exception type 1 days http://bugs.python.org/issue1376 gvanrossum test_import breaks on Linux 6 days http://bugs.python.org/issue1377 tiran py3k reloading imported modules sometimes fail with 'parent not in sy 1 days http://bugs.python.org/issue1379 _doublep py3k, patch fix for test_asynchat and test_asyncore on pep3137 branch 0 days http://bugs.python.org/issue1380 tiran py3k, patch py3k-pep3137: patch for test_ctypes 0 days http://bugs.python.org/issue1382 tiran py3k, patch Windows fix for inspect tests 2 days http://bugs.python.org/issue1384 tiran py3k, patch hmac module violates RFC for some hash functions, e.g. sha512 2 days http://bugs.python.org/issue1385 jowagner py3k py3k-pep3137: patch to ensure that all codecs return bytes 0 days http://bugs.python.org/issue1386 tiran py3k, patch py3k-pep3137: patch for hashlib on Windows 0 days http://bugs.python.org/issue1387 tiran py3k, patch py3k-pep3137: possible ref leak in ctypes 1 days http://bugs.python.org/issue1388 tiran py3k py3k-pep3137: struct module is leaking references 1 days http://bugs.python.org/issue1389 gvanrossum py3k py3k-pep3137: issue warnings / errors on str(bytes()) and simila 1 days http://bugs.python.org/issue1392 tiran py3k, patch py3k-pep3137: patch for mailbox 0 days http://bugs.python.org/issue1396 gvanrossum py3k, patch Can't pickle partial functions 1 days http://bugs.python.org/issue1398 tiran warnings module bug: BytesWarning: str() on a bytes instance 0 days http://bugs.python.org/issue1404 tiran patch Garbage collection not working correctly in Python 2.3 0 days http://bugs.python.org/issue1405 tiran Error on handling nan 1637 days http://bugs.python.org/issue737648 mike.verdone contextmanager eats StopIteration 199 days http://bugs.python.org/issue1705170 ncoghlan PyHeapTypeObject fix 114 days http://bugs.python.org/issue1752184 gvanrossum py3k, patch Top Issues Most Discussed (10) ______________________________ 30 py3k: duplicated line endings when using read(1) 3 days open http://bugs.python.org/issue1395 15 py3k-pep3137: issue warnings / errors on str(bytes()) and simil 1 days closed http://bugs.python.org/issue1392 15 toxml generates output that is not well formed 4 days open http://bugs.python.org/issue1390 14 Trailing slash in sys.path cause import failure 20 days closed http://bugs.python.org/issue1293 8 datetime module missing some important methods 249 days open http://bugs.python.org/issue1673409 5 urllib2 302 POST 1 days open http://bugs.python.org/issue1401 5 py3k-pep3137: patch for mailbox 0 days closed http://bugs.python.org/issue1396 5 Windows fix for inspect tests 2 days closed http://bugs.python.org/issue1384 5 cmath is numerically unsound 5 days open http://bugs.python.org/issue1381 5 Doc changes left over after mega-merge from trunk 0 days closed http://bugs.python.org/issue1370 From martin at v.loewis.de Thu Nov 8 19:39:26 2007 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Thu, 08 Nov 2007 19:39:26 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <4732F8EA.6010605@livinglogic.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> Message-ID: <473357DE.5010805@v.loewis.de> > Then how about the suggested "xml-auto-detect"? That is better. >> Then, I'd claim that the problem that the codec solves doesn't really >> exist. IOW, most XML parsers implement the auto-detection of encodings, >> anyway, and this is where architecturally this functionality belongs. > > But not all XML parsers support all encodings. The XML codec makes it > trivial to add this support to an existing parser. I would like to question this claim. Can you give an example of a parser that doesn't support a specific encoding and where adding such a codec solves that problem? In particular, why would that parser know how to process Python Unicode strings? > Furthermore encoding-detection might be part of the responsibility of > the XML parser, but this decoding phase is totally distinct from the > parsing phase, so why not put the decoding into a common library? I would not object to that - just to expose it as a codec. Adding it to the XML library is fine, IMO. > There's a (currently undocumented) codecs.detect_xml_encoding() in the > patch. We could document this function and make it public. But if > there's no codec that uses it, this function IMHO doesn't belong in the > codecs module. Should this function be available from xml/__init__.py or > should be put it into something like xml/utils.py? Either - or. >> Finally, I think the codec is incorrect. When saving XML to a file >> (e.g. in a text editor), there should rarely be encoding errors, since >> one could use character references in many cases. > > This requires some intelligent fiddling with the errors attribute of the > encoder. Much more than that, I think - you cannot use a character reference in an XML Name. So the codec would have to parse the output stream to know whether or not a character reference could be used. > Correct, but as long as Python doesn't have an EBCDIC codec, that won't > help much. Adding *detection* of EBCDIC to detect_xml_encoding() is > rather simple though. But it does! cp037 is EBCDIC, and supported by Python. Regards, Martin From walter at livinglogic.de Thu Nov 8 22:01:24 2007 From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=) Date: Thu, 08 Nov 2007 22:01:24 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <473357DE.5010805@v.loewis.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> Message-ID: <47337924.6030107@livinglogic.de> Martin v. L?wis wrote: >> Then how about the suggested "xml-auto-detect"? > > That is better. OK. >>> Then, I'd claim that the problem that the codec solves doesn't really >>> exist. IOW, most XML parsers implement the auto-detection of encodings, >>> anyway, and this is where architecturally this functionality belongs. >> But not all XML parsers support all encodings. The XML codec makes it >> trivial to add this support to an existing parser. > > I would like to question this claim. Can you give an example of a parser > that doesn't support a specific encoding It seems that e.g. expat doesn't support UTF-32: from xml.parsers import expat p = expat.ParserCreate() e = "utf-32" s = (u"" % e).encode(e) p.Parse(s, True) This fails with: Traceback (most recent call last): File "gurk.py", line 6, in p.Parse(s, True) xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 1 Replace "utf-32" with "utf-16" and the problem goes away. > and where adding such a codec > solves that problem? > > In particular, why would that parser know how to process Python Unicode > strings? It doesn't have to. You can use an XML encoder to reencode the unicode string into bytes (forcing an encoding that the parser knows): import codecs from xml.parsers import expat ci = codecs.lookup("xml-auto-detect") p = expat.ParserCreate() e = "utf-32" s = (u"" % e).encode(e) s = ci.encode(ci.decode(s)[0], encoding="utf-8")[0] p.Parse(s, True) >> Furthermore encoding-detection might be part of the responsibility of >> the XML parser, but this decoding phase is totally distinct from the >> parsing phase, so why not put the decoding into a common library? > > I would not object to that - just to expose it as a codec. Adding it > to the XML library is fine, IMO. But it does make sense as a codec. The decoding phase of an XML parser has to turn a byte stream into a unicode stream. That's the job of a codec. >> There's a (currently undocumented) codecs.detect_xml_encoding() in the >> patch. We could document this function and make it public. But if >> there's no codec that uses it, this function IMHO doesn't belong in the >> codecs module. Should this function be available from xml/__init__.py or >> should be put it into something like xml/utils.py? > > Either - or. OK, so should I put the C code into a _xml module? >>> Finally, I think the codec is incorrect. When saving XML to a file >>> (e.g. in a text editor), there should rarely be encoding errors, since >>> one could use character references in many cases. >> This requires some intelligent fiddling with the errors attribute of the >> encoder. > > Much more than that, I think - you cannot use a character reference > in an XML Name. So the codec would have to parse the output stream > to know whether or not a character reference could be used. That's what I meant with "intelligent" fiddling. But I agree this is way beyond what a text editor should do. AFAIK it is way beyond what existing text editors do. However using the XML codec would at least guarantee that the encoding specified in the XML declaration and the encoding used for encoding the file stay consistent. >> Correct, but as long as Python doesn't have an EBCDIC codec, that won't >> help much. Adding *detection* of EBCDIC to detect_xml_encoding() is >> rather simple though. > > But it does! cp037 is EBCDIC, and supported by Python. I didn't know that. I'm going to update the patch. Servus, Walter From walter at livinglogic.de Thu Nov 8 22:27:50 2007 From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=) Date: Thu, 08 Nov 2007 22:27:50 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <47337924.6030107@livinglogic.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> Message-ID: <47337F56.20408@livinglogic.de> Walter D?rwald wrote: > Martin v. L?wis wrote: > > [...] >>> Correct, but as long as Python doesn't have an EBCDIC codec, that won't >>> help much. Adding *detection* of EBCDIC to detect_xml_encoding() is >>> rather simple though. >> But it does! cp037 is EBCDIC, and supported by Python. > > I didn't know that. I'm going to update the patch. Done: http://bugs.python.org/1399 I also renamed the codec to xml_auto_detect. Servus, Walter From rhamph at gmail.com Thu Nov 8 23:45:51 2007 From: rhamph at gmail.com (Adam Olsen) Date: Thu, 8 Nov 2007 15:45:51 -0700 Subject: [Python-Dev] XML codec? In-Reply-To: <47337924.6030107@livinglogic.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> Message-ID: On 11/8/07, Walter D?rwald wrote: > Martin v. L?wis wrote: > > >> Then how about the suggested "xml-auto-detect"? > > > > That is better. > > OK. > > >>> Then, I'd claim that the problem that the codec solves doesn't really > >>> exist. IOW, most XML parsers implement the auto-detection of encodings, > >>> anyway, and this is where architecturally this functionality belongs. > >> But not all XML parsers support all encodings. The XML codec makes it > >> trivial to add this support to an existing parser. > > > > I would like to question this claim. Can you give an example of a parser > > that doesn't support a specific encoding > > It seems that e.g. expat doesn't support UTF-32: > > from xml.parsers import expat > > p = expat.ParserCreate() > e = "utf-32" > s = (u"" % e).encode(e) > p.Parse(s, True) > > This fails with: > > Traceback (most recent call last): > File "gurk.py", line 6, in > p.Parse(s, True) > xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, > column 1 > > Replace "utf-32" with "utf-16" and the problem goes away. > > > and where adding such a codec > > solves that problem? > > > > In particular, why would that parser know how to process Python Unicode > > strings? > > It doesn't have to. You can use an XML encoder to reencode the unicode > string into bytes (forcing an encoding that the parser knows): > > import codecs > from xml.parsers import expat > > ci = codecs.lookup("xml-auto-detect") > p = expat.ParserCreate() > e = "utf-32" > s = (u"" % e).encode(e) > s = ci.encode(ci.decode(s)[0], encoding="utf-8")[0] > p.Parse(s, True) > > >> Furthermore encoding-detection might be part of the responsibility of > >> the XML parser, but this decoding phase is totally distinct from the > >> parsing phase, so why not put the decoding into a common library? > > > > I would not object to that - just to expose it as a codec. Adding it > > to the XML library is fine, IMO. > > But it does make sense as a codec. The decoding phase of an XML parser > has to turn a byte stream into a unicode stream. That's the job of a codec. Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc codecs to do the encoding. There's no need to create a magical mystery codec to pick out which though. It's not even sufficient for XML: 1) round-tripping a file should be done in the original encoding. Containing the auto-detected encoding within a codec doesn't let you see what it picked. 2) the encoding may be specified externally from the file/stream[1]. The xml parser needs to handle these out-of-band encodings anyway. [2] http://mail.python.org/pipermail/xml-sig/2004-October/010649.html -- Adam Olsen, aka Rhamphoryncus From martin at v.loewis.de Fri Nov 9 00:30:21 2007 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Fri, 09 Nov 2007 00:30:21 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <47337924.6030107@livinglogic.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> Message-ID: <47339C0D.50906@v.loewis.de> > ci = codecs.lookup("xml-auto-detect") > p = expat.ParserCreate() > e = "utf-32" > s = (u"" % e).encode(e) > s = ci.encode(ci.decode(s)[0], encoding="utf-8")[0] > p.Parse(s, True) So how come the document being parsed is recognized as UTF-8? > OK, so should I put the C code into a _xml module? I don't see the need for C code at all. Regards, Martin From greg at krypto.org Fri Nov 9 03:05:25 2007 From: greg at krypto.org (Gregory P. Smith) Date: Thu, 8 Nov 2007 18:05:25 -0800 Subject: [Python-Dev] hex() and oct() still include the trailing L - change this in 2.6? Message-ID: <52dc1c820711081805u7b05162ag82fb32ce640e53a4@mail.gmail.com> I thought the hell of stripping trailing Ls off of stringed numbers was gone but it appears that the hex() and oct() builtins still leave the trailing 'L' on longs: Python 2.6a0 (trunk:58846M, Nov 4 2007, 15:44:12) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> x = 0xffffffffc10025be >>> x 18446744072652596670L >>> str(x) '18446744072652596670' >>> hex(x) '0xffffffffc10025beL' >>> '0x%x' % (x) '0xffffffffc10025be' >>> oct(x) '01777777777770100022676L' This appears to be fixed in py3k (as there is no longer an int/long to distinguish). Can we at least get rid of the annoying L in 2.6? -gps -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20071108/a750ec67/attachment.htm From brett at python.org Fri Nov 9 03:18:36 2007 From: brett at python.org (Brett Cannon) Date: Thu, 8 Nov 2007 18:18:36 -0800 Subject: [Python-Dev] hex() and oct() still include the trailing L - change this in 2.6? In-Reply-To: <52dc1c820711081805u7b05162ag82fb32ce640e53a4@mail.gmail.com> References: <52dc1c820711081805u7b05162ag82fb32ce640e53a4@mail.gmail.com> Message-ID: On Nov 8, 2007 6:05 PM, Gregory P. Smith wrote: > I thought the hell of stripping trailing Ls off of stringed numbers was gone > but it appears that the hex() and oct() builtins still leave the trailing > 'L' on longs: > > Python 2.6a0 (trunk:58846M, Nov 4 2007, 15:44:12) > [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> x = 0xffffffffc10025be > >>> x > 18446744072652596670L > >>> str(x) > '18446744072652596670' > >>> hex(x) > '0xffffffffc10025beL' > >>> '0x%x' % (x) > '0xffffffffc10025be' > >>> oct(x) > '01777777777770100022676L' > > This appears to be fixed in py3k (as there is no longer an int/long to > distinguish). Can we at least get rid of the annoying L in 2.6? It will break code, so probably not. Consider this motivation to move over to Python 3.0. =) -Brett From guido at python.org Fri Nov 9 04:17:36 2007 From: guido at python.org (Guido van Rossum) Date: Thu, 8 Nov 2007 19:17:36 -0800 Subject: [Python-Dev] hex() and oct() still include the trailing L - change this in 2.6? In-Reply-To: References: <52dc1c820711081805u7b05162ag82fb32ce640e53a4@mail.gmail.com> Message-ID: On Nov 8, 2007 6:18 PM, Brett Cannon wrote: > On Nov 8, 2007 6:05 PM, Gregory P. Smith wrote: > > I thought the hell of stripping trailing Ls off of stringed numbers was gone > > but it appears that the hex() and oct() builtins still leave the trailing > > 'L' on longs: > > > > Python 2.6a0 (trunk:58846M, Nov 4 2007, 15:44:12) > > [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. > > >>> x = 0xffffffffc10025be > > >>> x > > 18446744072652596670L > > >>> str(x) > > '18446744072652596670' > > >>> hex(x) > > '0xffffffffc10025beL' > > >>> '0x%x' % (x) > > '0xffffffffc10025be' > > >>> oct(x) > > '01777777777770100022676L' > > > > This appears to be fixed in py3k (as there is no longer an int/long to > > distinguish). Can we at least get rid of the annoying L in 2.6? > > It will break code, so probably not. Consider this motivation to move > over to Python 3.0. =) Right. Or perhaps in some kind of forward compatibility mode. A future import might do: from __future__ import no_long_suffix perhaps. Reminder (I can't say this enough): Python 2.6 needs to be as close as possible to 2.5, only adding forward compatibility with 3.0 as an option (using either a command line flag or a future import depending on what feature we're talking about). Additions and improvements are fine of course; but deletions or changes "in anticipation of 3.0" should not occur by default, only when a specific forward compatibility feature is requested. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From walter at livinglogic.de Fri Nov 9 11:41:28 2007 From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=) Date: Fri, 09 Nov 2007 11:41:28 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> Message-ID: <47343958.6090309@livinglogic.de> Adam Olsen wrote: > On 11/8/07, Walter D?rwald wrote: >> [...] >>>> Furthermore encoding-detection might be part of the responsibility of >>>> the XML parser, but this decoding phase is totally distinct from the >>>> parsing phase, so why not put the decoding into a common library? >>> I would not object to that - just to expose it as a codec. Adding it >>> to the XML library is fine, IMO. >> But it does make sense as a codec. The decoding phase of an XML parser >> has to turn a byte stream into a unicode stream. That's the job of a codec. > > Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc > codecs to do the encoding. There's no need to create a magical > mystery codec to pick out which though. So the code is good, if it is inside an XML parser, and it's bad if it is inside a codec? > It's not even sufficient for > XML: > > 1) round-tripping a file should be done in the original encoding. > Containing the auto-detected encoding within a codec doesn't let you > see what it picked. The chosen encoding is available from the incremental encoder: import codecs e = codecs.getincrementalencoder("xml-auto-detect")() e.encode(u"", True) print e.encoding This prints utf-32. > 2) the encoding may be specified externally from the file/stream[1]. > The xml parser needs to handle these out-of-band encodings anyway. It does. You can pass an encoding to the stateless decoder, the incremental decoder and the streamreader. It will then use this encoding instead the one detected from the byte stream. It even will put the correct encoding into the XML declaration (if there is one): import codecs d = codecs.getdecoder("xml-auto-detect") print d("", encoding="utf-8")[0] This prints: Servus, Walter From walter at livinglogic.de Fri Nov 9 11:51:38 2007 From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=) Date: Fri, 09 Nov 2007 11:51:38 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <47339C0D.50906@v.loewis.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47339C0D.50906@v.loewis.de> Message-ID: <47343BBA.9090800@livinglogic.de> Martin v. L?wis wrote: >> ci = codecs.lookup("xml-auto-detect") >> p = expat.ParserCreate() >> e = "utf-32" >> s = (u"" % e).encode(e) >> s = ci.encode(ci.decode(s)[0], encoding="utf-8")[0] >> p.Parse(s, True) > > So how come the document being parsed is recognized as UTF-8? Because you can force the encoder to use a specified encoding. If you do this and the unicode string starts with an XML declaration, the encoder will put the specified encoding into the declaration: import codecs e = codecs.getencoder("xml-auto-detect") print e(u"", encoding="utf-8")[0] This prints: >> OK, so should I put the C code into a _xml module? > > I don't see the need for C code at all. Doing the bit fiddling for Modules/_codecsmodule.c::detect_xml_encoding_str() in C felt like the right thing to do. Servus, Walter From martin at v.loewis.de Fri Nov 9 12:56:17 2007 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Fri, 09 Nov 2007 12:56:17 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <47343958.6090309@livinglogic.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> Message-ID: <47344AE1.1030707@v.loewis.de> >> Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc >> codecs to do the encoding. There's no need to create a magical >> mystery codec to pick out which though. > > So the code is good, if it is inside an XML parser, and it's bad if it > is inside a codec? Exactly so. This functionality just *isn't* a codec - there is no encoding. Instead, it is an algorithm for *detecting* an encoding. Regards, Martin From martin at v.loewis.de Fri Nov 9 13:01:57 2007 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Fri, 09 Nov 2007 13:01:57 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <47343BBA.9090800@livinglogic.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47339C0D.50906@v.loewis.de> <47343BBA.9090800@livinglogic.de> Message-ID: <47344C35.60807@v.loewis.de> > Because you can force the encoder to use a specified encoding. If you do > this and the unicode string starts with an XML declaration So what if the unicode string doesn't start with an XML declaration? Will it add one? If so, what version number will it use? >>> OK, so should I put the C code into a _xml module? >> I don't see the need for C code at all. > > Doing the bit fiddling for > Modules/_codecsmodule.c::detect_xml_encoding_str() in C felt like the > right thing to do. Hmm. I don't think a sequence like + if (strlen>0) + { + if (*str++ != '<') + return 1; + if (strlen>1) + { + if (*str++ != '?') + return 1; + if (strlen>2) + { + if (*str++ != 'x') + return 1; + if (strlen>3) + { + if (*str++ != 'm') + return 1; + if (strlen>4) + { + if (*str++ != 'l') + return 1; + if (strlen>5) + { + if (*str != ' ' && *str != '\t' && *str != '\r' && *str != '\n') + return 1; is well-maintainable C. I feel it is much better writing if not s.startswith("<=?xml"): return 1 What bit fiddling are you referring to specifically that you think is better done in C than in Python? Regards, Martin From walter at livinglogic.de Fri Nov 9 13:49:41 2007 From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=) Date: Fri, 09 Nov 2007 13:49:41 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <47344C35.60807@v.loewis.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47339C0D.50906@v.loewis.de> <47343BBA.9090800@livinglogic.de> <47344C35.60807@v.loewis.de> Message-ID: <47345765.2090606@livinglogic.de> Martin v. L?wis wrote: >> Because you can force the encoder to use a specified encoding. If you do >> this and the unicode string starts with an XML declaration > > So what if the unicode string doesn't start with an XML declaration? > Will it add one? No. > If so, what version number will it use? If we added this we could add an extra argument version to the encoder constructor defaulting to '1.0'. >>>> OK, so should I put the C code into a _xml module? >>> I don't see the need for C code at all. >> Doing the bit fiddling for >> Modules/_codecsmodule.c::detect_xml_encoding_str() in C felt like the >> right thing to do. > > Hmm. I don't think a sequence like > > + if (strlen>0) > + { > + if (*str++ != '<') > + return 1; > + if (strlen>1) > + { > + if (*str++ != '?') > + return 1; > + if (strlen>2) > + { > + if (*str++ != 'x') > + return 1; > + if (strlen>3) > + { > + if (*str++ != 'm') > + return 1; > + if (strlen>4) > + { > + if (*str++ != 'l') > + return 1; > + if (strlen>5) > + { > + if (*str != ' ' && *str != '\t' && *str != > '\r' && *str != '\n') > + return 1; > > is well-maintainable C. I feel it is much better writing > > if not s.startswith("<=?xml"): > return 1 The point of this code is not just to return whether the string starts with " What bit fiddling are you referring to specifically that you think > is better done in C than in Python? The code that checks the byte signature, i.e. the first part of detect_xml_encoding_str(). Servus, Walter From walter at livinglogic.de Fri Nov 9 14:10:24 2007 From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=) Date: Fri, 09 Nov 2007 14:10:24 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <47344AE1.1030707@v.loewis.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> Message-ID: <47345C40.1030002@livinglogic.de> Martin v. L?wis wrote: >>> Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc >>> codecs to do the encoding. There's no need to create a magical >>> mystery codec to pick out which though. >> So the code is good, if it is inside an XML parser, and it's bad if it >> is inside a codec? > > Exactly so. This functionality just *isn't* a codec - there is no > encoding. Instead, it is an algorithm for *detecting* an encoding. And what do you do once you've detected the encoding? You decode the input, so why not combine both into an XML decoder? Servus, Walter From mal at egenix.com Fri Nov 9 14:22:35 2007 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 09 Nov 2007 14:22:35 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <47345C40.1030002@livinglogic.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> Message-ID: <47345F1B.4090907@egenix.com> On 2007-11-09 14:10, Walter D?rwald wrote: > Martin v. L?wis wrote: >>>> Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc >>>> codecs to do the encoding. There's no need to create a magical >>>> mystery codec to pick out which though. >>> So the code is good, if it is inside an XML parser, and it's bad if it >>> is inside a codec? >> Exactly so. This functionality just *isn't* a codec - there is no >> encoding. Instead, it is an algorithm for *detecting* an encoding. > > And what do you do once you've detected the encoding? You decode the > input, so why not combine both into an XML decoder? FWIW: I'm +1 on adding such a codec. It makes working with XML data a lot easier: you simply don't have to bother with the encoding of the XML data anymore and can just let the codec figure out the details. The XML parser can then work directly on the Unicode data. Whether it needs to be in C or not is another question (I would have done this in Python since performance is not really an issue), but since the code is already written, why not use it ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 09 2007) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From walter at livinglogic.de Fri Nov 9 14:41:37 2007 From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=) Date: Fri, 09 Nov 2007 14:41:37 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <47345C40.1030002@livinglogic.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> Message-ID: <47346391.5040200@livinglogic.de> Walter D?rwald wrote: > Martin v. L?wis wrote: >>>> Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc >>>> codecs to do the encoding. There's no need to create a magical >>>> mystery codec to pick out which though. >>> So the code is good, if it is inside an XML parser, and it's bad if it >>> is inside a codec? >> Exactly so. This functionality just *isn't* a codec - there is no >> encoding. Instead, it is an algorithm for *detecting* an encoding. > > And what do you do once you've detected the encoding? You decode the > input, so why not combine both into an XML decoder? In fact, we already have such a codec. The utf-16 decoder looks at the first two bytes and then decides to forward the rest to either a utf-16-be or a utf-16-le decoder. Servus, Walter From walter at livinglogic.de Fri Nov 9 14:44:30 2007 From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=) Date: Fri, 09 Nov 2007 14:44:30 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <47345F1B.4090907@egenix.com> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> Message-ID: <4734643E.1030704@livinglogic.de> M.-A. Lemburg wrote: > On 2007-11-09 14:10, Walter D?rwald wrote: >> Martin v. L?wis wrote: >>>>> Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc >>>>> codecs to do the encoding. There's no need to create a magical >>>>> mystery codec to pick out which though. >>>> So the code is good, if it is inside an XML parser, and it's bad if it >>>> is inside a codec? >>> Exactly so. This functionality just *isn't* a codec - there is no >>> encoding. Instead, it is an algorithm for *detecting* an encoding. >> And what do you do once you've detected the encoding? You decode the >> input, so why not combine both into an XML decoder? > > FWIW: I'm +1 on adding such a codec. > > It makes working with XML data a lot easier: you simply don't have to > bother with the encoding of the XML data anymore and can just let the > codec figure out the details. The XML parser can then work directly > on the Unicode data. Exactly. I have a version of sgmlop lying around that does that. > Whether it needs to be in C or not is another question (I would have > done this in Python since performance is not really an issue), but since > the code is already written, why not use it ? Servus, Walter From fdrake at acm.org Fri Nov 9 15:15:50 2007 From: fdrake at acm.org (Fred Drake) Date: Fri, 9 Nov 2007 09:15:50 -0500 Subject: [Python-Dev] XML codec? In-Reply-To: <47345F1B.4090907@egenix.com> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> Message-ID: On Nov 9, 2007, at 8:22 AM, M.-A. Lemburg wrote: > FWIW: I'm +1 on adding such a codec. I'm undecided, and really don't feel strongly either way. > It makes working with XML data a lot easier: you simply don't have to > bother with the encoding of the XML data anymore and can just let the > codec figure out the details. The XML parser can then work directly > on the Unicode data. Which is fine if you want to write a new parser. I've no interest in that myself. > Whether it needs to be in C or not is another question (I would have > done this in Python since performance is not really an issue), but > since > the code is already written, why not use it ? The reason not to use C is the usual one: The implementation is more cross-implementation if it's written in Python. This makes it more useful with Jython, IronPython, and PyPy. That seems a pretty good reason to me. -Fred -- Fred Drake From lists at cheimes.de Fri Nov 9 18:05:08 2007 From: lists at cheimes.de (Christian Heimes) Date: Fri, 09 Nov 2007 18:05:08 +0100 Subject: [Python-Dev] Bug tracker: meaning of resolution keywords Message-ID: <47349344.5040306@cheimes.de> Hello! Guido has granted me committer privileges to svn.python.org and bugs.python.org about a week ago. So I'm new and new people tend to make mistakes until they've learned the specific rules of a project. Today I've learned that the resolution keyword "accepted" doesn't mean the bug report is accepted. It only means a patch for the bug is accepted. In the past I've used "accepted" in the meaning of "bug is confirmed" in my own projects. In my ignorance I've used it in the same way to mark bugs as confirmed when I was able to reproduce the bug myself. The tracker doc at http://wiki.python.org/moin/TrackerDocs/ doesn't have a formal definition of the various keywords. I like to add a definition to the wiki to prevent others from making the same mistake. But first I like to discuss my view of the keywords Resolutions *********** accepted - patch accepted confirmed (*) - the problem is confirmed duplicate - the bug is a duplicated of another bug fixed - the bug is fixed / patch is applied invalid - catch all for invalid reports later - the problem is going to be addressed later in the release cycle out of date - the bug was already fixed in svn postponed - the problem is going to be fixed in the next minor version rejected - the patch or feature request is rejected remind - remind me to finish the task (docs, unit tests) wont fix - it's not a bug, it's a feature works for me - unable to reproduce the problem (*) It's missing from the list of resolutions but I like to have it added. http://psf.upfronthosting.co.za/roundup/meta/issue167 Priority ******* immediate - the bug must be fixed *NOW* (only used for important security related problems) urgent - the problem must be fixed ASAP because it's crucial for future development high - the problem should be fixed soonish and must be fixed for the next release normal - the problem should be fixed for the next release low - nice to have features and fixes Christian From lists at cheimes.de Fri Nov 9 18:17:29 2007 From: lists at cheimes.de (Christian Heimes) Date: Fri, 09 Nov 2007 18:17:29 +0100 Subject: [Python-Dev] Bug tracker: meaning of resolution keywords In-Reply-To: <47349344.5040306@cheimes.de> References: <47349344.5040306@cheimes.de> Message-ID: <47349629.2050101@cheimes.de> Christian Heimes wrote: > (*) It's missing from the list of resolutions but I like to have it > added. http://psf.upfronthosting.co.za/roundup/meta/issue167 Update: Georg Brandl pointed out that it makes more sense to add confirmed to status. Christian From status at bugs.python.org Fri Nov 9 19:06:06 2007 From: status at bugs.python.org (Tracker) Date: Fri, 9 Nov 2007 18:06:06 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071109180606.7D31578385@psf.upfronthosting.co.za> ACTIVITY SUMMARY (11/02/07 - 11/09/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1322 open (+23) / 11575 closed (+18) / 12897 total (+41) Open issues with patches: 418 Average duration of open issues: 686 days. Median duration of open issues: 788 days. Open Issues Breakdown open 1317 (+23) pending 5 ( +0) Issues Created Or Reopened (41) _______________________________ IDLE - minor FormatParagraph bug fix 11/02/07 http://bugs.python.org/issue1374 created taleinat patch hotshot IndexError when loading stats 11/02/07 http://bugs.python.org/issue1375 created ratsberg uu module catches a wrong exception type 11/02/07 CLOSED http://bugs.python.org/issue1376 created billiejoex test_import breaks on Linux 11/09/07 http://bugs.python.org/issue1377 reopened gvanrossum py3k fromfd() and dup() for _socket on WIndows 11/03/07 http://bugs.python.org/issue1378 created roudkerk patch reloading imported modules sometimes fail with 'parent not in sy 11/03/07 CLOSED http://bugs.python.org/issue1379 created _doublep py3k, patch fix for test_asynchat and test_asyncore on pep3137 branch 11/03/07 CLOSED http://bugs.python.org/issue1380 created hupp py3k, patch cmath is numerically unsound 11/03/07 http://bugs.python.org/issue1381 created inducer py3k-pep3137: patch for test_ctypes 11/04/07 CLOSED http://bugs.python.org/issue1382 created amaury.forgeotdarc py3k, patch Backport abcoll to 2.6 11/04/07 http://bugs.python.org/issue1383 created baranguren patch Windows fix for inspect tests 11/04/07 CLOSED http://bugs.python.org/issue1384 created tiran py3k, patch hmac module violates RFC for some hash functions, e.g. sha512 11/04/07 CLOSED http://bugs.python.org/issue1385 created jowagner py3k py3k-pep3137: patch to ensure that all codecs return bytes 11/04/07 CLOSED http://bugs.python.org/issue1386 created amaury.forgeotdarc py3k, patch py3k-pep3137: patch for hashlib on Windows 11/04/07 CLOSED http://bugs.python.org/issue1387 created amaury.forgeotdarc py3k, patch py3k-pep3137: possible ref leak in ctypes 11/05/07 CLOSED http://bugs.python.org/issue1388 created tiran py3k py3k-pep3137: struct module is leaking references 11/05/07 CLOSED http://bugs.python.org/issue1389 created tiran py3k toxml generates output that is not well formed 11/05/07 http://bugs.python.org/issue1390 created drtomc Adds the .compact() method to bsddb db.DB objects 11/05/07 http://bugs.python.org/issue1391 created gregory.p.smith patch, rfe py3k-pep3137: issue warnings / errors on str(bytes()) and simila 11/05/07 CLOSED http://bugs.python.org/issue1392 created tiran py3k, patch function comparing lacks NotImplemented error 11/05/07 http://bugs.python.org/issue1393 created _doublep simple patch, improving unreachable bytecode removing 11/05/07 http://bugs.python.org/issue1394 created _doublep patch py3k: duplicated line endings when using read(1) 11/06/07 http://bugs.python.org/issue1395 created amaury.forgeotdarc py3k py3k-pep3137: patch for mailbox 11/06/07 CLOSED http://bugs.python.org/issue1396 created tiran py3k, patch py3k-pep3137: failing unit test test_bsddb 11/06/07 http://bugs.python.org/issue1397 created tiran py3k Can't pickle partial functions 11/07/07 CLOSED http://bugs.python.org/issue1398 created danhs XML codec 11/07/07 http://bugs.python.org/issue1399 created doerwalter patch Py3k's print() flushing problem 11/07/07 http://bugs.python.org/issue1400 created wojtekwalczak py3k urllib2 302 POST 11/07/07 http://bugs.python.org/issue1401 created andresriancho Interpreter cleanup: order of _PyGILState_Fini and PyInterpreter 11/07/07 http://bugs.python.org/issue1402 created ronaldoussoren py_compile and compileall need unit tests 11/08/07 http://bugs.python.org/issue1403 created tiran py3k warnings module bug: BytesWarning: str() on a bytes instance 11/08/07 CLOSED http://bugs.python.org/issue1404 created tiran patch Garbage collection not working correctly in Python 2.3 11/08/07 CLOSED http://bugs.python.org/issue1405 created pythonmeister Use widechar api for os.environ 11/08/07 CLOSED http://bugs.python.org/issue1406 created theller py3k, patch [performance] Too many closed() checkings 11/08/07 http://bugs.python.org/issue1407 created wojtekwalczak py3k Inconsistence in multiply list 11/08/07 CLOSED http://bugs.python.org/issue1408 created beco new keyword-only function parameters interact badly with nested 11/08/07 http://bugs.python.org/issue1409 created _doublep py3k BaseHTTPServer cannot accept Unicode data 11/08/07 http://bugs.python.org/issue1410 created isonno A typo in tutorial 11/09/07 CLOSED http://bugs.python.org/issue1411 created falsetru test_subprocess fails on SuSE 10 11/09/07 http://bugs.python.org/issue1412 created dvadasz int literal methods inaccessible 11/09/07 http://bugs.python.org/issue1413 created mykhal Fix for refleak tests 11/09/07 http://bugs.python.org/issue1414 created tiran py3k, patch Issues Now Closed (36) ______________________ test_glob fails with UnicodeDecodeError 72 days http://bugs.python.org/issue1042 tiran rfe py3k: corrections for test_subprocess on windows 72 days http://bugs.python.org/issue1047 tiran patch file.seek allows float arguments 68 days http://bugs.python.org/issue1081 tiran py3k test_email failed 67 days http://bugs.python.org/issue1086 tiran rfe py3k os.popen result is not iterable, patch attached 67 days http://bugs.python.org/issue1087 tiran patch decode_unicode doesn't nul-terminate 60 days http://bugs.python.org/issue1098 georg.brandl Problems with the msi installer - python-3.0a1.msi 64 days http://bugs.python.org/issue1110 tiran No tests for inspect.getfullargspec() 63 days http://bugs.python.org/issue1127 tiran py3k, patch test_urllib2net fails on test_ftp 57 days http://bugs.python.org/issue1157 tiran py3k Should itertools.count work for arbitrary integers? 53 days http://bugs.python.org/issue1165 rhettinger py3k allow subclassing of bytes type 46 days http://bugs.python.org/issue1171 gvanrossum py3k, patch test fixes for immutable bytes change 43 days http://bugs.python.org/issue1184 gvanrossum py3k, patch Trailing slash in sys.path cause import failure 20 days http://bugs.python.org/issue1293 gvanrossum patch Fix for test_netrc on Windows 9 days http://bugs.python.org/issue1345 tiran py3k, patch Preliminary stderr patch 5 days http://bugs.python.org/issue1352 loewis uu module catches a wrong exception type 1 days http://bugs.python.org/issue1376 gvanrossum reloading imported modules sometimes fail with 'parent not in sy 1 days http://bugs.python.org/issue1379 _doublep py3k, patch fix for test_asynchat and test_asyncore on pep3137 branch 0 days http://bugs.python.org/issue1380 tiran py3k, patch py3k-pep3137: patch for test_ctypes 0 days http://bugs.python.org/issue1382 tiran py3k, patch Windows fix for inspect tests 2 days http://bugs.python.org/issue1384 tiran py3k, patch hmac module violates RFC for some hash functions, e.g. sha512 2 days http://bugs.python.org/issue1385 jowagner py3k py3k-pep3137: patch to ensure that all codecs return bytes 0 days http://bugs.python.org/issue1386 tiran py3k, patch py3k-pep3137: patch for hashlib on Windows 0 days http://bugs.python.org/issue1387 tiran py3k, patch py3k-pep3137: possible ref leak in ctypes 1 days http://bugs.python.org/issue1388 tiran py3k py3k-pep3137: struct module is leaking references 1 days http://bugs.python.org/issue1389 gvanrossum py3k py3k-pep3137: issue warnings / errors on str(bytes()) and simila 1 days http://bugs.python.org/issue1392 tiran py3k, patch py3k-pep3137: patch for mailbox 0 days http://bugs.python.org/issue1396 gvanrossum py3k, patch Can't pickle partial functions 1 days http://bugs.python.org/issue1398 tiran warnings module bug: BytesWarning: str() on a bytes instance 0 days http://bugs.python.org/issue1404 tiran patch Garbage collection not working correctly in Python 2.3 0 days http://bugs.python.org/issue1405 tiran Use widechar api for os.environ 0 days http://bugs.python.org/issue1406 theller py3k, patch Inconsistence in multiply list 1 days http://bugs.python.org/issue1408 georg.brandl A typo in tutorial 0 days http://bugs.python.org/issue1411 georg.brandl Error on handling nan 1637 days http://bugs.python.org/issue737648 mike.verdone contextmanager eats StopIteration 199 days http://bugs.python.org/issue1705170 ncoghlan PyHeapTypeObject fix 114 days http://bugs.python.org/issue1752184 gvanrossum py3k, patch Top Issues Most Discussed (10) ______________________________ 35 py3k: duplicated line endings when using read(1) 4 days open http://bugs.python.org/issue1395 16 toxml generates output that is not well formed 5 days open http://bugs.python.org/issue1390 15 py3k-pep3137: issue warnings / errors on str(bytes()) and simil 1 days closed http://bugs.python.org/issue1392 9 Trailing slash in sys.path cause import failure 20 days closed http://bugs.python.org/issue1293 7 urllib2 302 POST 2 days open http://bugs.python.org/issue1401 6 new keyword-only function parameters interact badly with nested 1 days open http://bugs.python.org/issue1409 6 XML codec 2 days open http://bugs.python.org/issue1399 5 py3k-pep3137: patch for mailbox 0 days closed http://bugs.python.org/issue1396 5 Windows fix for inspect tests 2 days closed http://bugs.python.org/issue1384 5 cmath is numerically unsound 6 days open http://bugs.python.org/issue1381 From martin at v.loewis.de Fri Nov 9 19:55:51 2007 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Fri, 09 Nov 2007 19:55:51 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <47345765.2090606@livinglogic.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47339C0D.50906@v.loewis.de> <47343BBA.9090800@livinglogic.de> <47344C35.60807@v.loewis.de> <47345765.2090606@livinglogic.de> Message-ID: <4734AD37.5070209@v.loewis.de> >> So what if the unicode string doesn't start with an XML declaration? >> Will it add one? > > No. Ok. So the XML document would be ill-formed then unless the encoding is UTF-8, right? > The point of this code is not just to return whether the string starts > with " * The string does start with " * The string starts with a prefix of " decide if it starts with " * The string definitely doesn't start with "> What bit fiddling are you referring to specifically that you think >> is better done in C than in Python? > > The code that checks the byte signature, i.e. the first part of > detect_xml_encoding_str(). I can't see any *bit* fiddling there, except for the bit mask of candidates. For the candidate list, I cannot quite understand why you need a bit mask at all, since the candidates are rarely overlapping. I think there could be a much simpler routine to have the same effect. - if it's less than 4 bytes, answer "need more data". - otherwise, implement annex F "literally". Make a dictionary of all prefixes that are exactly 4 bytes, i.e. prefixes4 = {"\x00\x00\xFE\xFF":"utf-32be", ... ..., "\0\x3c\0\x3f":"utf-16le"} try: return prefixes4[s[:4]] except KeyError: pass if s.startswith(codecs.BOM_UTF16_BE):return "utf-16be" ... if s.startswith(" References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> Message-ID: <4734AE22.3000004@v.loewis.de> > And what do you do once you've detected the encoding? You decode the > input, so why not combine both into an XML decoder? Because it is the XML parser that does the decoding, not the application. Also, it is better to provide functionality in a modular manner (i.e. encoding detection separately from encodings), and leaving integration of modules to the application, in particular if the integration is trivial. Regards, Martin From rhamph at gmail.com Fri Nov 9 21:35:11 2007 From: rhamph at gmail.com (Adam Olsen) Date: Fri, 9 Nov 2007 13:35:11 -0700 Subject: [Python-Dev] XML codec? In-Reply-To: <47345C40.1030002@livinglogic.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> Message-ID: On Nov 9, 2007 6:10 AM, Walter D?rwald wrote: > > Martin v. L?wis wrote: > >>> Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc > >>> codecs to do the encoding. There's no need to create a magical > >>> mystery codec to pick out which though. > >> So the code is good, if it is inside an XML parser, and it's bad if it > >> is inside a codec? > > > > Exactly so. This functionality just *isn't* a codec - there is no > > encoding. Instead, it is an algorithm for *detecting* an encoding. > > And what do you do once you've detected the encoding? You decode the > input, so why not combine both into an XML decoder? It seems to me that parsing XML requires 3 steps: 1) determine encoding 2) decode byte stream 3) parse XML (including handling of character references) All an xml codec does is make the first part a side-effect of the second part. Rather than this: encoding = detect_encoding(raw_data) decoded_data = raw_data.decode(encoding) tree = parse_xml(decoded_data, encoding) # Verifies encoding You'd have this: e = codecs.getincrementaldecoder("xml-auto-detect")() decoded_data = e.decode(raw_data, True) tree = parse_xml(decoded_data, e.encoding) # Verifies encoding It's clear to me that detecting an encoding is actually the simplest part of all this (so long as there's an API to do it!) Putting it inside a codec seems like the wrong subdivision of responsibility. (An example using streams would end up closer, but it still seems wrong to me. Encoding detection is always one way, while codecs are always two way (even if lossy.)) -- Adam Olsen, aka Rhamphoryncus From martin at v.loewis.de Fri Nov 9 22:26:02 2007 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Fri, 09 Nov 2007 22:26:02 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <47345F1B.4090907@egenix.com> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> Message-ID: <4734D06A.2020000@v.loewis.de> > It makes working with XML data a lot easier: you simply don't have to > bother with the encoding of the XML data anymore and can just let the > codec figure out the details. The XML parser can then work directly > on the Unicode data. Having the functionality indeed makes things easier. However, I don't find s.decode(xml.detect_encoding(s)) particularly more difficult than s.decode("xml-auto-detection") > Whether it needs to be in C or not is another question (I would have > done this in Python since performance is not really an issue), but since > the code is already written, why not use it ? It's a maintenance issue. Regards, Martin From martin at v.loewis.de Fri Nov 9 22:27:26 2007 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Fri, 09 Nov 2007 22:27:26 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <47346391.5040200@livinglogic.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47346391.5040200@livinglogic.de> Message-ID: <4734D0BE.9010100@v.loewis.de> > In fact, we already have such a codec. The utf-16 decoder looks at the > first two bytes and then decides to forward the rest to either a > utf-16-be or a utf-16-le decoder. That's different. UTF-16 is a proper encoding that is just specified to use the BOM. "xml-auto-detection" is not an encoding. Regards, Martin From martin at v.loewis.de Fri Nov 9 22:56:32 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Fri, 09 Nov 2007 22:56:32 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> Message-ID: <4734D790.2050904@v.loewis.de> > It's clear to me that detecting an encoding is actually the simplest > part of all this (so long as there's an API to do it!) Putting it > inside a codec seems like the wrong subdivision of responsibility. In case it isn't clear - this is exactly my view also. Regards, Martin From mal at egenix.com Fri Nov 9 23:59:46 2007 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 09 Nov 2007 23:59:46 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <4734D06A.2020000@v.loewis.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> Message-ID: <4734E662.9070708@egenix.com> Martin v. L?wis wrote: >> It makes working with XML data a lot easier: you simply don't have to >> bother with the encoding of the XML data anymore and can just let the >> codec figure out the details. The XML parser can then work directly >> on the Unicode data. > > Having the functionality indeed makes things easier. However, I don't > find > > s.decode(xml.detect_encoding(s)) > > particularly more difficult than > > s.decode("xml-auto-detection") Not really, but the codec has more control over what happens to the stream, ie. it's easier to implement look-ahead in the codec than to do the detection and then try to push the bytes back onto the stream (which may or may not be possible depending on the nature of the stream). >> Whether it needs to be in C or not is another question (I would have >> done this in Python since performance is not really an issue), but since >> the code is already written, why not use it ? > > It's a maintenance issue. I'm sure Walter will do a great job in maintaining the code :-) Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 09 2007) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From rhamph at gmail.com Sat Nov 10 00:37:27 2007 From: rhamph at gmail.com (Adam Olsen) Date: Fri, 9 Nov 2007 16:37:27 -0700 Subject: [Python-Dev] XML codec? In-Reply-To: <4734E662.9070708@egenix.com> References: <4731FB82.8020001@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> Message-ID: On Nov 9, 2007 3:59 PM, M.-A. Lemburg wrote: > Martin v. L?wis wrote: > >> It makes working with XML data a lot easier: you simply don't have to > >> bother with the encoding of the XML data anymore and can just let the > >> codec figure out the details. The XML parser can then work directly > >> on the Unicode data. > > > > Having the functionality indeed makes things easier. However, I don't > > find > > > > s.decode(xml.detect_encoding(s)) > > > > particularly more difficult than > > > > s.decode("xml-auto-detection") > > Not really, but the codec has more control over what happens to > the stream, ie. it's easier to implement look-ahead in the codec > than to do the detection and then try to push the bytes back onto > the stream (which may or may not be possible depending on the > nature of the stream). io.BufferedReader() standardizes a .peek() API, making it trivial. I don't see why we couldn't require it. (As an aside, .peek() will fail to do what detect_encodings() needs if BufferedReader's buffer size is too small. I do wonder if that limitation is appropriate.) -- Adam Olsen, aka Rhamphoryncus From martin at v.loewis.de Sat Nov 10 00:53:58 2007 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 10 Nov 2007 00:53:58 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <4734E662.9070708@egenix.com> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> Message-ID: <4734F316.1040802@v.loewis.de> > Not really, but the codec has more control over what happens to > the stream, ie. it's easier to implement look-ahead in the codec > than to do the detection and then try to push the bytes back onto > the stream (which may or may not be possible depending on the > nature of the stream). YAGNI. Regards, Martin From stephen at xemacs.org Sat Nov 10 01:20:53 2007 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 10 Nov 2007 09:20:53 +0900 Subject: [Python-Dev] XML codec? In-Reply-To: <4734D790.2050904@v.loewis.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <4734D790.2050904@v.loewis.de> Message-ID: <87abpnlzmi.fsf@uwakimon.sk.tsukuba.ac.jp> "Martin v. L?wis" writes: > > It's clear to me that detecting an encoding is actually the simplest > > part of all this (so long as there's an API to do it!) Putting it > > inside a codec seems like the wrong subdivision of responsibility. > > In case it isn't clear - this is exactly my view also. But is there an API to do it? As MAL points out that API would have to return not an encoding, but a pair of an encoding and the rewound stream. For non-seekable, non-peekable streams (if any), what you'd need would be a stream that consisted of a concatenation of the buffered data used for detection and the continuation of the stream. From mal at egenix.com Sat Nov 10 01:25:11 2007 From: mal at egenix.com (M.-A. Lemburg) Date: Sat, 10 Nov 2007 01:25:11 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <4734F316.1040802@v.loewis.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> <4734F316.1040802@v.loewis.de> Message-ID: <4734FA67.10307@egenix.com> Martin v. L?wis wrote: >> Not really, but the codec has more control over what happens to >> the stream, ie. it's easier to implement look-ahead in the codec >> than to do the detection and then try to push the bytes back onto >> the stream (which may or may not be possible depending on the >> nature of the stream). > > YAGNI. A non-seekable stream is not all that uncommon in network processing. I usually end up either reading the complete data into memory or doing the needed buffering by hand. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 10 2007) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From guido at python.org Sat Nov 10 07:00:55 2007 From: guido at python.org (Guido van Rossum) Date: Fri, 9 Nov 2007 22:00:55 -0800 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: Message-ID: To follow up, I now have a patch. It's pretty straightforward. This implements the kind of syntax that I believe won over most folks in the end: @property def foo(self): ... @foo.setter def foo(self, value=None): ... There are also .getter and .deleter descriptors. This includes the hack that if you specify a setter but no deleter, the setter is called without a value argument when attempting to delete something. If the setter isn't ready for this, a TypeError will be raised, pretty much just as if no deleter was provided (just with a somewhat worse error message :-). I intend to check this into 2.6 and 3.0 unless there is a huge cry of dismay. Docs will be left to volunteers as always. --Guido On Oct 31, 2007 9:08 AM, Guido van Rossum wrote: > I've come up with a relatively unobtrusive pattern for defining > setters. Given the following definition: > > def propset(prop): > assert isinstance(prop, property) > def helper(func): > return property(prop.__get__, func, func, prop.__doc__) > return helper > > we can declare getters and setters as follows: > > class C(object): > > _encoding = None > > @property > def encoding(self): > return self._encoding > > @propset(encoding) > def encoding(self, value=None): > if value is not None: > unicode("0", value) # Test it > self._encoding = value > > c = C() > print(c.encoding) > c.encoding = "ascii" > print(c.encoding) > try: > c.encoding = "invalid" # Fails > except: > pass > print(c.encoding) > > I'd like to make this a standard built-in, in the hope the debate on > how to declare settable properties. > > I'd also like to change property so that the doc string defaults to > the doc string of the getter. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Sat Nov 10 07:03:03 2007 From: guido at python.org (Guido van Rossum) Date: Fri, 9 Nov 2007 22:03:03 -0800 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: Message-ID: D'oh. I forgot to point to the patch. It's here: http://bugs.python.org/issue1416 On Nov 9, 2007 10:00 PM, Guido van Rossum wrote: > To follow up, I now have a patch. It's pretty straightforward. > > This implements the kind of syntax that I believe won over most folks > in the end: > > @property > def foo(self): ... > > @foo.setter > def foo(self, value=None): ... > > There are also .getter and .deleter descriptors. This includes the hack > that if you specify a setter but no deleter, the setter is called > without a value argument when attempting to delete something. If the > setter isn't ready for this, a TypeError will be raised, pretty much > just as if no deleter was provided (just with a somewhat worse error > message :-). > > I intend to check this into 2.6 and 3.0 unless there is a huge cry of > dismay. Docs will be left to volunteers as always. > > --Guido > > > On Oct 31, 2007 9:08 AM, Guido van Rossum wrote: > > I've come up with a relatively unobtrusive pattern for defining > > setters. Given the following definition: > > > > def propset(prop): > > assert isinstance(prop, property) > > def helper(func): > > return property(prop.__get__, func, func, prop.__doc__) > > return helper > > > > we can declare getters and setters as follows: > > > > class C(object): > > > > _encoding = None > > > > @property > > def encoding(self): > > return self._encoding > > > > @propset(encoding) > > def encoding(self, value=None): > > if value is not None: > > unicode("0", value) # Test it > > self._encoding = value > > > > c = C() > > print(c.encoding) > > c.encoding = "ascii" > > print(c.encoding) > > try: > > c.encoding = "invalid" # Fails > > except: > > pass > > print(c.encoding) > > > > I'd like to make this a standard built-in, in the hope the debate on > > how to declare settable properties. > > > > I'd also like to change property so that the doc string defaults to > > the doc string of the getter. > > > > -- > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From goodger at python.org Sat Nov 10 04:57:56 2007 From: goodger at python.org (David Goodger) Date: Fri, 09 Nov 2007 22:57:56 -0500 Subject: [Python-Dev] Only one week left for PyCon proposals! Message-ID: <47352C44.80909@python.org> There is only one week left for PyCon tutorial & scheduled talk proposals. If you've been thinking about making a proposal, now's the time! Tutorial details and instructions here: http://us.pycon.org/2008/tutorials/proposals/ Scheduled talk details and instructions here: http://us.pycon.org/2008/conference/proposals/ The deadline is Friday, November 16. Don't put it off any longer! PyCon 2008: http://us.pycon.org -- David Goodger PyCon 2008 Chair -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://mail.python.org/pipermail/python-dev/attachments/20071109/709799bb/attachment.pgp From martin at v.loewis.de Sat Nov 10 09:52:59 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 10 Nov 2007 09:52:59 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <87abpnlzmi.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <4734D790.2050904@v.loewis.de> <87abpnlzmi.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <4735716B.1010308@v.loewis.de> > > In case it isn't clear - this is exactly my view also. > > But is there an API to do it? As MAL points out that API would have > to return not an encoding, but a pair of an encoding and the rewound > stream. The API wouldn't operate on streams. Instead, you pass a string, and it either returns the detected encoding, or an information telling that it needs more data. No streams. > For non-seekable, non-peekable streams (if any), what you'd > need would be a stream that consisted of a concatenation of the > buffered data used for detection and the continuation of the stream. The application would read data out of the stream, and pass it to the detection. It then can process it in whatever manner it meant to process it in the first place. Regards, Martin From martin at v.loewis.de Sat Nov 10 09:54:04 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 10 Nov 2007 09:54:04 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <4734FA67.10307@egenix.com> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> <4734F316.1040802@v.loewis.de> <4734FA67.10307@egenix.com> Message-ID: <473571AC.7020302@v.loewis.de> > A non-seekable stream is not all that uncommon in network processing. Right. But what is the relationship to XML encoding autodetection? Regards, Martin From walter at livinglogic.de Sat Nov 10 16:55:41 2007 From: walter at livinglogic.de (Walter =?iso-8859-1?Q?D=F6rwald?=) Date: Sat, 10 Nov 2007 16:55:41 +0100 (CET) Subject: [Python-Dev] XML codec? In-Reply-To: <4734AD37.5070209@v.loewis.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47339C0D.50906@v.loewis.de> <47343BBA.9090800@livinglogic.de> <47344C35.60807@v.loewis.de> <47345765.2090606@livinglogic.de> <4734AD37.5070209@v.loewis.de> Message-ID: <61862.89.54.66.61.1194710141.squirrel@isar.livinglogic.de> "Martin v. L??wis" sagte: >>> So what if the unicode string doesn't start with an XML declaration? >>> Will it add one? >> >> No. > > Ok. So the XML document would be ill-formed then unless the encoding is > UTF-8, right? I don't know. Is an XML document ill-formed if it doesn't contain an XML declaration, is not in UTF-8 or UTF-8, but there's external encoding info? If it is, then yes, the document would be ill-formed. >> The point of this code is not just to return whether the string starts >> with " > Still, it's overly complex for that matter: > >> * The string does start with " > if s.startswith(" return Yes > >> * The string starts with a prefix of "> decide if it starts with " > if " return Maybe > >> * The string definitely doesn't start with " > return No This looks good. Now we would have to extent the code to detect and replace the encoding in the XML declaration too. >>> What bit fiddling are you referring to specifically that you think >>> is better done in C than in Python? >> >> The code that checks the byte signature, i.e. the first part of >> detect_xml_encoding_str(). > > I can't see any *bit* fiddling there, except for the bit mask of > candidates. For the candidate list, I cannot quite understand why > you need a bit mask at all, since the candidates are rarely > overlapping. I tried many variants and that seemed to be the most straitforward one. > I think there could be a much simpler routine to have the same > effect. > - if it's less than 4 bytes, answer "need more data". Can there be an XML document that is less then 4 bytes? I guess not. > - otherwise, implement annex F "literally". Make a dictionary > of all prefixes that are exactly 4 bytes, i.e. > > prefixes4 = {"\x00\x00\xFE\xFF":"utf-32be", ... > ..., "\0\x3c\0\x3f":"utf-16le"} > > try: return prefixes4[s[:4]] > except KeyError: pass > if s.startswith(codecs.BOM_UTF16_BE):return "utf-16be" > ... > if s.startswith(" return get_encoding_from_declaration(s) > return "utf-8" get_encoding_from_declaration() would have to do the same yes/no/maybe decision. But anyway: would a Python implementation of these two functions (detect_encoding()/fix_encoding()) be accepted? Servus, Walter From walter at livinglogic.de Sat Nov 10 17:15:29 2007 From: walter at livinglogic.de (Walter =?iso-8859-1?Q?D=F6rwald?=) Date: Sat, 10 Nov 2007 17:15:29 +0100 (CET) Subject: [Python-Dev] XML codec? In-Reply-To: <4734AE22.3000004@v.loewis.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <4734AE22.3000004@v.loewis.de> Message-ID: <61869.89.54.66.61.1194711329.squirrel@isar.livinglogic.de> "Martin v. L??wis" sagte: >> And what do you do once you've detected the encoding? You decode the >> input, so why not combine both into an XML decoder? > > Because it is the XML parser that does the decoding, not the > application. Also, it is better to provide functionality in > a modular manner (i.e. encoding detection separately from > encodings), It is separate. Detection is done by codecs.detect_xml_encoding(), decoding is done by the codec. > and leaving integration of modules to the application, > in particular if the integration is trivial. Servus, Walter From status at bugs.python.org Sat Nov 10 19:06:06 2007 From: status at bugs.python.org (Tracker) Date: Sat, 10 Nov 2007 18:06:06 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071110180606.620717838B@psf.upfronthosting.co.za> ACTIVITY SUMMARY (11/03/07 - 11/10/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1322 open (+21) / 11579 closed (+18) / 12901 total (+39) Open issues with patches: 419 Average duration of open issues: 687 days. Median duration of open issues: 789 days. Open Issues Breakdown open 1317 (+21) pending 5 ( +0) Issues Created Or Reopened (40) _______________________________ test_import breaks on Linux 11/09/07 http://bugs.python.org/issue1377 reopened gvanrossum py3k fix for test_asynchat and test_asyncore on pep3137 branch 11/03/07 CLOSED http://bugs.python.org/issue1380 created hupp py3k, patch cmath is numerically unsound 11/03/07 http://bugs.python.org/issue1381 created inducer py3k-pep3137: patch for test_ctypes 11/04/07 CLOSED http://bugs.python.org/issue1382 created amaury.forgeotdarc py3k, patch Backport abcoll to 2.6 11/04/07 http://bugs.python.org/issue1383 created baranguren patch Windows fix for inspect tests 11/04/07 CLOSED http://bugs.python.org/issue1384 created tiran py3k, patch hmac module violates RFC for some hash functions, e.g. sha512 11/04/07 CLOSED http://bugs.python.org/issue1385 created jowagner py3k py3k-pep3137: patch to ensure that all codecs return bytes 11/04/07 CLOSED http://bugs.python.org/issue1386 created amaury.forgeotdarc py3k, patch py3k-pep3137: patch for hashlib on Windows 11/04/07 CLOSED http://bugs.python.org/issue1387 created amaury.forgeotdarc py3k, patch py3k-pep3137: possible ref leak in ctypes 11/05/07 CLOSED http://bugs.python.org/issue1388 created tiran py3k py3k-pep3137: struct module is leaking references 11/05/07 CLOSED http://bugs.python.org/issue1389 created tiran py3k toxml generates output that is not well formed 11/05/07 http://bugs.python.org/issue1390 created drtomc Adds the .compact() method to bsddb db.DB objects 11/05/07 http://bugs.python.org/issue1391 created gregory.p.smith patch, rfe py3k-pep3137: issue warnings / errors on str(bytes()) and simila 11/05/07 CLOSED http://bugs.python.org/issue1392 created tiran py3k, patch function comparing lacks NotImplemented error 11/05/07 http://bugs.python.org/issue1393 created _doublep simple patch, improving unreachable bytecode removing 11/05/07 http://bugs.python.org/issue1394 created _doublep patch py3k: duplicated line endings when using read(1) 11/06/07 http://bugs.python.org/issue1395 created amaury.forgeotdarc py3k py3k-pep3137: patch for mailbox 11/06/07 CLOSED http://bugs.python.org/issue1396 created tiran py3k, patch py3k-pep3137: failing unit test test_bsddb 11/06/07 http://bugs.python.org/issue1397 created tiran py3k Can't pickle partial functions 11/07/07 CLOSED http://bugs.python.org/issue1398 created danhs XML codec 11/07/07 http://bugs.python.org/issue1399 created doerwalter patch Py3k's print() flushing problem 11/07/07 http://bugs.python.org/issue1400 created wojtekwalczak py3k urllib2 302 POST 11/07/07 http://bugs.python.org/issue1401 created andresriancho Interpreter cleanup: order of _PyGILState_Fini and PyInterpreter 11/07/07 http://bugs.python.org/issue1402 created ronaldoussoren py_compile and compileall need unit tests 11/08/07 http://bugs.python.org/issue1403 created tiran py3k warnings module bug: BytesWarning: str() on a bytes instance 11/08/07 CLOSED http://bugs.python.org/issue1404 created tiran patch Garbage collection not working correctly in Python 2.3 11/09/07 http://bugs.python.org/issue1405 reopened tiran Use widechar api for os.environ 11/08/07 CLOSED http://bugs.python.org/issue1406 created theller py3k, patch [performance] Too many closed() checkings 11/08/07 http://bugs.python.org/issue1407 created wojtekwalczak py3k Inconsistence in multiply list 11/08/07 CLOSED http://bugs.python.org/issue1408 created beco new keyword-only function parameters interact badly with nested 11/08/07 http://bugs.python.org/issue1409 created _doublep py3k BaseHTTPServer cannot accept Unicode data 11/08/07 CLOSED http://bugs.python.org/issue1410 created isonno A typo in tutorial 11/09/07 CLOSED http://bugs.python.org/issue1411 created falsetru test_subprocess fails on SuSE 10 11/09/07 http://bugs.python.org/issue1412 created dvadasz int literal methods inaccessible 11/09/07 CLOSED http://bugs.python.org/issue1413 created mykhal Fix for refleak tests 11/09/07 http://bugs.python.org/issue1414 created tiran py3k, patch py3k: pythonw.exe fails because std streams a missing 11/10/07 http://bugs.python.org/issue1415 created tiran py3k @prop.setter decorators 11/10/07 http://bugs.python.org/issue1416 created gvanrossum patch Weakref not working properly 11/10/07 CLOSED http://bugs.python.org/issue1417 created MHOOO Python/hypot.c is never used 11/10/07 http://bugs.python.org/issue1418 created marketdickinson Issues Now Closed (34) ______________________ test_glob fails with UnicodeDecodeError 72 days http://bugs.python.org/issue1042 tiran rfe py3k: corrections for test_subprocess on windows 72 days http://bugs.python.org/issue1047 tiran patch file.seek allows float arguments 68 days http://bugs.python.org/issue1081 tiran py3k test_email failed 67 days http://bugs.python.org/issue1086 tiran rfe py3k os.popen result is not iterable, patch attached 67 days http://bugs.python.org/issue1087 tiran patch Problems with the msi installer - python-3.0a1.msi 64 days http://bugs.python.org/issue1110 tiran No tests for inspect.getfullargspec() 63 days http://bugs.python.org/issue1127 tiran py3k, patch test_urllib2net fails on test_ftp 57 days http://bugs.python.org/issue1157 tiran py3k Should itertools.count work for arbitrary integers? 53 days http://bugs.python.org/issue1165 rhettinger py3k Trailing slash in sys.path cause import failure 20 days http://bugs.python.org/issue1293 gvanrossum patch Fix for test_netrc on Windows 9 days http://bugs.python.org/issue1345 tiran py3k, patch Add getsize() to io instances 13 days http://bugs.python.org/issue1351 loewis py3k, patch reloading imported modules sometimes fail with 'parent not in sy 1 days http://bugs.python.org/issue1379 _doublep py3k, patch fix for test_asynchat and test_asyncore on pep3137 branch 0 days http://bugs.python.org/issue1380 tiran py3k, patch py3k-pep3137: patch for test_ctypes 0 days http://bugs.python.org/issue1382 tiran py3k, patch Windows fix for inspect tests 2 days http://bugs.python.org/issue1384 tiran py3k, patch hmac module violates RFC for some hash functions, e.g. sha512 2 days http://bugs.python.org/issue1385 jowagner py3k py3k-pep3137: patch to ensure that all codecs return bytes 0 days http://bugs.python.org/issue1386 tiran py3k, patch py3k-pep3137: patch for hashlib on Windows 0 days http://bugs.python.org/issue1387 tiran py3k, patch py3k-pep3137: possible ref leak in ctypes 1 days http://bugs.python.org/issue1388 tiran py3k py3k-pep3137: struct module is leaking references 1 days http://bugs.python.org/issue1389 gvanrossum py3k py3k-pep3137: issue warnings / errors on str(bytes()) and simila 1 days http://bugs.python.org/issue1392 tiran py3k, patch py3k-pep3137: patch for mailbox 0 days http://bugs.python.org/issue1396 gvanrossum py3k, patch Can't pickle partial functions 1 days http://bugs.python.org/issue1398 tiran warnings module bug: BytesWarning: str() on a bytes instance 0 days http://bugs.python.org/issue1404 tiran patch Use widechar api for os.environ 0 days http://bugs.python.org/issue1406 theller py3k, patch Inconsistence in multiply list 1 days http://bugs.python.org/issue1408 georg.brandl BaseHTTPServer cannot accept Unicode data 1 days http://bugs.python.org/issue1410 tiran A typo in tutorial 0 days http://bugs.python.org/issue1411 georg.brandl int literal methods inaccessible 0 days http://bugs.python.org/issue1413 loewis Weakref not working properly 0 days http://bugs.python.org/issue1417 georg.brandl Error on handling nan 1637 days http://bugs.python.org/issue737648 mike.verdone Intel icc build fails with optimizations -O2 227 days http://bugs.python.org/issue1689617 loewis contextmanager eats StopIteration 199 days http://bugs.python.org/issue1705170 ncoghlan Top Issues Most Discussed (10) ______________________________ 35 py3k: duplicated line endings when using read(1) 5 days open http://bugs.python.org/issue1395 16 toxml generates output that is not well formed 6 days open http://bugs.python.org/issue1390 15 py3k-pep3137: issue warnings / errors on str(bytes()) and simil 1 days closed http://bugs.python.org/issue1392 11 int literal methods inaccessible 0 days closed http://bugs.python.org/issue1413 9 Trailing slash in sys.path cause import failure 20 days closed http://bugs.python.org/issue1293 7 urllib2 302 POST 3 days open http://bugs.python.org/issue1401 6 BaseHTTPServer cannot accept Unicode data 1 days closed http://bugs.python.org/issue1410 6 new keyword-only function parameters interact badly with nested 2 days open http://bugs.python.org/issue1409 6 Garbage collection not working correctly in Python 2.3 1 days open http://bugs.python.org/issue1405 6 XML codec 3 days open http://bugs.python.org/issue1399 From guido at python.org Sat Nov 10 19:31:07 2007 From: guido at python.org (Guido van Rossum) Date: Sat, 10 Nov 2007 10:31:07 -0800 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: Message-ID: Unless I get negative feedback really soon I plan to submit this later today. I've tweaked the patch slightly to be smarter about replacing the setter and the deleter together if they are the same object. On Nov 9, 2007 10:03 PM, Guido van Rossum wrote: > D'oh. I forgot to point to the patch. It's here: > http://bugs.python.org/issue1416 > > > On Nov 9, 2007 10:00 PM, Guido van Rossum wrote: > > To follow up, I now have a patch. It's pretty straightforward. > > > > This implements the kind of syntax that I believe won over most folks > > in the end: > > > > @property > > def foo(self): ... > > > > @foo.setter > > def foo(self, value=None): ... > > > > There are also .getter and .deleter descriptors. This includes the hack > > that if you specify a setter but no deleter, the setter is called > > without a value argument when attempting to delete something. If the > > setter isn't ready for this, a TypeError will be raised, pretty much > > just as if no deleter was provided (just with a somewhat worse error > > message :-). > > > > I intend to check this into 2.6 and 3.0 unless there is a huge cry of > > dismay. Docs will be left to volunteers as always. > > > > --Guido > > > > > > On Oct 31, 2007 9:08 AM, Guido van Rossum wrote: > > > I've come up with a relatively unobtrusive pattern for defining > > > setters. Given the following definition: > > > > > > def propset(prop): > > > assert isinstance(prop, property) > > > def helper(func): > > > return property(prop.__get__, func, func, prop.__doc__) > > > return helper > > > > > > we can declare getters and setters as follows: > > > > > > class C(object): > > > > > > _encoding = None > > > > > > @property > > > def encoding(self): > > > return self._encoding > > > > > > @propset(encoding) > > > def encoding(self, value=None): > > > if value is not None: > > > unicode("0", value) # Test it > > > self._encoding = value > > > > > > c = C() > > > print(c.encoding) > > > c.encoding = "ascii" > > > print(c.encoding) > > > try: > > > c.encoding = "invalid" # Fails > > > except: > > > pass > > > print(c.encoding) > > > > > > I'd like to make this a standard built-in, in the hope the debate on > > > how to declare settable properties. > > > > > > I'd also like to change property so that the doc string defaults to > > > the doc string of the getter. > > > > > > -- > > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > > > > > > > > > -- > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > > > > -- > > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From steven.bethard at gmail.com Sat Nov 10 20:09:16 2007 From: steven.bethard at gmail.com (Steven Bethard) Date: Sat, 10 Nov 2007 12:09:16 -0700 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: Message-ID: On Nov 10, 2007 11:31 AM, Guido van Rossum wrote: > Unless I get negative feedback really soon I plan to submit this later > today. I've tweaked the patch slightly to be smarter about replacing > the setter and the deleter together if they are the same object. Definitely +1 on the basic patch. Could you explain briefly the advantage of the "hack" that merges the set and del methods? Looking at the patch, I get a little nervous about this:: @foo.setter def foo(self, value=None): if value is None: del self._foo else: self._foo = abs(value) That means that ``c.foo = None`` is equivalent to ``del c.foo`` right? STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy From guido at python.org Sat Nov 10 22:17:39 2007 From: guido at python.org (Guido van Rossum) Date: Sat, 10 Nov 2007 13:17:39 -0800 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: Message-ID: On Nov 10, 2007 11:09 AM, Steven Bethard wrote: > On Nov 10, 2007 11:31 AM, Guido van Rossum wrote: > > Unless I get negative feedback really soon I plan to submit this later > > today. I've tweaked the patch slightly to be smarter about replacing > > the setter and the deleter together if they are the same object. > > Definitely +1 on the basic patch. > > Could you explain briefly the advantage of the "hack" that merges the > set and del methods? Looking at the patch, I get a little nervous > about this:: > > @foo.setter > def foo(self, value=None): > if value is None: > del self._foo > else: > self._foo = abs(value) > > That means that ``c.foo = None`` is equivalent to ``del c.foo`` right? Which is sometimes convenient. But thinking about this some more I think that if I *wanted* to use the same method as setter and deleter, I could just write @foo.setter @foo.deleter def foo(self, value=None): ... So I'm withdrawing the hacks, making the code and semantics much simpler. See propset3.diff in http://bugs.python.org/issue1416 . -- --Guido van Rossum (home page: http://www.python.org/~guido/) From lists at cheimes.de Sat Nov 10 22:43:21 2007 From: lists at cheimes.de (Christian Heimes) Date: Sat, 10 Nov 2007 22:43:21 +0100 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: Message-ID: Guido van Rossum wrote: > Which is sometimes convenient. But thinking about this some more I > think that if I *wanted* to use the same method as setter and deleter, > I could just write > > @foo.setter > @foo.deleter > def foo(self, value=None): ... > > So I'm withdrawing the hacks, making the code and semantics much simpler. I like the new way better than the implicit magic of your former patch. (*) I've reviewed your patch and I found a minor typo caused by copy and paste. Good work Guido! Christian (*) The buzz words 'implicit' and 'magic' are used in this posting to make Guido's non-pythonic-code-sense tingle. *scnr* :] From guido at python.org Sun Nov 11 00:37:41 2007 From: guido at python.org (Guido van Rossum) Date: Sat, 10 Nov 2007 15:37:41 -0800 Subject: [Python-Dev] Declaring setters with getters In-Reply-To: References: Message-ID: On Nov 10, 2007 1:43 PM, Christian Heimes wrote: > Good work Guido! With sich a ringing endorsement, I've submitted this to the 2.6 trunk and the py3k branch. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From brett at python.org Sun Nov 11 00:56:31 2007 From: brett at python.org (Brett Cannon) Date: Sat, 10 Nov 2007 15:56:31 -0800 Subject: [Python-Dev] Bug tracker: meaning of resolution keywords In-Reply-To: <47349344.5040306@cheimes.de> References: <47349344.5040306@cheimes.de> Message-ID: On Nov 9, 2007 9:05 AM, Christian Heimes wrote: > Hello! > > Guido has granted me committer privileges to svn.python.org and > bugs.python.org about a week ago. So I'm new and new people tend to make > mistakes until they've learned the specific rules of a project. > > Today I've learned that the resolution keyword "accepted" doesn't mean > the bug report is accepted. It only means a patch for the bug is > accepted. In the past I've used "accepted" in the meaning of "bug is > confirmed" in my own projects. In my ignorance I've used it in the same > way to mark bugs as confirmed when I was able to reproduce the bug myself. > > The tracker doc at http://wiki.python.org/moin/TrackerDocs/ doesn't have > a formal definition of the various keywords. I like to add a definition > to the wiki to prevent others from making the same mistake. But first I > like to discuss my view of the keywords > > Resolutions > *********** > > accepted - patch accepted > confirmed (*) - the problem is confirmed > duplicate - the bug is a duplicated of another bug > fixed - the bug is fixed / patch is applied > invalid - catch all for invalid reports > later - the problem is going to be addressed later in the release cycle > out of date - the bug was already fixed in svn > postponed - the problem is going to be fixed in the next minor version > rejected - the patch or feature request is rejected > remind - remind me to finish the task (docs, unit tests) > wont fix - it's not a bug, it's a feature > works for me - unable to reproduce the problem It doesn't really work for you if you can't reproduce it. =) An important thing to remember is all of the states are there because they are hold-overs for SourceForge's bug tracker, not from choice. SOMEDAY, damn it, I am going to have the time to work on redesigning our workflow is how WE want it to be and makes sense for us. Then we can have a doc like Django has (http://www.djangoproject.com/documentation/contributing/#ticket-triage) which would spell all of this out. But as Christian knows first hand from me not getting to any of my bugs quickly as of late, I don't have the time right now. =( But I have stopped adding to my list of stuff to do for Python (it is already long enough as it is) so that I will eventually get to this in 2008. -Brett From facundobatista at gmail.com Sun Nov 11 02:47:54 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Sat, 10 Nov 2007 22:47:54 -0300 Subject: [Python-Dev] Bug tracker: meaning of resolution keywords In-Reply-To: <47349344.5040306@cheimes.de> References: <47349344.5040306@cheimes.de> Message-ID: 2007/11/9, Christian Heimes : > Guido has granted me committer privileges to svn.python.org and > bugs.python.org about a week ago. So I'm new and new people tend to make > mistakes until they've learned the specific rules of a project. Yes, I saw the change in developers.txt. Now you remind me that I was going to ask yourself for a presentation. Who're you, what do you do, where're you from, what do you like, etc. And I hope to meet you in Chicago! > Today I've learned that the resolution keyword "accepted" doesn't mean > the bug report is accepted. It only means a patch for the bug is > accepted. In the past I've used "accepted" in the meaning of "bug is If you accept a patch for a bug, doesn't it imply that the bug is real and that you're accepting the bug? > accepted - patch accepted > confirmed (*) - the problem is confirmed > duplicate - the bug is a duplicated of another bug > fixed - the bug is fixed / patch is applied > invalid - catch all for invalid reports > later - the problem is going to be addressed later in the release cycle > out of date - the bug was already fixed in svn > postponed - the problem is going to be fixed in the next minor version > rejected - the patch or feature request is rejected > remind - remind me to finish the task (docs, unit tests) > wont fix - it's not a bug, it's a feature > works for me - unable to reproduce the problem I think that they're too many. You shouldn't be thinking too much in which category to put a bug, or arguing with a coworker for a category. Some can clearly be combined (like "later" and "postponed"), some needs more thought (like "invalid", doesn't it includes "works for me"?). But it would be great if they're only 5 or 6, and not so vague. Thanks! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From mal at egenix.com Sun Nov 11 12:34:41 2007 From: mal at egenix.com (M.-A. Lemburg) Date: Sun, 11 Nov 2007 12:34:41 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <473571AC.7020302@v.loewis.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> <4734F316.1040802@v.loewis.de> <4734FA67.10307@egenix.com> <473571AC.7020302@v.loewis.de> Message-ID: <4736E8D1.8020200@egenix.com> On 2007-11-10 09:54, Martin v. L?wis wrote: >> A non-seekable stream is not all that uncommon in network processing. > > Right. But what is the relationship to XML encoding autodetection? It pops up whenever you need to detect the encoding of the incoming XML data on the network connection, e.g. in XML RPC or data upload mechanisms. Even though XML data mostly uses UTF-8 in real life applications, a standards compliant XML interface must also support other possible encodings. It is also not always feasible to load all data into memory, so some form of buffering must be used. Since incremental codecs already implement buffering, it's only natural to let them take care of the auto detection. This approach is also needed if you want to stack stream codecs (not sure whether this is still possible in Py3, but that's how I designed them for Py2). Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 11 2007) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From martin at v.loewis.de Sun Nov 11 14:40:44 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 11 Nov 2007 14:40:44 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <61862.89.54.66.61.1194710141.squirrel@isar.livinglogic.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47339C0D.50906@v.loewis.de> <47343BBA.9090800@livinglogic.de> <47344C35.60807@v.loewis.de> <47345765.2090606@livinglogic.de> <4734AD37.5070209@v.loewis.de> <61862.89.54.66.61.1194710141.squirrel@isar.livinglogic.de> Message-ID: <4737065C.8020404@v.loewis.de> > I don't know. Is an XML document ill-formed if it doesn't contain an > XML declaration, is not in UTF-8 or UTF-8, but there's external > encoding info? If there is external encoding info, matching the actual encoding, it would be well-formed. Of course, preserving that information would be up to the application. > This looks good. Now we would have to extent the code to detect and > replace the encoding in the XML declaration too. I'm still opposed to making this a codec. Right - for a pure Python solution, the processing of the XML declaration would still need to be implemented. >> I think there could be a much simpler routine to have the same >> effect. - if it's less than 4 bytes, answer "need more data". > > Can there be an XML document that is less then 4 bytes? I guess not. No, the smallest document has exactly 4 characters (e.g. ""). However, external entities may be smaller, such as "x". > But anyway: would a Python implementation of these two functions > (detect_encoding()/fix_encoding()) be accepted? I could agree to a Python implementation of this algorithm as long as it's not packaged as a codec. Regards, Martin From martin at v.loewis.de Sun Nov 11 14:51:39 2007 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 11 Nov 2007 14:51:39 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <4736E8D1.8020200@egenix.com> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> <4734F316.1040802@v.loewis.de> <4734FA67.10307@egenix.com> <473571AC.7020302@v.loewis.de> <4736E8D1.8020200@egenix.com> Message-ID: <473708EB.1060600@v.loewis.de> >>> A non-seekable stream is not all that uncommon in network processing. >> Right. But what is the relationship to XML encoding autodetection? > > It pops up whenever you need to detect the encoding of the > incoming XML data on the network connection, e.g. in XML RPC > or data upload mechanisms. No, it doesn't. For XML-RPC, you pass the XML payload of the HTTP request to the XML parser, and it deals with the encoding. > It is also not always feasible to load all data into memory, so > some form of buffering must be used. Again, I don't see the use case. For XML-RPC, it's very feasible and standard procedure to have the entire document in memory (in a processed form). > This approach is also needed if you want to stack stream codecs > (not sure whether this is still possible in Py3, but that's how > I designed them for Py2). The design of the Py2 codecs is fairly flawed, unfortunately. Regards, Martin From mal at egenix.com Sun Nov 11 18:36:49 2007 From: mal at egenix.com (M.-A. Lemburg) Date: Sun, 11 Nov 2007 18:36:49 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <473708EB.1060600@v.loewis.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> <4734F316.1040802@v.loewis.de> <4734FA67.10307@egenix.com> <473571AC.7020302@v.loewis.de> <4736E8D1.8020200@egenix.com> <473708EB.1060600@v.loewis.de> Message-ID: <47373DB1.6030908@egenix.com> On 2007-11-11 14:51, Martin v. L?wis wrote: >>>> A non-seekable stream is not all that uncommon in network processing. >>> Right. But what is the relationship to XML encoding autodetection? >> It pops up whenever you need to detect the encoding of the >> incoming XML data on the network connection, e.g. in XML RPC >> or data upload mechanisms. > > No, it doesn't. For XML-RPC, you pass the XML payload of the > HTTP request to the XML parser, and it deals with the encoding. First, XML-RPC is not the only mechanism using XML over a network connection. Second, you don't want to do this if you're dealing with several 100 MB of data just because you want to figure out the encoding. >> It is also not always feasible to load all data into memory, so >> some form of buffering must be used. > > Again, I don't see the use case. For XML-RPC, it's very feasible > and standard procedure to have the entire document in memory > (in a processed form). You may not see the use case, but that doesn't really mean anything if the use cases exist in real life applications, right ?! >> This approach is also needed if you want to stack stream codecs >> (not sure whether this is still possible in Py3, but that's how >> I designed them for Py2). > > The design of the Py2 codecs is fairly flawed, unfortunately. Fortunately, this sounds like a fairly flawed argument to me ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 11 2007) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From martin at v.loewis.de Sun Nov 11 18:56:40 2007 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 11 Nov 2007 18:56:40 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <47373DB1.6030908@egenix.com> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> <4734F316.1040802@v.loewis.de> <4734FA67.10307@egenix.com> <473571AC.7020302@v.loewis.de> <4736E8D1.8020200@egenix.com> <473708EB.1060600@v.loewis.de> <47373DB1.6030908@egenix.com> Message-ID: <47374258.3070205@v.loewis.de> > First, XML-RPC is not the only mechanism using XML over a network > connection. Second, you don't want to do this if you're dealing > with several 100 MB of data just because you want to figure > out the encoding. That's my original claim/question: what SPECIFIC application do you have in mind that transfers XML over a network and where you would want to have such a stream codec? If I have 100MB of XML in a file, using the detection API, I do f = open(filename) s = f.read(100) while True: coding = xml.utils.detect_encoding(s) if coding is not undetermined: break s += f.read(100) f.close() Having the loop here is paranoia: in my application, I might be able to know that 100 bytes are sufficient to determine the encoding always. >> Again, I don't see the use case. For XML-RPC, it's very feasible >> and standard procedure to have the entire document in memory >> (in a processed form). > > You may not see the use case, but that doesn't really mean > anything if the use cases exist in real life applications, > right ?! Right. However, I' will remain opposed to adding this to the standard library until I see why one would absolutely need to have that. Not every piece of code that is useful in some application should be added to the standard library. Regards, Martin From status at bugs.python.org Sun Nov 11 19:06:06 2007 From: status at bugs.python.org (Tracker) Date: Sun, 11 Nov 2007 18:06:06 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071111180606.544A678328@psf.upfronthosting.co.za> ACTIVITY SUMMARY (11/04/07 - 11/11/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1323 open (+21) / 11582 closed (+19) / 12905 total (+40) Open issues with patches: 419 Average duration of open issues: 687 days. Median duration of open issues: 791 days. Open Issues Breakdown open 1318 (+21) pending 5 ( +0) Issues Created Or Reopened (41) _______________________________ test_import breaks on Linux 11/09/07 http://bugs.python.org/issue1377 reopened gvanrossum py3k Backport abcoll to 2.6 11/04/07 http://bugs.python.org/issue1383 created baranguren patch Windows fix for inspect tests 11/04/07 CLOSED http://bugs.python.org/issue1384 created tiran py3k, patch hmac module violates RFC for some hash functions, e.g. sha512 11/04/07 CLOSED http://bugs.python.org/issue1385 created jowagner py3k py3k-pep3137: patch to ensure that all codecs return bytes 11/04/07 CLOSED http://bugs.python.org/issue1386 created amaury.forgeotdarc py3k, patch py3k-pep3137: patch for hashlib on Windows 11/04/07 CLOSED http://bugs.python.org/issue1387 created amaury.forgeotdarc py3k, patch py3k-pep3137: possible ref leak in ctypes 11/05/07 CLOSED http://bugs.python.org/issue1388 created tiran py3k py3k-pep3137: struct module is leaking references 11/05/07 CLOSED http://bugs.python.org/issue1389 created tiran py3k toxml generates output that is not well formed 11/05/07 http://bugs.python.org/issue1390 created drtomc Adds the .compact() method to bsddb db.DB objects 11/05/07 http://bugs.python.org/issue1391 created gregory.p.smith patch, rfe py3k-pep3137: issue warnings / errors on str(bytes()) and simila 11/05/07 CLOSED http://bugs.python.org/issue1392 created tiran py3k, patch function comparing lacks NotImplemented error 11/05/07 http://bugs.python.org/issue1393 created _doublep simple patch, improving unreachable bytecode removing 11/05/07 http://bugs.python.org/issue1394 created _doublep patch py3k: duplicated line endings when using read(1) 11/06/07 http://bugs.python.org/issue1395 created amaury.forgeotdarc py3k py3k-pep3137: patch for mailbox 11/06/07 CLOSED http://bugs.python.org/issue1396 created tiran py3k, patch py3k-pep3137: failing unit test test_bsddb 11/06/07 http://bugs.python.org/issue1397 created tiran py3k Can't pickle partial functions 11/07/07 CLOSED http://bugs.python.org/issue1398 created danhs XML codec 11/07/07 http://bugs.python.org/issue1399 created doerwalter patch Py3k's print() flushing problem 11/07/07 http://bugs.python.org/issue1400 created wojtekwalczak py3k urllib2 302 POST 11/07/07 http://bugs.python.org/issue1401 created andresriancho Interpreter cleanup: order of _PyGILState_Fini and PyInterpreter 11/07/07 http://bugs.python.org/issue1402 created ronaldoussoren py_compile and compileall need unit tests 11/08/07 http://bugs.python.org/issue1403 created tiran py3k warnings module bug: BytesWarning: str() on a bytes instance 11/08/07 CLOSED http://bugs.python.org/issue1404 created tiran patch Garbage collection not working correctly in Python 2.3 11/09/07 CLOSED http://bugs.python.org/issue1405 reopened tiran Use widechar api for os.environ 11/08/07 CLOSED http://bugs.python.org/issue1406 created theller py3k, patch [performance] Too many closed() checkings 11/08/07 http://bugs.python.org/issue1407 created wojtekwalczak py3k Inconsistence in multiply list 11/08/07 CLOSED http://bugs.python.org/issue1408 created beco new keyword-only function parameters interact badly with nested 11/08/07 http://bugs.python.org/issue1409 created _doublep py3k BaseHTTPServer cannot accept Unicode data 11/08/07 CLOSED http://bugs.python.org/issue1410 created isonno A typo in tutorial 11/09/07 CLOSED http://bugs.python.org/issue1411 created falsetru test_subprocess fails on SuSE 10 11/09/07 http://bugs.python.org/issue1412 created dvadasz int literal methods inaccessible 11/09/07 CLOSED http://bugs.python.org/issue1413 created mykhal Fix for refleak tests 11/09/07 http://bugs.python.org/issue1414 created tiran py3k, patch py3k: pythonw.exe fails because std streams a missing 11/10/07 http://bugs.python.org/issue1415 created tiran py3k @prop.setter decorators 11/10/07 CLOSED http://bugs.python.org/issue1416 created gvanrossum patch Weakref not working properly 11/10/07 CLOSED http://bugs.python.org/issue1417 created MHOOO Python/hypot.c is never used 11/10/07 http://bugs.python.org/issue1418 created marketdickinson ssl module version 1.10 causes TypeError when accepting connecti 11/11/07 http://bugs.python.org/issue1419 created complex Unicode literals in tokenize.py and tests. 11/11/07 http://bugs.python.org/issue1420 created ron_adam py3k, patch python.org: outdated and false information 11/11/07 CLOSED http://bugs.python.org/issue1421 created tiran Writing to an invalid fd doesn't raise an exception 11/11/07 http://bugs.python.org/issue1422 created tiran py3k Issues Now Closed (34) ______________________ test_glob fails with UnicodeDecodeError 72 days http://bugs.python.org/issue1042 tiran rfe py3k: corrections for test_subprocess on windows 72 days http://bugs.python.org/issue1047 tiran patch file.seek allows float arguments 68 days http://bugs.python.org/issue1081 tiran py3k test_email failed 67 days http://bugs.python.org/issue1086 tiran rfe py3k os.popen result is not iterable, patch attached 67 days http://bugs.python.org/issue1087 tiran patch Problems with the msi installer - python-3.0a1.msi 64 days http://bugs.python.org/issue1110 tiran No tests for inspect.getfullargspec() 63 days http://bugs.python.org/issue1127 tiran py3k, patch test_urllib2net fails on test_ftp 57 days http://bugs.python.org/issue1157 tiran py3k Should itertools.count work for arbitrary integers? 53 days http://bugs.python.org/issue1165 rhettinger py3k Trailing slash in sys.path cause import failure 20 days http://bugs.python.org/issue1293 gvanrossum patch Fix for test_netrc on Windows 9 days http://bugs.python.org/issue1345 tiran py3k, patch Add getsize() to io instances 13 days http://bugs.python.org/issue1351 loewis py3k, patch Windows fix for inspect tests 2 days http://bugs.python.org/issue1384 tiran py3k, patch hmac module violates RFC for some hash functions, e.g. sha512 2 days http://bugs.python.org/issue1385 jowagner py3k py3k-pep3137: patch to ensure that all codecs return bytes 0 days http://bugs.python.org/issue1386 tiran py3k, patch py3k-pep3137: patch for hashlib on Windows 0 days http://bugs.python.org/issue1387 tiran py3k, patch py3k-pep3137: possible ref leak in ctypes 1 days http://bugs.python.org/issue1388 tiran py3k py3k-pep3137: struct module is leaking references 1 days http://bugs.python.org/issue1389 gvanrossum py3k py3k-pep3137: issue warnings / errors on str(bytes()) and simila 1 days http://bugs.python.org/issue1392 tiran py3k, patch py3k-pep3137: patch for mailbox 0 days http://bugs.python.org/issue1396 gvanrossum py3k, patch Can't pickle partial functions 1 days http://bugs.python.org/issue1398 tiran warnings module bug: BytesWarning: str() on a bytes instance 0 days http://bugs.python.org/issue1404 tiran patch Garbage collection not working correctly in Python 2.3 1 days http://bugs.python.org/issue1405 gvanrossum Use widechar api for os.environ 0 days http://bugs.python.org/issue1406 theller py3k, patch Inconsistence in multiply list 1 days http://bugs.python.org/issue1408 georg.brandl BaseHTTPServer cannot accept Unicode data 1 days http://bugs.python.org/issue1410 tiran A typo in tutorial 0 days http://bugs.python.org/issue1411 georg.brandl int literal methods inaccessible 0 days http://bugs.python.org/issue1413 loewis @prop.setter decorators 1 days http://bugs.python.org/issue1416 gvanrossum patch Weakref not working properly 0 days http://bugs.python.org/issue1417 rhettinger python.org: outdated and false information 0 days http://bugs.python.org/issue1421 georg.brandl Error on handling nan 1637 days http://bugs.python.org/issue737648 mike.verdone Intel icc build fails with optimizations -O2 227 days http://bugs.python.org/issue1689617 loewis contextmanager eats StopIteration 199 days http://bugs.python.org/issue1705170 ncoghlan Top Issues Most Discussed (10) ______________________________ 36 py3k: duplicated line endings when using read(1) 6 days open http://bugs.python.org/issue1395 16 toxml generates output that is not well formed 7 days open http://bugs.python.org/issue1390 15 py3k-pep3137: issue warnings / errors on str(bytes()) and simil 1 days closed http://bugs.python.org/issue1392 11 int literal methods inaccessible 0 days closed http://bugs.python.org/issue1413 9 Trailing slash in sys.path cause import failure 20 days closed http://bugs.python.org/issue1293 7 py3k: pythonw.exe fails because std streams a missing 2 days open http://bugs.python.org/issue1415 7 urllib2 302 POST 4 days open http://bugs.python.org/issue1401 6 BaseHTTPServer cannot accept Unicode data 1 days closed http://bugs.python.org/issue1410 6 new keyword-only function parameters interact badly with nested 3 days open http://bugs.python.org/issue1409 6 Garbage collection not working correctly in Python 2.3 1 days closed http://bugs.python.org/issue1405 From mal at egenix.com Sun Nov 11 19:31:36 2007 From: mal at egenix.com (M.-A. Lemburg) Date: Sun, 11 Nov 2007 19:31:36 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <47374258.3070205@v.loewis.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> <4734F316.1040802@v.loewis.de> <4734FA67.10307@egenix.com> <473571AC.7020302@v.loewis.de> <4736E8D1.8020200@egenix.com> <473708EB.1060600@v.loewis.de> <47373DB1.6030908@egenix.com> <47374258.3070205@v.loewis.de> Message-ID: <47374A88.108@egenix.com> On 2007-11-11 18:56, Martin v. L?wis wrote: >> First, XML-RPC is not the only mechanism using XML over a network >> connection. Second, you don't want to do this if you're dealing >> with several 100 MB of data just because you want to figure >> out the encoding. > > That's my original claim/question: what SPECIFIC application do > you have in mind that transfers XML over a network and where you > would want to have such a stream codec? XML-based web services used for business integration, e.g. based on ebXML. A common use case from our everyday consulting business is e.g. passing market and trading data to portfolio pricing web services. > If I have 100MB of XML in a file, using the detection API, I do > > f = open(filename) > s = f.read(100) > while True: > coding = xml.utils.detect_encoding(s) > if coding is not undetermined: > break > s += f.read(100) > f.close() > > Having the loop here is paranoia: in my application, I might be > able to know that 100 bytes are sufficient to determine the encoding > always. Doing the detection with files is easy, but that was never questioned. >>> Again, I don't see the use case. For XML-RPC, it's very feasible >>> and standard procedure to have the entire document in memory >>> (in a processed form). >> You may not see the use case, but that doesn't really mean >> anything if the use cases exist in real life applications, >> right ?! > > Right. However, I' will remain opposed to adding this to the > standard library until I see why one would absolutely need to > have that. Not every piece of code that is useful in some > application should be added to the standard library. Agreed, but the application space of web services is large enough to warrant this. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 11 2007) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From martin at v.loewis.de Sun Nov 11 23:22:32 2007 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 11 Nov 2007 23:22:32 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <47374A88.108@egenix.com> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> <4734F316.1040802@v.loewis.de> <4734FA67.10307@egenix.com> <473571AC.7020302@v.loewis.de> <4736E8D1.8020200@egenix.com> <473708EB.1060600@v.loewis.de> <47373DB1.6030908@egenix.com> <47374258.3070205@v.loewis.de> <47374A88.108@egenix.com> Message-ID: <473780A8.1060108@v.loewis.de> >>> First, XML-RPC is not the only mechanism using XML over a network >>> connection. Second, you don't want to do this if you're dealing >>> with several 100 MB of data just because you want to figure >>> out the encoding. >> That's my original claim/question: what SPECIFIC application do >> you have in mind that transfers XML over a network and where you >> would want to have such a stream codec? > > XML-based web services used for business integration, e.g. based > on ebXML. > > A common use case from our everyday consulting business is e.g. > passing market and trading data to portfolio pricing web services. I still don't see the need for this feature from this example. First, in ebXML messaging, the message are typically *not* large (i.e. much smaller than 100 MB). Furthermore, the typical processing of such a message would be to pass it directly to the XML parser, no need for the functionality under discussion. >> Right. However, I' will remain opposed to adding this to the >> standard library until I see why one would absolutely need to >> have that. Not every piece of code that is useful in some >> application should be added to the standard library. > > Agreed, but the application space of web services is large > enough to warrant this. If that was the case, wouldn't the existing Python web service libraries already include such a functionality? Regards, Martin From graham.horler at gmail.com Mon Nov 12 01:00:27 2007 From: graham.horler at gmail.com (Graham Horler) Date: Mon, 12 Nov 2007 00:00:27 +0000 Subject: [Python-Dev] Proposal for new 2to23 tool Message-ID: <6e8ddi$59lcj2@mercury.eclipse.kcom.com> I have been developing in Python since 1.5, and now have to support 2.1 as a minimum version. I do like to keep my code runnable on newer versions however, and am considering the feasability of forward compatibility with Python 3.0. I also notice the Leo[1] project could use some assistance with forward compatibility. So I was wondering if anyone else had a need for a 2to23.py tool to help make code compatible with 3.0 but not break it for 2.x. Such a tool could also include implementations of new builtins added in python 3.0, or work in tandem with a "py3to2" library. One such function would be "print" (which would have to be renamed to e.g. "prints" as "def print()" is a syntax error in 2.x). This would have the added benefit of staunching the flow of wasted effort into many differing implementations of such things, and maybe direct some of it into development of this tool. Hope this is on topic, and has not already been considered and dismissed. Thanks, Graham [1] http://webpages.charter.net/edreamleo/front.html P.S. a suggested prints() implementation for py3to2.py, including raising a TypeError exception for extra keyword args, and returning None. It works in python 2.1 through to python 3.0a1. def prints(*args, **kw): kw.setdefault('sep', ' ') kw.setdefault('end', '\n') kw.setdefault('file', sys.stdout) if len(kw) > 3: for k in ('sep', 'end', 'file'): del kw[k] if len(kw) > 1: raise TypeError(', '.join(map(repr, kw.keys())) + ' are invalid keyword arguments for this function') else: raise TypeError('%r is an invalid keyword argument for this function' % list(kw.keys())[0]) kw['file'].write(kw['sep'].join(['%s' % a for a in args]) + kw['end']) From brett at python.org Mon Nov 12 02:19:10 2007 From: brett at python.org (Brett Cannon) Date: Sun, 11 Nov 2007 17:19:10 -0800 Subject: [Python-Dev] Proposal for new 2to23 tool In-Reply-To: <6e8ddi$59lcj2@mercury.eclipse.kcom.com> References: <6e8ddi$59lcj2@mercury.eclipse.kcom.com> Message-ID: On Nov 11, 2007 4:00 PM, Graham Horler wrote: > I have been developing in Python since 1.5, and now have to support 2.1 > as a minimum version. I do like to keep my code runnable on newer > versions however, and am considering the feasability of forward > compatibility with Python 3.0. > > I also notice the Leo[1] project could use some assistance with forward > compatibility. > > So I was wondering if anyone else had a need for a 2to23.py tool to help > make code compatible with 3.0 but not break it for 2.x. What exactly are you proposing? We already have 2to3 (http://svn.python.org/view/sandbox/trunk/2to3/) for source-to-source translation from 2.x to 3.0. -Brett From lists at janc.be Mon Nov 12 04:24:34 2007 From: lists at janc.be (Jan Claeys) Date: Mon, 12 Nov 2007 04:24:34 +0100 Subject: [Python-Dev] Proposal for new 2to23 tool In-Reply-To: References: <6e8ddi$59lcj2@mercury.eclipse.kcom.com> Message-ID: <1194837874.8183.100.camel@localhost> Op zondag 11-11-2007 om 17:19 uur [tijdzone -0800], schreef Brett Cannon: > On Nov 11, 2007 4:00 PM, Graham Horler wrote: > > I have been developing in Python since 1.5, and now have to support 2.1 > > as a minimum version. I do like to keep my code runnable on newer > > versions however, and am considering the feasability of forward > > compatibility with Python 3.0. > > > > I also notice the Leo[1] project could use some assistance with forward > > compatibility. > > > > So I was wondering if anyone else had a need for a 2to23.py tool to help > > make code compatible with 3.0 but not break it for 2.x. > > What exactly are you proposing? We already have 2to3 > (http://svn.python.org/view/sandbox/trunk/2to3/) for source-to-source > translation from 2.x to 3.0. Graham wants to convert his code such that it works on both Python 2.x (probably even early versions of it?) & Python 3.x. Not 2 instances of code, but one source that works on both 2.x and 3.x... -- Jan Claeys From graham.horler at gmail.com Mon Nov 12 09:50:22 2007 From: graham.horler at gmail.com (Graham Horler) Date: Mon, 12 Nov 2007 08:50:22 +0000 Subject: [Python-Dev] Proposal for new 2to23 tool References: <6e8ddi$59lcj2@mercury.eclipse.kcom.com> <1194837874.8183.100.camel@localhost> Message-ID: <6e8ddi$5a0mjm@mercury.eclipse.kcom.com> On 12 Nov 2007, 03:24:34, Jan Claeys wrote: > > Op zondag 11-11-2007 om 17:19 uur [tijdzone -0800], schreef Brett > Cannon: > > On Nov 11, 2007 4:00 PM, Graham Horler wrote: > > > I have been developing in Python since 1.5, and now have to support 2.1 > > > as a minimum version. I do like to keep my code runnable on newer > > > versions however, and am considering the feasability of forward > > > compatibility with Python 3.0. > > > > > > I also notice the Leo[1] project could use some assistance with forward > > > compatibility. > > > > > > So I was wondering if anyone else had a need for a 2to23.py tool to help > > > make code compatible with 3.0 but not break it for 2.x. > > > > What exactly are you proposing? We already have 2to3 > > (http://svn.python.org/view/sandbox/trunk/2to3/) for source-to-source > > translation from 2.x to 3.0. > > Graham wants to convert his code such that it works on both Python 2.x > (probably even early versions of it?) & Python 3.x. Not 2 instances of > code, but one source that works on both 2.x and 3.x... Absolutely From walter at livinglogic.de Mon Nov 12 10:39:21 2007 From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=) Date: Mon, 12 Nov 2007 10:39:21 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <4737065C.8020404@v.loewis.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47339C0D.50906@v.loewis.de> <47343BBA.9090800@livinglogic.de> <47344C35.60807@v.loewis.de> <47345765.2090606@livinglogic.de> <4734AD37.5070209@v.loewis.de> <61862.89.54.66.61.1194710141.squirrel@isar.livinglogic.de> <4737065C.8020404@v.loewis.de> Message-ID: <47381F49.8070206@livinglogic.de> Martin v. L?wis wrote: >> I don't know. Is an XML document ill-formed if it doesn't contain an >> XML declaration, is not in UTF-8 or UTF-8, but there's external >> encoding info? > > If there is external encoding info, matching the actual encoding, > it would be well-formed. Of course, preserving that information would > be up to the application. OK. When the application passes an encoding to the decoder this is supposed to be the external encoding info, so for the decoder it makes sense to assume that the encoding passed to the encoder is the external encoding info and will be transmitted along with the encoded bytes. >> This looks good. Now we would have to extent the code to detect and >> replace the encoding in the XML declaration too. > > I'm still opposed to making this a codec. Right - for a pure Python > solution, the processing of the XML declaration would still need to > be implemented. > >>> I think there could be a much simpler routine to have the same >>> effect. - if it's less than 4 bytes, answer "need more data". >> Can there be an XML document that is less then 4 bytes? I guess not. > > No, the smallest document has exactly 4 characters (e.g. ""). > However, external entities may be smaller, such as "x". > >> But anyway: would a Python implementation of these two functions >> (detect_encoding()/fix_encoding()) be accepted? > > I could agree to a Python implementation of this algorithm as long > as it's not packaged as a codec. I still can't understand your objection to a codec. What's the difference between UTF-16 decoding and XML decoding? In fact PEP 263 IMHO does specify how to decode Python source, so in theory it could be a codec (in practice this probably wouldn't work because of bootstrapping problems). Servus, Walter From walter at livinglogic.de Mon Nov 12 10:53:54 2007 From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=) Date: Mon, 12 Nov 2007 10:53:54 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <4735716B.1010308@v.loewis.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <4734D790.2050904@v.loewis.de> <87abpnlzmi.fsf@uwakimon.sk.tsukuba.ac.jp> <4735716B.1010308@v.loewis.de> Message-ID: <473822B2.1040303@livinglogic.de> Martin v. L?wis wrote: >> > In case it isn't clear - this is exactly my view also. >> >> But is there an API to do it? As MAL points out that API would have >> to return not an encoding, but a pair of an encoding and the rewound >> stream. > > The API wouldn't operate on streams. Instead, you pass a string, and > it either returns the detected encoding, or an information telling that > it needs more data. No streams. But in many cases you read the data out of a stream and pass it to an incremental XML parser. So if you're transcoding the input (either because the XML parser can't handle the encoding in question or because there's an external encoding specified, but it's not possible to pass that to the parser), a codec makes the most sense. >> For non-seekable, non-peekable streams (if any), what you'd >> need would be a stream that consisted of a concatenation of the >> buffered data used for detection and the continuation of the stream. > > The application would read data out of the stream, and pass it to > the detection. It then can process it in whatever manner it meant to > process it in the first place. Servus, Walter From mal at egenix.com Mon Nov 12 14:16:29 2007 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 12 Nov 2007 14:16:29 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: <473780A8.1060108@v.loewis.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> <4734F316.1040802@v.loewis.de> <4734FA67.10307@egenix.com> <473571AC.7020302@v.loewis.de> <4736E8D1.8020200@egenix.com> <473708EB.1060600@v.loewis.de> <47373DB1.6030908@egenix.com> <47374258.3070205@v.loewis.de> <47374A88.108@egenix.com> <473780A8.1060108@v.loewis.de> Message-ID: <4738522D.90807@egenix.com> On 2007-11-11 23:22, Martin v. L?wis wrote: >>>> First, XML-RPC is not the only mechanism using XML over a network >>>> connection. Second, you don't want to do this if you're dealing >>>> with several 100 MB of data just because you want to figure >>>> out the encoding. >>> That's my original claim/question: what SPECIFIC application do >>> you have in mind that transfers XML over a network and where you >>> would want to have such a stream codec? >> XML-based web services used for business integration, e.g. based >> on ebXML. >> >> A common use case from our everyday consulting business is e.g. >> passing market and trading data to portfolio pricing web services. > > I still don't see the need for this feature from this example. > First, in ebXML messaging, the message are typically *not* large > (i.e. much smaller than 100 MB). Furthermore, the typical processing > of such a message would be to pass it directly to the XML parser, > no need for the functionality under discussion. I don't see the point in continuing this discussion. If you think you know better, that's fine. Just please don't generalize this to everyone else working with Python and XML. >>> Right. However, I' will remain opposed to adding this to the >>> standard library until I see why one would absolutely need to >>> have that. Not every piece of code that is useful in some >>> application should be added to the standard library. >> Agreed, but the application space of web services is large >> enough to warrant this. > > If that was the case, wouldn't the existing Python web service > libraries already include such a functionality? No. To finalize this: We have a -1 from Martin and a +1 from Walter, Guido and myself. Pretty clear vote if you ask me. I'd say we end the discussion here and move on. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 12 2007) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From fdrake at acm.org Mon Nov 12 14:37:27 2007 From: fdrake at acm.org (Fred Drake) Date: Mon, 12 Nov 2007 08:37:27 -0500 Subject: [Python-Dev] XML codec? In-Reply-To: <4738522D.90807@egenix.com> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> <4734F316.1040802@v.loewis.de> <4734FA67.10307@egenix.com> <473571AC.7020302@v.loewis.de> <4736E8D1.8020200@egenix.com> <473708EB.1060600@v.loewis.de> <47373DB1.6030908@egenix.com> <47374258.3070205@v.loewis.de> <47374A88.108@egenix.com> <473780A8.1060108@v.loewis.de> <4738522D.90807@egenix.com> Message-ID: On Nov 12, 2007, at 8:16 AM, M.-A. Lemburg wrote: > We have a -1 from Martin and a +1 from Walter, Guido and myself. > Pretty clear vote if you ask me. I'd say we end the discussion here > and move on. If we're counting, you've got a -1 on the codec from me as well. Martin's right: there's no value to embedding the logic of auto- detection into the codec. A function somewhere in the xml package is all that's warranted. -Fred -- Fred Drake From walter at livinglogic.de Mon Nov 12 14:56:41 2007 From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=) Date: Mon, 12 Nov 2007 14:56:41 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> <4734F316.1040802@v.loewis.de> <4734FA67.10307@egenix.com> <473571AC.7020302@v.loewis.de> <4736E8D1.8020200@egenix.com> <473708EB.1060600@v.loewis.de> <47373DB1.6030908@egenix.com> <47374258.3070205@v.loewis.de> <47374A88.108@egenix.com> <473780A8.1060108@v.loewis.de> <4738522D.90807@egenix.com> Message-ID: <47385B99.8050903@livinglogic.de> Fred Drake wrote: > On Nov 12, 2007, at 8:16 AM, M.-A. Lemburg wrote: >> We have a -1 from Martin and a +1 from Walter, Guido and myself. >> Pretty clear vote if you ask me. I'd say we end the discussion here >> and move on. > > If we're counting, you've got a -1 on the codec from me as well. > Martin's right: there's no value to embedding the logic of auto- > detection into the codec. It isn't "embedded". codecs.detect_xml_encoding() is callable without any problems (though not documented). > A function somewhere in the xml package is > all that's warranted. Who would use such a function for what? Servus, Walter From fdrake at acm.org Mon Nov 12 16:23:50 2007 From: fdrake at acm.org (Fred Drake) Date: Mon, 12 Nov 2007 10:23:50 -0500 Subject: [Python-Dev] XML codec? In-Reply-To: <47385B99.8050903@livinglogic.de> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> <4734F316.1040802@v.loewis.de> <4734FA67.10307@egenix.com> <473571AC.7020302@v.loewis.de> <4736E8D1.8020200@egenix.com> <473708EB.1060600@v.loewis.de> <47373DB1.6030908@egenix.com> <47374258.3070205@v.loewis.de> <47374A88.108@egenix.com> <473780A8.1060108@v.loewis.de> <4738522D.90807@egenix.com> <47385B99.8050903@livinglogic.de> Message-ID: On Nov 12, 2007, at 8:56 AM, Walter D?rwald wrote: > It isn't "embedded". codecs.detect_xml_encoding() is callable without > any problems (though not documented). "Not documented" means not available, I think. > Who would use such a function for what? Being able to detect the encoding can be useful anytime you want information about a file, actually. In particular, presenting encoding information in a user interface (yes, you can call that contrived, but some people want to be able to see such things, and for them it's a requirement). If you want to parse the XML and re-encode, it's common to want to re-encode in the origin encoding; it's needed for that as well. If you just want to toss the text into an editor, the encoding is also needed. In that case, the codec approach *might* be acceptable (depending on the rest of the editor implementation), but the same re-encoding issue applies as well. Simply, it's sometimes desired to know the encoding for purposes that don't require immediate decoding. A function would be quite handing in these cases. -Fred -- Fred Drake From janssen at parc.com Mon Nov 12 16:54:53 2007 From: janssen at parc.com (Bill Janssen) Date: Mon, 12 Nov 2007 07:54:53 PST Subject: [Python-Dev] XML codec? In-Reply-To: References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> <4734F316.1040802@v.loewis.de> <4734FA67.10307@egenix.com> <473571AC.7020302@v.loewis.de> <4736E8D1.8020200@egenix.com> <473708EB.1060600@v.loewis.de> <47373DB1.6030908@egenix.com> <47374258.3070205@v.loewis.de> <47374A88.108@egenix.com> <473780A8.1060108@v.loewis.de> <4738522D.90807@egenix.com> <47385B99.8050903@livinglogic.de> Message-ID: <07Nov12.075502pst."57996"@synergy1.parc.xerox.com> > Simply, it's sometimes desired to know the encoding for purposes that > don't require immediate decoding. A function would be quite handy > in these cases. In os.path? os.path.encoding(location)? Bill From fdrake at acm.org Mon Nov 12 17:01:53 2007 From: fdrake at acm.org (Fred Drake) Date: Mon, 12 Nov 2007 11:01:53 -0500 Subject: [Python-Dev] XML codec? In-Reply-To: <07Nov12.075502pst."57996"@synergy1.parc.xerox.com> References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> <4734F316.1040802@v.loewis.de> <4734FA67.10307@egenix.com> <473571AC.7020302@v.loewis.de> <4736E8D1.8020200@egenix.com> <473708EB.1060600@v.loewis.de> <47373DB1.6030908@egenix.com> <47374258.3070205@v.loewis.de> <47374A88.108@egenix.com> <473780A8.1060108@v.loewis.de> <4738522D.90807@egenix.com> <47385B99.8050903@livinglogic.de> <07Nov12.075502pst."57996"@synergy1.parc.xerox.com> Message-ID: On Nov 12, 2007, at 10:54 AM, Bill Janssen wrote: > In os.path? os.path.encoding(location)? I wasn't thinking it would be that general; determining the encoding for an arbitrary text file is a larger problem than it is for an XML file. An implementation based strictly on the rules from the XML specification should be in the xml package (somewhere). Determining that the file is an XML file is separate. I doubt this really makes sense in os.path. -Fred -- Fred Drake From status at bugs.python.org Mon Nov 12 19:06:03 2007 From: status at bugs.python.org (Tracker) Date: Mon, 12 Nov 2007 18:06:03 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071112180603.B4B8478357@psf.upfronthosting.co.za> ACTIVITY SUMMARY (11/05/07 - 11/12/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1321 open (+17) / 11592 closed (+21) / 12913 total (+38) Open issues with patches: 418 Average duration of open issues: 689 days. Median duration of open issues: 791 days. Open Issues Breakdown open 1316 (+17) pending 5 ( +0) Issues Created Or Reopened (39) _______________________________ test_import breaks on Linux 11/09/07 http://bugs.python.org/issue1377 reopened gvanrossum py3k function comparing lacks NotImplemented error 11/05/07 http://bugs.python.org/issue1393 created _doublep simple patch, improving unreachable bytecode removing 11/05/07 http://bugs.python.org/issue1394 created _doublep patch py3k: duplicated line endings when using read(1) 11/06/07 http://bugs.python.org/issue1395 created amaury.forgeotdarc py3k py3k-pep3137: patch for mailbox 11/06/07 CLOSED http://bugs.python.org/issue1396 created tiran py3k, patch py3k-pep3137: failing unit test test_bsddb 11/06/07 http://bugs.python.org/issue1397 created tiran py3k Can't pickle partial functions 11/07/07 CLOSED http://bugs.python.org/issue1398 created danhs XML codec 11/07/07 http://bugs.python.org/issue1399 created doerwalter patch Py3k's print() flushing problem 11/07/07 http://bugs.python.org/issue1400 created wojtekwalczak py3k urllib2 302 POST 11/07/07 http://bugs.python.org/issue1401 created andresriancho Interpreter cleanup: order of _PyGILState_Fini and PyInterpreter 11/07/07 http://bugs.python.org/issue1402 created ronaldoussoren py_compile and compileall need unit tests 11/08/07 http://bugs.python.org/issue1403 created tiran py3k warnings module bug: BytesWarning: str() on a bytes instance 11/08/07 CLOSED http://bugs.python.org/issue1404 created tiran patch Garbage collection not working correctly in Python 2.3 11/09/07 CLOSED http://bugs.python.org/issue1405 reopened tiran Use widechar api for os.environ 11/08/07 CLOSED http://bugs.python.org/issue1406 created theller py3k, patch [performance] Too many closed() checkings 11/08/07 http://bugs.python.org/issue1407 created wojtekwalczak py3k Inconsistence in multiply list 11/08/07 CLOSED http://bugs.python.org/issue1408 created beco new keyword-only function parameters interact badly with nested 11/08/07 http://bugs.python.org/issue1409 created _doublep py3k BaseHTTPServer cannot accept Unicode data 11/08/07 CLOSED http://bugs.python.org/issue1410 created isonno A typo in tutorial 11/09/07 CLOSED http://bugs.python.org/issue1411 created falsetru test_subprocess fails on SuSE 10 11/09/07 http://bugs.python.org/issue1412 created dvadasz int literal methods inaccessible 11/09/07 CLOSED http://bugs.python.org/issue1413 created mykhal Fix for refleak tests 11/09/07 http://bugs.python.org/issue1414 created tiran py3k, patch py3k: pythonw.exe fails because std streams a missing 11/10/07 http://bugs.python.org/issue1415 created tiran py3k @prop.setter decorators 11/10/07 CLOSED http://bugs.python.org/issue1416 created gvanrossum patch Weakref not working properly 11/10/07 CLOSED http://bugs.python.org/issue1417 created MHOOO Python/hypot.c is never used 11/10/07 CLOSED http://bugs.python.org/issue1418 created marketdickinson ssl module version 1.10 causes TypeError when accepting connecti 11/11/07 CLOSED http://bugs.python.org/issue1419 created complex Unicode literals in tokenize.py and tests. 11/11/07 CLOSED http://bugs.python.org/issue1420 created ron_adam py3k, patch python.org: outdated and false information 11/11/07 CLOSED http://bugs.python.org/issue1421 created tiran Writing to an invalid fd doesn't raise an exception 11/11/07 CLOSED http://bugs.python.org/issue1422 created tiran py3k wave sunau aifc 16bit errors 11/11/07 http://bugs.python.org/issue1423 created jeroen py3k: readline and rlcompleter doesn't list choices 11/11/07 CLOSED http://bugs.python.org/issue1424 created tiran py3k readline: no display matches hook set 11/11/07 CLOSED http://bugs.python.org/issue1425 created tiran py3k readline module needs a review 11/11/07 http://bugs.python.org/issue1426 created tiran py3k Error in standard module calendar 11/11/07 CLOSED http://bugs.python.org/issue1427 created gdamjan patch Update to property.__doc__ 11/11/07 CLOSED http://bugs.python.org/issue1428 created tiran patch FD leak in SocketServer 11/12/07 http://bugs.python.org/issue1429 created luke-jr Installing on Vista asks to close Explorer (and Nokia PC Suite) 11/12/07 CLOSED http://bugs.python.org/issue1430 created dabarlow Issues Now Closed (41) ______________________ test_glob fails with UnicodeDecodeError 72 days http://bugs.python.org/issue1042 tiran rfe py3k: corrections for test_subprocess on windows 72 days http://bugs.python.org/issue1047 tiran patch file.seek allows float arguments 68 days http://bugs.python.org/issue1081 tiran py3k test_email failed 67 days http://bugs.python.org/issue1086 tiran rfe py3k os.popen result is not iterable, patch attached 67 days http://bugs.python.org/issue1087 tiran patch Problems with the msi installer - python-3.0a1.msi 64 days http://bugs.python.org/issue1110 tiran No tests for inspect.getfullargspec() 63 days http://bugs.python.org/issue1127 tiran py3k, patch test_urllib2net fails on test_ftp 57 days http://bugs.python.org/issue1157 tiran py3k Should itertools.count work for arbitrary integers? 53 days http://bugs.python.org/issue1165 rhettinger py3k pdb fails to launch some script. 33 days http://bugs.python.org/issue1254 tiran Trailing slash in sys.path cause import failure 20 days http://bugs.python.org/issue1293 gvanrossum patch Fix for test_netrc on Windows 9 days http://bugs.python.org/issue1345 tiran py3k, patch Add getsize() to io instances 13 days http://bugs.python.org/issue1351 loewis py3k, patch Windows fix for inspect tests 2 days http://bugs.python.org/issue1384 tiran py3k, patch hmac module violates RFC for some hash functions, e.g. sha512 2 days http://bugs.python.org/issue1385 jowagner py3k py3k-pep3137: struct module is leaking references 1 days http://bugs.python.org/issue1389 gvanrossum py3k py3k-pep3137: issue warnings / errors on str(bytes()) and simila 1 days http://bugs.python.org/issue1392 tiran py3k, patch py3k-pep3137: patch for mailbox 0 days http://bugs.python.org/issue1396 gvanrossum py3k, patch Can't pickle partial functions 1 days http://bugs.python.org/issue1398 tiran warnings module bug: BytesWarning: str() on a bytes instance 0 days http://bugs.python.org/issue1404 tiran patch Garbage collection not working correctly in Python 2.3 1 days http://bugs.python.org/issue1405 gvanrossum Use widechar api for os.environ 0 days http://bugs.python.org/issue1406 theller py3k, patch Inconsistence in multiply list 1 days http://bugs.python.org/issue1408 georg.brandl BaseHTTPServer cannot accept Unicode data 1 days http://bugs.python.org/issue1410 tiran A typo in tutorial 0 days http://bugs.python.org/issue1411 georg.brandl int literal methods inaccessible 0 days http://bugs.python.org/issue1413 loewis @prop.setter decorators 1 days http://bugs.python.org/issue1416 gvanrossum patch Weakref not working properly 1 days http://bugs.python.org/issue1417 MHOOO Python/hypot.c is never used 2 days http://bugs.python.org/issue1418 loewis ssl module version 1.10 causes TypeError when accepting connecti 2 days http://bugs.python.org/issue1419 gvanrossum Unicode literals in tokenize.py and tests. 1 days http://bugs.python.org/issue1420 gvanrossum py3k, patch python.org: outdated and false information 1 days http://bugs.python.org/issue1421 georg.brandl Writing to an invalid fd doesn't raise an exception 1 days http://bugs.python.org/issue1422 gvanrossum py3k py3k: readline and rlcompleter doesn't list choices 1 days http://bugs.python.org/issue1424 tiran py3k readline: no display matches hook set 0 days http://bugs.python.org/issue1425 loewis py3k Error in standard module calendar 0 days http://bugs.python.org/issue1427 doerwalter patch Update to property.__doc__ 0 days http://bugs.python.org/issue1428 tiran patch Installing on Vista asks to close Explorer (and Nokia PC Suite) 0 days http://bugs.python.org/issue1430 loewis Error on handling nan 1637 days http://bugs.python.org/issue737648 mike.verdone Intel icc build fails with optimizations -O2 227 days http://bugs.python.org/issue1689617 loewis contextmanager eats StopIteration 199 days http://bugs.python.org/issue1705170 ncoghlan Top Issues Most Discussed (10) ______________________________ 36 py3k: duplicated line endings when using read(1) 7 days open http://bugs.python.org/issue1395 12 toxml generates output that is not well formed 8 days open http://bugs.python.org/issue1390 11 py3k: pythonw.exe fails because std streams a missing 3 days open http://bugs.python.org/issue1415 11 int literal methods inaccessible 0 days closed http://bugs.python.org/issue1413 9 py3k-pep3137: issue warnings / errors on str(bytes()) and simil 1 days closed http://bugs.python.org/issue1392 9 Trailing slash in sys.path cause import failure 20 days closed http://bugs.python.org/issue1293 7 Unicode literals in tokenize.py and tests. 1 days closed http://bugs.python.org/issue1420 7 urllib2 302 POST 5 days open http://bugs.python.org/issue1401 6 BaseHTTPServer cannot accept Unicode data 1 days closed http://bugs.python.org/issue1410 6 new keyword-only function parameters interact badly with nested 4 days open http://bugs.python.org/issue1409 From brett at python.org Mon Nov 12 19:17:34 2007 From: brett at python.org (Brett Cannon) Date: Mon, 12 Nov 2007 10:17:34 -0800 Subject: [Python-Dev] Proposal for new 2to23 tool In-Reply-To: <6e8ddi$5a0mjm@mercury.eclipse.kcom.com> References: <6e8ddi$59lcj2@mercury.eclipse.kcom.com> <1194837874.8183.100.camel@localhost> <6e8ddi$5a0mjm@mercury.eclipse.kcom.com> Message-ID: On Nov 12, 2007 12:50 AM, Graham Horler wrote: > On 12 Nov 2007, 03:24:34, Jan Claeys wrote: > > > > Op zondag 11-11-2007 om 17:19 uur [tijdzone -0800], schreef Brett > > Cannon: > > > On Nov 11, 2007 4:00 PM, Graham Horler wrote: > > > > I have been developing in Python since 1.5, and now have to support 2.1 > > > > as a minimum version. I do like to keep my code runnable on newer > > > > versions however, and am considering the feasability of forward > > > > compatibility with Python 3.0. > > > > > > > > I also notice the Leo[1] project could use some assistance with forward > > > > compatibility. > > > > > > > > So I was wondering if anyone else had a need for a 2to23.py tool to help > > > > make code compatible with 3.0 but not break it for 2.x. > > > > > > What exactly are you proposing? We already have 2to3 > > > (http://svn.python.org/view/sandbox/trunk/2to3/) for source-to-source > > > translation from 2.x to 3.0. > > > > Graham wants to convert his code such that it works on both Python 2.x > > (probably even early versions of it?) & Python 3.x. Not 2 instances of > > code, but one source that works on both 2.x and 3.x... > > Absolutely > Well, we will do our best to make a common base between 2.6 and 3.0. But since things are still in flux who knows if everything can somehow be added through a __future__ statement in 2.6. As for supporting older versions, that won't happen. -Brett From collinw at gmail.com Mon Nov 12 19:48:54 2007 From: collinw at gmail.com (Collin Winter) Date: Mon, 12 Nov 2007 10:48:54 -0800 Subject: [Python-Dev] Proposal for new 2to23 tool In-Reply-To: <6e8ddi$5a0mjm@mercury.eclipse.kcom.com> References: <6e8ddi$59lcj2@mercury.eclipse.kcom.com> <1194837874.8183.100.camel@localhost> <6e8ddi$5a0mjm@mercury.eclipse.kcom.com> Message-ID: <43aa6ff70711121048m5614224bj3a132a96126762b2@mail.gmail.com> On Nov 12, 2007 12:50 AM, Graham Horler wrote: > On 12 Nov 2007, 03:24:34, Jan Claeys wrote: > > > > Op zondag 11-11-2007 om 17:19 uur [tijdzone -0800], schreef Brett > > Cannon: > > > On Nov 11, 2007 4:00 PM, Graham Horler wrote: > > > > I have been developing in Python since 1.5, and now have to support 2.1 > > > > as a minimum version. I do like to keep my code runnable on newer > > > > versions however, and am considering the feasability of forward > > > > compatibility with Python 3.0. > > > > > > > > I also notice the Leo[1] project could use some assistance with forward > > > > compatibility. > > > > > > > > So I was wondering if anyone else had a need for a 2to23.py tool to help > > > > make code compatible with 3.0 but not break it for 2.x. > > > > > > What exactly are you proposing? We already have 2to3 > > > (http://svn.python.org/view/sandbox/trunk/2to3/) for source-to-source > > > translation from 2.x to 3.0. > > > > Graham wants to convert his code such that it works on both Python 2.x > > (probably even early versions of it?) & Python 3.x. Not 2 instances of > > code, but one source that works on both 2.x and 3.x... > > Absolutely I don't believe that's possible. There are enough key differences between the two that having the same body of code work in both 2.x and 3.x would require an extensive, complicated runtime support system that no-one has all(the ability, the time, the motivation) to implement. And of course, even if you had such a system, the generated code wouldn't look anything like well-formed Python and would be a maintenance nightmare. Collin Winter From steve at holdenweb.com Mon Nov 12 20:02:14 2007 From: steve at holdenweb.com (Steve Holden) Date: Mon, 12 Nov 2007 14:02:14 -0500 Subject: [Python-Dev] Proposal for new 2to23 tool In-Reply-To: <43aa6ff70711121048m5614224bj3a132a96126762b2@mail.gmail.com> References: <6e8ddi$59lcj2@mercury.eclipse.kcom.com> <1194837874.8183.100.camel@localhost> <6e8ddi$5a0mjm@mercury.eclipse.kcom.com> <43aa6ff70711121048m5614224bj3a132a96126762b2@mail.gmail.com> Message-ID: <4738A336.7040909@holdenweb.com> Collin Winter wrote: > On Nov 12, 2007 12:50 AM, Graham Horler wrote: >> On 12 Nov 2007, 03:24:34, Jan Claeys wrote: >>> Op zondag 11-11-2007 om 17:19 uur [tijdzone -0800], schreef Brett >>> Cannon: >>>> On Nov 11, 2007 4:00 PM, Graham Horler wrote: >>>>> I have been developing in Python since 1.5, and now have to support 2.1 >>>>> as a minimum version. I do like to keep my code runnable on newer >>>>> versions however, and am considering the feasability of forward >>>>> compatibility with Python 3.0. >>>>> >>>>> I also notice the Leo[1] project could use some assistance with forward >>>>> compatibility. >>>>> >>>>> So I was wondering if anyone else had a need for a 2to23.py tool to help >>>>> make code compatible with 3.0 but not break it for 2.x. >>>> What exactly are you proposing? We already have 2to3 >>>> (http://svn.python.org/view/sandbox/trunk/2to3/) for source-to-source >>>> translation from 2.x to 3.0. >>> Graham wants to convert his code such that it works on both Python 2.x >>> (probably even early versions of it?) & Python 3.x. Not 2 instances of >>> code, but one source that works on both 2.x and 3.x... >> Absolutely > > I don't believe that's possible. There are enough key differences > between the two that having the same body of code work in both 2.x and > 3.x would require an extensive, complicated runtime support system > that no-one has all(the ability, the time, the motivation) to > implement. And of course, even if you had such a system, the generated > code wouldn't look anything like well-formed Python and would be a > maintenance nightmare. > Besides which, the migration path is already well-specified: write in 3.x-compatible 2.6 and use 2to3 to migrate the code with no further processing. This does eventually give you a single code base. Earlier versions need not apply - there is no way to accommodate them. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From steve at holdenweb.com Mon Nov 12 20:02:14 2007 From: steve at holdenweb.com (Steve Holden) Date: Mon, 12 Nov 2007 14:02:14 -0500 Subject: [Python-Dev] Proposal for new 2to23 tool In-Reply-To: <43aa6ff70711121048m5614224bj3a132a96126762b2@mail.gmail.com> References: <6e8ddi$59lcj2@mercury.eclipse.kcom.com> <1194837874.8183.100.camel@localhost> <6e8ddi$5a0mjm@mercury.eclipse.kcom.com> <43aa6ff70711121048m5614224bj3a132a96126762b2@mail.gmail.com> Message-ID: <4738A336.7040909@holdenweb.com> Collin Winter wrote: > On Nov 12, 2007 12:50 AM, Graham Horler wrote: >> On 12 Nov 2007, 03:24:34, Jan Claeys wrote: >>> Op zondag 11-11-2007 om 17:19 uur [tijdzone -0800], schreef Brett >>> Cannon: >>>> On Nov 11, 2007 4:00 PM, Graham Horler wrote: >>>>> I have been developing in Python since 1.5, and now have to support 2.1 >>>>> as a minimum version. I do like to keep my code runnable on newer >>>>> versions however, and am considering the feasability of forward >>>>> compatibility with Python 3.0. >>>>> >>>>> I also notice the Leo[1] project could use some assistance with forward >>>>> compatibility. >>>>> >>>>> So I was wondering if anyone else had a need for a 2to23.py tool to help >>>>> make code compatible with 3.0 but not break it for 2.x. >>>> What exactly are you proposing? We already have 2to3 >>>> (http://svn.python.org/view/sandbox/trunk/2to3/) for source-to-source >>>> translation from 2.x to 3.0. >>> Graham wants to convert his code such that it works on both Python 2.x >>> (probably even early versions of it?) & Python 3.x. Not 2 instances of >>> code, but one source that works on both 2.x and 3.x... >> Absolutely > > I don't believe that's possible. There are enough key differences > between the two that having the same body of code work in both 2.x and > 3.x would require an extensive, complicated runtime support system > that no-one has all(the ability, the time, the motivation) to > implement. And of course, even if you had such a system, the generated > code wouldn't look anything like well-formed Python and would be a > maintenance nightmare. > Besides which, the migration path is already well-specified: write in 3.x-compatible 2.6 and use 2to3 to migrate the code with no further processing. This does eventually give you a single code base. Earlier versions need not apply - there is no way to accommodate them. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From guido at python.org Mon Nov 12 20:44:50 2007 From: guido at python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 11:44:50 -0800 Subject: [Python-Dev] Proposal for new 2to23 tool In-Reply-To: <1194837874.8183.100.camel@localhost> References: <6e8ddi$59lcj2@mercury.eclipse.kcom.com> <1194837874.8183.100.camel@localhost> Message-ID: On Nov 11, 2007 7:24 PM, Jan Claeys wrote: > Graham wants to convert his code such that it works on both Python 2.x > (probably even early versions of it?) & Python 3.x. Not 2 instances of > code, but one source that works on both 2.x and 3.x... The transition strategy for 3.0 explicitly excludes this possibility. For example, you couldn't catch exceptions with an error variable, because the except clause syntax changed. You couldn't use print except to print a single string. You couldn't use unicode string literals; you couldn't distinguish between text and binary data in a meaningful way. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Mon Nov 12 22:21:41 2007 From: guido at python.org (Guido van Rossum) Date: Mon, 12 Nov 2007 13:21:41 -0800 Subject: [Python-Dev] Fwd: volunteers for a test In-Reply-To: <9A6A62B6B84859469F3EBB5F09D818CA291FB9@cernxchg50.cern.ch> References: <9A6A62B6B84859469F3EBB5F09D818CA291FB9@cernxchg50.cern.ch> Message-ID: Please indulge this off-topic post. I know there are a lot of Python developers here whose mother tongue is not English; would those folks mind participating in the experiment below? --Guido ---------- Forwarded message ---------- From: Jose Oriol Lopez Berengueres Date: Nov 12, 2007 12:22 PM Subject: volunteers for a test To: guido at python.org Dear Mr. Guido, A coleague and me at CERN are trying to measure the productivity differential of mothertonge and non-mothertonge programming... it just takes arround 3 minutes and we are looking. for all kinds of expert and non expert people... I was wondering since you are so famous if you know anybody willing to volunteer? http://cern.ch/test-volunteers Thanks a lot. J. oriol -- --Guido van Rossum (home page: http://www.python.org/~guido/) From andrewm at object-craft.com.au Mon Nov 12 23:35:00 2007 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Tue, 13 Nov 2007 09:35:00 +1100 Subject: [Python-Dev] XML codec? In-Reply-To: References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> <4734F316.1040802@v.loewis.de> <4734FA67.10307@egenix.com> <473571AC.7020302@v.loewis.de> <4736E8D1.8020200@egenix.com> <473708EB.1060600@v.loewis.de> <47373DB1.6030908@egenix.com> <47374258.3070205@v.loewis.de> <47374A88.108@egenix.com> <473780A8.1060108@v.loewis.de> <4738522D.90807@egenix.com> Message-ID: <20071112223500.C9B53600878@longblack.object-craft.com.au> >On Nov 12, 2007, at 8:16 AM, M.-A. Lemburg wrote: >> We have a -1 from Martin and a +1 from Walter, Guido and myself. >> Pretty clear vote if you ask me. I'd say we end the discussion here >> and move on. > >If we're counting, you've got a -1 on the codec from me as well. >Martin's right: there's no value to embedding the logic of auto- >detection into the codec. A function somewhere in the xml package is >all that's warranted. I agree with Fred here - it should be a function in the xml package, not a codec. -1 -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From walter at livinglogic.de Tue Nov 13 13:01:55 2007 From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=) Date: Tue, 13 Nov 2007 13:01:55 +0100 Subject: [Python-Dev] XML codec? In-Reply-To: References: <4731FB82.8020001@livinglogic.de> <4732A73C.4000803@v.loewis.de> <4732F8EA.6010605@livinglogic.de> <473357DE.5010805@v.loewis.de> <47337924.6030107@livinglogic.de> <47343958.6090309@livinglogic.de> <47344AE1.1030707@v.loewis.de> <47345C40.1030002@livinglogic.de> <47345F1B.4090907@egenix.com> <4734D06A.2020000@v.loewis.de> <4734E662.9070708@egenix.com> <4734F316.1040802@v.loewis.de> <4734FA67.10307@egenix.com> <473571AC.7020302@v.loewis.de> <4736E8D1.8020200@egenix.com> <473708EB.1060600@v.loewis.de> <47373DB1.6030908@egenix.com> <47374258.3070205@v.loewis.de> <47374A88.108@egenix.com> <473780A8.1060108@v.loewis.de> <4738522D.90807@egenix.com> <47385B99.8050903@livinglogic.de> Message-ID: <47399233.9080107@livinglogic.de> Fred Drake wrote: > On Nov 12, 2007, at 8:56 AM, Walter D?rwald wrote: >> It isn't "embedded". codecs.detect_xml_encoding() is callable without >> any problems (though not documented). > > "Not documented" means not available, I think. I just din't think that someone wants the detection function, but not the codec, so I left the function undocumented. >> Who would use such a function for what? > > Being able to detect the encoding can be useful anytime you want > information about a file, actually. In particular, presenting encoding > information in a user interface (yes, you can call that contrived, but > some people want to be able to see such things, and for them it's a > requirement). And if you want to display the XML you'd need to decode it. An example might be a text viewer. E.g. Apples QuickLook. > If you want to parse the XML and re-encode, it's common > to want to re-encode in the origin encoding; it's needed for that as > well. If you just want to toss the text into an editor, the encoding is > also needed. In that case, the codec approach *might* be acceptable > (depending on the rest of the editor implementation), but the same > re-encoding issue applies as well. > > Simply, it's sometimes desired to know the encoding for purposes that > don't require immediate decoding. A function would be quite handing in > these cases. So the consensus seems to be: Add an encoding detection function (implemented in Python) to the xml module? Servus, Walter From status at bugs.python.org Tue Nov 13 19:06:07 2007 From: status at bugs.python.org (Tracker) Date: Tue, 13 Nov 2007 18:06:07 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071113180607.5182678055@psf.upfronthosting.co.za> ACTIVITY SUMMARY (11/06/07 - 11/13/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1323 open (+17) / 11597 closed (+23) / 12920 total (+40) Open issues with patches: 418 Average duration of open issues: 689 days. Median duration of open issues: 795 days. Open Issues Breakdown open 1318 (+17) pending 5 ( +0) Issues Created Or Reopened (41) _______________________________ test_import breaks on Linux 11/09/07 http://bugs.python.org/issue1377 reopened gvanrossum py3k Can't pickle partial functions 11/07/07 CLOSED http://bugs.python.org/issue1398 created danhs XML codec 11/07/07 http://bugs.python.org/issue1399 created doerwalter patch Py3k's print() flushing problem 11/07/07 http://bugs.python.org/issue1400 created wojtekwalczak py3k urllib2 302 POST 11/07/07 http://bugs.python.org/issue1401 created andresriancho Interpreter cleanup: order of _PyGILState_Fini and PyInterpreter 11/07/07 http://bugs.python.org/issue1402 created ronaldoussoren py_compile and compileall need unit tests 11/08/07 http://bugs.python.org/issue1403 created tiran py3k warnings module bug: BytesWarning: str() on a bytes instance 11/08/07 CLOSED http://bugs.python.org/issue1404 created tiran patch Garbage collection not working correctly in Python 2.3 11/09/07 CLOSED http://bugs.python.org/issue1405 reopened tiran Use widechar api for os.environ 11/08/07 CLOSED http://bugs.python.org/issue1406 created theller py3k, patch [performance] Too many closed() checkings 11/08/07 http://bugs.python.org/issue1407 created wojtekwalczak py3k Inconsistence in multiply list 11/08/07 CLOSED http://bugs.python.org/issue1408 created beco new keyword-only function parameters interact badly with nested 11/08/07 http://bugs.python.org/issue1409 created _doublep py3k BaseHTTPServer cannot accept Unicode data 11/08/07 CLOSED http://bugs.python.org/issue1410 created isonno A typo in tutorial 11/09/07 CLOSED http://bugs.python.org/issue1411 created falsetru test_subprocess fails on SuSE 10 11/09/07 http://bugs.python.org/issue1412 created dvadasz int literal methods inaccessible 11/09/07 CLOSED http://bugs.python.org/issue1413 created mykhal Fix for refleak tests 11/09/07 http://bugs.python.org/issue1414 created tiran py3k, patch py3k: pythonw.exe fails because std streams a missing 11/10/07 CLOSED http://bugs.python.org/issue1415 created tiran py3k @prop.setter decorators 11/10/07 CLOSED http://bugs.python.org/issue1416 created gvanrossum patch Weakref not working properly 11/10/07 CLOSED http://bugs.python.org/issue1417 created MHOOO Python/hypot.c is never used 11/10/07 CLOSED http://bugs.python.org/issue1418 created marketdickinson ssl module version 1.10 causes TypeError when accepting connecti 11/11/07 CLOSED http://bugs.python.org/issue1419 created complex Unicode literals in tokenize.py and tests. 11/11/07 CLOSED http://bugs.python.org/issue1420 created ron_adam py3k, patch python.org: outdated and false information 11/11/07 CLOSED http://bugs.python.org/issue1421 created tiran Writing to an invalid fd doesn't raise an exception 11/11/07 CLOSED http://bugs.python.org/issue1422 created tiran py3k wave sunau aifc 16bit errors 11/11/07 http://bugs.python.org/issue1423 created jeroen py3k: readline and rlcompleter doesn't list choices 11/11/07 CLOSED http://bugs.python.org/issue1424 created tiran py3k readline: no display matches hook set 11/11/07 CLOSED http://bugs.python.org/issue1425 created tiran py3k readline module needs a review 11/11/07 CLOSED http://bugs.python.org/issue1426 created tiran py3k Error in standard module calendar 11/11/07 CLOSED http://bugs.python.org/issue1427 created gdamjan patch Update to property.__doc__ 11/11/07 CLOSED http://bugs.python.org/issue1428 created tiran patch FD leak in SocketServer 11/12/07 http://bugs.python.org/issue1429 created luke-jr Installing on Vista asks to close Explorer (and Nokia PC Suite) 11/12/07 CLOSED http://bugs.python.org/issue1430 created dabarlow pth files not loaded at startup 11/12/07 http://bugs.python.org/issue1431 created gbloisi patch Strange behavior of urlparse.urljoin 11/13/07 http://bugs.python.org/issue1432 created yan marshal roundtripping for unicode 11/13/07 http://bugs.python.org/issue1433 created cfbolz SocketServer creates non-blocking files 11/13/07 http://bugs.python.org/issue1434 created luke-jr Support for multiple handlers for the "with" statement 11/13/07 http://bugs.python.org/issue1435 created Stavros logging.config.fileConfig, NameError: name 'RotatingFileHandler' 11/13/07 http://bugs.python.org/issue1436 created sebastian List member inside a class is shared by all instances of the cla 11/13/07 CLOSED http://bugs.python.org/issue1437 created glubglub Issues Now Closed (41) ______________________ test_glob fails with UnicodeDecodeError 72 days http://bugs.python.org/issue1042 tiran rfe py3k: corrections for test_subprocess on windows 72 days http://bugs.python.org/issue1047 tiran patch file.seek allows float arguments 68 days http://bugs.python.org/issue1081 tiran py3k test_email failed 67 days http://bugs.python.org/issue1086 tiran rfe py3k os.popen result is not iterable, patch attached 67 days http://bugs.python.org/issue1087 tiran patch Problems with the msi installer - python-3.0a1.msi 64 days http://bugs.python.org/issue1110 tiran No tests for inspect.getfullargspec() 63 days http://bugs.python.org/issue1127 tiran py3k, patch test_urllib2net fails on test_ftp 57 days http://bugs.python.org/issue1157 tiran py3k Should itertools.count work for arbitrary integers? 53 days http://bugs.python.org/issue1165 rhettinger py3k pdb fails to launch some script. 33 days http://bugs.python.org/issue1254 tiran pdb bug with "with" statement 33 days http://bugs.python.org/issue1265 amaury.forgeotdarc py3k Trailing slash in sys.path cause import failure 20 days http://bugs.python.org/issue1293 gvanrossum patch Add getsize() to io instances 13 days http://bugs.python.org/issue1351 loewis py3k, patch py3k-pep3137: patch for mailbox 0 days http://bugs.python.org/issue1396 gvanrossum py3k, patch Can't pickle partial functions 1 days http://bugs.python.org/issue1398 tiran warnings module bug: BytesWarning: str() on a bytes instance 0 days http://bugs.python.org/issue1404 tiran patch Garbage collection not working correctly in Python 2.3 1 days http://bugs.python.org/issue1405 gvanrossum Use widechar api for os.environ 0 days http://bugs.python.org/issue1406 theller py3k, patch Inconsistence in multiply list 1 days http://bugs.python.org/issue1408 georg.brandl BaseHTTPServer cannot accept Unicode data 1 days http://bugs.python.org/issue1410 tiran A typo in tutorial 0 days http://bugs.python.org/issue1411 georg.brandl int literal methods inaccessible 0 days http://bugs.python.org/issue1413 loewis py3k: pythonw.exe fails because std streams a missing 4 days http://bugs.python.org/issue1415 amaury.forgeotdarc py3k @prop.setter decorators 1 days http://bugs.python.org/issue1416 gvanrossum patch Weakref not working properly 1 days http://bugs.python.org/issue1417 MHOOO Python/hypot.c is never used 2 days http://bugs.python.org/issue1418 loewis ssl module version 1.10 causes TypeError when accepting connecti 3 days http://bugs.python.org/issue1419 janssen Unicode literals in tokenize.py and tests. 1 days http://bugs.python.org/issue1420 gvanrossum py3k, patch python.org: outdated and false information 1 days http://bugs.python.org/issue1421 georg.brandl Writing to an invalid fd doesn't raise an exception 1 days http://bugs.python.org/issue1422 gvanrossum py3k py3k: readline and rlcompleter doesn't list choices 1 days http://bugs.python.org/issue1424 tiran py3k readline: no display matches hook set 0 days http://bugs.python.org/issue1425 loewis py3k readline module needs a review 1 days http://bugs.python.org/issue1426 tiran py3k Error in standard module calendar 0 days http://bugs.python.org/issue1427 doerwalter patch Update to property.__doc__ 0 days http://bugs.python.org/issue1428 tiran patch Installing on Vista asks to close Explorer (and Nokia PC Suite) 0 days http://bugs.python.org/issue1430 loewis List member inside a class is shared by all instances of the cla 0 days http://bugs.python.org/issue1437 tiran Error on handling nan 1637 days http://bugs.python.org/issue737648 mike.verdone Intel icc build fails with optimizations -O2 227 days http://bugs.python.org/issue1689617 loewis interpreter crash when multiplying large lists 206 days http://bugs.python.org/issue1704621 gvanrossum patch contextmanager eats StopIteration 199 days http://bugs.python.org/issue1705170 ncoghlan Top Issues Most Discussed (10) ______________________________ 29 py3k: duplicated line endings when using read(1) 8 days open http://bugs.python.org/issue1395 25 py3k: pythonw.exe fails because std streams a missing 4 days closed http://bugs.python.org/issue1415 11 int literal methods inaccessible 0 days closed http://bugs.python.org/issue1413 9 toxml generates output that is not well formed 9 days open http://bugs.python.org/issue1390 9 Trailing slash in sys.path cause import failure 20 days closed http://bugs.python.org/issue1293 7 Unicode literals in tokenize.py and tests. 1 days closed http://bugs.python.org/issue1420 7 Fix for refleak tests 4 days open http://bugs.python.org/issue1414 7 urllib2 302 POST 6 days open http://bugs.python.org/issue1401 7 pdb bug with "with" statement 33 days closed http://bugs.python.org/issue1265 6 BaseHTTPServer cannot accept Unicode data 1 days closed http://bugs.python.org/issue1410 From amauryfa at gmail.com Tue Nov 13 22:05:24 2007 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Tue, 13 Nov 2007 22:05:24 +0100 Subject: [Python-Dev] New python developer Message-ID: Hello, As you may have seen, I have recently been granted developer privileges on python svn. Let me introduce myself. I am French, 35 years old, and father of 5 children. I work as a programmer in a fund manager company, and have been working with python for eight years now. What I mostly like in python are: - fun to work with - its robustness: not only against bugs, but the stability of its concepts, and the readability of its code base; - easy to interface with any other system. To start with python development, I think I will try to help with python3.0, or picking some bugs in the issue tracker. I have some knowledge of the python internals, with hours of debugging sessions of a C++ application mixed with the python interpreter. And I think I have read almost every svn commit for two years. I can also help on win32 specific development. As an example, I find that the distutils module don't work very well with the new compilers. I won't be of much help on Unix, though. I also like good and accurate documentation. Even if my english may be poor sometimes, I can help with writing some parts. Digging in the code to extract specifications is one of my favourite jobs. And of course I can help on other subjects if there is some interest. I am very excited to take part in this great project. So please forgive me if I do something wrong or too quickly. And your (kind) remarks will always be welcome. -- Amaury Forgeot d'Arc From guido at python.org Tue Nov 13 22:30:47 2007 From: guido at python.org (Guido van Rossum) Date: Tue, 13 Nov 2007 13:30:47 -0800 Subject: [Python-Dev] New python developer In-Reply-To: References: Message-ID: Welcome Amaury! Your contributions have already been most helpful. Thanks for letting us peek at your background! --Guido On Nov 13, 2007 1:05 PM, Amaury Forgeot d'Arc wrote: > Hello, > > As you may have seen, I have recently been granted developer > privileges on python svn. > > Let me introduce myself. I am French, 35 years old, and father of 5 children. > I work as a programmer in a fund manager company, and have been > working with python for eight years now. > > What I mostly like in python are: > - fun to work with > - its robustness: not only against bugs, but the stability of its > concepts, and the readability of its code base; > - easy to interface with any other system. > > To start with python development, I think I will try to help with > python3.0, or picking some bugs in the issue tracker. > > I have some knowledge of the python internals, with hours of debugging > sessions of a C++ application mixed with the python interpreter. And I > think I have read almost every svn commit for two years. > > I can also help on win32 specific development. As an example, I find > that the distutils module don't work very well with the new compilers. > I won't be of much help on Unix, though. > I also like good and accurate documentation. Even if my english may be > poor sometimes, I can help with writing some parts. Digging in the > code to extract specifications is one of my favourite jobs. > And of course I can help on other subjects if there is some interest. > > I am very excited to take part in this great project. So please > forgive me if I do something wrong or too quickly. And your (kind) > remarks will always be welcome. > > -- > Amaury Forgeot d'Arc > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From brett at python.org Wed Nov 14 00:17:00 2007 From: brett at python.org (Brett Cannon) Date: Tue, 13 Nov 2007 15:17:00 -0800 Subject: [Python-Dev] New python developer In-Reply-To: References: Message-ID: On Nov 13, 2007 1:05 PM, Amaury Forgeot d'Arc wrote: > Hello, > > As you may have seen, I have recently been granted developer > privileges on python svn. Welcome aboard, Amaury! -Brett From python at rcn.com Wed Nov 14 02:06:50 2007 From: python at rcn.com (Raymond Hettinger) Date: Tue, 13 Nov 2007 20:06:50 -0500 (EST) Subject: [Python-Dev] New python developer Message-ID: <20071113200650.ABI52066@ms19.lnh.mail.rcn.net> > As you may have seen, I have recently been granted developer > privileges on python svn. Hello Amaury. Welcome aboard. Raymond From lists at cheimes.de Wed Nov 14 03:15:11 2007 From: lists at cheimes.de (Christian Heimes) Date: Wed, 14 Nov 2007 03:15:11 +0100 Subject: [Python-Dev] Hello, I'm the other new guy Message-ID: <473A5A2F.6090203@cheimes.de> Hello Pythonistas and fellow core developers! After Amaury introduced himself I've decided that I *have* to take some time to introduce myself, too. Hello, my name is Christian Heimes and I'm a 28 years old German from Aachen. Aachen is a beautiful city about 70km West to Cologne and near the borders to The Netherlands and Belgium. Some of you may know me from #python as Crys (|Crys| or Crys_) or my former nick Tiran. Others may have seen me at some Python related conferences like EuroPython 2003 in Charleroi/Belgium, 2004+2005 in Gothenburg/Sweden, DZUG 2004 at the DESY/Hamburg or Plone Conference 2004/Vienna. Before I'm going to bore you with the (Python) story of my life let me tell you something about my persona. I'm of average build and average height but people usually don't describe me as an average guy. Unless you see the more Metal and Gothic like chap with glasses, chin-beard and very long hair in black cloths, boots and a hat as ordinary. *g* When I'm not sitting in front of my box I'm spending time with my beautiful girl friend, listening to music, my friends or in a disco. I enjoy cooking but I rarely spend time in front of the TV. I only watch some well selected series like Myth Busters + LOST and information channels like ARTE. My more exotic hobby is Medieval Living History, also known as Reenactment although we don't take it as serious as Reenacters. I usually describe it as a counter weight to my science and computer interests. We are tailoring cloths and living in tents or castles like people about 1200 to 600 years ago. That is without electricity, mobile phones and computers as much as it is possible these days. It's like a vacation from the modern world for a view days or entire week for me. Now here is the story how Python entered my life: I had my first real contact with Python in 2002 when some friends and me were evaluation web frameworks for the relaunch of our community site. We were all frustrated from our past experiences with PHP and MySQL and were looking for something innovative and more professional. Quickly we were brim over with enthusiasm for Zope3 and Python. But Zope3 wasn't ready in 2002 and the community project went dead after some internal frictions and lack of time. But I kept learning Python and playing around with Zope3 and Zope2. After some Zope related jobs I came in contact with Plone and eventually became a Plone core developer and elected board member of the newly formed Plone Foundation. Unfortunately personal and health problems forced me to drop everything. After things went better again I focused on other areas like PyQt4, Twisted. C#/.NET and PythonDotNET in order to broaden my knowledge and learn other techniques beside CMS and web applications. I came to Python C development as I worked on PythonDotNET for one of my projects. Although it might sound strange how a .NET and C# project got me into C and Python C API but it's easy to explain. In order to fix PythonDotNET for Python 2.5, Mono and UCS-4 builds of Python I had to familiarize myself with the C API of Python. The project is a bridge between CPython and .NET and not related to IronPython. The C# is doing a lot of calls into the C library using a technology that can be compared to ctypes. The code jumps forth and back between C, C#/.NET and Python code. It's a nightmare to debug problems but it's fun, too. Once I had overcome my fear of Python's C API I saw its elegance and started to contribute to Python's core. I wrote some patches for Python 3000 because I saw an opportunity to get involved and contribute. And because I like to play with new stuff ;) After a heap of patches and bug reports Guido finally granted me developer privileges. I'm planing to focus my work on Python 3000. I'm a Linux user (10 years server and 5 years work station experience) but I've a VMWare running to test patches on Windows XP, too. Questions? :) Christian From facundobatista at gmail.com Wed Nov 14 12:20:55 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Wed, 14 Nov 2007 09:20:55 -0200 Subject: [Python-Dev] Hello, I'm the other new guy In-Reply-To: <473A5A2F.6090203@cheimes.de> References: <473A5A2F.6090203@cheimes.de> Message-ID: 2007/11/14, Christian Heimes : > After Amaury introduced himself I've decided that I *have* to take some > time to introduce myself, too. Welcome you both to this journey. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From status at bugs.python.org Wed Nov 14 19:06:07 2007 From: status at bugs.python.org (Tracker) Date: Wed, 14 Nov 2007 18:06:07 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071114180607.2844E781F7@psf.upfronthosting.co.za> ACTIVITY SUMMARY (11/07/07 - 11/14/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1325 open (+18) / 11600 closed (+25) / 12925 total (+43) Open issues with patches: 421 Average duration of open issues: 689 days. Median duration of open issues: 797 days. Open Issues Breakdown open 1320 (+18) pending 5 ( +0) Issues Created Or Reopened (44) _______________________________ test_import breaks on Linux 11/09/07 http://bugs.python.org/issue1377 reopened gvanrossum py3k Py3k's print() flushing problem 11/07/07 http://bugs.python.org/issue1400 created wojtekwalczak py3k urllib2 302 POST 11/07/07 http://bugs.python.org/issue1401 created andresriancho Interpreter cleanup: order of _PyGILState_Fini and PyInterpreter 11/07/07 http://bugs.python.org/issue1402 created ronaldoussoren py_compile and compileall need unit tests 11/08/07 http://bugs.python.org/issue1403 created tiran py3k warnings module bug: BytesWarning: str() on a bytes instance 11/08/07 CLOSED http://bugs.python.org/issue1404 created tiran patch Garbage collection not working correctly in Python 2.3 11/09/07 CLOSED http://bugs.python.org/issue1405 reopened tiran Use widechar api for os.environ 11/08/07 CLOSED http://bugs.python.org/issue1406 created theller py3k, patch [performance] Too many closed() checkings 11/08/07 http://bugs.python.org/issue1407 created wojtekwalczak py3k Inconsistence in multiply list 11/08/07 CLOSED http://bugs.python.org/issue1408 created beco new keyword-only function parameters interact badly with nested 11/08/07 http://bugs.python.org/issue1409 created _doublep py3k BaseHTTPServer cannot accept Unicode data 11/08/07 CLOSED http://bugs.python.org/issue1410 created isonno A typo in tutorial 11/09/07 CLOSED http://bugs.python.org/issue1411 created falsetru test_subprocess fails on SuSE 10 11/09/07 http://bugs.python.org/issue1412 created dvadasz int literal methods inaccessible 11/09/07 CLOSED http://bugs.python.org/issue1413 created mykhal Fix for refleak tests 11/09/07 http://bugs.python.org/issue1414 created tiran py3k, patch py3k: pythonw.exe fails because std streams a missing 11/10/07 CLOSED http://bugs.python.org/issue1415 created tiran py3k @prop.setter decorators 11/10/07 CLOSED http://bugs.python.org/issue1416 created gvanrossum patch Weakref not working properly 11/10/07 CLOSED http://bugs.python.org/issue1417 created MHOOO Python/hypot.c is never used 11/10/07 CLOSED http://bugs.python.org/issue1418 created marketdickinson ssl module version 1.10 causes TypeError when accepting connecti 11/11/07 CLOSED http://bugs.python.org/issue1419 created complex Unicode literals in tokenize.py and tests. 11/11/07 CLOSED http://bugs.python.org/issue1420 created ron_adam py3k, patch python.org: outdated and false information 11/11/07 CLOSED http://bugs.python.org/issue1421 created tiran Writing to an invalid fd doesn't raise an exception 11/11/07 CLOSED http://bugs.python.org/issue1422 created tiran py3k wave sunau aifc 16bit errors 11/11/07 http://bugs.python.org/issue1423 created jeroen py3k: readline and rlcompleter doesn't list choices 11/11/07 CLOSED http://bugs.python.org/issue1424 created tiran py3k readline: no display matches hook set 11/11/07 CLOSED http://bugs.python.org/issue1425 created tiran py3k readline module needs a review 11/11/07 CLOSED http://bugs.python.org/issue1426 created tiran py3k Error in standard module calendar 11/11/07 CLOSED http://bugs.python.org/issue1427 created gdamjan patch Update to property.__doc__ 11/11/07 CLOSED http://bugs.python.org/issue1428 created tiran patch FD leak in SocketServer 11/12/07 http://bugs.python.org/issue1429 created luke-jr Installing on Vista asks to close Explorer (and Nokia PC Suite) 11/12/07 CLOSED http://bugs.python.org/issue1430 created dabarlow pth files not loaded at startup 11/12/07 http://bugs.python.org/issue1431 created gbloisi patch Strange behavior of urlparse.urljoin 11/13/07 http://bugs.python.org/issue1432 created yan marshal roundtripping for unicode 11/13/07 CLOSED http://bugs.python.org/issue1433 created cfbolz SocketServer creates non-blocking files 11/13/07 http://bugs.python.org/issue1434 created luke-jr Support for multiple handlers for the "with" statement 11/13/07 CLOSED http://bugs.python.org/issue1435 created Stavros logging.config.fileConfig, NameError: name 'RotatingFileHandler' 11/13/07 CLOSED http://bugs.python.org/issue1436 created sebastian List member inside a class is shared by all instances of the cla 11/13/07 CLOSED http://bugs.python.org/issue1437 created glubglub Calling base class methods is slow due to __instancecheck__ over 11/13/07 http://bugs.python.org/issue1438 created gvanrossum proposed 3000 patch for socket.py - "socket GC worries" 11/13/07 http://bugs.python.org/issue1439 created janssen py3k, patch Checks for PySys_GetObject("std???") == Py_None 11/14/07 http://bugs.python.org/issue1440 created tiran py3k, patch Cycles through ob_type aren't freed 11/14/07 http://bugs.python.org/issue1441 created rhamphoryncus pythonstartup addition of minor error checking 11/14/07 http://bugs.python.org/issue1442 created JosephArmbruster patch Issues Now Closed (40) ______________________ test_glob fails with UnicodeDecodeError 72 days http://bugs.python.org/issue1042 tiran rfe py3k: corrections for test_subprocess on windows 72 days http://bugs.python.org/issue1047 tiran patch file.seek allows float arguments 68 days http://bugs.python.org/issue1081 tiran py3k test_email failed 67 days http://bugs.python.org/issue1086 tiran rfe py3k os.popen result is not iterable, patch attached 67 days http://bugs.python.org/issue1087 tiran patch Problems with the msi installer - python-3.0a1.msi 64 days http://bugs.python.org/issue1110 tiran No tests for inspect.getfullargspec() 63 days http://bugs.python.org/issue1127 tiran py3k, patch test_urllib2net fails on test_ftp 57 days http://bugs.python.org/issue1157 tiran py3k Should itertools.count work for arbitrary integers? 53 days http://bugs.python.org/issue1165 rhettinger py3k pdb fails to launch some script. 33 days http://bugs.python.org/issue1254 tiran pdb bug with "with" statement 33 days http://bugs.python.org/issue1265 amaury.forgeotdarc py3k Add getsize() to io instances 13 days http://bugs.python.org/issue1351 loewis py3k, patch Can't pickle partial functions 1 days http://bugs.python.org/issue1398 tiran warnings module bug: BytesWarning: str() on a bytes instance 0 days http://bugs.python.org/issue1404 tiran patch Garbage collection not working correctly in Python 2.3 1 days http://bugs.python.org/issue1405 gvanrossum Use widechar api for os.environ 0 days http://bugs.python.org/issue1406 theller py3k, patch Inconsistence in multiply list 1 days http://bugs.python.org/issue1408 georg.brandl BaseHTTPServer cannot accept Unicode data 1 days http://bugs.python.org/issue1410 tiran A typo in tutorial 0 days http://bugs.python.org/issue1411 georg.brandl int literal methods inaccessible 0 days http://bugs.python.org/issue1413 loewis py3k: pythonw.exe fails because std streams a missing 4 days http://bugs.python.org/issue1415 amaury.forgeotdarc py3k @prop.setter decorators 1 days http://bugs.python.org/issue1416 gvanrossum patch Weakref not working properly 4 days http://bugs.python.org/issue1417 gagenellina Python/hypot.c is never used 2 days http://bugs.python.org/issue1418 loewis ssl module version 1.10 causes TypeError when accepting connecti 3 days http://bugs.python.org/issue1419 janssen Unicode literals in tokenize.py and tests. 1 days http://bugs.python.org/issue1420 gvanrossum py3k, patch python.org: outdated and false information 1 days http://bugs.python.org/issue1421 georg.brandl Writing to an invalid fd doesn't raise an exception 1 days http://bugs.python.org/issue1422 gvanrossum py3k py3k: readline and rlcompleter doesn't list choices 1 days http://bugs.python.org/issue1424 tiran py3k readline: no display matches hook set 0 days http://bugs.python.org/issue1425 loewis py3k readline module needs a review 1 days http://bugs.python.org/issue1426 tiran py3k Error in standard module calendar 0 days http://bugs.python.org/issue1427 doerwalter patch Update to property.__doc__ 0 days http://bugs.python.org/issue1428 tiran patch Installing on Vista asks to close Explorer (and Nokia PC Suite) 0 days http://bugs.python.org/issue1430 loewis marshal roundtripping for unicode 0 days http://bugs.python.org/issue1433 loewis Support for multiple handlers for the "with" statement 0 days http://bugs.python.org/issue1435 gvanrossum logging.config.fileConfig, NameError: name 'RotatingFileHandler' 0 days http://bugs.python.org/issue1436 vsajip List member inside a class is shared by all instances of the cla 0 days http://bugs.python.org/issue1437 tiran Intel icc build fails with optimizations -O2 227 days http://bugs.python.org/issue1689617 loewis interpreter crash when multiplying large lists 206 days http://bugs.python.org/issue1704621 gvanrossum patch Top Issues Most Discussed (10) ______________________________ 25 py3k: pythonw.exe fails because std streams a missing 4 days closed http://bugs.python.org/issue1415 21 py3k: duplicated line endings when using read(1) 9 days open http://bugs.python.org/issue1395 11 int literal methods inaccessible 0 days closed http://bugs.python.org/issue1413 8 Parsing a simple script eats all of your memory 67 days open http://bugs.python.org/issue1134 7 Unicode literals in tokenize.py and tests. 1 days closed http://bugs.python.org/issue1420 7 Fix for refleak tests 5 days open http://bugs.python.org/issue1414 7 urllib2 302 POST 7 days open http://bugs.python.org/issue1401 7 pdb bug with "with" statement 33 days closed http://bugs.python.org/issue1265 6 BaseHTTPServer cannot accept Unicode data 1 days closed http://bugs.python.org/issue1410 6 new keyword-only function parameters interact badly with nested 6 days open http://bugs.python.org/issue1409 From ijmorlan at cs.uwaterloo.ca Wed Nov 14 19:30:04 2007 From: ijmorlan at cs.uwaterloo.ca (Isaac Morland) Date: Wed, 14 Nov 2007 13:30:04 -0500 (EST) Subject: [Python-Dev] Suggestions for Improvements to namedtuple Message-ID: I was working on something very similar to namedtuple for a project of my own, when it occurred to me that it's generally useful idea and maybe somebody else was working on it too. So I searched, and found Raymond Hettinger's addition to collections.py, and it does pretty much what I want. I have a few suggestions which I hope are improvements. I will discuss each one, and then at the bottom I will put my version of namedtuple. It is not based on the one in Python SVN because it was mostly written before I found out about that one. If my suggestions meet with approval, I could check out a copy of collections.py and make a patch for further comment and eventual submission to somebody with checkin privileges. 1. I think it is important that there be a way to create individual namedtuple instances from an existing sequence that doesn't involve splitting the sequence out into individual parameters and then re-assembling a tuple to pass to the base tuple constructor. In my application, I'm taking database rows and creating named tuples from them, with the named tuple type being automatically created as appropriate. So there will be *lots* of named tuple instances created, so for efficiency I would prefer to avoid using * to break up the sequences generated directly by the database interface. I would like to pass those sequences directly to the base tuple constructor. To restore to my code the feature of being able to use individual parameters as in collections.py, I added a classmethod to the generated classes called __fromvalues__. This uses Signature, my other idea (next message) to convert a call matching a procedure signature of (fieldname1, ...) into a dictionary, and passes that dictionary into another classmethod __fromdict__ which creates a named tuple instance from the dictionary contents. The problem I see with this is that having to say Point.__fromvalues__ (11, y=22) instead of Point (11, y=22) is a little verbose. Perhaps there could be an __fromsequence__ instead for the no-unpacking method of instance creation, as the most common use of direct-from-sequence creation I think is in a more general circumstance. 2. It would be nice to be able to have default values for named tuple fields. Using Signature it's easy to do this - I just specify a dictionary of defaults at named tuple class creation time. 3. In my opinion __replace__ should be able to replace multiple fields. My version takes either two parameters, same as collections.py, or a single dictionary containing replacements. 4. I put as much of the implementation as possible of the named tuple classes into a base class which I've called BaseNamedTuple. This defines the classmethods __fromvalues__ and __fromdict__, as well as the regular methods __repr__, __asdict__, and __replace__. 5. It didn't occur to me to use exec ... in so I just create the new type using the type() function. To me, exec is a last resort, but I'm a Python newbie so I'd be interested to hear what people have to say about this. 6. Not an improvement but a concern about my code: the generated classes and instances have all the crucial stuff like __fields__ and __signature__ fully read-write. It feels like those should be read-only properties. I think that would require namedtuple to be a metaclass instead of just a function (in order for the properties of the generated classes to be read-only). On the other hand, I'm a recovering Java programmer, so maybe it's un-Pythonic to want stuff to be read-only. Here I would especially appreciate any guidance more experienced hands can offer. And now, here is the code, together with a rudimentary example of how this could be used to improve the "addr" functions in email.utils: #!/usr/bin/env python from operator import itemgetter class BaseNamedTuple (tuple): @classmethod def __fromvalues__ (cls, *args, **keys): return cls.__fromdict__ (cls.__signature__.expand_args (*args, **keys)) @classmethod def __fromdict__ (cls, d): return cls ([d[name] for name in cls.__fields__]) def __repr__ (self): return self.__reprtemplate__ % self def __asdict__ (self): return dict (zip (self.__fields__, self)) def __replace__ (self, *args): slist = list (self) if len (args) == 1: sdict = args[0] elif len (args) == 2: sdict = {args[0]: args[1]} else: raise TypeError for key in sdict: slist[self.__indices__[key]] = sdict[key] return self.__class__ (slist) def namedtuple (name, fields, defaults=None): fields = tuple (fields) result = type (name, (BaseNamedTuple,), {}) for i in range (len (fields)): setattr (result, fields[i], property (itemgetter (i), None, result)) result.__fields__ = fields result.__signature__ = Signature (fields, defaults=defaults) result.__reprtemplate__ = "%s(%s)" % (name, ", ".join ("%s=%%r" % name for name in fields)) result.__indices__ = dict ((field, i) for i, field in enumerate (fields)) return result from email.utils import formataddr class test (namedtuple ("test", ("realname", "email"), {'realname': None})): @property def valid (self): return self.email.find ("@") >= 0 __str__ = formataddr if __name__ == "__main__": e1 = test (("Smith, John", "jsmith at example.com")) print "e1.realname =", e1.realname print "e1.email =", e1.email print "e1 =", repr (e1) print "str(e1) =", str (e1) e2 = test.__fromvalues__ (email="test at example.com") print "e2 =", repr (e2) print "str(e2) =", str (e2) Isaac Morland CSCF Web Guru DC 2554C, x36650 WWW Software Specialist From ijmorlan at cs.uwaterloo.ca Wed Nov 14 19:30:21 2007 From: ijmorlan at cs.uwaterloo.ca (Isaac Morland) Date: Wed, 14 Nov 2007 13:30:21 -0500 (EST) Subject: [Python-Dev] Python Library Addition: First-class Procedure Signatures Message-ID: For another project (see my previous email on named tuples), I needed to represent procedure signatures, and use them to expand arguments into the dictionary of values that exists when execution of a procedure starts. To my surprise, this capability didn't seem to be provided by the Python library, even though it clearly is present within the Python system somewhere. So I wrote a Signature class. Instances of the class represent all the information present between the parentheses of a procedure definition. Properties are provided to get the information out, and an expand_args method can be called to expand arguments into a dictionary. This expand_args method implements (if I've done it right) the argument conversion part of section 5.3.4 of the Python Reference Manual (http://docs.python.org/ref/calls.html). I've put the code below, but I wonder if the real solution is just to create an interface to already-existing capability? It occurs to me that the implementation is likely to be in the interpreter itself and not written in Python. One possible improvement (and I'm not sure it's better, so I'm just putting it out there): perhaps expand_args should be renamed to __call__. Then essentially a Signature object would be a procedure whose body is just "return locals ()". class Signature (object): def __init__ (self, argnames, excessargs=None, excesskeys=None, defaults=None): self.__argnames = tuple (argnames) self.__excessargs = excessargs self.__excesskeys = excesskeys if defaults is None: defaults = {} self.__defaults = dict (defaults) @property def argnames (self): return self.__argnames @property def excessargs (self): return self.__excessargs @property def excesskeys (self): return self.__excesskeys def defaults (self): return dict (self.__defaults) def expand_args (self, *args, **keys): # Start with defaults result = self.defaults () # Assign positional arguments for i in range (min (len (args), len (self.argnames))): result[self.argnames[i]] = args[i] # Assign keyword arguments for arg in self.argnames: if arg in keys: if arg in result: raise TypeError result[arg] = keys[arg] del keys[arg] # Check for missing arguments for i in range (len (args), len (self.argnames)): if not self.argnames[i] in result: raise TypeError # Excess positional arguments (*args parameter) if self.excessargs is None: if len (args) > len (self.argnames): raise TypeError else: result[self.excessargs] = args[len (self.argnames):] # Excess keyword arguments (**keys parameter) if self.excesskeys is None: if keys: raise TypeError else: result[self.excesskeys] = keys return result Isaac Morland CSCF Web Guru DC 2554C, x36650 WWW Software Specialist From jmstall at exchange.microsoft.com Wed Nov 14 20:16:09 2007 From: jmstall at exchange.microsoft.com (Mike Stall) Date: Wed, 14 Nov 2007 11:16:09 -0800 Subject: [Python-Dev] CPython crash with '%o' Message-ID: <5F42453283142A448EB8AD5B34FCFC6DF010236AE2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> This is my first post, so here's a quick intro: I've recently joined the IronPython team at Microsoft, after about 6 years as a developer on the the .NET runtime (CLR). I'm currently trying to make IronPython match CPython's behavior regarding some % format string to a level of detail not documented by the spec. (http://docs.python.org/lib/typesseq-strings.html) While exploring to determine what CPython's behavior is, I'm hitting a SystemError in CPython. Given the following snippet: class c(long): def __oct__(self): return '100' x=c(5) oct(x) # expected to print 100 '%o' % x # expected to use print '5' It looks like in CPython, '%o' uses __int__ and so it should ignore __oct__ and print 5. However, I'm hitting an SystemError in CPython with this snippet: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] onwin32 Type "help", "copyright", "credits" or "license" for more information. >>> class c(long): ... def __oct__(self): ... return '100' ... >>> x=c(5) >>> oct(x) # expected to print 100 '100' >>> '%o' % x # expected to use print '5' Traceback (most recent call last): File "", line 1, in SystemError: \loewis\25\python\Objects\stringobject.c:4236: bad argument to internal function Note that if c derives from 'int' instead of 'long', everything works as expected. 1. Can somebody confirm that '%o' should not use __oct__ and that is uses __int__ instead, and that the correct output from ('%o' % x) is indeed 5? 2. Should I file a bug for the SystemError exception? Thanks, Mike http://blogs.msdn.com/jmstall -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20071114/0c5f7eb6/attachment.htm From collinw at gmail.com Wed Nov 14 20:41:42 2007 From: collinw at gmail.com (Collin Winter) Date: Wed, 14 Nov 2007 11:41:42 -0800 Subject: [Python-Dev] Python Library Addition: First-class Procedure Signatures In-Reply-To: References: Message-ID: <43aa6ff70711141141y4e4428e6m6bfaa10df5e910d@mail.gmail.com> On Nov 14, 2007 10:30 AM, Isaac Morland wrote: > For another project (see my previous email on named tuples), I needed to > represent procedure signatures, and use them to expand arguments into the > dictionary of values that exists when execution of a procedure starts. To my > surprise, this capability didn't seem to be provided by the Python library, > even though it clearly is present within the Python system somewhere. > > So I wrote a Signature class. Instances of the class represent all the > information present between the parentheses of a procedure definition. > Properties are provided to get the information out, and an expand_args method > can be called to expand arguments into a dictionary. This expand_args method > implements (if I've done it right) the argument conversion part of section > 5.3.4 of the Python Reference Manual (http://docs.python.org/ref/calls.html). Have you seen http://www.python.org/dev/peps/pep-0362/? It sounds awfully similar to what you're proposing here. Collin Winter From lists at cheimes.de Wed Nov 14 20:47:42 2007 From: lists at cheimes.de (Christian Heimes) Date: Wed, 14 Nov 2007 20:47:42 +0100 Subject: [Python-Dev] CPython crash with '%o' In-Reply-To: <5F42453283142A448EB8AD5B34FCFC6DF010236AE2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <5F42453283142A448EB8AD5B34FCFC6DF010236AE2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: Mike Stall wrote: > Traceback (most recent call last): > File "", line 1, in > SystemError: \loewis\25\python\Objects\stringobject.c:4236: bad argument to internal function > Note that if c derives from 'int' instead of 'long', everything works as expected. I'm able to reproduce the error with Python 2.5.1 and 2.5 svn on Linux. It also happens when I overwrite __hex__ and do "%x" % c(5) for subclasses of long but not for subclasses from int. class c(long): def __hex__(self): return "100" def __oct__(self): return "100" >>> x = c(5) >>> hex(x) '100' >>> oct(x) '100' >>> "%o" % x Traceback (most recent call last): File "", line 1, in SystemError: Objects/stringobject.c:4269: bad argument to internal function >>> "%x" % x Traceback (most recent call last): File "", line 1, in SystemError: Objects/stringobject.c:4269: bad argument to internal function Objects/stringobject.c:_PyString_FormatLong(...) ... /* To modify the string in-place, there can only be one reference. */ if (result->ob_refcnt != 1) { PyErr_BadInternalCall(); return NULL; } ... Christian From guido at python.org Wed Nov 14 20:41:16 2007 From: guido at python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 11:41:16 -0800 Subject: [Python-Dev] CPython crash with '%o' In-Reply-To: <5F42453283142A448EB8AD5B34FCFC6DF010236AE2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <5F42453283142A448EB8AD5B34FCFC6DF010236AE2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: Yes, and yes. There may be time still to fix the SystemError in 2.5.2! On Nov 14, 2007 11:16 AM, Mike Stall wrote: > > > > > This is my first post, so here's a quick intro: I've recently joined the > IronPython team at Microsoft, after about 6 years as a developer on the the > .NET runtime (CLR). > > I'm currently trying to make IronPython match CPython's behavior regarding > some % format string to a level of detail not documented by the spec. > (http://docs.python.org/lib/typesseq-strings.html) > > While exploring to determine what CPython's behavior is, I'm hitting a > SystemError in CPython. > > Given the following snippet: > > class c(long): > def __oct__(self): > return '100' > > x=c(5) > oct(x) # expected to print 100 > '%o' % x # expected to use print '5' > > It looks like in CPython, '%o' uses __int__ and so it should ignore __oct__ > and print 5. > > However, I'm hitting an SystemError in CPython with this snippet: > > Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] > onwin32 > Type "help", "copyright", "credits" or "license" for more information. > >>> class c(long): > ... def __oct__(self): > ... return '100' > ... > >>> x=c(5) > >>> oct(x) # expected to print 100 > '100' > >>> '%o' % x # expected to use print '5' > Traceback (most recent call last): > File "", line 1, in > SystemError: \loewis\25\python\Objects\stringobject.c:4236: bad argument to > internal function > > Note that if c derives from 'int' instead of 'long', everything works as > expected. > > 1. Can somebody confirm that '%o' should not use __oct__ and that is uses > __int__ instead, and that the correct output from ('%o' % x) is indeed 5? > 2. Should I file a bug for the SystemError exception? > > Thanks, > Mike > http://blogs.msdn.com/jmstall > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Wed Nov 14 20:41:16 2007 From: guido at python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 11:41:16 -0800 Subject: [Python-Dev] CPython crash with '%o' In-Reply-To: <5F42453283142A448EB8AD5B34FCFC6DF010236AE2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <5F42453283142A448EB8AD5B34FCFC6DF010236AE2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: Yes, and yes. There may be time still to fix the SystemError in 2.5.2! On Nov 14, 2007 11:16 AM, Mike Stall wrote: > > > > > This is my first post, so here's a quick intro: I've recently joined the > IronPython team at Microsoft, after about 6 years as a developer on the the > .NET runtime (CLR). > > I'm currently trying to make IronPython match CPython's behavior regarding > some % format string to a level of detail not documented by the spec. > (http://docs.python.org/lib/typesseq-strings.html) > > While exploring to determine what CPython's behavior is, I'm hitting a > SystemError in CPython. > > Given the following snippet: > > class c(long): > def __oct__(self): > return '100' > > x=c(5) > oct(x) # expected to print 100 > '%o' % x # expected to use print '5' > > It looks like in CPython, '%o' uses __int__ and so it should ignore __oct__ > and print 5. > > However, I'm hitting an SystemError in CPython with this snippet: > > Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] > onwin32 > Type "help", "copyright", "credits" or "license" for more information. > >>> class c(long): > ... def __oct__(self): > ... return '100' > ... > >>> x=c(5) > >>> oct(x) # expected to print 100 > '100' > >>> '%o' % x # expected to use print '5' > Traceback (most recent call last): > File "", line 1, in > SystemError: \loewis\25\python\Objects\stringobject.c:4236: bad argument to > internal function > > Note that if c derives from 'int' instead of 'long', everything works as > expected. > > 1. Can somebody confirm that '%o' should not use __oct__ and that is uses > __int__ instead, and that the correct output from ('%o' % x) is indeed 5? > 2. Should I file a bug for the SystemError exception? > > Thanks, > Mike > http://blogs.msdn.com/jmstall > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Wed Nov 14 21:04:50 2007 From: guido at python.org (Guido van Rossum) Date: Wed, 14 Nov 2007 12:04:50 -0800 Subject: [Python-Dev] CPython crash with '%o' In-Reply-To: References: <5F42453283142A448EB8AD5B34FCFC6DF010236AE2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: I take back the first "Yes" answer. Alas, the % operator is a mess, especially for %d/%o/%x. For subclassed longs, it *is* attempting to call the overridden __oct__, and this is causing the SystemError. It looks like this code wasn't really revisited when subclassing int and long was introduced. :-( For subclassed ints, it never looks at the overridden __oct__. For objects that are neither, it attempts to convert them to ints using __int__ first. The trend in 3.0 is to completely kill __oct__ specialization and rely only on __int__ instead. So maybe I should retract my retraction and claim that '%o' % c(5) should indeed return '5'. The bug stands though. There's a relatively simple fix. --Guido On Nov 14, 2007 11:41 AM, Guido van Rossum wrote: > Yes, and yes. There may be time still to fix the SystemError in 2.5.2! > > > On Nov 14, 2007 11:16 AM, Mike Stall wrote: > > > > > > > > > > This is my first post, so here's a quick intro: I've recently joined the > > IronPython team at Microsoft, after about 6 years as a developer on the the > > .NET runtime (CLR). > > > > I'm currently trying to make IronPython match CPython's behavior regarding > > some % format string to a level of detail not documented by the spec. > > (http://docs.python.org/lib/typesseq-strings.html) > > > > While exploring to determine what CPython's behavior is, I'm hitting a > > SystemError in CPython. > > > > Given the following snippet: > > > > class c(long): > > def __oct__(self): > > return '100' > > > > x=c(5) > > oct(x) # expected to print 100 > > '%o' % x # expected to use print '5' > > > > It looks like in CPython, '%o' uses __int__ and so it should ignore __oct__ > > and print 5. > > > > However, I'm hitting an SystemError in CPython with this snippet: > > > > Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] > > onwin32 > > Type "help", "copyright", "credits" or "license" for more information. > > >>> class c(long): > > ... def __oct__(self): > > ... return '100' > > ... > > >>> x=c(5) > > >>> oct(x) # expected to print 100 > > '100' > > >>> '%o' % x # expected to use print '5' > > Traceback (most recent call last): > > File "", line 1, in > > SystemError: \loewis\25\python\Objects\stringobject.c:4236: bad argument to > > internal function > > > > Note that if c derives from 'int' instead of 'long', everything works as > > expected. > > > > 1. Can somebody confirm that '%o' should not use __oct__ and that is uses > > __int__ instead, and that the correct output from ('%o' % x) is indeed 5? > > 2. Should I file a bug for the SystemError exception? > > > > Thanks, > > Mike > > http://blogs.msdn.com/jmstall > > > > > > _______________________________________________ > > Python-Dev mailing list > > Python-Dev at python.org > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From brett at python.org Wed Nov 14 21:14:32 2007 From: brett at python.org (Brett Cannon) Date: Wed, 14 Nov 2007 12:14:32 -0800 Subject: [Python-Dev] Hello, I'm the other new guy In-Reply-To: <473A5A2F.6090203@cheimes.de> References: <473A5A2F.6090203@cheimes.de> Message-ID: On Nov 13, 2007 6:15 PM, Christian Heimes wrote: > Hello Pythonistas and fellow core developers! > > After Amaury introduced himself I've decided that I *have* to take some > time to introduce myself, too. Obviously welcome, but you have been in the thick of things already, so I think you already knew you were welcome here. =) -Brett From brett at python.org Wed Nov 14 21:18:56 2007 From: brett at python.org (Brett Cannon) Date: Wed, 14 Nov 2007 12:18:56 -0800 Subject: [Python-Dev] Python Library Addition: First-class Procedure Signatures In-Reply-To: References: Message-ID: On Nov 14, 2007 10:30 AM, Isaac Morland wrote: > For another project (see my previous email on named tuples), I needed to > represent procedure signatures, and use them to expand arguments into the > dictionary of values that exists when execution of a procedure starts. To my > surprise, this capability didn't seem to be provided by the Python library, > even though it clearly is present within the Python system somewhere. > > So I wrote a Signature class. Instances of the class represent all the > information present between the parentheses of a procedure definition. > Properties are provided to get the information out, and an expand_args method > can be called to expand arguments into a dictionary. This expand_args method > implements (if I've done it right) the argument conversion part of section > 5.3.4 of the Python Reference Manual (http://docs.python.org/ref/calls.html). > As Collin already pointed out, it sounds like you want PEP 362 to get into the stdlib. I have not made a big push to try to get my existing implementation into Python 2.6/3.0, but I plan to at some point. > I've put the code below, but I wonder if the real solution is just to create an > interface to already-existing capability? It occurs to me that the > implementation is likely to be in the interpreter itself and not written in > Python. > I don't see why a Python implementation is bad. If you make this information lazy then it is not such a big deal to have it take a little bit longer than if it was implemented in C. > One possible improvement (and I'm not sure it's better, so I'm just putting it > out there): perhaps expand_args should be renamed to __call__. Then essentially > a Signature object would be a procedure whose body is just "return locals ()". __call__ is already used a method name for objects that can be called. -Brett From mak at trisoft.com.pl Wed Nov 14 22:52:54 2007 From: mak at trisoft.com.pl (Grzegorz Makarewicz) Date: Wed, 14 Nov 2007 22:52:54 +0100 Subject: [Python-Dev] smlop - maintaned ? - what is the status of this module ? Message-ID: <473B6E36.6060702@trisoft.com.pl> Hi I have some scripts where this module is used - asyncore, xmlrpc, sgmlop. Some errors are arriving - memory errors reported by msvc2005 malloc/free. Where I should report bugs ? my env: py-2.5- partial cvs, sgmlop either from Frideric-s site or pyxml - same effect. tia, mak From python at rcn.com Wed Nov 14 23:39:09 2007 From: python at rcn.com (Raymond Hettinger) Date: Wed, 14 Nov 2007 17:39:09 -0500 (EST) Subject: [Python-Dev] Suggestions for Improvements to namedtuple Message-ID: <20071114173909.ABK23428@ms19.lnh.mail.rcn.net> > for efficiency I would prefer to avoid using * to break > up the sequences generated directly by the database interface. There are some use cases that would be better served by an alternate design and others that are better served by the current design. For example, it would really suck to have to type-out an an enclosing set of parenthesis to build a named tuple explicitly: opt = StockOption((daysleft/360., strike/100.0, bool(putcall))). The alternate signature was discussed and rejected previously. See some of the details on previous python-dev posting and in the ASPN recipe discussion: at some length in the ASPN recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/500261 FWIW, the current design does work efficiently with your use case if you use itertools to apply the named tuple cast to large record sets. See the example in the docs: http://docs.python.org/dev/library/collections.html#named-tuple-factory-function-for-tuples-with-named-fields Also, fwiw, I've had good success using this starmap() approach in some performance critcal applications. Almost every class in Python could be subjected to the same discussion. Why doesn't every class and function accept a tuple of args instead of separate, serial arguments. The * operator and starmap() function were provided specifically to address the inter-conversion between the two approaches. > It would be nice to be able to have default values This came-up before, but I'll take another look at it this weekend. If it significantly complicates the API or impacts performance, then it is a non-starter; otherwise, I'll put together an implementation and float it on ASPN for comments. > In my opinion __replace__ should be able to replace multiple fields. This may be do-able. Will take a look at it. The current design is easily extended for this without impacting performance. The question is whether is makes sense in normal applications to do multiple replacements at once. FWIW, the str.replace function only has one target/replacement pair. > To me, exec is a last resort It was a last resort here also. Earlier versions of the recipe used type() but they were less flexible, slower, had crummy error reporting, and were much less clear. The exec version has the advantage of being able to print-out the template so you can see *exactly* what it is doing. I ended-up putting in a lot f field validation to prevent injection attacks (they are also they to provide more actionable error messages). > crucial stuff like __fields__ and __signature__ fully > read-write. It feels like those should be read-only properties. > ... On the other hand, I'm a recovering Java programmer, Welcome to the Python world of consenting adults. These fields could be made read-only but that is just a matter of taste. Looking through the standard library, you'll see making attributes read-only is not the typical practice. If users demand it, I don't see a problem with it, but until then, I don't see a reason to unnecessarily complicate and slow-down the code. FWIW, you're welcome to email me directly. I've been getting tons of user feedback and have already incorporated the better suggestions. Also, the recipe itself is a combination of the best of prior attempts. Unfortunately, each of several commenters revisit everything from scratch and propose their own complete rewrites that ignore the requests and commments of all those who preceded them. Fortunately, we're homing in on a darned good tool. Raymond From python at rcn.com Wed Nov 14 23:58:21 2007 From: python at rcn.com (Raymond Hettinger) Date: Wed, 14 Nov 2007 17:58:21 -0500 (EST) Subject: [Python-Dev] Suggestions for Improvements to namedtuple Message-ID: <20071114175821.ABK26218@ms19.lnh.mail.rcn.net> > crucial stuff like __fields__ ... fully > read-write. On further thought, I think this is a good idea. Nothing good can come from writing to this class variable. Suggestion is checked-in in rev 58971. Curiously, it was already documented as read-only (I took the time machine out for a spin). Raymond From brett at python.org Thu Nov 15 00:01:58 2007 From: brett at python.org (Brett Cannon) Date: Wed, 14 Nov 2007 15:01:58 -0800 Subject: [Python-Dev] smlop - maintaned ? - what is the status of this module ? In-Reply-To: <473B6E36.6060702@trisoft.com.pl> References: <473B6E36.6060702@trisoft.com.pl> Message-ID: On Nov 14, 2007 1:52 PM, Grzegorz Makarewicz wrote: > Hi > > I have some scripts where this module is used - asyncore, xmlrpc, sgmlop. > Some errors are arriving - memory errors reported by msvc2005 malloc/free. > > Where I should report bugs ? http://bugs.python.org/ -Brett From martin at v.loewis.de Thu Nov 15 00:22:50 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Thu, 15 Nov 2007 00:22:50 +0100 Subject: [Python-Dev] smlop - maintaned ? - what is the status of this module ? In-Reply-To: <473B6E36.6060702@trisoft.com.pl> References: <473B6E36.6060702@trisoft.com.pl> Message-ID: <473B834A.6050403@v.loewis.de> > I have some scripts where this module is used - asyncore, xmlrpc, sgmlop. > Some errors are arriving - memory errors reported by msvc2005 malloc/free. > > Where I should report bugs ? > > my env: py-2.5- partial cvs, sgmlop either from Frideric-s site or pyxml > - same effect. sgmlop is not part of the Python distribution, so you should report errors directly to Fredrik Lundh (sp!). Notice, however, that you should use msvc2003, not 2005, to compile it. Regards, Martin From python at rcn.com Thu Nov 15 03:48:16 2007 From: python at rcn.com (Raymond Hettinger) Date: Wed, 14 Nov 2007 21:48:16 -0500 (EST) Subject: [Python-Dev] Suggestions for Improvements to namedtuple Message-ID: <20071114214816.ABK52614@ms19.lnh.mail.rcn.net> > In my opinion __replace__ should be able to replace multiple fields. This suggestion is accepted and checked-in. See revision 58975. Surprisingly, the required signature change results in improved clarity. This was an all around win. Raymond From daniel at stutzbachenterprises.com Thu Nov 15 04:39:47 2007 From: daniel at stutzbachenterprises.com (Daniel Stutzbach) Date: Wed, 14 Nov 2007 21:39:47 -0600 Subject: [Python-Dev] Alternative C implementation idea for collections.deque Message-ID: Many years ago I implemented a deque type in C (for use in C programs) using a single dynamically sized array as the underling type, along with an extra integer to designate where the "start" of the list is. Somehow, I had always imagined that Python's implementation worked the same way, but was just looking at the code and found that it uses doubly-linked lists of 62-item blocks. I just wanted to toss my approach out there to see if it might offer better performance and/or simpler code (my pure-C implementation is only 80 lines of code). If there's interest, I'd be happy to work it up into a patch. I could also do some performance tests if others have specific use cases they'd like to see tested. I see the advantages as follows: - __getitem__ would take O(1) time instead of O(n) - Dirt simple implementation Compared to the existing code, memory allocation/deallocation is less frequent but more expensive when necessary, working out to O(1) amortized time (same as the current implementation). The basic idea is to use a single dynamically sized array (much like Python's list type). An extra integer points to the start of the deque within the array, and the data implicitly wraps around the end of the list back to the beginning. Here's the basic data structure: struct deque { PyObject **obs; int max_len; /* Number of objects we can store in the deque before having to reallocate */ int len; /* Number of objects currently in the deque */ int start; /* Where in obs the objects starts */ } When len == max_len and the user adds an element, we reallocate obs. Much like Python's list type, this can be done in such a way that memory allocation takes O(1) amortized time (e.g., by doubling max_len).. The start of the list is always obs[start] and the last element of the list is at obs[(start + len - 1) % max_len]. The nth element of the list is obs[(start + n) % max_len]. I think an example would be helpful. For illustrative purposes, suppose we start with max_len=4. Each line is followed by a picture of the data structure's contents: >>> x = deque() {obs = {NULL, NULL, NULL, NULL}, max_len = 4, len = 0, start = 0} >>> x.extend((1,2,3,4)) {obs = {1, 2, 3, 4}, max_len = 4, len = 4, start = 0} >>> x.popleft() {obs = {NULL, 2, 3, 4}, max_len = 4, len = 3, start = 1} >>> x.append(5) {obs = {5, 2, 3, 4}, max_len = 4, len = 4, start = 1} >>> x.popleft() {obs = {5, NULL, 3, 4}, max_len = 4, len = 3, start = 2} >>> x.pop() {obs = {NULL, NULL, 3, 4}, max_len = 4, len = 2, start = 2} Comments? Thoughts? Would a patch be welcome? -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC From daniel at stutzbachenterprises.com Thu Nov 15 08:01:14 2007 From: daniel at stutzbachenterprises.com (Daniel Stutzbach) Date: Thu, 15 Nov 2007 01:01:14 -0600 Subject: [Python-Dev] Alternative C implementation idea for collections.deque In-Reply-To: <003d01c82754$c21150f0$7700a8c0@RaymondLaptop1> References: <003d01c82754$c21150f0$7700a8c0@RaymondLaptop1> Message-ID: On Nov 15, 2007 12:57 AM, Raymond Hettinger wrote: > FWIW, my development time is now somewhat limited > and I prefer to spend it on a todo list that has been around > for some time. I dread throwing that time away and > spending it on reviewing your patch, timing tons of test > cases, arguing the merits of alternate approaches, and ending-up > with substantially the same functionality that we already have. I respect that. I won't waste either of our time, then. Cheers, -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC From python at rcn.com Thu Nov 15 07:57:14 2007 From: python at rcn.com (Raymond Hettinger) Date: Wed, 14 Nov 2007 22:57:14 -0800 Subject: [Python-Dev] Alternative C implementation idea for collections.deque References: Message-ID: <003d01c82754$c21150f0$7700a8c0@RaymondLaptop1> From: "Daniel Stutzbach" > Many years ago I implemented a deque type in C (for use in C programs) > using a single dynamically sized array as the underling type, The approach was not used so we could avoid data movement associated with re-sizing. > I see the > advantages as follows: > > - __getitem__ would take O(1) time instead of O(n) While nice, that is somewhat at odds with how deques are used. The current implementation has O(1) access time with a tiny constant for access near the end-points. The only reason that __getitem__ was put in was to support fast access to the head and tail without actually popping the value. That it can access the middle was incidental and imho optimizing in the middle access would only encourage mis-use of the data structure. > Compared to the existing code, memory allocation/deallocation is less > frequent but more expensive when necessary, For most use cases, the current version rolls around with no memory allocations (reusable blocks are kept on a free list). > Comments? Thoughts? Would a patch be welcome? Might as well put it in the tracker for history/research purposes, but I think you're barking up the wrong tree. Deques are not about accessing the nth item in the middle. For their purpose, the current design works really well (the blocks are sized to fit in cache lines and no mass movements are necessary when the size changes -- the data never moves). If you're going to spend time, why not put it into developing a data structure we don't already have (red-black trees or some such). FWIW, my development time is now somewhat limited and I prefer to spend it on a todo list that has been around for some time. I dread throwing that time away and spending it on reviewing your patch, timing tons of test cases, arguing the merits of alternate approaches, and ending-up with substantially the same functionality that we already have. The big win for deques was getting the O(1) append/pop on each end. That gave a huge algorithmic speed boost to the Queue module and a number of other tools that were using lists for deque-style operations. Raymond From ijmorlan at cs.uwaterloo.ca Thu Nov 15 17:42:46 2007 From: ijmorlan at cs.uwaterloo.ca (Isaac Morland) Date: Thu, 15 Nov 2007 11:42:46 -0500 (EST) Subject: [Python-Dev] Python Library Addition: First-class Procedure Signatures In-Reply-To: References: Message-ID: On Wed, 14 Nov 2007, Brett Cannon wrote: > As Collin already pointed out, it sounds like you want PEP 362 to get > into the stdlib. I have not made a big push to try to get my existing > implementation into Python 2.6/3.0, but I plan to at some point. Yes, it had not occurred to me to check the existing PEPs for my PEP before proposing it. Now that I've read it I have a couple of comments, but it is close to what I'm looking for. >> I've put the code below, but I wonder if the real solution is just to create an >> interface to already-existing capability? It occurs to me that the >> implementation is likely to be in the interpreter itself and not written in >> Python. > > I don't see why a Python implementation is bad. If you make this > information lazy then it is not such a big deal to have it take a > little bit longer than if it was implemented in C. I don't have any problem with a Python implementation. In particular, I'm not concerned in this case about the performance. Rather what I actually wanted was a way to just bind arguments and then get the resulting dictionary (what would usually become locals()). I realized that I could create a Signature object with a binding method, but that I would just be duplicating part of the Python interpreter. I haven't studied the Python interpreter so I don't know if it is feasible to re-use that (presumably highly optimized for actually calling procedures, not just binding arguments) code or if it makes more sense to simply re-implement it. >> One possible improvement (and I'm not sure it's better, so I'm just putting it >> out there): perhaps expand_args should be renamed to __call__. Then essentially >> a Signature object would be a procedure whose body is just "return locals ()". > > __call__ is already used a method name for objects that can be called. Yes, that is why I used that name. The idea is that a Signature object be callable, have itself as signature, and return the dictionary of locals resulting from the procedure call argument binding process. You can also think of (my idea of) Signature objects as providing a simple way to create lots of special-case dictionary constructors. More (semi-)formally, if the body of a procedure p is "return locals ()", then p(...) is the same as p.__signature__(...). A couple of comments about PEP-362: 1. For the "name" attribute of the Parameter object, I think it needs to be str | tuple(str) | tuple(tuple(str)) | ....: >>> def a ((b,c),(d,(e,f))): ... print b,c,d,e,f ... >>> a >>> a((1,2),(3,(4,5))) 1 2 3 4 5 >>> 2. For "position" of keyword-only parameters, are they allowed to conflict with each other, or does each parameter get a unique value? +1 on not using -1 as a special value. Python is not COBOL. 3. (My apologies if any of these have already been discussed) Under "Implementation", could __signature__ just be a property of callable objects? Not saying anything about implementation, but just being able to say "formataddr.__signature__" feels nicely minimal (to me). 4. Signature.bind - for what I'm doing, I definitely want what would become locals() in a procedure call, i.e. keys in the resulting dictionary are strings. But I can see the other behaviour being useful in other circumstances so maybe there should be bind and bindp, or (see above) __call__ and bind, or something else. 5. var_args... default to None. +10 from me on this one - this is *exactly* what None is, as far as I can tell. I'm new enough that this should probably count for at most +0.1 though. 6. The PEP doesn't say anything about building Signature objects from scratch, and the code does not reassure me. I would like to be able to build a Signature from a sequence of strings for positional parameter names, for example, and provide default values for some parameters. My solution started off: class Signature (object): def __init__ (self, argnames, excessargs=None, excesskeys=None, defaults=None): self.__argnames = tuple (argnames) self.__excessargs = excessargs self.__excesskeys = excesskeys if defaults is None: defaults = {} self.__defaults = dict (defaults) [....] Thanks for the responses. I hope the above is at least in part not a re-hash of old discussions. Isaac Morland CSCF Web Guru DC 2554C, x36650 WWW Software Specialist From ijmorlan at cs.uwaterloo.ca Thu Nov 15 18:06:43 2007 From: ijmorlan at cs.uwaterloo.ca (Isaac Morland) Date: Thu, 15 Nov 2007 12:06:43 -0500 (EST) Subject: [Python-Dev] Python Library Addition: First-class Procedure Signatures In-Reply-To: References: Message-ID: On Thu, 15 Nov 2007, Isaac Morland wrote: > 1. For the "name" attribute of the Parameter object, I think it needs to > be str | tuple(str) | tuple(tuple(str)) | ....: No, that's still wrong. I think it needs to be T, where T == str | tuple(T). Isaac Morland CSCF Web Guru DC 2554C, x36650 WWW Software Specialist From status at bugs.python.org Thu Nov 15 19:06:06 2007 From: status at bugs.python.org (Tracker) Date: Thu, 15 Nov 2007 18:06:06 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071115180606.65E4C78329@psf.upfronthosting.co.za> ACTIVITY SUMMARY (11/08/07 - 11/15/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1330 open (+19) / 11604 closed (+26) / 12934 total (+45) Open issues with patches: 425 Average duration of open issues: 687 days. Median duration of open issues: 798 days. Open Issues Breakdown open 1325 (+19) pending 5 ( +0) Issues Created Or Reopened (47) _______________________________ test_import breaks on Linux 11/09/07 http://bugs.python.org/issue1377 reopened gvanrossum py3k Garbage collection not working correctly in Python 2.3 11/09/07 CLOSED http://bugs.python.org/issue1405 reopened tiran [performance] Too many closed() checkings 11/08/07 http://bugs.python.org/issue1407 created wojtekwalczak py3k Inconsistence in multiply list 11/08/07 CLOSED http://bugs.python.org/issue1408 created beco new keyword-only function parameters interact badly with nested 11/08/07 http://bugs.python.org/issue1409 created _doublep py3k BaseHTTPServer cannot accept Unicode data 11/08/07 CLOSED http://bugs.python.org/issue1410 created isonno A typo in tutorial 11/09/07 CLOSED http://bugs.python.org/issue1411 created falsetru test_subprocess fails on SuSE 10 11/09/07 http://bugs.python.org/issue1412 created dvadasz int literal methods inaccessible 11/09/07 CLOSED http://bugs.python.org/issue1413 created mykhal Fix for refleak tests 11/09/07 http://bugs.python.org/issue1414 created tiran py3k, patch py3k: pythonw.exe fails because std streams a missing 11/10/07 CLOSED http://bugs.python.org/issue1415 created tiran py3k @prop.setter decorators 11/10/07 CLOSED http://bugs.python.org/issue1416 created gvanrossum patch Weakref not working properly 11/10/07 CLOSED http://bugs.python.org/issue1417 created MHOOO Python/hypot.c is never used 11/10/07 CLOSED http://bugs.python.org/issue1418 created marketdickinson ssl module version 1.10 causes TypeError when accepting connecti 11/11/07 CLOSED http://bugs.python.org/issue1419 created complex Unicode literals in tokenize.py and tests. 11/11/07 CLOSED http://bugs.python.org/issue1420 created ron_adam py3k, patch python.org: outdated and false information 11/11/07 CLOSED http://bugs.python.org/issue1421 created tiran Writing to an invalid fd doesn't raise an exception 11/11/07 CLOSED http://bugs.python.org/issue1422 created tiran py3k wave sunau aifc 16bit errors 11/11/07 http://bugs.python.org/issue1423 created jeroen py3k: readline and rlcompleter doesn't list choices 11/11/07 CLOSED http://bugs.python.org/issue1424 created tiran py3k readline: no display matches hook set 11/11/07 CLOSED http://bugs.python.org/issue1425 created tiran py3k readline module needs a review 11/11/07 CLOSED http://bugs.python.org/issue1426 created tiran py3k Error in standard module calendar 11/11/07 CLOSED http://bugs.python.org/issue1427 created gdamjan patch Update to property.__doc__ 11/11/07 CLOSED http://bugs.python.org/issue1428 created tiran patch FD leak in SocketServer 11/12/07 http://bugs.python.org/issue1429 created luke-jr Installing on Vista asks to close Explorer (and Nokia PC Suite) 11/12/07 CLOSED http://bugs.python.org/issue1430 created dabarlow pth files not loaded at startup 11/12/07 http://bugs.python.org/issue1431 created gbloisi patch Strange behavior of urlparse.urljoin 11/13/07 http://bugs.python.org/issue1432 created yan marshal roundtripping for unicode 11/13/07 CLOSED http://bugs.python.org/issue1433 created cfbolz SocketServer creates non-blocking files 11/13/07 http://bugs.python.org/issue1434 created luke-jr Support for multiple handlers for the "with" statement 11/13/07 CLOSED http://bugs.python.org/issue1435 created Stavros logging.config.fileConfig, NameError: name 'RotatingFileHandler' 11/13/07 CLOSED http://bugs.python.org/issue1436 created sebastian List member inside a class is shared by all instances of the cla 11/13/07 CLOSED http://bugs.python.org/issue1437 created glubglub Calling base class methods is slow due to __instancecheck__ over 11/13/07 http://bugs.python.org/issue1438 created gvanrossum proposed 3000 patch for socket.py - "socket GC worries" 11/13/07 CLOSED http://bugs.python.org/issue1439 created janssen py3k, patch Checks for PySys_GetObject("std???") == Py_None 11/14/07 CLOSED http://bugs.python.org/issue1440 created tiran py3k, patch Cycles through ob_type aren't freed 11/14/07 http://bugs.python.org/issue1441 created rhamphoryncus pythonstartup addition of minor error checking 11/14/07 http://bugs.python.org/issue1442 created JosephArmbruster patch Magic class member variable initialization with lists 11/14/07 CLOSED http://bugs.python.org/issue1443 created neoone utf_8_sig streamreader bug, patch, and test 11/15/07 http://bugs.python.org/issue1444 created jgsack patch SystemError accessing uninitialised cell contents 11/15/07 http://bugs.python.org/issue1445 created duncanb Link to call me for free 11/15/07 CLOSED http://bugs.python.org/issue1446 created gopiyadav26 patch to make msvccompiler.py work with vs 2005(MSVC8) 11/15/07 http://bugs.python.org/issue1447 created weck patch Build Python with VS 2005(MSVC8) 11/15/07 http://bugs.python.org/issue1448 created weck patch make msi work the vs 2005(MSVC8) 11/15/07 http://bugs.python.org/issue1449 created weck patch make modulator more general 11/15/07 http://bugs.python.org/issue1450 created weck patch SSL patch for Python 3000 11/15/07 http://bugs.python.org/issue1451 created janssen py3k, patch Issues Now Closed (37) ______________________ py3k: corrections for test_subprocess on windows 72 days http://bugs.python.org/issue1047 tiran patch test_urllib2net fails on test_ftp 57 days http://bugs.python.org/issue1157 tiran py3k pdb fails to launch some script. 33 days http://bugs.python.org/issue1254 tiran pdb bug with "with" statement 33 days http://bugs.python.org/issue1265 amaury.forgeotdarc py3k Add getsize() to io instances 13 days http://bugs.python.org/issue1351 loewis py3k, patch Garbage collection not working correctly in Python 2.3 1 days http://bugs.python.org/issue1405 gvanrossum Use widechar api for os.environ 0 days http://bugs.python.org/issue1406 theller py3k, patch Inconsistence in multiply list 1 days http://bugs.python.org/issue1408 georg.brandl BaseHTTPServer cannot accept Unicode data 1 days http://bugs.python.org/issue1410 tiran A typo in tutorial 0 days http://bugs.python.org/issue1411 georg.brandl int literal methods inaccessible 0 days http://bugs.python.org/issue1413 loewis py3k: pythonw.exe fails because std streams a missing 4 days http://bugs.python.org/issue1415 amaury.forgeotdarc py3k @prop.setter decorators 1 days http://bugs.python.org/issue1416 gvanrossum patch Weakref not working properly 4 days http://bugs.python.org/issue1417 gagenellina Python/hypot.c is never used 2 days http://bugs.python.org/issue1418 loewis ssl module version 1.10 causes TypeError when accepting connecti 3 days http://bugs.python.org/issue1419 janssen Unicode literals in tokenize.py and tests. 1 days http://bugs.python.org/issue1420 gvanrossum py3k, patch python.org: outdated and false information 1 days http://bugs.python.org/issue1421 georg.brandl Writing to an invalid fd doesn't raise an exception 1 days http://bugs.python.org/issue1422 gvanrossum py3k py3k: readline and rlcompleter doesn't list choices 1 days http://bugs.python.org/issue1424 tiran py3k readline: no display matches hook set 0 days http://bugs.python.org/issue1425 loewis py3k readline module needs a review 1 days http://bugs.python.org/issue1426 tiran py3k Error in standard module calendar 0 days http://bugs.python.org/issue1427 doerwalter patch Update to property.__doc__ 0 days http://bugs.python.org/issue1428 tiran patch Installing on Vista asks to close Explorer (and Nokia PC Suite) 0 days http://bugs.python.org/issue1430 loewis marshal roundtripping for unicode 0 days http://bugs.python.org/issue1433 loewis Support for multiple handlers for the "with" statement 0 days http://bugs.python.org/issue1435 gvanrossum logging.config.fileConfig, NameError: name 'RotatingFileHandler' 0 days http://bugs.python.org/issue1436 vsajip List member inside a class is shared by all instances of the cla 0 days http://bugs.python.org/issue1437 tiran proposed 3000 patch for socket.py - "socket GC worries" 1 days http://bugs.python.org/issue1439 janssen py3k, patch Checks for PySys_GetObject("std???") == Py_None 1 days http://bugs.python.org/issue1440 tiran py3k, patch Magic class member variable initialization with lists 0 days http://bugs.python.org/issue1443 gvanrossum Link to call me for free 0 days http://bugs.python.org/issue1446 tiran C3 MRO algorithm implementation 1865 days http://bugs.python.org/issue619475 gvanrossum patch Use correct encoding for printing SyntaxErrors 1151 days http://bugs.python.org/issue1031213 ishimoto patch Intel icc build fails with optimizations -O2 227 days http://bugs.python.org/issue1689617 loewis interpreter crash when multiplying large lists 206 days http://bugs.python.org/issue1704621 gvanrossum patch Top Issues Most Discussed (10) ______________________________ 25 py3k: pythonw.exe fails because std streams a missing 4 days closed http://bugs.python.org/issue1415 14 fromfd() and dup() for _socket on WIndows 12 days open http://bugs.python.org/issue1378 11 int literal methods inaccessible 0 days closed http://bugs.python.org/issue1413 8 Parsing a simple script eats all of your memory 68 days open http://bugs.python.org/issue1134 7 Unicode literals in tokenize.py and tests. 1 days closed http://bugs.python.org/issue1420 7 Fix for refleak tests 6 days open http://bugs.python.org/issue1414 7 pdb bug with "with" statement 33 days closed http://bugs.python.org/issue1265 6 BaseHTTPServer cannot accept Unicode data 1 days closed http://bugs.python.org/issue1410 6 new keyword-only function parameters interact badly with nested 7 days open http://bugs.python.org/issue1409 6 py3k: duplicated line endings when using read(1) 10 days open http://bugs.python.org/issue1395 From brett at python.org Thu Nov 15 21:18:41 2007 From: brett at python.org (Brett Cannon) Date: Thu, 15 Nov 2007 12:18:41 -0800 Subject: [Python-Dev] Python Library Addition: First-class Procedure Signatures In-Reply-To: References: Message-ID: On Nov 15, 2007 8:42 AM, Isaac Morland wrote: > On Wed, 14 Nov 2007, Brett Cannon wrote: > > > As Collin already pointed out, it sounds like you want PEP 362 to get > > into the stdlib. I have not made a big push to try to get my existing > > implementation into Python 2.6/3.0, but I plan to at some point. > > Yes, it had not occurred to me to check the existing PEPs for my PEP > before proposing it. Now that I've read it I have a couple of comments, > but it is close to what I'm looking for. > > >> I've put the code below, but I wonder if the real solution is just to create an > >> interface to already-existing capability? It occurs to me that the > >> implementation is likely to be in the interpreter itself and not written in > >> Python. > > > > I don't see why a Python implementation is bad. If you make this > > information lazy then it is not such a big deal to have it take a > > little bit longer than if it was implemented in C. > > I don't have any problem with a Python implementation. In particular, I'm > not concerned in this case about the performance. Rather what I actually > wanted was a way to just bind arguments and then get the resulting > dictionary (what would usually become locals()). I realized that I could > create a Signature object with a binding method, but that I would just be > duplicating part of the Python interpreter. > > I haven't studied the Python interpreter so I don't know if it is feasible > to re-use that (presumably highly optimized for actually calling > procedures, not just binding arguments) code or if it makes more sense to > simply re-implement it. > > >> One possible improvement (and I'm not sure it's better, so I'm just putting it > >> out there): perhaps expand_args should be renamed to __call__. Then essentially > >> a Signature object would be a procedure whose body is just "return locals ()". > > > > __call__ is already used a method name for objects that can be called. > > Yes, that is why I used that name. The idea is that a Signature object be > callable, have itself as signature, and return the dictionary of locals > resulting from the procedure call argument binding process. > > You can also think of (my idea of) Signature objects as providing a simple > way to create lots of special-case dictionary constructors. > > More (semi-)formally, if the body of a procedure p is "return locals ()", > then p(...) is the same as p.__signature__(...). > Fair enough, but I prefer having a method for it. > A couple of comments about PEP-362: > > 1. For the "name" attribute of the Parameter object, I think it needs to > be str | tuple(str) | tuple(tuple(str)) | ....: > > >>> def a ((b,c),(d,(e,f))): > ... print b,c,d,e,f > ... > >>> a > > >>> a((1,2),(3,(4,5))) > 1 2 3 4 5 > >>> You are taking annotations a little too far in terms of typing. =) There are no type checks for the annotations; they are for documentation purposes only. Plus tuple parameters are gone as of Py3K thanks to my prodding to ditch them so I am really not going to worry about them now. =) > > 2. For "position" of keyword-only parameters, are they allowed to conflict > with each other, or does each parameter get a unique value? +1 on not > using -1 as a special value. Python is not COBOL. > It is just he numeric order that the arguments are found, period. Keyword-only arguments are given a index position, it just doesn't really mean much other than giving it a numeric position. > 3. (My apologies if any of these have already been discussed) Under > "Implementation", could __signature__ just be a property of callable > objects? Not saying anything about implementation, but just being able to > say "formataddr.__signature__" feels nicely minimal (to me). The idea has been to add the code to the stdlib and let people try them out first. If they ended up being used often enough then discussion of putting a signature object on every callable could be discussed. > > 4. Signature.bind - for what I'm doing, I definitely want what would > become locals() in a procedure call, i.e. keys in the resulting dictionary > are strings. But I can see the other behaviour being useful in other > circumstances so maybe there should be bind and bindp, or (see above) > __call__ and bind, or something else. > I only want to bother supporting one or the other. Doing the reverse is one or two lines of code. > 5. var_args... default to None. +10 from me on this one - this is > *exactly* what None is, as far as I can tell. I'm new enough that this > should probably count for at most +0.1 though. > > 6. The PEP doesn't say anything about building Signature objects from > scratch, and the code does not reassure me. That's because there is no way. =) > I would like to be able to > build a Signature from a sequence of strings for positional parameter > names, for example, and provide default values for some parameters. My > solution started off: > > class Signature (object): > def __init__ (self, argnames, > excessargs=None, excesskeys=None, defaults=None): > self.__argnames = tuple (argnames) > self.__excessargs = excessargs > self.__excesskeys = excesskeys > if defaults is None: > defaults = {} > self.__defaults = dict (defaults) > [....] I really don't see this being used often enough to warrant the need to support building a Signature object from scratch instead of an actual callable. It's easy enough to create a string for a function that has what you want, compile it, and get the Signature object from that. -Brett From steven.bethard at gmail.com Thu Nov 15 21:48:44 2007 From: steven.bethard at gmail.com (Steven Bethard) Date: Thu, 15 Nov 2007 13:48:44 -0700 Subject: [Python-Dev] Python Library Addition: First-class Procedure Signatures In-Reply-To: References: Message-ID: On Nov 14, 2007 1:18 PM, Brett Cannon wrote: > On Nov 14, 2007 10:30 AM, Isaac Morland wrote: > > So I wrote a Signature class. Instances of the class represent all the > > information present between the parentheses of a procedure definition. > > Properties are provided to get the information out, and an expand_args method > > can be called to expand arguments into a dictionary. This expand_args method > > implements (if I've done it right) the argument conversion part of section > > 5.3.4 of the Python Reference Manual (http://docs.python.org/ref/calls.html). > > As Collin already pointed out, it sounds like you want PEP 362 to get > into the stdlib. I have not made a big push to try to get my existing > implementation into Python 2.6/3.0, but I plan to at some point. Every time I read PEP 362, I get lost in the details. When you get around to working on it again, could you add a bunch of examples? That would make it much easier to tell why we want all those objects and attributes. FWIW, Isaac's version of bind() that returns a regular str->object dict is all I've ever needed in my own code. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy From theller at ctypes.org Thu Nov 15 22:17:29 2007 From: theller at ctypes.org (Thomas Heller) Date: Thu, 15 Nov 2007 22:17:29 +0100 Subject: [Python-Dev] Hello, I'm the other new guy In-Reply-To: References: <473A5A2F.6090203@cheimes.de> Message-ID: Facundo Batista schrieb: > 2007/11/14, Christian Heimes : > >> After Amaury introduced himself I've decided that I *have* to take some >> time to introduce myself, too. It's probably too late to say welcome to both Christian and Amaury, also we have already met in the bug tracker. I'm especially pleased that both of you also care about and work on Windows stuff - much appreciated. Thomas PS: I smiled when I saw your introductions. Amaury: I also have 5 children, and Christian: I'm also a 'strange' guy (but not metal and gothic). From guido at python.org Thu Nov 15 22:27:55 2007 From: guido at python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 13:27:55 -0800 Subject: [Python-Dev] Hello, I'm the other new guy In-Reply-To: References: <473A5A2F.6090203@cheimes.de> Message-ID: On Nov 15, 2007 1:17 PM, Thomas Heller wrote: > PS: I smiled when I saw your introductions. Amaury: I also have > 5 children, and Christian: I'm also a 'strange' guy (but not > metal and gothic). I feel left out. I have only one child and I don't qualify as 'strange' by any stretch of the imagination... Sometimes I think I'm the only regular guy working on Python. ;-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) From terry at jon.es Thu Nov 15 22:33:20 2007 From: terry at jon.es (Terry Jones) Date: Thu, 15 Nov 2007 22:33:20 +0100 Subject: [Python-Dev] Hello, I'm the other new guy In-Reply-To: Your message at 13:27:55 on Thursday, 15 November 2007 References: <473A5A2F.6090203@cheimes.de> Message-ID: <18236.47904.724291.170966@terry.local> >>>>> "Guido" == Guido van Rossum writes: Guido> I feel left out. I have only one child and I don't qualify as Guido> 'strange' by any stretch of the imagination... Sometimes I think I'm Guido> the only regular guy working on Python. ;-) Ah well, that explains a lot! :-) Anyone else here think they're normal? 1. You're a programmer 2. You work on Python 3. You're on the dev mailing list (and you read it) Each one of those must be worth at least one unit of standard deviation. Terry From lists at cheimes.de Thu Nov 15 22:43:17 2007 From: lists at cheimes.de (Christian Heimes) Date: Thu, 15 Nov 2007 22:43:17 +0100 Subject: [Python-Dev] Hello, I'm the other new guy In-Reply-To: References: <473A5A2F.6090203@cheimes.de> Message-ID: Guido van Rossum wrote: > I feel left out. I have only one child and I don't qualify as > 'strange' by any stretch of the imagination... Sometimes I think I'm > the only regular guy working on Python. ;-) Gosh! Your new beard definitely puts you in the strange guys category. I'm astonished that your son isn't afraid of you with all those hairs in your face. ;) Christian From guido at python.org Thu Nov 15 22:53:26 2007 From: guido at python.org (Guido van Rossum) Date: Thu, 15 Nov 2007 13:53:26 -0800 Subject: [Python-Dev] Hello, I'm the other new guy In-Reply-To: References: <473A5A2F.6090203@cheimes.de> Message-ID: On Nov 15, 2007 1:43 PM, Christian Heimes wrote: > Guido van Rossum wrote: > > I feel left out. I have only one child and I don't qualify as > > 'strange' by any stretch of the imagination... Sometimes I think I'm > > the only regular guy working on Python. ;-) > > Gosh! Your new beard definitely puts you in the strange guys category. > I'm astonished that your son isn't afraid of you with all those hairs in > your face. ;) It's a matter of starting them to get used to it when they're young. :-) At least I don't rattle when I walk... -- --Guido van Rossum (home page: http://www.python.org/~guido/) From goodger at python.org Fri Nov 16 06:55:14 2007 From: goodger at python.org (David Goodger) Date: Fri, 16 Nov 2007 00:55:14 -0500 Subject: [Python-Dev] Last chance for PyCon talk & tutorial proposals! Message-ID: <473D30C2.2010107@python.org> Thanks to all the proposal authors so far, we have received lots of proposals for PyCon talks & tutorials. But we'd like to have even more. Alas, the proposal submission deadline should have been set after a weekend, not before. So we have decided to extend the proposal submission deadline to Monday, November 19 at midnight (Chicago time). This gives you a *whole extra weekend* to write up your talk and tutorial ideas! If you've been procrastinating, stop! Get started on a proposal instead! See the call for conference talk proposals: http://us.pycon.org/2008/conference/proposals/ Topic ideas: http://wiki.python.org/moin/Talk_Subjects http://wiki.python.org/moin/PyCon2007/Feedback#head-e2dca74d1492e49fae11550e6cbc40fa18a17f40 See the call for tutorial proposals http://us.pycon.org/2008/tutorials/proposals/ Topic ideas from the PyCon 2007 feedback: http://wiki.python.org/moin/PyCon2007/Feedback/TutorialIdeas I hope to see (and hear) you at PyCon 2008! http://us.pycon.org -- David Goodger, PyCon 2008 Chair -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://mail.python.org/pipermail/python-dev/attachments/20071116/9695a651/attachment.pgp From nnorwitz at gmail.com Fri Nov 16 07:15:13 2007 From: nnorwitz at gmail.com (Neal Norwitz) Date: Thu, 15 Nov 2007 22:15:13 -0800 Subject: [Python-Dev] New python developer In-Reply-To: References: Message-ID: On Nov 13, 2007 1:05 PM, Amaury Forgeot d'Arc wrote: > > I can also help on win32 specific development. As an example, I find > that the distutils module don't work very well with the new compilers. > I won't be of much help on Unix, though. We need more help on Windows! Most of us are Unix only, so it will be great to have some help here. There are many windows bugs in the bug tracker if you'd like to take a look there. Welcome and good work so far! It's great seeing some of the memory issues in py3k get addressed. n From gjcarneiro at gmail.com Fri Nov 16 15:17:31 2007 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Fri, 16 Nov 2007 14:17:31 +0000 Subject: [Python-Dev] for loop with if filter Message-ID: I am finding myself often doing for loops over a subset of a list, like: for r in results: if r.numNodes != numNodes: continue # do something with r It would be nice if the plain for loop was as flexible as list comprehensions and allowed an optional if clause, like this: for r in results if r.numNodes == numNodes: # do something with r Has this idea come up before? Does anyone else like this idea? -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20071116/06f859b6/attachment.htm From benji at benjiyork.com Fri Nov 16 15:26:06 2007 From: benji at benjiyork.com (Benji York) Date: Fri, 16 Nov 2007 09:26:06 -0500 Subject: [Python-Dev] for loop with if filter In-Reply-To: References: Message-ID: <473DA87E.8030507@benjiyork.com> Gustavo Carneiro wrote: > I am finding myself often doing for loops over a subset of a list, like: > > for r in results: > if r.numNodes != numNodes: > continue > # do something with r > > It would be nice if the plain for loop was as flexible as list comprehensions > and allowed an optional if clause, like this: > > for r in results if r.numNodes == numNodes: > # do something with r You can do the same today, sans sugar: for r in (s for s in results if s.numNodes == numNodes): # do something with r -- Benji York http://benjiyork.com From gjcarneiro at gmail.com Fri Nov 16 15:35:56 2007 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Fri, 16 Nov 2007 14:35:56 +0000 Subject: [Python-Dev] for loop with if filter In-Reply-To: <473DA87E.8030507@benjiyork.com> References: <473DA87E.8030507@benjiyork.com> Message-ID: On 16/11/2007, Benji York wrote: > > Gustavo Carneiro wrote: > > I am finding myself often doing for loops over a subset of a list, like: > > > > for r in results: > > if r.numNodes != numNodes: > > continue > > # do something with r > > > > It would be nice if the plain for loop was as flexible as list > comprehensions > > and allowed an optional if clause, like this: > > > > for r in results if r.numNodes == numNodes: > > # do something with r > > You can do the same today, sans sugar: > > for r in (s for s in results if s.numNodes == numNodes): > # do something with r Yes, I can do that, as well as I can use the 'continue' statement, but both versions are slightly more verbose and less clear than what I propose. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20071116/28fd6ca5/attachment.htm From facundobatista at gmail.com Fri Nov 16 15:50:15 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Fri, 16 Nov 2007 11:50:15 -0300 Subject: [Python-Dev] for loop with if filter In-Reply-To: References: <473DA87E.8030507@benjiyork.com> Message-ID: 2007/11/16, Gustavo Carneiro : > Yes, I can do that, as well as I can use the 'continue' statement, but both > versions are slightly more verbose and less clear than what I propose. The question is: is this slightly more verbosity and less clarity worth enough as to make a syntax change in the language? Personally, my answer is No. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From p.f.moore at gmail.com Fri Nov 16 15:50:32 2007 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 16 Nov 2007 14:50:32 +0000 Subject: [Python-Dev] for loop with if filter In-Reply-To: References: <473DA87E.8030507@benjiyork.com> Message-ID: <79990c6b0711160650w3689589p1879adc3c8c6a8c8@mail.gmail.com> On 16/11/2007, Gustavo Carneiro wrote: > Yes, I can do that, as well as I can use the 'continue' statement, but both > versions are slightly more verbose and less clear than what I propose. This should go to python-ideas, I guess. (FWIW, I can see the attraction of the idea, but I don't think it's worth the cost in terms of new syntax, subtle corner cases, etc etc). Paul. From martin at martinthomas.net Fri Nov 16 17:11:25 2007 From: martin at martinthomas.net (martin at martinthomas.net) Date: Fri, 16 Nov 2007 10:11:25 -0600 Subject: [Python-Dev] for loop with if filter In-Reply-To: References: Message-ID: <20071116101125.qesp2hp8btz4s4sc@64.40.144.195> I started thinking about itertools when I saw this then I realised that your question was about changing the syntax to produce fewer lines of code rather than writing more effiicient code.. seemed like a case where you could use ifilter. //Martin are talking about cvhanging the syntax rQuoting Gustavo Carneiro : > I am finding myself often doing for loops over a subset of a list, like: > > for r in results: > if r.numNodes != numNodes: > continue > # do something with r > > It would be nice if the plain for loop was as flexible as list > comprehensions and allowed an optional if clause, like this: > > for r in results if r.numNodes == numNodes: > # do something with r > > Has this idea come up before? Does anyone else like this idea? > > -- > Gustavo J. A. M. Carneiro > INESC Porto, Telecommunications and Multimedia Unit > "The universe is always one step beyond logic." -- Frank Herbert > From status at bugs.python.org Fri Nov 16 19:06:05 2007 From: status at bugs.python.org (Tracker) Date: Fri, 16 Nov 2007 18:06:05 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071116180605.CD70878389@psf.upfronthosting.co.za> ACTIVITY SUMMARY (11/09/07 - 11/16/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1323 open (+13) / 11612 closed (+25) / 12935 total (+38) Open issues with patches: 418 Average duration of open issues: 691 days. Median duration of open issues: 799 days. Open Issues Breakdown open 1318 (+13) pending 5 ( +0) Issues Created Or Reopened (39) _______________________________ Garbage collection not working correctly in Python 2.3 11/09/07 CLOSED http://bugs.python.org/issue1405 reopened tiran py3k: pythonw.exe fails because std streams a missing 11/10/07 CLOSED http://bugs.python.org/issue1415 created tiran py3k @prop.setter decorators 11/10/07 CLOSED http://bugs.python.org/issue1416 created gvanrossum patch Weakref not working properly 11/10/07 CLOSED http://bugs.python.org/issue1417 created MHOOO Python/hypot.c is never used 11/10/07 CLOSED http://bugs.python.org/issue1418 created marketdickinson ssl module version 1.10 causes TypeError when accepting connecti 11/11/07 CLOSED http://bugs.python.org/issue1419 created complex Unicode literals in tokenize.py and tests. 11/11/07 CLOSED http://bugs.python.org/issue1420 created ron_adam py3k, patch python.org: outdated and false information 11/11/07 CLOSED http://bugs.python.org/issue1421 created tiran Writing to an invalid fd doesn't raise an exception 11/11/07 CLOSED http://bugs.python.org/issue1422 created tiran py3k wave sunau aifc 16bit errors 11/11/07 http://bugs.python.org/issue1423 created jeroen py3k: readline and rlcompleter doesn't list choices 11/11/07 CLOSED http://bugs.python.org/issue1424 created tiran py3k readline: no display matches hook set 11/11/07 CLOSED http://bugs.python.org/issue1425 created tiran py3k readline module needs a review 11/11/07 CLOSED http://bugs.python.org/issue1426 created tiran py3k Error in standard module calendar 11/11/07 CLOSED http://bugs.python.org/issue1427 created gdamjan patch Update to property.__doc__ 11/11/07 CLOSED http://bugs.python.org/issue1428 created tiran patch FD leak in SocketServer 11/12/07 http://bugs.python.org/issue1429 created luke-jr Installing on Vista asks to close Explorer (and Nokia PC Suite) 11/12/07 CLOSED http://bugs.python.org/issue1430 created dabarlow pth files not loaded at startup 11/12/07 http://bugs.python.org/issue1431 created gbloisi patch Strange behavior of urlparse.urljoin 11/13/07 http://bugs.python.org/issue1432 created yan marshal roundtripping for unicode 11/13/07 CLOSED http://bugs.python.org/issue1433 created cfbolz SocketServer creates non-blocking files 11/13/07 http://bugs.python.org/issue1434 created luke-jr Support for multiple handlers for the "with" statement 11/13/07 CLOSED http://bugs.python.org/issue1435 created Stavros logging.config.fileConfig, NameError: name 'RotatingFileHandler' 11/13/07 CLOSED http://bugs.python.org/issue1436 created sebastian List member inside a class is shared by all instances of the cla 11/13/07 CLOSED http://bugs.python.org/issue1437 created glubglub Calling base class methods is slow due to __instancecheck__ over 11/13/07 http://bugs.python.org/issue1438 created gvanrossum proposed 3000 patch for socket.py - "socket GC worries" 11/13/07 CLOSED http://bugs.python.org/issue1439 created janssen py3k, patch Checks for PySys_GetObject("std???") == Py_None 11/14/07 CLOSED http://bugs.python.org/issue1440 created tiran py3k, patch Cycles through ob_type aren't freed 11/14/07 http://bugs.python.org/issue1441 created rhamphoryncus pythonstartup addition of minor error checking 11/14/07 http://bugs.python.org/issue1442 created JosephArmbruster patch Magic class member variable initialization with lists 11/14/07 CLOSED http://bugs.python.org/issue1443 created neoone utf_8_sig streamreader bug, patch, and test 11/15/07 http://bugs.python.org/issue1444 created jgsack patch SystemError accessing uninitialised cell contents 11/15/07 http://bugs.python.org/issue1445 created duncanb Link to call me for free 11/15/07 CLOSED http://bugs.python.org/issue1446 created gopiyadav26 patch to make msvccompiler.py work with vs 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1447 created weck patch Build Python with VS 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1448 created weck patch make msi work the vs 2005(MSVC8) 11/15/07 http://bugs.python.org/issue1449 created weck patch make modulator more general 11/15/07 http://bugs.python.org/issue1450 created weck patch SSL patch for Python 3000 11/15/07 CLOSED http://bugs.python.org/issue1451 created janssen py3k, patch subprocess's popen.stdout.seek(0) doesn't raise an error 11/16/07 http://bugs.python.org/issue1452 created tiran py3k Issues Now Closed (40) ______________________ Parsing a simple script eats all of your memory 68 days http://bugs.python.org/issue1134 amaury.forgeotdarc py3k, patch parsermodule validation out of sync with Grammar 65 days http://bugs.python.org/issue1144 gvanrossum patch pdb fails to launch some script. 33 days http://bugs.python.org/issue1254 tiran pdb bug with "with" statement 33 days http://bugs.python.org/issue1265 amaury.forgeotdarc py3k Add getsize() to io instances 13 days http://bugs.python.org/issue1351 loewis py3k, patch fromfd() and dup() for _socket on WIndows 12 days http://bugs.python.org/issue1378 gvanrossum patch Garbage collection not working correctly in Python 2.3 1 days http://bugs.python.org/issue1405 gvanrossum BaseHTTPServer cannot accept Unicode data 1 days http://bugs.python.org/issue1410 tiran int literal methods inaccessible 0 days http://bugs.python.org/issue1413 loewis py3k: pythonw.exe fails because std streams a missing 4 days http://bugs.python.org/issue1415 amaury.forgeotdarc py3k @prop.setter decorators 1 days http://bugs.python.org/issue1416 gvanrossum patch Weakref not working properly 5 days http://bugs.python.org/issue1417 MHOOO Python/hypot.c is never used 2 days http://bugs.python.org/issue1418 loewis ssl module version 1.10 causes TypeError when accepting connecti 3 days http://bugs.python.org/issue1419 janssen Unicode literals in tokenize.py and tests. 1 days http://bugs.python.org/issue1420 gvanrossum py3k, patch python.org: outdated and false information 1 days http://bugs.python.org/issue1421 georg.brandl Writing to an invalid fd doesn't raise an exception 1 days http://bugs.python.org/issue1422 gvanrossum py3k py3k: readline and rlcompleter doesn't list choices 1 days http://bugs.python.org/issue1424 tiran py3k readline: no display matches hook set 0 days http://bugs.python.org/issue1425 loewis py3k readline module needs a review 1 days http://bugs.python.org/issue1426 tiran py3k Error in standard module calendar 0 days http://bugs.python.org/issue1427 doerwalter patch Update to property.__doc__ 0 days http://bugs.python.org/issue1428 tiran patch Installing on Vista asks to close Explorer (and Nokia PC Suite) 0 days http://bugs.python.org/issue1430 loewis marshal roundtripping for unicode 3 days http://bugs.python.org/issue1433 lemburg Support for multiple handlers for the "with" statement 0 days http://bugs.python.org/issue1435 gvanrossum logging.config.fileConfig, NameError: name 'RotatingFileHandler' 0 days http://bugs.python.org/issue1436 vsajip List member inside a class is shared by all instances of the cla 0 days http://bugs.python.org/issue1437 tiran proposed 3000 patch for socket.py - "socket GC worries" 1 days http://bugs.python.org/issue1439 janssen py3k, patch Checks for PySys_GetObject("std???") == Py_None 1 days http://bugs.python.org/issue1440 tiran py3k, patch Magic class member variable initialization with lists 0 days http://bugs.python.org/issue1443 gvanrossum Link to call me for free 0 days http://bugs.python.org/issue1446 georg.brandl patch to make msvccompiler.py work with vs 2005(MSVC8) 0 days http://bugs.python.org/issue1447 loewis patch Build Python with VS 2005(MSVC8) 0 days http://bugs.python.org/issue1448 loewis patch SSL patch for Python 3000 0 days http://bugs.python.org/issue1451 janssen py3k, patch C3 MRO algorithm implementation 1865 days http://bugs.python.org/issue619475 gvanrossum patch Use correct encoding for printing SyntaxErrors 1151 days http://bugs.python.org/issue1031213 gvanrossum patch recursive __getattr__ in thread crashes 641 days http://bugs.python.org/issue1430436 brett.cannon Intel icc build fails with optimizations -O2 227 days http://bugs.python.org/issue1689617 loewis interpreter crash when multiplying large lists 206 days http://bugs.python.org/issue1704621 gvanrossum patch Remove backslash escapes from tokenize.c. 183 days http://bugs.python.org/issue1720390 gvanrossum py3k, patch Top Issues Most Discussed (10) ______________________________ 27 fromfd() and dup() for _socket on WIndows 12 days closed http://bugs.python.org/issue1378 25 py3k: pythonw.exe fails because std streams a missing 4 days closed http://bugs.python.org/issue1415 10 int literal methods inaccessible 0 days closed http://bugs.python.org/issue1413 9 SSL patch for Python 3000 0 days closed http://bugs.python.org/issue1451 9 Parsing a simple script eats all of your memory 68 days closed http://bugs.python.org/issue1134 7 Unicode literals in tokenize.py and tests. 1 days closed http://bugs.python.org/issue1420 7 pdb bug with "with" statement 33 days closed http://bugs.python.org/issue1265 6 pth files not loaded at startup 4 days open http://bugs.python.org/issue1431 6 Weakref not working properly 5 days closed http://bugs.python.org/issue1417 6 Fix for refleak tests 7 days open http://bugs.python.org/issue1414 From brett at python.org Fri Nov 16 19:13:34 2007 From: brett at python.org (Brett Cannon) Date: Fri, 16 Nov 2007 10:13:34 -0800 Subject: [Python-Dev] Python Library Addition: First-class Procedure Signatures In-Reply-To: References: Message-ID: On Nov 15, 2007 12:48 PM, Steven Bethard wrote: > On Nov 14, 2007 1:18 PM, Brett Cannon wrote: > > On Nov 14, 2007 10:30 AM, Isaac Morland wrote: > > > So I wrote a Signature class. Instances of the class represent all the > > > information present between the parentheses of a procedure definition. > > > Properties are provided to get the information out, and an expand_args method > > > can be called to expand arguments into a dictionary. This expand_args method > > > implements (if I've done it right) the argument conversion part of section > > > 5.3.4 of the Python Reference Manual (http://docs.python.org/ref/calls.html). > > > > As Collin already pointed out, it sounds like you want PEP 362 to get > > into the stdlib. I have not made a big push to try to get my existing > > implementation into Python 2.6/3.0, but I plan to at some point. > > Every time I read PEP 362, I get lost in the details. When you get > around to working on it again, could you add a bunch of examples? > That would make it much easier to tell why we want all those objects > and attributes. > You might not need them in general. It just re-packages all the information that is found between a function object and a code object into a single location. > FWIW, Isaac's version of bind() that returns a regular str->object > dict is all I've ever needed in my own code. That's what the implementation does at the moment (if I remember correctly). I am about to bundle up the code and submit to PyPI to get feedback from folks and to just get it out there instead of languishing in the sandbox while I try to decide exactly what to do about the open issues. I will see if i can toss in some examples into the PEP. -Brett From tjreedy at udel.edu Sat Nov 17 00:31:12 2007 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 16 Nov 2007 18:31:12 -0500 Subject: [Python-Dev] for loop with if filter References: Message-ID: "Gustavo Carneiro" wrote in message news:a467ca4f0711160617p11564c05q8b2c59e87981c028 at mail.gmail.com... |I am finding myself often doing for loops over a subset of a list, like: | | for r in results: | if r.numNodes != numNodes: | continue | # do something with r Why write it backwards? for r in results: if r.numNodes == numNodes # do something with r is the direct parallel with the below code. | It would be nice if the plain for loop was as flexible as list | comprehensions and allowed an optional if clause, like this: | | for r in results if r.numNodes == numNodes: | # do something with r Same as above with ':\n' deleted. A trivial difference. An optional if clause is *less* flexible than an optional if statement and block. | Has this idea come up before? Does anyone else like this idea? Yes, and Guido rejected at that time. tjr From mithrandi-python-dev at mithrandi.za.net Sat Nov 17 02:31:51 2007 From: mithrandi-python-dev at mithrandi.za.net (Tristan Seligmann) Date: Sat, 17 Nov 2007 03:31:51 +0200 Subject: [Python-Dev] for loop with if filter In-Reply-To: References: Message-ID: <20071117013151.GA4230@mithrandi.za.net> * Terry Reedy [2007-11-16 18:31:12 -0500]: > > "Gustavo Carneiro" wrote in message > news:a467ca4f0711160617p11564c05q8b2c59e87981c028 at mail.gmail.com... > |I am finding myself often doing for loops over a subset of a list, like: > | > | for r in results: > | if r.numNodes != numNodes: > | continue > | # do something with r > > Why write it backwards? > > for r in results: > if r.numNodes == numNodes > # do something with r > > is the direct parallel with the below code. The extra level of indentation is awkward. -- mithrandi, i Ainil en-Balandor, a faer Ambar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/python-dev/attachments/20071117/0cb16eef/attachment.pgp From brett at python.org Sat Nov 17 05:26:37 2007 From: brett at python.org (Brett Cannon) Date: Fri, 16 Nov 2007 20:26:37 -0800 Subject: [Python-Dev] Python Library Addition: First-class Procedure Signatures In-Reply-To: References: Message-ID: On Nov 15, 2007 12:48 PM, Steven Bethard wrote: > On Nov 14, 2007 1:18 PM, Brett Cannon wrote: > > On Nov 14, 2007 10:30 AM, Isaac Morland wrote: > > > So I wrote a Signature class. Instances of the class represent all the > > > information present between the parentheses of a procedure definition. > > > Properties are provided to get the information out, and an expand_args method > > > can be called to expand arguments into a dictionary. This expand_args method > > > implements (if I've done it right) the argument conversion part of section > > > 5.3.4 of the Python Reference Manual (http://docs.python.org/ref/calls.html). > > > > As Collin already pointed out, it sounds like you want PEP 362 to get > > into the stdlib. I have not made a big push to try to get my existing > > implementation into Python 2.6/3.0, but I plan to at some point. > > Every time I read PEP 362, I get lost in the details. When you get > around to working on it again, could you add a bunch of examples? > That would make it much easier to tell why we want all those objects > and attributes. > Done. I tossed up an annotations duck typing checker in the PEP. > FWIW, Isaac's version of bind() that returns a regular str->object > dict is all I've ever needed in my own code. My implementation does that as well. It was a typo in the PEP that said bind() returned Parameter objects as values. -Brett From status at bugs.python.org Sat Nov 17 19:06:06 2007 From: status at bugs.python.org (Tracker) Date: Sat, 17 Nov 2007 18:06:06 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071117180606.1C3E7781F7@psf.upfronthosting.co.za> ACTIVITY SUMMARY (11/10/07 - 11/17/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1323 open (+14) / 11615 closed (+23) / 12938 total (+37) Open issues with patches: 418 Average duration of open issues: 692 days. Median duration of open issues: 800 days. Open Issues Breakdown open 1318 (+14) pending 5 ( +0) Issues Created Or Reopened (37) _______________________________ ssl module version 1.10 causes TypeError when accepting connecti 11/11/07 CLOSED http://bugs.python.org/issue1419 created complex Unicode literals in tokenize.py and tests. 11/11/07 CLOSED http://bugs.python.org/issue1420 created ron_adam py3k, patch python.org: outdated and false information 11/11/07 CLOSED http://bugs.python.org/issue1421 created tiran Writing to an invalid fd doesn't raise an exception 11/11/07 CLOSED http://bugs.python.org/issue1422 created tiran py3k wave sunau aifc 16bit errors 11/11/07 http://bugs.python.org/issue1423 created jeroen py3k: readline and rlcompleter doesn't list choices 11/11/07 CLOSED http://bugs.python.org/issue1424 created tiran py3k readline: no display matches hook set 11/11/07 CLOSED http://bugs.python.org/issue1425 created tiran py3k readline module needs a review 11/11/07 CLOSED http://bugs.python.org/issue1426 created tiran py3k Error in standard module calendar 11/11/07 CLOSED http://bugs.python.org/issue1427 created gdamjan patch Update to property.__doc__ 11/11/07 CLOSED http://bugs.python.org/issue1428 created tiran patch FD leak in SocketServer 11/12/07 http://bugs.python.org/issue1429 created luke-jr Installing on Vista asks to close Explorer (and Nokia PC Suite) 11/12/07 CLOSED http://bugs.python.org/issue1430 created dabarlow pth files not loaded at startup 11/12/07 CLOSED http://bugs.python.org/issue1431 created gbloisi patch Strange behavior of urlparse.urljoin 11/13/07 http://bugs.python.org/issue1432 created yan marshal roundtripping for unicode 11/13/07 CLOSED http://bugs.python.org/issue1433 created cfbolz SocketServer creates non-blocking files 11/13/07 http://bugs.python.org/issue1434 created luke-jr Support for multiple handlers for the "with" statement 11/13/07 CLOSED http://bugs.python.org/issue1435 created Stavros logging.config.fileConfig, NameError: name 'RotatingFileHandler' 11/13/07 CLOSED http://bugs.python.org/issue1436 created sebastian List member inside a class is shared by all instances of the cla 11/13/07 CLOSED http://bugs.python.org/issue1437 created glubglub Calling base class methods is slow due to __instancecheck__ over 11/13/07 http://bugs.python.org/issue1438 created gvanrossum proposed 3000 patch for socket.py - "socket GC worries" 11/13/07 CLOSED http://bugs.python.org/issue1439 created janssen py3k, patch Checks for PySys_GetObject("std???") == Py_None 11/14/07 CLOSED http://bugs.python.org/issue1440 created tiran py3k, patch Cycles through ob_type aren't freed 11/14/07 http://bugs.python.org/issue1441 created rhamphoryncus pythonstartup addition of minor error checking 11/14/07 http://bugs.python.org/issue1442 created JosephArmbruster patch Magic class member variable initialization with lists 11/14/07 CLOSED http://bugs.python.org/issue1443 created neoone utf_8_sig streamreader bug, patch, and test 11/15/07 http://bugs.python.org/issue1444 created jgsack patch SystemError accessing uninitialised cell contents 11/15/07 http://bugs.python.org/issue1445 created duncanb Link to call me for free 11/15/07 CLOSED http://bugs.python.org/issue1446 created gopiyadav26 patch to make msvccompiler.py work with vs 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1447 created weck patch Build Python with VS 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1448 created weck patch make msi work the vs 2005(MSVC8) 11/15/07 http://bugs.python.org/issue1449 created weck patch make modulator more general 11/15/07 http://bugs.python.org/issue1450 created weck patch SSL patch for Python 3000 11/15/07 CLOSED http://bugs.python.org/issue1451 created janssen py3k, patch subprocess's popen.stdout.seek(0) doesn't raise an error 11/16/07 http://bugs.python.org/issue1452 created tiran py3k Python does not honor "CFLAGS" environment variable 11/16/07 CLOSED http://bugs.python.org/issue1453 created tebeka Generators break trace functionality 11/17/07 http://bugs.python.org/issue1454 created cortesi VS2008, quick hack for distutils.msvccompiler 11/17/07 http://bugs.python.org/issue1455 created tiran py3k, patch Issues Now Closed (39) ______________________ Parsing a simple script eats all of your memory 68 days http://bugs.python.org/issue1134 amaury.forgeotdarc py3k, patch parsermodule validation out of sync with Grammar 65 days http://bugs.python.org/issue1144 gvanrossum patch pdb fails to launch some script. 33 days http://bugs.python.org/issue1254 tiran string find and rfind methods give a TypeError that is misleadin 37 days http://bugs.python.org/issue1259 facundobatista pdb bug with "with" statement 33 days http://bugs.python.org/issue1265 amaury.forgeotdarc py3k fromfd() and dup() for _socket on WIndows 12 days http://bugs.python.org/issue1378 gvanrossum patch Garbage collection not working correctly in Python 2.3 1 days http://bugs.python.org/issue1405 gvanrossum py3k: pythonw.exe fails because std streams a missing 4 days http://bugs.python.org/issue1415 amaury.forgeotdarc py3k @prop.setter decorators 1 days http://bugs.python.org/issue1416 gvanrossum patch Weakref not working properly 5 days http://bugs.python.org/issue1417 MHOOO Python/hypot.c is never used 2 days http://bugs.python.org/issue1418 loewis ssl module version 1.10 causes TypeError when accepting connecti 3 days http://bugs.python.org/issue1419 janssen Unicode literals in tokenize.py and tests. 1 days http://bugs.python.org/issue1420 gvanrossum py3k, patch python.org: outdated and false information 1 days http://bugs.python.org/issue1421 georg.brandl Writing to an invalid fd doesn't raise an exception 1 days http://bugs.python.org/issue1422 gvanrossum py3k py3k: readline and rlcompleter doesn't list choices 1 days http://bugs.python.org/issue1424 tiran py3k readline: no display matches hook set 0 days http://bugs.python.org/issue1425 loewis py3k readline module needs a review 1 days http://bugs.python.org/issue1426 tiran py3k Error in standard module calendar 0 days http://bugs.python.org/issue1427 doerwalter patch Update to property.__doc__ 0 days http://bugs.python.org/issue1428 tiran patch Installing on Vista asks to close Explorer (and Nokia PC Suite) 0 days http://bugs.python.org/issue1430 loewis pth files not loaded at startup 4 days http://bugs.python.org/issue1431 brett.cannon patch marshal roundtripping for unicode 3 days http://bugs.python.org/issue1433 lemburg Support for multiple handlers for the "with" statement 0 days http://bugs.python.org/issue1435 gvanrossum logging.config.fileConfig, NameError: name 'RotatingFileHandler' 0 days http://bugs.python.org/issue1436 vsajip List member inside a class is shared by all instances of the cla 0 days http://bugs.python.org/issue1437 tiran proposed 3000 patch for socket.py - "socket GC worries" 1 days http://bugs.python.org/issue1439 janssen py3k, patch Checks for PySys_GetObject("std???") == Py_None 1 days http://bugs.python.org/issue1440 tiran py3k, patch Magic class member variable initialization with lists 0 days http://bugs.python.org/issue1443 gvanrossum Link to call me for free 0 days http://bugs.python.org/issue1446 georg.brandl patch to make msvccompiler.py work with vs 2005(MSVC8) 0 days http://bugs.python.org/issue1447 loewis patch Build Python with VS 2005(MSVC8) 0 days http://bugs.python.org/issue1448 loewis patch SSL patch for Python 3000 0 days http://bugs.python.org/issue1451 janssen py3k, patch Python does not honor "CFLAGS" environment variable 0 days http://bugs.python.org/issue1453 loewis C3 MRO algorithm implementation 1865 days http://bugs.python.org/issue619475 gvanrossum patch Use correct encoding for printing SyntaxErrors 1151 days http://bugs.python.org/issue1031213 gvanrossum patch recursive __getattr__ in thread crashes 641 days http://bugs.python.org/issue1430436 brett.cannon interpreter crash when multiplying large lists 206 days http://bugs.python.org/issue1704621 gvanrossum patch Remove backslash escapes from tokenize.c. 183 days http://bugs.python.org/issue1720390 gvanrossum py3k, patch Top Issues Most Discussed (10) ______________________________ 26 fromfd() and dup() for _socket on WIndows 12 days closed http://bugs.python.org/issue1378 22 py3k: pythonw.exe fails because std streams a missing 4 days closed http://bugs.python.org/issue1415 9 SSL patch for Python 3000 0 days closed http://bugs.python.org/issue1451 9 Parsing a simple script eats all of your memory 68 days closed http://bugs.python.org/issue1134 7 Python does not honor "CFLAGS" environment variable 0 days closed http://bugs.python.org/issue1453 7 pth files not loaded at startup 4 days closed http://bugs.python.org/issue1431 7 Unicode literals in tokenize.py and tests. 1 days closed http://bugs.python.org/issue1420 7 pdb bug with "with" statement 33 days closed http://bugs.python.org/issue1265 5 make msi work the vs 2005(MSVC8) 2 days open http://bugs.python.org/issue1449 5 Checks for PySys_GetObject("std???") == Py_None 1 days closed http://bugs.python.org/issue1440 From status at bugs.python.org Sun Nov 18 19:06:06 2007 From: status at bugs.python.org (Tracker) Date: Sun, 18 Nov 2007 18:06:06 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071118180606.028637836D@psf.upfronthosting.co.za> ACTIVITY SUMMARY (11/11/07 - 11/18/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1322 open (+14) / 11618 closed (+21) / 12940 total (+35) Open issues with patches: 417 Average duration of open issues: 693 days. Median duration of open issues: 801 days. Open Issues Breakdown open 1317 (+14) pending 5 ( +0) Issues Created Or Reopened (35) _______________________________ wave sunau aifc 16bit errors 11/11/07 http://bugs.python.org/issue1423 created jeroen py3k: readline and rlcompleter doesn't list choices 11/11/07 CLOSED http://bugs.python.org/issue1424 created tiran py3k readline: no display matches hook set 11/11/07 CLOSED http://bugs.python.org/issue1425 created tiran py3k readline module needs a review 11/11/07 CLOSED http://bugs.python.org/issue1426 created tiran py3k Error in standard module calendar 11/11/07 CLOSED http://bugs.python.org/issue1427 created gdamjan patch Update to property.__doc__ 11/11/07 CLOSED http://bugs.python.org/issue1428 created tiran patch FD leak in SocketServer 11/12/07 http://bugs.python.org/issue1429 created luke-jr Installing on Vista asks to close Explorer (and Nokia PC Suite) 11/12/07 CLOSED http://bugs.python.org/issue1430 created dabarlow pth files not loaded at startup 11/12/07 CLOSED http://bugs.python.org/issue1431 created gbloisi patch Strange behavior of urlparse.urljoin 11/13/07 http://bugs.python.org/issue1432 created yan marshal roundtripping for unicode 11/13/07 CLOSED http://bugs.python.org/issue1433 created cfbolz SocketServer creates non-blocking files 11/13/07 http://bugs.python.org/issue1434 created luke-jr Support for multiple handlers for the "with" statement 11/13/07 CLOSED http://bugs.python.org/issue1435 created Stavros logging.config.fileConfig, NameError: name 'RotatingFileHandler' 11/13/07 CLOSED http://bugs.python.org/issue1436 created sebastian List member inside a class is shared by all instances of the cla 11/13/07 CLOSED http://bugs.python.org/issue1437 created glubglub Calling base class methods is slow due to __instancecheck__ over 11/13/07 http://bugs.python.org/issue1438 created gvanrossum proposed 3000 patch for socket.py - "socket GC worries" 11/13/07 CLOSED http://bugs.python.org/issue1439 created janssen py3k, patch Checks for PySys_GetObject("std???") == Py_None 11/14/07 CLOSED http://bugs.python.org/issue1440 created tiran py3k, patch Cycles through ob_type aren't freed 11/14/07 http://bugs.python.org/issue1441 created rhamphoryncus pythonstartup addition of minor error checking 11/14/07 http://bugs.python.org/issue1442 created JosephArmbruster patch Magic class member variable initialization with lists 11/14/07 CLOSED http://bugs.python.org/issue1443 created neoone utf_8_sig streamreader bug, patch, and test 11/15/07 http://bugs.python.org/issue1444 created jgsack patch SystemError accessing uninitialised cell contents 11/15/07 http://bugs.python.org/issue1445 created duncanb Link to call me for free 11/15/07 CLOSED http://bugs.python.org/issue1446 created gopiyadav26 patch to make msvccompiler.py work with vs 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1447 created weck patch Build Python with VS 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1448 created weck patch make msi work the vs 2005(MSVC8) 11/15/07 http://bugs.python.org/issue1449 created weck patch make modulator more general 11/15/07 http://bugs.python.org/issue1450 created weck patch SSL patch for Python 3000 11/15/07 CLOSED http://bugs.python.org/issue1451 created janssen py3k, patch subprocess's popen.stdout.seek(0) doesn't raise an error 11/16/07 http://bugs.python.org/issue1452 created tiran py3k Python does not honor "CFLAGS" environment variable 11/16/07 CLOSED http://bugs.python.org/issue1453 created tebeka Generators break trace functionality 11/17/07 CLOSED http://bugs.python.org/issue1454 created cortesi VS2008, quick hack for distutils.msvccompiler 11/17/07 http://bugs.python.org/issue1455 created tiran py3k, patch unexpected iterator behavior with removal 11/18/07 CLOSED http://bugs.python.org/issue1456 created JosephArmbruster IDLE - configDialog - new layout for key config 11/18/07 http://bugs.python.org/issue1457 created taleinat Issues Now Closed (40) ______________________ Parsing a simple script eats all of your memory 68 days http://bugs.python.org/issue1134 amaury.forgeotdarc py3k, patch parsermodule validation out of sync with Grammar 65 days http://bugs.python.org/issue1144 gvanrossum patch pdb fails to launch some script. 33 days http://bugs.python.org/issue1254 tiran string find and rfind methods give a TypeError that is misleadin 37 days http://bugs.python.org/issue1259 facundobatista pdb bug with "with" statement 33 days http://bugs.python.org/issue1265 amaury.forgeotdarc py3k fromfd() and dup() for _socket on WIndows 12 days http://bugs.python.org/issue1378 gvanrossum patch py3k: pythonw.exe fails because std streams a missing 4 days http://bugs.python.org/issue1415 amaury.forgeotdarc py3k Weakref not working properly 5 days http://bugs.python.org/issue1417 MHOOO Python/hypot.c is never used 2 days http://bugs.python.org/issue1418 loewis ssl module version 1.10 causes TypeError when accepting connecti 3 days http://bugs.python.org/issue1419 janssen Unicode literals in tokenize.py and tests. 1 days http://bugs.python.org/issue1420 gvanrossum py3k, patch python.org: outdated and false information 1 days http://bugs.python.org/issue1421 georg.brandl Writing to an invalid fd doesn't raise an exception 1 days http://bugs.python.org/issue1422 gvanrossum py3k py3k: readline and rlcompleter doesn't list choices 1 days http://bugs.python.org/issue1424 tiran py3k readline: no display matches hook set 0 days http://bugs.python.org/issue1425 loewis py3k readline module needs a review 1 days http://bugs.python.org/issue1426 tiran py3k Error in standard module calendar 0 days http://bugs.python.org/issue1427 doerwalter patch Update to property.__doc__ 0 days http://bugs.python.org/issue1428 tiran patch Installing on Vista asks to close Explorer (and Nokia PC Suite) 0 days http://bugs.python.org/issue1430 loewis pth files not loaded at startup 4 days http://bugs.python.org/issue1431 brett.cannon patch marshal roundtripping for unicode 3 days http://bugs.python.org/issue1433 lemburg Support for multiple handlers for the "with" statement 0 days http://bugs.python.org/issue1435 gvanrossum logging.config.fileConfig, NameError: name 'RotatingFileHandler' 0 days http://bugs.python.org/issue1436 vsajip List member inside a class is shared by all instances of the cla 0 days http://bugs.python.org/issue1437 tiran proposed 3000 patch for socket.py - "socket GC worries" 1 days http://bugs.python.org/issue1439 janssen py3k, patch Checks for PySys_GetObject("std???") == Py_None 1 days http://bugs.python.org/issue1440 tiran py3k, patch Magic class member variable initialization with lists 0 days http://bugs.python.org/issue1443 gvanrossum Link to call me for free 0 days http://bugs.python.org/issue1446 georg.brandl patch to make msvccompiler.py work with vs 2005(MSVC8) 0 days http://bugs.python.org/issue1447 loewis patch Build Python with VS 2005(MSVC8) 0 days http://bugs.python.org/issue1448 loewis patch SSL patch for Python 3000 0 days http://bugs.python.org/issue1451 janssen py3k, patch Python does not honor "CFLAGS" environment variable 0 days http://bugs.python.org/issue1453 loewis Generators break trace functionality 1 days http://bugs.python.org/issue1454 gvanrossum unexpected iterator behavior with removal 0 days http://bugs.python.org/issue1456 tiran C3 MRO algorithm implementation 1865 days http://bugs.python.org/issue619475 gvanrossum patch Use correct encoding for printing SyntaxErrors 1151 days http://bugs.python.org/issue1031213 gvanrossum patch recursive __getattr__ in thread crashes 641 days http://bugs.python.org/issue1430436 brett.cannon interpreter crash when multiplying large lists 206 days http://bugs.python.org/issue1704621 gvanrossum patch Remove backslash escapes from tokenize.c. 183 days http://bugs.python.org/issue1720390 gvanrossum py3k, patch Add a -z interpreter flag to execute a zip file 152 days http://bugs.python.org/issue1739468 ncoghlan patch Top Issues Most Discussed (10) ______________________________ 26 fromfd() and dup() for _socket on WIndows 12 days closed http://bugs.python.org/issue1378 18 py3k: pythonw.exe fails because std streams a missing 4 days closed http://bugs.python.org/issue1415 9 SSL patch for Python 3000 0 days closed http://bugs.python.org/issue1451 9 Parsing a simple script eats all of your memory 68 days closed http://bugs.python.org/issue1134 7 Python does not honor "CFLAGS" environment variable 0 days closed http://bugs.python.org/issue1453 7 pth files not loaded at startup 4 days closed http://bugs.python.org/issue1431 7 pdb bug with "with" statement 33 days closed http://bugs.python.org/issue1265 6 VS2008, quick hack for distutils.msvccompiler 1 days open http://bugs.python.org/issue1455 5 make msi work the vs 2005(MSVC8) 3 days open http://bugs.python.org/issue1449 5 Checks for PySys_GetObject("std???") == Py_None 1 days closed http://bugs.python.org/issue1440 From lists at cheimes.de Mon Nov 19 00:16:25 2007 From: lists at cheimes.de (Christian Heimes) Date: Mon, 19 Nov 2007 00:16:25 +0100 Subject: [Python-Dev] r59042 - python/branches/py3k/Modules/xxmodule.c In-Reply-To: References: <20071118213037.1418E1E4024@bag.python.org> Message-ID: <4740C7C9.4090900@cheimes.de> Brett Cannon wrote: > Can't you do this testing in your own checkout without committing the > change until you have talked to python-dev about the idea of changing > how all types are initialized? CC to Python Dev The discussion is about http://svn.python.org/view?rev=59042&view=rev I've carefully studied the docs before I've committed the change. The problem is a well documented compiler issue on Windows. The tp_base slot can't be filled with a type on Windows when the module is compiled with distutils. On Unix the gcc can handle tp_base fine. Since most Python developers are using Linux or Mac OS X and the file isn't covered by a unit test nobody has noticed the problem http://docs.python.org/dev/3.0/extending/newtypes.html#subclassing-other-types "When filling out the PyTypeObject() for the Shoddy type, you see a slot for tp_base(). Due to cross platform compiler issues, you can?t fill that field directly with the PyList_Type(); it can be done later in the module?s init() function." I've changed it for two reasons: * The xxmodule.c file is an example and template for developers. It's giving a bad example and it leads to code that doesn't compile on Windows. * I'm working on a very basic unit test to test distutils.core.Extension. I've chosen xxmodule and xxsubtype for the tests. I hope I didn't step over a line with the change. I didn't change the files w/o consulting the documentation first. Christian From brett at python.org Mon Nov 19 01:55:32 2007 From: brett at python.org (Brett Cannon) Date: Sun, 18 Nov 2007 16:55:32 -0800 Subject: [Python-Dev] r59042 - python/branches/py3k/Modules/xxmodule.c In-Reply-To: <4740C7C9.4090900@cheimes.de> References: <20071118213037.1418E1E4024@bag.python.org> <4740C7C9.4090900@cheimes.de> Message-ID: On Nov 18, 2007 3:16 PM, Christian Heimes wrote: > Brett Cannon wrote: > > Can't you do this testing in your own checkout without committing the > > change until you have talked to python-dev about the idea of changing > > how all types are initialized? > > CC to Python Dev > The discussion is about http://svn.python.org/view?rev=59042&view=rev > > I've carefully studied the docs before I've committed the change. The > problem is a well documented compiler issue on Windows. The tp_base slot > can't be filled with a type on Windows when the module is compiled with > distutils. > > On Unix the gcc can handle tp_base fine. Since most Python developers > are using Linux or Mac OS X and the file isn't covered by a unit test > nobody has noticed the problem > > http://docs.python.org/dev/3.0/extending/newtypes.html#subclassing-other-types > > "When filling out the PyTypeObject() for the Shoddy type, you see a slot > for tp_base(). Due to cross platform compiler issues, you can't fill > that field directly with the PyList_Type(); it can be done later in the > module's init() function." > If the docs point that fact out then it is fine. I didn't even know about it! > I've changed it for two reasons: > > * The xxmodule.c file is an example and template for developers. It's > giving a bad example and it leads to code that doesn't compile on Windows. > > * I'm working on a very basic unit test to test > distutils.core.Extension. I've chosen xxmodule and xxsubtype for the tests. > > I hope I didn't step over a line with the change. I didn't change the > files w/o consulting the documentation first. Nope. With the docs specifying that then it makes sense to change the example code. -Brett From lists at cheimes.de Mon Nov 19 02:13:05 2007 From: lists at cheimes.de (Christian Heimes) Date: Mon, 19 Nov 2007 02:13:05 +0100 Subject: [Python-Dev] r59042 - python/branches/py3k/Modules/xxmodule.c In-Reply-To: References: <20071118213037.1418E1E4024@bag.python.org> <4740C7C9.4090900@cheimes.de> Message-ID: <4740E321.5000109@cheimes.de> Brett Cannon wrote: > If the docs point that fact out then it is fine. I didn't even know about it! I didn't know it until today, too. I took me some reading why the h... the same code compiles fine on Linux but fails on Windows. :) Christian From status at bugs.python.org Mon Nov 19 19:06:06 2007 From: status at bugs.python.org (Tracker) Date: Mon, 19 Nov 2007 18:06:06 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071119180606.38A1D7832B@psf.upfronthosting.co.za> ACTIVITY SUMMARY (11/12/07 - 11/19/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1325 open (+15) / 11623 closed (+20) / 12948 total (+35) Open issues with patches: 416 Average duration of open issues: 693 days. Median duration of open issues: 802 days. Open Issues Breakdown open 1320 (+15) pending 5 ( +0) Issues Created Or Reopened (36) _______________________________ pth files not loaded at startup 11/12/07 CLOSED http://bugs.python.org/issue1431 created gbloisi patch Strange behavior of urlparse.urljoin 11/13/07 http://bugs.python.org/issue1432 created yan marshal roundtripping for unicode 11/13/07 CLOSED http://bugs.python.org/issue1433 created cfbolz SocketServer creates non-blocking files 11/13/07 http://bugs.python.org/issue1434 created luke-jr Support for multiple handlers for the "with" statement 11/13/07 CLOSED http://bugs.python.org/issue1435 created Stavros logging.config.fileConfig, NameError: name 'RotatingFileHandler' 11/13/07 CLOSED http://bugs.python.org/issue1436 created sebastian List member inside a class is shared by all instances of the cla 11/13/07 CLOSED http://bugs.python.org/issue1437 created glubglub Calling base class methods is slow due to __instancecheck__ over 11/13/07 http://bugs.python.org/issue1438 created gvanrossum proposed 3000 patch for socket.py - "socket GC worries" 11/13/07 CLOSED http://bugs.python.org/issue1439 created janssen py3k, patch Checks for PySys_GetObject("std???") == Py_None 11/14/07 CLOSED http://bugs.python.org/issue1440 created tiran py3k, patch Cycles through ob_type aren't freed 11/14/07 http://bugs.python.org/issue1441 created rhamphoryncus pythonstartup addition of minor error checking 11/14/07 http://bugs.python.org/issue1442 created JosephArmbruster patch Magic class member variable initialization with lists 11/14/07 CLOSED http://bugs.python.org/issue1443 created neoone utf_8_sig streamreader bug, patch, and test 11/15/07 CLOSED http://bugs.python.org/issue1444 created jgsack patch SystemError accessing uninitialised cell contents 11/15/07 http://bugs.python.org/issue1445 created duncanb Link to call me for free 11/15/07 CLOSED http://bugs.python.org/issue1446 created gopiyadav26 patch to make msvccompiler.py work with vs 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1447 created weck patch Build Python with VS 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1448 created weck patch make msi work the vs 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1449 created weck patch make modulator more general 11/15/07 http://bugs.python.org/issue1450 created weck patch SSL patch for Python 3000 11/15/07 CLOSED http://bugs.python.org/issue1451 created janssen py3k, patch subprocess's popen.stdout.seek(0) doesn't raise an error 11/16/07 http://bugs.python.org/issue1452 created tiran py3k Python does not honor "CFLAGS" environment variable 11/16/07 CLOSED http://bugs.python.org/issue1453 created tebeka Generators break trace functionality 11/17/07 CLOSED http://bugs.python.org/issue1454 created cortesi VS2008, quick hack for distutils.msvccompiler 11/17/07 http://bugs.python.org/issue1455 created tiran py3k, patch unexpected iterator behavior with removal 11/18/07 CLOSED http://bugs.python.org/issue1456 created JosephArmbruster IDLE - configDialog - new layout for key config 11/18/07 http://bugs.python.org/issue1457 created taleinat installer crashes on attempted cancellation 11/18/07 http://bugs.python.org/issue1458 created JosephArmbruster Bugs lost on migration from Sourceforge 11/18/07 CLOSED http://bugs.python.org/issue1459 created gagenellina codecs utf7 decoding error 11/19/07 http://bugs.python.org/issue1460 created arnimar 0**0 should raise an error 11/19/07 CLOSED http://bugs.python.org/issue1461 created jmgillet About this document refers to SourceForge tracker 11/19/07 http://bugs.python.org/issue1462 created kjohnson Minor error in mimetypes docs 11/19/07 CLOSED http://bugs.python.org/issue1463 created kjohnson inet_pton redefined while building with windows SDK 6.0 11/19/07 http://bugs.python.org/issue1464 created weck building python 2.6 with VC Express 2008 Beta2 11/19/07 http://bugs.python.org/issue1465 created weck Add a -z interpreter flag to execute a zip file 11/19/07 http://bugs.python.org/issue1739468 reopened ncoghlan patch Issues Now Closed (35) ______________________ Parsing a simple script eats all of your memory 68 days http://bugs.python.org/issue1134 amaury.forgeotdarc py3k, patch parsermodule validation out of sync with Grammar 65 days http://bugs.python.org/issue1144 gvanrossum patch string find and rfind methods give a TypeError that is misleadin 37 days http://bugs.python.org/issue1259 facundobatista pdb bug with "with" statement 33 days http://bugs.python.org/issue1265 amaury.forgeotdarc py3k windows installer problem 20 days http://bugs.python.org/issue1354 loewis fromfd() and dup() for _socket on WIndows 12 days http://bugs.python.org/issue1378 gvanrossum patch py3k: pythonw.exe fails because std streams a missing 4 days http://bugs.python.org/issue1415 amaury.forgeotdarc py3k Weakref not working properly 5 days http://bugs.python.org/issue1417 MHOOO ssl module version 1.10 causes TypeError when accepting connecti 3 days http://bugs.python.org/issue1419 janssen readline module needs a review 1 days http://bugs.python.org/issue1426 tiran py3k pth files not loaded at startup 4 days http://bugs.python.org/issue1431 brett.cannon patch marshal roundtripping for unicode 3 days http://bugs.python.org/issue1433 lemburg Support for multiple handlers for the "with" statement 0 days http://bugs.python.org/issue1435 gvanrossum logging.config.fileConfig, NameError: name 'RotatingFileHandler' 0 days http://bugs.python.org/issue1436 vsajip List member inside a class is shared by all instances of the cla 0 days http://bugs.python.org/issue1437 tiran proposed 3000 patch for socket.py - "socket GC worries" 1 days http://bugs.python.org/issue1439 janssen py3k, patch Checks for PySys_GetObject("std???") == Py_None 1 days http://bugs.python.org/issue1440 tiran py3k, patch Magic class member variable initialization with lists 0 days http://bugs.python.org/issue1443 gvanrossum utf_8_sig streamreader bug, patch, and test 4 days http://bugs.python.org/issue1444 doerwalter patch Link to call me for free 0 days http://bugs.python.org/issue1446 georg.brandl patch to make msvccompiler.py work with vs 2005(MSVC8) 0 days http://bugs.python.org/issue1447 loewis patch Build Python with VS 2005(MSVC8) 0 days http://bugs.python.org/issue1448 loewis patch make msi work the vs 2005(MSVC8) 3 days http://bugs.python.org/issue1449 tiran patch SSL patch for Python 3000 0 days http://bugs.python.org/issue1451 janssen py3k, patch Python does not honor "CFLAGS" environment variable 0 days http://bugs.python.org/issue1453 loewis Generators break trace functionality 1 days http://bugs.python.org/issue1454 gvanrossum unexpected iterator behavior with removal 0 days http://bugs.python.org/issue1456 tiran Bugs lost on migration from Sourceforge 0 days http://bugs.python.org/issue1459 brett.cannon 0**0 should raise an error 0 days http://bugs.python.org/issue1461 gvanrossum Minor error in mimetypes docs 0 days http://bugs.python.org/issue1463 facundobatista C3 MRO algorithm implementation 1865 days http://bugs.python.org/issue619475 gvanrossum patch Use correct encoding for printing SyntaxErrors 1151 days http://bugs.python.org/issue1031213 gvanrossum patch recursive __getattr__ in thread crashes 641 days http://bugs.python.org/issue1430436 brett.cannon interpreter crash when multiplying large lists 206 days http://bugs.python.org/issue1704621 gvanrossum patch Remove backslash escapes from tokenize.c. 183 days http://bugs.python.org/issue1720390 gvanrossum py3k, patch Top Issues Most Discussed (10) ______________________________ 26 fromfd() and dup() for _socket on WIndows 12 days closed http://bugs.python.org/issue1378 14 py3k: pythonw.exe fails because std streams a missing 4 days closed http://bugs.python.org/issue1415 9 SSL patch for Python 3000 0 days closed http://bugs.python.org/issue1451 9 Parsing a simple script eats all of your memory 68 days closed http://bugs.python.org/issue1134 8 Add a -z interpreter flag to execute a zip file 0 days open http://bugs.python.org/issue1739468 8 make msi work the vs 2005(MSVC8) 3 days closed http://bugs.python.org/issue1449 7 Python does not honor "CFLAGS" environment variable 0 days closed http://bugs.python.org/issue1453 7 pth files not loaded at startup 4 days closed http://bugs.python.org/issue1431 7 pdb bug with "with" statement 33 days closed http://bugs.python.org/issue1265 6 VS2008, quick hack for distutils.msvccompiler 2 days open http://bugs.python.org/issue1455 From status at bugs.python.org Tue Nov 20 19:06:10 2007 From: status at bugs.python.org (Tracker) Date: Tue, 20 Nov 2007 18:06:10 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071120180610.1C3E378357@psf.upfronthosting.co.za> ACTIVITY SUMMARY (11/13/07 - 11/20/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1328 open (+20) / 11630 closed (+18) / 12958 total (+38) Open issues with patches: 419 Average duration of open issues: 692 days. Median duration of open issues: 805 days. Open Issues Breakdown open 1322 (+19) pending 6 ( +1) Issues Created Or Reopened (39) _______________________________ Calling base class methods is slow due to __instancecheck__ over 11/13/07 http://bugs.python.org/issue1438 created gvanrossum py3k proposed 3000 patch for socket.py - "socket GC worries" 11/13/07 CLOSED http://bugs.python.org/issue1439 created janssen py3k, patch Checks for PySys_GetObject("std???") == Py_None 11/14/07 CLOSED http://bugs.python.org/issue1440 created tiran py3k, patch Cycles through ob_type aren't freed 11/14/07 http://bugs.python.org/issue1441 created rhamphoryncus pythonstartup addition of minor error checking 11/14/07 http://bugs.python.org/issue1442 created JosephArmbruster patch Magic class member variable initialization with lists 11/14/07 CLOSED http://bugs.python.org/issue1443 created neoone utf_8_sig streamreader bug, patch, and test 11/15/07 CLOSED http://bugs.python.org/issue1444 created jgsack patch SystemError accessing uninitialised cell contents 11/15/07 http://bugs.python.org/issue1445 created duncanb Link to call me for free 11/15/07 CLOSED http://bugs.python.org/issue1446 created gopiyadav26 patch to make msvccompiler.py work with vs 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1447 created weck patch Build Python with VS 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1448 created weck patch make msi work the vs 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1449 created weck patch make modulator more general 11/15/07 http://bugs.python.org/issue1450 created weck patch SSL patch for Python 3000 11/15/07 CLOSED http://bugs.python.org/issue1451 created janssen py3k, patch subprocess's popen.stdout.seek(0) doesn't raise an error 11/16/07 http://bugs.python.org/issue1452 created tiran py3k Python does not honor "CFLAGS" environment variable 11/16/07 CLOSED http://bugs.python.org/issue1453 created tebeka Generators break trace functionality 11/17/07 CLOSED http://bugs.python.org/issue1454 created cortesi VS2008, quick hack for distutils.msvccompiler 11/17/07 http://bugs.python.org/issue1455 created tiran py3k, patch unexpected iterator behavior with removal 11/18/07 CLOSED http://bugs.python.org/issue1456 created JosephArmbruster IDLE - configDialog - new layout for key config 11/18/07 http://bugs.python.org/issue1457 created taleinat installer crashes on attempted cancellation 11/18/07 http://bugs.python.org/issue1458 created JosephArmbruster Bugs lost on migration from Sourceforge 11/18/07 CLOSED http://bugs.python.org/issue1459 created gagenellina codecs utf7 decoding error 11/19/07 http://bugs.python.org/issue1460 created arnimar 0**0 should raise an error 11/19/07 CLOSED http://bugs.python.org/issue1461 created jmgillet About this document refers to SourceForge tracker 11/19/07 CLOSED http://bugs.python.org/issue1462 created kjohnson Minor error in mimetypes docs 11/19/07 CLOSED http://bugs.python.org/issue1463 created kjohnson inet_pton redefined while building with windows SDK 6.0 11/19/07 http://bugs.python.org/issue1464 created weck py3k, patch building python 2.6 with VC Express 2008 Beta2 11/19/07 http://bugs.python.org/issue1465 created weck patch Special reporting of NotImplementedError in unittest 11/19/07 CLOSED http://bugs.python.org/issue1466 created erik_andersen error in TestResult.addError and TestResult.addFailure 11/19/07 http://bugs.python.org/issue1467 created draghuram MSI installer does not include SSL test .pem files 11/19/07 http://bugs.python.org/issue1468 created pmoore SSL tests leak memory 11/19/07 http://bugs.python.org/issue1469 created janssen py3k py3k unit tests are removing %TEMP% dir on Windows 11/20/07 CLOSED http://bugs.python.org/issue1470 created tiran py3k ioctl doesn't work properly on 64-bit OpenBSD 11/20/07 http://bugs.python.org/issue1471 created fbvortex Small bat files to build docs on Windows 11/20/07 http://bugs.python.org/issue1472 created tiran py3k, patch Drop _EXPORTS macros in PCbuild9 11/20/07 http://bugs.python.org/issue1473 created loewis py3k PCbuild9 patch for trunk 11/20/07 http://bugs.python.org/issue1474 created tiran patch test_popen fails when the directory contains a space 11/20/07 http://bugs.python.org/issue1475 created tiran py3k Add a -z interpreter flag to execute a zip file 11/19/07 CLOSED http://bugs.python.org/issue1739468 reopened ncoghlan patch Issues Now Closed (36) ______________________ Parsing a simple script eats all of your memory 68 days http://bugs.python.org/issue1134 amaury.forgeotdarc py3k, patch parsermodule validation out of sync with Grammar 65 days http://bugs.python.org/issue1144 gvanrossum patch os.system() encoding bug on Windows 57 days http://bugs.python.org/issue1193 amaury.forgeotdarc py3k string find and rfind methods give a TypeError that is misleadin 37 days http://bugs.python.org/issue1259 facundobatista PCBuild8 Solution Support Changes 27 days http://bugs.python.org/issue1320 tiran windows installer problem 20 days http://bugs.python.org/issue1354 loewis fromfd() and dup() for _socket on WIndows 12 days http://bugs.python.org/issue1378 gvanrossum patch py3k: duplicated line endings when using read(1) 14 days http://bugs.python.org/issue1395 amaury.forgeotdarc py3k Weakref not working properly 5 days http://bugs.python.org/issue1417 MHOOO pth files not loaded at startup 4 days http://bugs.python.org/issue1431 brett.cannon patch marshal roundtripping for unicode 3 days http://bugs.python.org/issue1433 lemburg Support for multiple handlers for the "with" statement 0 days http://bugs.python.org/issue1435 gvanrossum logging.config.fileConfig, NameError: name 'RotatingFileHandler' 7 days http://bugs.python.org/issue1436 sebastian proposed 3000 patch for socket.py - "socket GC worries" 1 days http://bugs.python.org/issue1439 janssen py3k, patch Checks for PySys_GetObject("std???") == Py_None 1 days http://bugs.python.org/issue1440 tiran py3k, patch Magic class member variable initialization with lists 0 days http://bugs.python.org/issue1443 gvanrossum utf_8_sig streamreader bug, patch, and test 4 days http://bugs.python.org/issue1444 doerwalter patch Link to call me for free 0 days http://bugs.python.org/issue1446 georg.brandl patch to make msvccompiler.py work with vs 2005(MSVC8) 0 days http://bugs.python.org/issue1447 loewis patch Build Python with VS 2005(MSVC8) 0 days http://bugs.python.org/issue1448 loewis patch make msi work the vs 2005(MSVC8) 3 days http://bugs.python.org/issue1449 tiran patch SSL patch for Python 3000 0 days http://bugs.python.org/issue1451 janssen py3k, patch Python does not honor "CFLAGS" environment variable 0 days http://bugs.python.org/issue1453 loewis Generators break trace functionality 1 days http://bugs.python.org/issue1454 gvanrossum unexpected iterator behavior with removal 0 days http://bugs.python.org/issue1456 tiran Bugs lost on migration from Sourceforge 0 days http://bugs.python.org/issue1459 brett.cannon 0**0 should raise an error 0 days http://bugs.python.org/issue1461 gvanrossum About this document refers to SourceForge tracker 0 days http://bugs.python.org/issue1462 brett.cannon Minor error in mimetypes docs 0 days http://bugs.python.org/issue1463 facundobatista Special reporting of NotImplementedError in unittest 0 days http://bugs.python.org/issue1466 erik_andersen py3k unit tests are removing %TEMP% dir on Windows 0 days http://bugs.python.org/issue1470 tiran py3k C3 MRO algorithm implementation 1865 days http://bugs.python.org/issue619475 gvanrossum patch Use correct encoding for printing SyntaxErrors 1151 days http://bugs.python.org/issue1031213 gvanrossum patch recursive __getattr__ in thread crashes 641 days http://bugs.python.org/issue1430436 brett.cannon Remove backslash escapes from tokenize.c. 183 days http://bugs.python.org/issue1720390 gvanrossum py3k, patch Add a -z interpreter flag to execute a zip file 0 days http://bugs.python.org/issue1739468 gvanrossum patch Top Issues Most Discussed (10) ______________________________ 26 fromfd() and dup() for _socket on WIndows 12 days closed http://bugs.python.org/issue1378 9 Add a -z interpreter flag to execute a zip file 0 days closed http://bugs.python.org/issue1739468 9 SSL patch for Python 3000 0 days closed http://bugs.python.org/issue1451 9 Parsing a simple script eats all of your memory 68 days closed http://bugs.python.org/issue1134 8 Special reporting of NotImplementedError in unittest 0 days closed http://bugs.python.org/issue1466 8 VS2008, quick hack for distutils.msvccompiler 3 days open http://bugs.python.org/issue1455 8 make msi work the vs 2005(MSVC8) 3 days closed http://bugs.python.org/issue1449 7 Python does not honor "CFLAGS" environment variable 0 days closed http://bugs.python.org/issue1453 6 building python 2.6 with VC Express 2008 Beta2 1 days open http://bugs.python.org/issue1465 5 Checks for PySys_GetObject("std???") == Py_None 1 days closed http://bugs.python.org/issue1440 From mail5159 at gmail.com Wed Nov 21 15:02:40 2007 From: mail5159 at gmail.com (cave girl) Date: Wed, 21 Nov 2007 19:32:40 +0530 Subject: [Python-Dev] interested in google intership.. Message-ID: <91c7eda80711210602r64f0c835s69c6ffd28198908d@mail.gmail.com> Sir, I am a computer science student studying in India. I have maintained a good academic record throughtout my engineering. I would like to associate myself with GOOGLE. I will be glad if you let me know how to apply for GOOGLE INTERSHIP.. given a chance i would prove to be an asset to your firm.Yourhelp might provide a new dimension to my career. Please help. Thank you -- SILKY SINGH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20071121/d8da253f/attachment.htm From brett at python.org Wed Nov 21 18:52:25 2007 From: brett at python.org (Brett Cannon) Date: Wed, 21 Nov 2007 09:52:25 -0800 Subject: [Python-Dev] interested in google intership.. In-Reply-To: <91c7eda80711210602r64f0c835s69c6ffd28198908d@mail.gmail.com> References: <91c7eda80711210602r64f0c835s69c6ffd28198908d@mail.gmail.com> Message-ID: On Nov 21, 2007 6:02 AM, cave girl wrote: > Sir, > I am a computer science student studying in India. I have maintained a good > academic record throughtout my engineering. I would like to associate myself > with GOOGLE. I will be glad if you let me know how to apply for GOOGLE > INTERSHIP.. given a chance i would prove to be an asset to your firm.Your > help might provide a new dimension to my career. Please help. > Thank you This mailing list is for the Python programming language, not Google. You can use Google to search for the proper page on Google's web site: http://www.google.com/support/jobs/bin/static.py?page=students.html&sid=intern . -Brett From status at bugs.python.org Wed Nov 21 19:06:08 2007 From: status at bugs.python.org (Tracker) Date: Wed, 21 Nov 2007 18:06:08 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071121180608.3EF4778357@psf.upfronthosting.co.za> ACTIVITY SUMMARY (11/14/07 - 11/21/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1328 open (+20) / 11638 closed (+21) / 12966 total (+41) Open issues with patches: 418 Average duration of open issues: 693 days. Median duration of open issues: 806 days. Open Issues Breakdown open 1322 (+19) pending 6 ( +1) Issues Created Or Reopened (42) _______________________________ Magic class member variable initialization with lists 11/14/07 CLOSED http://bugs.python.org/issue1443 created neoone utf_8_sig streamreader bug, patch, and test 11/15/07 CLOSED http://bugs.python.org/issue1444 created jgsack patch SystemError accessing uninitialised cell contents 11/15/07 http://bugs.python.org/issue1445 created duncanb Link to call me for free 11/15/07 CLOSED http://bugs.python.org/issue1446 created gopiyadav26 patch to make msvccompiler.py work with vs 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1447 created weck patch Build Python with VS 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1448 created weck patch make msi work the vs 2005(MSVC8) 11/15/07 CLOSED http://bugs.python.org/issue1449 created weck patch make modulator more general 11/15/07 http://bugs.python.org/issue1450 created weck patch SSL patch for Python 3000 11/15/07 CLOSED http://bugs.python.org/issue1451 created janssen py3k, patch subprocess's popen.stdout.seek(0) doesn't raise an error 11/16/07 http://bugs.python.org/issue1452 created tiran py3k Python does not honor "CFLAGS" environment variable 11/16/07 CLOSED http://bugs.python.org/issue1453 created tebeka Generators break trace functionality 11/17/07 CLOSED http://bugs.python.org/issue1454 created cortesi VS2008, quick hack for distutils.msvccompiler 11/17/07 http://bugs.python.org/issue1455 created tiran py3k, patch unexpected iterator behavior with removal 11/18/07 CLOSED http://bugs.python.org/issue1456 created JosephArmbruster IDLE - configDialog - new layout for key config 11/18/07 http://bugs.python.org/issue1457 created taleinat installer crashes on attempted cancellation 11/18/07 http://bugs.python.org/issue1458 created JosephArmbruster Bugs lost on migration from Sourceforge 11/18/07 CLOSED http://bugs.python.org/issue1459 created gagenellina codecs utf7 decoding error 11/19/07 CLOSED http://bugs.python.org/issue1460 created arnimar 0**0 should raise an error 11/19/07 CLOSED http://bugs.python.org/issue1461 created jmgillet About this document refers to SourceForge tracker 11/19/07 CLOSED http://bugs.python.org/issue1462 created kjohnson Minor error in mimetypes docs 11/19/07 CLOSED http://bugs.python.org/issue1463 created kjohnson inet_pton redefined while building with windows SDK 6.0 11/19/07 CLOSED http://bugs.python.org/issue1464 created weck py3k, patch building python 2.6 with VC Express 2008 Beta2 11/19/07 http://bugs.python.org/issue1465 created weck patch Special reporting of NotImplementedError in unittest 11/19/07 CLOSED http://bugs.python.org/issue1466 created erik_andersen error in TestResult.addError and TestResult.addFailure 11/19/07 http://bugs.python.org/issue1467 created draghuram MSI installer does not include SSL test .pem files 11/19/07 http://bugs.python.org/issue1468 created pmoore SSL tests leak memory 11/19/07 http://bugs.python.org/issue1469 created janssen py3k py3k unit tests are removing %TEMP% dir on Windows 11/20/07 CLOSED http://bugs.python.org/issue1470 created tiran py3k ioctl doesn't work properly on 64-bit OpenBSD 11/20/07 http://bugs.python.org/issue1471 created fbvortex Small bat files to build docs on Windows 11/20/07 http://bugs.python.org/issue1472 created tiran py3k, patch Drop _EXPORTS macros in PCbuild9 11/20/07 CLOSED http://bugs.python.org/issue1473 created loewis py3k PCbuild9 patch for trunk 11/20/07 http://bugs.python.org/issue1474 created tiran patch test_popen fails when the directory contains a space 11/20/07 http://bugs.python.org/issue1475 created tiran py3k missing debug configuration for make_versioninfo.vcproj 11/20/07 CLOSED http://bugs.python.org/issue1476 created JosephArmbruster UnicodeDecodeError that cannot be caught in narrow unicode build 11/20/07 http://bugs.python.org/issue1477 created sbp pythoncore.vcproj fails to generate buildinfo (when spaces in pa 11/21/07 CLOSED http://bugs.python.org/issue1478 created JosephArmbruster py3k, patch csv module is leaking references 11/21/07 http://bugs.python.org/issue1479 created tiran py3k sqlite module is leaking lots of references 11/21/07 http://bugs.python.org/issue1480 created tiran py3k test_uuid is warning about unreliable functions 11/21/07 http://bugs.python.org/issue1481 created tiran py3k IMAP4 SSL isn't working 11/21/07 http://bugs.python.org/issue1482 created tiran py3k xml.sax.saxutils.prepare_input_source ignores character stream i 11/21/07 http://bugs.python.org/issue1483 created ygale Add a -z interpreter flag to execute a zip file 11/19/07 CLOSED http://bugs.python.org/issue1739468 reopened ncoghlan patch Issues Now Closed (43) ______________________ pyexpat.XMParserType broken (was: pydoc doesn't work on pyexpat) 87 days http://bugs.python.org/issue1020 tiran py3k Parsing a simple script eats all of your memory 68 days http://bugs.python.org/issue1134 amaury.forgeotdarc py3k, patch parsermodule validation out of sync with Grammar 65 days http://bugs.python.org/issue1144 gvanrossum patch os.system() encoding bug on Windows 57 days http://bugs.python.org/issue1193 amaury.forgeotdarc py3k string find and rfind methods give a TypeError that is misleadin 37 days http://bugs.python.org/issue1259 facundobatista PCBuild8 Solution Support Changes 27 days http://bugs.python.org/issue1320 tiran windows installer problem 20 days http://bugs.python.org/issue1354 loewis zlibmodule.c: int overflow in PyZlib_decompress 19 days http://bugs.python.org/issue1372 tiran patch, 64bit fromfd() and dup() for _socket on WIndows 12 days http://bugs.python.org/issue1378 gvanrossum patch py3k: duplicated line endings when using read(1) 14 days http://bugs.python.org/issue1395 amaury.forgeotdarc py3k py_compile and compileall need unit tests 13 days http://bugs.python.org/issue1403 tiran py3k Weakref not working properly 5 days http://bugs.python.org/issue1417 MHOOO pth files not loaded at startup 4 days http://bugs.python.org/issue1431 brett.cannon patch marshal roundtripping for unicode 3 days http://bugs.python.org/issue1433 lemburg logging.config.fileConfig, NameError: name 'RotatingFileHandler' 7 days http://bugs.python.org/issue1436 vsajip proposed 3000 patch for socket.py - "socket GC worries" 1 days http://bugs.python.org/issue1439 janssen py3k, patch Checks for PySys_GetObject("std???") == Py_None 1 days http://bugs.python.org/issue1440 tiran py3k, patch Magic class member variable initialization with lists 0 days http://bugs.python.org/issue1443 gvanrossum utf_8_sig streamreader bug, patch, and test 4 days http://bugs.python.org/issue1444 doerwalter patch Link to call me for free 0 days http://bugs.python.org/issue1446 georg.brandl patch to make msvccompiler.py work with vs 2005(MSVC8) 0 days http://bugs.python.org/issue1447 loewis patch Build Python with VS 2005(MSVC8) 0 days http://bugs.python.org/issue1448 loewis patch make msi work the vs 2005(MSVC8) 3 days http://bugs.python.org/issue1449 tiran patch SSL patch for Python 3000 0 days http://bugs.python.org/issue1451 janssen py3k, patch Python does not honor "CFLAGS" environment variable 0 days http://bugs.python.org/issue1453 loewis Generators break trace functionality 1 days http://bugs.python.org/issue1454 gvanrossum unexpected iterator behavior with removal 0 days http://bugs.python.org/issue1456 tiran Bugs lost on migration from Sourceforge 0 days http://bugs.python.org/issue1459 brett.cannon codecs utf7 decoding error 2 days http://bugs.python.org/issue1460 amaury.forgeotdarc 0**0 should raise an error 0 days http://bugs.python.org/issue1461 gvanrossum About this document refers to SourceForge tracker 0 days http://bugs.python.org/issue1462 brett.cannon Minor error in mimetypes docs 0 days http://bugs.python.org/issue1463 facundobatista inet_pton redefined while building with windows SDK 6.0 1 days http://bugs.python.org/issue1464 tiran py3k, patch Special reporting of NotImplementedError in unittest 0 days http://bugs.python.org/issue1466 erik_andersen py3k unit tests are removing %TEMP% dir on Windows 0 days http://bugs.python.org/issue1470 tiran py3k Drop _EXPORTS macros in PCbuild9 1 days http://bugs.python.org/issue1473 tiran py3k missing debug configuration for make_versioninfo.vcproj 0 days http://bugs.python.org/issue1476 tiran pythoncore.vcproj fails to generate buildinfo (when spaces in pa 0 days http://bugs.python.org/issue1478 tiran py3k, patch C3 MRO algorithm implementation 1865 days http://bugs.python.org/issue619475 gvanrossum patch Use correct encoding for printing SyntaxErrors 1151 days http://bugs.python.org/issue1031213 gvanrossum patch recursive __getattr__ in thread crashes 641 days http://bugs.python.org/issue1430436 brett.cannon Remove backslash escapes from tokenize.c. 183 days http://bugs.python.org/issue1720390 gvanrossum py3k, patch Add a -z interpreter flag to execute a zip file 0 days http://bugs.python.org/issue1739468 gvanrossum patch Top Issues Most Discussed (10) ______________________________ 26 fromfd() and dup() for _socket on WIndows 12 days closed http://bugs.python.org/issue1378 9 Add a -z interpreter flag to execute a zip file 0 days closed http://bugs.python.org/issue1739468 9 VS2008, quick hack for distutils.msvccompiler 4 days open http://bugs.python.org/issue1455 9 SSL patch for Python 3000 0 days closed http://bugs.python.org/issue1451 8 Special reporting of NotImplementedError in unittest 0 days closed http://bugs.python.org/issue1466 8 make msi work the vs 2005(MSVC8) 3 days closed http://bugs.python.org/issue1449 7 Python does not honor "CFLAGS" environment variable 0 days closed http://bugs.python.org/issue1453 6 building python 2.6 with VC Express 2008 Beta2 2 days open http://bugs.python.org/issue1465 5 test_popen fails when the directory contains a space 1 days open http://bugs.python.org/issue1475 5 proposed 3000 patch for socket.py - "socket GC worries" 1 days closed http://bugs.python.org/issue1439 From p.f.moore at gmail.com Wed Nov 21 23:58:00 2007 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 21 Nov 2007 22:58:00 +0000 Subject: [Python-Dev] Tracker summary emails Message-ID: <79990c6b0711211458h785172bdxef07d7d6d620a4dd@mail.gmail.com> Is it only me who thinks that the current daily summaries are a bit frequent? Would it be possible to reduce the frequency to, say, once a week? I can set up a filter to simply ditch the things, but I thought I'd check what other people's views are before I did. Paul. From guido at python.org Thu Nov 22 00:18:47 2007 From: guido at python.org (Guido van Rossum) Date: Wed, 21 Nov 2007 15:18:47 -0800 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? Message-ID: I'm asking a Py3k question on python-dev because I'd like to have opinions from people who haven't thought about Py3k much yet. Consider the following example: class C: def foo(self): pass C.foo(42) This currently fails with this error message: TypeError: unbound method foo() must be called with C instance as first argument (got int instance instead) This message is called when isinstance(self, C) returns False, where self is the first argument passed to the unbound method. That's nice, but there is a cost associated with this: the expression "C.foo" can't just return the function object "foo", it has to wrap it in an unbound method object. In Py3k the cost of calling an unbound method object goes up, because the isinstance() check may be overloaded. This typically happens when the class C uses the special metaclass (abc.ABCMeta) used for virtual inheritance (see PEP 3119). in Py3k the I/O stream classes are perhaps the most common use case. Given that the error is of limited value and that otherwise the unbound method behaves exactly the same as the original function object, I'd like to see if there are strenuous objections against dropping unbound method objects altogether (or at least not using them in this case), so that explicit super calls (via the unbound method) may go a little faster. Also, it would make it easier to fix this issue: http://bugs.python.org/issue1109 To illustrate the cost of the isinstance() overloading, step through this simple program with Py3k: import abc, pdb class Base(metaclass=abc.ABCMeta): @abc.abstractmethod def foo(self): pass class C(Base): def foo(self): Base.foo(self) c = C() pdb.run("c.foo()") -- --Guido van Rossum (home page: http://www.python.org/~guido/) From martin at v.loewis.de Thu Nov 22 00:21:40 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Thu, 22 Nov 2007 00:21:40 +0100 Subject: [Python-Dev] Tracker summary emails In-Reply-To: <79990c6b0711211458h785172bdxef07d7d6d620a4dd@mail.gmail.com> References: <79990c6b0711211458h785172bdxef07d7d6d620a4dd@mail.gmail.com> Message-ID: <4744BD84.6010908@v.loewis.de> > Is it only me who thinks that the current daily summaries are a bit > frequent? Would it be possible to reduce the frequency to, say, once a > week? Only if the person in charge of it changes the cron job. Feel free to submit a bug report at http://psf.upfronthosting.co.za/roundup/meta (I thought there was one already, but I can't find it right now). Help in administrating the roundup installation is urgently desired; there is currently no active maintenance of this site (which makes me wonder whether we should have used Jira instead of roundup, as the company offering it had also offered hosting and active maintenance) FWIW, help in adminstration is desired for *all* hosts on *.python.org (web, mailing lists, PyPI, ...) Regards, Martin From facundobatista at gmail.com Thu Nov 22 00:35:50 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Wed, 21 Nov 2007 20:35:50 -0300 Subject: [Python-Dev] Tracker summary emails In-Reply-To: <4744BD84.6010908@v.loewis.de> References: <79990c6b0711211458h785172bdxef07d7d6d620a4dd@mail.gmail.com> <4744BD84.6010908@v.loewis.de> Message-ID: 2007/11/21, "Martin v. L?wis" : > Help in administrating the roundup installation is urgently desired; > there is currently no active maintenance of this site (which makes me > wonder whether we should have used Jira instead of roundup, as the > company offering it had also offered hosting and active maintenance) > > FWIW, help in adminstration is desired for *all* hosts on *.python.org > (web, mailing lists, PyPI, ...) Is somewhere the description of these hosts? Are they debian, solaris, or what? Which web server do they have? Etc. This way, we can search for help in our sysadmins friends. Better: if you have a description, I'd post a request for help in the Python Argentina list. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From foom at fuhm.net Thu Nov 22 00:02:43 2007 From: foom at fuhm.net (James Y Knight) Date: Wed, 21 Nov 2007 18:02:43 -0500 Subject: [Python-Dev] Tracker summary emails In-Reply-To: <79990c6b0711211458h785172bdxef07d7d6d620a4dd@mail.gmail.com> References: <79990c6b0711211458h785172bdxef07d7d6d620a4dd@mail.gmail.com> Message-ID: <700B645A-0F04-482B-8E85-0E1A2DF06B4C@fuhm.net> On Nov 21, 2007, at 5:58 PM, Paul Moore wrote: > Is it only me who thinks that the current daily summaries are a bit > frequent? Would it be possible to reduce the frequency to, say, once a > week? > > I can set up a filter to simply ditch the things, but I thought I'd > check what other people's views are before I did. Not only are they once a day, but every day's report contains the preceeding 7 days worth of changes. I had assumed it was just a bug in the script, since it seems utterly useless. James From fuzzyman at voidspace.org.uk Thu Nov 22 00:33:21 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 21 Nov 2007 23:33:21 +0000 Subject: [Python-Dev] [python] Should we do away with unbound methods in Py3k? In-Reply-To: References: Message-ID: <4744C041.2030100@voidspace.org.uk> Guido van Rossum wrote: > I'm asking a Py3k question on python-dev because I'd like to have > opinions from people who haven't thought about Py3k much yet. Consider > the following example: > > class C: > def foo(self): pass > > C.foo(42) > > This currently fails with this error message: > > TypeError: unbound method foo() must be called with C instance as > first argument (got int instance instead) > > This message is called when isinstance(self, C) returns False, where > self is the first argument passed to the unbound method. > > That's nice, but there is a cost associated with this: the expression > "C.foo" can't just return the function object "foo", it has to wrap it > in an unbound method object. In Py3k the cost of calling an unbound > method object goes up, because the isinstance() check may be > overloaded. This typically happens when the class C uses the special > metaclass (abc.ABCMeta) used for virtual inheritance (see PEP 3119). > in Py3k the I/O stream classes are perhaps the most common use case. > > Given that the error is of limited value and that otherwise the > unbound method behaves exactly the same as the original function > object, I'd like to see if there are strenuous objections against > dropping unbound method objects altogether (or at least not using them > in this case), so that explicit super calls (via the unbound method) > may go a little faster. Also, it would make it easier to fix this > issue: http://bugs.python.org/issue1109 > On occasions I've found it a drag that you *can't* call unbound methods with a different type. Python normally allows duck typing and this is one place it actually places type restrictions... I'd be happy to see this restriction go. :-) Michael Foord From p.f.moore at gmail.com Thu Nov 22 00:53:00 2007 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 21 Nov 2007 23:53:00 +0000 Subject: [Python-Dev] Tracker summary emails In-Reply-To: <4744BD84.6010908@v.loewis.de> References: <79990c6b0711211458h785172bdxef07d7d6d620a4dd@mail.gmail.com> <4744BD84.6010908@v.loewis.de> Message-ID: <79990c6b0711211553x5b860559s52b78c8ffde447ab@mail.gmail.com> On 21/11/2007, "Martin v. L?wis" wrote: > > Is it only me who thinks that the current daily summaries are a bit > > frequent? Would it be possible to reduce the frequency to, say, once a > > week? > > Only if the person in charge of it changes the cron job. Feel free to > submit a bug report at > > http://psf.upfronthosting.co.za/roundup/meta Done. Issue 168. Thanks for the pointer. Paul. From steven.bethard at gmail.com Thu Nov 22 01:25:52 2007 From: steven.bethard at gmail.com (Steven Bethard) Date: Wed, 21 Nov 2007 17:25:52 -0700 Subject: [Python-Dev] [python] Should we do away with unbound methods in Py3k? In-Reply-To: <4744C041.2030100@voidspace.org.uk> References: <4744C041.2030100@voidspace.org.uk> Message-ID: On Nov 21, 2007 4:33 PM, Michael Foord wrote: > Guido van Rossum wrote: > > I'm asking a Py3k question on python-dev because I'd like to have > > opinions from people who haven't thought about Py3k much yet. Consider > > the following example: > > > > class C: > > def foo(self): pass > > > > C.foo(42) > > > > This currently fails with this error message: > > > > TypeError: unbound method foo() must be called with C instance as > > first argument (got int instance instead) > > > > This message is called when isinstance(self, C) returns False, where > > self is the first argument passed to the unbound method. > > > > That's nice, but there is a cost associated with this: the expression > > "C.foo" can't just return the function object "foo", it has to wrap it > > in an unbound method object. In Py3k the cost of calling an unbound > > method object goes up, because the isinstance() check may be > > overloaded. This typically happens when the class C uses the special > > metaclass (abc.ABCMeta) used for virtual inheritance (see PEP 3119). > > in Py3k the I/O stream classes are perhaps the most common use case. > > > > Given that the error is of limited value and that otherwise the > > unbound method behaves exactly the same as the original function > > object, I'd like to see if there are strenuous objections against > > dropping unbound method objects altogether (or at least not using them > > in this case), so that explicit super calls (via the unbound method) > > may go a little faster. Also, it would make it easier to fix this > > issue: http://bugs.python.org/issue1109 > > > > On occasions I've found it a drag that you *can't* call unbound methods > with a different type. Python normally allows duck typing and this is > one place it actually places type restrictions... > > I'd be happy to see this restriction go. :-) I agree. Though I'd like to know what happens when I do something like:: >>> class C(object): ... def __setitem__(self, key, value): ... print key, value ... >>> c = C() >>> dict.update(c, foo='bar') Traceback (most recent call last): File "", line 1, in TypeError: descriptor 'update' requires a 'dict' object but received a 'C' I assume the code will fail (though it would be really cool if it didn't). How will it fail? STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy From amauryfa at gmail.com Thu Nov 22 01:41:28 2007 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Thu, 22 Nov 2007 01:41:28 +0100 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: References: Message-ID: Guido van Rossum wrote: > I'm asking a Py3k question on python-dev because I'd like to have > opinions from people who haven't thought about Py3k much yet. Consider > the following example: > > class C: > def foo(self): pass > > C.foo(42) > > This currently fails with this error message: > > TypeError: unbound method foo() must be called with C instance as > first argument (got int instance instead) > > This message is called when isinstance(self, C) returns False, where > self is the first argument passed to the unbound method. > > That's nice, but there is a cost associated with this: the expression > "C.foo" can't just return the function object "foo", it has to wrap it > in an unbound method object. In Py3k the cost of calling an unbound > method object goes up, because the isinstance() check may be > overloaded. This typically happens when the class C uses the special > metaclass (abc.ABCMeta) used for virtual inheritance (see PEP 3119). > in Py3k the I/O stream classes are perhaps the most common use case. Could we check for "real" inheritance first, and call __instancecheck__ only when the previous is false? It would speed-up the common cases. Or is there really a use case for a derived class to appear as NOT being a subclass of its base class? -- Amaury Forgeot d'Arc From pje at telecommunity.com Thu Nov 22 01:53:22 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 21 Nov 2007 19:53:22 -0500 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: References: Message-ID: <20071122005433.D95413A40AE@sparrow.telecommunity.com> At 01:41 AM 11/22/2007 +0100, Amaury Forgeot d'Arc wrote: >Could we check for "real" inheritance first, and call >__instancecheck__ only when the previous is false? It would speed-up >the common cases. +1. >Or is there really a use case for a derived class to appear as NOT >being a subclass of its base class? The only reason to do this would be to work around badly written code, but IMO the cure is worse than the disease at that point. The lookup sequence should probably be something like: 1. type(ob) is cls 2. issubclass(type(ob), cls) 3. ob.__class__ is cls 4. issubclass(ob.__class__, cls) 5. ob.__instancecheck__(cls) Where issubclass() checks __mro__ before calling the subclass check method, and #3 and #4 can be skipped if ob.__class__ is type(ob). From tjreedy at udel.edu Thu Nov 22 01:58:37 2007 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 21 Nov 2007 19:58:37 -0500 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? References: Message-ID: If I understand correctly, this would negate the need for staticmethod() when accessing the function via the class (and not instances) since the main effect of that is to prevent the wrapping. (And since I consider instance.somestaticmeth() as even less idiomatic Python that class.somestaticmeth(), I should think staticmethod then could go also.) This change would certainly reinforce the idea that in Python, methods are just functions with a special access. It might quiet the calls for 'implicit' self. It would make Python slightly easier to learn, I think, since the reason for unbound method wrapping is not obvious. From what you said, it is a sacrifice of speed for safety. But this is the only place I can think of where an argument type-check is automatically applied to user-written functions. So, +whatever from me for making Python slightly simpler. tjr From greg.ewing at canterbury.ac.nz Thu Nov 22 03:48:12 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 22 Nov 2007 15:48:12 +1300 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: <20071122005433.D95413A40AE@sparrow.telecommunity.com> References: <20071122005433.D95413A40AE@sparrow.telecommunity.com> Message-ID: <4744EDEC.8020102@canterbury.ac.nz> Phillip J. Eby wrote: > The lookup sequence should probably be something like: > > 1. type(ob) is cls > 2. issubclass(type(ob), cls) But can't issubclass be overridden as well? -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing at canterbury.ac.nz +--------------------------------------+ From greg.ewing at canterbury.ac.nz Thu Nov 22 03:51:55 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 22 Nov 2007 15:51:55 +1300 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: References: Message-ID: <4744EECB.9020905@canterbury.ac.nz> Guido van Rossum wrote: > Given that the error is of limited value and that otherwise the > unbound method behaves exactly the same as the original function > object, I'd like to see if there are strenuous objections against > dropping unbound method objects altogether (or at least not using them > in this case) Fine by me. I've always thought they were of dubious value in the first place. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing at canterbury.ac.nz +--------------------------------------+ From guido at python.org Thu Nov 22 04:15:10 2007 From: guido at python.org (Guido van Rossum) Date: Wed, 21 Nov 2007 19:15:10 -0800 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: References: Message-ID: On Nov 21, 2007 4:58 PM, Terry Reedy wrote: > If I understand correctly, this would negate the need for staticmethod() > when accessing the function via the class (and not instances) since the > main effect of that is to prevent the wrapping. (And since I consider > instance.somestaticmeth() as even less idiomatic Python that > class.somestaticmeth(), I should think staticmethod then could go also.) Not quite. You can evolve an API from an instancemethod into a staticmethod without changing the call sites. Also (unlike Java or C++) you can override a staticmethod, and self.somestaticmeth() will look it up in self.__class__. > This change would certainly reinforce the idea that in Python, methods are > just functions with a special access. It might quiet the calls for > 'implicit' self. Doubt it. :-) > It would make Python slightly easier to learn, I think, since the reason > for unbound method wrapping is not obvious. From what you said, it is a > sacrifice of speed for safety. But this is the only place I can think of > where an argument type-check is automatically applied to user-written > functions. I think historically we didn't always have unbound methods; I believe I introduced them (in the 1.x days I think) to catch what was mostly a hypothetical error case. > So, +whatever from me for making Python slightly simpler. Thanks. I like this better than changing the definition of isinstance(). -- --Guido van Rossum (home page: http://www.python.org/~guido/) From pje at telecommunity.com Thu Nov 22 04:15:03 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 21 Nov 2007 22:15:03 -0500 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: <4744EDEC.8020102@canterbury.ac.nz> References: <20071122005433.D95413A40AE@sparrow.telecommunity.com> <4744EDEC.8020102@canterbury.ac.nz> Message-ID: <20071122031511.E59ED3A40AE@sparrow.telecommunity.com> At 03:48 PM 11/22/2007 +1300, Greg Ewing wrote: >Phillip J. Eby wrote: > > The lookup sequence should probably be something like: > > > > 1. type(ob) is cls > > 2. issubclass(type(ob), cls) > >But can't issubclass be overridden as well? Yes, which is why I spelled it that way, and mentioned that 'issubclass()' should check class identity and __mro__ before falling through to the special method check. From guido at python.org Thu Nov 22 04:16:27 2007 From: guido at python.org (Guido van Rossum) Date: Wed, 21 Nov 2007 19:16:27 -0800 Subject: [Python-Dev] [python] Should we do away with unbound methods in Py3k? In-Reply-To: References: <4744C041.2030100@voidspace.org.uk> Message-ID: On Nov 21, 2007 4:25 PM, Steven Bethard wrote: > Though I'd like to know what happens when I do something like:: > > >>> class C(object): > ... def __setitem__(self, key, value): > ... print key, value > ... > >>> c = C() > >>> dict.update(c, foo='bar') > Traceback (most recent call last): > File "", line 1, in > TypeError: descriptor 'update' requires a 'dict' object but received a 'C' > > I assume the code will fail (though it would be really cool if it > didn't). How will it fail? I expect it won't change -- built-in types use a different mechanism. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From martin at v.loewis.de Thu Nov 22 06:53:53 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Thu, 22 Nov 2007 06:53:53 +0100 Subject: [Python-Dev] Tracker summary emails In-Reply-To: References: <79990c6b0711211458h785172bdxef07d7d6d620a4dd@mail.gmail.com> <4744BD84.6010908@v.loewis.de> Message-ID: <47451971.5020207@v.loewis.de> > Is somewhere the description of these hosts? Not that I know of; you'll have to ask. > Are they debian, solaris, > or what? Which web server do they have? Etc. They are mostly Debian systems, with Apache, and other debian packages installed. I don't know what bugs.python.org runs, but I believe it's Linux also. Regards, Martin From ronaldoussoren at mac.com Thu Nov 22 11:57:20 2007 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 22 Nov 2007 11:57:20 +0100 Subject: [Python-Dev] A crash during interpreter cleanup when using PyGILState APIs Message-ID: An extension module I use makes extensive use of the PyGILState API's in callback functions for C APIs. Some of the functions that use the PyGILState APIs are used in the tp_dealloc of methods. This seems cause problems when objects are cleaned up during interpreter shutdown: when an object is deallocated during PyInterpreterState_Clear I get a hard crash because the GILState machinery has been shut down at that time :-( The bug report for this: http://bugs.python.org/issue1402 The report includes a patch, but I know just enough about the python threading infrastructure to be dangerous and am not convinced that the patch is actually correct. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available Url : http://mail.python.org/pipermail/python-dev/attachments/20071122/bc28c457/attachment.bin From ncoghlan at gmail.com Thu Nov 22 12:27:03 2007 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 22 Nov 2007 21:27:03 +1000 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: References: Message-ID: <47456787.5070601@gmail.com> Guido van Rossum wrote: > Given that the error is of limited value and that otherwise the > unbound method behaves exactly the same as the original function > object, I'd like to see if there are strenuous objections against > dropping unbound method objects altogether (or at least not using them > in this case), so that explicit super calls (via the unbound method) > may go a little faster. Also, it would make it easier to fix this > issue: http://bugs.python.org/issue1109 Assuming the proposal is simply to change function.__get__ to return self when the second argument is None, then +1. The method descriptors for types written in C should continue to return a wrapper which performs the typecheck, as C method implementations tend to assume that the self argument is guaranteed to be of the correct type. Having to perform that check manually would be rather tedious. This does introduce a new discrepancy between types implemented in C and Python classes, but I suspect that the underlying difference in memory layout restrictions is always going to leak through in at least a few places. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From lists at cheimes.de Thu Nov 22 12:30:25 2007 From: lists at cheimes.de (Christian Heimes) Date: Thu, 22 Nov 2007 12:30:25 +0100 Subject: [Python-Dev] PCbuild9 for the trunk Message-ID: Just for your information: I've back-ported the PCbuild9 directory from py3k to the trunk. You now can build Python 2.6 and 3.0 with the new Visual Studio 2008. As far as I've heard from other it works with the free Express Edition. MSDN subscribers with the Standard or Professional version can also create PGO builds with the new directory. Preliminary tests are showing that PGO builds are roughly 10% faster than standard builds. Have fun! Christian From p.f.moore at gmail.com Thu Nov 22 13:53:25 2007 From: p.f.moore at gmail.com (Paul Moore) Date: Thu, 22 Nov 2007 12:53:25 +0000 Subject: [Python-Dev] Tracker summary emails In-Reply-To: <79990c6b0711211553x5b860559s52b78c8ffde447ab@mail.gmail.com> References: <79990c6b0711211458h785172bdxef07d7d6d620a4dd@mail.gmail.com> <4744BD84.6010908@v.loewis.de> <79990c6b0711211553x5b860559s52b78c8ffde447ab@mail.gmail.com> Message-ID: <79990c6b0711220453t6b45891ekcd3b06091ec44841@mail.gmail.com> On 21/11/2007, Paul Moore wrote: > On 21/11/2007, "Martin v. L?wis" wrote: > > > Is it only me who thinks that the current daily summaries are a bit > > > frequent? Would it be possible to reduce the frequency to, say, once a > > > week? > > > > Only if the person in charge of it changes the cron job. Feel free to > > submit a bug report at > > > > http://psf.upfronthosting.co.za/roundup/meta > > Done. Issue 168. Thanks for the pointer. That's been fixed now. Paul. From ncoghlan at gmail.com Thu Nov 22 15:45:39 2007 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 23 Nov 2007 00:45:39 +1000 Subject: [Python-Dev] Update to PEP 366 (Relative imports from the main module) Message-ID: <47459613.7060301@gmail.com> I've updated PEP 366 with a proposed implementation, as well as a few changes to the proposed semantics to make the implementation feasible (the old proposal called for imp.new_module to calculate a value when it didn't have access to all of the relevant information). The updated text is below, and should turn up on python.org before too long. Regards, Nick. -------------------------------------------- PEP: 366 Title: Main module explicit relative imports Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 1-May-2007 Python-Version: 2.6, 3.0 Post-History: 1-May-2007, 4-Jul-2007, 7-Jul-2007, 23-Nov-2007 Abstract ======== This PEP proposes a backwards compatible mechanism that permits the use of explicit relative imports from executable modules within packages. Such imports currently fail due to an awkward interaction between PEP 328 and PEP 338. By adding a new module level attribute, this PEP allows relative imports to work automatically if the module is executed using the ``-m`` switch. A small amount of boilerplate in the module itself will allow the relative imports to work when the file is executed by name. Proposed Change =============== The major proposed change is the introduction of a new module level attribute, ``__package__``. When it is present, relative imports will be based on this attribute rather than the module ``__name__`` attribute. As with the current ``__name__`` attribute, setting ``__package__`` will be the responsibility of the PEP 302 loader used to import a module. Loaders which use ``imp.new_module()`` to create the module object will have the new attribute set automatically to ``None``. When the import system encounters an explicit relative import in a module without ``__package__`` set (or with it set to ``None``), it will calculate and store the correct value (``__name__.rpartition('.')[0]`` for normal modules and ``__name__`` for package initialisation modules). If ``__package__`` has already been set then the import system will use it in preference to recalculating the package name from the ``__name__`` and ``__path__`` attributes. The ``runpy`` module will explicitly set the new attribute, basing it off the name used to locate the module to be executed rather than the name used to set the module's ``__name__`` attribute. This will allow relative imports to work correctly from main modules executed with the ``-m`` switch. When the main module is specified by its filename, then the ``__package__`` attribute will be set to ``None``. To allow relative imports when the module is executed directly, boilerplate similar to the following would be needed before the first relative import statement:: if __name__ == "__main__" and __package__ is None: __package__ = "expected.package.name" Note that this boilerplate is sufficient only if the top level package is already accessible via ``sys.path``. Additional code that manipulates ``sys.path`` would be needed in order for direct execution to work without the top level package already being importable. This approach also has the same disadvantage as the use of absolute imports of sibling modules - if the script is moved to a different package or subpackage, the boilerplate will need to be updated manually. It has the advantage that this change need only be made once per file, regardless of the number of relative imports. Rationale for Change ==================== The current inability to use explicit relative imports from the main module is the subject of at least one open SF bug report (#1510172) [1]_, and has most likely been a factor in at least a few queries on comp.lang.python (such as Alan Isaac's question in [2]_). This PEP is intended to provide a solution which permits explicit relative imports from main modules, without incurring any significant costs during interpreter startup or normal module import. The section in PEP 338 on relative imports and the main module provides further details and background on this problem. Reference Implementation ======================== Rev 47142 in SVN implemented an early variant of this proposal which stored the main module's real module name in the ``__module_name__`` attribute. It was reverted due to the fact that 2.5 was already in beta by that time. Patch 1487 [4] is the proposed implementation for this PEP. Alternative Proposals ===================== PEP 3122 proposed addressing this problem by changing the way the main module is identified. That's a significant compatibility cost to incur to fix something that is a pretty minor bug in the overall scheme of things, and the PEP was rejected [3]_. The advantage of the proposal in this PEP is that its only impact on normal code is the small amount of time needed to set the extra attribute when importing a module. Relative imports themselves should be sped up fractionally, as the package name is cached in the module globals, rather than having to be worked out again for each relative import. References ========== .. [1] Absolute/relative import not working? (http://www.python.org/sf/1510172) .. [2] c.l.p. question about modules and relative imports (http://groups.google.com/group/comp.lang.python/browse_thread/thread/c44c769a72ca69fa/) .. [3] Guido's rejection of PEP 3122 (http://mail.python.org/pipermail/python-3000/2007-April/006793.html) .. [4] PEP 366 implementation patch (http://bugs.python.org/issue1487) Copyright ========= This document has been placed in the public domain. From josepharmbruster at gmail.com Thu Nov 22 16:25:45 2007 From: josepharmbruster at gmail.com (Joseph Armbruster) Date: Thu, 22 Nov 2007 10:25:45 -0500 Subject: [Python-Dev] (no subject) In-Reply-To: References: Message-ID: <47459F79.2090001@gmail.com> Christian, When will the third party library versions be finalized for Py3k? For the time being I am building with: bzip2-1.0.3 db-4.4.20 openssl-0.9.8g sqlite-source-3.3.4 tcl8.4.12 tix-8.4.0 tk8.4.12 I had an slight issue with the PCbuild9 solution with OpenSSL, I will open a bug and submit a patch in a few. I have a few hours before turkey time :-) Good Day! Joseph Armbruster Christian Heimes wrote: > Just for your information: I've back-ported the PCbuild9 directory from > py3k to the trunk. You now can build Python 2.6 and 3.0 with the new > Visual Studio 2008. As far as I've heard from other it works with the > free Express Edition. > > MSDN subscribers with the Standard or Professional version can also > create PGO builds with the new directory. Preliminary tests are showing > that PGO builds are roughly 10% faster than standard builds. > > Have fun! > > Christian > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/josepharmbruster%40gmail.com > From lists at cheimes.de Thu Nov 22 16:53:20 2007 From: lists at cheimes.de (Christian Heimes) Date: Thu, 22 Nov 2007 16:53:20 +0100 Subject: [Python-Dev] PCbuild9 for the trunk In-Reply-To: <47459F79.2090001@gmail.com> References: <47459F79.2090001@gmail.com> Message-ID: <4745A5F0.8060309@cheimes.de> Joseph Armbruster wrote: > Christian, > > When will the third party library versions be finalized for Py3k? For the time > being I am building with: > > bzip2-1.0.3 > db-4.4.20 > openssl-0.9.8g > sqlite-source-3.3.4 > tcl8.4.12 > tix-8.4.0 > tk8.4.12 > > I had an slight issue with the PCbuild9 solution with OpenSSL, I will open a > bug and submit a patch in a few. I have a few hours before turkey time :-) The dependencies are going to be updated shortly before the next release. The owners of the build bots don't want to update the dependencies every time a new version comes out. For now I stick to the versions in our svn repository except of openssl. I had to update it to 0.9.8g because I had some trouble with it. Christian From greg.ewing at canterbury.ac.nz Fri Nov 23 01:14:44 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 23 Nov 2007 13:14:44 +1300 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: References: Message-ID: <47461B74.4050409@canterbury.ac.nz> Guido van Rossum wrote: > Not quite. You can evolve an API from an instancemethod into a > staticmethod without changing the call sites. But is there ever any need to do that, rather than leave it as an instance method? Personally it would never have occurred to me to do that. If you want to be able to override it in subclasses, to me that's an indication that it should be an instance method. Also, what happens if you perform such a migration and then some subclasser later finds that he wants access to 'self'? I don't see this as a use case worth supporting. -- Greg From pje at telecommunity.com Fri Nov 23 03:14:14 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 22 Nov 2007 21:14:14 -0500 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: <47461B74.4050409@canterbury.ac.nz> References: <47461B74.4050409@canterbury.ac.nz> Message-ID: <20071123021416.E68713A40AC@sparrow.telecommunity.com> At 01:14 PM 11/23/2007 +1300, Greg Ewing wrote: >Guido van Rossum wrote: > > Not quite. You can evolve an API from an instancemethod into a > > staticmethod without changing the call sites. > >But is there ever any need to do that, rather than leave >it as an instance method? Yes. :) See below. >Personally it would never have occurred to me to do that. >If you want to be able to override it in subclasses, to >me that's an indication that it should be an instance >method. Or a classmethod, or a staticmethod. The most common use case for this (in my experience) is when you need a converter function or some other sort of function that's configurable per-instance or per-subclass. If you are configuring it per-class and accessing it per-instance, and reusing an existing function, you have to make it a staticmethod. >Also, what happens if you perform such a migration and >then some subclasser later finds that he wants access to >'self'? Then he overrides it with a normal method. From guido at python.org Fri Nov 23 05:19:57 2007 From: guido at python.org (Guido van Rossum) Date: Thu, 22 Nov 2007 20:19:57 -0800 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: <20071123021416.E68713A40AC@sparrow.telecommunity.com> References: <47461B74.4050409@canterbury.ac.nz> <20071123021416.E68713A40AC@sparrow.telecommunity.com> Message-ID: It looks like we're in agreement to drop unbound methods and have a reasonable set or arguments around it (e.g. keep staticmethod, no changes to methods of builtin types, etc.). Do we need a PEP? It's essentially a 2-line change in funcobject.c (func_descr_get()) -- plus fixing up half a dozen or so unittests that specifically seem to test the behavior of unbound methods. --Guido On Nov 22, 2007 6:14 PM, Phillip J. Eby wrote: > At 01:14 PM 11/23/2007 +1300, Greg Ewing wrote: > >Guido van Rossum wrote: > > > Not quite. You can evolve an API from an instancemethod into a > > > staticmethod without changing the call sites. > > > >But is there ever any need to do that, rather than leave > >it as an instance method? > > Yes. :) See below. > > > >Personally it would never have occurred to me to do that. > >If you want to be able to override it in subclasses, to > >me that's an indication that it should be an instance > >method. > > Or a classmethod, or a staticmethod. > > The most common use case for this (in my experience) is when you need > a converter function or some other sort of function that's > configurable per-instance or per-subclass. If you are configuring it > per-class and accessing it per-instance, and reusing an existing > function, you have to make it a staticmethod. > > > >Also, what happens if you perform such a migration and > >then some subclasser later finds that he wants access to > >'self'? > > Then he overrides it with a normal method. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From greg.ewing at canterbury.ac.nz Fri Nov 23 07:57:07 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 23 Nov 2007 19:57:07 +1300 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: <20071123021416.E68713A40AC@sparrow.telecommunity.com> References: <47461B74.4050409@canterbury.ac.nz> <20071123021416.E68713A40AC@sparrow.telecommunity.com> Message-ID: <474679C3.6040703@canterbury.ac.nz> Phillip J. Eby wrote: > If you are configuring it per-class and > accessing it per-instance, and reusing an existing function, you have to > make it a staticmethod. I don't understand that. Can you provide an example? > > some subclasser later finds that he wants access to > > 'self'? > > Then he overrides it with a normal method. If that works, I don't see why making the default method a normal method wouldn't work also. -- Greg From lists at cheimes.de Fri Nov 23 08:12:28 2007 From: lists at cheimes.de (Christian Heimes) Date: Fri, 23 Nov 2007 08:12:28 +0100 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: References: <47461B74.4050409@canterbury.ac.nz> <20071123021416.E68713A40AC@sparrow.telecommunity.com> Message-ID: <47467D5C.6050502@cheimes.de> Guido van Rossum wrote: > It looks like we're in agreement to drop unbound methods and have a > reasonable set or arguments around it (e.g. keep staticmethod, no > changes to methods of builtin types, etc.). Do we need a PEP? It's > essentially a 2-line change in funcobject.c (func_descr_get()) -- plus > fixing up half a dozen or so unittests that specifically seem to test > the behavior of unbound methods. I'd like to help but after staring at the code for 10 minutes I still don't get how the descriptor function should be altered. Can you please give an example to a mer mortal? :) Christian From tjreedy at udel.edu Fri Nov 23 08:41:10 2007 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 23 Nov 2007 02:41:10 -0500 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? References: <47461B74.4050409@canterbury.ac.nz><20071123021416.E68713A40AC@sparrow.telecommunity.com> Message-ID: "Guido van Rossum" wrote in message news:ca471dc20711222019m19adf0aaic905793c08afd3b2 at mail.gmail.com... |Do we need a PEP? In my view, no. And I am a fan of PEPs. I personally saw unbound method wrapping as more of a CPython implementation detail than an essential part of the language definition. This in spite of its mention in the reference manual. In the index, 'method object' has 3 links. I believe all three areas will need at least a word or two changed. If this is a 3.0 change, then it should be listed in the general PEP with a reference to the thread. Otherwise, What's New. tjr From pje at telecommunity.com Fri Nov 23 13:59:22 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 23 Nov 2007 07:59:22 -0500 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: References: <47461B74.4050409@canterbury.ac.nz> <20071123021416.E68713A40AC@sparrow.telecommunity.com> Message-ID: <20071123125923.812CC3A40AC@sparrow.telecommunity.com> At 08:19 PM 11/22/2007 -0800, Guido van Rossum wrote: >It looks like we're in agreement to drop unbound methods and have a >reasonable set or arguments around it (e.g. keep staticmethod, no >changes to methods of builtin types, etc.). Do we need a PEP? It's >essentially a 2-line change in funcobject.c (func_descr_get()) -- plus >fixing up half a dozen or so unittests that specifically seem to test >the behavior of unbound methods. Since the only meaningful difference between an unbound method and a function is the availability of the im_class attribute, I Googled 'im_class ext:py' to see what's using it. There were 314 hits uses in published code, and I skimmed the first 60 or 70 of those. Of the ones I looked at, relatively few actually do anything with unbound methods specifically. Most are just custom pickling or persistence for methods, or method replacements like a "weakref method" that doesn't keep a strong reference to im_self. However, a few uses relevant to unbound methods turned up, however. Some documentation tools, an AOP library, an xreload()-like module reloader from Enthought, plus one usage in the stdlib. There were also a few modules where it was difficult to tell if unbound methods were actually important. While for most of the documentation tools it was probably not relevant, there were some (like a method deprecation utility) that looked like they would lose functionality by not being able to get the im_class of an object. The stdlib usage is in the unittest module: the test loading machinery needs to know the class of an unbound method so it knows what TestCase subclass to instantiate, when loading a single test by name. This could probably be worked around by making the routine keep track of the object from which the target object was retrieved. This is far from a comprehensive survey; 'UnboundMethodType ext:py' turns up 102 more hits, including another testing tool that uses unbound methods in a different way. There are also usage patterns that can't easily be searched for. For example, code that wants to be able to distinguish static methods and instance methods at the class level. Most of these use cases could probably be worked around, with sufficient effort. Many will probably have bigger problems porting to 3.0 than the absence of unbound methods. And I don't personally have a horse in this race, as my own code is surprisingly free of im_class use. Actually, given how many places my code is peppered with '.im_func' calls to *unwrap* unbound methods and reuse them in other classes, I probably lean more towards getting rid of them. :) From pje at telecommunity.com Fri Nov 23 14:04:32 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 23 Nov 2007 08:04:32 -0500 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: <474679C3.6040703@canterbury.ac.nz> References: <47461B74.4050409@canterbury.ac.nz> <20071123021416.E68713A40AC@sparrow.telecommunity.com> <474679C3.6040703@canterbury.ac.nz> Message-ID: <20071123130432.A30F53A40AC@sparrow.telecommunity.com> At 07:57 PM 11/23/2007 +1300, Greg Ewing wrote: >Phillip J. Eby wrote: >>If you are configuring it per-class and accessing it per-instance, >>and reusing an existing function, you have to make it a staticmethod. > >I don't understand that. Can you provide an example? def two_decimal_places(text): # ... class Field: # doesn't need staticmethod because str isn't a function converter = str def __init__(self, title): self.title = title class MoneyField(Field): # does need staticmethod because two_decimal_places # doesn't take a self converter = staticmethod(two_decimal_places) def get_input(field): return field.converter(raw_input(field.title+': ')) >> > some subclasser later finds that he wants access to >> > 'self'? >>Then he overrides it with a normal method. > >If that works, I don't see why making the default >method a normal method wouldn't work also. Because sometimes you want to reuse an existing function, as shown above. From lists at cheimes.de Fri Nov 23 15:10:55 2007 From: lists at cheimes.de (Christian Heimes) Date: Fri, 23 Nov 2007 15:10:55 +0100 Subject: [Python-Dev] Backquote deprecation warning Message-ID: Hello! I'm having a bit of a trouble getting the deprecation warning for backquotes `repr` right. Neither the ast_for_* functions in Python/ast.c nor the node structures have access to the filename. Should the node structure gain an additional field to drag the filename around? Or can we simply life with the fact that the user won't get a filename in the deprecation warning? Christian From lists at cheimes.de Fri Nov 23 15:27:59 2007 From: lists at cheimes.de (Christian Heimes) Date: Fri, 23 Nov 2007 15:27:59 +0100 Subject: [Python-Dev] 1324 bugs in the tracker Message-ID: Dear fellow Python developers! The Python bug tracker contains more than 1,300 bugs and it's growing. And growing ... and growing. I'm picking a bug once in a while or tossing some invalid bugs away but it's a helpless cause. The bugs are augmenting with anybody stopping them. Well, I'm exaggerating a bit but you probably get my point. The core developers can't keep up with new bugs and check old bugs at the same time. The resources are already stretched thin. But Brett gave me an idea how we could solve the problem when he posted the link to http://www.djangoproject.com/documentation/contributing/#ticket-triage. What do you think about inviting some trustworthy and experienced Python users to join the cause? They don't need to solve every problem and they won't need developer access to the svn. Instead their task is cleaning up the tracker, categorizing bugs and checking patches. The tracker sure contains a lot of outdated junk and already fixed bugs. A group of five to ten highly motivated people could squall through the tracker smashing all those ugly bugs like the infantry in Starship Troopers - but hopefully with less loss on our side. :] Christian From g.brandl at gmx.net Fri Nov 23 14:36:29 2007 From: g.brandl at gmx.net (Georg Brandl) Date: Fri, 23 Nov 2007 14:36:29 +0100 Subject: [Python-Dev] Backquote deprecation warning In-Reply-To: References: Message-ID: Christian Heimes schrieb: > Hello! > > I'm having a bit of a trouble getting the deprecation warning for > backquotes `repr` right. Neither the ast_for_* functions in Python/ast.c > nor the node structures have access to the filename. On a related note, every time you start a Python interpreter with -3 you get 8 instances of warning: callable() not supported in 3.x They come from copy_reg.py:pickle/constructor. Py3k has a hasattr('__call__') there. Am I correct that for Py2, that must be hasattr(object, '__call__') or isinstance(object, types.ClassType) ? Or are there other callable objects without a __call__ method? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. From p.f.moore at gmail.com Fri Nov 23 15:53:42 2007 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 23 Nov 2007 14:53:42 +0000 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition Message-ID: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> I have just built the current trunk version of Python on Windows, using the new PCBuild9 directory, and Visual Studio 2008 Express Edition. Everything went extremely well. I include below my notes on what I did, for reference. To be honest, there's nothing in here that really warrants a change to the readme.txt - to all intents and purposes, the process "just works". OK, here are my notes: Install Visual C++ 2008 Express Edition. Only select Silverlight from the options (no documentation or SQL Server - Silverlight probably isn't actually needed either). I already had the Platform SDK installed, but did nothing to tell VS about it, or to integrate it. I doubt this is relevant. I am using Python trunk at revision 59132. (But I hit an issue fixed in 59136, so better to use that). Start VC. Open project PCBuild9\pcbuild.sln Message "Solution Folders are not supported in this version of Visual Studio. Solution folder 'Solution Items' will be displayed as unavailable." Select OK. Select the release build (Build > Configuration Manager) Right click pythoncore > Build make_buildinfo - succeeded 1 warning (unlink vs _unlink) make_versioninfo - succeeded pythoncore - I hit an error in ast.c so I needed to svn up (to 59136). Succeeded. Right click python > Build. Succeeded. Right click pythonw > Build. Succeeded. Right click _socket > Build. Succeeded. Right click _testcapi > Build. Succeeded. Right click pyexpat > Build. Succeeded. Right click select > Build. Succeeded. Right click unicodedata > Build. Succeeded. Right click winsound > Build. Succeeded. At this point, we have finished the modules documented as "build out of the box" in PCBuild9\readme.txt. The modules _tkinter, bz2, _bsddb, _sqlite3, _ssl are documented as having dependencies. See below. Modules _ctypes, _ctypes_test, _elementtree, _msi, w9xpopen are not mentioned in readme.txt. They all build without error. bz2 --- The include dir is a macro, and I can't work out how to override the default (which is bzip2-1.0.3). So I stuck to 1.0.3 and exported it from Python svn, as per the instructions. Built OK. _sqlite3 -------- Again, couldn't work out how to change the macro, so I stuck with the external from svn (sqlite-source-3.3.4). The pre-link step failed with an error about not finding TCL. I edited the prelink step to include a /DNO_TCL flag on the cl command. There may be a better approach - I don't know if not having TCL is an issue for Python's use of sqlite. _tkinter and _bsddb ------------------- The instructions suggest using VS 2003 to build the dependencies. I don't have VS 2003 and don't have the time at the moment to investigate further. _ssl ---- Christian has been making changes to allow this to build without Perl, so I gave it a try. I used openssl 0.9.8g, which I extracted to the build directory (I noticed afterwards that this is the same version as in Python svn, so I could have used the svn external!) I needed to download nasm (nasm.sf.net) version 2.00rc1, and rename nasm.exe to nasmw.exe and put it on my PATH. Build succeeded, no issues. Tests ----- Running the tests, all succeed except test_tcl and test_bsddb, which are because I didn't build those two extensions, and test_os. The test_os failure is just because it looks for C:\pagefile.sys and my pagefile is on D:\. (There's also a problem with test_socket_ssl hanging, but this is present in the standard 2.6 snapshot build. I've raised a separate bug report for this). Paul. From andreas.raab at gmx.de Fri Nov 23 15:57:04 2007 From: andreas.raab at gmx.de (Andreas Raab) Date: Fri, 23 Nov 2007 06:57:04 -0800 Subject: [Python-Dev] .pyc location? Message-ID: <4746EA40.2090706@gmx.de> Hi - I'm having a few problems with our (embedded) Python interpreter trying to write .pyc files in the installation of our product (which actually sometimes works and sometimes doesn't depending on OS and paranoia level involved). This can give raise to a few very confusing situations and I'd like to be able to specify an explicit location for the .pyc files. Ideally, this would be a cache location where all .pyc files are created under an hashed (MD5 or similar) name of the original source file so that the cache location can be used for all of the compiled Python files. While googling this issue, I noticed that the status of PEP 304 says "withdrawn" but since most of the discussion around it seems to be a couple of years old, I thought I'd ask if anyone has done something in this area recently. If not, a pointer to the place which manages these mappings (or a starting point for further digging) would be greatly welcome. Cheers, - Andreas From g.brandl at gmx.net Fri Nov 23 14:57:17 2007 From: g.brandl at gmx.net (Georg Brandl) Date: Fri, 23 Nov 2007 14:57:17 +0100 Subject: [Python-Dev] 1324 bugs in the tracker In-Reply-To: References: Message-ID: Christian Heimes schrieb: > Dear fellow Python developers! > > The Python bug tracker contains more than 1,300 bugs and it's growing. Not speaking of the 432 bugs that weren't migrated from SourceForge (though I don't know how many of them were open). > And growing ... and growing. I'm picking a bug once in a while or > tossing some invalid bugs away but it's a helpless cause. The bugs are > augmenting with anybody stopping them. This is unfortunately not an easy problem. I've had some thoughts about it myself, and done some forays through the tracker closing "easy" bugs, but it has become more difficult to find such lately. > Well, I'm exaggerating a bit but you probably get my point. The core > developers can't keep up with new bugs and check old bugs at the same > time. The resources are already stretched thin. But Brett gave me an > idea how we could solve the problem when he posted the link to > http://www.djangoproject.com/documentation/contributing/#ticket-triage. > > What do you think about inviting some trustworthy and experienced Python > users to join the cause? They don't need to solve every problem and they > won't need developer access to the svn. Instead their task is cleaning > up the tracker, categorizing bugs and checking patches. The tracker sure > contains a lot of outdated junk and already fixed bugs. > > A group of five to ten highly motivated people could squall through the > tracker smashing all those ugly bugs like the infantry in Starship > Troopers - but hopefully with less loss on our side. :] Many old issues in the bug tracker fall in one of these categories: * Odd problem on a non-mainstream platform * Minor problem that is hard to fix * Minor problem that is in theory easy to fix, but there is no consensus on how to fix it * Minor problem that is easy but very tedious to fix * Major problem that is very hard to fix * Problem that one developer is more qualified to fix than all the others, but he is retired * Behavior about which even developers cannot consent whether it is a problem * Patch for a minor problem that is correct in theory, but will cause backwards compatibility issues * Patch for a minor problem that is not correct, but points in the right direction And of course, many RFEs that don't have a chance of being implemented without someone writing a patch and making a good cause on python-dev, which probably nobody except the OP will have an interest in. None of these categories are issues that you can just close, especially if you are new to Python core development, if we want to have a satisfactory resolution to each closed bug (which was the policy, as far as I was concerned, but it can be changed of course). On the other hand, there are kinds of issues than can be dealt with quickly: * Duplicated issues which were bug/patch pairs at SF * Issues where developers requested OP feedback but got none Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. From mail at timgolden.me.uk Fri Nov 23 16:06:14 2007 From: mail at timgolden.me.uk (Tim Golden) Date: Fri, 23 Nov 2007 15:06:14 +0000 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> Message-ID: <4746EC66.70608@timgolden.me.uk> Paul Moore wrote: > I have just built the current trunk version of Python on Windows, > using the new PCBuild9 directory, and Visual Studio 2008 Express > Edition. > > Everything went extremely well. I include below my notes on what I > did, for reference. To be honest, there's nothing in here that really > warrants a change to the readme.txt - to all intents and purposes, the > process "just works". My experience also. Thanks v. much to Christian for the work on this one. > _ssl > ---- > > Christian has been making changes to allow this to build without Perl, > so I gave it a try. I used openssl 0.9.8g, which I extracted to the > build directory (I noticed afterwards that this is the same version as > in Python svn, so I could have used the svn external!) > > I needed to download nasm (nasm.sf.net) version 2.00rc1, and rename > nasm.exe to nasmw.exe and put it on my PATH. Ah. Thanks for that last bit. I thought this might not build without the full VS, so I didn't try poking round for a nasm-alike. I managed to fudge distutils around sufficiently to build the standard Pyrex primes testcase as an extension. I noticed that Christian has committed patches to the py3k trunk which do useful things with the vcvars.bat file to pick up the compiler environment, so I was going to email him privately to look at backporting those into 2.6. This, my first experience of hacking distutils, felt a little like clambering over a construction site, with lots of ungainly "if it's v6; if it's v7" stuff obviously reflecting the vagaries of Microsoft's registry layout changes over the different compiler flavours. For practicality's sake I'd very much like to help get this to the point where you can build Python *and* extensions with the VS Express compilers (including, critically, the pywin32 stuff). TJG From g.brandl at gmx.net Fri Nov 23 15:22:05 2007 From: g.brandl at gmx.net (Georg Brandl) Date: Fri, 23 Nov 2007 15:22:05 +0100 Subject: [Python-Dev] .pyc location? In-Reply-To: <4746EA40.2090706@gmx.de> References: <4746EA40.2090706@gmx.de> Message-ID: Andreas Raab schrieb: > Hi - > > I'm having a few problems with our (embedded) Python interpreter trying > to write .pyc files in the installation of our product (which actually > sometimes works and sometimes doesn't depending on OS and paranoia level > involved). This can give raise to a few very confusing situations and > I'd like to be able to specify an explicit location for the .pyc files. > Ideally, this would be a cache location where all .pyc files are created > under an hashed (MD5 or similar) name of the original source file so > that the cache location can be used for all of the compiled Python files. > > While googling this issue, I noticed that the status of PEP 304 says > "withdrawn" but since most of the discussion around it seems to be a > couple of years old, I thought I'd ask if anyone has done something in > this area recently. If not, a pointer to the place which manages these > mappings (or a starting point for further digging) would be greatly welcome. There is this issue: http://bugs.python.org/issue602345 which contains a patch that adds a Python option to not write .pyc files at all. As far as I know, there is no further work in the direction of PEP 304. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. From lists at cheimes.de Fri Nov 23 16:43:59 2007 From: lists at cheimes.de (Christian Heimes) Date: Fri, 23 Nov 2007 16:43:59 +0100 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <4746EC66.70608@timgolden.me.uk> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> <4746EC66.70608@timgolden.me.uk> Message-ID: <4746F53F.40608@cheimes.de> Tim Golden wrote: > Ah. Thanks for that last bit. I thought this might not build > without the full VS, so I didn't try poking round for a > nasm-alike. I've changed the build_ssl.py script to build openssl for nasm instead of ml/masm. The MS assembler for x86 is only available in the standard and professional version. While it's possible to extract it from the SDK package I don't see the point in installing several hundreds of MB when less than one MB free a free assembler is more than fine. > I managed to fudge distutils around sufficiently to build > the standard Pyrex primes testcase as an extension. I noticed > that Christian has committed patches to the py3k trunk which > do useful things with the vcvars.bat file to pick up the > compiler environment, so I was going to email him privately to > look at backporting those into 2.6. This, my first experience > of hacking distutils, felt a little like clambering over a > construction site, with lots of ungainly "if it's v6; if it's v7" > stuff obviously reflecting the vagaries of Microsoft's registry > layout changes over the different compiler flavours. > > For practicality's sake I'd very much like to help get this > to the point where you can build Python *and* extensions with > the VS Express compilers (including, critically, the pywin32 > stuff). I've a preliminary patch for distutils.msvccompiler at http://bugs.python.org/issue1455. I haven't applied the patch because it's not backward compatible with VC 7 and VS 6. We haven't yet agreed how to address backward compatibility. I really like to throw out the old junk to have a clean script. Maybe I could leave the old msvccompiler alone and put the new code into distutils.msvc9compiler? Christian From facundobatista at gmail.com Fri Nov 23 16:45:11 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Fri, 23 Nov 2007 12:45:11 -0300 Subject: [Python-Dev] 1324 bugs in the tracker In-Reply-To: References: Message-ID: 2007/11/23, Christian Heimes : > The Python bug tracker contains more than 1,300 bugs and it's growing. > And growing ... and growing. I'm picking a bug once in a while or > tossing some invalid bugs away but it's a helpless cause. The bugs are > augmenting with anybody stopping them. Yes. I even created a web page to facilitate the view of how much each bug is considered, and I normally use it to take a random pick: http://www.taniquetil.com.ar/facundo/py_tickets.html > won't need developer access to the svn. Instead their task is cleaning > up the tracker, categorizing bugs and checking patches. The tracker sure > contains a lot of outdated junk and already fixed bugs. One way to do this is to create a monthly (or each two months) a bug day. This way we can invite people that starts working on this (and with luck they'll continue with it). Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From p.f.moore at gmail.com Fri Nov 23 16:54:56 2007 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 23 Nov 2007 15:54:56 +0000 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <4746F53F.40608@cheimes.de> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> <4746EC66.70608@timgolden.me.uk> <4746F53F.40608@cheimes.de> Message-ID: <79990c6b0711230754o459d3dd0w426363c4b64fdced@mail.gmail.com> On 23/11/2007, Christian Heimes wrote: > I've a preliminary patch for distutils.msvccompiler at > http://bugs.python.org/issue1455. I haven't applied the patch because > it's not backward compatible with VC 7 and VS 6. We haven't yet agreed > how to address backward compatibility. I looked at this, and it seems like more of a change than is really needed. But it's a LONG time since I looked at the distutils compiler stuff. I think that the VC7 stuff has provision for checking the registry first, then looking for one specific key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0 would be the VS 2008 equivalent) and if it's there but no others, asking the user to run vsvars.bat (and then relying on PATH being set right). Something like that might work for VS 2008 as well. > I really like to throw out the old junk to have a clean script. Maybe I > could leave the old msvccompiler alone and put the new code into > distutils.msvc9compiler? That might work. I'm not sure if throwing the old stuff out is OK. As long as we have a VC6 directory (however unmaintained it may be) I'd say we need the equivalent distutils support. Paul. From p.f.moore at gmail.com Fri Nov 23 16:59:28 2007 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 23 Nov 2007 15:59:28 +0000 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <4746EC66.70608@timgolden.me.uk> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> <4746EC66.70608@timgolden.me.uk> Message-ID: <79990c6b0711230759g683bfdb4gb8d8cb51e59be9bd@mail.gmail.com> On 23/11/2007, Tim Golden wrote: > For practicality's sake I'd very much like to help get this > to the point where you can build Python *and* extensions with > the VS Express compilers (including, critically, the pywin32 > stuff). Pywin32 needs MFC (and at one stage, ATL, although I think that was a mistake and has been fixed). As far as I know, the Express edition doesn't include MFC or ATL - VS 2005 Express certainly didn't. Paul. From lists at cheimes.de Fri Nov 23 16:59:32 2007 From: lists at cheimes.de (Christian Heimes) Date: Fri, 23 Nov 2007 16:59:32 +0100 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> Message-ID: <4746F8E4.2090207@cheimes.de> Paul Moore wrote: > Install Visual C++ 2008 Express Edition. Only select Silverlight from > the options (no documentation or SQL Server - Silverlight probably > isn't actually needed either). > I already had the Platform SDK installed, but did nothing to tell VS > about it, or to integrate it. I doubt this is relevant. Even the VS 2008 Express Edition comes with the necessary bits and pieces to build everything. I don't think you need an extra installation of the platform SDK anymore. It should only be required for developers with the Express Edition who want to build a 64bit build. > Start VC. > Open project PCBuild9\pcbuild.sln > Message "Solution Folders are not supported in this version of Visual > Studio. Solution folder 'Solution Items' will be displayed as > unavailable." Select OK. That's harmless but disappointing. The solution folder contains the README.txt for quick access. > Select the release build (Build > Configuration Manager) > > Right click pythoncore > Build > make_buildinfo - succeeded 1 warning (unlink vs _unlink) > make_versioninfo - succeeded > pythoncore - I hit an error in ast.c so I needed to svn up (to > 59136). Succeeded. > > Right click python > Build. Succeeded. > Right click pythonw > Build. Succeeded. > Right click _socket > Build. Succeeded. > Right click _testcapi > Build. Succeeded. > Right click pyexpat > Build. Succeeded. > Right click select > Build. Succeeded. > Right click unicodedata > Build. Succeeded. > Right click winsound > Build. Succeeded. Why are you building the projects step by step? "Build solution" or F6 builds everything in the right order. > bz2 > --- > > The include dir is a macro, and I can't work out how to override the > default (which is bzip2-1.0.3). So I stuck to 1.0.3 and exported it > from Python svn, as per the instructions. You can alter the user macros from the Property Manager. It's a bit hidden in the GUI under View -> Other Windows -> Property Manager. In the property manager pick a random project and configuration and edit the pyproject property file. Almost every project inherits settings directly or indirectly from pyproject. The macros are under "User Macros". You have to safe the property file all by yourself. My Beta 2 doesn't save the property file with "Save All". > _sqlite3 > -------- > > Again, couldn't work out how to change the macro, so I stuck with the > external from svn (sqlite-source-3.3.4). > > The pre-link step failed with an error about not finding TCL. I edited > the prelink step to include a /DNO_TCL flag on the cl command. There > may be a better approach - I don't know if not having TCL is an issue > for Python's use of sqlite. Hey, that's a good idea. The TCL error isn't a critical error although VS reports it so. > _tkinter and _bsddb > ------------------- > > The instructions suggest using VS 2003 to build the dependencies. I > don't have VS 2003 and don't have the time at the moment to > investigate further. bsddb is automatically build by a build step. But you have to convert the project files in build_win32 to VS 2008 first. Simply open the solution file and let VS convert the projects. tcl/tk isn't integrated in the new build process yet. I think we have to update the dependencies first. > _ssl > ---- > > Christian has been making changes to allow this to build without Perl, > so I gave it a try. I used openssl 0.9.8g, which I extracted to the > build directory (I noticed afterwards that this is the same version as > in Python svn, so I could have used the svn external!) > > I needed to download nasm (nasm.sf.net) version 2.00rc1, and rename > nasm.exe to nasmw.exe and put it on my PATH. > > Build succeeded, no issues. You still need Perl if you are using an official download of openssl. I've added the pre-build assembly and makefiles in the svn external at svn.python.org Christian From mail at timgolden.me.uk Fri Nov 23 17:01:16 2007 From: mail at timgolden.me.uk (Tim Golden) Date: Fri, 23 Nov 2007 16:01:16 +0000 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <79990c6b0711230754o459d3dd0w426363c4b64fdced@mail.gmail.com> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> <4746EC66.70608@timgolden.me.uk> <4746F53F.40608@cheimes.de> <79990c6b0711230754o459d3dd0w426363c4b64fdced@mail.gmail.com> Message-ID: <4746F94C.3000607@timgolden.me.uk> Paul Moore wrote: > On 23/11/2007, Christian Heimes wrote: >> I really like to throw out the old junk to have a clean script. Maybe I >> could leave the old msvccompiler alone and put the new code into >> distutils.msvc9compiler? > > That might work. I'm not sure if throwing the old stuff out is OK. As > long as we have a VC6 directory (however unmaintained it may be) I'd > say we need the equivalent distutils support. Presumably the advantage of a new compiler flavour is that you could set your pydistutils.cfg to that compiler (or use --compiler= or whatever) and put whatever specifics you want in a new class without having to disturb the unstable equilibrium which is msvccompiler. TJG From p.f.moore at gmail.com Fri Nov 23 17:11:40 2007 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 23 Nov 2007 16:11:40 +0000 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <4746F8E4.2090207@cheimes.de> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> <4746F8E4.2090207@cheimes.de> Message-ID: <79990c6b0711230811q4c3d7d72kf9dfebdef998ffd@mail.gmail.com> On 23/11/2007, Christian Heimes wrote: > Why are you building the projects step by step? "Build solution" or F6 > builds everything in the right order. Because I'm clueless :-) I knew there must be a way of building the lot, but couldn't find it - I haven't used Visual Studio since the days of VC6, and what little I did know, I've forgotten :-) Thanks for the tip. > You can alter the user macros from the Property Manager. It's a bit > hidden in the GUI under View -> Other Windows -> Property Manager. In > the property manager pick a random project and configuration and edit > the pyproject property file. Almost every project inherits settings > directly or indirectly from pyproject. The macros are under "User Macros". > You have to safe the property file all by yourself. My Beta 2 doesn't > save the property file with "Save All". Thanks again for the tip :-) > You still need Perl if you are using an official download of openssl. > I've added the pre-build assembly and makefiles in the svn external at > svn.python.org I don't think I did... I'm pretty sure I used the ones from openssl.org. But it's no big deal. Whatever I did seemed to work. Paul. From g.brandl at gmx.net Fri Nov 23 16:37:56 2007 From: g.brandl at gmx.net (Georg Brandl) Date: Fri, 23 Nov 2007 16:37:56 +0100 Subject: [Python-Dev] 1324 bugs in the tracker In-Reply-To: References: Message-ID: Facundo Batista schrieb: >> won't need developer access to the svn. Instead their task is cleaning >> up the tracker, categorizing bugs and checking patches. The tracker sure >> contains a lot of outdated junk and already fixed bugs. > > One way to do this is to create a monthly (or each two months) a bug > day. This way we can invite people that starts working on this (and > with luck they'll continue with it). Exactly. The bug day brings together volunteers and developers, and it also helps discussion between developers (which often takes long via the tracker) because of IRC. IOW, +1. It would be a good thing to have a regular bug day. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. From ncoghlan at gmail.com Fri Nov 23 17:47:10 2007 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 24 Nov 2007 02:47:10 +1000 Subject: [Python-Dev] .pyc location? In-Reply-To: <4746EA40.2090706@gmx.de> References: <4746EA40.2090706@gmx.de> Message-ID: <4747040E.4010205@gmail.com> Andreas Raab wrote: > While googling this issue, I noticed that the status of PEP 304 says > "withdrawn" but since most of the discussion around it seems to be a > couple of years old, I thought I'd ask if anyone has done something in > this area recently. If not, a pointer to the place which manages these > mappings (or a starting point for further digging) would be greatly welcome. As I recall, the PEP was withdrawn because Skip didn't have the time and/or level of interest needed to champion it any more, and nobody else was interested in taking on the task. What opposition that existed to the idea was based on the question of whether or not the problem was one that was worth spending significant effort on solving. Issues with collocating the compiled files with the source files do arise occasionally, but they can generally be resolved by having root run compileall [1] over the affected directories. In cases where users are able to modify source files (hence leading to the need to recompile them after installation), those users are also typically able to write the necessary .pyc files to the same directory. For the optimisation cases the PEP mentions (network drives, RAM drives), you can get the same effect (and more) by caching the whole application. Cheers, Nick. [1] http://docs.python.org/lib/module-compileall.html -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From mal at egenix.com Fri Nov 23 17:49:27 2007 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 23 Nov 2007 17:49:27 +0100 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <4746F8E4.2090207@cheimes.de> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> <4746F8E4.2090207@cheimes.de> Message-ID: <47470497.4050203@egenix.com> On 2007-11-23 16:59, Christian Heimes wrote: > Paul Moore wrote: >> _ssl >> ---- >> >> Christian has been making changes to allow this to build without Perl, >> so I gave it a try. I used openssl 0.9.8g, which I extracted to the >> build directory (I noticed afterwards that this is the same version as >> in Python svn, so I could have used the svn external!) >> >> I needed to download nasm (nasm.sf.net) version 2.00rc1, and rename >> nasm.exe to nasmw.exe and put it on my PATH. >> >> Build succeeded, no issues. > > You still need Perl if you are using an official download of openssl. > I've added the pre-build assembly and makefiles in the svn external at > svn.python.org Why not include the prebuilt libraries of all external libs in SVN as well ? BTW: Are you including the patented algorithms in the standard OpenSSL build or excluding them ? The patented ones are RC5, IDEA and MDC2: http://svn.python.org/view/external/openssl-0.9.8g/README Here's a previous discussion: http://mail.python.org/pipermail/python-dev/2006-August/068055.html Here's what MediaCrypt has to say about requiring a license for IDEA: http://www.mediacrypt.com/_contents/20_support/204010_faq_bus.asp Note that in the case of IDEA, any commercial use will require getting a license to the patented algorithm first (costs start at EUR 15 for a single use license). I'd opt for not including these algorithms, as it's just too easy for the user to overlook this license requirement. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 23 2007) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From facundobatista at gmail.com Fri Nov 23 18:14:54 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Fri, 23 Nov 2007 14:14:54 -0300 Subject: [Python-Dev] 1324 bugs in the tracker In-Reply-To: References: Message-ID: 2007/11/23, Christian Heimes : > Well, I'm exaggerating a bit but you probably get my point. The core > developers can't keep up with new bugs and check old bugs at the same > time. The resources are already stretched thin. But Brett gave me an One *fantastic* tool that exists is the subscription to the "bugs-announce" mail list. I wasn't aware of this before. But I subscribed to it, and now I know about a lot of bugs that potentially interests me. Ok, I don't care about a 80% of the bugs that I receive. But I read the other 20%, and even I solve a small amount of that. It increased my bug-hunting activity a lot! Maybe we should publicize this more. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From g.brandl at gmx.net Fri Nov 23 17:28:38 2007 From: g.brandl at gmx.net (Georg Brandl) Date: Fri, 23 Nov 2007 17:28:38 +0100 Subject: [Python-Dev] 1324 bugs in the tracker In-Reply-To: References: Message-ID: Facundo Batista schrieb: > 2007/11/23, Christian Heimes : > >> Well, I'm exaggerating a bit but you probably get my point. The core >> developers can't keep up with new bugs and check old bugs at the same >> time. The resources are already stretched thin. But Brett gave me an > > One *fantastic* tool that exists is the subscription to the > "bugs-announce" mail list. > > I wasn't aware of this before. But I subscribed to it, and now I know > about a lot of bugs that potentially interests me. Even better is that you don't even need to subscribe to the mailing list (whose daily traffic may be a bit annoying); reading the gmane.comp.python.bugs newsgroup via gmane is equally useful. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. From skip at pobox.com Fri Nov 23 18:32:20 2007 From: skip at pobox.com (skip at pobox.com) Date: Fri, 23 Nov 2007 11:32:20 -0600 Subject: [Python-Dev] .pyc location? In-Reply-To: <4747040E.4010205@gmail.com> References: <4746EA40.2090706@gmx.de> <4747040E.4010205@gmail.com> Message-ID: <18247.3748.102999.298982@montanaro.dyndns.org> Nick> As I recall, the PEP was withdrawn because Skip didn't have the Nick> time and/or level of interest needed to champion it any more, and Nick> nobody else was interested in taking on the task. Correct. I only implemented what I did because it seemed like an interesting concept arising out of a discussion on c.l.py. I personally have never encountered the problems it tries to address so the fact that it remains unaccepted is not a problem for me. It would be better if PEP 304 scratched an itch for its champion. Skip From lists at cheimes.de Fri Nov 23 18:40:01 2007 From: lists at cheimes.de (Christian Heimes) Date: Fri, 23 Nov 2007 18:40:01 +0100 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <47470497.4050203@egenix.com> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> <4746F8E4.2090207@cheimes.de> <47470497.4050203@egenix.com> Message-ID: <47471071.6030304@cheimes.de> M.-A. Lemburg wrote: > Why not include the prebuilt libraries of all external libs in SVN > as well ? For one I'm still using Beta 2 of the standard edition and I'm not allowed to distribute binaries build with the Beta. With the new pre-build steps it's also very easy to build the dependencies. I don't like to add more binaries to the svn repos. > > BTW: Are you including the patented algorithms in the standard > OpenSSL build or excluding them ? > > The patented ones are RC5, IDEA and MDC2: [snip] > I'd opt for not including these algorithms, as it's just > too easy for the user to overlook this license requirement. Thanks for thinking about license problems! I didn't even think about checking the licenses since I was under the impression that restricted algorithms are disabled by default. I've disabled IDEA in the makefiles and configure headers of openssl. I've also added another step to the makefile patcher in build_ssl. It makes sure that the three algorithms are disabled. Christian From mal at egenix.com Fri Nov 23 18:51:57 2007 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 23 Nov 2007 18:51:57 +0100 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <47471071.6030304@cheimes.de> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> <4746F8E4.2090207@cheimes.de> <47470497.4050203@egenix.com> <47471071.6030304@cheimes.de> Message-ID: <4747133D.8010907@egenix.com> On 2007-11-23 18:40, Christian Heimes wrote: > M.-A. Lemburg wrote: >> Why not include the prebuilt libraries of all external libs in SVN >> as well ? > > For one I'm still using Beta 2 of the standard edition and I'm not > allowed to distribute binaries build with the Beta. With the new > pre-build steps it's also very easy to build the dependencies. I don't > like to add more binaries to the svn repos. Fair enough - was just thinking that people compiling Python on Windows are probably more interested in compiling the Python code itself, rather than getting the 3rd party tools to compile :-) >> BTW: Are you including the patented algorithms in the standard >> OpenSSL build or excluding them ? >> >> The patented ones are RC5, IDEA and MDC2: > > [snip] > >> I'd opt for not including these algorithms, as it's just >> too easy for the user to overlook this license requirement. > > Thanks for thinking about license problems! I didn't even think about > checking the licenses since I was under the impression that restricted > algorithms are disabled by default. > > I've disabled IDEA in the makefiles and configure headers of openssl. > I've also added another step to the makefile patcher in build_ssl. It > makes sure that the three algorithms are disabled. Thanks. Much appreciated. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 23 2007) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From steve at holdenweb.com Fri Nov 23 19:00:01 2007 From: steve at holdenweb.com (Steve Holden) Date: Fri, 23 Nov 2007 13:00:01 -0500 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <47471071.6030304@cheimes.de> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> <4746F8E4.2090207@cheimes.de> <47470497.4050203@egenix.com> <47471071.6030304@cheimes.de> Message-ID: <47471521.5010306@holdenweb.com> Christian Heimes wrote: > M.-A. Lemburg wrote: >> Why not include the prebuilt libraries of all external libs in SVN >> as well ? > > For one I'm still using Beta 2 of the standard edition and I'm not > allowed to distribute binaries build with the Beta. With the new > pre-build steps it's also very easy to build the dependencies. I don't > like to add more binaries to the svn repos. > >> BTW: Are you including the patented algorithms in the standard >> OpenSSL build or excluding them ? >> >> The patented ones are RC5, IDEA and MDC2: > > [snip] > >> I'd opt for not including these algorithms, as it's just >> too easy for the user to overlook this license requirement. > > Thanks for thinking about license problems! I didn't even think about > checking the licenses since I was under the impression that restricted > algorithms are disabled by default. > > I've disabled IDEA in the makefiles and configure headers of openssl. > I've also added another step to the makefile patcher in build_ssl. It > makes sure that the three algorithms are disabled. > I believe the patent on MDC2 expired this year, though this is not an authoritative opinion. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From steve at holdenweb.com Fri Nov 23 19:00:01 2007 From: steve at holdenweb.com (Steve Holden) Date: Fri, 23 Nov 2007 13:00:01 -0500 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <47471071.6030304@cheimes.de> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> <4746F8E4.2090207@cheimes.de> <47470497.4050203@egenix.com> <47471071.6030304@cheimes.de> Message-ID: <47471521.5010306@holdenweb.com> Christian Heimes wrote: > M.-A. Lemburg wrote: >> Why not include the prebuilt libraries of all external libs in SVN >> as well ? > > For one I'm still using Beta 2 of the standard edition and I'm not > allowed to distribute binaries build with the Beta. With the new > pre-build steps it's also very easy to build the dependencies. I don't > like to add more binaries to the svn repos. > >> BTW: Are you including the patented algorithms in the standard >> OpenSSL build or excluding them ? >> >> The patented ones are RC5, IDEA and MDC2: > > [snip] > >> I'd opt for not including these algorithms, as it's just >> too easy for the user to overlook this license requirement. > > Thanks for thinking about license problems! I didn't even think about > checking the licenses since I was under the impression that restricted > algorithms are disabled by default. > > I've disabled IDEA in the makefiles and configure headers of openssl. > I've also added another step to the makefile patcher in build_ssl. It > makes sure that the three algorithms are disabled. > I believe the patent on MDC2 expired this year, though this is not an authoritative opinion. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From andreas.raab at gmx.de Fri Nov 23 19:02:15 2007 From: andreas.raab at gmx.de (Andreas Raab) Date: Fri, 23 Nov 2007 10:02:15 -0800 Subject: [Python-Dev] .pyc location? In-Reply-To: <4747040E.4010205@gmail.com> References: <4746EA40.2090706@gmx.de> <4747040E.4010205@gmail.com> Message-ID: <474715A7.4090202@gmx.de> Nick Coghlan wrote: > Issues with collocating the compiled files with the source files do > arise occasionally, but they can generally be resolved by having root > run compileall [1] over the affected directories. In cases where users > are able to modify source files (hence leading to the need to recompile > them after installation), those users are also typically able to write > the necessary .pyc files to the same directory. Thanks, I'll try using compileall before digging deeper. If the file times are preserved correctly by the various installers this should do the trick. Cheers, - Andreas From status at bugs.python.org Fri Nov 23 19:06:07 2007 From: status at bugs.python.org (Tracker) Date: Fri, 23 Nov 2007 18:06:07 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071123180607.C5B4978358@psf.upfronthosting.co.za> ACTIVITY SUMMARY (11/16/07 - 11/23/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1321 open (+20) / 11654 closed (+20) / 12975 total (+40) Open issues with patches: 413 Average duration of open issues: 697 days. Median duration of open issues: 825 days. Open Issues Breakdown open 1314 (+19) pending 7 ( +1) Issues Created Or Reopened (41) _______________________________ Python does not honor "CFLAGS" environment variable 11/16/07 CLOSED http://bugs.python.org/issue1453 created tebeka Generators break trace functionality 11/17/07 CLOSED http://bugs.python.org/issue1454 created cortesi VS2008, quick hack for distutils.msvccompiler 11/17/07 http://bugs.python.org/issue1455 created tiran py3k, patch unexpected iterator behavior with removal 11/18/07 CLOSED http://bugs.python.org/issue1456 created JosephArmbruster IDLE - configDialog - new layout for key config 11/18/07 http://bugs.python.org/issue1457 created taleinat installer crashes on attempted cancellation 11/18/07 http://bugs.python.org/issue1458 created JosephArmbruster Bugs lost on migration from Sourceforge 11/18/07 CLOSED http://bugs.python.org/issue1459 created gagenellina codecs utf7 decoding error 11/19/07 CLOSED http://bugs.python.org/issue1460 created arnimar 0**0 should raise an error 11/19/07 CLOSED http://bugs.python.org/issue1461 created jmgillet About this document refers to SourceForge tracker 11/19/07 CLOSED http://bugs.python.org/issue1462 created kjohnson Minor error in mimetypes docs 11/19/07 CLOSED http://bugs.python.org/issue1463 created kjohnson inet_pton redefined while building with windows SDK 6.0 11/19/07 CLOSED http://bugs.python.org/issue1464 created weck py3k, patch building python 2.6 with VC Express 2008 Beta2 11/19/07 http://bugs.python.org/issue1465 created weck patch Special reporting of NotImplementedError in unittest 11/19/07 CLOSED http://bugs.python.org/issue1466 created erik_andersen error in TestResult.addError and TestResult.addFailure 11/19/07 http://bugs.python.org/issue1467 created draghuram MSI installer does not include SSL test .pem files 11/19/07 http://bugs.python.org/issue1468 created pmoore SSL tests leak memory 11/19/07 http://bugs.python.org/issue1469 created janssen py3k py3k unit tests are removing %TEMP% dir on Windows 11/20/07 CLOSED http://bugs.python.org/issue1470 created tiran py3k ioctl doesn't work properly on 64-bit OpenBSD 11/20/07 http://bugs.python.org/issue1471 created fbvortex Small bat files to build docs on Windows 11/20/07 http://bugs.python.org/issue1472 created tiran py3k, patch Drop _EXPORTS macros in PCbuild9 11/20/07 CLOSED http://bugs.python.org/issue1473 created loewis py3k PCbuild9 patch for trunk 11/20/07 CLOSED http://bugs.python.org/issue1474 created tiran patch test_popen fails when the directory contains a space 11/20/07 http://bugs.python.org/issue1475 created tiran py3k missing debug configuration for make_versioninfo.vcproj 11/20/07 CLOSED http://bugs.python.org/issue1476 created JosephArmbruster UnicodeDecodeError that cannot be caught in narrow unicode build 11/20/07 http://bugs.python.org/issue1477 created sbp pythoncore.vcproj fails to generate buildinfo (when spaces in pa 11/21/07 CLOSED http://bugs.python.org/issue1478 created JosephArmbruster py3k, patch csv module is leaking references 11/21/07 http://bugs.python.org/issue1479 created tiran py3k sqlite module is leaking lots of references 11/21/07 http://bugs.python.org/issue1480 created tiran py3k test_uuid is warning about unreliable functions 11/21/07 http://bugs.python.org/issue1481 created tiran py3k IMAP4 SSL isn't working 11/21/07 http://bugs.python.org/issue1482 created tiran py3k xml.sax.saxutils.prepare_input_source ignores character stream i 11/21/07 http://bugs.python.org/issue1483 created ygale logging: callHandlers tests handler levels instead of logger lev 11/21/07 CLOSED http://bugs.python.org/issue1484 created gidi_avrahami Idle tab command completion 11/22/07 CLOSED http://bugs.python.org/issue1485 created Mufasa Idle tab command completion 11/22/07 CLOSED http://bugs.python.org/issue1486 created Mufasa PEP 366 implementation 11/22/07 http://bugs.python.org/issue1487 created ncoghlan patch PCBuild9 _ssl.vcproj improperly launches build 11/22/07 CLOSED http://bugs.python.org/issue1488 created JosephArmbruster py3k, patch test_socket_ssl hanhs on Windows (deadlock) 11/22/07 http://bugs.python.org/issue1489 created pmoore Bug in eval() function 11/23/07 CLOSED http://bugs.python.org/issue1490 created arunkumarrajan BaseHTTPServer incorrectly implements response code 100 11/23/07 http://bugs.python.org/issue1491 created samwyse BaseHTTPServer hard-codes Content-Type for error messages 11/23/07 http://bugs.python.org/issue1492 created samwyse Add a -z interpreter flag to execute a zip file 11/19/07 CLOSED http://bugs.python.org/issue1739468 reopened ncoghlan patch Issues Now Closed (43) ______________________ pyexpat.XMParserType broken (was: pydoc doesn't work on pyexpat) 87 days http://bugs.python.org/issue1020 tiran py3k os.system() encoding bug on Windows 57 days http://bugs.python.org/issue1193 amaury.forgeotdarc py3k string find and rfind methods give a TypeError that is misleadin 37 days http://bugs.python.org/issue1259 facundobatista PCBuild8 Solution Support Changes 27 days http://bugs.python.org/issue1320 tiran windows installer problem 20 days http://bugs.python.org/issue1354 loewis zlibmodule.c: int overflow in PyZlib_decompress 19 days http://bugs.python.org/issue1372 tiran patch, 64bit Backport abcoll to 2.6 17 days http://bugs.python.org/issue1383 gvanrossum patch py3k: duplicated line endings when using read(1) 14 days http://bugs.python.org/issue1395 amaury.forgeotdarc py3k py_compile and compileall need unit tests 13 days http://bugs.python.org/issue1403 tiran py3k pth files not loaded at startup 4 days http://bugs.python.org/issue1431 brett.cannon patch logging.config.fileConfig, NameError: name 'RotatingFileHandler' 7 days http://bugs.python.org/issue1436 vsajip utf_8_sig streamreader bug, patch, and test 4 days http://bugs.python.org/issue1444 doerwalter patch make msi work the vs 2005(MSVC8) 3 days http://bugs.python.org/issue1449 tiran patch Python does not honor "CFLAGS" environment variable 0 days http://bugs.python.org/issue1453 loewis Generators break trace functionality 1 days http://bugs.python.org/issue1454 gvanrossum unexpected iterator behavior with removal 0 days http://bugs.python.org/issue1456 tiran Bugs lost on migration from Sourceforge 0 days http://bugs.python.org/issue1459 brett.cannon codecs utf7 decoding error 2 days http://bugs.python.org/issue1460 amaury.forgeotdarc 0**0 should raise an error 0 days http://bugs.python.org/issue1461 gvanrossum About this document refers to SourceForge tracker 0 days http://bugs.python.org/issue1462 brett.cannon Minor error in mimetypes docs 0 days http://bugs.python.org/issue1463 facundobatista inet_pton redefined while building with windows SDK 6.0 1 days http://bugs.python.org/issue1464 tiran py3k, patch Special reporting of NotImplementedError in unittest 0 days http://bugs.python.org/issue1466 erik_andersen py3k unit tests are removing %TEMP% dir on Windows 0 days http://bugs.python.org/issue1470 tiran py3k Drop _EXPORTS macros in PCbuild9 1 days http://bugs.python.org/issue1473 tiran py3k PCbuild9 patch for trunk 3 days http://bugs.python.org/issue1474 tiran patch missing debug configuration for make_versioninfo.vcproj 0 days http://bugs.python.org/issue1476 tiran pythoncore.vcproj fails to generate buildinfo (when spaces in pa 0 days http://bugs.python.org/issue1478 tiran py3k, patch logging: callHandlers tests handler levels instead of logger lev 1 days http://bugs.python.org/issue1484 vsajip Idle tab command completion 0 days http://bugs.python.org/issue1485 facundobatista Idle tab command completion 1 days http://bugs.python.org/issue1486 facundobatista PCBuild9 _ssl.vcproj improperly launches build 1 days http://bugs.python.org/issue1488 JosephArmbruster py3k, patch Bug in eval() function 0 days http://bugs.python.org/issue1490 loewis trace.py needs to know about doctests 650 days http://bugs.python.org/issue1429818 skip.montanaro patch sqlite timestamp converter bug (floating point) 371 days http://bugs.python.org/issue1597404 ghaering Improve platform.py usability on Windows 337 days http://bugs.python.org/issue1620174 lemburg patch Importing a submodule fails after unloading its parent 171 days http://bugs.python.org/issue1731068 tiran python 2.6 latest fails test_socketserver.py 170 days http://bugs.python.org/issue1732145 tiran sqlite3 module trigger problem 168 days http://bugs.python.org/issue1733085 ghaering Add a -z interpreter flag to execute a zip file 0 days http://bugs.python.org/issue1739468 gvanrossum patch Deprecation warning for `backticks` 131 days http://bugs.python.org/issue1754271 tiran patch Deprecation warning for <> (NOTEQUAL) 131 days http://bugs.python.org/issue1754273 tiran patch MSVC++8 x86 tkinter build patch for trunk 110 days http://bugs.python.org/issue1767787 tiran patch Top Issues Most Discussed (10) ______________________________ 9 Add a -z interpreter flag to execute a zip file 0 days closed http://bugs.python.org/issue1739468 9 VS2008, quick hack for distutils.msvccompiler 6 days open http://bugs.python.org/issue1455 8 Special reporting of NotImplementedError in unittest 0 days closed http://bugs.python.org/issue1466 7 Python does not honor "CFLAGS" environment variable 0 days closed http://bugs.python.org/issue1453 6 test_popen fails when the directory contains a space 3 days open http://bugs.python.org/issue1475 6 building python 2.6 with VC Express 2008 Beta2 4 days open http://bugs.python.org/issue1465 5 PCBuild9 _ssl.vcproj improperly launches build 1 days closed http://bugs.python.org/issue1488 4 Idle tab command completion 1 days closed http://bugs.python.org/issue1486 4 ioctl doesn't work properly on 64-bit OpenBSD 4 days pending http://bugs.python.org/issue1471 4 py3k unit tests are removing %TEMP% dir on Windows 0 days closed http://bugs.python.org/issue1470 From facundobatista at gmail.com Fri Nov 23 19:19:54 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Fri, 23 Nov 2007 15:19:54 -0300 Subject: [Python-Dev] Decimal news: speedup and stabilization Message-ID: Hi people! Two news. A big speed up, and now we reached some stable state. Mark Dickinson found out that a lot of time was lost internally in decimal.py when dealing with the Decimal mantissas. He changed the way that mantissa was stored, from a tuple of ints, to a plain string (each character a digit). This achieved a speedup of around a 40%!!! Three notes: - The speedup was measured using two tools I created [*], one basically tries a lot of use cases, the other use the specification test cases. Both generate a .py which actually measures the times. - No API was changed, and this a good thing, :) - The change is somewhat big. But as the speedup is important, and the API es untouched, I considered it was something that worths it. After several months with a lot of work here, no more big changes are planned to this module, so I will backport it to 2.5.3 (when the trunk gets unfrozen). Note that the module complies with the latest specification and with the latest test cases (that are from one month ago!). Thanks Mark for all your effort here! [*] http://tools.assembla.com/svn/homedevel/decimal/ Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From brett at python.org Fri Nov 23 19:28:22 2007 From: brett at python.org (Brett Cannon) Date: Fri, 23 Nov 2007 10:28:22 -0800 Subject: [Python-Dev] .pyc location? In-Reply-To: <474715A7.4090202@gmx.de> References: <4746EA40.2090706@gmx.de> <4747040E.4010205@gmail.com> <474715A7.4090202@gmx.de> Message-ID: On Nov 23, 2007 10:02 AM, Andreas Raab wrote: > Nick Coghlan wrote: > > Issues with collocating the compiled files with the source files do > > arise occasionally, but they can generally be resolved by having root > > run compileall [1] over the affected directories. In cases where users > > are able to modify source files (hence leading to the need to recompile > > them after installation), those users are also typically able to write > > the necessary .pyc files to the same directory. > > Thanks, I'll try using compileall before digging deeper. If the file > times are preserved correctly by the various installers this should do > the trick. There is also importlib which is import implemented in Python (currently in Python's sandbox in svn). Skipping .pyc compilation is not hard in what instance as you just subclass something and overload a single method. -Brett From gnewsg at gmail.com Fri Nov 23 19:37:38 2007 From: gnewsg at gmail.com (Giampaolo Rodola') Date: Fri, 23 Nov 2007 10:37:38 -0800 (PST) Subject: [Python-Dev] ssl module integration with asyncore Message-ID: Hi there, since ssl module is still in development I thought it would have been better asking such question here instead of on comp.lang.python. I'm interested in using the ssl module with asyncore but since there's no real documentation about it yet I've been not able to write something useful with it. Currently I'm trying to add the SSL support to an asyncore-based FTP server I wrote. I tried to write some code by watching the ssl-related test-suite scripts with no luck since there are no available tests for asyncore available. I tried to play with the wrap_socket() function a little bit but different type of errors are raised every time. I'm sure this happens because I'm not doing things in the right way. Could someone please show me an example code about how the ssl module could be integrated with asyncore? From gnewsg at gmail.com Fri Nov 23 20:07:26 2007 From: gnewsg at gmail.com (Giampaolo Rodola') Date: Fri, 23 Nov 2007 11:07:26 -0800 (PST) Subject: [Python-Dev] ssl module integration with asyncore Message-ID: <8e0e2e0a-fdb4-49b9-9b17-92ec85dab642@r31g2000hsg.googlegroups.com> Hi there, since ssl module is still in development I thought it would have been better asking such question here instead of on comp.lang.python. I'm interested in using the ssl module with asyncore but since there's no real documentation about it yet I've been not able to write something useful with it. Currently I'm trying to add the SSL support to an asyncore-based FTP server I wrote. I tried to write some code by watching the ssl-related test-suite scripts with no luck since there are no available tests for asyncore available. I tried to play with the wrap_socket() function a little bit but different types of error are raised every time. I'm sure this happens because I'm not doing things in the right way. Could someone please show me an example code about how the ssl module could be integrated with asyncore? From p.f.moore at gmail.com Fri Nov 23 20:25:43 2007 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 23 Nov 2007 19:25:43 +0000 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <4747133D.8010907@egenix.com> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> <4746F8E4.2090207@cheimes.de> <47470497.4050203@egenix.com> <47471071.6030304@cheimes.de> <4747133D.8010907@egenix.com> Message-ID: <79990c6b0711231125r543e5c69ic80c242aaf0816e6@mail.gmail.com> On 23/11/2007, M.-A. Lemburg wrote: > On 2007-11-23 18:40, Christian Heimes wrote: > > M.-A. Lemburg wrote: > >> Why not include the prebuilt libraries of all external libs in SVN > >> as well ? > > > > For one I'm still using Beta 2 of the standard edition and I'm not > > allowed to distribute binaries build with the Beta. With the new > > pre-build steps it's also very easy to build the dependencies. I don't > > like to add more binaries to the svn repos. > > Fair enough - was just thinking that people compiling Python > on Windows are probably more interested in compiling the Python > code itself, rather than getting the 3rd party tools to compile :-) I'd agree with that, but for the ones I've tried so far, Christian has made it simple enough that it's not really an issue - you simply svn export the externals, and then the build just works. It's possible that TCL/Tk may be harder (particularly as there are 3 packages, TCL, Tk and Tix) - if so, then having binaries for that may be useful. But for the rest, it makes little difference. Paul. From p.f.moore at gmail.com Fri Nov 23 23:12:34 2007 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 23 Nov 2007 22:12:34 +0000 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <4746F8E4.2090207@cheimes.de> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> <4746F8E4.2090207@cheimes.de> Message-ID: <79990c6b0711231412j1f5da2f5r6fec302c03c4003c@mail.gmail.com> On 23/11/2007, Christian Heimes wrote: > bsddb is automatically build by a build step. But you have to convert > the project files in build_win32 to VS 2008 first. Simply open the > solution file and let VS convert the projects. VS 2008 Express doesn't have a devenv command, so the pre-link step doesn't work. You need to open the bsddb project file, and build db_static by hand. For a debug Python, you need the Debug configuration, for a release Python you need the Release configuration. Beware - the default config is Debug_ASCII which is not checked by the pre-link step. So, from a checkout of Python, plus the various svn externals: - dowload nasm, install it somewhere on your PATH, and copy nasm.exe to nasmw.exe (Why did you use nasmw.exe rather than nasm.exe? Is there a difference in the version you have?) - Open the bsddb solution file, and build debug and release versions of db_static - Open the Python pcbuild solution file, and build the solution. You'll get a total of 2 failures and 18 successes. Of the failures, one (_sqlite3) is not actually fatal (the pre-link step fails, and that only the first time), and the module is actually built correctly. The other is _tkinter, which isn't sorted out yet. You can then run the tests with rt.bat. If you have an openssl.exe on your path, test_socket_ssl may hang. Otherwise, everything should pass, apart from test_tcl. (Actually, there's a failure in test_doctest right now, seems to have come in with r59137, but I don't have time to diagnose right now). This is the case for both trunk and py3k (ignoring genuine test failures). Paul. From greg.ewing at canterbury.ac.nz Sat Nov 24 00:38:54 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sat, 24 Nov 2007 12:38:54 +1300 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: <20071123130432.A30F53A40AC@sparrow.telecommunity.com> References: <47461B74.4050409@canterbury.ac.nz> <20071123021416.E68713A40AC@sparrow.telecommunity.com> <474679C3.6040703@canterbury.ac.nz> <20071123130432.A30F53A40AC@sparrow.telecommunity.com> Message-ID: <4747648E.6080401@canterbury.ac.nz> Phillip J. Eby wrote: > class MoneyField(Field): > # does need staticmethod because two_decimal_places > # doesn't take a self > converter = staticmethod(two_decimal_places) Okay, I see what you mean now. But you could just as well wrap it in a function that takes self and discards it, so I still don't think staticmethod is essential in the absence of unbound methods. Not that I would object if it stayed around -- I don't really mind one way or the other. -- Greg From martin at v.loewis.de Sat Nov 24 00:50:54 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 24 Nov 2007 00:50:54 +0100 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <79990c6b0711231412j1f5da2f5r6fec302c03c4003c@mail.gmail.com> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> <4746F8E4.2090207@cheimes.de> <79990c6b0711231412j1f5da2f5r6fec302c03c4003c@mail.gmail.com> Message-ID: <4747675E.40103@v.loewis.de> > VS 2008 Express doesn't have a devenv command Can you please try out whether the buildbot commands have any chance to work with the Express edition? Buildbot operators will have to install VS 2008 one way or the other, and it would be nice if you could provide instructions for them what precisely to install, in what order, to make it work. Currently, the build slaves run, in order Tools\buildbot\build.bat Tools\buildbot\test.bat Tools\buildbot\clean.bat These will of course need to be adjusted after a switchover, but they heavily rely on devenv.com working. Regards, Martin From greg.ewing at canterbury.ac.nz Sat Nov 24 00:48:48 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sat, 24 Nov 2007 12:48:48 +1300 Subject: [Python-Dev] Backquote deprecation warning In-Reply-To: References: Message-ID: <474766E0.4020504@canterbury.ac.nz> Christian Heimes wrote: > Should the node structure gain an additional field to drag the filename > around? Why not? Early on in the design of the Pyrex compiler, I made the decision that every parse tree node would contain a source filename and position, down to character resolution. It's paid off enormously, as I can produce highly pinpointed error messages for just about anything at any stage of processing. -- Greg From brett at python.org Sat Nov 24 00:44:31 2007 From: brett at python.org (Brett Cannon) Date: Fri, 23 Nov 2007 15:44:31 -0800 Subject: [Python-Dev] test_doctest failing Message-ID: Looks like Skip's r59137 fix for working with tracing has led to test_doctest to be broken on 2.5 and the trunk (at least according to the buildbots). Can someone either revert the commit or fix it? I would normally do it myself but US Thanksgiving has me tied up to not do too much beyond bitching about the amount of buildbot emails I have been getting. =) -Brett From martin at v.loewis.de Sat Nov 24 01:24:17 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 24 Nov 2007 01:24:17 +0100 Subject: [Python-Dev] Backquote deprecation warning In-Reply-To: References: Message-ID: <47476F31.7010307@v.loewis.de> > Should the node structure gain an additional field to drag the filename > around? Or can we simply life with the fact that the user won't get a > filename in the deprecation warning? I think struct compiling should carry the file name, starting in PyAST_FromNode. Regards, Martin From lists at cheimes.de Sat Nov 24 02:37:10 2007 From: lists at cheimes.de (Christian Heimes) Date: Sat, 24 Nov 2007 02:37:10 +0100 Subject: [Python-Dev] Backquote deprecation warning In-Reply-To: <47476F31.7010307@v.loewis.de> References: <47476F31.7010307@v.loewis.de> Message-ID: <47478046.5090806@cheimes.de> Martin v. L?wis wrote: > I think struct compiling should carry the file name, starting in > PyAST_FromNode. Thanks! I was trying to add the filename to node but it required too many changes. I really wonder why I wasn't touching the compiling struct. Christian From python at rcn.com Sat Nov 24 03:59:46 2007 From: python at rcn.com (Raymond Hettinger) Date: Fri, 23 Nov 2007 18:59:46 -0800 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? References: <47461B74.4050409@canterbury.ac.nz><20071123021416.E68713A40AC@sparrow.telecommunity.com> Message-ID: <002001c82e46$12f650e0$f938fea9@RaymondLaptop1> > It looks like we're in agreement to drop unbound methods +1 It is a bit cleaner to simply return the unmodified function. Raymond From skip at pobox.com Sat Nov 24 05:32:25 2007 From: skip at pobox.com (skip at pobox.com) Date: Fri, 23 Nov 2007 22:32:25 -0600 Subject: [Python-Dev] test_doctest failing In-Reply-To: References: Message-ID: <18247.43353.355163.692974@montanaro.dyndns.org> Brett> Looks like Skip's r59137 fix for working with tracing has led to Brett> test_doctest to be broken on 2.5 and the trunk (at least Brett> according to the buildbots). Can someone either revert the Brett> commit or fix it? I would normally do it myself but US Brett> Thanksgiving has me tied up to not do too much beyond bitching Brett> about the amount of buildbot emails I have been getting. =) Sorry. I did verify that it solved the problem I was having with trace & doctest, but I completely forgot to make test after applying that patch. The checkins have been reverted. Skip From ncoghlan at gmail.com Sat Nov 24 05:56:15 2007 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 24 Nov 2007 14:56:15 +1000 Subject: [Python-Dev] Decimal news: speedup and stabilization In-Reply-To: References: Message-ID: <4747AEEF.2010104@gmail.com> Facundo Batista wrote: > Mark Dickinson found out that a lot of time was lost internally in > decimal.py when dealing with the Decimal mantissas. > > He changed the way that mantissa was stored, from a tuple of ints, to > a plain string (each character a digit). This achieved a speedup of > around a 40%!!! Given the frequent conversion to and from long integers needed to actually do the calculations, I can actually see how that would be the case. Excellent news. Did you change the Decimal repr to use the same format for the mantissa? > > Three notes: > > - The speedup was measured using two tools I created [*], one > basically tries a lot of use cases, the other use the specification > test cases. Both generate a .py which actually measures the times. Could you also check the performance gain against the telco benchmark which is in the sandbox? [1] The 10-number file is checked into svn along with the test script, and the million-number file is available from Cowlishaw's decimal site [2]. Cheers, Nick. [1] http://svn.python.org/projects/sandbox/trunk/decimal/telco/ [2] http://www2.hursley.ibm.com/decimal/telco.html -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From guido at python.org Sat Nov 24 06:17:44 2007 From: guido at python.org (Guido van Rossum) Date: Fri, 23 Nov 2007 21:17:44 -0800 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: <47467D5C.6050502@cheimes.de> References: <47461B74.4050409@canterbury.ac.nz> <20071123021416.E68713A40AC@sparrow.telecommunity.com> <47467D5C.6050502@cheimes.de> Message-ID: On Nov 22, 2007 11:12 PM, Christian Heimes wrote: > Guido van Rossum wrote: > > It looks like we're in agreement to drop unbound methods and have a > > reasonable set or arguments around it (e.g. keep staticmethod, no > > changes to methods of builtin types, etc.). Do we need a PEP? It's > > essentially a 2-line change in funcobject.c (func_descr_get()) -- plus > > fixing up half a dozen or so unittests that specifically seem to test > > the behavior of unbound methods. > > I'd like to help but after staring at the code for 10 minutes I still > don't get how the descriptor function should be altered. Can you please > give an example to a mer mortal? :) Index: Objects/funcobject.c =================================================================== --- Objects/funcobject.c (revision 59154) +++ Objects/funcobject.c (working copy) @@ -643,8 +643,10 @@ static PyObject * func_descr_get(PyObject *func, PyObject *obj, PyObject *type) { - if (obj == Py_None) - obj = NULL; + if (obj == Py_None || obj == NULL) { + Py_INCREF(func); + return func; + } return PyMethod_New(func, obj, type); } [well, except those should be tabs not spaces] -- --Guido van Rossum (home page: http://www.python.org/~guido/) From titus at caltech.edu Sat Nov 24 07:44:01 2007 From: titus at caltech.edu (Titus Brown) Date: Fri, 23 Nov 2007 22:44:01 -0800 Subject: [Python-Dev] test_doctest failing In-Reply-To: <18247.43353.355163.692974@montanaro.dyndns.org> References: <18247.43353.355163.692974@montanaro.dyndns.org> Message-ID: <20071124064401.GD20996@caltech.edu> On Fri, Nov 23, 2007 at 10:32:25PM -0600, skip at pobox.com wrote: -> -> Brett> Looks like Skip's r59137 fix for working with tracing has led to -> Brett> test_doctest to be broken on 2.5 and the trunk (at least -> Brett> according to the buildbots). Can someone either revert the -> Brett> commit or fix it? I would normally do it myself but US -> Brett> Thanksgiving has me tied up to not do too much beyond bitching -> Brett> about the amount of buildbot emails I have been getting. =) -> -> Sorry. I did verify that it solved the problem I was having with trace & -> doctest, but I completely forgot to make test after applying that patch. -> The checkins have been reverted. Skip, this set_trace rewrite fixes the problem in both 25-maint and trunk: def set_trace(self, frame=None): self.__debugger_used = True if frame is None: frame = sys._getframe().f_back pdb.Pdb.set_trace(self, frame) from the old: def set_trace(self): self.__debugger_used = True pdb.Pdb.set_trace(self) This was an actual bug: the patch didn't correctly allow for the fact that Bdb.set_trace(self, None) went and got the calling frame -- which, when the function was overriden in a subclass, was the subclass function. Let me know if you want a formal patch or somethin'. And thanks for tackling the doctest/trace situation - some users have been complaining about it to me and it was on my list for tomorrow! Happy post-Thanksgiving, all! cheers, --titus From lists at cheimes.de Sat Nov 24 08:10:31 2007 From: lists at cheimes.de (Christian Heimes) Date: Sat, 24 Nov 2007 08:10:31 +0100 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: References: <47461B74.4050409@canterbury.ac.nz> <20071123021416.E68713A40AC@sparrow.telecommunity.com> <47467D5C.6050502@cheimes.de> Message-ID: <4747CE67.803@cheimes.de> Guido van Rossum wrote: > > Index: Objects/funcobject.c > =================================================================== > --- Objects/funcobject.c (revision 59154) > +++ Objects/funcobject.c (working copy) > @@ -643,8 +643,10 @@ > static PyObject * > func_descr_get(PyObject *func, PyObject *obj, PyObject *type) > { > - if (obj == Py_None) > - obj = NULL; > + if (obj == Py_None || obj == NULL) { > + Py_INCREF(func); > + return func; > + } > return PyMethod_New(func, obj, type); > } > > [well, except those should be tabs not spaces] I've created a preliminary patch. Several unit tests are still failing. The patch is also changing some semantics. For example in Python 2.5: >>> import inspect >>> class Class(object): ... def method(self): pass ... >>> inspect.ismethod(Class().method) True >>> inspect.ismethod(Class.method) True But in py3k: >>> import inspect >>> class Class: ... def method(self): pass ... >>> inspect.ismethod(Class().method) True >>> inspect.ismethod(Class.method) False # !!! Without support from the descriptor it's not possible to distinguish a function from an unbound method any more. I like to add im_class to the function object. I don't see negative side effects, do you? /* Bind a function to an object */ static PyObject * func_descr_get(PyObject *func, PyObject *obj, PyObject *type) { if (obj == Py_None || obj == NULL) { Py_INCREF(func); if (type) { PyObject_SetAttrString(func, "im_class", type); } else { PyObject_SetAttrString(func, "im_class", Py_None); } return func; } return PyMethod_New(func, obj, type); } http://bugs.python.org/issue1493 Christian From lists at cheimes.de Sat Nov 24 09:51:47 2007 From: lists at cheimes.de (Christian Heimes) Date: Sat, 24 Nov 2007 09:51:47 +0100 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: <4747CE67.803@cheimes.de> References: <47461B74.4050409@canterbury.ac.nz> <20071123021416.E68713A40AC@sparrow.telecommunity.com> <47467D5C.6050502@cheimes.de> <4747CE67.803@cheimes.de> Message-ID: <4747E623.7020102@cheimes.de> Christian Heimes wrote: > Without support from the descriptor it's not possible to distinguish a > function from an unbound method any more. I like to add im_class to the > function object. I don't see negative side effects, do you? OK, forget that. Pretend I've never said it. I shouldn't submit ideas until coffee shows its effect. Christian From mal at egenix.com Sat Nov 24 11:00:30 2007 From: mal at egenix.com (M.-A. Lemburg) Date: Sat, 24 Nov 2007 11:00:30 +0100 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <79990c6b0711231412j1f5da2f5r6fec302c03c4003c@mail.gmail.com> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> <4746F8E4.2090207@cheimes.de> <79990c6b0711231412j1f5da2f5r6fec302c03c4003c@mail.gmail.com> Message-ID: <4747F63E.9030806@egenix.com> On 2007-11-23 23:12, Paul Moore wrote: > On 23/11/2007, Christian Heimes wrote: >> bsddb is automatically build by a build step. But you have to convert >> the project files in build_win32 to VS 2008 first. Simply open the >> solution file and let VS convert the projects. > > VS 2008 Express doesn't have a devenv command, so the pre-link step > doesn't work. You need to open the bsddb project file, and build > db_static by hand. For a debug Python, you need the Debug > configuration, for a release Python you need the Release > configuration. Beware - the default config is Debug_ASCII which is not > checked by the pre-link step. > > So, from a checkout of Python, plus the various svn externals: > > - dowload nasm, install it somewhere on your PATH, and copy nasm.exe > to nasmw.exe (Why did you use nasmw.exe rather than nasm.exe? Is there > a difference in the version you have?) The OpenSSL build process still uses the old nasmw.exe name (the build instructions there are for the old NASM version, but it also works with the latest NASM release). The NASM project has recently changed the name of the executable to nasm.exe. > - Open the bsddb solution file, and build debug and release versions > of db_static > - Open the Python pcbuild solution file, and build the solution. > > You'll get a total of 2 failures and 18 successes. Of the failures, > one (_sqlite3) is not actually fatal (the pre-link step fails, and > that only the first time), and the module is actually built correctly. > The other is _tkinter, which isn't sorted out yet. > > You can then run the tests with rt.bat. If you have an openssl.exe on > your path, test_socket_ssl may hang. Otherwise, everything should > pass, apart from test_tcl. (Actually, there's a failure in > test_doctest right now, seems to have come in with r59137, but I don't > have time to diagnose right now). > > This is the case for both trunk and py3k (ignoring genuine test failures). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 24 2007) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From tom at vector-seven.com Thu Nov 22 01:07:12 2007 From: tom at vector-seven.com (Thomas Lee) Date: Thu, 22 Nov 2007 11:07:12 +1100 Subject: [Python-Dev] [python] Should we do away with unbound methods in Py3k? In-Reply-To: <4744C041.2030100@voidspace.org.uk> References: <4744C041.2030100@voidspace.org.uk> Message-ID: <4744C830.4050708@vector-seven.com> Michael Foord wrote: > Guido van Rossum wrote: > >> I'm asking a Py3k question on python-dev because I'd like to have >> opinions from people who haven't thought about Py3k much yet. Consider >> the following example: >> >> class C: >> def foo(self): pass >> >> C.foo(42) >> >> This currently fails with this error message: >> >> TypeError: unbound method foo() must be called with C instance as >> first argument (got int instance instead) >> >> This message is called when isinstance(self, C) returns False, where >> self is the first argument passed to the unbound method. >> >> That's nice, but there is a cost associated with this: the expression >> "C.foo" can't just return the function object "foo", it has to wrap it >> in an unbound method object. In Py3k the cost of calling an unbound >> method object goes up, because the isinstance() check may be >> overloaded. This typically happens when the class C uses the special >> metaclass (abc.ABCMeta) used for virtual inheritance (see PEP 3119). >> in Py3k the I/O stream classes are perhaps the most common use case. >> >> Given that the error is of limited value and that otherwise the >> unbound method behaves exactly the same as the original function >> object, I'd like to see if there are strenuous objections against >> dropping unbound method objects altogether (or at least not using them >> in this case), so that explicit super calls (via the unbound method) >> may go a little faster. Also, it would make it easier to fix this >> issue: http://bugs.python.org/issue1109 >> >> > > On occasions I've found it a drag that you *can't* call unbound methods > with a different type. Python normally allows duck typing and this is > one place it actually places type restrictions... > > I'd be happy to see this restriction go. :-) > > Michael Foord > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/krumms%40gmail.com > +1 to getting rid of unbound methods! From skip at pobox.com Sat Nov 24 15:35:34 2007 From: skip at pobox.com (skip at pobox.com) Date: Sat, 24 Nov 2007 08:35:34 -0600 Subject: [Python-Dev] test_doctest failing In-Reply-To: <20071124064401.GD20996@caltech.edu> References: <18247.43353.355163.692974@montanaro.dyndns.org> <20071124064401.GD20996@caltech.edu> Message-ID: <18248.14006.669114.215578@montanaro.dyndns.org> Titus> Skip, this set_trace rewrite fixes the problem in both 25-maint and Titus> trunk: ... Thanks, Titus. Both the doctest and trace tests pass with your change. Checked back in. I didn't run the full test suite, as test_sqlite causes a bus error on my Mac which I've yet to investigate. Titus> Let me know if you want a formal patch or somethin'. And thanks Titus> for tackling the doctest/trace situation - some users have been Titus> complaining about it to me and it was on my list for tomorrow! Actually, there was little tackling on my part. More like googling. I searched for "trace and doctest". The second hit was a patch against 2.4 from February 2006: http://bugs.python.org/issue1429818 I blindly applied the patches it contained, verified they solved the problems I was having, then checked it in. Again, my apologies to Brett and others for the buildbot breakage. Skip From guido at python.org Sat Nov 24 18:56:40 2007 From: guido at python.org (Guido van Rossum) Date: Sat, 24 Nov 2007 09:56:40 -0800 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: <4747CE67.803@cheimes.de> References: <47461B74.4050409@canterbury.ac.nz> <20071123021416.E68713A40AC@sparrow.telecommunity.com> <47467D5C.6050502@cheimes.de> <4747CE67.803@cheimes.de> Message-ID: On Nov 23, 2007 11:10 PM, Christian Heimes wrote: > Guido van Rossum wrote: > > > > Index: Objects/funcobject.c > > =================================================================== > > --- Objects/funcobject.c (revision 59154) > > +++ Objects/funcobject.c (working copy) > > @@ -643,8 +643,10 @@ > > static PyObject * > > func_descr_get(PyObject *func, PyObject *obj, PyObject *type) > > { > > - if (obj == Py_None) > > - obj = NULL; > > + if (obj == Py_None || obj == NULL) { > > + Py_INCREF(func); > > + return func; > > + } > > return PyMethod_New(func, obj, type); > > } > > > > [well, except those should be tabs not spaces] > > I've created a preliminary patch. Several unit tests are still failing. Thanks for the patch! Now I'm hoping someone will look into those remaining six test failures. Also, there was discussion of this before: http://mail.python.org/pipermail/python-dev/2005-January/050625.html -- why didn't we decide to do it then? > The patch is also changing some semantics. For example in Python 2.5: > > >>> import inspect > >>> class Class(object): > ... def method(self): pass > ... > >>> inspect.ismethod(Class().method) > True > >>> inspect.ismethod(Class.method) > True > > But in py3k: > > >>> import inspect > >>> class Class: > ... def method(self): pass > ... > >>> inspect.ismethod(Class().method) > True > >>> inspect.ismethod(Class.method) > False # !!! As it should be. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From nd at perlig.de Sat Nov 24 19:06:30 2007 From: nd at perlig.de (=?iso-8859-1?q?Andr=E9_Malo?=) Date: Sat, 24 Nov 2007 19:06:30 +0100 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: <4747648E.6080401@canterbury.ac.nz> References: <20071123130432.A30F53A40AC@sparrow.telecommunity.com> <4747648E.6080401@canterbury.ac.nz> Message-ID: <200711241906.30828@news.perlig.de> * Greg Ewing wrote: > Phillip J. Eby wrote: > > class MoneyField(Field): > > # does need staticmethod because two_decimal_places > > # doesn't take a self > > converter = staticmethod(two_decimal_places) > > Okay, I see what you mean now. But you could just as well wrap > it in a function that takes self and discards it, I always thought, that this is exactly what staticmethod does. > so I still > don't think staticmethod is essential in the absence of > unbound methods. Actually I don't see why those issues were bound together in the first place. nd -- Winnetous Erbe: From pje at telecommunity.com Sat Nov 24 19:22:04 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Sat, 24 Nov 2007 13:22:04 -0500 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: References: <47461B74.4050409@canterbury.ac.nz> <20071123021416.E68713A40AC@sparrow.telecommunity.com> <47467D5C.6050502@cheimes.de> <4747CE67.803@cheimes.de> Message-ID: <20071124182207.00C7A3A40AC@sparrow.telecommunity.com> At 09:56 AM 11/24/2007 -0800, Guido van Rossum wrote: >Also, there was discussion of this before: >http://mail.python.org/pipermail/python-dev/2005-January/050625.html >-- why didn't we decide to do it then? http://mail.python.org/pipermail/python-dev/2005-January/051236.html There were also a few protests of use cases that could not be worked around (e.g. pickling methods), and a few people pointed out that the type checking actually *is* useful when using explicit base calls (BaseClass.somemethod(self,...)), as it usually catches when you forget to include the self argument.) (Note that super() doesn't do away with the need for such explicit upcalls, especially in __init__, as multiple-inheriting classes with non-cooperative bases usually need to individually call the base class __init__ methods.) From guido at python.org Sat Nov 24 19:23:06 2007 From: guido at python.org (Guido van Rossum) Date: Sat, 24 Nov 2007 10:23:06 -0800 Subject: [Python-Dev] test_doctest failing In-Reply-To: <18248.14006.669114.215578@montanaro.dyndns.org> References: <18247.43353.355163.692974@montanaro.dyndns.org> <20071124064401.GD20996@caltech.edu> <18248.14006.669114.215578@montanaro.dyndns.org> Message-ID: On Nov 24, 2007 6:35 AM, wrote: > Thanks, Titus. Both the doctest and trace tests pass with your change. > Checked back in. I didn't run the full test suite, as test_sqlite causes a > bus error on my Mac which I've yet to investigate. It's easy though to run all tests *except* a known failure: .../runtest.py -x test_sqline -- --Guido van Rossum (home page: http://www.python.org/~guido/) From titus at caltech.edu Sat Nov 24 22:57:56 2007 From: titus at caltech.edu (Titus Brown) Date: Sat, 24 Nov 2007 13:57:56 -0800 Subject: [Python-Dev] test_doctest failing In-Reply-To: References: <18247.43353.355163.692974@montanaro.dyndns.org> <20071124064401.GD20996@caltech.edu> <18248.14006.669114.215578@montanaro.dyndns.org> Message-ID: <20071124215756.GA15036@caltech.edu> On Sat, Nov 24, 2007 at 10:23:06AM -0800, Guido van Rossum wrote: -> On Nov 24, 2007 6:35 AM, wrote: -> > Thanks, Titus. Both the doctest and trace tests pass with your change. -> > Checked back in. I didn't run the full test suite, as test_sqlite causes a -> > bus error on my Mac which I've yet to investigate. -> -> It's easy though to run all tests *except* a known failure: -> .../runtest.py -x test_sqline Just to make sure ... do you mean regrtest? ./python Lib/test/regrtest.py -x test_sqlite ? (There's no 'runtest.py' in the trunk, and 'runtests.py' exists under Lib/ctypes/.) --titus From tjreedy at udel.edu Sat Nov 24 23:19:19 2007 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 24 Nov 2007 17:19:19 -0500 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? References: <47461B74.4050409@canterbury.ac.nz><20071123021416.E68713A40AC@sparrow.telecommunity.com><47467D5C.6050502@cheimes.de><4747CE67.803@cheimes.de> Message-ID: "Guido van Rossum" wrote in message news:ca471dc20711240956l28254408v51f404e181ab064a at mail.gmail.com... | Also, there was discussion of this before: | http://mail.python.org/pipermail/python-dev/2005-January/050625.html | -- why didn't we decide to do it then? 1. Nobody ran with it. 2. There was mild concern with breaking 2.x code. From greg.ewing at canterbury.ac.nz Sat Nov 24 23:55:38 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sun, 25 Nov 2007 11:55:38 +1300 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: <200711241906.30828@news.perlig.de> References: <20071123130432.A30F53A40AC@sparrow.telecommunity.com> <4747648E.6080401@canterbury.ac.nz> <200711241906.30828@news.perlig.de> Message-ID: <4748ABEA.5080607@canterbury.ac.nz> Andr? Malo wrote: > * Greg Ewing wrote: > > > But you could just as well wrap > > it in a function that takes self and discards it, > > I always thought, that this is exactly what staticmethod does. Not quite -- staticmethod prevents a self from getting passed in the first place, so there's no need to discard it. Which is probably slightly more efficient, but if unbound methods had never been invented in the first place, I doubt that staticmethod would have been created just for that reason. The other thing about staticmethod is that it makes it possible to call the method via either a class or an instance, but I've never found a real need for that in anything I've written or seen. -- Greg From brett at python.org Sun Nov 25 03:56:59 2007 From: brett at python.org (Brett Cannon) Date: Sat, 24 Nov 2007 18:56:59 -0800 Subject: [Python-Dev] test_doctest failing In-Reply-To: <20071124215756.GA15036@caltech.edu> References: <18247.43353.355163.692974@montanaro.dyndns.org> <20071124064401.GD20996@caltech.edu> <18248.14006.669114.215578@montanaro.dyndns.org> <20071124215756.GA15036@caltech.edu> Message-ID: On Nov 24, 2007 1:57 PM, Titus Brown wrote: > On Sat, Nov 24, 2007 at 10:23:06AM -0800, Guido van Rossum wrote: > -> On Nov 24, 2007 6:35 AM, wrote: > -> > Thanks, Titus. Both the doctest and trace tests pass with your change. > -> > Checked back in. I didn't run the full test suite, as test_sqlite causes a > -> > bus error on my Mac which I've yet to investigate. > -> > -> It's easy though to run all tests *except* a known failure: > -> .../runtest.py -x test_sqline > > Just to make sure ... do you mean regrtest? > > ./python Lib/test/regrtest.py -x test_sqlite > > ? Yep, he means regrtest. I really need to write a "How to run and write unit test for Python and its Standard Library" some day. -Brett From ncoghlan at gmail.com Sun Nov 25 04:36:26 2007 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 25 Nov 2007 13:36:26 +1000 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: References: <47461B74.4050409@canterbury.ac.nz> <20071123021416.E68713A40AC@sparrow.telecommunity.com> <47467D5C.6050502@cheimes.de> <4747CE67.803@cheimes.de> Message-ID: <4748EDBA.5010100@gmail.com> Guido van Rossum wrote: > > Also, there was discussion of this before: > http://mail.python.org/pipermail/python-dev/2005-January/050625.html > -- why didn't we decide to do it then? Skimming that thread, the issues seem to be: - worse error messages from explicit base class calls if you forget to supply self - breaking code that uses im_func, im_class, im_self This led to a mixture of a few +1's and several -0's, so it didn't happen. Py3k severely reduces the weight of the latter objection though, and we can use the Py3k warnings feature in 2.6 to complain if any code attempts to access im_self, im_class or im_func on an instancemethod object when im_class is None. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From lists at cheimes.de Sun Nov 25 10:46:24 2007 From: lists at cheimes.de (Christian Heimes) Date: Sun, 25 Nov 2007 10:46:24 +0100 Subject: [Python-Dev] Should we do away with unbound methods in Py3k? In-Reply-To: References: <47461B74.4050409@canterbury.ac.nz> <20071123021416.E68713A40AC@sparrow.telecommunity.com> <47467D5C.6050502@cheimes.de> <4747CE67.803@cheimes.de> Message-ID: <47494470.5070703@cheimes.de> Guido van Rossum wrote: > Thanks for the patch! Now I'm hoping someone will look into those > remaining six test failures. The tooth fairy has left a present for you, Guido. Georg has fixed 5 of the remaining bugs and I got test_unittest working this morning. Christian From muehlenhoff at univention.de Mon Nov 26 11:57:44 2007 From: muehlenhoff at univention.de (Moritz =?utf-8?q?M=C3=BChlenhoff?=) Date: Mon, 26 Nov 2007 11:57:44 +0100 Subject: [Python-Dev] Possible error in Python 2.4 garbage collector Message-ID: <200711261157.44836.muehlenhoff@univention.de> Hi, we're running into a problem with the Python interpreter, which we suspect triggers a bug in the garbage collector or a related part of the memory management. We are using Python 2.4.4 in the version from Debian 4.0. Our C application imports various Python plugins using PyNode_Compile(). This used to work very well (it's a feature we've been using for years now), but if we import more than 23 modules we're running a segmentation fault with the backtrace below: (gdb) bt #0 0xb7ee9cad in visit_decref (op=0xb7287ec0, data=0x0) at ../Modules/gcmodule.c:269 #1 0xb7e716d1 in list_traverse (o=0xb724e62c, visit=0xb7ee9ca0 , arg=0x0) at ../Objects/listobject.c:2280 #2 0xb7eea729 in collect (generation=0) at ../Modules/gcmodule.c:294 #3 0xb7eeb0a3 in _PyObject_GC_Malloc (basicsize=20) at ../Modules/gcmodule.c:872 #4 0xb7eeb0eb in _PyObject_GC_NewVar (tp=0xb7f25720, nitems=2) at ../Modules/gcmodule.c:1283 #5 0xb7e913e4 in PyTuple_New (size=2) at ../Objects/tupleobject.c:68 #6 0xb7e91bb5 in PyTuple_Pack (n=2) at ../Objects/tupleobject.c:143 #7 0xb7ebfded in com_add (c=0xbfc5d3ac, list=0x0, dict=0xb7ee9ca0, v=0xb770fc20) at ../Python/compile.c:1375 #8 0xb7ec4b1e in com_addop_varname (c=0xbfc5d3ac, kind=0, name=0xb71f9218 "new") at ../Python/compile.c:1410 #9 0xb7ecea53 in com_atom (c=0xbfc5d3ac, n=0xb71f8ca0) at ../Python/compile.c:2213 #10 0xb7ecefe0 in com_power (c=0x70732f72, n=0xb71fb5c0) at ../Python/compile.c:2587 #11 0xb7ecf4c3 in com_term (c=0x70732f72, n=0xb71fb590) at ../Python/compile.c:2727 #12 0xb7ecf639 in com_shift_expr (c=0xbfc5d3ac, n=0xb71fb560) at ../Python/compile.c:2762 #13 0xb7ecf924 in com_xor_expr (c=0x70732f72, n=0xb71fb530) at ../Python/compile.c:2814 #14 0xb7ec5064 in com_comparison (c=0x70732f72, n=0xb71fb2a8) at ../Python/compile.c:2858 #15 0xb7ec5e5a in com_test (c=0xbfc5d3ac, n=0xb71f8714) at ../Python/compile.c:2986 #16 0xb7eca88a in com_if_stmt (c=0xbfc5d3ac, n=0xb71fb278) at ../Python/compile.c:3844 #17 0xb7ec9101 in com_node (c=0xbfc5d3ac, n=0xb71f4d2c) at ../Python/compile.c:4181 #18 0xb7eca926 in com_if_stmt (c=0xbfc5d3ac, n=0xb71f7398) at ../Python/compile.c:3848 #19 0xb7ec9101 in com_node (c=0xbfc5d3ac, n=0xb720a688) at ../Python/compile.c:4181 #20 0xb7ecd1af in com_try_except (c=0xbfc5d3ac, n=0xb71f5728) at ../Python/compile.c:3998 #21 0xb7ec9101 in com_node (c=0xbfc5d3ac, n=0xb722ecdc) at ../Python/compile.c:4181 #22 0xb7eca926 in com_if_stmt (c=0xbfc5d3ac, n=0xb71dcb60) at ../Python/compile.c:3848 #23 0xb7ec9101 in com_node (c=0xbfc5d3ac, n=0xb71d8318) at ../Python/compile.c:4181 #24 0xb7ecac18 in com_if_stmt (c=0xbfc5d3ac, n=0xb71d4110) at ../Python/compile.c:3855 #25 0xb7ec9101 in com_node (c=0xbfc5d3ac, n=0xb737c610) at ../Python/compile.c:4181 #26 0xb7ec6d4c in compile_node (c=0xbfc5d3ac, n=) at ../Python/compile.c:4755 #27 0xb7ec7e80 in jcompile (n=0xb71d4098, filename=, base=0xbfc5d72c, flags=0x0) at ../Python/compile.c:5006 #28 0xb7ec8776 in com_funcdef (c=0xbfc5d72c, n=0xb71d4098) at ../Python/compile.c:4942 #29 0xb7ec6c8e in compile_node (c=0xbfc5d72c, n=) at ../Python/compile.c:4728 #30 0xb7ec7e80 in jcompile (n=0xb7341668, filename=, base=0x0, flags=0x0) at ../Python/compile.c:5006 #31 0xb7ec86ca in PyNode_Compile (n=0xb71a58f0, filename=0x82d5aa0 "/usr/lib/univention-directory-listener/system/cyrus-sieve.py") at ../Python/compile.c:4913 #32 0x0804e5de in module_import (filename=0x82d5aa0 "/usr/lib/univention-directory-listener/system/cyrus-sieve.py") at handlers.c:98 #33 0x0804ec6e in handler_import (filename=0x82d5aa0 "/usr/lib/univention-directory-listener/system/cyrus-sieve.py") at handlers.c:184 #34 0x0804fb37 in handlers_load_path (path=0x8062130 "/usr/lib/univention-directory-listener/system") at handlers.c:472 #35 0x0804fbc0 in handlers_load_all_paths () at handlers.c:491 #36 0x0804fff0 in handlers_init () at handlers.c:568 #37 0x0804bfb9 in main (argc=16, argv=0xbfc5dce4) at main.c:489 (gdb) Given the function names I would suspect a bug in the garbage collector? I'm not familiar with the internals of Python's memory managent, so I can't really tell for sure. It could also be that some default internal limits of the memory manager are triggered. Shall I open a bug in the tracker for this does anyone suspect a different cause or even a workaround? Cheers, Moritz -- Moritz Muehlenhoff muehlenhoff at univention.de fon: +49 421 22 232- 0 Development Linux for Your Business fax: +49 421 22 232-99 Univention GmbH http://www.univention.de/ mobil: +49 175 22 999 23 From kristjan at ccpgames.com Mon Nov 26 16:16:50 2007 From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=) Date: Mon, 26 Nov 2007 15:16:50 +0000 Subject: [Python-Dev] Possible error in Python 2.4 garbage collector In-Reply-To: <200711261157.44836.muehlenhoff@univention.de> References: <200711261157.44836.muehlenhoff@univention.de> Message-ID: <4E9372E6B2234D4F859320D896059A950F9402C30D@exchis.ccp.ad.local> This is almost certainly not a bug in python. A cursory look indicates that a list being traversed in list_traverse has a NULL member. I'd suggest examining the other members of the list to figure out what this list is. Use the debugger for this, that is what it is for. It is probably a list you have created in your C code but forgot to check for exceptions when adding members to it, thus leaving one of them with a NULL pointer. see for example http://wiki.python.org/moin/DebuggingWithGdb for tips on debugging. K > -----Original Message----- > From: python-dev-bounces+kristjan=ccpgames.com at python.org > [mailto:python-dev-bounces+kristjan=ccpgames.com at python.org] On Behalf > Of Moritz M?hlenhoff > Sent: Monday, November 26, 2007 10:58 > To: python-dev at python.org; muehlenhoff at univention.de > Subject: [Python-Dev] Possible error in Python 2.4 garbage collector > > Hi, > we're running into a problem with the Python interpreter, which we > suspect > triggers a bug in the garbage collector or a related part of the memory > management. We are using Python 2.4.4 in the version from Debian 4.0. > > Our C application imports various Python plugins using > PyNode_Compile(). > This used to work very well (it's a feature we've been using for years > now), > but if we import more than 23 modules we're running a segmentation > fault with > the backtrace below: > > (gdb) bt > #0 0xb7ee9cad in visit_decref (op=0xb7287ec0, data=0x0) > at ../Modules/gcmodule.c:269 > #1 0xb7e716d1 in list_traverse (o=0xb724e62c, visit=0xb7ee9ca0 > , arg=0x0) at ../Objects/listobject.c:2280 > #2 0xb7eea729 in collect (generation=0) at ../Modules/gcmodule.c:294 > #3 0xb7eeb0a3 in _PyObject_GC_Malloc (basicsize=20) > at ../Modules/gcmodule.c:872 From arkanes at gmail.com Mon Nov 26 17:21:53 2007 From: arkanes at gmail.com (Chris Mellon) Date: Mon, 26 Nov 2007 10:21:53 -0600 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> Message-ID: <4866bea60711260821q6c63be6fhdced80d5a37d54e4@mail.gmail.com> On Nov 23, 2007 8:53 AM, Paul Moore wrote: > I have just built the current trunk version of Python on Windows, > using the new PCBuild9 directory, and Visual Studio 2008 Express > Edition. > > Everything went extremely well. I include below my notes on what I > did, for reference. To be honest, there's nothing in here that really > warrants a change to the readme.txt - to all intents and purposes, the > process "just works". > > OK, here are my notes: > > Install Visual C++ 2008 Express Edition. Only select Silverlight from > the options (no documentation or SQL Server - Silverlight probably > isn't actually needed either). > I already had the Platform SDK installed, but did nothing to tell VS > about it, or to integrate it. I doubt this is relevant. > > I am using Python trunk at revision 59132. (But I hit an issue fixed > in 59136, so better to use that). > > Start VC. > Open project PCBuild9\pcbuild.sln > Message "Solution Folders are not supported in this version of Visual > Studio. Solution folder 'Solution Items' will be displayed as > unavailable." Select OK. > > Select the release build (Build > Configuration Manager) > > Right click pythoncore > Build > make_buildinfo - succeeded 1 warning (unlink vs _unlink) > make_versioninfo - succeeded > pythoncore - I hit an error in ast.c so I needed to svn up (to > 59136). Succeeded. > > Right click python > Build. Succeeded. > Right click pythonw > Build. Succeeded. > Right click _socket > Build. Succeeded. > Right click _testcapi > Build. Succeeded. > Right click pyexpat > Build. Succeeded. > Right click select > Build. Succeeded. > Right click unicodedata > Build. Succeeded. > Right click winsound > Build. Succeeded. > > At this point, we have finished the modules documented as "build out > of the box" in PCBuild9\readme.txt. > > The modules _tkinter, bz2, _bsddb, _sqlite3, _ssl are documented as > having dependencies. See below. > > Modules _ctypes, _ctypes_test, _elementtree, _msi, w9xpopen are not > mentioned in readme.txt. They all build without error. > > bz2 > --- > > The include dir is a macro, and I can't work out how to override the > default (which is bzip2-1.0.3). So I stuck to 1.0.3 and exported it > from Python svn, as per the instructions. > > Built OK. > > _sqlite3 > -------- > > Again, couldn't work out how to change the macro, so I stuck with the > external from svn (sqlite-source-3.3.4). > > The pre-link step failed with an error about not finding TCL. I edited > the prelink step to include a /DNO_TCL flag on the cl command. There > may be a better approach - I don't know if not having TCL is an issue > for Python's use of sqlite. > > _tkinter and _bsddb > ------------------- > > The instructions suggest using VS 2003 to build the dependencies. I > don't have VS 2003 and don't have the time at the moment to > investigate further. > > _ssl > ---- > > Christian has been making changes to allow this to build without Perl, > so I gave it a try. I used openssl 0.9.8g, which I extracted to the > build directory (I noticed afterwards that this is the same version as > in Python svn, so I could have used the svn external!) > > I needed to download nasm (nasm.sf.net) version 2.00rc1, and rename > nasm.exe to nasmw.exe and put it on my PATH. > > Build succeeded, no issues. > > Tests > ----- > > Running the tests, all succeed except test_tcl and test_bsddb, which > are because I didn't build those two extensions, and test_os. The > test_os failure is just because it looks for C:\pagefile.sys and my > pagefile is on D:\. > > (There's also a problem with test_socket_ssl hanging, but this is > present in the standard 2.6 snapshot build. I've raised a separate bug > report for this). > I was able to build both 2.6 and py3k (trunk checkouts, revision 59136 and 59130 respectively) out of the box, except for openssl and tcl, which I didn't try to install. The external libraries I placed as sibling directories to the python source root dir, just as with the previous PCBuild instructions. I didn't need to build in any specific order, "Build solution" correctly resolved dependencies. I got the alert box about solution folders but it didn't harm anything. If anyone is curious, I ran pybench for both 2.6 and 3k build against VS 2003 and VS 2008. This is using the out of the box settings, and no PGO for 2008 (Express version doesn't have it). MSVC 9 was slightly faster for 2.6, but somewhat slower for py3k. I'm not sure how relevant that is, but (surprisingly to me) it's not an automatic speed win over MSVC 7.1. The results of my pybench runs available here: http://code.google.com/p/wxpsvg/wiki/PyBenchRuns From muehlenhoff at univention.de Mon Nov 26 17:27:45 2007 From: muehlenhoff at univention.de (Moritz =?iso-8859-1?q?M=FChlenhoff?=) Date: Mon, 26 Nov 2007 17:27:45 +0100 Subject: [Python-Dev] Possible error in Python 2.4 garbage collector In-Reply-To: <4E9372E6B2234D4F859320D896059A950F9402C30D@exchis.ccp.ad.local> References: <200711261157.44836.muehlenhoff@univention.de> <4E9372E6B2234D4F859320D896059A950F9402C30D@exchis.ccp.ad.local> Message-ID: <200711261727.45778.muehlenhoff@univention.de> Kristj?n Valur J?nsson wrote: > This is almost certainly not a bug in python. > A cursory look indicates that a list being traversed in list_traverse has a > NULL member. I'd suggest examining the other members of the list to figure > out what this list is. Use the debugger for this, that is what it is for. > It is probably a list you have created in your C code but forgot to check > for exceptions when adding members to it, thus leaving one of them with a > NULL pointer. Thank you for your comment. A longer debugging session showed a stray Py_DECREF in an unexpected code path, which lead to the error above. The Python GC is indeed fine. Thanks, Moritz -- Moritz Muehlenhoff muehlenhoff at univention.de fon: +49 421 22 232- 0 Development Linux for Your Business fax: +49 421 22 232-99 Univention GmbH http://www.univention.de/ mobil: +49 175 22 999 23 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20071126/fc103544/attachment.htm From lists at cheimes.de Mon Nov 26 18:14:36 2007 From: lists at cheimes.de (Christian Heimes) Date: Mon, 26 Nov 2007 18:14:36 +0100 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: <4866bea60711260821q6c63be6fhdced80d5a37d54e4@mail.gmail.com> References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> <4866bea60711260821q6c63be6fhdced80d5a37d54e4@mail.gmail.com> Message-ID: Chris Mellon wrote: > If anyone is curious, I ran pybench for both 2.6 and 3k build against > VS 2003 and VS 2008. This is using the out of the box settings, and no > PGO for 2008 (Express version doesn't have it). MSVC 9 was slightly > faster for 2.6, but somewhat slower for py3k. I'm not sure how > relevant that is, but (surprisingly to me) it's not an automatic speed > win over MSVC 7.1. The results of my pybench runs available here: I haven't enabled all optimization flags yet. We may get some speed ups by enable more flags. I leave that to the optimization experts. I'm glad that everybody is happy with the new PCbuild9 directory. Tcl/Tk is the last obstacle. I'm not able to build the 64bit version with the cross compiler of VS 2008 Standard Edition. Christian From janssen at parc.com Mon Nov 26 19:23:08 2007 From: janssen at parc.com (Bill Janssen) Date: Mon, 26 Nov 2007 10:23:08 PST Subject: [Python-Dev] ssl module integration with asyncore In-Reply-To: References: Message-ID: <07Nov26.102313pst."58696"@synergy1.parc.xerox.com> > Hi there, > since ssl module is still in development I thought it would have been > better asking such question here instead of on comp.lang.python. > I'm interested in using the ssl module with asyncore but since there's > no real documentation about it yet I've been not able to write > something useful with it. http://docs.python.org/dev/library/ssl.html -- it's not quite up-to-date, but close. > Currently I'm trying to add the SSL support to an asyncore-based FTP > server I wrote. > I tried to write some code by watching the ssl-related test-suite > scripts with no luck since there are no available tests for asyncore > available. Take a look at the SSL 1.12 test suite -- there's an asyncore-based server in there. > I tried to play with the wrap_socket() function a little bit but > different type of errors are raised every time. > I'm sure this happens because I'm not doing things in the right way. > Could someone please show me an example code about how the ssl module > could be integrated with asyncore? Hope that helps. Bill From martin at v.loewis.de Mon Nov 26 22:56:10 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 26 Nov 2007 22:56:10 +0100 Subject: [Python-Dev] Build Notes for building trunk with Visual Studio 2008 Express Edition In-Reply-To: References: <79990c6b0711230653x421cc894vd631968189f45a46@mail.gmail.com> <4866bea60711260821q6c63be6fhdced80d5a37d54e4@mail.gmail.com> Message-ID: <474B40FA.6050108@v.loewis.de> > I'm glad that everybody is happy with the new PCbuild9 directory. Tcl/Tk > is the last obstacle. I'm not able to build the 64bit version with the > cross compiler of VS 2008 Standard Edition. I'll look into it. I'll probably try to build some beta of Tcl 8.5, hoping that they manage to release Tcl/Tk 8.5 before Python gets released. Regards, Martin From gnewsg at gmail.com Tue Nov 27 01:06:06 2007 From: gnewsg at gmail.com (Giampaolo Rodola') Date: Mon, 26 Nov 2007 16:06:06 -0800 (PST) Subject: [Python-Dev] ssl module integration with asyncore In-Reply-To: <07Nov26.102313pst."58696"@synergy1.parc.xerox.com> References: <07Nov26.102313pst."58696"@synergy1.parc.xerox.com> Message-ID: On 26 Nov, 19:23, Bill Janssen wrote: > > Hi there, > > since ssl module is still in development I thought it would have been > > better asking such question here instead of on comp.lang.python. > > I'm interested in using the ssl module with asyncore but since there's > > no real documentation about it yet I've been not able to write > > something useful with it. > > http://docs.python.org/dev/library/ssl.html-- it's not quite up-to-date, > but close. > > > Currently I'm trying to add the SSL support to an asyncore-based FTP > > server I wrote. > > I tried to write some code by watching the ssl-related test-suite > > scripts with no luck since there are no available tests for asyncore > > available. > > Take a look at the SSL 1.12 test suite -- there's an asyncore-based > server in there. I downloaded this one: http://pypi.python.org/pypi/ssl/1.12 ...which seems to contain the same test-suite used in the current Python 2.6 distribution available here: http://svn.python.org/snapshots/ I looked into test/test_ssl.py but I didn't find any test referencing to the asyncore module. I see a class named "AsyncoreHTTPSServer" but it does not use the asyncore or asynchat modules. Or maybe... am I'm looking in the wrong place? From janssen at parc.com Tue Nov 27 02:47:34 2007 From: janssen at parc.com (Bill Janssen) Date: Mon, 26 Nov 2007 17:47:34 PST Subject: [Python-Dev] ssl module integration with asyncore In-Reply-To: References: <07Nov26.102313pst."58696"@synergy1.parc.xerox.com> Message-ID: <07Nov26.174736pst."58696"@synergy1.parc.xerox.com> > I downloaded this one: > http://pypi.python.org/pypi/ssl/1.12 Yes, that's the one. > ...which seems to contain the same test-suite used in the current Not quite. > Python 2.6 distribution available here: > http://svn.python.org/snapshots/ > I looked into test/test_ssl.py but I didn't find any test referencing > to the asyncore module. > I see a class named "AsyncoreHTTPSServer" but it does not use the > asyncore or asynchat modules. Yes, that's right, it uses SocketServer. But that's very close to the same thing. I'll change the name to make it clear. Really, the only interesting part is the "get_request" method, which overrides the "get_request" method from SocketServer.TCPServer, and is very similar to the asyncore.dispatcher "accept" method. You may also need to override the "readable" method on asyncore.dispatcher: def readable(self): if isinstance(self.socket, ssl.SSLSocket): # dispatch any bytes left in the SSL buffer while self.socket.pending() > 0: self.handle_read_event() return True Bill From facundobatista at gmail.com Tue Nov 27 17:41:14 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Tue, 27 Nov 2007 13:41:14 -0300 Subject: [Python-Dev] SSL tests are failing... Message-ID: ...in my machine with no Internet connection. I saw what's happening: there's a test in BasicTests that tries to access "svn.python.org". It's strange, because this test is an exact copy of the one in NetworkTest (but the latter is included only if the "network" resource is enabled). Seeing more in deep, I saw that Bill replaced in r58164, in this BasicTest, a lot of previous code (I think that from r57464) that actually tested it *locally*. Do you know if there's a good reason to this? I'm sure that making a network test if the resource is not available is not a good thing, and as the test is just repeated, it can be removed, but maybe this is part of a bigger mistake... that's why I'm asking. Thanks!! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From ijmorlan at cs.uwaterloo.ca Tue Nov 27 17:49:38 2007 From: ijmorlan at cs.uwaterloo.ca (Isaac Morland) Date: Tue, 27 Nov 2007 11:49:38 -0500 (EST) Subject: [Python-Dev] .pyc location? In-Reply-To: <4746EA40.2090706@gmx.de> References: <4746EA40.2090706@gmx.de> Message-ID: On Fri, 23 Nov 2007, Andreas Raab wrote: > I'd like to be able to specify an explicit location for the .pyc files. Me too, although for different reasons. I don't like my working directories being filled with clutter by programs. When I work in Java I always have javac aliased to use the -d option to put the .class files in a specific directory, and I set my CLASSPATH to refer to that directory. I end up with a java-src directory with a tree of .java files under it and a java-cls directory with .class files under it. I also get java-doc containing the output of javadoc. Something similar for Python would be very helpful for me. Isaac Morland CSCF Web Guru DC 2554C, x36650 WWW Software Specialist From janssen at parc.com Tue Nov 27 17:48:57 2007 From: janssen at parc.com (Bill Janssen) Date: Tue, 27 Nov 2007 08:48:57 PST Subject: [Python-Dev] SSL tests are failing... In-Reply-To: References: Message-ID: <07Nov27.084913pst."58696"@synergy1.parc.xerox.com> Which branch is this? Bill > Seeing more in deep, I saw that Bill replaced in r58164, in this > BasicTest, a lot of previous code (I think that from r57464) that > actually tested it *locally*. From facundobatista at gmail.com Tue Nov 27 17:51:56 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Tue, 27 Nov 2007 13:51:56 -0300 Subject: [Python-Dev] SSL tests are failing... In-Reply-To: <-2781936700889099881@unknownmsgid> References: <-2781936700889099881@unknownmsgid> Message-ID: 2007/11/27, Bill Janssen : > Which branch is this? The trunk, sorry. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From gnewsg at gmail.com Wed Nov 28 03:19:58 2007 From: gnewsg at gmail.com (Giampaolo Rodola') Date: Tue, 27 Nov 2007 18:19:58 -0800 (PST) Subject: [Python-Dev] ssl module integration with asyncore In-Reply-To: <07Nov26.174736pst."58696"@synergy1.parc.xerox.com> References: <07Nov26.102313pst."58696"@synergy1.parc.xerox.com> <07Nov26.174736pst."58696"@synergy1.parc.xerox.com> Message-ID: <33b2d8d1-ac00-49c9-8323-82c2fa1d3847@d21g2000prf.googlegroups.com> I tried to write a simple asyncore-based server code, then I used a simple client to establish a connection with it. Once the client is connected server raises the following exception: --- snippet --- C:\Documents and Settings\billiejoex\Desktop\test>test.py []127.0.0.1:3003 Connected. Traceback (most recent call last): File "C:\Documents and Settings\billiejoex\Desktop\test\test.py", line 40, in asyncore.loop(timeout=1) File "C:\Python26\lib\asyncore.py", line 191, in loop poll_fun(timeout, map) File "C:\Python26\lib\asyncore.py", line 132, in poll read(obj) File "C:\Python26\lib\asyncore.py", line 72, in read obj.handle_error() File "C:\Python26\lib\asyncore.py", line 68, in read obj.handle_read_event() File "C:\Python26\lib\asyncore.py", line 384, in handle_read_event self.handle_accept() File "C:\Documents and Settings\billiejoex\Desktop\test\test.py", line 33, in handle_accept Handler(sock_obj) File "C:\Documents and Settings\billiejoex\Desktop\test\test.py", line 9, in _ _init__ certfile='keycert.pem') File "C:\Python26\lib\ssl.py", line 466, in wrap_socket ssl_version=ssl_version, ca_certs=ca_certs) File "C:\Python26\lib\ssl.py", line 103, in __init__ cert_reqs, ssl_version, ca_certs) ssl.SSLError: [Errno 2] _ssl.c:429: The operation did not complete (read) --- /snippet --- This is the server code I used. Note that 'keycert.pem' is the certificate file I found in the test directory. --- snippet --- import asyncore, asynchat, socket, ssl class Handler(asyncore.dispatcher): def __init__(self, conn): asyncore.dispatcher.__init__(self, conn) self.socket = ssl.wrap_socket(conn, server_side=True, certfile='keycert.pem') self.send('hi there') def readable(self): if isinstance(self.socket, ssl.SSLSocket): while self.socket.pending() > 0: self.handle_read_event() return True def handle_error(self): raise class Server(asyncore.dispatcher): def __init__(self): asyncore.dispatcher.__init__(self) self.create_socket(socket.AF_INET, socket.SOCK_STREAM) self.bind(('', 54321)) self.listen(5) def handle_accept(self): sock_obj, addr = self.accept() print "[]%s:%s Connected." %addr Handler(sock_obj) def handle_error(self): raise Server() asyncore.loop(timeout=1) --- snippet --- From titus at caltech.edu Wed Nov 28 06:50:50 2007 From: titus at caltech.edu (Titus Brown) Date: Tue, 27 Nov 2007 21:50:50 -0800 Subject: [Python-Dev] Fwd: Google Highly Open Participation Contest Message-ID: <20071128055050.GC18977@caltech.edu> Dear Python-Dev-ers, about half of the tasks for the GHOP contest (described below) are currently on the stdlib, Python core, or Py3K: http://code.google.com/p/google-highly-open-participation-psf/issues/list?q=label:stdlib http://code.google.com/p/google-highly-open-participation-psf/issues/list?q=label:core http://code.google.com/p/google-highly-open-participation-psf/issues/list?q=label:py3k We have room for another twenty or so; if you can come up with testing tasks, documentation updates/review needs, or anything else that you can write down in a fairly detailed and specific way, we'd love to have them. Here are the new task guidelines: http://code.google.com/p/google-highly-open-participation-psf/wiki/NewTaskGuidelines and I'm happy to write up the tasks if people send me good ideas. cheers, --titus ----- Forwarded message from Titus Brown ----- From: Titus Brown Subject: Google Highly Open Participation Contest Dear Python community, I'm happy to announce that the Python Software Foundation is part of a new Google Open Source program, the Highly Open Participation Contest. This contest is an effort by Google to engage pre-college students in open source programming: Google is offering prizes and awards for completing a variety of tasks for several organizations. You can read the official announcement of the PSF's involvement over on the Python Software Foundation blog, at http://pyfound.blogspot.com/ or read about the overall Google Highly Open Participation Contest on the GHOP page itself, http://code.google.com/opensource/ghop/2007-8 Python's project page is: http://code.google.com/p/google-highly-open-participation-psf/ There are several ways that the community can help; please check out the MentorPage, http://code.google.com/p/google-highly-open-participation-psf/wiki/MentorPage for more information. We could use more mentors, and there's room for ~40 more tasks -- why not write one up on your own project? Also be sure to thank the people who made this possible, http://code.google.com/p/google-highly-open-participation-psf/wiki/Contributors and, of course, Google! best, --titus ----- End forwarded message ----- From ncoghlan at gmail.com Wed Nov 28 12:36:37 2007 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 28 Nov 2007 21:36:37 +1000 Subject: [Python-Dev] removing the new and types modules In-Reply-To: <474CA95B.7030202@cheimes.de> References: <474CA95B.7030202@cheimes.de> Message-ID: <474D52C5.8070006@gmail.com> Redirecting discussion from python-checkins to python-dev. 'new' has now been deprecated for 3.0, GvR suggested it would be nice to get rid of 'types' as well. Christian Heimes wrote: > Georg Brandl wrote: >> I've just looked, and the types you can't get trivially via builtin or >> type(singleton) are >> >> * module >> * function >> * generator >> * code >> * method >> * builtin-function-or-method >> * frame >> * traceback >> * dictproxy >> * getset- and member-descriptor >> >> Where would one put them? > > Python 3.0 has several more types that aren't exposed through types. For > example the views like dict_keys, dict_values and dict_items are not in > types. Most of those 'hard-to-get-at' types are tied pretty tightly to the interpreter internals, and would fit in with Guido's suggestion of a 'pyvm' module. Such a module would let us clean up the 'sys' namespace a little bit by moving some of the more arcane hackery to another module (like the recursion limit and the threading check interval). The only ones I would suggest putting elsewhere are the module type (exposing it through the imp module instead), and the new dict_keys/_values/_items types (exposing them through the collections module, as others have suggested). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From lists at cheimes.de Wed Nov 28 14:51:10 2007 From: lists at cheimes.de (Christian Heimes) Date: Wed, 28 Nov 2007 14:51:10 +0100 Subject: [Python-Dev] removing the new and types modules In-Reply-To: <474D52C5.8070006@gmail.com> References: <474CA95B.7030202@cheimes.de> <474D52C5.8070006@gmail.com> Message-ID: <474D724E.1060804@cheimes.de> Nick Coghlan wrote: > 'new' has now been deprecated for 3.0, GvR suggested it would be nice to > get rid of 'types' as well. I've removed the 'new' module from py3k and also removed a lot of types from the 'types' module in py3k. It only contains types that aren't easily available through builtins. > Most of those 'hard-to-get-at' types are tied pretty tightly to the > interpreter internals, and would fit in with Guido's suggestion of a > 'pyvm' module. Such a module would let us clean up the 'sys' namespace a > little bit by moving some of the more arcane hackery to another module > (like the recursion limit and the threading check interval). Can we leave 'pyvm' until the next alpha is out? We are already near the schedule for mid to end of November. > The only ones I would suggest putting elsewhere are the module type > (exposing it through the imp module instead), and the new > dict_keys/_values/_items types (exposing them through the collections > module, as others have suggested). Several other types are used in the Python core, too. The most remarkable is MethodType (to bind functions to instances) but also FunctionType and CodeType. Christian From lists at cheimes.de Wed Nov 28 14:51:10 2007 From: lists at cheimes.de (Christian Heimes) Date: Wed, 28 Nov 2007 14:51:10 +0100 Subject: [Python-Dev] removing the new and types modules In-Reply-To: <474D52C5.8070006@gmail.com> References: <474CA95B.7030202@cheimes.de> <474D52C5.8070006@gmail.com> Message-ID: <474D724E.1060804@cheimes.de> Nick Coghlan wrote: > 'new' has now been deprecated for 3.0, GvR suggested it would be nice to > get rid of 'types' as well. I've removed the 'new' module from py3k and also removed a lot of types from the 'types' module in py3k. It only contains types that aren't easily available through builtins. > Most of those 'hard-to-get-at' types are tied pretty tightly to the > interpreter internals, and would fit in with Guido's suggestion of a > 'pyvm' module. Such a module would let us clean up the 'sys' namespace a > little bit by moving some of the more arcane hackery to another module > (like the recursion limit and the threading check interval). Can we leave 'pyvm' until the next alpha is out? We are already near the schedule for mid to end of November. > The only ones I would suggest putting elsewhere are the module type > (exposing it through the imp module instead), and the new > dict_keys/_values/_items types (exposing them through the collections > module, as others have suggested). Several other types are used in the Python core, too. The most remarkable is MethodType (to bind functions to instances) but also FunctionType and CodeType. Christian From g.brandl at gmx.net Wed Nov 28 15:52:35 2007 From: g.brandl at gmx.net (Georg Brandl) Date: Wed, 28 Nov 2007 15:52:35 +0100 Subject: [Python-Dev] Fwd: Google Highly Open Participation Contest In-Reply-To: <20071128055050.GC18977@caltech.edu> References: <20071128055050.GC18977@caltech.edu> Message-ID: Titus Brown schrieb: > Dear Python-Dev-ers, > > about half of the tasks for the GHOP contest (described below) are > currently on the stdlib, Python core, or Py3K: > > http://code.google.com/p/google-highly-open-participation-psf/issues/list?q=label:stdlib > > http://code.google.com/p/google-highly-open-participation-psf/issues/list?q=label:core > > http://code.google.com/p/google-highly-open-participation-psf/issues/list?q=label:py3k > > We have room for another twenty or so; if you can come up with testing > tasks, documentation updates/review needs, or anything else that you can > write down in a fairly detailed and specific way, we'd love to have > them. To emphasize, coding something specific is also a possible task, as well as solving one or more specific issues in the tracker -- as long as it's doable in a time of 3 to 5 days. Georg From lists at cheimes.de Wed Nov 28 16:20:05 2007 From: lists at cheimes.de (Christian Heimes) Date: Wed, 28 Nov 2007 16:20:05 +0100 Subject: [Python-Dev] [poll] New name for __builtins__ Message-ID: <474D8725.8000706@cheimes.de> I'm sending this mail to Python-dev in the hope to reach more developers. GvR likes to rename the __builtin__ to reduce confusing between __builtin__ and __builtins__. He wanted to start a poll on the new name but apparently he forgot. >From http://bugs.python.org/issue1498 --- In http://bugs.python.org/issue1774369 I mentioned that I wanted to rename __builtins__ to __rootns__. Though right now I think something longer and less cryptic might be better. The reason is to avoid for once and for all the confusion between __builtin__, which is a module, and __builtins__, a feature mainly used by sandboxing to pass the set of builtins to be used via the global namespace. This lay at the heart of the referenced bug. I'm still in favor of this but haven't had the time to investigate how much work it would be. [...] OK, then we need to agree on a new name. I find __root__ too short, __rootns__ too cryptic, and __root_namespace__ too long. :-) What else have we got? --- What name do you prefer? I'm +1 with Raymond on __root__ but I'm still open for better suggestions. Christian From fuzzyman at voidspace.org.uk Wed Nov 28 17:06:52 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 28 Nov 2007 16:06:52 +0000 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474D8725.8000706@cheimes.de> References: <474D8725.8000706@cheimes.de> Message-ID: <474D921C.6@voidspace.org.uk> Christian Heimes wrote: > I'm sending this mail to Python-dev in the hope to reach more developers. > > GvR likes to rename the __builtin__ to reduce confusing between > __builtin__ and __builtins__. He wanted to start a poll on the new name > but apparently he forgot. > > >From http://bugs.python.org/issue1498 > --- > In http://bugs.python.org/issue1774369 I mentioned that I wanted to > rename __builtins__ to __rootns__. Though right now I think something > longer and less cryptic might be better. The reason is to avoid for > once and for all the confusion between __builtin__, which is a module, > and __builtins__, a feature mainly used by sandboxing to pass the set of > builtins to be used via the global namespace. This lay at the heart of > the referenced bug. > > I'm still in favor of this but haven't had the time to investigate how > much work it would be. > [...] > OK, then we need to agree on a new name. I find __root__ too short, > __rootns__ too cryptic, and __root_namespace__ too long. :-) What else > have we got? > --- > > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. > +1 for '__root_namespace__' (explicit) +0.5 for '__root__' Michael Foord > Christian > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > From g.brandl at gmx.net Wed Nov 28 17:32:29 2007 From: g.brandl at gmx.net (Georg Brandl) Date: Wed, 28 Nov 2007 17:32:29 +0100 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474D8725.8000706@cheimes.de> References: <474D8725.8000706@cheimes.de> Message-ID: Christian Heimes schrieb: > I'm sending this mail to Python-dev in the hope to reach more developers. > > GvR likes to rename the __builtin__ to reduce confusing between > __builtin__ and __builtins__. He wanted to start a poll on the new name > but apparently he forgot. > >>From http://bugs.python.org/issue1498 > --- > In http://bugs.python.org/issue1774369 I mentioned that I wanted to > rename __builtins__ to __rootns__. Though right now I think something > longer and less cryptic might be better. The reason is to avoid for > once and for all the confusion between __builtin__, which is a module, > and __builtins__, a feature mainly used by sandboxing to pass the set of > builtins to be used via the global namespace. This lay at the heart of > the referenced bug. > > I'm still in favor of this but haven't had the time to investigate how > much work it would be. > [...] > OK, then we need to agree on a new name. I find __root__ too short, > __rootns__ too cryptic, and __root_namespace__ too long. :-) What else > have we got? > --- > > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. FWIW, +1 for __root__ too. Georg From rrr at ronadam.com Wed Nov 28 17:46:58 2007 From: rrr at ronadam.com (Ron Adam) Date: Wed, 28 Nov 2007 10:46:58 -0600 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474D8725.8000706@cheimes.de> References: <474D8725.8000706@cheimes.de> Message-ID: <474D9B82.4090902@ronadam.com> Christian Heimes wrote: > I'm sending this mail to Python-dev in the hope to reach more developers. > > GvR likes to rename the __builtin__ to reduce confusing between > __builtin__ and __builtins__. He wanted to start a poll on the new name > but apparently he forgot. > >>From http://bugs.python.org/issue1498 > --- > In http://bugs.python.org/issue1774369 I mentioned that I wanted to > rename __builtins__ to __rootns__. Though right now I think something > longer and less cryptic might be better. The reason is to avoid for > once and for all the confusion between __builtin__, which is a module, > and __builtins__, a feature mainly used by sandboxing to pass the set of > builtins to be used via the global namespace. This lay at the heart of > the referenced bug. > > I'm still in favor of this but haven't had the time to investigate how > much work it would be. > [...] > OK, then we need to agree on a new name. I find __root__ too short, > __rootns__ too cryptic, and __root_namespace__ too long. :-) What else > have we got? > --- > > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. My first thought was that __root__ would be the global name space and __builtin(s)__ would be the default module that gets loaded into the __root__ name space. But I see I have that reversed. Ron From p.f.moore at gmail.com Wed Nov 28 17:54:11 2007 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 28 Nov 2007 16:54:11 +0000 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> Message-ID: <79990c6b0711280854m2a67ced4qafcd55f8bb5ea41a@mail.gmail.com> On 28/11/2007, Georg Brandl wrote: > Christian Heimes schrieb: > > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > > open for better suggestions. > > FWIW, +1 for __root__ too. What about __global__? If that's not an option, I'm OK with __root__. Paul. From barry at python.org Wed Nov 28 18:09:17 2007 From: barry at python.org (Barry Warsaw) Date: Wed, 28 Nov 2007 12:09:17 -0500 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474D8725.8000706@cheimes.de> References: <474D8725.8000706@cheimes.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 28, 2007, at 10:20 AM, Christian Heimes wrote: > > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. > The only other thing I can suggest is __python__ built __root__ works fine for me too. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR02gvXEjvBPtnXfVAQJ4CQP+MuBSyL13DwLjFPon4l/lSXEBEa2XZ40U LZMB/KF+VpgV8dNz/f1Bv7FA9pc/cIAU7qKKP8/vdAFQkkIPZhKzAgLlpBiOmK47 muNGYT5GsczfgM90/vzNqi2JQ8hWxpR/DIB+/59u2p/2zrADSdhVARt3tmJfivhI 9OY1e4VZkZY= =VGDm -----END PGP SIGNATURE----- From g.brandl at gmx.net Wed Nov 28 18:00:07 2007 From: g.brandl at gmx.net (Georg Brandl) Date: Wed, 28 Nov 2007 18:00:07 +0100 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <79990c6b0711280854m2a67ced4qafcd55f8bb5ea41a@mail.gmail.com> References: <474D8725.8000706@cheimes.de> <79990c6b0711280854m2a67ced4qafcd55f8bb5ea41a@mail.gmail.com> Message-ID: Paul Moore schrieb: > On 28/11/2007, Georg Brandl wrote: >> Christian Heimes schrieb: >> > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still >> > open for better suggestions. >> >> FWIW, +1 for __root__ too. > > What about __global__? If that's not an option, I'm OK with __root__. "global" is already taken for the global namespace, which is module-local. ;) Georg From steve at holdenweb.com Wed Nov 28 17:55:01 2007 From: steve at holdenweb.com (Steve Holden) Date: Wed, 28 Nov 2007 11:55:01 -0500 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474D8725.8000706@cheimes.de> References: <474D8725.8000706@cheimes.de> Message-ID: Christian Heimes wrote: > I'm sending this mail to Python-dev in the hope to reach more developers. > > GvR likes to rename the __builtin__ to reduce confusing between > __builtin__ and __builtins__. He wanted to start a poll on the new name > but apparently he forgot. > >>From http://bugs.python.org/issue1498 > --- > In http://bugs.python.org/issue1774369 I mentioned that I wanted to > rename __builtins__ to __rootns__. Though right now I think something > longer and less cryptic might be better. The reason is to avoid for > once and for all the confusion between __builtin__, which is a module, > and __builtins__, a feature mainly used by sandboxing to pass the set of > builtins to be used via the global namespace. This lay at the heart of > the referenced bug. > > I'm still in favor of this but haven't had the time to investigate how > much work it would be. > [...] > OK, then we need to agree on a new name. I find __root__ too short, > __rootns__ too cryptic, and __root_namespace__ too long. :-) What else > have we got? > --- > > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. > The namespace should really be called __global__. I doubt this will fly, because it's too radical, and unfortunately would undermine the "global" keyword, used in 2.x to indicate that a name should be sought in the module namespace. I doubt many people would want to replace "global" with "module". What's it being replaced with in 3.x? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From lists at cheimes.de Wed Nov 28 18:22:17 2007 From: lists at cheimes.de (Christian Heimes) Date: Wed, 28 Nov 2007 18:22:17 +0100 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <79990c6b0711280854m2a67ced4qafcd55f8bb5ea41a@mail.gmail.com> References: <474D8725.8000706@cheimes.de> <79990c6b0711280854m2a67ced4qafcd55f8bb5ea41a@mail.gmail.com> Message-ID: <474DA3C9.5040408@cheimes.de> Paul Moore wrote: > What about __global__? If that's not an option, I'm OK with __root__. __global__ was also on my list but I've abolished it. It could create confusing with globals(). Christian From cmason at vcentertainment.com Wed Nov 28 18:21:55 2007 From: cmason at vcentertainment.com (Chuck Mason (Visual Concepts)) Date: Wed, 28 Nov 2007 09:21:55 -0800 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: Message-ID: <8D590944234B4047B01E464FACB35A3516B7FC@2KGNOVEXG01.2kgames.t2.corp> Hello everybody! I really should introduce myself before stating my opinion. But I'll keep this short and sweet -- I have been "trolling" python-dev for a while just to keep up on its development and have never posted but I thought I'd share my opinion on this thread simply because it's a simple topic :) Before finishing the OP I had thought __python__ would be a good name. So +1 to __python__ for me. +0 to __root__ and __rootns__ and +0.5 to __root_namespace__ (prefer explicitness to short/cryptic names). Chuck -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 28, 2007, at 10:20 AM, Christian Heimes wrote: > > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. > The only other thing I can suggest is __python__ built __root__ works fine for me too. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR02gvXEjvBPtnXfVAQJ4CQP+MuBSyL13DwLjFPon4l/lSXEBEa2XZ40U LZMB/KF+VpgV8dNz/f1Bv7FA9pc/cIAU7qKKP8/vdAFQkkIPZhKzAgLlpBiOmK47 muNGYT5GsczfgM90/vzNqi2JQ8hWxpR/DIB+/59u2p/2zrADSdhVARt3tmJfivhI 9OY1e4VZkZY= =VGDm -----END PGP SIGNATURE----- _______________________________________________ Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/cmason%40vcentertainme nt.com From g.brandl at gmx.net Wed Nov 28 18:39:34 2007 From: g.brandl at gmx.net (Georg Brandl) Date: Wed, 28 Nov 2007 18:39:34 +0100 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> Message-ID: Steve Holden schrieb: >> What name do you prefer? I'm +1 with Raymond on __root__ but I'm still >> open for better suggestions. >> > The namespace should really be called __global__. I doubt this will fly, > because it's too radical, and unfortunately would undermine the "global" > keyword, used in 2.x to indicate that a name should be sought in the > module namespace. There are quite a few other places where "globals" is used with that meaning. > I doubt many people would want to replace "global" with "module". > > What's it being replaced with in 3.x? Nothing yet, it's still there, together with "nonlocal". Georg From guido at python.org Wed Nov 28 18:59:01 2007 From: guido at python.org (Guido van Rossum) Date: Wed, 28 Nov 2007 09:59:01 -0800 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> Message-ID: On Nov 28, 2007 9:39 AM, Georg Brandl wrote: > Steve Holden schrieb: > > >> What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > >> open for better suggestions. > >> > > The namespace should really be called __global__. I doubt this will fly, > > because it's too radical, and unfortunately would undermine the "global" > > keyword, used in 2.x to indicate that a name should be sought in the > > module namespace. > > There are quite a few other places where "globals" is used with that meaning. > > > I doubt many people would want to replace "global" with "module". > > > > What's it being replaced with in 3.x? > > Nothing yet, it's still there, together with "nonlocal". The global statement will not be changed or renamed. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From rhamph at gmail.com Wed Nov 28 19:46:33 2007 From: rhamph at gmail.com (Adam Olsen) Date: Wed, 28 Nov 2007 11:46:33 -0700 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474D8725.8000706@cheimes.de> References: <474D8725.8000706@cheimes.de> Message-ID: On Nov 28, 2007 8:20 AM, Christian Heimes wrote: > I'm sending this mail to Python-dev in the hope to reach more developers. > > GvR likes to rename the __builtin__ to reduce confusing between > __builtin__ and __builtins__. He wanted to start a poll on the new name > but apparently he forgot. In a recent thread on python-ideas[1] it was suggested that builtins be added as an argument to eval and exec. I'd prefer to do that and eliminate the name altogether. If not that I suggest something like __inject_builtins__. This implies it's a command to eval/exec, and doesn't necessarily reflect your current builtins (which are canonically accessible as an attribute of your frame.) [1] http://mail.python.org/pipermail/python-ideas/2007-November/001250.html -- Adam Olsen, aka Rhamphoryncus From guido at python.org Wed Nov 28 19:50:33 2007 From: guido at python.org (Guido van Rossum) Date: Wed, 28 Nov 2007 10:50:33 -0800 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> Message-ID: On Nov 28, 2007 10:46 AM, Adam Olsen wrote: > On Nov 28, 2007 8:20 AM, Christian Heimes wrote: > > I'm sending this mail to Python-dev in the hope to reach more developers. > > > > GvR likes to rename the __builtin__ to reduce confusing between > > __builtin__ and __builtins__. He wanted to start a poll on the new name > > but apparently he forgot. > > In a recent thread on python-ideas[1] it was suggested that builtins > be added as an argument to eval and exec. I'd prefer to do that and > eliminate the name altogether. > [1] http://mail.python.org/pipermail/python-ideas/2007-November/001250.html You can do that but the special entry in globals is still required in order to pass it on to all scopes that need it. > If not that I suggest something like __inject_builtins__. This > implies it's a command to eval/exec, and doesn't necessarily reflect > your current builtins (which are canonically accessible as an > attribute of your frame.) You're misunderstanding the reason why __builtins__ exists at all. It is used *everywhere* as the root namespace, not just as a special case to inject different builtins. ATM I'm torn between __root__ and __python__. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From facundobatista at gmail.com Wed Nov 28 20:02:19 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Wed, 28 Nov 2007 16:02:19 -0300 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> Message-ID: 2007/11/28, Guido van Rossum : > ATM I'm torn between __root__ and __python__. __root__ gives me the idea of the base of a tree, its primary node. +0 __python__ gives me the idea of something very deep inside python. +1 Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From rhamph at gmail.com Wed Nov 28 20:11:10 2007 From: rhamph at gmail.com (Adam Olsen) Date: Wed, 28 Nov 2007 12:11:10 -0700 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> Message-ID: On Nov 28, 2007 11:50 AM, Guido van Rossum wrote: > On Nov 28, 2007 10:46 AM, Adam Olsen wrote: > > On Nov 28, 2007 8:20 AM, Christian Heimes wrote: > > > I'm sending this mail to Python-dev in the hope to reach more developers. > > > > > > GvR likes to rename the __builtin__ to reduce confusing between > > > __builtin__ and __builtins__. He wanted to start a poll on the new name > > > but apparently he forgot. > > > > In a recent thread on python-ideas[1] it was suggested that builtins > > be added as an argument to eval and exec. I'd prefer to do that and > > eliminate the name altogether. > > [1] http://mail.python.org/pipermail/python-ideas/2007-November/001250.html > > You can do that but the special entry in globals is still required in > order to pass it on to all scopes that need it. > > > If not that I suggest something like __inject_builtins__. This > > implies it's a command to eval/exec, and doesn't necessarily reflect > > your current builtins (which are canonically accessible as an > > attribute of your frame.) > > You're misunderstanding the reason why __builtins__ exists at all. It > is used *everywhere* as the root namespace, not just as a special case > to inject different builtins. Ahh, so only replacing __builtins__ is unsupported (an implementation detail, as it may be cached), not all use of it? It is confusing that something normally unsupported becomes required for eval/exec. > ATM I'm torn between __root__ and __python__. -1 on __python__. It seems to be an abbreviation of "python interpreter core" or the like, but on its own it implies nothing about what it means. Contrast that with __root__ where we all know what a root is, even though it doesn't imply what kind of root it is or how its used. __root_globals__ would be another option, showing clearly how it relates to our existing use of the "globals" term. -- Adam Olsen, aka Rhamphoryncus From guido at python.org Wed Nov 28 20:13:17 2007 From: guido at python.org (Guido van Rossum) Date: Wed, 28 Nov 2007 11:13:17 -0800 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> Message-ID: On Nov 28, 2007 11:02 AM, Facundo Batista wrote: > 2007/11/28, Guido van Rossum : > > > ATM I'm torn between __root__ and __python__. > > __root__ gives me the idea of the base of a tree, its primary node. +0 Which it is, if you consider nested namespaces as a tree (all modules are children of __root__, all unnested function locals are children of their module's globals, nested functions are children of their containing function's locals). > __python__ gives me the idea of something very deep inside python. +1 But it violates the (never before uttered, but nevertheless existing in my consciousness since day one) rule that we shouldn't start calling things inside Python "Python things" because then *everything* becomes a Python thingie. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From lists at cheimes.de Wed Nov 28 20:21:36 2007 From: lists at cheimes.de (Christian Heimes) Date: Wed, 28 Nov 2007 20:21:36 +0100 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> Message-ID: <474DBFC0.10603@cheimes.de> Adam Olsen wrote: > -1 on __python__. It seems to be an abbreviation of "python > interpreter core" or the like, but on its own it implies nothing about > what it means. > > Contrast that with __root__ where we all know what a root is, even > though it doesn't imply what kind of root it is or how its used. I don't like __python__ either. It doesn't explain the meaning of the variable at all. If you want to stick to something like __python__ I suggest __pythoncore__ or __pythonroot__, maybe __pythongastric__ (just kidding). Christian From g.brandl at gmx.net Wed Nov 28 20:59:47 2007 From: g.brandl at gmx.net (Georg Brandl) Date: Wed, 28 Nov 2007 20:59:47 +0100 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474DBFC0.10603@cheimes.de> References: <474D8725.8000706@cheimes.de> <474DBFC0.10603@cheimes.de> Message-ID: Christian Heimes schrieb: > Adam Olsen wrote: >> -1 on __python__. It seems to be an abbreviation of "python >> interpreter core" or the like, but on its own it implies nothing about >> what it means. >> >> Contrast that with __root__ where we all know what a root is, even >> though it doesn't imply what kind of root it is or how its used. > > I don't like __python__ either. It doesn't explain the meaning of the > variable at all. If you want to stick to something like __python__ I > suggest __pythoncore__ or __pythonroot__, maybe __pythongastric__ (just > kidding). __guts__ ? Really, __python__ has not much self-explanatory potential. Georg From shansen at advpubtech.com Wed Nov 28 21:01:54 2007 From: shansen at advpubtech.com (Stephen Hansen) Date: Wed, 28 Nov 2007 12:01:54 -0800 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> Message-ID: <7a9c25c20711281201g43dc612dy35cc9f3f9802e035@mail.gmail.com> (The lurker awakes...) > > If not that I suggest something like __inject_builtins__. This > > implies it's a command to eval/exec, and doesn't necessarily reflect > > your current builtins (which are canonically accessible as an > > attribute of your frame.) > > You're misunderstanding the reason why __builtins__ exists at all. It > is used *everywhere* as the root namespace, not just as a special case > to inject different builtins. > > ATM I'm torn between __root__ and __python__. Something with the word "global" speaks to it's real effect, except that the word already has an established meaning in Python as being 'global to the module level', and modifying __builtins__ lets you be "global to the entire universe of that instance" So I would humbly suggest __universal__. The names within are available everywhere. 'root' speaks to me too much of trees, and while namespaces may be tree-like, __root__ alone doesn't say "root namespace"... and __root_namespace__ is long. (Then again, long for a feature that should only be used with care isn't a bad thing) --Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20071128/78c86ba8/attachment.htm From lgautier at gmail.com Wed Nov 28 21:28:50 2007 From: lgautier at gmail.com (Laurent Gautier) Date: Wed, 28 Nov 2007 21:28:50 +0100 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <7a9c25c20711281201g43dc612dy35cc9f3f9802e035@mail.gmail.com> References: <474D8725.8000706@cheimes.de> <7a9c25c20711281201g43dc612dy35cc9f3f9802e035@mail.gmail.com> Message-ID: <27d1e6020711281228y42b83fal4796d5d8c11b121b@mail.gmail.com> I find __root_namespace__ rather explicit without being unbearably long. If length is an issue, and __root__ not found explicit, I am suggesting __session__. L. 2007/11/28, Stephen Hansen : > (The lurker awakes...) > > > > > > > If not that I suggest something like __inject_builtins__. This > > > implies it's a command to eval/exec, and doesn't necessarily reflect > > > your current builtins (which are canonically accessible as an > > > attribute of your frame.) > > > > You're misunderstanding the reason why __builtins__ exists at all. It > > is used *everywhere* as the root namespace, not just as a special case > > to inject different builtins. > > > > ATM I'm torn between __root__ and __python__. > > > Something with the word "global" speaks to it's real effect, except that the > word already has an established meaning in Python as being 'global to the > module level', and modifying __builtins__ lets you be "global to the entire > universe of that instance" > > So I would humbly suggest __universal__. The names within are available > everywhere. 'root' speaks to me too much of trees, and while namespaces may > be tree-like, __root__ alone doesn't say "root namespace"... and > __root_namespace__ is long. > > (Then again, long for a feature that should only be used with care isn't a > bad thing) > > --Stephen > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/lgautier%40gmail.com > > From guido at python.org Wed Nov 28 21:45:55 2007 From: guido at python.org (Guido van Rossum) Date: Wed, 28 Nov 2007 12:45:55 -0800 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <27d1e6020711281228y42b83fal4796d5d8c11b121b@mail.gmail.com> References: <474D8725.8000706@cheimes.de> <7a9c25c20711281201g43dc612dy35cc9f3f9802e035@mail.gmail.com> <27d1e6020711281228y42b83fal4796d5d8c11b121b@mail.gmail.com> Message-ID: On Nov 28, 2007 12:28 PM, Laurent Gautier wrote: > I find __root_namespace__ rather explicit without being unbearably long. Perhaps the length is even an advantage -- this is not something that should be messed with lightly. > If length is an issue, and __root__ not found explicit, I am > suggesting __session__. No, that already has too many unrelated meanings. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From suraj at barkale.com Wed Nov 28 19:13:09 2007 From: suraj at barkale.com (Suraj Barkale) Date: Wed, 28 Nov 2007 18:13:09 +0000 (UTC) Subject: [Python-Dev] =?utf-8?q?=5Bpoll=5D_New_name_for_=5F=5Fbuiltins=5F?= =?utf-8?q?=5F?= References: <474D8725.8000706@cheimes.de> Message-ID: Hi, Christian Heimes cheimes.de> writes: > > GvR likes to rename the __builtin__ to reduce confusing between > __builtin__ and __builtins__. He wanted to start a poll on the new name > but apparently he forgot. > > >From http://bugs.python.org/issue1498 > > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. I lurk around in this list on gmane and I am a Python user. I just wanted to add my shade of color :) As __builtins__ provides identifiers present in python language, I would prefer __py__ or __lang__ over __root__. Thanks for reading, Suraj From carsten at uniqsys.com Wed Nov 28 22:04:24 2007 From: carsten at uniqsys.com (Carsten Haese) Date: Wed, 28 Nov 2007 16:04:24 -0500 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474D8725.8000706@cheimes.de> References: <474D8725.8000706@cheimes.de> Message-ID: <1196283864.12856.1.camel@dot.uniqsys.com> On Wed, 2007-11-28 at 16:20 +0100, Christian Heimes wrote: > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. My suggestions, in descending degrees of seriousness: __core__ __fixtures__ -- Carsten Haese http://informixdb.sourceforge.net From henning.vonbargen at arcor.de Wed Nov 28 22:23:24 2007 From: henning.vonbargen at arcor.de (henning.vonbargen at arcor.de) Date: Wed, 28 Nov 2007 22:23:24 +0100 (CET) Subject: [Python-Dev] removing the new and types modules Message-ID: <26869826.1196285004888.JavaMail.ngmail@webmail15> Sorry if this is a dumb question, but are there actually good reasons to remove "types"? IMHO the types module helps keeping code readable. For example "if type(obj) == FloatType" is just more readable than "if type(obj) == type(1.0)". Luckily Python does not distinguish float and double like other languages - otherwise it wouldn't be clear for the average programmer if 1.0 is a float or a double constant. Henning From steven.bethard at gmail.com Wed Nov 28 23:38:11 2007 From: steven.bethard at gmail.com (Steven Bethard) Date: Wed, 28 Nov 2007 15:38:11 -0700 Subject: [Python-Dev] removing the new and types modules In-Reply-To: <26869826.1196285004888.JavaMail.ngmail@webmail15> References: <26869826.1196285004888.JavaMail.ngmail@webmail15> Message-ID: On Nov 28, 2007 2:23 PM, wrote: > Sorry if this is a dumb question, but are there actually good reasons to remove "types"? > IMHO the types module helps keeping code readable. > For example > "if type(obj) == FloatType" > is just more readable than > "if type(obj) == type(1.0)". But you should really be writing:: if isinstance(obj, float) for most situations, and:: if type(obj) == float if you really *have* to check the exact type. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy From fuzzyman at voidspace.org.uk Wed Nov 28 23:39:35 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 28 Nov 2007 22:39:35 +0000 Subject: [Python-Dev] [python] Re: removing the new and types modules In-Reply-To: <26869826.1196285004888.JavaMail.ngmail@webmail15> References: <26869826.1196285004888.JavaMail.ngmail@webmail15> Message-ID: <474DEE27.4030707@voidspace.org.uk> henning.vonbargen at arcor.de wrote: > Sorry if this is a dumb question, but are there actually good reasons to remove "types"? > IMHO the types module helps keeping code readable. > For example > "if type(obj) == FloatType" > is just more readable than > "if type(obj) == type(1.0)". > if isinstance(obj, float) or if type(obj) is float I often use FunctionType though.So long as it moves rather than vanishes... Michael http://www.manning.com/foord > Luckily Python does not distinguish float and double like other languages > - otherwise it wouldn't be clear for the average programmer if 1.0 is a > float or a double constant. > > Henning > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > From greg.ewing at canterbury.ac.nz Thu Nov 29 00:15:25 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 29 Nov 2007 12:15:25 +1300 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> Message-ID: <474DF68D.6010701@canterbury.ac.nz> Steve Holden wrote: > The namespace should really be called __global__. I doubt this will fly, > because it's too radical, and unfortunately would undermine the "global" > keyword __uberglobal__ -- Greg From greg.ewing at canterbury.ac.nz Thu Nov 29 00:21:31 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 29 Nov 2007 12:21:31 +1300 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> Message-ID: <474DF7FB.5040006@canterbury.ac.nz> Guido van Rossum wrote: > You can do that but the special entry in globals is still required in > order to pass it on to all scopes that need it. Unless you use something other than a plain dict for module namespaces. -- Greg From janssen at parc.com Thu Nov 29 00:26:24 2007 From: janssen at parc.com (Bill Janssen) Date: Wed, 28 Nov 2007 15:26:24 PST Subject: [Python-Dev] ssl module integration with asyncore In-Reply-To: <33b2d8d1-ac00-49c9-8323-82c2fa1d3847@d21g2000prf.googlegroups.com> References: <07Nov26.102313pst."58696"@synergy1.parc.xerox.com> <07Nov26.174736pst."58696"@synergy1.parc.xerox.com> <33b2d8d1-ac00-49c9-8323-82c2fa1d3847@d21g2000prf.googlegroups.com> Message-ID: <07Nov28.152632pst."58696"@synergy1.parc.xerox.com> > I tried to write a simple asyncore-based server code, then I used a > simple client to establish a connection with it. > Once the client is connected server raises the following exception: I think this is a bug. Thanks! The issue is that the internal call to do_handshake() doesn't handle non-blocking sockets properly. You can work around the bug like this: --- snippet --- import asyncore, asynchat, socket, ssl, select class Handler(asyncore.dispatcher): def __init__(self, conn): asyncore.dispatcher.__init__(self, conn) self.socket = ssl.wrap_socket(conn, server_side=True, certfile='keycert.pem', do_handshake_on_connect=False) while True: try: self.socket.do_handshake() break except ssl.SSLError, err: if err.args[0] == ssl.SSL_ERROR_WANT_READ: select.select([self.socket], [], []) elif err.args[0] == ssl.SSL_ERROR_WANT_WRITE: select.select([], [self.socket], []) else: raise self.send('hi there') --- /snippet --- Bill From josepharmbruster at gmail.com Thu Nov 29 00:25:56 2007 From: josepharmbruster at gmail.com (Joseph Armbruster) Date: Wed, 28 Nov 2007 18:25:56 -0500 Subject: [Python-Dev] Statsvn output for /python/branches/py3k Message-ID: <474DF904.6020204@gmail.com> All, I was looking at statsvn today at work and gave it a test-run on a repo there. I wondered what it would look like for python3k. And... here are the results: http://www.joevial.com/statsvn/ Enjoy, Joseph Armbruster From gnewsg at gmail.com Thu Nov 29 02:52:31 2007 From: gnewsg at gmail.com (Giampaolo Rodola') Date: Wed, 28 Nov 2007 17:52:31 -0800 (PST) Subject: [Python-Dev] ssl module integration with asyncore In-Reply-To: <07Nov28.152632pst."58696"@synergy1.parc.xerox.com> References: <07Nov26.102313pst."58696"@synergy1.parc.xerox.com> <07Nov26.174736pst."58696"@synergy1.parc.xerox.com> <33b2d8d1-ac00-49c9-8323-82c2fa1d3847@d21g2000prf.googlegroups.com> <07Nov28.152632pst."58696"@synergy1.parc.xerox.com> Message-ID: <0e3948ae-6e24-4ed6-9152-3bd8457f7547@d27g2000prf.googlegroups.com> On 29 Nov, 00:26, Bill Janssen wrote: > > I tried to write a simple asyncore-based server code, then I used a > > simple client to establish a connection with it. > > Once the client is connected server raises the following exception: > > I think this is a bug. Thanks! You're welcome. > The issue is that the internal call to do_handshake() doesn't handle > non-blocking sockets properly. > > You can work around the bug like this: > > --- snippet --- > import asyncore, asynchat, socket, ssl, select > > class Handler(asyncore.dispatcher): > > def __init__(self, conn): > asyncore.dispatcher.__init__(self, conn) > self.socket = ssl.wrap_socket(conn, server_side=True, > certfile='keycert.pem', > do_handshake_on_connect=False) > while True: > try: > self.socket.do_handshake() > break > except ssl.SSLError, err: > if err.args[0] == ssl.SSL_ERROR_WANT_READ: > select.select([self.socket], [], []) > elif err.args[0] == ssl.SSL_ERROR_WANT_WRITE: > select.select([], [self.socket], []) > else: > raise > self.send('hi there') > --- /snippet --- > > Bill It does raise the same exception. Are there plans for fixing this? Using that kind of workaround is not acceptable in any case (select module shouldn't even get imported when using asyncore). Moreover I think we need at least a minimal test suite to make sure that non-blocking sockets work properly. I'm not experienced with ssl module but I know asyncore/asynchat quite good. If you need some help I could propose myself for writing a minimal test suite for asyncore integration with ssl module when the bocking issues will be fixed. From janssen at parc.com Thu Nov 29 03:27:33 2007 From: janssen at parc.com (Bill Janssen) Date: Wed, 28 Nov 2007 18:27:33 PST Subject: [Python-Dev] ssl module integration with asyncore In-Reply-To: <0e3948ae-6e24-4ed6-9152-3bd8457f7547@d27g2000prf.googlegroups.com> References: <07Nov26.102313pst."58696"@synergy1.parc.xerox.com> <07Nov26.174736pst."58696"@synergy1.parc.xerox.com> <33b2d8d1-ac00-49c9-8323-82c2fa1d3847@d21g2000prf.googlegroups.com> <07Nov28.152632pst."58696"@synergy1.parc.xerox.com> <0e3948ae-6e24-4ed6-9152-3bd8457f7547@d27g2000prf.googlegroups.com> Message-ID: <07Nov28.182739pst."58696"@synergy1.parc.xerox.com> > It does raise the same exception. Hmmm, not in my version. > Are there plans for fixing this? Yes, it's fixed in my CVS, and I'll upload a new version to PyPI when I get a chance. > Using that kind of workaround is not acceptable in any case (select > module shouldn't even get imported when using asyncore). Well, that's what the fix in the SSL module will do under the covers, so if there's a reason not to do it, or a better way of doing it, speak now. It really has nothing to do with asyncore; it's just a way of safely handling a socket which may or may not be non-blocking. A more extended example, more true to the asyncore way of doing things, would in fact keep track of the connection state in a local variable, and would consult that in "handle_read_event" and "handle_write_event", calling do_handshake again if it's still not completed. That way you could get rid of the select. Here's my (working) version of your code. Note that I inherit from dispatcher_with_send to make sure I have a working "handle_write" method. Bill --- snippet --- import asyncore, asynchat, socket, ssl, select class Handler(asyncore.dispatcher_with_send): def __init__(self, conn): asyncore.dispatcher_with_send.__init__(self, conn) self.socket = ssl.wrap_socket(conn, server_side=True, certfile='keycert.pem', do_handshake_on_connect=False) while True: try: self.socket.do_handshake() break except ssl.SSLError, err: if err.args[0] == ssl.SSL_ERROR_WANT_READ: select.select([self.socket], [], []) elif err.args[0] == ssl.SSL_ERROR_WANT_WRITE: select.select([], [self.socket], []) else: raise self.send("hello there!") def readable(self): if isinstance(self.socket, ssl.SSLSocket): while self.socket.pending() > 0: self.handle_read_event() return True def handle_read(self): data = self.recv(1024) print data def handle_error(self): raise class Server(asyncore.dispatcher): def __init__(self): asyncore.dispatcher.__init__(self) self.create_socket(socket.AF_INET, socket.SOCK_STREAM) self.bind(('', 54321)) self.listen(5) def handle_accept(self): sock_obj, addr = self.accept() print "[]%s:%s Connected." %addr Handler(sock_obj) def handle_error(self): raise Server() asyncore.loop(timeout=1) --- /snippet --- From brett at python.org Thu Nov 29 03:31:24 2007 From: brett at python.org (Brett Cannon) Date: Wed, 28 Nov 2007 18:31:24 -0800 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> <7a9c25c20711281201g43dc612dy35cc9f3f9802e035@mail.gmail.com> <27d1e6020711281228y42b83fal4796d5d8c11b121b@mail.gmail.com> Message-ID: On Nov 28, 2007 12:45 PM, Guido van Rossum wrote: > On Nov 28, 2007 12:28 PM, Laurent Gautier wrote: > > I find __root_namespace__ rather explicit without being unbearably long. > > Perhaps the length is even an advantage -- this is not something that > should be messed with lightly. > I think that is a valid point. This is one of those situations that the fact this is provided is good enough; it does not need to be short and easy to type. +1 for either __root_namespace__ or __root__. -Brett From brett at python.org Thu Nov 29 03:33:18 2007 From: brett at python.org (Brett Cannon) Date: Wed, 28 Nov 2007 18:33:18 -0800 Subject: [Python-Dev] Statsvn output for /python/branches/py3k In-Reply-To: <474DF904.6020204@gmail.com> References: <474DF904.6020204@gmail.com> Message-ID: On Nov 28, 2007 3:25 PM, Joseph Armbruster wrote: > All, > > I was looking at statsvn today at work and gave it a test-run on a repo there. > I wondered what it would look like for python3k. And... here are the results: > > http://www.joevial.com/statsvn/ Interesting. Unfortunately no one gets credit for ripping out code. =( -Brett From fdrake at acm.org Thu Nov 29 03:36:43 2007 From: fdrake at acm.org (Fred Drake) Date: Wed, 28 Nov 2007 21:36:43 -0500 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> <7a9c25c20711281201g43dc612dy35cc9f3f9802e035@mail.gmail.com> <27d1e6020711281228y42b83fal4796d5d8c11b121b@mail.gmail.com> Message-ID: <7ABE1953-5236-40A0-9166-F2F819FBA4C9@acm.org> On Nov 28, 2007, at 9:31 PM, Brett Cannon wrote: > +1 for either __root_namespace__ or __root__. What is it with nutrient extractors for plants that makes sense here? The goal is to make it blindingly obvious to someone reading code they didn't write (or even that they did) what's going on. +1 for __builtin_namespace__. -Fred -- Fred Drake From gnewsg at gmail.com Thu Nov 29 04:23:17 2007 From: gnewsg at gmail.com (Giampaolo Rodola') Date: Wed, 28 Nov 2007 19:23:17 -0800 (PST) Subject: [Python-Dev] ssl module integration with asyncore In-Reply-To: <07Nov28.182739pst."58696"@synergy1.parc.xerox.com> References: <07Nov26.102313pst."58696"@synergy1.parc.xerox.com> <07Nov26.174736pst."58696"@synergy1.parc.xerox.com> <33b2d8d1-ac00-49c9-8323-82c2fa1d3847@d21g2000prf.googlegroups.com> <07Nov28.152632pst."58696"@synergy1.parc.xerox.com> <0e3948ae-6e24-4ed6-9152-3bd8457f7547@d27g2000prf.googlegroups.com> <07Nov28.182739pst."58696"@synergy1.parc.xerox.com> Message-ID: On 29 Nov, 03:27, Bill Janssen wrote: > > It does raise the same exception. > > Hmmm, not in my version. > > > Are there plans for fixing this? > > Yes, it's fixed in my CVS, and I'll upload a new version to PyPI when > I get a chance. > > > Using that kind of workaround is not acceptable in any case (select > > module shouldn't even get imported when using asyncore). > > Well, that's what the fix in the SSL module will do under the covers, > so if there's a reason not to do it, or a better way of doing it, > speak now. IMO, it's not reasonable since the application could use something different than select.select(), like select.poll() or something else again. I guess that the best thing to have in such case would be having an "ssl-ized" wrap of the socket which follows the same behaviour of a classical non-blocking socket, then it would be up to the application deciding what to do with it. That way the asynchronous application which wants to switch to a secure connection would just need to wrap the socket by using ssl.wrap_socket() without altering the existing code. Note that I'm just talking about end-user API design. Actually I don't know what happens under the hoods so I'm not even sure which are the real implications. From tjreedy at udel.edu Thu Nov 29 04:32:54 2007 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 28 Nov 2007 22:32:54 -0500 Subject: [Python-Dev] [poll] New name for __builtins__ References: <474D8725.8000706@cheimes.de> Message-ID: "Christian Heimes" wrote in message news:474D8725.8000706 at cheimes.de... || | What name do you prefer? I'm +1 with Raymond on __root__ but I'm still | open for better suggestions. Ok with me, or __rootnames__, but __root_namespace__ is too long for me ;-) From janssen at parc.com Thu Nov 29 06:00:09 2007 From: janssen at parc.com (Bill Janssen) Date: Wed, 28 Nov 2007 21:00:09 PST Subject: [Python-Dev] ssl module integration with asyncore In-Reply-To: References: <07Nov26.102313pst."58696"@synergy1.parc.xerox.com> <07Nov26.174736pst."58696"@synergy1.parc.xerox.com> <33b2d8d1-ac00-49c9-8323-82c2fa1d3847@d21g2000prf.googlegroups.com> <07Nov28.152632pst."58696"@synergy1.parc.xerox.com> <0e3948ae-6e24-4ed6-9152-3bd8457f7547@d27g2000prf.googlegroups.com> <07Nov28.182739pst."58696"@synergy1.parc.xerox.com> Message-ID: <07Nov28.210014pst."58696"@synergy1.parc.xerox.com> > IMO, it's not reasonable since the application could use something > different than select.select(), like select.poll() or something else > again. As I said before, you can do away with select or poll altogether if you write a state machine for your asyncore dispatcher. Asyncore will tell you when you can read or write the socket; you just need to know what to do with that information. > I guess that the best thing to have in such case would be having an > "ssl-ized" wrap of the socket which follows the same behaviour of a > classical non-blocking socket, then it would be up to the application > deciding what to do with it. That's what you get if you use "do_handshake_on_connect=False". Your application is expected to do the SSL handshake in its own time. You can do it whichever way you want, as long as you keep calling "do_handshake" appropriately until it fails to raise an error. I think it's simpler to let the SSL module do it, even though it comes at the expense of blocking the thread till the handshake is complete. > That way the asynchronous application which wants to switch to a > secure connection would just need to wrap the socket by using > ssl.wrap_socket() without altering the existing code. That's essentially what happens already. The question is whether the SSL setup code is allowed to block the non-blocking socket till the SSL handshake is complete. Bill From rrr at ronadam.com Thu Nov 29 06:11:47 2007 From: rrr at ronadam.com (Ron Adam) Date: Wed, 28 Nov 2007 23:11:47 -0600 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <7ABE1953-5236-40A0-9166-F2F819FBA4C9@acm.org> References: <474D8725.8000706@cheimes.de> <7a9c25c20711281201g43dc612dy35cc9f3f9802e035@mail.gmail.com> <27d1e6020711281228y42b83fal4796d5d8c11b121b@mail.gmail.com> <7ABE1953-5236-40A0-9166-F2F819FBA4C9@acm.org> Message-ID: <474E4A13.1090303@ronadam.com> Fred Drake wrote: > On Nov 28, 2007, at 9:31 PM, Brett Cannon wrote: >> +1 for either __root_namespace__ or __root__. > > > What is it with nutrient extractors for plants that makes sense here? Root is a word that takes on a specific meaning depending on the context. Root as in tooth root, tree root, to root one self as in self defense, root of all evil, to root out. etc... In the case of python and name spaces, the context of __root__ would be suitably narrow so that the meaning would be clear and familiar with use. Searching for "python __root__" would give good results as well. In the case of a file or module name where it could be viewed out of context, it would be less suitable. I think __builtin__ is fine for that. Or __default_root__, as in the default root module to be placed in the __root__ name space. Keeping __root__ relatively short has the benefit of being able to easily use "__root__.name" in the case where "name" was/is used in the local scope. I don't see any reason to make it harder. There might even be a use case for using all explicit __root__ references. So +1 on __root__ for me for a name space designator. Regards, Ron > The goal is to make it blindingly obvious to someone reading code they > didn't write (or even that they did) what's going on. > > +1 for __builtin_namespace__. > > > -Fred > From alexandre at peadrop.com Thu Nov 29 06:55:19 2007 From: alexandre at peadrop.com (Alexandre Vassalotti) Date: Thu, 29 Nov 2007 00:55:19 -0500 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474D8725.8000706@cheimes.de> References: <474D8725.8000706@cheimes.de> Message-ID: On 11/28/07, Christian Heimes wrote: > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. > I think __root__ is a fine name. Anyway, here some suggestions (in no particular order): __top__ __syswide__ __outer__ __telescope__ -- Alexandre From steven.bethard at gmail.com Thu Nov 29 07:29:08 2007 From: steven.bethard at gmail.com (Steven Bethard) Date: Wed, 28 Nov 2007 23:29:08 -0700 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474E4A13.1090303@ronadam.com> References: <474D8725.8000706@cheimes.de> <7a9c25c20711281201g43dc612dy35cc9f3f9802e035@mail.gmail.com> <27d1e6020711281228y42b83fal4796d5d8c11b121b@mail.gmail.com> <7ABE1953-5236-40A0-9166-F2F819FBA4C9@acm.org> <474E4A13.1090303@ronadam.com> Message-ID: On Nov 28, 2007 10:11 PM, Ron Adam wrote: > Keeping __root__ relatively short has the benefit of being able to easily > use "__root__.name" in the case where "name" was/is used in the local > scope. I don't see any reason to make it harder. There might even be a > use case for using all explicit __root__ references. Isn't this an explicit non-goal? We're talking about __builtins__, the implementation hack, not __builtin__ the module-like object you're supposed to use if you want to do things like __builtin__.open. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy From ton.vanvliet at skynet.be Thu Nov 29 08:15:34 2007 From: ton.vanvliet at skynet.be (Ton van Vliet) Date: Thu, 29 Nov 2007 08:15:34 +0100 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474D8725.8000706@cheimes.de> References: <474D8725.8000706@cheimes.de> Message-ID: On Wed, 28 Nov 2007 16:20:05 +0100, you wrote: >What name do you prefer? I'm +1 with Raymond on __root__ but I'm still >open for better suggestions. how about making it (a little bit) more explicit with __rootdict__ or __root_dict__ -- Ton From ntoronto at cs.byu.edu Thu Nov 29 11:26:37 2007 From: ntoronto at cs.byu.edu (Neil Toronto) Date: Thu, 29 Nov 2007 03:26:37 -0700 Subject: [Python-Dev] PATCH: Fast globals/builtins lookups for 2.6 Message-ID: <474E93DD.2020605@cs.byu.edu> I've posted a patch here: http://bugs.python.org/issue1518 for 2.6a0 that speeds up LOAD_GLOBAL to where it's just barely slower than LOAD_FAST for both globals and builtins. It started life here, in Python-ideas: http://mail.python.org/pipermail/python-ideas/2007-November/001212.html The idea is to cache pointers to dictionary entries rather than dictionary values as is usually suggested for speeding up globals. In my original approach, every dictionary would keep a list of "observers" that it would notify when an entry pointer became invalid. However, the surgery on PyDictObject became too invasive, to the point where the new code was affecting performance of unrelated code paths. (It was probably caching issues.) It also made some (very rare) operations on builtins and globals very, very slow. The new approach tags each PyDictObject with a "version": a 64-bit value that is incremented for every operation that invalidates at least one entry pointer. (Those are inserting set, delete, pop, clear and resize. Non-inserting set and get are unaffected.) In this approach, changes to PyDictObject are uninvasive and do not affect performance in any measurable way (as far as I can tell). Every function has a PyFastGlobalsObject, which keeps entry pointers for everything in co_names and tracks its dicts' versions so it can update the pointers when one might have become invalid. LOAD_GLOBALS uses the PyFastGlobalsObject to get globals and builtins by name index rather than by string key. With the patch, Python behaves differently in these two ways (as far as I can tell): 1. As before, a __builtins__ ({'None': None}) is created for frames whose globals do not have one. Unlike before, it's added to the globals dict rather than just kept internally. This made implementation easier - I don't think it's a big deal (but I might be wrong). 2. A change of __builtins__ (its value, not its contents) always appears at the beginning of a stack frame. (Before, changing __builtins__ in a module would be undetectable if function calls were kept within that module.) This is likely of little importance. I'd love to see it included. I have donned my asbestos underwear and my best chain mail shirt and I'm begging for comments. Neil From ncoghlan at gmail.com Thu Nov 29 11:50:03 2007 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 29 Nov 2007 20:50:03 +1000 Subject: [Python-Dev] removing the new and types modules In-Reply-To: <26869826.1196285004888.JavaMail.ngmail@webmail15> References: <26869826.1196285004888.JavaMail.ngmail@webmail15> Message-ID: <474E995B.5050503@gmail.com> henning.vonbargen at arcor.de wrote: > Sorry if this is a dumb question, but are there actually good reasons to remove "types"? Mainly because it is an unrelated grab bag of types that could be put in more topical locations - what they're for is more interesting than the mere fact that they happen to be types. As it turns out, the cleanup for Py3k (removing the members which are merely aliases for existing names) has already cut it down to only a few types which are closely related to the interpreter core. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From lists at cheimes.de Thu Nov 29 11:51:05 2007 From: lists at cheimes.de (Christian Heimes) Date: Thu, 29 Nov 2007 11:51:05 +0100 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474DF68D.6010701@canterbury.ac.nz> References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> Message-ID: <474E9999.5090401@cheimes.de> Greg Ewing wrote: > __uberglobal__ Since Python 3.0 supports all unicode chars I vote for __?berglobal__. Christian From titus at caltech.edu Thu Nov 29 11:52:50 2007 From: titus at caltech.edu (Titus Brown) Date: Thu, 29 Nov 2007 02:52:50 -0800 Subject: [Python-Dev] Memory benchmarking? Message-ID: <20071129105250.GA17096@caltech.edu> Hi all, is there a good, or standard memory benchmarking system for Python? pybench doesn't return significantly different results when Python 2.6 is compiled with pymalloc and without pymalloc. Thinking on it, I'm not too surprised -- pybench probably benchmarks a lot of stuff -- but some guidance on how/whether to benchmark different memory allocation schemes would be welcome. thanks, --titus refs: http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=105&colspec=ID%20Status%20Summary http://evanjones.ca/memoryallocator/ http://www.advogato.org/person/wingo/diary/225.html From ncoghlan at gmail.com Thu Nov 29 12:01:01 2007 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 29 Nov 2007 21:01:01 +1000 Subject: [Python-Dev] Statsvn output for /python/branches/py3k In-Reply-To: References: <474DF904.6020204@gmail.com> Message-ID: <474E9BED.7070607@gmail.com> Brett Cannon wrote: > On Nov 28, 2007 3:25 PM, Joseph Armbruster wrote: >> All, >> >> I was looking at statsvn today at work and gave it a test-run on a repo there. >> I wondered what it would look like for python3k. And... here are the results: >> >> http://www.joevial.com/statsvn/ > > Interesting. Unfortunately no one gets credit for ripping out code. =( And svnmerge committers get lots of LoC credits. Thomas's 58k line commit in September must have taken a while :) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From ntoronto at cs.byu.edu Thu Nov 29 12:06:45 2007 From: ntoronto at cs.byu.edu (Neil Toronto) Date: Thu, 29 Nov 2007 04:06:45 -0700 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474E9999.5090401@cheimes.de> References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> Message-ID: <474E9D45.8030509@cs.byu.edu> Christian Heimes wrote: > Greg Ewing wrote: >> __uberglobal__ > > Since Python 3.0 supports all unicode chars I vote for __?berglobal__. Make it untypeable to most Americans so as to discourage use? If that's what we're going for, I suggest the somewhat more self-documenting and less impossible __the_dictionary_where_all_the_builtins_are_now__. Seriously, though, I really liked __universal__. It's part of a theme: local < global < universal, and it communicates itself well. __root__ and its ilk don't bring anything concrete to mind, just abstract trees. I don't think of namespaces as trees when I'm coding a function - they're more like layers or overlays at that level. So, a +0.01 from me (after weighting for lurkerhood) for __universal__. Neil From ncoghlan at gmail.com Thu Nov 29 12:15:12 2007 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 29 Nov 2007 21:15:12 +1000 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474D8725.8000706@cheimes.de> References: <474D8725.8000706@cheimes.de> Message-ID: <474E9F40.5050707@gmail.com> Given that the *effect* of __builtins__ is to make the contents of the __builtin__ module implicitly available in every module's global namespace, why not call it __implicit__? I really don't like all of these __root__ inspired names, because __builtin__ isn't the root of any Python hierarchy that I know of. >>> import sys >>> import __builtin__ >>> __builtin__.sys Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'sys' The builtin namespace doesn't know anything about other modules, the current module's global namespace, the current function's local variables, or much of anything really. To me, the concept of "root" in a computing sense implies a node from which you can reach every other node - from the root of the filesystem you can get to every other directory, as the root user you can access any other account, etc. To those that like these names, what do you consider __root__ to be the root of? Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From mal at egenix.com Thu Nov 29 12:19:51 2007 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 29 Nov 2007 12:19:51 +0100 Subject: [Python-Dev] Memory benchmarking? In-Reply-To: <20071129105250.GA17096@caltech.edu> References: <20071129105250.GA17096@caltech.edu> Message-ID: <474EA057.5090609@egenix.com> On 2007-11-29 11:52, Titus Brown wrote: > Hi all, > > is there a good, or standard memory benchmarking system for Python? > pybench doesn't return significantly different results when Python 2.6 > is compiled with pymalloc and without pymalloc. Thinking on it, I'm not > too surprised -- pybench probably benchmarks a lot of stuff -- but some > guidance on how/whether to benchmark different memory allocation schemes > would be welcome. pybench focuses on runtime performance, not memory usage. It's way of creating and deleting objects is also highly non-standard when compared to typical use of Python in real life applications. It's also rather difficult to benchmark memory allocation, since most implementations work with some sort of pre-allocation, buffer pools or free lists. If you want to use a similar approach as pybench does, ie. benchmark small parts of the interpreter instead of generating some grand total, then you'd probably have to do this by spawning a separate process per test. > refs: > > http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=105&colspec=ID%20Status%20Summary > > http://evanjones.ca/memoryallocator/ > > http://www.advogato.org/person/wingo/diary/225.html -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 29 2007) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From lists at cheimes.de Thu Nov 29 12:36:15 2007 From: lists at cheimes.de (Christian Heimes) Date: Thu, 29 Nov 2007 12:36:15 +0100 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474E9D45.8030509@cs.byu.edu> References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> <474E9D45.8030509@cs.byu.edu> Message-ID: <474EA42F.70309@cheimes.de> Neil Toronto wrote: >> Since Python 3.0 supports all unicode chars I vote for __?berglobal__. > > Make it untypeable to most Americans so as to discourage use? If that's > what we're going for, I suggest the somewhat more self-documenting and > less impossible __the_dictionary_where_all_the_builtins_are_now__. :) OK, let's get serious again. > Seriously, though, I really liked __universal__. It's part of a theme: > local < global < universal, and it communicates itself well. __root__ > and its ilk don't bring anything concrete to mind, just abstract trees. > I don't think of namespaces as trees when I'm coding a function - > they're more like layers or overlays at that level. You are making a very good point! Thank you, you have added a new perspective to the discussion. :) I tend to agree that local, nonlocal, global and the-other-thingie are more like the layers of an onion than a tree. It makes sense to me. The name lookup starts at the local level and goes all the way out until it reaches the universal level. Or does it go in until it reaches the core of the onion? It's a matter of perspective. __universal__ or __core__ ? Christian From fredrik.johansson at gmail.com Thu Nov 29 13:03:57 2007 From: fredrik.johansson at gmail.com (Fredrik Johansson) Date: Thu, 29 Nov 2007 13:03:57 +0100 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474D8725.8000706@cheimes.de> References: <474D8725.8000706@cheimes.de> Message-ID: <3d0cebfb0711290403i1dc001cbj4c1ffe51dbfb926d@mail.gmail.com> On Nov 28, 2007 4:20 PM, Christian Heimes wrote: > What name do you prefer? I'm +1 with Raymond on __root__ but I'm still > open for better suggestions. Perhaps __basic__? Fredrik From graham.horler at gmail.com Thu Nov 29 14:07:14 2007 From: graham.horler at gmail.com (Graham Horler) Date: Thu, 29 Nov 2007 13:07:14 +0000 Subject: [Python-Dev] [poll] New name for __builtins__ References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> <474E9D45.8030509@cs.byu.edu> <474EA42F.70309@cheimes.de> Message-ID: <6framq$5ce6af@earth.karoo.kcom.com> This is an interesting thread, here is my 1c :-) Unless one is feeling chronologically challenged, it is always the __last__ layer looked in as Christian Heimes described, so maybe __lastns__ or __latter__, or even __zns__. Perhaps __final__ or __finalns__ sounds too similar to "finally:". How about __inbuilt__ :-? I don't like __finish__, __close__, __terminal__, __integral__ too ambiguous. Poll summary so far (but without vote tally, and sorry if I missed any), including the ones above. Rejected: __builtin__ GvR "I want to keep both concepts" __session__ GvR "too many unrelated meanings" __python__ GvR "But ... *everything* becomes a Python thingie." Humorous: __guts__ __pythongastric__ __the_dictionary_where_all_the_builtins_are_now__ __telescope__ __uberglobal__ With and without umlaut __zns__ Cryptic / confusing: __close__ __final__ __finalns__ __finish__ __global__ __inbuilt__ __integral__ __rootns__ __terminal__ The others: __basic__ __builtin_namespace__ __core__ __default_root__ __fixtures__ __implicit__ __inject_builtins__ __lang__ __last__ __lastns__ __latter__ __outer__ __py__ __pythoncore__ __pythonroot__ __root__ This one is popular but has beed described as "too short" __root_dict__ __rootdict__ __root_globals__ __rootnames__ __root_namespace__ __syswide__ __top__ __universal__ +0.2 from me I hope this helps to have them all in one list. From ncoghlan at gmail.com Thu Nov 29 14:16:46 2007 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 29 Nov 2007 23:16:46 +1000 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474EA42F.70309@cheimes.de> References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> <474E9D45.8030509@cs.byu.edu> <474EA42F.70309@cheimes.de> Message-ID: <474EBBBE.2010808@gmail.com> Christian Heimes wrote: > I tend to agree that local, nonlocal, global and the-other-thingie are > more like the layers of an onion than a tree. It makes sense to me. The > name lookup starts at the local level and goes all the way out until it > reaches the universal level. Or does it go in until it reaches the core > of the onion? It's a matter of perspective. __universal__ or __core__ ? Function locals, module globals and program universals would make more sense to me - outer layers have a broader scope than inner layers. If we wanted to beat the metaphor to death we could even rename nonlocal to regional ;) Cheers, Nick. P.S. Just to be clear, I am definitely NOT suggesting that renaming nonlocal like that would be a good idea :) -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From lists at cheimes.de Thu Nov 29 14:23:48 2007 From: lists at cheimes.de (Christian Heimes) Date: Thu, 29 Nov 2007 14:23:48 +0100 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474EBBBE.2010808@gmail.com> References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> <474E9D45.8030509@cs.byu.edu> <474EA42F.70309@cheimes.de> <474EBBBE.2010808@gmail.com> Message-ID: <474EBD64.4070704@cheimes.de> Nick Coghlan wrote: > Function locals, module globals and program universals would make more > sense to me - outer layers have a broader scope than inner layers. __universal__ rhymes with the other __*al__ names, too. I'm shifting my vote from __root__ to __universal__. All hail the Aussies! :) Christian From graham.horler at gmail.com Thu Nov 29 14:47:44 2007 From: graham.horler at gmail.com (Graham Horler) Date: Thu, 29 Nov 2007 13:47:44 +0000 Subject: [Python-Dev] [poll] New name for __builtins__ References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> <474E9D45.8030509@cs.byu.edu> <474EA42F.70309@cheimes.de> <6framq$5ce6af@earth.karoo.kcom.com> Message-ID: <6fsfi8$5bl9rn@venus.eclipse.kcom.com> Are we scraping the __bottom__ of the English language __barrel__? Perhaps someone here can draw some inspiration from __monty__ python's flying __circus__. It would be nice to have a name with a pythonic __ground__. Unfortunately that show is not my __staple__ entertainment, and although I have a __general__ idea what the show's about, it needs a __canonic__ understanding of its __founding__ __elements__ in order to be used for __primary__ ideas. Sorry, went mad for a few seconds there. From ijmorlan at cs.uwaterloo.ca Thu Nov 29 15:06:34 2007 From: ijmorlan at cs.uwaterloo.ca (Isaac Morland) Date: Thu, 29 Nov 2007 09:06:34 -0500 (EST) Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <6fsfi8$5bl9rn@venus.eclipse.kcom.com> References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> <474E9D45.8030509@cs.byu.edu> <474EA42F.70309@cheimes.de> <6framq$5ce6af@earth.karoo.kcom.com> <6fsfi8$5bl9rn@venus.eclipse.kcom.com> Message-ID: On Thu, 29 Nov 2007, Graham Horler wrote: > Perhaps someone here can draw some inspiration from __monty__ python's > flying __circus__. It would be nice to have a name with a pythonic > __ground__. > > Unfortunately that show is not my __staple__ entertainment, and although > I have a __general__ idea what the show's about, it needs a __canonic__ > understanding of its __founding__ __elements__ in order to be used for > __primary__ ideas. For my part, I like __universal__. I was going to suggest __cosmological__ to leave space in case we need to put something between __global__ and (what is now called) __builtin__, but then I remembered the Galaxy Song, and thought of __galactic__ for that eventuality. I wonder how much you could sell the naming rights for? i.e. call it __[name of sponsor]__. Python's pretty popular, such advertising should be worth something.... PS: I actually do like __universal__. The rest may be somewhat addled. Isaac Morland CSCF Web Guru DC 2554C, x36650 WWW Software Specialist From gnewsg at gmail.com Thu Nov 29 15:10:57 2007 From: gnewsg at gmail.com (Giampaolo Rodola') Date: Thu, 29 Nov 2007 06:10:57 -0800 (PST) Subject: [Python-Dev] ssl module integration with asyncore In-Reply-To: <07Nov28.210014pst."58696"@synergy1.parc.xerox.com> References: <07Nov26.102313pst."58696"@synergy1.parc.xerox.com> <07Nov26.174736pst."58696"@synergy1.parc.xerox.com> <33b2d8d1-ac00-49c9-8323-82c2fa1d3847@d21g2000prf.googlegroups.com> <07Nov28.152632pst."58696"@synergy1.parc.xerox.com> <0e3948ae-6e24-4ed6-9152-3bd8457f7547@d27g2000prf.googlegroups.com> <07Nov28.182739pst."58696"@synergy1.parc.xerox.com> <07Nov28.210014pst."58696"@synergy1.parc.xerox.com> Message-ID: <4f3d8f74-b30a-4f49-a940-46040001c26f@i12g2000prf.googlegroups.com> On 29 Nov, 06:00, Bill Janssen wrote: > I think it's simpler to let the SSL module do it, even though it comes > at the expense of blocking the thread till the handshake is complete. > That's essentially what happens already. The question is whether the > SSL setup code is allowed to block the non-blocking socket till the > SSL handshake is complete. No, the SSL code should NOT be allowed to block anything in any case, even though the handshake is still not completed, in which case just retry it at a later time. Meanwhile the application must be able to do other things, like read or write from other sockets. If the handshake would complete in 1 second that would mean that the application won't do anything else until that operation is finished, holding up the entire loop. That means you would block other clients connected at that time (e.g. applications serving more than 1 client at time), transfers in progress and so on... That would be only reasonable when using threads or multiple processes but not in an asynchronous environment. From lists at cheimes.de Thu Nov 29 15:24:01 2007 From: lists at cheimes.de (Christian Heimes) Date: Thu, 29 Nov 2007 15:24:01 +0100 Subject: [Python-Dev] Statsvn output for /python/branches/py3k In-Reply-To: <474E9BED.7070607@gmail.com> References: <474DF904.6020204@gmail.com> <474E9BED.7070607@gmail.com> Message-ID: <474ECB81.7010301@cheimes.de> Nick Coghlan wrote: > And svnmerge committers get lots of LoC credits. Thomas's 58k line > commit in September must have taken a while :) Exactly! Most of my LoC credits must either come from svnmerge or my work on PCBuild9. Visual Studio's project xml files contain a *lot* of space and meaningless lines. Christian From barry at python.org Thu Nov 29 16:27:37 2007 From: barry at python.org (Barry Warsaw) Date: Thu, 29 Nov 2007 10:27:37 -0500 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <6fsfi8$5bl9rn@venus.eclipse.kcom.com> References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> <474E9D45.8030509@cs.byu.edu> <474EA42F.70309@cheimes.de> <6framq$5ce6af@earth.karoo.kcom.com> <6fsfi8$5bl9rn@venus.eclipse.kcom.com> Message-ID: <8602294A-B586-479D-A5F5-C6E800107C2F@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 29, 2007, at 8:47 AM, Graham Horler wrote: > Perhaps someone here can draw some inspiration from __monty__ python's > flying __circus__. It would be nice to have a name with a pythonic > __ground__. Clearly then, it should be called __bruce__. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR07aaXEjvBPtnXfVAQLlawQApbUkTl9BHm31evewnpn8OCqpz5RM4k6N f4wfJ2HIZgDrFVkQLnBvWKp1t4b+HD+VGYHWxZgAjJ6+CFCFklkhOvxuDoyphuVu bJLxUMrkra9PyM4Mrs6O8lc+z0YyqW/gGyEqtkXu/YVDK8bcEtVo6vQg9cjbtfSj a7TLnkoBdUk= =tKo/ -----END PGP SIGNATURE----- From phd at phd.pp.ru Thu Nov 29 16:38:22 2007 From: phd at phd.pp.ru (Oleg Broytmann) Date: Thu, 29 Nov 2007 18:38:22 +0300 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <8602294A-B586-479D-A5F5-C6E800107C2F@python.org> References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> <474E9D45.8030509@cs.byu.edu> <474EA42F.70309@cheimes.de> <6framq$5ce6af@earth.karoo.kcom.com> <6fsfi8$5bl9rn@venus.eclipse.kcom.com> <8602294A-B586-479D-A5F5-C6E800107C2F@python.org> Message-ID: <20071129153822.GB14499@phd.pp.ru> On Thu, Nov 29, 2007 at 10:27:37AM -0500, Barry Warsaw wrote: > > Perhaps someone here can draw some inspiration from __monty__ python's > > flying __circus__. It would be nice to have a name with a pythonic > > __ground__. > > Clearly then, it should be called __bruce__. No, __spam__! __Oleg__Stressed__by__undersores__'ly yours. -- Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From pje at telecommunity.com Thu Nov 29 17:15:35 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 29 Nov 2007 11:15:35 -0500 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474EBBBE.2010808@gmail.com> References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> <474E9D45.8030509@cs.byu.edu> <474EA42F.70309@cheimes.de> <474EBBBE.2010808@gmail.com> Message-ID: <20071129161543.A98703A405E@sparrow.telecommunity.com> At 11:16 PM 11/29/2007 +1000, Nick Coghlan wrote: >Function locals, module globals and program universals would make more >sense to me - outer layers have a broader scope than inner layers. +1 for __universal__ From janssen at parc.com Thu Nov 29 17:23:49 2007 From: janssen at parc.com (Bill Janssen) Date: Thu, 29 Nov 2007 08:23:49 PST Subject: [Python-Dev] ssl module integration with asyncore In-Reply-To: <4f3d8f74-b30a-4f49-a940-46040001c26f@i12g2000prf.googlegroups.com> References: <07Nov26.102313pst."58696"@synergy1.parc.xerox.com> <07Nov26.174736pst."58696"@synergy1.parc.xerox.com> <33b2d8d1-ac00-49c9-8323-82c2fa1d3847@d21g2000prf.googlegroups.com> <07Nov28.152632pst."58696"@synergy1.parc.xerox.com> <0e3948ae-6e24-4ed6-9152-3bd8457f7547@d27g2000prf.googlegroups.com> <07Nov28.182739pst."58696"@synergy1.parc.xerox.com> <07Nov28.210014pst."58696"@synergy1.parc.xerox.com> <4f3d8f74-b30a-4f49-a940-46040001c26f@i12g2000prf.googlegroups.com> Message-ID: <07Nov29.082350pst."58696"@synergy1.parc.xerox.com> > No, the SSL code should NOT be allowed to block anything in any case, > even though the handshake is still not completed, in which case just > retry it at a later time. That's why there's "do_handshake_on_connect" in the first place. I'm just talking about what the SSL module should do if you don't use it when you call wrap_socket(). If you do use it, driving the handshake to completion is up to your code, and you can use select, poll, and/or handle_read_event() or handle_write_event() as you see fit. I think we're talking past each other here. Using asyncore (as you know) is not simple; I believe I've outlined how to use it successfully and properly with the SSL module. Bill From guido at python.org Thu Nov 29 18:29:59 2007 From: guido at python.org (Guido van Rossum) Date: Thu, 29 Nov 2007 09:29:59 -0800 Subject: [Python-Dev] PATCH: Fast globals/builtins lookups for 2.6 In-Reply-To: <474E93DD.2020605@cs.byu.edu> References: <474E93DD.2020605@cs.byu.edu> Message-ID: Cool! Can't wait to get my hands on it. How does it affect pystone? What happens if the globals are not a real dict but an instance of another collections.MutableMapping (virtual or real) subclass? We've worked hard (well, some folks have) to enable this. It would be a show-stopper if this broke (or changed semantics or became significantly slower). --Guido On Nov 29, 2007 2:26 AM, Neil Toronto wrote: > I've posted a patch here: > > http://bugs.python.org/issue1518 > > for 2.6a0 that speeds up LOAD_GLOBAL to where it's just barely slower > than LOAD_FAST for both globals and builtins. It started life here, in > Python-ideas: > > http://mail.python.org/pipermail/python-ideas/2007-November/001212.html > > The idea is to cache pointers to dictionary entries rather than > dictionary values as is usually suggested for speeding up globals. In my > original approach, every dictionary would keep a list of "observers" > that it would notify when an entry pointer became invalid. However, the > surgery on PyDictObject became too invasive, to the point where the new > code was affecting performance of unrelated code paths. (It was probably > caching issues.) It also made some (very rare) operations on builtins > and globals very, very slow. > > The new approach tags each PyDictObject with a "version": a 64-bit value > that is incremented for every operation that invalidates at least one > entry pointer. (Those are inserting set, delete, pop, clear and resize. > Non-inserting set and get are unaffected.) In this approach, changes to > PyDictObject are uninvasive and do not affect performance in any > measurable way (as far as I can tell). > > Every function has a PyFastGlobalsObject, which keeps entry pointers for > everything in co_names and tracks its dicts' versions so it can update > the pointers when one might have become invalid. LOAD_GLOBALS uses the > PyFastGlobalsObject to get globals and builtins by name index rather > than by string key. > > With the patch, Python behaves differently in these two ways (as far as > I can tell): > > 1. As before, a __builtins__ ({'None': None}) is created for frames > whose globals do not have one. Unlike before, it's added to the globals > dict rather than just kept internally. This made implementation easier - > I don't think it's a big deal (but I might be wrong). > > 2. A change of __builtins__ (its value, not its contents) always appears > at the beginning of a stack frame. (Before, changing __builtins__ in a > module would be undetectable if function calls were kept within that > module.) This is likely of little importance. > > I'd love to see it included. I have donned my asbestos underwear and my > best chain mail shirt and I'm begging for comments. > > Neil > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Thu Nov 29 18:54:09 2007 From: guido at python.org (Guido van Rossum) Date: Thu, 29 Nov 2007 09:54:09 -0800 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <20071129161543.A98703A405E@sparrow.telecommunity.com> References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> <474E9D45.8030509@cs.byu.edu> <474EA42F.70309@cheimes.de> <474EBBBE.2010808@gmail.com> <20071129161543.A98703A405E@sparrow.telecommunity.com> Message-ID: I nearly choked on my coffee when I read the "naming rights" suggestion. :-) Then I started leaning towards __universal__. But then I thought, what if we renamed the __builtin__ module instead to builtins, and left __builtins__ alone? In Python 0.1, __builtin__ *was* called builtin, and I think the reason for renaming it wasn't particularly well thought-out; as a *module*, I'm not sure that it really needs to have such a special name (I don't think it's more special than sys, anyway). There's no motivation in the checkin comment that renamed it (r3527). -- --Guido van Rossum (home page: http://www.python.org/~guido/) From ntoronto at cs.byu.edu Thu Nov 29 22:07:40 2007 From: ntoronto at cs.byu.edu (Neil Toronto) Date: Thu, 29 Nov 2007 14:07:40 -0700 Subject: [Python-Dev] PATCH: Fast globals/builtins lookups for 2.6 In-Reply-To: References: <474E93DD.2020605@cs.byu.edu> Message-ID: <474F2A1C.8010105@cs.byu.edu> Guido van Rossum wrote: > Cool! Can't wait to get my hands on it. How does it affect pystone? Pystone likes it, according to my tests and Chris's. On his machine, if I'm reading these stones right, it takes about 7% off the run time on average. On mine it takes off 4%. > What happens if the globals are not a real dict but an instance of > another collections.MutableMapping (virtual or real) subclass? Globals has to be a real dict or a subclass, because otherwise PyFastGlobalsObject won't be able to point directly at its entries. This doesn't change anything, since globals had to be a real dict or subclass before. > We've worked hard (well, some folks have) to enable this. It would be > a show-stopper if this broke (or changed semantics or became > significantly slower). Besides what I outlined about __builtins__ (which should be an arbitrary implementation detail), everything is exactly the same. The details of fast globals are completely transparent to everything but PyDictObject (in which they're nearly insignificant) and PyFastGlobalsObject. In other words, every other bit of code in the interpreter can happily do whatever the heck it wants with globals and builtins without having to worry about messing anything up. Since it's nearly transparent to the interpreter core, Python-the-language shouldn't see any differences at all. But then, I know less about the rest of the core than just about everybody else here, so I may just be talking out of my rear. :) Pystone and my microbenchmarks look good, but we don't know yet about Pybench. On my tests, it's nearly the same, with small variations in individual tests. On Chris's, there are large variations that appear (to me) to be random. Pybench does almost nothing with globals, though - the numbers on that really only need to stay put. Neil From guido at python.org Thu Nov 29 23:05:47 2007 From: guido at python.org (Guido van Rossum) Date: Thu, 29 Nov 2007 14:05:47 -0800 Subject: [Python-Dev] PATCH: Fast globals/builtins lookups for 2.6 In-Reply-To: <474F2A1C.8010105@cs.byu.edu> References: <474E93DD.2020605@cs.byu.edu> <474F2A1C.8010105@cs.byu.edu> Message-ID: On Nov 29, 2007 1:07 PM, Neil Toronto wrote: > Guido van Rossum wrote: > > Cool! Can't wait to get my hands on it. How does it affect pystone? > > Pystone likes it, according to my tests and Chris's. On his machine, if > I'm reading these stones right, it takes about 7% off the run time on > average. On mine it takes off 4%. Hm. On my Linux box, in the trunk: Before the patch: Pystone(1.1) time for 50000 passes = 1.16 This machine benchmarks at 43103.4 pystones/second After the patch: Pystone(1.1) time for 50000 passes = 1.14 This machine benchmarks at 43859.6 pystones/second That's only about 1.75% faster. But pystone is a lousy benchmark. > > What happens if the globals are not a real dict but an instance of > > another collections.MutableMapping (virtual or real) subclass? > > Globals has to be a real dict or a subclass, because otherwise > PyFastGlobalsObject won't be able to point directly at its entries. This > doesn't change anything, since globals had to be a real dict or subclass > before. > > > We've worked hard (well, some folks have) to enable this. It would be > > a show-stopper if this broke (or changed semantics or became > > significantly slower). > > Besides what I outlined about __builtins__ (which should be an arbitrary > implementation detail), everything is exactly the same. The details of > fast globals are completely transparent to everything but PyDictObject > (in which they're nearly insignificant) and PyFastGlobalsObject. In > other words, every other bit of code in the interpreter can happily do > whatever the heck it wants with globals and builtins without having to > worry about messing anything up. Since it's nearly transparent to the > interpreter core, Python-the-language shouldn't see any differences at all. > > But then, I know less about the rest of the core than just about > everybody else here, so I may just be talking out of my rear. :) My apologies. I though I remembered we changed exec() and eval() to accept a totally arbitrary mapping for globals() -- but that's not the case, it must be a dict subclass. > Pystone and my microbenchmarks look good, but we don't know yet about > Pybench. On my tests, it's nearly the same, with small variations in > individual tests. On Chris's, there are large variations that appear (to > me) to be random. Pybench does almost nothing with globals, though - the > numbers on that really only need to stay put. The only pybench tests that matter would be the ones checking dict performance. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From tjreedy at udel.edu Thu Nov 29 23:05:37 2007 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 29 Nov 2007 17:05:37 -0500 Subject: [Python-Dev] removing the new and types modules References: <26869826.1196285004888.JavaMail.ngmail@webmail15> <474E995B.5050503@gmail.com> Message-ID: "Nick Coghlan" wrote in message news:474E995B.5050503 at gmail.com... | henning.vonbargen at arcor.de wrote: | > Sorry if this is a dumb question, but are there actually good reasons to remove "types"? | | Mainly because it is an unrelated grab bag of types that could be put in | more topical locations - what they're for is more interesting than the | mere fact that they happen to be types. An additional answer is that a number of changes in the 2.x series have have the types modules more or less obsolete. 1. It was once intended, I believe,to be a more or less complete catalog of types. As the number of internal implementation types have increased (and changed from release to release), this goal has become more difficult and less sensible. 2. The type-class unification that started in 2.2 unified several type objects with their corresponding (builtin) constructors (which became the __call__ methods of the type objects). This mades the type objects that most people are most interested in directly accessible as builtins. "type(o) == str" did not work when 'str' was a just conversion function rather than the string type object! tjr From greg.ewing at canterbury.ac.nz Thu Nov 29 23:22:03 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 30 Nov 2007 11:22:03 +1300 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> Message-ID: <474F3B8B.4000305@canterbury.ac.nz> The next step up from global would be __galactic__. -- Greg From greg.ewing at canterbury.ac.nz Thu Nov 29 23:31:54 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 30 Nov 2007 11:31:54 +1300 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474E9F40.5050707@gmail.com> References: <474D8725.8000706@cheimes.de> <474E9F40.5050707@gmail.com> Message-ID: <474F3DDA.1090706@canterbury.ac.nz> Nick Coghlan wrote: > why not call it __implicit__? But isn't __explicit__ better than __implicit__? :-) I tend to agree about __root__, though -- it just doesn't seem quite right somehow. -- Greg From phd at phd.pp.ru Thu Nov 29 23:46:41 2007 From: phd at phd.pp.ru (Oleg Broytmann) Date: Fri, 30 Nov 2007 01:46:41 +0300 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474F3B8B.4000305@canterbury.ac.nz> References: <474D8725.8000706@cheimes.de> <474F3B8B.4000305@canterbury.ac.nz> Message-ID: <20071129224641.GA20097@phd.pp.ru> On Fri, Nov 30, 2007 at 11:22:03AM +1300, Greg Ewing wrote: > The next step up from global would be __galactic__. Let me skip __universe[al]__ and go directly to The Ultimate Questions: Is there __life__ after __death__? Does __Deity__ exist? What attributes, properties and keys has __He__ got? Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From greg.ewing at canterbury.ac.nz Thu Nov 29 23:42:25 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 30 Nov 2007 11:42:25 +1300 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <474EA42F.70309@cheimes.de> References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> <474E9D45.8030509@cs.byu.edu> <474EA42F.70309@cheimes.de> Message-ID: <474F4051.4040404@canterbury.ac.nz> Another idea: __ubiquitous__ -- Greg From greg.ewing at canterbury.ac.nz Thu Nov 29 23:47:15 2007 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 30 Nov 2007 11:47:15 +1300 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <6framq$5ce6af@earth.karoo.kcom.com> References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> <474E9D45.8030509@cs.byu.edu> <474EA42F.70309@cheimes.de> <6framq$5ce6af@earth.karoo.kcom.com> Message-ID: <474F4173.6080708@canterbury.ac.nz> > __the_dictionary_where_all_the_builtins_are_now__ __the_entry_formerly_known_as_builtins__ -- Greg From tjreedy at udel.edu Fri Nov 30 00:12:53 2007 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 29 Nov 2007 18:12:53 -0500 Subject: [Python-Dev] [poll] New name for __builtins__ References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de><474E9D45.8030509@cs.byu.edu> <474EA42F.70309@cheimes.de><474EBBBE.2010808@gmail.com><20071129161543.A98703A405E@sparrow.telecommunity.com> Message-ID: "Guido van Rossum" wrote in message news:ca471dc20711290954v173cf2ebx9427de211ba9afbd at mail.gmail.com... | But then I thought, what if we renamed the __builtin__ module instead | to builtins, and left __builtins__ alone? | | In Python 0.1, __builtin__ *was* called builtin, and I think the | reason for renaming it wasn't particularly well thought-out; as a | *module*, I'm not sure that it really needs to have such a special | name (I don't think it's more special than sys, anyway). There's no | motivation in the checkin comment that renamed it (r3527). +1 for plain 'builtins' or whatever for the name of the module. I believe it would have been less confusing to me learning Python, (and still today ;-) if it had been this way 10 years ago. The rationale for special __xxx__ names (identifiers) is to avoid namespace clashes. So they are only needed for namespace names bound to objects, including string objects representing definition names. Since '__builtin__' is merely a string object bound to '__name__' (I presume) in the module itself and to '__builtins__' in all others, a string that did not imitate a reserved identifier would be clearer, at least to me. Similarly, by the way, the main module might justifiably be '__name__'ed 'main' rather than '__main__' since whatever string is bound to '__name__' is *not* in the module namespace. "if __name__ == 'main' " is a bit easier to type and to me a bit clearer. The only problem would be if someone put the incantation into a non-main module named 'main.py', but the same is true today of '__main__.py'. And I would consider either a buggy practice. These are the only two builtin strings I can think of that have the form of special names, even though they are not actually identifiers. If so, they are the only two 'special names' that *must* be quoted as strings, while binding names (identifiers) usually are not. If both were changed, then 'special names' would simply be 'internal namespace names used by the implementation'. I think this would make it easier for beginners to keep separate the notions of 'identifier' and 'string'. Terry Jan Reedy From facundobatista at gmail.com Fri Nov 30 00:31:01 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Thu, 29 Nov 2007 20:31:01 -0300 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> <474E9D45.8030509@cs.byu.edu> <474EA42F.70309@cheimes.de> <474F4051.4040404@canterbury.ac.nz> Message-ID: 2007/11/29, Greg Ewing : > > __ubiquitous__ > Uh! Great! +1 -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From guido at python.org Fri Nov 30 00:34:27 2007 From: guido at python.org (Guido van Rossum) Date: Thu, 29 Nov 2007 15:34:27 -0800 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> <474E9D45.8030509@cs.byu.edu> <474EA42F.70309@cheimes.de> <474EBBBE.2010808@gmail.com> <20071129161543.A98703A405E@sparrow.telecommunity.com> Message-ID: On Nov 29, 2007 3:12 PM, Terry Reedy wrote: > "Guido van Rossum" wrote in message > news:ca471dc20711290954v173cf2ebx9427de211ba9afbd at mail.gmail.com... > | But then I thought, what if we renamed the __builtin__ module instead > | to builtins, and left __builtins__ alone? > | > | In Python 0.1, __builtin__ *was* called builtin, and I think the > | reason for renaming it wasn't particularly well thought-out; as a > | *module*, I'm not sure that it really needs to have such a special > | name (I don't think it's more special than sys, anyway). There's no > | motivation in the checkin comment that renamed it (r3527). > > +1 for plain 'builtins' or whatever for the name of the module. I believe > it would have been less confusing to me learning Python, (and still today > ;-) if it had been this way 10 years ago. Right. It was this way 15 years ago. :-) > The rationale for special __xxx__ names (identifiers) is to avoid namespace > clashes. So they are only needed for namespace names bound to objects, > including string objects representing definition names. Since > '__builtin__' is merely a string object bound to '__name__' (I presume) in > the module itself and to '__builtins__' in all others, a string that did > not imitate a reserved identifier would be clearer, at least to me. Right again. > Similarly, by the way, the main module might justifiably be '__name__'ed > 'main' rather than '__main__' since whatever string is bound to '__name__' > is *not* in the module namespace. "if __name__ == 'main' " is a bit easier > to type and to me a bit clearer. The only problem would be if someone put > the incantation into a non-main module named 'main.py', but the same is > true today of '__main__.py'. And I would consider either a buggy practice. Not quite. main.py is a valid regular module name and shouldn't be endowed with special powers. But __main__.py would be a "reserved" module name, like __init__.py, and could reasonably be expected to have extra semantics. > These are the only two builtin strings I can think of that have the form of > special names, even though they are not actually identifiers. I'm not sure I follow. A module name is an identifier too. (This is how it's used by import.) > If so, they > are the only two 'special names' that *must* be quoted as strings, while > binding names (identifiers) usually are not. If both were changed, then > 'special names' would simply be 'internal namespace names used by the > implementation'. I think this would make it easier for beginners to keep > separate the notions of 'identifier' and 'string'. I think you're looking at this from the wrong angle. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From jason.orendorff at gmail.com Fri Nov 30 01:05:26 2007 From: jason.orendorff at gmail.com (Jason Orendorff) Date: Thu, 29 Nov 2007 18:05:26 -0600 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> <474E9D45.8030509@cs.byu.edu> <474EA42F.70309@cheimes.de> <474EBBBE.2010808@gmail.com> <20071129161543.A98703A405E@sparrow.telecommunity.com> Message-ID: On Nov 29, 2007 11:54 AM, Guido van Rossum wrote: > But then I thought, what if we renamed the __builtin__ module instead > to builtins, and left __builtins__ alone? Hmm. __builtins__ is a magic hook, but __builtin__-the-module isn't the thing it hooks, exactly, not the way __import__ hooks import or __iter__ hooks iter(). Really the __builtin__ module *implements* the __builtins__ hook protocol. It would be cool to have a name for __builtin__ the module that suggests that. I suggest sys.builtins. The builtins module feels both central enough and magical enough to belong in sys. And a lot of other stuff in sys has the same "it's fun but slightly crazy to tweak this knob" vibe. And, for sandboxers, mysandbox.builtins seems like a nice parallel to sys.builtins, with "sys" serving the bonus role of suggesting "unrestricted access". -j From ntoronto at cs.byu.edu Fri Nov 30 06:43:12 2007 From: ntoronto at cs.byu.edu (Neil Toronto) Date: Thu, 29 Nov 2007 22:43:12 -0700 Subject: [Python-Dev] PATCH: Fast globals/builtins lookups for 2.6 In-Reply-To: References: <474E93DD.2020605@cs.byu.edu> <474F2A1C.8010105@cs.byu.edu> Message-ID: <474FA2F0.6020305@cs.byu.edu> Guido van Rossum wrote: > Hm. > > On my Linux box, in the trunk: > > Before the patch: > Pystone(1.1) time for 50000 passes = 1.16 > This machine benchmarks at 43103.4 pystones/second > > After the patch: > Pystone(1.1) time for 50000 passes = 1.14 > This machine benchmarks at 43859.6 pystones/second > > That's only about 1.75% faster. But pystone is a lousy benchmark. I'm not aware of any benchmark that isn't. :) Can you humor me and change the PY_LONG_LONG to Py_ssize_t in both PyDictObject and PyFastGlobalsObject and see if that helps? It does on one of my test machines. Speaking of which, here's a question for everybody. I was wondering whether 64 bits is necessary. It takes an hour of concerted effort - nothing but "module.d = 1; del module.d" for an hour straight - to overflow a 32-bit version number. Is anybody going to actually get close to doing that in a global namespace? I don't think a malicious user could exploit it. The most they could do is segfault by doing exactly 2**32 entry-invalidating operations and then one get or set. They've got better things to do if they're running code on your machine. FWIW - and I wouldn't bother with this if I weren't mucking about with dict internals - with a 32-bit version number, I've verified that gcc emits only one extra instruction in dict functions that increment it. It's two for a 64-bit number. The version test in LOAD_GLOBAL does take a bit more time with 64 bits, though. Neil From bh at intevation.de Fri Nov 30 12:17:54 2007 From: bh at intevation.de (Bernhard Herzog) Date: Fri, 30 Nov 2007 12:17:54 +0100 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: <20071129224641.GA20097@phd.pp.ru> (Oleg Broytmann's message of "Fri, 30 Nov 2007 01:46:41 +0300") References: <474D8725.8000706@cheimes.de> <474F3B8B.4000305@canterbury.ac.nz> <20071129224641.GA20097@phd.pp.ru> Message-ID: Oleg Broytmann writes: > On Fri, Nov 30, 2007 at 11:22:03AM +1300, Greg Ewing wrote: >> The next step up from global would be __galactic__. > > Let me skip __universe[al]__ and go directly to The Ultimate > Questions: So maybe it should be called __42__? Bernhard From steve at holdenweb.com Fri Nov 30 14:52:34 2007 From: steve at holdenweb.com (Steve Holden) Date: Fri, 30 Nov 2007 08:52:34 -0500 Subject: [Python-Dev] PATCH: Fast globals/builtins lookups for 2.6 In-Reply-To: <474FA2F0.6020305@cs.byu.edu> References: <474E93DD.2020605@cs.byu.edu> <474F2A1C.8010105@cs.byu.edu> <474FA2F0.6020305@cs.byu.edu> Message-ID: Neil Toronto wrote: > Guido van Rossum wrote: >> Hm. >> >> On my Linux box, in the trunk: >> >> Before the patch: >> Pystone(1.1) time for 50000 passes = 1.16 >> This machine benchmarks at 43103.4 pystones/second >> >> After the patch: >> Pystone(1.1) time for 50000 passes = 1.14 >> This machine benchmarks at 43859.6 pystones/second >> >> That's only about 1.75% faster. But pystone is a lousy benchmark. > > I'm not aware of any benchmark that isn't. :) > > Can you humor me and change the PY_LONG_LONG to Py_ssize_t in both > PyDictObject and PyFastGlobalsObject and see if that helps? It does on > one of my test machines. > > Speaking of which, here's a question for everybody. I was wondering > whether 64 bits is necessary. It takes an hour of concerted effort - > nothing but "module.d = 1; del module.d" for an hour straight - to > overflow a 32-bit version number. Is anybody going to actually get close > to doing that in a global namespace? > Of course not. And 640k is as much memory as anyone could reasonably need ... > I don't think a malicious user could exploit it. The most they could do > is segfault by doing exactly 2**32 entry-invalidating operations and > then one get or set. They've got better things to do if they're running > code on your machine. > > FWIW - and I wouldn't bother with this if I weren't mucking about with > dict internals - with a 32-bit version number, I've verified that gcc > emits only one extra instruction in dict functions that increment it. > It's two for a 64-bit number. The version test in LOAD_GLOBAL does take > a bit more time with 64 bits, though. > That's a good local optimization for today's conditions, probably. Who nows whether it will survive the next ten years. And decisions like that have a weird habit of running into pathological cases whose authors curse you when they find out where the problem arose. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ From ntoronto at cs.byu.edu Fri Nov 30 17:14:04 2007 From: ntoronto at cs.byu.edu (Neil Toronto) Date: Fri, 30 Nov 2007 09:14:04 -0700 Subject: [Python-Dev] PATCH: Fast globals/builtins lookups for 2.6 In-Reply-To: References: <474E93DD.2020605@cs.byu.edu> <474F2A1C.8010105@cs.byu.edu> <474FA2F0.6020305@cs.byu.edu> Message-ID: <475036CC.6020306@cs.byu.edu> Steve Holden wrote: > Neil Toronto wrote: >> Speaking of which, here's a question for everybody. I was wondering >> whether 64 bits is necessary. It takes an hour of concerted effort - >> nothing but "module.d = 1; del module.d" for an hour straight - to >> overflow a 32-bit version number. Is anybody going to actually get close >> to doing that in a global namespace? >> > Of course not. And 640k is as much memory as anyone could reasonably > need ... Point taken - forget I asked. Neil From facundobatista at gmail.com Fri Nov 30 18:18:34 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Fri, 30 Nov 2007 14:18:34 -0300 Subject: [Python-Dev] Decimal news: speedup and stabilization In-Reply-To: <4747AEEF.2010104@gmail.com> References: <4747AEEF.2010104@gmail.com> Message-ID: 2007/11/24, Nick Coghlan : > Did you change the Decimal repr to use the same format for the mantissa? I don't understand the question. The output of repr() does not show this internals... > Could you also check the performance gain against the telco benchmark > which is in the sandbox? [1] I tested different versions of Decimal with this telco.py. With Python from the trunk (r58550), which is the last decimal.py version previous to this change: 1241.8 After changed it to keep _int as string: 869.3 (30% faster!) But still there're a lot of room for improvements. I just commited other patch from Mark, where he reordered __new__, to minimize isinstance() checks for the most used types.} After new reordering patch: 672.9 (22% faster!) :) Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From status at bugs.python.org Fri Nov 30 19:06:05 2007 From: status at bugs.python.org (Tracker) Date: Fri, 30 Nov 2007 18:06:05 +0000 (UTC) Subject: [Python-Dev] Summary of Tracker Issues Message-ID: <20071130180605.C0197782ED@psf.upfronthosting.co.za> ACTIVITY SUMMARY (11/23/07 - 11/30/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1323 open (+24) / 11687 closed (+11) / 13010 total (+35) Open issues with patches: 418 Average duration of open issues: 699 days. Median duration of open issues: 844 days. Open Issues Breakdown open 1315 (+23) pending 8 ( +1) Issues Created Or Reopened (36) _______________________________ Warning required when calling register() on an ABCMeta subclass 11/30/07 CLOSED http://bugs.python.org/issue1109 reopened gvanrossum py3k, patch Patch to remove unbound methods 11/24/07 CLOSED http://bugs.python.org/issue1493 created tiran py3k, patch DOM-Documentation should mention that appendChild() removes the 11/24/07 CLOSED http://bugs.python.org/issue1494 created dennda Unicode in a comment. 11/24/07 CLOSED http://bugs.python.org/issue1495 created wiscados add str.maketrans() 11/25/07 CLOSED http://bugs.python.org/issue1496 created georg.brandl py3k, patch Patch to remove API to create new unbound methods 11/25/07 http://bugs.python.org/issue1497 created tiran py3k, patch Rename __builtins__ to __root_namespace__? 11/26/07 http://bugs.python.org/issue1498 created gvanrossum py3k failure behaviour of compile() is missing 11/26/07 http://bugs.python.org/issue1499 created AchimGaedke Example using range doesn't give claimed results 11/26/07 CLOSED http://bugs.python.org/issue1500 created basingwerk 0 ** 0 documentation 11/26/07 http://bugs.python.org/issue1501 created jimjjewett itertools should grow chunkify 11/26/07 CLOSED http://bugs.python.org/issue1502 created arkanes test_xmlrpc is still flakey 11/27/07 http://bugs.python.org/issue1503 created gvanrossum Add 2to3 fixer for (un)bound methods 11/27/07 http://bugs.python.org/issue1504 reopened tiran py3k Changes to PyMethod_New breaks ctypes on Windows 11/27/07 CLOSED http://bugs.python.org/issue1505 created tiran py3k func alloca inside ctypes lib needs #include on solar 11/27/07 http://bugs.python.org/issue1506 created mthibaut complex constructor loses signs of zeros 11/27/07 http://bugs.python.org/issue1507 created marketdickinson Removal of stale code in _csv.c / pyexpat.c 11/27/07 CLOSED http://bugs.python.org/issue1508 created JosephArmbruster py3k Documentation lacking for the sqlite3 module. 11/28/07 http://bugs.python.org/issue1509 created pmawhorter help for file/open should state which is prefered. 11/28/07 http://bugs.python.org/issue1510 created carlfk csv input converts \r\n to \n but csv output does not when a fie 11/28/07 http://bugs.python.org/issue1511 created fenner Removal of stale code in pyconfig.h 11/28/07 http://bugs.python.org/issue1512 created JosephArmbruster object.c do_compare comparison ordering error 11/28/07 CLOSED http://bugs.python.org/issue1513 created JosephArmbruster missing constants in socket module 11/28/07 http://bugs.python.org/issue1514 created dbinger py3k, patch deepcopy doesn't copy instance methods 11/29/07 http://bugs.python.org/issue1515 created mlvanbie make _ctypes work with non-gcc compilers 11/29/07 http://bugs.python.org/issue1516 created gregcouch lookdict should INCREF/DECREF startkey around PyObject_RichCompa 11/29/07 CLOSED http://bugs.python.org/issue1517 created rhamphoryncus patch Fast globals/builtins access (patch) 11/29/07 http://bugs.python.org/issue1518 created ntoronto patch async_chat.__init__() parameters 11/29/07 http://bugs.python.org/issue1519 created nvawda 'without make' documentation build anomaly 11/29/07 http://bugs.python.org/issue1520 created JosephArmbruster string.decode() fails on long strings 11/29/07 http://bugs.python.org/issue1521 created eisele pyvm module patch 11/29/07 http://bugs.python.org/issue1522 created tiran py3k, patch xdrlib fails to detect overflow (struct bug?) 11/29/07 http://bugs.python.org/issue1523 created lloyd os.system() fails for commands with multiple quoted file names 11/29/07 http://bugs.python.org/issue1524 created Quigon Executing Python script using subprocess.Popen twice interactive 11/30/07 CLOSED http://bugs.python.org/issue1525 created canhuth DeprecationWarning in zipfile.py while zipping 113000 files 11/30/07 http://bugs.python.org/issue1526 created bialix Problem with static libs on Windows 11/30/07 http://bugs.python.org/issue1527 created tiran py3k, patch Issues Now Closed (34) ______________________ Warning required when calling register() on an ABCMeta subclass 0 days http://bugs.python.org/issue1109 tiran py3k, patch Fixer needed for __future__ imports 82 days http://bugs.python.org/issue1138 tiran py3k popen3 website documentation inconsistency 55 days http://bugs.python.org/issue1220 georg.brandl email module example email-unpack.py error 43 days http://bugs.python.org/issue1273 georg.brandl Bug in pstats.print_callers 32 days http://bugs.python.org/issue1315 georg.brandl subprocess.communication doc could use clarification 28 days http://bugs.python.org/issue1344 georg.brandl xml.dom refers to PyXML, which is no longer maintained 26 days http://bugs.python.org/issue1355 georg.brandl Interpreter cleanup: order of _PyGILState_Fini and PyInterpreter 22 days http://bugs.python.org/issue1402 amaury.forgeotdarc new keyword-only function parameters interact badly with nested 15 days http://bugs.python.org/issue1409 amaury.forgeotdarc py3k test_subprocess fails on SuSE 10 16 days http://bugs.python.org/issue1412 tiran SystemError accessing uninitialised cell contents 9 days http://bugs.python.org/issue1445 amaury.forgeotdarc error in TestResult.addError and TestResult.addFailure 5 days http://bugs.python.org/issue1467 georg.brandl MSI installer does not include SSL test .pem files 6 days http://bugs.python.org/issue1468 loewis csv module is leaking references 4 days http://bugs.python.org/issue1479 georg.brandl py3k sqlite module is leaking lots of references 4 days http://bugs.python.org/issue1480 georg.brandl py3k Patch to remove unbound methods 2 days http://bugs.python.org/issue1493 gvanrossum py3k, patch DOM-Documentation should mention that appendChild() removes the 0 days http://bugs.python.org/issue1494 loewis Unicode in a comment. 0 days http://bugs.python.org/issue1495 facundobatista add str.maketrans() 3 days http://bugs.python.org/issue1496 georg.brandl py3k, patch Example using range doesn't give claimed results 0 days http://bugs.python.org/issue1500 gvanrossum itertools should grow chunkify 0 days http://bugs.python.org/issue1502 rhettinger Changes to PyMethod_New breaks ctypes on Windows 1 days http://bugs.python.org/issue1505 tiran py3k Removal of stale code in _csv.c / pyexpat.c 0 days http://bugs.python.org/issue1508 tiran py3k object.c do_compare comparison ordering error 0 days http://bugs.python.org/issue1513 georg.brandl lookdict should INCREF/DECREF startkey around PyObject_RichCompa 1 days http://bugs.python.org/issue1517 gvanrossum patch Executing Python script using subprocess.Popen twice interactive 0 days http://bugs.python.org/issue1525 canhuth inspect, class instances and __getattr__ 1692 days http://bugs.python.org/issue718532 gvanrossum Subclassing from Modules 1607 days http://bugs.python.org/issue765228 gvanrossum profiler: Bad return and Bad call errors with exceptions 1022 days http://bugs.python.org/issue1117670 georg.brandl cannot change cursor color in IDLE 221 days http://bugs.python.org/issue1705362 georg.brandl sqlite3 causes memory read error 169 days http://bugs.python.org/issue1734164 ghaering Add O_NOATIME to os module 165 days http://bugs.python.org/issue1735632 georg.brandl Decimal.__int__ overflows for large values 107 days http://bugs.python.org/issue1770416 facundobatista Unify __builtins__ -> __builtin__ 107 days http://bugs.python.org/issue1774369 georg.brandl py3k, patch Top Issues Most Discussed (10) ______________________________ 12 pyvm module patch 1 days open http://bugs.python.org/issue1522 11 string.decode() fails on long strings 1 days open http://bugs.python.org/issue1521 9 Patch to remove unbound methods 2 days closed http://bugs.python.org/issue1493 8 Add 2to3 fixer for (un)bound methods 3 days open http://bugs.python.org/issue1504 6 func alloca inside ctypes lib needs #include on sola 3 days open http://bugs.python.org/issue1506 6 Patch to remove API to create new unbound methods 5 days pending http://bugs.python.org/issue1497 6 Interpreter cleanup: order of _PyGILState_Fini and PyInterprete 22 days closed http://bugs.python.org/issue1402 5 lookdict should INCREF/DECREF startkey around PyObject_RichComp 1 days closed http://bugs.python.org/issue1517 5 object.c do_compare comparison ordering error 0 days closed http://bugs.python.org/issue1513 5 Rename __builtins__ to __root_namespace__? 4 days open http://bugs.python.org/issue1498 From ntoronto at cs.byu.edu Fri Nov 30 21:02:07 2007 From: ntoronto at cs.byu.edu (Neil Toronto) Date: Fri, 30 Nov 2007 13:02:07 -0700 Subject: [Python-Dev] -O2 faster than -O3? Message-ID: <47506C3F.7040709@cs.byu.edu> On both of my systems, using -O2 reduces execution time in pystone by 9% and in pybench by 8%. It's function inlining: "-O3 -fno-inline-functions" works just as well as "-O2". Removing "-g" has little effect on the result. Systems: - AMD Athlon 64 X2 Dual Core 4600+, 512 KB cache (desktop) - Intel T2300 Dual Core 1.66GHz, 512 KB cache (laptop) Both are Ubuntu 7.04, GCC 4.1.2. Does anybody else see this? It may be GCC being stupid (which has happened before) or not enough cache on my systems (definitely possible). If it's not one of those, I'd say it's because CPython core functions are already very large, and almost everything that ought to be inlined is already a macro. Pybench comparison for the Athlon: http://spreadsheets.google.com/ccc?key=pHIJrYc_pnIXCwJvDvU9gfQ&hl=en_US Neil From lists at cheimes.de Fri Nov 30 21:16:38 2007 From: lists at cheimes.de (Christian Heimes) Date: Fri, 30 Nov 2007 21:16:38 +0100 Subject: [Python-Dev] msvcr90 support was added to mingw Message-ID: Paul Moore got some Cygwin developers persuaded to implement support for msvcr90 [1]. The coded was added a few days ago [2]. This means that users are still able to use MinGW to compile extensions when we switch to VS 2008 as default compiler on Windows. I'm not sure how many people are interested in the topic but some may be glad to hear that MinGW is still supported. Christian [1] http://article.gmane.org/gmane.comp.gnu.mingw.user/24686 [2] http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/msvcrt.def.in?rev=1.8&content-type=text/x-cvsweb-markup&cvsroot=src From p.f.moore at gmail.com Fri Nov 30 21:35:22 2007 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 30 Nov 2007 20:35:22 +0000 Subject: [Python-Dev] msvcr90 support was added to mingw In-Reply-To: References: Message-ID: <79990c6b0711301235i471339act2b71fbd8f5fc3ae7@mail.gmail.com> On 30/11/2007, Christian Heimes wrote: > Paul Moore got some Cygwin developers persuaded to implement support for > msvcr90 [1]. The coded was added a few days ago [2]. This means that > users are still able to use MinGW to compile extensions when we switch > to VS 2008 as default compiler on Windows. > > I'm not sure how many people are interested in the topic but some may be > glad to hear that MinGW is still supported. Thanks for letting people know about this Christian! I'm waiting until there's a released binary with this included (or I get time to work out how to build my own!), and then I'll work up a patch for distutils to make this work. Paul. From guido at python.org Fri Nov 30 21:38:28 2007 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Nov 2007 12:38:28 -0800 Subject: [Python-Dev] Update to PEP 366 (Relative imports from the main module) In-Reply-To: <47459613.7060301@gmail.com> References: <47459613.7060301@gmail.com> Message-ID: This looks good. Please make the appropriate changes to the PEP and to PEP 0 to mark it as accepted. I think the implementation is fine too (others will have to check it more carefully) but I noticed that the promised functionality of -m doesn't work yet: I created a file Lib/test/foo.py whose sole contents was "from . import test_support". Then I tried to import this using -m: $ ./python.exe -m test.foo Traceback (most recent call last): File "/Users/guido/p/Lib/runpy.py", line 104, in _run_module_as_main "__main__", fname, loader) File "/Users/guido/p/Lib/runpy.py", line 34, in _run_code exec code in run_globals File "/Users/guido/p/Lib/test/foo.py", line 1, in from . import test_support ValueError: Attempted relative import in non-package $ What's missing here? --Guido On Nov 22, 2007 6:45 AM, Nick Coghlan wrote: > I've updated PEP 366 with a proposed implementation, as well as a few > changes to the proposed semantics to make the implementation feasible > (the old proposal called for imp.new_module to calculate a value when it > didn't have access to all of the relevant information). > > The updated text is below, and should turn up on python.org before too long. > > Regards, > Nick. > > -------------------------------------------- > PEP: 366 > Title: Main module explicit relative imports > Version: $Revision$ > Last-Modified: $Date$ > Author: Nick Coghlan > Status: Draft > Type: Standards Track > Content-Type: text/x-rst > Created: 1-May-2007 > Python-Version: 2.6, 3.0 > Post-History: 1-May-2007, 4-Jul-2007, 7-Jul-2007, 23-Nov-2007 > > > Abstract > ======== > > This PEP proposes a backwards compatible mechanism that permits > the use of explicit relative imports from executable modules within > packages. Such imports currently fail due to an awkward interaction > between PEP 328 and PEP 338. > > By adding a new module level attribute, this PEP allows relative imports > to work automatically if the module is executed using the ``-m`` switch. > A small amount of boilerplate in the module itself will allow the relative > imports to work when the file is executed by name. > > > Proposed Change > =============== > > The major proposed change is the introduction of a new module level > attribute, ``__package__``. When it is present, relative imports will > be based on this attribute rather than the module ``__name__`` > attribute. > > As with the current ``__name__`` attribute, setting ``__package__`` will > be the responsibility of the PEP 302 loader used to import a module. > Loaders which use ``imp.new_module()`` to create the module object will > have the new attribute set automatically to ``None``. When the import > system encounters an explicit relative import in a module without > ``__package__`` set (or with it set to ``None``), it will calculate and > store the correct value (``__name__.rpartition('.')[0]`` for normal > modules and ``__name__`` for package initialisation modules). If > ``__package__`` has already been set then the import system will use > it in preference to recalculating the package name from the > ``__name__`` and ``__path__`` attributes. > > The ``runpy`` module will explicitly set the new attribute, basing it off > the name used to locate the module to be executed rather than the name > used to set the module's ``__name__`` attribute. This will allow relative > imports to work correctly from main modules executed with the ``-m`` > switch. > > When the main module is specified by its filename, then the > ``__package__`` attribute will be set to ``None``. To allow > relative imports when the module is executed directly, boilerplate > similar to the following would be needed before the first relative > import statement:: > > if __name__ == "__main__" and __package__ is None: > __package__ = "expected.package.name" > > Note that this boilerplate is sufficient only if the top level package > is already accessible via ``sys.path``. Additional code that manipulates > ``sys.path`` would be needed in order for direct execution to work > without the top level package already being importable. > > This approach also has the same disadvantage as the use of absolute > imports of sibling modules - if the script is moved to a different > package or subpackage, the boilerplate will need to be updated > manually. It has the advantage that this change need only be made > once per file, regardless of the number of relative imports. > > > Rationale for Change > ==================== > > The current inability to use explicit relative imports from the main > module is the subject of at least one open SF bug report (#1510172) [1]_, > and has most likely been a factor in at least a few queries on > comp.lang.python (such as Alan Isaac's question in [2]_). > > This PEP is intended to provide a solution which permits explicit > relative imports from main modules, without incurring any significant > costs during interpreter startup or normal module import. > > The section in PEP 338 on relative imports and the main module provides > further details and background on this problem. > > > Reference Implementation > ======================== > > Rev 47142 in SVN implemented an early variant of this proposal > which stored the main module's real module name in the > ``__module_name__`` attribute. It was reverted due to the fact > that 2.5 was already in beta by that time. > > Patch 1487 [4] is the proposed implementation for this PEP. > > Alternative Proposals > ===================== > > PEP 3122 proposed addressing this problem by changing the way > the main module is identified. That's a significant compatibility cost > to incur to fix something that is a pretty minor bug in the overall > scheme of things, and the PEP was rejected [3]_. > > The advantage of the proposal in this PEP is that its only impact on > normal code is the small amount of time needed to set the extra > attribute when importing a module. Relative imports themselves should > be sped up fractionally, as the package name is cached in the module > globals, rather than having to be worked out again for each relative > import. > > > References > ========== > > .. [1] Absolute/relative import not working? > (http://www.python.org/sf/1510172) > > .. [2] c.l.p. question about modules and relative imports > > (http://groups.google.com/group/comp.lang.python/browse_thread/thread/c44c769a72ca69fa/) > > .. [3] Guido's rejection of PEP 3122 > (http://mail.python.org/pipermail/python-3000/2007-April/006793.html) > > .. [4] PEP 366 implementation patch > (http://bugs.python.org/issue1487) > > Copyright > ========= > > This document has been placed in the public domain. > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From nicko at nicko.org Fri Nov 30 23:17:18 2007 From: nicko at nicko.org (Nicko van Someren) Date: Fri, 30 Nov 2007 22:17:18 +0000 Subject: [Python-Dev] [poll] New name for __builtins__ In-Reply-To: References: <474D8725.8000706@cheimes.de> <474DF68D.6010701@canterbury.ac.nz> <474E9999.5090401@cheimes.de> <474E9D45.8030509@cs.byu.edu> <474EA42F.70309@cheimes.de> <6framq$5ce6af@earth.karoo.kcom.com> <6fsfi8$5bl9rn@venus.eclipse.kcom.com> Message-ID: On 29 Nov 2007, at 14:06, Isaac Morland wrote: > > I wonder how much you could sell the naming rights for? i.e. call it > __[name of sponsor]__. Python's pretty popular, such advertising > should > be worth something.... I'm sorry, but if you call it __Microsoft_Office_2007__ I shall never write a program that uses what we now call __builtins__ ever again! > PS: I actually do like __universal__. Me too. +1 for __universal__ Nicko From sg-max-mp11 at windowslive.com Thu Nov 29 03:53:17 2007 From: sg-max-mp11 at windowslive.com (sg-max-mp11) Date: Thu, 29 Nov 2007 09:53:17 +0700 Subject: [Python-Dev] Security Advisory for unicode repr() bug? Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20071129/815b0496/attachment-0001.htm