Re: [Python-Dev] == on object tests identity in 3.x

Steven D'Aprano writes: > I don't think so. Floating point == represents *numeric* equality, There is no such thing as floating point == in Python. You can apply == to two floating point numbers, but == (at the language level) handles any two numbers, as well as pairs of things that aren't numb

Re: [Python-Dev] == on object tests identity in 3.x

On Jul 7, 2014, at 4:37 PM, Andreas Maier wrote: > I do not really buy into the arguments that try to show how identity and > value are somehow the same. They are not, not even in Python. > > The argument I can absolutely buy into is that the implementation cannot be > changed within a major

Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal

On 07/08/2014 06:08 PM, Ben Hoyt wrote: Just like an attribute does not imply a system call, having a method named 'is_dir' /does/ imply a system call, and not having one can be just as misleading. Why does a method imply a system call? os.path.join() and str.lower() don't make system calls. I

Re: [Python-Dev] == on object tests identity in 3.x

On Tue, Jul 08, 2014 at 06:33:31PM +0100, MRAB wrote: > The log of a negative number is a complex number. Only in complex arithmetic. In real arithmetic, the log of a negative number isn't a number at all. -- Steven ___ Python-Dev mailing list Python

Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal

> I did better than that -- I read the whole thing! ;) Thanks. :-) > -1 on the PEP's implementation. > > Just like an attribute does not imply a system call, having a > method named 'is_dir' /does/ imply a system call, and not > having one can be just as misleading. Why does a method imply a sy

Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal

On 07/08/2014 01:22 PM, Ethan Furman wrote: I think caching the attributes for DirEntry is fine, but let's do it as a snapshot of that moment in time, not name now, and attributes in 30 minutes when we finally get to you because we had a lot of processing/files ahead of you (you being a DirEnt

Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal

