[issue42564] "from .__init__ import ..." syntax imports a duplicate module

[Gregory Szorc]

Gregory Szorc  added the comment:

Who uses this syntax? 
https://github.com/search?l=Python=%22from+.__init__+import%22=Code says 
a lot of random code, surprisingly/sadly.

As for python-ideas, thanks for the suggestion: I may very well craft an email!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42564] "from .__init__ import ..." syntax imports a duplicate module

[Brett Cannon]

Brett Cannon  added the comment:

You could propose your backwards-incompatible proposals on python-ideas, Greg, 
and see if you get any uptake.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42564] "from .__init__ import ..." syntax imports a duplicate module

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

What is the problem? What real code imports __init__?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42564] "from .__init__ import ..." syntax imports a duplicate module

[Gregory Szorc]

Gregory Szorc  added the comment:

I worked around this in PyOxidizer by stripping a trailing `.__init__` from 
module names when resolving the indexed resource data. This allows the import 
to work since it can find the data now, but it also preserves the double module 
object, which isn't ideal IMO.

My preferred solution would be to either ban `__init__` in module name 
components or strip trailing `.__init__` from the name in `find_spec()`, 
effectively normalizing it away. Either of these would be backwards 
incompatible. Could either of these be considered for 3.10?

It's worth noting that `__init__` could potentially occur in the interior of 
the module name. e.g. `foo.__init__.bar`. This would require filenames like 
`foo/__init__/bar.py`. I wouldn't be surprised if this exists somewhere in the 
wild.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42564] "from .__init__ import ..." syntax imports a duplicate module

[Brett Cannon]

Brett Cannon  added the comment:

I agree with Serhiy; don't do this. The only way we could fix this would be to 
always set a `__init__` module for every package implicitly, but then that 
would break anyone who wanted to clear out a package in sys.modules as the 
`__init__` reference in sys.modules becomes a dangling reference.

--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42564] "from .__init__ import ..." syntax imports a duplicate module

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Other example is:

>>> import sys
>>> import xml
>>> import xml.__init__
>>> sys.modules['xml']

>>> sys.modules['xml.__init__']

>>> sys.modules['xml'] is sys.modules['xml.__init__']
False

I'm not sure we should do anything about it other than say "Don't do this."

--
nosy: +brett.cannon, eric.snow, ncoghlan, serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42564] "from .__init__ import ..." syntax imports a duplicate module

[Gregory Szorc]

New submission from Gregory Szorc :

(Rereporting from https://github.com/indygreg/PyOxidizer/issues/317.)

$ mkdir foo
$ cat > foo/__init__.py < test = True
> EOF
$ cat > foo/bar.py < from .__init__ import test
> EOF
$ python3.9
Python 3.9.0 (default, Nov  1 2020, 22:40:00)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo.bar
>>> import sys
>>> sys.modules['foo']

>>> sys.modules['foo.__init__']


I am surprised that `from .__init__` even works, as `__init__` isn't a valid 
module name.

What appears to be happening is the path based importer doesn't recognize the 
`__init__` as special and it falls back to its regular file probing technique 
to locate a module derive from the path. It finds the `__init__.py[c]` file and 
imports it.

A consequence of this is that the explicit `__init__` import/module exists as a 
separate module object under `sys.modules`. So you can effectively have the 
same file imported as 2 module objects living under 2 names. This could of 
course result in subtle software bugs, like module-level variables not updating 
when you expect them to. (This could also be a feature for code relying on this 
behavior, of course.)

I only attempted to reproduce with 3.9. But this behavior has likely existed 
for years.

--
components: Interpreter Core
messages: 382464
nosy: indygreg
priority: normal
severity: normal
status: open
title: "from .__init__ import ..." syntax imports a duplicate module
type: behavior
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue42564>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: import syntax

[Chris Angelico]

On Mon, Jul 29, 2013 at 11:37 PM, Joshua Landau jos...@landau.ws wrote:
 2d) Realise that the slow part is not what you thought it was

This step is mandatory.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: import syntax

[Neil Cerutti]

