date:20100924

Re: [Python-Dev] Goodbye

2010-09-24 Thread Georg Brandl

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 have 
>> done in the last 4 months. It it 44 instead of perhaps 5 because Tarek 
>> and Eric insist on marking all disutils2 issues for all versions even 
>> though though these issues have nothing to do with maintenance releases. 
>> It is a real nuisance when trying to do tracker cleanup.
> 
> Let’s fix this.  Two days ago, I said this in
> http://bugs.python.org/issue2200#msg117003 :
> 
>  distutils2 has to work with 2.4-2.7 and (soon) 3.1-3.2, so Tarek told
>  me to set all available versions for those bugs (2.5-py3k), even if I
>  think “3rd party” is more appropriate and useful (since a distutils2
>  bug would not for example block a CPython 3.2 release).
> 
> I’ve been following these rules since before GSoC, when I had less
> confidence and no will to conflict with Tarek on such a small thing
> .  Now I argue that the versions field is not really useful for
> d2, since it lacks 2.4 which we support and chiefly because it does not
> actually help our workflow: We don’t have separate branches for
> backporting fixes, we apply patches and run tests for all supported
> versions before committing on a single branch.  There is no use case of
> setting a version to remind that a port needs to be done.  For bug
> purposes, I actually see distutils2 as a value for the versions field of
> distutils bugs.

Thanks Eric, that sounds good.

> respect-my-non-ASCII-diversity-write-my-acute-accent-thanks’ly yours,

Oops. My bad.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python wiki

2010-09-24 Thread Georg Brandl

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

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

> Fourth. GPL license. I personally don't have interest to waste my time
> for the code I won't be able to use in some projects, unless the
> project is either exceptional (Mercurial) or interesting. To make
> python.org MoinMoin interesting - there should be an inviting
> entrypoint (see point three above) and the list of tasks to choose
> form. Something that is better than
> http://wiki.python.org/moin/SiteImprovements

Yes, that needs to be updated indeed.

> Fifth. Credits and motivation for all python.org works. I still
> convinced that there should be one primary dedicated list and it
> should be public. All sensitive issues can be discussed with
> webmasters@ privately, but the primary list should be run by
> community. Not the volunteers who are better than others. If there
> will be a feeling that site is run by community, then you can expect
> contributions. Otherwise expect the community to think "they're doing
> the stuff here, so they will fix it".

I'm puzzled what you expect in addition to the pydotorg-www list.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] wiki/docs enhancement idea

2010-09-24 Thread Gerard Flanagan

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 and the idea would 
be that the result could be included alongside the official docs. This 
may increase people's motivation to contribute to the wiki.


Script here: http://scraperwiki.com/scrapers/pywiki2rest/edit/

Example api call:

http://api.scraperwiki.com/api/1.0/datastore/getdata?format=json&name=pywiki2rest


Regards

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Goodbye

2010-09-24 Thread Éric Araujo

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 again, let’s put this information directly under the eyes of the bug
reporter.

Regards
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Chris Withers


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 isn't twitter, we have no character limits, and as a result the 
cons by far outweigh any pros...


Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Chris Withers

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 unsatisfying to me :-S

How can I get 'TeSt.txt' from 'test.txt' (which feels like the contract 
normcase *should* have...)

They can be used without a working
filesystem even. (E.g. you can import ntpath on a Unix box and happily
parse Windows paths.)

But what value does that add over just doing a .lower() on the path?

Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Chris Withers


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 in Python 2.6? :-)

Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python wiki

2010-09-24 Thread Michael Foord


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

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.



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!

All the best,

Michael Foord


IIUC, this is primarily for spam protection, though.

So would they object against additions to the team?

I don't think they would.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Ned Deily

In article <[email protected]>,
 É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 getting tired of explaining the meaning of the versions field again
> and again, let’s put this information directly under the eyes of the bug
> reporter.

I believe there is another separate use case for the versions field that 
hasn't been mentioned yet:  for issues with "release blocker" priority, 
the versions field is often used to identify the upcoming release for 
which a resolution is deemed mandatory.  However, having a single 
versions field is not totally satisfactory for this, particularly when - 
as has happened in the recent past - two different release cycles 
overlap (say, Python 2.7.x and 3.2.y).  A given issue may or may not 
apply to both, it may be a "release blocker" for one or both, and, if 
both, a fix may be checked-in for one branch but not the other.  The 
release managers for the two releases may end up using the one priority 
field and the one set of version fields for conflicting purposes.  It 
certainly makes it more difficult to automate a tracking report of 
exactly what are the release blocker issues for a specific release.

Besides adding fields to the database for an issue, there are other ways 
to handle the ambiguity, of course.  The simplest might be to just open 
a separate duplicate issue for each additional release blocked.  
Presumably that level of detail might only be needed in the endgame of a 
release, beta or rc stages.  It still places a restriction on the use of 
the version field and possibly other fields.  In issue workflow 
documentation, there should be some description of how "release blocker" 
should work, perhaps including something along the lines of "once a 
release enters stage , 'release blocker' priority should only be 
changed with the approval of the release manager".

