Re: Why does list have no 'get' method?
On Feb 8, 4:24 pm, [EMAIL PROTECTED] wrote:
> > > val = BETTER foo THAN bar
>
> > > ;-)
>
> > > Cobol-strikes-back-ly yours,
>
> > > George
>
> > I use a ETL language/tool that actually has a function for this kind
> > of thing:
>
> > NulltoValue(value,defaultValue)
>
> > it returns defaultValue if value is null otherwise value.
>
> even Ksh has one;
>
> val=${foo:=$bar}
>
An approximation in Python:
http://gflanagan.net/site/python/utils/RattlebagTemplate.py.html
http://gflanagan.net/site/python/utils/RattlebagTemplate.py
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
[EMAIL PROTECTED] writes: > (would it help if I put lots of blank lines after this, so the disclaimer > is out-of-sight/out-of-mind?) Not really. It would help far more if you could stop having this disclaimer appear at all on this list (or any other list, really, but that's a matter for those lists to complain about). This can be achieved either by preventing the disclaimer from being attached, or by not posting from accounts that will cause the disclaimer to appear. -- \ "Writing a book is like washing an elephant: there no good | `\place to begin or end, and it's hard to keep track of what | _o__) you've already covered." —Anonymous | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
Carl Banks:
> I think booleans should be completely disjoint from all other types,
> as they are in Java. "and", "or", and "not" should accept only boolean
> operands and return only boolean results.
I'd like "or" and "and" (and "not") to return booleans only, to avoid
bugs and make their meaning more transparent, but I like the fact that
empty containers like "" [] (,) {} are seen as false:
x = []
if x:
...
else:
... // goes here
bool([]) ==> False
So I don't mind "and", "or" to take non-booleans too as input:
[] or "aa" ==> True
I think that's a good compromise between practicality, and avoiding
bugs.
"not" already works that way, it takes other objects too as input, but
its output is always a bool:
>>> not "aa"
False
>>> not ""
True
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
En Fri, 08 Feb 2008 13:24:19 -0200, <[EMAIL PROTECTED]> escribió: > > Matt. > (would it help if I put lots of blank lines after this, so the disclaimer > is out-of-sight/out-of-mind?) > -- > ie, from here on? No, what would help is a line containing *exactly* (dash)(dash)(space)(newline) That is, add a single space after those two dashes above. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
On Feb 8, 3:38 am, [EMAIL PROTECTED] wrote: > Can't you just make a subclass of Boolean and add methods to the true/ > false, or am i running up a tree with a cat? I'm not sure what point you were trying to make, but no you can't subclass bool in Python as it is now; certainly it wouldn't be possible if Python treated bools according to my preference. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
> > val = BETTER foo THAN bar
> >
> > ;-)
> >
> > Cobol-strikes-back-ly yours,
> >
> > George
>
> I use a ETL language/tool that actually has a function for this kind
> of thing:
>
> NulltoValue(value,defaultValue)
>
> it returns defaultValue if value is null otherwise value.
even Ksh has one;
val=${foo:=$bar}
Matt.
(would it help if I put lots of blank lines after this, so the disclaimer
is out-of-sight/out-of-mind?)
--
ie, from here on?
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
Do not print this message unless it is necessary,
consider the environment.
-
Ce message et toutes les pieces jointes (ci-apres le
"message") sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
N'imprimez ce message que si necessaire,
pensez a l'environnement.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
On Feb 7, 4:36 pm, George Sakkis <[EMAIL PROTECTED]> wrote: > On Feb 7, 4:25 pm, Steven D'Aprano <[EMAIL PROTECTED] > > > > cybersource.com.au> wrote: > > On Thu, 07 Feb 2008 15:59:13 +0100, Wildemar Wildenburger wrote: > > > Arnaud Delobelle wrote: > > >> Personally, between > > > >> * foo if foo else bar > > >> * foo or bar > > > >> I prefer the second. Maybe it could be spelt > > > >> * foo else bar ? > > > > How about > > > > val = foo rather than bar > > > > If that is not clear and obvios, I don't know what is. ;) > > > In English, the expression "foo rather than bar" means "bar is never > > chosen, foo is always chosen". > > Ok, the fix is easy: > > val = BETTER foo THAN bar > > ;-) > > Cobol-strikes-back-ly yours, > > George I use a ETL language/tool that actually has a function for this kind of thing: NulltoValue(value,defaultValue) it returns defaultValue if value is null otherwise value. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
On Feb 8, 8:23 am, Carl Banks <[EMAIL PROTECTED]> wrote: > On Feb 7, 8:44 am, Steve Holden <[EMAIL PROTECTED]> wrote: > > > [EMAIL PROTECTED] wrote: > > > I'd like to know what others think about it, about this anti-feature. > > > What I can say is that other computer languages too think that boolean > > > operations must return boolean values only, so I am not alone in my > > > folly :-) > > > Other languages do indeed refuse the temptation to short-circuit, > > Short-circuiting isn't the issue here; a language can short circuit > and still return a boolean. > > > but > > that doesn't mean that Python is wrong to do so. It's a design choice, > > and while you are free to disagree with it I imagine you would be > > pissing in the wind in attempting to get a change like that into Python 3. > > > Most people like the semantics of "and" and "or" as they are. > > I guess I'll agree with bearophile here; I think booleans should be > completely disjoint from all other types, as they are in Java. "and", > "or", and "not" should accept only boolean operands and return only > boolean results. > > I don't deny that it's convenient to use "or" that returns the first > true value, or that it's sometimes a marginal improvement in clarity. > > I just think this idiom is too error prone, and very often too > misleading, to justify its convenience. There's ordinary > carelessness, of course, where someone writes a function like this: > > def op(datum=None): > result = datum or default > > while not stopping to consider that the empty string would be a legal > value for datum in this case. But there's a more insidious danger > that can't be chalked up to carelessness: when the acceptable values > for datum change *after* the function is written. This leads to > subtle breakage. > > As far as the user is concerned, this function's correct behavior is > to "use the default when the argument is not specified", but as-is the > function is not robust to future changes or uses. The function is a > poor, non-robust implementation of the desired behavior. > > To me this feels like a ticking bomb, a bug waiting to emerge from > it's egg. > > More generally: I find that the boundary between what Python considers > to be true and false rarely corresponds exactly to what I'm trying to > do in cases like the above. > Usually the true/false test only works for certain set of expected > values that I have in my mind. When the acceptable values are > generalized, when you want to expand this function's role, does the > true/false test still work? I find it rarely does. > > The Python treatment of booleans is, by far, my biggest gripe with > Python. (Which, you know, is a pretty good thing to have as a biggest > gripe.) > > Carl Banks Can't you just make a subclass of Boolean and add methods to the true/ false, or am i running up a tree with a cat? I think a clear problem with this is that, this is one area of grief for some users with the Try/Except: clause usage, there are many other examples of this where people would prefer one liners, and a good argument not to allow one is because then you probably wouldn't have a good defence against disallowing the other forms... just-my-one-cent-ly's yours Coko -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
On Feb 7, 8:44 am, Steve Holden <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > I'd like to know what others think about it, about this anti-feature. > > What I can say is that other computer languages too think that boolean > > operations must return boolean values only, so I am not alone in my > > folly :-) > > Other languages do indeed refuse the temptation to short-circuit, Short-circuiting isn't the issue here; a language can short circuit and still return a boolean. > but > that doesn't mean that Python is wrong to do so. It's a design choice, > and while you are free to disagree with it I imagine you would be > pissing in the wind in attempting to get a change like that into Python 3. > > Most people like the semantics of "and" and "or" as they are. I guess I'll agree with bearophile here; I think booleans should be completely disjoint from all other types, as they are in Java. "and", "or", and "not" should accept only boolean operands and return only boolean results. I don't deny that it's convenient to use "or" that returns the first true value, or that it's sometimes a marginal improvement in clarity. I just think this idiom is too error prone, and very often too misleading, to justify its convenience. There's ordinary carelessness, of course, where someone writes a function like this: def op(datum=None): result = datum or default while not stopping to consider that the empty string would be a legal value for datum in this case. But there's a more insidious danger that can't be chalked up to carelessness: when the acceptable values for datum change *after* the function is written. This leads to subtle breakage. As far as the user is concerned, this function's correct behavior is to "use the default when the argument is not specified", but as-is the function is not robust to future changes or uses. The function is a poor, non-robust implementation of the desired behavior. To me this feels like a ticking bomb, a bug waiting to emerge from it's egg. More generally: I find that the boundary between what Python considers to be true and false rarely corresponds exactly to what I'm trying to do in cases like the above. Usually the true/false test only works for certain set of expected values that I have in my mind. When the acceptable values are generalized, when you want to expand this function's role, does the true/false test still work? I find it rarely does. The Python treatment of booleans is, by far, my biggest gripe with Python. (Which, you know, is a pretty good thing to have as a biggest gripe.) Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
En Thu, 07 Feb 2008 19:36:57 -0200, George Sakkis <[EMAIL PROTECTED]> escribió: > On Feb 7, 4:25 pm, Steven D'Aprano <[EMAIL PROTECTED] > cybersource.com.au> wrote: >> On Thu, 07 Feb 2008 15:59:13 +0100, Wildemar Wildenburger wrote: >> >> > val = foo rather than bar >> >> > If that is not clear and obvios, I don't know what is. ;) >> >> In English, the expression "foo rather than bar" means "bar is never >> chosen, foo is always chosen". > > Ok, the fix is easy: > > val = BETTER foo THAN bar Great! It could even be qualified: val = BETTER foo THAN bar UNLESS not required(foo) and nested: val = BETTER foo THAN ( BETTER bar THAN baz UNLESS lunar_phase=="Full Moon") and used wherever any other expression is allowed: val = BETTER foo THAN ( BETTER bar THAN baz UNLESS insanity_level>threshold) UNLESS self.parent is self \ if verbose else 42 Sane precedence rules would require using ( ) around the expression before the if clause, I presume. Eagerly awaiting the implementation, -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
On Feb 7, 4:25 pm, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: > On Thu, 07 Feb 2008 15:59:13 +0100, Wildemar Wildenburger wrote: > > Arnaud Delobelle wrote: > >> Personally, between > > >> * foo if foo else bar > >> * foo or bar > > >> I prefer the second. Maybe it could be spelt > > >> * foo else bar ? > > > How about > > > val = foo rather than bar > > > If that is not clear and obvios, I don't know what is. ;) > > In English, the expression "foo rather than bar" means "bar is never > chosen, foo is always chosen". Ok, the fix is easy: val = BETTER foo THAN bar ;-) Cobol-strikes-back-ly yours, George -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
"Denis Bilenko" <[EMAIL PROTECTED]> writes: > I convinced that this > > line = self._buffer.get(self._bufindex) > if line is None: > self._bufindex += 1 > self._lineno += 1 > self._filelineno += 1 > return line > line = self.readline() I haven't looked at the original file but the above really looks like it should use an iterator instead. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
On Thu, 07 Feb 2008 15:59:13 +0100, Wildemar Wildenburger wrote: > Arnaud Delobelle wrote: >> Personally, between >> >> * foo if foo else bar >> * foo or bar >> >> I prefer the second. Maybe it could be spelt >> >> * foo else bar ? >> > How about > > val = foo rather than bar > > If that is not clear and obvios, I don't know what is. ;) In English, the expression "foo rather than bar" means "bar is never chosen, foo is always chosen". Oh, and if you think it's hard convincing Guido to add one new keyword, wait until you try to get him to add TWO. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
On Feb 7, 12:15 pm, [EMAIL PROTECTED] wrote: > On Feb 7, 11:01 am, "Denis Bilenko" <[EMAIL PROTECTED]> wrote: > > > > > Steve Holden wrote: > > > These versions differ with respect to treatment of blank lines, which > > > indicates how easy it is to go astray in this kind of semantic > > > optimization. Your example simply wouldn't work (though you could patch > > > it up using "if line is None". (despite the use of short-circuiting > > > predicates). > > > > both examples show reduction by 3 lines. > > > > Perhaps so, but you have to realise that Python has never valued code > > > compactness over clarity. > > > I'm not sure that your democratic wish to ensure fairness to sequences > > > will garner much support, interesting though it is in an academic sense. > > > Thank you for the patch. My incentives are not academic though. > > > I convinced that this > > > line = self._buffer.get(self._bufindex) > > if line is None: > > self._bufindex += 1 > > self._lineno += 1 > > self._filelineno += 1 > > return line > > line = self.readline() > > > is more clear than > > > try: > > line = self._buffer[self._bufindex] > > except IndexError: > > pass > > else: > > self._bufindex += 1 > > self._lineno += 1 > > self._filelineno += 1 > > return line > > line = self.readline() > > > I mentioned 3 lines reduction just because it is > > objective, while 'more clear' is subjective. > > > Code snippets are again not equivalent, e.g. in the > > case when self._buffer[self._bufindex] exists and is > > equal to None. Although the author could probably > > make a guarantee that is never the case. > > This has been a pet peeve of mine too. So you are not completely > crazy: > > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/269484 > > There is a discussion about precisely this by Alex Martelli in the > printed version of the Python cookbook (2nd edition). I don't share > the opinion but I am not going to fight the core Python developers > over it. I don't think it is worth the effort. Python is so smooth > already, there has to be some excuse to add some cute hack to your > program once in a while :-). > > dict(enumerate(lst)).get(i,default) for example although not very > efficient, looks cute. I think I like it better than my own solution. Actually to clarify, I think this is more useful for tuples (or tuple like structures) than lists per se. On homogeneous lists I usually iterate. It is on heterogeneous that I want to extract specific fields that might be optional. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
Wildemar Wildenburger wrote: > Arnaud Delobelle wrote: >> Personally, between >> >> * foo if foo else bar >> * foo or bar >> >> I prefer the second. Maybe it could be spelt >> >> * foo else bar ? >> > How about > > val = foo rather than bar > > If that is not clear and obvios, I don't know what is. ;) > > /W Excellent suggestion, and obviously its semantics should be: val = foo if bar else foo and so, some might argue for: val = foo despite bar which would allow more aggressive short-circuiting. However, I'm not sure how useful this is in practice. M -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
On Feb 7, 11:01 am, "Denis Bilenko" <[EMAIL PROTECTED]> wrote: > Steve Holden wrote: > > These versions differ with respect to treatment of blank lines, which > > indicates how easy it is to go astray in this kind of semantic > > optimization. Your example simply wouldn't work (though you could patch > > it up using "if line is None". (despite the use of short-circuiting > > predicates). > > > both examples show reduction by 3 lines. > > > Perhaps so, but you have to realise that Python has never valued code > > compactness over clarity. > > I'm not sure that your democratic wish to ensure fairness to sequences > > will garner much support, interesting though it is in an academic sense. > > Thank you for the patch. My incentives are not academic though. > > I convinced that this > > line = self._buffer.get(self._bufindex) > if line is None: > self._bufindex += 1 > self._lineno += 1 > self._filelineno += 1 > return line > line = self.readline() > > is more clear than > > try: > line = self._buffer[self._bufindex] > except IndexError: > pass > else: > self._bufindex += 1 > self._lineno += 1 > self._filelineno += 1 > return line > line = self.readline() > > I mentioned 3 lines reduction just because it is > objective, while 'more clear' is subjective. > > Code snippets are again not equivalent, e.g. in the > case when self._buffer[self._bufindex] exists and is > equal to None. Although the author could probably > make a guarantee that is never the case. This has been a pet peeve of mine too. So you are not completely crazy: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/269484 There is a discussion about precisely this by Alex Martelli in the printed version of the Python cookbook (2nd edition). I don't share the opinion but I am not going to fight the core Python developers over it. I don't think it is worth the effort. Python is so smooth already, there has to be some excuse to add some cute hack to your program once in a while :-). dict(enumerate(lst)).get(i,default) for example although not very efficient, looks cute. I think I like it better than my own solution. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
Steve Holden wrote: > These versions differ with respect to treatment of blank lines, which > indicates how easy it is to go astray in this kind of semantic > optimization. Your example simply wouldn't work (though you could patch > it up using "if line is None". (despite the use of short-circuiting > predicates). > > both examples show reduction by 3 lines. > > > Perhaps so, but you have to realise that Python has never valued code > compactness over clarity. > I'm not sure that your democratic wish to ensure fairness to sequences > will garner much support, interesting though it is in an academic sense. Thank you for the patch. My incentives are not academic though. I convinced that this line = self._buffer.get(self._bufindex) if line is None: self._bufindex += 1 self._lineno += 1 self._filelineno += 1 return line line = self.readline() is more clear than try: line = self._buffer[self._bufindex] except IndexError: pass else: self._bufindex += 1 self._lineno += 1 self._filelineno += 1 return line line = self.readline() I mentioned 3 lines reduction just because it is objective, while 'more clear' is subjective. Code snippets are again not equivalent, e.g. in the case when self._buffer[self._bufindex] exists and is equal to None. Although the author could probably make a guarantee that is never the case. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
Wildemar Wildenburger wrote: > Arnaud Delobelle wrote: >> Personally, between >> >> * foo if foo else bar >> * foo or bar >> >> I prefer the second. Maybe it could be spelt >> >> * foo else bar ? >> > How about > > val = foo rather than bar > > If that is not clear and obvios, I don't know what is. ;) > Even clearer: ASSIGN foo IF foo HAS A VALUE, OTHERWISE bar, TO val Ahh, the joys of the COmmon Business Oriented Language. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
Arnaud Delobelle wrote: > Personally, between > > * foo if foo else bar > * foo or bar > > I prefer the second. Maybe it could be spelt > > * foo else bar ? > How about val = foo rather than bar If that is not clear and obvios, I don't know what is. ;) /W -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
Thomas Bellman a écrit : > Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > (snip) >> In Lisp (and IIRC), an empty list is false, anything else >> is true. > > There seems to be a language name missing from the parenthesis. Yes, sorry - I was thinking of OCaml and/or Haskell, but couldn't remember which so I cout this out but forgot the (and IIRC). -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
Denis Bilenko wrote:
> Tim Golden wrote:
>
>> Dodging your question slightly (and at the risk of teaching
>> my grandmother to suck eggs) I sometimes use this idiom for
>> checking params. Obviously it only goes so far, but it's
>> fairly compact:
>
>>
>> import os, sys
>
>> if __name__ == '__main__':
>> ARGS = None, "DEV"
>> filename, db = \
>> (j or i for i, j in map (None, ARGS, sys.argv[1:]))
>
>> print sys.argv
>> print filename, db
>
>>
>
> Thank you for the example. It demonstrates perfectly how
> much people miss this feature :)
>
>
> Raymond Hettinger wrote:
>
>> At first blush that example would make it seem like a good idea, but I
>> don't see how the example could extend past the first index. If the
>> port argument is optional, how would you know the index position of
>> optional arguments to follow?
>
>> With a dictionary, one could plausibly write:
>
>> host = d.get('host', 'http://example.com')
>> port = d.get('port', 8080)
>> path = d.get('path', '/')
>
>> But would this make sense with a list:
>
>> host = s.get(0, 'http://example.com')
>> port = d.get(1, 8080)
>> path = d.get(2, '/')
>
>> If positions 0 and 1 are optional, how do you expect to know whether
>> "path" is going to be at position 2? This problem doesn't exist with
>> dictionaries because the presence or absence of optional entries does
>> not affect the key reference to other entries. Accordingly, I
>> wouldn't expect that dict.get() would have a parallel list.get() with
>> plausible use cases.
>
> If you want to fill position 2, then positions 0 and 1 are mandatory.
> It is the simplest possible option parsing, I didn't said it was the
> most flexible :)
>
> But perhaps it was a wrong example altogether.
>
> Consider a couple more snippets, unrelated to command-line options.
> (found by searching 'IndexError' in the python standard library)
>
> this snippet from cmd.py:
>
> try:
> return self.completion_matches[state]
> except IndexError:
> return None
>
> transforms into
>
> return self.completion_matches.get(state)
>
>
> another one from fileinput.py
>
> try:
> line = self._buffer[self._bufindex]
> except IndexError:
> pass
> else:
> self._bufindex += 1
> self._lineno += 1
> self._filelineno += 1
> return line
> line = self.readline()
>
> becomes
>
> line = self._buffer.get(self._bufindex)
> if line:
> self._bufindex += 1
> self._lineno += 1
> self._filelineno += 1
> return line
> line = self.readline()
>
These versions differ with respect to treatment of blank lines, which
indicates how easy it is to go astray in this kind of semantic
optimization. Your example simply wouldn't work (though you could patch
it up using "if line is None". (despite the use of short-circuiting
predicates).
> both examples show reduction by 3 lines.
>
Perhaps so, but you have to realise that Python has never valued code
compactness over clarity.
> There's nothing dictionary-specific in 'get', it is
> just a special use-case of '__getitem__' that is needed frequently.
> Since list has '__getitem__' it deserves to have 'get' too.
I'm not sure that your democratic wish to ensure fairness to sequences
will garner much support, interesting though it is in an academic sense.
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
[EMAIL PROTECTED] wrote: > Steven D'Aprano: >> With the greatest respect, I think that if you think the second example >> "is more clear", you're completely bonkers. *grins* > It's amusing how often "with the greatest respect" is used to preface a statement that clearly implies very little respect at all. Though, for what it's worth, I agree with Steven here. > No one is completely normal, I presume :-) > I'd like to know what others think about it, about this anti-feature. > What I can say is that other computer languages too think that boolean > operations must return boolean values only, so I am not alone in my > folly :-) > Other languages do indeed refuse the temptation to short-circuit, but that doesn't mean that Python is wrong to do so. It's a design choice, and while you are free to disagree with it I imagine you would be pissing in the wind in attempting to get a change like that into Python 3. Most people like the semantics of "and" and "or" as they are. no-more-normal-than-anyone-else-ly y'rs - steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Not quite. In C and a couple other langages, int 0 is false, anything > else is true. Not just int, but all kinds of integers, as well as all kinds of floating point types and all kinds of pointers, with the value 0 are considered false. And structs and unions can't be used in a boolean context at all, and are thus neither true nor false. > In Lisp (and IIRC), an empty list is false, anything else > is true. There seems to be a language name missing from the parenthesis. Were you perhaps thinking of Scheme? If so, then no, in Scheme only #f is false, and the empty list () is considered true. -- Thomas Bellman, Lysator Computer Club, Linköping University, Sweden "When C++ is your hammer, everything ! bellman @ lysator.liu.se looks like a thumb."! Make Love -- Nicht Wahr! -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
[EMAIL PROTECTED] a écrit : > Steven D'Aprano: >> With the greatest respect, I think that if you think the second example >> "is more clear", you're completely bonkers. *grins* > > No one is completely normal, I presume :-) > I'd like to know what others think about it, about this anti-feature. s/anti// > What I can say is that other computer languages too think that boolean > operations must return boolean values only, Not quite. In C and a couple other langages, int 0 is false, anything else is true. In Lisp (and IIRC), an empty list is false, anything else is true. I'm sure someone else could come with more than a couple other non-cryptic langages that just don't have a proper boolean type. Using "emptyness" as a false value in boolean expressions is not that uncommon, and it has proven so far to be a working solution. Also, returning the tested object instead of a bool just makes sens to me. FWIW, booleans are a late addition to Python, and quite a couple persons where worried that it would only lead to confusion. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
Denis Bilenko wrote: > Raymond Hettinger wrote: >> If positions 0 and 1 are optional, how do you expect to know whether >> "path" is going to be at position 2? This problem doesn't exist with >> dictionaries because the presence or absence of optional entries does >> not affect the key reference to other entries. Accordingly, I >> wouldn't expect that dict.get() would have a parallel list.get() with >> plausible use cases. > > If you want to fill position 2, then positions 0 and 1 are mandatory. > It is the simplest possible option parsing, I didn't said it was the > most flexible :) d = dict(enumerate(args)) print d[0], d[1], d.get(2) Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
On Feb 7, 8:20 am, [EMAIL PROTECTED] wrote: > Paul Rubin: > > > I like the suggestion, except it should be > > port = int(sys.argv.get(1, '8000')) > > one could imagine your example going wrong in a protocol where 0 is > > a valid port number. > > I think a high-level language like Python must have boolean operators > (or and not) that behave in a much more clean way, with a simpler > semantics. That is they have to return only true or false. Otherwise > they are just a source of bugs and confusion. This is a change fit for > Python 3. > That trick with or/and may look good for Perl, but it's unfit for a > language that tries to be clear, readable from people that don't know > it much, and good to learn to program. Python has now the if-then > expression too that is more clear. > > Bye, > bearophile Personally, between * foo if foo else bar * foo or bar I prefer the second. Maybe it could be spelt * foo else bar ? Moreover between the following two: * foores = foo() foobar = foores if foores else bar * foobar = foo() or bar I also prefer the second. Maybe it could be spelt * foo() else bar ? I have not thought of parsing issues :) -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
Steven D'Aprano: > With the greatest respect, I think that if you think the second example > "is more clear", you're completely bonkers. *grins* No one is completely normal, I presume :-) I'd like to know what others think about it, about this anti-feature. What I can say is that other computer languages too think that boolean operations must return boolean values only, so I am not alone in my folly :-) Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
Tim Golden wrote:
> Dodging your question slightly (and at the risk of teaching
> my grandmother to suck eggs) I sometimes use this idiom for
> checking params. Obviously it only goes so far, but it's
> fairly compact:
>
> import os, sys
> if __name__ == '__main__':
> ARGS = None, "DEV"
> filename, db = \
> (j or i for i, j in map (None, ARGS, sys.argv[1:]))
> print sys.argv
> print filename, db
>
Thank you for the example. It demonstrates perfectly how
much people miss this feature :)
Raymond Hettinger wrote:
> At first blush that example would make it seem like a good idea, but I
> don't see how the example could extend past the first index. If the
> port argument is optional, how would you know the index position of
> optional arguments to follow?
> With a dictionary, one could plausibly write:
> host = d.get('host', 'http://example.com')
> port = d.get('port', 8080)
> path = d.get('path', '/')
> But would this make sense with a list:
> host = s.get(0, 'http://example.com')
> port = d.get(1, 8080)
> path = d.get(2, '/')
> If positions 0 and 1 are optional, how do you expect to know whether
> "path" is going to be at position 2? This problem doesn't exist with
> dictionaries because the presence or absence of optional entries does
> not affect the key reference to other entries. Accordingly, I
> wouldn't expect that dict.get() would have a parallel list.get() with
> plausible use cases.
If you want to fill position 2, then positions 0 and 1 are mandatory.
It is the simplest possible option parsing, I didn't said it was the
most flexible :)
But perhaps it was a wrong example altogether.
Consider a couple more snippets, unrelated to command-line options.
(found by searching 'IndexError' in the python standard library)
this snippet from cmd.py:
try:
return self.completion_matches[state]
except IndexError:
return None
transforms into
return self.completion_matches.get(state)
another one from fileinput.py
try:
line = self._buffer[self._bufindex]
except IndexError:
pass
else:
self._bufindex += 1
self._lineno += 1
self._filelineno += 1
return line
line = self.readline()
becomes
line = self._buffer.get(self._bufindex)
if line:
self._bufindex += 1
self._lineno += 1
self._filelineno += 1
return line
line = self.readline()
both examples show reduction by 3 lines.
There's nothing dictionary-specific in 'get', it is
just a special use-case of '__getitem__' that is needed frequently.
Since list has '__getitem__' it deserves to have 'get' too.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
On Thu, 07 Feb 2008 00:20:52 -0800, bearophileHUGS wrote: > I think a high-level language like Python must have boolean operators > (or and not) that behave in a much more clean way, with a simpler > semantics. That is they have to return only true or false. Otherwise > they are just a source of bugs and confusion. Well, that's one opinion. Boolean operators can be complicated to understand if you write complicated expressions, or if you don't understand what they do. But otherwise, they're no more complicated than arithmetic expressions. [...] > That trick with or/and may look good for Perl, but it's unfit for a > language that tries to be clear, readable from people that don't know it > much, and good to learn to program. Python has now the if-then > expression too that is more clear. Suppose I have two lists, and want to process the first one if it is not empty, otherwise process the second. I'd write it like this: process(mylist or yourlist) You're suggesting I should write it like this: process(mylist if mylist else yourlist) With the greatest respect, I think that if you think the second example "is more clear", you're completely bonkers. *grins* -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
Denis Bilenko wrote: > Why does list have no 'get' method with exactly the same semantics as > dict's get, > that is "return an element if there is one, but do NOT raise > an exception if there is not.": > > def get(self, item, default = None): > try: > return self[item] > except IndexError: > return default > > It is often desirable, for example, when one uses the easiest > command-line options parsing - based on absolute positions: Dodging your question slightly (and at the risk of teaching my grandmother to suck eggs) I sometimes use this idiom for checking params. Obviously it only goes so far, but it's fairly compact: import os, sys if __name__ == '__main__': ARGS = None, "DEV" filename, db = \ (j or i for i, j in map (None, ARGS, sys.argv[1:])) print sys.argv print filename, db TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
[EMAIL PROTECTED] wrote: > Paul Rubin: >> I like the suggestion, except it should be >> port = int(sys.argv.get(1, '8000')) >> one could imagine your example going wrong in a protocol where 0 is >> a valid port number. > > I think a high-level language like Python must have boolean operators > (or and not) that behave in a much more clean way, with a simpler > semantics. That is they have to return only true or false. Otherwise > they are just a source of bugs and confusion. This is a change fit for > Python 3. Conditional expressions have clear semantics. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
Paul Rubin: > I like the suggestion, except it should be > port = int(sys.argv.get(1, '8000')) > one could imagine your example going wrong in a protocol where 0 is > a valid port number. I think a high-level language like Python must have boolean operators (or and not) that behave in a much more clean way, with a simpler semantics. That is they have to return only true or false. Otherwise they are just a source of bugs and confusion. This is a change fit for Python 3. That trick with or/and may look good for Perl, but it's unfit for a language that tries to be clear, readable from people that don't know it much, and good to learn to program. Python has now the if-then expression too that is more clear. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
[Denis Bilenko]
> Why does list have no 'get' method with exactly the same semantics as
> dict's get,
> that is "return an element if there is one, but do NOT raise
> an exception if there is not.":
. . .
> It is often desirable, for example, when one uses the easiest
> command-line options parsing - based on absolute positions:
>
> With such a method instead of this (snippet from BaseHTTPServer.py)
>
> if sys.argv[1:]:
> port = int(sys.argv[1])
> else:
> port = 8000
>
> we could write
>
> port = sys.argv.get(1) or 8000
At first blush that example would make it seem like a good idea, but I
don't see how the example could extend past the first index. If the
port argument is optional, how would you know the index position of
optional arguments to follow?
With a dictionary, one could plausibly write:
host = d.get('host', 'http://example.com')
port = d.get('port', 8080)
path = d.get('path', '/')
But would this make sense with a list:
host = s.get(0, 'http://example.com')
port = d.get(1, 8080)
path = d.get(2, '/')
If positions 0 and 1 are optional, how do you expect to know whether
"path" is going to be at position 2? This problem doesn't exist with
dictionaries because the presence or absence of optional entries does
not affect the key reference to other entries. Accordingly, I
wouldn't expect that dict.get() would have a parallel list.get() with
plausible use cases.
Raymond
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why does list have no 'get' method?
"Denis Bilenko" <[EMAIL PROTECTED]> writes: > port = sys.argv.get(1) or 8000 I like the suggestion, except it should be port = int(sys.argv.get(1, '8000')) one could imagine your example going wrong in a protocol where 0 is a valid port number. -- http://mail.python.org/mailman/listinfo/python-list
Why does list have no 'get' method?
Why does list have no 'get' method with exactly the same semantics as dict's get, that is "return an element if there is one, but do NOT raise an exception if there is not.": def get(self, item, default = None): try: return self[item] except IndexError: return default It is often desirable, for example, when one uses the easiest command-line options parsing - based on absolute positions: With such a method instead of this (snippet from BaseHTTPServer.py) if sys.argv[1:]: port = int(sys.argv[1]) else: port = 8000 we could write port = sys.argv.get(1) or 8000 which is both more condense and more clear. The change is unlikely to break anyone's code. (nobody uses getattr(obj, 'get') to distinguish between lists and dicts, right?) -- http://mail.python.org/mailman/listinfo/python-list
