How To Let People Know You're A Bad Python Programmer
artificialcode.blogspot.com
How To Let People Know You're A Bad Python Programmer
1–10 of 40 posts
Re: How To Let People Know You're A Bad Python Programmer
#2Funny, you could replace "Python" with "Java" and it would still make sense. I guess idiots will be idiots regardless of the language.
Re: How To Let People Know You're A Bad Python Programmer
#3The one issue I have is with the PEP 8 camel case reference. I can see the value of everyone keeping the same style while coding, but at the same time who says that style is the best? In terms of "expecting" that style when using other's libraries, you still have to read the docs for library to understand how to use it, so I don't see the ultimate value.
Re: How To Let People Know You're A Bad Python Programmer
#4The one issue I have is with the PEP 8 camel case reference. I can see the value of everyone keeping the same style while coding, but at the same time who says that style is the best? In terms of "expecting" that style when using other's libraries, you still have to read the docs for library to understand how to use it, so I don't see the ultimate value.
From PEP 8:
But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment.Re: How To Let People Know You're A Bad Python Programmer
#5Make up excuses like, "I am used to other people testing my code" (This one sounds especially good if your a former .NET developer.)
Why single out .NET? Am I missing something?
Re: How To Let People Know You're A Bad Python Programmer
#6The one issue I have is with the PEP 8 camel case reference. I can see the value of everyone keeping the same style while coding, but at the same time who says that style is the best? In terms of "expecting" that style when using other's libraries, you still have to read the docs for library to understand how to use it, so I don't see the ultimate value.
I disagree, as a rubyist I find it really useful that everyone uses underscores.
Language-wide style conventions make it easier to remember methods and classes since remembering a method like each_with_index as a phrase is easy, attaching a piece of useless data unrelated to what it does like Camel Case vs underscore is harder.
Re: How To Let People Know You're A Bad Python Programmer
#7The one issue I have is with the PEP 8 camel case reference. I can see the value of everyone keeping the same style while coding, but at the same time who says that style is the best? In terms of "expecting" that style when using other's libraries, you still have to read the docs for library to understand how to use it, so I don't see the ultimate value.
Settling on language-wide naming conventions reduces cognitive dissonance. Naming conventions don't supplant reading library docs, but they support it. In any case, you have to pick something, and some people will always be dissatisfied.
The answer to any "who says" question about Python is "Guido van Rossum says". (In the case of PEP 8, Barry Warsaw says as well.)
Re: How To Let People Know You're A Bad Python Programmer
#8> Add comments in the doc string or anywhere, that say, this is "magic", or "bad" and needs to be rewritten.
These are XXX comments and they're pretty common even with the best developers. They're so common that pretty much every editor has a syntax highlighting regex to detect them.
Re: How To Let People Know You're A Bad Python Programmer
#9Make up excuses like, "I am used to other people testing my code" (This one sounds especially good if your a former .NET developer.) Why single out .NET? Am I missing something?
[deleted]
Re: How To Let People Know You're A Bad Python Programmer
#10> Add comments in the doc string or anywhere, that say, this is "magic", or "bad" and needs to be rewritten. These are XXX comments and they're pretty common even with the best developers. They're so common that pretty much every editor has a syntax highlighting regex to detect them.
I'd go further - it's a good thing to do. It allows you to cruise through and get your main algorithm going, and then focus on details when you can afford for your brain to be doing that. I used to get distracted by this stuff and then forget about the big picture thing I was doing. Sometimes you can eve stub out lists of things with these as comments and then fill in the gaps as you're able to. Sometimes I review and realise the initial idea was too complicated and that I've saved energy.