Re: [Python-Dev] Proposal / Questions about OrderedDict literals and/or faster C implementation
On 2011-02-10, at 21:47 , Éric Araujo wrote: > Ideas are usually discussed first on python-ideas to assess usefulness, > get the pulse of the community, beat the API into shape and such things > before coming up to python-dev. (A number of core devs are on both lists.) > > You may want to search the mail archive for all the previous threads > about adding a C version and literal notation for ordered dicts. Indeed, there's been a discussion on this very subject not three weeks ago: http://mail.python.org/pipermail/python-ideas/2011-January/009037.html I'm guessing this request is going to get more common for some time, as people are getting aware Ruby switched its Hash implementation to an ordered dict in 1.9 (well they didn't exactly switch anything around, they added back and next pointers to their dict cells) ___ 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] API bloat
Nick Coghlan wrote: On Fri, Feb 11, 2011 at 3:25 AM, Mark Shannon wrote: Antoine Pitrou wrote: Please, don't just document all these. Don't add them to the API, unless they are really needed. We only add functions when they are actually needed (by us, usually). If only you (I presume you mean the CPython devs) need them, why put them in the API. That underscore prefix saves a lot of trouble in the long run ;) Keep in mind that you're asking us to change our audience here. When we modify the C API, we have precisely *three* audiences in mind: 1. CPython developers 2. authors of CPython extensions 3. developers embedding a CPython interpreter (or interpreters) into their application This makes me wonder who `owns' the API. Is the CPython developers, the Python community as a whole, the PSF? (Another one for Python-ideas) So if we find something that makes life easier for us in group 1, our natural inclination is to make it available to the people in groups 2 and 3 as well, rather than selfishly reserving it for ourselves. We will also take aesthetics and obvious symmetries into account when providing convenience functions (as in the case of PySys_FormatStdout). It's only when we consider something to be an ugly hack, or have some other reason to think we may want to change it in the future, that we opt to make it a private implementation detail. The audience consisting of "authors of other implementations trying to mimic the CPython C API" has never even been on the radar. That's quite a significant philosophical shift, so coming in and asking us to apply it retroactively to a release in its RC phase comes across as being *very* presumptuous. Sorry to leave it the RC stage, I just didn't pick up the changes until now. Don't forget that `other implementations' include future versions of CPython. Now that the issue has been brought up, it can certainly be taken into consideration for 3.3. The idea of defining a Py_PORTABLE_API that is even more restrictive than PEP 384 (e.g. eliminating lots of old cruft that is a legacy of CPython's long history of development when it was the *only* viable Python implementation) may also be worth exploring. Absolutely. I intend to do just that. But no, at this late stage nothing significant is going to be done in the context of 3.2, except perhaps describing the C API changes in more detail in the What's New document (whether or not that happens is up to Raymond - the C API is of very little interest to most Python users, who will either use pre-existing C extensions, or else use something like ctypes, Cython, Pyrex, Boost or SWIG to deal with the details of the C/Python boundary). I do realise that its rather late in the release process, so I'll leave it that. Thanks, Mark. Cheers, Nick. ___ 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] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On Fri, Feb 11, 2011 at 11:04 PM, giampaolo.rodola wrote: > Author: giampaolo.rodola > Date: Fri Feb 11 14:04:18 2011 > New Revision: 88395 > > Log: > asyncore: introduce a new 'closed' attribute to make sure that dispatcher > gets closed only once. > In different occasions close() might be called more than once, causing > problems with already disconnected sockets/dispatchers. Giampaolo, This checkin and the previous one are not appropriate for the release candidate phase of the 3.2 release. At the very least, they need to identify the second core dev that reviewed them, as well as a reference to the tracker issue where the RM approved them for inclusion. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
I'm sorry, I'm going to revert those checkins. They are very minor changes which I'm sure don't break anything, but I understand your complain. --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ 2011/2/11 Nick Coghlan : > On Fri, Feb 11, 2011 at 11:04 PM, giampaolo.rodola > wrote: >> Author: giampaolo.rodola >> Date: Fri Feb 11 14:04:18 2011 >> New Revision: 88395 >> >> Log: >> asyncore: introduce a new 'closed' attribute to make sure that dispatcher >> gets closed only once. >> In different occasions close() might be called more than once, causing >> problems with already disconnected sockets/dispatchers. > > Giampaolo, > > This checkin and the previous one are not appropriate for the release > candidate phase of the 3.2 release. At the very least, they need to > identify the second core dev that reviewed them, as well as a > reference to the tracker issue where the RM approved them for > inclusion. > > Regards, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > ___ 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] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
Le vendredi 11 février 2011 à 14:52 +0100, Giampaolo Rodolà a écrit : > >> New Revision: 88395 > >> > >> Log: > >> asyncore: introduce a new 'closed' attribute to make sure that dispatcher > >> gets closed only once. > >> In different occasions close() might be called more than once, causing > >> problems with already disconnected sockets/dispatchers. > > (...) > I'm sorry, I'm going to revert those checkins. > They are very minor changes which I'm sure don't break anything, but I > understand your complain. dispatcher.closing is a public attribute: some programs my rely on it. I checked mine: it uses "connected", but not closing :-) I think that it will be fine for Python 3.3, but not for 3.2 (too late). And you should document your change, because it is the public API. Victor ___ 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] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On Fri, Feb 11, 2011 at 6:28 AM, Victor Stinner wrote: > Le vendredi 11 février 2011 à 14:52 +0100, Giampaolo Rodolà a écrit : >> >> New Revision: 88395 >> >> >> >> Log: >> >> asyncore: introduce a new 'closed' attribute to make sure that dispatcher >> >> gets closed only once. >> >> In different occasions close() might be called more than once, causing >> >> problems with already disconnected sockets/dispatchers. >> > (...) >> I'm sorry, I'm going to revert those checkins. >> They are very minor changes which I'm sure don't break anything, but I >> understand your complain. > > dispatcher.closing is a public attribute: some programs my rely on it. I > checked mine: it uses "connected", but not closing :-) > > I think that it will be fine for Python 3.3, but not for 3.2 (too late). > And you should document your change, because it is the public API. And finally remember that asyncore is the most monkey-patched module in the world. :-) -- --Guido van Rossum (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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2011-02-04 - 2011-02-11) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open2627 (+42) closed 20348 (+34) total 22975 (+76) Open issues with patches: 1119 Issues opened (56) == #6378: Patch to make 'idle.bat' run idle.pyw using appropriate Python http://bugs.python.org/issue6378 reopened by srid #7074: Turtle module crashes python http://bugs.python.org/issue7074 reopened by terry.reedy #9920: test_cmath on atan fails on AIX http://bugs.python.org/issue9920 reopened by mark.dickinson #11120: threading.Thread.daemon Documentation Incomplete http://bugs.python.org/issue11120 opened by cardinalbiggles #11122: bdist_rpm fails http://bugs.python.org/issue11122 opened by purpleidea #11123: problem with packaged dependency extracter script, pdeps http://bugs.python.org/issue11123 opened by $$Coffeepot$$ #11126: Wave.py does not always write proper length in header http://bugs.python.org/issue11126 opened by jtidman #11127: sockets should not be pickleable http://bugs.python.org/issue11127 opened by pitrou #11128: decimal.py: to_integral() corner cases http://bugs.python.org/issue11128 opened by skrah #11131: decimal.py: plus/minus with ROUND_FLOOR http://bugs.python.org/issue11131 opened by skrah #11133: inspect.getattr_static code execution http://bugs.python.org/issue11133 opened by durban #11134: Add missing type slots http://bugs.python.org/issue11134 opened by loewis #11135: Redundant doc field in TypeSpec http://bugs.python.org/issue11135 opened by loewis #11140: threading.Lock().release() raises _thread.error, not RuntimeEr http://bugs.python.org/issue11140 opened by aaugustin #11142: xmlrpclib.ServerProxy with verbosity produces bad output http://bugs.python.org/issue11142 opened by Erez.Sh #11144: int(float) may return a long for no reason http://bugs.python.org/issue11144 opened by arigo #11145: '%o' % user-defined instance http://bugs.python.org/issue11145 opened by arigo #11147: _Py_ANNOTATE_MEMORY_ORDER has unused argument, effects code wh http://bugs.python.org/issue11147 opened by ideasman42 #11148: Crash and error message from Python VM http://bugs.python.org/issue11148 opened by pcdinh #11149: [PATCH] Configure should enable -fwrapv for clang http://bugs.python.org/issue11149 opened by cartman #11151: Arguments to various types not specified in types module http://bugs.python.org/issue11151 opened by noufal #11152: pb in zipfile module http://bugs.python.org/issue11152 opened by Emmanuel LAB #11153: urllib2 basic auth parser handle unquoted realm in WWW-Authent http://bugs.python.org/issue11153 opened by mmb #11155: multiprocessing.Queue's put() signature differs from docs http://bugs.python.org/issue11155 opened by Erik.Cederstrand #11158: Python VM deadlock http://bugs.python.org/issue11158 opened by pcdinh #11159: Sax parser crashes if given unicode file name http://bugs.python.org/issue11159 opened by ricli85 #11160: ZipFile.comment expects bytes http://bugs.python.org/issue11160 opened by xuanji #11161: futures.ProcessPoolExecutor hangs http://bugs.python.org/issue11161 opened by pclinch #11163: iter() documentation code doesn't work http://bugs.python.org/issue11163 opened by mgrazebrook #11164: xml shouldn't use _xmlplus http://bugs.python.org/issue11164 opened by Arfrever #11165: Document PyEval_Call* functions http://bugs.python.org/issue11165 opened by ncoghlan #11166: No exit when daemon thread is running. http://bugs.python.org/issue11166 opened by dmahn #11168: UnicodeEncodeError on recusion limit if the script filename is http://bugs.python.org/issue11168 opened by haypo #11169: compileall doesn't support the PEP 383 (undecodable paths/file http://bugs.python.org/issue11169 opened by haypo #11171: Python 2.7.1 does not start when "./configure" is used with " http://bugs.python.org/issue11171 opened by hoel #11172: Avoid '.' as runpath on AIX http://bugs.python.org/issue11172 opened by haubi #11173: Undocumented public APIs in Python 3.2 http://bugs.python.org/issue11173 opened by lemburg #11174: add argparse formatting option to display type names for metav http://bugs.python.org/issue11174 opened by bethard #11175: allow argparse FileType to accept encoding and errors argument http://bugs.python.org/issue11175 opened by bethard #11176: give more meaningful argument names in argparse documentation http://bugs.python.org/issue11176 opened by bethard #11177: Set asyncore create_socket default argument http://bugs.python.org/issue11177 opened by giampaolo.rodola #11178: Running tests inside a package by module name fails http://bugs.python.org/issue11178 opened by michael.foord #11179: ccbench doesn't work on 3.1/2.7 http://bugs.python.org/issue11179 opened by pitrou #11181: TLS end connection not detected properly in retrb
Re: [Python-Dev] API bloat
On 2/11/2011 4:29 AM, Mark Shannon wrote: Nick Coghlan wrote: Now that the issue has been brought up, it can certainly be taken into consideration for 3.3. The idea of defining a Py_PORTABLE_API that is even more restrictive than PEP 384 (e.g. eliminating lots of old cruft that is a legacy of CPython's long history of development when it was the *only* viable Python implementation) may also be worth exploring. Absolutely. I intend to do just that. I think we should try to have deprecations and removals in the codebase by the first alpha release for maximal testing. GP's asyncore changes inspired this thought, but I would apply it generally. -- Terry Jan Reedy ___ 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] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On Fri, Feb 11, 2011 at 8:06 AM, Guido van Rossum wrote: > > And finally remember that asyncore is the most monkey-patched module > in the world. :-) I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys. -- Daniel Stutzbach ___ 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] API bloat
On Fri, 11 Feb 2011 13:16:12 -0500 Terry Reedy wrote: > On 2/11/2011 4:29 AM, Mark Shannon wrote: > > Nick Coghlan wrote: > > >> Now that the issue has been brought up, it can certainly be taken into > >> consideration for 3.3. The idea of defining a Py_PORTABLE_API that is > >> even more restrictive than PEP 384 (e.g. eliminating lots of old cruft > >> that is a legacy of CPython's long history of development when it was > >> the *only* viable Python implementation) may also be worth exploring. > > > > Absolutely. I intend to do just that. > > I think we should try to have deprecations and removals in the codebase > by the first alpha release for maximal testing. Why would we deprecate or remove anything? Are some functions useless? Reducing the number of API functions is not a goal in itself. Regards Antoine. ___ 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] API bloat
2011/2/11 Antoine Pitrou : > On Fri, 11 Feb 2011 13:16:12 -0500 > Terry Reedy wrote: >> On 2/11/2011 4:29 AM, Mark Shannon wrote: >> > Nick Coghlan wrote: >> >> >> Now that the issue has been brought up, it can certainly be taken into >> >> consideration for 3.3. The idea of defining a Py_PORTABLE_API that is >> >> even more restrictive than PEP 384 (e.g. eliminating lots of old cruft >> >> that is a legacy of CPython's long history of development when it was >> >> the *only* viable Python implementation) may also be worth exploring. >> > >> > Absolutely. I intend to do just that. >> >> I think we should try to have deprecations and removals in the codebase >> by the first alpha release for maximal testing. > > Why would we deprecate or remove anything? Are some functions useless? > Reducing the number of API functions is not a goal in itself. I think he's referring to deprecations and removals in general. -- Regards, Benjamin ___ 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] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On Fri, 11 Feb 2011 10:11:54 -0800 Daniel Stutzbach wrote: > On Fri, Feb 11, 2011 at 8:06 AM, Guido van Rossum wrote: > > > > And finally remember that asyncore is the most monkey-patched module > > in the world. :-) > > > I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys. Would that be a Mapping or a Sequence? ___ 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] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
2011/2/11 Antoine Pitrou : > On Fri, 11 Feb 2011 10:11:54 -0800 > Daniel Stutzbach wrote: >> On Fri, Feb 11, 2011 at 8:06 AM, Guido van Rossum wrote: >> > >> > And finally remember that asyncore is the most monkey-patched module >> > in the world. :-) >> >> >> I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys. > > Would that be a Mapping or a Sequence? Actually, probably Laughable. -- Regards, Benjamin ___ 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] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
Yeah, the original API design (which is very inflexible) and the lack of maintenance for many years is at the base of asyncore problems. I still think it worths some love as a stdlib module, though. For 3.3 I have in mind to revamp asyncore/asynchat a bit by introducing SSL support and finally add a scheduler (issue 1641). --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ 2011/2/11 Daniel Stutzbach : > On Fri, Feb 11, 2011 at 8:06 AM, Guido van Rossum wrote: >> >> And finally remember that asyncore is the most monkey-patched module >> in the world. :-) > > I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys. > -- > Daniel Stutzbach > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com > > ___ 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] API bloat
>> 1. CPython developers >> 2. authors of CPython extensions >> 3. developers embedding a CPython interpreter (or interpreters) into >> their application > > This makes me wonder who `owns' the API. > Is the CPython developers, the Python community as a whole, the PSF? > (Another one for Python-ideas) Clearly the CPython contributors own the API. There are both policies for additions and policies for removal, and so far, these policies haven't been challenged. The "addition" policy is that anything can be added as long as it's reasonable that future versions support it, and that there is a plausible use case for an embedder or extender actually making use of the API. The "removal" policy is that things can be removed after "proper" deprecation. The precise requirements of deprecation depend on how widely the API is being used. More explicitly: while it is policy to consider alternative implementations when changing the language or the standard library, it is not policy to consider alternative implementations when changing the C API. Regards, Martin ___ 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] API bloat
On 2/11/2011 1:35 PM, Benjamin Peterson wrote: 2011/2/11 Antoine Pitrou: On Fri, 11 Feb 2011 13:16:12 -0500 Terry Reedy wrote: On 2/11/2011 4:29 AM, Mark Shannon wrote: Nick Coghlan wrote: Now that the issue has been brought up, it can certainly be taken into consideration for 3.3. The idea of defining a Py_PORTABLE_API that is even more restrictive than PEP 384 (e.g. eliminating lots of old cruft that is a legacy of CPython's long history of development when it was the *only* viable Python implementation) may also be worth exploring. Absolutely. I intend to do just that. I think we should try to have deprecations and removals in the codebase by the first alpha release for maximal testing. My next sentence [snipped] was "GP's asyncore changes inspired this thought, but I would apply it generally." Why would we deprecate or remove anything? Are some functions useless? Shannon thinks so. I am specifically suggesting that he make any removal suggestion well before the alpha release. I think he's referring to deprecations and removals in general. Yes, as I said. I am also thinking about 3.2 deprecations that will become 3.3 removals. That includes one that I am responsible for. -- Terry Jan Reedy ___ 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] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On Fri, Feb 11, 2011 at 10:36 AM, Antoine Pitrou wrote: > Daniel Stutzbach wrote: > > I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys. > > Would that be a Mapping or a Sequence? Before or after monkey-patching? :-) -- Daniel Stutzbach ___ 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] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On Sat, Feb 12, 2011 at 5:56 AM, Giampaolo Rodolà wrote: > Yeah, the original API design (which is very inflexible) and the lack > of maintenance for many years is at the base of asyncore problems. > I still think it worths some love as a stdlib module, though. Oh, definitely. It's popularity is half the problem :) Flawed API + lack of popularity = just fix it Flawed API + popularity = years of fun* *For a given definition of fun, that may or may not align with any real person's idea of fun ;) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
Antoine Pitrou writes: > Would that be a Mapping or a Sequence? Sure it would be nowhere near as predictable as a Mapping or Sequence, so Isuppose it would be a Container ... although the probability of OverflowException is near 1. ___ 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
