Ron_Adam wrote:
> On Fri, 25 Mar 2005 18:58:27 +0100, Reinhold Birkenfeld
> <[EMAIL PROTECTED]> wrote:
>
>>Ron_Adam wrote:
>>
>>> What if you could:
>>>
>>> x = lambda{ x, y: x+y}
>>> Hmm comma creates a problem here. so...
>>
> from __future__ import braces
>>SyntaxError: not a chance
On Fri, 25 Mar 2005 17:09:38 -0500, "George Sakkis"
<[EMAIL PROTECTED]> wrote:
>I posted a recipe in python cookbook
>(http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/392768) for the
>subproblem I was interested
>in initially (variable-length iterable unpacking), and I prefer it over
>ex
On Fri, 25 Mar 2005 18:58:27 +0100, Reinhold Birkenfeld
<[EMAIL PROTECTED]> wrote:
>Ron_Adam wrote:
>
>> What if you could:
>>
>> x = lambda{ x, y: x+y}
>> Hmm comma creates a problem here. so...
>
from __future__ import braces
>SyntaxError: not a chance
>
>Reinhold ;)
LOL, :-)
"Ron_Adam" <[EMAIL PROTECTED]> wrote:
> On 25 Mar 2005 10:09:50 GMT, Duncan Booth
> <[EMAIL PROTECTED]> wrote:
>
>
> >I've never found any need for an is_defined function. If in doubt I just
> >make sure and initialise all variables to a suitable value before use.
> >However, I'll assume you have
On 25 Mar 2005 10:09:50 GMT, Duncan Booth
<[EMAIL PROTECTED]> wrote:
>I've never found any need for an is_defined function. If in doubt I just
>make sure and initialise all variables to a suitable value before use.
>However, I'll assume you have a good use case.
I admit that that is the better
Ron_Adam wrote:
> What if you could:
>
> x = lambda{ x, y: x+y}
> Hmm comma creates a problem here. so...
>>> from __future__ import braces
SyntaxError: not a chance
>>>
Reinhold ;)
--
http://mail.python.org/mailman/listinfo/python-list
On 24 Mar 2005 22:16:10 -0800, "Kay Schluehr" <[EMAIL PROTECTED]>
wrote:
>It's all developed during this discussion. Sometimes I'm a bit
>surprised were it goes.
I enjoy exploring ideas this way. Many times it leads to dead ends or
you just end up with a long way back to where you started, but
so
Ron wrote:
> It's interesting that there is a whole is_"type"_() group of functions
> in the inspect module, but not a is_defined(). Maybe I just haven't
> found it yet.
I've never found any need for an is_defined function. If in doubt I just
make sure and initialise all variables to a suitable
"Kay Schluehr" <[EMAIL PROTECTED]> wrote:
> To make my intention clear for another time, also for George who
> mistrusts these exercises alltogether. I want to derive a syntax and
> semantics for anonymus functions ( called "tuple-actions" ) that are
> generalizations of rules that are already use
Ron_Adam wrote:
> On 24 Mar 2005 01:58:48 -0800, "Kay Schluehr" <[EMAIL PROTECTED]>
> wrote:
>
> >I personally don't like using exec and eval for stuff different from
> >evaluating user input.
>
> I lean the other way. I never want to use user impute for eval and
> exec. Way too risky.
Well a Py
On 24 Mar 2005 01:58:48 -0800, "Kay Schluehr" <[EMAIL PROTECTED]>
wrote:
>I personally don't like using exec and eval for stuff different from
>evaluating user input.
I lean the other way. I never want to use user impute for eval and
exec. Way too risky. But limited use, that is not user input,
On Thu, 24 Mar 2005 12:07:44 -0500, "George Sakkis"
<[EMAIL PROTECTED]> wrote:
>"Kay Schluehr" <[EMAIL PROTECTED]> wrote:
>> [snipped]
>>
>> Wouldn't it be fun to use in Python?
>>
>> Only drawback: does not look like executable pseudo-code anymore :(
>>
>>
>> Regards Kay
>
>I don't know if it wou
On 24 Mar 2005 09:20:52 GMT, Duncan Booth
<[EMAIL PROTECTED]> wrote:
>Ron wrote:
>
A working makeVars seems not to be different from
def makeVars(**nameVals):
globals().update(nameVals)
>>>
>>>Not quite. If Ron can come up with a working makeVars it would update
>>>the call
"Kay Schluehr" <[EMAIL PROTECTED]> wrote:
> [snipped]
>
> Wouldn't it be fun to use in Python?
>
> Only drawback: does not look like executable pseudo-code anymore :(
>
>
> Regards Kay
I don't know if it would be fun, but it certainly doesn't look accessible to
mere mortals :-) I'm
not sure if th
Ron wrote:
> On Wed, 23 Mar 2005 06:21:30 +0100, Kay Schluehr <[EMAIL PROTECTED]>
> wrote:
>
> >I think my proposal was more in mind of Rons modified exec than
> >Pythons lambda.
> >
> >When George proposed his unpacking behavoir for list-comps as a pack
of
> >suggar:
> >
> >1. [x*y-z for (x,y,z=0)
Ron wrote:
>>> A working makeVars seems not to be different from
>>>
>>> def makeVars(**nameVals):
>>>globals().update(nameVals)
>>
>>Not quite. If Ron can come up with a working makeVars it would update
>>the caller's globals whereas what you just posted updates makeVar's
>>globals so there
George Sakkis wrote:
"bruno modulix" <[EMAIL PROTECTED]> wrote: in message news:[EMAIL PROTECTED]
(snip)
Note that you don't have anything like
list unpacking, now tuple unpacking is pretty common in Python (swap,
multiple return values, formatted strings and outputs, ...).
All the following are p
On Wed, 23 Mar 2005 06:21:30 +0100, Kay Schluehr <[EMAIL PROTECTED]>
wrote:
>I think my proposal was more in mind of Rons modified exec than
>Pythons lambda.
>
>When George proposed his unpacking behavoir for list-comps as a pack of
>suggar:
>
>1. [x*y-z for (x,y,z=0) in (1,2,3), (4,5), (6,7,8)]
>
On 23 Mar 2005 14:47:30 GMT, Duncan Booth
<[EMAIL PROTECTED]> wrote:
>Kay Schluehr wrote:
>
>> A working makeVars seems not to be different from
>>
>> def makeVars(**nameVals):
>>globals().update(nameVals)
>
>Not quite. If Ron can come up with a working makeVars it would update the
>caller's
"bruno modulix" <[EMAIL PROTECTED]> wrote: in message news:[EMAIL PROTECTED]
> Ron wrote:
> >>The problem here is that Kay's proposition mixes two points: flexible
> >>tuple unpacking and a new syntax for anonymous functions.
> >
> >
> > Yes, two different problems. I don't think anything needs to
On 23 Mar 2005 08:31:36 GMT
Antoon Pardon <[EMAIL PROTECTED]> wrote:
> Can someone who thinks this way, please explain why this is acceptable
>
> [ x * x for x in some_iterator ]
>
> But this is not
>
> map(lambda x: x * x, some_iteraror)
>
> and should be replaced with
>
> def sqr(x):
Kay Schluehr wrote:
> A working makeVars seems not to be different from
>
> def makeVars(**nameVals):
>globals().update(nameVals)
Not quite. If Ron can come up with a working makeVars it would update the
caller's globals whereas what you just posted updates makeVar's globals so
there is a
Ron wrote:
> On 23 Mar 2005 10:13:16 GMT, Duncan Booth
> <[EMAIL PROTECTED]> wrote:
>
>
>> Do I really need to mention that the whole concept here is broken.
This
>> only works if you call it from global scope. If you call it from
inside a
>> function it [usually] won't work:
>>
>
>
> That's only
On 23 Mar 2005 10:13:16 GMT, Duncan Booth
<[EMAIL PROTECTED]> wrote:
>Do I really need to mention that the whole concept here is broken. This
>only works if you call it from global scope. If you call it from inside a
>function it [usually] won't work:
Ok... you can get globals this way if you k
On 23 Mar 2005 10:13:16 GMT, Duncan Booth
<[EMAIL PROTECTED]> wrote:
>Do I really need to mention that the whole concept here is broken. This
>only works if you call it from global scope. If you call it from inside a
>function it [usually] won't work:
That's only becuase it was asked to go up
Op 2005-03-23, Diez B. Roggisch schreef <[EMAIL PROTECTED]>:
>> Can someone who thinks this way, please explain why this is acceptable
>>
>> [ x * x for x in some_iterator ]
>>
>> But this is not
>>
>> map(lambda x: x * x, some_iteraror)
>>
>> and should be replaced with
>>
>> def sqr(x)
Duncan Booth wrote:
> Do I really need to mention that the whole concept here is broken.
This
> only works if you call it from global scope. If you call it from
inside a
> function it [usually] won't work:
>
> >>> def makeVars(**nameVals):
> sys._getframe(1).f_locals.update(nameVals)
>
>
>
> Can someone who thinks this way, please explain why this is acceptable
>
> [ x * x for x in some_iterator ]
>
> But this is not
>
> map(lambda x: x * x, some_iteraror)
>
> and should be replaced with
>
> def sqr(x): return x * x
> map(sqr , some_iterator)
It shouldn't, it should be
George Sakkis wrote:
>> So then the question is ... is there a way for a function to create a
>> varable in it's parents namespace that persists after the function is
>> done?
>
> Yeap.. a simple one-liner can do the trick:
>
> def makeVars(**nameVals):
> sys._getframe(1).f_locals.update(nam
Kay Schluehr wrote:
Hi all,
thanks for Your attention !
I think my proposal was more in mind of Rons modified exec than
Pythons lambda.
When George proposed his unpacking behavoir for list-comps as a pack of
suggar:
1. [x*y-z for (x,y,z=0) in (1,2,3), (4,5), (6,7,8)]
I interpreted it in a subsequen
Ron wrote:
On Tue, 22 Mar 2005 21:45:42 +0100, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
Ron a écrit :
On 21 Mar 2005 22:37:42 -0800, "Kay Schluehr" <[EMAIL PROTECTED]>
wrote:
Mappings like that:
((x,y),z) -> x+y-z
((x,y=0),z) -> None
should be valid actions too.
What is the audience think
George Sakkis wrote:
"Ron" <[EMAIL PROTECTED]> wrote:
On Tue, 22 Mar 2005 21:56:57 GMT, Ron <[EMAIL PROTECTED]> wrote:
Why should a function not create a local varable of an argument if the
varable doesn't exist and a default value is given?
ok... thought it out better. :)
Getting a default into a
Ron wrote:
On Tue, 22 Mar 2005 21:56:57 GMT, Ron <[EMAIL PROTECTED]> wrote:
Why should a function not create a local varable of an argument if the
varable doesn't exist and a default value is given?
ok... thought it out better. :)
Getting a default into a function isn't the problem. Returning the
Op 2005-03-22, Diez B. Roggisch schreef <[EMAIL PROTECTED]>:
>> Not exactly in fact - unless I messed something. There are 2 problems
>> here: a more flexible tuple unpacking, *and* a lambda in disguise.
>> Actually, I'd go + 1 for the first, -1 for the second
>
> The proposed syntax from Kay is la
Please do not change the syntax. Better focus on the library.
1. There are already 3 constructs right now for this problem.
2. List comprehensions are used mostly in examples. At least I came to
such conclusion reading the standard library modules.
--
http://mail.python.org/mailman/listinfo/pyth
On Tue, 22 Mar 2005 21:45:42 +0100, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
>Ron a écrit :
>> On 21 Mar 2005 22:37:42 -0800, "Kay Schluehr" <[EMAIL PROTECTED]>
>> wrote:
>>
>>
>>>Mappings like that:
>>>
>>> ((x,y),z) -> x+y-z
>>>
>>> ((x,y=0),z) -> None
>>>
>>>should be valid actions
On Tue, 22 Mar 2005 18:15:25 -0500, "George Sakkis"
<[EMAIL PROTECTED]> wrote:
>"Ron" <[EMAIL PROTECTED]> wrote:
>> On Tue, 22 Mar 2005 21:56:57 GMT, Ron <[EMAIL PROTECTED]> wrote:
>>
>> >Why should a function not create a local varable of an argument if the
>> >varable doesn't exist and a default
"Ron" <[EMAIL PROTECTED]> wrote:
> On Tue, 22 Mar 2005 21:56:57 GMT, Ron <[EMAIL PROTECTED]> wrote:
>
> >Why should a function not create a local varable of an argument if the
> >varable doesn't exist and a default value is given?
>
> ok... thought it out better. :)
>
> Getting a default into a fun
On Tue, 22 Mar 2005 21:56:57 GMT, Ron <[EMAIL PROTECTED]> wrote:
>Why should a function not create a local varable of an argument if the
>varable doesn't exist and a default value is given?
ok... thought it out better. :)
Getting a default into a function isn't the problem. Returning the
value t
On Tue, 22 Mar 2005 21:43:48 +0100, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
>Ron a écrit :
>(snip)
def dfv( arg = value):
>>
>> return arg
> >
> >>> def dfv( arg = value):
>... return arg
>...
>Traceback (most recent call last):
> File "", line 1, in ?
>NameError: na
Diez B. Roggisch a écrit :
(snip)
You are right, but for lambda in its current limited form short, named
functions are a good replacement.
-inf on this !-)
--
http://mail.python.org/mailman/listinfo/python-list
Ron a écrit :
On 21 Mar 2005 22:37:42 -0800, "Kay Schluehr" <[EMAIL PROTECTED]>
wrote:
Mappings like that:
((x,y),z) -> x+y-z
((x,y=0),z) -> None
should be valid actions too.
What is the audience thinking about that?
I think that there's too much implied, and that in the long run it,
if we k
Ron a écrit :
(snip)
def dfv( arg = value):
return arg
>
>>> def dfv( arg = value):
... return arg
...
Traceback (most recent call last):
File "", line 1, in ?
NameError: name 'value' is not defined
And sorry, but -1 for using exec here.
--
http://mail.python.org/mailman/listinfo
Claudio Grondi wrote:
What do you find most readable: your version, with an ad-hoc function
defined somewhere else, far away in the code, or a simpler:
for (x,y,z=0) in tupleList:
do_whatever_with_it()
I came up with the "ad-hoc function"
to give a kind of replacement
for the used syntax, in or
> What do you find most readable: your version, with an ad-hoc function
> defined somewhere else, far away in the code, or a simpler:
> for (x,y,z=0) in tupleList:
> do_whatever_with_it()
I came up with the "ad-hoc function"
to give a kind of replacement
for the used syntax, in order
not to as
On Tue, 22 Mar 2005 15:05:55 +0100, bruno modulix <[EMAIL PROTECTED]>
wrote:
>bruno modulix wrote:
>> Kay Schluehr wrote:
>>
>>> Since George Sakkis proposed a new way of doing list comprehensions
>>> letting tuples-like objects (x,y,z=0) acting as functions on other
>>> tuples I wonder why this
> Not exactly in fact - unless I messed something. There are 2 problems
> here: a more flexible tuple unpacking, *and* a lambda in disguise.
> Actually, I'd go + 1 for the first, -1 for the second
The proposed syntax from Kay is lambda in disguise. To make it work like
George want it is modifying
Diez B. Roggisch wrote:
letting tuples-like objects (x,y,z=0) acting as functions on other
tuples I wonder why this would not be a good starting point of
rethinking anonymus functions?
In Georges proposition the action is
(x,y,z=0) -> (x,y,z)
i.e. mapping tuples on other tuples. This is equivalen
Claudio Grondi wrote:
for x,y,z in some_iterator:
If some_iterator produces at some time
a tuple with only two elements this
will raise an exception no matter
whether you assigned z already or not.
So if I now understand it right, the core
of the whole proposal is to find a way to
make unpacking o
> for x,y,z in some_iterator:
>
> If some_iterator produces at some time
> a tuple with only two elements this
> will raise an exception no matter
> whether you assigned z already or not.
So if I now understand it right, the core
of the whole proposal is to find a way to
make unpacking of tuples
bruno modulix wrote:
Kay Schluehr wrote:
Since George Sakkis proposed a new way of doing list comprehensions
http://groups-beta.google.com/group/comp.lang.python/browse_frm/thread/ac5023ad18b2835f/d3ff1b81fa70c8a7#d3ff1b81fa70c8a7
letting tuples-like objects (x,y,z=0) acting as functions on other
> letting tuples-like objects (x,y,z=0) acting as functions on other
> tuples I wonder why this would not be a good starting point of
> rethinking anonymus functions?
>
> In Georges proposition the action is
>
>(x,y,z=0) -> (x,y,z)
>
> i.e. mapping tuples on other tuples. This is equivalent
On 21 Mar 2005 22:37:42 -0800, "Kay Schluehr" <[EMAIL PROTECTED]>
wrote:
>Mappings like that:
>
> ((x,y),z) -> x+y-z
>
> ((x,y=0),z) -> None
>
>should be valid actions too.
>
>What is the audience thinking about that?
I think that there's too much implied, and that in the long run it,
if w
Op 2005-03-22, Claudio Grondi schreef <[EMAIL PROTECTED]>:
> reducing the number of lines to two,
> but I don't, because in my eyes
> I can read the code better if
> spread over five lines and because
> of this, the code becomes in my
> opinion even less error-prone.
> Actually I would write in my
> > Already
> > lambda x,y,z=0:(x,y,z)
> > is a problem for me.
> >
> > Why not:
> > try:
> > (x,y,z)
> > except NameError:
> > z=0
> > (x,y,z)
> > ?
>
> Because they are not equivallent.
>
> > Watching the last piece of code
> > can even directly be seen, that there
> > is eventually a Nam
> > Why not:
> > try:
> > (x,y,z)
> > except NameError:
> > z=0
> > (x,y,z)
> > ?
instead of
> > lambda x,y,z=0:(x,y,z)
> Because it does not do the same thing ?-)
Haven't got the idea why? ()
> Because, if it did, it would still require 5 times more lines of code to
> do the same thing (he
Op 2005-03-22, Claudio Grondi schreef <[EMAIL PROTECTED]>:
> For me, one of the reasons for using Python
> is the ease and the intuivity of reading its
> code.
> I have a problem with intuitively getting
> what is going on when using a pattern like
> (x,y,z=0) -> (x,y,z)
> where I expect at the
Kay Schluehr wrote:
Since George Sakkis proposed a new way of doing list comprehensions
http://groups-beta.google.com/group/comp.lang.python/browse_frm/thread/ac5023ad18b2835f/d3ff1b81fa70c8a7#d3ff1b81fa70c8a7
letting tuples-like objects (x,y,z=0) acting as functions on other
tuples I wonder why th
Claudio Grondi wrote:
For me, one of the reasons for using Python
is the ease and the intuivity of reading its
code.
I guess this is true for many of us. Now 'ease and intuitivity' stronly
depends on one's background...
I have a problem with intuitively getting
what is going on when using a patt
For me, one of the reasons for using Python
is the ease and the intuivity of reading its
code.
I have a problem with intuitively getting
what is going on when using a pattern like
(x,y,z=0) -> (x,y,z)
where I expect at the first glance some
C code with access to class members.
At least I must st
60 matches
Mail list logo
