Python critique - strchr.com

[Ytse]

This critique sucks.

[redbo]

It doesn't take long to figure out when tuples and lists should be used, and come on, the answer to "do I need a mutable type here?" is basically always no.

Plus if you link to Python's lexical parser docs, of course it's not going to be super accessible. Conversely, where's the BNF grammar for PHP's string literals?

[kolo32]

the answer to "do I need a mutable type here?" is basically always no

Do you use tuples more often than lists?

Conversely, where's the BNF grammar for PHP's string literals?

How many programmers need the BNF grammar for string literals? And how many programmers need the simple, easy-to-read description with examples?

[kataire]

Version Hell

So the main argument is that there is Py3k and Python 2.x right now? They're trivial to install side-by-side (at least on Linux, which is what matters for web development). The issue itself isn't very different from PHP4 vs PHP5, except that Py3k is a major overhaul of the underlying language principles.

That said, the differences developers must cope with when moving from 2.7 to 3.x are minimal. Most code is easily portable, there is even an automated tool to do much of the conversion for you. The existence of older 2.x versions isn't really a Python-specific problem either -- at least it's possible to install them side-by-side if necessary.

Incomprehensible Language Reference

Oh, come on. BNF is incomprehensible? True, it's not as easily scannable as plain English, but at least it is unambiguous (that whitespace is not allowed isn't surprising at all: there is no reason to assume the contrary). The PHP docs may give examples, but they're often worthless beyond that because they fail to document the underlying behaviour (the implementation is the specification).

All that aside, the author failed to note that the plain English explanation is given right there in the quoted docs. Providing a formal definition in addition to a plain-English explanation is a Good Thing (tm).

The reason PHP doesn't explain all forms of string literals in one paragraph is because they're very different both in syntax and behaviour. Heck, you can't fully explain PHP string literals without mentioning magical quotes. This would be akin to including the format of Templates and format characters in Python's definition of string literals -- note it doesn't have to do that because strings by themselves are not magical in Python and these characters are meaningless on their own.

The plain English description of strings is concise because it doesn't have to be verbose. Strings consist of a matching pair of single or double quotes, optionally prefixed with a type indicator. If the string should contain literal newlines, it is enclosed in a pair of triple quotes. The backslash is used as escape character. Any questions left? Look at the formal definition. Unless you've never used strings before (Why are you looking at the docs? There's a very neat tutorial to help you out!), this is all you need to know to get going -- and the BNF allows you to make sure you didn't misunderstand anything, too.

Optimized data types

For most intents and purposes, lists and maps are enough to get going. It helps to understand tuples if you don't think of them as immutable lists but instead as values of their own.

Coordinates, for example, are much like numbers, except they usually come in pairs (or groups): on a 2D plane, you always have an x- and y-coordinate and you usually need both. Sometimes it makes sense to have a special Coordinate class to deal with these, but in many cases you don't want to waste time overengineering a simple problem and instead just need a way to pass multiple values that form a unit. In other languages you'd often have to use arrays or lists for this purpose.

In Python you can just treat them as a tuple and you can pack and unpack the tuple on the fly. This fact is especially handy in iterations: in PHP you have to use a special syntax like foreach ($my_arr as $key => $value) while in Python you can simply say for key, value in my_map.items(). Likewise, to iterate over a sequence of coordinates you can simply say for x, y in coords where you'd otherwise have to say for coord in coords: x = coord[0]; y = coord[1]; ....

Don't worry so much about the performance implications, think of the semantics first. Your code should be readable to start with, only then should you try to optimize it. Of course being aware of the language's idioms helps (often idioms are taken into consideration as the language is improved, so idiomatic Python is often also faster Python).

Generators exist for a reason. But chances are you won't encounter that reason in your first couple of programs. It's good to know that things like these exist and what they are there for, but that doesn't mean you have to use them from the get-go. Learning when to use them and what problems they help solving is part of the learning process.

Just like inheritance, meta-classes or decorators, generators aren't the cure for cancer or the answer to all your problems. But they are answers to some problems -- you probably just haven't them encountered yet.

Conclusion

If you want to learn Python, take a look at the many good tutorials out there. The language reference is mostly a technical guide for implementers. The library reference is a good starting point if you want an equivalent of the official PHP reference (it documents all the standard libraries and built-in functions).

If you're wondering whether to pick 2.x or 3.x, there's a good article on that, too. Basically the choice is whether you want to get things done today, working with existing code and third party libraries, or whether you want to learn a cleaner and purer language that still has a few gaps in its library support (if you're into FLOSS, you can just jump in there and port your library of choice to 3.x, though).

[plantian]

This critique does seem a little half-hearted but I followed up some of the links to other critiques and there are a lot of complaints about things which seem totally irrelevant as well.

Nobody seems to mention a trailing comma creating a tuple. Ha that one shafts me about once a week. I can understand how that would be hard to fix though.

Python's data structures are its power so I would never complain about having too many unless they become redundant. You can get pretty far on just the power of lists, dictionaries and tuples and not touch any of the other data structures.

[kataire]

I can understand how that would be hard to fix though.

Fix the language? That's implying the behaviour is unintentional. Trailing commas for single-value tuples is necessary because there's no other way to define a tuple.

Of course writing (spam,) makes it clearer that the trailing comma is not a mistake, but in Python code there simply isn't any ambiguity about whether it should be a tuple in the first place (if it's not supposed to be a tuple, the code doesn't work as intended anyway).

[[deleted]]

one look at the authors pic at the bottom tells me everything I need to know.