Re: shutil _isindir
David Hoese wrote: > I wasn't really sure where to post this since the python-dev list seems > way too official. I'm wondering/questioning the behavior of > shutil.move. It currently does a check for if the dst is inside the src > directory with a _destinsrc function. This function uses > os.path.abspath to convert the arguments, but I think it should convert > using os.path.realpath. A recent problem I had with this I ended up > asking on stackoverflow: > http://stackoverflow.com/questions/7854608/python-shutil-move-odd- softlinking > > So I was wondering if this sounds like a change that should happen in > the shutil code or should programmers(me) just be more careful. I feel > like it should be in the shutil code since its getting around a checked > case (destination inside source) and it can end up deleting information > when a move was intended. But then again this has been in the standard > lib for a while now, so I'm guessing there are reasons for it...plus it > was a dumb mistake by me. > > So I guess what I'm asking is what are the reasons that _destinsrc uses > abspath instead of realpath? And is there a better place to ask this? > > FYI, I was provided this link to the shutil.py source on SO: > http://hg.python.org/cpython/file/d30482d51c25/Lib/shutil.py#l262 Your suggestion makes sense to me and I don't see any disadvantages. I encourage you to file a bug report on bugs.python.org, preferably with a patch. If there are any problems with the proposed change they can be discussed there. -- http://mail.python.org/mailman/listinfo/python-list
Re: shutil _isindir
On Fri, 21 Oct 2011 22:13:06 -0500, David Hoese wrote: > So I guess what I'm asking is what are the reasons that _destinsrc uses > abspath instead of realpath? And is there a better place to ask this? Probably because abspath goes back to Python 1.5, while realpath is comparatively recent only going back to 2.2, and nobody has thought to change the code in shutil. I recommend you raise a bug/feature request on the bug tracker, preferably with a fix and a test demonstrating the problem. http://bugs.python.org/ -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: revive a generator
On Thursday, October 20, 2011 6:23:50 AM UTC-7, Yingjie Lan wrote: > Hi, > > it seems a generator expression can be used only once: > > >>> g = (x*x for x in range(3)) > >>> for x in g: print x > 0 > 1 > 4 > >>> for x in g: print x #nothing printed > >>> > > Is there any way to revive g here? Revive is the wrong word for what you want. Once an iterator (be it a generator or some other kind of iterator) is done, it's done. What you are asking for is, given a generator, to create a new generator from the same expression/function that created the original generator. This is not reviving, but recreating. I have two objections to this: a major ideological one and a minor practical one. The practical drawback to allowing generators to be recreated is that it forces all generators to carry around a reference to the code object that created it. if random.random() > 5: g = (x*x for x in xrange(3)) else: g = (x+x for x in xrange(3)) for y in g: print x revive(g) # which generator expression was it? # need to carry around a reference to be able to tell for y in g: print x Carrying a reference to a code object in turn carries around any closures used in the generator expression or function, so it can potentially keep a large amount of data alive. Given that the vast majority of generators would never be recreated, this is quite wasteful. My ideological objection is that it forces the programmer to be wary of the effects of recreation. Right now, if someone writes a generator expression, they can rely on the fact that it can only be iterated through once (per time the generator expression is evaluated). But if you allow a downstream user to recreate the generator at will, then the writer will always have to be wary of adverse side-effects if the generator is iterated through twice. So, although I can see it being occasionally useful, I'm going to opine that it is more trouble than it's worth. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
logging: warn() methods and function to be deprecated.
In response to an issue (#13235) raised on the Python bug tracker, I'm going to deprecate the warn() methods in the Logger and LoggerAdapter classes in the stdlib logging package, as well the module-level warn() function. The warn() variants were synonyms for the warning() methods and function, and a holdover from before the time that logging was added to Python.They were not documented; it's probably time to retire them, so I've added a DeprecationWarning to appear in 3.3, and they'll be completely removed in 3.4 (along with the WARN synonym for WARNING). With this change, all the logging levels are adjectives which apply to the logged message: DEBUG, INFO, WARNING, ERROR and CRITICAL. I don't believe the WARN/warn variants were used much, if at all - but this is just a heads up for anyone who might have used them. Regards, Vinay Sajip -- http://mail.python.org/mailman/listinfo/python-list
shutil _isindir
I was about to submit a bug report, but while testing I have figured out that my specific problem has been solved in Python 2.7 (server that I was using had 2.6 on it). You can see the differences here: 2.6: http://hg.python.org/cpython/file/b9a95ce2692c/Lib/shutil.py 2.7: http://hg.python.org/cpython/file/d30482d51c25/Lib/shutil.py You'll notice that in move(), there is now a check for the same file, which if they're not the same file you don't get unexpected deleted files. If you still think I should submit a bug report let me know and provide me with the test case...or just submit the bug yourself. -Dave P.S. Sorry for the original poor subject line, was a place holder that I forgot to change. On 10/22/2011 5:00 AM, [email protected] wrote: Subject: Re: shutil _isindir From: Steven D'Aprano Date: 10/22/2011 4:03 AM To: [email protected] On Fri, 21 Oct 2011 22:13:06 -0500, David Hoese wrote: > So I guess what I'm asking is what are the reasons that _destinsrc uses > abspath instead of realpath? And is there a better place to ask this? Probably because abspath goes back to Python 1.5, while realpath is comparatively recent only going back to 2.2, and nobody has thought to change the code in shutil. I recommend you raise a bug/feature request on the bug tracker, preferably with a fix and a test demonstrating the problem. http://bugs.python.org/ -- http://mail.python.org/mailman/listinfo/python-list
Re: compare range objects
On Sat, 22 Oct 2011 05:32:44 +, Steven D'Aprano wrote: > On Fri, 21 Oct 2011 16:42:16 -0700, SigmundV wrote: > >> On Oct 21, 2:55 am, Yingjie Lan wrote: >>> >>> In simulation, one can use range objects to denote a discrete domain, >>> and domain comparison could be very useful. Not just equality, but >>> also things like if one domain is contained in another. [...] > If you need a data type to store large numeric domains, whether discrete > or continuous, a tree of intervals storing the lower and upper bounds is > probably the right solution. And purely by coincidence, I came across this today: http://docs.pylandro.com/pylandro-collections-range/0.1/tutorial.html I haven't used the library yet, but it looks impressive. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: help
On Oct 8, 2:51 pm, X1 wrote: easy_install does not exist on Fedora. That's a pure lie. mitmanek:~ $ sudo repoquery -qf /usr/bin/easy_install python-setuptools-0:0.6.10-3.el6.noarch mitmanek:~ $ Matěj -- http://mail.python.org/mailman/listinfo/python-list
Re: help
On Sat, 22 Oct 2011 15:16:47 +0200, Matej Cepl wrote: > On Oct 8, 2:51 pm, X1 wrote: >> >> easy_install does not exist on Fedora. > > That's a pure lie. Rather than assume malice, we should give X1 the benefit of the doubt and assume he genuinely believed what he wrote but was merely mistaken. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: compare range objects
On Oct 22, 6:32 am, Steven D'Aprano wrote: > > Sure. But the downside of sets is that, like lists, they are not lazy, Thank you for pointing this out. I agree that it's not a viable alternative for large domains. Storing the bounds and the resolution should be enough. /Sigmund -- http://mail.python.org/mailman/listinfo/python-list
Books to lean Python 3 Web Programming?
Can anyone recommend a good book to learn the web programming aspects of Python 3? -- http://mail.python.org/mailman/listinfo/python-list
How to isolate a constant?
Say this: class tester(): _someList = [0, 1] def __call__(self): someList = self._someList someList += "X" return someList test = tester() But guess what, every call adds to the variable that I am trying to copy each time: test() > [0, 1, 'X'] test() > [0, 1, 'X', 'X'] Can someone explain this behavior? And how to prevent a classwide constant from ever getting changed? -- Gnarlie -- http://mail.python.org/mailman/listinfo/python-list
Re: How to isolate a constant?
On Sat, Oct 22, 2011 at 5:26 PM, Gnarlodious wrote: > Say this: > > class tester(): Style note: either have it explicitly subclass `object`, or don't include the parens at all. Empty parens for the superclasses is just weird. > _someList = [0, 1] > def __call__(self): > someList = self._someList > someList += "X" > return someList > > test = tester() > > But guess what, every call adds to the variable that I am trying to > copy each time: > test() >> [0, 1, 'X'] > test() >> [0, 1, 'X', 'X'] > > > Can someone explain this behavior? The line `someList = self._someList` does NOT copy the list. It make `someList` point to the same existing list object. Hence, modifications to that object from either variable will affect the other. Similarly, `someList += "X"` modifies someList *in-place*; it does not produce a new list object. The upshot is that you're just modifying and returning references to *the same list* repeatedly, never producing a new list object. > And how to prevent a classwide > constant from ever getting changed? Python doesn't have any language-enforced notion of constants. So, short of writing/using a library to try and enforce such a notion, you're out of luck. You could use an immutable datatype (e.g. a tuple) instead of a mutable one (e.g. a list) as some level of safeguard though. Cheers, Chris -- http://rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: How to isolate a constant?
On 23/10/2011 01:26, Gnarlodious wrote: Say this: class tester(): _someList = [0, 1] def __call__(self): someList = self._someList someList += "X" return someList test = tester() But guess what, every call adds to the variable that I am trying to copy each time: test() [0, 1, 'X'] test() [0, 1, 'X', 'X'] Can someone explain this behavior? And how to prevent a classwide constant from ever getting changed? '_someList' is part of the class itself. This: someList = self._someList just creates a new _reference to the list and this: someList += "X" appends the items of the sequence "X" to the list. Note that a string is also a sequence of characters, so: >>> x = [] >>> x += "XY" >>> x ['X', 'Y'] Python will copy something only when you tell it to copy. A simple way of copying a list is to slice it: someList = self._someList[:] -- http://mail.python.org/mailman/listinfo/python-list
Re: How to isolate a constant?
On Oct 22, 6:41 pm, Chris Rebert wrote: > The line `someList = self._someList` does NOT copy the list. It make > `someList` point to the same existing list object. Thanks for all those explanations, I've already fixed it with a tuple. Which is more reliable anyway. -- Gnarlie -- http://mail.python.org/mailman/listinfo/python-list
Exception Handling (C - extending python)
Hi all, Where does PyExc_TypeError (and alike) points to? I can see its declaration - PyAPI_DATA(PyObject *) PyExc_TypeError; - in pyerrors.h but I cannot figure out what it is its value, where it is initialized. Any help is greatly appreciated. Lee -- http://mail.python.org/mailman/listinfo/python-list
Re: compare range objects
On Oct 22, 10:51 pm, SigmundV wrote: > On Oct 22, 6:32 am, Steven D'Aprano > [email protected]> wrote: > > > Sure. But the downside of sets is that, like lists, they are not lazy, > > Thank you for pointing this out. I agree that it's not a viable > alternative for large domains. Storing the bounds and the resolution > should be enough. > > /Sigmund This kind of question is a nontrivial research issue -- dealt with for example in the polyhedral language alpha: http://www.irisa.fr/cosi/Rajopadhye/dag-talk.ps -- http://mail.python.org/mailman/listinfo/python-list
Re: How to isolate a constant?
Thank you for the good trick for a static class owned property. Someone might object this but this is really useful. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to isolate a constant?
On Sat, 22 Oct 2011 18:01:52 -0700, Gnarlodious wrote: > On Oct 22, 6:41 pm, Chris Rebert wrote: > >> The line `someList = self._someList` does NOT copy the list. It make >> `someList` point to the same existing list object. > Thanks for all those explanations, I've already fixed it with a tuple. > Which is more reliable anyway. No, tuples are not "more reliable" than lists. Don't make the mistake of confusing your inexperience and lack of understanding about Python's object model for "lists are unreliable". They are completely reliable. You just have to learn how they work, and not make invalid assumptions about how they work. You wouldn't say "Nails are more reliable than screws, because I hammered a screw into a plaster wall and it just fell out." Of course it fell out: you used it incorrectly for what you needed. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
