[Python-Dev] Python development tools (Was: Goodbye)

On Wed, Sep 22, 2010 at 1:47 PM, Antoine Pitrou 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

Re: [Python-Dev] os.path.normcase rationale?

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

Re: [Python-Dev] os.path.normcase rationale?

Guido van Rossum wrote: Maybe the API could be called os.path.unnormpath(), since it is in a sense the opposite of normpath() (which removes case) ? Cute, but not very intuitive. Something like actualpath() might be better -- although that's somewhat arbitrarily different from realpath(). --

Re: [Python-Dev] os.path function for “get the re al filename”

Ben Finney wrote: Your heuristics seem to assume there will only ever be a maximum of one match, which is false. I present the following example: $ ls foo/ bAr.dat BaR.dat bar.DAT There should perhaps be an extra step at the beginning: 0) Test whether the specified path refers

Re: [Python-Dev] Summary of Python tracker Issues

On Fri, Sep 24, 2010 at 13:04, Georg Brandl 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 th

Re: [Python-Dev] os.path.normcase rationale?

On Sep 24, 2010, at 10:53 AM, Paul Moore wrote: > On 24 September 2010 15:29, Guido van Rossum wrote: >> I don't think we should try to reimplement what the filesystem does. I >> think we should just ask the filesystem (how exactly I haven't figured >> out yet but I expect it will be more OS-speci

Re: [Python-Dev] os.path function for “get the r eal filename” (was: os.path.normcase ra tionale?)

I think searching a case-sensitive filename for a case-insensitive match should not be offered as part of os.path. Apps that really want to do things like """There is no file named "README", do you want to use "Readme" instead?""" can write their own inefficient code, thank you. --Guido On Fri, S

Re: [Python-Dev] os.path.normcase rationale?

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

Re: [Python-Dev] PyObject_GC_UnTrack() no longer reliable in 2.7?

[Tim] >> I assume this is unintended because (a) the docs weren't changed to >> warn about this; and, (b) it's wrong ;-) [Martin v. Löwis] > It seems Jim is happy with (or has at least accepted) the behavior > change. Would you still like to see it fixed (or, rather, have the > 2.6 state restored)

[Python-Dev] os.path function for “get the re al filename” (was: os.path.normcase rationale ?)

Greg Ewing writes: > Maybe we could use a heuristic such as: Your heuristics seem to assume there will only ever be a maximum of one match, which is false. I present the following example: $ ls foo/ bAr.dat BaR.dat bar.DAT > 1) Search the directory for an exact match to the name

Re: [Python-Dev] os.path.normcase rationale?

On 9/24/2010 3:10 PM, Greg Ewing wrote: Paul Moore wrote: I dug into this once, and as far as I could tell, it's possible to get the information on Windows, but there's no way on Linux to "ask the filesystem". Maybe we could use a heuristic such as: 1) Search the directory for an exact matc

Re: [Python-Dev] PyObject_GC_UnTrack() no longer reliable in 2.7?

Am 24.09.2010 23:22, schrieb Daniel Stutzbach: > On Fri, Sep 24, 2010 at 4:09 PM, "Martin v. Löwis" > wrote: > > I think it would be possible to have two versions of > _PyGC_REFS_UNTRACKED, one being, say, -5. > _PyGC_REFS_UNTRACKED_AND_KEEP_IT_THAT_WAY woul

Re: [Python-Dev] os.path.normcase rationale?

Paul Moore wrote: I dug into this once, and as far as I could tell, it's possible to get the information on Windows, but there's no way on Linux to "ask the filesystem". Maybe we could use a heuristic such as: 1) Search the directory for an exact match to the name given, return it if found.

Re: [Python-Dev] PyObject_GC_UnTrack() no longer reliable in 2.7?

On Fri, Sep 24, 2010 at 4:09 PM, "Martin v. Löwis" wrote: > I think it would be possible to have two versions of > _PyGC_REFS_UNTRACKED, one being, say, -5. > _PyGC_REFS_UNTRACKED_AND_KEEP_IT_THAT_WAY would be what you get > when you call PyObject_GC_UnTrack; the code to do automatic > tracking/un

Re: [Python-Dev] PyObject_GC_UnTrack() no longer reliable in 2.7?

