My Python annoyances

[=?iso-8859-1?B?QW5kcuk=?=]

I'm really annoyed at Python - and not for the reasons already
mentioned on this list.

Everyone know that programming is supposed to be a dark art, nearly
impossible to learn. Computer code is supposed to be something
impossible to read to the common person and yet reveal their secrets
to the initiated - just remember the code displayed in the Matrix...

Python takes all of that away. It is just too readable. Even
beginners can quickly learn to read code written by experts.

To make it even friendlier to beginners, Python uses ugly double
underscores both as prefix and suffix on "magic methods" to be invoked
only by more advanced programmers. What's the fun in hiding the
complexity so that beginners can stay away from potential problems.

And why, oh why, does raw_input() have to go? Here was at least one
good example of something that gave a hint (what does "raw" mean?) at
the underlying complexity. Combined with the evil of the hidden eval
in the more obvious input(), there was at least a chance to trip
beginners into doing something "dangerous". Alas, that will no longer
be the case...

Python does not even make good use of weird symbols like $ and @ and %
to define variable types like Perl does. Now, that's a language to
learn if you want to be respected. I think that Georg Brandl had it
right in his recent proposal:
http://mail.python.org/pipermail/python-dev/2007-April/072419.html

If not Perl, perhaps Python should be inspired by a language like C++,
full of arcane stuff and, thankfully, requiring typing declaration.
This dynamic typing thing makes it just too easy to write working
programs quickly, especially combined with the ease of use of the
interpreter. And this other thing called "duck typing" is just too
flexible to use.

No, Python should be more difficult. It should take a full two
minutes to compile a "Hello World" program on a modern computer.

Also, this "docstring" business has to go. Any programmer should, as
a rite of passage, have to spend countless hours reading obscure
documentation to learn other people's code before finding out what
methods can be used and how they should be used. Having to use things
like "dir" and "help" just makes it too easy.

And don't get me started about the absence of curly braces to define
blocks of code. What's the fun in making it so darn visually easy to
define such blocks of code, removing the possibility of creating
subtle bugs due to the misplacement of a curly bracket. No sir, with
Python, the structure has to be obvious at a glance - newbies can see
it just as well as experts, thereby decreasing the aura surrounding
the latter. This is not fair for people that have spent dozens of
hours in learning to program using Python!

And don't talk to me about functions, classes and methods, not to
mention modules. Python makes it too easy to write code in many
different styles, trying to please people who like to write only
object-oriented code as well as those that follow the more traditional
procedural approach. Even "functional" type people find their way to
write code in their preferred method using Python. This is not right.

Fortunately, Python has incorporated some newbie-unfriendly features,
like metaclasses and, to a lesser extent, decorators which, at last,
make use of a special character. There should be more of these, to
make Python something more challenging to learn.

Programming should be more difficult than this - otherwise, how can
programmers be respected by the common folks?

 

[Stef Mientki]

Programming should be more difficult than this - otherwise, how can
programmers be respected by the common folks?

the answer is very simple (even more simple than Python ;-) ...
.... create what common folks ask for !!

cheers,
Stef Mientki

 

[Basilisk96]

Everyone know that programming is supposed to be a dark art, nearly

impossible to learn. Computer code is supposed to be something
impossible to read to the common person and yet reveal their secrets
to the initiated - just remember the code displayed in the Matrix...

Hmm, on my PyCon mug there are words "Python: so easy...even your BOSS
can use it!"
Thankfully, my boss doesn't know the difference between directories
and files, so I can easily succeed in making him think that Python
really IS a black art

Cheers
-Basilisk96

 

[James Stroud]

I'm really annoyed at Python - and not for the reasons already
mentioned on this list.

Everyone know that programming is supposed to be a dark art, nearly
impossible to learn. Computer code is supposed to be something
impossible to read to the common person and yet reveal their secrets
to the initiated - just remember the code displayed in the Matrix...

Python takes all of that away. It is just too readable. Even
beginners can quickly learn to read code written by experts.

