4 ms·

Actually Perl's characterization was that the easy things should be easy, and the hard things possible. Sometimes Python could learn from that. Oh you want to

by tus666 4y ago

Actually Perl's characterization was that the easy things should be easy, and the hard things possible. Sometimes Python could learn from that. Oh you want to print to stderr hmm?

8organicbits 4y ago
I don't think I follow the stderr comment. Isn't it just: Perl print STDERR "foo" Python print(file=sys.stderr, "foo") Those look fairly similar. I prefer that print() is obviously a function call and file is a named parameter so the purpose is clear.
- tus666 4y ago
  Well in Perl there is... warn("foo") In Python you have to at least: - remember not to forget to import sys - remember the file= syntax for the print statement - type about 10 extra characters Bunch of annoying stuff when you are hurriedly debugging something...
- tyingq 4y ago
  The file=sys.stderr came with Python 3. Because of that, I tend to see sys.stderr.write("foo\n") more often.
  - jerdfelt 4y ago
    Python 2 was even more terse with it's print statement print >>sys.stderr, "foo"
marcosdumay 4y ago
Or, on the first Python3 releases, do you want to output binary data at all?
bvrmn 4y ago
What's wrong with printing to stderr in python?
- eesmith 4y ago
  Agreed! In fact, I think this makes it so all print() calls by default write to stderr: >>> import sys, functools, builtins >>> real_print = print >>> builtins.print = functools.partial(real_print, file=sys.stderr) >>> print("Hello") Hello
  - abdusco 4y ago
    Or use logging module as you should, which prints to stderr by default. import logging logging.basicConfig() logging.info('something happened')
    - prirun 4y ago
      The problem for me with logging is that it's slow for production code: Python 2.7.15 Linux (logging is 60x slower): [root@hbtest ~]# py -m timeit -s 'import logging' "logging.info('something happened')" 1000000 loops, best of 3: 1.31 usec per loop [root@hbtest ~]# py -m timeit -s 'import sys; debug = False' "if debug: print >>sys.stderr, 'something happened'" 10000000 loops, best of 3: 0.0216 usec per loop Python 2.7.15 OSX (logging is 71x slower): $ py -m timeit -s 'import logging' "logging.info('something happened')" 1000000 loops, best of 3: 0.925 usec per loop [jim@mbp hbrel]$ py -m timeit -s 'import sys; debug = False' "if debug: print >>sys.stderr, 'something happened'" 100000000 loops, best of 3: 0.013 usec per loop Python 3.6.8 Linux (logging is 99x slower): [root@hbtest ~]# python3 -m timeit -s 'import logging' "logging.info('something happened')" 1000000 loops, best of 3: 1.62 usec per loop [root@hbtest ~]# python3 -m timeit -s 'import sys; debug = False' "if debug: print >>sys.stderr, 'something happened'" 100000000 loops, best of 3: 0.0163 usec per loop And, as usual, Python 3 is 25% slower than Python 2 for the logging case (but 2x faster for the noop if debug case). I hope the recent efforts to increase Python 3 performance are successful.
      - mixmastamyk 4y ago
        Microseconds are not important unless in a very tight loop. Avoid there and/or make a shortcut beforehand.
adrianmonk 4y ago
Perl also has the motto "there's more than one way to do it". https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...
- omoikane 4y ago
  This is also the motto I learned. This would explain Python's motto of "There Is Only One Way to Do It". (It's a joke due from this page: http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m..., actual motto is "there should be one -- and preferably only one -- obvious way to do it")
dspillett 4y ago
My main memory of perl (I used it for CGI and local CLI tooling back in the day) was that it was usually very terse, to the point of being a write-only language. I learned an important lesson with it: the more clever you feel writing code, the more you are likely to hate maintaining it after a few months away!
- xyzzy123 4y ago
  There was a long time period (IMHO good few years in early 2000s) where Python looked better on paper but Perl was still better for production. All the Perl libraries for doing certain things (db access, web stuff, process management) were "actually battle tested" and worked well even if they were utterly unreadable. Python looked a lot nicer but when you tried to do any real work with it everything seemed to leak memory or give you continuous paper cuts - and it was a lot slower. I made the switch to Python eventually but it took a while.
  - dspillett 4y ago
    > (IMHO good few years in early 2000s) That tallies with when I was using Perl (late 90s / early 00s). Python was very much on the up in that time but I didn't feel compelled to switch, then DayJob and personal projects took me away from such thing completely (DayJob was Windows/VB6/IIS/ASP based, home web stuff went PHP for a while and admin stuff to Bash).
