Re: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On Sun, Feb 13, 2011 at 2:20 PM, wrote: >> The desire is there, but it's a hard problem. There was a similar >> discussion before PyCon 2009, but not much came of it: >> >> http://mail.python.org/pipermail/python-dev/2009-March/086678.html > > I started working on a PEP last year, but I didn't get very far partly > because I doubted the desire. > > What part do you think is a hard problem? Convincing people to switch to a > new API? *Defining* the new API doesn't seem very hard to me. If there is an essential subset of the API that the Twisted devs think would be a suitable replacement for asyncore, while providing a more straightforward migration path into Twisted itself, then it certainly makes sense to include it. The other possible sticking point I can see is that I don't know how Twisted's licensing works - is there anyone with the legal authority to appropriately license the code to the PSF for inclusion in the standard library? Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On Sun, 13 Feb 2011 19:18:52 +1000 Nick Coghlan wrote: > > If there is an essential subset of the API that the Twisted devs think > would be a suitable replacement for asyncore, while providing a more > straightforward migration path into Twisted itself, then it certainly > makes sense to include it. That subset would be the reactor (actually, the various reactor implementations) and its close dependencies. However, that might already amount to a sizeable chunk of code :-) (for good reason, of course: even Twisted Core does much, much more than asyncore). > The other possible sticking point I can see is that I don't know how > Twisted's licensing works - is there anyone with the legal authority > to appropriately license the code to the PSF for inclusion in the > standard library? Twisted's license is MIT-like so I don't think there would be any so-called "licensing" problem. :-) 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] r88395 - python/branches/py3k/Lib/asyncore.py
On 13/02/2011 14:23, Antoine Pitrou wrote: On Sun, 13 Feb 2011 19:18:52 +1000 Nick Coghlan wrote: If there is an essential subset of the API that the Twisted devs think would be a suitable replacement for asyncore, while providing a more straightforward migration path into Twisted itself, then it certainly makes sense to include it. That subset would be the reactor (actually, the various reactor implementations) and its close dependencies. However, that might already amount to a sizeable chunk of code :-) (for good reason, of course: even Twisted Core does much, much more than asyncore). It would then be subject to python-dev development policy rather than twisted dev policy (which is even stricter!). Would the twisted devs *really* want that? We could use the same processes we have for "externally maintained" libraries, but they have without fail caused us problems. This is usually due to maintainers leaving or going dark, which *probably* wouldn't be the case with twisted, nonetheless we've been burned enough times to be cautious about adding new "externally maintained" packages to the standard library. Not to mention that the twisted tests have quite a few "non standard library" dependencies, so integrating it would be non-trivial. That's after it has been ported to Python 3. The other issue is that just because we provide an alternative doesn't mean that everyone automatically stops using asyncore and migrates. That means the maintenance burden of asyncore doesn't necessarily go away, we just add a new maintenance burden (albeit one with lots of advantages - certainly in principle it would be *great* to have twisted-core in the standard library). The other possible sticking point I can see is that I don't know how Twisted's licensing works - is there anyone with the legal authority to appropriately license the code to the PSF for inclusion in the standard library? Twisted's license is MIT-like so I don't think there would be any so-called "licensing" problem. :-) That's not sufficient (IIUC). The code *authors* (copyright owners) have to agree, and probably have to sign contributor agreements. :-) Twisted have gone through an IP management process already I believe, so it is certainly possible. Michael 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
> It would then be subject to python-dev development policy rather than > twisted dev policy (which is even stricter!). Would the twisted devs > *really* want that? We could use the same processes we have for > "externally maintained" libraries, but they have without fail caused us > problems. Oh, I agree with you. -1 on any new externally maintained library. > The other issue is that just because we provide an alternative doesn't > mean that everyone automatically stops using asyncore and migrates. Of course. asyncore's problem is not that its a maintenance burden, it's that it's really subpar compared to everything else out there. That said, Giampaolo has committed to taking it forward, so perhaps the 3.3 version of asyncore will be much (?) better. > >> The other possible sticking point I can see is that I don't know how > >> Twisted's licensing works - is there anyone with the legal authority > >> to appropriately license the code to the PSF for inclusion in the > >> standard library? > > Twisted's license is MIT-like so I don't think there would be any > > so-called "licensing" problem. :-) > > > That's not sufficient (IIUC). The code *authors* (copyright owners) have > to agree, and probably have to sign contributor agreements. :-) Well, of course. Or at least that's the theory. In practice, the algebra of open source licenses is quite well-known and non-copyleft code usually can be combined freely without any worries. (and do you think the zlib authors signed a contributor agreement for inclusion in Python distributions? :-)) > Twisted > have gone through an IP management process already I believe, so it is > certainly possible. "IP management process"? What is that horrible jargon supposed to mean? :) I don't think the Twisted people are into legalese, and I've never signed an agreement when contributing (admittedly little) code to Twisted. They did relicense Twisted once (from LGPL to MIT-like), but that probably means they asked every past contributor. 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
[Python-Dev] Rights on the tracker
Hi python-devs, I'm currently working on distutils2, and I'm trying to stop having different informations in different places. This means using the bugs.python.org bugtracker, instead of some weird TODO-lists in the bitbucket wiki. Two requests then: * Is it possible to give me the rights to edit the reports for the distutils2 component ? * Is it possible to automatically be in the noisy list for distutils2' bug reports ? Tarek co-opts this. My roundup username is "alexis". Thanks, Alex ___ 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] Rights on the tracker
On 2/13/2011 9:47 AM, Alexis Métaireau wrote: Tarek co-opts this. Do you meant that Tarek supports or approves of this? (Co-opt means something rather different in English.) -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rights on the tracker
Le 13/02/2011 15:40, Terry Reedy a écrit : > Do you meant that Tarek supports or approves of this? > (Co-opt means something rather different in English.) Sorry, I mean that Tarek approves that :-) ___ 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] Rights on the tracker
Hi, I’ve wanted to move our TODO wiki page to the bug tracker for months, thanks for doing it! Auto-nosy is useful to catch new bugs; for existing bugs, instead of adding yourself manually to each one and trigger not-so-useful email, a tracker admin could add you automatically. I’ve asked on http://psf.upfronthosting.co.za/roundup/meta/issue362 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] Rights on the tracker
Le 13/02/2011 16:12, Éric Araujo a écrit : > Hi, > > I’ve wanted to move our TODO wiki page to the bug tracker for months, > thanks for doing it! Auto-nosy is useful to catch new bugs; for > existing bugs, instead of adding yourself manually to each one and > trigger not-so-useful email, a tracker admin could add you > automatically. I’ve asked on > http://psf.upfronthosting.co.za/roundup/meta/issue362 Great, thanks for that :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
[email protected] wrote: On 10:46 pm, [email protected] wrote: On Sun, 13 Feb 2011 11:19:06 +1300 Greg Ewing wrote: I was thinking of something lighter-weight than that. Twisted Core I just had a look at the docs for Twisted Core, and it lists 10 sub-modules. The only one that really looks "core" to me is twisted.internet. Drilling into that reveals another 39 public sub-sub-modules and 10 private ones. Sorry, but you'll have to chop it back quite a bit more than that before it's focused enough to be a stlib module, I think. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On 08:06 pm, [email protected] wrote: [email protected] wrote: On 10:46 pm, [email protected] wrote: On Sun, 13 Feb 2011 11:19:06 +1300 Greg Ewing wrote: I was thinking of something lighter-weight than that. Twisted Core I just had a look at the docs for Twisted Core, and it lists 10 sub-modules. The only one that really looks "core" to me is twisted.internet. Drilling into that reveals another 39 public sub-sub-modules and 10 private ones. Sorry, but you'll have to chop it back quite a bit more than that before it's focused enough to be a stlib module, I think. Excluding stuff is not hard, seriously. It's not hard to see that wxPython integration doesn't belong in the stdlib. There are more useful aspects of the task to discuss. 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] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On Mon, Feb 14, 2011 at 8:11 AM, wrote: > > Excluding stuff is not hard, seriously. It's not hard to see that wxPython > integration doesn't belong in the stdlib. There are more useful aspects of > the task to discuss. I think part of the problem is that those of us that aren't Twisted users aren't familiar enough with it to know which of the elements in twisted.internet would be important to include in a stdlib "reactor" package (or whatever it ended up being called). So we see the size of twisted.internet and start to get nervous. Our fears may be unfounded in practice, but we don't know that up front. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On Mon, Feb 14, 2011 at 8:11 AM, wrote: > On 08:06 pm, [email protected] wrote: >> >> [email protected] wrote: >>> >>> On 10:46 pm, [email protected] wrote: > > On Sun, 13 Feb 2011 11:19:06 +1300 > Greg Ewing wrote: I was thinking of something lighter-weight than that. >>> >>> Twisted Core >> >> I just had a look at the docs for Twisted Core, and it lists >> 10 sub-modules. The only one that really looks "core" to me >> is twisted.internet. Drilling into that reveals another >> 39 public sub-sub-modules and 10 private ones. >> >> Sorry, but you'll have to chop it back quite a bit more than >> that before it's focused enough to be a stlib module, I think. > > Excluding stuff is not hard, seriously. It's not hard to see that wxPython > integration doesn't belong in the stdlib. There are more useful aspects of > the task to discuss. I don't mean to but in here and I may have no business doing so... But what about circuits.core ? cheers James -- -- James Mills -- -- "Problems are solved by method" ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On 13/02/2011 22:24, James Mills wrote: On Mon, Feb 14, 2011 at 8:11 AM, wrote: On 08:06 pm, [email protected] wrote: [email protected] wrote: On 10:46 pm, [email protected] wrote: On Sun, 13 Feb 2011 11:19:06 +1300 Greg Ewing wrote: I was thinking of something lighter-weight than that. Twisted Core I just had a look at the docs for Twisted Core, and it lists 10 sub-modules. The only one that really looks "core" to me is twisted.internet. Drilling into that reveals another 39 public sub-sub-modules and 10 private ones. Sorry, but you'll have to chop it back quite a bit more than that before it's focused enough to be a stlib module, I think. Excluding stuff is not hard, seriously. It's not hard to see that wxPython integration doesn't belong in the stdlib. There are more useful aspects of the task to discuss. I don't mean to but in here and I may have no business doing so... But what about circuits.core ? Well, what about it? The virtue of twisted is that even if we haven't all used it, we've all heard of it. That speaks volumes about its penetration into the python world. Note that the requirements for inclusion in the standard library (and at this point the conversation should really move to python-ideas) are *ideally*: * well established and widely used * well written and tested (including working on the major platforms that python runs on) * solves a common problem * the "owners" are submitting the code for conclusion and we have someone (preferably more than one) commited to maintaining the code in the core for the forseeable future * can be integrated with python-as-it-is-at-the-moment without bringing in new dependencies that *shouldn't* go into python core Twisted certainly meets the first three of those requirements, the last two are uncertain and still being discussed. We *don't* go around fishing for projects to include which is why we haven't suggested alternatives. There has been ongoing musing about including parts of twisted for many years however, and the core contributor to this discussion (Jean-Paul Calderone) is one of the lead developers of twisted. I think if we *were* going to include an alternative async event loop into the Python standard library there would have to be very good reasons for it *not* to be twisted, just because of the prominence of twisted within the python ecosystem. All the best, Michael Foord cheers James -- 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On Mon, Feb 14, 2011 at 8:36 AM, Michael Foord wrote: > Well, what about it? The virtue of twisted is that even if we haven't all > used it, we've all heard of it. That speaks volumes about its penetration > into the python world. Just a mere suggestion. The fact that this discussion exists means that Twisted may end up being in the std. lib in the end because no-one can come up with a better? solution that meets "all" requirements. In any case, there are other alternatives. I realize we're not discussing them but it's nice to know what is and can be included in the std. lib, etc. I'll just follow and keep quiet now :) cheers James -- -- James Mills -- -- "Problems are solved by method" ___ 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] Rights on the tracker
On Sun, 13 Feb 2011 14:47:01 + Alexis Métaireau wrote: > > * Is it possible to give me the rights to edit the reports for the > distutils2 component ? Done. Actually, you have general developer rights, since there doesn't seem to be a way (in the GUI) to restrict those to a specific component. > * Is it possible to automatically be in the noisy list for distutils2' > bug reports ? Someone else with the right knowledge and power will have to do that. 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] Rights on the tracker
Le 13/02/2011 23:16, Antoine Pitrou a écrit : > On Sun, 13 Feb 2011 14:47:01 + > Alexis Métaireau wrote: >> >> * Is it possible to give me the rights to edit the reports for the >> distutils2 component ? > > Done. Actually, you have general developer rights, since there doesn't > seem to be a way (in the GUI) to restrict those to a specific component. Thanks ! > Someone else with the right knowledge and power will have to do that. Okay, there is an issue on the tracker's tracker, as Éric told. Cheers, Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
On 2/13/2011 5:23 PM, Nick Coghlan wrote: On Mon, Feb 14, 2011 at 8:11 AM, wrote: Excluding stuff is not hard, seriously. It's not hard to see that wxPython integration doesn't belong in the stdlib. There are more useful aspects of the task to discuss. I think part of the problem is that those of us that aren't Twisted users aren't familiar enough with it to know which of the elements in twisted.internet would be important to include in a stdlib "reactor" package (or whatever it ended up being called). To me, this is what a PEP would be for -- to present a concrete proposal listing inclusions that could be evaluated. The someone familiar with asyncore could compare feature lists to decide if the new module would have everything needed without too much other stuff. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.2 rc 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I'm happy to announce the third release candidate of Python 3.2. Python 3.2 is a continuation of the efforts to improve and stabilize the Python 3.x line. Since the final release of Python 2.7, the 2.x line will only receive bugfixes, and new features are developed for 3.x only. Since PEP 3003, the Moratorium on Language Changes, is in effect, there are no changes in Python's syntax and built-in types in Python 3.2. Development efforts concentrated on the standard library and support for porting code to Python 3. Highlights are: * numerous improvements to the unittest module * PEP 3147, support for .pyc repository directories * PEP 3149, support for version tagged dynamic libraries * PEP 3148, a new futures library for concurrent programming * PEP 384, a stable ABI for extension modules * PEP 391, dictionary-based logging configuration * an overhauled GIL implementation that reduces contention * an extended email package that handles bytes messages * a much improved ssl module with support for SSL contexts and certificate hostname matching * a sysconfig module to access configuration information * additions to the shutil module, among them archive file support * many enhancements to configparser, among them mapping protocol support * improvements to pdb, the Python debugger * countless fixes regarding bytes/string issues; among them full support for a bytes environment (filenames, environment variables) * many consistency and behavior fixes for numeric operations For a more extensive list of changes in 3.2, see http://docs.python.org/3.2/whatsnew/3.2.html To download Python 3.2 visit: http://www.python.org/download/releases/3.2/ Please consider trying Python 3.2 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.2's contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1YzkAACgkQN9GcIYhpnLAggwCfQ92djMinrmNkGI4Ma3VRqrcX EWIAn16kTEJtvEH/7DJApp7YdhnmIRBd =NJ1B -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
