things I wish python could do

[Ryan Paul]

I've spent a lot of time using python, and personally, I feel like it is
vastly superior when compared to languages like java, and c++, but there
are still a few things that detract from its elegance and flexibility. I
thought I might mention a few of them. I'd like to hear what people think
of my complaints, and I also like to hear the complaints of others.

1. many keywords (eg:try/except) are strictly imperative, and cannot be
used in a functional context.

this really should be possible: map(print,mylist)

2. there is no easy way to extend existing classes externally.

its possible, but it aint pretty...

class Shape:
def __init__(self,numSides, perimeter):
pass

Currently you can do this:

Shape.__dict__.update({
'triangle':ClassMethod(
lambda self,sideLength: Shape(3,sideLength*3))

'square':ClassMethod(
lambda self,sideLength: Shape(4,sideLength*4))
})

I want a way to extend a class as easily as I can define it.

3. you cant extend the builtins (string,list,etc), you have to inherit
them. Guido says he wont let us because it would create compatability
issues, and possibly break the interpreter. Maybe if we had namespace
functionality, that wouldnt be an issue?

4. assignments cant be made inside of anonymous functions.

I think most python programmers will agree, that python emphasizes
simplicity, readability, and uniformity. Ultimately, I dont think that any
of those things are important enough to justify the reduction of
flexibility, syntactic mutability, and versatility. I was surprised to
find that Ruby solves all of my python complaints, while achieving
grace and simplicity easily comparable to that of python, and providing a
few innovative extras (including real private, public, and protected
methods).

Despite the fact that I disagree with quite a bit of the philosophy behind
prothon, I have enjoyed watching it, because it inspires good dialogue
about language development. (as long as those with closed minds keep their
mouths closed as well)

Are there are any strong reasons why a language shouldn't support the
things I list? Is anybody aware of features promised for future python
versions that solve or nullify my problems? Are any of my perceived
problems really just products of ignorance?

[Scott David Daniels]

Ryan Paul wrote:

I've spent a lot of time using python, and personally, I feel like it is
vastly superior when compared to languages like java, and c++, but there
are still a few things that detract from its elegance and flexibility.

1. many keywords (eg:try/except) are strictly imperative, and cannot be
used in a functional context. Python is a language of statements and expressions. This won't change.
If you dislike this feature, ml, lisp, (or it seems, ruby) will be more
to your liking. Python has an imperative definition. A pure functional
system has problems defining things like "print" which, by their very
nature, cause side-effects.
this really should be possible: map(print,mylist) After:
def prints(*args):
print ', '.join(map(str, args))
you can do:
map(prints, mylist)
or even:
prints(*mylist)
2. there is no easy way to extend existing classes externally.
its possible, but it aint pretty...

class Shape:
def __init__(self,numSides, perimeter):
pass
Currently you can do this:
Shape.__dict__.update({
'triangle':ClassMethod(
lambda self,sideLength: Shape(3,sideLength*3))

'square':ClassMethod(
lambda self,sideLength: Shape(4,sideLength*4))
})
I want a way to extend a class as easily as I can define it.

OK, this is just plain wrong. You are walking the wrong way around a
building and then claiming, "these two doors are too far apart."

class Shape:
def __init__(self,numSides, perimeter):
self.numSides = numSides
self.perimeter = perimeter
# which is, I expect what you meant)

Shape.triangle = classmethod(lambda klass, side: klass(3, side*3))
Shape.square = classmethod(lambda klass, side: klass(4, side*4))
and even:
Shape.__repr__ = lambda self: 'Shape(%r, %r)' % (self.numSides,
self.perimeter)

Using klass above allows you to follow this code with:
class FunnyShape(Shape):
def avgSide(self):
return float(self.perimeter) / self.numSides

where you can then:
FunnyShape.triangle(5).avgSide()
3. you cant extend the builtins (string,list,etc), you have to inherit
them. Guido says he wont let us because it would create compatability
issues, and possibly break the interpreter. Maybe if we had namespace
functionality, that wouldnt be an issue? Nope, the complaint is about affecting the global environment
(thus making packages that you import unsure of the behavior of
the primitives).
4. assignments cant be made inside of anonymous functions. The idea is that generally anonymous functions should be trivial, or
you are better off separately defining them and assigning a meaningful
name to the code. Such code takes more effort at the time you write it,
but the code becomes much more readable.
I think most python programmers will agree, that python emphasizes
simplicity, readability, and uniformity.
Ultimately, I dont think that any of those things are important
enough to justify the reduction of flexibility, syntactic
mutability, and versatility.

Then you really would prefer ruby or smalltalk. If you are building
non-trivial, long-lived programs, you spend _far_ more time reading
code than writing it. Flexibility is important, but there need not
be more than one way to do something to accommodate tastes. Code
that mixes styles is the hardest kind of code to read (other than
machine-generated code).

