[Python-ideas] making a module callable

Michael Foord fuzzyman at gmail.com
Fri Nov 22 18:01:17 CET 2013


On 22 November 2013 16:45, Gregory P. Smith <greg at krypto.org> wrote:

>
>
>
> On Wed, Nov 20, 2013 at 7:44 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>>
>> On 21 Nov 2013 13:02, "Ethan Furman" <ethan at stoneleaf.us> wrote:
>> >
>> > On 11/20/2013 05:57 PM, Andrew Barnert wrote:
>> >
>> >> On Nov 20, 2013, at 12:14, Eric Snow wrote:
>> >>
>> >>> In contrast, something like __metamodule__ would be an effective
>> >>> replacement.  It would be similar in spirit and in syntax to
>> >>> __init_class__ in PEP 422 (and __metaclass__ in Python 2), defined at
>> >>> the top of the module and used for the module.  The thing that appeals
>> >>> to me is that we could deprecate the sys.modules hack. :)
>> >>
>> >>
>> >> Given that __metaclass__ was removed in Python 3, doesn't "this is an
>> >>  exact parallel to __metaclass__" argue against the idea, rather than
>> >>  for? Or at least against the name? (Maybe __init_module__?)
>> >>
>> >> Anyway, I think a module replacing itself with something callable is
>> >>  both more flexible and more in line with the way people are actually
>> >>  doing things today, so maybe a "less hacky" way to do the sys.modules
>> >>  hack is what people actually want here.
>> >
>> >
>> > sys.modules is a dictionary.
>> >
>> >     dict[name] = something
>> >
>> > is the normal way to set values to keys.
>> >
>> > What is so horrible about this idiom?
>>
>> It potentially causes problems for module reloading and it definitely
>> causes problems for the import engine PEP (since sys.modules is process
>> global state).
>>
>> I expect we'll revisit this later in the 3.5 development cycle (we
>> haven't even merged the accepted PEP 451 for 3.4 yet), but formalising the
>> current module replacement idiom is already a more likely outcome than
>> making module instances callable.
>>
> Agreed, formalizing how to do the replacement trick sounds good. It'd be
> ideal for a module to not need to know its own name within the code doing
> the replacement and for it to not need to reimplement common interface bits
> in a replacement class so that it quacks like a module.
>
>

Well, it just has to use __name__. Any formalisation that doesn't get
passed the name is going to have to use frame trickery to get the name
which is just smelly.

Michael


> Making it callable? well, that does just seem silly so I'm not actually
> worried about making that specifically easier itself.
>
>
>> Cheers,
>> Nick.
>>
>> >
>> > --
>> > ~Ethan~
>> >
>> > _______________________________________________
>> > Python-ideas mailing list
>> > Python-ideas at python.org
>> > https://mail.python.org/mailman/listinfo/python-ideas
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>>
>>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
>


-- 

http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131122/5d4d773a/attachment.html>


More information about the Python-ideas mailing list