Weblogs Forum - What Are Your Python Pain Points, Really?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
What Are Your Python Pain Points, Really?

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

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Flat View


Previous Topic		Next Topic

Threaded View: This topic has 24 replies on 1 page

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

Summary
Every Python programmer I talk to seems pretty darn happy, but every language design requires tradeoffs. What are your Python pain points?

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.

Re: What Are Your Python Pain Points, Really?

Posted: Feb 22, 2007 2:09 AM

Posted by: Tiago Antao Posts: 26 / Nickname: tiago / Registered: Feb, 2003

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...

Re: What Are Your Python Pain Points, Really?

Posted: Feb 22, 2007 2:39 AM

Posted by: Jean-Baptiste Potonnier Posts: 1 / Nickname: papafurax / Registered: Feb, 2007

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.

Lack of DSLs

Posted: Feb 22, 2007 9:59 AM

Posted by: Erik Engbrecht Posts: 210 / Nickname: eengbrec / Registered: Apr, 2006

>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.

Re: Lack of DSLs

Posted: Feb 23, 2007 10:09 AM

Posted by: Tiago Antao Posts: 26 / Nickname: tiago / Registered: Feb, 2003

> >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...

Re: Lack of DSLs

Posted: Feb 23, 2007 10:26 AM

Posted by: Ivan Lazarte Posts: 91 / Nickname: ilazarte / Registered: Mar, 2006

self It self seems self like self you self are self coding self "self" self alot.

Re: self self self

Posted: Feb 23, 2007 12:09 PM

Posted by: Micah Elliott Posts: 106 / Nickname: mde / Registered: Feb, 2007

> 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.)

Re: self self self

Posted: Feb 25, 2007 9:42 AM

Posted by: Merriodoc Brandybuck Posts: 225 / Nickname: brandybuck / Registered: Mar, 2003

> > 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.

Re: self self self

Posted: Mar 4, 2007 11:19 PM

Posted by: Matt Gerrans Posts: 1153 / Nickname: matt / Registered: Feb, 2002

I guess it was a contrived example, but:

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

Is the same as:

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

Re: self self self

Posted: Mar 5, 2007 6:02 AM

Posted by: Merriodoc Brandybuck Posts: 225 / Nickname: brandybuck / Registered: Mar, 2003

> I guess it was a contrived example, but:
>

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

> Is the same as:
>

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

It was. I have on that cranks through the event log and only outputs certain records. Something like

[logEntry for logEntry in allEntries if allEntries.logName == "myLog"]

But I can't remember the exact syntax and that particular block of code is not accessible to me at the moment so I didn't want to copy a total hack. Besides, that example is easily digested without having to go flail about documentation to figure out what pieces of pythonwin I'm using if they were so interested.

Glad to know I'm not the only language lawyer hanging around here :-)

Haven't seen you around these parts lately Matt.

Re: self self self

Posted: Mar 5, 2007 3:42 PM

Posted by: Matt Gerrans Posts: 1153 / Nickname: matt / Registered: Feb, 2002

> Haven't seen you around these parts lately Matt.

Yeah, if I'm not careful, someone is going to usurp my Posts standing (if it hasn't happened already).