I believe syntactic mutability is an idea that has been tried and
found wanting. The more you can define non-standard syntax, the
more you have to know about a particular piece of code before you
can read it.

As for versatility, the pinnacle of versatility and flexibility
is machine code (not that wimpy assembler). I have found very
few things I'd avoid doing in python, and most of those can be
build as extension modules fairly easily.

I've seen too many interlisp and smalltalk code sets that cannot
use each other's modules. When you can modify the primitives
of a system for your convenience, it becomes tough to work with
someone else who doesn't share your particular quirks of how to
modify the base system.

After having written code for more than three decades, I find python
refreshing in having a language system with a clear discernible,
readable structure that I can trust.

Sorry for having taken troll-bait if that is what this post was.

--
-Scott David Daniels
Sc***********@Acm.Org

[Peter Maas]

Ryan Paul wrote:

1. many keywords (eg:try/except) are strictly imperative, and cannot be
used in a functional context.

this really should be possible: map(print,mylist)

To make everything functional in Python would probably be a
huge effort with cosmetic effects only. What about defining
e.g.

def fprint(item):
print item

putting all functional definitions in a module 'functional'
and using it:

from functional import fprint

....
map(fprint, mylist)

Mit freundlichen Gruessen,

Peter Maas

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
Tel [phone] Fax [phone] eMail pe********@mplusr.de
-------------------------------------------------------------------

[Jacek Generowicz]

Ryan Paul <se*******@sbcglobal.net> writes:

I've spent a lot of time using python, and personally, I feel like it is
vastly superior when compared to languages like java, and c++, but there
are still a few things that detract from its elegance and flexibility. I
thought I might mention a few of them. I'd like to hear what people think
of my complaints, and I also like to hear the complaints of others.

1. many keywords (eg:try/except) are strictly imperative, and cannot be
used in a functional context.
Yes, I find the whole statement expression dichotomy one huge PITA.
this really should be possible: map(print,mylist)

2. there is no easy way to extend existing classes externally.

its possible, but it aint pretty...

class Shape:
def __init__(self,numSides, perimeter):
pass

Currently you can do this:

Shape.__dict__.update({
'triangle':ClassMethod(
lambda self,sideLength: Shape(3,sideLength*3))

'square':ClassMethod(
lambda self,sideLength: Shape(4,sideLength*4))
})
Which looks like (I don't know what ClassMethod is) a long-winded way
of wrting:

Shape.triangle = lambda self, sideLength: Shape(...))
I want a way to extend a class as easily as I can define it.
You can. There is one syntax for creating new classes, and another for
mutating existing ones. Ruby conflates the two.

I think that what you "want" is to cleate new classes and mutate
existing ones using the same syntax. Perhaps you should question
whether you really want that.

Maybe there's a satisfactory solution based on the decorators that are
being proposed in PEP 318:

class Shape [update]:
def triangle(self, sideLength):
...
4. assignments cant be made inside of anonymous functions.
Actually, there's very little you can do in anonymous functions, given
that you are restricted to a _single expression_.
I was surprised to find that Ruby solves all of my python
complaints, while achieving grace and simplicity easily comparable
to that of python, and providing a few innovative extras (including
real private, public, and protected methods).
Yes, access-restricted private methods were an innovation in the field
of programmer productivity reduction, but it was not an innovation on
Ruby's part ... though why a language which sounds quite sensible,
would choose to embrace such a criminal practice is a mystery to me.

(Hmm ... briefly perusing a Ruby manual, I get the impression that
some of it is a result of having to get around problems caused by all
classes inheriting all (would-be) global functions ... which makes me
reconsider my statement that Ruby sounds quite sensible.)
Are there are any strong reasons why a language shouldn't support the
things I list?
1) Keywords are just plain wrong.

4) Python's indentation-based block structure makes general anonymous
functions a bit problematic. (Briefly perusing the PEPs I notice 308
... and I'm surprised that it's publication date is not April 1st,
as it looks like a PERLification attempt.)
Is anybody aware of features promised for future python versions
that solve or nullify my problems?
Read the PEPs.
Are any of my perceived problems really just products of ignorance?

Probably.

I'm feeling in a controversy-stirring mood. Can you tell?

With any luck I've trodden on Python's, Ruby's and your toes :-)

[Andrew Bennetts]

On Thu, May 13, 2004 at 10:07:19AM +0200, Jacek Generowicz wrote:
[...]

I want a way to extend a class as easily as I can define it.

You can. There is one syntax for creating new classes, and another for
mutating existing ones. Ruby conflates the two.

I think that what you "want" is to cleate new classes and mutate
existing ones using the same syntax. Perhaps you should question
whether you really want that.

Maybe there's a satisfactory solution based on the decorators that are
being proposed in PEP 318:

class Shape [update]:
def triangle(self, sideLength):
...

