On Mon, Apr 16, 2018 at 10:23 AM, Brett Cannon wrote:
>
>
> On Mon, 16 Apr 2018 at 09:58 Eric Fahlgren wrote:
>
>> The documentation is pretty opaque or non-existent on other aspects of
>> importlib use, too.
>>
>
> Well, we are diving into the dark corners of import here. (Details can be
> foun
On Mon, 16 Apr 2018 at 09:58 Eric Fahlgren wrote:
> The documentation is pretty opaque or non-existent on other aspects of
> importlib use, too.
>
Well, we are diving into the dark corners of import here. (Details can be
found in the language reference:
https://docs.python.org/3/reference/import
The documentation is pretty opaque or non-existent on other aspects of
importlib use, too. If I enable warnings, I see this (and many more like
it). I've read PEP 302 a couple times, read the code in importlib that
detects the warning and searched down several rabbit holes, only to come up
empty.
On 16 April 2018 at 17:22, Nick Coghlan wrote:
> If we're not covering explicit __path__ manipulation anywhere, we
> should definitely mention that possibility.
> https://docs.python.org/3/library/pkgutil.html#pkgutil.extend_path
> does talk about it, but only in the context of scanning sys.path f
On 16 April 2018 at 03:45, Steve Barnes wrote:
> On 15/04/2018 08:12, Nick Coghlan wrote:
>> The discoverability of these kinds of techniques could definitely
>> stand to be improved, but the benefit of adopting them is that they
>> work on all currently supported versions of Python (even
>> impor
On 15/04/2018 08:12, Nick Coghlan wrote:
> On 14 April 2018 at 19:22, Steve Barnes wrote:
>> I generally love the current import system for "just working" regardless
>> of platform, installation details, etc., but what I would like to see is
>> a clear import local, (as opposed to import from wh
On 15 April 2018 at 17:12, Nick Coghlan wrote:
> If you want to do this dynamically relative to the current module,
> then it's possible to do:
>
> global __path__
> __path__[:] = (some_directory, some_other_directory)
> custom_mod = importlib.import_module(".name", package=__name__)
On 14 April 2018 at 19:22, Steve Barnes wrote:
> I generally love the current import system for "just working" regardless
> of platform, installation details, etc., but what I would like to see is
> a clear import local, (as opposed to import from wherever you can find
> something to satisfy mecha
On 4/13/2018 11:28 PM, Ken Hilton wrote:
Hi all,
First of all, please excuse me if I'm presenting this idea in the wrong
way or at the wrong time - I'm new to this mailing list and haven't seen
anyone propose a new idea on it yet, so I don't know the customs.
I have an idea for importing fil
On 14/04/2018 06:27, Nick Coghlan wrote:
> On 14 April 2018 at 13:28, Ken Hilton wrote:
>> Hi all,
>>
>> First of all, please excuse me if I'm presenting this idea in the wrong way
>> or at the wrong time - I'm new to this mailing list and haven't seen anyone
>> propose a new idea on it yet, so
On 14 April 2018 at 13:28, Ken Hilton wrote:
> Hi all,
>
> First of all, please excuse me if I'm presenting this idea in the wrong way
> or at the wrong time - I'm new to this mailing list and haven't seen anyone
> propose a new idea on it yet, so I don't know the customs.
>
> I have an idea for i
I'm fairly certain similar changes have been discussed in the past. Someone
else can probably find / link / rehash the reasons why imports deliberately
use dot notation instead of path?
I can think of a few:
1) Portability. dotted imports looked up from sys.path are platform-portable
# $HOME/\th
Hi all,
First of all, please excuse me if I'm presenting this idea in the wrong way
or at the wrong time - I'm new to this mailing list and haven't seen anyone
propose a new idea on it yet, so I don't know the customs.
I have an idea for importing files with arbitrary names. Currently, the
"offic
13 matches
Mail list logo
