Re: Spectre/Meltdown bug affecting Python ?

[Julien Salort]

Le 06/01/2018 à 21:49, J.O. Aho a écrit :


Not just Linux, but all other OS:es, Microsoft and Apple been patching
in secret as they have a closed source approach, but ms-windows needs at
least one more patch before it can breath out, which will be released on
Tuesday.


As a matter of fact, Apple kernel, xnu, is not closed source,
https://opensource.apple.com/source/xnu/

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python Inheritance Terminology

[Irv Kalb]

Thanks for the confirmation, and for the link.

Irv


> On Jan 5, 2018, at 4:32 PM, Ben Finney  wrote:
> 
> Irv Kalb  writes:
> 
>> I'm doing some writing for an upcoming course on OOP using Python.  
> 
> Welcome, and congratulations for using Python in this work.
> 
>> I'd like to know if there are "official" or even standard terms that
>> are used to describe a class that is inherited from, and the class
>> that is doing the inheriting. From my reading (especially the PSF
>> docs.python.org ), it looks like the terms
>> would be "base class" and "subclass".
> 
> Standard (“official”) terms are most likely to be had from the language
> reference http://docs.python.org/3/reference/>. I would recommend
> the glossary http://docs.python.org/3/glossary.html>, but with the
> caveat that many flaws have been found in recent years.
> 
>> However, in books about Python and other languages, I have also seen the 
>> terms:
>> 
>> base class & derived class
>> parent class & child class
>> superclass & subclass
> 
> The only term I take issue with there is “superclass”. In a
> multiple-inheritance system, such as provided by Python, the superclass
> is *not* necessarily the base class. See this article from 2011
> https://rhettinger.wordpress.com/2011/05/26/super-considered-super/>.
> 
>> So, are base class & subclass the proper terms?
> 
> In my opinion you will be correct to use those terms. Which is not to
> say that other terms aren't also good.
> 
> -- 
> \“The greatest tragedy in mankind's entire history may be the |
>  `\   hijacking of morality by religion.” —Arthur C. Clarke, 1991 |
> _o__)  |
> Ben Finney
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Why does __ne__ exist?

[Chris Angelico]

When you create a Python class, you can create dunder methods to
define how your objects respond to the standard operators. With
comparison operators, Python will happily switch the operands around
to find a method to call:

>>> class Spam():
... def __lt__(self, other):
... print("%s is less than %s" % (self, other))
... return True
...
>>> Spam() < 2
<__main__.Spam object at 0x7fb7557b1fd0> is less than 2
True
>>> 3 > Spam()
<__main__.Spam object at 0x7fb7557b1fd0> is less than 3
True
>>> 4 > Spam() < 5
<__main__.Spam object at 0x7fb7557b1fd0> is less than 4
<__main__.Spam object at 0x7fb7557b1fd0> is less than 5
True

But Python will not automatically assume the converse:

>>> Spam() >= 6
Traceback (most recent call last):
  File "", line 1, in 
TypeError: '>=' not supported between instances of 'Spam' and 'int'
>>> Spam() > 7
Traceback (most recent call last):
  File "", line 1, in 
TypeError: '>' not supported between instances of 'Spam' and 'int'

This is good. This is correct. For inequalities, you can't assume that
>= is the exact opposite of < (for example, sets don't behave like
numbers, so "x <= y" is very different from )
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Chris Angelico]

Whoops, premature send. Picking up from the last paragraph.

This is good. This is correct. For inequalities, you can't assume that
>= is the exact opposite of < or the combination of < and == (for
example, sets don't behave like numbers, so "x <= y" is very different
from "x < y or x == y"). But the one that confuses me is != or __ne__.
If you don't create it, you get default behaviour:

>>> class Ham:
... def __eq__(self, other):
... print("%s equals %s" % (self, other))
... return True
...
>>> Ham() == 1
<__main__.Ham object at 0x7fb7557c0278> equals 1
True
>>> 2 == Ham()
<__main__.Ham object at 0x7fb7557c0278> equals 2
True
>>> Ham() != 3
<__main__.Ham object at 0x7fb7557c0278> equals 3
False
>>> 4 != Ham()
<__main__.Ham object at 0x7fb7557c0278> equals 4
False
>>> x = Ham()
>>> x == x
<__main__.Ham object at 0x7fb7557b80f0> equals <__main__.Ham object at
0x7fb7557b80f0>
True
>>> x != x
<__main__.Ham object at 0x7fb7557b80f0> equals <__main__.Ham object at
0x7fb7557b80f0>
False

Under what circumstances would you want "x != y" to be different from
"not (x == y)" ? How would this make for sane behaviour? Even when
other things go weird with equality checks, that basic parallel is
always maintained:

>>> z = float("nan")
>>> z == z
False
>>> z != z
True

Python gives us a "not in" operator that uses __contains__ and then
negates the result. There is no way for "x not in y" to be anything
different from "not (x in y)", as evidenced by the peephole optimizer:

>>> dis.dis("x not in y")
  1   0 LOAD_NAME0 (x)
  2 LOAD_NAME1 (y)
  4 COMPARE_OP   7 (not in)
  6 RETURN_VALUE
>>> dis.dis("not (x in y)")
  1   0 LOAD_NAME0 (x)
  2 LOAD_NAME1 (y)
  4 COMPARE_OP   7 (not in)
  6 RETURN_VALUE

So why isn't != done the same way? Is it historical?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Thomas Jollans]

On 07/01/18 20:55, Chris Angelico wrote:
> Under what circumstances would you want "x != y" to be different from
> "not (x == y)" ?

In numpy, __eq__ and __ne__ do not, in general, return bools.

Python 3.6.3 (default, Oct  3 2017, 21:45:48)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> a = np.array([1,2,3,4])
>>> b = np.array([0,2,0,4])
>>> a == b
array([False,  True, False,  True], dtype=bool)
>>> a != b
array([ True, False,  True, False], dtype=bool)
>>> not (a == b)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: The truth value of an array with more than one element is
ambiguous. Use a.any() or a.all()
>>> ~(a == b)
array([ True, False,  True, False], dtype=bool)
>>>

I couldn't tell you why this was originally allowed, but it does turn
out to be strangely useful. (As far as the numpy API is concerned, it
would be even nicer if 'not' could be overridden, IMHO)

Cheers
Thomas
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Chris Angelico]

On Mon, Jan 8, 2018 at 7:13 AM, Thomas Jollans  wrote:
> On 07/01/18 20:55, Chris Angelico wrote:
>> Under what circumstances would you want "x != y" to be different from
>> "not (x == y)" ?
>
> In numpy, __eq__ and __ne__ do not, in general, return bools.
>
 a = np.array([1,2,3,4])
 b = np.array([0,2,0,4])
 a == b
> array([False,  True, False,  True], dtype=bool)
 a != b
> array([ True, False,  True, False], dtype=bool)

Thanks, that's the kind of example I was looking for. Though numpy
doesn't drive the core language development much, so the obvious next
question is: was this why __ne__ was implemented, or was there some
other reason? This example shows how it can be useful, but not why it
exists.

 not (a == b)
> Traceback (most recent call last):
>   File "", line 1, in 
> ValueError: The truth value of an array with more than one element is
> ambiguous. Use a.any() or a.all()

Which means that this construct is still never going to come up in good code.

 ~(a == b)
> array([ True, False,  True, False], dtype=bool)

>
> I couldn't tell you why this was originally allowed, but it does turn
> out to be strangely useful. (As far as the numpy API is concerned, it
> would be even nicer if 'not' could be overridden, IMHO)

I'm glad 'not' can't be overridden; it'd be too hard to reason about a
piece of code if even the basic boolean operations could change. If
you want overridables, you have &|~ for the bitwise operators (which
is how numpy does things).

Has numpy ever asked for a "not in" dunder method (__not_contained__
or something)? It's a strange anomaly that "not (x in y)" can be
perfectly safely optimized to "x not in y", yet basic equality has to
have separate handling. The default handling does mean that you can
mostly ignore __ne__ and expect things to work, but if you subclass
something that has both, it'll break:

class Foo:
def __eq__(self, other):
print("Foo: %s == %s" % (self, other))
return True
def __ne__(self, other):
print("Foo: %s != %s" % (self, other))
return False

class Bar(Foo):
def __eq__(self, other):
print("Bar: %s == %s" % (self, other))
return False

>>> Bar() == 1
Bar: <__main__.Bar object at 0x7f40ebf3a128> == 1
False
>>> Bar() != 1
Foo: <__main__.Bar object at 0x7f40ebf3a128> != 1
False

Obviously this trivial example looks stupid, but imagine if the
equality check in the subclass USUALLY gives the same result as the
superclass, but differs in rare situations. Maybe you create a "bag"
class that functions a lot like collections.Counter but ignores zeroes
when comparing:

>>> class Bag(collections.Counter):
... def __eq__(self, other):
... # Disregard any zero entries when comparing to another Bag
... return {k:c for k,c in self.items() if c} == {k:c for k,c
in other.items() if c}
...
>>> b1 = Bag("aaabccdd")
>>> b2 = Bag("aaabccddq")
>>> b2["q"] -= 1
>>> b1 == b2
True
>>> b1 != b2
True
>>> dict(b1) == dict(b2)
False
>>> dict(b1) != dict(b2)
True

The behaviour of __eq__ is normal and sane. But since there's no
__ne__, the converse comparison falls back on dict.__ne__, not on
object.__ne__.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[bartc]

On 07/01/2018 19:55, Chris Angelico wrote:


Under what circumstances would you want "x != y" to be different from
"not (x == y)" ? How would this make for sane behaviour?


Presumably so that any behaviour any be programmed when overriding these 
operators.


Maybe someone wants to do weird stuff with == that doesn't yield a true 
or false result, so that you can't just reverse it for !=.


For example (perhaps this is similar to what was suggested in another post):

 (10,20,30) == (10,20,40)   yields  (1,1,0)
 (10,20,30) != (10,20,40)   yields  (0,0,1)

Although here, you would probably define 'not' so that 'not (1,1,0)' 
does actually yield '(0,0,1)'.


So clearly I need a weirder example.


 Even when

other things go weird with equality checks, that basic parallel is
always maintained:


z = float("nan")
z == z

False

z != z

True

Python gives us a "not in" operator that uses __contains__ and then
negates the result. There is no way for "x not in y" to be anything
different from "not (x in y)", as evidenced by the peephole optimizer:


dis.dis("x not in y")

   1   0 LOAD_NAME0 (x)
   2 LOAD_NAME1 (y)
   4 COMPARE_OP   7 (not in)
   6 RETURN_VALUE

dis.dis("not (x in y)")

   1   0 LOAD_NAME0 (x)
   2 LOAD_NAME1 (y)
   4 COMPARE_OP   7 (not in)


I get '4 COMPARE OP6 (in)' here. So they are distinct ops. 'not in' 
doesn't just call 'in', then apply 'not'. Not here anyway.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Christian Gollwitzer]

Am 05.01.18 um 22:15 schrieb Michael Torrie:

Please, no!  We don't need emoji in this group. Fortunately the vast
majority of posters use plain text (as is the etiquette) and so we don't
have to worry about that kind of nonsense.


It's not needed, but shouldn't pose any big problems with modern 
software? I'm using Thunderbird over NNTP, and this shows up as graphics 
to me:


🐍 💻

(a snake and a computer) Unless this message is blocked at the NNTP-List 
boundary, it should show the same on any recent mail reader.


Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Chris Angelico]

On Mon, Jan 8, 2018 at 7:41 AM, bartc  wrote:
> On 07/01/2018 19:55, Chris Angelico wrote:
>
>> Under what circumstances would you want "x != y" to be different from
>> "not (x == y)" ? How would this make for sane behaviour?
>
>
> Presumably so that any behaviour any be programmed when overriding these
> operators.
>
> Maybe someone wants to do weird stuff with == that doesn't yield a true or
> false result, so that you can't just reverse it for !=.
>
> For example (perhaps this is similar to what was suggested in another post):
>
>  (10,20,30) == (10,20,40)   yields  (1,1,0)
>  (10,20,30) != (10,20,40)   yields  (0,0,1)
>
> Although here, you would probably define 'not' so that 'not (1,1,0)' does
> actually yield '(0,0,1)'.
>
> So clearly I need a weirder example.

With tuples, I absolutely agree with Python's current behaviour: the
tuples you give are simply not equal. A tuple doesn't represent a
vector; it represents a specific collection of values, like the
coordinates of a point in 2D or 3D space. If you look at the two
points (1,5) and (3,5), they aren't "half equal". They're different
points, at different locations. They happen to have the same
elevation, but that's just a point of curiosity.

>  Even when
>>
>> other things go weird with equality checks, that basic parallel is
>> always maintained:
>>
> z = float("nan")
> z == z
>>
>> False
>
> z != z
>>
>> True
>>
>> Python gives us a "not in" operator that uses __contains__ and then
>> negates the result. There is no way for "x not in y" to be anything
>> different from "not (x in y)", as evidenced by the peephole optimizer:
>>
> dis.dis("x not in y")
>>
>>1   0 LOAD_NAME0 (x)
>>2 LOAD_NAME1 (y)
>>4 COMPARE_OP   7 (not in)
>>6 RETURN_VALUE
>
> dis.dis("not (x in y)")
>>
>>1   0 LOAD_NAME0 (x)
>>2 LOAD_NAME1 (y)
>>4 COMPARE_OP   7 (not in)
>
>
> I get '4 COMPARE OP6 (in)' here. So they are distinct ops. 'not in'
> doesn't just call 'in', then apply 'not'. Not here anyway.
>

The fact that your Python doesn't optimize it is actually beside the
point; if _any_ Python interpreter can optimize this down, it must be
semantically identical. I did this on CPython 3.7, fwiw, but it
doesn't really matter.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Gene Heskett]

On Sunday 07 January 2018 16:22:57 Christian Gollwitzer wrote:

> Am 05.01.18 um 22:15 schrieb Michael Torrie:
> > Please, no!  We don't need emoji in this group. Fortunately the vast
> > majority of posters use plain text (as is the etiquette) and so we
> > don't have to worry about that kind of nonsense.
>
> It's not needed, but shouldn't pose any big problems with modern
> software? I'm using Thunderbird over NNTP, and this shows up as
> graphics to me:
>
> 🐍 💻
>
But here its broken and I am looking at two pairs of vertical boxes 
because it is not properly mime'd. If you use chars or gliphs from a 
non-default charset, it needs to demarcated with a mime-boundary marker 
followed by the new type definition. Your email/news agent did not do 
that. 

> (a snake and a computer) Unless this message is blocked at the
> NNTP-List boundary, it should show the same on any recent mail reader.
>
>  Christian


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[bartc]

On 07/01/2018 21:51, Chris Angelico wrote:

On Mon, Jan 8, 2018 at 7:41 AM, bartc  wrote:



Maybe someone wants to do weird stuff with == that doesn't yield a true or
false result, so that you can't just reverse it for !=.

For example (perhaps this is similar to what was suggested in another post):

  (10,20,30) == (10,20,40)   yields  (1,1,0)
  (10,20,30) != (10,20,40)   yields  (0,0,1)



With tuples, I absolutely agree with Python's current behaviour: the
tuples you give are simply not equal. A tuple doesn't represent a
vector; it represents a specific collection of values, like the
coordinates of a point in 2D or 3D space. If you look at the two
points (1,5) and (3,5), they aren't "half equal". They're different
points, at different locations. They happen to have the same
elevation, but that's just a point of curiosity.


My (10,20,30) were meant to represent some user-defined type, not an 
ordinary tuple. And someone might intend that == operates on two 
instances of that type as thought they were vectors. Or any other kind 
of behaviour as I said.


But not necessarily some logical inverse of !=.


dis.dis("not (x in y)")


1   0 LOAD_NAME0 (x)
2 LOAD_NAME1 (y)
4 COMPARE_OP   7 (not in)



I get '4 COMPARE OP6 (in)' here. So they are distinct ops. 'not in'
doesn't just call 'in', then apply 'not'. Not here anyway.



The fact that your Python doesn't optimize it is actually beside the
point; if _any_ Python interpreter can optimize this down, it must be
semantically identical.


Actually I didn't see the 'not' on the outside of the brackets. I 
thought the two expressions were 'not in' and 'in' and that you might 
have transcribed the '7 (not in)' part wrongly.


But this reduction isn't necessarily an optimisation. It might just be a 
syntactical transformation from 'not (a in b)' to '(a not in b)'


The disassembly for 'in' and 'not in' suggests that these are two 
independent operators, which could indeed have behaviours that are not 
complements of each other.


On the other hand, when you /did/ want to evaluate 'in' followed by 
'not', then you want:


   not (a in b)# compare using 'not in'

to do the same thing as:

   temp = a in b   # compare using 'in'
   not temp# apply unary not

Then there might not be the freedom to have in/not in have independent 
behaviours.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Random832]

On Sun, Jan 7, 2018, at 17:27, Gene Heskett wrote:
> >
> > 🐍 💻
> >
> But here its broken and I am looking at two pairs of vertical boxes 
> because it is not properly mime'd. If you use chars or gliphs from a 
> non-default charset, it needs to demarcated with a mime-boundary marker 
> followed by the new type definition. Your email/news agent did not do 
> that. 

UTF-8 is the default character set, and anyway his message does have a 
content-type of 'text/plain; charset="utf-8"; Format="flowed"'. Your 
environment not having font support and/or support for non-BMP characters is 
not a deficiency in the message.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Chris Angelico]

On Mon, Jan 8, 2018 at 9:27 AM, Gene Heskett  wrote:
> On Sunday 07 January 2018 16:22:57 Christian Gollwitzer wrote:
>
>> Am 05.01.18 um 22:15 schrieb Michael Torrie:
>> > Please, no!  We don't need emoji in this group. Fortunately the vast
>> > majority of posters use plain text (as is the etiquette) and so we
>> > don't have to worry about that kind of nonsense.
>>
>> It's not needed, but shouldn't pose any big problems with modern
>> software? I'm using Thunderbird over NNTP, and this shows up as
>> graphics to me:
>>
>> 🐍 💻
>>
> But here its broken and I am looking at two pairs of vertical boxes
> because it is not properly mime'd. If you use chars or gliphs from a
> non-default charset, it needs to demarcated with a mime-boundary marker
> followed by the new type definition. Your email/news agent did not do
> that.
>

Non-default charset?

Content-Type: text/plain; charset="utf-8"; Format="flowed"

I'm pretty sure UTF-8 is a very default charset. Had no problems at
all vieweing the original email.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Richard Damon]

On 1/7/18 5:27 PM, Gene Heskett wrote:

On Sunday 07 January 2018 16:22:57 Christian Gollwitzer wrote:


Am 05.01.18 um 22:15 schrieb Michael Torrie:

Please, no!  We don't need emoji in this group. Fortunately the vast
majority of posters use plain text (as is the etiquette) and so we
don't have to worry about that kind of nonsense.


It's not needed, but shouldn't pose any big problems with modern
software? I'm using Thunderbird over NNTP, and this shows up as
graphics to me:

🐍 💻


But here its broken and I am looking at two pairs of vertical boxes
because it is not properly mime'd. If you use chars or gliphs from a
non-default charset, it needs to demarcated with a mime-boundary marker
followed by the new type definition. Your email/news agent did not do
that.


The headers say:

Content-Type: text/plain; charset=UTF-8; format=flowed

So it DOES declare the right character set.

But it also says:

Content-Transfer-Encoding: 7bit

Which is incorrect, as the message is actually 8bit encoded (since the 
Emoji aren't in the first 127 characters, so their UTF-8 encoding isn't 
7-bit. Some software might have messed up the message in transit due to 
that error.


It came up on the mailing list correct, and the gateway converted the 
encoding to Base64 which should work.


If you don't have a font installed that your reader can find those 
characters, that could be another issue.





(a snake and a computer) Unless this message is blocked at the
NNTP-List boundary, it should show the same on any recent mail reader.

  Christian



Cheers, Gene Heskett



--
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Chris Angelico]

On Mon, Jan 8, 2018 at 9:32 AM, bartc  wrote:
> On 07/01/2018 21:51, Chris Angelico wrote:
>>> dis.dis("not (x in y)")


 1   0 LOAD_NAME0 (x)
 2 LOAD_NAME1 (y)
 4 COMPARE_OP   7 (not in)
>>>
>>>
>>>
>>> I get '4 COMPARE OP6 (in)' here. So they are distinct ops. 'not in'
>>> doesn't just call 'in', then apply 'not'. Not here anyway.
>>>
>>
>> The fact that your Python doesn't optimize it is actually beside the
>> point; if _any_ Python interpreter can optimize this down, it must be
>> semantically identical.
>
>
> Actually I didn't see the 'not' on the outside of the brackets. I thought
> the two expressions were 'not in' and 'in' and that you might have
> transcribed the '7 (not in)' part wrongly.

That's why I don't transcribe - I copy and paste. It's way WAY safer that way.

> But this reduction isn't necessarily an optimisation. It might just be a
> syntactical transformation from 'not (a in b)' to '(a not in b)'
>
> The disassembly for 'in' and 'not in' suggests that these are two
> independent operators, which could indeed have behaviours that are not
> complements of each other.

Uhm, if the peephole optimizer does a syntactical transformation, it
MUST retain the semantics. The disassembly for "in" and "not in" shows
that they are independent, but the disassembly for "not (x in y)"
proves that they are semantically linked.

> On the other hand, when you /did/ want to evaluate 'in' followed by 'not',
> then you want:
>
>not (a in b)# compare using 'not in'
>
> to do the same thing as:
>
>temp = a in b   # compare using 'in'
>not temp# apply unary not
>
> Then there might not be the freedom to have in/not in have independent
> behaviours.

And the whole point of my post is that there is no such freedom - that
"not in" MUST always give the exact converse of "in". (And if
__contains__ returns something other than a boolean, it is coerced
before the operator returns it.) Yet equality is not like that. Hence
my post.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Random832]

On Sun, Jan 7, 2018, at 17:47, Richard Damon wrote:

> But it also says:
> 
> Content-Transfer-Encoding: 7bit
> 
> Which is incorrect, as the message is actually 8bit encoded (since the 
> Emoji aren't in the first 127 characters, so their UTF-8 encoding isn't 
> 7-bit. Some software might have messed up the message in transit due to 
> that error.

Well, the fact that the emoji survived the round-trip and showed up properly in 
his reply (and yours) led me to rule out the possibility that anything like 
that had happened. Plus, if that had happened, the result wouldn't be boxes, 
but a series of ASCII characters (some of which are control characters, and 
some of which are printable).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Chris Angelico]

On Mon, Jan 8, 2018 at 8:06 AM,   wrote:
> From the third paragraph at 
> https://docs.python.org/2/reference/datamodel.html#object.__ne__ "There are 
> no implied relationships among the comparison operators. The truth of x==y 
> does not imply that x!=y is false. Accordingly, when defining __eq__(), one 
> should also define __ne__() so that the operators will behave as 
> expected...".  Compare that with the Python 3 equivalent "By default, 
> __ne__() delegates to __eq__() and inverts the result unless it is 
> NotImplemented. There are no other implied relationships among the comparison 
> operators, for example, the truth of (x

Ah, I forgot to check the Py2 docs. So, yeah, sounds like it's
basically historical. I'm still not sure why it was done in the first
place, but it looks like it's the sort of thing that wouldn't be done
now.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Gene Heskett]

On Sunday 07 January 2018 17:37:14 Random832 wrote:

> On Sun, Jan 7, 2018, at 17:27, Gene Heskett wrote:
> > > 🐍 💻
> >
> > But here its broken and I am looking at two pairs of vertical boxes
> > because it is not properly mime'd. If you use chars or gliphs from a
> > non-default charset, it needs to demarcated with a mime-boundary
> > marker followed by the new type definition. Your email/news agent
> > did not do that.
>
> UTF-8 is the default character set, and anyway his message does have a
> content-type of 'text/plain; charset="utf-8"; Format="flowed"'. Your
> environment not having font support and/or support for non-BMP
> characters is not a deficiency in the message.

That, now that you mention it, could also effect this as I see it, my 
default kmail message body font is hack 14 in deference to the age of my 
eyes.

My system default font is I believe utf-8. That is not a kmail settable 
option. But if I uncheck the "use custom fonts", it is still two pair of 
character outlines. So to what family of fonts do these characters 
belong?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Ben Finney]

Chris Angelico  writes:

> So, yeah, sounds like it's basically historical. I'm still not sure
> why it was done in the first place, but it looks like it's the sort of
> thing that wouldn't be done now.

I'm not understanding why you speculate that it wouldn't be done today.

We've established that it is useful to allow data types to define their
own meaning of “equal” and “not equal”, like many other operations. Is
that not good enough reason to allow it still?

-- 
 \  “Science is what we understand well enough to explain to a |
  `\  computer. Art is everything else we do.” —Donald Knuth, 1996 |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Ethan Furman]

