The Artima Developer Community
Sponsored Link

Weblogs Forum
What Are Your Python Pain Points, Really?

24 replies on 2 pages. Most recent reply: Mar 5, 2007 3:42 PM by Matt Gerrans

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 24 replies on 2 pages [ 1 2 | » ]
Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

What Are Your Python Pain Points, Really? (View in Weblogs)
Posted: Feb 22, 2007 12:25 AM
Reply to this message Reply
Summary
Every Python programmer I talk to seems pretty darn happy, but every language design requires tradeoffs. What are your Python pain points?
Advertisement

The past two weeks I did a kind of needs analysis for both the Java and Ruby programming communities. I asked people to relate their Java pain points and Ruby pain points in our discussion forums. The discussion that ensued was interesting, so I thought I'd give Python programmers a similar opportunity.

My own experience with Python is similar to my experience with Ruby, though I've used Python more than Ruby. With one exception, I have only really used Python for relatively small scripts. The exception was a medium-sized script, which has been running in deployment for several years behind the scenes at Artima. My main concern about Python is performance and scalability, so I hope to hear from people who have built larger applications with Python. But what I'd really like to hear is whatever is truly a pain point for you with Python. So if you're a Python programmer, lay down on the couch and tell us your troubles. Please enter your top Python pain points in the discussion forum for this weblog post.


Tiago Antao

Posts: 26
Nickname: tiago
Registered: Feb, 2003

Re: What Are Your Python Pain Points, Really? Posted: Feb 22, 2007 2:09 AM
Reply to this message Reply
This is mainly a Python version of the points I had on using Ruby on scientific computing.

First, Python is the language that I am really using on my day-to-day work.

