Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #103527
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Newsgroups | comp.lang.python |
| Subject | Re: "from module import data; print(data)" vs "import module; print(module.data)" |
| Date | 2016-02-26 15:37 +1100 |
| Message-ID | <mailman.141.1456461448.20994.python-list@python.org> (permalink) |
| References | <mailman.111.1456362461.20994.python-list@python.org> <535b56b5-f836-4cd6-ae95-33f18004c90b@googlegroups.com> <dj9d10F4gciU1@mid.individual.net> <mailman.138.1456443525.20994.python-list@python.org> <56cf9f01$0$1620$c3e8da3$5496439d@news.astraweb.com> |
Steven D'Aprano <steve@pearwood.info> writes:
> On Fri, 26 Feb 2016 10:38 am, Ben Finney wrote:
>
> > Gregory Ewing <greg.ewing@canterbury.ac.nz> writes:
> >
> >> sohcahtoa82@gmail.com wrote:
> >> > Now, I've noticed people talking about importing os.path. Is there any
> >> > reason to use "import os.path" rather than "import os"? Both of them
> >> > will still put the "os" module into the global namespace.
> >>
> >> In the case of os.path it doesn't matter, because the
> >> os module imports the appropriate path module automatically.
> >
> > My position is that behaviour violates one of the principles of the Zen
> > of Python: “Special cases aren't special enough to break the rules.”
>
> But it's not special. It's the standard behaviour of any module which offers
> a public name
That is the special behaviour. ‘os’ is a package that has a sub-module
‘path’. Normally, to get at a module inside a package, you import it
with a qualified name::
import os.path
The special case is that ‘os’ also wants the ‘path’ module itself, and
so the name happens to be available as a module attribute. That's a
special case that can not be depended on for other cases.
> `import os` makes all the names in the os name space available.
Since ‘os.path’ is a sub-module of the ‘os’ package, it should not also
be exported from the ‘os’ module attributes. The special case is confusing.
> There's no difference between (say) `os.listdir` and `os.path` except
> that listdir happens to be a function and path happens to be a module.
There's no difference between ‘logging.info’ and ‘logging.config’ except
that ‘info’ happens to be a function and ‘config’ happens to be a
module.
The difference is salient::
>>> import logging
>>> logging.info
<function info at 0x7fa7935bfa60>
>>> logging.config
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: module 'logging' has no attribute 'config'
That's the case normally, when one name is primarily an attribute and
another name is primarily a sub-module. The ‘os.path’ case is not
special enough to break that rule IMO.
> `path` has been a documented public attribute of the `os` module since at
> least Python 1.5:
Then it's been violating that principle for that long :-)
> If you take "Special cases are not special enough" seriously, you will
> not use `import os.path` since os is not a package
The implementation is special. That doesn't exempt it from the principle
that a special case isn't special enough to break expectations.
> and os.path is not part of os, it's just a publicly exposed attribute
> which merely happens to be a module.
You seem to be making my case for me: ‘os’ is indeed special. It goes to
some legth to hide that specialness; I think it doesn't go far enough.
--
\ “If you don't want your beliefs to be ridiculed, don't have |
`\ such ridiculous beliefs.” —Greta Christina, 2011-10-22 |
_o__) |
Ben Finney
Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread
"from module import data; print(data)" vs "import module; print(module.data)" Dan Stromberg <drsalists@gmail.com> - 2016-02-24 17:07 -0800
Re: "from module import data; print(data)" vs "import module; print(module.data)" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-02-25 14:39 +1100
Re: "from module import data; print(data)" vs "import module; print(module.data)" Dan Stromberg <drsalists@gmail.com> - 2016-02-25 08:15 -0800
Re: "from module import data; print(data)" vs "import module; print(module.data)" Dan Stromberg <drsalists@gmail.com> - 2016-02-25 08:20 -0800
Re: "from module import data; print(data)" vs "import module; print(module.data)" Ethan Furman <ethan@stoneleaf.us> - 2016-02-25 08:35 -0800
Re: "from module import data; print(data)" vs "import module; print(module.data)" Ethan Furman <ethan@stoneleaf.us> - 2016-02-25 08:51 -0800
Re: "from module import data; print(data)" vs "import module; print(module.data)" sohcahtoa82@gmail.com - 2016-02-25 12:00 -0800
Re: "from module import data; print(data)" vs "import module; print(module.data)" Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-02-26 11:20 +1300
Re: "from module import data; print(data)" vs "import module; print(module.data)" Ben Finney <ben+python@benfinney.id.au> - 2016-02-26 10:38 +1100
Re: "from module import data; print(data)" vs "import module; print(module.data)" Steven D'Aprano <steve@pearwood.info> - 2016-02-26 11:40 +1100
Re: "from module import data; print(data)" vs "import module; print(module.data)" Ian Kelly <ian.g.kelly@gmail.com> - 2016-02-25 20:56 -0700
Re: "from module import data; print(data)" vs "import module; print(module.data)" Chris Angelico <rosuav@gmail.com> - 2016-02-26 15:11 +1100
Re: "from module import data; print(data)" vs "import module; print(module.data)" Ben Finney <ben+python@benfinney.id.au> - 2016-02-26 15:37 +1100
csiph-web