On 01/07/2018 12:33 PM, Chris Angelico wrote:

On Mon, Jan 8, 2018 at 7:13 AM, Thomas Jollans  wrote:

On 07/01/18 20:55, Chris Angelico wrote:

Under what circumstances would you want "x != y" to be different from
"not (x == y)" ?


In numpy, __eq__ and __ne__ do not, in general, return bools.


a = np.array([1,2,3,4])
b = np.array([0,2,0,4])
a == b

array([False,  True, False,  True], dtype=bool)

a != b

array([ True, False,  True, False], dtype=bool)


Thanks, that's the kind of example I was looking for. Though numpy
doesn't drive the core language development much, so the obvious next
question is: was this why __ne__ was implemented, or was there some
other reason? This example shows how it can be useful, but not why it
exists.


Actually, I think it is why it exists.  If I recall correctly, the addition of the six comparative operators* was added 
at the behest of the scientific/numerical community.


--
~Ethan~

* Yeah, I can't remember the cool name for those six operators at the moment.  
:(
--
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Chris Angelico]

On Mon, Jan 8, 2018 at 10:50 AM, Gene Heskett  wrote:
> On Sunday 07 January 2018 17:37:14 Random832 wrote:
>
>> On Sun, Jan 7, 2018, at 17:27, Gene Heskett wrote:
>> > > 🐍 💻
>> >
>> > But here its broken and I am looking at two pairs of vertical boxes
>> > because it is not properly mime'd. If you use chars or gliphs from a
>> > non-default charset, it needs to demarcated with a mime-boundary
>> > marker followed by the new type definition. Your email/news agent
>> > did not do that.
>>
>> UTF-8 is the default character set, and anyway his message does have a
>> content-type of 'text/plain; charset="utf-8"; Format="flowed"'. Your
>> environment not having font support and/or support for non-BMP
>> characters is not a deficiency in the message.
>
> That, now that you mention it, could also effect this as I see it, my
> default kmail message body font is hack 14 in deference to the age of my
> eyes.
>
> My system default font is I believe utf-8. That is not a kmail settable
> option. But if I uncheck the "use custom fonts", it is still two pair of
> character outlines. So to what family of fonts do these characters
> belong?
>

