By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,676 Members | 2,262 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,676 IT Pros & Developers. It's quick & easy.

Some "pythonic" suggestions for Python

P: n/a
I love Python, and it is one of my 2 favorite
languages. I would suggest that Python steal some
aspects of the S language.

-------------------------------------------------------
1. Currently in Python
def foo(x,y): ...
assigns the name foo to a function object. Is this pythonic?

Why not use the = operator like most other assignments?
Define function objects as "function"s, let users put them where
they want to. Get rid of lambda, get rid of def, only use =
for assignments.

foo = function(x,y) x+y*2 # Example S language code
bar = foo
bar(3,4)
m = lapply( s, foo )
bb = lapply(s, function(t) t[3]*4 )

foo = func(x,y): x+y*2 # Possible python code
bar = foo
bar(3,4)
m = barf( s, foo )
bb = barf(s, func(t): t[3]*4 )

-------------------------------------------------------
2. Allow sequences to be indices:
>>s=["hello", 6, 33, "none"]
x= [1,3]
[ s[y] for y in x] # Current verbose version
[6, 'none']
>>s[x] # Simpler, clearer, more productive
To quote a poster at http://www.thescripts.com/forum/thread22741.html,
"While we are at it, I also don't understand why sequences can't be
used as indices. Why not, say, l[[2,3]] or l[(2, 3)]? Why a special
slice concept? " Isn't that unpythonic?

--------------------------------------------------------
3. When I first started using python, I frequently used
map, because I didn't want to have to learn the
additional syntax of list comprehensions, which
appeared very nonstructured.

# Is this readable?
b= [x+y for x in vec1 if x>0 for y in vec2 if y>x ]

Perhaps a list comprehension syntax more like the rest
of python. "for" could return a list given by continue
arguments:

b= for x in vec1 :
if (x>0): continue # "returns" nothing
continue for y in vec2:
if (x>y): continue(x+y)

Note that my code would actually return a list of lists
rather than a single list like the list comprehension.
More structured syntax opens the door to having much
more complicated, yet still comprehensible (thus more
pythonic), list comprehensions.

--------------------------------------------------------

I know these ideas are not perfect, but I think they
may be better... Fire away.

-Frank
Nov 8 '07 #1
Share this Question
Share on Google+
26 Replies


P: n/a
On Nov 8, 12:00 pm, Frank Samuelson
<newsdump0711.12.cud...@neverbox.comwrote:
def foo(x,y): ...
assigns the name foo to a function object.

Why not use the = operator like most other assignments?
FWIW, the also binds the __name__ attribute:

foo = lambda(x,y): ...
foo.__name__ = 'foo'
Raymond

Nov 8 '07 #2

P: n/a
On Nov 8, 3:00 pm, Frank Samuelson
<newsdump0711.12.cud...@neverbox.comwrote:
I know these ideas are not perfect, but I think they
may be better... Fire away.

Python isn't Lisp.
Carl Banks

Nov 8 '07 #3

P: n/a
Frank Samuelson pisze:
foo = function(x,y) x+y*2 # Example S language code
Ugly.

--
Jarek Zgoda
http://zgodowie.org/
Nov 8 '07 #4

P: n/a
Frank Samuelson schrieb:
I love Python, and it is one of my 2 favorite
languages. I would suggest that Python steal some
aspects of the S language.

-------------------------------------------------------
1. Currently in Python
def foo(x,y): ...
assigns the name foo to a function object. Is this pythonic?

Why not use the = operator like most other assignments?
Define function objects as "function"s, let users put them where
they want to. Get rid of lambda, get rid of def, only use =
for assignments.

foo = function(x,y) x+y*2 # Example S language code
bar = foo
bar(3,4)
m = lapply( s, foo )
bb = lapply(s, function(t) t[3]*4 )

foo = func(x,y): x+y*2 # Possible python code
bar = foo
bar(3,4)
m = barf( s, foo )
bb = barf(s, func(t): t[3]*4 )
The whole purpose being that you have statements in lambdas - something
that has been proposed and rejected about a bazillion times. Read the
archives.

-------------------------------------------------------
2. Allow sequences to be indices:
>>s=["hello", 6, 33, "none"]
>>x= [1,3]
>>[ s[y] for y in x] # Current verbose version
[6, 'none']
>>s[x] # Simpler, clearer, more productive

To quote a poster at http://www.thescripts.com/forum/thread22741.html,
"While we are at it, I also don't understand why sequences can't be
used as indices. Why not, say, l[[2,3]] or l[(2, 3)]? Why a special
slice concept? " Isn't that unpythonic?

