On 02/27/2015 04:21 PM, Travis Griggs wrote:
On Feb 25, 2015, at 12:45 PM, Mark Lawrence <breamore...@yahoo.co.uk> wrote:
http://www.slideshare.net/pydanny/python-worst-practices
Any that should be added to this list? Any that be removed as not that bad?
I read ‘em. I thought they were pretty good, some more than others. And I
learned some things. I especially liked the first one, since I’ve struggled
with that one a bunch. In the context of “hey, accept Python for what it is”, I
agree greatly with it. Memorize the builtins, and stay the heck away from them.
I’ve been burned many times because I stored some bytes in a binding call, er,
uh, ‘bytes’. And having mentored some people learning Python in the early
stages, any explanation other than “Thou Shalt Never Use These Holy Words” just
confuses people.
That said…
If I were giving a talk at SPLASH (or some other suitable polyglot conference),
I might do one called “Language Design Worst Practices”.
One of my first slides might be titled:
Abuse Common Tokens in Confusing Ways
* Make your language have a lot of keywords. Enough to make memorizing them ALL
unlikely, requiring constant visits to your documentation
* Make sure said keywords are many of the obvious words programmers would use
in their applications (map, object, bytes, dir, etc)
* Design your syntax so that you can’t disambiguate them contextually between
bind and reference
* Be sure to use it in a late bound language where no warnings will be provided
about the mistake you’re making at authorship time, deferring the educational
experience to sundry run times
In my examples column of this bad practice, I’d put Python of course. :)
I do like Python, and I accept it for what it is, so no one needs to jump
forward as a Holy Python See to convert me to the truth. I also know that with
most other languages, that first slide wouldn’t need to be one of the prominent
“worst practices” slide.
Right. In C and C++, instead of being the first slide, it'd be the
first 3 or 4. Between header file conflicts (especially good because
the stdlib itself has many multiply-defined symbols, duplicate header
files, and contradictory include path patterns), implib conflicts, and
DLL load conflicts, not to mention the notorious win32 directory, which
is magically renamed out from under you in 64bit code. (That one is a
Windows thing; I wouldn't expect that Linux got caught in that trap)
I don't know how much of this has changed in recent years, but I suspect
it's gotten much worse, not better.
In Python, the error is noticed much later, but it can actually be
debugged without tearing out one's hair. Things like
print(mymodule.__file__)
to figure out where the mymodule is defined.
--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list