You're conflating a few different things here. The character set is
the Universal Character Set, basically synonymous with "Unicode". The
encoding is UTF-8 and is a way to represent Unicode characters as
bytes. The transfer encoding is base 64 (sometimes called "MIME
encoding"), at least in the email version of it - I don't know what
the original NG post used, and it may have been different. The font
used is a mapping from character codes to displayable glyphs.

Everything except the font is under the sender's control, and (at
least in the mailing list version) was all fine. If your font can't
handle those characters, the font renderer should still recognize that
they are characters, and put boxes (maybe with the codepoints written
in them).

On my Debian Linux systems, I can "sudo apt install unifont" to grab a
font that's used as a fallback for any characters not found in other
fonts. Quoting from the package's description:

"The philosophy behind this font, though, is that anything meaningful
is better than an empty box for an unknown glyph."

It's not perfect, but it's way better than nothing. I don't know how
many of the emoji are included, but it's worth a try.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Gene Heskett]

On Sunday 07 January 2018 18:25:52 Random832 wrote:

> On Sun, Jan 7, 2018, at 17:47, Richard Damon wrote:
> > But it also says:
> >
> > Content-Transfer-Encoding: 7bit
> >
> > Which is incorrect, as the message is actually 8bit encoded (since
> > the Emoji aren't in the first 127 characters, so their UTF-8
> > encoding isn't 7-bit. Some software might have messed up the message
> > in transit due to that error.
>
> Well, the fact that the emoji survived the round-trip and showed up
> properly in his reply (and yours) led me to rule out the possibility
> that anything like that had happened. Plus, if that had happened, the
> result wouldn't be boxes, but a series of ASCII characters (some of
> which are control characters, and some of which are printable).

