Re: [Python-Dev] cpython: Issue #11377: platform.popen() emits a DeprecationWarning
On 24.05.2011 00:17, victor.stinner wrote: > http://hg.python.org/cpython/rev/e44b851d0a2b > changeset: 70323:e44b851d0a2b > parent: 70321:202d973e8bf5 > user:Victor Stinner > date:Tue May 24 00:16:16 2011 +0200 > summary: > Issue #11377: platform.popen() emits a DeprecationWarning Please see http://mail.python.org/pipermail/python-dev/2011-May/111303.html about the style of your commit messages. 9a16fa0c9548 is another example. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader
On Tue, May 24, 2011 at 10:08 AM, Victor Stinner wrote: > It's trivial to replace a call to codecs.open() by a call to open(), > because the two API are very close. The main different is that > codecs.open() doesn't support universal newline, so you have to use > open(..., newline='') to keep the same behaviour (keep newlines > unchanged). This task can be done by 2to3. But I suppose that most > people will be happy with the universal newline mode. Is there any reason that codecs.open() can't become a thin wrapper around builtin open in 3.3? > I don't see which usecase is not covered by TextIOWrapper. But I know > some cases which are not supported by StreamReader/StreamWriter. How API compatible is TextIOWrapper with StreamReader/StreamWriter? How hard would it to be change them to be adapters over the main IO machinery rather than independent classes? Rather than deprecating them, that seems like a more profitable direction to take them. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] CPython optimization: storing reference counters outside of objects
On Tue, May 24, 2011 at 8:33 AM, Sturla Molden wrote: > Den 24.05.2011 00:07, skrev Artur Siekielski: >> >> Oh, and using explicit shared memory or mmap is much harder, because >> you have to map the whole object graph into bytes. > > It sounds like you need PYRO, POSH or multiprocessing's proxy objects. Indeed. Abstractions over mmap (local machine sharing) and serialisation (remote sharing) are likely to be far more beneficial in this area than trying to change the underlying memory model to support copy-on-write. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stable buildbots update
In article <87zkmcalt8@uwakimon.sk.tsukuba.ac.jp>, "Stephen J. Turnbull" wrote: > Are you saying you expect Mac OS X 10.4 "Tiger" to go green once the > bots update? If so, I'm impressed, and "thank you!" to all involved. > Apple and MacPorts have long since washed their hands of that release. OS X 10.4 does have its quirks that makes it challenging to get all of the tests to run without a few cornercase failures but, besides the buildbots, I still test regularly with 10.4 and occasionally build there, too. And, FWIW, while top-of-trunk MacPorts may not officially support 10.4, many ports work there just fine including python2.6, 2.7, and 3.1. (3.2 has a build issue that may get fixed in 3.2.1). -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stable buildbots update
On Tue, 24 May 2011 11:12:35 +0900, "Stephen J. Turnbull" wrote: > Tarek Ziadé writes: > > > I have now completed the cleanup and we're back on green-land for the > > stable bots. > > Are you saying you expect Mac OS X 10.4 "Tiger" to go green once the > bots update? If so, I'm impressed, and "thank you!" to all involved. > Apple and MacPorts have long since washed their hands of that release. You will note that Tiger is *not* in the stable set :) -- R. David Murray http://www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stable buildbots update
Tarek Ziadé writes: > I have now completed the cleanup and we're back on green-land for the > stable bots. Are you saying you expect Mac OS X 10.4 "Tiger" to go green once the bots update? If so, I'm impressed, and "thank you!" to all involved. Apple and MacPorts have long since washed their hands of that release. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader
Hi, In Python 2, codecs.open() is the best way to read and/or write files using Unicode. But in Python 3, open() is preferred with its fast io module. I would like to deprecate codecs.open() because it can be replaced by open() and io.TextIOWrapper. I would like your opinion and that's why I'm writing this email. -- codecs.open() and StreamReader, StreamWriter and StreamReaderWriter classes of the codecs module don't support universal newlines, still have some issues with stateful codecs (like UTF-16/32 BOMs), and each codec has to implement a StreamReader and a StreamWriter class. StreamReader and StreamWriter are stateless codecs (no reset() or setstate() method), and so it's not possible to write a generic fix for all child classes in the codecs module. Each stateful codec has to handle special cases like seek() problems. For example, UTF-16 codec duplicates some IncrementalEncoder/IncrementalDecoder code into its StreamWriter/StreamReader class. The io module is well tested, supports non-seekable streams, handles correctly corner-cases (like UTF-16/32 BOMs) and supports any kind of newlines including an "universal newline" mode. TextIOWrapper reuses incremental encoders and decoders, so BOM issues were fixed only once, in TextIOWrapper. It's trivial to replace a call to codecs.open() by a call to open(), because the two API are very close. The main different is that codecs.open() doesn't support universal newline, so you have to use open(..., newline='') to keep the same behaviour (keep newlines unchanged). This task can be done by 2to3. But I suppose that most people will be happy with the universal newline mode. I don't see which usecase is not covered by TextIOWrapper. But I know some cases which are not supported by StreamReader/StreamWriter. -- I opened an issue for this idea. Brett and Marc-Andree Lemburg don't want to deprecate codecs.open() & friends because they want to be able to write code working on Python 2 and on Python 3 without any change. I don't think it's realistic: nontrivial programs require at least the six module, and most likely the 2to3 program. The six module can have its "codecs.open" function if codecs.open is removed from Python 3.4. StreamReader, StreamWriter, StreamReaderEncoder and EncodedFile are not used in the Python 3 standard library. I tried removed them: except tests of test_codecs which test them directly, the full test suite pass. Read the issue for more information: http://bugs.python.org/issue8796 Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] CPython optimization: storing reference counters outside of objects
Den 24.05.2011 00:07, skrev Artur Siekielski: Oh, and using explicit shared memory or mmap is much harder, because you have to map the whole object graph into bytes. It sounds like you need PYRO, POSH or multiprocessing's proxy objects. Sturla ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] CPython optimization: storing reference counters outside of objects
2011/5/23 Guido van Rossum : >> Anyway, I'd like to have working copy-on-write in CPython - in the >> presence of GIL I find it important to have multiprocess programs >> optimized (and I think it's a common idiom that a parent process >> prepares some big data structure, and child "worker" processes do some >> read-only quering). > > That is the question though -- *is* the idiom commonly used? In fact I came to the whole idea with this optimization because the idiom didn't work for me. I had a big word index built by a parent process, and than wanted the children to enable querying this index (I wanted to use all cores on a server). The index consumed 50% of RAM and after a few minutes the children consumed all RAM. I find it common in languages like Java to use thread pools, in Python+Linux we have multiprocess pools if we want to use all cores, and in this setting having a working copy-on-write is really valuable. Oh, and using explicit shared memory or mmap is much harder, because you have to map the whole object graph into bytes. > It > doesn't seem to me that it would scale all that far, since it only > works as long as all forked copies live on the same machine and run on > the same symmetrical multi-core processor. ? I don't know about multi-processor systems, but on single-processor multi-core systems (which are common even on servers) and Linux it works. Artur ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] CPython optimization: storing reference counters outside of objects
On Mon, May 23, 2011 at 1:55 PM, Artur Siekielski wrote: > Ok, I managed to make a quick but working patch (sufficient to get > working interpreter, it segfaults for extension modules). It uses the > "ememoa" allocator (http://code.google.com/p/ememoa/) which seems a > reasonable pool allocator. The patch: http://dpaste.org/K8en/. The > main obstacle was that there isn't a single function/macro that can be > used to initialize all PyObjects, so I had to initialize static > PyObjects (mainly PyTypeObjects) by hand. > > I used a naive quicksort algorithm as a benchmark: > http://dpaste.org/qquh/ . The result is that after patching it runs > 50% SLOWER. I profiled it and allocator methods used 35% time. So > there is still 15% performance loss even if the allocator is poor. > > Anyway, I'd like to have working copy-on-write in CPython - in the > presence of GIL I find it important to have multiprocess programs > optimized (and I think it's a common idiom that a parent process > prepares some big data structure, and child "worker" processes do some > read-only quering). That is the question though -- *is* the idiom commonly used? It doesn't seem to me that it would scale all that far, since it only works as long as all forked copies live on the same machine and run on the same symmetrical multi-core processor. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] CPython optimization: storing reference counters outside of objects
Ok, I managed to make a quick but working patch (sufficient to get working interpreter, it segfaults for extension modules). It uses the "ememoa" allocator (http://code.google.com/p/ememoa/) which seems a reasonable pool allocator. The patch: http://dpaste.org/K8en/. The main obstacle was that there isn't a single function/macro that can be used to initialize all PyObjects, so I had to initialize static PyObjects (mainly PyTypeObjects) by hand. I used a naive quicksort algorithm as a benchmark: http://dpaste.org/qquh/ . The result is that after patching it runs 50% SLOWER. I profiled it and allocator methods used 35% time. So there is still 15% performance loss even if the allocator is poor. Anyway, I'd like to have working copy-on-write in CPython - in the presence of GIL I find it important to have multiprocess programs optimized (and I think it's a common idiom that a parent process prepares some big data structure, and child "worker" processes do some read-only quering). Artur ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.x and bytes
On 5/23/2011 1:20 PM, Ethan Furman wrote: Glyph Lefkowitz wrote: In fact, I feel like I would want to push in the opposite direction: don't treat one-byte bytes slices less like integers; I wish I could more easily treat n-byte sequences _more_ like integers! :). More protocols have 2-byte or 4-byte network-endian packed integers embedded in them than have individual tag bytes that I want to examine. So are you thinking that bytes([01,56])[:2] == 120 ? Or more along the lines of a .to_int() method? I believe that such things can be handled by the struct module. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] CPython optimization: storing reference counters outside of objects
Den 23.05.2011 06:59, skrev "Martin v. Löwis": My expectation is that your approach would likely make the issues worse in a multi-CPU setting. If you put multiple reference counters into a contiguous block of memory, unrelated reference counters will live in the same cache line. Consequentially, changing one reference counter on one CPU will invalidate the cached reference counters of that cache line on other CPU, making your problem a) actually worse. In a multi-threaded setting with concurrent thread accessing reference counts, this would certainly worsen the situation. In a single-threaded setting, this will likely be an improvement. CPython, however, has a GIL. Thus there is only one concurrently active thread with access to reference counts. On a thread switch in the interpreter, I think the performance result will depend on the nature of the Python code: If threads share a lot of objects, it could help to reduce the number of dirty cache lines. If threads mainly work on private objects, it would likely have the effect you predict. Which will dominate is hard to tell. Instead, we could use multiple heaps: Each Python thread could manage it's own heap for malloc and free (cf. HeapAlloc and HeapFree in Windows). Objects local to one thread only reside in the locally managed heap. When an object becomes shared by seveeral Python threads, it is moved from a local heap to the global heap of the process. Some objects, such as modules, would be stored directly onto the global heap. This way, objects only used by only one thread would never dirty cache lines used by other threads. This would also be a way to reduce the CPython dependency on the GIL. Only the global heap would need to be protected by the GIL, whereas the local heaps would not need any global synchronization. (I am setting follow-up to the Python Ideas list, it does not belong on Python dev.) Sturla Molden ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stable buildbots update
On Mon, May 23, 2011 at 8:48 AM, Tarek Ziadé wrote: > On Mon, May 23, 2011 at 3:00 AM, Bill Janssen wrote: >> Tarek Ziadé wrote: >> >>> Yes, I am aware of this. I have fixed today most remaining issues, and >>> fixing the final ones right now. >> >> Just FYI: the "AMD64 Snow Leopard" buildbot and "PPC Leopard" buildbots >> are now green, but the "PPC Tiger" buildbot is still failing for all >> branches because of packaging errors: > > All the linux and windows stable slaves are now green, and I have a > few issues left to be fixed for all solaris flavors and the two you > are showing, that are also failing under Free BSD. I have now completed the cleanup and we're back on green-land for the stable bots. The red slaves should get green when they catch up with the latest rev (they are slow). If they're not and they are failing in packaging or sysconfig let me know. Sorry again if it has taken so long. Setting up Solaris and BSD VMs took some time ;) Cheers Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.x and bytes
Glyph Lefkowitz wrote: In fact, I feel like I would want to push in the opposite direction: don't treat one-byte bytes slices less like integers; I wish I could more easily treat n-byte sequences _more_ like integers! :). More protocols have 2-byte or 4-byte network-endian packed integers embedded in them than have individual tag bytes that I want to examine. So are you thinking that bytes([01,56])[:2] == 120 ? Or more along the lines of a .to_int() method? ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] the distutils2 repo and 3to2
On Mon, May 23, 2011 at 10:40 AM, Barry Warsaw wrote: > You're not required to run the default desktop (Unity) of course. There are > several options out of the box, including the classic desktop and Unity 2D, > and there are a wide range of supported derivatives of Ubuntu offering > additional desktops, such as KDE (Kubuntu) and Xfce (Xubuntu). Of course, but I still think the default affects the rate of uptake. I'm not attacking Ubuntu, but I think the uptake rate is relevant to our current discussion. That said, the multi-monitor issues prevent my updating to 11.04. -Fred -- Fred L. Drake, Jr. "Give me the luxuries of life and I will willingly do without the necessities." --Frank Lloyd Wright ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] the distutils2 repo and 3to2
Okay, this reply is getting off-topic, so I won't belabor the point (please email me directly if you want to discuss further). On May 23, 2011, at 08:25 AM, Fred Drake wrote: >2011/5/23 Łukasz Langa : >> The new Ubuntu already ships with Python 3.2. > >Uptake on Ubuntu 11.04 will take longer than 10.10 uptake, given the >reliability issues and the reaction to the new user interface. You're not required to run the default desktop (Unity) of course. There are several options out of the box, including the classic desktop and Unity 2D, and there are a wide range of supported derivatives of Ubuntu offering additional desktops, such as KDE (Kubuntu) and Xfce (Xubuntu). Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] looking for a contact at Google on the Blogger team
On Mon, May 23, 2011 at 2:15 AM, Nick Coghlan wrote: > On Sat, May 21, 2011 at 7:47 AM, "Martin v. Löwis" wrote: >>> As Jesse has said, there is an RFP in development to improve >>> python.org to the point where we can self-host blogs and the like and >>> deal with the associated user account administration appropriately. >> >> To run a blog on www.python.org, a PEP is not needed. If anybody would >> volunteer to set this up, it could be done in no time. > > If I understand correctly, the RFP is more about improving the entire > python.org toolchain to make it something that non-programmers can > easily provide content for (and even *programmers* don't particularly > like the current toolchain). > > Cheers, > Nick. That is correct. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] the distutils2 repo and 3to2
2011/5/23 Łukasz Langa : > The new Ubuntu already ships with Python 3.2. Uptake on Ubuntu 11.04 will take longer than 10.10 uptake, given the reliability issues and the reaction to the new user interface. That's not to say it won't be significant, but the strength of the indicator may be less significant than in the past. -Fred -- Fred L. Drake, Jr. "Give me the luxuries of life and I will willingly do without the necessities." --Frank Lloyd Wright ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] the distutils2 repo and 3to2
2011/5/23 Tarek Ziadé : > 2011/5/23 Łukasz Langa : > ... >> >> I've heard you're targetting 2.4 compatibility so be prepared that this is >> not going to be easy. > > yeah well, we might raise the bar to 2.5 and use some __future__ > statements. I am not sure that keeping 2.4 support is that useful > anymore. Anyone still stuck with 2.4 at this point in time is probably going to struggle to switch their packaging support library from distutils to distutils2 anyway. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] the distutils2 repo and 3to2
2011/5/23 Łukasz Langa : ... > > I've heard you're targetting 2.4 compatibility so be prepared that this is > not going to be easy. yeah well, we might raise the bar to 2.5 and use some __future__ statements. I am not sure that keeping 2.4 support is that useful anymore. Cheers Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] the distutils2 repo and 3to2
Wiadomość napisana przez Tarek Ziadé w dniu 2011-05-23, o godz. 12:58: > 2011/5/23 Łukasz Langa : > .. >> I'm maintaining a configparser 3.2+ backport for 2.6-2.7 using 3to2. > > Do you backport to 3.1 ? > Not really. I personally think people already using py3k will migrate sooner (even if they have to do it on their own) than the folk on 2.x. The new Ubuntu already ships with Python 3.2. As for Python 2.x I've learnt that keeping compatibility with a Python version without decorators, `io` library, abstract base classes, etc. would mean either diverging branches or reproducing and maintaining bits of the newer stdlib. This is something 3to2 won't help you with as it's out of scope for that tool. For configparser I only support 2.6+ and none the less the backport has a helpers module with a couple of things copied over from 2.7 or 3.1. There's also an external dependency on ordereddict, etc. You see where this is going. I've heard you're targetting 2.4 compatibility so be prepared that this is not going to be easy. -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. <> Pomyśl o środowisku naturalnym zanim wydrukujesz tę wiadomość! Please consider the environment before printing out this e-mail. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] the distutils2 repo and 3to2
2011/5/23 Łukasz Langa : .. > I'm maintaining a configparser 3.2+ backport for 2.6-2.7 using 3to2. Do you backport to 3.1 ? .. > > There's some documentation there on the conversion process I came up with. Awesome, will look up, thanks > > As for distutils2, I was already contacted by Éric Araujo and will help him > improve 3to2. We are yet to contact its authors to see if they believe > merging our changes upstream will be possible. Great, anything was started already ? If so, we should sync to see how we can initiate the d2 repo Cheers Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] the distutils2 repo and 3to2
Wiadomość napisana przez Tarek Ziadé w dniu 2011-05-23, o godz. 11:58: > Hey, > > Now that packaging has landed, the distutils2 repo is going to be > re-seted and will be the python 2.x / 3.1 / 3.2 backport of packaging. > > In theory, we want to automate the extraction of packaging from the > stdlib and a few other modules, and run 3to2 at install time. Or > should I say 3.3tosomething. > I want to do this to avoid maintaining yet another code base. In > practice, I don't really know the current state of 3to2 so we'll see.. > > Any help/hint in this project would be appreciated. I'm maintaining a configparser 3.2+ backport for 2.6-2.7 using 3to2. A fully automatic conversion is not really possible, partly because the 3to2 tool is not perfect, and partly because there are parts of the code (esp. in the tests) which no mechanical converter could have figured out on its own. Anyway, the backport is available here: http://pypi.python.org/pypi/configparser There's some documentation there on the conversion process I came up with. As for distutils2, I was already contacted by Éric Araujo and will help him improve 3to2. We are yet to contact its authors to see if they believe merging our changes upstream will be possible. -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] the distutils2 repo and 3to2
Hey, Now that packaging has landed, the distutils2 repo is going to be re-seted and will be the python 2.x / 3.1 / 3.2 backport of packaging. In theory, we want to automate the extraction of packaging from the stdlib and a few other modules, and run 3to2 at install time. Or should I say 3.3tosomething. I want to do this to avoid maintaining yet another code base. In practice, I don't really know the current state of 3to2 so we'll see.. Any help/hint in this project would be appreciated. Thanks Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.access on Windows
On 20/05/2011 22:56, "Martin v. Löwis" wrote: TBH I think the less attractive we can make os.access() look the better. It uses the real uid instead of the effective uid, it encourages LBYL behavior, the outcome may be incorrect, it doesn't work on Windows... The ONLY reason to ever use it is in a setuid() program. But who writes those any more? (Esp. in Python!) +1. The best way to determine "could I access this file" is to try to access it, and be prepared to get an exception. FWIW the OP knew this but -- for some reason specific to his use case -- wanted to avoid updating the mod dates of the containing directory. Obviously that's his problem, not ours... > So we might deprecate-then-delete it on Windows. I'll rework that patch to be a DeprecationWarning in that case. People who *really* need to know in advance should use the Windows API for that on Windows (i.e. call AccessCheck). And indeed this is what I've recommended to the OP. I'll follow this up in that python-list thread. I see that Benjamin's updated the os.access docs so I'll let this thread die and talk the OP through the AccessCheck route (which is, unfortunately, more tricky because it's not exposed by pywin32. Also not our problem...) TJG ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
