tags when executed in text mode http://bugs.python.org/issue12890 7 msgs #13466: new timezones http://bugs.python.org/issue13466 7 msgs Issues closed (29) ================== #7049: decimal.py: Three argument power issues http://bugs.python.org/issue7049 closed by mark.dickinson #8270: Should socket.PF_PACKET be removed, in favor of socket.AF_PACK http://bugs.python.org/issue8270 closed by neologix #9614: _pickle is not entirely 64-bit safe http://bugs.python.org/issue9614 closed by pitrou #12156: test_multiprocessing.test_notify_all() timeout (1 hour) on Fre http://bugs.python.org/issue12156 closed by neologix #12245: Document the meaning of FLT_ROUNDS constants for sys.float_inf http://bugs.python.org/issue12245 closed by mark.dickinson #12934: pysetup doesn???t work for the docutils project http://bugs.python.org/issue12934 closed by eric.araujo #13093: Redundant code in PyUnicode_EncodeDecimal() http://bugs.python.org/issue13093 closed by haypo #13156: _PyGILState_Reinit assumes auto thread state will always exist http://bugs.python.org/issue13156 closed by neologix #13215: multiprocessing Manager.connect() aggressively retries refused http://bugs.python.org/issue13215 closed by neologix #13245: sched.py kwargs addition and default time functions http://bugs.python.org/issue13245 closed by giampaolo.rodola #13313: test_time fails: tzset() do not change timezone http://bugs.python.org/issue13313 closed by haypo #13338: Not all enumerations used in _Py_ANNOTATE_MEMORY_ORDER http://bugs.python.org/issue13338 closed by python-dev #13393: Improve BufferedReader.read1() http://bugs.python.org/issue13393 closed by pitrou #13401: test_argparse fails with root permissions http://bugs.python.org/issue13401 closed by python-dev #13411: Hashable memoryviews http://bugs.python.org/issue13411 closed by pitrou #13415: del os.environ[key] ignores errors http://bugs.python.org/issue13415 closed by python-dev #13417: faster utf-8 decoding http://bugs.python.org/issue13417 closed by pitrou #13425: http.client.HTTPMessage.getallmatchingheaders() always returns http://bugs.python.org/issue13425 closed by stachjankowski #13431: Pass context information into the extension module init functi http://bugs.python.org/issue13431 closed by scoder #13432: Encoding alias "unicode" http://bugs.python.org/issue13432 closed by georg.brandl #13442: Better support for pipe I/O encoding in subprocess http://bugs.python.org/issue13442 closed by ncoghlan #13457: Display module name as string in `ImportError` http://bugs.python.org/issue13457 closed by cool-RR #13458: _ssl memory leak in _get_peer_alt_names http://bugs.python.org/issue13458 closed by pitrou #13459: logger.propagate=True behavior clarification http://bugs.python.org/issue13459 closed by python-dev #13460: urllib methods should demand unicode, instead demand str http://bugs.python.org/issue13460 closed by r.david.murray #13468: Python 2.7.1 SegmentationFaults when given high recursion limi http://bugs.python.org/issue13468 closed by benjamin.peterson #13469: TimedRotatingFileHandler fails to handle intervals of several http://bugs.python.org/issue13469 closed by vinay.sajip #13470: A user may need ... when she has ... http://bugs.python.org/issue13470 closed by pitrou #13480: range exits loop without action when start is higher than end http://bugs.python.org/issue13480 closed by r.david.murray From brett at python.org Fri Nov 25 18:37:59 2011 From: brett at python.org (Brett Cannon) Date: Fri, 25 Nov 2011 12:37:59 -0500 Subject: [Python-Dev] PyPy 1.7 - widening the sweet spot In-Reply-To: References: <6F9490B9-DBEF-4CF6-89B7-26EA0C8A88E2@underboss.org> Message-ID: On Thu, Nov 24, 2011 at 07:46, Nick Coghlan wrote: > On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski > wrote: > > The problem is not with maintaining the modified directory. The > > problem was always things like changing interface between the C > > version and the Python version or introduction of new stuff that does > > not run on pypy because it relies on refcounting. I don't see how > > having a subrepo helps here. > > Indeed, the main thing that can help on this front is to get more > modules to the same state as heapq, io, datetime (and perhaps a few > others that have slipped my mind) where the CPython repo actually > contains both C and Python implementations and the test suite > exercises both to make sure their interfaces remain suitably > consistent (even though, during normal operation, CPython users will > only ever hit the C accelerated version). > > This not only helps other implementations (by keeping a Python version > of the module continuously up to date with any semantic changes), but > can help people that are porting CPython to new platforms: the C > extension modules are far more likely to break in that situation than > the pure Python equivalents, and a relatively slow fallback is often > going to be better than no fallback at all. (Note that ctypes based > pure Python modules *aren't* particularly useful for this purpose, > though - due to the libffi dependency, ctypes is one of the extension > modules most likely to break when porting). > And the other reason I plan to see this through before I die is to help distribute the maintenance burden. Why should multiple VMs fix bad assumptions made by CPython in their own siloed repos and then we hope the change gets pushed upstream to CPython when it could be fixed once in a single repo that everyone works off of? -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Fri Nov 25 18:37:46 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 25 Nov 2011 18:37:46 +0100 Subject: [Python-Dev] PyPy 1.7 - widening the sweet spot References: <6F9490B9-DBEF-4CF6-89B7-26EA0C8A88E2@underboss.org> Message-ID: <20111125183746.45ab20b5@pitrou.net> On Fri, 25 Nov 2011 12:37:59 -0500 Brett Cannon wrote: > On Thu, Nov 24, 2011 at 07:46, Nick Coghlan wrote: > > > On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski > > wrote: > > > The problem is not with maintaining the modified directory. The > > > problem was always things like changing interface between the C > > > version and the Python version or introduction of new stuff that does > > > not run on pypy because it relies on refcounting. I don't see how > > > having a subrepo helps here. > > > > Indeed, the main thing that can help on this front is to get more > > modules to the same state as heapq, io, datetime (and perhaps a few > > others that have slipped my mind) where the CPython repo actually > > contains both C and Python implementations and the test suite > > exercises both to make sure their interfaces remain suitably > > consistent (even though, during normal operation, CPython users will > > only ever hit the C accelerated version). > > > > This not only helps other implementations (by keeping a Python version > > of the module continuously up to date with any semantic changes), but > > can help people that are porting CPython to new platforms: the C > > extension modules are far more likely to break in that situation than > > the pure Python equivalents, and a relatively slow fallback is often > > going to be better than no fallback at all. (Note that ctypes based > > pure Python modules *aren't* particularly useful for this purpose, > > though - due to the libffi dependency, ctypes is one of the extension > > modules most likely to break when porting). > > > > And the other reason I plan to see this through before I die Uh! Any bad news? :/ From amauryfa at gmail.com Fri Nov 25 19:21:48 2011 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Fri, 25 Nov 2011 19:21:48 +0100 Subject: [Python-Dev] PyPy 1.7 - widening the sweet spot In-Reply-To: References: <6F9490B9-DBEF-4CF6-89B7-26EA0C8A88E2@underboss.org> Message-ID: 2011/11/25 Brett Cannon > > > On Thu, Nov 24, 2011 at 07:46, Nick Coghlan wrote: > >> On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski >> wrote: >> > The problem is not with maintaining the modified directory. The >> > problem was always things like changing interface between the C >> > version and the Python version or introduction of new stuff that does >> > not run on pypy because it relies on refcounting. I don't see how >> > having a subrepo helps here. >> >> Indeed, the main thing that can help on this front is to get more >> modules to the same state as heapq, io, datetime (and perhaps a few >> others that have slipped my mind) where the CPython repo actually >> contains both C and Python implementations and the test suite >> exercises both to make sure their interfaces remain suitably >> consistent (even though, during normal operation, CPython users will >> only ever hit the C accelerated version). >> >> This not only helps other implementations (by keeping a Python version >> of the module continuously up to date with any semantic changes), but >> can help people that are porting CPython to new platforms: the C >> extension modules are far more likely to break in that situation than >> the pure Python equivalents, and a relatively slow fallback is often >> going to be better than no fallback at all. (Note that ctypes based >> pure Python modules *aren't* particularly useful for this purpose, >> though - due to the libffi dependency, ctypes is one of the extension >> modules most likely to break when porting). >> > > And the other reason I plan to see this through before I die is to help > distribute the maintenance burden. Why should multiple VMs fix bad > assumptions made by CPython in their own siloed repos and then we hope the > change gets pushed upstream to CPython when it could be fixed once in a > single repo that everyone works off of? > PyPy copied the CPython stdlib in a directory named "2.7", which is never modified; instead, adaptations are made by copying the file into "modified-2.7", and fixed there. Both directories appear in sys.path This was done for this very reason: so that it's easy to identify the differences and suggest changes to push upstream. But this process was not very successful for several reasons: - The definition of "bad assumptions" used to be very strict. It's much much better nowadays, thanks to the ResourceWarning in 3.x for example (most changes in modified-2.7 are related to the garbage collector), and wider acceptance by the core developers of the "@impl_detail" decorators in tests. - 2.7 was already in maintenance mode, and such changes were not considered as bug fixes, so modified-2.7 never shrinks. It was a bit hard to find the motivation to fix only the 3.2 version of the stdlib, which you can not even test with PyPy! - Some modules in the stdlib rely on specific behaviors of the VM or extension modules that are not always easy to implement correctly in PyPy. The ctypes module is the most obvious example to me, but also the pickle/copy modules which were modified because of subtle differences around built-in methods (or was it the __builtins__ module?) And oh, I almost forgot distutils, which needs to parse some Makefile which of course does not exist in PyPy. - Differences between C extensions and pure Python modules are sometimes considered "undefined behaviour" and are rejected. See issue13274, this one has an happy ending, but I remember that the _pyio.py module chose to not fix some obscure reentrancy issues (which I completely agree with) -- Amaury Forgeot d'Arc -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Fri Nov 25 23:14:04 2011 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 25 Nov 2011 22:14:04 +0000 Subject: [Python-Dev] PEP 380 In-Reply-To: References: Message-ID: On 24 Nov 2011, at 04:06, Nick Coghlan wrote: > On Thu, Nov 24, 2011 at 10:28 AM, Guido van Rossum wrote: >> Mea culpa for not keeping track, but what's the status of PEP 380? I >> really want this in Python 3.3! > > There are two relevant tracker issues (both with me for the moment). > > The main tracker issue for PEP 380 is here: http://bugs.python.org/issue11682 > > That's really just missing the doc updates - I haven't had a chance to > look at Zbyszek's latest offering on that front, but it shouldn't be > far off being complete (the *text* in his previous docs patch actually > seemed reasonable - I mainly objected to way it was organised). > > However, the PEP 380 test suite updates have a dependency on a new dis > module feature that provides an iterator over a structured description > of bytecode instructions: http://bugs.python.org/issue11816 Is it necessary to test parts of PEP 380 through bytecode structures rather than semantics? Those tests aren't going to be usable by other implementations. Michael > > I find Meador's suggestion to change the name of the new API to > something involving the word "instruction" appealing, so I plan to do > that, which will have a knock-on effect on the tests in the PEP 380 > branch. However, even once I get that done, Raymond specifically said > he wanted to review the dis module patch before I check it in, so I > don't plan to commit it until he gives the OK (either because he > reviewed it, or because he decides he's OK with it going in without > his review and he can review and potentially update it in Mercurial > any time before 3.3 is released). > > I currently plan to update my working branches for both of those on > the 3rd of December, so hopefully they'll be ready to go within the > next couple of weeks. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > _______________________________________________ > 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 > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From jcea at jcea.es Sat Nov 26 03:18:51 2011 From: jcea at jcea.es (Jesus Cea) Date: Sat, 26 Nov 2011 03:18:51 +0100 Subject: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS" In-Reply-To: <9bf460d39f263e856f6ff5042f28dfc6@netwok.org> References: <4EB94F97.6020002@jcea.es> <9bf460d39f263e856f6ff5042f28dfc6@netwok.org> Message-ID: <4ED04C8B.8000502@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/11/11 16:56, ?ric Araujo wrote: > Ezio and I chatted a bit about his on IRC and he may try to write > a Python parser for Misc/NEWS in order to write a fully automated > merge tool. Anything new in this front? :-) - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTtBMi5lgi5GaxT1NAQLKsgP6At6qnzHknuTjq35mHfxVSOxJnMuZ8/vx 5ZXHcxCuPJud9GJz0+NEmDPImQAtRUZyV41ud9nQYIfhYE5rV4qBiK7KwMspg39o kclfRhMIPsQV3PkB4dDWy+gEkck+Q16pSzdtxbzKx7DpYk7lnFp/vsHQbNC5iqC9 pfmMny4L0s8= =NlDr -----END PGP SIGNATURE----- From ncoghlan at gmail.com Sat Nov 26 05:39:45 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 26 Nov 2011 14:39:45 +1000 Subject: [Python-Dev] PEP 380 In-Reply-To: References: Message-ID: On Sat, Nov 26, 2011 at 8:14 AM, Michael Foord wrote: > > On 24 Nov 2011, at 04:06, Nick Coghlan wrote: > >> On Thu, Nov 24, 2011 at 10:28 AM, Guido van Rossum wrote: >>> Mea culpa for not keeping track, but what's the status of PEP 380? I >>> really want this in Python 3.3! >> >> There are two relevant tracker issues (both with me for the moment). >> >> The main tracker issue for PEP 380 is here: http://bugs.python.org/issue11682 >> >> That's really just missing the doc updates - I haven't had a chance to >> look at Zbyszek's latest offering on that front, but it shouldn't be >> far off being complete (the *text* in his previous docs patch actually >> seemed reasonable - I mainly objected to way it was organised). >> >> However, the PEP 380 test suite updates have a dependency on a new dis >> module feature that provides an iterator over a structured description >> of bytecode instructions: http://bugs.python.org/issue11816 > > > Is it necessary to test parts of PEP 380 through bytecode structures rather than semantics? Those tests aren't going to be usable by other implementations. The affected tests aren't testing the PEP 380 semantics, they're specifically testing CPython's bytecode generation for yield from expressions and disassembly of same. Just because they aren't of any interest to other implementations doesn't mean *we* don't need them :) There are plenty of behavioural tests to go along with the bytecode specific ones, and those *will* be useful to other implementations. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From raymond.hettinger at gmail.com Sat Nov 26 06:14:59 2011 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Fri, 25 Nov 2011 21:14:59 -0800 Subject: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS" In-Reply-To: <4ED04C8B.8000502@jcea.es> References: <4EB94F97.6020002@jcea.es> <9bf460d39f263e856f6ff5042f28dfc6@netwok.org> <4ED04C8B.8000502@jcea.es> Message-ID: <52625A45-0613-43DE-9892-2EB6DFA635C2@gmail.com> On Nov 25, 2011, at 6:18 PM, Jesus Cea wrote: > On 12/11/11 16:56, ?ric Araujo wrote: >> Ezio and I chatted a bit about his on IRC and he may try to write >> a Python parser for Misc/NEWS in order to write a fully automated >> merge tool. > > Anything new in this front? :-) To me, it would make more sense to split the file into a Misc/NEWS3.2 and Misc/NEWS3.3 much as we've done with whatsnew. That would make merging a piece of cake and would avoid adding a parser (an its idiosyncracies) to the toolchain. Raymond -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Sat Nov 26 06:29:34 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 26 Nov 2011 15:29:34 +1000 Subject: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS" In-Reply-To: <52625A45-0613-43DE-9892-2EB6DFA635C2@gmail.com> References: <4EB94F97.6020002@jcea.es> <9bf460d39f263e856f6ff5042f28dfc6@netwok.org> <4ED04C8B.8000502@jcea.es> <52625A45-0613-43DE-9892-2EB6DFA635C2@gmail.com> Message-ID: On Sat, Nov 26, 2011 at 3:14 PM, Raymond Hettinger wrote: > > On Nov 25, 2011, at 6:18 PM, Jesus Cea wrote: > > On 12/11/11 16:56, ?ric Araujo wrote: > > Ezio and I chatted a bit about his on IRC and he may try to write > > a Python parser for Misc/NEWS in order to write a fully automated > > merge tool. > > Anything new in this front? :-) > > To me, it would make more sense to split the file into a Misc/NEWS3.2 and > Misc/NEWS3.3 much as we've done with whatsnew. ?That would make merging a > piece of cake and would avoid adding a parser (and its idiosyncracies) to the > toolchain. +1 A simple-but-it-works approach to this problem sounds good to me. We'd still need to work out a few conventions about how changes that affect both versions get recorded (I still favour putting independent entries in both files), but simply eliminating the file name collision will also eliminate most of the merge conflicts. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From fijall at gmail.com Sat Nov 26 08:46:29 2011 From: fijall at gmail.com (Maciej Fijalkowski) Date: Sat, 26 Nov 2011 09:46:29 +0200 Subject: [Python-Dev] PEP 380 In-Reply-To: References: Message-ID: On Sat, Nov 26, 2011 at 6:39 AM, Nick Coghlan wrote: > On Sat, Nov 26, 2011 at 8:14 AM, Michael Foord > wrote: >> >> On 24 Nov 2011, at 04:06, Nick Coghlan wrote: >> >>> On Thu, Nov 24, 2011 at 10:28 AM, Guido van Rossum wrote: >>>> Mea culpa for not keeping track, but what's the status of PEP 380? I >>>> really want this in Python 3.3! >>> >>> There are two relevant tracker issues (both with me for the moment). >>> >>> The main tracker issue for PEP 380 is here: http://bugs.python.org/issue11682 >>> >>> That's really just missing the doc updates - I haven't had a chance to >>> look at Zbyszek's latest offering on that front, but it shouldn't be >>> far off being complete (the *text* in his previous docs patch actually >>> seemed reasonable - I mainly objected to way it was organised). >>> >>> However, the PEP 380 test suite updates have a dependency on a new dis >>> module feature that provides an iterator over a structured description >>> of bytecode instructions: http://bugs.python.org/issue11816 >> >> >> Is it necessary to test parts of PEP 380 through bytecode structures rather than semantics? Those tests aren't going to be usable by other implementations. > > The affected tests aren't testing the PEP 380 semantics, they're > specifically testing CPython's bytecode generation for yield from > expressions and disassembly of same. Just because they aren't of any > interest to other implementations doesn't mean *we* don't need them :) > > There are plenty of behavioural tests to go along with the bytecode > specific ones, and those *will* be useful to other implementations. > > Cheers, > Nick. > I'm with nick on this one, seems like a very useful test, just remember to mark it as @impl_detail (or however the decorator is called). Cheers, fijal From fuzzyman at voidspace.org.uk Sat Nov 26 14:46:12 2011 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 26 Nov 2011 13:46:12 +0000 Subject: [Python-Dev] PEP 380 In-Reply-To: References: Message-ID: <4ED0EDA4.6050309@voidspace.org.uk> On 26/11/2011 07:46, Maciej Fijalkowski wrote: > On Sat, Nov 26, 2011 at 6:39 AM, Nick Coghlan wrote: >> On Sat, Nov 26, 2011 at 8:14 AM, Michael Foord >> wrote: >>> On 24 Nov 2011, at 04:06, Nick Coghlan wrote: >>> >>>> On Thu, Nov 24, 2011 at 10:28 AM, Guido van Rossum wrote: >>>>> Mea culpa for not keeping track, but what's the status of PEP 380? I >>>>> really want this in Python 3.3! >>>> There are two relevant tracker issues (both with me for the moment). >>>> >>>> The main tracker issue for PEP 380 is here: http://bugs.python.org/issue11682 >>>> >>>> That's really just missing the doc updates - I haven't had a chance to >>>> look at Zbyszek's latest offering on that front, but it shouldn't be >>>> far off being complete (the *text* in his previous docs patch actually >>>> seemed reasonable - I mainly objected to way it was organised). >>>> >>>> However, the PEP 380 test suite updates have a dependency on a new dis >>>> module feature that provides an iterator over a structured description >>>> of bytecode instructions: http://bugs.python.org/issue11816 >>> >>> Is it necessary to test parts of PEP 380 through bytecode structures rather than semantics? Those tests aren't going to be usable by other implementations. >> The affected tests aren't testing the PEP 380 semantics, they're >> specifically testing CPython's bytecode generation for yield from >> expressions and disassembly of same. Just because they aren't of any >> interest to other implementations doesn't mean *we* don't need them :) >> >> There are plenty of behavioural tests to go along with the bytecode >> specific ones, and those *will* be useful to other implementations. >> >> Cheers, >> Nick. >> > I'm with nick on this one, seems like a very useful test, just > remember to mark it as @impl_detail (or however the decorator is > called). Fair enough. :-) If other tests are failing (the semantics are wrong) then having a test that shows you the semantics are screwed because the bytecode has been incorrectly generated will be a useful diagnostic tool. On the other hand it is hard to see that bytecode generation could be "wrong" without it affecting some test of semantics that should also fail - so as tests in their own right the bytecode tests *must* be superfluous (or there is some aspect of the semantics that is *only* tested through the bytecode and that seems bad, particularly for other implementations). All the best, Michael > Cheers, > fijal > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From merwok at netwok.org Sat Nov 26 14:52:32 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sat, 26 Nov 2011 14:52:32 +0100 Subject: [Python-Dev] PyPy 1.7 - widening the sweet spot In-Reply-To: References: <6F9490B9-DBEF-4CF6-89B7-26EA0C8A88E2@underboss.org> Message-ID: <4ED0EF20.1060203@netwok.org> Le 25/11/2011 19:21, Amaury Forgeot d'Arc a ?crit : > And oh, I almost forgot distutils, which needs to parse some Makefile which > of course does not exist in PyPy. This is a bug (#10764) that I intend to fix for the next releases of 2.7 and 3.2. I also want to fix all modules that use sys.version[:2] to get 'X.Y', which is a CPython implementation detail. I find PyPy and excellent project, so you can send any bugs in distutils, sysconfig, site and friends my way! I also hope to make distutils2 compatible with PyPy before 2012. Cheers From merwok at netwok.org Sat Nov 26 17:13:03 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sat, 26 Nov 2011 17:13:03 +0100 Subject: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS" In-Reply-To: <4ED04C8B.8000502@jcea.es> References: <4EB94F97.6020002@jcea.es> <9bf460d39f263e856f6ff5042f28dfc6@netwok.org> <4ED04C8B.8000502@jcea.es> Message-ID: <4ED1100F.4090701@netwok.org> Le 26/11/2011 03:18, Jesus Cea a ?crit : > On 12/11/11 16:56, ?ric Araujo wrote: >> Ezio and I chatted a bit about his on IRC and he may try to write >> a Python parser for Misc/NEWS in order to write a fully automated >> merge tool. > Anything new in this front? :-) Not from me. I don?t have the roundtuits, and I find my hgddmt script good enough. Cheers From aahz at pythoncraft.com Sat Nov 26 17:14:35 2011 From: aahz at pythoncraft.com (Aahz) Date: Sat, 26 Nov 2011 08:14:35 -0800 Subject: [Python-Dev] 404 in (important) documentation in www.python.org and contributor agreement In-Reply-To: <4ECEDAC9.7040903@jcea.es> References: <4ECEDAC9.7040903@jcea.es> Message-ID: <20111126161435.GA24540@panix.com> On Fri, Nov 25, 2011, Jesus Cea wrote: > > Checking documentation abut the contributor license agreement, I had > encounter a wrong HTML link in http://www.python.org/about/help/ : > > * "Python Patch Guidelines" points to > http://www.python.org/dev/patches/, that doesn't exist. Fixed > PS: The devguide doesn't say anything (AFAIK) about the contributor > agreement. The devguide seems to now be hosted on docs.python.org and AFAIK the web team doesn't deal with that. Someone from python-dev needs to lead. -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ WiFi is the SCSI of the 21st Century -- there are fundamental technical reasons for sacrificing a goat. (with no apologies to John Woods) From merwok at netwok.org Sat Nov 26 17:16:44 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sat, 26 Nov 2011 17:16:44 +0100 Subject: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS" In-Reply-To: References: <4EB94F97.6020002@jcea.es> <9bf460d39f263e856f6ff5042f28dfc6@netwok.org> <4ED04C8B.8000502@jcea.es> <52625A45-0613-43DE-9892-2EB6DFA635C2@gmail.com> Message-ID: <4ED110EC.3080702@netwok.org> Le 26/11/2011 06:29, Nick Coghlan a ?crit : > On Sat, Nov 26, 2011 at 3:14 PM, Raymond Hettinger wrote: >> To me, it would make more sense to split the file into a Misc/NEWS3.2 and >> Misc/NEWS3.3 much as we've done with whatsnew. That would make merging a >> piece of cake and would avoid adding a parser (and its idiosyncracies) to the >> toolchain. > > +1 > > A simple-but-it-works approach to this problem sounds good to me. > > We'd still need to work out a few conventions about how changes that > affect both versions get recorded (I still favour putting independent > entries in both files), but simply eliminating the file name collision > will also eliminate most of the merge conflicts. Maybe I?m not seeing something, but adding an entry by hand does not sound much better than solving conflicts by hand. Another idea: If we had different sections for bug fixes and new features (with or without another level of core/lib/doc/tests separation), then there should be less (no?) conflicts. Regards From merwok at netwok.org Sat Nov 26 17:23:54 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sat, 26 Nov 2011 17:23:54 +0100 Subject: [Python-Dev] Long term development external named branches and periodic merges from python In-Reply-To: References: <4ECE741F.10303@jcea.es> <4ECE7A25.5000701@netwok.org> Message-ID: <4ED1129A.5090702@netwok.org> Le 24/11/2011 22:46, Xavier Morel a ?crit : > Wouldn't it be simpler to just use MQ and upload the patch(es) > from the series? MQ is a very powerful and useful tool, but its learning curve is steeper than regular Mercurial, and it is not designed for long-term development. Rebasing patches is more fragile and less user-friendly than merging branches, and it?s also easier to corrupt your MQ patch queue than your Mercurial repo. I like Mercurial merges and I don?t like diffs of diffs, so I avoid MQ. > Would be easier to keep in sync with the development tip too. How so? With a regular clone you have to pull and merge regularly, with MQ you have to pull and rebase. Regards From merwok at netwok.org Sat Nov 26 17:30:22 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sat, 26 Nov 2011 17:30:22 +0100 Subject: [Python-Dev] Long term development external named branches and periodic merges from python In-Reply-To: <4ECEFFD4.5030601@jcea.es> References: <4ECE741F.10303@jcea.es> <4ECE7A25.5000701@netwok.org> <4ECEFFD4.5030601@jcea.es> Message-ID: <4ED1141E.9050604@netwok.org> Le 25/11/2011 03:39, Jesus Cea a ?crit : > On 24/11/11 18:08, ?ric Araujo wrote: >>> I have a question and I would rather have an answer instead of >>> actually trying and getting myself in a messy situation. >> Clones are cheap, trying is cheap! > [snip valid reasons for not trying] My reply was tongue-in-cheek :) FYI, it?s not considered pollution to use a tracker issue to test hooks or Mercurial integration (there?s even one issue entirely devoted to such tests, but I can?t find its number). >>> 5. Development of the new feature is taking a long time, and >>> python canonical version keeps moving forward. The clone+branch >>> and the original python version are diverging. Eventually there >>> are changes in python that the programmer would like in her >>> version, so she does a "pull" and then a merge for the original >>> python branch to her named branch. >> I do this all the time. I work on a fix-nnnn branch, and once a >> week for example I pull and merge the base branch. Sometimes there >> are no conflicts except Misc/NEWS, sometimes I have to adapt my >> code because of other people?s changes before I can commit the >> merge. > That is good, because that means your patch is always able to be > applied to the original branch tip, and that you changes work with > current work in the mainline. > > That is what I want to do, but I need to know that it is safe to do so > (from the "Create Patch" perspective). I don?t understand ?safe?. >>> 6. What would be posted in the bug tracker when she does a new >>> "Create Patch"?. Only her changes, her changes SINCE the merge, >>> her changes plus merged changes or something else?. >> The diff would be equivalent to ?hg diff -r base? and would contain >> all the changes she did to add the bug fix or feature. Merging >> only makes sure that the computed diff does not appear to touch >> unrelated files, IOW that it applies cleanly. (Barring bugs in >> Mercurial-Roundup integration, we have a few of these in the >> metatracker.) > So you are saying that "Create patch" will ONLY get the differences in > the development branch and not the changes brought in from the merge?. I don?t really understand how you understood what I said :( The merge brings in changes from default; when you diff your branch against default later, it will not show the changes brought by the merge, but it will apply cleanly on top of default. Does this wording make sense? Regards From merwok at netwok.org Sat Nov 26 17:44:59 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sat, 26 Nov 2011 17:44:59 +0100 Subject: [Python-Dev] Deprecation policy In-Reply-To: <4EA560E3.8060307@gmail.com> References: <4EA560E3.8060307@gmail.com> Message-ID: <4ED1178B.6030203@netwok.org> Hi, +1 to all Ezio said. One specific remark: PendingDeprecationWarning could just become an alias of DeprecationWarning, but maybe there is code out there that relies on the distinction, and there is no real value in making it an alias (there is value in removing it altogether, but we can?t do that, can we?). I don?t see the need to deprecate PDW, except in documentation, and am -1 to the metaclass idea (no need). Cheers From merwok at netwok.org Sat Nov 26 17:53:02 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sat, 26 Nov 2011 17:53:02 +0100 Subject: [Python-Dev] PEP 402: Simplified Package Layout and Partitioning In-Reply-To: <20110811183114.701DF3A406B@sparrow.telecommunity.com> References: <4E43E9A6.7020608@netwok.org> <20110811183114.701DF3A406B@sparrow.telecommunity.com> Message-ID: <4ED1196E.8090505@netwok.org> Hi, Going through my email backlog. > Le 11/08/2011 20:30, P.J. Eby a ?crit : >> At 04:39 PM 8/11/2011 +0200, ?ric Araujo wrote: >>>> (By the way, both of these additions to the import protocol (i.e. the >>>> dynamically-added ``__path__``, and dynamically-created modules) >>>> apply recursively to child packages, using the parent package's >>>> ``__path__`` in place of ``sys.path`` as a basis for generating a >>>> child ``__path__``. This means that self-contained and virtual >>>> packages can contain each other without limitation, with the caveat >>>> that if you put a virtual package inside a self-contained one, it's >>>> gonna have a really short ``__path__``!) >>> I don't understand the caveat or its implications. >> Since each package's __path__ is the same length or shorter than its >> parent's by default, then if you put a virtual package inside a >> self-contained one, it will be functionally speaking no different >> than a self-contained one, in that it will have only one path >> entry. So, it's not really useful to put a virtual package inside a >> self-contained one, even though you can do it. (Apart form it >> letting you avoid a superfluous __init__ module, assuming it's indeed >> superfluous.) I still don?t understand why this matters or what negative effects it could have on code, but I?m fine with not understanding. I?ll trust that people writing or maintaining import-related tools will agree or complain about that item. >>> I?ll just regret that it's not possible to provide a module docstring >>> to inform that this is a namespace package used for X and Y. >> It *is* possible - you'd just have to put it in a "zc.py" file. IOW, >> this PEP still allows "namespace-defining packages" to exist, as was >> requested by early commenters on PEP 382. It just doesn't *require* >> them to exist in order for the namespace contents to be importable. That?s quite cool. I guess such a namespace-defining module (zc.py here) would be importable, right? Also, would it cause worse performance for other zc.* packages than if there were no zc.py? >>> This was probably said on import-sig, but here I go: yet another import >>> artifact in the sys module! I hope we get ImportEngine in 3.3 to clean >>> up all this. >> Well, I rather *like* having them there, personally, vs. having to >> learn yet another API, but oh well, whatever. Agreed with ?whatever? :) I just like to grunt sometimes. >> AFAIK, ImportEngine isn't going to do away with the need for the >> global ones to live somewhere, Yep, but as Nick replied, at least we?ll gain one structure to rule them all. >>> Let's imagine my application Spam has a namespace spam.ext for plugins. >>> To use a custom directory where plugins are stored, or a zip file with >>> plugins (I don't use eggs, so let me talk about zip files here), I'd >>> have to call sys.path.append *and* pkgutil.extend_virtual_paths? >> As written in the current proposal, yes. There was some discussion >> on Python-Dev about having this happen automatically, and I proposed >> that it could be done by making virtual packages' __path__ attributes >> an iterable proxy object, rather than a list: That sounds a bit too complicated. What about just having pkgutil.extend_virtual_paths call sys.path.append? For maximum flexibility, extend_virtual_paths could have an argument to avoid calling sys.path.append. >>> Besides, putting data files in a Python package is held very poorly by >>> some (mostly people following the File Hierarchy Standard), >> ISTM that anybody who thinks that is being inconsistent in >> considering the Python code itself to not be a "data file" by that >> same criterion... especially since one of the more common uses for >> such "data" files are for e.g. HTML templates (which usually contain >> some sort of code) or GUI resources (which are pretty tightly bound >> to the code). A good example is documentation: Having a unique location (/usr/share/doc) for all installed software makes my life easier. Another example is JavaScript files used with HTML documents, such as jQuery: Debian recently split the jQuery file out of their Sphinx package, so that there is only one library installed that all packages can use and that can be updated and fixed once for all. (I?m simplifying; there can be multiple versions of libraries, but not multiple copies. I?ll stop here; I?m not one of the authors of the Filesystem Hierarchy Standard, and I?ll rant against package_data in distutils mailing lists :) >>> A pure virtual package having no source file, I think it should have no >>> __file__ at all. Antoine and someone else thought likewise (I can find the link if you want); do you consider it consensus enough to update the PEP? Regards From benjamin at python.org Sat Nov 26 20:36:25 2011 From: benjamin at python.org (Benjamin Peterson) Date: Sat, 26 Nov 2011 13:36:25 -0600 Subject: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS" In-Reply-To: <52625A45-0613-43DE-9892-2EB6DFA635C2@gmail.com> References: <4EB94F97.6020002@jcea.es> <9bf460d39f263e856f6ff5042f28dfc6@netwok.org> <4ED04C8B.8000502@jcea.es> <52625A45-0613-43DE-9892-2EB6DFA635C2@gmail.com> Message-ID: 2011/11/25 Raymond Hettinger : > To me, it would make more sense to split the file into a Misc/NEWS3.2 and > Misc/NEWS3.3 much as we've done with whatsnew. ?That would make merging a > piece of cake and would avoid adding a parser (an its idiosyncracies) to the > toolchain. Would we not add fixes from 3.2, which were ported to 3.3 to the NEWS3.3 file then? -- Regards, Benjamin From zbyszek at in.waw.pl Sat Nov 26 18:54:13 2011 From: zbyszek at in.waw.pl (=?UTF-8?B?WmJpZ25pZXcgSsSZZHJ6ZWpld3NraS1Tem1law==?=) Date: Sat, 26 Nov 2011 18:54:13 +0100 Subject: [Python-Dev] ImportError: No module named multiarray (is back) In-Reply-To: <4ECD1D31.7080802@netwok.org> References: <4ECBFF19.8080100@in.waw.pl> <4ECD1D31.7080802@netwok.org> Message-ID: <4ED127C5.1060004@in.waw.pl> Hi, I apologize in advance for the length of this mail. sys.path ======== When a script or a module is executed by invoking python with proper arguments, sys.path is extended. When a path to script is given, the directory containing the script is prepended. When '-m' or '-c' is used, $CWD is prepended. This is documented in http://docs.python.org/dev/using/cmdline.html, so far ok. sys.path and $PYTHONPATH is like $PATH -- if you can convince someone to put a directory under your control in any of them, you can execute code as this someone. Therefore, sys.path is dangerous and important. Unfortunately, sys.path manipulations are only described very briefly, and without any commentary, in the on-line documentation. python(1) manpage doesn't even mention them. The problem: each of the commands below is insecure: python /tmp/script.py (when script.py is safe by itself) ('/tmp' is added to sys.path, so an attacker can override any module imported in /tmp/script.py by writing to /tmp/module.py) cd /tmp && python -mtimeit -s 'import numpy' 'numpy.test()' (UNIX users are accustomed to being able to safely execute programs in any directory, e.g. ls, or gcc, or something. Here '' is added to sys.path, so it is not secure to run python is other-user-writable directories.) cd /tmp/ && python -c 'import numpy; print(numpy.version.version)' (The same as above, '' is added to sys.path.) cd /tmp && python (The same as above). IMHO, if this (long-lived) behaviour is necessary, it should at least be prominently documented. Also in the manpage. Prepending realpath(dirname(scriptname)) ======================================== Before adding a directory to sys.path as described above, Python actually runs os.path.realpath over it. This means that if the path to a script given on the commandline is actually a symlink, the directory containing the real file will be executed. This behaviour is not really documented (the documentation only says "the directory containing that file is added to the start of sys.path"), but since the integrity of sys.path is so important, it should be, IMHO. Using realpath instead of the (expected) path specified by the user breaks imports of non-pure-python (mixed .py and .so) modules from modules executed as scripts on Debian. This is because Debian installs architecture-independent python files in /usr/share/pyshared, and symlinks those files into /usr/lib/pymodules/pythonX.Y/. The architecture-dependent .so and python-version-dependent .pyc files are installed in /usr/lib/pymodules/pythonX.Y/. When a script, e.g. /usr/lib/pymodules/pythonX.Y/script.py, is executed, the directory /usr/share/pyshared is prepended to sys.path. If the script tries to import a module which has architecture-dependent parts (e.g. numpy) it first sees the incomplete module in /usr/share/pyshared and fails. This happens for example in parallel python (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620551) and recently when packaging CellProfiler for Debian. Again, if this is on purpose, it should be documented. PEP 395 (Qualified Names for Modules) ===================================== PEP 395 proposes another sys.path manipulation. When running a script, the directory tree will be walked upwards as long as there are __init__.py files, and then the first directory without will be added. This is of course a fine idea, but it makes a scenario, which was previously safe, insecure. More precisely, when executing a script in a directory in a parent directory-writable-by-other-users, the parent directory will be added to sys.path. So the (safe) operation of downloading an archive with a package, unzipping it in /tmp, changing into the created directory, checking that the script doesn't do anything bad, and running a script is now insecure if there is __init__.py in the archive root. I guess that it would be useful to have an option to turn off those sys.path manipulations. Zbyszek From ncoghlan at gmail.com Sun Nov 27 01:28:33 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 27 Nov 2011 10:28:33 +1000 Subject: [Python-Dev] ImportError: No module named multiarray (is back) In-Reply-To: <4ED127C5.1060004@in.waw.pl> References: <4ECBFF19.8080100@in.waw.pl> <4ECD1D31.7080802@netwok.org> <4ED127C5.1060004@in.waw.pl> Message-ID: 2011/11/27 Zbigniew J?drzejewski-Szmek : > I guess that it would be useful to have an option to turn off those sys.path > manipulations. Yeah, I recently proposed exactly that (a '--nopath0' option) in http://bugs.python.org/issue13475 (that issue also proposes a "-p/--path0" option to *override* the automatic initialisation of sys.path[0] with a different value). I may still make this general question part of the proposals in PEP 395, though, since it's fairly closely related to many of the issues already discussed by that PEP and is something that will need to be thought out fairly well to make sure it achieves the objective of avoiding cross-user interference. There are limits to what we can do by default due to backwards compatibility concerns, but it should at least be possible to provide better tools to help manage the problem. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From petri at digip.org Sun Nov 27 20:33:29 2011 From: petri at digip.org (Petri Lehtinen) Date: Sun, 27 Nov 2011 21:33:29 +0200 Subject: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS" In-Reply-To: <4ED04C8B.8000502@jcea.es> References: <4EB94F97.6020002@jcea.es> <9bf460d39f263e856f6ff5042f28dfc6@netwok.org> <4ED04C8B.8000502@jcea.es> Message-ID: <20111127193329.GA2219@ihaa> Jesus Cea wrote: > On 12/11/11 16:56, ?ric Araujo wrote: > > Ezio and I chatted a bit about his on IRC and he may try to write > > a Python parser for Misc/NEWS in order to write a fully automated > > merge tool. > > Anything new in this front? :-) I don't see what's the problem really. The most common case is to have one conflicting file with one conflict. I'm completely fine with removing the conflict markers and possibly moving my own entry above the other entries. Petri From jcea at jcea.es Mon Nov 28 05:21:18 2011 From: jcea at jcea.es (Jesus Cea) Date: Mon, 28 Nov 2011 05:21:18 +0100 Subject: [Python-Dev] Long term development external named branches and periodic merges from python In-Reply-To: <4ED1141E.9050604@netwok.org> References: <4ECE741F.10303@jcea.es> <4ECE7A25.5000701@netwok.org> <4ECEFFD4.5030601@jcea.es> <4ED1141E.9050604@netwok.org> Message-ID: <4ED30C3E.4090700@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26/11/11 17:30, ?ric Araujo wrote: >> That is what I want to do, but I need to know that it is safe to >> do so (from the "Create Patch" perspective). > I don?t understand ?safe?. "Safe", in this context, means "when clicking 'create patch' the created patch ONLY includes my code in the development branch, EVEN if the branch merged-in the original mainline branch several times". >>>> 6. What would be posted in the bug tracker when she does a >>>> new "Create Patch"?. Only her changes, her changes SINCE the >>>> merge, her changes plus merged changes or something else?. >>> The diff would be equivalent to ?hg diff -r base? and would >>> contain all the changes she did to add the bug fix or feature. >>> Merging only makes sure that the computed diff does not appear >>> to touch unrelated files, IOW that it applies cleanly. >>> (Barring bugs in Mercurial-Roundup integration, we have a few >>> of these in the metatracker.) >> So you are saying that "Create patch" will ONLY get the >> differences in the development branch and not the changes brought >> in from the merge?. > I don?t really understand how you understood what I said :( The > merge brings in changes from default; when you diff your branch > against default later, it will not show the changes brought by the > merge, but it will apply cleanly on top of default. But I am not doing that diff, it is the tracker who is doing that diff. I agree that the following procedure would work. In fact it is the way I used to work, before publishing my repository and using "create patch" in the tracker: 1. Branch. 2. Develop in the branch. 3. Merge changes from mainline INTO the branch. 4. Jump to 2 as many times as needed. 5. When done: 5.1. Do a final merge from mainline to branch. 5.2. Do a DIFF from branch to mainline. After 5.2, the diff shows only the code I have patched in the branch. PERFECT. But I don't know if the tracker does that or not. Without the final merge, a diff between my branch and mainline tips will show my changes PLUS the "undoing" of any change in mainline that I didn't merge in my branch. Since "create patch" (in the tracker) doesn't compare against the tip of mainline (at least not in a trivial way), I guess it is comparing against the BASE of the branch. That is ok... as far as I don't merge changes from mainline to the branch. If so, when diffing the branch tip from the branch base it will show all changes in the branch, both my code and the code imported via merges. So, in this context, if the tracker "create patch" diff from BASE, it is not "safe" to merge changes from mainline to the branch, because if so "create patch" would include code not related to my work. I could try actually merging and clicking "create patch" but if the result is unpleasant my repository would be in a state "not compatible" with "create patch" tool in the tracker. I rather prefer to avoid that, if somebody knows the answer. If nobody can tell, experimentation would be the only option, although any experimental result would be suspicious because the hooks can be changes later or you are hitting any strange corner case. Another approach, that I am doing so far, is to avoid merging from mainline while developing in a branch, just in case. But I am hitting now a situation while there are changes in mainline that overlap my effort so I am quite forced to merge that code in, instead of dealing with a huge divergent code in a month. So, I have avoid to merge in the past and was happy, but I would need to merge now (changes from mainline) and I am unsure on what is going to happen with the "create patch" option in the tracker. Anybody knows the mercurial command used to implement "create patch"?. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTtMMPplgi5GaxT1NAQKzhQP8DzAql1PAJkyEROsWl8CgPpW9ie8jNM1V +K5jLx/dCukzFXrZ2Ba1Tu5IFYFZxH7Wj4rg4sQ47zlKBi6gQELgtGV+bCYPAEt/ WQo7uGUCj+xLmBKXuQQlXrl1pNl9XhlufTNXIzW34o7SPKMEQy7N7uUxpxgwV8JX KoJoYAbiH88= =9lYm -----END PGP SIGNATURE----- From ncoghlan at gmail.com Mon Nov 28 06:06:56 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 28 Nov 2011 15:06:56 +1000 Subject: [Python-Dev] Long term development external named branches and periodic merges from python In-Reply-To: <4ED30C3E.4090700@jcea.es> References: <4ECE741F.10303@jcea.es> <4ECE7A25.5000701@netwok.org> <4ECEFFD4.5030601@jcea.es> <4ED1141E.9050604@netwok.org> <4ED30C3E.4090700@jcea.es> Message-ID: On Mon, Nov 28, 2011 at 2:21 PM, Jesus Cea wrote: > Since "create patch" (in the tracker) doesn't compare against the tip > of mainline (at least not in a trivial way), I guess it is comparing > against the BASE of the branch. That is ok... as far as I don't merge > changes from mainline to the branch. If so, when diffing the branch > tip from the branch base it will show all changes in the branch, both > my code and the code imported via merges. > > So, in this context, if the tracker "create patch" diff from BASE, it > is not "safe" to merge changes from mainline to the branch, because if > so "create patch" would include code not related to my work. No, "Create Patch" is smarter than that. What it does (or tries to do) is walk back through your branch history, trying to find the last point where you merged in a changeset that it recognises as coming from the main CPython repo. It then uses that revision of the CPython repo as the basis for the diff. So if you're just working on a feature branch, periodically pulling from hg.python.org/cpython and merging from default, then it should all work fine. Branches-of-branches (i.e. where you've merged from CPython via another named branch in your local repo) seems to confuse it though - I plan to change my workflow for those cases to merge each branch from the same version of default before merging from the other branch. > Anybody knows the mercurial command used to implement "create patch"?. It's not a single command - it's a short script MvL wrote that uses the Mercurial API to traverse the branch history and find an appropriate revision to diff against. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From raymond.hettinger at gmail.com Mon Nov 28 10:30:53 2011 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Mon, 28 Nov 2011 01:30:53 -0800 Subject: [Python-Dev] Deprecation policy In-Reply-To: <4EA560E3.8060307@gmail.com> References: <4EA560E3.8060307@gmail.com> Message-ID: <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> On Oct 24, 2011, at 5:58 AM, Ezio Melotti wrote: > Hi, > our current deprecation policy is not so well defined (see e.g. [0]), and it seems to me that it's something like: > 1) deprecate something and add a DeprecationWarning; > 2) forget about it after a while; > 3) wait a few versions until someone notices it; > 4) actually remove it; > > I suggest to follow the following process: > 1) deprecate something and add a DeprecationWarning; > 2) decide how long the deprecation should last; > 3) use the deprecated-remove[1] directive to document it; > 4) add a test that fails after the update so that we remember to remove it[2]; How about we agree that actually removing things is usually bad for users. It will be best if the core devs had a strong aversion to removal. Instead, it is best to mark APIs as obsolete with a recommendation to use something else instead. There is rarely a need to actually remove support for something in the standard library. That may serve a notion of tidyness or somesuch but in reality it is a PITA for users making it more difficult to upgrade python versions and making it more difficult to use published recipes. Raymond -------------- next part -------------- An HTML attachment was scrubbed... URL: From catch-all at masklinn.net Mon Nov 28 10:53:24 2011 From: catch-all at masklinn.net (Xavier Morel) Date: Mon, 28 Nov 2011 10:53:24 +0100 Subject: [Python-Dev] Deprecation policy In-Reply-To: <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> Message-ID: On 2011-11-28, at 10:30 , Raymond Hettinger wrote: > On Oct 24, 2011, at 5:58 AM, Ezio Melotti wrote: > How about we agree that actually removing things is usually bad for users. > It will be best if the core devs had a strong aversion to removal. > Instead, it is best to mark APIs as obsolete with a recommendation to use something else instead. > There is rarely a need to actually remove support for something in the standard library. The problem with "deprecating and not removing" (and worse, only informally deprecating by leaving a note in the documentation) is that you end up with zombie APIs: there are tons of tutorials & such on the web talking about them, they're not maintained, nobody really cares about them (but users who found them via Google) and they're all around harmful. It's the current state of many JDK 1.0 and 1.1 APIs and it's dreadful, most of them are more than a decade out of date, sometimes retrofitted for new interfaces (but APIs using them usually are *not* fixed, keeping them in their state of partial death), sometimes still *taught*, all of that because they're only informally deprecated (at best, sometimes not even that as other APIs still depend on them). It's bad for (language) users because they use outdated and partially unmaintained (at least in that it's not improved) APIs and it's bad for (language) maintainers in that once in a while they still have to dive into those things and fix bugs cropping up without the better understanding they have from the old APIs or the cleaner codebase they got from it. Not being too eager to kill APIs is good, but giving rise to this kind of living-dead APIs is no better in my opinion, even more so since Python has lost one of the few tools it had to manage them (as DeprecationWarning was silenced by default). Both choices are harmful to users, but in the long run I do think zombie APIs are worse. From ncoghlan at gmail.com Mon Nov 28 13:06:48 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 28 Nov 2011 22:06:48 +1000 Subject: [Python-Dev] Deprecation policy In-Reply-To: References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> Message-ID: On Mon, Nov 28, 2011 at 7:53 PM, Xavier Morel wrote: > Not being too eager to kill APIs is good, but giving rise to this kind of living-dead APIs is no better in my opinion, even more so since Python has lost one of the few tools it had to manage them (as DeprecationWarning was silenced by default). Both choices are harmful to users, but in the long run I do think zombie APIs are worse. But restricting ourselves to cleaning out such APIs every 10 years or so with a major version bump is also a potentially viable option. So long as the old APIs are fully tested and aren't actively *harmful* to creating reasonable code (e.g. optparse) then refraining from killing them before the (still hypothetical) 4.0 is reasonable. OTOH, genuinely problematic APIs that ideally wouldn't have survived even the 3.x transition (e.g. the APIs that the 3.x subprocess module inherited from the 2.x commands module that run completely counter to the design principles of the subprocess module) should probably still be considered for removal as soon as is reasonable after a superior alternative is made available. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From steve at pearwood.info Mon Nov 28 13:14:46 2011 From: steve at pearwood.info (Steven D'Aprano) Date: Mon, 28 Nov 2011 23:14:46 +1100 Subject: [Python-Dev] Deprecation policy In-Reply-To: References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> Message-ID: <4ED37B36.7080208@pearwood.info> Xavier Morel wrote: > Not being too eager to kill APIs is good, but giving rise to this kind of > living-dead APIs is no better in my opinion, even more so since Python has > lost one of the few tools it had to manage them (as DeprecationWarning was > silenced by default). Both choices are harmful to users, but in the long > run I do think zombie APIs are worse. I would much rather have my code relying on "zombie" APIs and keep working, than to have that code suddenly stop working when the zombie is removed. Working code should stay working. Unless the zombie is actively harmful, what's the big deal if there is a newer, better way of doing something? If it works, and if it's fast enough, why force people to "fix" it? It is a good thing that code or tutorials from Python 1.5 still (mostly) work, even when there are newer, better ways of doing something. I see a lot of newbies, and the frustration they suffer when they accidentally (carelessly) try following 2.x instructions in Python3, or vice versa, is great. It's bad enough (probably unavoidable) that this happens during a major transition like 2 to 3, without it also happening during minor releases. Unless there is a good reason to actively remove an API, it should stay as long as possible. "I don't like this and it should go" is not a good reason, nor is "but there's a better way you should use". When in doubt, please don't break people's code. -- Steven From exarkun at twistedmatrix.com Mon Nov 28 13:45:24 2011 From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com) Date: Mon, 28 Nov 2011 12:45:24 -0000 Subject: [Python-Dev] Deprecation policy In-Reply-To: <4ED37B36.7080208@pearwood.info> References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> <4ED37B36.7080208@pearwood.info> Message-ID: <20111128124524.2308.1242187804.divmod.xquotient.325@localhost.localdomain> On 12:14 pm, steve at pearwood.info wrote: >Xavier Morel wrote: >>Not being too eager to kill APIs is good, but giving rise to this kind >>of >>living-dead APIs is no better in my opinion, even more so since Python >>has >>lost one of the few tools it had to manage them (as DeprecationWarning >>was >>silenced by default). Both choices are harmful to users, but in the >>long >>run I do think zombie APIs are worse. > >I would much rather have my code relying on "zombie" APIs and keep >working, than to have that code suddenly stop working when the zombie >is removed. Working code should stay working. Unless the zombie is >actively harmful, what's the big deal if there is a newer, better way >of doing something? If it works, and if it's fast enough, why force >people to "fix" it? > >It is a good thing that code or tutorials from Python 1.5 still >(mostly) work, even when there are newer, better ways of doing >something. I see a lot of newbies, and the frustration they suffer when >they accidentally (carelessly) try following 2.x instructions in >Python3, or vice versa, is great. It's bad enough (probably >unavoidable) that this happens during a major transition like 2 to 3, >without it also happening during minor releases. > >Unless there is a good reason to actively remove an API, it should stay >as long as possible. "I don't like this and it should go" is not a good >reason, nor is "but there's a better way you should use". When in >doubt, please don't break people's code. +1 Jean-Paul From python-dev at masklinn.net Mon Nov 28 13:56:31 2011 From: python-dev at masklinn.net (Xavier Morel) Date: Mon, 28 Nov 2011 13:56:31 +0100 Subject: [Python-Dev] Deprecation policy In-Reply-To: References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> Message-ID: On 2011-11-28, at 13:06 , Nick Coghlan wrote: > On Mon, Nov 28, 2011 at 7:53 PM, Xavier Morel wrote: >> Not being too eager to kill APIs is good, but giving rise to this kind of living-dead APIs is no better in my opinion, even more so since Python has lost one of the few tools it had to manage them (as DeprecationWarning was silenced by default). Both choices are harmful to users, but in the long run I do think zombie APIs are worse. > > But restricting ourselves to cleaning out such APIs every 10 years or > so with a major version bump is also a potentially viable option. > > So long as the old APIs are fully tested and aren't actively *harmful* > to creating reasonable code (e.g. optparse) then refraining from > killing them before the (still hypothetical) 4.0 is reasonable. Sure, the original proposal leaves the deprecation timelines as TBD and I hope I did not give the impression of setting up a timeline (that was not the intention). Ezio's original proposal could simply be implemented by having the second step ("decide how long the deprecation should last") default to "the next major release", I don't think that goes against his proposal, and in case APIs are actively harmful (e.g. very hard to use correctly) the deprecation timeline can be accelerated specifically for that case. From petri at digip.org Mon Nov 28 14:36:03 2011 From: petri at digip.org (Petri Lehtinen) Date: Mon, 28 Nov 2011 15:36:03 +0200 Subject: [Python-Dev] Deprecation policy In-Reply-To: <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> Message-ID: <20111128133603.GD32511@p16> Raymond Hettinger wrote: > How about we agree that actually removing things is usually bad for users. > It will be best if the core devs had a strong aversion to removal. > Instead, it is best to mark APIs as obsolete with a recommendation to use > something else instead. > > There is rarely a need to actually remove support for something in > the standard library. > > That may serve a notion of tidyness or somesuch but in reality it is > a PITA for users making it more difficult to upgrade python versions > and making it more difficult to use published recipes. I'm strongly against breaking backwards compatiblity between minor versions (e.g. 3.2 and 3.3). If something is removed in this manner, the transition period should at least be very, very long. To me, deprecating an API means "this code will not get new features and possibly not even (big) fixes". It's important for the long term health of a project to be able to deprecate and eventually remove code that is no longer maintained. So, I think we should have a clear and working deprecation policy, and Ezio's suggestion sounds good to me. There should be a clean way to state, in both code and documentation, that something is deprecated, do not use in new code. Furthermore, deprecated code should actually be removed when the time comes, be it Python 4.0 or something else. Petri From barry at python.org Mon Nov 28 14:53:44 2011 From: barry at python.org (Barry Warsaw) Date: Mon, 28 Nov 2011 08:53:44 -0500 Subject: [Python-Dev] Deprecation policy In-Reply-To: <20111128133603.GD32511@p16> References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> <20111128133603.GD32511@p16> Message-ID: <20111128085344.012bf983@resist.wooz.org> On Nov 28, 2011, at 03:36 PM, Petri Lehtinen wrote: >Raymond Hettinger wrote: >> That may serve a notion of tidyness or somesuch but in reality it is >> a PITA for users making it more difficult to upgrade python versions >> and making it more difficult to use published recipes. > >I'm strongly against breaking backwards compatiblity between minor >versions (e.g. 3.2 and 3.3). If something is removed in this manner, >the transition period should at least be very, very long. +1 It's even been a pain when porting between Python 2.x and 3. You'll see some things that were carried forward into Python 3.0 and 3.1 but are now gone in 3.2. So if you port from 2.7 -> 3.2 for example, you'll find a few things missing (the intobject.h aliases come to mind). For those reasons I think we need to be conservative about removing stuff. Once the world is all on Python 3 we can think about removing code. Cheers, -Barry From fuzzyman at voidspace.org.uk Mon Nov 28 15:33:50 2011 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 28 Nov 2011 14:33:50 +0000 Subject: [Python-Dev] Deprecation policy In-Reply-To: <20111128133603.GD32511@p16> References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> <20111128133603.GD32511@p16> Message-ID: <4ED39BCE.5040000@voidspace.org.uk> On 28/11/2011 13:36, Petri Lehtinen wrote: > Raymond Hettinger wrote: >> How about we agree that actually removing things is usually bad for users. >> It will be best if the core devs had a strong aversion to removal. >> Instead, it is best to mark APIs as obsolete with a recommendation to use >> something else instead. >> >> There is rarely a need to actually remove support for something in >> the standard library. >> >> That may serve a notion of tidyness or somesuch but in reality it is >> a PITA for users making it more difficult to upgrade python versions >> and making it more difficult to use published recipes. > I'm strongly against breaking backwards compatiblity between minor > versions (e.g. 3.2 and 3.3). If something is removed in this manner, > the transition period should at least be very, very long. We tend to see 3.2 -> 3.3 as a "major version" increment, but that's just Python's terminology. Nonetheless, our usual deprecation policy has been a *minimum* of deprecated for two releases and removed in a third (if at all) - which is about five years from deprecation to removal given our normal release rate. The water is muddied by Python 3, where we may deprecate something in Python 3.1 and remove in 3.3 (hypothetically) - but users may go straight from Python 2.7 to 3.3 and skip the deprecation period altogether... So we should be extra conservative about removals in Python 3 (for the moment at least). > To me, deprecating an API means "this code will not get new features > and possibly not even (big) fixes". It's important for the long term > health of a project to be able to deprecate and eventually remove code > that is no longer maintained. The issue is that deprecated code can still be a maintenance burden. Keeping deprecated APIs around can require effort just to keep them working and may actively *prevent* other changes / improvements. All the best, Michael Foord > So, I think we should have a clear and working deprecation policy, and > Ezio's suggestion sounds good to me. There should be a clean way to > state, in both code and documentation, that something is deprecated, > do not use in new code. Furthermore, deprecated code should actually > be removed when the time comes, be it Python 4.0 or something else. > > Petri > _______________________________________________ > 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 > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From anacrolix at gmail.com Mon Nov 28 15:38:18 2011 From: anacrolix at gmail.com (Matt Joiner) Date: Tue, 29 Nov 2011 01:38:18 +1100 Subject: [Python-Dev] Deprecation policy In-Reply-To: <4ED37B36.7080208@pearwood.info> References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> <4ED37B36.7080208@pearwood.info> Message-ID: On Mon, Nov 28, 2011 at 11:14 PM, Steven D'Aprano wrote: > Xavier Morel wrote: > >> Not being too eager to kill APIs is good, but giving rise to this kind of >> living-dead APIs is no better in my opinion, even more so since Python has >> lost one of the few tools it had to manage them (as DeprecationWarning was >> silenced by default). Both choices are harmful to users, but in the long >> run I do think zombie APIs are worse. > > I would much rather have my code relying on "zombie" APIs and keep working, > than to have that code suddenly stop working when the zombie is removed. > Working code should stay working. Unless the zombie is actively harmful, > what's the big deal if there is a newer, better way of doing something? If > it works, and if it's fast enough, why force people to "fix" it? > > It is a good thing that code or tutorials from Python 1.5 still (mostly) > work, even when there are newer, better ways of doing something. I see a lot > of newbies, and the frustration they suffer when they accidentally > (carelessly) try following 2.x instructions in Python3, or vice versa, is > great. It's bad enough (probably unavoidable) that this happens during a > major transition like 2 to 3, without it also happening during minor > releases. > > Unless there is a good reason to actively remove an API, it should stay as > long as possible. "I don't like this and it should go" is not a good reason, > nor is "but there's a better way you should use". When in doubt, please > don't break people's code. This is a great argument. But people want to see new, bigger better things in the standard library, and the #1 reason cited against this is "we already have too much". I think that's where the issue lies: Either lots of cool nice stuff is added and supported (we all want our favourite things in the standard lib for this reason), and or the old stuff lingers... I'm sure a while ago there was mention of a "staging" area for inclusion in the standard library. This attracts interest, stabilization, and quality from potential modules for inclusion. Better yet, the existing standard library ownership is somehow detached from the CPython core, so that changes enabling easier customization to fit other implementations (jpython, pypy etc.) are possible. tl;dr old stuff blocks new hotness. make room or separate standard library concerns from cpython > > > > -- > Steven > _______________________________________________ > 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/anacrolix%40gmail.com > From brett at python.org Mon Nov 28 16:11:57 2011 From: brett at python.org (Brett Cannon) Date: Mon, 28 Nov 2011 10:11:57 -0500 Subject: [Python-Dev] PyPy 1.7 - widening the sweet spot In-Reply-To: <20111125183746.45ab20b5@pitrou.net> References: <6F9490B9-DBEF-4CF6-89B7-26EA0C8A88E2@underboss.org> <20111125183746.45ab20b5@pitrou.net> Message-ID: On Fri, Nov 25, 2011 at 12:37, Antoine Pitrou wrote: > On Fri, 25 Nov 2011 12:37:59 -0500 > Brett Cannon wrote: > > On Thu, Nov 24, 2011 at 07:46, Nick Coghlan wrote: > > > > > On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski > > > > wrote: > > > > The problem is not with maintaining the modified directory. The > > > > problem was always things like changing interface between the C > > > > version and the Python version or introduction of new stuff that does > > > > not run on pypy because it relies on refcounting. I don't see how > > > > having a subrepo helps here. > > > > > > Indeed, the main thing that can help on this front is to get more > > > modules to the same state as heapq, io, datetime (and perhaps a few > > > others that have slipped my mind) where the CPython repo actually > > > contains both C and Python implementations and the test suite > > > exercises both to make sure their interfaces remain suitably > > > consistent (even though, during normal operation, CPython users will > > > only ever hit the C accelerated version). > > > > > > This not only helps other implementations (by keeping a Python version > > > of the module continuously up to date with any semantic changes), but > > > can help people that are porting CPython to new platforms: the C > > > extension modules are far more likely to break in that situation than > > > the pure Python equivalents, and a relatively slow fallback is often > > > going to be better than no fallback at all. (Note that ctypes based > > > pure Python modules *aren't* particularly useful for this purpose, > > > though - due to the libffi dependency, ctypes is one of the extension > > > modules most likely to break when porting). > > > > > > > And the other reason I plan to see this through before I die > > Uh! Any bad news? :/ Sorry, turn of phrase in English which didn't translate well. I just meant "when I get to it, which could quite possibly be a *long* time from now". This year has been absolutely insane for me personally (if people care, the details are shared on Google+ or you can just ask me), so I am just not promising anything for Python on a short timescale (although I'm still hoping the final details for bootstrapping importlib won't be difficult to work out so I can meet a personal deadline of PyCon). -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at xemacs.org Mon Nov 28 16:19:50 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 29 Nov 2011 00:19:50 +0900 Subject: [Python-Dev] Deprecation policy In-Reply-To: References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> <4ED37B36.7080208@pearwood.info> Message-ID: <874nxop949.fsf@uwakimon.sk.tsukuba.ac.jp> Matt Joiner writes: > This is a great argument. But people want to see new, bigger better > things in the standard library, and the #1 reason cited against this > is "we already have too much". I think that's where the issue lies: > Either lots of cool nice stuff is added and supported (we all want our > favourite things in the standard lib for this reason), and or the old > stuff lingers... Deprecated features are pretty much irrelevant to the height of the bar for new features. The problem is that there are a limited number of folks doing long term maintenance of the standard library, and an essentially unlimited supply of one-off patches to add cool new features (not backed by a long term warranty of maintenance by the contributor). So deprecated features do add some burden of maintenance for the core developers, as Michael points out -- but removing *all* of them on short notice would not really make it possible to *add* features *in a maintainable way* any faster. > I'm sure a while ago there was mention of a "staging" area for > inclusion in the standard library. This attracts interest, > stabilization, and quality from potential modules for inclusion. But there's no particular reason to believe it will attract more contributors willing to do long-term maintenance, and *somebody* has to maintain the staging area. From solipsis at pitrou.net Mon Nov 28 16:46:23 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 28 Nov 2011 16:46:23 +0100 Subject: [Python-Dev] New features References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> <4ED37B36.7080208@pearwood.info> <874nxop949.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20111128164623.1fcc8835@pitrou.net> On Tue, 29 Nov 2011 00:19:50 +0900 "Stephen J. Turnbull" wrote: > > Deprecated features are pretty much irrelevant to the height of the > bar for new features. The problem is that there are a limited number > of folks doing long term maintenance of the standard library, and an > essentially unlimited supply of one-off patches to add cool new > features (not backed by a long term warranty of maintenance by the > contributor). Actually, we don't often get patches for new features. Many new features are implemented by core developers themselves. Regards Antoine. From stephen at xemacs.org Mon Nov 28 18:19:58 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 29 Nov 2011 02:19:58 +0900 Subject: [Python-Dev] New features In-Reply-To: <20111128164623.1fcc8835@pitrou.net> References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> <4ED37B36.7080208@pearwood.info> <874nxop949.fsf@uwakimon.sk.tsukuba.ac.jp> <20111128164623.1fcc8835@pitrou.net> Message-ID: <8739d8p3k1.fsf@uwakimon.sk.tsukuba.ac.jp> Antoine Pitrou writes: > Actually, we don't often get patches for new features. Many new > features are implemented by core developers themselves. Right. That's not inconsistent with what I wrote, as long as would-be feature submitters realize what the standards for an acceptable feature patch are. From solipsis at pitrou.net Mon Nov 28 18:37:24 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 28 Nov 2011 18:37:24 +0100 Subject: [Python-Dev] Deprecation policy References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> Message-ID: <20111128183724.1a50a0ee@pitrou.net> Hi, On Mon, 28 Nov 2011 01:30:53 -0800 Raymond Hettinger wrote: > > On Oct 24, 2011, at 5:58 AM, Ezio Melotti wrote: > > > Hi, > > our current deprecation policy is not so well defined (see e.g. [0]), and it seems to me that it's something like: > > 1) deprecate something and add a DeprecationWarning; > > 2) forget about it after a while; > > 3) wait a few versions until someone notices it; > > 4) actually remove it; > > > > I suggest to follow the following process: > > 1) deprecate something and add a DeprecationWarning; > > 2) decide how long the deprecation should last; > > 3) use the deprecated-remove[1] directive to document it; > > 4) add a test that fails after the update so that we remember to remove it[2]; > > How about we agree that actually removing things is usually bad for users. > It will be best if the core devs had a strong aversion to removal. Well, it's not like we aren't already conservative in deprecating things. > Instead, it is best to mark APIs as obsolete with a recommendation to use something else instead. > There is rarely a need to actually remove support for something in the standard library. > That may serve a notion of tidyness or somesuch but in reality it is a PITA for users making it more difficult to upgrade python versions and making it more difficult to use published recipes. I agree with Xavier's answer that having recipes around which use outdated (and possibly inefficient/insecure/etc.) APIs is a nuisance. Also, deprecated-but-not-removed APIs come at a maintenance and support cost. Regards Antoine. From jcea at jcea.es Mon Nov 28 21:47:55 2011 From: jcea at jcea.es (Jesus Cea) Date: Mon, 28 Nov 2011 21:47:55 +0100 Subject: [Python-Dev] Long term development external named branches and periodic merges from python In-Reply-To: References: <4ECE741F.10303@jcea.es> <4ECE7A25.5000701@netwok.org> <4ECEFFD4.5030601@jcea.es> <4ED1141E.9050604@netwok.org> <4ED30C3E.4090700@jcea.es> Message-ID: <4ED3F37B.4030103@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/11/11 06:06, Nick Coghlan wrote: >> So, in this context, if the tracker "create patch" diff from >> BASE, it is not "safe" to merge changes from mainline to the >> branch, because if so "create patch" would include code not >> related to my work. > > No, "Create Patch" is smarter than that. What it does (or tries to > do) is walk back through your branch history, trying to find the > last point where you merged in a changeset that it recognises as > coming from the main CPython repo. It then uses that revision of > the CPython repo as the basis for the diff. Oh, that sounds quite the right way. Clever. > So if you're just working on a feature branch, periodically > pulling from hg.python.org/cpython and merging from default, then > it should all work fine. So, my original question is answered as "yes, you can merge in changes from mainline, and 'create patch' will work as it should". Good!!. Thanks!!!. >> Anybody knows the mercurial command used to implement "create >> patch"?. > > It's not a single command - it's a short script MvL wrote that > uses the Mercurial API to traverse the branch history and find an > appropriate revision to diff against. Publish out somewhere would be useful, I guess. This is a problem I have found in a few other projects. I can see even a modifier for "hg diff" for a future mercurial version :-). Could be implemented as a command line command using "revsets"?. Propose a new revset to mercurial devels? - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTtPze5lgi5GaxT1NAQIT9gP+N4urbw7TgCWTa7EFZ4rjj7/o9f3aBq4I kYBnVZGmh98YqjHL0MzHhhu2a+G6pC/Zksf9CyIinPol4DJR8zGhBDIxo6SNIja+ QsSyQ7DhBWkSwKZAKqBNSdBBH0fu/DpdmNv6fP0s04Ju6sllvHAbEN/oj9zWqxWM KjAMzrgPcSA= =zViH -----END PGP SIGNATURE----- From ncoghlan at gmail.com Mon Nov 28 22:00:28 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 29 Nov 2011 07:00:28 +1000 Subject: [Python-Dev] Long term development external named branches and periodic merges from python In-Reply-To: <4ED3F37B.4030103@jcea.es> References: <4ECE741F.10303@jcea.es> <4ECE7A25.5000701@netwok.org> <4ECEFFD4.5030601@jcea.es> <4ED1141E.9050604@netwok.org> <4ED30C3E.4090700@jcea.es> <4ED3F37B.4030103@jcea.es> Message-ID: It's published as part of the tracker repo, although I'm not sure exactly where it lives. -- Nick Coghlan (via Gmail on Android, so likely to be more terse than usual) On Nov 29, 2011 6:50 AM, "Jesus Cea" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 28/11/11 06:06, Nick Coghlan wrote: > >> So, in this context, if the tracker "create patch" diff from > >> BASE, it is not "safe" to merge changes from mainline to the > >> branch, because if so "create patch" would include code not > >> related to my work. > > > > No, "Create Patch" is smarter than that. What it does (or tries to > > do) is walk back through your branch history, trying to find the > > last point where you merged in a changeset that it recognises as > > coming from the main CPython repo. It then uses that revision of > > the CPython repo as the basis for the diff. > > Oh, that sounds quite the right way. Clever. > > > So if you're just working on a feature branch, periodically > > pulling from hg.python.org/cpython and merging from default, then > > it should all work fine. > > So, my original question is answered as "yes, you can merge in changes > from mainline, and 'create patch' will work as it should". > > Good!!. Thanks!!!. > > >> Anybody knows the mercurial command used to implement "create > >> patch"?. > > > > It's not a single command - it's a short script MvL wrote that > > uses the Mercurial API to traverse the branch history and find an > > appropriate revision to diff against. > > Publish out somewhere would be useful, I guess. This is a problem I > have found in a few other projects. I can see even a modifier for "hg > diff" for a future mercurial version :-). > > Could be implemented as a command line command using "revsets"?. > Propose a new revset to mercurial devels? > > - -- > Jesus Cea Avion _/_/ _/_/_/ _/_/_/ > jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ > jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ > . _/_/ _/_/ _/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQCVAwUBTtPze5lgi5GaxT1NAQIT9gP+N4urbw7TgCWTa7EFZ4rjj7/o9f3aBq4I > kYBnVZGmh98YqjHL0MzHhhu2a+G6pC/Zksf9CyIinPol4DJR8zGhBDIxo6SNIja+ > QsSyQ7DhBWkSwKZAKqBNSdBBH0fu/DpdmNv6fP0s04Ju6sllvHAbEN/oj9zWqxWM > KjAMzrgPcSA= > =zViH > -----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/ncoghlan%40gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petri at digip.org Tue Nov 29 13:46:06 2011 From: petri at digip.org (Petri Lehtinen) Date: Tue, 29 Nov 2011 14:46:06 +0200 Subject: [Python-Dev] Deprecation policy In-Reply-To: <4ED39BCE.5040000@voidspace.org.uk> References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> <20111128133603.GD32511@p16> <4ED39BCE.5040000@voidspace.org.uk> Message-ID: <20111129124606.GC21346@p16> Michael Foord wrote: > We tend to see 3.2 -> 3.3 as a "major version" increment, but that's > just Python's terminology. Even though (in the documentation) Python's version number components are called major, minor, micro, releaselevel and serial, in this order? So when the minor version component is increased it's a major version increment? :) From petri at digip.org Tue Nov 29 13:58:39 2011 From: petri at digip.org (Petri Lehtinen) Date: Tue, 29 Nov 2011 14:58:39 +0200 Subject: [Python-Dev] Long term development external named branches and periodic merges from python In-Reply-To: References: <4ECE741F.10303@jcea.es> <4ECE7A25.5000701@netwok.org> <4ECEFFD4.5030601@jcea.es> <4ED1141E.9050604@netwok.org> <4ED30C3E.4090700@jcea.es> Message-ID: <20111129125839.GD21346@p16> Nick Coghlan wrote: > > So, in this context, if the tracker "create patch" diff from BASE, it > > is not "safe" to merge changes from mainline to the branch, because if > > so "create patch" would include code not related to my work. > > No, "Create Patch" is smarter than that. What it does (or tries to do) > is walk back through your branch history, trying to find the last > point where you merged in a changeset that it recognises as coming > from the main CPython repo. It then uses that revision of the CPython > repo as the basis for the diff. > > So if you're just working on a feature branch, periodically pulling > from hg.python.org/cpython and merging from default, then it should > all work fine. > > Branches-of-branches (i.e. where you've merged from CPython via > another named branch in your local repo) seems to confuse it though - > I plan to change my workflow for those cases to merge each branch from > the same version of default before merging from the other branch. The ancestor() revset could help for the confusion: http://stackoverflow.com/a/6744163/639276 In this case, the user would have to be able to tell the branch against which he wants the diff. Petri From solipsis at pitrou.net Tue Nov 29 13:59:48 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 29 Nov 2011 13:59:48 +0100 Subject: [Python-Dev] Deprecation policy References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> <20111128133603.GD32511@p16> <4ED39BCE.5040000@voidspace.org.uk> <20111129124606.GC21346@p16> Message-ID: <20111129135948.23a2e5cc@pitrou.net> On Tue, 29 Nov 2011 14:46:06 +0200 Petri Lehtinen wrote: > Michael Foord wrote: > > We tend to see 3.2 -> 3.3 as a "major version" increment, but that's > > just Python's terminology. > > Even though (in the documentation) Python's version number components > are called major, minor, micro, releaselevel and serial, in this > order? So when the minor version component is increased it's a major > version increment? :) Well, that's why I think the version number components are not correctly named. I don't think any of the 2.x or 3.x releases can be called "minor" by any stretch of the word. A quick glance at http://docs.python.org/dev/whatsnew/index.html should be enough. Regards Antoine. From phd at phdru.name Tue Nov 29 13:53:58 2011 From: phd at phdru.name (Oleg Broytman) Date: Tue, 29 Nov 2011 16:53:58 +0400 Subject: [Python-Dev] Deprecation policy In-Reply-To: <20111129124606.GC21346@p16> References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> <20111128133603.GD32511@p16> <4ED39BCE.5040000@voidspace.org.uk> <20111129124606.GC21346@p16> Message-ID: <20111129125358.GA7839@iskra.aviel.ru> On Tue, Nov 29, 2011 at 02:46:06PM +0200, Petri Lehtinen wrote: > Michael Foord wrote: > > We tend to see 3.2 -> 3.3 as a "major version" increment, but that's > > just Python's terminology. > > Even though (in the documentation) Python's version number components > are called major, minor, micro, releaselevel and serial, in this > order? So when the minor version component is increased it's a major > version increment? :) When the major version component is increased it's a World Shattering Change, isn't it?! ;-) Oleg. -- Oleg Broytman http://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From barry at python.org Tue Nov 29 16:13:06 2011 From: barry at python.org (Barry Warsaw) Date: Tue, 29 Nov 2011 10:13:06 -0500 Subject: [Python-Dev] Deprecation policy In-Reply-To: <20111129135948.23a2e5cc@pitrou.net> References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> <20111128133603.GD32511@p16> <4ED39BCE.5040000@voidspace.org.uk> <20111129124606.GC21346@p16> <20111129135948.23a2e5cc@pitrou.net> Message-ID: <20111129101306.08a931b9@resist.wooz.org> On Nov 29, 2011, at 01:59 PM, Antoine Pitrou wrote: >Well, that's why I think the version number components are not >correctly named. I don't think any of the 2.x or 3.x releases can be >called "minor" by any stretch of the word. A quick glance at >http://docs.python.org/dev/whatsnew/index.html should be enough. Agreed, but it's too late to change it. I look at it as the attributes of the namedtuple being evocative of the traditional names for the digit positions, not the assignment of those positions to Python's semantics. -Barry From g.brandl at gmx.net Tue Nov 29 19:28:40 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Tue, 29 Nov 2011 19:28:40 +0100 Subject: [Python-Dev] Deprecation policy In-Reply-To: <20111129124606.GC21346@p16> References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> <20111128133603.GD32511@p16> <4ED39BCE.5040000@voidspace.org.uk> <20111129124606.GC21346@p16> Message-ID: Am 29.11.2011 13:46, schrieb Petri Lehtinen: > Michael Foord wrote: >> We tend to see 3.2 -> 3.3 as a "major version" increment, but that's >> just Python's terminology. > > Even though (in the documentation) Python's version number components > are called major, minor, micro, releaselevel and serial, in this > order? So when the minor version component is increased it's a major > version increment? :) Yes. Georg From nadeem.vawda at gmail.com Tue Nov 29 23:59:11 2011 From: nadeem.vawda at gmail.com (Nadeem Vawda) Date: Wed, 30 Nov 2011 00:59:11 +0200 Subject: [Python-Dev] LZMA support has landed Message-ID: Hey folks, I'm pleased to announce that as of changeset 74d182cf0187, the standard library now includes support for the LZMA compression algorithm (as well as the associated .xz and .lzma file formats). The new lzma module has a very similar API to the existing bz2 module; it should serve as a drop-in replacement for most use cases. If anyone has any feedback or any suggestions for improvement, please let me know. I'd like to ask the owners of (non-Windows) buildbots to install the XZ Utils development headers so that they can build the new module. For Debian-derived Linux distros, the relevant package is named "liblzma-dev"; on Fedora I believe the correct package is "xz-devel". Binaries for OS X are available from the project's homepage at . Finally, a big thanks to everyone who contributed feedback during this module's development! Cheers, Nadeem From solipsis at pitrou.net Wed Nov 30 00:07:00 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 30 Nov 2011 00:07:00 +0100 Subject: [Python-Dev] cpython: Issue #6715: Add module for compression using the LZMA algorithm. References: Message-ID: <20111130000700.56e9c9bc@pitrou.net> On Tue, 29 Nov 2011 23:36:58 +0100 nadeem.vawda wrote: > http://hg.python.org/cpython/rev/74d182cf0187 > changeset: 73794:74d182cf0187 > user: Nadeem Vawda > date: Wed Nov 30 00:25:06 2011 +0200 > summary: > Issue #6715: Add module for compression using the LZMA algorithm. Congratulations, Nadeem! Regards Antoine. From amauryfa at gmail.com Wed Nov 30 00:34:49 2011 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Wed, 30 Nov 2011 00:34:49 +0100 Subject: [Python-Dev] LZMA support has landed In-Reply-To: References: Message-ID: 2011/11/29 Nadeem Vawda > I'm pleased to announce that as of changeset 74d182cf0187, the > standard library now includes support for the LZMA compression > algorithm Congratulations! > I'd like to ask the owners of (non-Windows) buildbots to install the > XZ Utils development headers so that they can build the new module. > And don't worry about Windows builbots, they will automatically download the XZ prebuilt binaries from the usual place. (svn export http://svn.python.org/projects/external/xz-5.0.3) Next step: add support for tar.xz files (issue5689)... -- Amaury Forgeot d'Arc -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Wed Nov 30 00:45:19 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 30 Nov 2011 09:45:19 +1000 Subject: [Python-Dev] Deprecation policy In-Reply-To: <20111129101306.08a931b9@resist.wooz.org> References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> <20111128133603.GD32511@p16> <4ED39BCE.5040000@voidspace.org.uk> <20111129124606.GC21346@p16> <20111129135948.23a2e5cc@pitrou.net> <20111129101306.08a931b9@resist.wooz.org> Message-ID: On Wed, Nov 30, 2011 at 1:13 AM, Barry Warsaw wrote: > On Nov 29, 2011, at 01:59 PM, Antoine Pitrou wrote: > >>Well, that's why I think the version number components are not >>correctly named. I don't think any of the 2.x or 3.x releases can be >>called "minor" by any stretch of the word. A quick glance at >>http://docs.python.org/dev/whatsnew/index.html should be enough. > > Agreed, but it's too late to change it. ?I look at it as the attributes of the > namedtuple being evocative of the traditional names for the digit positions, > not the assignment of those positions to Python's semantics. Hmm, I wonder about that. Perhaps we could add a second set of names in parallel with the "major.minor.micro" names: "series.feature.maint". That would, after all, reflect what is actually said in practice: - release series: 2.x, 3.x (usually used in a form like "In the 3.x series, X is true. In 2.x, Y is true) - feature release: 2.7, 3.2, etc - maintenance release: 2.7.2, 3.2.1, etc I know I tend to call feature releases major releases and I'm far from alone in that. The discrepancy in relation to sys.version_info is confusing, but we can't make 'major' refer to a different field without breaking existing programs. But we *can* change: >>> sys.version_info sys.version_info(major=2, minor=7, micro=2, releaselevel='final', serial=0) to instead read: sys.version_info(series=2, feature=7, maint=2, releaselevel='final', serial=0) while allowing 'major' as an alias of 'series', 'minor' as an alias of 'feature' and 'micro' as an alias of 'maint'. Nothing breaks, and we'd have started down the path towards coherent terminology for the three fields in the version numbers (by accepting that 'major' has now become irredeemably ambiguous in the context of CPython releases). This idea of renaming all three fields has come up before, but I believe we got stuck on the question of what to call the first number (i.e. the one I'm calling the "series" here). Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From benjamin at python.org Wed Nov 30 01:00:45 2011 From: benjamin at python.org (Benjamin Peterson) Date: Tue, 29 Nov 2011 19:00:45 -0500 Subject: [Python-Dev] Deprecation policy In-Reply-To: References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> <20111128133603.GD32511@p16> <4ED39BCE.5040000@voidspace.org.uk> <20111129124606.GC21346@p16> <20111129135948.23a2e5cc@pitrou.net> <20111129101306.08a931b9@resist.wooz.org> Message-ID: 2011/11/29 Nick Coghlan : > On Wed, Nov 30, 2011 at 1:13 AM, Barry Warsaw wrote: >> On Nov 29, 2011, at 01:59 PM, Antoine Pitrou wrote: >> >>>Well, that's why I think the version number components are not >>>correctly named. I don't think any of the 2.x or 3.x releases can be >>>called "minor" by any stretch of the word. A quick glance at >>>http://docs.python.org/dev/whatsnew/index.html should be enough. >> >> Agreed, but it's too late to change it. ?I look at it as the attributes of the >> namedtuple being evocative of the traditional names for the digit positions, >> not the assignment of those positions to Python's semantics. > > Hmm, I wonder about that. Perhaps we could add a second set of names > in parallel with the "major.minor.micro" names: > "series.feature.maint". > > That would, after all, reflect what is actually said in practice: > - release series: 2.x, 3.x ?(usually used in a form like "In the 3.x > series, X is true. In 2.x, Y is true) > - feature release: 2.7, 3.2, etc > - maintenance release: 2.7.2, 3.2.1, etc > > I know I tend to call feature releases major releases and I'm far from > alone in that. The discrepancy in relation to sys.version_info is > confusing, but we can't make 'major' refer to a different field > without breaking existing programs. But we *can* change: > >>>> sys.version_info > sys.version_info(major=2, minor=7, micro=2, releaselevel='final', serial=0) > > to instead read: > > sys.version_info(series=2, feature=7, maint=2, releaselevel='final', serial=0) > > while allowing 'major' as an alias of 'series', 'minor' as an alias of > 'feature' and 'micro' as an alias of 'maint'. Nothing breaks, and we'd > have started down the path towards coherent terminology for the three > fields in the version numbers (by accepting that 'major' has now > become irredeemably ambiguous in the context of CPython releases). > > This idea of renaming all three fields has come up before, but I > believe we got stuck on the question of what to call the first number > (i.e. the one I'm calling the "series" here). Can we drop this now? Too much effort for very little benefit. We call releases what we call releases. -- Regards, Benjamin From anacrolix at gmail.com Wed Nov 30 06:26:27 2011 From: anacrolix at gmail.com (Matt Joiner) Date: Wed, 30 Nov 2011 16:26:27 +1100 Subject: [Python-Dev] Deprecation policy In-Reply-To: References: <4EA560E3.8060307@gmail.com> <9D996A31-5968-4485-B953-4961B8623DB8@gmail.com> <20111128133603.GD32511@p16> <4ED39BCE.5040000@voidspace.org.uk> <20111129124606.GC21346@p16> <20111129135948.23a2e5cc@pitrou.net> <20111129101306.08a931b9@resist.wooz.org> Message-ID: I like this article on it: http://semver.org/ The following snippets being relevant here: Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. With the exception of actually dropping stuff (however this only occurs in terms of modules, which hardly count in special cases?), Python already conforms to this standard very well. On Wed, Nov 30, 2011 at 11:00 AM, Benjamin Peterson wrote: > 2011/11/29 Nick Coghlan : >> On Wed, Nov 30, 2011 at 1:13 AM, Barry Warsaw wrote: >>> On Nov 29, 2011, at 01:59 PM, Antoine Pitrou wrote: >>> >>>>Well, that's why I think the version number components are not >>>>correctly named. I don't think any of the 2.x or 3.x releases can be >>>>called "minor" by any stretch of the word. A quick glance at >>>>http://docs.python.org/dev/whatsnew/index.html should be enough. >>> >>> Agreed, but it's too late to change it. ?I look at it as the attributes of the >>> namedtuple being evocative of the traditional names for the digit positions, >>> not the assignment of those positions to Python's semantics. >> >> Hmm, I wonder about that. Perhaps we could add a second set of names >> in parallel with the "major.minor.micro" names: >> "series.feature.maint". >> >> That would, after all, reflect what is actually said in practice: >> - release series: 2.x, 3.x ?(usually used in a form like "In the 3.x >> series, X is true. In 2.x, Y is true) >> - feature release: 2.7, 3.2, etc >> - maintenance release: 2.7.2, 3.2.1, etc >> >> I know I tend to call feature releases major releases and I'm far from >> alone in that. The discrepancy in relation to sys.version_info is >> confusing, but we can't make 'major' refer to a different field >> without breaking existing programs. But we *can* change: >> >>>>> sys.version_info >> sys.version_info(major=2, minor=7, micro=2, releaselevel='final', serial=0) >> >> to instead read: >> >> sys.version_info(series=2, feature=7, maint=2, releaselevel='final', serial=0) >> >> while allowing 'major' as an alias of 'series', 'minor' as an alias of >> 'feature' and 'micro' as an alias of 'maint'. Nothing breaks, and we'd >> have started down the path towards coherent terminology for the three >> fields in the version numbers (by accepting that 'major' has now >> become irredeemably ambiguous in the context of CPython releases). >> >> This idea of renaming all three fields has come up before, but I >> believe we got stuck on the question of what to call the first number >> (i.e. the one I'm calling the "series" here). > > Can we drop this now? Too much effort for very little benefit. We call > releases what we call releases. > > > > -- > Regards, > Benjamin > _______________________________________________ > 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/anacrolix%40gmail.com From anacrolix at gmail.com Wed Nov 30 06:28:54 2011 From: anacrolix at gmail.com (Matt Joiner) Date: Wed, 30 Nov 2011 16:28:54 +1100 Subject: [Python-Dev] LZMA support has landed In-Reply-To: References: Message-ID: Congrats, this is an excellent feature. On Wed, Nov 30, 2011 at 10:34 AM, Amaury Forgeot d'Arc wrote: > 2011/11/29 Nadeem Vawda >> >> I'm pleased to announce that as of changeset 74d182cf0187, the >> standard library now includes support for the LZMA compression >> algorithm > > > Congratulations! > >> >> I'd like to ask the owners of (non-Windows) buildbots to install the >> XZ Utils development headers so that they can build the new module. > > > And don't worry about Windows builbots, they will automatically download > the XZ prebuilt?binaries from the usual place. > (svn export http://svn.python.org/projects/external/xz-5.0.3) > > Next step: add support for tar.xz files (issue5689)... > > -- > 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/anacrolix%40gmail.com > From meadori at gmail.com Wed Nov 30 06:50:26 2011 From: meadori at gmail.com (Meador Inge) Date: Tue, 29 Nov 2011 23:50:26 -0600 Subject: [Python-Dev] LZMA support has landed In-Reply-To: References: Message-ID: On Tue, Nov 29, 2011 at 4:59 PM, Nadeem Vawda wrote: > "liblzma-dev"; on Fedora I believe the correct package is "xz-devel". "xz-devel" is right. I just verified a build of the new module on a fresh F16 system. -- Meador From martin at v.loewis.de Wed Nov 30 09:01:55 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 30 Nov 2011 09:01:55 +0100 Subject: [Python-Dev] Long term development external named branches and periodic merges from python In-Reply-To: <4ED3F37B.4030103@jcea.es> References: <4ECE741F.10303@jcea.es> <4ECE7A25.5000701@netwok.org> <4ECEFFD4.5030601@jcea.es> <4ED1141E.9050604@netwok.org> <4ED30C3E.4090700@jcea.es> <4ED3F37B.4030103@jcea.es> Message-ID: <4ED5E2F3.4050200@v.loewis.de> > Could be implemented as a command line command using "revsets"?. > Propose a new revset to mercurial devels? It *is* implemented as a command line command using "revsets". The revset is max(ancestors(branch("%s")))-outgoing("%s")) where the first parameter is the branch that contains your changes, and the second one is the "path" of the repository you want to diff against. In English: find the most recent revision in the ancestry of your branch that is not an outgoing change wrt. the base repository. ancestors(branch(yours)) gives all revisions preceding your branches' tip, which will be your own changes, plus all changes from the "default" branch that have been merged into your branch (including the changes from where you originally forked the branch). Subtracting outgoing removes all changes that are not yet in cpython, leaving only the changes in your ancestry that come from cpython. max() then finds the most recent such change, which will be the "default" parent of your last merge, or the branch point if you haven't merged after branching. HTH, Martin From anacrolix at gmail.com Wed Nov 30 15:31:14 2011 From: anacrolix at gmail.com (Matt Joiner) Date: Thu, 1 Dec 2011 01:31:14 +1100 Subject: [Python-Dev] STM and python Message-ID: Given GCC's announcement that Intel's STM will be an extension for C and C++ in GCC 4.7, what does this mean for Python, and the GIL? I've seen efforts made to make STM available as a context, and for use in user code. I've also read about the "old attempts way back" that attempted to use finer grain locking. The understandably failed due to the heavy costs involved in both the locking mechanisms used, and the overhead of a reference counting garbage collection system. However given advances in locking and garbage collection in the last decade, what attempts have been made recently to try these new ideas out? In particular, how unlikely is it that all the thread safe primitives, global contexts, and reference counting functions be made __transaction_atomic, and magical parallelism performance boosts ensue? I'm aware that C89, platforms without STM/GCC, and single threaded performance are concerns. Please ignore these for the sake of discussion about possibilities. http://gcc.gnu.org/wiki/TransactionalMemory http://linux.die.net/man/4/futex From benjamin at python.org Wed Nov 30 16:25:20 2011 From: benjamin at python.org (Benjamin Peterson) Date: Wed, 30 Nov 2011 10:25:20 -0500 Subject: [Python-Dev] STM and python In-Reply-To: References: Message-ID: 2011/11/30 Matt Joiner : > Given GCC's announcement that Intel's STM will be an extension for C > and C++ in GCC 4.7, what does this mean for Python, and the GIL? > > I've seen efforts made to make STM available as a context, and for use > in user code. I've also read about the "old attempts way back" that > attempted to use finer grain locking. The understandably failed due to > the heavy costs involved in both the locking mechanisms used, and the > overhead of a reference counting garbage collection system. > > However given advances in locking and garbage collection in the last > decade, what attempts have been made recently to try these new ideas > out? In particular, how unlikely is it that all the thread safe > primitives, global contexts, and reference counting functions be made > __transaction_atomic, and magical parallelism performance boosts > ensue? Have you seen http://morepypy.blogspot.com/2011/08/we-need-software-transactional-memory.html ? -- Regards, Benjamin From pje at telecommunity.com Wed Nov 30 16:28:32 2011 From: pje at telecommunity.com (PJ Eby) Date: Wed, 30 Nov 2011 10:28:32 -0500 Subject: [Python-Dev] PEP 402: Simplified Package Layout and Partitioning In-Reply-To: <4ED1196E.8090505@netwok.org> References: <4E43E9A6.7020608@netwok.org> <20110811183114.701DF3A406B@sparrow.telecommunity.com> <4ED1196E.8090505@netwok.org> Message-ID: On Sat, Nov 26, 2011 at 11:53 AM, ?ric Araujo wrote: > > Le 11/08/2011 20:30, P.J. Eby a ?crit : > >> At 04:39 PM 8/11/2011 +0200, ?ric Araujo wrote: > >>> I?ll just regret that it's not possible to provide a module docstring > >>> to inform that this is a namespace package used for X and Y. > >> It *is* possible - you'd just have to put it in a "zc.py" file. IOW, > >> this PEP still allows "namespace-defining packages" to exist, as was > >> requested by early commenters on PEP 382. It just doesn't *require* > >> them to exist in order for the namespace contents to be importable. > > That?s quite cool. I guess such a namespace-defining module (zc.py > here) would be importable, right? Yes. > Also, would it cause worse > performance for other zc.* packages than if there were no zc.py? > No. The first import of a subpackage sets up the __path__, and all subsequent imports use it. > >>> A pure virtual package having no source file, I think it should have no >>> __file__ at all. > > Antoine and someone else thought likewise (I can find the link if you > want); do you consider it consensus enough to update the PEP? > Sure. At this point, though, before doing any more work on the PEP I'd like to have some idea of whether there's any chance of it being accepted. At this point, there seems to be a lot of passive, "Usenet nod syndrome" type support for it, but little active support. It doesn't help at all that I'm not really in a position to provide an implementation, and the persons most likely to implement have been leaning somewhat towards 382, or wanting to modify 402 such that it uses .pyp directory extensions so that PEP 395 can be supported... And while 402 is an extension of an idea that Guido proposed a few years ago, he hasn't weighed in lately on whether he still likes that idea, let alone whether he likes where I've taken it. ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From neologix at free.fr Wed Nov 30 17:45:07 2011 From: neologix at free.fr (=?ISO-8859-1?Q?Charles=2DFran=E7ois_Natali?=) Date: Wed, 30 Nov 2011 17:45:07 +0100 Subject: [Python-Dev] STM and python In-Reply-To: References: Message-ID: > However given advances in locking and garbage collection in the last > decade, what attempts have been made recently to try these new ideas > out? In particular, how unlikely is it that all the thread safe > primitives, global contexts, and reference counting functions be made > __transaction_atomic, and magical parallelism performance boosts > ensue? > I'd say that given that the current libitm implementation uses a single global lock, you're more likely to see a performance loss. TM is useful to synchronize non-trivial operations: an increment or decrement of a reference count is highly trivial (and expensive when performed atomically, as noted), and TM's never going to help if you put each refcount operation in its own transaction: see Armin's http://morepypy.blogspot.com/2011/08/we-need-software-transactional-memory.html for more realistic use cases. From merwok at netwok.org Wed Nov 30 17:52:17 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Wed, 30 Nov 2011 17:52:17 +0100 Subject: [Python-Dev] PEP 402: Simplified Package Layout and Partitioning In-Reply-To: References: <4E43E9A6.7020608@netwok.org> <20110811183114.701DF3A406B@sparrow.telecommunity.com> <4ED1196E.8090505@netwok.org> Message-ID: <4ED65F41.2000400@netwok.org> Hi, Thanks for the replies. > At this point, though, before doing any more work on the PEP I'd > like to have some idea of whether there's any chance of it being accepted. > At this point, there seems to be a lot of passive, "Usenet nod syndrome" > type support for it, but little active support. If this helps, I am +1, and I?m sure other devs will chime in. I think the feature is useful, and I prefer 402?s way to 382?s pyp directories. I do acknowledge that 402 poses problems to PEP 395 which 382 does not, and as I?m not in a position to help, my vote may count less. Cheers From martin at v.loewis.de Wed Nov 30 18:33:32 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Wed, 30 Nov 2011 18:33:32 +0100 Subject: [Python-Dev] PEP 402: Simplified Package Layout and Partitioning In-Reply-To: <4ED65F41.2000400@netwok.org> References: <4E43E9A6.7020608@netwok.org> <20110811183114.701DF3A406B@sparrow.telecommunity.com> <4ED1196E.8090505@netwok.org> <4ED65F41.2000400@netwok.org> Message-ID: <4ED668EC.3090700@v.loewis.de> > If this helps, I am +1, and I?m sure other devs will chime in. I think > the feature is useful, and I prefer 402?s way to 382?s pyp directories. If that's the obstacle to adopting PEP 382, it would be easy to revert the PEP back to having file markers to indicate package-ness. I insist on having markers of some kind, though (IIUC, this is also what PEP 395 requires). The main problem with file markers is that a) they must not overlap across portions of a package, and b) the actual file name and content is irrelevant. a) means that package authors have to come up with some name, and b) means that the name actually doesn't matter (but the file name extension would). UUIDs would work, as would the name of the portion/distribution. I think the specific choice of name will confuse people into interpreting things in the file name that aren't really intended. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4