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/pyt...il/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?
---
André

[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]

André wrote:

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/pyt...il/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?
---
André

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]

In article <11************ **********@l77g 2000hsb.googleg roups.com>,
=?iso-8859-1?B?QW5kcuk=?= <an***********@ gmail.comwrote:

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

http://www.netfunny.com/rhf/jokes/98...troustrup.html
--
Aahz (aa**@pythoncra ft.com) <* 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]

James Stroud <js*****@mbi.uc la.eduwrote:

André wrote:

[snipping total repost of André's post]

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/pyt...il/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?
---
André

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.

[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._Tempo raryFileWrapper .

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]

On 3 Mai, 15:49, Ben Collver <coll...@peak.o rgwrote:

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

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=%22th...bout+Python%22

Paul