Python Worst Practices

[Dave Angel]

On 02/27/2015 04:21 PM, Travis Griggs wrote:
>
>> On Feb 25, 2015, at 12:45 PM, Mark Lawrence <breamoreboy at 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