What has the one to do with the other? Slices are use- and powerful.

I'm not against this, but then what you call "verbose" is very concise
in my book - and concise enough to be used when the need arises, which
is seldom enough.
--------------------------------------------------------
3. When I first started using python, I frequently used
map, because I didn't want to have to learn the
additional syntax of list comprehensions, which
appeared very nonstructured.

# Is this readable?
b= [x+y for x in vec1 if x>0 for y in vec2 if y>x ]

Yes, I think it is readable. You could ask the same for the
parenthesis-overload in lisp - after all, it's just what you are
accustomed to.

Perhaps a list comprehension syntax more like the rest
of python. "for" could return a list given by continue
arguments:

b= for x in vec1 :
if (x>0): continue # "returns" nothing
continue for y in vec2:
if (x>y): continue(x+y)

Note that my code would actually return a list of lists
rather than a single list like the list comprehension.
More structured syntax opens the door to having much
more complicated, yet still comprehensible (thus more
pythonic), list comprehensions.
So it is _not_ a list comprehension, but all it does is to create
implicit lists?

I prefer list-comps. They allow for nested as well as flattened structures:

b= [x+y for x in vec1 if x>0 for y in vec2 if y>x ]
b= [[x+y for y in vec2 if y>x ] for x in vec1 if x>0]

Overall, I'd say you don't stand a chance that your proposals will be
adopted. They are minor variations of things that have been proposed &
rejected too often to count - and to be honest: it get's tiresome
beating the same old horses again and again...

Diez
Nov 8 '07 #5

P: n/a
Frank Samuelson <ne********************@neverbox.comwrites:
I love Python, and it is one of my 2 favorite
languages. I would suggest that Python steal some
aspects of the S language.
I would suggest each of these be discussed in a separate thread, each
with a specific Subject field, rather than three loosely-related
questions in a single thread.