Its just boxes here, and I just spent the better part of half an hour 
trying all the fonts available to kmail, without see anything but 
variable sizes of twin boxes. Looking at the raw message its also marked 
transfer content encoding = base64, which I'd assume destroys any 
semblance of an 8 bit encoding.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Chris Angelico]

On Mon, Jan 8, 2018 at 10:55 AM, Ben Finney  wrote:
> Chris Angelico  writes:
>
>> So, yeah, sounds like it's basically historical. I'm still not sure
>> why it was done in the first place, but it looks like it's the sort of
>> thing that wouldn't be done now.
>
> I'm not understanding why you speculate that it wouldn't be done today.
>
> We've established that it is useful to allow data types to define their
> own meaning of “equal” and “not equal”, like many other operations. Is
> that not good enough reason to allow it still?

The fact that container types can define "contains" but can't define
"doesn't contain", and that (as of Py3) there's proper default
handling, suggests that it's not as big a priority now.

Let's put it this way. Suppose that __eq__ existed and __ne__ didn't,
just like with __contains__. Go ahead: sell the notion of __ne__.
Pitch it, show why we absolutely need to allow this. Make sure you
mention the potential confusion when subclassing. Be sure to show why
it's okay for "not in" to force to boolean but "==" should allow any
return value.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Chris Angelico]

