[Python-Dev] Python development tools (Was: Goodbye)
On Wed, Sep 22, 2010 at 1:47 PM, Antoine Pitrou solip...@pitrou.net wrote: Simply, situations like the above (Mark closing a bug just because nobody would answer his message on a short delay) have happened multiple times - despite people opposing, obviously -, I must say that the same attitude is present in meta tracker proposals as well. People, who need a closure quite often tend to mark issues (enhancement proposals) as won't fix just because they can't (or don't want) to see solution or just because they think that solution is too complicated to implement. They judge it from the point of annoyed developer even though the feature can actually be handy for users of the tracker. The reason here could be that developers are lost in the amount of issues and can't filter them and see who does what. For example, I could triage issues for some modules I am interested in, but I can't. So, to overcome the complexity of global bug space developers are tempted to squash confusing issues. There can be only one solution - concentrate on the tools. Add an omnibox to tracker that will use autocompletion and labels (Google Code). Useful ticket query interface (Trac). Favorite issues (Google stars). Personal tags, issue sets, message filters (Slashdot). I've already brought the issue about necessity to enhance Python tools some six months ago. At that time Richard Leland promised to do a research of Python process to further work on proposal to improve it. This was due to June, but still no result. I should blame myself for waiting, because I had some plans to propose, but at that time it was impossible to get going, because everybody had big hopes for that research. There was a whole python-dev thread some time (weeks? months?) ago where several of us already tried to suggest more fruitful ways of contributing, suggestions which weren't received very welcomingly AFAIR. This will never give any results if you did not collecting the outcomes, summaries and links for the future. My vision is that other fruitful ways of contributing are not fun. The most modern tool with more or less sane gameplay here is tracker. But it suxx in many ways. Mostly because it is too old and too few are able to patch it due to either lack of information or experience (or time to get one or another). Mercurial is insane, and there isn't really anything else (except Sphinx). Well, there are lists, but there is nothing you can really do about them (except prevent Mailman from dropping archives from time to time or setup a Google Groups mirror). -- anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python wiki
On Fri, Sep 24, 2010 at 1:27 AM, Nick Coghlan ncogh...@gmail.com wrote: Antoine Given that few or none of us seem to (want to) actively Antoine contribute to the wiki, I'm afraid python-dev is not the place Antoine to ask. Perhaps a call should be issued on c.l.py ... It would be nice if you could actually send messages to the people who do actually update wiki content. Unfortunately, without donning my cape and blue tights, then digging into the users files on the wiki there's no real way to do that. That's bad. I'd really like to see the amount of my contributions so far. How about recording a session on MoinMoin hacking and drafting an upgrade plan? Who's gonna be the driver? That's a good point actually... why *isn't* there a pydotorg-wiki-sig? (Aside from the obvious point of nobody ever asking for one). Because Yet Another Mailing List doesn't solve the problem. If you need one - go Google Groups like packaging folks did. Python ML are: 1. require dedicated admin to update, who is not a member of the group 2. don't have search 3. don't have optional thread subscription That's already enough to seek better platform for collaboration. I must admit, that the various things I've thrown on there myself have been pretty much fire-and-forget. Without anyone that feels like they collectively own the wiki, the much needed pruning never happens. Community can perfectly manage the stuff without dedicated admins if there is a gameplay in it. I am doing the wiki works when I am redirected to outdated wiki pages from search. But I do it only if it doesn't take me more than 5 minutes, and if I can remember the password (and I know where an edit button is). My advice - subscribe people editing page by default (a checkbox near submit button). This way more people will receive notifications when a page is changed and will be more interested to contribute themselves. Of course, there must be a setting to opt out. With an admin team behind it, you can also make more use of ACLs to flag certain parts of the wiki as official by making them only editable by certain people (e.g. only devs, only the triage team, only the wiki admins). But keeping those user lists up to date is itself something that requires a strong wiki admin team. That's a dead way. Wiki should be open for everyone. Just need more people subscribed to revert unwelcome changes. That is to make timeline more visible, because on wiki.python.org it is _not_ intuitive. It may worth to see how Mercurial wiki is managed - I've picked up the bookmarks monitoring habit from it. Maybe a design change will help, but again - there is no entrypoint for people with design skills to start. A lot of problems. All on the surface. Mailing list won't help. What's next? -- anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.normcase rationale?
On 24 September 2010 23:43, Glenn Linderman v+pyt...@g.nevcal.com wrote: Hmm. There is no need for the function on a case sensitive file system, because the name had better be spelled with matching case: that is, if it is spelled with non-matching case it is an attempt to reference a non-existent file (or at least a different file). On Linux, I don't believe there's a way to ask is this filesystem case insensitive? In fact, with userfs, I believe it's possible to do massively pathological things like having a filesystem which treats anagrams as the same file (foo is the same file as oof or ofo). (More realistically, MacOS does Unicode normalisation). Windows has (I believe) user definable filesystems, too, but the OS has get me the real filename style calls, which the filesystem should support, so no matter how nasty a filesystem implementer gets, he has to deal with his own mess :-) Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
Am 25.09.2010 03:45, schrieb Brett Cannon: On Fri, Sep 24, 2010 at 13:04, Georg Brandl g.bra...@gmx.net wrote: So by opening and closing a bug 5 times within a week, the open and close counters both go up by 5? That would be stupid. No, as in a bug was re-opened last week and then closed again this week. Issues can't be open and closed at the same time. There is a count of open issues at the start of the week, and one at the end of the week. There's a difference between those two counts which in total must sum up to the total difference in issues. If I understand correctly how the counters work, they at least need to be renamed -- they do *not* count open/closed issues, they count openings/closings. Guess the only way to settle this is look at the code, but I don't care enough to bother. =) I'll bother Ezio when he's back. It just feels strange to me that the bit of statistic I feel is most interesting -- whether there are less open bugs at the end of the week than at the start -- is not obvious from the report. 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
Guess the only way to settle this is look at the code, but I don't care enough to bother. =) I'll bother Ezio when he's back. It just feels strange to me that the bit of statistic I feel is most interesting -- whether there are less open bugs at the end of the week than at the start -- is not obvious from the report. The total numbers reported are really the totals. Also, the delta reported for the totals is the difference to the last report. The number reported with +/- for open/closed are *not* deltas, but the number of issues opened since last week. As some open issues were closed and some closed issues were opened, they don't sum up the way you expect. An example: old: open: #1 #2 closed: #3 #4 new: open: #1 #3 #5 closed: #2 #4 The report would be open: 3 (+2, namely #3 and #5); delta would be +1 closed: 2 (+1, namely #4); delta would be 0 IOW, the numbers after +/- match the counts in the lists shown below, not the delta since last week. HTH, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python wiki
On Fri, Sep 24, 2010 at 1:31 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: More wiki and website maintainers needed! That's the consequence. You need to seek the reason why there are no maintainers or active members on pydotorg-www lists. I've expressed my thoughts earlier. On Fri, Sep 24, 2010 at 6:40 AM, Steven D'Aprano st...@pearwood.info wrote: For me, the number one roadblock is unfamiliarity -- I always forget that there is a Python wiki. For me a major annoyance is the empty page with two links on wiki.python.org While it allows to tell new people that there is also a Jython wiki, my vision that it should be instead be oriented on existing contributors immediately providing instruments to work with Python wiki. So if smb. need Jython wiki - it should be moved to wiki.jython.org I'd start from there. Who can do this? -- anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
Am 25.09.2010 14:10, schrieb Martin v. Löwis: Guess the only way to settle this is look at the code, but I don't care enough to bother. =) I'll bother Ezio when he's back. It just feels strange to me that the bit of statistic I feel is most interesting -- whether there are less open bugs at the end of the week than at the start -- is not obvious from the report. The total numbers reported are really the totals. Also, the delta reported for the totals is the difference to the last report. The number reported with +/- for open/closed are *not* deltas, but the number of issues opened since last week. As some open issues were closed and some closed issues were opened, they don't sum up the way you expect. An example: old: open: #1 #2 closed: #3 #4 new: open: #1 #3 #5 closed: #2 #4 The report would be open: 3 (+2, namely #3 and #5); delta would be +1 closed: 2 (+1, namely #4); delta would be 0 IOW, the numbers after +/- match the counts in the lists shown below, not the delta since last week. Yes, and that's what I complained about. However, your example doesn't demonstrate my problem, since its deltas *are* real deltas, and +1 + +0 == +1. I guess a better example would be old: open #1 #2 closed #3 new: open #1 closed #2 #3 #4 #5 which results in +2 for open (since #4 and #5 were opened) and +3 for closed (since #2, #4 and #5 were closed), however the total issue delta is +2. This is why I think these numbers should be labeled openings and closings. 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Relative imports in Py3k
Hi, I wonder if situation with relative imports in packages is improved in Python 3k or we are still doomed to a chain of hacks? My user story: I am currently debugging project, which consists of many modules in one package. Each module has tests or other useful stuff for debug in its main section, but it is a disaster to use it, because I can't just execute the module file and expect it to find relatives. All imports are like: from spyderlib.config import get_icon from spyderlib.utils.qthelpers import translate, add_actions, create_action PEP 328 http://www.python.org/dev/peps/pep-0328/ proposes: from ... import config from ..utils.qthelpers import translate, add_actions, create_action But this doesn't work, and I couldn't find any short user level explanation why it is not possible to make this work at least in Py3k without additional magic. -- anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python wiki
On Sat, Sep 25, 2010 at 8:22 AM, anatoly techtonik techto...@gmail.com wrote: For me a major annoyance is the empty page with two links on wiki.python.org While it allows to tell new people that there is also a Jython wiki, my vision that it should be instead be oriented on existing contributors immediately providing instruments to work with Python wiki. So if smb. need Jython wiki - it should be moved to wiki.jython.org That's funny, I've never seen that page before. Does it get linked to from somewhere? -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Relative imports in Py3k
Am 25.09.2010 15:15, schrieb anatoly techtonik: Hi, I wonder if situation with relative imports in packages is improved in Python 3k or we are still doomed to a chain of hacks? My user story: I am currently debugging project, which consists of many modules in one package. Each module has tests or other useful stuff for debug in its main section, but it is a disaster to use it, because I can't just execute the module file and expect it to find relatives. All imports are like: from spyderlib.config import get_icon from spyderlib.utils.qthelpers import translate, add_actions, create_action PEP 328 http://www.python.org/dev/peps/pep-0328/ proposes: from ... import config from ..utils.qthelpers import translate, add_actions, create_action But this doesn't work, and I couldn't find any short user level explanation why it is not possible to make this work at least in Py3k without additional magic. Uh, this doesn't work is a report that every developer loves. I suppose Python does raise an exception with a message? For diagnosing this, you should also at least include from which module you're trying to executing these import statements. 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 Python-Dev@python.org 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 wiki
Am 25.09.2010 15:15, schrieb David Stanek: On Sat, Sep 25, 2010 at 8:22 AM, anatoly techtonik techto...@gmail.com wrote: For me a major annoyance is the empty page with two links on wiki.python.org While it allows to tell new people that there is also a Jython wiki, my vision that it should be instead be oriented on existing contributors immediately providing instruments to work with Python wiki. So if smb. need Jython wiki - it should be moved to wiki.jython.org That's funny, I've never seen that page before. Does it get linked to from somewhere? It's at http://wiki.python.org/, and FTR, it has annoyed me as well. 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Relative imports in Py3k
On 9/25/2010 9:15 AM, anatoly techtonik wrote: from ... import config from ..utils.qthelpers import translate, add_actions, create_action But this doesn't work, and I couldn't find any short user level explanation why it is not possible to make this work at least in Py3k without additional magic. This doesn't belong on python-dev, as it's not about developing python. Also, it's a horrible bug report, if that's what it is. I'd suggest trying python-list and reading something like http://itscommonsensestupid.blogspot.com/2008/07/tips-to-write-good-bug-report.html Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
Éric Araujo writes: How about revamping the type/versions fields? Issue type () Feature request (blocked by moratorium: () yes () no) I think the information about blocked by moratorium is not something that users or devs will care about much. The users can be informed about the fact of the moratorium (There is currently a feature moratorium in effect. If this feature is determined to be a change in the language, it will not appear until Python 3.4 or later. Changes to the standard library functions are acceptable. If no progress is made on the issue in a reasonable time, you may request discussion on python-...@python.org.) in the reply page that confirms receipt of the issue. However, devs already know about the moratorium, and if there's a question of interpretation it will be discussed on python-dev. Users only care that their request is (not) being addressed; the moratorium is only one of many reasons why action is delayed. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.normcase rationale?
Paul Moore writes: In fact, with userfs, I believe it's possible to do massively pathological things like having a filesystem which treats anagrams as the same file (foo is the same file as oof or ofo). (More realistically, MacOS does Unicode normalisation). Nitpick: Mac OS X doesn't do Unicode normalization. The default filesystem implementation does. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.normcase rationale?
On Fri, Sep 24, 2010 at 8:25 PM, Steven D'Aprano st...@pearwood.info wrote: On Sat, 25 Sep 2010 09:22:47 am Guido van Rossum wrote: I think that, like os.path.realpath(), it should not fail if the file does not exist. Maybe the API could be called os.path.unnormpath(), since it is in a sense the opposite of normpath() (which removes case) ? But I would want to write it so that even on Unix it scans the filesystem, in case the filesystem is case-preserving (like the default fs on OS X). It is not entirely clear to me what this function is meant to actually do? Should it: 1. Return the case of a filename in some canonical form which depends on the file system? 2. Return the case of a filename as it is actually stored on disk? This one. This is actually useful (on case-preserving filesystems). There is no doubt in my mind that this is the requested and needed functionality. 3. Something else? and just for completeness: 4. Return the case of a filename in some arbitrarily-chosen canonical form which does not depend on the file system? These are not the same, either conceptually or in practice. If you want #4, you already have it in os.path.normcase. I think that the OP, Chris, wants #1, but it isn't entirely clear to me. I don't think this is where the issue lies. It's possible that he wants #2. Various people have posted links to recipes that solve case #2. Note though that this necessarily demands that if the file doesn't exist, it should raise an exception. No it needn't; realpath() uses the filesystem but leaves non-existing parts alone. Also some of the path may exist (e.g. a parent directory). In the case of #1, if the file system doesn't exist, we can't predict what the canonical form should be. The very concept of canonical form for file names is troublesome. If the file system is case-preserving, the file system doesn't define a canonical form: the case of the file name will depend on how the file is initially named. If the file system is case-destructive the behaviour will depend on the file system itself: e.g. FAT12 and ISO 9660 both uppercase file names, but other file systems may make other choices. For some arbitrary path, where we don't know what file system it is, or if the path doesn't actually exist, we have no way of telling what the file system's canonical form will be, or even whether it will have one. Note that I've been talking about case preservation, not case sensitivity. That's because case preservation is orthogonal to sensitivity. You can see three of the four combinations, e.g.: Preserving + insensitive: fat32, NTFS under Win32, normally HFS+ Preserving + sensitive: ext3, NTFS under POSIX, optionally HFS+ Destructive + insensitive: fat12, fat16 without long file name support To the best of my knowledge, destructive + sensitive doesn't exist. It could, in principle, but it would be silly to do so. Note that just knowing the file system type is not enough to tell what its behaviour will be. Given an arbitrary file system, there's no obvious way to determine what it will do to file names short of trying to create a file and see what happens. This operation should not do any writes. The solution may well be OS specific. Solutions for Windows and OS X have already been pointed out. If it can't be done for other Unix versions, I think returning the input unchanged on those platform is a fine fallback (as it is for non-existent filenames). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r85000 - python/branches/py3k/Lib/test/test_trace.py
On Sat, 25 Sep 2010 00:04:23 +0200 (CEST) alexander.belopolsky python-check...@python.org wrote: Author: alexander.belopolsky Date: Sat Sep 25 00:04:22 2010 New Revision: 85000 Log: This should fix buildbot failure introduced by r84994 Can you also backport it to 2.7? Thanks Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
On 9/25/2010 7:11 AM, Georg Brandl wrote: I'll bother Ezio when he's back. It just feels strange to me that the bit of statistic I feel is most interesting -- whether there are less open bugs at the end of the week than at the start -- is not obvious from the report. As of just now, the default search for all open issues returns 2475. That is down steadily over the last 8 or so weeks from a peak of about 2750 in early June. About 30 people have closed at least one issue in this period. The current figure is up from about 1200 a few years ago. Part of the increase is due to the 2.x to 3.x transition and the bulge from 2 to 4 active issues. I would roughly guess that there are perhap a couple hundred 2.7-only issue. You just closed one today. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
Am 25.09.2010 18:53, schrieb Terry Reedy: On 9/25/2010 7:11 AM, Georg Brandl wrote: I'll bother Ezio when he's back. It just feels strange to me that the bit of statistic I feel is most interesting -- whether there are less open bugs at the end of the week than at the start -- is not obvious from the report. As of just now, the default search for all open issues returns 2475. That is down steadily over the last 8 or so weeks from a peak of about 2750 in early June. About 30 people have closed at least one issue in this period. That's really promising. (And that's also why I want to see a negative delta for the open count.) Thanks for these numbers! 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 Python-Dev@python.org 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 wiki
Hello, I've been following this thread all week at work, but I thought it might be time to respond to the different remarks in a single response, given that I am involved in editing and maintaining the Wiki on python.org, and I had a strong enough opinion about such things to give a talk about it at EuroPython that some of you attended: http://wiki.europython.eu/Talks/Web_Collaboration_And_Python/Talk Guido van Rossum wrote: On Thu, Sep 23, 2010 at 3:35 PM, Martin v. Löwis martin at v.loewis.de wrote: There actually is an admin team, and they actually do set ACLs. Who are they? IIUC, this is primarily for spam protection, though. So would they object against additions to the team? The administrators are generally the people on the following page: http://wiki.python.org/moin/AdminGroup Someone may have special powers, particularly if they have shell access to the machine running the Wiki, but there's no secret brotherhood. In fact, I recall advocating that Carl Trachte get admin powers given his continuing high-quality contributions, so we can say that people aren't denying others administrative privileges if that person is clearly doing good work and would benefit from being able to have those privileges. [Later on...] Guido van Rossum wrote: On Fri, Sep 24, 2010 at 3:31 AM, Michael Foord fuzzyman at voidspace.org.uk wrote: Wiki maintenance is discussed, along with other python.org maintenance topics, on the pydotorg-www mailing list: http://mail.python.org/mailman/listinfo/pydotorg-www Which has hidden its membership (even to members). Does it really need to appear that secretive? At least the message archive is open and has all the usual suspects. As we're now seeing, people don't feel that it's acceptable to publish the subscribers list, and I think that it's a complete distraction to seek to do so, anyway. It's not as if everyone on that list has special privileges and is preventing newcomers from joining it. More wiki and website maintainers needed! Maybe a prominent wiki page with info about how to join the list and the responsibilities / needs would help? Also, I gotta say that the wiki login process is awkward. MoinMoin supports OpenID, although I did find and report issues with Moin 1.9 in this regard. Something on my now-huge list of things to do is to make Moin authentication better, especially where there might be a choice of authentication methods. Georg Brandl wrote: Am 23.09.2010 22:25, schrieb anatoly techtonik: On Thu, Sep 23, 2010 at 6:57 PM, Barry Warsaw barry at python.org wrote: I certainly agree with that. So, how can we solve those problems? Radomir has shell access now so perhaps we can ask him to make the Python wiki theme more visually appealing. What roadblocks do people encounter when they want to help garden or reorganize the wiki? First of all Wiki is outdated. Correct me, but python.org specific customizations are not modules, but patches that makes it hard to update the Wiki to latest version or add new customizations. That's why we have a Moin core developer on the team. ISTM that Moin 1.x is notoriously hard to extend -- once you go beyond plugins adding new wiki macros -- which is part of what the team wants to fix in 2.x. Although I understand the sentiments about specific customizations, python.org should only have its theme as something that isn't a generic extension to MoinMoin, and that theme should be actively maintained. When python.org switched its architecture a while ago, the special theme presumably came with the deal, but it's been so out of date for so long that I switched to one of the standard themes years ago. Fortunately, Radomir's EuroPython theme is actively maintained, works with recent MoinMoin releases, looks a lot better than the old theme, and is used elsewhere. As for Moin 1.x being notoriously hard to extend beyond macros, you can get a long way with macros and actions, although I agree that sometimes it's possible to hit architectural constraints. Second - ugly Creole syntax. I am for inter-cooperation between wikis, and I understand that for non-developer communities [] symbols imposing problems, but as an open source developer I am addicted to Trac and Google Code syntax and never had problems with those. This isn't Creole syntax, it's Moin wiki syntax. And face it, it's not going to change. It's also not so much different from Trac wiki syntax. I never agreed with this complaint, anyway. When discussing this previously with Anatoly, I went as far as to ask on #moin where Radomir actually posted a good summary of the syntax differences: http://wiki.python.org/moin/SiteImprovements/WikiSyntaxComparison I invite anyone to justify claims that the old style (which Trac adopted) was better. Complaints about double bracketing are specious: MediaWiki has different bracketing levels and it's really confusing. Fourth. GPL license.
Re: [Python-Dev] Python wiki
On 25/09/2010 20:12, Paul Boddie wrote: [snip...] Guido van Rossum wrote: On Fri, Sep 24, 2010 at 3:31 AM, Michael Foord fuzzyman at voidspace.org.uk wrote: Wiki maintenance is discussed, along with other python.org maintenance topics, on the pydotorg-www mailing list: http://mail.python.org/mailman/listinfo/pydotorg-www Which has hidden its membership (even to members). Does it really need to appear that secretive? At least the message archive is open and has all the usual suspects. As we're now seeing, people don't feel that it's acceptable to publish the subscribers list, To be fair, quite a few people said they thought it was fine / a good thing. A couple (maybe 3?) said that as the list was originally advertised with the member list hidden it would be unfair to change. So based on responses, more people think it *is* acceptable. So long as we give notice for the change, so that anyone who doesn't want their name associated with the list can unsubscribe, I don't see why there should be a problem. All the best, Michael and I think that it's a complete distraction to seek to do so, anyway. It's not as if everyone on that list has special privileges and is preventing newcomers from joining it. -- 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 Python-Dev@python.org 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 wiki
Am 25.09.2010 21:12, schrieb Paul Boddie: Georg Brandl wrote: Am 23.09.2010 22:25, schrieb anatoly techtonik: On Thu, Sep 23, 2010 at 6:57 PM, Barry Warsaw barry at python.org wrote: I certainly agree with that. So, how can we solve those problems? Radomir has shell access now so perhaps we can ask him to make the Python wiki theme more visually appealing. What roadblocks do people encounter when they want to help garden or reorganize the wiki? First of all Wiki is outdated. Correct me, but python.org specific customizations are not modules, but patches that makes it hard to update the Wiki to latest version or add new customizations. That's why we have a Moin core developer on the team. ISTM that Moin 1.x is notoriously hard to extend -- once you go beyond plugins adding new wiki macros -- which is part of what the team wants to fix in 2.x. Although I understand the sentiments about specific customizations, python.org should only have its theme as something that isn't a generic extension to MoinMoin, and that theme should be actively maintained. When python.org switched its architecture a while ago, the special theme presumably came with the deal, but it's been so out of date for so long that I switched to one of the standard themes years ago. Fortunately, Radomir's EuroPython theme is actively maintained, works with recent MoinMoin releases, looks a lot better than the old theme, and is used elsewhere. As a disclaimer, I have no idea about the specific configuration of Moin used at wiki.python.org. As for Moin 1.x being notoriously hard to extend beyond macros, you can get a long way with macros and actions, although I agree that sometimes it's possible to hit architectural constraints. It's just that every Moin installation I've come across used custom patches, and as a consequence was difficult to update. 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] WSGI is now Python 3-friendly
I have only done the Python 3-specific changes at this point; the diff is here if anybody wants to review, nitpick or otherwise comment: http://svn.python.org/view/peps/trunk/pep-0333.txt?r1=85014r2=85013pathrev=85014 For that matter, if anybody wants to take a crack at updating Python 3's wsgiref based on the above, feel free. ;-) I'll be happy to answer any questions I can that come up in the process. (Please note: I went with Ian Bicking's headers are strings, bodies are bytes proposal, rather than my original bodies and outputs are bytes one, as there were not only some good arguments in its favor, but because it also resulted in fewer changes to the PEP, especially in the code samples.) I will continue to work on adding the other addenda/errata mentioned here: http://mail.python.org/pipermail/web-sig/2010-September/004655.html But because these are shoulds rather than musts, and apply to both Python 2 and 3, they are not as high priority for immediate implementation in wsgiref and do not necessarily need to hold up the 3.2 release. (Nonetheless, if anybody is willing to implement them in the Python 3 version, I will happily review the changes for backport into the Python 2 standalone version of wsgiref, and issue an updated release to include them.) Thanks! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
On Sat, 25 Sep 2010 14:22:06 +0200, Georg Brandl g.bra...@gmx.net wrote: Am 25.09.2010 14:10, schrieb Martin v. L=F6wis: The total numbers reported are really the totals. Also, the delta reported for the totals is the difference to the last report. The number reported with +/- for open/closed are *not* deltas, but the number of issues opened since last week. As some open issues were closed and some closed issues were opened, they don't sum up the way you expect. An example: old: open: #1 #2 closed: #3 #4 new: open: #1 #3 #5 closed: #2 #4 The report would be open: 3 (+2, namely #3 and #5); delta would be +1 closed: 2 (+1, namely #4); delta would be 0 IOW, the numbers after +/- match the counts in the lists shown below, not the delta since last week. Yes, and that's what I complained about. However, your example doesn't demonstrate my problem, since its deltas *are* real deltas, and +1 + +0 = +1. I guess a better example would be old: open #1 #2 closed #3 new: open #1 closed #2 #3 #4 #5 which results in +2 for open (since #4 and #5 were opened) and +3 for closed (since #2, #4 and #5 were closed), however the total issue delta is +2. Th= is why I think these numbers should be labeled openings and closings. I haven't looked at the code, so I don't know the details of the algorithm that is actually used, but from what Ezio said your example is *not* correct. The numbers in parenthesis are the number of issues opened/closed in the past week that are *still* open or closed. So open would certainly not be +2. I'm not sure if it would be +0 or -1 without looking at the code. I agree that having the delta against open from the previous week would be the most helpful. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python wiki
On Sat, Sep 25, 2010 at 12:12 PM, Paul Boddie p...@boddie.org.uk wrote: Guido van Rossum wrote: Also, I gotta say that the wiki login process is awkward. MoinMoin supports OpenID, although I did find and report issues with Moin 1.9 in this regard. Something on my now-huge list of things to do is to make Moin authentication better, especially where there might be a choice of authentication methods. Unfortunately, most sites using OpenID seem have an awkward login process. Maybe it's just me (I don't use OpenID much) but I expect that without a lot more handholding of new users, OpenID actually turns more people away than any other registration/login process. The people who like OpenID are often the ultra-geeks who cannot imagine the worldview of a typical internet user, and when they design a website they are often clueless about what it feels like to start using OpenID for the first time or to remember your OpenID handle if the last time you used it was a month ago. Not that the native Moin login method is much better... Either way, Python's wikis have some of the most awkward auth systems I've come across. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
This is a very laudable initiative and I approve of the changes -- but I really think it ought to be a separate PEP rather than pretending it is just a set of textual corrections on the existing PEP 333. --Guido On Sat, Sep 25, 2010 at 12:56 PM, P.J. Eby p...@telecommunity.com wrote: I have only done the Python 3-specific changes at this point; the diff is here if anybody wants to review, nitpick or otherwise comment: http://svn.python.org/view/peps/trunk/pep-0333.txt?r1=85014r2=85013pathrev=85014 For that matter, if anybody wants to take a crack at updating Python 3's wsgiref based on the above, feel free. ;-) I'll be happy to answer any questions I can that come up in the process. (Please note: I went with Ian Bicking's headers are strings, bodies are bytes proposal, rather than my original bodies and outputs are bytes one, as there were not only some good arguments in its favor, but because it also resulted in fewer changes to the PEP, especially in the code samples.) I will continue to work on adding the other addenda/errata mentioned here: http://mail.python.org/pipermail/web-sig/2010-September/004655.html But because these are shoulds rather than musts, and apply to both Python 2 and 3, they are not as high priority for immediate implementation in wsgiref and do not necessarily need to hold up the 3.2 release. (Nonetheless, if anybody is willing to implement them in the Python 3 version, I will happily review the changes for backport into the Python 2 standalone version of wsgiref, and issue an updated release to include them.) Thanks! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python wiki
Unfortunately, most sites using OpenID seem have an awkward login process. Maybe it's just me (I don't use OpenID much) but I expect that without a lot more handholding of new users, OpenID actually turns more people away than any other registration/login process. So how do you like the OpenID login of PyPI, which has a Google, MyOpenID and Launchpad icon, which users need to click on to create in account or login? The ultra geeks demanded and got a separate page where they can enter long URLs. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
I guess a better example would be old: open #1 #2 closed #3 new: open #1 closed #2 #3 #4 #5 which results in +2 for open (since #4 and #5 were opened) and +3 for closed (since #2, #4 and #5 were closed), however the total issue delta is +2. This is why I think these numbers should be labeled openings and closings. I *have* looked at the code, any I'm certain that this is not how the computation goes. Instead, I'm also certain that it goes as in the message I sent. Notice that it prints the numbers I put into parentheses (+2, +1), and they do *not* sum up to +1. The numbers I posted as delta would be are not currently included in the report. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
Am 25.09.2010 23:41, schrieb Martin v. Löwis: I guess a better example would be old: open #1 #2 closed #3 new: open #1 closed #2 #3 #4 #5 which results in +2 for open (since #4 and #5 were opened) and +3 for closed (since #2, #4 and #5 were closed), however the total issue delta is +2. This is why I think these numbers should be labeled openings and closings. I *have* looked at the code, any I'm certain that this is not how the computation goes. Instead, I'm also certain that it goes as in the message I sent. Notice that it prints the numbers I put into parentheses (+2, +1), and they do *not* sum up to +1. The numbers I posted as delta would be are not currently included in the report. Ah. I misunderstood, sorry. Well, let's bury this thread then and I will put it on my todo list to modify it to work as expected. 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Relative imports in Py3k
Also, it's a horrible bug report, if that's what it is. It's not a bug report, and I don't think it was meant to be one. It started with I wonder if, suggesting that it is really a request for help. What you read as a bug report was labeled user story, which I think is anatoly's way of saying it's not a bug report. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python wiki
Am 25.09.2010 23:43, schrieb Martin v. Löwis: For me a major annoyance is the empty page with two links on wiki.python.org While it allows to tell new people that there is also a Jython wiki, my vision that it should be instead be oriented on existing contributors immediately providing instruments to work with Python wiki. So if smb. need Jython wiki - it should be moved to wiki.jython.org That's funny, I've never seen that page before. Does it get linked to from somewhere? It's at http://wiki.python.org/, and FTR, it has annoyed me as well. So how would you propose to resolve this? Keep in mind that existing links need to continue to work. Redirect wiki.python.org to the Python wiki front page, and put the Jython wiki somewhere on its own (whether it's wiki.jython.org or not). The only people who will need a pointer are those who went directly to wiki.python.org/ and intended to go to the Jython wiki; a link might be added on the front page of the Python wiki. 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 Python-Dev@python.org 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 wiki
As we're now seeing, people don't feel that it's acceptable to publish the subscribers list, Michael To be fair, quite a few people said they thought it was fine / Michael a good thing. A couple (maybe 3?) said that as the list was Michael originally advertised with the member list hidden it would be Michael unfair to change. So based on responses, more people think it Michael *is* acceptable. I've not yet responded to this aspect of the thread. I see no reason not to make the membership list visible to the list members themselves. Beyond that, I don't think it serves any benefit, and of course, runs the risk of exposing email addresses to spam harvesters. OTOH, those of us who are visible enough on the web that we get to the point of helping maintain a very public website have probably already exposed our email addresses dozens or hundreds of times (or more) to spammers. Googling for s...@pobox.com (the quotes are required to constrain the search properly) yields about 22,000 hits. gu...@python.org yields about 38,000 hits. Paul's and Michael's addresses returned multiple thousands of hits. And so on. As I recall, one reason for the formation of pydotorg-www was to create a more visible list than pydotorg so the maintenance of the website didn't appear so cabalistic to the interested observer. Still, I see that most/all lists hosted on mail.python.org seem to restrict the list membership to the list admins, so leaving the status quo probably won't hurt anything. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python wiki
Redirect wiki.python.org to the Python wiki front page, and put the Jython wiki somewhere on its own (whether it's wiki.jython.org or not). But that can't work: then off-site links into either wiki break. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python wiki
Am 26.09.2010 00:16, schrieb Martin v. Löwis: Redirect wiki.python.org to the Python wiki front page, and put the Jython wiki somewhere on its own (whether it's wiki.jython.org or not). But that can't work: then off-site links into either wiki break. Why -- they can be redirected easily. 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.normcase rationale?
Paul Moore wrote: Windows has (I believe) user definable filesystems, too, but the OS has get me the real filename style calls, Does it really, though? The suggestions I've seen for doing this involve abusing the short/long filename translation machinery, and I'm not sure they're guaranteed to return the actual case rather than something that happens to work. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python wiki
Am 26.09.2010 00:48, schrieb Georg Brandl: Am 26.09.2010 00:16, schrieb Martin v. Löwis: Redirect wiki.python.org to the Python wiki front page, and put the Jython wiki somewhere on its own (whether it's wiki.jython.org or not). But that can't work: then off-site links into either wiki break. Why -- they can be redirected easily. Ok, so please be more specific: what exactly should the new structure look like? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Goodbye
On 9/24/2010 10:50 AM, Antoine Pitrou wrote: Le samedi 25 septembre 2010 à 00:42 +1000, Nick Coghlan a écrit : I have often used searches on performance or resource usage to find what was needing a review or a patch. I think it would be a mistake to remove those two categories. That purpose would be served just as well by keywords though (particularly since those attributes aren't mutually exclusive - resource usage problems will usually *cause* performance problems, and you may notice the latter first). Keywords are generally better than a restricted vocabulary for richness of content, but worse for finding the appropriate search term. You pays yer money and takes yer chance. Given that we could (if necessary) overlay some sort of Python-specific semantic category generation to searches if we needed to, I tend to favor the liberally tag with keywords approach. But without any smarts being applied to the problem it's always to know whether you are searching for the right keywords. A generic bug classification would also better suit documentation bugs. The simpler we can make the more common fields, while still providing the essential information, the better. But how should a performance improvement be filed? Bug? Feature request? Or should feature request be renamed improvement? Not all features would be improvements (and I'm thinking specifically here of 2.x's print f as an egregious design wart added for entirely pragmatic reasons). They could, however, be classified along with performance improvement requests as Enhancement requests. The big problem, I suspect, is that we don't give clear enough guidance to almost total noobs about how to fill in the issue tracker form. If you can't remember what your first month as a programmer was like then you probably aren't qualified to be writing int on-line help for the tracker. (The tracker does *have* on-line help, right?) 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
On Sat, Sep 25, 2010 at 3:56 PM, P.J. Eby p...@telecommunity.com wrote: I have only done the Python 3-specific changes at this point; the diff is here if anybody wants to review, nitpick or otherwise comment: http://svn.python.org/view/peps/trunk/pep-0333.txt?r1=85014r2=85013pathrev=85014 For that matter, if anybody wants to take a crack at updating Python 3's wsgiref based on the above, feel free. ;-) I'll be happy to answer any questions I can that come up in the process. (Please note: I went with Ian Bicking's headers are strings, bodies are bytes proposal, rather than my original bodies and outputs are bytes one, as there were not only some good arguments in its favor, but because it also resulted in fewer changes to the PEP, especially in the code samples.) I will continue to work on adding the other addenda/errata mentioned here: http://mail.python.org/pipermail/web-sig/2010-September/004655.html But because these are shoulds rather than musts, and apply to both Python 2 and 3, they are not as high priority for immediate implementation in wsgiref and do not necessarily need to hold up the 3.2 release. (Nonetheless, if anybody is willing to implement them in the Python 3 version, I will happily review the changes for backport into the Python 2 standalone version of wsgiref, and issue an updated release to include them.) Thanks! This looks like good progress (and does not seem to block the progress of PEP 444) but would it be possible to do it as a different PEP rather then just an update; or adding an explicit these are the differences between v1 and v2 section? It seems like it will end up different enough to be a different specification, closely related to the original, but different enough to trip up all the people maintaining current WSGI servers and apps. jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
At 09:22 PM 9/25/2010 -0400, Jesse Noller wrote: It seems like it will end up different enough to be a different specification, closely related to the original, but different enough to trip up all the people maintaining current WSGI servers and apps. The only actual *change* to the spec is mandating the use of the 'bytes' type or equivalent for HTTP bodies when using Python 3. Seriously, that's *it*. Everything else that's (planned to be) added is either 100% truly just clarifications (e.g. nothing in the spec *ever* said SERVER_PORT could be an int, but apparently some people somehow interpreted it so), or else best-practice recommendations from people who actually implemented WSGI servers. For example, the readline() size hint is not supported in the original spec (meaning clients can't call it and be compliant). The planned modification is servers should implement it (best practice), but you can't call an implementation that *doesn't* implement it noncompliant. (This just addresses the fact that most practical implementations *did* in fact support it, and code out there relies on this.) So, no (previously-)compliant implementations were harmed in the making of the updated spec. If they were compliant before, they're compliant now. I'm actually a bit surprised people are bringing this up now, since when I announced the plan to make these changes, I said that nothing would be changed that would break anything... even for what I believe are the only Python 3 WSGI implementations right now (by Graham Dumpleton and Robert Brewer). Indeed, all of the changes (except the bytes thing) are stuff previously discussed endlessly on the Web-SIG (years ago in most cases) and widely agreed on as, this should have been made clear in the original PEP. And, I also explicitly deferred and/or rejected items that *can't* be done in a 100% backward-compatible way, and would have to be WSGI 1.1 or higher -- indeed, I have a long list of changes from Graham that I've pronounced can't be done without a 1.1. Indeed, the entire point of the my scope choices were to allow all this to happen *without* a whole new spec. ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
On 9/25/2010 1:08 PM, Antoine Pitrou wrote: On Sat, 25 Sep 2010 19:02:06 +0200 Georg Brandlg.bra...@gmx.net wrote: Am 25.09.2010 18:53, schrieb Terry Reedy: On 9/25/2010 7:11 AM, Georg Brandl wrote: I'll bother Ezio when he's back. It just feels strange to me that the bit of statistic I feel is most interesting -- whether there are less open bugs at the end of the week than at the start -- is not obvious from the report. As of just now, the default search for all open issues returns 2475. That is down steadily over the last 8 or so weeks from a peak of about 2750 in early June. About 30 people have closed at least one issue in this period. That's really promising. (And that's also why I want to see a negative delta for the open count.) Thanks for these numbers! Without any precision on how and why these bugs were closed, these numbers don't mean anything. We would need a breakdown of bug closings according to the resolution field, at the minimum. Doing some hand-counting because I do not have proper (as in sql query) access to the database, closed issues so far for Activity: 2010-09 174 fixed 36 invalid 31 out of date 1 postponed 18 reject 18 won't fix 7 works for me --- 285 -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
At 02:07 PM 9/25/2010 -0700, Guido van Rossum wrote: This is a very laudable initiative and I approve of the changes -- but I really think it ought to be a separate PEP rather than pretending it is just a set of textual corrections on the existing PEP 333. With the exception of the bytes change, I ruled out accepting any proposed amendments that would actually alter the protocol. The amendments are all either textual clarifications, clarifications of ambiguous/unspecified areas, or best-practice recommendations by implementors. (i.e., which are generally already implemented in major servers) The full list of things Graham and others have asked for or recommended would indeed require a 1.1 version at minimum, and thus a new PEP. But I really don't want to start down that road right now, and therefore hope that I can talk Graham or some other poor soul into shepherding a 1.1 PEP instead. ;-) (Seriously: through an ironic twist of fate, I have done nearly *zero* Python web programming since around the time I drafted the first spec in 2004, so even if it makes sense for me to finish PEP 333, it makes little sense for me to be starting a *new* one on the topic now!) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
On Sat, Sep 25, 2010 at 7:00 PM, P.J. Eby p...@telecommunity.com wrote: At 02:07 PM 9/25/2010 -0700, Guido van Rossum wrote: This is a very laudable initiative and I approve of the changes -- but I really think it ought to be a separate PEP rather than pretending it is just a set of textual corrections on the existing PEP 333. With the exception of the bytes change, I ruled out accepting any proposed amendments that would actually alter the protocol. The amendments are all either textual clarifications, clarifications of ambiguous/unspecified areas, or best-practice recommendations by implementors. (i.e., which are generally already implemented in major servers) Of those, IMO only textual clarifications ought to be made to an existing, accepted, widely implemented standards-track PEP. Clarifications of ambiguous/unspecified behavior can possibly rule as non-conforming implementations that used to get the benefit of the doubt. Best-practice recommendations also have the effect of changing (perceived) compliance. Really, what's the problem with creating a new PEP? PEPs are cheap -- it's getting the acceptance that's costly, and you've already gotten that part. It doesn't have to be long. You can still make pure textual clarifications to PEP 333 (basically, improve grammar) and add a pointer to the new PEP. Or, you can create a new PEP that is an updated copy of PEP 333, and just add a pointer to PEP 333 saying (especially in the context of Python 3) this PEP is now superseded by PEP . I strongly disagree with using (standards-track) PEPs as mutable documents -- before you know it people will have to use weasel words like compliant with PEP 333 as of date X to describe their software's conformity. If you add a new PEP #, software declared compliant with PEP 333 remains compliant (and some such software can now also claim compliance with the new PEP without any changes). The full list of things Graham and others have asked for or recommended would indeed require a 1.1 version at minimum, and thus a new PEP. But I really don't want to start down that road right now, and therefore hope that I can talk Graham or some other poor soul into shepherding a 1.1 PEP instead. ;-) That's fine. It will just be another PEP. (Seriously: through an ironic twist of fate, I have done nearly *zero* Python web programming since around the time I drafted the first spec in 2004, so even if it makes sense for me to finish PEP 333, it makes little sense for me to be starting a *new* one on the topic now!) Don't see this as a new spec. See it as a procedural issue. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com