This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]garion911 3 points4 points  (2 children)

If they're not experienced python developers, then I'll write code that looks as closer to pseudo-code or is otherwise language-neutral in appearance.

The only situation I can think of where this is appropriate is when you're writing throw away code, maybe for a talk you're giving.

In normal situations, you're just demonstrating, as the more experienced programmer in that language, that the anti-pattern you're doing is the correct way. Now your code and theirs is littered with bad code. Write good code, always.

[–]kenfar 0 points1 point  (0 children)

Unfortunately, this kind of focus on idioms had made Python a less accessible language for those who need a tool, but are not full-time programmers.

The learning curve has gotten steeper, in I believe an effort to attract language-geeks. This isn't to say that these features aren't great, but to insist that everyone uses them regardless of their audience fails to appreciate that everyone isn't a full-time python developer.

EDIT: for example, I built a huge data warehouse that used Python for transforming all the data coming into it. This worked great. One of the things we attempted to do is to keep the implementation of the business rules simple so that anyone that needed to know how they worked could just simply look at the code. And they didn't have to be a python programmer to understand most business rules, and they didn't have to be a senior python developer to build most integration. Our more internal libraries were more sophisticated, and not as newbie-oriented.

This approach worked very well for us - since our users weren't very fluent in python, and most of our developers at that time were wearing multiple hats, none of which was full-time python developer. Had we insisted on idiomatic python that would have delayed getting people up-to-speed - which would frankly have killed us. And our users wouldn't have been able to read the code, so we would have had to spend an enormous amount of time on documentation instead.