On Mon, Jan 8, 2018 at 11:07 AM, Gene Heskett  wrote:
> On Sunday 07 January 2018 18:25:52 Random832 wrote:
>
>> On Sun, Jan 7, 2018, at 17:47, Richard Damon wrote:
>> > But it also says:
>> >
>> > Content-Transfer-Encoding: 7bit
>> >
>> > Which is incorrect, as the message is actually 8bit encoded (since
>> > the Emoji aren't in the first 127 characters, so their UTF-8
>> > encoding isn't 7-bit. Some software might have messed up the message
>> > in transit due to that error.
>>
>> Well, the fact that the emoji survived the round-trip and showed up
>> properly in his reply (and yours) led me to rule out the possibility
>> that anything like that had happened. Plus, if that had happened, the
>> result wouldn't be boxes, but a series of ASCII characters (some of
>> which are control characters, and some of which are printable).
>
> Its just boxes here, and I just spent the better part of half an hour
> trying all the fonts available to kmail, without see anything but
> variable sizes of twin boxes. Looking at the raw message its also marked
> transfer content encoding = base64, which I'd assume destroys any
> semblance of an 8 bit encoding.

Proper font substitution would mean that, no matter which font you
have selected, unknown glyphs will be drawn from some other font that
supports them. So you probably don't have any font installed that has
those glyphs. That should be a solvable problem, though it'll depend
on finding one that you like.

Transfer encoding of base64 just means that eight-bit encodings get
wrapped up in a four-for-three carriage method. You take three bytes
and represent them in four letters. It's an encoding that can be used
for binary files or eight-bit text alike. Doesn't change the content
itself; once you decode base64, you get back a series of bytes, which
can be decoded into Unicode text by the normal methods.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Richard Damon]

On 1/7/18 7:07 PM, Gene Heskett wrote:

On Sunday 07 January 2018 18:25:52 Random832 wrote:


On Sun, Jan 7, 2018, at 17:47, Richard Damon wrote:

But it also says:

Content-Transfer-Encoding: 7bit

Which is incorrect, as the message is actually 8bit encoded (since
the Emoji aren't in the first 127 characters, so their UTF-8
encoding isn't 7-bit. Some software might have messed up the message
in transit due to that error.

Well, the fact that the emoji survived the round-trip and showed up
properly in his reply (and yours) led me to rule out the possibility
that anything like that had happened. Plus, if that had happened, the
result wouldn't be boxes, but a series of ASCII characters (some of
which are control characters, and some of which are printable).

Its just boxes here, and I just spent the better part of half an hour
trying all the fonts available to kmail, without see anything but
variable sizes of twin boxes. Looking at the raw message its also marked
transfer content encoding = base64, which I'd assume destroys any
semblance of an 8 bit encoding.

Cheers, Gene Heskett


If you see base64, then something converted it. The 7bit was what I got 
from the source comp.language.python, and it looks like the gateway saw 
that it wasn't 7 bit, and fixed the encoding to base64, which maintains 
the full 8 bit content of the message (with an encoding overhead of 
using 4 characters to encode 3 bytes of data, plus line overhead).


If you got the message from the list, it was intact, and the lack of 
characters says you machine just doesn't have a full unicode font. (One 
of the issues with Unicode, a FULL font is huge)


--
Richard Damon

--
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Gene Heskett]

On Sunday 07 January 2018 19:04:12 Chris Angelico wrote:

