[issue33277] Deprecate __loader__, __package__, __file__, and __cached__ on modules

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33277] Deprecate __loader__, __package__, __file__, and __cached__ on modules

Brett Cannon added the comment: > Maybe this can be revisited now. I've started the work already (albeit rather slowly ). Importlib has been updated to prefer __spec__.parent of __package__ and warns when the values are not equal. Next step will be to raise an ImportWarning when __package__

[issue33277] Deprecate __loader__, __package__, __file__, and __cached__ on modules

Irit Katriel added the comment: > We didn't make it stronger since we can't get rid of any of these attributes > until Python 2.7 compatibility is no longer a concern. Maybe this can be revisited now. -- nosy: +iritkatriel versions: +Python 3.11 -Python 3.8

[issue33277] Deprecate __loader__, __package__, __file__, and __cached__ on modules

Brett Cannon added the comment: @Nick: We've had this discussion before about specs being a "receipt" of import versus not and the last time we agreed on not. :) That's why we raise a warning if __package__ doesn't match __spec__.parent:

[issue33277] Deprecate __loader__, __package__, __file__, and __cached__ on modules

Barry A. Warsaw added the comment: Not that I've thought this through in much detail, but what if we start out by proxying those module attributes to the spec via PEP 562 hooks? We can do that in 3.8, issue (silent?) deprecation warnings, and then do a full deprecation

[issue33277] Deprecate __loader__, __package__, __file__, and __cached__ on modules

Change by pmpp : -- nosy: +pmpp ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue33277] Deprecate __loader__, __package__, __file__, and __cached__ on modules

Antoine Pitrou added the comment: This sounds like gratuitous breakage to me. __file__ in particular is used quite often. -- nosy: +pitrou ___ Python tracker

[issue33277] Deprecate __loader__, __package__, __file__, and __cached__ on modules

Nick Coghlan added the comment: As a concrete proposal for 3.8, how about: 1. Add the following utility functions to importlib.util (names adjusted to match PEP 451 rather than my initial suggestions above): def get_location(module): try: return

[issue33277] Deprecate __loader__, __package__, __file__, and __cached__ on modules

Raymond Hettinger added the comment: +1 from me. The visual clutter in dir() has proven to be somewhat distracting in introduction-to-python courses. -- nosy: +rhettinger ___ Python tracker

[issue33277] Deprecate __loader__, __package__, __file__, and __cached__ on modules

Nick Coghlan added the comment: -1 from me for __package__, as setting that's the preferred way for directly executed scripts to fix their explicit relative imports (rather than trying to retroactively fix their spec). (https://docs.python.org/3/library/importlib.html

[issue33277] Deprecate __loader__, __package__, __file__, and __cached__ on modules

Barry A. Warsaw added the comment: I agree. It should also be pointed out that we've had inconsistencies between the module attributes and the spec attributes, and even fixing those has lead to problems. There should be a single source of truth, and the module spec should

[issue33277] Deprecate __loader__, __package__, __file__, and __cached__ on modules

Change by Brett Cannon : -- priority: normal -> low ___ Python tracker ___ ___

[issue33277] Deprecate __loader__, __package__, __file__, and __cached__ on modules

New submission from Brett Cannon : If you look at https://docs.python.org/3/reference/import.html#import-related-module-attributes you will notice there are a lot of attributes on modules. But since the introduction of module specs