Dunder variables
Hi all I have read that one should not call dunder methods in application code. Does the same apply to dunder variables? I am thinking of the instance attribute __dict__, which allows access to the contents of the instance. I only want to read from __dict__, not update it. Is this frowned upon? Thanks Frank Millman -- https://mail.python.org/mailman/listinfo/python-list
How to create "transitional" package?
Hi, all. Yesterday, I released msgpack-0.5, which was msgpack-python. Both packages provide "msgpack" python package. I used msgpack in early days, but easy_install crawling website and download msgpack-1.0.0.tar.gz, which is msgpack for C instead of Python package I upload to PyPI. So I renamed msgpack-python but I really dislike it. Now pip doesn't such silly crawling so I decided to rename back to msgpack. To ease transition, I follow what uritemplate.py [1] did (which was migrated to uritemplate). I released msgpack-python 0.5. It is empty package. But it's metadata contains `install_requires=["msgpack>=0.5"]`. Sadly, this breaks upgrading from old version via `pip install -U msgpack-python`. It does: * Install msgpack-0.5 (overwrite msgpack-python 0.4.7) * Uninstall msgpack-python 0.4.7 (removes msgapck 0.5!) * Install msgpack-python 0.5 (empty!) I found uritemplate.py has same issue. Maybe pip's behavior was changed after migration of uritemplate.py to uritemplate. Now what can I do for smooth transition? I don't want to back to msgpack-python again. [1] https://pypi.python.org/pypi/uritemplate.py Regards, INADA Naoki -- https://mail.python.org/mailman/listinfo/python-list
Re: Native object exposing buffer protocol
On Saturday, January 6, 2018 at 12:02:18 AM UTC, Rob Gaddi wrote: > I'd like to create a native Python object that exposes the buffer > protocol. Basically, something with a ._data member which is a > bytearray that I can still readinto, make directly into a numpy array, etc. > > I can do it by inheriting the entire thing from bytearray directly, but > that gives me a whole lot of methods that are unsuitable for what I'm > doing with it, which is reading the contents of a binary file, allowing > them to be lightly malleable in memory, and then sending them on to a > device. > > Not the end of the world (the file's less than 2KB), but it seems like > something that should be doable easily without having to throw around a > lot of extraneous copies. > > -- > Rob Gaddi, Highland Technology -- www.highlandtechnology.com > Email address domain is currently out of order. See above to fix. Curiosity having got the better of me I did some searching and found this "Implementing the buffer protocol" http://cython.readthedocs.io/en/latest/src/userguide/buffer.html, any use to you? Note that at the bottom of the link the final section "References" states "The buffer interface used here is set out in PEP 3118, Revising the buffer protocol.", i.e. it is the new protocol and not the old Python 2 one. -- Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I send keystrokes to a console window in Windows XP?
在 2005年7月16日星期六 UTC+8下午8:46:34，Benji York写道：
> googlegro...@garringer.net wrote:
> > How do I use Python to send keystrokes to a console window in Windows
> > XP?
>
> import win32com.client
>
> shell = win32com.client.Dispatch("WScript.Shell")
> shell.AppActivate("Command Prompt")
>
> shell.SendKeys("cls{ENTER}")
> shell.SendKeys("dir{ENTER}")
> shell.SendKeys("echo Hi There{ENTER}")
> --
> Benji York
Recently, I tried `.AppActivate("Command Prompt")` but cannot catch the `cmd`
on my Windows 7, the result is `False`. I know it has been some years since
your reply, and the name of the window object may be different.(Still I'm
pretty thankful to your answer.) Just wondering if there is a similar solution
with another object name.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Native object exposing buffer protocol
On 01/05/2018 04:27 PM, Ben Finney wrote: Rob Gaddi writes: I'd like to create a native Python object that exposes the buffer protocol. Basically, something with a ._data member which is a bytearray that I can still readinto, make directly into a numpy array, etc. The “etc.” seems pretty important, there. You want the behaviour of ‘bytearray’ without actually inheriting that behaviour from the ‘bytearray’ type. > Well, one specific behavior. Ideally, what I want is, when calls like RawIOBase.readinto and ndarray.frombuffer ask my class "Hey, do you have any raw bytes that I can read and potentially write?" it can answer "Why certainly, here they are." Something like a: class Thingy: def __memoryview__(self): return memoryview(self._data) But it doesn't look as if there's a dunder for that. There's __bytes__, but that specifically requires you give back a bytes() object; even returning a bytearray causes an error. So, it seems your options are: * Enumerate all the things, specifically, that you do want your new type to do. Don't hide anything in “etc.”, so that you know exactly what behaviours need to be implemented. Implement all those behaviours, without benefit of inheriting from ‘bytearray’. * Inherit from ‘bytearray’, but ameliorate the problems you want to avoid. This will require enumerating all those problems, so that you can know whether you have avoided them. Don't hide any of them in an “etc.”. That's ultimately the way I'm going about it, but since this is only going to get used in-house, I'm approaching it the Pythonic way. The problem is "Most methods of bytearray make no sense on a data structure representing a fixed length waveform." The solution is "Well, don't use them." Not the end of the world (the file's less than 2KB), but it seems like something that should be doable easily without having to throw around a lot of extraneous copies. I look forward to your report from having tried it :-) -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
fun with cwrap: Unknown type kind 114
Dear Eli,
Can you please take a look at:
https://bitbucket.org/tkadm30/libuwsgictl/raw/048978bf2b51b1185302da98c5063978061293df/tests/cwrap/error
I'm playing around with cwrap: https://github.com/geggo/cwrap
Looks like this *gem* can generate Cython pxd files from C headers using
libclang. :)
Traceback (most recent call last):
File "/usr/local/bin/cwrap", line 46, in
ast_items = clang_parser.parse([('input.h', inputfile)], include_dirs, '')
File
"/usr/local/lib/python2.7/dist-packages/cwrap/frontends/clang/clang_parser.py",
line 889, in parse
parser.parse(cfile[0][0], include_dirs, language, unsaved_files=cfile)
File
"/usr/local/lib/python2.7/dist-packages/cwrap/frontends/clang/clang_parser.py",
line 123, in parse
self.parse_element(tu.cursor)
File
"/usr/local/lib/python2.7/dist-packages/cwrap/frontends/clang/clang_parser.py",
line 306, in parse_element
child = self.parse_element(c, level+1)
File
"/usr/local/lib/python2.7/dist-packages/cwrap/frontends/clang/clang_parser.py",
line 259, in parse_element
result = mth(cursor, level)
File
"/usr/local/lib/python2.7/dist-packages/cwrap/frontends/clang/clang_parser.py",
line 496, in visit_VAR_DECL
typ, id_ = self.type_to_c_ast_type(cursor.type, level)
File
"/usr/local/lib/python2.7/dist-packages/cwrap/frontends/clang/clang_parser.py",
line 167, in type_to_c_ast_type
level.show( 'in type to c_ast:', 'kind:', t.kind,
repr(t.get_declaration().spelling))
File
"/usr/local/lib/python2.7/dist-packages/cwrap/frontends/clang/clang/cindex.py",
line 1467, in kind
return TypeKind.from_id(self._kind_id)
File
"/usr/local/lib/python2.7/dist-packages/cwrap/frontends/clang/clang/cindex.py",
line 1407, in from_id
raise ValueError,'Unknown type kind %d' % id
ValueError: Unknown type kind 114
What do you think about this error?
I ran: $ cwrap -i . -i /usr/lib/llvm-3.8/lib/clang/3.8.1/include uwsgi.h
libuwsgi.pxd
Cheers,
Etienne
--
Etienne Robillard
tkad...@yandex.com
https://www.isotopesoftware.ca/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does __ne__ exist?
On Tue, Jan 9, 2018 at 3:25 AM, Cody Piersall wrote: >> 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. > > __ne__ and __eq__ are important for building mask arrays in NumPy, > which allow complex indexing operations. A lot of NumPy's design was > inspired by MATLAB, so being able to index the same way as in MATLAB > is a pretty killer feature. > > Indexing an array using mask arrays like this is idiomatic: > > some_arr = np.array([-1, 0, 1, 2, 3, 4, 5, 2, -1, 3, -1, 6, 7, 3]) > valid = some_arr[some_arr != -1] > > Anybody with familiarity with NumPy appreciates that this is possible. I've used it, and I'm familiar with it, and I'm still not sure that I appreciate it. But if it's there because of MATLAB, well, I guess that's what people want? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: : ✨🍰✨ python 2018 wiki - a piece of cake ✨🍰✨ --- 🙄🙄🙄
On Mon, 08 Jan 2018 15:55:00 +, user net wrote: > Abdur-Rahmaan Janhangeer: >> there is a language called python by guido >> >> you can ask your questions here ! > > > > ✨🍰✨ python - a piece of cake ✨🍰✨ > > > when u read this post in thunderbird or torBrowser, you see colored > emoji font > > in other newsreaders, like XPN, pan, etc., it is black & white only. > > how to get colored emoji icons - like the above cake - everywhere ? I am using Pan & it is in colour - not that i would loose any sleep if it wasn't 💩 -- Wrinkles should merely indicate where smiles have been. -- Mark Twain -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does __ne__ exist?
Op 08-01-18 om 17:25 schreef Cody Piersall: >> 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. > > __ne__ and __eq__ are important for building mask arrays in NumPy, > which allow complex indexing operations. A lot of NumPy's design was > inspired by MATLAB, so being able to index the same way as in MATLAB > is a pretty killer feature. They are only important if you find it necessary to build these mask arrays wih an operator. > Indexing an array using mask arrays like this is idiomatic: > > some_arr = np.array([-1, 0, 1, 2, 3, 4, 5, 2, -1, 3, -1, 6, 7, 3]) > valid = some_arr[some_arr != -1] I guess it was rather useful because list comprehension wasn't included in the language at that moment, but I don't find it that much more useful than: valid = somearr[[number != -1 for number in somearr]] -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Plot map wit a white and black box
On Monday, January 8, 2018 at 1:16:08 PM UTC, jorge@cptec.inpe.br wrote: > Hi, > > Please, I woudl like to plot a map like this figure. How can I do this > using Python2.7 > > Thanks, > > Conrado Figures don't get through and you've all ready asked this question, possibly on another forum. What was wrong with the replies that you got then? -- Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does __ne__ exist?
> 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. __ne__ and __eq__ are important for building mask arrays in NumPy, which allow complex indexing operations. A lot of NumPy's design was inspired by MATLAB, so being able to index the same way as in MATLAB is a pretty killer feature. Indexing an array using mask arrays like this is idiomatic: some_arr = np.array([-1, 0, 1, 2, 3, 4, 5, 2, -1, 3, -1, 6, 7, 3]) valid = some_arr[some_arr != -1] Anybody with familiarity with NumPy appreciates that this is possible. I imagine that ORMs like Django or SqlAlchemy also override __ne__ to provide nice APIs. Finally (and perhaps least imporant), there is a performance hit if only allowing __eq__ and then taking its inverse. Cody -- https://mail.python.org/mailman/listinfo/python-list
Re: : ✨🍰✨ python 2018 wiki - a piece of cake ✨🍰✨ --- 🙄🙄🙄
there is a language called python by guido you can ask your questions here ! On 5 Jan 2018 23:30, "Kim of K." wrote: > OK now we have emoji in XPN > > > but not in colour like in torBrowser... > > > :-( > > > 🙄 > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does __ne__ exist?
Op 08-01-18 om 00:53 schreef Ethan Furman: > On 01/07/2018 12:33 PM, Chris Angelico wrote: > > 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. Which personnaly, I think was a mistake. I can understand it is useful for the scientific/numerical community to compare vectors with each other and get a vector of booleans. However how useful is it doing this with the normal boolean operators, instead of calling a function? And if doing it with an operator was so important, I think it would have been better to introduce boxed operators, like [+], [<] ... where the default behaviour would be an elementary wise application of the non-boxed operator. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does __ne__ exist?
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:
> > 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.
>
> See my earlier email and/or PEP 207. (tl;dr: non-bool return values)
>
> >
> > That said, while it is true you only need one of (__eq__, __ne__), you
> > could make the same claim about (__lt__, __ge__) and (__le__, __gt__).
> > That is, in principle you could get by with only (__eq__, __le__, and
> > __ge__) or, if you prefer, (__ne__, __lt__, __gt__), or any other
> > combination you prefer.
>
> PEP 207: "The above mechanism is such that classes can get away with not
> implementing either __lt__ and __le__ or __gt__ and __ge__."
>
>
> >
> > Or you could go where C++ is doing and say that _if_ one specifies a
> single
> > __cmp__ method, it should return one of LT, EQ, GT, and this will
> > automatically give rise to all the comparison operators.
>
> This used to be the case. (from version 2.1 to version 2.7, AFAICT)
>
>
> >
> > "Trade-offs... trafe-offs as far as the eye can see" ;-)
> >
> >
> > On Mon, Jan 8, 2018 at 4:01 PM, Thomas Nyberg wrote:
> >
> >> On 01/08/2018 12:36 PM, Thomas Jollans wrote:
> >>>
> >>> Interesting sentence from that PEP:
> >>>
> >>> "3. The == and != operators are not assumed to be each other's
> >>> complement (e.g. IEEE 754 floating point numbers do not satisfy this)."
> >>>
> >>> Does anybody here know how IEE 754 floating point numbers need __ne__?
> >>
> >> That's very interesting. I'd also like an answer to this. I can't wrap
> >> my head around why it would be true. I've just spent 15 minutes playing
> >> with the interpreter (i.e. checking operations on 0, -0, 7,
> >> float('nan'), float('inf'), etc.) and then also reading a bit about IEEE
> >> 754 online and I can't find any combination of examples where == and !=
> >> are not each others' complement.
> >>
> >> Cheers,
> >> Thomas
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does __ne__ exist?
On 2018-01-08 15:25, Oren Ben-Kiki wrote:
> 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.
See my earlier email and/or PEP 207. (tl;dr: non-bool return values)
>
> That said, while it is true you only need one of (__eq__, __ne__), you
> could make the same claim about (__lt__, __ge__) and (__le__, __gt__).
> That is, in principle you could get by with only (__eq__, __le__, and
> __ge__) or, if you prefer, (__ne__, __lt__, __gt__), or any other
> combination you prefer.
PEP 207: "The above mechanism is such that classes can get away with not
implementing either __lt__ and __le__ or __gt__ and __ge__."
>
> Or you could go where C++ is doing and say that _if_ one specifies a single
> __cmp__ method, it should return one of LT, EQ, GT, and this will
> automatically give rise to all the comparison operators.
This used to be the case. (from version 2.1 to version 2.7, AFAICT)
>
> "Trade-offs... trafe-offs as far as the eye can see" ;-)
>
>
> On Mon, Jan 8, 2018 at 4:01 PM, Thomas Nyberg wrote:
>
>> On 01/08/2018 12:36 PM, Thomas Jollans wrote:
>>>
>>> Interesting sentence from that PEP:
>>>
>>> "3. The == and != operators are not assumed to be each other's
>>> complement (e.g. IEEE 754 floating point numbers do not satisfy this)."
>>>
>>> Does anybody here know how IEE 754 floating point numbers need __ne__?
>>
>> That's very interesting. I'd also like an answer to this. I can't wrap
>> my head around why it would be true. I've just spent 15 minutes playing
>> with the interpreter (i.e. checking operations on 0, -0, 7,
>> float('nan'), float('inf'), etc.) and then also reading a bit about IEEE
>> 754 online and I can't find any combination of examples where == and !=
>> are not each others' complement.
>>
>> Cheers,
>> Thomas
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does __ne__ exist?
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 where __ne__ is actually useful.
>
> Assuming you're talking about a case specifically for IEEE 754, I'm
> starting to agree. In general, however, it certainly is useful for some
> numpy objects (as mentioned elsewhere in this thread).
>
> > That said, while it is true you only need one of (__eq__, __ne__), you
> > could make the same claim about (__lt__, __ge__) and (__le__, __gt__).
> > That is, in principle you could get by with only (__eq__, __le__, and
> > __ge__) or, if you prefer, (__ne__, __lt__, __gt__), or any other
> > combination you prefer.
>
> This isn't true for IEEE 754. For example:
>
> >>> float('nan') < 0
> False
> >>> float('nan') > 0
> False
> >>> float('nan') == 0
> False
>
> Also there are many cases where you don't have a < b OR a >= b. For
> example, subsets don't follow this.
>
> > "Trade-offs... trafe-offs as far as the eye can see" ;-)
>
> Yes few things in life are free. :)
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does __ne__ exist?
On 01/08/2018 03:25 PM, Oren Ben-Kiki wrote:
> I am hard pressed to think of a case where __ne__ is actually useful.
Assuming you're talking about a case specifically for IEEE 754, I'm
starting to agree. In general, however, it certainly is useful for some
numpy objects (as mentioned elsewhere in this thread).
> That said, while it is true you only need one of (__eq__, __ne__), you
> could make the same claim about (__lt__, __ge__) and (__le__, __gt__).
> That is, in principle you could get by with only (__eq__, __le__, and
> __ge__) or, if you prefer, (__ne__, __lt__, __gt__), or any other
> combination you prefer.
This isn't true for IEEE 754. For example:
>>> float('nan') < 0
False
>>> float('nan') > 0
False
>>> float('nan') == 0
False
Also there are many cases where you don't have a < b OR a >= b. For
example, subsets don't follow this.
> "Trade-offs... trafe-offs as far as the eye can see" ;-)
Yes few things in life are free. :)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does __ne__ exist?
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
could make the same claim about (__lt__, __ge__) and (__le__, __gt__).
That is, in principle you could get by with only (__eq__, __le__, and
__ge__) or, if you prefer, (__ne__, __lt__, __gt__), or any other
combination you prefer.
Or you could go where C++ is doing and say that _if_ one specifies a single
__cmp__ method, it should return one of LT, EQ, GT, and this will
automatically give rise to all the comparison operators.
"Trade-offs... trafe-offs as far as the eye can see" ;-)
On Mon, Jan 8, 2018 at 4:01 PM, Thomas Nyberg wrote:
> On 01/08/2018 12:36 PM, Thomas Jollans wrote:
> >
> > Interesting sentence from that PEP:
> >
> > "3. The == and != operators are not assumed to be each other's
> > complement (e.g. IEEE 754 floating point numbers do not satisfy this)."
> >
> > Does anybody here know how IEE 754 floating point numbers need __ne__?
>
> That's very interesting. I'd also like an answer to this. I can't wrap
> my head around why it would be true. I've just spent 15 minutes playing
> with the interpreter (i.e. checking operations on 0, -0, 7,
> float('nan'), float('inf'), etc.) and then also reading a bit about IEEE
> 754 online and I can't find any combination of examples where == and !=
> are not each others' complement.
>
> Cheers,
> Thomas
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does __ne__ exist?
On 01/08/2018 12:36 PM, Thomas Jollans wrote:
>
> Interesting sentence from that PEP:
>
> "3. The == and != operators are not assumed to be each other's
> complement (e.g. IEEE 754 floating point numbers do not satisfy this)."
>
> Does anybody here know how IEE 754 floating point numbers need __ne__?
That's very interesting. I'd also like an answer to this. I can't wrap
my head around why it would be true. I've just spent 15 minutes playing
with the interpreter (i.e. checking operations on 0, -0, 7,
float('nan'), float('inf'), etc.) and then also reading a bit about IEEE
754 online and I can't find any combination of examples where == and !=
are not each others' complement.
Cheers,
Thomas
--
https://mail.python.org/mailman/listinfo/python-list
Re: has sourceforge exposed the dirty little secret ?
fuel the troll ** poor py ** On 5 Jan 2018 20:30, "Kim of K." wrote: > > "Background > > We feel that the world still produces way too much software that is > frankly substandard. The reasons for this are pretty simple: software > producers do not pay enough attention [...]" > > > quote from http://texttest.sourceforge.net/index.php?page=about > > > In other words: most sites like SF and github offer tons of crap. > download and break is the overwhelming theme here. > > why is no one complaining ? > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Plot map wit a white and black box
Hi, Please, I woudl like to plot a map like this figure. How can I do this using Python2.7 Thanks, Conrado -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does __ne__ exist?
On 2018-01-08 01:31, 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. Interesting sentence from that PEP: "3. The == and != operators are not assumed to be each other's complement (e.g. IEEE 754 floating point numbers do not satisfy this)." Does anybody here know how IEE 754 floating point numbers need __ne__? > > -- > Kindest regards. > > Mark Lawrence. > -- https://mail.python.org/mailman/listinfo/python-list