> On Mon, Jan 8, 2018 at 10:50 AM, Gene Heskett  
wrote:
> > On Sunday 07 January 2018 17:37:14 Random832 wrote:
> >> On Sun, Jan 7, 2018, at 17:27, Gene Heskett wrote:
> >> > > 🐍 💻
> >> >
> >> > But here its broken and I am looking at two pairs of vertical
> >> > boxes because it is not properly mime'd. If you use chars or
> >> > gliphs from a non-default charset, it needs to demarcated with a
> >> > mime-boundary marker followed by the new type definition. Your
> >> > email/news agent did not do that.
> >>
> >> UTF-8 is the default character set, and anyway his message does
> >> have a content-type of 'text/plain; charset="utf-8";
> >> Format="flowed"'. Your environment not having font support and/or
> >> support for non-BMP characters is not a deficiency in the message.
> >
> > That, now that you mention it, could also effect this as I see it,
> > my default kmail message body font is hack 14 in deference to the
> > age of my eyes.
> >
> > My system default font is I believe utf-8. That is not a kmail
> > settable option. But if I uncheck the "use custom fonts", it is
> > still two pair of character outlines. So to what family of fonts do
> > these characters belong?
>
> You're conflating a few different things here. The character set is
> the Universal Character Set, basically synonymous with "Unicode". The
> encoding is UTF-8 and is a way to represent Unicode characters as
> bytes. The transfer encoding is base 64 (sometimes called "MIME
> encoding"), at least in the email version of it - I don't know what
> the original NG post used, and it may have been different. The font
> used is a mapping from character codes to displayable glyphs.
>
That was looking at the original message.  And its body was indeed a blob 
of base64.

> Everything except the font is under the sender's control, and (at
> least in the mailing list version) was all fine. If your font can't
> handle those characters, the font renderer should still recognize that
> they are characters, and put boxes (maybe with the codepoints written
> in them).
>
> On my Debian Linux systems, I can "sudo apt install unifont" to grab a
> font that's used as a fallback for any characters not found in other
> fonts. Quoting from the package's description:
>
> "The philosophy behind this font, though, is that anything meaningful
> is better than an empty box for an unknown glyph."
>
> It's not perfect, but it's way better than nothing. I don't know how
> many of the emoji are included, but it's worth a try.
>
> ChrisA


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Serhiy Storchaka]

07.01.18 22:33, Chris Angelico пише:

On Mon, Jan 8, 2018 at 7:13 AM, Thomas Jollans  wrote:

On 07/01/18 20:55, Chris Angelico wrote:

Under what circumstances would you want "x != y" to be different from
"not (x == y)" ?


In numpy, __eq__ and __ne__ do not, in general, return bools.


a = np.array([1,2,3,4])
b = np.array([0,2,0,4])
a == b

array([False,  True, False,  True], dtype=bool)

a != b

array([ True, False,  True, False], dtype=bool)


Thanks, that's the kind of example I was looking for. Though numpy
doesn't drive the core language development much, so the obvious next
question is: was this why __ne__ was implemented, or was there some
other reason? This example shows how it can be useful, but not why it
exists.


AFAIK this was the main reason. This can be also used for creating queries.

NumPy inspired 4 or 5 core features which are rarely used outside of 
NumPy. They include the possibility of comparison operators to return 
non-booleans.


--
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Gene Heskett]

On Sunday 07 January 2018 19:04:12 Chris Angelico wrote:

> On Mon, Jan 8, 2018 at 10:50 AM, Gene Heskett  
wrote:
> > On Sunday 07 January 2018 17:37:14 Random832 wrote:
> >> On Sun, Jan 7, 2018, at 17:27, Gene Heskett wrote:
> >> > > 🐍 💻
> >> >
> >> > But here its broken and I am looking at two pairs of vertical
> >> > boxes because it is not properly mime'd. If you use chars or
> >> > gliphs from a non-default charset, it needs to demarcated with a
> >> > mime-boundary marker followed by the new type definition. Your
> >> > email/news agent did not do that.
> >>
> >> UTF-8 is the default character set, and anyway his message does
> >> have a content-type of 'text/plain; charset="utf-8";
> >> Format="flowed"'. Your environment not having font support and/or
> >> support for non-BMP characters is not a deficiency in the message.
> >
> > That, now that you mention it, could also effect this as I see it,
> > my default kmail message body font is hack 14 in deference to the
> > age of my eyes.
> >
> > My system default font is I believe utf-8. That is not a kmail
> > settable option. But if I uncheck the "use custom fonts", it is
> > still two pair of character outlines. So to what family of fonts do
> > these characters belong?
>
> You're conflating a few different things here. The character set is
> the Universal Character Set, basically synonymous with "Unicode". The
> encoding is UTF-8 and is a way to represent Unicode characters as
> bytes. The transfer encoding is base 64 (sometimes called "MIME
> encoding"), at least in the email version of it - I don't know what
> the original NG post used, and it may have been different. The font
> used is a mapping from character codes to displayable glyphs.
>
> Everything except the font is under the sender's control, and (at
> least in the mailing list version) was all fine. If your font can't
> handle those characters, the font renderer should still recognize that
> they are characters, and put boxes (maybe with the codepoints written
> in them).
>
> On my Debian Linux systems, I can "sudo apt install unifont" to grab a
> font that's used as a fallback for any characters not found in other
> fonts. Quoting from the package's description:
>
> "The philosophy behind this font, though, is that anything meaningful
> is better than an empty box for an unknown glyph."

And here, unifont showed them as empty boxes. So does that point the 
finger of guilt to kmail? This is the TDE, R14.0.5 version. Hundreds of 
bugs fixed since the fork at KDE-3.5.

> It's not perfect, but it's way better than nothing. I don't know how
> many of the emoji are included, but it's worth a try.
>
> ChrisA

I'll leave it set to use this unifont & see how it displays the 
smileys ;-)


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Ben Finney via Python-list]

Chris Angelico  writes:

> On Mon, Jan 8, 2018 at 10:55 AM, Ben Finney  
> wrote:
> > We've established that it is useful to allow data types to define
> > their own meaning of “equal” and “not equal”, like many other
> > operations. Is that not good enough reason to allow it still?
>
> The fact that container types can define "contains" but can't define
> "doesn't contain", and that (as of Py3) there's proper default
> handling, suggests that it's not as big a priority now.

That is an inconsistency, I agree.

> Let's put it this way. Suppose that __eq__ existed and __ne__ didn't,
> just like with __contains__. Go ahead: sell the notion of __ne__.
> Pitch it, show why we absolutely need to allow this.

I think “reject unless absolutely needed” is an unreasonably high bar,
which would disqualify most Python language features. So I don't know
why you expect this to be so especially strongly argued.

> Make sure you mention the potential confusion when subclassing.

For example, that would alsop be a problem for multiple inheritance. Not
“absolutely needed”, and high risk of confusion when subclassing. Do you
think that multiple inheritance would thereby also not be allowed today?

If you consider that a different case, why?

