unorderable error: less ok, equal ok, less-or-equal gives unorderable error!
Hi, in python 3.4.1, I get this surpising behaviour: l=Loc(0,0) l2=Loc(1,1) ll2 False ll2 True l=l2 Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: Loc() = Loc() l==l2 False ll2 or l==l2 True Loc implements both __lt__ and __eq__, which should be enough (?), but even after I've added __lte__, I still have the error. implementation: class Loc: def __init__(self, x, y): self._loc = x, y self.x, self.y = x, y def __eq__(self, other): return self._loc == getattr(other, _loc, None) def __lt__(self, other): return self._loc other._loc - andrei -- https://mail.python.org/mailman/listinfo/python-list
Re: unorderable error: less ok, equal ok, less-or-equal gives unorderable error!
On Monday, June 30, 2014 3:34:25 PM UTC-4, Peter Otten wrote: RainyDay wrote: Hi, in python 3.4.1, I get this surpising behaviour: l=Loc(0,0) l2=Loc(1,1) ll2 False ll2 True l=l2 Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: Loc() = Loc() l==l2 False ll2 or l==l2 True Loc implements both __lt__ and __eq__, which should be enough (?), These two methods should be sufficient if you use the functools.total_ordering class decorator, see Thanks! I literally failed to read one more paragraph in a SO answer which referenced this decorator. I really need to start reading those paragraphs, they often provide answers... but even after I've added __lte__, I still have the error. There is no special method of that name; it should probably be __le__(). Right, I used lte in django and assumed they were consistent with python. def __eq__(self, other): return self._loc == getattr(other, _loc, None) Note that None is not a good default when _loc is expected to be a tuple: I'm only using None in equality comparison, it's never a default value of _loc itself, so this should be ok because it'll compare to all other object types and correctly say they're unequal. - andrei -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation about for
On Jan 10, 6:37 am, Νικόλαος Κούρας nikos.kou...@gmail.com wrote: On 10 Ιαν, 12:57, Thomas Rachel nutznetz-0c1b6768-bfa9-48d5- a470-7603bd3aa...@spamschutz.glglgl.de wrote: Am 10.01.2012 10:02 schrieb Νικόλαος Κούρας: --- | HOST | HITS | AGENT | DATE | --- | foo | 7 | IE6 | 1/1/11 | --- | bar | 42 | Firefox | 2/2/10 | --- | baz | 4 | Chrome | 3/3/09 | --- In this line: for host, hits, agent, date in dataset: 'dataset' is one of the rows of the mysql result or the whole mysql result set like the table above? dataset is a cursor, representing the whole result set. Iterating over it produces one row at each iteration step: for row in dataset: ... As each row consists of 4 fields, one iteration result is a tuple of 4 elements. In this case, for host, hits, agent, date in dataset: So that means that for host, hits, agent, date in dataset: is: for host, hits, agent, date in (foo,7,IE6,1/1/11) and then: for host, hits, agent, date in (bar,42,Firefox,2/2/10) and then: for host, hits, agent, date in (baz,4,Chrome,3/3/09) So 'dataset' is one row at each time? but we said that 'dataset' represent the whole result set. So isnt it wrong iam substituting it with one line per time only? It maps naturally to a phrase 'for page in a book'. Book refers to a complete book with all pages, but 'for page in a book' refers to each page, one by one. 'for each page in book: turn it'. The meaning is to turn each page, so your question is equivalent to asking 'so book is one page at each time'? No, it is not and doesn't have to be (unless it's a really short book!) -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
On May 26, 5:33 pm, Daniel Kluev dan.kl...@gmail.com wrote: On Wed, May 25, 2011 at 3:10 AM, Octavian Rasnita orasn...@gmail.com wrote: Once again. Suppose we have array of key-value pairs (two-dimensional array), This is a forced example to fit the way Python can do it with a clean syntax, but I don't think there are cases in which somebody wants to create hashes/dictionaries where the key is not a plain string but an array. This is not a rare case, but a case that probably nobody needs, ever. This is far more popular case than converting flat lists into dicts in Python world. In fact, I *never* had need to convert flat list instead of properly structured one. Thats why we have both lists and tuples, after all. I agree that it's almost never needed to convert flat lists. I've used python for over 10 years and I remember exactly one time when I needed to do that. It turned out that it's a bit tricky and hacky to do in python, in the sense that it's hard to remember if I'll ever need it again, but it will only take minutes to google it. For example, in one piece of code I did recently I created a dict of range tuples and counts from a sequential list, like so: ranges = [(x*width, (x+1)*width) for x in range(y)] data = dict((x,0) for x in ranges) A perl programmer would instead create a flat list and then convert it to dict. And if he were new to python he'd create a flat list and then be annoyed that there's no quick and easy way to make it into a dict. Python way in this case is more structured and disciplined, and the only flaw I can see is that it doesn't meet expectations of perl programmers. -Rainy -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
On May 25, 3:14 pm, John Bokma j...@castleamber.com wrote: Ethan Furman et...@stoneleaf.us writes: Terry Reedy wrote: On 5/25/2011 8:01 AM, John Bokma wrote: to. Like I already stated before: if Python is really so much better than Python readability wise, why do I have such a hard time dropping Perl and moving on? [you meant 'than Perl'] You are one of the people whose brain fits Perl (or vice versa) better than most. So enjoy it. Ignore anyone who says otherwise. +1 If everybody's brain worked the same, we wouldn't have so many different languages to choose from. So, this means that in general language readability is not as clear cut as some seem to advertise ;-). I only know a tiny bit of Perl but I think you may prefer it because it gives you some advantages in short term but you have to pay more than it's worth (arguably) in the long term. When you sit down to write a new program, it's easier to do than in python because it's quicker to type and, of the proverbial many ways, you chose the ones that suit your taste better. However, when you sit down to read someone else's code, it's harder to read because you don't know the intent of their authors. If they had different taste for idioms or formatting style than you do, you will chalk it up to them being bad programmers and having bad coding or formatting style, so it's not perceived as a perl's failing. Python way has more of an emphasis on everyone agreeing on some preferred, standard idioms so that everyone can pick up each others' code quickly. Similarly, when we write in english, we have conventions of, for instance, capitalizing at the start of a sentence and having a period at the end of it, and following rules of grammar. However, if I'm writing notes for my own use, I might write: similarly when we write in english we have conventions of eg capitalizing at start of sentence and having period at the end following rules of grammar but since i'm writing for my own use maybe it's easier to write in lower caps and use 3 spaces at the end of sentences, since no-ones has to read it but me? -- http://mail.python.org/mailman/listinfo/python-list