-- 
 Ned Deily,
 [email protected]

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread 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":

==
ERROR: test_getlogin (test.test_os.LoginTests)
--
Traceback (most recent call last):
  File 
"/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/test_os.py", line 
1208, in test_getlogin
user_name = os.getlogin()
OSError: [Errno 2] No such file or directory

==
ERROR: test_getlogin (test.test_os.LoginTests)
--
Traceback (most recent call last):
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/test/test_os.py", 
line 1208, in test_getlogin
user_name = os.getlogin()
OSError: [Errno 22] Invalid argument

==
ERROR: test_getlogin (test.test_os.LoginTests)
--
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_os.py", line 
1208, in test_getlogin
user_name = os.getlogin()
OSError: unable to determine login name




On Thu, 23 Sep 2010 22:04:14 +0200 (CEST)
brian.curtin  wrote:
> Author: brian.curtin
> Date: Thu Sep 23 22:04:14 2010
> New Revision: 84983
> 
> Log:
> #9808. Implement os.getlogin for Windows, completed by Jon Anglin.
> 
> The test is semi-dumb, it just makes sure something comes back since we
> don't have a solid source to validate the returned login. We can't be 100%
> sure that the USERNAME env var will always match what os.getlogin() returns,
> so we don't make any specific assertion there.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Amaury Forgeot d'Arc

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
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Antoine Pitrou

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. with no user logged in?

I don't think any of our Unix buildbots runs in our Windows service :)

The diversity of errors we get is a bit disturbing: in the Linux man
pages, ENOENT is mentioned as a glibc extension (“There was no
corresponding entry in the utmp-file”)  but EINVAL is not mentioned at
all; also, returning NULL without setting errno is not a possibility in
the POSIX spec.

Regards

Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Ned Batchelder


 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'
>>> os.path.normcase('TeSt.txt')
'test.txt'

Both feel unsatisfying to me :-S

How can I get 'TeSt.txt' from 'test.txt' (which feels like the 
contract normcase *should* have...)



http://stackoverflow.com/questions/3692261/in-python-how-can-i-get-the-correctly-cased-path-for-a-file

They can be used without a working
filesystem even. (E.g. you can import ntpath on a Unix box and happily
parse Windows paths.)


But what value does that add over just doing a .lower() on the path?

Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/ned%40nedbatchelder.com



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread R. David Murray

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.realpath('test.txt')
> 'H:\\test.txt'
>  >>> os.path.normcase('TeSt.txt')
> 'test.txt'
> 
> Both feel unsatisfying to me :-S
> 
> How can I get 'TeSt.txt' from 'test.txt' (which feels like the contract 
> normcase *should* have...)

You can't, and you shouldn't be able to.  "normalization" is something
that happens without reference to existing objects, the whole point
is to put the thing into "standard form" so that you can compare
strings obtained from different sources and know that they will
represent the same object on that filesystem.

> > They can be used without a working
> > filesystem even. (E.g. you can import ntpath on a Unix box and happily
> > parse Windows paths.)
> 
> But what value does that add over just doing a .lower() on the path?

It does what is appropriate for thatoh, yeah.  For that OS, not
"for that filesystem".  (e.g. on Unix normcase does nothing since files
with different cases but the same letters are different files.) 

Being os specific rather than file system type specific is the usability bug.
But to fix it we'll need to introduce a 'filesystems' module enumerating
the different file systems we support, with tools for figuring out
what filesystem your program is talking to.  But normacase still,
wouldn't (shouldn't) do what you want.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Goodbye

2010-09-24 Thread Antoine Pitrou

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 getting tired of explaining the meaning of the versions field again
> and again, let’s put this information directly under the eyes of the bug
> reporter.

But we also have "performance", "crash", "resource usage"... Are we
suggesting we devise a separate list box for each of these issue types?

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Brian Curtin

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 login name":
> >
> > Do these buildbots run in a Windows service, i.e. with no user logged in?
>
> I don't think any of our Unix buildbots runs in our Windows service :)
>
> The diversity of errors we get is a bit disturbing: in the Linux man
> pages, ENOENT is mentioned as a glibc extension (“There was no
> corresponding entry in the utmp-file”)  but EINVAL is not mentioned at
> all; also, returning NULL without setting errno is not a possibility in
> the POSIX spec.
>
> Regards
>
> Antoine.

Now, it makes sense why there was no os.getlogin() test in the past. I'll
disable the test for the time being.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python wiki

2010-09-24 Thread Nick Coghlan

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 advertise helping with pydotorg itself a bit more in
the "How can I help?" sections of the docs and website.

I did just notice there is actually a "Help Maintain Website" on the
left of the main page which is a good start, but (for example) the
general Python FAQ in the docs points people to
http://python.org/dev/, which in turn has a "Suggested Tasks" link to
http://python.org/dev/contributing/. That page could probably do with
a section in the main text that links to the website maintenance info
page.