I wanted to chime in on several of the long threads lately, but I don't like to make points that have already been made and I don't have time to get all the way though all the posts. :(

Maybe I'll just set aside an hour or two a week for Artima...

Re: Lack of DSLs

Posted: Feb 23, 2007 4:33 PM

Posted by: Erik Engbrecht Posts: 210 / Nickname: eengbrec / Registered: Apr, 2006

>(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.

Re: What Are Your Python Pain Points, Really?

Posted: Feb 22, 2007 12:34 PM

Posted by: Micah Elliott Posts: 106 / Nickname: mde / Registered: Feb, 2007

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.

Re: What Are Your Python Pain Points, Really?

Posted: Feb 23, 2007 9:33 AM

Posted by: Larry Bugbee Posts: 13 / Nickname: bugbee / Registered: Dec, 2004

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.

Re: What Are Your Python Pain Points, Really?

Posted: Feb 23, 2007 10:03 AM

Posted by: Eli Courtwright Posts: 14 / Nickname: eliandrewc / Registered: Jan, 2006

> 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.

Re: What Are Your Python Pain Points, Really?

Posted: Feb 23, 2007 9:41 PM

Posted by: Larry Bugbee Posts: 13 / Nickname: bugbee / Registered: Dec, 2004

> 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.

Re: What Are Your Python Pain Points, Really?

Posted: Feb 23, 2007 2:27 PM

Posted by: Leo Lipelis Posts: 111 / Nickname: aeoo / Registered: Apr, 2006

__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.

Re: What Are Your Python Pain Points, Really?

Posted: Feb 25, 2007 9:14 AM

Posted by: tim whidbey Posts: 1 / Nickname: catenary / Registered: Feb, 2007

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.

Re: What Are Your Python Pain Points, Really?

Posted: Feb 26, 2007 1:12 AM

Posted by: Torsten Marek Posts: 1 / Nickname: shlomme / Registered: Feb, 2007

1. os.path: There must be a decent way to handle files in the standard library.

2. str vs. unicode: Fortunately, that will go away with Python 3.0

3. I like generators and use them a lot. However, yielding values from nested generators is a pain. Maybe if Python had tail-call recursion, one could remedy that.

With greenlets, this is possible, so it should be supported by PyPy as well, though I haven't check lately.

Web programming.

Posted: Feb 28, 2007 5:44 AM

Posted by: Antonio Cavallo Posts: 10 / Nickname: cavallo71 / Registered: Mar, 2006

There are too many python's frameworks for web programming and
none of them has learn the lesson from php that is by far
the most used language for web (and the syntax is not
bad either especially compared to perl).

Php has two major points: is is simple to setup from
an administrator point of view (it really comes bundled
with all systems) and it has a trivial document model
(it is designed ground up to blend within html).

Thank to this simple model, users have the tools to build
frameworks bottom up that is more effective when
coding for a domain specific application.

More power than polish.

Posted: Mar 1, 2007 7:04 AM

Posted by: Jim Carroll Posts: 7 / Nickname: mrmaple / Registered: Jan, 2006

I'm a very happy python programmer. There are a few things that I'm sure will happen eventually...

Innovation is not always coordinated. Python eggs are a great, valuable idea, but if you're coding a Windows application with py2exe, you can't use eggs (yet) because py2exe doesn't have a good way to package them.

I enjoy coding wxPython apps with code-templates, but there's still room for a really good dialog builder. XRCed is probably the best alternative right now.

Lack of type information prevents my text editor from doing code-completion. I actually think this is a good thing, since it encourages the developer to memorize more... and having Python (even partially) memorized is a very powerful feeling. However, lots of Java and C# programmers don't like it because they're used to having IDE crutches.

It's not ubiquitous (yet.) This makes it hard to run with a python project because someone on the team has to bring up all the alternatives. (looks up into the ceiling cam: Damn you Ruby! :)

-Jim

Re: More power than polish.

Posted: Mar 2, 2007 8:02 AM

Posted by: Brandon Corfman Posts: 14 / Nickname: bcorfman / Registered: Aug, 2003

>I enjoy coding wxPython apps with code-templates, but there's still room for a really good dialog builder. XRCed is probably the best alternative right now.

Have you tried VisualWx? I really like it.

>Lack of type information prevents my text editor from doing code-completion.
Wing IDE, Komodo 4 or PyDev are good Python IDEs w/ pretty decent code completion if you haven't run across them yet. Makes it easier to sell to other developers, I agree.

Re: More power than polish.

Posted: Mar 3, 2007 2:06 PM

Posted by: Jim Carroll Posts: 7 / Nickname: mrmaple / Registered: Jan, 2006

> Wing IDE, Komodo 4 or PyDev are good Python IDEs w/ pretty
> decent code completion if you haven't run across them yet.
> Makes it easier to sell to other developers, I agree.

It's true, I use Wing IDE regularly, and if you assert your isinstances at the top of your functions, then the code completion is just about perfect:

def fun(a, b, c):
""" nice docstring. """
assert(isinstance(a, AsyncInterface))
assert(isinstance(b, BinaryStream))
assert(isinstance(c, Cache))

a.[list shows up just right]

But getting co-workers to do this is a pain... I still heard
about the lack of code completion.

-Jim

Re: More power than polish.

Posted: Mar 4, 2007 11:23 PM

Posted by: Matt Gerrans Posts: 1153 / Nickname: matt / Registered: Feb, 2002

>... don't like it because they're used to having
> IDE crutches.

Crutch? Why is a useful IDE a crutch? Is an editor a crutch? Is Python a crutch? Shouldn't you just be typing in machine instructions on a numeric keypad?

This reminds me of the annoying old "syntatic candy" canard.

The more the computer does, the better.

Re: What Are Your Python Pain Points, Really?

Posted: Mar 3, 2007 6:58 AM

Posted by: Chris Greb Posts: 1 / Nickname: cgrebeld / Registered: Dec, 2006

Lack of built-in support for true multi-threading on an SMP machine. I know there are many work-arounds for this but it would be nice if the threading modules in the standard library just worked as one would expect.

Previous Topic

Next Topic