I'm in general in favor of this. I will accept it once there is a
working implementation that is satisfactory.
Are we planning on supporting this in 2.6? It might break some 2.5
code that messes with modules and packages?
--Guido
On 7/10/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon
Brett Cannon wrote:
> On 7/9/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Given the above limitations, I propose that we document the new
>> attribute as follows:
>>
>> "If the module global __package__ exists when executing an import
>> statement, it is used to determine the base for relative im
On 7/9/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > On 7/8/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> >> As with the current ``__name__`` attribute, setting ``__package__`` will
> >> be the responsibility of the PEP 302 loader used to import a module.
> >> Loaders which
Brett Cannon wrote:
> On 7/8/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> As with the current ``__name__`` attribute, setting ``__package__`` will
>> be the responsibility of the PEP 302 loader used to import a module.
>> Loaders which use ``imp.new_module()`` to create the module object will
>>
On 7/8/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > "Brett Cannon" <[EMAIL PROTECTED]> wrote:
> >> On 7/5/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >>> At 11:53 AM 7/5/2007 +0200, Guido van Rossum wrote:
> I see no big problems with this, except I wonder if in
Josiah Carlson wrote:
> "Brett Cannon" <[EMAIL PROTECTED]> wrote:
>> On 7/5/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>> At 11:53 AM 7/5/2007 +0200, Guido van Rossum wrote:
I see no big problems with this, except I wonder if in the end it
wouldn't be better to *always* define __packa
"Brett Cannon" <[EMAIL PROTECTED]> wrote:
> On 7/5/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 11:53 AM 7/5/2007 +0200, Guido van Rossum wrote:
> > >I see no big problems with this, except I wonder if in the end it
> > >wouldn't be better to *always* define __package_name__ instead of onl
On 7/5/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:53 AM 7/5/2007 +0200, Guido van Rossum wrote:
> >I see no big problems with this, except I wonder if in the end it
> >wouldn't be better to *always* define __package_name__ instead of only
> >when it's in main? And then perhaps rename it
At 11:53 AM 7/5/2007 +0200, Guido van Rossum wrote:
>I see no big problems with this, except I wonder if in the end it
>wouldn't be better to *always* define __package_name__ instead of only
>when it's in main? And then perhaps rename it to __package__? Done
>properly it could always be used for re
Guido van Rossum wrote:
> Oh, one more thing. Perhaps we should rename it, like the other PEPs
> still active slated for inclusion in Py3k (and backporting to 2.6)?
Might as well be consistent - I'll take care of that when I update the
PEP based on your suggestions.
> On 7/5/07, Guido van Rossum
Oh, one more thing. Perhaps we should rename it, like the other PEPs
still active slated for inclusion in Py3k (and backporting to 2.6)?
--Guido
On 7/5/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I see no big problems with this, except I wonder if in the end it
> wouldn't be better to *alwa
I see no big problems with this, except I wonder if in the end it
wouldn't be better to *always* define __package_name__ instead of only
when it's in main? And then perhaps rename it to __package__? Done
properly it could always be used for relative imports, rather than
parsing __module__ to find t
A c.l.p discussion referenced from Python-URL just brought this topic
back to my attention, and with the relatively low traffic on the
development lists in the last few days, it seemed like a good time to
repost this PEP (it vanished beneath the Unicode identifier discussion
last time).
Cheers
13 matches
Mail list logo