> I assume this is unintended because (a) the docs weren't changed to > warn about this; and, (b) it's wrong ;-) It seems Jim is happy with (or has at least accepted) the behavior change. Would you still like to see it fixed (or, rather, have the 2.6 state restored)? I think it would be possible

Re: [Python-Dev] PyObject_GC_UnTrack() no longer reliable in 2.7?

On Fri, Sep 24, 2010 at 3:36 PM, Antoine Pitrou wrote: > On Fri, 24 Sep 2010 15:14:32 -0400 > Tim Peters wrote: >> Looks like 2.7 changes introduced to exempt dicts and tuples from >> cyclic gc if they obviously can't be in cycles has some unintended >> consequences.  Specifically, if an extensio

Re: [Python-Dev] Summary of Python tracker Issues

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. 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 t

Re: [Python-Dev] Summary of Python tracker Issues

On Fri, Sep 24, 2010 at 12:57, Georg Brandl wrote: > Is it me, or is the "open" and "closed" count confusing to anyone else? > I.e., shouldn't the "total" delta equal the sum of the "open" delta and > the "closed" delta? The total delta is a complete count of bugs, while the open and closed delta

Re: [Python-Dev] Summary of Python tracker Issues

Is it me, or is the "open" and "closed" count confusing to anyone else? I.e., shouldn't the "total" delta equal the sum of the "open" delta and the "closed" delta? Georg Am 24.09.2010 20:00, schrieb Brett Cannon: > I think every week where more bugs are closed than opened should be > celebrated!

Re: [Python-Dev] Goodbye

On 9/24/2010 1:41 AM, Stephen J. Turnbull wrote: Yes, and we'd all like more people to do more "real" work. But not everybody has the time or skills. I think this is a case where "agreeing to disagree" is the best we can do. There is also the matter of letting people start with something the

Re: [Python-Dev] PyObject_GC_UnTrack() no longer reliable in 2.7?

On Fri, 24 Sep 2010 15:14:32 -0400 Tim Peters wrote: > Looks like 2.7 changes introduced to exempt dicts and tuples from > cyclic gc if they obviously can't be in cycles has some unintended > consequences. Specifically, if an extension module calls > PyObject_GC_UnTrack() on a dict it _does not w

Re: [Python-Dev] Some changes to logging for 3.2

Chris Withers simplistix.co.uk> writes: > > Cool, how can I use it in Python 2.6? > > Chris Hi Chris, 1. Copy the top part (imports, QueueHandler and QueueListener classes) from the Gist linked to in the article - http://gist.github.com/591699 - into a utility module you can use again and ag

[Python-Dev] PyObject_GC_UnTrack() no longer reliable in 2.7?

Looks like 2.7 changes introduced to exempt dicts and tuples from cyclic gc if they obviously can't be in cycles has some unintended consequences. Specifically, if an extension module calls PyObject_GC_UnTrack() on a dict it _does not want tracked_, Python can start tracking the dict again. I ass

Re: [Python-Dev] Summary of Python tracker Issues

I think every week where more bugs are closed than opened should be celebrated! =) Thanks to everyone who closed something this week (and to those that filed good bug reports). On Fri, Sep 24, 2010 at 09:14, Python tracker wrote: > > ACTIVITY SUMMARY (2010-09-17 - 2010-09-24) > Python tracker at

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2010-09-17 - 2010-09-24) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues stats: open2533 (+42) closed 19189 (+57) total 21722 (+53) Open issues with patches: 1

Re: [Python-Dev] Goodbye

> > But how should a performance improvement be filed? Bug? Feature request? > > Or should "feature request" be renamed "improvement"? > > It's a feature request (since we won't backport it unless there is a > genuine performance problem being addressed as a bug fix). Whether > that warrants chan

Re: [Python-Dev] Goodbye

On Sat, Sep 25, 2010 at 12: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 thos

Re: [Python-Dev] os.path.normcase rationale?

On 24 September 2010 15:29, Guido van Rossum wrote: > I don't think we should try to reimplement what the filesystem does. I > think we should just ask the filesystem (how exactly I haven't figured > out yet but I expect it will be more OS-specific than > filesystem-specific). It will have to be a

Re: [Python-Dev] Goodbye

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 wel

