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_
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
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
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
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 KD
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
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
> >>
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
>> > o
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
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 beh
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 th
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 p
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.ar
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 p
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 12
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
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 spec
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 th
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
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.
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
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
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__
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 mes
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
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)
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 etique
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
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 pos
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 n
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
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
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
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
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"
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 t
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 i
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 a
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
39 matches
Mail list logo