Or there's the evil solution, available right now:
http://www.intarweb.us:8080/evil/reopenable.py

-Andrew.

[Terry Reedy]

"Jacek Generowicz" <ja**************@cern.ch> wrote in message
news:ty*************@pcepsft001.cern.ch...

Ryan Paul <se*******@sbcglobal.net> writes: Yes, I find the whole statement expression dichotomy one huge PITA.
Would you really prefer writing <target> = expression as set('<target>',
expression) or as the 'special-form' pseudofunction call setq(<target>,
expression)? Just about all Python statements are statements because they
would also be a PITA, and possibly more so, as expressions.

4. assignments cant be made inside of anonymous functions.

Actually, there's very little you can do in anonymous functions, given
that you are restricted to a _single expression_.

Lambda expressions in Python are strictly an abbreviation for functions
with a trivial body ('return expression'), nothing more. Anonymity is a
wart, not a feature. The keyword is, to me, a mistake because of the false
expectations it stimulates.
I'm feeling in a controversy-stirring mood. Can you tell?

Bait taken ;-)

Terry J. Reedy

[Daniel 'Dang' Griffith]

On Thu, 13 May 2004 12:35:48 -0400, "Terry Reedy" <tj*****@udel.edu>
wrote:

"Jacek Generowicz" <ja**************@cern.ch> wrote in message
news:ty*************@pcepsft001.cern.ch...

Ryan Paul <se*******@sbcglobal.net> writes:

Yes, I find the whole statement expression dichotomy one huge PITA.

.....

> 4. assignments cant be made inside of anonymous functions.

Actually, there's very little you can do in anonymous functions, given
that you are restricted to a _single expression_.

Lambda expressions in Python are strictly an abbreviation for functions
with a trivial body ('return expression'), nothing more. Anonymity is a
wart, not a feature. The keyword is, to me, a mistake because of the false
expectations it stimulates.

Maybe lambda should be renamed as lameda? ;-)
--dang "$.02 too much" dude

[Ville Vainio]

>>>>> "Terry" == Terry Reedy <tj*****@udel.edu> writes:

Terry> Would you really prefer writing <target> = expression as
Terry> set('<target>', expression) or as the 'special-form'
Terry> pseudofunction call setq(<target>, expression)? Just about
Terry> all Python statements are statements because they would
Terry> also be a PITA, and possibly more so, as expressions.

Couldn't a = 10 still be an expression despite the syntax? Or at least
behave like one, i.e. yield a result, probably 10 or None...

These days I do think it's not that big a deal, though. Putting
assignment into the condition part of while is a habit people will
outgrow, and other statements would be very clumsy as expressions.

--
Ville Vainio http://tinyurl.com/2prnb

[rzed]

Daniel 'Dang' Griffith <no*****@noemail4u.com> wrote in
news:e2******************************@news.teranew s.com:

On Thu, 13 May 2004 12:35:48 -0400, "Terry Reedy"
<tj*****@udel.edu> wrote:

[...]

Lambda expressions in Python are strictly an abbreviation for
functions with a trivial body ('return expression'), nothing
more. Anonymity is a wart, not a feature. The keyword is, to
me, a mistake because of the false expectations it stimulates.

Maybe lambda should be renamed as lameda? ;-)

Or: lambada -- the forbidden function.

--
rzed
No more than $0.01 here.

[Ville Vainio]

>>>>> "rzed" == rzed <rz*****@ntelos.net> writes:

Maybe lambda should be renamed as lameda? ;-)

rzed> Or: lambada -- the forbidden function.

Or leave it to Lambda - the function that dare not speak its name.

(I guess I need to get some sleep now)

--
Ville Vainio http://tinyurl.com/2prnb

[Jacek Generowicz]

"Terry Reedy" <tj*****@udel.edu> writes:

Would you really prefer writing <target> = expression as set('<target>',
expression) or as the 'special-form' pseudofunction call setq(<target>,
expression)?

Almost. I'd really like to write it thus:

(setq <target> expression)

then we'd really be getting somewhere.

I'm feeling in a controversy-stirring mood. Can you tell?

Bait taken ;-)

Here's some more, if you still have the apetite :-)

[Michael Walter]

Ville Vainio wrote:

Couldn't a = 10 still be an expression despite the syntax? Or at least
behave like one, i.e. yield a result, probably 10 or None...

I would think so -- even in C(++) it's possible to write:

a = b = 10;

Cheers,
Michael

[David Eppstein]

In article <2g************@uni-berlin.de>,
Michael Walter <[e-mail]> wrote:

Couldn't a = 10 still be an expression despite the syntax? Or at least
behave like one, i.e. yield a result, probably 10 or None...

I would think so -- even in C(++) it's possible to write:

a = b = 10;

It's possible to write that in Python, too, but nevertheless in Python
the "b = 10" part isn't an expression.

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science