3 ms·

The author makes the assertion that flat is better than nested, and indeed it's one of the rules in "import this", but I just don't see it. I spend about half

by tsuraan 17y ago

The author makes the assertion that flat is better than nested, and indeed it's one of the rules in "import this", but I just don't see it. I spend about half my time in python, and about half in erlang. Erlang makes python look pretty deeply nested, since it pretty much lacks support for any namespace nesting, but honestly, I prefer Java's namespaces. If I were to write a library in Java (god forbid), I'd start it in net.tsuraan.whatever. I'd know that I'm not going to have namespace clashes with the standard library, apache, nor anybody else that is half-way sane. In python, the root namespace is pretty crowded, and you need to step carefully to avoid namespace clashes. In erlang, it's even harder. Why do people like flat namespaces, as opposed to reasonably nested ones?

jnoller 17y ago
noooo, I wasn't making that assertion - I was saying the argument against my gripe about nesting bits of the stdlib deeper would be responded with "flat is better than nested". The "flat" crowd always whips that one out when someone suggests nesting it a bit more. I am a fan of nesting it just a little bit deeper than what it is today.
- tsuraan 17y ago
  It reads as though you generally do agree with the flat is better than nested though; your argument appears to be more against how the system is currently organized, rather than being concerned with the ability to write libraries without worrying much about namespace clashes. I'd love to see the entire python standard library moved into a root-level "python" namespace; I'm guessing that would be about as popular as curly braces with the general python crowd... Heck, even the ability to root your imports, like import .email would bring in the root-level email library, would be pretty nice. I'm sure I've seen the idea shot down before, but I can't recall what the reasoning was.
  - jnoller 17y ago
    Relative imports are in python, which allows you to dictate where a "foo" module is imported from
  - jnoller 17y ago
    I'll adjust the text to clarify my point
kaens 17y ago
I assume that language implementors "like" flat namespaces because they are easy to implement. Or easier. I've never looked into how such things are done, but it seems like flat namespaces are a much simpler problem in terms of implementation, at the cost of making users of the language be careful about name collisions. "Flat is better than nested" is a rule of thumb, not a maxim. I agree that the python standard library could use a bit more nesting, but I think that going to the same lengths as java wouldn't fit with python too well. I've never had to step carefully to avoid namespace clashes in python - I'm curious as to when and/or how you run into this problem. The only way I can think of that would make my code run into it a lot would be if I was doing a lot of "from foo import *", which generally isn't a good idea. "import foo", or "import foo as bar" serves the same purpose. It seems to me that having a nested namespace for the standard library, but not to the point that it's a tree, is roughly analogous to a lot of other design decisions in Python - for example, there not being any concept of private or protected variables, at least on the high level.
lsd5you 17y ago
I always thought it was to save on typing ... Remembering that a)python has shell scripting (and even interactive shell) as a design influence, and b)is often developed from within vim/emacs where mouse aversion is strong enough to influenc the convention for the language.

by tsuraan 17y ago

jnoller 17y ago

noooo, I wasn't making that assertion - I was saying the argument against my gripe about nesting bits of the stdlib deeper would be responded with "flat is better than nested". The "flat" crowd always whips that one out when someone suggests nesting it a bit more. I am a fan of nesting it just a little bit deeper than what it is today.

tsuraan 17y ago
It reads as though you generally do agree with the flat is better than nested though; your argument appears to be more against how the system is currently organized, rather than being concerned with the ability to write libraries without worrying much about namespace clashes. I'd love to see the entire python standard library moved into a root-level "python" namespace; I'm guessing that would be about as popular as curly braces with the general python crowd... Heck, even the ability to root your imports, like import .email would bring in the root-level email library, would be pretty nice. I'm sure I've seen the idea shot down before, but I can't recall what the reasoning was.
- jnoller 17y ago
  Relative imports are in python, which allows you to dictate where a "foo" module is imported from
- jnoller 17y ago
  I'll adjust the text to clarify my point

kaens 17y ago

I assume that language implementors "like" flat namespaces because they are easy to implement. Or easier. I've never looked into how such things are done, but it seems like flat namespaces are a much simpler problem in terms of implementation, at the cost of making users of the language be careful about name collisions. "Flat is better than nested" is a rule of thumb, not a maxim. I agree that the python standard library could use a bit more nesting, but I think that going to the same lengths as java wouldn't fit with python too well. I've never had to step carefully to avoid namespace clashes in python - I'm curious as to when and/or how you run into this problem. The only way I can think of that would make my code run into it a lot would be if I was doing a lot of "from foo import *", which generally isn't a good idea. "import foo", or "import foo as bar" serves the same purpose. It seems to me that having a nested namespace for the standard library, but not to the point that it's a tree, is roughly analogous to a lot of other design decisions in Python - for example, there not being any concept of private or protected variables, at least on the high level.

lsd5you 17y ago

I always thought it was to save on typing ... Remembering that a)python has shell scripting (and even interactive shell) as a design influence, and b)is often developed from within vim/emacs where mouse aversion is strong enough to influenc the convention for the language.