Re: [Python-Dev] pydoc for named tuples is missing methods
On 03/14/2011 10:02 PM, James Mills wrote: On Tue, Mar 15, 2011 at 11:50 AM, Terry Reedytjre...@udel.edu wrote: How would that work if you had a field named replace? I think Raymond's current design is as good as it's going to get. 'as_dict' is an unlikely fieldname. 're_place' is too, but that just shift the '_' from '_replace'. No gain. I might prefer _asdict to _as_dict, but not enough to change. Probably a stupid idea (sorry) but one could just make asdict() and replace() public methods with the caveat that developers not use those as field names. The field names are not always under direct control of the developer, such as when they are database column names. Not that using _replace completely gets rid of this problem, but I agree with Raymond's decision that a field name can be any valid identifier not starting with an underscore. It's the simplest thing for the developer using namedtuple. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging
On Tue, Mar 15, 2011 at 10:27 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Maybe this will be the killer app for the or enhancement to the import statement. :-) Except that won't help, since even if it were added right now, pre-3.3 compatible code couldn't use it :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
On Tue, Mar 15, 2011 at 6:20 PM, Eric Smith e...@trueblade.com wrote: The field names are not always under direct control of the developer, such as when they are database column names. Not that using _replace completely gets rid of this problem, but I agree with Raymond's decision that a field name can be any valid identifier not starting with an underscore. It's the simplest thing for the developer using namedtuple. While I actually think the current API design is a decent compromise, another option to consider would be to move the underscore to the *end* (as_dict_, replace_, make_) as is sometimes done for code that needs to avoid conflicting with a keyword. Namespace collisions with actual fields would remain unlikely, while pydoc would pick up the new names correctly. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
In fact, since the deprecation in the Python 2 line happened in 2.7, the deprecation period of this API in practice was between July 3rd 2010 and February 20 2011. That is a deprecation period of somewhat longer than seven months. Nobody obviously though 2.6 was out of practical use by now, so why did you decide to remove one if it's API's? Python 2.6's API wasn't removed in 2.7. It remains available. If you go from 2.7 to 3.2, you should expect things to break. That's why the major version changed. For 3.x, as Reid points out, the API was deprecated in 3.1, so the deprecation period was rather 19 months, not 7. Let's make no bones about this: The PyCObject API should *not* have been removed in 3.2. In fact, the removal should be reversed, and 3.2.1 should be released ASAP, making 3.2 a moot and unsupported version. This change conforms to PEP 5: There must be at least a one-year transition period between the release of the transitional version of Python and the release of the backwards incompatible version. Users will have at least a year to test their programs and migrate them from use of the deprecated construct to the alternative one. If you think a year is too little, you should lobby for a PEP 5 change. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] NetBSD and curses
Would you please post this to bugs.python.org so that it doesn't get lost? thanks! -gps On Mon, Mar 14, 2011 at 8:51 PM, Bill Green b...@supposedly.org wrote: Hi all, I ran across this issue several months ago and filed a bug report (#9667). It just came up again, and it doesn't look like anything's been done with the bug report, so I thought I'd post here. In _cursesmodule.c there are a lot of preprocesser conditionals that test if the system is NetBSD. In my case, the issue was that the module built lacked the KEY_UP / _DOWN / etc. constants, but there are other changes as well. This is the case even if you're compiling against ncurses instead of the system curses. Αttached below is a patch against 2.7.1 that negates the NetBSD conditionals if ncurses is present. It seems to work as expected, although I haven't done any real testing. I assumed this was done because NetBSD curses was missing something, but I looked at the headers and it seems to have most of the constants that the compilation directives are leaving out (A_INVIS, the aforementioned KEY_* constants, at least), so I'm not sure why that code isn't compiled in anyway. Please let me know if I'm misunderstanding this. Thanks, Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging
On Tue, Mar 15, 2011 at 7:50 AM, Nick Coghlan ncogh...@gmail.com wrote: On Tue, Mar 15, 2011 at 10:27 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Maybe this will be the killer app for the or enhancement to the import statement. :-) Except that won't help, since even if it were added right now, pre-3.3 compatible code couldn't use it :) or if you backport it, we could add a new fallback ;) try: from __future__ import or_importer except ImportError: XXX -- previous proposal else: or based proposal Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
On 15/03/2011 07:59, Nick Coghlan wrote: On Tue, Mar 15, 2011 at 6:20 PM, Eric Smithe...@trueblade.com wrote: The field names are not always under direct control of the developer, such as when they are database column names. Not that using _replace completely gets rid of this problem, but I agree with Raymond's decision that a field name can be any valid identifier not starting with an underscore. It's the simplest thing for the developer using namedtuple. While I actually think the current API design is a decent compromise, another option to consider would be to move the underscore to the *end* (as_dict_, replace_, make_) as is sometimes done for code that needs to avoid conflicting with a keyword. Namespace collisions with actual fields would remain unlikely, while pydoc would pick up the new names correctly. Although it's a backwards incompatible change. Teaching pydoc to recognise the private methods isn't. Michael Cheers, Nick. -- 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Fix #11509. Significantly increase test coverage for fileinput.
On Tue, 15 Mar 2011 15:29:59 +0100 brian.curtin python-check...@python.org wrote: + +def test_gz_ext(self): [...] + +def test_bz2_ext(self): [...] + +def test_Gz_ext(self): +self.do_test_use_builtin_open(abcd.Gz, 6) + +def test_Bz2_ext(self): +self.do_test_use_builtin_open(abcd.Bz2, 7) Just a stylistic nit, but perhaps we should avoid having methods names which differ in casing only? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Fix #11509. Significantly increase test coverage for fileinput.
On Tue, Mar 15, 2011 at 10:44, Antoine Pitrou solip...@pitrou.net wrote: On Tue, 15 Mar 2011 15:29:59 +0100 brian.curtin python-check...@python.org wrote: + +def test_gz_ext(self): [...] + +def test_bz2_ext(self): [...] + +def test_Gz_ext(self): +self.do_test_use_builtin_open(abcd.Gz, 6) + +def test_Bz2_ext(self): +self.do_test_use_builtin_open(abcd.Bz2, 7) Just a stylistic nit, but perhaps we should avoid having methods names which differ in casing only? Agreed. I'll rename them to be more expressive. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 09:20, Martin v. Löwis mar...@v.loewis.de wrote: In fact, since the deprecation in the Python 2 line happened in 2.7, the deprecation period of this API in practice was between July 3rd 2010 and February 20 2011. That is a deprecation period of somewhat longer than seven months. Nobody obviously though 2.6 was out of practical use by now, so why did you decide to remove one if it's API's? Python 2.6's API wasn't removed in 2.7. It remains available. But not in 3.2. And the new API appeared in 2.7. That is a deprecation period of seven and a half months. If you go from 2.7 to 3.2, you should expect things to break. That's why the major version changed. And 3.1 to 3.2? There is no major version break there. For 3.x, as Reid points out, the API was deprecated in 3.1, so the deprecation period was rather 19 months, not 7. Yes, but we are now in a period of parallell support for Python 2 and Python 3. So it doesn't work like that. We need to support both Python 2 and Python 3 at the same time. Therefore, the deprecation period was seven and a half month, because it was impossible to support the new API before, and impossible to support the new API after, if you need to support both Python 2 and Python 3. Let's make no bones about this: The PyCObject API should *not* have been removed in 3.2. In fact, the removal should be reversed, and 3.2.1 should be released ASAP, making 3.2 a moot and unsupported version. This change conforms to PEP 5: There must be at least a one-year transition period between the release of the transitional version of Python and the release of the backwards incompatible version. Users will have at least a year to test their programs and migrate them from use of the deprecated construct to the alternative one. It is too short, and so is 19 months, but this change does *not* conform. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Mon, Mar 14, 2011 at 19:22, Reid Kleckner reid.kleck...@gmail.com wrote: I don't know how your code works, but handling either type from C seems very straightforward to me. You can simply use #ifdef Py_COBJECT_H to see if the cobject.h header was pulled into Python.h. Similarly for Py_CAPSULE_H. All you lose is that if you do get a PyCObject, there is no way of knowing if the void pointer is of the right type. Good to know. **We can't deprecate an API in one version and drop the API in the next. This is not acceptable. The deprecation period must be much longer!** Surely, you must be joking. No. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
On Tue, Mar 15, 2011 at 9:42 AM, Tim Lesher tles...@gmail.com wrote: 2. Add a new class attribute that uses the same mechanism, with a different name (e.g., __api__). Pro: fairly easy to explain; because it doesn't share a name with __all__ its semantics can be tweaked without confusing people. Con: slight additional cognitive burden of a new feature I'm implementing both of these separately this week to see which works better in practice. So far I'm liking __api__ better, with these semantics: 1. Classes without __api__ are treated just as they are today. 2. __api__ on classes works just like __all__ on modules (only special names, plus its contents are documented) 3. Additionally, __api__ can take an Ellipsis. That makes the __api__ list additive--pydoc documents everything it normally would, *plus* the contents of __api__ 4. __api__ is added to pydoc's hidden names list; since its only purpose is to help generate docs, its value would be of little use in the generated docs themselves. Point 3 (Ellipsis) is unusual, but to me it makes the declaration read well and solves the namedtuple case succinctly and compatibly, without changing a published API. It also could be used to address the issue of stdlib classes that have non-underscored members that really shouldn't be considered part of the public API, but can't be renamed now for fear of breaking code. The challenge here is how it would interact with inheritance. pydoc couldn't use normal attribute lookup, it would have to walk the MRO manually, only applying __api__ to the specific class that defined it. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 15/03/2011 07:59, Nick Coghlan wrote: While I actually think the current API design is a decent compromise, another option to consider would be to move the underscore to the *end* (as_dict_, replace_, make_) as is sometimes done for code that needs to avoid conflicting with a keyword. Namespace collisions with actual fields would remain unlikely, while pydoc would pick up the new names correctly. Although it's a backwards incompatible change. Teaching pydoc to recognise the private methods isn't. If we can find a good way to do it, making pydoc smarter would definitely be a nicer option. If we went the moving the underscore route, the old names would indeed have to remain for compatibility. Just one of many reasons it isn't a great solution :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging
On Tue, Mar 15, 2011 at 9:48 AM, Tarek Ziadé ziade.ta...@gmail.com wrote: or if you backport it, we could add a new fallback ;) try: from __future__ import or_importer except ImportError: XXX -- previous proposal else: or based proposal Alas, the fallback trick doesn't work for the from __future__ compiler hacks. What you could do though, is isolate the logic for the import fallbacks and then do: from myproject.import_fallbacks import compiler, commands Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
On Tue, 15 Mar 2011 11:17:18 -0400 Nick Coghlan ncogh...@gmail.com wrote: On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 15/03/2011 07:59, Nick Coghlan wrote: While I actually think the current API design is a decent compromise, another option to consider would be to move the underscore to the *end* (as_dict_, replace_, make_) as is sometimes done for code that needs to avoid conflicting with a keyword. Namespace collisions with actual fields would remain unlikely, while pydoc would pick up the new names correctly. Although it's a backwards incompatible change. Teaching pydoc to recognise the private methods isn't. If we can find a good way to do it, making pydoc smarter would definitely be a nicer option. Wouldn't a decorator be adequate? @pydoc.public_api def _asdict(self): some docstring ... Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Fix #11509. Significantly increase test coverage for fileinput.
On Tue, Mar 15, 2011 at 10:52 AM, Brian Curtin brian.cur...@gmail.com wrote: Agreed. I'll rename them to be more expressive. Don't forget NEWS and ACKS updates as well. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The purpose of SETUP_LOOP, BREAK_LOOP, CONTINUE_LOOP
I think you guys are forgetting about FOR_ITER, listcomps, and the like. That is, IIRC, the reason loops use the block stack is because they put things on the regular stack, that need to be cleared off the stack when the loop is exited (whether normally or via an exception). Good point. However, for exit via exception you always unwind till try block, having loop block in the way seems unneeded? While loops don't keep anything on values stack, so sounds like they can avoid SETUP_LOOP? Comprehensions don't use SETUP_LOOP already as you can't break from them. Sounds like the only use case is for loop with explicit break. In this case break can be compiled into POP and JUMP at the expense of bytecode size if there are multiple breaks. Eugene ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Fix #11509. Significantly increase test coverage for fileinput.
On Tue, Mar 15, 2011 at 11:28, Nick Coghlan ncogh...@gmail.com wrote: On Tue, Mar 15, 2011 at 10:52 AM, Brian Curtin brian.cur...@gmail.com wrote: Agreed. I'll rename them to be more expressive. Don't forget NEWS and ACKS updates as well. Got the news update in 9448691fe084. Had him in acks from another patch last night. Thanks. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
Python 2.6's API wasn't removed in 2.7. It remains available. But not in 3.2. And the new API appeared in 2.7. No, it didn't. It first appeared in 3.1. That is a deprecation period of seven and a half months. Not true. It's a deprecation period of 19 months and two releases (3.1 and 2.7). If you go from 2.7 to 3.2, you should expect things to break. That's why the major version changed. And 3.1 to 3.2? There is no major version break there. Right. So for things to be removed there, they have to be deprecated first (and that's what happened). For 3.x, as Reid points out, the API was deprecated in 3.1, so the deprecation period was rather 19 months, not 7. Yes, but we are now in a period of parallell support for Python 2 and Python 3. So it doesn't work like that. We need to support both Python 2 and Python 3 at the same time. Therefore, the deprecation period was seven and a half month, because it was impossible to support the new API before, and impossible to support the new API after, if you need to support both Python 2 and Python 3. If you actually had been supporting 2.x and 3.x in parallel for the last two years, you would have had a deprecation period of 19 months and two releases. It's only if you are now migrating from 2 to 3 that you notice the breakage for the first time. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] NetBSD and curses
Hi, Sorry, it was just laughingly pointed out to me that I responded to your complaint about a bug being ignored by asking you to file a bug. :) Thats what I get for reading things late at night. regardless, any time you have a patch for something, please attach it to the issue, things on the mailing list get lost. I've gone ahead and attached the patch and accepted the issue. I have a netbsd ec2 instance to test with now but haven't had time to get it setup for python development. None of the devs currently run netbsd on a regular basis or have much experience with it as a platform so patches are a great help. Any chance you can also make a version of the patch that applies against hg cpython tip (3.3)? -gps 2011/3/15 Gregory P. Smith g...@krypto.org Would you please post this to bugs.python.org so that it doesn't get lost? thanks! -gps On Mon, Mar 14, 2011 at 8:51 PM, Bill Green b...@supposedly.org wrote: Hi all, I ran across this issue several months ago and filed a bug report (#9667). It just came up again, and it doesn't look like anything's been done with the bug report, so I thought I'd post here. In _cursesmodule.c there are a lot of preprocesser conditionals that test if the system is NetBSD. In my case, the issue was that the module built lacked the KEY_UP / _DOWN / etc. constants, but there are other changes as well. This is the case even if you're compiling against ncurses instead of the system curses. Αttached below is a patch against 2.7.1 that negates the NetBSD conditionals if ncurses is present. It seems to work as expected, although I haven't done any real testing. I assumed this was done because NetBSD curses was missing something, but I looked at the headers and it seems to have most of the constants that the compilation directives are leaving out (A_INVIS, the aforementioned KEY_* constants, at least), so I'm not sure why that code isn't compiled in anyway. Please let me know if I'm misunderstanding this. Thanks, Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
On Tue, Mar 15, 2011 at 11:24, Antoine Pitrou solip...@pitrou.net wrote: Wouldn't a decorator be adequate? @pydoc.public_api def _asdict(self): some docstring ... That was my first attempt. Unfortunately, it didn't work well with classmethods or immutable data members, and forcing the module to import pydoc had some bad side effects (particularly in the eval-ed code for namedtuple). -- Tim Lesher tles...@gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
On Tue, Mar 15, 2011 at 11:15, Nick Coghlan ncogh...@gmail.com wrote: The challenge here is how it would interact with inheritance. pydoc couldn't use normal attribute lookup, it would have to walk the MRO manually, only applying __api__ to the specific class that defined it. Great catch. I know pydoc already looks at this in the attrs-processing loop (to group attrs by their defining class), but my current implementation applies __api__ too early to deal with that. I'll fix it. Any test cases should definitely throw some diamond-pattern or even more degenerate cases at the implementation. What *is* the worst case for MRO complexity? Overall, this is becoming more interesting than I'd thought at first. Is this something that should require a PEP? -- Tim Lesher tles...@gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On 3/14/11 5:30 PM, Lennart Regebro wrote: Many projects, not only the Zope Toolkit needs to support a lot of versions. The Zope component architecture currently supports 2.4, 2.5 and 2.6 and is expected to work on 2.7. I don't know if 2.4 or 2.5 can be dropped, but it definitely will be *years* until we can drop support for 2.6. But if I move the PyCObject API to the PyCapsule API, the zope packages will **only work on Python 2.7 and 3.2**. This is obviously not an option. If I do *not* switch, I can't support Python 3.2. That's bad. For what it's worth, numpy simultaneously supports Python 2.5-2.7 and 3.1-3.2. It uses PyCObject or PyCapsule APIs as appropriate. We do this from the same codebase. We had to add another layer of indirection, but nothing too bad. You can steal our code here: https://github.com/numpy/numpy/blob/master/numpy/core/include/numpy/npy_3kcompat.h#L299 -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.1): #11515: fix several typos. Patch by Piotr Kasprzyk.
On Tue, 15 Mar 2011 04:19:24 +0100 ezio.melotti python-check...@python.org wrote: Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c libffi is a third-party library and you should probably not introduce gratuitous changes in these files. It will make tracking changes with upstream more tedious. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
On Tue, Mar 15, 2011 at 12:27 PM, Tim Lesher tles...@gmail.com wrote: Overall, this is becoming more interesting than I'd thought at first. Is this something that should require a PEP? Yeah, just to thrash out the semantics and give some visibility into the design decisions. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
One of simplest and least invasive ways to get help() to show the underscore methods and attributes is to make pydoc aware of named tuples by checking for the presence of _fields. * That leaves the named tuple code as simple as possible (which is important because the self-documenting code is exposed to the user through the verbose option). * It supports the _1, _2 attributes created by the rename option, and it works with user supplied underscore methods and attributes in a subclass. * It doesn't exaggerate the importance of help issue which AFAICT hasn't ever been noticed or cared about since the introduction of named tuples a few years ago or since the publication of its recipe in years prior to that. Raymond P.S. There are other ways like creating an abstract base class to identify a class as having underscored names that aren't private (like _from_iterable in the ABC for sets), but this seems to me like trying to kill a mosquito with a cannon. The underlying issue is so minor that it rules out invasive or heavy-weight efforts. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 12:02, Martin v. Löwis mar...@v.loewis.de wrote: If you actually had been supporting 2.x and 3.x in parallel for the last two years, you would have had a deprecation period of 19 months and two releases. It's only if you are now migrating from 2 to 3 that you notice the breakage for the first time. The code in question was ported to Python 3 last year, before both 2.7 and 3.2. I noticed the API change now because it's gone from 3.2. That's how most API changes gets noticed: Things stop working. And that's OK. Deprecation periods are there to help you support multiple versions at the same time. Deprecation notices are helpful, of course, but in this case it doesn't help. Even if I had noticed the deprecation warning in 3.1, I wouldn't have been able to do anything about that, because 2.7 had then not been released, and the new API isn't supported in 2.6. I therefore could not have moved to the new API *because* I support both Python 2.x and 3.x I could have (and still can) support it by using compatibility macros or #ifdefs, sure. But you can do that without a deprecation period. So: without compatibility preprocessing I can no longer support 2.6. 2.7 came out seven and a half months before 3.2. Hence the deprecation period was in practice seven and a half months. Admittedly, in C with the preprocessing it's less of an issue, but the C-extensions is rapidly reaching a position where there seems to be as much compatibility macros as there is C code... :-) How long is this going to continue. What API's are going to be needlessly removed in Python 3.3? Could we please cool down with the backwards incompatibility? //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
I noticed the API change now because it's gone from 3.2. That's how most API changes gets noticed: Things stop working. And that's OK. Deprecation periods are there to help you support multiple versions at the same time. That may be the source of misunderstanding. In my understanding, that's *not* what deprecation periods are there. Instead, they are there to give people time to adjust to the changes before their code will break for good. So during the deprecation period, they should start using the new way of doing things, so that the code is ready when the old way goes away. Deprecation notices are helpful, of course, but in this case it doesn't help. Even if I had noticed the deprecation warning in 3.1, I wouldn't have been able to do anything about that Of course you could have. You could have added a version of your code that uses capsules (just as you are probably doing now). Then, the could would not have been broken in 3.2. I could have (and still can) support it by using compatibility macros or #ifdefs, sure. But you can do that without a deprecation period. Right - and that's why the deprecation period is not about supporting multiple versions, but to reduce the need for people to adjust their code on a quick notice. Could we please cool down with the backwards incompatibility? That's another motivation for deprecation. It gives people a chance to intervene and ask for an extension of the deprecation period, so that they have more time to adjust. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
On 3/15/2011 11:17 AM, Nick Coghlan wrote: On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 15/03/2011 07:59, Nick Coghlan wrote: While I actually think the current API design is a decent compromise, another option to consider would be to move the underscore to the *end* (as_dict_, replace_, make_) as is sometimes done for code that needs to avoid conflicting with a keyword. Namespace collisions with actual fields would remain unlikely, while pydoc would pick up the new names correctly. Although it's a backwards incompatible change. Teaching pydoc to recognise the private methods isn't. If we can find a good way to do it, making pydoc smarter would definitely be a nicer option. If we went the moving the underscore route, the old names would indeed have to remain for compatibility. However, pydoc left alone would only pick up (and publicize) the new names. One can argue that since the methods are not really private, they should have had a trailing rather than leading underscore in the first place. Other module classes have recently had method names aliased and deprecated for eventual removal, so this would not be a unique move, though a class factory is slightly different from a class. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Have we lost changeset info in the buildbots
Traditionally I could see who was the committer who push change to the buildbots. This info seems not to be (easily) available. I have now restored that information in the buildbot. However, only includes the committer, not the pusher. Traditionally, they were the same thing, but they are not anymore since the mercurial switch. I don't know whether the pushlog is available remotely. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Fix #11509. Significantly increase test coverage for fileinput.
On 3/15/2011 11:57 AM, Brian Curtin wrote: On Tue, Mar 15, 2011 at 11:28, Nick Coghlan ncogh...@gmail.com mailto:ncogh...@gmail.com wrote: On Tue, Mar 15, 2011 at 10:52 AM, Brian Curtin brian.cur...@gmail.com mailto:brian.cur...@gmail.com wrote: Agreed. I'll rename them to be more expressive. Don't forget NEWS and ACKS updates as well. Got the news update in 9448691fe084. Had him in acks from another patch last night. Thanks. Great to see significant patches coming from the sprint. I hope we can keep some of the newer people involved in the future. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.1): #11515: fix several typos. Patch by Piotr Kasprzyk.
On 3/15/2011 1:00 PM, Antoine Pitrou wrote: On Tue, 15 Mar 2011 04:19:24 +0100 ezio.melottipython-check...@python.org wrote: Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c libffi is a third-party library and you should probably not introduce gratuitous changes in these files. It will make tracking changes with upstream more tedious. This answers my question elsewhere of why revert real fixes. Perhaps the fixes could be submitted upstream. Is that status and the restriction on changes indicated in the file? -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.1): #11515: fix several typos. Patch by Piotr Kasprzyk.
2011/3/15 Terry Reedy tjre...@udel.edu: On 3/15/2011 1:00 PM, Antoine Pitrou wrote: On Tue, 15 Mar 2011 04:19:24 +0100 ezio.melottipython-check...@python.org wrote: Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c libffi is a third-party library and you should probably not introduce gratuitous changes in these files. It will make tracking changes with upstream more tedious. This answers my question elsewhere of why revert real fixes. Perhaps the fixes could be submitted upstream. It really doesn't matter if there's typos in 3rd party libraries which we distribute. Is that status and the restriction on changes indicated in the file? No, because that would make updating it annoying, too. :) -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Have we lost changeset info in the buildbots
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15/03/11 21:14, Martin v. Löwis wrote: Traditionally I could see who was the committer who push change to the buildbots. This info seems not to be (easily) available. I have now restored that information in the buildbot. However, only includes the committer, not the pusher. Traditionally, they were the same thing, but they are not anymore since the mercurial switch. I don't know whether the pushlog is available remotely. Thanks for bringing this back!. Recording the pusher is useful, since anybody (with push privileges) can fake commit attributions. I know that people like Mozilla actually store this information (via a push hook, if I am not mistaken). - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@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/ iQCVAwUBTX/Zn5lgi5GaxT1NAQLkyAP/WmXHtvSrx2UKkH8ubRvPVNoOqJChsPor BLjOZD3oxiM9l0EUBtgmJPVsH9yvB0fdvFj+2T3sc9Jt5eWgSE4bzgIHXsgA7aXZ sq24yK0Vdot+F9aDTDmeHlHrv0UzpJSBQm0iI+mkUQIVCK0da/Fy/1BMuyCxjR0C 7DZCGVOzQyg= =jmsM -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Mercurial workflow: merging from 3.2
Hey all, I realise that we're still getting used to the workflows, but there are currently unmerged changesets (in test_peepholer and friends) on the 3.2 branch that seem to have been applied *separately* to 3.3. This causes problems for anyone else who wants to merge changes from 3.2 to 3.3 as these unmerged changesets appear as conflicts. If you do work in 3.2 (or earlier) please merge those changesets to default. All the best, Michael -- 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 15:39, Martin v. Löwis mar...@v.loewis.de wrote: Of course you could have. You could have added a version of your code that uses capsules (just as you are probably doing now). No I'm not. Right - and that's why the deprecation period is not about supporting multiple versions, but to reduce the need for people to adjust their code on a quick notice. I think we need to adjust PEP 5 then. We can't keep on breaking backwards compatibility like this. People are already freaked out about Python 2 to Python 3, and the argument is often used against Python that it's not a language to be used in enterprise situations because Python keeps on breaking backwards compatibility. Up until 3.2 that statement was not actually true. Python 2.x was very backwards compatible. The next time somebody tells me that Python isn't stable and breaks backwards compatibility all the time, and says that's why you should use Java, what can I now say? OK, it's just the C-API, but that excuse isn't going to fly... //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 6:46 PM, Lennart Regebro rege...@gmail.com wrote: On Tue, Mar 15, 2011 at 15:39, Martin v. Löwis mar...@v.loewis.de wrote: Of course you could have. You could have added a version of your code that uses capsules (just as you are probably doing now). No I'm not. The numpy folks have shown it is quite possible to support 3.2 without sacrificing compatibility with earlier versions. Right - and that's why the deprecation period is not about supporting multiple versions, but to reduce the need for people to adjust their code on a quick notice. I think we need to adjust PEP 5 then. We can't keep on breaking backwards compatibility like this. People are already freaked out about Python 2 to Python 3, and the argument is often used against Python that it's not a language to be used in enterprise situations because Python keeps on breaking backwards compatibility. Up until 3.2 that statement was not actually true. Python 2.x was very backwards compatible. The next time somebody tells me that Python isn't stable and breaks backwards compatibility all the time, and says that's why you should use Java, what can I now say? OK, it's just the C-API, but that excuse isn't going to fly... But given that this situation was unique to the parallel development of 2.x and 3.x, and PEP 5 was applied correctly within each of the parallel lines of development, why not just consider this another instance of the 2.x/3.x incompatibility? That's what it is after all. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
For years, urlparse (and subsequently urlib.parse) has opted to implement the semantics from the older URL processing RFCs, rather than updating to the new semantics as the RFCs are superseded. With RFC 3986 passing its 6th birthday, and with it being well past its 7th by the time 3.3 comes out, can we finally switch to supporting the current semantics rather than the obsolete behaviour? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 18:56, Nick Coghlan ncogh...@gmail.com wrote: why not just consider this another instance of the 2.x/3.x incompatibility? That's what it is after all. Apparently not, as the code already ran under Python 3.1. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan ncogh...@gmail.com wrote: With RFC 3986 passing its 6th birthday, and with it being well past its 7th by the time 3.3 comes out, can we finally switch to supporting the current semantics rather than the obsolete behaviour? We do infact, support RFC 3986, expect for the cases where those conflict with the previous RFCs. (IOW, backwards compatible). The tests can give you a good picture here. Do you mean, we should just do away with backwards compatibility? Or you had anything else specifically in mind? -- Senthil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
On Tue, 15 Mar 2011 18:46:37 -0400 Lennart Regebro rege...@gmail.com wrote: Right - and that's why the deprecation period is not about supporting multiple versions, but to reduce the need for people to adjust their code on a quick notice. I think we need to adjust PEP 5 then. We can't keep on breaking backwards compatibility like this. We? You must understand that compatibility rules are quite a burden when it comes to evolving Python's APIs. Making these rules even stricter would probably reduce motivation to contribute to Python for at least some developers (be they core developers or not). Beside, if you need long-term support, there is a well-known solution: turn to a company that provides such support. That company can be called Redhat, Canonical, ActiveState or even Apple. The community of volunteers called python-dev is already doing quite a lot in that area. People are already freaked out about Python 2 to Python 3, and the argument is often used against Python that it's not a language to be used in enterprise situations because Python keeps on breaking backwards compatibility. This sounds like FUD. Again, such companies can just rely on a commercial vendor to provide support. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
Martin v. Löwis wrote: There must be at least a one-year transition period between the release of the transitional version of Python and the release of the backwards incompatible version. I still think this is going to result in rude shocks to people switching from 2 to 3 and jumping several releases into the 3.x line. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging
Tarek Ziadé wrote: try: from __future__ import or_importer except ImportError: XXX -- previous proposal else: or based proposal This could easily be fixed if we allowed run-time access to the time machine: from __future__ import temporal_mechanics, or_importer import timemachine timemachine.backport_feature(or_importer, from_version = 3.4) ... (For obvious reasons, this will work despite the future import of or_importer occurring before the code that backports it.) Manual use of the time machine would be required to backport the timemachine module itself, after which there would never be any backwards compatibility problems again. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
Nick Coghlan wrote: The challenge here is how it would interact with inheritance. pydoc couldn't use normal attribute lookup, it would have to walk the MRO manually, This is an instance of a pattern that I've encountered a few times in things that I've done: you have a class attribute containing a list of things, and you want it to be additive with respect to inheritance -- i.e. it contains the items specified in a particular class plus all those specified in its base classes. This can obviously be arranged using appropriate metaclass hackery, but I'm wondering whether it could be provided using some mechanism that can be applied orthogonally to any class attribute. Maybe this is another reason to have a hook somewhere in the standard class creation process that allows a descriptor to initialise itself with knowledge of its environment. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] User conversions in custom string.Formatter
As PEP 3101 http://www.python.org/dev/peps/pep-3101/ says (and current
Python does) user can specify conversions like {0!s}.
In custom formatters (derived from string.Formatter) he can override
convert_field method to add custom conversions.
I experimented with that last month and found it very convenient.
From my perspective custom conversions are very close to 'filters'
from html template engines (jinja2, mako, django etc).
While I like to see custom conversions simple and easy I don't wan't
to bring 'cascading' and 'parametrization' to standard formatting.
But why don't relax spec a bit and allow to use any word (with
'identifier' semantix, I mean str.isidentifier()) as conversion name?
Proposed update doesn't make any backward incompatibility (both python
and public C API are not changed), it's clean and obvious.
And it's very funny to use words instead single characters for custom
user-specific conversions.
What do you think?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User conversions in custom string.Formatter
On 03/15/2011 08:07 PM, Andrew Svetlov wrote:
As PEP 3101 http://www.python.org/dev/peps/pep-3101/ says (and current
Python does) user can specify conversions like {0!s}.
In custom formatters (derived from string.Formatter) he can override
convert_field method to add custom conversions.
I experimented with that last month and found it very convenient.
From my perspective custom conversions are very close to 'filters'
from html template engines (jinja2, mako, django etc).
While I like to see custom conversions simple and easy I don't wan't
to bring 'cascading' and 'parametrization' to standard formatting.
But why don't relax spec a bit and allow to use any word (with
'identifier' semantix, I mean str.isidentifier()) as conversion name?
Proposed update doesn't make any backward incompatibility (both python
and public C API are not changed), it's clean and obvious.
And it's very funny to use words instead single characters for custom
user-specific conversions.
What do you think?
This should be in python-ideas, but I don't know if Andrew is
subscribed, so I'll reply here until it gets out of control.
Andrew: Could you give a code sample of what you'd like to see?
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
Tim Lesher wrote: Any test cases should definitely throw some diamond-pattern or even more degenerate cases at the implementation. What *is* the worst case for MRO complexity? I don't think that's an issue -- the MRO gets flattened into a list at class creation time, so code that walks it never sees any of the complexities of diamonds, etc. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] devguide: managing +1 heads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As far as I remember, python-dev decided that each branch should have a single head. We probably have even a push hook to avoid mistakes. Or we should :). But we don't explain what is suppose to be done when a developer is working in a feature, she updates her repository clone, rebase her patches, collapses all her local changesets to a single giant changeset, commit it locally, merge them to default and then she tries to push. But somebody else raced her and commit first, so she is trying to generate a new head. The standard approach in mercurial is for her to pull the changes and to do a merge before trying to push again (and hope nobody else raced her again, this time). But the merge will be visible in the project history, and I have the feeling that python-dev tries hard to keep a lineal history. Another usual approach would be to pull the changes and rebase the local unpushed changesets before trying again, to get a linear history. But no idea of what would happen when we have multiple local commits in several different branches. Never tried in this situation, and not sure that I want to try :). In any case, devguide is silent about this. I would suggest to write something to fill this gap. See, for instance, http://hg.python.org/cpython/rev/9a817ab166e0, http://hg.python.org/cpython/graph/9a817ab166e0. PS: I didn't merged 9a817ab166e0 to 3.x because I don't know what plans Raymond has for 6544accfefc3. I guess he is waiting for buildbot results before merging to 3.x. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@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/ iQCVAwUBTYALuplgi5GaxT1NAQIpwgP/U7MTC59QKOn5/4PgFEe3L1q7tsiAs6Tb jLYhL8vXBjyY3Ct5bOXW9MBcagHa+Bk/hz/ohGcGP+PL3ZtqgXE9Zv6ZXRydnhWb GslPQnCnHjp8KMa3iE6wDMRskY46iDQtVh1QOo9UTi001jn5mqo2CLDugmFHVU+l lFEnXBCotGo= =SBiW -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: managing +1 heads
On Wed, 16 Mar 2011 02:00:42 +0100 Jesus Cea j...@jcea.es wrote: The standard approach in mercurial is for her to pull the changes and to do a merge before trying to push again (and hope nobody else raced her again, this time). This is indeed the standard approach, so I'm not sure what the point of mentioning it in the devguide would be. I don't think the devguide should turn into a Mercurial tutorial: there are plenty of them on the Web. Regardless, if you want to experiment with other approaches, please go ahead and report the results here. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 19:14, Antoine Pitrou solip...@pitrou.net wrote: Beside, if you need long-term support, there is a well-known solution: turn to a company that provides such support. That company can be called Redhat, Canonical, ActiveState or even Apple. The community of volunteers called python-dev is already doing quite a lot in that area. OK, fine. I'm stopping my efforts of porting the ZTK to Python 3 unless somebody pays me then, if that is the attitude from the core developers on this issue. Why should there be third-party libraries available for Python 3.2!? No need, if you want them you can find commercial support, apparently. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: managing +1 heads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/03/11 02:15, Antoine Pitrou wrote: On Wed, 16 Mar 2011 02:00:42 +0100 Jesus Cea j...@jcea.es wrote: The standard approach in mercurial is for her to pull the changes and to do a merge before trying to push again (and hope nobody else raced her again, this time). This is indeed the standard approach, so I'm not sure what the point of mentioning it in the devguide would be. I don't think the devguide should turn into a Mercurial tutorial: there are plenty of them on the Web. My point is that I was getting the +1 head warning. I know how to solve it by myself, but I checked the devguide to learn if there was some kind of policy about it. The devguide is silent about it. Maybe a simple try to keep the history lineal, as possible and feel free to merge heads in the standard mercurial way. In fact, we have discussed here the approach of collapsing local changes to a single changeset when pushing to the central repository, but I don't see any reference to this policy in the devguide. Unwritten culture is not good. Better for new contributors to read a document and learn the way that to pick some details here, some there after stepping over a lot of toes. For instance, merging between branches (in which direction) is established here, but not in the devguide. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@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/ iQCVAwUBTYAUUZlgi5GaxT1NAQJp8wQAmuj5QLohUvAGRetajubTlizIMhgUEk1l 9kYn9XcfdtETHkM2t3Fmi73FscslNWXTT11kR1rqoyJUjS7XklcPGYtKQqWBAo+b qICXLKo6C150lRe5VRDWBlJCvUTpFGQddh3ouTjfPjW43sO1Sj/OWJb4H1tSkyjL smKW5SaSnXE= =46ku -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: managing +1 heads
2011/3/15 Jesus Cea j...@jcea.es: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/03/11 02:15, Antoine Pitrou wrote: On Wed, 16 Mar 2011 02:00:42 +0100 Jesus Cea j...@jcea.es wrote: The standard approach in mercurial is for her to pull the changes and to do a merge before trying to push again (and hope nobody else raced her again, this time). This is indeed the standard approach, so I'm not sure what the point of mentioning it in the devguide would be. I don't think the devguide should turn into a Mercurial tutorial: there are plenty of them on the Web. My point is that I was getting the +1 head warning. I know how to solve it by myself, but I checked the devguide to learn if there was some kind of policy about it. The devguide is silent about it. Maybe a simple try to keep the history lineal, as possible and feel free to merge heads in the standard mercurial way. In fact, we have discussed here the approach of collapsing local changes to a single changeset when pushing to the central repository, but I don't see any reference to this policy in the devguide. Unwritten culture is not good. Better for new contributors to read a document and learn the way that to pick some details here, some there after stepping over a lot of toes. For instance, merging between branches (in which direction) is established here, but not in the devguide. What are you talking about? http://docs.python.org/devguide/committing.html#forward-porting -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: managing +1 heads
On Wed, 16 Mar 2011 02:37:21 +0100 Jesus Cea j...@jcea.es wrote: Maybe a simple try to keep the history lineal, as possible and feel free to merge heads in the standard mercurial way. Well, can you propose a patch to add or improve wording? For instance, merging between branches (in which direction) is established here, but not in the devguide. It is: http://docs.python.org/devguide/committing.html#forward-porting Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: managing +1 heads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/03/11 02:42, Benjamin Peterson wrote: For instance, merging between branches (in which direction) is established here, but not in the devguide. What are you talking about? http://docs.python.org/devguide/committing.html#forward-porting I beg your pardon. 3AM in Spain. Time to get some sleep, it seems... - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@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/ iQCVAwUBTYAWOZlgi5GaxT1NAQJD6gP5AbqT+PP/1DPmzVUXy0iqWuy+HE1PJC6X dBzvE3abcqCsCEIhmqn8NW//jXUzGZ162dF+3xJ9IViCZhOol3n5d+E/Yna67/uh 48LJIV0bUrXDkg/nm0/VJGyx0GUqFx546mv9M3dsjMOxd7Q6ZbSfCp/clyWa8Drn IwfdJMkGnAI= =NW3O -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
On Tue, 15 Mar 2011 21:16:58 -0400 Lennart Regebro rege...@gmail.com wrote: On Tue, Mar 15, 2011 at 19:14, Antoine Pitrou solip...@pitrou.net wrote: Beside, if you need long-term support, there is a well-known solution: turn to a company that provides such support. That company can be called Redhat, Canonical, ActiveState or even Apple. The community of volunteers called python-dev is already doing quite a lot in that area. OK, fine. I'm stopping my efforts of porting the ZTK to Python 3 unless somebody pays me then, if that is the attitude from the core developers on this issue. I don't know what other core devs, but I don't think this discussion is going anywhere. If porting the ZTK is a burden for you, perhaps you should try to find some financial support for it (or let other people do it for you), rather than accusing the python-dev community. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou solip...@pitrou.net wrote: I don't know what other core devs, but I don't think this discussion is going anywhere. If porting the ZTK is a burden for you, perhaps you should try to find some financial support for it (or let other people do it for you), rather than accusing the python-dev community. Up until the reactions from the core Python developers on these real world problems, it was hard work, but also fun. It isn't anymore, and I hear your message, loud and clear, so indeed, somebody else will have to do it. I've lost interest. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 10:14:12PM -0400, Lennart Regebro wrote: Up until the reactions from the core Python developers on these real world problems, it was hard work, but also fun. It is still. The majority of the responses were informative on backwards compatibility and release process. And suggestive of how things changed from between 2.7, 3.1 and 3.2. And there is a unique problem here that 3.1 was released before 2.7. And things which break backwards compatibility is discussed before any changes are made. So, your comment on python 'always breaking the compatibility' was not correct and perhaps that invoked a strong reaction. -- Senthil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 7:14 PM, Lennart Regebro rege...@gmail.com wrote: On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou solip...@pitrou.net wrote: I don't know what other core devs, but I don't think this discussion is going anywhere. If porting the ZTK is a burden for you, perhaps you should try to find some financial support for it (or let other people do it for you), rather than accusing the python-dev community. Up until the reactions from the core Python developers on these real world problems, it was hard work, but also fun. It isn't anymore, and I hear your message, loud and clear, so indeed, somebody else will have to do it. I've lost interest. This is unfortunate (and the PyCon sprints aren't even over!). I think Lennart's complaint has *some* validity. I think PEP 5 did not anticipate two overlapping lines of development, and in retrospect it was unwise to kill the offending API in 3.2 (even if it is *possible* to deal with it, it's cumbersome). But I do not think that there is a way to undo the damage that was done; putting the missing API back in 3.2.1 will cause other problems (because it would break compatibility between 3.2 and 3.2.1). So Lennart will have to put up with the pragmatics of supporting 2.7 and 3.2 (and others as he desires). But we should learn from the experience and be more cautious with 3.3. Fortunately there may not be any more such cases since no new major versions of Python 2 will be released. So I'm not sure what an update of PEP 5 will buy us. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
On Mar 15, 2011, at 10:14 PM, Lennart Regebro wrote: On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou solip...@pitrou.net wrote: I don't know what other core devs, but I don't think this discussion is going anywhere. If porting the ZTK is a burden for you, perhaps you should try to find some financial support for it (or let other people do it for you), rather than accusing the python-dev community. Up until the reactions from the core Python developers on these real world problems, it was hard work, but also fun. It isn't anymore, and I hear your message, loud and clear, so indeed, somebody else will have to do it. I've lost interest. It seems a bit odd for you to be so surprised about this, considering Python3 is a *huge* compatibility break that broke basically every single thing ever written in Python. And I'm not sure why you're making such a big deal about this one corner of incompatibility -- PyCObject vs. PyCapsule seems like such a trivial and easy to work around issue compared to the massive pain-in-the-ass porting job for all the incompatibilities on the Python-language side of the fence. James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
On Tue, Mar 15, 2011 at 7:14 PM, Senthil Kumaran orsent...@gmail.com wrote: On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan ncogh...@gmail.com wrote: With RFC 3986 passing its 6th birthday, and with it being well past its 7th by the time 3.3 comes out, can we finally switch to supporting the current semantics rather than the obsolete behaviour? We do infact, support RFC 3986, expect for the cases where those conflict with the previous RFCs. (IOW, backwards compatible). The tests can give you a good picture here. Do you mean, we should just do away with backwards compatibility? Or you had anything else specifically in mind? Backwards compatible with *what* though? For the decimal module, we treat deviations from spec as bug fixes and update accordingly, even if this changes behaviour. For URL parsing, the spec has changed (6 years ago!), but we still don't provide a spec-conformant implementation, even via a flag or new function. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 22:42, Guido van Rossum gu...@python.org wrote: Fortunately there may not be any more such cases since no new major versions of Python 2 will be released. So I'm not sure what an update of PEP 5 will buy us. That is a good point. But at least making sure no more API's get deprecated in 3.3 (and preferably 3.4) would go a long way, as we are likely to still have to support Python 2 in parallell for those versions as well. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: managing +1 heads
On Tue, Mar 15, 2011 at 9:15 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 16 Mar 2011 02:00:42 +0100 Jesus Cea j...@jcea.es wrote: The standard approach in mercurial is for her to pull the changes and to do a merge before trying to push again (and hope nobody else raced her again, this time). This is indeed the standard approach, so I'm not sure what the point of mentioning it in the devguide would be. I don't think the devguide should turn into a Mercurial tutorial: there are plenty of them on the Web. Given our stated preference for pushing collapsed changesets, it does seem worthwhile to explicitly mention the pull/merge/push case as a case where a collapsed changeset isn't expected. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
On Tue, Mar 15, 2011 at 22:58, Lennart Regebro rege...@gmail.com wrote: That is a good point. But at least making sure no more API's get deprecated in 3.3 (and preferably 3.4) I meant removed. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] public visibility of python-dev decisions before it's too late
On 3/15/2011 10:58 PM, Lennart Regebro wrote: On Tue, Mar 15, 2011 at 22:42, Guido van Rossumgu...@python.org wrote: Fortunately there may not be any more such cases since no new major versions of Python 2 will be released. So I'm not sure what an update of PEP 5 will buy us. That is a good point. But at least making sure no more API's get deprecated in 3.3 (and preferably 3.4) would go a long way, as we are likely to still have to support Python 2 in parallell for those versions as well. I think it's valid that we should consider the affect of libraries that are trying to support 2.x and 3.y (for some values of x and y) at the same time. Speaking for myself, I'll admit I hadn't thought of this during any discussions of changing APIs. We'll only have to consider this for at most 2 more 3.x releases, if we believe the 5 year timeframe (since 3.0) for most projects to migrate. But I agree that there's not much we can do in the capsule case. The ship has sailed on that one. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
On Tue, Mar 15, 2011 at 7:58 PM, Nick Coghlan ncogh...@gmail.com wrote: On Tue, Mar 15, 2011 at 7:14 PM, Senthil Kumaran orsent...@gmail.com wrote: On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan ncogh...@gmail.com wrote: With RFC 3986 passing its 6th birthday, and with it being well past its 7th by the time 3.3 comes out, can we finally switch to supporting the current semantics rather than the obsolete behaviour? We do infact, support RFC 3986, expect for the cases where those conflict with the previous RFCs. (IOW, backwards compatible). The tests can give you a good picture here. Do you mean, we should just do away with backwards compatibility? Or you had anything else specifically in mind? Backwards compatible with *what* though? For the decimal module, we treat deviations from spec as bug fixes and update accordingly, even if this changes behaviour. For URL parsing, the spec has changed (6 years ago!), but we still don't provide a spec-conformant implementation, even via a flag or new function. Can you be specific? What is different between those RFCs? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
Nick Coghlan wrote:
Backwards compatible with *what* though?
I meant the parsing 'behavior'.
For the decimal module, we treat deviations from spec as bug fixes and
update accordingly, even if this changes behaviour.
For URL parsing, the spec has changed (6 years ago!), but we still
don't provide a spec-conformant implementation, even via a flag or new
function.
If I understand correctly, by spec-comformant implementation, you mean
having the parsed components denoted by the same terminology (as well
as behavior) as written in the RFC3986.
Like the example in the url denote:
foo://example.com:8042/over/there?name=ferret#nose
\_/ \__/\_/ \_/ \__/
| ||||
scheme authority pathquery fragment
| _|__
/ \ /\
urn:example:animal:ferret:nose
If I send the same url's via urlparse at the moment, I would get:
urlparse('foo://example.com:8042/over/there?name=ferret#nose')
ParseResult(scheme='foo', netloc='example.com:8042',
path='/over/there?name=ferret#nose', params='', query='', fragment='')
urlparse('urn:example:animal:ferret:nose')
ParseResult(scheme='urn', netloc='', path='example:animal:ferret:nose',
params='', query='', fragment='')
The first one is because, we still have old scheme specific parsing behavior.
Where foo is an unrecognized scheme so everything was classified under path. If
we have valid scheme name, then the parsing behaviour would match the
expectation.
- A change to this would break the compatibility with older parsing behavior.
Another point to note is naming - We use 'netloc' as part name loosely, where
as 'authority' is correct term to use and then authority component has
sub-parts.
- I think, it is good to change this and adopt the RFC terminology more
rigorously.
I am +1 to any helpful improvement we can do in this module. But often it
noticed that any slightest changes in parsing behavior has caused harm and
brought us more bug-reports.
A new function, which can given this behavior is also a good idea.
--
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
On Wed, Mar 16, 2011 at 12:03 AM, Senthil Kumaran orsent...@gmail.com wrote: A new function, which can given this behavior is also a good idea. I'm strongly in favor of this approach. I know we've been bitten by changes made in the past, and have had to introduce Python-version specific handling. (I don't have the details handy, but vaguely recall the two versions involved being 2.4 and 2.6.) -Fred -- Fred L. Drake, Jr. fdrake at acm.org A storm broke loose in my mind. --Albert Einstein ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