--
\ "People are very open-minded about new things, as long as |
`\ they're exactly like the old ones." -- Charles F. Kettering |
_o__) |
Ben Finney
Nov 8 '07 #6

P: n/a
Frank Samuelson a écrit :
I love Python, and it is one of my 2 favorite
languages. I would suggest that Python steal some
aspects of the S language.

-------------------------------------------------------
1. Currently in Python
def foo(x,y): ...
assigns the name foo to a function object. Is this pythonic?
Yes. Python deliberately choosed to be a statement-based language.
Why not use the = operator like most other assignments?
This dead horse has been beaten to hell and back.

Note that as far as I'm concerned, I may like an expression-based
Python-inspired language. But this is another story.
>
-------------------------------------------------------
2. Allow sequences to be indices:
>>s=["hello", 6, 33, "none"]
>>x= [1,3]
>>[ s[y] for y in x] # Current verbose version
Verbose ???
[6, 'none']
>>s[x] # Simpler, clearer, more productive

To quote a poster at http://www.thescripts.com/forum/thread22741.html,
"While we are at it, I also don't understand why sequences can't be
used as indices. Why not, say, l[[2,3]] or l[(2, 3)]? Why a special
slice concept?
slices are very powerful.
>" Isn't that unpythonic?
Not IMHO. But extending slices to support might not be totally stupid.
Do you volunteer to write the PEP and the patch ?
--------------------------------------------------------
3. When I first started using python, I frequently used
map, because I didn't want to have to learn the
additional syntax of list comprehensions, which
appeared very nonstructured.

# Is this readable?
b= [x+y for x in vec1 if x>0 for y in vec2 if y>x ]
Yes.
Perhaps a list comprehension syntax more like the rest
of python. "for" could return a list given by continue
arguments:

b= for x in vec1 :
if (x>0): continue # "returns" nothing
continue for y in vec2:
if (x>y): continue(x+y)
Now *this* is a mess. And FWIW, you inverted the second test...
Note that my code would actually return a list of lists
rather than a single list like the list comprehension.
More structured syntax opens the door to having much
more complicated, yet still comprehensible (thus more
pythonic), list comprehensions.
The Pythonic way to write "more complicated yet still comprehensible
list comprehensions" is to not use list comprehensions.

b = []
for x in vec1:
if x 0:
for y in vec2:
if y x:
b.append(x + y)

Or if you really want a more functional approach:

def do_stuff(vec1, vec2):
for x in vec1:
if x 0:
for y in vec2:
if y x:
yield x + y

b = list(do_stuff(vec1, vec2))
Nov 8 '07 #7

P: n/a
Frank Samuelson wrote:
I love Python, and it is one of my 2 favorite
languages. I would suggest that Python steal some
aspects of the S language.
I generally agree with the various naye-sayers, but find one
argument missing:
-------------------------------------------------------
2. Allow sequences to be indices:
>>s=["hello", 6, 33, "none"]
>>x= [1,3]
>>[ s[y] for y in x] # Current verbose version
[6, 'none']
>>s[x] # Simpler, clearer, more productive

To quote a poster at http://www.thescripts.com/forum/thread22741.html,
"While we are at it, I also don't understand why sequences can't be
used as indices. Why not, say, l[[2,3]] or l[(2, 3)]? Why a special
slice concept? " Isn't that unpythonic?
Right now, after:

which_corner = {}
corner = {}
for n, position in enumerate([(1,1), (1,5), (3,5), (3,1)]):
corner[n] = position
which_corner[position] = n

which_corner[1,5] returns 1

I would hate to have to know whether which_corner is a dictionary
or a list before I can decide whether this is iteration.

-Scott David Daniels
Scott,Da*****@Acm.org
Nov 9 '07 #8

P: n/a
Scott David Daniels <Sc***********@Acm.Orgwrote:
>To quote a poster at
http://www.thescripts.com/forum/thread22741.html,
>"While we are at it, I also don't understand why sequences can't be
used as indices. Why not, say, l[[2,3]] or l[(2, 3)]? Why a special
slice concept? " Isn't that unpythonic?

Right now, after:

which_corner = {}
corner = {}
for n, position in enumerate([(1,1), (1,5), (3,5), (3,1)]):
corner[n] = position
which_corner[position] = n

which_corner[1,5] returns 1

I would hate to have to know whether which_corner is a dictionary
or a list before I can decide whether this is iteration.
Quite so, tuples are currently a valid and indeed commonly used type for
subscripts, so if there was going to be special treatment it would have
to be for lists only and not sequences in general.

Alternatively, and more pythonically (explicit is better than implicit),
we could have a special syntax to indicate that we want to use each
element of the sequence as a separate subscript. I'd like to propose
that the special syntax be:

[s[y] for y in x]

Now someone go and fire up the time machine.

Nov 9 '07 #9

P: n/a
Steven D'Aprano wrote:
Why? What benefit do you gain?
>Define function objects as "function"s, let users put them where they
want to. Get rid of lambda, get rid of def, only use = for assignments.

So you remove two keywords. That's a plus. But then you have to create a
WHOLE lot more syntax to support it, and that's about a thousand minuses.
Python has very little syntax, and the designers are (rightly) very
resistant to adding more.
You answered your own question. There is less syntax.
>
It's also not clear how you expect this to work with anything more
complex than a single expression. How do you handle statements and
multiple returns?

def foo(x, y):
L = []
try:
if x[y] % 2:
print x, y
return y
return x[y]
except:
return None
Huh? This is trivial. I don't see why this is so hard to grasp.

foo= function(x, y):
L = []
try:
if x[y] % 2:
print x, y
return y
return x[y]
except:
return None

> >>s[x] # Simpler, clearer, more productive

It's certainly smaller.

But the fatal objection to this is that it is a special case for a very
limited benefit: saving half a dozen characters.
It sounds like you are describing slices here. It is interesting
how python people don't like specific case syntax, unless it applies
to their already existing specific cases. Lists and tuples represent
any sequence that slices can. Why slices?
>
But can't you see that the suggestion to use sequences as replacements
for slices is completely incompatible with your suggestion above?

seq = range(10)

Would you expect seq[[2,6]] to do an index lookup, as you suggested
originally, or a slice? In the first case, it would return [2, 6], but in
the second, it would return [2, 3, 4, 5].

If sequence indices are slices, what does an index of [1, 2, 3, 4] mean?
It means whatever you decide it to mean. Make a definition and stick with it.
Nov 9 '07 #10

P: n/a
Frank Samuelson <ne********************@neverbox.comwrote:
>It's also not clear how you expect this to work with anything more
complex than a single expression. How do you handle statements and
multiple returns?

def foo(x, y):
L = []
try:
if x[y] % 2:
print x, y
return y
return x[y]
except:
return None

Huh? This is trivial. I don't see why this is so hard to grasp.

foo= function(x, y):
L = []
try:
if x[y] % 2:
print x, y
return y
return x[y]
except:
return None
It is hard to grasp because you said you wanted:

name = function(*argument_list) expression

There is no colon in your proposed syntax, and you only asked for a
single expression in the function rather than a suite. Your 'this is
trivial' response seems to be proposing another syntax entirely.

Unfortunately my crystal ball is away being cleaned, so I am unable to
guess whether you meant for a function definition to be an expression
(opening up a whole host of questions about how you nest it inside other
expressions) or a special case of an assignment to a single name and
wanted to disallow such things as:

foo = l[3] = function(): pass

or if you didn't mean to disallow them, what name should that function
have.

If you are going to make syntax proposals you must be precise.
Nov 9 '07 #11

P: n/a
Bruno Desthuilliers wrote:
Yes. Python deliberately choosed to be a statement-based language.
>Why not use the = operator like most other assignments?

This dead horse has been beaten to hell and back.

Note that as far as I'm concerned, I may like an expression-based
Python-inspired language. But this is another story.
My bad! In my rush I forgot that python requires the return statements.
You people think I'm trying to push lisp, which I am not. (Apparently
many people do, because you are rather skittish.)
In S the value of the last executed statement of a function is the
returned value of the function by default, if there is no return() function.
It is very convenient for writing really small functions. But skip that for now.

foo = function(x,y) { # S language
if (x>2) return(x+y*2)
x+y
}

foo = func(x,y): # My suggested python syntax (Improved!)
if x>2: return x+y*2
return x+y

# put the function object in the code wherever you want it.
bb= bar( a,b, func(x,y): x=x*2 ; b=4 ; return x*b+y )

It still is a statement language. The statement is an explicit
assignment using the "=" like most other assignments. "Def" and "lambda"
are silly. Assign names to function objects names the same way
you assign them to any other object. Call a duck a duck.

While I'm at it, classes are objects too. Assign names to them the
same way you assign names to _any_ other object: "="

MyClass= class(inhereted):
attributes
functions
whatever

x=MyClass() # an object of the above class.
The Pythonic way to write "more complicated yet still comprehensible
list comprehensions" is to not use list comprehensions.

b = []
for x in vec1:
if x 0:
for y in vec2:
if y x:
b.append(x + y)
You have just demonstrated that list comprehensions are not really
necessary at all. So given the "one clear way of doing things",
shouldn't they be removed? My point is that if you are going to
have them, why make some new unstructured syntax for them?
Nov 9 '07 #12

P: n/a
On Nov 9, 2007 8:52 AM, Frank Samuelson
<ne********************@neverbox.comwrote:
Bruno Desthuilliers wrote:
Yes. Python deliberately choosed to be a statement-based language.
Why not use the = operator like most other assignments?
This dead horse has been beaten to hell and back.

Note that as far as I'm concerned, I may like an expression-based
Python-inspired language. But this is another story.

My bad! In my rush I forgot that python requires the return statements.
You people think I'm trying to push lisp, which I am not. (Apparently
many people do, because you are rather skittish.)
In S the value of the last executed statement of a function is the
returned value of the function by default, if there is no return() function.
It is very convenient for writing really small functions. But skip that for now.

foo = function(x,y) { # S language
if (x>2) return(x+y*2)
x+y
}

foo = func(x,y): # My suggested python syntax (Improved!)
if x>2: return x+y*2
return x+y

# put the function object in the code wherever you want it.
bb= bar( a,b, func(x,y): x=x*2 ; b=4 ; return x*b+y )

It still is a statement language. The statement is an explicit
assignment using the "=" like most other assignments. "Def" and "lambda"
are silly. Assign names to function objects names the same way
you assign them to any other object. Call a duck a duck.

While I'm at it, classes are objects too. Assign names to them the
same way you assign names to _any_ other object: "="

MyClass= class(inhereted):
attributes
functions
whatever

x=MyClass() # an object of the above class.
The Pythonic way to write "more complicated yet still comprehensible
list comprehensions" is to not use list comprehensions.

b = []
for x in vec1:
if x 0:
for y in vec2:
if y x:
b.append(x + y)

You have just demonstrated that list comprehensions are not really
necessary at all. So given the "one clear way of doing things",
shouldn't they be removed? My point is that if you are going to
have them, why make some new unstructured syntax for them?
There are at least 2 posts a month by someone who decides that they
want to re-wire Python syntax. Usually it's because of some particular
idiom they're used to in another language, in other cases it's because
they've got some particular issue with "consistency". The ideas are
*never* fully thought out or materialized, and they invariably invite
scorn from the user community. The poster is almost always a Python
beginner (I don't know if thats true in your case or not).

Arbitrary changes to syntax are never going to fly. It's a lost cause.
If you can't handle Python without your pet changes, fork it and write
your own version and let the marketplace of ideas decide if its
useful.
Nov 9 '07 #13

P: n/a
On Nov 9, 9:52 am, Frank Samuelson
<newsdump0711.12.cud...@neverbox.comwrote:
Bruno Desthuilliers wrote:
Yes. Python deliberately choosed to be a statement-based language.
Why not use the = operator like most other assignments?
This dead horse has been beaten to hell and back.
Note that as far as I'm concerned, I may like an expression-based
Python-inspired language. But this is another story.

My bad! In my rush I forgot that python requires the return statements.
You people think I'm trying to push lisp, which I am not. (Apparently
many people do, because you are rather skittish.)
In S the value of the last executed statement of a function is the
returned value of the function by default, if there is no return() function.
It is very convenient for writing really small functions. But skip that for now.

foo = function(x,y) { # S language
if (x>2) return(x+y*2)
x+y

}

foo = func(x,y): # My suggested python syntax (Improved!)
if x>2: return x+y*2
return x+y

# put the function object in the code wherever you want it.
bb= bar( a,b, func(x,y): x=x*2 ; b=4 ; return x*b+y )

It still is a statement language. The statement is an explicit
assignment using the "=" like most other assignments. "Def" and "lambda"
are silly. Assign names to function objects names the same way
you assign them to any other object. Call a duck a duck.

If you do that, then when your pure, duck-called function results in a
raised exception, your stack trace will look like this:

File "xxx.py", line yy

instead of the much more helpful

File "xxx.py", line yy, in foo

because the function will be nameless. For me, this is more than
enough to justify a special assignment syntax for function. (In fact,
I'd say there are at least three reasons that are good enough by
themselves, but this'll do for now.)

More generally: your proposals are not "Pythonic", and will get very
little support in the Python community, because the mentality "If it's
good for X, it's good for Y" isn't Pythonic. Python is about a
practical balance of many concerns, and all decisions are considered
from many viewpoints. An argument for consistency for the sake of
keeping things simple is only one of many factors considered.
Carl Banks

Nov 9 '07 #14

P: n/a
Frank Samuelson a écrit :
foo = function(x,y) x+y*2 # Example S language code
bar = foo
bar(3,4)
m = lapply( s, foo )
bb = lapply(s, function(t) t[3]*4 )
Here you want all functions to be lambda functions:

you can get something very close to what you want,
just like this:

foo = lambda x,y: x+y*2
bar = foo
bar(3,4)

you would only need to extend existing lambda:
* support all python keywords/expressions in lambda
* multiline lambda
* multi return value lambda
* and possibility to map 'function' name to be equivalent to 'lambda'
Loic
Nov 9 '07 #15

P: n/a


Multi-return value lambda? Just so you know, there is no concept of
returning more than one value from a function.

def a(): return 1, 2

returns one value - a tuple of (1, 2).

lambda: (1, 2)

does the same thing.

Nov 9 '07 #16

P: n/a

So you like my ideas too!
>
There are at least 2 posts a month by someone who decides that they
want to re-wire Python syntax. Usually it's because of some particular
idiom they're used to in another language,
And python does not use idioms from other languages?
in other cases it's because
they've got some particular issue with "consistency".
My impression was that "consistency" was important to Python.
"Consistency" improves my productivity because I don't have to
keep referring to the manual. Things work the way I expect them
to work.
The ideas are
*never* fully thought out or materialized, and they invariably invite
scorn from the user community.
Of course, they're thought out: They're stolen from another language.
Specifically, the language in which I am most productive.
The poster is almost always a Python
beginner (I don't know if thats true in your case or not).
Only a couple years at it, but that is true of all of the languages
that I know, I guess...
>
Arbitrary changes to syntax are never going to fly. It's a lost cause.
The changes are not arbitrary. They are logical, consistent, less
arbitrary and thus more productive. If such
changes are a lost cause, that is too bad, because
it implies that Python will stagnate. Unfortunately that appears the case.
Though backward compatibility is not an issue (3.0 breaks stuff), I have
learned that there are many pythonistas who make up lots of arbitrary
reasons not to change anything, even if it is for the better.
If you can't handle Python without your pet changes, fork it and write
your own version and let the marketplace of ideas decide if its
useful.
Apparently you missed my statement about loving Python. I love it
because it is the second most productive language I have ever used,
though I do believe it has the potential to be the greatest ever by
far.


Nov 9 '07 #17

P: n/a
On Fri, 09 Nov 2007 11:41:24 -0500, Frank Samuelson wrote:
>There are at least 2 posts a month by someone who decides that they
want to re-wire Python syntax. Usually it's because of some particular
idiom they're used to in another language,

And python does not use idioms from other languages?
It does. So what? Does that mean any idiom from any other language makes
sense in Python?
>in other cases it's because they've got some particular issue with
"consistency".

My impression was that "consistency" was important to Python.
It is but to quote a headline from the Python style guide: `A Foolish
Consistency is the Hobgoblin of Little Minds`.
"Consistency" improves my productivity because I don't have to keep
referring to the manual. Things work the way I expect them to work.
I expect meaningful function names in tracebacks.
>The ideas are *never* fully thought out or materialized, and they
invariably invite scorn from the user community.

Of course, they're thought out: They're stolen from another language.
Specifically, the language in which I am most productive.
They are not thought out. You just ripped an aspect from that other
language and threw it into a Python environment. This doesn't mean it
will fit into the language or scales beyond the small toy examples. What
about function names in tracebacks? What about nesting these anonymous
multiline functions? What about the impact on the grammar?

Ciao,
Marc 'BlackJack' Rintsch
Nov 9 '07 #18

P: n/a
On Fri, 09 Nov 2007 11:41:24 -0500, Frank Samuelson wrote:
So you like my ideas too!

>There are at least 2 posts a month by someone who decides that they
want to re-wire Python syntax. Usually it's because of some particular
idiom they're used to in another language,

And python does not use idioms from other languages?
Python doesn't haphazardly include features from other languages, no.
Any feature it borrows from another language will get the same
deliberation as an original suggestion gets, which is quite a lot.
>in other cases it's because
they've got some particular issue with "consistency".

My impression was that "consistency" was important to Python.
Important, yes. All-important, no.
"Consistency" improves my productivity because I don't have to keep
referring to the manual. Things work the way I expect them to work.
Really, should we be taking suggestions from someone who needs a manual
to recall the syntax of the def statement?

What you say is correct in principle, but it's senseless to apply it to
something you use every day, like def. It's like arguing that irregular
verbs make speech less productive.
>The ideas are
*never* fully thought out or materialized, and they invariably invite
scorn from the user community.

Of course, they're thought out: They're stolen from another language.
That's not well-thought out.

(Most language features are not well-thought out enough for their own
langauge, let alone in a new environment where well-thought-out-ness is
critical.)
Specifically, the language in which I am most productive.
>The poster is almost always a Python
beginner (I don't know if thats true in your case or not).

Only a couple years at it, but that is true of all of the languages that
I know, I guess...
>Arbitrary changes to syntax are never going to fly. It's a lost cause.

The changes are not arbitrary. They are logical, consistent, less
arbitrary and thus more productive.
The last doesn't necessary follow from the first three.
If such changes are a lost cause,
that is too bad, because it implies that Python will stagnate.
This doesn't even make sense, and is certainly not borne out by history.
Unfortunately that appears the case. Though backward compatibility is
not an issue (3.0 breaks stuff), I have learned that there are many
pythonistas who make up lots of arbitrary reasons not to change
anything, even if it is for the better.
I'm getting the feeling that to you, "arbitrary" is an synonym for
"something not pure enough for my personal taste".
>If you can't handle Python without your pet changes, fork it and write
your own version and let the marketplace of ideas decide if its useful.

Apparently you missed my statement about loving Python. I love it
because it is the second most productive language I have ever used,
though I do believe it has the potential to be the greatest ever by far.
You probably should go back to #1, then. The "defects in productivity"
in Python aren't going to be "fixed", and nobody's going to listen to you
as long as you justify your suggestions with such a narrowminded argument.

Carl Banks
Nov 9 '07 #19

P: n/a
Carl Banks wrote:
>"Consistency" improves my productivity because I don't have to keep
referring to the manual. Things work the way I expect them to work.

Really, should we be taking suggestions from someone who needs a manual
to recall the syntax of the def statement?

What you say is correct in principle, but it's senseless to apply it to
something you use every day, like def. It's like arguing that irregular
verbs make speech less productive.
They do for people who speak foreign languages. It's always easier
for me to remember Spanish verbs that conjugate regularly. And based
on the speaking snafus of my French coworker, I would say that it is
true for her English too!

Likewise, consistency helps me remember the syntax of the
seven or so programming languages that I use regularly.

>Unfortunately that appears the case. Though backward compatibility is
not an issue (3.0 breaks stuff), I have learned that there are many
pythonistas who make up lots of arbitrary reasons not to change
anything, even if it is for the better.

I'm getting the feeling that to you, "arbitrary" is an synonym for
"something not pure enough for my personal taste".
That was the point that I was trying to make to the previous poster,
who called my suggestions "arbitrary",
but who never actually addressed the suggestions.

The "defects in productivity"
in Python aren't going to be "fixed",
That doesn't sound very promising, though I'm not sure whom you are
quoting.

>
Carl Banks
Nov 9 '07 #20

P: n/a
Frank Samuelson a écrit :
Bruno Desthuilliers wrote:
>Yes. Python deliberately choosed to be a statement-based language.
>>Why not use the = operator like most other assignments?


This dead horse has been beaten to hell and back.

Note that as far as I'm concerned, I may like an expression-based
Python-inspired language. But this is another story.


My bad! In my rush I forgot that python requires the return statements.
You people think I'm trying to push lisp, which I am not.
Did I mention Lisp ??? No need to go lispish for this - Javascript
already does what you want here. FWIW, I was somewhat thinking out loud,
and I guess I thought of Javascript's use of anonymous functions, then
switched to Ruby (and it's code blocks), which took me to
expression-based languages. That's all.
(Apparently
many people do, because you are rather skittish.)
I don't get the point here.
In S the value of the last executed statement of a function is the
returned value of the function by default,
Which is what expression-based languages usually do - cf Ruby and most
functional languages.
if there is no return()
function.
Actually, in most languages, it's a statement !-)
It is very convenient for writing really small functions.
For really small functions, Python has lambda - which actually work that
way.
But skip that
for now.

foo = function(x,y) { # S language
if (x>2) return(x+y*2)
x+y
}

foo = func(x,y): # My suggested python syntax (Improved!)
if x>2: return x+y*2
return x+y
# put the function object in the code wherever you want it.
bb= bar( a,b, func(x,y): x=x*2 ; b=4 ; return x*b+y )
bb = bar(a, b, func(x,y):
for x in y:
if x 10:
do_something_with(x)
return y[-1] * 42

ho, wait, I have a couple keyword args to pass to bar too... How should
I do ? add a comma after the return statement ???

Franck, believe us, *this has been beaten to hell and back*. The point
is not that full anonymous functions are a bad thing (I personally use
them a lot in Javascript), but that it just doesn't fit within Python,
and that the necessary modifications would yield a mostly different
language. Perhaps a pretty good one, but not Python anymore. You see, I
don't necessarily share all Python's design choices, and I'm well aware
of some restrictions they impose. But day in, day out, it happens that
these choices are mostly coherent, and that the resulting language
offers a (IMHO) great balance between simplicity and power.
Non-programmers can (and do) use it, C programmers can (and do) use it,
Java programmers can (and do) use it, Lisp programmers can (and do) use
it, etc, etc, etc.
While I'm at it, classes are objects too. Assign names to them the
same way you assign names to _any_ other object: "="
Same problem. Note that in both cases, you already *can* build functions
and classes that way - as you say, they are objects, and both the def
and class statements are somewhat syntactic sugar. The only point is
that, to instanciate a function, you have more to do:

Help on class function in module __builtin__:

class function(object)
| function(code, globals[, name[, argdefs[, closure]]])
|
| Create a function object from a code object and a dictionary.
| The optional name string overrides the name from the code object.
| The optional argdefs tuple specifies the default argument values.
| The optional closure tuple supplies the bindings for free variables

>The Pythonic way to write "more complicated yet still comprehensible
list comprehensions" is to not use list comprehensions.

b = []
for x in vec1:
if x 0:
for y in vec2:
if y x:
b.append(x + y)

You have just demonstrated that list comprehensions are not really
necessary at all. So given the "one clear way of doing things",
Actually, it's: "there should be one - and preferably only one - obvious
way to do it". List comps are the obvious way for simple list
operations, and for loops are the obvious way for complex operations. If
you're in for Python Zen quotes, here are some others:
"""
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
"""

shouldn't they be removed? My point is that if you are going to
have them, why make some new unstructured syntax for them?
Because there's already a (well-known) structured syntax for the cases
that are too complex to fit a single, simple expression. It's a question
of balance between purity, readability, and practicallity.

Nov 9 '07 #21

P: n/a
Frank Samuelson a écrit :
(snip)
>Arbitrary changes to syntax are never going to fly. It's a lost cause.


The changes are not arbitrary.
Which ones ?
They are logical, consistent, less
arbitrary and thus more productive.
For who ?
If such
changes are a lost cause, that is too bad, because
it implies that Python will stagnate. Unfortunately that appears the case.
This is totally ridiculous. Let's see : list comprehensions, a new,
widely improved object system, with metaclasses, and the descriptor
protocol which brings customisable computed attributes -, lexical
closures, iterators, generator expressions, syntactic sugar for function
decorators, contexts (the 'with' statement), and coroutines. Just to
name a few, and only talking of production releases. Which other
language grew so many new features in the last seven years ? Java ? C ?
C++ ? Lisp ? VB (lol) ?

(snip)
>If you can't handle Python without your pet changes, fork it and write
your own version and let the marketplace of ideas decide if its
useful.

Apparently you missed my statement about loving Python. I love it
because it is the second most productive language I have ever used,
though I do believe it has the potential to be the greatest ever by
far.
I don't think you'll gain that much productivity by fighting against the
language trying to write <whatever-other-languagein it.
Nov 9 '07 #22

P: n/a
On Fri, 09 Nov 2007 11:41:24 -0500, Frank Samuelson wrote:

>The ideas are
*never* fully thought out or materialized, and they invariably invite
scorn from the user community.

Of course, they're thought out: They're stolen from another language.
Specifically, the language in which I am most productive.
No, they aren't fully thought out *at all*. To wit:

* you've suggested crippling tracebacks, throwing away the most important
piece of information they currently provide, just because you don't like
the def statement;

* you've suggested allowing sequences as indices into lists, completely
unaware that your two suggestions for what it should mean are mutually
incompatible;

* you've suggested getting rid of the slice syntax for no advantage;

* you've suggested making the function constructor itself a function, and
seem to be completely unaware that your request would need a very
different syntax to that Python already uses;

* you suggest two different versions for the function constructor, one
that is an expression and one that is a suite, but judging by your
comments you don't even realize they are two different versions.
Need I go on?
If you want your suggestions to be taken seriously, you need to think
them through carefully. Well-designed programming languages are not like
chop suey, where you grab whatever left-overs you have in the fridge and
mix them all together because you like the individual ingredients.

--
Steven.
Nov 9 '07 #23

P: n/a
On 9 Nov, 20:43, Frank Samuelson <newsdump0711.12.cud...@neverbox.com>
wrote:
Carl Banks wrote:
What you say is correct in principle, but it's senseless to apply it to
something you use every day, like def. It's like arguing that irregular
verbs make speech less productive.

They do for people who speak foreign languages. It's always easier
for me to remember Spanish verbs that conjugate regularly. And based
on the speaking snafus of my French coworker, I would say that it is
true for her English too!
But where do you seek consistency? It's true that "class" and "def"
both bind names in a namespace, and I either recall or have imagined
bizarre suggestions where "def" would be used for normal assignments,
but is the "inconsistency" really a problem? At some point you still
need to have a special syntactic component which says that, in the
case of a function, some code is going to follow (yes, "lambda" can do
this to an extent already, and people have argued for multi-line
lambdas to no avail), and similar cues are needed for classes. You
can't wipe away the things which provide meaning in the name of
consistency.
Likewise, consistency helps me remember the syntax of the
seven or so programming languages that I use regularly.
One can actually make an argument that people using noticeably
different natural languages are less likely to mix them up than people
using more similar languages; perhaps one can make the case for
programming languages too. For example, do people mix up Python and
SQL by accident? Java and C++?

[...]
The "defects in productivity"
in Python aren't going to be "fixed",

That doesn't sound very promising, though I'm not sure whom you are
quoting.
I started tracking some of the complaints about Python and comparing
them to Python 3000's supposed remedies. It's interesting reading:

http://wiki.python.org/moin/PythonWarts

Paul

Nov 10 '07 #24

P: n/a
On 2007-11-10, Terry Reedy <tj*****@udel.eduwrote:
I think you can regard 'No do statement' as rejected. Some
consider the non-proliferation of loop constructs a feature. I
believe this includes GvR.
Non-providing of the standard loop constructs, yes. But loop
constructs are plenty proliferate.

--
Neil Cerutti
Nov 10 '07 #25

P: n/a
Chris M write :
Multi-return value lambda? Just so you know, there is no concept of
returning more than one value from a function.
I wrote:
* multi return value lambda
I meant: multiple return statement, not return multiple values

pseudo code here:

lambda x: if A return B, if C return D, if E return F ...

it could be nice if ou could write normal functions ... as lambda ones
and not being limited to a subset of the kewords ...

at least it would fit Frank Samuleson needs/wishes better...
Nov 12 '07 #26

P: n/a
Loic Mahe <lo*******@nospam.frwrites:
Chris M write :
>Multi-return value lambda? Just so you know, there is no concept of
returning more than one value from a function.

I wrote:
>* multi return value lambda

I meant: multiple return statement, not return multiple values

pseudo code here:

lambda x: if A return B, if C return D, if E return F ...
You can do that with conditional expressions:

lambda x: B if A else D if C else F in E ...
it could be nice if ou could write normal functions ... as lambda
ones and not being limited to a subset of the kewords ...
It becomes natural if you think of lambda as a deferred expression
rather than as an anonymous function.
Nov 12 '07 #27

This discussion thread is closed

Replies have been disabled for this discussion.