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
Reinhold ;)
LOL, :-)
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 used
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
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
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 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 [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 a good use
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, :-)
Is that to discourage
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
explicit
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
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 is a difference
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) in (1,2,3),
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 the mind
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 caller's globals whereas what
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 would be fun, but it
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,
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 Python console
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 lambda in
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
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: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 thinking
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
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(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 replaced
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)
def
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): return x * x
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 1
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 know
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 becuase it was
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
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): return x * x
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 be done
to
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 globals
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)]
I
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
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
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
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 first
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? (pedantic?)
Because, if it did, it would still require 5 times more lines of code to
do the same thing (hence it's
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 NameError
problem with z to
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 code:
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 keep addding
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 to
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
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 work
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
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
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
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 would not be a
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 ask why
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
Ron a écrit :
(snip)
def dfv( arg = value):
return arg
def dfv( arg = value):
... return arg
...
Traceback (most recent call last):
File stdin, line 1, in ?
NameError: name 'value' is not defined
And sorry, but -1 for using exec here.
--
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 keep
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
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 stdin, line 1, in ?
NameError: name 'value' is not
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 to a
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 function isn't the
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 value is given?
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 thinking
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.
--
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 subsequent posting in lambda
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 this would not be a
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 this would not be a
63 matches
Mail list logo
