Other Software > Developer's Corner

Python Language Annoyances

(1/7) > >>

mouser:
[EDIT: This discussion was originally on this thread]

first let me just say this, python uses implicit variable declaration (ie you dont have to declare a variable before it is used, you just use it).

to me, this is the single worst most harmful idea in the history of programming languages, and it completely baffles me that it can be found in a modern and popular language.  that single issue is reason enough that no one should be using this language.

this is actually a little related to why the issue of significant indentation is such a bad idea -- because it makes it so easy to introduce bugs that are nearly invisible to the naked eye (using a tab instead of a space, mispelling a variable name, etc.)

the syntax is a personal thing, but just feels wrong to me.. having to declare object functions with "self" as the first parameter (even though when you invoke it you dont pass that.  this optional class documentation string stuff, by just specifying a string after the def line.. it just feels kludgey and dirty.

kartal:
mouser,

Please check out these articles if you have time. These are quite old but I think that they explain where Python is really practical and easy to use

http://www.ibm.com/developerworks/library/l-pycon.html
http://www.ibm.com/developerworks/linux/library/l-prog.html

tinjaw:
Just very brief comments, since I know you will investigate deeper if you care to (and have the time).

It boils down to static typing versus dynamic typing; and the workflow that goes along with that.

And most Python programmers do TDD, so bugs are found via testing and there is no need to compile so you just run and debuging realtime based on stacktraces (which are integraded into the python tools that are worthwhile using).

tinjaw:
Oh, and regardless of what tools you use, use IPython. Yes, it is that good. I always have an IPython window open regardless of what platform I am on or tool I am using. Think of it as a fulltime realtime debugger with built in macros.

f0dder:
First: this is about Python, not IDEs - I suggest a moderator separate this post, and the posts below, to a new thread:Spoilerhttps://www.donationcoder.com/forum/index.php?topic=15491.msg192725#msg192725
https://www.donationcoder.com/forum/index.php?topic=15491.msg192753#msg192753
https://www.donationcoder.com/forum/index.php?topic=15491.msg192859#msg192859

It boils down to static typing versus dynamic typing; and the workflow that goes along with that.-tinjaw (January 24, 2010, 02:37 PM)
--- End quote ---
No, it doesn't :) - you can do dynamic typing even if you have to predeclare variables (just declare them as "var" rather than a specific type). Even though I generally prefer static typing (catching bugs at compile-time = :-*), I do accept that dynamic typing can be useful (especially while prototyping stuff  - nice not having to bother with endless type conversions)... but not requiring variables to be predefined is a big mistake, IMHO.

And I also agree with mouser that it's also a big mistake depending on indentation for program structure... there's just too many ways this can screw you over, and it's not like it's a big hurdle to {enclose structural blocks}. These two things are items I find problematic (and downright stupid) in the core Python language.

Also, as mouser, I think the "__self__" for Python OOP looks kludgy, nasty and superfluous. This is more of an aesthetic issue though, and not something that bothers me majorly. Most importantly, it's not dangerous as the above two points.

Final gripe is probably the standard library, which feels... messy. Some stuff tries to look like POSIX C which is OK for a lot of stuff, while other parts look like WIN32 emulations. Of course one shouldn't re-invent the wheel all the time, but it would be nice with a somewhat more coherent standard library. There's also the issue of not everything being available everywhere, leading to perhaps having to do platform-specific code (probably less of a problem now than when I last bumped into it - and I can't remember the specifics anyway).

There's also been a fair amount of times where I've scratched my head pondering why a particular routine throws an exception instead of using a return code... IMHO exceptions should be for exceptional conditions, whereas return codes signal "failure" that can be "expected" (ie, a file-read that fails would be an exception, file-not-found would be return code) - but when to use exceptions (and when not to) is somewhat of a religious subject.

And most Python programmers do TDD, so bugs are found via testing and there is no need to compile so you just run and debuging realtime based on stacktraces (which are integraded into the python tools that are worthwhile using).-tinjaw (January 24, 2010, 02:37 PM)
--- End quote ---
Even with that, I'm still a firm believe in my first two points... doing those properly costs you almost nothing, and will very likely end up saving you a lot more in the end.

But in spite of all the above, I still do like Python, and find that it's a pretty nice tool for a lot of things, where you'd spend too much time in C++ focusing on auxillary stuff rather than getting your job done.

Navigation

[0] Message Index

[#] Next page