It seems like we all agree that getting such a warning would be optimal. The
only real question is how we would make sure that it doesn’t slow down imports
more than it helps.
I’d gladly see your proposed option become a part of the language. With the
mentioned restrictions on when it actually
On Sat, Aug 22, 2020, at 20:17, Chris Angelico wrote:
> A speed drawback on every import would almost certainly be too high a
> price to pay.
My proposal would only add an extra check 1) on module load [not on import, so
you only pay it once per module, and not at all for built-in modules] 2) onl
On Sat, Aug 22, 2020 at 5:19 PM Chris Angelico wrote:
> On Sun, Aug 23, 2020 at 10:14 AM Gustav O wrote:
>
> >
>
> > I agree — having a warning would be fantastic! Personally, I think the
> minor speed drawback of
> A speed drawback on every import would almost certainly be too high a
>
> pr
Alright, thanks for the help. You’ll probably see an implementation in a new
thread here soon again. :)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman
On Sun, Aug 23, 2020 at 11:44 AM Gustav O wrote:
>
> Alright! I’ll sure take a look at that.
>
> I also think adding it to the core language would be greatly beneficial. Just
> like Christopher said, this is one of those "gotchas".
>
> I’m still new to this process, but do you think that writing
Alright! I’ll sure take a look at that.
I also think adding it to the core language would be greatly beneficial. Just
like Christopher said, this is one of those "gotchas".
I’m still new to this process, but do you think that writing a PEP for this
would be a reasonable next step?
_
On Sun, Aug 23, 2020 at 11:19 AM Gustav O wrote:
>
> In your answer, it sounds like the code would be written by the person
> developing a program. Or they could possibly have the importhook a separate
> module, which can be imported whenever you’d like to have it.
>
> Maybe I misunderstood you,
In your answer, it sounds like the code would be written by the person
developing a program. Or they could possibly have the importhook a separate
module, which can be imported whenever you’d like to have it.
Maybe I misunderstood you, but this wouldn’t really be optimal. I think most
people wo
On Sun, Aug 23, 2020 at 11:02 AM Gustav O wrote:
>
> It seems like most of us agree that the speed drawbacks wouldn’t be worth it
> — which I find understandable.
>
> If my understanding of excepthooks is correct, and that it’s the place to put
> code that should be executed once an AttributeErr
It seems like most of us agree that the speed drawbacks wouldn’t be worth it —
which I find understandable.
If my understanding of excepthooks is correct, and that it’s the place to put
code that should be executed once an AttributeError is raised, it sounds like a
great solution.
However, Att
On Sun, Aug 23, 2020 at 10:14 AM Gustav O wrote:
>
> I agree — having a warning would be fantastic! Personally, I think the minor
> speed drawback of checking the full path would be worth it, in most cases.
> The fact that a module is being shadowed is really valuable information to
> have.
>
I agree — having a warning would be fantastic! Personally, I think the minor
speed drawback of checking the full path would be worth it, in most cases. The
fact that a module is being shadowed is really valuable information to have.
If there’s enough of a demand for this, which I think there is,
On Sat, Aug 22, 2020 at 12:11 AM Random832 wrote:
> I think there are two possible paths here: either always print a warning
> [not an error] when importing a module from the current directory [the
> first entry in sys.path] that is also available in any other entry in
> sys.path,
This would be
Re: Improve error message for trying to import itself
I think you have some really valid points in your answer, Steven. To me, it
seems like we have two main options to improve the message for shadowing
modules. I copied part of your and Random832’s answer here, since they
summarize it quite nicel
I think you have some really valid points in your answer, Steven. To me, it
seems like we have two main options to improve the message for shadowing
modules. I copied part of your and Random832’s answer here, since they
summarize it quite nicely:
1. If a module attempts to directly import a mod
On Sat, Aug 22, 2020, at 03:09, Random832 wrote:
> > AttributeError: partially initialized module 'spam' has no attribute
> > 'egsg' (most likely due to a circular import)
> >
> > If the error wasn't due to shadowing or a circular import, then knowing
> > that I had misspelled 'eggs' would be ve
On Fri, Aug 21, 2020, at 21:52, Steven D'Aprano wrote:
> Having said all that, I cannot help but feel that shadowing of modules
> is such an issue that maybe we need to make a special case of this. Not
> specifically tkinter, of course, but if a module attempts to directly
> import a module with
On Fri, Aug 21, 2020 at 09:35:14AM -, Gustav O wrote:
> If a file named "tkinter.py" is created and tkinter is imported and used
> within the file, the following exception is raised:
> "AttributeError: partially initialized module 'tkinter' has no attribute 'Tk'
> (most likely due to a circu
On 22/08/20 6:43 am, Serhiy Storchaka wrote:
It would have non-zero cost. There is a common idiom:
try:
from foo import bar
except ImportError:
def bar(): ...
In this case you would need to try importing foo from other locations.
I wouldn't suggest going that far.
On Fri, Aug 21, 2020, at 15:13, Gustav O wrote:
> In the beginning of the programming journey, getting a message about
> circular imports when they were testing out tkinter in a file names
> "tkinter.py" would probably not be helpful. Getting a message that
> hints that you may have accidentally
I actually didn't know that there were use cases for importing itself — thanks
for letting me know.
The best way of implementing a better error message would probably be to change
the message for when the user import itself, while it's still partially
initialized.
In the beginning of the progr
21.08.20 18:22, Greg Ewing пише:
> Maybe check whether the module being imported from is shadowing another
> module further along the search path and warn about that?
It would have non-zero cost. There is a common idiom:
try:
from foo import bar
except ImportError:
def bar
21.08.20 12:35, Gustav O пише:
> If a file named "tkinter.py" is created and tkinter is imported and used
> within the file, the following exception is raised:
> "AttributeError: partially initialized module 'tkinter' has no attribute 'Tk'
> (most likely due to a circular import)"
>
> I've spoke
Great that you point that out. I have thought of are two possible solutions to
this:
1. Make the current error message clearer, but make sure that it's correct for
both cases
2. Create a special case for trying to import itself.
I personally think the second option would be superior. If necessar
Maybe check whether the module being imported from is shadowing another
module further along the search path and warn about that?
--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.
On Fri, Aug 21, 2020 at 11:40 PM Gustav O wrote:
>
> If a file named "tkinter.py" is created and tkinter is imported and used
> within the file, the following exception is raised:
> "AttributeError: partially initialized module 'tkinter' has no attribute 'Tk'
> (most likely due to a circular imp
26 matches
Mail list logo
