4 ms·

>>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex

by 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:
    - eloisius 4y ago
      That’s what I described as the facade module approach.
    - eesmith 4y ago
      What I don't like about this approach is how I'm supposed to refer to something by namespace.C1 but its repr is namespace.c1.C1. I would prefer if the repr reported its primary public API name, not its internal implementation location.
  - mikepurvis 4y ago
    What's wrong with facade modules? That seems to be a pretty common pattern, and it allows you to decouple your filesystem structure from module structure while still giving someone reading the source a breadcrumb to follow. Quite apart from implementation challenges (eg, needing to parse every file in package upfront to know what's in there), how else would you see this working? Are there other interpreted languages that manage this indirection in a more elegant way than having some central file that supplies the mapping information?
    - eloisius 4y ago
      There’s nothing wrong with it, per se, but it is more to maintain, and it’s a confusing indirection to downstream users that need to pry into your code to debug something. Ruby has its own problems, but I like that the modules are independent from the file that contains them. You can “reopen” a module and declare new classes or constants or whatever. You have freedom (and responsibility) to organize your files in a way that maps to module namespaces. The drawback is the `require “my_file”` doesn’t give you any hint about what you’re importing.
  - emidln 4y ago
    You can organize your packages however you want if you write and register a new module loader.
  - throwaway892238 4y ago
    The module system linked to file structure worked for Perl pretty well. Perl had this crazy idea that different authors should publish packages/modules with the same namespace, e.g. IO.pm <-- author: Larry Wall IO/File.pm <-- author: Me IO/Socket.pm <-- author: You IO/Socket/INET.pm <-- author: Larry Wall IO/Socket/INET/Daemon.pm <-- author: Me Simpler and encourages code reuse. Of course there is duplicate code in CPAN, but you really have to go out of your way to avoid an existing module that can do what you need.
- hoosieree 4y ago
  If you use a single namespace it becomes Monomial.
- mirekrusin 4y ago
  It violates rule 5 "Flat is better than nested".
  - eesmith 4y ago
    NumPy also imports all of its subpackages, allowing: >>> import numpy >>> P = numpy.polynomial.polynomial.Polynomial This results in a high startup cost if you just one one NumPy feature. I've always thought this ran counter to "Explicit is better than implicit". The NumPy developers think "practicality beats purity" is more important, and their main use-case is long-running programs where startup costs are slow, which I interpret as meaning their special cases is special enough to break the rules.
    - urthor 4y ago
      Isn't Numpy about making things go fast? People who expect things to go fast want it all cached up front, for very obvious reasons. Seems straightforward.
      - eesmith 4y ago
        "Go fast" has multiple dimensions. For one example, I had a command-line tool which needed to compute something related to hypergeometric distribution. (It's been a few years; I forget the details.) This available in scipy, which need numpy. Most of my program's run-time was spent importing numpy. (The following timings are best-of-3.) % time python -c pass 0.027u 0.011s 0:00.04 75.0% 0+0k 0+0io 0pf+0w % time python -c "import numpy" 0.212u 0.059s 0:00.17 152.9% 0+0k 0+0io 14pf+0w % time python -c "import scipy" 0.252u 0.077s 0:00.32 100.0% 0+0k 0+0io 14pf+0w While 0.2 seconds doesn't seem like much to people used to spending hours developing a notebook, or running some large matrix computation, I could make my program 8x faster by writing the dozen or so lines I needed to evaluate that function myself. Numpy is not about making short-lived programs fast. In any case, this specific choice of importing all submodules is not to cache things up "for obvious [performance] reasons", because there is no machine performance improvements. Instead, it's to make the API easier/faster to use. When you're in a notebook and you need numpy.foo.bar() you can just use it, and not have to go up and use an import statement first.
uranusjr 4y ago
Note that this describes a Zen state (as in the Western colloquial sense) and is supposed to be intentionally self-contradicting to provoke thoughts. It’s sometimes disappointing to see a lot of people follow it as rules or strong suggestions, which completely misses the point.
- bityard 4y ago
  It seems obvious that they are at least strong suggestions, what makes you think they are not?
  - jofer 4y ago
    It's a matter of how you interpret and use them. If you think about it as "strong suggestions", then yeah it seems obvious that they're suggestions for how to approach ambiguous situations. However, that's also missing the point a bit. It's often more useful to think about it as "thought exercises when trying to understand the design philosophy". Note that it deliberately contradicts itself. Similarly, things like "flat is better than nested" and "sparse is better than dense" are completely false a lot of the time. There are plenty of cases where the opposite is true for practical reasons like memory use or access patterns. The point is not necessarily to make those as statements or suggestions. The point is to give you something to think about. They're more like koans than suggestions. Think about why and where they're not true as much as why and where they are. And don't take it too seriously, either way! The whole thing of "import this" is tongue in cheek, after all.
Stormwalker 4y ago
Not so known fact: Zen of Python refers to internal CPython design, and not to external application of the language itself. So, any new syntax is fine while one can wrap their head around implementation.
- fulafel 4y ago
  No, it was prompted by a post to comp.lang.python asking for guidance for new Python users. There's a link to that post in the PEP references (https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/)
zlwerq 4y ago
This hasn't been true for a long time. These days it feels like mentioning the original founding principles of Animal Farm after it went totalitarian. It is from a different age, when intelligent people like Tim Peters still had influence and there was more of an academic atmosphere. These days it is about warming chairs, getting power, eliminating your enemies and speaking at conferences.

by js2 4y ago

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:
  - eloisius 4y ago
    That’s what I described as the facade module approach.
  - eesmith 4y ago
    What I don't like about this approach is how I'm supposed to refer to something by namespace.C1 but its repr is namespace.c1.C1. I would prefer if the repr reported its primary public API name, not its internal implementation location.
- mikepurvis 4y ago
  What's wrong with facade modules? That seems to be a pretty common pattern, and it allows you to decouple your filesystem structure from module structure while still giving someone reading the source a breadcrumb to follow. Quite apart from implementation challenges (eg, needing to parse every file in package upfront to know what's in there), how else would you see this working? Are there other interpreted languages that manage this indirection in a more elegant way than having some central file that supplies the mapping information?
  - eloisius 4y ago
    There’s nothing wrong with it, per se, but it is more to maintain, and it’s a confusing indirection to downstream users that need to pry into your code to debug something. Ruby has its own problems, but I like that the modules are independent from the file that contains them. You can “reopen” a module and declare new classes or constants or whatever. You have freedom (and responsibility) to organize your files in a way that maps to module namespaces. The drawback is the `require “my_file”` doesn’t give you any hint about what you’re importing.