That page itself could also mention assisting in wiki maintenance as a
way to demonstrate interest (similar to the way patches and triage
assistance show interest in contributing to the official docs and
source code).

For the wiki itself, I would suggest a "Help Maintain the Wiki" link
in the left navbar of each (with appropriately updated text, that
could just link to the general website maintenance page).

So, given that we don't actually *ask* anywhere for people to
contribute to the wiki, I guess it isn't that surprising that it is
underutilised.

Something else the wiki can be *very* useful for is to provide
information that is potentially useful to Python users, but that we
don't want to be seen as unduly "blessed" by either python-dev or the
PSF. Lists of libraries supporting particular tasks can fit into that
category, since an entry on an open access wiki page is (justifiably)
going to be given far less weight than a reference from the official
documentation.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Goodbye

2010-09-24 Thread Nick Coghlan

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)
>> () 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 again, let’s put this information directly under the eyes of the bug
>> reporter.
>
> 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 mark the issue "feature request". The characterisation
of "what *kind* of bug is it?" is something that can usually be left
until later in the process.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Guido van Rossum

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:
>>
>> 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 unsatisfying to me :-S
>>
>> How can I get 'TeSt.txt' from 'test.txt' (which feels like the contract
>> normcase *should* have...)
>
> You can't, and you shouldn't be able to.  "normalization" is something
> that happens without reference to existing objects, the whole point
> is to put the thing into "standard form" so that you can compare
> strings obtained from different sources and know that they will
> represent the same object on that filesystem.

Clearly there is another use case where people want to display the
filename back to the user with the correct case. This is a reasonable
request and I think it makes sense for us to add another API to
os.path that does this by looking up the path on the filesystem, or
making an OS-specific call.

>> > They can be used without a working
>> > filesystem even. (E.g. you can import ntpath on a Unix box and happily
>> > parse Windows paths.)
>>
>> But what value does that add over just doing a .lower() on the path?
>
> It does what is appropriate for thatoh, yeah.  For that OS, not
> "for that filesystem".  (e.g. on Unix normcase does nothing since files
> with different cases but the same letters are different files.)

Yeah, which is wrong on Mac OS X -- that's Unix but the default
filesystem is case-preserving (though apparently it's possible to
mount case-sensitive filesystems too). I've heard that on Windows
there are also case-sensitive filesystems (part of a POSIX compliance
package?). And on Linux you can mount FAT32 filesystems which are
case-preserving.

> Being os specific rather than file system type specific is the usability bug.

Agreed.

> But to fix it we'll need to introduce a 'filesystems' module enumerating
> the different file systems we support, with tools for figuring out
> what filesystem your program is talking to.  But normacase still,
> wouldn't (shouldn't) do what you want.

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 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 new use case we
need a new API.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Goodbye

2010-09-24 Thread Antoine Pitrou


> > 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 mark the issue "feature request". The characterisation
> of "what *kind* of bug is it?" is something that can usually be left
> until later in the process.

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.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python wiki

2010-09-24 Thread Guido van Rossum

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

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

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Antoine Pitrou

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 new use case we
> need a new API.

realpath() sounds like the proper API for that. It just needs to have a
better implementation :)

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Goodbye

2010-09-24 Thread Nick Coghlan

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 I'm flagging a bug I'll nearly always mark it "behaviour",
>> otherwise I'll mark the issue "feature request". The characterisation
>> of "what *kind* of bug is it?" is something that can usually be left
>> until later in the process.
>
> 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).

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. When someone like me
is looking at a field pondering what to set it to for a comparatively
simple issue report, what hope does someone submitted their first
issue have?

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Goodbye

2010-09-24 Thread Antoine Pitrou

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).
> 
> 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"?

cheers

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Paul Moore

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 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 new use case we
> need a new API.

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". From my researches, the standard interfaces a filesystem
has to implement on Linux don't offer any means of asking this
question.

Of course, (a) I'm no Linux expert so what do I know, and (b) it may
well be possible to come up with a "good enough" solution by ignoring
pathologically annoying theoretical cases.

I'm happy to provide Windows code if someone needs it.
Paul

PS There were some places I'd have been glad of this feature (and from
what I recall, Mercurial could have used it too) so I'm +1 on the
idea.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Goodbye

2010-09-24 Thread Nick Coghlan

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 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).
>>
>> 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"?

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 name, I don't know. A third option for
"other improvement" may also work (since that would also cover things
like clarifying doc wording, fixing comments, adjusting code to be
more readable/obviously correct, etc).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Goodbye

2010-09-24 Thread Antoine Pitrou


> > 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 name, I don't know.

I think most people won't intuitively file performance issues as
"feature requests", since it doesn't sound like a feature.

>  A third option for
> "other improvement" may also work (since that would also cover things
> like clarifying doc wording, fixing comments, adjusting code to be
> more readable/obviously correct, etc).

But then why not keep a clear categorization of these "other
improvements"?

By the way, doc wording fixes and cosmetic code changes often get
backported. :)

cheers

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

2010-09-24 Thread Python tracker


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: 1061 