On 07/08/2014 12:34 PM, Ben Hoyt wrote: Better to just have the attributes be None if they were not fetched. None is better than hasattr anyway, at least in the respect of not having to catch exceptions to function properly. The thing is, is_dir() and lstat() are not attributes (for a good re

Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal

>> I think you're misunderstanding is_dir() and is_file(), as these don't >> actually call os.stat(). All DirEntry methods either call nothing or >> os.lstat() to get the stat info on the entry itself (not the >> destination of the symlink). > > > Oh. Extract of your PEP: "is_dir(): like os.path.is

Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal

Le mardi 8 juillet 2014, Ben Hoyt a écrit : > > > It is not clear to me which methods share the cache. > > > > On UNIX, is_dir() and is_file() call os.stat(); whereas lstat() and > > is_symlink() call os.lstat(). > > > > If os.stat() says that the file is not a symlink, I guess that you can > > u

Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal

> Better to just have the attributes be None if they were not fetched. None > is better than hasattr anyway, at least in the respect of not having to > catch exceptions to function properly. The thing is, is_dir() and lstat() are not attributes (for a good reason). Please read the relevant "Rejec

Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal

On 07/08/2014 11:05 AM, Ben Hoyt wrote: Only exposing what the OS provides for free will make the API too difficult to use in the common case. But is there a nice way to expand the API that will allow the user who is trying to avoid extra expense know what information is already available? Even

Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal

> Only exposing what the OS provides for free will make the API too difficult > to use in the common case. But is there a nice way to expand the API that > will allow the user who is trying to avoid extra expense know what > information is already available? > > Even if the initial version doesn't

Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal

> I remember a pending question on python-dev: > > - Martin von Loewis asked if the scandir generator would have send() > and close() methods as any Python generator. I didn't see a reply on > the mailing (nor in the PEP). Good call. Looks like you're referring to this message: https://mail.python

Re: [Python-Dev] == on object tests identity in 3.x

On 2014-07-08 17:57, Steven D'Aprano wrote: [snip] In particular, reflexivity for NANs was dropped for a number of reasons, some stronger than others: - One of the weaker reasons for NAN non-reflexivity is that it preserved the identity x == y <=> x - y == 0. Although that is the cornerstone

Re: [Python-Dev] == on object tests identity in 3.x

On Wed, Jul 9, 2014 at 3:00 AM, Steven D'Aprano wrote: > On Tue, Jul 08, 2014 at 04:58:33PM +0200, Anders J. Munch wrote: > >> For two NaNs computed differently to compare equal is no worse than 2+2 >> comparing equal to 1+3. You're comparing values, not their history. > > a = -23 > b = -42 > if

Re: [Python-Dev] == on object tests identity in 3.x

On Tue, Jul 08, 2014 at 04:58:33PM +0200, Anders J. Munch wrote: > For two NaNs computed differently to compare equal is no worse than 2+2 > comparing equal to 1+3. You're comparing values, not their history. a = -23 b = -42 if log(a) == log(b): print "a == b" -- Steven _

Re: [Python-Dev] == on object tests identity in 3.x

On Tue, Jul 08, 2014 at 04:53:50PM +0900, Stephen J. Turnbull wrote: > Chris Angelico writes: > > > The reason NaN isn't equal to itself is because there are X bit > > patterns representing NaN, but an infinite number of possible > > non-numbers that could result from a calculation. > > I unde

Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal

On 7/8/2014 9:52 AM, Ben Hoyt wrote: DirEntry fields being "static" attribute-only objects - In `this July 2014 python-dev message `_, Paul Moore suggested a solution that was

Re: [Python-Dev] == on object tests identity in 3.x

Chris Angelico wrote: This is off-topic for this thread, but still... The trouble is that your "arguably just as wrong" is an indistinguishable case. If you don't want two different calculations' NaNs to *ever* compare equal, the only solution is to have all NaNs compare unequal For two NaNs co

Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal

Hi, 2014-07-08 15:52 GMT+02:00 Ben Hoyt : > After some very good python-dev feedback on my first version of PEP > 471, I've updated the PEP to clarify a few things and added various > "Rejected ideas" subsections. Here's a link to the new version (I've > also copied the full text below): Thanks,

Re: [Python-Dev] buildbot.python.org down again?

May the true owner of buildbot.python.org stand up! (But I do think there may well not be anyone who feels they own it. And that's a problem for its long term viability.) Generally speaking, as an organization we should set up a process for managing ownership of *all* infrastructure in a uniform

[Python-Dev] Updates to PEP 471, the os.scandir() proposal

Hi folks, After some very good python-dev feedback on my first version of PEP 471, I've updated the PEP to clarify a few things and added various "Rejected ideas" subsections. Here's a link to the new version (I've also copied the full text below): http://legacy.python.org/dev/peps/pep-0471/ -- n

Re: [Python-Dev] == on object tests identity in 3.x

On Tue, Jul 8, 2014 at 5:53 PM, Stephen J. Turnbull wrote: > But you're missing at least two alternatives that > involve raising on some calculations involving NaN, as well as the > fact that forcing inequality of two NaNs produced by equivalent > calculations is arguably just as wrong as allowing

Re: [Python-Dev] == on object tests identity in 3.x

Chris Angelico writes: > The reason NaN isn't equal to itself is because there are X bit > patterns representing NaN, but an infinite number of possible > non-numbers that could result from a calculation. I understand that. But you're missing at least two alternatives that involve raising on

Re: [Python-Dev] buildbot.python.org down again?

On Jul 8, 2014, at 12:58 AM, Nick Coghlan wrote: > > On 7 Jul 2014 10:47, "Guido van Rossum" wrote: > > > > It would still be nice to know who "the appropriate persons" are. Too much > > of our infrastructure seems to be maintained by house elves or the ITA. > > I volunteered to be the board

Re: [Python-Dev] == on object tests identity in 3.x

On Tue, Jul 8, 2014 at 5:01 PM, Stephen J. Turnbull wrote: > I agree with Steven d'A that this rule is not part of the language > definition and shouldn't be, but it's the rule of thumb I find hardest > to imagine *ever* wanting to break in my own code (although I sort of > understand why the IEEE

Re: [Python-Dev] == on object tests identity in 3.x

Rob Cliffe writes: > > Why? What value (pun intended) is there in adding an explicit statement > > of value to every single class? > It troubles me a bit that "value" seems to be a fuzzy concept - it has > an obvious meaning for some types (int, float, list etc.) but for > callable objects