Re: [Python-Dev] Rework nntlib?
On Wed, 15 Sep 2010 01:06:29 pm geremy condra wrote: > I ran some statistics on the number of times modules out of the > stdlib got imported a few months ago What do those statistics measure? The number of individual import statements with a given module name? The number of times those imports are actually executed? Something else? > and came up with a reasonably > comprehensive list of the least-used things in the stdlib. Least used by whom? > I'm not sure what the name of the library was originally, but the > word 'gopher' does not appear in any of the imports that I was able > to parse in pypi. By contrast, nntplib and poplib are tied at 8 [...] I don't know how to interpret that. Does that mean that there are eight modules in the whole of PyPi which import nntplib or poplib? If so, what does that tell us? Those eight modules could have three users between them, or they could be critical infrastructure for a quarter of the Internet. I'm not trying to belittle the stats you have gathered, but without the context of *what* the numbers represent, it's impossible to put any meaning to them. -- Steven D'Aprano ___ 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] Rework nntlib?
On Wed, Sep 15, 2010 at 09:18:19PM +1000, Steven D'Aprano wrote: > I'm not trying to belittle the stats you have gathered, but without the > context of *what* the numbers represent, it's impossible to put any > meaning to them. I thought Geremy mentioned somewhere that he collected those metrics as number of times the stdlib modules were imported by the packages in the pypi infrastructure. -- 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] Rework nntlib?
On Wed, Sep 15, 2010 at 4:18 AM, Steven D'Aprano wrote: > On Wed, 15 Sep 2010 01:06:29 pm geremy condra wrote: > >> I ran some statistics on the number of times modules out of the >> stdlib got imported a few months ago > > What do those statistics measure? > > The number of individual import statements with a given module name? The > number of times those imports are actually executed? Something else? Not to put too fine a point on it, but I already told you that. It's the number of packages on pypi that imported each of those, and I measured it by parsing for import statements. >> and came up with a reasonably >> comprehensive list of the least-used things in the stdlib. > > Least used by whom? Not to be pedantic, but there isn't a good answer to a question as vague as this. If you want a piece of information, ask for it and I'll tell you if I can get it or not. >> I'm not sure what the name of the library was originally, but the >> word 'gopher' does not appear in any of the imports that I was able >> to parse in pypi. By contrast, nntplib and poplib are tied at 8 > [...] > > > I don't know how to interpret that. Does that mean that there are eight > modules in the whole of PyPi which import nntplib or poplib? If so, > what does that tell us? Those eight modules could have three users > between them, or they could be critical infrastructure for a quarter of > the Internet. Yup. The closest I could come to representing that would be by the number of downloads, and IIRC I have that information laying around here somewhere. It would probably be several days before I could get ahold of it though. > I'm not trying to belittle the stats you have gathered, but without the > context of *what* the numbers represent, it's impossible to put any > meaning to them. Not really. It's a metric of use, and as such a starting point in a discussion. After that I wouldn't take it too seriously no matter what metric is applied- looking at the number of downloads on pypi it's a fairly small sample anyway. Geremy Condra ___ 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] Rework nntlib?
On Wed, Sep 15, 2010 at 10:06 PM, geremy condra wrote: > Not really. It's a metric of use, and as such a starting point in a > discussion. After that I wouldn't take it too seriously no matter what > metric is applied- looking at the number of downloads on pypi it's a > fairly small sample anyway. Agreed. Still an interesting snapshot though. 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] r84823 - python/branches/py3k/Doc/reference/expressions.rst
On Wed, Sep 15, 2010 at 10:09 AM, raymond.hettinger wrote: > +The formal syntax makes no special provision for negative indices in > +sequences; however, built-in sequences all provide a :meth:`__getitem__` > +method that interprets negative indices by adding the length of the sequence > +to the index (so that ``x[-1]`` selects the last item of ``x``). The > +resulting value must be a nonnegative integer less than the number of items > in > +the sequence, and the subscription selects the item whose index is that value > +(counting from zero). Since the support for negative indices and slicing > +occurs in the object's :meth:`__getitem__` method, subclasses overriding > +this method will need to explicitly add that support. Perhaps mention the slice.indices(len) helper for performing the standard conversion from negative indices to positive ones when dealing with negative indices *in* slices? 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] Rework nntlib?
On Wed, Sep 15, 2010 at 9:57 AM, Steve Holden wrote: > And again I say, if anyone knows of any budgets to which this work is > important, the PSF will be happy to try and tap these people for money > that can help the development effort. Frankly I am a little embarrassed > by the poor quality of some library code. > > I think it shows that the "rush to release" which might not have been in > Python's best short-term interests, even though actually getting it out > the door was a significant occurrence for the long term.. I'm not sure we would ever have realised the full implications of the bytes/str split without pushing 3.0 out the door when we did. And it was the early feedback on 3.0 that showed 3.1 really was necessary to deal with the I/O performance issue. I agree the current state of things is not ideal, but I don't think it's a given waiting longer to release 3.x would have actually helped anything (and there is already code out there showing that, so long as you don't need the modules with bytes/unicode issues, Python 3 is very usable). 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] Rework nntlib?
On Tue, Sep 14, 2010 at 7:57 PM, Steve Holden wrote: > On 9/14/2010 6:45 PM, R. David Murray wrote: >> On Tue, 14 Sep 2010 16:34:33 +0530, Senthil Kumaran >> wrote: >>> On Tue, Sep 14, 2010 at 12:44:30PM +0200, Baptiste Carvello wrote: > Antoine> Like the email package, nntplib in py3k is broken (because of > Antoine> various bytes/str mismatches; I suppose the lack of a test > Antoine> suite didn't help when porting). > > How heavily used is nntp these days (unless you're looking for spam)? > Would > it make more sense to find someone willing to maintain it outside the > Python > core and just remove it altogether? > Reading this from GMANE ;-) >>> >>> I guess, Skip's question or intention was, how often nntplib as a >>> module is being used these days to write scripts/tools or clients? >>> Very rarely. >>> >>> It would definitely be interesting to know, if there are python >>> applications out there which are using nntplib at the moment. >> >> You all might find it interesting to know that I'm now maintaining >> email and working on email6 as a direct consequence of nntplib. I was >> using it to read mailing lists through gmane, and when I tried to >> port my nntp tool to Python3 I found that decode_header (among >> other things) was broken, and as a consequence of talking to Barry >> about that walked in to the email minefield >> >> I'm currently not using my nttp reader, but it is because I couldn't >> stand working on my client in Python2, I wanted to be using Python3. >> So I volunteered to help with email...but I figure I'll come back around >> and help Antoine with nttplib by and by :) >> > And again I say, if anyone knows of any budgets to which this work is > important, the PSF will be happy to try and tap these people for money > that can help the development effort. Frankly I am a little embarrassed > by the poor quality of some library code. > > I think it shows that the "rush to release" which might not have been in > Python's best short-term interests, even though actually getting it out > the door was a significant occurrence for the long term.. > > regards > Steve Without the release we probably would not have found out about these issues; no one seems to take the betas or alphas for serious test drives (to be expected) with real code, so yeah, in hindsight, there are issues - but then again, they would have been fixed if everyone had really known about them in advance. No one wants to ship something with horrible bugs in it. ___ 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] Rework nntlib?
On 9/15/2010 10:02 AM, Jesse Noller wrote: > On Tue, Sep 14, 2010 at 7:57 PM, Steve Holden wrote: >> On 9/14/2010 6:45 PM, R. David Murray wrote: >>> On Tue, 14 Sep 2010 16:34:33 +0530, Senthil Kumaran >>> wrote: On Tue, Sep 14, 2010 at 12:44:30PM +0200, Baptiste Carvello wrote: >>Antoine> Like the email package, nntplib in py3k is broken (because of >>Antoine> various bytes/str mismatches; I suppose the lack of a test >>Antoine> suite didn't help when porting). >> >> How heavily used is nntp these days (unless you're looking for spam)? >> Would >> it make more sense to find someone willing to maintain it outside the >> Python >> core and just remove it altogether? >> > Reading this from GMANE ;-) I guess, Skip's question or intention was, how often nntplib as a module is being used these days to write scripts/tools or clients? Very rarely. It would definitely be interesting to know, if there are python applications out there which are using nntplib at the moment. >>> >>> You all might find it interesting to know that I'm now maintaining >>> email and working on email6 as a direct consequence of nntplib. I was >>> using it to read mailing lists through gmane, and when I tried to >>> port my nntp tool to Python3 I found that decode_header (among >>> other things) was broken, and as a consequence of talking to Barry >>> about that walked in to the email minefield >>> >>> I'm currently not using my nttp reader, but it is because I couldn't >>> stand working on my client in Python2, I wanted to be using Python3. >>> So I volunteered to help with email...but I figure I'll come back around >>> and help Antoine with nttplib by and by :) >>> >> And again I say, if anyone knows of any budgets to which this work is >> important, the PSF will be happy to try and tap these people for money >> that can help the development effort. Frankly I am a little embarrassed >> by the poor quality of some library code. >> >> I think it shows that the "rush to release" which might not have been in >> Python's best short-term interests, even though actually getting it out >> the door was a significant occurrence for the long term.. >> >> regards >> Steve > > Without the release we probably would not have found out about these > issues; no one seems to take the betas or alphas for serious test > drives (to be expected) with real code, so yeah, in hindsight, there > are issues - but then again, they would have been fixed if everyone > had really known about them in advance. No one wants to ship something > with horrible bugs in it. > Well, consider my remarks in a historical rather than a critical context. I have no beef with 3.0 having come out when it did, and see no reason why 3.x shouldn't continue to yield lessons for all Python implementers. The question of when to declare 3.x the "official" release is interesting. I am inclined to say "when there's at least one other implementation at 3.2" - even if CPython is then at 3.3 or 3.4. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ 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] Rework nntlib?
On Wed, Sep 15, 2010 at 10:21 AM, Steve Holden wrote: > On 9/15/2010 10:02 AM, Jesse Noller wrote: >> On Tue, Sep 14, 2010 at 7:57 PM, Steve Holden wrote: >>> On 9/14/2010 6:45 PM, R. David Murray wrote: On Tue, 14 Sep 2010 16:34:33 +0530, Senthil Kumaran wrote: > On Tue, Sep 14, 2010 at 12:44:30PM +0200, Baptiste Carvello wrote: >>> Antoine> Like the email package, nntplib in py3k is broken (because >>> of >>> Antoine> various bytes/str mismatches; I suppose the lack of a test >>> Antoine> suite didn't help when porting). >>> >>> How heavily used is nntp these days (unless you're looking for spam)? >>> Would >>> it make more sense to find someone willing to maintain it outside the >>> Python >>> core and just remove it altogether? >>> >> Reading this from GMANE ;-) > > I guess, Skip's question or intention was, how often nntplib as a > module is being used these days to write scripts/tools or clients? > Very rarely. > > It would definitely be interesting to know, if there are python > applications out there which are using nntplib at the moment. You all might find it interesting to know that I'm now maintaining email and working on email6 as a direct consequence of nntplib. I was using it to read mailing lists through gmane, and when I tried to port my nntp tool to Python3 I found that decode_header (among other things) was broken, and as a consequence of talking to Barry about that walked in to the email minefield I'm currently not using my nttp reader, but it is because I couldn't stand working on my client in Python2, I wanted to be using Python3. So I volunteered to help with email...but I figure I'll come back around and help Antoine with nttplib by and by :) >>> And again I say, if anyone knows of any budgets to which this work is >>> important, the PSF will be happy to try and tap these people for money >>> that can help the development effort. Frankly I am a little embarrassed >>> by the poor quality of some library code. >>> >>> I think it shows that the "rush to release" which might not have been in >>> Python's best short-term interests, even though actually getting it out >>> the door was a significant occurrence for the long term.. >>> >>> regards >>> Steve >> >> Without the release we probably would not have found out about these >> issues; no one seems to take the betas or alphas for serious test >> drives (to be expected) with real code, so yeah, in hindsight, there >> are issues - but then again, they would have been fixed if everyone >> had really known about them in advance. No one wants to ship something >> with horrible bugs in it. >> > Well, consider my remarks in a historical rather than a critical > context. I have no beef with 3.0 having come out when it did, and see no > reason why 3.x shouldn't continue to yield lessons for all Python > implementers. > > The question of when to declare 3.x the "official" release is > interesting. I am inclined to say "when there's at least one other > implementation at 3.2" - even if CPython is then at 3.3 or 3.4. The moratorium is in place to allow this catch-up to occur (in theory) as cpython is not as large a moving target. However, I don't see how waiting for another implementation, which would probably inherit the same standard library code (and therefore, the same issues) is going to help with issues in the 3.x standard library. Besides; we have two official releases of python - 2.7 and 3.1, I see us as already having declared or decided to mark it as official, even if it's not entirely bug free. ___ 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] 3.x as the official release
On Wed, 15 Sep 2010 10:21:11 -0400 Steve Holden wrote: > > The question of when to declare 3.x the "official" release is > interesting. I am inclined to say "when there's at least one other > implementation at 3.2" - even if CPython is then at 3.3 or 3.4. I don't think that's a good criterion. 95% of Python users (my guesstimate) are on CPython, so whether or not alternative implementations are up-to-date isn't critically important. 3.1 had some warts left (*), but 3.2 should really be a high-quality release. Many bugs have been squashed, small improvements done (including additional features in the stdlib, or the new GIL), and unicode support has been polished again thanks to Martin's and Victor's efforts. Not only will it be as robust as any 2.x release (**), but it's also more pleasant to use, and there's upwards compatibility for many years to come. (*) some of them fixed in the 3.1 maintenance branch (**) with a couple of lacking areas such as the email module, I suppose 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] 3.x as the official release
On Wed, Sep 15, 2010 at 10:43 AM, Antoine Pitrou wrote: > On Wed, 15 Sep 2010 10:21:11 -0400 > Steve Holden wrote: >> >> The question of when to declare 3.x the "official" release is >> interesting. I am inclined to say "when there's at least one other >> implementation at 3.2" - even if CPython is then at 3.3 or 3.4. > > I don't think that's a good criterion. 95% of Python users (my > guesstimate) are on CPython, so whether or not alternative > implementations are up-to-date isn't critically important. > > 3.1 had some warts left (*), but 3.2 should really be a high-quality > release. Many bugs have been squashed, small improvements done > (including additional features in the stdlib, or the new GIL), and > unicode support has been polished again thanks to Martin's and Victor's > efforts. Not only will it be as robust as any 2.x release (**), but it's > also more pleasant to use, and there's upwards compatibility for many > years to come. > > (*) some of them fixed in the 3.1 maintenance branch > > (**) with a couple of lacking areas such as the email module, I suppose > > Regards > > Antoine. +0.5 The one area I have concerns about is the state of WSGI and other web-oriented modules. These issues have been brought up by Armin and others, but given a lack of a clear path forward (bugs, peps, etc), I don't think it's fair to use it as a measurement of overall quality. jesse ___ 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] Rework nntlib?
On Sep 15, 2010, at 10:21 AM, Steve Holden wrote: >The question of when to declare 3.x the "official" release is >interesting. I am inclined to say "when there's at least one other >implementation at 3.2" - even if CPython is then at 3.3 or 3.4. The fun starts now. We've just seen the last official release of Python 2, and while it will be maintained for a long time (and used for longer I'm sure), we've put out the clear message that the future is Python 3. So I think you'll start to see momentum around Python 3 pick up, and that includes improvements to the stdlib. In fact, with the moratorium in place, I'm hoping *most* of the incredible Pythonic brain power will be devoted to Python 3 stdlib improvements. -Barry signature.asc 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
Re: [Python-Dev] 2.6.6 is a release candidate?
On Sep 14, 2010, at 10:34 PM, Chris Withers wrote: >http://www.python.org/download/releases/2.6.6/ > >..includes the text: > >"This is a release candidate; we currently support these formats:" > >Is that text meant to be there? Nope, and fixed. Thanks for noticing this typo. -Barry signature.asc 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
Re: [Python-Dev] Rework nntlib?
Jesse Noller wrote: > no one seems to take the betas or alphas for serious test drives (to > be expected) with real code I wonder if there's some way to improve that situation -- perhaps by some engineering of the Python packaging, or some such? Bill ___ 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] Rework nntlib?
Interesting. I personally use nis and poplib quite a bit, but I can see how that would be very location-dependent. Bill ___ 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] 3.x as the official release
On Wed, Sep 15, 2010 at 07:50, Jesse Noller wrote: > On Wed, Sep 15, 2010 at 10:43 AM, Antoine Pitrou wrote: >> On Wed, 15 Sep 2010 10:21:11 -0400 >> Steve Holden wrote: >>> >>> The question of when to declare 3.x the "official" release is >>> interesting. I am inclined to say "when there's at least one other >>> implementation at 3.2" - even if CPython is then at 3.3 or 3.4. >> >> I don't think that's a good criterion. 95% of Python users (my >> guesstimate) are on CPython, so whether or not alternative >> implementations are up-to-date isn't critically important. >> >> 3.1 had some warts left (*), but 3.2 should really be a high-quality >> release. Many bugs have been squashed, small improvements done >> (including additional features in the stdlib, or the new GIL), and >> unicode support has been polished again thanks to Martin's and Victor's >> efforts. Not only will it be as robust as any 2.x release (**), but it's >> also more pleasant to use, and there's upwards compatibility for many >> years to come. >> >> (*) some of them fixed in the 3.1 maintenance branch >> >> (**) with a couple of lacking areas such as the email module, I suppose >> >> Regards >> >> Antoine. > > +0.5 > > The one area I have concerns about is the state of WSGI and other > web-oriented modules. These issues have been brought up by Armin and > others, but given a lack of a clear path forward (bugs, peps, etc), I > don't think it's fair to use it as a measurement of overall quality. The whole WSGI situation is not going to get cleared up (from my understanding) until someone flat-out declares a winner in the whole str/bytes argument that keeps coming up. I think it might be time to have a PEP or two on this and use our new PEP dictator procedure to settle this so it stops dragging on (unless it has been miraculously settled and I am just unaware of it). ___ 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] 3.x as the official release
On Wed, Sep 15, 2010 at 12:22 PM, Brett Cannon wrote: ...snip... >> The one area I have concerns about is the state of WSGI and other >> web-oriented modules. These issues have been brought up by Armin and >> others, but given a lack of a clear path forward (bugs, peps, etc), I >> don't think it's fair to use it as a measurement of overall quality. > > The whole WSGI situation is not going to get cleared up (from my > understanding) until someone flat-out declares a winner in the whole > str/bytes argument that keeps coming up. I think it might be time to > have a PEP or two on this and use our new PEP dictator procedure to > settle this so it stops dragging on (unless it has been miraculously > settled and I am just unaware of it). > Yup, and I spoke with some people with horses in that race at Djangocon. The important thing is that the PEP(s) and suggestion come from the people with the most experience in that domain. That's why I said we (in the "committer" sense) need a clear path of things we need to change or fix - without it we're just stabbing in the dark. jesse ___ 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] Rework nntlib?
On Wed, Sep 15, 2010 at 12:14 PM, Bill Janssen wrote: > Jesse Noller wrote: > >> no one seems to take the betas or alphas for serious test drives (to >> be expected) with real code > > I wonder if there's some way to improve that situation -- perhaps by > some engineering of the Python packaging, or some such? > > Bill > You need people with the time and willingness to download, install and run production code on the releases. I don't know that fudging with the packaging would help as python versions can and do live side by side in most cases. ___ 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] 3.x as the official release
On 15/09/2010 17:35, Jesse Noller wrote: On Wed, Sep 15, 2010 at 12:22 PM, Brett Cannon wrote: ...snip... The one area I have concerns about is the state of WSGI and other web-oriented modules. These issues have been brought up by Armin and others, but given a lack of a clear path forward (bugs, peps, etc), I don't think it's fair to use it as a measurement of overall quality. The whole WSGI situation is not going to get cleared up (from my understanding) until someone flat-out declares a winner in the whole str/bytes argument that keeps coming up. I think it might be time to have a PEP or two on this and use our new PEP dictator procedure to settle this so it stops dragging on (unless it has been miraculously settled and I am just unaware of it). Yup, and I spoke with some people with horses in that race at Djangocon. The important thing is that the PEP(s) and suggestion come from the people with the most experience in that domain. That's why I said we (in the "committer" sense) need a clear path of things we need to change or fix - without it we're just stabbing in the dark. I agree. wsgi is a different kettle of fish to the other "web related modules" in the standard library though. (wsgiref is the only directly wsgi related standard library module IIUC.) email, cgi, nntplib, ftplib and friends all still need to work correctly with both bytes and strings and that shouldn't need a great deal of discussion (well perhaps except email) just people willing to do the work. Unfortunately in some cases will need backwards incompatible changes. For example at the moment cgi reads from stdin in text mode and so is broken for file uploads. We have also heard recently from Antoine about backwards incompatible changes required in nntplib. All the best, Michael jesse ___ 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.ironpythoninaction.com/ http://www.voidspace.org.uk/blog 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] 3.x as the official release
On Wed, Sep 15, 2010 at 09:35, Jesse Noller wrote: > On Wed, Sep 15, 2010 at 12:22 PM, Brett Cannon wrote: > ...snip... >>> The one area I have concerns about is the state of WSGI and other >>> web-oriented modules. These issues have been brought up by Armin and >>> others, but given a lack of a clear path forward (bugs, peps, etc), I >>> don't think it's fair to use it as a measurement of overall quality. >> >> The whole WSGI situation is not going to get cleared up (from my >> understanding) until someone flat-out declares a winner in the whole >> str/bytes argument that keeps coming up. I think it might be time to >> have a PEP or two on this and use our new PEP dictator procedure to >> settle this so it stops dragging on (unless it has been miraculously >> settled and I am just unaware of it). >> > > Yup, and I spoke with some people with horses in that race at > Djangocon. The important thing is that the PEP(s) and suggestion come > from the people with the most experience in that domain. Yes. They have to be people who are not only stakeholders but people who actively use and develop large applications using WSGI. > That's why I > said we (in the "committer" sense) need a clear path of things we need > to change or fix - without it we're just stabbing in the dark. So, who do we get to write the PEP(s)? Should we ask the web-sig to choose a person or two and then once we have the PEPs we designate PEP dictators? Either way we should probably set a deadline to get the PEPs in else the SIG might argue too long where to go look at paint samples. ___ 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] 3.x as the official release
On Wed, Sep 15, 2010 at 12:55 PM, Brett Cannon wrote: > On Wed, Sep 15, 2010 at 09:35, Jesse Noller wrote: >> On Wed, Sep 15, 2010 at 12:22 PM, Brett Cannon wrote: >> ...snip... The one area I have concerns about is the state of WSGI and other web-oriented modules. These issues have been brought up by Armin and others, but given a lack of a clear path forward (bugs, peps, etc), I don't think it's fair to use it as a measurement of overall quality. >>> >>> The whole WSGI situation is not going to get cleared up (from my >>> understanding) until someone flat-out declares a winner in the whole >>> str/bytes argument that keeps coming up. I think it might be time to >>> have a PEP or two on this and use our new PEP dictator procedure to >>> settle this so it stops dragging on (unless it has been miraculously >>> settled and I am just unaware of it). >>> >> >> Yup, and I spoke with some people with horses in that race at >> Djangocon. The important thing is that the PEP(s) and suggestion come >> from the people with the most experience in that domain. > > Yes. They have to be people who are not only stakeholders but people > who actively use and develop large applications using WSGI. > >> That's why I >> said we (in the "committer" sense) need a clear path of things we need >> to change or fix - without it we're just stabbing in the dark. > > So, who do we get to write the PEP(s)? Should we ask the web-sig to > choose a person or two and then once we have the PEPs we designate PEP > dictators? Either way we should probably set a deadline to get the > PEPs in else the SIG might argue too long where to go look at paint > samples. > At Djangocon, I was told this is being discussed amongst people on web-sig, and I encouraged a few people to get involved. I don't think this is something we can set a deadline for (and I don't know that it's *our* place), especially given a lack of people to actually write the code in some cases. In at least one case, I've encouraged them to contact the PSF with a proposal in case funding is needed (such as your own, or Jean-Paul's work). Fundamentally; I would gladly hold up 3.2 (just my opinion) for the needed fixes to the standard lib I've heard discussed (once we have bugs and/or patches) but that requires the decisions to be made, and I don't think the people here are the ones to make the decisions - so we can only state the release date of 3.2 and the subsequent releases and let the people who know infinitely more about the nuances then us decide on it. jesse ___ 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] 3.x as the official release
On Wed, Sep 15, 2010 at 12:09 PM, Jesse Noller wrote: > Fundamentally; I would gladly hold up 3.2 (just my opinion) for the > needed fixes to the standard lib [...] I think I should share a little anecdote at this point: Earlier in the year I worked for a while on Django/Py3. It's actually not that hard of a task (because I'm building on the work by MvL and some of Greg Wilson's students!) and I quickly got a simple app working locally. So the next step for me was to see about putting the app into production... and that's where the wheels fell off. So that's where I stopped. As far as I'm concerned, I'm not willing to expend the effort to get Django ported if I can't put it into production. Most of us working on Django are going to feel the same way, I suspect. Further, I can say with some confidence that until the WSGI issue is sorted the Python web world isn't going to have much enthusiasm for Python 3. I'm trying not to sound overly negative here -- really, I can't *WAIT* to be able to switch to Py3! But until I have a bunch of interoperable, robust WSGI servers like I do on Python 2 -- modwsgi, uwsgi, cherrypy, gunicorn, ... -- Python 3 is going to remain a pipe dream. Jacob ___ 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] Rework nntlib?
On Wed, Sep 15, 2010 at 11:37 AM, Jesse Noller wrote: > You need people with the time and willingness to download, install and > run production code on the releases. This might be getting off-topic, but maybe not as many people as you think. How many projects in pypi provide unittests? That's at least more tests to add to the ones already being run in the stdlib. -Devin ___ 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] Rework nntlib?
On Wed, Sep 15, 2010 at 10:48 AM, Devin Cook wrote: > On Wed, Sep 15, 2010 at 11:37 AM, Jesse Noller wrote: >> You need people with the time and willingness to download, install and >> run production code on the releases. > > This might be getting off-topic, but maybe not as many people as you > think. How many projects in pypi provide unittests? That's at least > more tests to add to the ones already being run in the stdlib. > > -Devin Make it automatic and I can probably get some machines put on the job. I don't have a lot of time to devote, though. Geremy Condra ___ 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] Rework nntlib?
On Wed, Sep 15, 2010 at 1:48 PM, Devin Cook wrote: > On Wed, Sep 15, 2010 at 11:37 AM, Jesse Noller wrote: >> You need people with the time and willingness to download, install and >> run production code on the releases. > > This might be getting off-topic, but maybe not as many people as you > think. How many projects in pypi provide unittests? That's at least > more tests to add to the ones already being run in the stdlib. > > -Devin > And who do you get to maintain all the new tests and buildbots you spawn from running hundreds of community projects unittests? How do you know those tests are real, and actually work? You quickly outstrip the ability of the core team to stay on top of it, and you run into issues in the past akin to the community build bots project. jesse ___ 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] 3.x as the official release
On Wed, Sep 15, 2010 at 10:36, Jacob Kaplan-Moss wrote: > On Wed, Sep 15, 2010 at 12:09 PM, Jesse Noller wrote: >> Fundamentally; I would gladly hold up 3.2 (just my opinion) for the >> needed fixes to the standard lib [...] > > I think I should share a little anecdote at this point: > > Earlier in the year I worked for a while on Django/Py3. It's actually > not that hard of a task (because I'm building on the work by MvL and > some of Greg Wilson's students!) and I quickly got a simple app > working locally. So the next step for me was to see about putting the > app into production... and that's where the wheels fell off. > > So that's where I stopped. As far as I'm concerned, I'm not willing to > expend the effort to get Django ported if I can't put it into > production. Most of us working on Django are going to feel the same > way, I suspect. > > Further, I can say with some confidence that until the WSGI issue is > sorted the Python web world isn't going to have much enthusiasm for > Python 3. > > I'm trying not to sound overly negative here -- really, I can't *WAIT* > to be able to switch to Py3! But until I have a bunch of > interoperable, robust WSGI servers like I do on Python 2 -- modwsgi, > uwsgi, cherrypy, gunicorn, ... -- Python 3 is going to remain a pipe > dream. Which is why I would like to see this settled *now* rather than later. It's Georg's call, but I'm also fine with holding up Python 3.2 *if* we set a goal date to get this settled. If we release 3.2 without these fixes we won't have a chance for wsgiref to get updated until roughly June 2012 for Python 3.3 which will be 3.5 years since Python 3.0 was released. The Python web development community is a big (and friendly) part of the overall Python community. I think they deserve to have us do what we can as the harbingers of the language (and by extension, the technical aspect of the community as what we decide the community takes queues from) to solve this issue to allow forward movement towards using Python 3. ___ 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] 3.x as the official release
Given that wsgiref is in the stdlib, I think we should hold up the 3.2 release (and even the first beta) until this is resolved, unless we can convince ourselves that it's okay to delete wsgiref from the stdlib (which sounds unlikely but may not be any more incompatible than making it work properly :-). I want to emphasize that I am *not* a stakeholder so my preference for bytes or Unicode shouldn't matter; that said, given WSGI's traditional emphasis on using the lowest-level, vanilla standard datatypes (e.g. you can't even subclass dict let alone provide another kind of mapping -- it has to be a real dict) it makes sense to me that the values should be bytes, os.environ notwithstanding. The keys probably could be Unicode (HTTP headers are required to use only 7-bit ASCII characters anyways right?). But I'd be happy to be shown the error of my ways (or given a link showing prior discussion of the matter -- preferably with a conclusion :-). --Guido On Wed, Sep 15, 2010 at 10:36 AM, Jacob Kaplan-Moss wrote: > On Wed, Sep 15, 2010 at 12:09 PM, Jesse Noller wrote: >> Fundamentally; I would gladly hold up 3.2 (just my opinion) for the >> needed fixes to the standard lib [...] > > I think I should share a little anecdote at this point: > > Earlier in the year I worked for a while on Django/Py3. It's actually > not that hard of a task (because I'm building on the work by MvL and > some of Greg Wilson's students!) and I quickly got a simple app > working locally. So the next step for me was to see about putting the > app into production... and that's where the wheels fell off. > > So that's where I stopped. As far as I'm concerned, I'm not willing to > expend the effort to get Django ported if I can't put it into > production. Most of us working on Django are going to feel the same > way, I suspect. > > Further, I can say with some confidence that until the WSGI issue is > sorted the Python web world isn't going to have much enthusiasm for > Python 3. > > I'm trying not to sound overly negative here -- really, I can't *WAIT* > to be able to switch to Py3! But until I have a bunch of > interoperable, robust WSGI servers like I do on Python 2 -- modwsgi, > uwsgi, cherrypy, gunicorn, ... -- Python 3 is going to remain a pipe > dream. > > Jacob > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ 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] Rework nntlib?
On Sep 15, 2010, at 02:02 PM, Jesse Noller wrote: >And who do you get to maintain all the new tests and buildbots you >spawn from running hundreds of community projects unittests? How do >you know those tests are real, and actually work? You quickly outstrip >the ability of the core team to stay on top of it, and you run into >issues in the past akin to the community build bots project. This was something we were thinking about as part of the snakebite project. I don't know if that's still alive though. I would love to have *some* kind of health/QA metric show up next to packages on the Cheeseshop for example. It's also something I've been mulling over as part of QA for the large number of Python packages available in Debian/Ubuntu. This was in the context of trying to judge the health of those packages for Python 2.7. At our last UDS I spoke to a number of people and thought that it actually wouldn't be infeasible to set up some kind of automated Hudson-based farm to run test suites for all the packages we make available. I think all the basic pieces are there, it's mostly a matter of finding the time to put it all together. I of course did not find the time :/ so it hasn't happened yet. Of course, the set of platforms, Python versions, and packages we care about is much narrower than the full Python community, but it would still be an interesting exercise. -Barry signature.asc 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
Re: [Python-Dev] Rework nntlib?
On Wed, Sep 15, 2010 at 11:02 AM, Jesse Noller wrote: > On Wed, Sep 15, 2010 at 1:48 PM, Devin Cook wrote: >> On Wed, Sep 15, 2010 at 11:37 AM, Jesse Noller wrote: >>> You need people with the time and willingness to download, install and >>> run production code on the releases. >> >> This might be getting off-topic, but maybe not as many people as you >> think. How many projects in pypi provide unittests? That's at least >> more tests to add to the ones already being run in the stdlib. >> >> -Devin >> > > And who do you get to maintain all the new tests and buildbots you > spawn from running hundreds of community projects unittests? How do > you know those tests are real, and actually work? You quickly outstrip > the ability of the core team to stay on top of it, and you run into > issues in the past akin to the community build bots project. > > jesse Obviously information overload can be an issue, but ISTM that having projects opt-in for testing with new builds would give the core team some potentially useful feedback in the event that they needed it. Since pypi also has download statistics, it might help to figure out relative importance of different problems. Having said that, I'm only volunteering firepower, so don't interpret this as trying to push this on you guys if you don't want it. Geremy Condra ___ 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] 3.x as the official release
On Sep 15, 2010, at 11:11 AM, Guido van Rossum wrote: >Given that wsgiref is in the stdlib, I think we should hold up the 3.2 >release (and even the first beta) until this is resolved, unless we >can convince ourselves that it's okay to delete wsgiref from the >stdlib (which sounds unlikely but may not be any more incompatible >than making it work properly :-). I would much prefer holding up the release to fix wsgiref rather than remove it. I think it's an important module worthy of being in the stdlib. -Barry signature.asc 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
Re: [Python-Dev] Rework nntlib?
On Wed, Sep 15, 2010 at 2:29 PM, Barry Warsaw wrote: > On Sep 15, 2010, at 02:02 PM, Jesse Noller wrote: > >>And who do you get to maintain all the new tests and buildbots you >>spawn from running hundreds of community projects unittests? How do >>you know those tests are real, and actually work? You quickly outstrip >>the ability of the core team to stay on top of it, and you run into >>issues in the past akin to the community build bots project. > > This was something we were thinking about as part of the snakebite project. I > don't know if that's still alive though. I would love to have *some* kind of > health/QA metric show up next to packages on the Cheeseshop for example. My GSOC student this past year worked on a testing backend for PyPI, I think there's a want and strong desire for this, but a lack of person-resources. Also, the onus has to be on the maintainers of the package; not on core. > It's also something I've been mulling over as part of QA for the large number > of Python packages available in Debian/Ubuntu. This was in the context of > trying to judge the health of those packages for Python 2.7. > > At our last UDS I spoke to a number of people and thought that it actually > wouldn't be infeasible to set up some kind of automated Hudson-based farm to > run test suites for all the packages we make available. I think all the basic > pieces are there, it's mostly a matter of finding the time to put it all > together. I of course did not find the time :/ so it hasn't happened yet. Yeah; we have a plethora of options - hudson, pony-build, buildbot, pyti (http://bitbucket.org/mouad/pypi-testing-infrastructure-pyti) and many more. We also have the isolation tools (such as virtualenv) and awesome little utilities like tox (http://pypi.python.org/pypi/tox) for doing all of this now. Manpower and time prohibit it > Of course, the set of platforms, Python versions, and packages we care about > is much narrower than the full Python community, but it would still be an > interesting exercise. If we had an existing back end for this - say "python 2.6, 2.7, 3.1" and package maintainers could use that infrastructure, on pypi, to run their tests and we could see Green Dots (pass) for those packages, I think it's a short jump from that, to having a "dev" section where we can take tests that pass 3.1 and run it on a new experimental interpreter. If we know in advance that it passes on the old interpreter, we can at least assume that we may have broken something. ___ 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] 3.x as the official release
On Sep 15, 2010, at 7:50 AM, Jesse Noller wrote: > > +0.5 > > The one area I have concerns about is the state of WSGI and other > web-oriented modules. These issues have been brought up by Armin and > others, but given a lack of a clear path forward (bugs, peps, etc), I > don't think it's fair to use it as a measurement of overall quality. Any chance you're going to have time to do work on multiprocessing? There are a huge number of bugs reports open for that module. Raymond ___ 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] 3.x as the official release
On Wed, Sep 15, 2010 at 2:43 PM, Raymond Hettinger wrote: > > On Sep 15, 2010, at 7:50 AM, Jesse Noller wrote: >> >> +0.5 >> >> The one area I have concerns about is the state of WSGI and other >> web-oriented modules. These issues have been brought up by Armin and >> others, but given a lack of a clear path forward (bugs, peps, etc), I >> don't think it's fair to use it as a measurement of overall quality. > > Any chance you're going to have time to do work on multiprocessing? > There are a huge number of bugs reports open for that module. > Trying to get that time; and I've recently brought on Ask Solem to help me there, I concur that the current situation is sub optimal. ___ 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] 3.x as the official release
On 9/15/2010 2:47 PM, Jesse Noller wrote: > On Wed, Sep 15, 2010 at 2:43 PM, Raymond Hettinger > wrote: >> >> On Sep 15, 2010, at 7:50 AM, Jesse Noller wrote: >>> >>> +0.5 >>> >>> The one area I have concerns about is the state of WSGI and other >>> web-oriented modules. These issues have been brought up by Armin and >>> others, but given a lack of a clear path forward (bugs, peps, etc), I >>> don't think it's fair to use it as a measurement of overall quality. >> >> Any chance you're going to have time to do work on multiprocessing? >> There are a huge number of bugs reports open for that module. >> > > Trying to get that time; and I've recently brought on Ask Solem to > help me there, I concur that the current situation is sub optimal. Great that the "bus number" for multiprocessing has gone up by one! regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ 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] Rework nntlib?
On Sep 15, 2010, at 02:39 PM, Jesse Noller wrote: >Yeah; we have a plethora of options - hudson, pony-build, buildbot, >pyti (http://bitbucket.org/mouad/pypi-testing-infrastructure-pyti) and >many more. We also have the isolation tools (such as virtualenv) and >awesome little utilities like tox (http://pypi.python.org/pypi/tox) >for doing all of this now. > >Manpower and time prohibit it This might make for a fun sprint at Pycon 2011. It's closer than you think. (Well, maybe not closer than Jesse thinks :). -Barry signature.asc 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
Re: [Python-Dev] 3.x as the official release
On Wed, Sep 15, 2010 at 2:58 PM, Steve Holden wrote: > On 9/15/2010 2:47 PM, Jesse Noller wrote: >> On Wed, Sep 15, 2010 at 2:43 PM, Raymond Hettinger >> wrote: >>> >>> On Sep 15, 2010, at 7:50 AM, Jesse Noller wrote: +0.5 The one area I have concerns about is the state of WSGI and other web-oriented modules. These issues have been brought up by Armin and others, but given a lack of a clear path forward (bugs, peps, etc), I don't think it's fair to use it as a measurement of overall quality. >>> >>> Any chance you're going to have time to do work on multiprocessing? >>> There are a huge number of bugs reports open for that module. >>> >> >> Trying to get that time; and I've recently brought on Ask Solem to >> help me there, I concur that the current situation is sub optimal. > > Great that the "bus number" for multiprocessing has gone up by one! > > regards > Steve No one is happier about this then me. ___ 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] 3.x as the official release
At 11:11 AM 9/15/2010 -0700, Guido van Rossum wrote: Given that wsgiref is in the stdlib, I think we should hold up the 3.2 release (and even the first beta) until this is resolved, unless we can convince ourselves that it's okay to delete wsgiref from the stdlib (which sounds unlikely but may not be any more incompatible than making it work properly :-). FWIW, I'd be fine with that option. I want to emphasize that I am *not* a stakeholder so my preference for bytes or Unicode shouldn't matter; that said, given WSGI's traditional emphasis on using the lowest-level, vanilla standard datatypes (e.g. you can't even subclass dict let alone provide another kind of mapping -- it has to be a real dict) it makes sense to me that the values should be bytes, os.environ notwithstanding. The keys probably could be Unicode (HTTP headers are required to use only 7-bit ASCII characters anyways right?). But I'd be happy to be shown the error of my ways (or given a link showing prior discussion of the matter -- preferably with a conclusion :-). There isn't a conclusion yet, but the proposals under discussion are summarized here: http://www.wsgi.org/wsgi/Python_3#Proposals The primary points of consensus are bytes for wsgi.input, and native strings (i.e. Unicode on Python 3) for environment keys. If I were to offer a suggestion to a PEP author or dictator wanting to get something out ASAP, it would probably be to create a compromise between the "flat" model (my personal favorite) and the mod_wsgi model, as an addendum to PEP 333. Specifically: * leave start_response/write in play (ala mod_wsgi) * use the required types from the "flat" proposal (i.e. status, headers, and output stream MUST be bytes) * add a decorator to wsgiref that supports using native strings as output instead of bytes, for ease-of-porting (combine mod_wsgi's ease-of-porting w/"flat"'s simple verifiability) This would probably allow us to get by with the least changes to existing code, the stdlib, the standard itself, and wsgiref. (wsgiref itself would still need a thorough code review, especially wsgiref.validate, but it'd be unlikely to change much.) ___ 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] 3.x as the official release
Am 15.09.2010 20:32, schrieb Barry Warsaw: > On Sep 15, 2010, at 11:11 AM, Guido van Rossum wrote: > >>Given that wsgiref is in the stdlib, I think we should hold up the 3.2 >>release (and even the first beta) until this is resolved, unless we >>can convince ourselves that it's okay to delete wsgiref from the >>stdlib (which sounds unlikely but may not be any more incompatible >>than making it work properly :-). I also think this must be resolved before 3.2 can be released, and especially in the case of fixing it (vs removing), it should happen before beta 1. > I would much prefer holding up the release to fix wsgiref rather than remove > it. I think it's an important module worthy of being in the stdlib. Really? I'd like to hear from some of its users first. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] 3.x as the official release
On Wed, 2010-09-15 at 14:59 -0400, Chris McDonough wrote: > For reference, I have developed a spec and an (untested) reference > implementation of a WSGI successor I've given the name "Web3". Ian is > not hot on this spec (he prefers native strings as environ keys). That should read "as environ values" sorry. - C ___ 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] 3.x as the official release
For reference, I have developed a spec and an (untested) reference implementation of a WSGI successor I've given the name "Web3". Ian is not hot on this spec (he prefers native strings as environ keys). I'm definitely not going to write a WebOb analogue, so I'd more or less given up trying to promote it. But it's here for consideration. Given that nobody else has written this all out in spec form, it may be useful: http://github.com/mcdonc/web3 - C On Wed, 2010-09-15 at 11:11 -0700, Guido van Rossum wrote: > Given that wsgiref is in the stdlib, I think we should hold up the 3.2 > release (and even the first beta) until this is resolved, unless we > can convince ourselves that it's okay to delete wsgiref from the > stdlib (which sounds unlikely but may not be any more incompatible > than making it work properly :-). > > I want to emphasize that I am *not* a stakeholder so my preference for > bytes or Unicode shouldn't matter; that said, given WSGI's traditional > emphasis on using the lowest-level, vanilla standard datatypes (e.g. > you can't even subclass dict let alone provide another kind of mapping > -- it has to be a real dict) it makes sense to me that the values > should be bytes, os.environ notwithstanding. The keys probably could > be Unicode (HTTP headers are required to use only 7-bit ASCII > characters anyways right?). But I'd be happy to be shown the error of > my ways (or given a link showing prior discussion of the matter -- > preferably with a conclusion :-). > > --Guido > > On Wed, Sep 15, 2010 at 10:36 AM, Jacob Kaplan-Moss > wrote: > > On Wed, Sep 15, 2010 at 12:09 PM, Jesse Noller wrote: > >> Fundamentally; I would gladly hold up 3.2 (just my opinion) for the > >> needed fixes to the standard lib [...] > > > > I think I should share a little anecdote at this point: > > > > Earlier in the year I worked for a while on Django/Py3. It's actually > > not that hard of a task (because I'm building on the work by MvL and > > some of Greg Wilson's students!) and I quickly got a simple app > > working locally. So the next step for me was to see about putting the > > app into production... and that's where the wheels fell off. > > > > So that's where I stopped. As far as I'm concerned, I'm not willing to > > expend the effort to get Django ported if I can't put it into > > production. Most of us working on Django are going to feel the same > > way, I suspect. > > > > Further, I can say with some confidence that until the WSGI issue is > > sorted the Python web world isn't going to have much enthusiasm for > > Python 3. > > > > I'm trying not to sound overly negative here -- really, I can't *WAIT* > > to be able to switch to Py3! But until I have a bunch of > > interoperable, robust WSGI servers like I do on Python 2 -- modwsgi, > > uwsgi, cherrypy, gunicorn, ... -- Python 3 is going to remain a pipe > > dream. > > > > Jacob > > ___ > > Python-Dev mailing list > > [email protected] > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > http://mail.python.org/mailman/options/python-dev/guido%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/archive%40mail-archive.com
Re: [Python-Dev] 3.x as the official release
On Sep 15, 2010, at 09:21 PM, Georg Brandl wrote: >Am 15.09.2010 20:32, schrieb Barry Warsaw: >> I would much prefer holding up the release to fix wsgiref rather >> than remove it. I think it's an important module worthy of being in >> the stdlib. > >Really? I'd like to hear from some of its users first. I've used it. When combined with something like restish it's about 20 lines of code to publish a database-backed REST service. -Barry signature.asc 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
Re: [Python-Dev] 3.x as the official release
On Wed, Sep 15, 2010 at 9:18 PM, P.J. Eby wrote: > At 11:11 AM 9/15/2010 -0700, Guido van Rossum wrote: >> >> Given that wsgiref is in the stdlib, I think we should hold up the 3.2 >> release (and even the first beta) until this is resolved, unless we >> can convince ourselves that it's okay to delete wsgiref from the >> stdlib (which sounds unlikely but may not be any more incompatible >> than making it work properly :-). > > FWIW, I'd be fine with that option. Could we remove in any case the wsgiref.egg-info file ? Since we've been working on a new format for that (PEP 376), that should be starting to get used in the coming years, it'll be a bit of a non-sense to have that metadata file in the sdtlib shipped with 3,2 I am not really sure what was the intent to have it there in the first place though. Regards Tarek -- Tarek Ziadé | http://ziade.org ___ 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] 3.x as the official release
On Wed, Sep 15, 2010 at 12:45, Tarek Ziadé wrote: > On Wed, Sep 15, 2010 at 9:18 PM, P.J. Eby wrote: >> At 11:11 AM 9/15/2010 -0700, Guido van Rossum wrote: >>> >>> Given that wsgiref is in the stdlib, I think we should hold up the 3.2 >>> release (and even the first beta) until this is resolved, unless we >>> can convince ourselves that it's okay to delete wsgiref from the >>> stdlib (which sounds unlikely but may not be any more incompatible >>> than making it work properly :-). >> >> FWIW, I'd be fine with that option. I'm also fine with removing the module if that is what it takes to move all of this forward. That would remove Python 3.2's release cycle from this picture while also allowing a finalization of WSGI specs to continue in parallel. But this probably shouldn't happen as Geremy's Cheeseshop #s put wsgiref squarely in the middle of most used stdlib modules with 421 projects. So there are users of the module. > > Could we remove in any case the wsgiref.egg-info file ? Since we've > been working on a new format for that (PEP 376), that should be > starting to get used in the coming years, it'll be a bit of a > non-sense to have that metadata file in the sdtlib shipped with 3,2 > > I am not really sure what was the intent to have it there in the first > place though. I say go ahead and remove it. ___ 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] how to decide on a Python 3 design for wsgiref
Both the RM and BDFL agree that Python 3.2b1 should be held up until we settle this wsgi matter. That makes it a question of how to settle it. Thinking out loud here to keep this discussion focused, I say we give a deadline for PEPs to be submitted by October 15th. We then choose two PEP dictators to make a call by November 1, get wsgiref cleaned up ASAP, and get Python 3.2b1 out the door immediately thereafter. If web-sig manages to come to an agreement as a whole before then we can skip the PEPs, but if they have not managed to do this already then it probably is not going to suddenly happen now under threat of python-dev making the call for them by blessing a new wsgiref implementation (happy to be proven wrong, though). ___ 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] how to decide on a Python 3 design for wsgiref
On Wed, Sep 15, 2010 at 4:46 PM, Brett Cannon wrote: > Both the RM and BDFL agree that Python 3.2b1 should be held up until > we settle this wsgi matter. That makes it a question of how to settle > it. > > Thinking out loud here to keep this discussion focused, I say we give > a deadline for PEPs to be submitted by October 15th. We then choose > two PEP dictators to make a call by November 1, get wsgiref cleaned up > ASAP, and get Python 3.2b1 out the door immediately thereafter. If > web-sig manages to come to an agreement as a whole before then we can > skip the PEPs, but if they have not managed to do this already then it > probably is not going to suddenly happen now under threat of > python-dev making the call for them by blessing a new wsgiref > implementation (happy to be proven wrong, though). There's not just wsgiref; there's the possibility that other core and standard library changes may be needed. For example, the discussion from back in june: http://mail.python.org/pipermail/python-dev/2010-June/100733.html (that thread goes on for awhile) I'd personally like to see a plan which provides a path for both wsgiref, WSGI itself in python3 and the related changes to core which might be predicated, that way we can have some level of confidence we're not making the same misstep we made in the first place, making it so painful for the web frameworks/gateways/etc. jesse ___ 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] 3.x as the official release
Le 15/09/2010 21:45, Tarek Ziadé a écrit :
> Could we remove in any case the wsgiref.egg-info file ? Since we've
> been working on a new format for that (PEP 376), that should be
> starting to get used in the coming years, it'll be a bit of a
> non-sense to have that metadata file in the sdtlib shipped with 3,2
+1 on removing wsgiref.egg-info in the same version that ships with
distutils2, or with 3.2 (in case they’re not the same version).
> I am not really sure what was the intent to have it there in the first
> place though.
Unless I remember wrong, the intent was not to break code that used
pkg_resources.require('wsgiref').
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] 3.x as the official release
> * add a decorator to wsgiref that supports using native strings as > output instead of bytes, for ease-of-porting (combine mod_wsgi's > ease-of-porting w/"flat"'s simple verifiability) Ah, thanks, I’ve been reading web-sig and was totally at a loss to understand what a “native string” was. Now I get it’s a character string / string / str object / former unicode object. FWIW, I’m glad to see concern for web-sig in python-dev, and messages from Web people in python-dev. Some threads going “they broke strings, we can’t use the stdlib” were a bit alarming to me. 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] how to decide on a Python 3 design for wsgiref
On Wed, Sep 15, 2010 at 22:46, Brett Cannon wrote: > Both the RM and BDFL agree that Python 3.2b1 should be held up until > we settle this wsgi matter. That makes it a question of how to settle > it. I think that's a very good goal. Given all the times it's come up on the Web-SIG list (I even tried my hand at it once) and a consensus has failed to form, it seems pretty important that we force some kind of breakthrough. One problem: Graham Dumpleton, who is certainly one of the more knowledgeable people on this subject, will be on vacation "from late September". It looks like he's gone at least until half October. It would be a pity if we force a decision without his input. Cheers, Dirkjan ___ 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] how to decide on a Python 3 design for wsgiref
On Wed, Sep 15, 2010 at 14:41, Dirkjan Ochtman wrote: > On Wed, Sep 15, 2010 at 22:46, Brett Cannon wrote: >> Both the RM and BDFL agree that Python 3.2b1 should be held up until >> we settle this wsgi matter. That makes it a question of how to settle >> it. > > I think that's a very good goal. Given all the times it's come up on > the Web-SIG list (I even tried my hand at it once) and a consensus has > failed to form, it seems pretty important that we force some kind of > breakthrough. > > One problem: Graham Dumpleton, who is certainly one of the more > knowledgeable people on this subject, will be on vacation "from late > September". It looks like he's gone at least until half October. It > would be a pity if we force a decision without his input. It can get shifted to November 1 if needed. I just don't want it to drag on forever as it will keep postponing Python 3.2. ___ 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] 3.x as the official release
On Wed, Sep 15, 2010 at 21:18, P.J. Eby wrote: > If I were to offer a suggestion to a PEP author or dictator wanting to get > something out ASAP, it would probably be to create a compromise between the > "flat" model (my personal favorite) and the mod_wsgi model, as an addendum > to PEP 333. Specifically: > > * leave start_response/write in play (ala mod_wsgi) The alternative is returning a three-tuple status, headers, content-iterable, right? I would definitely prefer just returning a three-tuple instead of the crappy start_response callback that returns a write callable. It makes applications easier to write, and the unified model should also make server implemation easier. It also combines nicely with yield from in some cases. Cheers, Dirkjan ___ 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] (Not) delaying the 3.2 release
On Wed, 15 Sep 2010 11:11:14 -0700 Guido van Rossum wrote: > Given that wsgiref is in the stdlib, I think we should hold up the 3.2 > release (and even the first beta) until this is resolved, unless we > can convince ourselves that it's okay to delete wsgiref from the > stdlib (which sounds unlikely but may not be any more incompatible > than making it work properly :-). I'm not sure I agree with this. Considering that: - a PEP can be written at any time, and third-party implementations made compatible independently of our release schedule, and - a wsgi3ref package can be uploaded to the Cheese Shop as soon as the PEP is finalized, I don't see what we gain by holding up the 3.2 release. Some writing a Web application will need third-party modules anyway, so downloading wsgi3ref shouldn't be too painful. On the other hand, if 3.2 is delayed by a month or more, I might try to push for rapid acceptance of PEP 3151, in the hope that the implementation is ready before the first beta! 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] how to decide on a Python 3 design for wsgiref
On Wed, 2010-09-15 at 13:46 -0700, Brett Cannon wrote: > Both the RM and BDFL agree that Python 3.2b1 should be held up until > we settle this wsgi matter. That makes it a question of how to settle > it. > > Thinking out loud here to keep this discussion focused, I say we give > a deadline for PEPs to be submitted by October 15th. We then choose > two PEP dictators to make a call by November 1, get wsgiref cleaned up > ASAP, and get Python 3.2b1 out the door immediately thereafter. If > web-sig manages to come to an agreement as a whole before then we can > skip the PEPs, but if they have not managed to do this already then it > probably is not going to suddenly happen now under threat of > python-dev making the call for them by blessing a new wsgiref > implementation (happy to be proven wrong, though). FWIW, I've submitted http://github.com/mcdonc/web3/blob/master/web3.rst as a PEP (by sending a mail to [email protected]). - C ___ 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] 3.x as the official release
At 11:12 PM 9/15/2010 +0200, Ãric Araujo wrote:
Unless I remember wrong, the intent was not to break code that used
pkg_resources.require('wsgiref')
More precisely, at the time it was done, setuptools was slated for
inclusion in Python 2.5, and the idea was that when modules moved
from PyPI to the stdlib, they would include the metadata so that
projects requiring the module on an older version of Python would not
need to use Python-version-dependent dependencies.
So, for example, if a package was written on 2.4 using a requirement
of wsgiref, then that code would run unchanged on 2.5 using the
stdlib-supplied copy.
In practice, this didn't work out in 2.x, and it's meaningless on 3.x
where nothing has migrated yet from PyPI to stdlib AFAIK. ;-)
___
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] 3.x as the official release
At 11:50 PM 9/15/2010 +0200, Dirkjan Ochtman wrote: On Wed, Sep 15, 2010 at 21:18, P.J. Eby wrote: > If I were to offer a suggestion to a PEP author or dictator wanting to get > something out ASAP, it would probably be to create a compromise between the > "flat" model (my personal favorite) and the mod_wsgi model, as an addendum > to PEP 333. Â Specifically: > > * leave start_response/write in play (ala mod_wsgi) The alternative is returning a three-tuple status, headers, content-iterable, right? I would definitely prefer just returning a three-tuple instead of the crappy start_response callback that returns a write callable. It makes applications easier to write, and the unified model should also make server implemation easier. It also combines nicely with yield from in some cases. I would prefer it too (which is why the "flat" model is my favorite), but I think it would be easier to get a quick consensus for something that allows apps to be more mechanically ported from 2.x to 3.x. That's why I said, "offer a suggestion to ... get something out ASAP". ;-) ___ 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] (Not) delaying the 3.2 release
On Thu, Sep 16, 2010 at 8:09 AM, Antoine Pitrou wrote: > I don't see what we gain by holding up the 3.2 release. Some writing a > Web application will need third-party modules anyway, so downloading > wsgi3ref shouldn't be too painful. I agree with you. Further, is wsgiref actually heavily used by web developers and or web framework developers at all ? I would tend to think that web developers might be more interested in using some of the larger more popular web frameworks such as: TurboGears, Django, Pylons, Cherrypy, etc. i don't think a Python 3.2 release should be held up because of wsgiref. 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
[Python-Dev] PEP 444 aka "Web3" (was Re: how to decide on a Python 3 design for wsgiref)
This spec, a WSGI-like spec for Python2 and Python3 named Web3 was accepted today as PEP 444. http://python.org/dev/peps/pep-0444/ Comments and competing specs would be useful. - C On Wed, 2010-09-15 at 18:16 -0400, Chris McDonough wrote: > On Wed, 2010-09-15 at 13:46 -0700, Brett Cannon wrote: > > Both the RM and BDFL agree that Python 3.2b1 should be held up until > > we settle this wsgi matter. That makes it a question of how to settle > > it. > > > > Thinking out loud here to keep this discussion focused, I say we give > > a deadline for PEPs to be submitted by October 15th. We then choose > > two PEP dictators to make a call by November 1, get wsgiref cleaned up > > ASAP, and get Python 3.2b1 out the door immediately thereafter. If > > web-sig manages to come to an agreement as a whole before then we can > > skip the PEPs, but if they have not managed to do this already then it > > probably is not going to suddenly happen now under threat of > > python-dev making the call for them by blessing a new wsgiref > > implementation (happy to be proven wrong, though). > > FWIW, I've submitted http://github.com/mcdonc/web3/blob/master/web3.rst > as a PEP (by sending a mail to [email protected]). > > - C > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/lists%40plope.com > ___ 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] r84842 - peps/trunk/pep-0444.txt
2010/9/15 Brett Cannon : > Can I just ask why 444 since 392 was the last assigned Python 2 number? Likely because WSGI 1.0 is PEP 333. -- Regards, Benjamin ___ 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] PEP 444 aka "Web3" (was Re: how to decide on a Python 3 design for wsgiref)
On Thu, Sep 16, 2010 at 9:06 AM, Chris McDonough wrote: > Comments and competing specs would be useful. Can I post comments here ? :) I have one initial comment (at first glance). I'm not sure I quite like the idea of changing the keys from wsgi to web3 for the simple reason that you will already have to port your application to python3 (bytes vs. str) anyway. Changing the keys is just more unnecessary work (although one could just use a search/replace). My 2c (or pence) 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] (Not) delaying the 3.2 release
On Thu, Sep 16, 2010 at 9:31 AM, Jesse Noller wrote: > My goal (personally) is to make sure python 3.2 is perfectly good for use in > web applications, and is therefore a much more interesting porting target for > web projects/libraries and frameworks. Python 3 is already quite well done and very usable by web frameworks (at least my tiny one). (It's just my opinion of course). I think the biggest problem is the uptake of Python 3 itself and the general attitude towards Python 3 as a whole. That's what's stopping me from focusing on and even maintaining a Python 3 branch for my project(s). 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] PEP 444 aka "Web3" (was Re: how to decide on a Python 3 design for wsgiref)
At 09:22 AM 9/16/2010 +1000, James Mills wrote: On Thu, Sep 16, 2010 at 9:06 AM, Chris McDonough wrote: > Comments and competing specs would be useful. Can I post comments here ? :) Please, let's put any spec-detail commentary on the Web-SIG instead (commenting here on process issues related to the 3.x releases is of course fine). ___ 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] (Not) delaying the 3.2 release
On Sep 15, 2010, at 6:44 PM, James Mills wrote: > On Thu, Sep 16, 2010 at 8:09 AM, Antoine Pitrou wrote: >> I don't see what we gain by holding up the 3.2 release. Some writing a >> Web application will need third-party modules anyway, so downloading >> wsgi3ref shouldn't be too painful. > > I agree with you. Further, is wsgiref actually heavily used by web developers > and or web framework developers at all ? I would tend to think that > web developers > might be more interested in using some of the larger more popular web > frameworks > such as: TurboGears, Django, Pylons, Cherrypy, etc. > > i don't think a Python 3.2 release should be held up because of wsgiref. > > cheers > James > It's not just wsgiref. We need to talk with the web-sig participants to work out any other issues in addition to wsgiref which have been contentious (str vs byte methods, bytearrays, stdlib issues) or at least hear from the group that these issues are resolved. My goal (personally) is to make sure python 3.2 is perfectly good for use in web applications, and is therefore a much more interesting porting target for web projects/libraries and frameworks. If it was just wsgiref, it would be one thing, but based on conversations with members of web-sig in the past, it's not. I can't clearly communicate everything they've mentioned in the past for them. jesse ___ 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] Add PEP 444, Python Web3 Interface.
On 9/15/2010 4:44 PM, [email protected] wrote: ``SERVER_PORT`` must be a bytes instance (not an integer). What's that supposed to mean? What goes in the "bytes instance"? A character string in some format? A long binary number? If the latter, with which byte ordering? What problem does this\ solve? John Nagle ___ 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] problem with python 3.1
I made a program that, according to my teacher, is correct but is not running
properly.The program is really simple:
import mathx = input ("Coloque o valor do primeiro cateto:")y = input ("Coloque
o valor do segundo cateto:")z = x**2w = y**2soma = z + wh = math.sqrt
(soma)print = "O valor da hipotenusa é:", h
But after I put the value of x and y this error appears:
Traceback (most recent call last): File "C:/lista03.py", line 4, in
z = x**2TypeError: unsupported operand type(s) for ** or pow(): 'str' and 'int'
My teacher said the program ran normally in his computer, but in my it
doesn't!why? ___
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] (Not) delaying the 3.2 release
On Wed, Sep 15, 2010 at 6:31 PM, Jesse Noller wrote: > My goal (personally) is to make sure python 3.2 is perfectly good for use in > web applications, and is therefore a much more interesting porting target for > web projects/libraries and frameworks. To try (again) to make things concrete here: I didn't work to get Django running on Python 3.0 because it was just too slow. I'm not working to get Django running on Python 3.1 because I don't feel confident I'll be able to put any apps I write into production. If Python 3.2 is the same, I won't feel any motivation to target it and I'll get to be lazy and wait for Python 3.3. If, on the other hand, Python 3.2 "is perfectly good for use in web applications" then I'll be inspired to work on porting to it. And if I don't Jesse will yell out me, louder and louder, until I find some inspiration. Now, I'm really only speaking for myself here -- not making any statements on behalf of the Django core team, or community, or Python web community, or whatever. So if you think I'm alone (or a minority) in feeling this way then by all means hurry up and push out Python 3.2. If, on the other hand, you think that others in the Python web community might feel similarly, well, then maybe the delay would be worth it. Jacob ___ 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] problem with python 3.1
This list is for the development of Python, not questions about its
use. You should ask python-list. None the less, it's because input()
changed between Python 2 and 3. Look at the docs for both.
2010/9/15 João Vitor :
> I made a program that, according to my teacher, is correct but is not
> running properly.
> The program is really simple:
> import math
> x = input ("Coloque o valor do primeiro cateto:")
> y = input ("Coloque o valor do segundo cateto:")
> z = x**2
> w = y**2
> soma = z + w
> h = math.sqrt (soma)
> print = "O valor da hipotenusa é:", h
> But after I put the value of x and y this error appears:
> Traceback (most recent call last):
> File "C:/lista03.py", line 4, in
> z = x**2
> TypeError: unsupported operand type(s) for ** or pow(): 'str' and 'int'
> My teacher said the program ran normally in his computer, but in my it
> doesn't!
> why?
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/benjamin%40python.org
>
>
--
Regards,
Benjamin
___
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] (Not) delaying the 3.2 release
On 9/15/2010 8:55 PM, Jacob Kaplan-Moss wrote: To try (again) to make things concrete here: I didn't work to get Django running on Python 3.0 because it was just too slow. Soon after 3.0 was released, it was discovered and acknowledged thay the new I/O has some speed problems. (Why not discovered sooner? Because the people who had the use cases that exposed it did not run them on the alpha or beta ;-). It was quickly fixed and 3.1 was released earlier than planned it order to get the fix out. Otherwise, 3.x should be about the same speed as 2.x. If you know of other, specific, unreported problems, clue us in. I'm not working to get Django running on Python 3.1 because I don't feel confident I'll be able to put any apps I write into production. Why not? Since the I/O speed problem is fixed, I have no idea what you are referring to. Please do be concrete. -- 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