I find 2 main problems:
1. Speed. Really a problem outside the Database bottleneck scenario that most enterprise developers are used to (I suppose the vast majority of Artima readership). I have that background and it really is something important in the field of scientific computing. That is why there is still much Fortran code floating around (and because some scientists don't know any better).
2. Lack of support for DSLs. My main Python peeve.

I would like to have, as there is in CAML, the freedom to do explicit typing when desired. So I could
def do_something(param):
or
def do_something(string param):
Its amazing how, when debugging, forcing the type of parameters shows a lot...
I am not defending explicit typing _always_, just for it to be optional, like in CAML. Although I suppose it might be implemented with decorators and some cleverness around them...

Jean-Baptiste Potonnier

Posts: 1
Nickname: papafurax
Registered: Feb, 2007

Re: What Are Your Python Pain Points, Really? Posted: Feb 22, 2007 2:39 AM
Reply to this message Reply
Ocaml typing, just like Haskell, is not optionnal but juste inferred.
In fact in Ocaml you can specify a type, to be less general than the inferred type.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Lack of DSLs Posted: Feb 22, 2007 9:59 AM
Reply to this message Reply
>2. Lack of support for DSLs. My main Python peeve.

Huh? How much support do you want? How much have you worked with metaclasses?

It's true that Python syntax isn't particularly malleable...but I think that's good. LISP is great for DSLs but sometimes the only way you can tells it's LISP is all the parenthesis.

Micah Elliott

Posts: 106
Nickname: mde
Registered: Feb, 2007

Re: What Are Your Python Pain Points, Really? Posted: Feb 22, 2007 12:34 PM
Reply to this message Reply
AMK wrote an article on Python Warts a few years ago: http://www.amk.ca/python/writing/warts

The "X-lang warts" theme seems to be a popular article subject for various X languages.

Larry Bugbee

Posts: 13
Nickname: bugbee
Registered: Dec, 2004

Re: What Are Your Python Pain Points, Really? Posted: Feb 23, 2007 9:33 AM
Reply to this message Reply
I want to optionally declare my data types. Hopefully this will not only serve to reduce confusion, but could improve performance because the type is known.

If decorators are to remain, I'd like to see syntax that better suggests the semantics. It is extremely confusing, so much so I discourage their use.

Eli Courtwright

Posts: 14
Nickname: eliandrewc
Registered: Jan, 2006

Re: What Are Your Python Pain Points, Really? Posted: Feb 23, 2007 10:03 AM
Reply to this message Reply
> If decorators are to remain, I'd like to see syntax that
> better suggests the semantics. It is extremely confusing,
> so much so I discourage their use.

Can you give an example of decorators being confusing? I've only used them a few times for very simple things, so your comment makes me curious.

Tiago Antao

Posts: 26
Nickname: tiago
Registered: Feb, 2003

Re: Lack of DSLs Posted: Feb 23, 2007 10:09 AM
Reply to this message Reply
> >2. Lack of support for DSLs. My main Python peeve.
>
> Huh? How much support do you want? How much have you
> worked with metaclasses?

Not as much as I should, I mainly base my reasoning on what I read. Most "elegant" programming (or attempts of) that I have done are Java (poor) and Prolog (heaven). In fact my Python is still quite intermediate, so I might be wrong...

Prolog :-op directive
say this "enterprise web" example:

(id, name) of person render html_link_table(detail).


(id, name) of person would be converted to an SQL query returning a list of tuples.
render would take a list of tuples and pass it to the predicate html_link_table generating a HTML table with a URLs pointing to a detail function.

I know Prolog running code precisely like this, I would like to do this in Python. Maybe I am just basing myself too much on the perceived reality, more than in what can really be done...

Ivan Lazarte

Posts: 91
Nickname: ilazarte
Registered: Mar, 2006

Re: Lack of DSLs Posted: Feb 23, 2007 10:26 AM
Reply to this message Reply
self It self seems self like self you self are self coding self "self" self alot.

Micah Elliott

Posts: 106
Nickname: mde
Registered: Feb, 2007

Re: self self self Posted: Feb 23, 2007 12:09 PM
Reply to this message Reply
> self It self seems self like self you self are self coding
> self "self" self alot.

Agreed! I wish we had conventionalized s instead of self. Seems too late now.

Better yet would be to enable self to be implicit so any .foo would actually be self.foo. (Please don't tell me to import this.)

Leo Lipelis

Posts: 111
Nickname: aeoo
Registered: Apr, 2006

Re: What Are Your Python Pain Points, Really? Posted: Feb 23, 2007 2:27 PM
Reply to this message Reply
__self.

There are too many double double underscores, like __blah__, for various build-in APIs.

Speed.

Better support for functional style programming.

Disclaimer: I haven't used the latest version of Python, so some of these might have been remedied already.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Lack of DSLs Posted: Feb 23, 2007 4:33 PM
Reply to this message Reply
>(id, name) of person render html_link_table(detail).

You could do:

html_link_table(Person.query("id", "name"), detail))

where html_link_table takes an object supporting the iterator protocol that generate tuples which will be rendered as hyperlinks generated by passing each tuple the the function detail. Person is a class (which could be automagically generated from the DB schema, task #11243 on my list) and the query method generates the SQL and returns an iterator that will spit out the tuples.

It's not precisely the same but I think it is just as readable and concise. There are other ways to approach it. I've written code to do similar things.

You could turn thins around a bit and do:

Person.render(("id", "name"), html_link_table(detail))

In which case Person.render would feed the tuples into html_link_table (probably an object implementing the __call__ method) which would in turn generate the links using detail.

Larry Bugbee

Posts: 13
Nickname: bugbee
Registered: Dec, 2004

Re: What Are Your Python Pain Points, Really? Posted: Feb 23, 2007 9:41 PM
Reply to this message Reply
> Can you give an example of decorators being confusing?
> I've only used them a few times for very simple things,
> , so your comment makes me curious.

Not to start a flame war (I know the dicy history), and perhaps I don't understand decorators, but...

It seems decorators can be likened to function wrappers. If that be the case, I'd expect the syntax to *look* like a function wrapper. The use of @somename doesn't connote that.

Like I say, the whole thing is confusing and that disappoints me. One of the chief attractors to Python is/was its simplicity and clarity of expression. It seems the current implementation of decorators took away that innocence. ...my opinion.

tim whidbey

Posts: 1
Nickname: catenary
Registered: Feb, 2007

Re: What Are Your Python Pain Points, Really? Posted: Feb 25, 2007 9:14 AM
Reply to this message Reply
Lack of a stable ABI. This makes distributing extension modules or apps which target multiple Python releases needlessly painful. The C API should remain backward compatible unless there's a major new release like 3.0.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: self self self Posted: Feb 25, 2007 9:42 AM
Reply to this message Reply
> > self It self seems self like self you self are self
> coding
> > self "self" self alot.
>
> Agreed! I wish we had conventionalized s
> instead of self. Seems too late now.
>
> Better yet would be to enable self to be
> implicit so any .foo would actually be
> self.foo. (Please don't tell me to
> import this.)


I have to agree with this as well. I have a couple other ones:

1. The pace with which things change. Sometimes it's slow, sometimes the changes seem very big. The one I'm thinking of particularly is the addition of list comprehensions. These were a pretty big change for me and it took me a while to actually see what they were about. Now that I understand them I think they are fantastic. I won't go so far as to say that I look for excuses to code them, but they sure do come in pretty damn handy. And they are nice and compact, too.

2. Related to list comprehensions, some of the examples available in the documentation are terrible. They are worse than useless because they show nothing of some of the more useful features. Again, list comprehensions is my most recent example of this. The filters for them are very useful, but the docs don't show any good examples of that at all. A real simple one would be all the odd numbers and the number times 2 up to 20.

[[x, 2*x] for x in range(20) if x % 2]

The filter is one of the most powerful features of the comprehension but I can't find one single good example in the standard python docs.

3. This is kind of stupid, but the ':' at the end of certain statements seems unnecessary to me. Indentation controls scope so why do we need to type


for x in range(10):
print x


that being said, I'll still work in python whenever I get the chance.

Flat View: This topic has 24 replies on 2 pages [ 1  2 | » ]
Topic: What Are Your Python Pain Points, Really? Previous Topic   Next Topic Topic: TurboGears Jam

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use