- emidln 4y ago
  You can organize your packages however you want if you write and register a new module loader.
- throwaway892238 4y ago
  The module system linked to file structure worked for Perl pretty well. Perl had this crazy idea that different authors should publish packages/modules with the same namespace, e.g. IO.pm <-- author: Larry Wall IO/File.pm <-- author: Me IO/Socket.pm <-- author: You IO/Socket/INET.pm <-- author: Larry Wall IO/Socket/INET/Daemon.pm <-- author: Me Simpler and encourages code reuse. Of course there is duplicate code in CPAN, but you really have to go out of your way to avoid an existing module that can do what you need.
hoosieree 4y ago
If you use a single namespace it becomes Monomial.
mirekrusin 4y ago
It violates rule 5 "Flat is better than nested".
- eesmith 4y ago
  NumPy also imports all of its subpackages, allowing: >>> import numpy >>> P = numpy.polynomial.polynomial.Polynomial This results in a high startup cost if you just one one NumPy feature. I've always thought this ran counter to "Explicit is better than implicit". The NumPy developers think "practicality beats purity" is more important, and their main use-case is long-running programs where startup costs are slow, which I interpret as meaning their special cases is special enough to break the rules.
  - urthor 4y ago
    Isn't Numpy about making things go fast? People who expect things to go fast want it all cached up front, for very obvious reasons. Seems straightforward.
    - eesmith 4y ago
      "Go fast" has multiple dimensions. For one example, I had a command-line tool which needed to compute something related to hypergeometric distribution. (It's been a few years; I forget the details.) This available in scipy, which need numpy. Most of my program's run-time was spent importing numpy. (The following timings are best-of-3.) % time python -c pass 0.027u 0.011s 0:00.04 75.0% 0+0k 0+0io 0pf+0w % time python -c "import numpy" 0.212u 0.059s 0:00.17 152.9% 0+0k 0+0io 14pf+0w % time python -c "import scipy" 0.252u 0.077s 0:00.32 100.0% 0+0k 0+0io 14pf+0w While 0.2 seconds doesn't seem like much to people used to spending hours developing a notebook, or running some large matrix computation, I could make my program 8x faster by writing the dozen or so lines I needed to evaluate that function myself. Numpy is not about making short-lived programs fast. In any case, this specific choice of importing all submodules is not to cache things up "for obvious [performance] reasons", because there is no machine performance improvements. Instead, it's to make the API easier/faster to use. When you're in a notebook and you need numpy.foo.bar() you can just use it, and not have to go up and use an import statement first.

uranusjr 4y ago

Note that this describes a Zen state (as in the Western colloquial sense) and is supposed to be intentionally self-contradicting to provoke thoughts. It’s sometimes disappointing to see a lot of people follow it as rules or strong suggestions, which completely misses the point.

bityard 4y ago
It seems obvious that they are at least strong suggestions, what makes you think they are not?
- jofer 4y ago
  It's a matter of how you interpret and use them. If you think about it as "strong suggestions", then yeah it seems obvious that they're suggestions for how to approach ambiguous situations. However, that's also missing the point a bit. It's often more useful to think about it as "thought exercises when trying to understand the design philosophy". Note that it deliberately contradicts itself. Similarly, things like "flat is better than nested" and "sparse is better than dense" are completely false a lot of the time. There are plenty of cases where the opposite is true for practical reasons like memory use or access patterns. The point is not necessarily to make those as statements or suggestions. The point is to give you something to think about. They're more like koans than suggestions. Think about why and where they're not true as much as why and where they are. And don't take it too seriously, either way! The whole thing of "import this" is tongue in cheek, after all.

Stormwalker 4y ago

Not so known fact: Zen of Python refers to internal CPython design, and not to external application of the language itself. So, any new syntax is fine while one can wrap their head around implementation.

fulafel 4y ago
No, it was prompted by a post to comp.lang.python asking for guidance for new Python users. There's a link to that post in the PEP references (https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/)

zlwerq 4y ago

This hasn't been true for a long time. These days it feels like mentioning the original founding principles of Animal Farm after it went totalitarian. It is from a different age, when intelligent people like Tim Peters still had influence and there was more of an academic atmosphere. These days it is about warming chairs, getting power, eliminating your enemies and speaking at conferences.