On 2013-07-29, Joshua Landau jos...@landau.ws wrote:
 Sure, just as one light is no brighter or dimmer than another
 when disregarding luminosity.

 As people have said, it improves diffs as well. It flows
 quicker into the from module import things form (which I oft
 prefer), too.

 When asking these questions, ask yourself why would it
 *compile* differently? It wouldn't. Plus, premature
 optimisation is the root of all evil.

 1) Write your code
 2) If it's slow:
 2a) Do you have time? If so:
 2b) Is it important to speed up, or is the slowness not worth spending the
 hours fixing?
 2c) Profile it to see what's actually slow
 2d) Realise that the slow part is not what you thought it was
 2e) Fix the bit that's slow (and nothing else)
 2f) Repeat from 2
 3) Write some more code

1a) Does it work?
1b) Can you prove it?

It's best to at least have some regression tests before you start
refactoring and optimizing.

-- 
Neil Cerutti
-- 
http://mail.python.org/mailman/listinfo/python-list

import syntax

[Devyn Collier Johnson]

The PEP8 recommends importing like this:

import os
import re

not like this:

import os, re

Why is that? Is there a performance advantage to one of the styles?


Mahalo,

Devyn Collier Johnson
devyncjohn...@gmail.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: import syntax

[Joel Goldstick]

On Mon, Jul 29, 2013 at 3:48 PM, Devyn Collier Johnson
devyncjohn...@gmail.com wrote:
 The PEP8 recommends importing like this:

 import os
 import re

 not like this:

 import os, re

 Why is that? Is there a performance advantage to one of the styles?


 Mahalo,

 Devyn Collier Johnson
 devyncjohn...@gmail.com
 --
 http://mail.python.org/mailman/listinfo/python-list

I think its just for clarity

-- 
Joel Goldstick
http://joelgoldstick.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: import syntax

[Dave Angel]

On 07/29/2013 03:48 PM, Devyn Collier Johnson wrote:

The PEP8 recommends importing like this:

import os
import re

not like this:

import os, re

Why is that? Is there a performance advantage to one of the styles?




Pep 8 is not about performance, it's about readability.  And unless the 
two libraries are closely related, it's clearer to use separate lines 
for them.


I got a bit further, and if I'm only using a couple of functions from 
the import, I'll list them in the comment.


--
DaveA

--
http://mail.python.org/mailman/listinfo/python-list

Re: import syntax

[Tim Chase]

On 2013-07-29 15:48, Devyn Collier Johnson wrote:
 The PEP8 recommends importing like this:
 
 import os
 import re
 
 not like this:
 
 import os, re
 
 Why is that? Is there a performance advantage to one of the styles?

While I don't believe there's much of a performance difference (if
so, it should be pretty negligible, especially since imports are
usually just done at load-time rather than run-time), but

1) it's easier to read one-per-line (IMHO), particularly if you sort
them alphabetically

2) it makes for cleaner diffs

Which would you rather read and try to figure out what's going on?

  =
  --- before.py   2013-07-29 15:04:38.250996094 -0500
  +++ after.py2013-07-29 15:04:44.026996132 -0500
  @@ -1 +1 @@
  -import csv, re, sys, os
  +import csv, re, sys, glob, os
  =

vs.

  =
  --- before.py   2013-07-29 15:13:13.050997907 -0500
  +++ after.py2013-07-29 15:13:18.434997950 -0500
  @@ -1,4 +1,5 @@
   import csv
  +import glob
   import os
   import re
   import sys
  =

The latter makes it much easier (at least for me) to spot that glob
was added.  And it's more tolerant of merge-conflict resolution.

-tkc




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: import syntax

[Tim Chase]

On 2013-07-29 16:09, Dave Angel wrote:
 On 07/29/2013 03:48 PM, Devyn Collier Johnson wrote:
  The PEP8 recommends importing like this:
 
  import os
  import re
 
  not like this:
 
  import os, re

 I got a bit further, and if I'm only using a couple of functions
 from the import, I'll list them in the comment.

If I just plan to use a small subset, I tend to reach for the

  from sys import stdout, stderr, exit

sort of syntax.  I find it makes my code read a bit more cleanly than
having to type sys.stderr.write(...) everywhere but is still pretty
readable.

