I've posted a very preliminary Python 3.3 release schedule as PEP 398. The final release is set to be about 18 months after 3.2 final, which is in August 2012. For 3.3, I'd like to revive the tradition of listing planned large-scale changes in the PEP. Please let me know if you plan any such changes, at any time. (If they aren't codified in PEP form, we should think about whether they should be.) The "Candidate PEPs" I listed are those open PEPs that in my opinion have the highest chance to be accepted and implemented for 3.3. It is by no means binding. cheers, Georg
Hi Georg, On 03/23/2011 03:56 PM, Georg Brandl wrote:
For 3.3, I'd like to revive the tradition of listing planned large-scale changes in the PEP. Please let me know if you plan any such changes, at any time. (If they aren't codified in PEP form, we should think about whether they should be.)
Over in distutils-sig there's been extensive discussion at and since PyCon of a built-in Python virtual-environment tool, similar to virtualenv, targeted hopefully for 3.3. This is something that's seen some discussion on python-dev previously; I now have a working prototype and am working on a PEP. When the PEP is ready I'll bring it up for discussion on python-ideas and then python-dev; anyone interested in checking it out sooner can go read the discussions at distutils-sig. Carl
On Thu, Mar 24, 2011 at 5:56 AM, Georg Brandl <g.brandl@gmx.net> wrote:
For 3.3, I'd like to revive the tradition of listing planned large-scale changes in the PEP. Please let me know if you plan any such changes, at any time. (If they aren't codified in PEP form, we should think about whether they should be.)
I would add a note about a "standardised event loop interface" - that's a PEP idea that came up at the language summit, and LvH plans to write it with support from the Twisted crew and others. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Thu, Mar 24, 2011 at 00:12, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Thu, Mar 24, 2011 at 5:56 AM, Georg Brandl <g.brandl@gmx.net> wrote:
For 3.3, I'd like to revive the tradition of listing planned large-scale changes in the PEP. Please let me know if you plan any such changes, at any time. (If they aren't codified in PEP form, we should think about whether they should be.)
I would add a note about a "standardised event loop interface" - that's a PEP idea that came up at the language summit, and LvH plans to write it with support from the Twisted crew and others.
It ended up that Jim Fulton is actually writing the PEP (with input from Twisted people and others.) -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
On Thu, Mar 24, 2011 at 12:18 AM, Thomas Wouters <thomas@python.org> wrote:
It ended up that Jim Fulton is actually writing the PEP (with input from Twisted people and others.)
-- Thomas Wouters <thomas@python.org>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Well, if help is still needed I'll gladly chip in. It's not that I'm not interested in doing it -- it's just that I don't know who's supposed to or who's working on it :) -- cheers lvh
On 26/03/2011 00:33, Laurens Van Houtven wrote:
On Thu, Mar 24, 2011 at 12:18 AM, Thomas Wouters <thomas@python.org <mailto:thomas@python.org>> wrote:
It ended up that Jim Fulton is actually writing the PEP (with input from Twisted people and others.)
-- Thomas Wouters <thomas@python.org <mailto:thomas@python.org>>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Well, if help is still needed I'll gladly chip in. It's not that I'm not interested in doing it -- it's just that I don't know who's supposed to or who's working on it :)
Hey lvh, It's worth following this up. If Jim Fulton hasn't had time to move this forward and you have the bandwidth to work on it then it would be great to see some action. All the best, Michael Foord
-- cheers lvh
_______________________________________________ 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/fuzzyman%40voidspace.org.u...
-- 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
On 23/03/2011 19:56, Georg Brandl wrote:
I've posted a very preliminary Python 3.3 release schedule as PEP 398. The final release is set to be about 18 months after 3.2 final, which is in August 2012.
For 3.3, I'd like to revive the tradition of listing planned large-scale changes in the PEP. Please let me know if you plan any such changes, at any time. (If they aren't codified in PEP form, we should think about whether they should be.)
The "Candidate PEPs" I listed are those open PEPs that in my opinion have the highest chance to be accepted and implemented for 3.3. It is by no means binding.
During the language summit we also discussed formalising in a pep the rule that all modules that have a pure python form and a C accelerator must keep the pure python and C form precisely in sync and the same tests must be run against both. Brett said he would write the pep after he has switched import to use importlib... There was also the "compatibility warning", probably enabled by a command line flag, that would warn on the use of CPython specific implementation details (for example using non-string keys in class dicts). There is no owner for this as a PEP. They're both mentioned in Nick Coghlan's summary: http://www.boredomandlaziness.org/2011/03/python-language-summit-highlights.... Another item discussed at the language summit was moving the standard library into its own repository. Jesse Noller started working on a PEP but it stalled waiting for the transition to mercurial and I don't know if he is volunteering to pick up the PEP again now that has happened. All the best, Michael Foord
cheers, Georg
_______________________________________________ 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/fuzzyman%40voidspace.org.u...
-- 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
Le mercredi 23 mars 2011 à 20:56 +0100, Georg Brandl a écrit :
For 3.3, I'd like to revive the tradition of listing planned large-scale changes in the PEP. Please let me know if you plan any such changes, at any time. (If they aren't codified in PEP form, we should think about whether they should be.)
I am still working on the import machinery to fix last bugs related to Unicode. So it will be possible to do an useless "import café" in Python 3.3, on any platform. But it is not really an huge change (for the user, but an huge change in the code ;-)). I will probably add my faulthandler module into 3.3. Victor
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/03/11 20:56, Georg Brandl wrote:
For 3.3, I'd like to revive the tradition of listing planned large-scale changes in the PEP.
I want to integrate dependence injection in the stdlib, specially in libs creating sockets. This would be an optional feature. The idea would be, for instance, that smtplib could call an optional constructor to create a socket-like object, if some is provided. That would break the implicit dependency with sockets, reduce monkey-patching need, and ease testing the libs. I proposed this on the list like a year ago. Somebody else said he was planning a PEP... not done yet, I guess. Digging the archive: <http://mail.python.org/pipermail/python-dev/2010-April/099237.html> - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@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/ iQCVAwUBTYqnDplgi5GaxT1NAQJTxQP/U9dk4x9r9Fbwm7zEzEMydzxqqiY/FF6z PA52YDRPUgyeiDnhmZwk1f9PqnwYWkgf2qmDi+v0eXLZJYqs/rBEcaY36yP1sgP+ +RrFp4aTpf6oqp7HSwrJMoOS2BmRZxLmzShfKecX+3q33Ix1C1EvcF8F8Yg4P4s6 Pd+jRaGvJRs= =Ec5o -----END PGP SIGNATURE-----
On 24/03/2011 02:06, Jesus Cea wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
For 3.3, I'd like to revive the tradition of listing planned large-scale changes in the PEP. I want to integrate dependence injection in the stdlib, specially in
On 23/03/11 20:56, Georg Brandl wrote: libs creating sockets. This would be an optional feature.
The idea would be, for instance, that smtplib could call an optional constructor to create a socket-like object, if some is provided.
That would break the implicit dependency with sockets, reduce monkey-patching need, and ease testing the libs.
In general I dislike dependency injection if it's only done for testability. With monkey patching (if done right) you can safely test Python code without messing with your public interfaces just to make code testable. A clean solution that does monkey patching correctly for us, for use within our own tests would be a better solution in my opinion. All the best, Michael Foord
I proposed this on the list like a year ago. Somebody else said he was planning a PEP... not done yet, I guess.
Digging the archive: <http://mail.python.org/pipermail/python-dev/2010-April/099237.html>
- -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@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/
iQCVAwUBTYqnDplgi5GaxT1NAQJTxQP/U9dk4x9r9Fbwm7zEzEMydzxqqiY/FF6z PA52YDRPUgyeiDnhmZwk1f9PqnwYWkgf2qmDi+v0eXLZJYqs/rBEcaY36yP1sgP+ +RrFp4aTpf6oqp7HSwrJMoOS2BmRZxLmzShfKecX+3q33Ix1C1EvcF8F8Yg4P4s6 Pd+jRaGvJRs= =Ec5o -----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/fuzzyman%40voidspace.org.u...
-- 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
On 24 March 2011 02:16, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
On 24/03/2011 02:06, Jesus Cea wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 23/03/11 20:56, Georg Brandl wrote:
For 3.3, I'd like to revive the tradition of listing planned large-scale changes in the PEP.
I want to integrate dependence injection in the stdlib, specially in libs creating sockets. This would be an optional feature.
The idea would be, for instance, that smtplib could call an optional constructor to create a socket-like object, if some is provided.
That would break the implicit dependency with sockets, reduce monkey-patching need, and ease testing the libs.
In general I dislike dependency injection if it's only done for testability. With monkey patching (if done right) you can safely test Python code without messing with your public interfaces just to make code testable.
Though in this case this sounds interesting to me as it would allow using stdlib modules with e.g. "green" sockets from eventlet or gevent without having to revert to monkey patching (which I don't mind for testing but dislike for production). In a way I'm always a little disappointed when a library uses sockets out of my reach, ideally you'd be able to use a library abstracted away from this so you can plug in into async frameworks and other things the author didn't foresee. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org
On 24/03/2011 02:06, Jesus Cea wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
For 3.3, I'd like to revive the tradition of listing planned large-scale changes in the PEP. I want to integrate dependence injection in the stdlib, specially in
On 23/03/11 20:56, Georg Brandl wrote: libs creating sockets. This would be an optional feature.
The idea would be, for instance, that smtplib could call an optional constructor to create a socket-like object, if some is provided.
That would break the implicit dependency with sockets, reduce monkey-patching need, and ease testing the libs.
I proposed this on the list like a year ago. Somebody else said he was planning a PEP... not done yet, I guess.
Digging the archive: <http://mail.python.org/pipermail/python-dev/2010-April/099237.html>
Although from this email it seems like it is for much more than just testability, in which case go ahead. :-) Michael
- -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@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/
iQCVAwUBTYqnDplgi5GaxT1NAQJTxQP/U9dk4x9r9Fbwm7zEzEMydzxqqiY/FF6z PA52YDRPUgyeiDnhmZwk1f9PqnwYWkgf2qmDi+v0eXLZJYqs/rBEcaY36yP1sgP+ +RrFp4aTpf6oqp7HSwrJMoOS2BmRZxLmzShfKecX+3q33Ix1C1EvcF8F8Yg4P4s6 Pd+jRaGvJRs= =Ec5o -----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/fuzzyman%40voidspace.org.u...
-- 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
On Wed, Mar 23, 2011 at 9:56 PM, Georg Brandl <g.brandl@gmx.net> wrote:
I've posted a very preliminary Python 3.3 release schedule as PEP 398. The final release is set to be about 18 months after 3.2 final, which is in August 2012.
Why this isn't being added to Release Calendar on the front page? Do you have an estimate of Python 3.2.1 release?
Am 02.04.2011 15:00, schrieb anatoly techtonik:
On Wed, Mar 23, 2011 at 9:56 PM, Georg Brandl <g.brandl@gmx.net> wrote:
I've posted a very preliminary Python 3.3 release schedule as PEP 398. The final release is set to be about 18 months after 3.2 final, which is in August 2012.
Why this isn't being added to Release Calendar on the front page?
It is.
Do you have an estimate of Python 3.2.1 release?
Not yet. Georg
Le samedi 02 avril 2011 à 16:00 +0300, anatoly techtonik a écrit :
Do you have an estimate of Python 3.2.1 release?
FYI I introduced (and then fixed) two regressions specific to Windows in Python 3.2: http://bugs.python.org/issue11272 (input) http://bugs.python.org/issue11395 (print) Issue #11272 is annoying: input() returns a string ending a string ending by '\r'. The workaround is input().rstrip('\r')or input().rstrip(). The second end is more a corner case: print fails if you write more than 60,000 bytes at once. Victor
participants (10)
-
anatoly techtonik -
Carl Meyer -
Floris Bruynooghe -
Georg Brandl -
Jesus Cea -
Laurens Van Houtven -
Michael Foord -
Nick Coghlan -
Thomas Wouters -
Victor Stinner