Issues opened (42)
==

#1763: Winpath module - easy access to Windows directories like My Do
http://bugs.python.org/issue1763  reopened by r.david.murray

#6627: threading.local() does not work with C-created threads
http://bugs.python.org/issue6627  reopened by Nikratio

#9441: increase logging handlers test coverage
http://bugs.python.org/issue9441  reopened by r.david.murray

#9552: ssl build under Windows always rebuilds OpenSSL
http://bugs.python.org/issue9552  reopened by ocean-city

#9877: Expose sysconfig._get_makefile_filename() in public API
http://bugs.python.org/issue9877  reopened by eric.araujo

#9889: PyUnicode_FormatV and Py_UNICODE*?
http://bugs.python.org/issue9889  opened by mkleehammer

#9890: Visual C++ Runtime Library Error is there a fix?
http://bugs.python.org/issue9890  opened by Hydro56

#9891: Minor doc typo at datamodel.rst: "list" -> "alist"
http://bugs.python.org/issue9891  opened by rbp

#9893: Usefulness of the Misc/Vim/ files?
http://bugs.python.org/issue9893  opened by pitrou

#9896: Introspectable range objects
http://bugs.python.org/issue9896  opened by durban

#9897: multiprocessing problems
http://bugs.python.org/issue9897  opened by hume

#9903: test_concurrent_futures writes on stderr
http://bugs.python.org/issue9903  opened by pitrou

#9904: Cosmetic issues that may warrant a fix in symtable.h/c
http://bugs.python.org/issue9904  opened by eli.bendersky

#9905: subprocess.Popen fails with stdout=PIPE, stderr=PIPE if standa
http://bugs.python.org/issue9905  opened by Thomas.Claveirole

#9907: interactive mode TAB does not insert on OS X built with editli
http://bugs.python.org/issue9907  opened by ned.deily

#9909: request for calendar.dayofyear() function
http://bugs.python.org/issue9909  opened by jfinkels

#9910: Add Py_SetPath API for embeddint python
http://bugs.python.org/issue9910  opened by krisvale

#9912: Fail when vsvarsall.bat produces stderr
http://bugs.python.org/issue9912  opened by flub

#9913: Misc/SpecialBuilds.txt  is out of date
http://bugs.python.org/issue9913  opened by belopolsky

#9914: trace/profile conflict with the use of sys.modules[__name__]
http://bugs.python.org/issue9914  opened by belopolsky

#9915: speeding up sorting with a key
http://bugs.python.org/issue9915  opened by stutzbach

#9917: resource max value represented as signed when should be unsign
http://bugs.python.org/issue9917  opened by r.david.murray

#9919: gdbinit lineno result is one line in excess
http://bugs.python.org/issue9919  opened by qpatata

#9920: test_cmath on atan fails on AIX
http://bugs.python.org/issue9920  opened by sable

#9921: os.path.join('x','') behavior
http://bugs.python.org/issue9921  opened by rgrig

#9922: subprocess.getstatusoutput can fail with utf8 UnicodeDecodeErr
http://bugs.python.org/issue9922  opened by debatem1

#9923: mailcap module may not work on non-POSIX platforms if MAILCAPS
http://bugs.python.org/issue9923  opened by gnofi

#9924: sqlite3 SELECT does not BEGIN a transaction, but should accord
http://bugs.python.org/issue9924  opened by zzzeek

#9925: Idle doesn't launch
http://bugs.python.org/issue9925  opened by Stephan.Bellegy

#9926: Wrapped TestSuite subclass does not get __call__ executed
http://bugs.python.org/issue9926  opened by loewis

#9927: Leak around GetFinalPathNameByHandle (Windows)
http://bugs.python.org/issue9927  opened by ocean-city

#9929: subprocess.Popen unbuffered not work
http://bugs.python.org/issue9929  opened by ocean-city

#9931: test_ttk_guionly hangs on XP5
http://bugs.python.org/issue9931  opened by ocean-city

#9934: Python Docs Typo
http://bugs.python.org/issue9934  opened by Retro

#9935: Faster pickling of instances
http://bugs.python.org/issue9935  opened by pitrou

#9936: trace misreports "missing" lines
http://bugs.python.org/issue9936  opened by belopolsky

#9937: _winreg.EnumValue causes MemoryError
http://bugs.python.org/issue9937  opened by kzmi

#9938: Documentation for argparse interactive use
http://bugs.python.org/issue9938  opened by jayt

#9939: Add a pipe type (FIFO) to the io module
http://bugs.python.org/issue9939  opened by pitrou

#9940: Strange error reporting with "with" statement
http://bugs.python.org/issue9940  opened by pitrou

#1724822: provide a shlex.split alternative for Windows shell syntax
http://bugs.python.org/issue1724822  reopened by r.david.murray

#678250: test_mmap failling on AIX
http://bugs.python.org/issue678250  reopened by r.david.murray



Most recent 15 issues with no replies (15)
==

#9940: Strange error reporting with "with" statement
http://bugs.python.org/issue9940