-tkc


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: import syntax

[Devyn Collier Johnson]

On 07/29/2013 04:20 PM, Tim Chase wrote:

On 2013-07-29 16:09, Dave Angel wrote:

On 07/29/2013 03:48 PM, Devyn Collier Johnson wrote:

The PEP8 recommends importing like this:

import os
import re

not like this:

import os, re

I got a bit further, and if I'm only using a couple of functions
from the import, I'll list them in the comment.

If I just plan to use a small subset, I tend to reach for the

   from sys import stdout, stderr, exit

sort of syntax.  I find it makes my code read a bit more cleanly than
having to type sys.stderr.write(...) everywhere but is still pretty
readable.

-tkc



So, there are no advantages or disadvantages when disregarding readability?

DCJ
--
http://mail.python.org/mailman/listinfo/python-list

Re: import syntax

[Joshua Landau]

On 29 July 2013 21:23, Devyn Collier Johnson devyncjohn...@gmail.comwrote:


 On 07/29/2013 04:20 PM, Tim Chase wrote:

 On 2013-07-29 16:09, Dave Angel wrote:

 On 07/29/2013 03:48 PM, Devyn Collier Johnson wrote:

 The PEP8 recommends importing like this:

 import os
 import re

 not like this:

 import os, re

 I got a bit further, and if I'm only using a couple of functions
 from the import, I'll list them in the comment.

 If I just plan to use a small subset, I tend to reach for the

from sys import stdout, stderr, exit

 sort of syntax.  I find it makes my code read a bit more cleanly than
 having to type sys.stderr.write(...) everywhere but is still pretty
 readable.

 -tkc


  So, there are no advantages or disadvantages when disregarding
 readability?


Sure, just as one light is no brighter or dimmer than another when
disregarding luminosity.

As people have said, it improves diffs as well. It flows quicker into the
from module import things form (which I oft prefer), too.

When asking these questions, ask yourself why would it *compile*
differently? It wouldn't. Plus, premature optimisation is the root of all
evil.

1) Write your code
2) If it's slow:
2a) Do you have time? If so:
2b) Is it important to speed up, or is the slowness not worth spending the
hours fixing?
2c) Profile it to see what's actually slow
2d) Realise that the slow part is not what you thought it was
2e) Fix the bit that's slow (and nothing else)
2f) Repeat from 2
3) Write some more code
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: import syntax

[Devyn Collier Johnson]

On 07/29/2013 06:37 PM, Joshua Landau wrote:
On 29 July 2013 21:23, Devyn Collier Johnson devyncjohn...@gmail.com 
mailto:devyncjohn...@gmail.com wrote:



On 07/29/2013 04:20 PM, Tim Chase wrote:

On 2013-07-29 16:09, Dave Angel wrote:

On 07/29/2013 03:48 PM, Devyn Collier Johnson wrote:

The PEP8 recommends importing like this:

import os
import re

not like this:

import os, re

I got a bit further, and if I'm only using a couple of
functions
from the import, I'll list them in the comment.

If I just plan to use a small subset, I tend to reach for the

   from sys import stdout, stderr, exit

sort of syntax.  I find it makes my code read a bit more
cleanly than
having to type sys.stderr.write(...) everywhere but is still
pretty
readable.

-tkc


So, there are no advantages or disadvantages when disregarding
readability?


Sure, just as one light is no brighter or dimmer than another when 
disregarding luminosity.


As people have said, it improves diffs as well. It flows quicker into 
the from module import things form (which I oft prefer), too.


When asking these questions, ask yourself why would it *compile* 
differently? It wouldn't. Plus, premature optimisation is the root of 
all evil.


1) Write your code
2) If it's slow:
2a) Do you have time? If so:
2b) Is it important to speed up, or is the slowness not worth spending 
the hours fixing?

2c) Profile it to see what's actually slow
2d) Realise that the slow part is not what you thought it was
2e) Fix the bit that's slow (and nothing else)
2f) Repeat from 2
3) Write some more code

Joshua, nice work-flow instructions.

Mahalo,

DCJ
-- 
http://mail.python.org/mailman/listinfo/python-list