On 1/9/2017 11:48 AM, Guido van Rossum wrote:
I would focus on changing habits to discourage "import *" rather than
The tkinter doc still has
...to use Tkinter all you need is a simple import statement:
import tkinter
Or, more often:
from tkinter import *
Should this be changed?
uglifyi
Easily solved with the totally evil ninja mode pattern of module
initialization. It has yet to catch on.
def ninja():
global exported
import os
def exported():
# do something
ninja()
del ninja
On Mon, Jan 9, 2017 at 1:13 PM Sven R. Kunze wrote:
> Interesting to see that othe
Interesting to see that others have the same problem.
We also had this kind of "over-protective" behavior. As far as I know,
our devs stopped doing it as it feels cumbersome.
Another argument for this is: when using PyCharm, this IDE will suggest
imports from those modules which aren't the o
On Jan 09, 2017, at 06:23 PM, André Malo wrote:
>- __all__ again: it's tedious and error-prone to maintain.
Only if you use the wrong tools
http://public.readthedocs.io/en/latest/
http://bugs.python.org/issue26632
Cheers,
-Barry
___
Python-Dev mailin
* Steve Holden wrote:
> One of my developers recently submitted a pull request incuding a number
> of lines like
>
> import os as _os
>
> When I asked him why he suggested a) this would improve encapsulation,
> and b) the practice was supported in the stdlib. Further investigation
> reveals that s
On 1/9/2017 6:42 AM, Steve Holden wrote:
One of my developers recently submitted a pull request incuding a number
of lines like
import os as _os
When I asked him why he suggested a) this would improve encapsulation,
and b) the practice was supported in the stdlib. Further investigation
reveals
I would focus on changing habits to discourage "import *" rather than
uglifying all new code with this "os as _os" pattern. Very occasionally one
designs a module to explicitly support "import *", and that usually entails
using __all__ (like it or not), making the problem go away without
uglifying
On 01/09/2017 03:42 AM, Steve Holden wrote:
When I asked him why he suggested
a) this would improve encapsulation, and
b) the practice was supported in the stdlib.
Further investigation reveals that some modules (e.g. argparse, crypt,
difflib, random) do use this technique, but it is far fro
On 9 January 2017 at 11:42, Steve Holden wrote:
> One of my developers recently submitted a pull request incuding a number of
> lines like
>
> import os as _os
>
> When I asked him why he suggested a) this would improve encapsulation, and
> b) the practice was supported in the stdlib. Further inve
One of my developers recently submitted a pull request incuding a number of
lines like
import os as _os
When I asked him why he suggested a) this would improve encapsulation, and
b) the practice was supported in the stdlib. Further investigation reveals
that some modules (e.g. argparse, crypt, di
On Jan 09, 2017, at 11:42 AM, Steve Holden wrote:
>So I thought it would be useful to get input from current devs about the
>value of this practice, since to me it seems somewhat anti-pythonic. What
>advantages does it confer?
It just means you can't accidentally import it with a from-import-* si
11 matches
Mail list logo
