Re: Expression can be simplified on list

On Fri, 30 Sep 2016 05:58 am, Random832 wrote: > On Thu, Sep 29, 2016, at 02:47, Rustom Mody wrote: >> Your example is exactly what I am saying; if a type has a behavior in >> which all values are always True (true-ish) its a rather strange kind >> of bool-nature. > > For a given type T, if all o

Re: Expression can be simplified on list

On Fri, Sep 30, 2016 at 5:58 AM, Random832 wrote: > On Thu, Sep 29, 2016, at 02:47, Rustom Mody wrote: >> Your example is exactly what I am saying; if a type has a behavior in >> which all values are always True (true-ish) its a rather strange kind >> of bool-nature. > > For a given type T, if all

Re: Expression can be simplified on list

On Thu, Sep 29, 2016, at 02:47, Rustom Mody wrote: > Your example is exactly what I am saying; if a type has a behavior in > which all values are always True (true-ish) its a rather strange kind > of bool-nature. For a given type T, if all objects of type T are true (true-ish, truthy, whatever), i

Re: Expression can be simplified on list

On 9/29/2016 2:47 AM, Rustom Mody wrote: On Thursday, September 15, 2016 at 1:43:05 AM UTC+5:30, Terry Reedy wrote: On 9/14/2016 3:16 AM, Rustom Mody wrote: In THOSE TYPES that element can justifiably serve as a falsey (empty) type However to extrapolate from here and believe that ALL TYPES c

Re: Expression can be simplified on list

On 9/29/2016 12:36 PM, MRAB wrote: On 2016-09-29 16:56, Steve D'Aprano wrote: On Thu, 29 Sep 2016 09:53 pm, MRAB wrote: What if an _exhausted_ iterator was falsey? Logic is about binary distinctions, rather than about 'truth'. For non-buggy iterator it, the useful binary distinction is whe

Re: Expression can be simplified on list

On 2016-09-29 09:14, Steven D'Aprano wrote: On Thursday 29 September 2016 16:47, Rustom Mody wrote: On Thursday, September 15, 2016 at 1:43:05 AM UTC+5:30, Terry Reedy wrote: [...] Python make no such nonsense claim. By default, Python objects are truthy. >>> bool(object()) True Because T

Re: Expression can be simplified on list

On Fri, Sep 30, 2016 at 2:36 AM, MRAB wrote: > On 2016-09-29 16:56, Steve D'Aprano wrote: >> >> On Thu, 29 Sep 2016 09:53 pm, MRAB wrote: >> >>> What if an _exhausted_ iterator was falsey? >> >> >> >> The problem is that in general you can't tell if an iterator is exhausted >> until you attempt to

Re: Expression can be simplified on list

On 2016-09-29 16:56, Steve D'Aprano wrote: On Thu, 29 Sep 2016 09:53 pm, MRAB wrote: What if an _exhausted_ iterator was falsey? The problem is that in general you can't tell if an iterator is exhausted until you attempt to advance it. So even if bool(iterator) returns True, the call to next

Re: Expression can be simplified on list

On Thu, 29 Sep 2016 09:53 pm, MRAB wrote: > What if an _exhausted_ iterator was falsey? The problem is that in general you can't tell if an iterator is exhausted until you attempt to advance it. So even if bool(iterator) returns True, the call to next() may raise StopIteration: def gen(): y

Re: Expression can be simplified on list

MRAB wrote: > What if an _exhausted_ iterator was falsey? Many would expect it = iter("abc") while it: print(next(it)) to work (i. e. no StopIteration) -- if it doesn't, what's the actual usecase? If it does work there must be some lookahead which not all iterators can provide in a meani

Re: Expression can be simplified on list

On 2016-09-29 10:49, Steven D'Aprano wrote: On Thursday 29 September 2016 18:45, Jussi Piitulainen wrote: [snip] What do you say about things like iterators and generators? I'd say they are containers, but they count as true even when they are empty. No, they aren't containers, because they d

Re: Expression can be simplified on list

On Thursday 29 September 2016 18:45, Jussi Piitulainen wrote: > Steven D'Aprano writes: > > [- -] > >> What is this truthiness abstraction? It is the difference between >> "something" and "nothing". >> >> Values which represent nothing, e.g.: >> >> - None >> - numeric zero: 0, 0.0, 0j, Decimal(0

