8 ms·

I learned Python probably over 15 years ago. Haven't used it very much and certainly not followed all the news. I remember back then it was said the design phi

I learned Python probably over 15 years ago. Haven't used it very much and certainly not followed all the news. I remember back then it was said the design philosphy was something like there should be one obvious way to code something correctly. In opposite to Perl where the philosohpy was that human thoughts can take weird ways and you should be able to put your thoughts to code directly. (Both characterizations from memory.) Today I hear little from Perl. And with new syntax added to Python in every version I start to wonder how far away Python is drifting away from that original characterization above.

planckscnst 4y ago
I don't ever think Python has lived up to that tenet. If they did, then there wouldn't be a million pull requests with comments saying something to the effect of "the pythonic way to do this is..." or "pipXYZ says you should/shouldn't..."
Aloha 4y ago
At some point those two philosophies cross over, that's where you end up with bash or even php, there are several right ways, and several wrong ways, and all of them work.
noobermin 4y ago
One way was never going to work, ever. No real substantive platform of any kind will ever have one way to do something. May be if you're a literalist, there can sometimes be an "obvious way" to do something with emphasis on "obvious," but beyond that, the moment you have more than one library in the ecosystem that does a similar thing, you no longer can do something "one way." I'm not sure if today that really matters though. I will admit I don't know much about Perl but Perl's death vs Python's life probably might have some influence from design choices but a lot of it just has to do with the libraries you have access to with Python. I know as a scientist, Python is the game in town, that has more to do with why I use it than design.
- xenophonf 4y ago
  Perl's popularity waned because of the whole Perl 6 fiasco, which stole lots of energy from Perl 5, offered no migration path from Perl 5, and eventually evolved into a completely different language. As a result, Perl 5 development stalled, and developers went elsewhere. I personally stopped writing new Perl code around 2005-2006 after learning Python 2 in 2003-2004 (when I was doing a lot of Zope/Plone hacking). I think Python 3 almost killed Python, too, and for the same reasons. The developers behind 2to3 saved the community, in my opinion, as did the folks who made the painful decision to publish a Python 2 end-of-life date sufficiently far enough into the future that people still using the old runtime had both a sense of urgency and plenty of time to complete their migrations. I finally made the leap to Python 3 around 2016. I'd like to claim that I jumped instead of being pushed, but the reality is that by then, people were developing new stuff I wanted badly on Python 3 exclusively.
  - eesmith 4y ago
    I think "six" proved more useful than 2to3. This made it easier to support both Python 2 and Python 3 in the same code base, which (IMO) resulted in a smoother migration path.
    - xenophonf 4y ago
      You're absolutely right, and again, I think that reinforces how important a good migration path was to Python 3. Without that path, I think there was a real risk of Python dying off same as Perl 5. It's sad because there was a lot I liked about Perl. I wish that community had better leadership because from my quick glance at the Wikipedia page, it looks like the Perl 7 project is making the same mistakes as Perl 6/Raku did. It's really too bad.
  - at_a_remove 4y ago
    Perl's popularity was already in a nosedive by that point. I was programming in Perl much prior, was on numerous mailing lists, etc. The dropoff was startling. Frankly, I believe the terrible state of affairs on CPAN was part of the problem, but it was initiated by the "there's more than one way to do it" mentality. If I wanted to do something where it would be a good idea to have a library for that task, I would have to search many candidates, each of which did sixty to eighty percent of whatever, then see which were long-abandoned, did what they actually managed to write match what I needed, etc.
deleted 4y ago
[deleted]
js2 4y ago
>>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
- isoprophlex 4y ago
  >>> import numpy.polynomial.polynomial.Polynomial as P NaMeSpAcES ArE ONe HONkInG gReAt IdEa https://i.redd.it/jsh0ut0mtm391.jpg https://i.redd.it/jsh0ut0mtm391.jpg
  - eloisius 4y ago
    Namespaces are great but Python’s module system being coupled to file system structure kinda sucks. You either have overly-granular modules with manageable files, or you end up with multi-thousand line files that present a reasonable module organization. Or the totally unreasonable granular module structure for reasonable files with a facade set of modules that just reexport things.
    - plq 4y ago
      You can split your big module into modules inside a sub-package and import stuff in the __init__.py file from the submodules to present a nice interface to the library user. eg instead of: namespace.py class C1: class C2: do namespace/__init__.py from .c1 import C1 from .c2 import C2 namespace/c1.py class C1: namespace/c2.py class C2:
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?
tqlz 4y ago
Development is no longer about the language or elegance. It is about the old boys and their subordinates getting and maintaining positions at large corporations. Which requires politics, churn, adding non-essential features and covering up mistakes by the old boys.

