Re: [Python-Dev] rlcompleter -- auto-complete dictionary keys (+ tests)
> > Can you post your patch on bugs.python.org? > done -- now both 2.x and 3.x patches are available on http://bugs.python.org/issue10351 The py3k appeared to be *much* more friendly regarding the unpleasant unicode-issues that I've faced in python 2.x regards, Valery ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GUI test runner tool
On 08/11/2010 19:00, Brett Cannon wrote: On Mon, Nov 8, 2010 at 04:09, Michael Foord wrote: Hello all, Now that unittest has test discovery, Mark Roddy has been working on resurrecting the old GUI test runner (using Tkinter): https://bitbucket.org/markroddy/unittestgui This was part of the original pyunit project but I believe it was never part of the standard library: http://sourceforge.net/projects/pyunit/ Here's a screenshot of what it looks like: http://skitch.com/fuzzyman/dhu9r/pyunit I'd like to propose adding it to Python in Tools/ and am volunteering to maintain it. Does that mean upgrading it as well? =) Yes... For instance it would be great to get it to use ttk so it looks a bit sharper, I've never used Ttk. Patches welcomed... supports skipped tests and expected failures, It already does, the screenshot is a bit old. :-) and dream-of-dreams ties into regrtest so you can just check boxes instead of passing a ton of CLI flags. That would be great, but regrtest is a bit custom. It's a great idea, but would need a different UI shell. If the answer is "not yet" that is fine as it can go into unittest2 first. Mark has updated it to work with test discovery and added support for configuring test discovery in the same way as you can from the command line. It is a nice tool for those new to writing tests who aren't yet familiar with the command line or prefer a GUI. I personally have no problem with it going into tools as long as it can also be used to run the tests in the stdlib. Unfortunately the stdlib tests largely aren't compatible with test discovery. There is an open issue about that. Many of the tests depend on being run with regrtest, and use features that are in many places now obsolete due to improvements in unittest. No-one has yet done the work to switch them over. It is 'on my list' though. All the best, Michael Foord Just don't put it in Demos/ . =) -Brett In its basic form you simply pick a directory and unittestgui will discover and run all the tests it finds. It would be nice if it provided more diagnostic information on tests it ran (clicking through test results) but these can be added later. All the best, Michael Foord -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list [email protected] 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/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r86351 - python/branches/py3k/Lib/tempfile.py
On Tue, 9 Nov 2010 04:43:58 +0100 (CET)
raymond.hettinger wrote:
> Author: raymond.hettinger
> Date: Tue Nov 9 04:43:58 2010
> New Revision: 86351
>
> Log:
> Simplify code
>
> Modified:
>python/branches/py3k/Lib/tempfile.py
>
> Modified: python/branches/py3k/Lib/tempfile.py
> ==
> --- python/branches/py3k/Lib/tempfile.py (original)
> +++ python/branches/py3k/Lib/tempfile.py Tue Nov 9 04:43:58 2010
> @@ -108,30 +108,19 @@
>
> _RandomNameSequence is an iterator."""
>
> -characters = ("abcdefghijklmnopqrstuvwxyz" +
> - "ABCDEFGHIJKLMNOPQRSTUVWXYZ" +
> - "0123456789_")
> +characters = "abcdefghijklmnopqrstuvwxyz0123456789_"
Aren't you reducing entropy here?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r86351 - python/branches/py3k/Lib/tempfile.py
On Tue, Nov 9, 2010 at 10:00 PM, Antoine Pitrou wrote:
>> - characters = ("abcdefghijklmnopqrstuvwxyz" +
>> - "ABCDEFGHIJKLMNOPQRSTUVWXYZ" +
>> - "0123456789_")
>> + characters = "abcdefghijklmnopqrstuvwxyz0123456789_"
>
> Aren't you reducing entropy here?
Perhaps in some cases, but it also makes the behaviour consistent
across all platforms.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking undocumented API
On Tue, 09 Nov 2010 02:03:23 - [email protected] wrote: > > I wonder if there are any actual technical arguments to be made against > something like `deprecatedModuleAttribute`? For example, does it work well with import hacks such as Mercurial's demandimport? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GUI test runner tool
On 08/11/2010 19:28, Alexander Belopolsky wrote: On Mon, Nov 8, 2010 at 7:09 AM, Michael Foord wrote: .. I'd like to propose adding [unittestgui] to Python in Tools/ and am volunteering to maintain it. Why not adding it under Lib/unittest/? I really don't want to make Tk a dependency for unittest itself. :-) I also don't want a GUI test runner to in any way be part of the *api* of unittest... I think Tools/ is a less attractive location for most users than say PyPI or some other package repository. Tools/ is for stuff that is primarily of interest to python developers, not python users. OS vendors are less likely to install packages in Tools/ in a user-visible place than they are a popular 3rd-party package. Well, there's always Demos/. ;-) I realise that putting it in Tools/ means that distros will probably have to make a conscious decision to package it. unittest2 will install it as a script. I don't think the gui runner belongs in Demos/, so Tools/ is the logical choice for including in core-Python. As Raymond says we can point to it in the docs. (The gui test runner is merely a convenience / beginners tool - so pointing to more "production suitable" tools like Hudson would also be good.) I was looking to see what else was in Tools/ that was distributed with Python, but I don't *think* the Mac distribution includes them at all. (freeze is in the Tools/ directory of the repo and is an 'end user' tool rather than core-developer tool.) The Mac distribution does put a bunch of stuff in the Python 'bin' directory, and ideally it would go there. All the best, Michael Foord ___ Python-Dev mailing list [email protected] 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/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r86355 - python/branches/py3k/Modules/_pickle.c
On Tue, 9 Nov 2010 11:23:23 -0500 Alexander Belopolsky wrote: > On Tue, Nov 9, 2010 at 4:39 AM, victor.stinner > wrote: > .. > > Log: > > Issue #10359: Remove useless comma, invalid in ISO C > > C99 allows it. Which compiler is giving you trouble? One part of the answer is that we generally try to enforce C89 compatibility. I don't know if any modern compiler would mind, though. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86355 - python/branches/py3k/Modules/_pickle.c
On Tue, Nov 9, 2010 at 4:39 AM, victor.stinner wrote: .. > Log: > Issue #10359: Remove useless comma, invalid in ISO C C99 allows it. Which compiler is giving you trouble? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking undocumented API
On 11:53 am, [email protected] wrote: On Tue, 09 Nov 2010 02:03:23 - [email protected] wrote: I wonder if there are any actual technical arguments to be made against something like `deprecatedModuleAttribute`? For example, does it work well with import hacks such as Mercurial's demandimport? I haven't tried before, but a quick experiment suggests that the two happily co-exist (aside from demandimport getting the blame instead of the true offending code, but that's really a problem with the warnings module): >>> import mercurial.demandimport as di >>> di.enable() >>> import twisted.python.threadpool as tp >>> tp.ThreadSafeList /usr/lib/pymodules/python2.6/mercurial/demandimport.py:76: DeprecationWarning: twisted.python.threadpool.ThreadSafeList was deprecated in Twisted 10.1.0: This was an internal implementation detail of support for Jython 2.1, which is now obsolete. return getattr(self._module, attr) >>> Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r86355 - python/branches/py3k/Modules/_pickle.c
On Tue, Nov 9, 2010 at 11:36 AM, Antoine Pitrou wrote: .. >> C99 allows it. Which compiler is giving you trouble? > > One part of the answer is that we generally try to enforce C89 > compatibility. I don't know if any modern compiler would mind, though. I know, but if we ever start making exceptions, this would be a particularly harmless one. There must be a reason why we don't use -std=c89 flag with the standard config. I don't think too many people remember that c89 allows trailing commas in array and struct initialization lists, but not in enum declarations. Without compiler help, enforcing this is an unnecessary maintenance burden. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r86355 - python/branches/py3k/Modules/_pickle.c
Alexander Belopolsky wrote: > On Tue, Nov 9, 2010 at 11:36 AM, Antoine Pitrou wrote: > .. > >> C99 allows it. Which compiler is giving you trouble? > > > > One part of the answer is that we generally try to enforce C89 > > compatibility. I don't know if any modern compiler would mind, though. > > I know, but if we ever start making exceptions, this would be a > particularly harmless one. There must be a reason why we don't use > -std=c89 flag with the standard config. I don't think too many people > remember that c89 allows trailing commas in array and struct > initialization lists, but not in enum declarations. Without compiler > help, enforcing this is an unnecessary maintenance burden. xlc on AIX has problems: http://bugs.python.org/issue5889 Stefan Krah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking undocumented API
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/08/2010 06:26 PM, Bobby Impollonia wrote: > This does hurt because anyone who was relying on "import *" to get a > name which is now omitted from __all__ is going to upgrade and find > their program failing with NameErrors. This is a backwards compatible > change and shouldn't happen without a deprecation warning first. Outside an interactive prompt, anyone using "from foo import *" has set themselves and their users up to lose anyway. That syntax is the single worst misfeature in all of Python. It impairs readability and discoverability for *no* benefit beyond one-time typing convenience. Module writers who compound the error by expecting to be imported this way, thereby bogarting the global namespace for their own purposes, should be fish-slapped. ;) Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzZl50ACgkQ+gerLs4ltQ5PYQCfUF2l8BjYvaZSu7ATT8/PxweH jqMAoIWD/D5KIfLp/JOdPVuWJsH/kdc/ =/349 -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86348 - in python/branches/py3k/Lib: test/test_xml_etree.py xml/etree/ElementTree.py
Hello Senthil > Author: senthil.kumaran > New Revision: 86348 > Log: Fix Issue10205 - XML QName error when different tags have same QName. > > Modified: >python/branches/py3k/Lib/test/test_xml_etree.py >python/branches/py3k/Lib/xml/etree/ElementTree.py Shouldn’t this include an entry in NEWS and maybe in ACKS? Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking undocumented API
On Nov 8, 2010, at 4:50 PM, Guido van Rossum wrote: > On Mon, Nov 8, 2010 at 3:55 PM, Glyph Lefkowitz > wrote: >> This seems like a pretty clear case of "practicality beats purity". Not >> only has nobody complained about deprecatedModuleAttribute, but there are >> tons of things which show up in sys.modules that aren't modules in the sense >> of 'instances of ModuleType'. The Twisted reactor, for example, is an >> instance, and we've been doing *that* for about 10 years with no complaints. > > But the Twisted universe is only a subset of the Python universe. The > Python stdlib needs to move more carefully. While this is true, I think the Twisted universe generally represents a particularly conservative, compatibility-conscious area within the Python universe (multiverse?). I know of several Twisted users who regularly upgrade to the most recent version of Twisted without incident, but can't move from Python 2.4->2.5 because of compatibility issues. That's not to say that there are no areas within the larger Python ecosystem that I'm unaware of where putting non-module-objects into sys.modules would cause issues. But if it were a practice that were at all common, I suspect that we would have bumped into it by now. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking undocumented API
On Tue, Nov 09, 2010 at 01:49:01PM -0500, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/08/2010 06:26 PM, Bobby Impollonia wrote: > > > This does hurt because anyone who was relying on "import *" to get a > > name which is now omitted from __all__ is going to upgrade and find > > their program failing with NameErrors. This is a backwards compatible > > change and shouldn't happen without a deprecation warning first. > > Outside an interactive prompt, anyone using "from foo import *" has set > themselves and their users up to lose anyway. > > That syntax is the single worst misfeature in all of Python. It impairs > readability and discoverability for *no* benefit beyond one-time typing > convenience. Module writers who compound the error by expecting to be > imported this way, thereby bogarting the global namespace for their own > purposes, should be fish-slapped. ;) > I think there's a valid case for bogarting the namespace in this instance, but let me know if there's a better way to do it:: # Method to use system libraries if available, otherwise use a bundled copy, # aka: make both system packagers and developers happy:: Relevant directories and files for this module:: + foo/ +- __init__.py ++ compat/ +- __init__.py ++ bar/ +- __init__.py +- _bar.py foo/compat/bar/_bar.py is a bundled module. foo/compat/bar/__init__.py has: try: from bar import * from bar import __all__ except ImportError:: from foo.compat.bar._bar import * from foo.compat.bar._bar import __all__ -Toshio pgp2MughtFdu4.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] bugs.python.org migration
bugs.python.org is moving to a new hardware; this also involves a new IP address. The migration will happen on Thursday, likely around 8:00 UTC. If all goes well, outage should be very short. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking undocumented API
On Wed, Nov 10, 2010 at 4:49 AM, Tres Seaver wrote: > Outside an interactive prompt, anyone using "from foo import *" has set > themselves and their users up to lose anyway. > > That syntax is the single worst misfeature in all of Python. It impairs > readability and discoverability for *no* benefit beyond one-time typing > convenience. Module writers who compound the error by expecting to be > imported this way, thereby bogarting the global namespace for their own > purposes, should be fish-slapped. ;) Be prepared to fish-slap all of python-dev then - we use precisely this technique to support optional acceleration modules. The pure Python versions of pairs like profile/_profile and heapq/_heapq include a try/except block at the end that does the equivalent of: try: from _accelerated import * # Allow accelerated overrides except ImportError: pass # Use pure Python versions This allows each implementation to make its own decisions about exactly which parts to accelerate without needing to change the pure Python version. In CPython itself, different *builds* may vary based on which components are available during the build process. There are utility functions provided in test.support that allow us to make sure that these modules are tested both with and without their accelerated components. The new unittest package in 2.7 and 3.2 also uses it in the module __init__ to present the old "flat" namespace despite become a package under the hood. Star imports are certainly open to abuse, but there are legitimate use cases when you want to lie about where particular APIs live in the module heirarchy. Those use cases generally involve being imported by one *specific* other module, such that anyone else importing the module directly *at all* is already doing the wrong thing. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking undocumented API
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/09/2010 03:48 PM, Toshio Kuratomi wrote: > I think there's a valid case for bogarting the namespace in this instance, > but let me know if there's a better way to do it:: > > # Method to use system libraries if available, otherwise use a bundled copy, > # aka: make both system packagers and developers happy:: > > > Relevant directories and files for this module:: > > + foo/ > +- __init__.py > ++ compat/ > +- __init__.py > ++ bar/ > +- __init__.py > +- _bar.py > > foo/compat/bar/_bar.py is a bundled module. > > foo/compat/bar/__init__.py has: > > try: > from bar import * > from bar import __all__ > except ImportError:: > from foo.compat.bar._bar import * > from foo.compat.bar._bar import __all__ I guess the usual caveats apply for dopplegangers / proxies. ;) Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzZxzAACgkQ+gerLs4ltQ5UsgCfcaxeFruJCDGnxBA0ma8Pjggg lW8AoMBx2FYg+PSA/Zbq94UbiPhKGnjO =/8QU -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
On Nov 8, 2010, at 6:08 PM, Lennart Regebro wrote: > 2010/11/8 James Y Knight : >> On Nov 8, 2010, at 4:42 AM, Lennart Regebro wrote: >>> So it can be done, but the question is "Why?" >> >> To keep the batteries included? > > But they'll only be included in > 2.7, which won't be used much, [...] If there was going to be an official python.org sanctioned Python 2.8 release, I'm not at all sure that'd be the case. Since there isn't going to be one, then yes, that's probably true. James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86348 - in python/branches/py3k/Lib: test/test_xml_etree.py xml/etree/ElementTree.py
Hello Éric, On Tue, Nov 09, 2010 at 08:46:41PM +0100, Éric Araujo wrote: > > Shouldn’t this include an entry in NEWS and maybe in ACKS? It was a very simple bug fix (caused due to an overlook initially), so did not add NEWS/ACKS. For features, larger fixes or complete patches, I the add NEWS and ACKS as appropriate. Thanks, Senthil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking undocumented API
Nick Coghlan writes: > > Module writers who compound the error by expecting to be imported > > this way, thereby bogarting the global namespace for their own > > purposes, should be fish-slapped. ;) > > Be prepared to fish-slap all of python-dev then - we use precisely > this technique to support optional acceleration modules. The pure > Python versions of pairs like profile/_profile and heapq/_heapq > include a try/except block at the end that does the equivalent of: > > try: > from _accelerated import * # Allow accelerated overrides > except ImportError: > pass # Use pure Python versions But these identifiers will appear at the module level, not global, no? Otherwise this technique couldn't be used. I don't really understand what Tres is talking about when he writes "modules that expect to be imported this way". The *imported* module shouldn't care, no? This is an issue for the *importing* code to deal with. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
James Y Knight writes: > > On Nov 8, 2010, at 6:08 PM, Lennart Regebro wrote: > > > 2010/11/8 James Y Knight : > >> On Nov 8, 2010, at 4:42 AM, Lennart Regebro wrote: > >>> So it can be done, but the question is "Why?" > >> > >> To keep the batteries included? > > > > But they'll only be included in > 2.7, which won't be used much, [...] > > If there was going to be an official python.org sanctioned Python > 2.8 release, I'm not at all sure that'd be the case. Since there > isn't going to be one, then yes, that's probably true. Which pretty much demonstrates that the argument for a sanctioned 2.8 is weak, and ditto for adding features to 2.7. Python 2.7 is a great language; existing projects which need to go beyond that need to port to a different language. The OP is already doing that IIUC: Stackless is a pretty faithful implementation of Python (in several versions of the language, too!), but not quite 100%, right? OTOH, how many derivatives has C spawned? Or Pascal, FORTRAN, LISP? ML? And people continue to find that variety *constraining*, and invent new languages! python-dev's decision to offer that different language as Python 3, where *almost all* of your skills will upgrade transparently (even though unfortunately a lot of code won't, at least not today), is probably a great boon to developers *in* Python. Time will tell. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