Re: [Python-Dev] Goodbye

On Sat, Sep 25, 2010 at 12:31 AM, Antoine Pitrou wrote: > >> > But we also have "performance", "crash", "resource usage"... Are we >> > suggesting we devise a separate list box for each of these issue types? >> >> I must admit, I've never actually found much use for those additional >> options. If

Re: [Python-Dev] os.path.normcase rationale?

On Fri, 24 Sep 2010 07:29:40 -0700 Guido van Rossum wrote: > It will have to be a new API -- normcase() at > least is *intended* to return a case-flattened name on OSes where > case-preserving filesystems are the default, and changing it to look > at the filesystem would break too much code. For a

Re: [Python-Dev] Python wiki

There actually is an admin team, and they actually do set ACLs. >>> >>> Who are they? >> >> I don't actually know entirely; at a minimum, Skip Montanaro. On Fri, Sep 24, 2010 at 3:31 AM, Michael Foord wrote: > Wiki maintenance is discussed, along with other python.org maintenance > topics, o

Re: [Python-Dev] Goodbye

> > But we also have "performance", "crash", "resource usage"... Are we > > suggesting we devise a separate list box for each of these issue types? > > I must admit, I've never actually found much use for those additional > options. If I'm flagging a bug I'll nearly always mark it "behaviour", >

Re: [Python-Dev] os.path.normcase rationale?

On Fri, Sep 24, 2010 at 5:17 AM, R. David Murray wrote: > On Fri, 24 Sep 2010 11:13:46 +0100, Chris Withers > wrote: >> On 18/09/2010 23:36, Guido van Rossum wrote: >> > course, exists() and isdir() etc. do, and so does realpath(), but the >> > pure parsing functions don't. >> >> Yes, but: >> >>

Re: [Python-Dev] Goodbye

On Fri, Sep 24, 2010 at 10:26 PM, Antoine Pitrou wrote: > On Fri, 24 Sep 2010 11:07:59 +0200 > Éric Araujo wrote: >> How about revamping the type/versions fields? >> >> Issue type >> () Feature request (blocked by moratorium: () yes () no) >> () Bug (found in: [] 2.7 [] 3.1 [] py3k) >> () Securit

Re: [Python-Dev] Python wiki

On Fri, Sep 24, 2010 at 8:31 PM, Michael Foord 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 > > More wiki and website maintainers needed! We could probably adver

Re: [Python-Dev] r84983 - in python/branches/py3k: Doc/library/os.rst Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c

On Fri, Sep 24, 2010 at 06:49, Antoine Pitrou wrote: > On Fri, 24 Sep 2010 13:38:44 +0200 > "Amaury Forgeot d'Arc" wrote: > > 2010/9/24 Antoine Pitrou : > > > > > > The getlogin test fails on many Unix buildbots, either with errno 2 > > > (ENOENT) or 22 (EINVAL) or "OSError: unable to determine

Re: [Python-Dev] Goodbye

On Fri, 24 Sep 2010 11:07:59 +0200 Éric Araujo wrote: > How about revamping the type/versions fields? > > Issue type > () Feature request (blocked by moratorium: () yes () no) > () Bug (found in: [] 2.7 [] 3.1 [] py3k) > () Security bug (found in: [] 2.5 [] 2.6 [] 2.7 [] 3.1 [] py3k) > > I’m get

Re: [Python-Dev] os.path.normcase rationale?

On Fri, 24 Sep 2010 11:13:46 +0100, Chris Withers wrote: > On 18/09/2010 23:36, Guido van Rossum wrote: > > course, exists() and isdir() etc. do, and so does realpath(), but the > > pure parsing functions don't. > > Yes, but: > > H:\>echo foo > TeSt.txt > ...>>> import os.path > >>> os.path.re

Re: [Python-Dev] os.path.normcase rationale?

On 9/24/2010 6:13 AM, Chris Withers wrote: On 18/09/2010 23:36, Guido van Rossum wrote: course, exists() and isdir() etc. do, and so does realpath(), but the pure parsing functions don't. Yes, but: H:\>echo foo > TeSt.txt ...>>> import os.path >>> os.path.realpath('test.txt') 'H:\\test.txt'