To make it even friendlier to beginners, Python uses ugly double
underscores both as prefix and suffix on "magic methods" to be invoked
only by more advanced programmers. What's the fun in hiding the
complexity so that beginners can stay away from potential problems.

And why, oh why, does raw_input() have to go? Here was at least one
good example of something that gave a hint (what does "raw" mean?) at
the underlying complexity. Combined with the evil of the hidden eval
in the more obvious input(), there was at least a chance to trip
beginners into doing something "dangerous". Alas, that will no longer
be the case...

Python does not even make good use of weird symbols like $ and @ and %
to define variable types like Perl does. Now, that's a language to
learn if you want to be respected. I think that Georg Brandl had it
right in his recent proposal:
http://mail.python.org/pipermail/python-dev/2007-April/072419.html

If not Perl, perhaps Python should be inspired by a language like C++,
full of arcane stuff and, thankfully, requiring typing declaration.
This dynamic typing thing makes it just too easy to write working
programs quickly, especially combined with the ease of use of the
interpreter. And this other thing called "duck typing" is just too
flexible to use.

No, Python should be more difficult. It should take a full two
minutes to compile a "Hello World" program on a modern computer.

Also, this "docstring" business has to go. Any programmer should, as
a rite of passage, have to spend countless hours reading obscure
documentation to learn other people's code before finding out what
methods can be used and how they should be used. Having to use things
like "dir" and "help" just makes it too easy.

And don't get me started about the absence of curly braces to define
blocks of code. What's the fun in making it so darn visually easy to
define such blocks of code, removing the possibility of creating
subtle bugs due to the misplacement of a curly bracket. No sir, with
Python, the structure has to be obvious at a glance - newbies can see
it just as well as experts, thereby decreasing the aura surrounding
the latter. This is not fair for people that have spent dozens of
hours in learning to program using Python!

And don't talk to me about functions, classes and methods, not to
mention modules. Python makes it too easy to write code in many
different styles, trying to please people who like to write only
object-oriented code as well as those that follow the more traditional
procedural approach. Even "functional" type people find their way to
write code in their preferred method using Python. This is not right.

Fortunately, Python has incorporated some newbie-unfriendly features,
like metaclasses and, to a lesser extent, decorators which, at last,
make use of a special character. There should be more of these, to
make Python something more challenging to learn.

Programming should be more difficult than this - otherwise, how can
programmers be respected by the common folks?

I want to complain about the fact that I wrote 200 lines the other day
and it worked first time. Problem was, I spent 20 minutes before I
realized that the lack of errors was a result of the lack of bugs.

 

[Aahz]

Programming should be more difficult than this - otherwise, how can
programmers be respected by the common folks?

http://www.netfunny.com/rhf/jokes/98/May/stroustrup.html
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"...string iteration isn't about treating strings as sequences of strings,
it's about treating strings as sequences of characters. The fact that
characters are also strings is the reason we have problems, but characters
are strings for other good reasons." --Aahz

 

[Alex Martelli]

André wrote:

