Re: Rough PEP: A ModuleSpec Type for the Import System

On Fri, Aug 9, 2013 at 12:20 PM, Brett Cannon <[email protected]> wrote:

> On Fri, Aug 9, 2013 at 2:03 PM, Eric Snow <[email protected]>wrote:
>
>
Having just the module parameter and letting it indicate a reload is
>> doable, but that would mean losing the option of having load() look up the
>> module (and it's less explicit).  Another option is to have a separate
>> reload() method.  Antoine mentioned it and I'd considered it early on.  I'm
>> considering it again since it makes the API less complicated.  Do you have
>> a preference between the current proposal (load() does it all) and a
>> separate reload() method?
>>
>
> Nope, no preference.
>

Okay.  I'll probably try it out a separate reload() and see how things look.


>
>
>>
>>  ``is_package`` is derived from ``path``, if passed.  Otherwise the
>>>> loader's ``is_package()`` is tried.  Finally, it defaults to False.
>>>>
>>>
>>> It can also be calculated based on whether ``name`` == ``package``:
>>> ``True if path is not None else name == package``.
>>>
>>
>> Good point, though at this point I don't think package will be something
>> you set.
>>
>
> So you would set 'name' and 'path' to decide if something is a package and
> use that to calculate 'package'?
>

That and the loader's is_package(), if available.


> cache_from_source()
>>
>
> I figured, but I know too much about this stuff. =) I would spell it out
> in the PEP.
>

Done.


> __getattr__().  I don't want to guess what methods a loader might have.
>>  And if someone wants to call get_filename() on what they think is the
>> loader, I think it's better to just call the loader's get_filename().  I'd
>> left this stuff out as an implementation detail.  Do you think it should be
>> in the PEP?  I could simply elaborate on "specs must act like the loader".
>>
>
> I would elaborate that it's going to be __getattr__() since it influences
> the level of backwards-compatibility.
>

Done.


> My goal was for ModuleSpec to be the container for module definition state
>> with some common attributes as a baseline and a minimal number of methods
>> for the import system to use.  Loaders would be where you would do extra
>> stuff or customize functionality, which is basically what happens now.
>>
>> It seemed correct before but now it's feeling like a very artificial and
>> unnecessary objective.
>>
>
> I totally get where you are coming from and if we were working in a
> language that pushed for read-only attributes I would agree, but we aren't
> so I wouldn't. =) It just becomes more hassle than it's worth to enforce.
>

Agreed.


> in lieu of the fact that find_loader() was just introduced in Python 3.3.
>>>
>>
>> Are you suggesting additional wording or making a comment?
>>
>
> Both? =)
>

Okay.  I clarified that.

I'll probably be posting an updated PEP shortly.

-eric

_______________________________________________
Import-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/import-sig