Comment by ajross | Hacker News Reader

Comment by ajross | Hacker News Reader

Parent Full thread

My experience is almost exactly the opposite. Whenever I'm writing in Python I can't escape the feeling that the code is simply fragile due to missing language features. Obviously this starts with all the regex initializations (often quite distant in source from where they are applied) which make regular expressions in python just a huge mess.

Perl's autovification allows me to build a data structure at parse time with code that is trivially verifiable. Python forces me to sprinkle the code with a thousand tests for whether or not the field is initialized yet, or write extra code to define things like defaultdict instances (with syntax that I always have to look up, and which in my experience most python programmers don't understand).

Not to mention that if I want to use an OO syntax for that data structure I have to write extra code defining a class for it (and inevitably be yelled at by the pythonista security branch for all the __whatnot__ methods I forgot to define).

Python's comprehension/generator syntax is nice, though, and doesn't have a clean analog in perl. One thing it does do well is chaining up "filter" operations on aggregate data structures in a clean way. And that has value and is worth emulating. But honestly most of the rest of the language is junk compared to perl or ruby.

I agree with you about the feeling of fragility, especially with defaultdicts.

As for regexes - while they are somewhat clumsy in python, they don't have to be defined distantly:

  m = re.match(r'(\d{4})', buf)
  if m:
    print "year: %s" % m.group(1)

The only thing that really bothers me about the above is the need to separate the assignment of m from the test.

Re comprehensions: seems to me they are just Python's version of Perl's map and grep.

grep:

  @good = grep { $_->{width} > 9 } @crates;
  good = [c for c in crates if c['width'] > 9]

map:

  @squares = map { $_ * $_ } @nums;
  squares = [i*i for i in nums]

Which is better? I think Ruby's way is the best, and Perl/Python are a wash here.

Now, on the autovivification note, I wonder if we can make a Python class that has the desired behaviors. Like:

  c = PerlishStruct()
  c['foo'][17]['bar'] = 'baz'

You don't really think it's junk, do you? Perl, Python and Ruby are extremely similar; I'd say Perl's more ergonomic, but messier; Python's cleaner, but sometimes awkward, and Ruby pretty much has the best of both worlds.

You probably shouldn't do this in an inner loop: :-)

  m = re.match(r'(\d{4})', buf)

'map' is more general than just the single, convoluted statement of list comprehensions, which really seems as a kludge from unwillingness to accept multi-line lambdas. So something new was invented that had to be learned; then it was argued it is a boon. (Like references in Perl. :-) )

(There is some defaultdict functionality for autovivification in Python iirc.)

Yeah, they are all similar. I don't know enough Ruby to have an opinion.

For list comprehensions and a different style of generator, look at https://metacpan.org/module/List::Gen

And then there are a pile of modules that implement python-style generators, some using https://metacpan.org/module/Coro (co-routines implemented as threads), some using crazy hacks:

https://metacpan.org/module/Compile::Generators

https://metacpan.org/module/Coro::Generator

https://metacpan.org/module/Attribute::Generator

Yeah, honestly though those fail the "clean" test for me. What I really meant isn't the computational capabilities of python generators but the way the mesh nicely with the way builtins like "in" or "all()" or "any()" work on plain old data. Reasoning about them, in general, isn't any harder than reasoning about a dict or list in the common case, and that's a feature missing from the perl equivalents which try to do it in a library. I'd feel comfortable throwing a comprehension into code intended to be maintained by a novice. I'd never inflict any of that junk on the poor maintainer.

Reply on news.ycombinator.com