[snipping total repost of André's post]

 

[Isaac Rodriguez]

Hmm, on my PyCon mug there are words "Python: so easy...even your BOSS

can use it!"

Oh man! I would've killed for a mug like that a year ago. I was
working for this guy, who had the entire build process automated
in .BAT scripts. We spent more time fixing the build process than
devoloping our product.

Anyway, I started to move the entire thing to Python. Using a real
programming language, allows creating a more robust process. It also
allows separating data and code, which comes very handy when the data
changes to not have to touch the code.

So a year ago, I moved to another department. I would not get into the
details of why, but I am just going to say that I'm much happier now.
One day, I walking down the hall, and I see a book in my old boss'
desk: "Learning Perl." I thought to my self, "You gotta be kiddin". So
I saw him in the coffee area, and I asked him about it. His answer
was, "Yeah, I'm re-writing the build scripts in Perl because you are
the only one that knew Python, and we need to maintain them."

Well, there is no-one in that team that knows Perl either, and if they
haven't been able to learn Python in the couple of years I tried to
push it, I really doubt they are going to learn Perl. Or maybe, the
problem was that I was trying to push Python, so they are doing this
just to prove me wrong.

Like I said, I'm much happier now, and so much glad to be out of that
team.

Thanks,

- Isaac.

 

[Bruno Desthuilliers]

James Stroud a écrit :
(snip)

I want to complain about the fact that I wrote 200 lines the other day
and it worked first time. Problem was, I spent 20 minutes before I
realized that the lack of errors was a result of the lack of bugs.

+1 QOTW

 

[Ben Collver]

I rewrote my code in Python and I found myself running into many of the
same hassles that I run into with other languages: inaccurate and
incomplete documentation, a maze of little platform-specific quirks to
work around in the base classes, and a macho community of users.

The python web site recommended Dive Into Python, so I learned by
reading that. It has several examples that don't work because the
Python base classes have changed behavior. I should have taken that as
lesson.

I tried to write portable Python code. The zlib CRC function returned
different results on architectures between 32 bit and 64 bit
architectures. I filed a bug report. It was closed, without a comment
from the person who closed it. I get the unspoken message: bug reports
are not welcome.

I installed Cygwin on a Windows machine. I try to quit from an
interactive Python session. It tells me that on my platform, I must
press Control-Z to exit. I press Control-Z and it makes Python a
background process.

I tried to use the XML.minidom. The documentation here is minimal as
well. So I read up on other web sites. It turns out that the interface
has changed quite a bit from the documentation I found on other web
sites. Where are the much loved docstrings? In 2.3 minidom, they are
sparse and cryptic.

Between 2.4 and 2.5, tempfile returns a different type of object. My
code cannot have a single test, it has check for type(obj) == file or
obj.__class__ == tempfile._TemporaryFileWrapper.

I decided to make a tkinter front-end for a Python program. I decided
to go with tkinter because it is included with many Python
installations, so it maximizes the chance for my program to run out of
the box.

The tkinter documentation on the Python site mainly consists of loose
notes and links to other sites. The documentation on other sites is
great, if you already know how to use tkinter. I ran into bugs in
TkAqua which make the grid layout unusable for me. So I will need to
ask potential users to install Xcode, X11, and mac ports, if they want
to run my program.

In short, there is plenty of room for improvement. Admittedly these are
not problems with the language definition. But I downloaded a Python
distribution, and the problems are Python specific.

 

[Paul Boddie]

I rewrote my code in Python and I found myself running into many of the
same hassles that I run into with other languages: inaccurate and
incomplete documentation, a maze of little platform-specific quirks to
work around in the base classes, and a macho community of users.

I'm sorry to hear about that. If by "macho" you mean people who insist
that things are good enough as they are, and that newcomers should
themselves adapt to whatever they may discover, instead of things
being improved so that they are more intuitive and reliable for
newcomers and experienced developers alike, then I'd certainly be
interested in undermining that culture.

The python web site recommended Dive Into Python, so I learned by
reading that. It has several examples that don't work because the
Python base classes have changed behavior. I should have taken that as
lesson.

Really Dive Into Python should be a sufficient guide, and it was
perhaps the best introduction to the language when it was written. It
is very unfortunate that the language has changed in a number of ways
(and exhibits continued change) whilst effort into documenting what is
already there remains neglected amongst the people making all the
changes.

I tried to write portable Python code. The zlib CRC function returned
different results on architectures between 32 bit and 64 bit
architectures. I filed a bug report. It was closed, without a comment
from the person who closed it. I get the unspoken message: bug reports
are not welcome.

Can you provide the bug identifier? Bug reports are generally welcome,
and despite complaints about patch reviews, I've found people
reviewing things I've submitted.

I installed Cygwin on a Windows machine. I try to quit from an
interactive Python session. It tells me that on my platform, I must
press Control-Z to exit. I press Control-Z and it makes Python a
background process.

Yes, Ctrl-Z exits Python in the standard Windows edition. Since Cygwin
provides a POSIX-like environment, Ctrl-D should be used instead. If
the documentation is wrong, a bug report or patch should be filed
against the software.

I tried to use the XML.minidom. The documentation here is minimal as
well. So I read up on other web sites. It turns out that the interface
has changed quite a bit from the documentation I found on other web
sites. Where are the much loved docstrings? In 2.3 minidom, they are
sparse and cryptic.

I really don't know what to say about the PyXML/xmlcore situation. I
don't use ElementTree and hardly use PyXML or minidom, but something
really should have been done about the maintenance of the established
libraries rather than declaring them as legacy items and pretending
that they don't exist.

Between 2.4 and 2.5, tempfile returns a different type of object. My
code cannot have a single test, it has check for type(obj) == file or
obj.__class__ == tempfile._TemporaryFileWrapper.

Try using isinstance or relying on "deeper" knowledge of how the
object will be used.

I decided to make a tkinter front-end for a Python program. I decided
to go with tkinter because it is included with many Python
installations, so it maximizes the chance for my program to run out of
the box.

The tkinter documentation on the Python site mainly consists of loose
notes and links to other sites. The documentation on other sites is
great, if you already know how to use tkinter. I ran into bugs in
TkAqua which make the grid layout unusable for me. So I will need to
ask potential users to install Xcode, X11, and mac ports, if they want
to run my program.

Take a look at the python.org Wiki for links to other resources on
Tkinter:

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

Or consider other graphical frameworks:

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

In short, there is plenty of room for improvement. Admittedly these are
not problems with the language definition. But I downloaded a Python
distribution, and the problems are Python specific.

My opinions, already expressed, include the observation that the core
development community is more interested in extending the language
than in strengthening the standard library (and its documentation). It
should be noted that the proposed standard library reorganisation,
which is a very conservative affair, has actually been postponed until
after the release of Python 3.0a1 according to a message I read
recently. And yet, if you read people's lists about what they "hate"
about Python (amongst actual users of Python), guess which thing
almost always comes up?

http://www.google.com/search?q="things+I+hate+about+Python"

Paul

 

[kyosohma]

I'm sorry to hear about that. If by "macho" you mean people who insist
that things are good enough as they are, and that newcomers should
themselves adapt to whatever they may discover, instead of things
being improved so that they are more intuitive and reliable for
newcomers and experienced developers alike, then I'd certainly be
interested in undermining that culture.


Really Dive Into Python should be a sufficient guide, and it was
perhaps the best introduction to the language when it was written. It
is very unfortunate that the language has changed in a number of ways
(and exhibits continued change) whilst effort into documenting what is
already there remains neglected amongst the people making all the
changes.


Can you provide the bug identifier? Bug reports are generally welcome,
and despite complaints about patch reviews, I've found people
reviewing things I've submitted.


Yes, Ctrl-Z exits Python in the standard Windows edition. Since Cygwin
provides a POSIX-like environment, Ctrl-D should be used instead. If
the documentation is wrong, a bug report or patch should be filed
against the software.


I really don't know what to say about the PyXML/xmlcore situation. I
don't use ElementTree and hardly use PyXML or minidom, but something
really should have been done about the maintenance of the established
libraries rather than declaring them as legacy items and pretending
that they don't exist.


Try using isinstance or relying on "deeper" knowledge of how the
object will be used.



Take a look at the python.org Wiki for links to other resources on
Tkinter:

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

Or consider other graphical frameworks:

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


My opinions, already expressed, include the observation that the core
development community is more interested in extending the language
than in strengthening the standard library (and its documentation). It
should be noted that the proposed standard library reorganisation,
which is a very conservative affair, has actually been postponed until
after the release of Python 3.0a1 according to a message I read
recently. And yet, if you read people's lists about what they "hate"
about Python (amongst actual users of Python), guess which thing
almost always comes up?

http://www.google.com/search?q="things+I+hate+about+Python"

Paul

I agree with Paul and Ben. The Docs need some help. Some are excellent
and others are hosed because of changes to the language. I started
with Tkinter, but quickly got frustrated with the lack of
documentation or screwy out-dated docs. What really annoys me is that
some very good authors state that Tkinter has excellent docs and
multiple published books. I found one book by Grayson that is 7 years
old. So I switched to wxPython.

wxPython has a better user group and better docs. Unfortunately, they
also have quite a few man pages, as do other external modules and man
pages typically make my eyes swim.

The closest thing to real docs by a real person for Python is Lundh's
site: http://effbot.org/librarybook/

Fortunately, since Python is so easy, some of this can be overcome.

Mike

 

[John Nagle]

I rewrote my code in Python and I found myself running into many of the
same hassles that I run into with other languages: inaccurate and
incomplete documentation, a maze of little platform-specific quirks to
work around in the base classes, and a macho community of users.

That's about typical. I've had much the same experiences, but
with a completely different set of external packages. I was doing
a web application in Linux; this user was doing a desktop
app on Windows. Yet he's reporting much the same kinds of quality
problems I noticed.

In general, the libraries outside of the core are not well
maintained. The user communities are small and bug reports can
take years to resolve.

I tried to write portable Python code. The zlib CRC function returned
different results on architectures between 32 bit and 64 bit
architectures. I filed a bug report. It was closed, without a comment
from the person who closed it. I get the unspoken message: bug reports
are not welcome.

That's the problem with bug reporting systems which let developers
close bugs arbitrarily. Defect reporting systems should have a status
for "developer in denial".

Bug handling in loosely managed projects tends to follow the
same path as the "stages of grief": denial, anger, bargaining,
depression, and acceptance. Getting through the process requires
a year or so.

There's an integration problem with the CPython implementation.
The mechanism for supporting extensions in other languages does not
have a tightly defined API which remains constant across versions.
Thus, C extensions are tied to a specific version of CPython compiled
with a specific compiler. There's no effort by the core Python
development group to keep third-party extensions in sync with the core,
so whenever a new core version comes out, many third party extensions
are unusuable with it for some months. The integration problem is
dumped on the third party extension developers. Most of the items
the user here is complaining about fall into that category.

In short, there is plenty of room for improvement. Admittedly these are
not problems with the language definition. But I downloaded a Python
distribution, and the problems are Python specific.

That's the usual observation. The language is in good shape, but
the libraries are not. Python is better than Perl, but CPAN is better
than Cheese Shop.

John Nagle

 

[John Salerno]

Fortunately, Python has incorporated some newbie-unfriendly features,
like metaclasses and, to a lesser extent, decorators which, at last,
make use of a special character. There should be more of these, to
make Python something more challenging to learn.

After reading the entire post about Python's ease of use, I find this
particular paragraph especially pointed.

I guess all the previous points about Python's features helps to show
how these other things (decorators, etc.) really stand out as perhaps
being un-Pythonic? At least, to me, it was an interesting way to make
that argument.

 

[Terry Reedy]

|I rewrote my code in Python and I found myself running into many of the
| same hassles that I run into with other languages: inaccurate and
| incomplete documentation, a maze of little platform-specific quirks to
| work around in the base classes, and a macho community of users.

Including you.

| I tried to write portable Python code. The zlib CRC function returned
| different results on architectures between 32 bit and 64 bit
| architectures. I filed a bug report. It was closed, without a comment
| from the person who closed it.

Misleading and untrue. Here is the link you omitted
http://sourceforge.net/tracker/index.php?func=detail&aid=1678102&group_id=5470&atid=105470

www.python.org/sf/1678102

Three days after you posted, 'gagenellina' explained that he thought your
complaint was invalid.
"py> -531560245 & 0xffffffff
3763407051L

It's the same number (actually, the same bit pattern). ..."

A few weeks later, noticing that you had not challenged his explanation, I
closed after changing the Resolution box to Invalid. THAT WAS MY COMMENT.

A month later, I notice that you still have not directly challenged G's
claim of invalidity. Instead, you ignored it and simply repeated your
claim here. WHO IS IGNORING WHO?

| I get the unspoken message: bug reports are not welcome.

Giving the shortage of reviewer time, invalid bug reports on tracker are a
nuisance and a diversion from attending to valid reports and reviewing
patches. That is why I encourage people to post here for community review.

Real bug reports are quite welcome, as any honest person could determine by
looking thru the tracker.

Terry Jan Reedy

 

[Terry Reedy]

| Ben Collver wrote:
|| > from the person who closed it. I get the unspoken message: bug
reports
| > are not welcome.
|
| That's the problem with bug reporting systems which let developers
| close bugs arbitrarily.

I think you should have looked at the actual tracker item, the evidence,
before responding, instead of relying on a misleading claim. The item was
closed as invalid three week after an explantion was given with no response
from the OP. The link is in my response.

| Defect reporting systems should have a status for "developer in denial".

The willingness of bystanders like you to trash volunteers with random
hobby horses is one reason there are fewer volunteers than needed.

| Bug handling in loosely managed projects tends to follow the
| same path as the "stages of grief": denial, anger, bargaining,
| depression, and acceptance.

Blah, blah. Not as profound as you seem to think.

| Getting through the process requires a year or so.

Ben got a respond in 3 days.

Terry Jan Reedy

 

[Thorsten Kampe]

* Paul Boddie (3 May 2007 07:27:11 -0700)

Yes, Ctrl-Z exits Python in the standard Windows edition. Since Cygwin
provides a POSIX-like environment, Ctrl-D should be used instead. If
the documentation is wrong, a bug report or patch should be filed
against the software.

He was using /Windows/ Python in Cygwin *chuckle*... Windows Python
says Ctrl-Z because it doesn't know that it's been run from bash where
Ctrl-Z is for job control.

And the lesson we learn from that: if you're using Windows Python use
a Windows shell. If you're using a Cygwin shell use Cygwin Python -
unless you know what you're doing (which he wasn't).