Re: Expression can be simplified on list

On Thursday, September 29, 2016 at 7:48:41 PM UTC+13, Rustom Mody wrote: > - And then uses a value of that type in a non-trivial bool-consuming position > such as the condition of an if/while etc > > There's a very good chance that bool-usage is buggy 👍 -- https://mail.python.org/mailman/listinf

Re: Expression can be simplified on list

On Thu, Sep 29, 2016 at 6:45 PM, Jussi Piitulainen wrote: > What do you say about things like iterators and generators? I'd say they > are containers, but they count as true even when they are empty. > > bool(x for x in [3,1] if x in [2,7]) # True > list(x for x in [3,1] if x in [2,7]) # [] > > I

Re: Expression can be simplified on list

Steven D'Aprano writes: [- -] > What is this truthiness abstraction? It is the difference between > "something" and "nothing". > > Values which represent nothing, e.g.: > > - None > - numeric zero: 0, 0.0, 0j, Decimal(0) etc > - empty strings u'', '' > - empty containers [], (), {} etc. > > are t

Re: Expression can be simplified on list

On Thursday 29 September 2016 16:47, Rustom Mody wrote: > On Thursday, September 15, 2016 at 1:43:05 AM UTC+5:30, Terry Reedy wrote: [...] >> Python make no such nonsense claim. By default, Python objects are truthy. >> >> >>> bool(object()) >> True >> >> Because True is the default, object ne

Re: Expression can be simplified on list

On Thu, Sep 29, 2016 at 4:47 PM, Rustom Mody wrote: >> Because True is the default, object need not and at least in CPython >> does not have a __bool__ (or __len__) method. Classes with no falsey >> objects, such as functions, generators, and codes, need not do anything >> either. In the absence

Re: Expression can be simplified on list

On Thursday, September 15, 2016 at 1:43:05 AM UTC+5:30, Terry Reedy wrote: > On 9/14/2016 3:16 AM, Rustom Mody wrote: > > > In THOSE TYPES that element can justifiably serve as a falsey (empty) type > > > > However to extrapolate from here and believe that ALL TYPES can have a > > falsey > > valu

Re: Expression can be simplified on list

Daiyue Weng writes: > Hi, I found that when I tried to make an equality test on empty like, > > if errors == []: > > PyCharm always warns me, > > Expression can be simplified. > > I am wondering what's wrong and how to fix this? > It is not wrong, but it can be simplified to just: if errors: Th

Re: Expression can be simplified on list

Rustom Mody writes: > On Wednesday, September 14, 2016 at 5:35:53 PM UTC+5:30, Jussi Piitulainen > wrote: >> Mathematical discussions tend to acknowledge only alternation >> (union), concatenation and iteration (Kleene star) as operations, >> unless they specifically focus on some other operatio

Re: Expression can be simplified on list

On Thu, 15 Sep 2016 08:46 am, Lawrence D’Oliveiro wrote: > On Thursday, September 15, 2016 at 9:12:25 AM UTC+12, Ned Batchelder > wrote: >> >> On Wednesday, September 14, 2016 at 5:00:02 PM UTC-4, Lawrence D’Oliveiro >> wrote: >>> >>> On Thursday, September 15, 2016 at 8:13:05 AM UTC+12, Terry Ree

Re: Expression can be simplified on list

On Thursday, September 15, 2016 at 9:12:25 AM UTC+12, Ned Batchelder wrote: > > On Wednesday, September 14, 2016 at 5:00:02 PM UTC-4, Lawrence D’Oliveiro > wrote: >> >> On Thursday, September 15, 2016 at 8:13:05 AM UTC+12, Terry Reedy wrote: >>> >>> Because True is the default, object need not and

Re: Expression can be simplified on list

On Wednesday, September 14, 2016 at 5:00:02 PM UTC-4, Lawrence D’Oliveiro wrote: > On Thursday, September 15, 2016 at 8:13:05 AM UTC+12, Terry Reedy wrote: > > Because True is the default, object need not and at least in CPython > > does not have a __bool__ (or __len__) method. > > If they had to

Re: Expression can be simplified on list