DemocracyFTW2 4y ago
Some things that should be easy are ridiculously hard in Python. Regexes for one have a horrible API story. Another one is the import system which I view as a totally broken effort to heal self-inflicted complexity with more complexity. Here is the code I came up when presented with the task to import a module when its name is given: def module_from_path( ctx, name, path ): ### thx to https://stackoverflow.com/a/50395128/7568091 ### ### thx to https://stackoverflow.com/a/67692/7568091 ### import importlib import importlib.util spec = importlib.util.spec_from_file_location( name, path ) module = importlib.util.module_from_spec( spec ) sys.modules[ spec.name ] = module spec.loader.exec_module( module ) return importlib.import_module( name ) Details may change any time without notice. The complexity here is a consequence of Python's design decision to treat module names as identifiers, not as quoted strings. The import system is full of such poor choices (dot/relative imports, `__init__.py`, `*.pyc` / `*.pyo` files littering one's source directories, and so on)
- tails4e 4y ago
  Agree on regex. I started in perl many years ago and loved how integrated regexes were. Was appalled that was was a simple one liner in perl turned into multiple lines in python for every regex. Making a powerful tool easy to use means it will be used more. It would be nice if that flaw could be fixed, as I like coding in python in general
  - deleted 4y ago
    [deleted]
  - eesmith 4y ago
    Here' an ancient hack that showed how that might look like - http://dalkescientific.com/Python/python4ply-tutorial.html#matching http://dalkescientific.com/Python/python4ply-tutorial.html#m... . count = 0 t1 = time.time() for line in open("nucleosome.pdb"): if line =~ m/(ATOM |HETATM)/: count += 1 print count, "atoms in", time.time()-t1, "seconds" It used it own PLY-based parser to generate the Python AST. None of it would work now. :)

by tus666 4y ago

Actually Perl's characterization was that the easy things should be easy, and the hard things possible. Sometimes Python could learn from that. Oh you want to print to stderr hmm?

8organicbits 4y ago

I don't think I follow the stderr comment. Isn't it just: Perl print STDERR "foo" Python print(file=sys.stderr, "foo") Those look fairly similar. I prefer that print() is obviously a function call and file is a named parameter so the purpose is clear.

tus666 4y ago
Well in Perl there is... warn("foo") In Python you have to at least: - remember not to forget to import sys - remember the file= syntax for the print statement - type about 10 extra characters Bunch of annoying stuff when you are hurriedly debugging something...
tyingq 4y ago
The file=sys.stderr came with Python 3. Because of that, I tend to see sys.stderr.write("foo\n") more often.
- jerdfelt 4y ago
  Python 2 was even more terse with it's print statement print >>sys.stderr, "foo"

marcosdumay 4y ago

Or, on the first Python3 releases, do you want to output binary data at all?

bvrmn 4y ago

What's wrong with printing to stderr in python?

