[Python-Dev] New Standard Library Module
Hello all, Can I suggest a new module for the standard library: 'antigravity.py'. Perhaps it could display a particular image on import... Michael http://www.manning.com/foord ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Standard Library Module
On Wed, Dec 05, 2007 at 06:17:34PM +, Michael Foord wrote: > Can I suggest a new module for the standard library: 'antigravity.py'. A friend of mine (the person who has suggested "raise without arguments") recommends implementing it in two phases. The first should be from __future__ import antigravity XKCD'ly yours ;) Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does anyone care enough about asyncore and asynchat to help adapt their APIs for Py3k?
On Dec 5, 2007 10:04 AM, Josiah Carlson <[EMAIL PROTECTED]> wrote: > On Dec 5, 2007 9:19 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > The asyncore and asynchat modules are in a difficult position when it > > comes to Python 3000. None of the core developers use it or > > particularly care about it (AFAIK), and the API has problems because > > it wasn't written to deal with bytes vs. unicode. E.g. in > > http://bugs.python.org/issue1067, Thomas suggests that these modules > > need to be rewritten to use bytes internally and have separate APIs to > > handle (unicode) text as desired, similar to the way file I/O was > > redesigned. Another alternative would be to make these modules deal > > strictly in bytes, but that would probably vastly reduce their > > usefulness (though I don't know -- as I said, I don't use them). > > I can look into it later this month, but for the short term, I'm a > little squeezed for time (work, finishing school, etc.). That's fine; I see this as part of the library reorg effort, which is still in the starting blocks. > I am a bit > curious, however, I could have sworn that bytes were to become, > essentially, the 2.x str type (without some methods). If that is the > case, no changes should really be necessary, except for a few small > changes to asynchat with regards to line terminators. Well, yes, that would be the easiest thing (and may be right for asyncore), but most of the code that *uses* asynchat (that I've seen anyway) passes it text strings, not byte strings. And in 3.0, all text is unicode, and you *must* specify an encoding *somewhere* in order to convert it to bytes correctly -- otherwise it will blow up immediately with a TypeError. > Then again, I haven't really been keeping up in the p3k/pydev lists > for the last 6-8 months, and only the subject line of this posting > caught my eye (because I use asyncore/asynchat, and support users of > asyncore/asynchat that contact me directly). Good to know there are users. Perhaps you could make them aware of this request. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does anyone care enough about asyncore and asynchat to help adapt their APIs for Py3k?
> Good to know there are users. And I use Medusa, which is built on top of asyncore. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac _OSA extension doesn't build on Leopard
How about this: delete them in 2.6 (3.0 will follow after a merge); in 2.5.2, put them inside an #if or #ifdef. Bonus points if you can use a condition that's true on 10.4 and false on 10.5, but always false is okay with me too, as long as there's a comment explaining it. --Guido On Dec 5, 2007 12:08 PM, Ronald Oussoren <[EMAIL PROTECTED]> wrote: > > On 5 Dec, 2007, at 17:56, Guido van Rossum wrote: > > > Thanks! The sooner the better given that tonight (PST) I plan to do > > the code freeze for the 3.0a2 release, and Anthony is also making > > noises about 2.5.2 again. > > I'm working on it right now. I would like a pronouncement on a > backward incompatible change though: > > The _OSA module doesn't compile anymore because it wraps an API that > was unsupported in 10.4 and was removed in 10.5. I can probably add > some configury-logic to detect if the API is still present, but would > prefer to remove those wrappers completely. That's no problem for 2.6 > and 3.0, but strictly speaking this would introduce a backward > incompatibility in 2.5.2. > > The wrappers are for debugging functionality and unlikely to be used > by anyone. > > BTW. the wrappers for OSADebug* functions are now gone in the trunk > (as of revision 59369). > > Ronald > > > > > > > > --Guido > > > > On Dec 4, 2007 11:19 PM, Ronald Oussoren <[EMAIL PROTECTED]> > > wrote: > >> > >> On 4 Dec, 2007, at 22:49, Guido van Rossum wrote: > >> > >>> On OSX 10.5 with Xcode 3.0, whenever I build either the trunk or the > >>> py3k or 25 branches, I get a series of errors when setup.py tries to > >>> build the _OSA module. On OSX 10.4 it builds fine. Can anybody help? > >>> I don't even know what OSA is! > >> > >> I'll try to do a crude fix later this week. The Carbon bindings also > >> wrap some deprecated API's, some of which were dropped in Leopard. > >> We're kind of lucky that _OSA is the only one that no longer > >> compiles. > >> > >> A correct fix will take some more time, as this will require > >> retargeting the bgen tool to use System headers instead of the OS9 > >> (!) > >> headers that were used to generate the current Carbon bindings. > >> > >> Ronald > >> > >> > > > > > > > > -- > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Does anyone care enough about asyncore and asynchat to help adapt their APIs for Py3k?
The asyncore and asynchat modules are in a difficult position when it comes to Python 3000. None of the core developers use it or particularly care about it (AFAIK), and the API has problems because it wasn't written to deal with bytes vs. unicode. E.g. in http://bugs.python.org/issue1067, Thomas suggests that these modules need to be rewritten to use bytes internally and have separate APIs to handle (unicode) text as desired, similar to the way file I/O was redesigned. Another alternative would be to make these modules deal strictly in bytes, but that would probably vastly reduce their usefulness (though I don't know -- as I said, I don't use them). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac _OSA extension doesn't build on Leopard
Thanks! The sooner the better given that tonight (PST) I plan to do the code freeze for the 3.0a2 release, and Anthony is also making noises about 2.5.2 again. --Guido On Dec 4, 2007 11:19 PM, Ronald Oussoren <[EMAIL PROTECTED]> wrote: > > On 4 Dec, 2007, at 22:49, Guido van Rossum wrote: > > > On OSX 10.5 with Xcode 3.0, whenever I build either the trunk or the > > py3k or 25 branches, I get a series of errors when setup.py tries to > > build the _OSA module. On OSX 10.4 it builds fine. Can anybody help? > > I don't even know what OSA is! > > I'll try to do a crude fix later this week. The Carbon bindings also > wrap some deprecated API's, some of which were dropped in Leopard. > We're kind of lucky that _OSA is the only one that no longer compiles. > > A correct fix will take some more time, as this will require > retargeting the bgen tool to use System headers instead of the OS9 (!) > headers that were used to generate the current Carbon bindings. > > Ronald > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does anyone care enough about asyncore and asynchat to help adapt their APIs for Py3k?
Guido van Rossum wrote: > The asyncore and asynchat modules are in a difficult position when it > comes to Python 3000. None of the core developers use it or > particularly care about it (AFAIK), and the API has problems because > it wasn't written to deal with bytes vs. unicode. E.g. in > http://bugs.python.org/issue1067, Thomas suggests that these modules > need to be rewritten to use bytes internally and have separate APIs to > handle (unicode) text as desired, similar to the way file I/O was > redesigned. Another alternative would be to make these modules deal > strictly in bytes, but that would probably vastly reduce their > usefulness (though I don't know -- as I said, I don't use them). > > I use asyncore/asynchat in one (proprietary) project of mine. However, since the only thing I use them for is bytes, your suggested alternative (of bytes instead of strings) is fine with me, and seems the most natural choice. (In fact what I'm currently passing around is strings produced by cPickle, but I'm assuming that the Python3 version of cPickle will create/consume bytes. True?) Gary Herron ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PATCH: attribute lookup caching for 2.6
At 10:48 PM 12/5/2007 +0100, Georg Brandl wrote: >Neil Toronto schrieb: > > So Jim and PJE finally convinced me to do it the right way. :) Thanks > > guys - it turned out very nice. > >How does this relate to Armin Rigo's method cache patch? > >(http://bugs.python.org/issue1685986) Interesting. Armin's approach uses a single global cache of up to 1024 descriptors. That seems a lot simpler than anything I thought of, and might perform better by encouraging the processor to keep the descriptors in cache. It has a lot less pointer indirection, and has a dirt-simple way of invalidating a class' entries when something changes. Was there any reason (aside from the usual lack of volunteers for review) why it didn't go in already? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac _OSA extension doesn't build on Leopard
On 5 Dec, 2007, at 21:25, Guido van Rossum wrote: > How about this: delete them in 2.6 (3.0 will follow after a merge); in > 2.5.2, put them inside an #if or #ifdef. Bonus points if you can use a > condition that's true on 10.4 and false on 10.5, but always false is > okay with me too, as long as there's a comment explaining it. There's now a configure test of this in the 2.5 branch (as of revision 59372), the wrappers for OSADebug API's were removed in 2.6 in revision 59369 (earlier tonight) and should be gone in 3.0 after the next merge. Both patches update a generated file, but as it is virtually impossible to regenerate these files at the moment that should be perfectly safe. Ronald > > > --Guido > > On Dec 5, 2007 12:08 PM, Ronald Oussoren <[EMAIL PROTECTED]> > wrote: >> >> On 5 Dec, 2007, at 17:56, Guido van Rossum wrote: >> >>> Thanks! The sooner the better given that tonight (PST) I plan to do >>> the code freeze for the 3.0a2 release, and Anthony is also making >>> noises about 2.5.2 again. >> >> I'm working on it right now. I would like a pronouncement on a >> backward incompatible change though: >> >> The _OSA module doesn't compile anymore because it wraps an API that >> was unsupported in 10.4 and was removed in 10.5. I can probably add >> some configury-logic to detect if the API is still present, but >> would >> prefer to remove those wrappers completely. That's no problem for 2.6 >> and 3.0, but strictly speaking this would introduce a backward >> incompatibility in 2.5.2. >> >> The wrappers are for debugging functionality and unlikely to be used >> by anyone. >> >> BTW. the wrappers for OSADebug* functions are now gone in the trunk >> (as of revision 59369). >> >> Ronald >> >> >>> >>> >>> --Guido >>> >>> On Dec 4, 2007 11:19 PM, Ronald Oussoren <[EMAIL PROTECTED]> >>> wrote: On 4 Dec, 2007, at 22:49, Guido van Rossum wrote: > On OSX 10.5 with Xcode 3.0, whenever I build either the trunk or > the > py3k or 25 branches, I get a series of errors when setup.py > tries to > build the _OSA module. On OSX 10.4 it builds fine. Can anybody > help? > I don't even know what OSA is! I'll try to do a crude fix later this week. The Carbon bindings also wrap some deprecated API's, some of which were dropped in Leopard. We're kind of lucky that _OSA is the only one that no longer compiles. A correct fix will take some more time, as this will require retargeting the bgen tool to use System headers instead of the OS9 (!) headers that were used to generate the current Carbon bindings. Ronald >>> >>> >>> >>> -- >>> --Guido van Rossum (home page: http://www.python.org/~guido/) >> >> > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PATCH: attribute lookup caching for 2.6
Neil Toronto schrieb: > So Jim and PJE finally convinced me to do it the right way. :) Thanks > guys - it turned out very nice. How does this relate to Armin Rigo's method cache patch? (http://bugs.python.org/issue1685986) Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac _OSA extension doesn't build on Leopard
On 5 Dec, 2007, at 17:56, Guido van Rossum wrote: > Thanks! The sooner the better given that tonight (PST) I plan to do > the code freeze for the 3.0a2 release, and Anthony is also making > noises about 2.5.2 again. I'm working on it right now. I would like a pronouncement on a backward incompatible change though: The _OSA module doesn't compile anymore because it wraps an API that was unsupported in 10.4 and was removed in 10.5. I can probably add some configury-logic to detect if the API is still present, but would prefer to remove those wrappers completely. That's no problem for 2.6 and 3.0, but strictly speaking this would introduce a backward incompatibility in 2.5.2. The wrappers are for debugging functionality and unlikely to be used by anyone. BTW. the wrappers for OSADebug* functions are now gone in the trunk (as of revision 59369). Ronald > > > --Guido > > On Dec 4, 2007 11:19 PM, Ronald Oussoren <[EMAIL PROTECTED]> > wrote: >> >> On 4 Dec, 2007, at 22:49, Guido van Rossum wrote: >> >>> On OSX 10.5 with Xcode 3.0, whenever I build either the trunk or the >>> py3k or 25 branches, I get a series of errors when setup.py tries to >>> build the _OSA module. On OSX 10.4 it builds fine. Can anybody help? >>> I don't even know what OSA is! >> >> I'll try to do a crude fix later this week. The Carbon bindings also >> wrap some deprecated API's, some of which were dropped in Leopard. >> We're kind of lucky that _OSA is the only one that no longer >> compiles. >> >> A correct fix will take some more time, as this will require >> retargeting the bgen tool to use System headers instead of the OS9 >> (!) >> headers that were used to generate the current Carbon bindings. >> >> Ronald >> >> > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does anyone care enough about asyncore and asynchat to help adapt their APIs for Py3k?
On 5 Dic, 20:27, Bill Janssen <[EMAIL PROTECTED]> wrote: > > Good to know there are users. > > And I use Medusa, which is built on top of asyncore. > > Bill +1. I use asyncore/asynchat modules in a public project of mine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PATCH: attribute lookup caching for 2.6
So Jim and PJE finally convinced me to do it the right way. :) Thanks guys - it turned out very nice. http://bugs.python.org/issue1560 http://spreadsheets.google.com/ccc?key=pHIJrYc_pnIUpTm6QSG2gZg&hl=en_US It caches type/metatype attribute lookups, including missing attributes. Summary of the bug tracker issue: - Successful attribute lookups are 20% faster, even for classes with short MROs and (probably most) builtins - haven't tested unsuccessful lookups - Successful hasattr is 5-10% faster, unsuccessful is 5% faster (less impressive than above, and likely due to overhead - internally, all lookups are the same) - list.__init__ and list().__init__ are slower, and I can't figure out why (creating instances of subclasses of list will be a little slower, and this may show up in other builtin types) - I haven't benchmarked type attribute sets (how much do we care?) - it should be quite a bit faster than updating a slot, though - Caching missing attributes is crucial for good performance - The CreateNewInstances benchmark uncovered an issue that needs fixing; please see the tracker for details All kinds of commentary and feedback is most welcome. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Slow tests involving bsddb - timeout
I'd expect 4.5 to work fine but I don't know why you're getting such a strange error, i've never seen that. fwiw i suggest people avoid berkeleydb 4.6 for now. On 12/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I noticed that test_anydbm and test_bsddb seemed to hang, so I -x'd them. > Later on while test_whichdb was running and I was off doing something else > (so didn't notice the delay), it eventually spewed this traceback: > > Traceback (most recent call last): > File "/Users/skip/src/python/trunk/Lib/test/test_whichdb.py", line 49, > in test_whichdb_name > f = mod.open(_fname, 'c') > File "/Users/skip/src/python/trunk/Lib/dbhash.py", line 16, in open > return bsddb.hashopen(file, flag, mode) > File "/Users/skip/src/python/trunk/Lib/bsddb/__init__.py", line 310, in > hashopen > d.open(file, db.DB_HASH, flags, mode) > DBFileExistsError: (17, 'File exists -- __fop_file_setup: Retry limit > (100) exceeded') > > Looking at _bsddb.so I see it's linked against Berkeley DB 4.5. This is on > Mac OSX 10.4.11 using the MacPorts version of Berkeley DB (4.5.20). Have I > somehow strayed out of the support cocoon without realizing it? I wouldn't > have thought so, since the max version listed in setup.py is 4.6. > > Thx, > > Skip > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PATCH: attribute lookup caching for 2.6
Hm... [EMAIL PROTECTED] bounced. I wonder what's going on there... On Dec 5, 2007 4:11 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Dec 5, 2007 4:08 PM, Kevin Jacobs <[EMAIL PROTECTED]> > > <[EMAIL PROTECTED]> wrote: > > On Dec 5, 2007 5:50 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > > At 10:48 PM 12/5/2007 +0100, Georg Brandl wrote: > > > >Neil Toronto schrieb: > > > > > So Jim and PJE finally convinced me to do it the right way. :) Thanks > > > > > guys - it turned out very nice. > > > > > > > >How does this relate to Armin Rigo's method cache patch? > > > > > > > >(http://bugs.python.org/issue1685986) > > > > Was there any reason (aside from the usual lack of volunteers for > > > review) why it didn't go in already? > > > I'm not sure-- I think folks were waiting for Raymond H. to evaluate it. I > > did my part to update Armin's patch against 2.4 to HEAD at the time and put > > in what cleanups seemed sensible. FWIW, I've been using an interpreter with > > this patch ever since without problems. > > I never even saw that one. I'm hoping Raymond will have another look. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PATCH: attribute lookup caching for 2.6
On Dec 5, 2007 4:08 PM, Kevin Jacobs <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: > On Dec 5, 2007 5:50 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > At 10:48 PM 12/5/2007 +0100, Georg Brandl wrote: > > >Neil Toronto schrieb: > > > > So Jim and PJE finally convinced me to do it the right way. :) Thanks > > > > guys - it turned out very nice. > > > > > >How does this relate to Armin Rigo's method cache patch? > > > > > >(http://bugs.python.org/issue1685986) > > Was there any reason (aside from the usual lack of volunteers for > > review) why it didn't go in already? > I'm not sure-- I think folks were waiting for Raymond H. to evaluate it. I > did my part to update Armin's patch against 2.4 to HEAD at the time and put > in what cleanups seemed sensible. FWIW, I've been using an interpreter with > this patch ever since without problems. I never even saw that one. I'm hoping Raymond will have another look. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Slow tests involving bsddb - timeout
I think I've seen this too when running the bsddb3 unittest. I think it's caused by a previous test ending badly and leaving junk behind that the test suite doesn't properly remove before starting. But I don't recall the details. --Guido On Dec 5, 2007 5:24 PM, Gregory P. Smith <[EMAIL PROTECTED]> wrote: > I'd expect 4.5 to work fine but I don't know why you're getting such a > strange error, i've never seen that. fwiw i suggest people avoid > berkeleydb 4.6 for now. > > > On 12/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > I noticed that test_anydbm and test_bsddb seemed to hang, so I -x'd them. > > Later on while test_whichdb was running and I was off doing something else > > (so didn't notice the delay), it eventually spewed this traceback: > > > > Traceback (most recent call last): > > File "/Users/skip/src/python/trunk/Lib/test/test_whichdb.py", line > > 49, in test_whichdb_name > > f = mod.open(_fname, 'c') > > File "/Users/skip/src/python/trunk/Lib/dbhash.py", line 16, in open > > return bsddb.hashopen(file, flag, mode) > > File "/Users/skip/src/python/trunk/Lib/bsddb/__init__.py", line 310, > > in hashopen > > d.open(file, db.DB_HASH, flags, mode) > > DBFileExistsError: (17, 'File exists -- __fop_file_setup: Retry limit > > (100) exceeded') > > > > Looking at _bsddb.so I see it's linked against Berkeley DB 4.5. This is on > > Mac OSX 10.4.11 using the MacPorts version of Berkeley DB (4.5.20). Have I > > somehow strayed out of the support cocoon without realizing it? I wouldn't > > have thought so, since the max version listed in setup.py is 4.6. > > > > Thx, > > > > Skip > > ___ > > Python-Dev mailing list > > [email protected] > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org > > > > ___ > Python-Dev mailing list > [email protected] > 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/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does anyone care enough about asyncore and asynchat to help adapt their APIs for Py3k?
On Dec 5, 2007 12:54 PM, Gary Herron <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > The asyncore and asynchat modules are in a difficult position when it > > comes to Python 3000. None of the core developers use it or > > particularly care about it (AFAIK), and the API has problems because > > it wasn't written to deal with bytes vs. unicode. E.g. in > > http://bugs.python.org/issue1067, Thomas suggests that these modules > > need to be rewritten to use bytes internally and have separate APIs to > > handle (unicode) text as desired, similar to the way file I/O was > > redesigned. Another alternative would be to make these modules deal > > strictly in bytes, but that would probably vastly reduce their > > usefulness (though I don't know -- as I said, I don't use them). > I use asyncore/asynchat in one (proprietary) project of mine. However, > since the only thing I use them for is bytes, your suggested alternative > (of bytes instead of strings) is fine with me, and seems the most > natural choice. > > (In fact what I'm currently passing around is strings produced by > cPickle, but I'm assuming that the Python3 version of cPickle will > create/consume bytes. True?) Right. Although it'll just be "pickle" -- if there's a C accelerator, it'll be hidden from view, so you won't have to change the imported name to get it. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Py3k code freeze imminent; 3.0a2 release Friday
I'm planning to freeze the py3k branch in 2-3 hours, some time after/around 8pm PST (midnight UTC). If someone wants to do another svnmerge from the trunk please do it before then -- though we're nearly current so I don't mind not having the last few changes merged into this release (it's only Raymond's refactoring of __length_hint__ implementations). If there's anything you think really should be in this release, please speak up ASAP. Filing a high priority bug and assigning it to me would be a great way to get my attention. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PATCH: attribute lookup caching for 2.6
On Dec 5, 2007 5:50 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 10:48 PM 12/5/2007 +0100, Georg Brandl wrote: > >Neil Toronto schrieb: > > > So Jim and PJE finally convinced me to do it the right way. :) Thanks > > > guys - it turned out very nice. > > > >How does this relate to Armin Rigo's method cache patch? > > > >(http://bugs.python.org/issue1685986) > > [...] > Was there any reason (aside from the usual lack of volunteers for > review) why it didn't go in already? > I'm not sure-- I think folks were waiting for Raymond H. to evaluate it. I did my part to update Armin's patch against 2.4 to HEAD at the time and put in what cleanups seemed sensible. FWIW, I've been using an interpreter with this patch ever since without problems. -Kevin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PATCH: attribute lookup caching for 2.6
> I never even saw that one. I'm hoping Raymond will have another look. Great. Will review it this week. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PATCH: attribute lookup caching for 2.6
> Hm... [EMAIL PROTECTED] bounced. I wonder what's going on there.. I'm now in an EWT spin-off company. The new email address is [EMAIL PROTECTED] Also, I frequently check the [EMAIL PROTECTED] account too. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does anyone care enough about asyncore and asynchat to help adapt their APIs for Py3k?
Guido van Rossum wrote: > The asyncore and asynchat modules are in a difficult position when it > comes to Python 3000. None of the core developers use it or > particularly care about it (AFAIK), and the API has problems because > it wasn't written to deal with bytes vs. unicode. E.g. in > http://bugs.python.org/issue1067, Thomas suggests that these modules > need to be rewritten to use bytes internally and have separate APIs to > handle (unicode) text as desired, similar to the way file I/O was > redesigned. Another alternative would be to make these modules deal > strictly in bytes, but that would probably vastly reduce their > usefulness (though I don't know -- as I said, I don't use them). I guess that would be me, if you'll have me. I think asyncore and asynchat are valuable, and I'm willing to do what needs to be done to ensure that they remain in Py3k. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PATCH: attribute lookup caching for 2.6
Phillip J. Eby wrote: > At 10:48 PM 12/5/2007 +0100, Georg Brandl wrote: >> Neil Toronto schrieb: >>> So Jim and PJE finally convinced me to do it the right way. :) Thanks >>> guys - it turned out very nice. >> How does this relate to Armin Rigo's method cache patch? >> >> (http://bugs.python.org/issue1685986) > > Interesting. Armin's approach uses a single global cache of up to > 1024 descriptors. That seems a lot simpler than anything I thought > of, and might perform better by encouraging the processor to keep the > descriptors in cache. It has a lot less pointer indirection, and has > a dirt-simple way of invalidating a class' entries when something changes. Hey, I took out all my extra pointer indirection. :p FWIW, I like it. Though the hash should really incorporate the hash of the type name as well as the attribute's so that sometype.method calling othertype.method doesn't invalidate the cache. Locality makes the global cache work, but locality also often means re-using the same names. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does anyone care enough about asyncore and asynchat to help adapt their APIs for Py3k?
On Dec 5, 2007 6:34 PM, Daniel Arbuckle <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > The asyncore and asynchat modules are in a difficult position when it > > comes to Python 3000. None of the core developers use it or > > particularly care about it (AFAIK), and the API has problems because > > it wasn't written to deal with bytes vs. unicode. E.g. in > > http://bugs.python.org/issue1067, Thomas suggests that these modules > > need to be rewritten to use bytes internally and have separate APIs to > > handle (unicode) text as desired, similar to the way file I/O was > > redesigned. Another alternative would be to make these modules deal > > strictly in bytes, but that would probably vastly reduce their > > usefulness (though I don't know -- as I said, I don't use them). > > I guess that would be me, if you'll have me. I think asyncore and > asynchat are valuable, and I'm willing to do what needs to be done to > ensure that they remain in Py3k. Excellent! Are you at all familiar with how Py3k deals with bytes vs strings? If not, perhaps you could start by reading PEP 3137. I'd be happy to answer any questions you have (possibly off-list). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k code freeze imminent; 3.0a2 release Friday
I've built and tested the latest py3k from scratch on Ubuntu, Fedora 7, OSX 10.4 and OSX 10.5, and found no issues. So the code freeze is a fact. Don't check anything into the py3k branch unless I tell you to. Please file high-priority bugs and assign them to me if you think you've found a showstopper. The buildbot is green for Solaris also, so I think we're in good shape. I don't see any green buildbots for Windows though, but Windows is always a flakey situation; Christian, what's your assessment? I see a few tests leaking; in particular test_ssl (1522 refs leaned per run!) and test_urllib2_localnet (3 per run). Anyone interested in researching these feel free to do so; just upload a patch and file a bug if you've squashed the leaks (or some). We're on for a 3.0a2 release Friday! --Guido On Dec 5, 2007 5:46 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I'm planning to freeze the py3k branch in 2-3 hours, some time > after/around 8pm PST (midnight UTC). > > If someone wants to do another svnmerge from the trunk please do it > before then -- though we're nearly current so I don't mind not having > the last few changes merged into this release (it's only Raymond's > refactoring of __length_hint__ implementations). > > If there's anything you think really should be in this release, please > speak up ASAP. Filing a high priority bug and assigning it to me would > be a great way to get my attention. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PATCH: attribute lookup caching for 2.6
At 07:43 PM 12/5/2007 -0700, Neil Toronto wrote: >Phillip J. Eby wrote: > > At 10:48 PM 12/5/2007 +0100, Georg Brandl wrote: > >> Neil Toronto schrieb: > >>> So Jim and PJE finally convinced me to do it the right way. :) Thanks > >>> guys - it turned out very nice. > >> How does this relate to Armin Rigo's method cache patch? > >> > >> (http://bugs.python.org/issue1685986) > > > > Interesting. Armin's approach uses a single global cache of up to > > 1024 descriptors. That seems a lot simpler than anything I thought > > of, and might perform better by encouraging the processor to keep the > > descriptors in cache. It has a lot less pointer indirection, and has > > a dirt-simple way of invalidating a class' entries when something changes. > >Hey, I took out all my extra pointer indirection. :p > >FWIW, I like it. Though the hash should really incorporate the hash of >the type name as well as the attribute's so that sometype.method calling >othertype.method doesn't invalidate the cache. Locality makes the global >cache work, but locality also often means re-using the same names. Look at the patch more closely. The hash function uses a version number times the method name's hash. "Version" numbers are assigned one per class, so unless there are 2**32 classes in the system, they are uniquely numbered. The multiplication and use of the high bits should tend to spread the hash locations around and avoid same-name collisions. Of course, it's still always possible to have pathological cases, but even these shouldn't be much slower than the way things work now. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Slow tests involving bsddb - timeout
Guido> I think I've seen this too when running the bsddb3 unittest. I Guido> think it's caused by a previous test ending badly and leaving Guido> junk behind that the test suite doesn't properly remove before Guido> starting. But I don't recall the details. Thanks, that at least gives me some hope that I can try to narrow down the problem with a little binary searching. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PATCH: attribute lookup caching for 2.6
Phillip J. Eby wrote: > At 07:43 PM 12/5/2007 -0700, Neil Toronto wrote: >> FWIW, I like it. Though the hash should really incorporate the hash of >> the type name as well as the attribute's so that sometype.method calling >> othertype.method doesn't invalidate the cache. Locality makes the global >> cache work, but locality also often means re-using the same names. > > Look at the patch more closely. The hash function uses a version number > times the method name's hash. "Version" numbers are assigned one per > class, so unless there are 2**32 classes in the system, they are > uniquely numbered. The multiplication and use of the high bits should > tend to spread the hash locations around and avoid same-name collisions. Good grief - how did I miss that? I plead parenthesis. They threw me off. So I've applied Armin's patch to 2.6 (it was nearly clean) and am playing with it. cls.name lookups are 15-20% faster than mine, and inst.name lookups are 5-10% faster. His is also winning on hasattr calls (succeeding and failing) on classes, but mine is winning on hasattr calls on instances. I want to poke at it a bit to find out why. On pybench, his is faster at BuiltinMethodLookups, significantly faster at CreateNewInstances, and a bit faster at almost everything else. BuiltinFunctionCalls is slower - slower than stock - it might need poking there, too. In all, it's a lovely piece of work. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
