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 and Mark
Am 23.09.2010 22:25, schrieb anatoly techtonik:
On Thu, Sep 23, 2010 at 6:57 PM, Barry Warsaw ba...@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
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
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
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
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'
Both feel
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
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öwismar...@v.loewis.de 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
In article 4c9c6a6f.6010...@netwok.org,
Éric Araujo mer...@netwok.org 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 []
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)
2010/9/24 Antoine Pitrou solip...@pitrou.net:
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
On Fri, 24 Sep 2010 13:38:44 +0200
Amaury Forgeot d'Arc amaur...@gmail.com wrote:
2010/9/24 Antoine Pitrou solip...@pitrou.net:
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
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'
On Fri, 24 Sep 2010 11:13:46 +0100, Chris Withers ch...@simplistix.co.uk
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
On Fri, 24 Sep 2010 11:07:59 +0200
Éric Araujo mer...@netwok.org 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)
On Fri, Sep 24, 2010 at 8:31 PM, Michael Foord
fuzzy...@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
More wiki and website maintainers needed!
We
On Fri, Sep 24, 2010 at 10:26 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 24 Sep 2010 11:07:59 +0200
Éric Araujo mer...@netwok.org wrote:
How about revamping the type/versions fields?
Issue type
() Feature request (blocked by moratorium: () yes () no)
() Bug (found in: [] 2.7 []
On Fri, Sep 24, 2010 at 5:17 AM, R. David Murray rdmur...@bitdance.com wrote:
On Fri, 24 Sep 2010 11:13:46 +0100, Chris Withers ch...@simplistix.co.uk
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
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,
otherwise I'll
On Sat, Sep 25, 2010 at 12:31 AM, Antoine Pitrou solip...@pitrou.net 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.
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
On 24 September 2010 15:29, Guido van Rossum gu...@python.org 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
On Sat, Sep 25, 2010 at 12:50 AM, Antoine Pitrou solip...@pitrou.net 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
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 changing the
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:
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 sta...@bugs.python.org wrote:
ACTIVITY SUMMARY (2010-09-17 - 2010-09-24)
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
Chris Withers chris at 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
On Fri, 24 Sep 2010 15:14:32 -0400
Tim Peters tim.pet...@gmail.com 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
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 they
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! =) Thanks
On Fri, Sep 24, 2010 at 12:57, Georg Brandl g.bra...@gmx.net 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
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
On Fri, Sep 24, 2010 at 3:36 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 24 Sep 2010 15:14:32 -0400
Tim Peters tim.pet...@gmail.com 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
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
On Fri, Sep 24, 2010 at 4:09 PM, Martin v. Löwis mar...@v.loewis.dewrote:
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
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.
Am 24.09.2010 23:22, schrieb Daniel Stutzbach:
On Fri, Sep 24, 2010 at 4:09 PM, Martin v. Löwis mar...@v.loewis.de
mailto:mar...@v.loewis.de wrote:
I think it would be possible to have two versions of
_PyGC_REFS_UNTRACKED, one being, say, -5.
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 match
Greg Ewing greg.ew...@canterbury.ac.nz 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
[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)?
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
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, Sep 24,
On Sep 24, 2010, at 10:53 AM, Paul Moore wrote:
On 24 September 2010 15:29, Guido van Rossum gu...@python.org 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
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
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
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().
--
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
48 matches
Mail list logo
