Good points. Well, this is pretty academic at this point - I don't think
anyone would seriously choose to obsolete __ne__, regardless of whether it
is absolutely necessary or not.
On Mon, Jan 8, 2018 at 4:51 PM, Thomas Jollans wrote:
> On 2018-01-08 15:25, Oren Ben-Kiki wrote:
> >
Ugh, right, for NaN you can have (x < y) != (x >= y) - both would be false
if one of x and y is a NaN.
But __ne__ is still useless ;-)
On Mon, Jan 8, 2018 at 4:36 PM, Thomas Nyberg wrote:
> On 01/08/2018 03:25 PM, Oren Ben-Kiki wrote:
> > I am hard pressed to think of a case
I don't see a case in IEEE where (x == y) != !(x != y).
There _is_ a case where (x != x) is true (when x is NaN), but for such an
x, (x == x) will be false.
I am hard pressed to think of a case where __ne__ is actually useful.
That said, while it is true you only need one of (__eq__, __ne__), you
The first line says "The major reason is history." :-) But it also gives an
explanation: providing functionality for types that, at the time, didn't
have methods.
On Mon, Oct 16, 2017 at 8:33 PM, Lele Gaifax wrote:
> Oren Ben-Kiki writes:
>
> > So I still think it
erence rather than a pure technical
consideration. But that's all second-guessing, anyway. You'd have to ask
Guido what his reasoning was...
On Mon, Oct 16, 2017 at 7:36 PM, Ned Batchelder
wrote:
> On 10/16/17 12:16 PM, Oren Ben-Kiki wrote:
>
>> That doesn't explain wh
That doesn't explain why `del` isn't a method though. Intuitively,
`my_dict.delete(some_key)` makes sense as a method. Of course, you could
also make the same case for `len` being a method... and personally I think
it would have been cleaner that way in both cases. But it is a minor issue,
if at al
Yes, it sort-of makes sense... I'll basically re-post my question there.
Thanks for the link!
Oren.
On Sun, Jul 16, 2017 at 4:29 PM, Peter Otten <__pete...@web.de> wrote:
> Oren Ben-Kiki wrote:
>
> > TL;DR: We need improved documentation of the way meta-classes behave
TL;DR: We need improved documentation of the way meta-classes behave for
generic classes, and possibly reconsider the way "__setattr__" and
"__getattribute__" behave for such classes.
I am using meta-programming pretty heavily in one of my projects.
It took me a while to figure out the dance betwe
You _can_ just extend a JSON file without loading it, but it will not be
"fun".
Say the JSON file contains a top-level array. The final significant
character in it would be a ']'. So, you can read just a reasonably-sized
block from the end of the file, find the location of the final ']',
overwrite
On Mon, Apr 3, 2017 at 7:43 PM, Chris Angelico wrote:
> Here's a counter-example that supports the current behaviour:
>
> >>> from enum import IntFlag, auto
> >>> class Spam(IntFlag):
> ... FOO = auto()
> ... BAR = auto()
> ... FOOBAR = FOO | BAR
> ... SPAM = auto()
> ... HAM
On Mon, Apr 3, 2017 at 11:03 AM, Ethan Furman wrote:
> Python code is executed top-down. First FOO, then BAR, then BAZ. It is
> not saved up and executed later in random order. Or, put another way, the
> value was appropriate when it was chosen -- it is not the fault of auto()
> that the user
it to the
documentation, we should instead remove this arbitrary restriction from the
implementation, and only modify the documentation to clarify this
restriction is gone.
Oren.
On Mon, Apr 3, 2017 at 8:38 AM, Chris Angelico wrote:
> On Mon, Apr 3, 2017 at 2:49 PM, Oren Ben-Kiki
> wrote:
&
` will invoke `_generate_next_value_` with the
concatenation of both lists (following values first, preceding values
second), to maximize compatibility with existing code.
Thanks,
Oren Ben-Kiki
--
https://mail.python.org/mailman/listinfo/python-list
13 matches
Mail list logo
