Re: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec
2009/11/29 James Y Knight : > On Nov 28, 2009, at 10:44 PM, Graham Dumpleton wrote: >> Either way, since there seemed to be objections at some level on every >> point, and since I really really have no enthusiasm for this stuff any >> more or of fighting for any change, I retract my personal interest in >> having any of the amendments as part of a WSGI 1.1 specification and >> will remove all that detail from mod_wsgi documentation > > > [...] > >> If don't see an answer, then guess I will just have to revert it back >> to (1, 0) to be safe and to avoid any accusations that am highjacking >> the process. >> >> An answer sooner rather than later would be appreciated on the >> wsgi.version issue. > > I'd rather appreciate it if you held off on making such changes until either > this discussion either peters out or is resolved. You sound somewhat > negative, but it seems to me that there's actually quite close to being a > consensus on adopting most of your proposal. Changing the proposal out from > under us doesn't really help things. > > The next step here is clearly for someone to redraft the changes as a diff > against PEP 333. If you do not have any interest in being that person, please > make that clear, so someone else can step up to do so. No I do not want a part in drafting any changes, I just want to move on from all this stuff and starting working on other projects. Since though some don't seem to understand the reasons for the changes then you will find it hard to find some who is in a position to be able to do them. You probably really are just better off worrying about Python 3.X support and accept that tinkering at edges of WSGI 1.0 on other issues is not going to solve all the WSGI issues. As PJE suggest, leave that to an interface incompatible update so that you don't have this whole problem of what version existing components support. Graham ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec
On Nov 28, 2009, at 10:44 PM, Graham Dumpleton wrote: > Either way, since there seemed to be objections at some level on every > point, and since I really really have no enthusiasm for this stuff any > more or of fighting for any change, I retract my personal interest in > having any of the amendments as part of a WSGI 1.1 specification and > will remove all that detail from mod_wsgi documentation [...] > If don't see an answer, then guess I will just have to revert it back > to (1, 0) to be safe and to avoid any accusations that am highjacking > the process. > > An answer sooner rather than later would be appreciated on the > wsgi.version issue. I'd rather appreciate it if you held off on making such changes until either this discussion either peters out or is resolved. You sound somewhat negative, but it seems to me that there's actually quite close to being a consensus on adopting most of your proposal. Changing the proposal out from under us doesn't really help things. The next step here is clearly for someone to redraft the changes as a diff against PEP 333. If you do not have any interest in being that person, please make that clear, so someone else can step up to do so. James ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec
2009/11/29 Graham Dumpleton : > After reading my prior blog posts where I explained my reasoning > behind the changes, I will acknowledge that I haven't explained some > stuff very well and people are failing to understand or getting wrong > idea about why something is being suggested. > > I still believe there are though underlying problems there in the WSGI > specification and right now, more by luck than design is various stuff > working. In some cases such as readline(), the majority of WSGI > applications/frameworks are in violation of the WSGI 1.0 specification > due to their reliance on cgi.FieldStorage which makes calls to > readline() with an argument. > > Either way, since there seemed to be objections at some level on every > point, and since I really really have no enthusiasm for this stuff any > more or of fighting for any change, I retract my personal interest in > having any of the amendments as part of a WSGI 1.1 specification and > will remove all that detail from mod_wsgi documentation. I will > instead replace it with a separate page describing mod_wsgi compliance > with WSGI 1.0 specification and highlighting those specific features > which are in common, or not so common use, via mod_wsgi and which > actually mean that people are writing applications incompatible with > the WSGI 1.0 specification. > > To ensure compliance I could well raise Python exceptions for any use > which isn't WSGI 1.0 compliant, but I have already learnt from where I > tried get people to write portable WSGI applications by giving errors > on certain use of stdin and stdout, that it is a pointless battle. All > it got was a long list of users who believe mod_wsgi is broken even > though if they read the actual documentation they would find it was > their own software which was suspect or at least wasn't portable to > all WSGI hosting mechanisms. This would only get worse if exceptions > were raised for use of readline() with an argument and use of read() > with no argument or argument of -1. Short story is that there are a > fair few people who are just lazy, they will always write stuff the > way the want to and not how it should be written. They will always > blame other peoples code for being wrong before acknowledging they > themselves are wrong. > > The only answer I therefore need out of WEB-SIG is whether the > qualifications about how Python 3.X is to be supported are going to be > an amendment to WSGI 1.0 or as a separate WSGI 1.1 update and whether > if the latter whether the WSGI 1.1 tag will also have meaning for > Python 2.X. > > I need an answer to this so I know whether to withdraw mod_wsgi 3.0 > from download and replace it with a mod_wsgi 4.0 which changes the > wsgi.version tuple being passed, for both Python 2.X and Python 3.X, > from (1, 1) back to original (1, 0), given that some opinion seems to > be that any interface changes can only really be performed as part of > WSGI 2.0 and so I would be wrong in using (1, 1). > > If don't see an answer, then guess I will just have to revert it back > to (1, 0) to be safe and to avoid any accusations that am highjacking > the process. > > An answer sooner rather than later would be appreciated on the > wsgi.version issue. Answering my own question, it is actually obvious that it has to be called (1, 0). This is because wsgiref in Python 3.X already calls it (1, 0) and don't have much choice to be in agreement with that. I will therefore replace mod_wsgi 3.0 with a 4.0 release that reverts it to (1, 0) from (1, 1) and all the other stuff about amendments can be ignored. Graham > 2009/11/28 Graham Dumpleton : >> Please ensure you have also all read: >> >> http://blog.dscpl.com.au/2009/10/details-on-wsgi-10-amendmentsclarificat.html >> >> I will post again later in detail when have some time to explain a few >> more points not mentioned in that post and where people aren't quite >> understanding the reasoning for doing things. >> >> One very quick comment about read(). >> >> Allowing read() with no argument is no different to a user saying >> read(environ['CONTENT_LENGTH']). Because a WSGI adapter/middleware is >> going to have to track bytes read to ensure can return an empty string >> as end sentinel, it will know length remaining and would internally >> for read() with no argument do read(remaining_bytes). As such no real >> differences in inefficiencies as far as memory use goes for >> implementing read() because of need to implement end sentinel. >> >> Also, you have concerns about read() with no argument, but frankly >> readline() with no argument, which is already required, is much worse >> because you cant really track bytes read and just read to end of >> input. This is because they only want to read to end of line and so >> reading all input is going to blow out memory use unreasonably as you >> speculate for read(). As such, a readline() implementation is likely >> to read in blocks and internally buffer where read() doesn't >> necessari
Re: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec
After reading my prior blog posts where I explained my reasoning behind the changes, I will acknowledge that I haven't explained some stuff very well and people are failing to understand or getting wrong idea about why something is being suggested. I still believe there are though underlying problems there in the WSGI specification and right now, more by luck than design is various stuff working. In some cases such as readline(), the majority of WSGI applications/frameworks are in violation of the WSGI 1.0 specification due to their reliance on cgi.FieldStorage which makes calls to readline() with an argument. Either way, since there seemed to be objections at some level on every point, and since I really really have no enthusiasm for this stuff any more or of fighting for any change, I retract my personal interest in having any of the amendments as part of a WSGI 1.1 specification and will remove all that detail from mod_wsgi documentation. I will instead replace it with a separate page describing mod_wsgi compliance with WSGI 1.0 specification and highlighting those specific features which are in common, or not so common use, via mod_wsgi and which actually mean that people are writing applications incompatible with the WSGI 1.0 specification. To ensure compliance I could well raise Python exceptions for any use which isn't WSGI 1.0 compliant, but I have already learnt from where I tried get people to write portable WSGI applications by giving errors on certain use of stdin and stdout, that it is a pointless battle. All it got was a long list of users who believe mod_wsgi is broken even though if they read the actual documentation they would find it was their own software which was suspect or at least wasn't portable to all WSGI hosting mechanisms. This would only get worse if exceptions were raised for use of readline() with an argument and use of read() with no argument or argument of -1. Short story is that there are a fair few people who are just lazy, they will always write stuff the way the want to and not how it should be written. They will always blame other peoples code for being wrong before acknowledging they themselves are wrong. The only answer I therefore need out of WEB-SIG is whether the qualifications about how Python 3.X is to be supported are going to be an amendment to WSGI 1.0 or as a separate WSGI 1.1 update and whether if the latter whether the WSGI 1.1 tag will also have meaning for Python 2.X. I need an answer to this so I know whether to withdraw mod_wsgi 3.0 from download and replace it with a mod_wsgi 4.0 which changes the wsgi.version tuple being passed, for both Python 2.X and Python 3.X, from (1, 1) back to original (1, 0), given that some opinion seems to be that any interface changes can only really be performed as part of WSGI 2.0 and so I would be wrong in using (1, 1). If don't see an answer, then guess I will just have to revert it back to (1, 0) to be safe and to avoid any accusations that am highjacking the process. An answer sooner rather than later would be appreciated on the wsgi.version issue. Graham 2009/11/28 Graham Dumpleton : > Please ensure you have also all read: > > http://blog.dscpl.com.au/2009/10/details-on-wsgi-10-amendmentsclarificat.html > > I will post again later in detail when have some time to explain a few > more points not mentioned in that post and where people aren't quite > understanding the reasoning for doing things. > > One very quick comment about read(). > > Allowing read() with no argument is no different to a user saying > read(environ['CONTENT_LENGTH']). Because a WSGI adapter/middleware is > going to have to track bytes read to ensure can return an empty string > as end sentinel, it will know length remaining and would internally > for read() with no argument do read(remaining_bytes). As such no real > differences in inefficiencies as far as memory use goes for > implementing read() because of need to implement end sentinel. > > Also, you have concerns about read() with no argument, but frankly > readline() with no argument, which is already required, is much worse > because you cant really track bytes read and just read to end of > input. This is because they only want to read to end of line and so > reading all input is going to blow out memory use unreasonably as you > speculate for read(). As such, a readline() implementation is likely > to read in blocks and internally buffer where read() doesn't > necessarily have to. > > It may also be pertinent to read: > > http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html > > as from memory it talks about issues with not paying attention to > Content-Length on output filtering middleware as well. > > As I said, will reply later when have some time to focus. Right now I > have a 2 year old to keep amused. > > Graham > > 2009/11/27 James Y Knight : >> I move to bless mod_wsgi's definition of WSGI 1.1 [1] as the official >> definition of WSGI 1.1, which descri
Re: [Web-SIG] http://wiki.python.org/moin/WebFrameworks
Personally, if the author/maintainer of any library claims it is maintained/up-to-date, I say trust them. Most people are pretty honest about the status of their projects. But it does require a positive response to really make this claim. On Sat, Nov 28, 2009 at 12:03 PM, Aaron Watters wrote: > > > > > On Thu, Nov 26, 2009 at 1:02 PM, Chris McDonough > > wrote: > > > http://wiki.python.org/moin/WebFrameworks > > seems to be the place where folks > > > are registering their respective web frameworks. > > > > > > I'd like to move some of the frameworks which are > > currently in the various > > > categories which haven't been active in a few years. > > In particular, I'd > > > like to move any framework which hasn't had a release > > since the beginning of > > > 2008 (arbitrary) into the "Discontinued / Inactive" > > framework category. I'd > > > be willing to do the work to make sure I wasn't moving > > one that actually > > > *did* have releases past that but just hadn't updated > > the page. > > > > > > Any dissent? > > > > > > - C > > Why not call them "apparently stable" > versus "under active development"? Is the > cgi module "discontinued"? > > I'm a little sensitive on this topic > because people tell me that Gadfly is "inactive" > or "discontinued" > but it still does what it does > as documented very well. > > Frequent releases may actually be a sign of > bugginess and bad design. > If you suspect a project is really dead, maybe you > could try to contact the authors and ask about > what they think. > > -- Aaron Watters > > === > BTW, I think "Release early, release often" is nonsense > because it means you are probably releasing > something buggy and unstable which will just alienate > your users, who will never come back to see the better > version. > > ___ > Web-SIG mailing list > Web-SIG@python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > http://mail.python.org/mailman/options/web-sig/ianb%40colorstudy.com > -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] http://wiki.python.org/moin/WebFrameworks
On 28 Nov, 08:03 pm, chr...@plope.com wrote: Well, that was my intention. I don't want to remove *actually* active or stable-and-still-used packages from the list. Maybe I should just dial back the date to the beginning of 2007 or something. Instead of trying to do this based on an arbitrary date, I'd suggest investigating the communities and developers for each project listed on the page. If no one is using the software, or the developers feel it would be appropriate to delist the software (or the developers are no longer responsive to communication attempts), then delisting it is probably a good idea. Otherwise, I think things should basically be left alone. Jean-Paul ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] http://wiki.python.org/moin/WebFrameworks
Aaron Watters wrote: On Thu, Nov 26, 2009 at 1:02 PM, Chris McDonough wrote: http://wiki.python.org/moin/WebFrameworks seems to be the place where folks are registering their respective web frameworks. I'd like to move some of the frameworks which are currently in the various categories which haven't been active in a few years. In particular, I'd like to move any framework which hasn't had a release since the beginning of 2008 (arbitrary) into the "Discontinued / Inactive" framework category. I'd be willing to do the work to make sure I wasn't moving one that actually *did* have releases past that but just hadn't updated the page. Any dissent? - C Why not call them "apparently stable" versus "under active development"? Is the cgi module "discontinued"? No, but the cgi module has undergone a lot of changes over the last couple of years which were present in Python releases: http://svn.python.org/view/python/branches/release26-maint/Lib/cgi.py?view=log I'm a little sensitive on this topic because people tell me that Gadfly is "inactive" or "discontinued" but it still does what it does as documented very well. Frequent releases may actually be a sign of bugginess and bad design. Agreed. On the other hand, though, no release for two years sometimes *does* mean it's dead. It's slightly unfair to the folks who are very actively improving a web framework to live in a "slot" on that page right next to actually-really-dead software because of the vagarities of lexical sorting. If you suspect a project is really dead, maybe you could try to contact the authors and ask about what they think. Well, that was my intention. I don't want to remove *actually* active or stable-and-still-used packages from the list. Maybe I should just dial back the date to the beginning of 2007 or something. - C ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] http://wiki.python.org/moin/WebFrameworks
> > On Thu, Nov 26, 2009 at 1:02 PM, Chris McDonough > wrote: > > http://wiki.python.org/moin/WebFrameworks > seems to be the place where folks > > are registering their respective web frameworks. > > > > I'd like to move some of the frameworks which are > currently in the various > > categories which haven't been active in a few years. > In particular, I'd > > like to move any framework which hasn't had a release > since the beginning of > > 2008 (arbitrary) into the "Discontinued / Inactive" > framework category. I'd > > be willing to do the work to make sure I wasn't moving > one that actually > > *did* have releases past that but just hadn't updated > the page. > > > > Any dissent? > > > > - C Why not call them "apparently stable" versus "under active development"? Is the cgi module "discontinued"? I'm a little sensitive on this topic because people tell me that Gadfly is "inactive" or "discontinued" but it still does what it does as documented very well. Frequent releases may actually be a sign of bugginess and bad design. If you suspect a project is really dead, maybe you could try to contact the authors and ask about what they think. -- Aaron Watters === BTW, I think "Release early, release often" is nonsense because it means you are probably releasing something buggy and unstable which will just alienate your users, who will never come back to see the better version. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
