Re: [Python-Dev] Python 2.5.1
Hi Martin, On 4/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > The error Windows reports is ERROR_SHARING_VIOLATION. I never > understood sharing fully, but it may be that if the file is opened > in "exclusive sharing", stat'ing it may fail. Sharing is actually very easy. If you didn't specify SHARE_READ/SHARE_WRITE/SHARE_DELETE when opening the file and you succeeded, then any process can't read/write/delete the file until you close the handle. > I personally consider it a bug in Windows that you cannot get file > attributes if some other process has opened it. Exclusive access > should only restrict access to file contents, but not file attributes. After doing some research I found that it seems to be impossible to use CreateFile for a file that doesn't have SHARE_READ. I played with different combinations and with FLAG_BACKUP_SEMANTICS and nothing helped. However on Windows there's still a possibility to read attributes: use FindFirstFile. _WIN32_FIND_DATA structure seems to have all the necessary fields (attributes, file times, size and full/short filename), and FindFirstFile doesn't care about sharing at all... ___ 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] New Super PEP
James> I did not intend to imply that it should be impossible to pass James> different arguments, only that passing the same ones should be James> foolproof and not require repeating yourself. Then some other argument syntax than "()" is needed which clearly means, "pass no arguments". Skip ___ 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-3000] Pre-pre PEP for 'super' keyword
Delaney, Timothy (Tim) wrote: > What I'm proposing is that the `super = super_factory()` line be > implicit in this case, resulting in the following code behaving > identically: > > class A(object): > def f(self): > def inner(): > return 'A' + super.f() > > print inner() As Guido pointed out it has some resemblance to how import works, but I also think there is resemblance to the context of how global is used. So if it is made into a keyword, could it work like the global keyword? class A(object): def f(self): def inner(): super f return 'A' + f() print inner() Cheers, Ron ___ 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-3000] Pre-pre PEP for 'super' keyword
From: "Delaney, Timothy (Tim)" <[EMAIL PROTECTED]> > Sorry - this is related to my proposal that the following two bits of > code behave the same: > >class A(object): >def f(self, *p, **kw): >super.f(*p, **kw) > >class A(object): >def f(self, *p, **kw): >super(*p, **kw) > > But as has been pointed out, this creates an ambiguity with: > >class A(object): >def f(self, *p, **kw): >super.__call__(*p, **kw) > > so I want to see if I can resolve it. A 'super' instance would be callable, without being able to access it's __call__ method (because super.__call__ would refer to the base class method of that name). But I find I really don't care. The only place where that would really matter IMO is if you want to find out if a 'super' instance is callable. Calling a base class __call__ method would not be ambiguous - the following two classes would work the same: class A(object): def __call__(self, *p, **kw): return super.__call__(*p, **kw) class A(object): def __call__(self, *p, **kw): return super(*p, **kw) So, I guess my question is whether the most common case of calling the base class method with the same name is worth having some further syntactic sugar to avoid repetition? I think it is, but that would be your call Guido. Cheers, Tim Delaney ___ 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] (no subject)
I was hoping you guys would consider creating function in os.path or otherwise that would find the full path of a file when given only it's base name and nothing else.I have been made to understand that this is not currently possible.If it is in any can you please inform me of it[i know this is not a tutorial] but please i need thiis badly if it's possible.Thank you _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ 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] Find file given basename
Joshua> I was hoping you guys would consider creating function in Joshua> os.path or otherwise that would find the full path of a file Joshua> when given only it's base name and nothing else.I have been made Joshua> to understand that this is not currently possible.If it is in Joshua> any can you please inform me of it[i know this is not a Joshua> tutorial] but please i need thiis badly if it's possible.Thank Joshua> you Joshua, This topic should be discussed (at least until there is a concrete proposal) on the Usenet newgroup comp.lang.python (a.k.a. [EMAIL PROTECTED]). It would be helpful if you presented a concrete example. As stated though there is no unique file that matches a given basename. You might also want to check out the glob module to see if it addresses your needs. Skip ___ 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-3000] Pre-pre PEP for 'super' keyword
On 4/30/07, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > >> 1. When a method is defined, the class is bound to it via an > attribute > >> (which in my version is called func_class). > > > In Py3k all the func_XXX attrs are renamed __XXX__, so this would be > > __class__; but that's a name reserved for something else, so it would > > need to be something else. E.g. __containing_class__. > > Yep - I've just used a placeholder name. > > > Also, this would have to be done when the class is defined; when the > > method is being defined the class doesn't exist yet. > > Good point. Change that to "at the first opportunity" ;) > > >> 2. Every non-static method has an implicit cell variable called > >> 'super'. > > > > I think you're using 'cell' in a different sense than it is normally > > used in Python's implementation. What you are looking for is called a > > local variable (I deduce this from your initialization of the "cell" > > with something computed from the first argument). > > Actually, I think I'm using the terminology correctly - I'm talking > about an entry in co_cellvars. Given the following class: > > class A(object): > def f(self): > super = super_factory() > > def inner(): > return 'A' + super.f() > > print inner() > > the use of 'super' in both A.f and A.f.inner will produce an entry in > A.f.func_code.co_cellvars and A.f.inner.func_code.co_freevars. What I'm > proposing is that the `super = super_factory()` line be implicit in this > case, resulting in the following code behaving identically: > > class A(object): > def f(self): > def inner(): > return 'A' + super.f() > > print inner() I believe the direction my PEP took with all this is a good bit primitive compared to this approach, although I still find value in it because at least a prototype came out of it that can be used to test the waters, regardless of if a more direct-in-the-language approach would be superior. However, I seem to think that if the __this_class__ PEP goes through, your version can be simplified as well. No tricky stuffy things in cells would be needed, but we can just expand the super 'keyword' to __super__(__this_class__, self), which has been suggested at least once. It seems this would be much simpler to implement, and it also brings up a second point. Also, I like that the super object is created at the beginning of the function, which my proposal couldn't even do. It is more efficient if you have multiple super calls, and gets around a problem I completely missed: what happens if the instance name were rebound before the implicit lookup of the instance object at the time of the super call? > >> The issue of super() vs. super.__call__() ambiguity - I'll need to > >> look at that when I get home. > > > > Sounds irrelevant -- if super is equivalent to > > __builtin__.__super__(, ) then super never gets > > called; the only thing ever done to it (in the normal course of > > things) is to request an attribute of it. > > Sorry - this is related to my proposal that the following two bits of > code behave the same: > > class A(object): > def f(self, *p, **kw): > super.f(*p, **kw) > > class A(object): > def f(self, *p, **kw): > super(*p, **kw) > > But as has been pointed out, this creates an ambiguity with: > > class A(object): > def f(self, *p, **kw): > super.__call__(*p, **kw) > > so I want to see if I can resolve it. Turns out, it doesn't. A lot of people expect it, but it turns out to be simple. super(*p, **kw) is not equivalent to super.__call__(*p, **kw) but to type(super).__call__.__get__(super, type(super))(*p, **kw), due to operator methods being looked up on the type directly and bound by the descriptor, without any lookup on the super object itself. Thus, no attribute is ever done on the super object itself, type(super).__getattribute__ is never invoked, and there is no problem at all. This also means we can still invoke super the old, explicit way. I've already got my copy of the PEP updated to reflect this. > > super(ThisClass).method(...) # ??? > > > > The third exists so that you can create an "unbound" super instance > > which is useful for the oft-misunderstood autosuper example in my > > "descrintro" essay: > > > http://www.python.org/download/releases/2.2.3/descrintro/#metaclass_exam > ples > > . > > > > But since the latter is the hack that we're trying to replace with a > > proper implementation here, I suspect we can get away with only > > supporting the first two forms (and the third form is still supported > > using __builtin__.__super__). > > Yep - that's my thought as well. I think it would be very rare to need > super(ThisClass), although it makes some sense that that would be what > super means in a static method ... Does super mean anything in a static method today?
Re: [Python-Dev] New Super PEP
On 4/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > James> I did not intend to imply that it should be impossible to pass > James> different arguments, only that passing the same ones should be > James> foolproof and not require repeating yourself. > > Then some other argument syntax than "()" is needed which clearly means, > "pass no arguments". I second, because I would like an actually good way to do this. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.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] [Python-3000] PEP 30XZ: Simplified Parsing
Jim Jewett wrote:
> Rationale for Removing Implicit String Concatenation
>
> Implicit String concatentation can lead to confusing, or even
> silent, errors. [1]
>
> def f(arg1, arg2=None): pass
>
> f("abc" "def") # forgot the comma, no warning ...
> # silently becomes f("abcdef", None)
>
> or, using the scons build framework,
>
> sourceFiles = [
> 'foo.c',
> 'bar.c',
> #...many lines omitted...
> 'q1000x.c']
>
Since your first example omits the comma, I think this one should, too.
sourceFiles = [
'foo.c'
'bar.c',
#...many lines omitted...
'q1000x.c']
That is, either both examples should show an error, or both examples
should work, but point out how easy it is to make an error.
Eric.
___
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-3000] Pre-pre PEP for 'super' keyword
From: "Calvin Spealman" <[EMAIL PROTECTED]> > I believe the direction my PEP took with all this is a good bit > primitive compared to this approach, although I still find value in it > because at least a prototype came out of it that can be used to test > the waters, regardless of if a more direct-in-the-language approach > would be superior. I've been working on improved super syntax for quite a while now - my original approach was 'self.super' which used _getframe() and mro crawling too. I hit on using bytecode hacking to instantiate a super object at the start of the method to gain performance, which required storing the class in co_consts, etc. It turns out that using a metaclass then makes this a lot cleaner. > However, I seem to think that if the __this_class__ PEP goes through, > your version can be simplified as well. No tricky stuffy things in > cells would be needed, but we can just expand the super 'keyword' to > __super__(__this_class__, self), which has been suggested at least > once. It seems this would be much simpler to implement, and it also > brings up a second point. > > Also, I like that the super object is created at the beginning of the > function, which my proposal couldn't even do. It is more efficient if > you have multiple super calls, and gets around a problem I completely > missed: what happens if the instance name were rebound before the > implicit lookup of the instance object at the time of the super call? You could expand it inline, but I think your second point is a strong argument against it. Also, sticking the super instance into a cell means that inner classes get access to it for free. Otherwise each inner class would *also* need to instantiate a super instance, and __this_class__ (or whatever it's called) would need to be in a cell for them to get access to it instead. BTW, one of my test cases involves multiple super calls in the same method - there is a *very* large performance improvement by instantiating it once. >> I think it would be very rare to need >> super(ThisClass), although it makes some sense that that would be what >> super means in a static method ... > > Does super mean anything in a static method today? Well, since all super instantiations are explicit currently, it can mean whatever you want it to. class A(object): @staticmethod def f(): print super(A) print super(A, A) Cheers, Tim Delaney ___ 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-3000] Pre-pre PEP for 'super' keyword
On 4/30/07, Tim Delaney <[EMAIL PROTECTED]> wrote: > I've been working on improved super syntax for quite a while now - my > original approach was 'self.super' which used _getframe() and mro crawling > too. I hit on using bytecode hacking to instantiate a super object at the > start of the method to gain performance, which required storing the class in > co_consts, etc. It turns out that using a metaclass then makes this a lot > cleaner. > > > However, I seem to think that if the __this_class__ PEP goes through, > > your version can be simplified as well. No tricky stuffy things in > > cells would be needed, but we can just expand the super 'keyword' to > > __super__(__this_class__, self), which has been suggested at least > > once. It seems this would be much simpler to implement, and it also > > brings up a second point. > > > > Also, I like that the super object is created at the beginning of the > > function, which my proposal couldn't even do. It is more efficient if > > you have multiple super calls, and gets around a problem I completely > > missed: what happens if the instance name were rebound before the > > implicit lookup of the instance object at the time of the super call? > > You could expand it inline, but I think your second point is a strong > argument against it. Also, sticking the super instance into a cell means > that inner classes get access to it for free. Otherwise each inner class > would *also* need to instantiate a super instance, and __this_class__ (or > whatever it's called) would need to be in a cell for them to get access to > it instead. > > BTW, one of my test cases involves multiple super calls in the same method - > there is a *very* large performance improvement by instantiating it once. Note that I would now advocate the creation of the super object at the beginning of function, and when I talk about expanding super to super(__this_class__, self) I do mean doing it at the beginning of the function, just like you are saying, so we're in agreement here. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.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] New Super PEP
Hi Calvin, On Mon, Apr 30, 2007 at 08:34:56AM -0400, Calvin Spealman wrote: > If you want, you can also grab the reference > implementation from my blog: http://ironfroggy-code.blogspot.com/ This reference implementation is broken. It doesn't pass the following test, for example: class A(object): __metaclass__ = autosuper def f(self): if type(self) is B: return "we've got a B" else: return "oups" class B(A): def f(self): return Super.f() assert B().f() == "we've got a B" I don't honestly think that you can easily fix the implementation to pass this test, but I'm ready to check proposed fixes and write tests for them. If there is really no working implementation yet then it shouldn't have been a PEP posted on python-dev in the first place, IMHO (and the discussion shouldn't go on on python-dev either). A bientot, Armin. ___ 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] New Super PEP
On 4/30/07, Armin Rigo <[EMAIL PROTECTED]> wrote: > Hi Calvin, > > On Mon, Apr 30, 2007 at 08:34:56AM -0400, Calvin Spealman wrote: > > If you want, you can also grab the reference > > implementation from my blog: http://ironfroggy-code.blogspot.com/ > > This reference implementation is broken. It doesn't pass the following > test, for example: > > class A(object): > __metaclass__ = autosuper > def f(self): > if type(self) is B: > return "we've got a B" > else: > return "oups" > > class B(A): > def f(self): > return Super.f() > > assert B().f() == "we've got a B" > > I don't honestly think that you can easily fix the implementation to > pass this test, but I'm ready to check proposed fixes and write tests > for them. If there is really no working implementation yet then it > shouldn't have been a PEP posted on python-dev in the first place, IMHO > (and the discussion shouldn't go on on python-dev either). You are absolutely correct, it should not have gone to python-dev. It was supposed to go to python-3000, where the initial discussion took place, where Guido asked for someone to write the PEP right off the bat. However, as much as I love GMail, it makes it less than easy to always know which mailing list I'm on, so I actually thought I was in that discussion at dev, not 3000. I apologize to everyone for mixing the threads between lists! This is exactly why I need to start pulling in all the dev lists to the summaries. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.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] deprecating macpath and macurl2path
On Monday, April 30, 2007, at 06:28AM, "Neal Norwitz" <[EMAIL PROTECTED]> wrote: >PEP 11 notes that Mac OS 9 support was unsupported in 2.4. There are >still quite a few places that we check for sys.platform == 'mac'. >There are also (at least) 2 modules (macpath and macurl2path) that >look specific to Mac OS. (OS X has sys.platform == 'darwin'.) > >Shall I add a deprecation warning on import to these modules or remove them? > >I plan to remove other mac specific code (checking sys.platform) in >the stdlib unless someone beat me to it. I don't know if anyone uses macpath for it, but OS9-style paths are still used in a number of APIs on OSX. macurl2path seems OS9 specific. Ronald ___ 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] os.rename on windows
Hi, I have submitted a patch (http://www.python.org/sf/1704547) that allows os.rename to replace the destination file if it exists, on windows. As part of discussion in the tracker, Martin suggested that python-dev should discuss the change. Currently, os.rename() on windows uses the API MoveFile() which fails if the destination file exists. The patch replaces this API with MoveFileEx() and uses the flag MOVEFILE_REPLACE_EXISTING which causes the destination file to be replaced if it exists. However, this change is subtle and if there is any existing code that depends on current os.rename behaviour on windows, their code is silently broken with (any) destination file being overwritten. But the functionality of replacing is important and I would like to know the best of way of supporting it. If it is deemed that this change is not good to go in as-is, how about having an optional parameter to os.rename (say, win_replace) that can be used by callers to explicitly request replacing? I must also point out that the patch uses another flag MOVEFILE_COPY_ALLOWED effectively allowing renamed files to be on separate file systems. The renaming in this case is not atomic and I used this flag only to support current functionality. It is not a bad idea to disallow such renames which brings it in line with the behaviour on many unix flavors. This also has the potential to break code but not silently. Lastly, I found an old discussion about the same topic by this list. http://mail.python.org/pipermail/python-dev/2001-May/014957.html Even though Guido indicated that he doesn't support API change in this thread, I am posting again as I did not see any one mention MoveFileEx() in that thread. Thanks, Raghu. ___ 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-3000] Pre-pre PEP for 'super' keyword
On 4/29/07, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > >> 2. Every non-static method has an implicit cell variable called > >> 'super'. > > > > I think you're using 'cell' in a different sense than it is normally > > used in Python's implementation. What you are looking for is called a > > local variable (I deduce this from your initialization of the "cell" > > with something computed from the first argument). > > Actually, I think I'm using the terminology correctly - I'm talking > about an entry in co_cellvars. Given the following class: > > class A(object): > def f(self): > super = super_factory() > > def inner(): > return 'A' + super.f() > > print inner() > > the use of 'super' in both A.f and A.f.inner will produce an entry in > A.f.func_code.co_cellvars and A.f.inner.func_code.co_freevars. What I'm > proposing is that the `super = super_factory()` line be implicit in this > case, resulting in the following code behaving identically: > > class A(object): > def f(self): > def inner(): > return 'A' + super.f() > > print inner() OK, I see now. I thought you meant for the cell-ness to be related to the basic implementation; but you meant it so that it woks correctly inside nested functions. That's fine of course. You might clarify this somewhere. > >> The issue of super() vs. super.__call__() ambiguity - I'll need to > >> look at that when I get home. > > > > Sounds irrelevant -- if super is equivalent to > > __builtin__.__super__(, ) then super never gets > > called; the only thing ever done to it (in the normal course of > > things) is to request an attribute of it. > > Sorry - this is related to my proposal that the following two bits of > code behave the same: > > class A(object): > def f(self, *p, **kw): > super.f(*p, **kw) > > class A(object): > def f(self, *p, **kw): > super(*p, **kw) > > But as has been pointed out, this creates an ambiguity with: > > class A(object): > def f(self, *p, **kw): > super.__call__(*p, **kw) > > so I want to see if I can resolve it. I think the shortcut is more confusing than helpful; I propose to drop it for the sake of focusing on the essential. > > super(ThisClass).method(...) # ??? > > > > The third exists so that you can create an "unbound" super instance > > which is useful for the oft-misunderstood autosuper example in my > > "descrintro" essay: > > > > http://www.python.org/download/releases/2.2.3/descrintro/#metaclass_exampples > > . > > > > But since the latter is the hack that we're trying to replace with a > > proper implementation here, I suspect we can get away with only > > supporting the first two forms (and the third form is still supported > > using __builtin__.__super__). > > Yep - that's my thought as well. I think it would be very rare to need > super(ThisClass), although it makes some sense that that would be what > super means in a static method ... But that doesn't work with the current (2.x) super, and hasn't been requested AFAIK, so I'd suggest dropping the use case -- KISS again. -- --Guido van Rossum (home page: http://www.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
[Python-Dev] Call for junior PEP editors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Goodger and I have been the PEP editors for ages. Well, mostly David lately as I've been way too busy to be of much use. David is also pretty busy, and he lamented that he doesn't have much time for editing when he put out his call for PEPs earlier this month. We've now, or will soon have three more experienced Pythonistas helping out as PEP editors, Georg Brandl, Brett Cannon, and Anthony Baxter. As long as they've been hacking Python, you'd have thought they'd have learned their lesson by now, but we'll gladly consume more of their time and souls. David and I would like to see some junior Pythonistas join the PEP editor team, as a great way to gain experience and become more involved with the community. As David says, PEP editing is something a tech writer can do; it doesn't require intimate knowledge of Python's C code base for example. PEP editors don't judge the worthiness of a PEP -- that's for the Python community to do, but they do the important work of ensuring that the PEPs are up to the high quality and consistent standards that have been established over the years. A PEP editor is sometimes also involved in the meta process of developing and maintaining the PEPs. A good editor's eye, excellent written communication skills, and the inhuman amount of spare time that only the young have are your most important qualifications. If you're a budding Pythonista and are interested in becoming a PEP editor, please send an email to [EMAIL PROTECTED] Let us know about your writing and/or editing experience, how long you've been using Python, how long you've been programming in general, and how much cash you'll be sending our way. Kidding about that last bit. python- dev lurkers are encouraged to apply! Again, this call is for junior Pythonistas only. I think we have enough experienced people now to cover our bases and to help mentor new editors. We're really eager to get some new blood involved in the Python community. We may not accept all applicants; we're aiming for two or three additional editors, but that number isn't set in stone. Cheers, - -Barry (and David) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRjZzeXEjvBPtnXfVAQIzFAQAhj1VIaa+QZ6+7O2BlmDGgCzXiJt1Yfb+ uz8HxVfL+5wjXeQELAPM0hxp07qKtq8ys131gZI19BtGe8F+imzEIkyZJvHrJYNw vOboLs9cSJuDlH0QCKT5p9HNf9H75tm5gOFiCTnDDKJ4/BRzsUG62EHDd4Tz9brq euEKecOMiwk= =vNz1 -END 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] Python 2.5.1
> After doing some research I found that it seems to be impossible to > use CreateFile for a file that doesn't have SHARE_READ. I played with > different combinations and with FLAG_BACKUP_SEMANTICS and nothing > helped. However on Windows there's still a possibility to read > attributes: use FindFirstFile. _WIN32_FIND_DATA structure seems to > have all the necessary fields (attributes, file times, size and > full/short filename), and FindFirstFile doesn't care about sharing at > all... So what about GetFileAttributesEx? What are the conditions under which I can successfully invoke it? Regards, Martin ___ 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] PEP 0365: Adding the pkg_resources module
I wanted to get this in before the Py3K PEP deadline, since this is a Python 2.6 PEP that would presumably impact 3.x as well. Feedback welcome. PEP: 365 Title: Adding the pkg_resources module Version: $Revision: 55032 $ Last-Modified: $Date: 2007-04-30 20:24:48 -0400 (Mon, 30 Apr 2007) $ Author: Phillip J. Eby <[EMAIL PROTECTED]> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 30-Apr-2007 Post-History: 30-Apr-2007 Abstract This PEP proposes adding an enhanced version of the ``pkg_resources`` module to the standard library. ``pkg_resources`` is a module used to find and manage Python package/version dependencies and access bundled files and resources, including those inside of zipped ``.egg`` files. Currently, ``pkg_resources`` is only available through installing the entire ``setuptools`` distribution, but it does not depend on any other part of setuptools; in effect, it comprises the entire runtime support library for Python Eggs, and is independently useful. In addition, with one feature addition, this module could support easy bootstrap installation of several Python package management tools, including ``setuptools``, ``workingenv``, and ``zc.buildout``. Proposal Rather than proposing to include ``setuptools`` in the standard library, this PEP proposes only that ``pkg_resources`` be added to the standard library for Python 2.6 and 3.0. ``pkg_resources`` is considerably more stable than the rest of setuptools, with virtually no new features being added in the last 12 months. However, this PEP also proposes that a new feature be added to ``pkg_resources``, before being added to the stdlib. Specifically, it should be possible to do something like:: python -m pkg_resources SomePackage==1.2 to request downloading and installation of ``SomePackage`` from PyPI. This feature would *not* be a replacement for ``easy_install``; instead, it would rely on ``SomePackage`` having pure-Python ``.egg`` files listed for download via the PyPI XML-RPC API, and the eggs would be placed in the ``$PYTHONEGGS`` cache, where they would **not** be importable by default. (And no scripts would be installed) However, if the download egg contains installation bootstrap code, it will be given a chance to run. These restrictions would allow the code to be extremely simple, yet still powerful enough to support users downloading package management tools such as ``setuptools``, ``workingenv`` and ``zc.buildout``, simply by supplying the tool's name on the command line. Rationale = Many users have requested that ``setuptools`` be included in the standard library, to save users needing to go through the awkward process of bootstrapping it. However, most of the bootstrapping complexity comes from the fact that setuptools-installed code cannot use the ``pkg_resources`` runtime module unless setuptools is already installed. Thus, installing setuptools requires (in a sense) that setuptools already be installed. Other Python package management tools, such as ``workingenv`` and ``zc.buildout``, have similar bootstrapping issues, since they both make use of setuptools, but also want to provide users with something approaching a "one-step install". The complexity of creating bootstrap utilities for these and any other such tools that arise in future, is greatly reduced if ``pkg_resources`` is already present, and is also able to download pre-packaged eggs from PyPI. (It would also mean that setuptools would not need to be installed in order to simply *use* eggs, as opposed to building them.) Finally, in addition to providing access to eggs built via setuptools or other packaging tools, it should be noted that since Python 2.5, the distutils install package metadata (aka ``PKG-INFO``) files that can be read by ``pkg_resources`` to identify what distributions are already on ``sys.path``. In environments where Python packages are installed using system package tools (like RPM), the ``pkg_resources`` module provides an API for detecting what versions of what packages are installed, even if those packages were installed via the distutils instead of setuptools. Implementation and Documentation The ``pkg_resources`` implementation is maintained in the Python SVN repository under ``/sandbox/trunk/setuptools/``; see ``pkg_resources.py`` and ``pkg_resources.txt``. Documentation for the egg format(s) supported by ``pkg_resources`` can be found in ``doc/formats.txt``. HTML versions of these documents are available at: * http://peak.telecommunity.com/DevCenter/PkgResources and * http://peak.telecommunity.com/DevCenter/EggFormats (These HTML versions are for setuptools 0.6; they may not reflect all of the changes found in the Subversion trunk's ``.txt`` versions.) Copyright = This document has been placed in the public domain. ___ Python-Dev mailing list Python-Dev@python.org http://
Re: [Python-Dev] os.rename on windows
Raghuram Devarakonda wrote: > Hi, > > I have submitted a patch (http://www.python.org/sf/1704547) that > allows os.rename to replace the destination file if it exists, on > windows. As part of discussion in the tracker, Martin suggested that > python-dev should discuss the change. Does MOVEFILE_REPLACE_EXISTING mean the rename over an existing file is actually atomic? I cannot find any MSDN docs that say so (and I've seen some that suggest to me that it probably isn't). If it's not atomic, then this doesn't offer any advantage over shutil.move that I can see (and in fact would damage the usefulness of os.rename, which is currently atomic on all platforms AFAIK, even though it cannot succeed all the time). If MOVEFILE_REPLACE_EXISTING miraculously turns out to be atomic, then my opinion is: * this feature would be very useful, and I would like a cross-platform way to do this in Python. * this feature should not be called "os.rename", which for years has done something else on some platforms, and so changing it will invite unnecessary breakage. A new function would be better, or perhaps an optional flag. I propose "os.atomic_rename". Also, I assume this cannot replace files that are in use? > Currently, os.rename() on windows uses the API MoveFile() which fails > if the destination file exists. The patch replaces this API with > MoveFileEx() and uses the flag MOVEFILE_REPLACE_EXISTING which causes > the destination file to be replaced if it exists. However, this change > is subtle and if there is any existing code that depends on current > os.rename behaviour on windows, their code is silently broken with > (any) destination file being overwritten. But the functionality of > replacing is important and I would like to know the best of way of > supporting it. If it is deemed that this change is not good to go in > as-is, how about having an optional parameter to os.rename (say, > win_replace) that can be used by callers to explicitly request > replacing? I'd be ok with a flag, but it should have a cross-platform name. "require_atomic" or "replace" or something like that. I think a new function makes more sense, though. > I must also point out that the patch uses another flag > MOVEFILE_COPY_ALLOWED effectively allowing renamed files to be on > separate file systems. The renaming in this case is not atomic and I > used this flag only to support current functionality. It is not a bad > idea to disallow such renames which brings it in line with the > behaviour on many unix flavors. This also has the potential to break > code but not silently. I don't quite follow what you're saying here, but I'd be against an operation called "rename" that sometimes was atomic and sometimes wasn't. > Lastly, I found an old discussion about the same topic by this list. > > http://mail.python.org/pipermail/python-dev/2001-May/014957.html > > Even though Guido indicated that he doesn't support API change in this > thread, I am posting again as I did not see any one mention > MoveFileEx() in that thread. Does MoveFileEx solve the atomicity problem that Guido raised in that thread? I don't think it does, so I think the situation is still the same. -Andrew. ___ 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] (no subject)
JOSHUA ABRAHAM wrote: > I was hoping you guys would consider creating function in os.path or > otherwise that would find the full path of a file when given only it's base > name and nothing else.I have been made to understand that this is not > currently possible. Does os.path.abspath() do what you want? If not, what exactly *do* you want? -- Greg ___ 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.rename on windows
On 4/30/07, Andrew Bennetts <[EMAIL PROTECTED]> wrote: > Does MOVEFILE_REPLACE_EXISTING mean the rename over an existing file is > actually > atomic? I cannot find any MSDN docs that say so (and I've seen some that > suggest to me that it probably isn't). Even though MSDN docs do not say it explicitly, I found some discussions claiming that MOVEFILE_REPLACE_EXISTING is atomic. However, after seeing your comment, I did a more thorough search and I too found some references claiming otherwise. As a last resort, I checked cygwin documentation which claims that it's rename() is POSIX.1 compliant. If I am not mistaken, POSIX.1 does require atomicity so I am curious how rename() is implemented there. I checked out the sources and I will try to find more about their implementation. I completely agree that without positive proof of atomicity, there is no point in making this code change. > Also, I assume this cannot replace files that are in use? A simple test shows that it can indeed replace files that are open. Thanks, Raghu ___ 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] (no subject)
On 4/30/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > JOSHUA ABRAHAM wrote: > > I was hoping you guys would consider creating function in os.path or > > otherwise that would find the full path of a file when given only it's base > > name and nothing else.I have been made to understand that this is not > > currently possible. > > Does os.path.abspath() do what you want? > > If not, what exactly *do* you want? probably: def find_in_path(filename): for path in os.environ['PATH'].split(os.pathsep): if os.path.exists(filename): return os.path.abspath(os.path.join(path, filename)) -Mike ___ 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] head crashing (was: Fwd: [Python-checkins] buildbot warnings in x86 mvlgcc trunk)
This is the third time I've seen a crash on 2 different machines. This is the first time I noticed this unexplained crash: http://python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/1983/step-test/0 That was at r54982. I tried to reproduce this: with a non-debug build, with a debug build, with valgrind with both types of build. I could never reproduce it. Valgrind did not report any errors either. Here is the third failure: http://python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/1986/step-test/0 The failure below prints: python: Objects/obmalloc.c:746: PyObject_Malloc: Assertion `bp != ((void *)0)' failed. which probably doesn't really help since the corruption has already occurred. See http://python.org/dev/buildbot/all/x86%20mvlgcc%20trunk/builds/497/step-test/0 Anyone have ideas what might have caused this? n -- -- Forwarded message -- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Apr 30, 2007 11:17 PM Subject: [Python-checkins] buildbot warnings in x86 mvlgcc trunk To: [EMAIL PROTECTED] The Buildbot has detected a new failure of x86 mvlgcc trunk. Full details are available at: http://www.python.org/dev/buildbot/all/x86%2520mvlgcc%2520trunk/builds/497 Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: Build Source Stamp: [branch trunk] HEAD Blamelist: georg.brandl Build had warnings: warnings test Excerpt from the test logfile: make: *** [buildbottest] Aborted (core dumped) sincerely, -The Buildbot ___ Python-checkins mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-checkins ___ 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