#9938: Documentation for argp

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

2010-09-24 Thread Brett Cannon

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 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:
>  open    2533 (+42)
>  closed 19189 (+57)
>  total  21722 (+53)
>
> Open issues with patches: 1061
>
>
> Issues opened (42)
> ==
>
> #1763: Winpath module - easy access to Windows directories like My Do
> http://bugs.python.org/issue1763  reopened by r.david.murray
>
> #6627: threading.local() does not work with C-created threads
> http://bugs.python.org/issue6627  reopened by Nikratio
>
> #9441: increase logging handlers test coverage
> http://bugs.python.org/issue9441  reopened by r.david.murray
>
> #9552: ssl build under Windows always rebuilds OpenSSL
> http://bugs.python.org/issue9552  reopened by ocean-city
>
> #9877: Expose sysconfig._get_makefile_filename() in public API
> http://bugs.python.org/issue9877  reopened by eric.araujo
>
> #9889: PyUnicode_FormatV and Py_UNICODE*?
> http://bugs.python.org/issue9889  opened by mkleehammer
>
> #9890: Visual C++ Runtime Library Error is there a fix?
> http://bugs.python.org/issue9890  opened by Hydro56
>
> #9891: Minor doc typo at datamodel.rst: "list" -> "alist"
> http://bugs.python.org/issue9891  opened by rbp
>
> #9893: Usefulness of the Misc/Vim/ files?
> http://bugs.python.org/issue9893  opened by pitrou
>
> #9896: Introspectable range objects
> http://bugs.python.org/issue9896  opened by durban
>
> #9897: multiprocessing problems
> http://bugs.python.org/issue9897  opened by hume
>
> #9903: test_concurrent_futures writes on stderr
> http://bugs.python.org/issue9903  opened by pitrou
>
> #9904: Cosmetic issues that may warrant a fix in symtable.h/c
> http://bugs.python.org/issue9904  opened by eli.bendersky
>
> #9905: subprocess.Popen fails with stdout=PIPE, stderr=PIPE if standa
> http://bugs.python.org/issue9905  opened by Thomas.Claveirole
>
> #9907: interactive mode TAB does not insert on OS X built with editli
> http://bugs.python.org/issue9907  opened by ned.deily
>
> #9909: request for calendar.dayofyear() function
> http://bugs.python.org/issue9909  opened by jfinkels
>
> #9910: Add Py_SetPath API for embeddint python
> http://bugs.python.org/issue9910  opened by krisvale
>
> #9912: Fail when vsvarsall.bat produces stderr
> http://bugs.python.org/issue9912  opened by flub
>
> #9913: Misc/SpecialBuilds.txt  is out of date
> http://bugs.python.org/issue9913  opened by belopolsky
>
> #9914: trace/profile conflict with the use of sys.modules[__name__]
> http://bugs.python.org/issue9914  opened by belopolsky
>
> #9915: speeding up sorting with a key
> http://bugs.python.org/issue9915  opened by stutzbach
>
> #9917: resource max value represented as signed when should be unsign
> http://bugs.python.org/issue9917  opened by r.david.murray
>
> #9919: gdbinit lineno result is one line in excess
> http://bugs.python.org/issue9919  opened by qpatata
>
> #9920: test_cmath on atan fails on AIX
> http://bugs.python.org/issue9920  opened by sable
>
> #9921: os.path.join('x','') behavior
> http://bugs.python.org/issue9921  opened by rgrig
>
> #9922: subprocess.getstatusoutput can fail with utf8 UnicodeDecodeErr
> http://bugs.python.org/issue9922  opened by debatem1
>
> #9923: mailcap module may not work on non-POSIX platforms if MAILCAPS
> http://bugs.python.org/issue9923  opened by gnofi
>
> #9924: sqlite3 SELECT does not BEGIN a transaction, but should accord
> http://bugs.python.org/issue9924  opened by zzzeek
>
> #9925: Idle doesn't launch
> http://bugs.python.org/issue9925  opened by Stephan.Bellegy
>
> #9926: Wrapped TestSuite subclass does not get __call__ executed
> http://bugs.python.org/issue9926  opened by loewis
>
> #9927: Leak around GetFinalPathNameByHandle (Windows)
> http://bugs.python.org/issue9927  opened by ocean-city
>
> #9929: subprocess.Popen unbuffered not work
> http://bugs.python.org/issue9929  opened by ocean-city
>
> #9931: test_ttk_guionly hangs on XP5
> http://bugs.python.org/issue9931  opened by ocean-city
>
> #9934: Python Docs Typo
> http://bugs.python.org/issue9934  opened by Retro
>
> #9935: Faster pickling of instances
> http://bugs.python.org/issue9935  opened by pitrou
>
> #9936: trace misreports "missing" lines
> http://bugs.python.org/issue9936  opened by belopolsky
>
> #9937: _winreg.EnumValue causes MemoryError
> http://bugs.python.org/issue9937  opened by kzmi
>
> #9938: Documentation for argparse interactive use
> http://bugs.python.org/issue9938  opened by jayt
>
> #9939: Add a pipe type (FIFO) to the io module
> http://bugs.python.org/issue9939  opened by pitrou
>
> #9940: Strange error reporting with "with" statement
> http://bugs.python.org/issue9940

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

