[Python-Dev] PEP 376
Hello, I think I went through all the latest feedback regarding PEP 376. There will be still some work of course, on the implementation side (for instance the Zip issues described by PJE). But I would like to go ahead and propose PEP 376 for acceptance. If it's accepted, I will implement it in pkgutil for Python 3.2 and provide a backport in distutils2. (In fact Michael Mulich has started this work in distutils2, so it might be done the other way) The next big piece is the FHS-compatible handling of resource files, which will worth a PEP on its own. Regards Tarek -- Tarek Ziadé | http://ziade.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] Reject bytearray filename in Python 3.2
Victor Stinner wrote:
> Le jeudi 22 avril 2010 00:21:02, vous avez écrit :
>> Victor Stinner wrote:
>>> I will be very sad if someone ask me to keep bytearray filename support
>>> in 3.2 because I opened a lot of issues about surrogates and I would make
>>> my work more diffcult :-(
>> I don't have an opinion one way or the other regarding bytearray, but
>> even if you deprecated it rather than dropping it, couldn't you just add
>> the surrogate support for the Unicode path and leave the bytecode path
>> with the legacy behaviour?
>
> Yes, we can do everything. But does it really have a sense? No Python
> function
> using filenames return a bytearray object. Example: os.listdir() and
> os.walk()
> result type is bytes or str.
Oh, never mind then, I misunderstood the question ('bytearray' flipped
to 'bytes' in my brain).
I don't see the point in allowing a mutable argument either.
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
[Python-Dev] PyTuple_Parse*() and discontigious buffer
Hi, I opened issue #8215 about PyTuple_Parse*() outdated documentation. When I read the code, I found two functions: getbuffer() and convertbuffer(). getbuffer() checks that the buffer is contigious, whereas convertbuffer() doesn't. We can group formats by contigious check: - contigious buffer: s, y*, z*, w* - discontigious buffer: s#, y, z, t, w, w# I tried to test formats accepting discontigious buffer but I didn't found any function or library to test this. I'm not sure that functions using s#, y, z, t, w, w# format do really support discontigious buffer and it's just a bug in getargs.c. Do someone have information about that? Should it be fixed (only accept contigious buffer)? -- Victor Stinner http://www.haypocalc.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] PEP 376
-On [20100422 10:55], Tarek Ziadé ([email protected]) wrote: >The next big piece is the FHS-compatible handling of resource files, >which will worth a PEP on its own. You do realize, I hope, that FHS is only followed by Linux distributions and not even fully at that. BSD Unixes, for example, have quite some different hier(7) requirements, most notably that /usr/local is used. So is your intent to have a PEP solely for Linux systems? -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B A wise man that walks in the dark with a blindfold on, is not much of a wise man... ___ 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] PEP 376
Jeroen Ruigrok van der Werven wrote: -On [20100422 10:55], Tarek Ziadé ([email protected]) wrote: The next big piece is the FHS-compatible handling of resource files, which will worth a PEP on its own. You do realize, I hope, that FHS is only followed by Linux distributions and not even fully at that. BSD Unixes, for example, have quite some different hier(7) requirements, most notably that /usr/local is used. So is your intent to have a PEP solely for Linux systems? I believe the intent is to have enough metadata describing the resource files that any system could be supported, including FHS. -- Eric. ___ 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] PEP 376
2010/4/22 Eric Smith : > Jeroen Ruigrok van der Werven wrote: >> >> -On [20100422 10:55], Tarek Ziadé ([email protected]) wrote: >>> >>> The next big piece is the FHS-compatible handling of resource files, >>> which will worth a PEP on its own. >> >> You do realize, I hope, that FHS is only followed by Linux distributions >> and >> not even fully at that. BSD Unixes, for example, have quite some different >> hier(7) requirements, most notably that /usr/local is used. >> >> So is your intent to have a PEP solely for Linux systems? >> > > I believe the intent is to have enough metadata describing the resource > files that any system could be supported, including FHS. Yes that's the idea. We want to provide a way in Python, to describe for each system (Windows included) default paths for resource files, and to give the ability to system packagers to change them. At the end, the developer will be able to say "Foo is a help file", and leave it up to distutils to install it at the best place depending on the platform. Then, he'll be able to say "Let me have Foo" at runtime. And os packagers, for example in Ubuntu, will be able to say "for now on, help files will be located *here*". We did quite a lot of work already on this during Pycon, see : http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst FHS was just our insipiration to list the different targets, because it's one of the most advanced description in this field. But we do need to provide default locations under windows as well, and windows will possibly add new locations, who knows.. Regards Tarek -- Tarek Ziadé | http://ziade.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] Doctests REPORT_ONLY_FIRST_FAILURE ignored
On Wed, Apr 21, 2010 at 06:56, Lennart Regebro wrote: > If you set up any sort of report flag on the unit test itself, the > default report flags given to the testrunner are ignored. This goes > for all report flags, the REPORT_xDIFF and REPORT_ONLY_FIRST_FAILURE. > I'd suggest that we do allow the testrunner to set > REPORT_ONLY_FIRST_FAILURE by default even if the testcase has a > REPORT_xDIFF flag. Why? Because it makes sense. :) > > The REPORT_xDFF flags makes sense both as parameters to a testrunner, > and as flags on a testcase. You might want to permanently set diff > flags on tests that generate output that warrants a diff if they fail. > > REPORT_ONLY_FIRST_FAILURE you would rarely set on a testcase. You > don't want that on the testcase, as buildbots wouldn't see the > subsequent fails, and developers might think it was only a minor > issue. It is a flag you give to the testrunner to stop having the > first failure scroll off screen. So you want it to work *always*. You > don't want or expect it to stop working just because one testcase had > a DIFF flag set. Right? > > Or did I miss something? If not, I'll provide a patch and put it in > the bugtracker. I apparently didn't miss anything. :) Patch will arrive soon. :) ___ 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] PEP 376
At 10:54 AM 4/22/2010 +0200, Tarek Ziadé wrote: Hello, I think I went through all the latest feedback regarding PEP 376. There will be still some work of course, on the implementation side (for instance the Zip issues described by PJE). But I would like to go ahead and propose PEP 376 for acceptance. One final (optional) question/suggestion... should we change from this (in RECORD files): lib/python2.6/site-packages/docutils/__init__.pyc to this: lib/python2.6/site-packages/docutils/__init__.pyc,, In this way, reader code can be written as: for path, hash, size in csv.reader(...): It's not a high-priority thing, but if anybody is writing code to parse RECORD files outside the provided API implementation (eg. system packaging tool authors), they'll probably appreciate this. ;-) ___ 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] PEP 376
2010/4/22 P.J. Eby : > At 10:54 AM 4/22/2010 +0200, Tarek Ziadé wrote: >> >> Hello, >> >> I think I went through all the latest feedback regarding PEP 376. >> >> There will be still some work of course, on the implementation side >> (for instance the Zip issues described by PJE). >> >> But I would like to go ahead and propose PEP 376 for acceptance. > > One final (optional) question/suggestion... should we change from this (in > RECORD files): > > lib/python2.6/site-packages/docutils/__init__.pyc > > to this: > > lib/python2.6/site-packages/docutils/__init__.pyc,, > > In this way, reader code can be written as: > > for path, hash, size in csv.reader(...): > > It's not a high-priority thing, but if anybody is writing code to parse > RECORD files outside the provided API implementation (eg. system packaging > tool authors), they'll probably appreciate this. ;-) > Yes, of course. the RECORD file is supposed to be iterable using the csv reader, so that's a mistake in the PEP. Thanks for noticing, I'll fix it later today > -- Tarek Ziadé | http://ziade.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
[Python-Dev] code.python.org - random 403 errors
I am seeing random 403 errors when cloning the mercurial repositories of Python. $ hg clone http://code.python.org/hg/branches/release2.6-maint destination directory: release2.6-maint requesting all changes abort: HTTP Error 403: Forbidden $ hg clone http://code.python.org/hg/branches/release2.6-maint/ destination directory: release2.6-maint requesting all changes abort: HTTP Error 403: Forbidden Sometimes they work, sometimes not. Should I report this issue to a specific tracker (other than bugs.python.org and [email protected])? -srid ___ 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] code.python.org - random 403 errors
Sridhar Ratnakumar wrote: > I am seeing random 403 errors when cloning the mercurial repositories of > Python. > > $ hg clone http://code.python.org/hg/branches/release2.6-maint > destination directory: release2.6-maint > requesting all changes > abort: HTTP Error 403: Forbidden > $ hg clone http://code.python.org/hg/branches/release2.6-maint/ > destination directory: release2.6-maint > requesting all changes > abort: HTTP Error 403: Forbidden > > Sometimes they work, sometimes not. What's your IP address? (you may want to tell in private only). > Should I report this issue to a specific tracker (other than bugs.python.org > and [email protected])? Please don't report that to the tracker. 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] code.python.org - random 403 errors
Sridhar Ratnakumar wrote: > I am seeing random 403 errors when cloning the mercurial repositories of > Python. > > $ hg clone http://code.python.org/hg/branches/release2.6-maint > destination directory: release2.6-maint > requesting all changes > abort: HTTP Error 403: Forbidden > $ hg clone http://code.python.org/hg/branches/release2.6-maint/ > destination directory: release2.6-maint > requesting all changes > abort: HTTP Error 403: Forbidden > > Sometimes they work, sometimes not. In general python.org seems flaky today. Sometimes I could not reach the site at all, now a ping to svn.python.org gives 30% packet loss. Stefan Krah ___ 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] code.python.org - random 403 errors
> In general python.org seems flaky today. Sometimes I could not reach the site > at all, now a ping to svn.python.org gives 30% packet loss. Yes. See http://www.python.org/munin/localdomain/localhost.localdomain-if_eth0.html Somebody was consuming all bandwidth, although we couldn't quite figure out who (whenever I was looking, the traffic looked genuine). It turned out that Sridhar himself contributed a good chunk of this traffic. 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] code.python.org - random 403 errors
On 2010-04-22, at 3:01 PM, Martin v. Löwis wrote: >> In general python.org seems flaky today. Sometimes I could not reach the site >> at all, now a ping to svn.python.org gives 30% packet loss. > > Yes. See > > http://www.python.org/munin/localdomain/localhost.localdomain-if_eth0.html > > Somebody was consuming all bandwidth, although we couldn't quite figure > out who (whenever I was looking, the traffic looked genuine). It turned > out that Sridhar himself contributed a good chunk of this traffic. Background in private emails to Martin (below): On 2010-04-22, at 5:42 PM, Sridhar Ratnakumar wrote: > > On 2010-04-22, at 2:13 PM, Martin v. Löwis wrote: > >>> [snip ... ip address] >>> >>> I must note that we do a nightly build of ActivePython using Python >>> mercurial repositories for trunk, release26-maint and release31-maint >>> (3 URLs) on 5 of our build machines. So one nightly build will make >>> 3x5=15 "hg clone" requests per day to code.python.org. This week, I >>> have been debugging the nightly build code (run by hudson); so that >>> number is likely higher this week. >> >> [snip ... possibly security-confidential part] >> >> Can you please find a way not to clone the complete repository every >> time? IIUC, it should be possible to update a clone, rather than >> refetching it from scratch. > > Ok, I setup a cron job to maintain an internal mirror of the above mentioned > repositories in code.python.org. We'll do a "hg pull -u" (equivalent to "svn > up") every hour; no clones. Hopefully, that should reduce the amount of > requests from our side. Let me know if in future this issue repeats. ___ 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] code.python.org - random 403 errors
-On [20100423 02:48], Sridhar Ratnakumar ([email protected]) wrote: >> Ok, I setup a cron job to maintain an internal mirror of the above mentioned >> repositories in code.python.org. We'll do a "hg pull -u" (equivalent to "svn >> up") every hour; no clones. Hopefully, that should reduce the amount of >> requests from our side. Let me know if in future this issue repeats. Dirk Jan can probably correct me (or some other heavy Hg user) but for all I know you should indeed simply clone once and subsequently hg pull and from your local copy clone as you like. (At least that's also how http://wiki.services.openoffice.org/wiki/Mercurial/Getting_Started seems to aim at explaining.) -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B A wise man that walks in the dark with a blindfold on, is not much of a wise man... ___ 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