Re: [Python-Dev] r84983 - in python/branches/py3k: Doc/library/os.rst Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c

On Fri, 24 Sep 2010 13:38:44 +0200 "Amaury Forgeot d'Arc" wrote: > 2010/9/24 Antoine Pitrou : > > > > The getlogin test fails on many Unix buildbots, either with errno 2 > > (ENOENT) or 22 (EINVAL) or "OSError: unable to determine login name": > > Do these buildbots run in a Windows service, i.e.

Re: [Python-Dev] r84983 - in python/branches/py3k: Doc/library/os.rst Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c

2010/9/24 Antoine Pitrou : > > The getlogin test fails on many Unix buildbots, either with errno 2 > (ENOENT) or 22 (EINVAL) or "OSError: unable to determine login name": Do these buildbots run in a Windows service, i.e. with no user logged in? -- Amaury Forgeot d'Arc ___

Re: [Python-Dev] r84983 - in python/branches/py3k: Doc/library/os.rst Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c

The getlogin test fails on many Unix buildbots, either with errno 2 (ENOENT) or 22 (EINVAL) or "OSError: unable to determine login name": == ERROR: test_getlogin (test.test_os.LoginTests) -

[Python-Dev] Version fields [was Re: Goodbye]

In article <4c9c6a6f.6010...@netwok.org>, Éric Araujo wrote: > How about revamping the type/versions fields? > > Issue type > () Feature request (blocked by moratorium: () yes () no) > () Bug (found in: [] 2.7 [] 3.1 [] py3k) > () Security bug (found in: [] 2.5 [] 2.6 [] 2.7 [] 3.1 [] py3k) > >

Re: [Python-Dev] Python wiki

On 24/09/2010 06:46, "Martin v. Löwis" wrote: Am 24.09.2010 00:39, schrieb Guido van Rossum: On Thu, Sep 23, 2010 at 3:35 PM, "Martin v. Löwis" wrote: 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

Re: [Python-Dev] Some changes to logging for 3.2

On 22/09/2010 16:54, Vinay Sajip wrote: I'm planning to make some smallish changes to logging in Python 3.2, please see http://plumberjack.blogspot.com/2010/09/improved-queuehandler-queuelistener.html If you're interested, I'd be grateful for any feedback you can give. Cool, how can I use it

Re: [Python-Dev] os.path.normcase rationale?

On 18/09/2010 23:36, Guido van Rossum wrote: course, exists() and isdir() etc. do, and so does realpath(), but the pure parsing functions don't. Yes, but: H:\>echo foo > TeSt.txt ...>>> import os.path >>> os.path.realpath('test.txt') 'H:\\test.txt' >>> os.path.normcase('TeSt.txt') 'test.txt'

[Python-Dev] url shortening services (was Re: standards for distribution names)

On 17/09/2010 12:54, Dan Buch wrote: You may also find this thread from the packaging google group useful, although it may not be quite what you're looking for: http://bit.ly/96SMuM To echo a please from the main python list, please can we all stop using url shortening services? This i

Re: [Python-Dev] Goodbye

How about revamping the type/versions fields? Issue type () Feature request (blocked by moratorium: () yes () no) () Bug (found in: [] 2.7 [] 3.1 [] py3k) () Security bug (found in: [] 2.5 [] 2.6 [] 2.7 [] 3.1 [] py3k) I’m getting tired of explaining the meaning of the versions field again and ag

[Python-Dev] wiki/docs enhancement idea

I didn't know who to reply to in the previous thread. (Moving the Developer docs/ Python wiki). scraperwiki.org is a 'site scraper automater'. I threw together a script just now which scrapes certain specified pages from the python wiki and converts to something rest-like. It runs every 24hrs

Re: [Python-Dev] Python wiki

Am 23.09.2010 22:25, schrieb anatoly techtonik: > On Thu, Sep 23, 2010 at 6:57 PM, Barry Warsaw 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

Re: [Python-Dev] Goodbye

Am 23.09.2010 22:51, schrieb Éric Araujo: > Le 23/09/2010 19:22, Terry Reedy a écrit : >> As of just now, if you were to wonder "What (security) bugs are open for >> 2.5" and search on open 2.5 issues, you would get a list of 44 issues. >> It is only 44 instead of hundreds because of the work I a