2010-09-24 Thread Tim Peters

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 assume this is unintended because (a) the docs weren't changed to
warn about this; and, (b) it's wrong ;-)

There are two main reasons an extension module may have been calling
PyObject_GC_UnTrack():

1. For correctness, if the extension is playing games with reference
counts Python isn't expecting.

2. For speed, if the extension is creating dicts (or tuples) it knows
cannot participate in cycles.

This came up when Jim Fulton asked me for advice about assertion
failures coming out of cyclic gc in a debug build when running ZODB's
tests under 2.7.  Turned out to be due to the "#1 reason" above:  ZODB
hand-rolled its own version of weak references long before Python had
them, and has a dict mapping strings ("object IDs") to complex objects
where the referenced objects' refcounts intentionally do _not_ account
for the references due to this dict.

This had been working fine for at least 8 years, thanks to calling
PyObject_GC_UnTrack() on this dict right after it's created.

But under 2.7, new code in Python apparently decides to track this
dict again the first time its __setitem__ is called.  Cyclic gc then
discovers object references due to this dict that aren't accounted for
in the referenced objects' refcounts, and dies early on with an
assertion failure (which it should do - the refcounts are nuts as far
as Python is concerned).

Jim wormed around that for now by calling PyObject_GC_UnTrack() again
every time the dict's content changes, but that was relatively easy in
this case because the dict is an internal implementation detail all
accesses to which are under ZODB's control.

Best if no changes had been needed.  "Better than nothing" if the docs
are changed to warn that the effect of calling PyObject_GC_UnTrack()
may be undone by Python a nanosecond later ;-)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Vinay Sajip

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

2. In your code, try to import them from logging.handlers and in an except
ImportError: clause, import them from your utility module.

3. Profit ;-)

Note that there's a slight change in the Gist from when the post was published -
but it should still work as per the post. Until 3.2 is out, there may be other
small changes: but you can copy the code over from the 3.2 branch in the Python
SVN repository later and it should work fine under Python 2.6 and 2.7.

Of course if you do find any problems (or have any other questions), please let
me know asap :-)

Regards,

Vinay Sajip

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Antoine Pitrou

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 want tracked_, Python can
> start tracking the dict again.
> 
> I assume this is unintended because (a) the docs weren't changed to
> warn about this; and, (b) it's wrong ;-)

It was indeed unintended. I didn't know people were using
PyObject_GC_(Un)Track in other places than constructors and destructors.

> There are two main reasons an extension module may have been calling
> PyObject_GC_UnTrack():
> 
> 1. For correctness, if the extension is playing games with reference
> counts Python isn't expecting.

Yikes :)

> 2. For speed, if the extension is creating dicts (or tuples) it knows
> cannot participate in cycles.

The optimization is now automated in the simple cases (as you've found
out!).

> This came up when Jim Fulton asked me for advice about assertion
> failures coming out of cyclic gc in a debug build when running ZODB's
> tests under 2.7.  Turned out to be due to the "#1 reason" above:  ZODB
> hand-rolled its own version of weak references long before Python had
> them, and has a dict mapping strings ("object IDs") to complex objects
> where the referenced objects' refcounts intentionally do _not_ account
> for the references due to this dict.

Perhaps ZODB should switch to standard weak references these days?
(as a bonus, chances are it will be faster)

> Best if no changes had been needed.  "Better than nothing" if the docs
> are changed to warn that the effect of calling PyObject_GC_UnTrack()
> may be undone by Python a nanosecond later ;-)

A doc addition will be enough, hopefully.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Goodbye

2010-09-24 Thread Terry Reedy


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 
feel condident with and grow into more complicated tasks.



Specifically, Terry has made a strong case that "a few minutes per
issue" *can* improve the tracker in ways that *are* noticable to some
of the developers (and some of them have acknowledged that).  It would
be nice if the "tracker trimmers"[1] could assemble 60 of those into a
few hours, and do some "real work", but that's often just not possible
(especially for people with minimal programming expertise as yet).


Footnotes:
[1]  Trawlers take fish out of the ocean: not really the best
metaphor.  Gardening is a better metaphor.


For instance, while 'gardening', I discovered 4! duplicate open issues 
about the bug created by the difflib.SequenceMatcher heuristic. I 
consolidated them into one, got intrigued, did some tests with 3.1, read 
difflib.py, ..., and now have a patch posted written with Eli Bendersky.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Georg Brandl

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 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 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: 1061

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Brett Cannon

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
deltas can apply to pre-existing bugs, e.g., a bug that was re-opened.

-Brett

>
> 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 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 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:
>>>  open    2533 (+42)
>>>  closed 19189 (+57)
>>>  total  21722 (+53)
>>>
>>> Open issues with patches: 1061
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Georg Brandl

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