planckscnst 4y ago

I don't ever think Python has lived up to that tenet. If they did, then there wouldn't be a million pull requests with comments saying something to the effect of "the pythonic way to do this is..." or "pipXYZ says you should/shouldn't..."

Aloha 4y ago

At some point those two philosophies cross over, that's where you end up with bash or even php, there are several right ways, and several wrong ways, and all of them work.

noobermin 4y ago

One way was never going to work, ever. No real substantive platform of any kind will ever have one way to do something. May be if you're a literalist, there can sometimes be an "obvious way" to do something with emphasis on "obvious," but beyond that, the moment you have more than one library in the ecosystem that does a similar thing, you no longer can do something "one way." I'm not sure if today that really matters though. I will admit I don't know much about Perl but Perl's death vs Python's life probably might have some influence from design choices but a lot of it just has to do with the libraries you have access to with Python. I know as a scientist, Python is the game in town, that has more to do with why I use it than design.

xenophonf 4y ago
Perl's popularity waned because of the whole Perl 6 fiasco, which stole lots of energy from Perl 5, offered no migration path from Perl 5, and eventually evolved into a completely different language. As a result, Perl 5 development stalled, and developers went elsewhere. I personally stopped writing new Perl code around 2005-2006 after learning Python 2 in 2003-2004 (when I was doing a lot of Zope/Plone hacking). I think Python 3 almost killed Python, too, and for the same reasons. The developers behind 2to3 saved the community, in my opinion, as did the folks who made the painful decision to publish a Python 2 end-of-life date sufficiently far enough into the future that people still using the old runtime had both a sense of urgency and plenty of time to complete their migrations. I finally made the leap to Python 3 around 2016. I'd like to claim that I jumped instead of being pushed, but the reality is that by then, people were developing new stuff I wanted badly on Python 3 exclusively.
- eesmith 4y ago
  I think "six" proved more useful than 2to3. This made it easier to support both Python 2 and Python 3 in the same code base, which (IMO) resulted in a smoother migration path.
  - xenophonf 4y ago
    You're absolutely right, and again, I think that reinforces how important a good migration path was to Python 3. Without that path, I think there was a real risk of Python dying off same as Perl 5. It's sad because there was a lot I liked about Perl. I wish that community had better leadership because from my quick glance at the Wikipedia page, it looks like the Perl 7 project is making the same mistakes as Perl 6/Raku did. It's really too bad.
- at_a_remove 4y ago
  Perl's popularity was already in a nosedive by that point. I was programming in Perl much prior, was on numerous mailing lists, etc. The dropoff was startling. Frankly, I believe the terrible state of affairs on CPAN was part of the problem, but it was initiated by the "there's more than one way to do it" mentality. If I wanted to do something where it would be a good idea to have a library for that task, I would have to search many candidates, each of which did sixty to eighty percent of whatever, then see which were long-abandoned, did what they actually managed to write match what I needed, etc.

deleted 4y ago

[deleted]

js2 4y ago

>>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!

isoprophlex 4y ago
>>> import numpy.polynomial.polynomial.Polynomial as P NaMeSpAcES ArE ONe HONkInG gReAt IdEa https://i.redd.it/jsh0ut0mtm391.jpg https://i.redd.it/jsh0ut0mtm391.jpg
- eloisius 4y ago
  Namespaces are great but Python’s module system being coupled to file system structure kinda sucks. You either have overly-granular modules with manageable files, or you end up with multi-thousand line files that present a reasonable module organization. Or the totally unreasonable granular module structure for reasonable files with a facade set of modules that just reexport things.
  - plq 4y ago
    You can split your big module into modules inside a sub-package and import stuff in the __init__.py file from the submodules to present a nice interface to the library user. eg instead of: namespace.py class C1: class C2: do namespace/__init__.py from .c1 import C1 from .c2 import C2 namespace/c1.py class C1: namespace/c2.py class C2:

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?

tqlz 4y ago

Development is no longer about the language or elegance. It is about the old boys and their subordinates getting and maintaining positions at large corporations. Which requires politics, churn, adding non-essential features and covering up mistakes by the old boys.