Thorsten

 

[John Nagle]

| Ben Collver wrote:
|| > from the person who closed it. I get the unspoken message: bug
reports
| > are not welcome.

| Getting through the process requires a year or so.

Ben got a respond in 3 days.

He didn't actually need anything fixed.

John Nagle

 

[Gabriel Genellina]

I tried to write portable Python code. The zlib CRC function returned
different results on architectures between 32 bit and 64 bit
architectures. I filed a bug report. It was closed, without a comment
from the person who closed it. I get the unspoken message: bug reports
are not welcome.

You got a comment from me, that you never disputed nor commented further.
I would have changed the status to "invalid" myself, if I were able to do
so.

I installed Cygwin on a Windows machine. I try to quit from an
interactive Python session. It tells me that on my platform, I must
press Control-Z to exit. I press Control-Z and it makes Python a
background process.

Maybe because you were running Windows Python from inside a bash prompt?
The Cygwin version tells you to use the right key combination to exit.

In short, there is plenty of room for improvement. Admittedly these are
not problems with the language definition. But I downloaded a Python
distribution, and the problems are Python specific.

Yes, some documentation is a bit outdated as Python is evolving
continuously. I prefer that, to a frozen language.

 

[Leo Kislov]

You got a comment from me, that you never disputed nor commented further.
I would have changed the status to "invalid" myself, if I were able to do
so.

I think it should have been marked as "won't fix" as it's a wart just
like
1/2 == 0, but as there are many users of the current behaviour it's
"impossible"
to fix it in Python 2.x. Maybe in Python 3.0?

-- Leo

 

[Nick Craig-Wood]

He was using /Windows/ Python in Cygwin *chuckle*... Windows Python
says Ctrl-Z because it doesn't know that it's been run from bash where
Ctrl-Z is for job control.

And the lesson we learn from that: if you're using Windows Python use
a Windows shell. If you're using a Cygwin shell use Cygwin Python -
unless you know what you're doing (which he wasn't).

I've noticed in the past that using cygwin python under a cygwin shell
is broken in some subtle ways when building extensions. Using the
windows python build in a windows command windows always works though
(with mingw as the compiler).