Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Anti-Patterns in Python Programming

lignos.org

Post reply on HN
Print view View original

211–220 of 242 posts

Re: Anti-Patterns in Python Programming

#211

Post by hueving »

jules wrote: post #91
sophacles wrote: post #90

The only thing I disagree with is "use nested comprehensions" thing. In my mind: x = [letter for word in words for letter in word] is inside-out or backwards or backwards. I want the nested for being the less specific case: x = [letter for letter in word for word in words] makes more sense in my mind. (It's also my first answer to the "what're some warts in the your language of choice).

Even clearer: x = [for word in words: for letter in word: letter] This also has the advantage of being readable left to right without encountering any unbound identifiers like all other constructs in Python.

As someone who spends a significant amount of time in python that is much harder to follow. There is an expectation for order in list comprehensions and what you wrote completely violates it.

Re: Anti-Patterns in Python Programming

#212

Post by PeterGriffin »

dlitz wrote: post #181
PeterGriffin wrote: post #71

Earlier quoted context omitted.

http://en.wikipedia.org/wiki/No_true_Scotsman Don't ask what's "more Pythonic" or "less Pythonic", Python is not a cult, it's a very practical scripting language. Ask for benefits and weaknesses of a given approach in given circumstances.

Speaking a language in the same way as other speakers of that language makes you easier to understand.

When it comes to basic formatting, symbol naming and high-level code organization, sure.

But computer languages, unlike human languages, are precise. Their intent is clear. And you'll never encounter a case where the Python 3 interpreter hasn't heard of that particular Python 3 keyword you're using.

It's also not an excuse to avoid certain features of a language, when using them leads to a better and simpler solution, just because they're less popular. Programming is not an exercise in popularity.

On the other hand, human language is fuzzy and full of phrases that consist of statements having nothing to do with their meaning. Such as me saying "your argument doesn't hold water".

Human languages also have additional layers entirely separate from the primary meaning of a conversation, such as sending social cues like "how smart am I", "do I like you", "do I fit in this group", and "am I a leader or a follower". Each layer of concern drives a certain way of expression and imitation, none of which occurs (or should occur) when writing computer code.

A better example to compare to programming code would be mathematical notation. As long as you express your intent shortly, using the available mathematical notation, people will be fine, and your intent will be clear.

I've never seen someone ask in a math forum if their formula is more Mathematic one way, or another way.

Re: Anti-Patterns in Python Programming

#213

Post by ghshephard »

jules wrote: post #150
jevgeni wrote: post #138

Earlier quoted context omitted.

Everybody, listen to this person!

Then it turns into this: x = [] for word in words: for letter in word: x.append(letter) Which in addition to being far more verbose and less readable, is also less efficient.

It's much more readable, people won't make mistakes on it the way they do when trying to be too clever with their multiple-for statements in list-comprehensions.

Trying to pack too much on a single line is one of the sins of perl, and I'm happy to read python code that is comfortable being multi-line.

Re: Anti-Patterns in Python Programming

#216

Post by dragonwriter »

jl6 wrote: post #199
dragonwriter wrote: post #167

Earlier quoted context omitted.

> Python allows these because "why not?" No, it allows them because the distinction that those restrictions are founded on is only useful in a statically-typed languages, and Python isn't statically typed. > For instance, should a Vector be a list or a tuple? A real vector/array should be its own data type (probably implemented in a C, or similar low-level, extension) that happens to implement the interface expected…

So why does Python distinguish between a list and a tuple at all?

Because the distinction between a mutable list and an immutable list is still meaningful in a dynamic language like python.

Re: Anti-Patterns in Python Programming

#217

Post by dragonwriter »

dozzie wrote: post #203
dragonwriter wrote: post #167

Earlier quoted context omitted.

> Python allows these because "why not?" No, it allows them because the distinction that those restrictions are founded on is only useful in a statically-typed languages, and Python isn't statically typed. > For instance, should a Vector be a list or a tuple? A real vector/array should be its own data type (probably implemented in a C, or similar low-level, extension) that happens to implement the interface expected…

> [this] distinction [...] is only useful in a statically-typed languages ...like Erlang.

Yeah, while snarkily made its a good point that Erlang does make use of it without being statically typed.

There is a deep difference that goes beyond use of tuples in language approach between Python and Erlang here where it comes to types in which Erlang, while dynamically typed, has a deep concern for types in its pattern matching system to make path decisions while Python is very much centered on using dynamic OO techniques -- how objects respond to messages -- to do that.

So I'd still say its the same kind of deep language approach difference at work.

Re: Anti-Patterns in Python Programming

#218

Post by ollysb »

zo1 wrote: post #141
kyllo wrote: post #139

Earlier quoted context omitted.

The confusion is that people assume the expression is evaluated every time the method is called. Because that's how it works in a lot of other languages, such as Ruby and Javascript.

I doubt that's the only reason. I fell for it myself at first without ever seeing a line of Ruby. It initially feels intuitive, and that's why I think most fall for it.

I think it's because the arguments are bound when the function is called. It's just natural that you'd expect the default values to also be bound at the same time.

Re: Anti-Patterns in Python Programming

#219

Post by ollysb »

hueving wrote: post #208
lilsunnybee wrote: post #153

Earlier quoted context omitted.

Yeah i really don't understand why this is just assumed to be a common 'gotcha' to be recognized and avoided by every competent python programmer. What exactly does the python spec specify as the desired behavior here? If you have this 'broken stair' that everyone should just know to step over, shouldn't somebody actually fix the stair!? I know python is not unique in having warts like this, but it's pretty b.s. in g…

It's not broken when you understand that functions are objects and default parameters are just members of those objects. Each time the function is executed you get local vars that point to these object members. If one is a mutable type, any changes you make to it will then obviously persist.

It leaves me wondering, are the parameters also scoped to the class(seeing as they're declared at the same time)? Wouldn't this cause an issue with concurrent access to the function?

Re: Anti-Patterns in Python Programming

#220

Post by ollysb »

dalke wrote: post #69
jcampbell1 wrote: post #48

Earlier quoted context omitted.

Can you clarify? def foo(default_arg = []): Why can't that just be shorthand for: def foo(default_arg = ParamNone): if default_arg == ParamNone: default_arg = [] How would that break first class functions?

As a minor point, use "default_arg is ParamNone", since "==" probably won't do the right thing. What breaks is something like: def foo(default_arg = slow_f()): pass Under the shorthand gets turned into: ParamNone = object() def foo(default_arg = ParamNone): if default_arg is ParamNone: default_arg = slow_f() pass This is fine, since everyone would know that the shorthand means to not put slow code there. Instead, peo…

Why not just memoize the result of the slow function?
Post reply on HN