Georg

Am 24.09.2010 22:00, schrieb Brett Cannon:
> 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
> deltas can apply to pre-existing bugs, e.g., a bug that was re-opened.
> 
> -Brett
> 
>>
>> 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 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 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: 1061
>>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: 
>> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Jim Fulton

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 extension module calls
>> PyObject_GC_UnTrack() on a dict it _does not want tracked_, Python can
>> start tracking the dict again.
>>
>> I assume this is unintended because (a) the docs weren't changed to
>> warn about this; and, (b) it's wrong ;-)
>
> It was indeed unintended. I didn't know people were using
> PyObject_GC_(Un)Track in other places than constructors and destructors.
>
>> There are two main reasons an extension module may have been calling
>> PyObject_GC_UnTrack():
>>
>> 1. For correctness, if the extension is playing games with reference
>> counts Python isn't expecting.
>
> Yikes :)
>
>> 2. For speed, if the extension is creating dicts (or tuples) it knows
>> cannot participate in cycles.
>
> The optimization is now automated in the simple cases (as you've found
> out!).
>
>> This came up when Jim Fulton asked me for advice about assertion
>> failures coming out of cyclic gc in a debug build when running ZODB's
>> tests under 2.7.  Turned out to be due to the "#1 reason" above:  ZODB
>> hand-rolled its own version of weak references long before Python had
>> them, and has a dict mapping strings ("object IDs") to complex objects
>> where the referenced objects' refcounts intentionally do _not_ account
>> for the references due to this dict.
>
> Perhaps ZODB should switch to standard weak references these days?
> (as a bonus, chances are it will be faster)

This is the long term plan.  Switching is not going to be a small
project and not high on the list of priorities.

(Actually, ZODB invented its own weakref mechanism after Python had
weakrefs, but before weakrefs were subclassable. Using standard
weakrefs was deemed too expensive in terms of memory use.)

For the record, I don't consider this a Python bug.  This corner of
ZODB is living on the edge and deserves what it gets. :)  I'm just
happy the fix was ultimately pretty simple.

>> Best if no changes had been needed.  "Better than nothing" if the docs
>> are changed to warn that the effect of calling PyObject_GC_UnTrack()
>> may be undone by Python a nanosecond later ;-)
>
> A doc addition will be enough, hopefully.

Absolutely.

Jim

--
Jim Fulton
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Martin v. Löwis

> 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 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/untracking based on contents would use some other
new API (which would be non-public in 2.7.x).

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread 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 would be what you get
> when you call PyObject_GC_UnTrack; the code to do automatic
> tracking/untracking based on contents would use some other
> new API (which would be non-public in 2.7.x).
>

Where would the extra state information be stored? (to distinguish untracked
and untracked-and-keep-it-that-way)

-- 
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Greg Ewing


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.

2) Look for a match ignoring case. If one is found, test it to
see if it refers to the same file as the given path, and if so
return it.

3) Otherwise, raise an exception.

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Martin v. Löwis

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 would be what you get
> when you call PyObject_GC_UnTrack; the code to do automatic
> tracking/untracking based on contents would use some other
> new API (which would be non-public in 2.7.x).
> 
> 
> Where would the extra state information be stored? (to distinguish
> untracked and untracked-and-keep-it-that-way)

As everything else: in gc_refs.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Glenn Linderman


 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 to the name given,
return it if found.

2) Look for a match ignoring case. If one is found, test it to
see if it refers to the same file as the given path, and if so
return it.

3) Otherwise, raise an exception.



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


So the API could do the "right thing" for case preserving or case 
ignoring file systems, but for case sensitive file systems, at most an 
existence check would be warranted.


In other words, the API, should it be created, should be "What is the 
actual name of the file that matches this if it exists in the 
filesystem", so the first check is to see if it exists in the file 
system (this may raise an exception if it doesn't exist), and then if it 
does, then on those filesystems for which it might be different, obtain 
the different name.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Ben Finney

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 given,
> return it if found.

And what if there are also matches for a case-insensitive search? e.g.
searching for ‘foo/bar.DAT’ in the above example.

> 2) Look for a match ignoring case. If one is found, test it to
> see if it refers to the same file as the given path, and if so
> return it.

And what if several matches are found? e.g. searching for ‘foo/BAR.DAT’
in the above example.

> 3) Otherwise, raise an exception.

It seems to me this whole thing should be hashed out on ‘python-ideas’.