eesmith 4y ago
Agreed! In fact, I think this makes it so all print() calls by default write to stderr: >>> import sys, functools, builtins >>> real_print = print >>> builtins.print = functools.partial(real_print, file=sys.stderr) >>> print("Hello") Hello
- abdusco 4y ago
  Or use logging module as you should, which prints to stderr by default. import logging logging.basicConfig() logging.info('something happened')
  - prirun 4y ago
    The problem for me with logging is that it's slow for production code: Python 2.7.15 Linux (logging is 60x slower): [root@hbtest ~]# py -m timeit -s 'import logging' "logging.info('something happened')" 1000000 loops, best of 3: 1.31 usec per loop [root@hbtest ~]# py -m timeit -s 'import sys; debug = False' "if debug: print >>sys.stderr, 'something happened'" 10000000 loops, best of 3: 0.0216 usec per loop Python 2.7.15 OSX (logging is 71x slower): $ py -m timeit -s 'import logging' "logging.info('something happened')" 1000000 loops, best of 3: 0.925 usec per loop [jim@mbp hbrel]$ py -m timeit -s 'import sys; debug = False' "if debug: print >>sys.stderr, 'something happened'" 100000000 loops, best of 3: 0.013 usec per loop Python 3.6.8 Linux (logging is 99x slower): [root@hbtest ~]# python3 -m timeit -s 'import logging' "logging.info('something happened')" 1000000 loops, best of 3: 1.62 usec per loop [root@hbtest ~]# python3 -m timeit -s 'import sys; debug = False' "if debug: print >>sys.stderr, 'something happened'" 100000000 loops, best of 3: 0.0163 usec per loop And, as usual, Python 3 is 25% slower than Python 2 for the logging case (but 2x faster for the noop if debug case). I hope the recent efforts to increase Python 3 performance are successful.
    - mixmastamyk 4y ago
      Microseconds are not important unless in a very tight loop. Avoid there and/or make a shortcut beforehand.

adrianmonk 4y ago

Perl also has the motto "there's more than one way to do it". https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...

omoikane 4y ago
This is also the motto I learned. This would explain Python's motto of "There Is Only One Way to Do It". (It's a joke due from this page: http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m..., actual motto is "there should be one -- and preferably only one -- obvious way to do it")

dspillett 4y ago

My main memory of perl (I used it for CGI and local CLI tooling back in the day) was that it was usually very terse, to the point of being a write-only language. I learned an important lesson with it: the more clever you feel writing code, the more you are likely to hate maintaining it after a few months away!

xyzzy123 4y ago
There was a long time period (IMHO good few years in early 2000s) where Python looked better on paper but Perl was still better for production. All the Perl libraries for doing certain things (db access, web stuff, process management) were "actually battle tested" and worked well even if they were utterly unreadable. Python looked a lot nicer but when you tried to do any real work with it everything seemed to leak memory or give you continuous paper cuts - and it was a lot slower. I made the switch to Python eventually but it took a while.
- dspillett 4y ago
  > (IMHO good few years in early 2000s) That tallies with when I was using Perl (late 90s / early 00s). Python was very much on the up in that time but I didn't feel compelled to switch, then DayJob and personal projects took me away from such thing completely (DayJob was Windows/VB6/IIS/ASP based, home web stuff went PHP for a while and admin stuff to Bash).

DemocracyFTW2 4y ago

Some things that should be easy are ridiculously hard in Python. Regexes for one have a horrible API story. Another one is the import system which I view as a totally broken effort to heal self-inflicted complexity with more complexity. Here is the code I came up when presented with the task to import a module when its name is given: def module_from_path( ctx, name, path ): ### thx to https://stackoverflow.com/a/50395128/7568091 ### ### thx to https://stackoverflow.com/a/67692/7568091 ### import importlib import importlib.util spec = importlib.util.spec_from_file_location( name, path ) module = importlib.util.module_from_spec( spec ) sys.modules[ spec.name ] = module spec.loader.exec_module( module ) return importlib.import_module( name ) Details may change any time without notice. The complexity here is a consequence of Python's design decision to treat module names as identifiers, not as quoted strings. The import system is full of such poor choices (dot/relative imports, `__init__.py`, `*.pyc` / `*.pyo` files littering one's source directories, and so on)

tails4e 4y ago
Agree on regex. I started in perl many years ago and loved how integrated regexes were. Was appalled that was was a simple one liner in perl turned into multiple lines in python for every regex. Making a powerful tool easy to use means it will be used more. It would be nice if that flaw could be fixed, as I like coding in python in general
- deleted 4y ago
  [deleted]
- eesmith 4y ago
  Here' an ancient hack that showed how that might look like - http://dalkescientific.com/Python/python4ply-tutorial.html#matching http://dalkescientific.com/Python/python4ply-tutorial.html#m... . count = 0 t1 = time.time() for line in open("nucleosome.pdb"): if line =~ m/(ATOM |HETATM)/: count += 1 print count, "atoms in", time.time()-t1, "seconds" It used it own PLY-based parser to generate the Python AST. None of it would work now. :)