On Thu, Sep 15, 2016 at 6:59 AM, Lawrence D’Oliveiro wrote: > On Thursday, September 15, 2016 at 8:13:05 AM UTC+12, Terry Reedy wrote: >> Because True is the default, object need not and at least in CPython >> does not have a __bool__ (or __len__) method. > > If they had to (in the absence of whic

Re: Expression can be simplified on list

On Thursday, September 15, 2016 at 8:13:05 AM UTC+12, Terry Reedy wrote: > Because True is the default, object need not and at least in CPython > does not have a __bool__ (or __len__) method. If they had to (in the absence of which a bool() cast would not work), then that would help prevent prob

Re: Expression can be simplified on list

On 9/14/2016 8:05 AM, Jussi Piitulainen wrote: Serhiy Storchaka writes: On 14.09.16 11:28, Steven D'Aprano wrote: I'm not sure if it makes sense to talk about an "empty regular expression", or if that is the same as re.compile(''). Presumably if such a thing makes sense, it would match nothi

Re: Expression can be simplified on list

On 9/14/2016 3:16 AM, Rustom Mody wrote: In THOSE TYPES that element can justifiably serve as a falsey (empty) type However to extrapolate from here and believe that ALL TYPES can have a falsey value meaningfully, especially in some obvious fashion, is mathematically nonsense. Python make no

Re: Expression can be simplified on list

On Wednesday, September 14, 2016 at 5:35:53 PM UTC+5:30, Jussi Piitulainen wrote: > Mathematical discussions tend to acknowledge only alternation (union), > concatenation and iteration (Kleene star) as operations, unless they > specifically focus on some other operations that can, in principle, be

Re: Expression can be simplified on list

Serhiy Storchaka writes: > On 14.09.16 11:28, Steven D'Aprano wrote: >> I'm not sure if it makes sense to talk about an "empty regular >> expression", or if that is the same as re.compile(''). Presumably if >> such a thing makes sense, it would match nothing, from any input at >> all. > > Actuall

Re: Expression can be simplified on list

On Wed, Sep 14, 2016 at 8:46 PM, Serhiy Storchaka wrote: > On 14.09.16 11:28, Steven D'Aprano wrote: >> >> I'm not sure if it makes sense to talk about an "empty regular >> expression", or >> if that is the same as re.compile(''). Presumably if such a thing makes >> sense, >> it would match nothin

Re: Expression can be simplified on list

On 14.09.16 11:28, Steven D'Aprano wrote: I'm not sure if it makes sense to talk about an "empty regular expression", or if that is the same as re.compile(''). Presumably if such a thing makes sense, it would match nothing, from any input at all. Actually, it matches anything. re.compile('').ma

Re: Expression can be simplified on list

On Wednesday 14 September 2016 17:16, Rustom Mody wrote: > On Wednesday, September 14, 2016 at 10:23:12 AM UTC+5:30, Steven D'Aprano > wrote: >> And if somebody designed an iterator that behaved badly or surprisingly, >> would you conclude that the entire concept of iteration is therefore broken?

Re: Expression can be simplified on list

On Wednesday, September 14, 2016 at 10:17:27 AM UTC+5:30, Steven D'Aprano wrote: > You're perfectly entitled to dislike duck-typed truthiness. But that makes > the > majority of dynamically-typed languages (like Python, Javascript, Ruby, Lua > and > more) a bad fit for your way of thinking. Ye

Re: Expression can be simplified on list

On Wednesday, September 14, 2016 at 10:23:12 AM UTC+5:30, Steven D'Aprano wrote: > On Wednesday 14 September 2016 13:59, Lawrence D’Oliveiro wrote: > > > On Wednesday, September 14, 2016 at 2:25:48 PM UTC+12, Ben Finney wrote: > >> Lawrence D’Oliveiro writes: > >> > >> > It would be better if all

Re: Expression can be simplified on list

On Wednesday 14 September 2016 13:59, Lawrence D’Oliveiro wrote: > On Wednesday, September 14, 2016 at 2:25:48 PM UTC+12, Ben Finney wrote: >> Lawrence D’Oliveiro writes: >> >> > It would be better if all such conversions were explicit >> >> Why? It's entirely unambiguous ... > >

Re: Expression can be simplified on list

Lawrence D’Oliveiro writes: > On Wednesday, September 14, 2016 at 2:25:48 PM UTC+12, Ben Finney wrote: >> Lawrence D’Oliveiro writes: >> >> > It would be better if all such conversions were explicit >> >> Why? It's entirely unambiguous ... > > That's the story

Re: Expression can be simplified on list

On Wednesday 14 September 2016 12:16, Lawrence D’Oliveiro wrote: > On Tuesday, September 13, 2016 at 2:33:40 PM UTC+12, Ned Batchelder wrote: >> Why do you object to the type conversion to bool? > > It would be better if all such conversions were explicit, e.g. > > if bool(«non-bool expr») :

Re: Expression can be simplified on list

Lawrence D’Oliveiro writes: > On Wednesday, September 14, 2016 at 2:25:48 PM UTC+12, Ben Finney wrote: > > Lawrence D’Oliveiro writes: > > > > > It would be better if all such conversions were explicit > > > > Why? It's entirely unambiguous: the expression of an ‘if’ statement > > *can only be*

Re: Expression can be simplified on list

On Wednesday, September 14, 2016 at 2:25:48 PM UTC+12, Ben Finney wrote: > Lawrence D’Oliveiro writes: > > > It would be better if all such conversions were explicit > > Why? It's entirely unambiguous ... -- https://mail.python.org/mailman/listinfo/python-list

Re: Expression can be simplified on list

On Wed, Sep 14, 2016 at 12:25 PM, Ben Finney wrote: > Lawrence D’Oliveiro writes: > >> On Tuesday, September 13, 2016 at 2:33:40 PM UTC+12, Ned Batchelder wrote: >> > Why do you object to the type conversion to bool? >> >> It would be better if all such conversions were explicit > > Why? It's ent

Re: Expression can be simplified on list

Lawrence D’Oliveiro writes: > On Tuesday, September 13, 2016 at 2:33:40 PM UTC+12, Ned Batchelder wrote: > > Why do you object to the type conversion to bool? > > It would be better if all such conversions were explicit Why? It's entirely unambiguous: the expression of an ‘if’ statement *can onl

Re: Expression can be simplified on list

On Tuesday, September 13, 2016 at 2:33:40 PM UTC+12, Ned Batchelder wrote: > Why do you object to the type conversion to bool? It would be better if all such conversions were explicit, e.g. if bool(«non-bool expr») : if not bool(«non-bool expr») : instead of if «non-bool expr» :

Re: Expression can be simplified on list

On Wed, Sep 14, 2016 at 9:16 AM, Thomas 'PointedEars' Lahn wrote: > Chris Angelico wrote: > >> […] Thomas 'PointedEars' Lahn […] wrote: >>> If I knew that it is always going to be a list or a tuple, I would check >>> its length instead: >>> >>> if len(errors) == 0: >> >> I wouldn't. I'd use bool

Re: Expression can be simplified on list

Chris Angelico wrote: > […] Thomas 'PointedEars' Lahn […] wrote: >> If I knew that it is always going to be a list or a tuple, I would check >> its length instead: >> >> if len(errors) == 0: > > I wouldn't. I'd use boolification here too. Only if I had to > distinguish between None, [], and [1,

Re: Expression can be simplified on list

On Monday, September 12, 2016 at 5:21:51 PM UTC-4, Thomas 'PointedEars' Lahn wrote: > Chris Angelico wrote: > > > On Mon, Sep 12, 2016 at 9:14 PM, Daiyue Weng wrote: > > If you know that 'errors' is always going to be a list, you can check > > for emptiness thus: > > > > if not errors: > > If

Re: Expression can be simplified on list

On Tue, Sep 13, 2016 at 7:21 AM, Thomas 'PointedEars' Lahn wrote: > If I knew that it is always going to be a list or a tuple, I would check its > length instead: > > if len(errors) == 0: I wouldn't. I'd use boolification here too. Only if I had to distinguish between None, [], and [1,2,3], wou

Re: Expression can be simplified on list

Chris Angelico wrote: > On Mon, Sep 12, 2016 at 9:14 PM, Daiyue Weng wrote: >> Hi, I found that when I tried to make an equality test on empty like, >> >> if errors == []: >> >> PyCharm always warns me, >> >> Expression can be simplified. >> >> I am wondering what's wrong and how to fix this? >>

Re: Expression can be simplified on list

On Mon, Sep 12, 2016 at 9:14 PM, Daiyue Weng wrote: > Hi, I found that when I tried to make an equality test on empty like, > > if errors == []: > > PyCharm always warns me, > > Expression can be simplified. > > I am wondering what's wrong and how to fix this? > If you know that 'errors' is alway

Re: possible bug in re expression?

On 28/04/2014 12:49, Steven D'Aprano wrote: .. Well, I don't know about "almost any", but at least some broken regexes will explicitly fail: py> import re sre_constants.error: nothing to repeat (For brevity I have abbreviated the traceback.) so there is intent to catch some

Re: possible bug in re expression?

On Mon, 28 Apr 2014 10:47:54 +0100, Robin Becker wrote: > Does this in fact that almost any broken regexp specification will > silently fail because re will reset and consider any metacharacter as > literal? Well, I don't know about "almost any", but at least some broken regexes will explicitly

Re: possible bug in re expression?

On 25/04/2014 19:32, Terry Reedy wrote: .. I suppose that one could argue that '{' alone should be treated as special immediately, and not just when a matching '}' is found, and should disable other special meanings. I wonder what JS does if there is no matching '}'? well in fact I susp

Re: possible bug in re expression?

On Fri, 25 Apr 2014 14:32:30 -0400, Terry Reedy wrote: > On 4/25/2014 12:30 PM, Robin Becker wrote: [...] >> should >> >> re.compile('.{1,+3}') >> >> raise an error? It doesn't on python 2.7 or 3.3. > > And it should not because it is not an error. '+' means 'match 1 or more > occurrences of the

Re: possible bug in re expression?

On 4/25/2014 12:30 PM, Robin Becker wrote: Whilst translating some javascript code I find that this A=re.compile('.{1,+3}').findall(p) doesn't give any error, but doesn't manage to find the strings in p that I want len(A)==>0, the correct translation should have been A=re.compile('.{1,3}').fin

Re: possible bug in re expression?

On 2014-04-25 17:55, Chris Angelico wrote: On Sat, Apr 26, 2014 at 2:30 AM, Robin Becker wrote: Whilst translating some javascript code I find that this A=re.compile('.{1,+3}').findall(p) doesn't give any error, but doesn't manage to find the strings in p that I want len(A)==>0, the correct t

Re: possible bug in re expression?

On Sat, Apr 26, 2014 at 2:30 AM, Robin Becker wrote: > Whilst translating some javascript code I find that this > > A=re.compile('.{1,+3}').findall(p) > > doesn't give any error, but doesn't manage to find the strings in p that I > want len(A)==>0, the correct translation should have been > > A=re

possible bug in re expression?

Whilst translating some javascript code I find that this A=re.compile('.{1,+3}').findall(p) doesn't give any error, but doesn't manage to find the strings in p that I want len(A)==>0, the correct translation should have been A=re.compile('.{1,3}').findall(p) which works fine. should re.com

Re: Expression problem.

On 6 okt, 15:25, Peter Otten <__pete...@web.de> wrote: > Nethirlon . wrote: > > On 6 okt, 11:53, Peter Otten <__pete...@web.de> wrote: > >> Sebastiaan de Haan wrote: > >> > Thank you Chris, > > >> > I'll try and find the attribute in the code. That was my conclusion > >> > aswell... The original au

Re: Expression problem.

Nethirlon . wrote: > On 6 okt, 11:53, Peter Otten <__pete...@web.de> wrote: >> Sebastiaan de Haan wrote: >> > Thank you Chris, >> >> > I'll try and find the attribute in the code. That was my conclusion >> > aswell... The original author must have defined it somewhere... >> >> Don't forget to chec

Re: Expression problem.

On 6 okt, 11:53, Peter Otten <__pete...@web.de> wrote: > Sebastiaan de Haan wrote: > > Thank you Chris, > > > I'll try and find the attribute in the code. That was my conclusion > > aswell... The original author must have defined it somewhere... > > Don't forget to check whether the object's class

Re: Expression problem.

Sebastiaan de Haan wrote: > Thank you Chris, > > I'll try and find the attribute in the code. That was my conclusion > aswell... The original author must have defined it somewhere... Don't forget to check whether the object's class (or any of its bases) has a __getattr__() or __getattribute__()

Re: Expression problem.

Thank you Chris, I'll try and find the attribute in the code. That was my conclusion aswell... The original author must have defined it somewhere... Thanks. On Wed, Oct 6, 2010 at 10:59 AM, Chris Rebert wrote: > On Wed, Oct 6, 2010 at 1:32 AM, Nethirlon . wrote: >> Hi, >> >> I am having troubl

Re: Expression problem.

On Wed, Oct 6, 2010 at 1:32 AM, Nethirlon . wrote: > Hi, > > I am having trouble with an expression. > > I have the following line of code: > > self.failUnless(c.as == 65215) > > What happens when you compile this is that you get a syntax error. > This is because as has been made a keyword. failUn

Re: expression in an if statement

Thomas Jollans wrote: What if "set" has side effects? A compiler could only exclude this possibility if it knew exactly what "set" will be at run time, And also that 'a' remains bound to the same object, and that object or anything reachable from it is not mutated in any way that could affect

Re: expression in an if statement

John Nagle wrote: > I was talking to the Facebook guys doing the compiler for PHP, and they > said that it was a huge win for them that PHP doesn't allow dynamically > replacing a function. I'm not sure if I call all that effort for a 50% speed increase a win. PyPy is seeing speed increases of up

Re: expression in an if statement

On 8/18/2010 3:12 PM, Thomas Jollans wrote: On Wednesday 18 August 2010, it occurred to John Nagle to exclaim: On 8/18/2010 11:24 AM, ernest wrote: Hi, In this code: if set(a).union(b) == set(a): pass Does Python compute set(a) twice? CPython does. Shed Skin might optimize. Don't kn

Re: expression in an if statement

On 19 Ago, 08:40, Frederic Rentsch wrote: > On Thu, 2010-08-19 at 00:12 +0200, Thomas Jollans wrote: > > On Wednesday 18 August 2010, it occurred to John Nagle to exclaim: > > > On 8/18/2010 11:24 AM, ernest wrote: > > > > Hi, > > > > > In this code: > > > > > if set(a).union(b) == set(a): pass >

Re: expression in an if statement

On Thu, 2010-08-19 at 00:12 +0200, Thomas Jollans wrote: > On Wednesday 18 August 2010, it occurred to John Nagle to exclaim: > > On 8/18/2010 11:24 AM, ernest wrote: > > > Hi, > > > > > > In this code: > > > > > > if set(a).union(b) == set(a): pass > > > > > > Does Python compute set(a) twice?

Re: expression in an if statement

On Thu, Aug 19, 2010 at 9:12 AM, Thomas Jollans wrote: > I doubt any actual Python implementation optimizes this -- how could it? > The > object "set" is clearly being called twice, and it happens to be called > with > the object "a" as a sole argument twice. What if "set" has side effects? A > c

Re: expression in an if statement

On Wednesday 18 August 2010, it occurred to John Nagle to exclaim: > On 8/18/2010 11:24 AM, ernest wrote: > > Hi, > > > > In this code: > > > > if set(a).union(b) == set(a): pass > > > > Does Python compute set(a) twice? > > CPython does. Shed Skin might optimize. Don't know > about Iron

Re: expression in an if statement

On 8/18/2010 11:24 AM, ernest wrote: Hi, In this code: if set(a).union(b) == set(a): pass Does Python compute set(a) twice? CPython does. Shed Skin might optimize. Don't know about Iron Python. John Nagle -- http://mail.python.org/mailman/listinf

Re: expression in an if statement

ernest wrote: > In this code: > > if set(a).union(b) == set(a): pass > > Does Python compute set(a) twice? >>> a = "abc" >>> b = "def" >>> _set = set >>> def set(x): ... print "computing set(%r)" % x ... return _set(x) ... >>> if set(a).union(b) == set(a): pass ... computing set('abc')

Re: Expression

Lydia wrote: I am working on calculating one of the fields in a feature class based on other 2 fields. The logic is, A (the resulting field) is calculated from B, but C and D have part of the value that could fill the blank of B, which meaning that combine three fields of values can make A. F

Re: expression IF (was: Why does python not have a mechanism for data hiding?)

BJörn Lindqvist wrote: On Wed, Jun 4, 2008 at 2:02 PM, Antoon Pardon <[EMAIL PROTECTED]> wrote: Now of course noone would defend such a limitation on the grounds that one doesn't need the general case and that the general case will only save you some vertical space. But when it came to the tern

Re: expression form of one-to-many dict?

Mike Meyer <[EMAIL PROTECTED]> wrote: > > As in, say, calling > > x = ternary(c, lambda:t, lambda:f) > > ? The 'lambda:' is a (not nice-looking, but...) "indication of > > non-evaluation"... or am I misundertanding what you're saying? > > No, you're saying it exactly right. And that does, in

Re: Lazy argument evaluation (was Re: expression form of one-to-many dict?)

Steven Bethard wrote: There must be something wrong with this idea that I'm missing. . . Well, it does cost you some conciceness, as your examples show[1]: lazy(mul, x, y) v.s. :x * y lazy(itemgetter(i), x) v.s. :x[i] lazy(attrgetter("a"), x)v.s.

Re: Lazy argument evaluation (was Re: expression form of one-to-many dict?)

Nick Coghlan wrote: def lazycall(x, *args, **kwds): """Executes x(*args, **kwds)() when called""" return lambda : x(*args, **kwds)() It occurred to me that this should be: def lazycall(x, *args, **kwds): """Executes x()(*args, **kwds) when called""" return lambda : x()(*args, **kwds) (Not

Re: expression form of one-to-many dict?

[EMAIL PROTECTED] (Alex Martelli) writes: > Mike Meyer <[EMAIL PROTECTED]> wrote: > >> [EMAIL PROTECTED] (Bengt Richter) writes: >> >> > On Sun, 19 Dec 2004 21:29:27 +0100, "Fredrik Lundh" > <[EMAIL PROTECTED]> wrote: >> > (or maybe a restricted unquote_arg function for better safety). >> > E.g.,

Re: Lazy argument evaluation (was Re: expression form of one-to-many dict?)

Nick Coghlan wrote: def lazy(x, *args, **kwds): """Executes x(*args, **kwds) when called""" if args or kwds: return lambda : x(*args, **kwds) else: return x # No arguments, so x must be callable by itself [snip] Huh. I think I like the idea of lazy() much better than I like the curre

Lazy argument evaluation (was Re: expression form of one-to-many dict?)

Mike Meyer wrote: Personally, I'd love a language feature that let you create a function that didn't evaluate arguments until they were actually used - lazy evaluation. That lets you write the C ?: operator as a function, for a start. The basic idea is to just specify that those arguments must be z

Re: expression form of one-to-many dict?

Doug Holton wrote: > Mike Meyer wrote: > >> Personally, I'd love a language feature that let you create a function >> that didn't evaluate arguments until they were actually used - lazy >> evaluation. That lets you write the C ?: operator as a function, for >> a start. >> >> Hmmm. No, iterators

Re: expression form of one-to-many dict?

Mike Meyer <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (Bengt Richter) writes: > > > On Sun, 19 Dec 2004 21:29:27 +0100, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote: > > (or maybe a restricted unquote_arg function for better safety). > > E.g., double back-tick is a syntax error now, so you could

Re: expression form of one-to-many dict?

Mike Meyer <[EMAIL PROTECTED]> writes: > Personally, I'd love a language feature that let you create a function > that didn't evaluate arguments until they were actually used - lazy > evaluation. That lets you write the C ?: operator as a function, for > a start. > > Hmmm. No, iterators can't be u

Re: expression form of one-to-many dict?

Mike Meyer wrote: Personally, I'd love a language feature that let you create a function that didn't evaluate arguments until they were actually used - lazy evaluation. That lets you write the C ?: operator as a function, for a start. Hmmm. No, iterators can't be used to fake it. Oh well. That is a

Re: expression form of one-to-many dict?

[EMAIL PROTECTED] (Bengt Richter) writes: > On Sun, 19 Dec 2004 21:29:27 +0100, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote: > (or maybe a restricted unquote_arg function for better safety). > E.g., double back-tick is a syntax error now, so you could write > > def ternary(c, ``t, ``f): >

Re: expression form of one-to-many dict?

On Sun, 19 Dec 2004 21:29:27 +0100, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote: >Mike Meyer wrote: > >> Personally, I'd love a language feature that let you create a function >> that didn't evaluate arguments until they were actually used - lazy >> evaluation. That lets you write the C ?: operator

Re: expression form of one-to-many dict?

Mike Meyer wrote: > Personally, I'd love a language feature that let you create a function > that didn't evaluate arguments until they were actually used - lazy > evaluation. That lets you write the C ?: operator as a function, for > a start. > > Hmmm. No, iterators can't be used to fake it. Oh we

Re: expression form of one-to-many dict?

Nick Craig-Wood <[EMAIL PROTECTED]> writes: > It would be nice if setdefault didn't evaluate the second argument > unless it needed it. However I guess it would have to be a language > feature to do that. Personally, I'd love a language feature that let you create a function that didn't evaluate

Re: expression form of one-to-many dict?

Steven Bethard <[EMAIL PROTECTED]> wrote: > map = {} > for key, value in sequence: > map.setdefault(key, []).append(value) I was thinking about exactly that the other day, when converting some perl to python. [ digression: In perl, you do push @{$map->{$key}}, $value If $map->{$key} d

Re: expression form of one-to-many dict?

In respect to map(func, seq) versus [func(i) for i in seq], for pre-existing func, 'OP' wrote The map form, in this case, parses instantly in my brain, while the listcomp certainly takes a few cycles. And note that I'm not talking about the typing conciseness, but about the

Re: expression form of one-to-many dict?

Fredrik Lundh wrote: Steven Bethard wrote: The map form, in this case, parses instantly in my brain, while the listcomp certainly takes a few cycles. And note that I'm not talking about the typing conciseness, but about the effort for my brain. But maybe I'm just wired funny :) Well, different at

Re: expression form of one-to-many dict?

Steven Bethard wrote: >> The map form, in this case, parses instantly in my brain, while the listcomp >> certainly takes a few cycles. And note that I'm not talking about the typing >> conciseness, but about the effort for my brain. But maybe I'm just wired >> funny :) > > Well, different at lea

Re: expression form of one-to-many dict?

Fernando Perez wrote: outlist = map(foo,inlist) is still better in my book, and far more readable, than outlist = [foo(x) for x in inlist] The map form, in this case, parses instantly in my brain, while the listcomp certainly takes a few cycles. And note that I'm not talking about the typing conci

Re: expression form of one-to-many dict?

Steven Bethard wrote: > Actually, it's even smaller now, because I've pretty much removed map > from all my code in favor of list comprehensions, which I find much > easier to read. While I agree that listcomps are more readable in most cases (and certainly for all cases with any amount of comple

Re: expression form of one-to-many dict?

Larry Bates wrote: Suggestion: It is a bad idea to name any variable "map". When you do, you destroy your ability to call Python's map function. Same goes for "list", "str", or any other built-in function. If you haven't been bitten by this you will, I was. A good reminder for all the newbies out

Re: expression form of one-to-many dict?

Steven, Suggestion: It is a bad idea to name any variable "map". When you do, you destroy your ability to call Python's map function. Same goes for "list", "str", or any other built-in function. If you haven't been bitten by this you will, I was. Larry Bates Steven Bethard wrote: So I end up writi

RE: expression form of one-to-many dict?

Steven Bethard wrote: > So I end up writing code like this a fair bit: > > map = {} > for key, value in sequence: > map.setdefault(key, []).append(value) > > This code basically constructs a one-to-many mapping -- each > value that > a key occurs with is stored in the list for that key. >

Re: expression form of one-to-many dict?

Tim Peters wrote: The point here is that there's a simple sequence or GE that I can throw to the dict constructor that spits out a dict with my one-to- one mapping. It's a simple sequence because it's a simple task. It's even simpler than perhaps it "should be", since it arbitrarily decides that,

Re: expression form of one-to-many dict?

[Steven Bethard] > So I end up writing code like this a fair bit: > > map = {} > for key, value in sequence: > map.setdefault(key, []).append(value) > > This code basically constructs a one-to-many mapping -- each > value that a key occurs with is stored in the list for that key. > > This code'