-- 
 \ “First they came for the verbs, and I said nothing, for verbing |
  `\weirds language. Then, they arrival for the nouns and I speech |
_o__)   nothing, for I no verbs.” —Peter Ellis |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[breamoreboy]

On Sunday, January 7, 2018 at 7:55:57 PM UTC, Chris Angelico wrote:
> Whoops, premature send. Picking up from the last paragraph.
> 
> This is good. This is correct. For inequalities, you can't assume that
> >= is the exact opposite of < or the combination of < and == (for
> example, sets don't behave like numbers, so "x <= y" is very different
> from "x < y or x == y"). But the one that confuses me is != or __ne__.
> If you don't create it, you get default behaviour:
> 
> >>> class Ham:
> ... def __eq__(self, other):
> ... print("%s equals %s" % (self, other))
> ... return True
> ...
> >>> Ham() == 1
> <__main__.Ham object at 0x7fb7557c0278> equals 1
> True
> >>> 2 == Ham()
> <__main__.Ham object at 0x7fb7557c0278> equals 2
> True
> >>> Ham() != 3
> <__main__.Ham object at 0x7fb7557c0278> equals 3
> False
> >>> 4 != Ham()
> <__main__.Ham object at 0x7fb7557c0278> equals 4
> False
> >>> x = Ham()
> >>> x == x
> <__main__.Ham object at 0x7fb7557b80f0> equals <__main__.Ham object at
> 0x7fb7557b80f0>
> True
> >>> x != x
> <__main__.Ham object at 0x7fb7557b80f0> equals <__main__.Ham object at
> 0x7fb7557b80f0>
> False
> 
> Under what circumstances would you want "x != y" to be different from
> "not (x == y)" ? How would this make for sane behaviour? Even when
> other things go weird with equality checks, that basic parallel is
> always maintained:
> 
> >>> z = float("nan")
> >>> z == z
> False
> >>> z != z
> True
> 
> Python gives us a "not in" operator that uses __contains__ and then
> negates the result. There is no way for "x not in y" to be anything
> different from "not (x in y)", as evidenced by the peephole optimizer:
> 
> >>> dis.dis("x not in y")
>   1   0 LOAD_NAME0 (x)
>   2 LOAD_NAME1 (y)
>   4 COMPARE_OP   7 (not in)
>   6 RETURN_VALUE
> >>> dis.dis("not (x in y)")
>   1   0 LOAD_NAME0 (x)
>   2 LOAD_NAME1 (y)
>   4 COMPARE_OP   7 (not in)
>   6 RETURN_VALUE
> 
> So why isn't != done the same way? Is it historical?
> 
> ChrisA

I'd say this is certainly historical, remembering that in Python 2 you used to 
be able to compare all sorts of things, whereas in Python 3 you'll get:-

>>> 1 < "a"
Traceback (most recent call last):
  File "", line 1, in 
TypeError: '<' not supported between instances of 'int' and 'str'
>>> 

This seems to be confirmed by the following.  From the third paragraph at 
https://docs.python.org/2/reference/datamodel.html#object.__ne__ "There are no 
implied relationships among the comparison operators. The truth of x==y does 
not imply that x!=y is false. Accordingly, when defining __eq__(), one should 
also define __ne__() so that the operators will behave as expected...".  
Compare that with the Python 3 equivalent "By default, __ne__() delegates to 
__eq__() and inverts the result unless it is NotImplemented. There are no other 
implied relationships among the comparison operators, for example, the truth of 
(xhttps://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Chris Angelico]

On Mon, Jan 8, 2018 at 11:33 AM, Gene Heskett  wrote:
> And here, unifont showed them as empty boxes. So does that point the
> finger of guilt to kmail? This is the TDE, R14.0.5 version. Hundreds of
> bugs fixed since the fork at KDE-3.5.
>

Huh. I've no idea, then, but it's entirely possible that (a) the font
actually doesn't have those characters, or (b) kmail uses a 16-bit
renderer. The latter is why Idle can't render astral characters -
Tcl/Tk is limited to the BMP.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Chris Angelico]

On Mon, Jan 8, 2018 at 11:35 AM, Ben Finney via Python-list
 wrote:
> Chris Angelico  writes:
>
>> On Mon, Jan 8, 2018 at 10:55 AM, Ben Finney  
>> wrote:
>> > We've established that it is useful to allow data types to define
>> > their own meaning of “equal” and “not equal”, like many other
>> > operations. Is that not good enough reason to allow it still?
>>
>> The fact that container types can define "contains" but can't define
>> "doesn't contain", and that (as of Py3) there's proper default
>> handling, suggests that it's not as big a priority now.
>
> That is an inconsistency, I agree.
>
>> Let's put it this way. Suppose that __eq__ existed and __ne__ didn't,
>> just like with __contains__. Go ahead: sell the notion of __ne__.
>> Pitch it, show why we absolutely need to allow this.
>
> I think “reject unless absolutely needed” is an unreasonably high bar,
> which would disqualify most Python language features. So I don't know
> why you expect this to be so especially strongly argued.

True, I exaggerated a bit. But do you think that, had __ne__ not
existed for years, its addition could be justified?

>> Make sure you mention the potential confusion when subclassing.
>
> For example, that would alsop be a problem for multiple inheritance. Not
> “absolutely needed”, and high risk of confusion when subclassing. Do you
> think that multiple inheritance would thereby also not be allowed today?
>
> If you consider that a different case, why?

There's a LOT that you can do usefully with MI that you can't do
without it. Having spent a few years (many years ago) working with
Java, I appreciate the ability to inherit from more than one class.
Does it have to be done the way Python currently does it? No. But one
way or another, it's a massively useful feature.

(You're right that "absolutely needed" is too high a bar, but
hyperbole aside, I do think that MI hits a higher mark than __ne__
does.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[breamoreboy]

On Monday, January 8, 2018 at 12:02:09 AM UTC, Ethan Furman wrote:
> On 01/07/2018 12:33 PM, Chris Angelico wrote:
> > On Mon, Jan 8, 2018 at 7:13 AM, Thomas Jollans wrote:
> >> On 07/01/18 20:55, Chris Angelico wrote:
> >>> Under what circumstances would you want "x != y" to be different from
> >>> "not (x == y)" ?
> >>
> >> In numpy, __eq__ and __ne__ do not, in general, return bools.
> >>
> > a = np.array([1,2,3,4])
> > b = np.array([0,2,0,4])
> > a == b
> >> array([False,  True, False,  True], dtype=bool)
> > a != b
> >> array([ True, False,  True, False], dtype=bool)
> >
> > Thanks, that's the kind of example I was looking for. Though numpy
> > doesn't drive the core language development much, so the obvious next
> > question is: was this why __ne__ was implemented, or was there some
> > other reason? This example shows how it can be useful, but not why it
> > exists.
> 
> Actually, I think it is why it exists.  If I recall correctly, the addition 
> of the six comparative operators* was added 
> at the behest of the scientific/numerical community.
> 
> --
> ~Ethan~
> 
> * Yeah, I can't remember the cool name for those six operators at the moment. 
>  :(

The six rich comparison methods were added to 2.1 as a result of PEP 207, which 
confirms that you're correct, they were added at the request of the numpyites.

--
Kindest regards.

Mark Lawrence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Ethan Furman]

On 01/07/2018 04:31 PM, breamore...@gmail.com wrote:

On Monday, January 8, 2018 at 12:02:09 AM UTC, Ethan Furman wrote:

On 01/07/2018 12:33 PM, Chris Angelico wrote:

On Mon, Jan 8, 2018 at 7:13 AM, Thomas Jollans wrote:

On 07/01/18 20:55, Chris Angelico wrote:



Under what circumstances would you want "x != y" to be different from
"not (x == y)" ?


In numpy, __eq__ and __ne__ do not, in general, return bools.


a = np.array([1,2,3,4])
b = np.array([0,2,0,4])
a == b

array([False,  True, False,  True], dtype=bool)

a != b

array([ True, False,  True, False], dtype=bool)


Thanks, that's the kind of example I was looking for. Though numpy
doesn't drive the core language development much, so the obvious next
question is: was this why __ne__ was implemented, or was there some
other reason? This example shows how it can be useful, but not why it
exists.


Actually, I think it is why it exists.  If I recall correctly, the addition of 
the six comparative operators* was added
at the behest of the scientific/numerical community.

--
~Ethan~

* Yeah, I can't remember the cool name for those six operators at the moment.  
:(


The six rich comparison methods were added to 2.1 as a result of PEP 207, which 
confirms that you're correct, they were added at the request of the numpyites.


Cool, thanks for tracking that down!

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Gene Heskett]

On Sunday 07 January 2018 19:38:37 Chris Angelico wrote:

> On Mon, Jan 8, 2018 at 11:33 AM, Gene Heskett  
wrote:
> > And here, unifont showed them as empty boxes. So does that point the
> > finger of guilt to kmail? This is the TDE, R14.0.5 version. Hundreds
> > of bugs fixed since the fork at KDE-3.5.
>
> Huh. I've no idea, 

We are in the same boat. :)
> then, but it's entirely possible that (a) the font 
> actually doesn't have those characters, or (b) kmail uses a 16-bit
> renderer.

Both of which are unk to me. I like the rest of how kmail works, and have 
written automatic scripts to reduce the actual work involved, so I am 
not likely to change agents without a better reason than a couple boxes 
where someone, think its cute, decides to test the rest of the systems.

I believe there is a french saying about such that boils down to a 
shrug. ;-) But its also something I've not seen in something approaching 
70 years, last in some required school reading in the middle 40's IIRC, 
so its still a shrug. I thought maybe I'd gain a clue by starting a 
discussion, but either it didn't or it flew by without even the loss of 
a feather. Solution buried deeper in the system than my bash speaking 
shovel can reach. ;)

Take care all, and have a better 2018.  Orders from Grandpa Gene.



> The latter is why Idle can't render astral characters - 
> Tcl/Tk is limited to the BMP.
>
> ChrisA


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Ben Finney]

Chris Angelico  writes:

> On Mon, Jan 8, 2018 at 11:35 AM, Ben Finney via Python-list
>  wrote:
> > I think “reject unless absolutely needed” is an unreasonably high
> > bar, which would disqualify most Python language features. So I
> > don't know why you expect this to be so especially strongly argued.
>
> True, I exaggerated a bit. But do you think that, had __ne__ not
> existed for years, its addition could be justified?

I'm not the one making pronouncements on what would or would not be
allowed, in a counterfactual universe where things had been different
for so many years. So, because I don't need to speculate about that, I
won't :-)

-- 
 \   “Corporation, n. An ingenious device for obtaining individual |
  `\   profit without individual responsibility.” —Ambrose Bierce, |