-- 
 \   “In case you haven't noticed, [the USA] are now almost as |
  `\ feared and hated all over the world as the Nazis were.” —Kurt |
_o__)   Vonnegut, 2004 |
Ben Finney

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Tim Peters

[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)?

"it's wrong ;-)" meant what it said - the track/untrack APIs weren't
intended to be hints Python is free to ignore, they were meant to give
the user control over whether and when their objects participated in
cyclic gc.  It's true that their (by far) most common uses are
mandatory, to avoid tracking before a new object is sane, and to
untrack again before it becomes insane when it's being torn down, but
those were not the only intended uses.

That said, the optimization 2.7 introduced probably has value that
shouldn't be dismissed either.

BTW, if it had taken Jim 1000 lines of new code instead of 2 to worm
around the regression in ZODB under Python 2.7, I expect he'd be
singing a different tune ;-)  I view his experience as akin to the
canary in the coal mine, albeit likely a mine with very few miners
worldwide.

> 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/untracking based on contents would use some other
> new API (which would be non-public in 2.7.x).

Looks like a promising idea!  gcmodule.c's IS_TRACKED macro would have
to change to check both states, and likewise the debug assert in
visit_reachable().
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Guido van Rossum

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

--Guido

On Fri, Sep 24, 2010 at 3:43 PM, Glenn Linderman  wrote:
>  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 to the name given,
>> return it if found.
>>
>> 2) Look for a match ignoring case. If one is found, test it to
>> see if it refers to the same file as the given path, and if so
>> return it.
>>
>> 3) Otherwise, raise an exception.
>
>
> 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).
>
> So the API could do the "right thing" for case preserving or case ignoring
> file systems, but for case sensitive file systems, at most an existence
> check would be warranted.
>
> In other words, the API, should it be created, should be "What is the actual
> name of the file that matches this if it exists in the filesystem", so the
> first check is to see if it exists in the file system (this may raise an
> exception if it doesn't exist), and then if it does, then on those
> filesystems for which it might be different, obtain the different name.
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Guido van Rossum

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, 2010 at 4:15 PM, Ben Finney  wrote:
> 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 given,
>> return it if found.
>
> And what if there are also matches for a case-insensitive search? e.g.
> searching for ‘foo/bar.DAT’ in the above example.
>
>> 2) Look for a match ignoring case. If one is found, test it to
>> see if it refers to the same file as the given path, and if so
>> return it.
>
> And what if several matches are found? e.g. searching for ‘foo/BAR.DAT’
> in the above example.
>
>> 3) Otherwise, raise an exception.
>
> It seems to me this whole thing should be hashed out on ‘python-ideas’.
>
> --
>  \           “In case you haven't noticed, [the USA] are now almost as |
>  `\     feared and hated all over the world as the Nazis were.” —Kurt |
> _o__)                                                   Vonnegut, 2004 |
> Ben Finney
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread James Y Knight

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-specific than
>> filesystem-specific). 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 new use case we
>> need a new API.
> 
> 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". From my researches, the standard interfaces a filesystem
> has to implement on Linux don't offer any means of asking this
> question.
> 
> Of course, (a) I'm no Linux expert so what do I know, and (b) it may
> well be possible to come up with a "good enough" solution by ignoring
> pathologically annoying theoretical cases.
> 
> I'm happy to provide Windows code if someone needs it.
> Paul

An OSX code sketch is available here (summary: call FSPathMakeRef to get an 
FSRef from a path string, then FSRefMakePath to make it back into a path, which 
will then have the correct case). And note that it only works if the file 
actually exists.

http://stackoverflow.com/questions/370186/how-do-i-find-the-correct-case-of-a-filename

It would indeed be useful to have that be available in Python.

James
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Brett Cannon

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 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. =)

-Brett

>
> Georg
>
> Am 24.09.2010 22:00, schrieb Brett Cannon:
>> 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
>> deltas can apply to pre-existing bugs, e.g., a bug that was re-opened.
>>
>> -Brett
>>
>>>
>>> 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 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 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:
>  open    2533 (+42)
>  closed 19189 (+57)
>  total  21722 (+53)
>
> Open issues with patches: 1061
>>>
>>> ___
>>> Python-Dev mailing list
>>> [email protected]
>>> http://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe: 
>>> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>>>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: 
>> http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
>
>
> --
> Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
> Four shall be the number of spaces thou shalt indent, and the number of thy
> indenting shall be four. Eight shalt thou not indent, nor either indent thou
> two, excepting that thou then proceed to four. Tabs are right out.
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Greg Ewing


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 to an existing
file. If not, raise an exception.

If that passes, and the file system is case-sensitive, then
there must be a directory entry that is an exact match, so
it will be returned by step 1.

If the file system is case-insensitive, then there can be
at most one entry that matches except for case, and it must
be the one we're looking for, so there is no need for the
extra test in step 2.

So the revised algorithm is:

0) Test whether the specified path refers to an existing
   file. If not, raise an exception.

1) Search the directory for an exact match, return it if found.

2) Search for a match ignoring case, and return one if found.

3) Otherwise, raise an exception.

There's also some prior art that might be worth looking at:
On Windows, Python checks to see whether the file name of an
imported module has the same case as the name being imported,
which is a similar problem in some ways.


It seems to me this whole thing should be hashed out on ‘python-ideas’.


Good point -- I've redirected the discussion there.

--
Greg

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Greg Ewing


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().

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread Steven D'Aprano

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

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.

-- 
Steven D'Aprano
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-09-24 Thread anatoly techtonik

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 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

52 matches

Mail list logo