_o__)   _The Devil's Dictionary_, 1906 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Random832]

On Sun, Jan 7, 2018, at 18:50, Gene Heskett wrote:
> That, now that you mention it, could also effect this as I see it, my 
> default kmail message body font is hack 14 in deference to the age of my 
> eyes.
> 
> My system default font is I believe utf-8. That is not a kmail settable 
> option. But if I uncheck the "use custom fonts", it is still two pair of 
> character outlines. So to what family of fonts do these characters 
> belong?

If it supports truetype fonts (and picking fonts based on what fonts have a 
character available, rather than one font for the whole message), you might try 
the https://www.google.com/get/noto/ family - it has a black-and-white Emoji 
font available (color fonts require special application support, but the black 
and white one is just plain truetype) - of course, that won't help if it's 
limited to 16 bits (the fact that they are *pairs* of boxes unfortunately 
suggests this, but maybe it'll work properly if a font is available).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Ethan Furman]

On 01/07/2018 04:57 PM, Chris Angelico wrote:

On Mon, Jan 8, 2018 at 11:35 AM, Ben Finney wrote:

Chris Angelico writes:



Let's put it this way. Suppose that __eq__ existed and __ne__ didn't,
just like with __contains__. Go ahead: sell the notion of __ne__.
Pitch it, show why we absolutely need to allow this.


I think “reject unless absolutely needed” is an unreasonably high bar,
which would disqualify most Python language features. So I don't know
why you expect this to be so especially strongly argued.


True, I exaggerated a bit. But do you think that, had __ne__ not
existed for years, its addition could be justified?


Considering we just recently added a matrix-multiplication operator, yes.

--
~Ethan~

--
https://mail.python.org/mailman/listinfo/python-list

Re: Why does __ne__ exist?

[Chris Angelico]

On Mon, Jan 8, 2018 at 4:21 PM, Ethan Furman  wrote:
> On 01/07/2018 04:57 PM, Chris Angelico wrote:
>>
>> On Mon, Jan 8, 2018 at 11:35 AM, Ben Finney wrote:
>>>
>>> Chris Angelico writes:
>
>
 Let's put it this way. Suppose that __eq__ existed and __ne__ didn't,
 just like with __contains__. Go ahead: sell the notion of __ne__.
 Pitch it, show why we absolutely need to allow this.
>>>
>>>
>>> I think “reject unless absolutely needed” is an unreasonably high bar,
>>> which would disqualify most Python language features. So I don't know
>>> why you expect this to be so especially strongly argued.
>>
>>
>> True, I exaggerated a bit. But do you think that, had __ne__ not
>> existed for years, its addition could be justified?
>
>
> Considering we just recently added a matrix-multiplication operator, yes.
>

That has approximately zero consequences on class authors. If you were
unaware of __matmul__, it wouldn't have the chance to randomly break
your __mul__ semantics. And even with that excellent backward
compatibility, it STILL took many years to get accepted.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list