On Apr 21, 2010, at 02:56 PM, Mark Dickinson wrote:
>On Wed, Apr 21, 2010 at 2:40 PM, Barry Warsaw wrote:
>> While talking about Python 2.6 -> 2.7 transitions, the subject of relative
>> and
>> absolute imports has come up. PEP 328 states that absolute imports will be
>> enabled by default in P
On Wed, Apr 21, 2010 at 06:58, Mark Dickinson wrote:
> On Wed, Apr 21, 2010 at 2:56 PM, Mark Dickinson
> wrote:
> > On Wed, Apr 21, 2010 at 2:40 PM, Barry Warsaw wrote:
> >> While talking about Python 2.6 -> 2.7 transitions, the subject of
> relative and
> >> absolute imports has come up. PEP
On Wed, Apr 21, 2010 at 2:56 PM, Mark Dickinson wrote:
> On Wed, Apr 21, 2010 at 2:40 PM, Barry Warsaw wrote:
>> While talking about Python 2.6 -> 2.7 transitions, the subject of relative
>> and
>> absolute imports has come up. PEP 328 states that absolute imports will be
>> enabled by default
On Wed, Apr 21, 2010 at 2:40 PM, Barry Warsaw wrote:
> While talking about Python 2.6 -> 2.7 transitions, the subject of relative and
> absolute imports has come up. PEP 328 states that absolute imports will be
> enabled by default in Python 2.7, however I cannot verify that this has
> actually h
While talking about Python 2.6 -> 2.7 transitions, the subject of relative and
absolute imports has come up. PEP 328 states that absolute imports will be
enabled by default in Python 2.7, however I cannot verify that this has
actually happened.
* Misc/NEWS doesn't mention it
* What's New in Pytho
Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Real-world usage case for import __main__? Otherwise, I say screw it :)
I have used it as a workaround for timeit.py's requirement that I pass
it strings instead of functions.
>>> def compute():
... 1+1
...
>>> import timeit
>>> t = timeit.Timer("__m
> Real-world usage case for import __main__?
Typically for inter-module communication. A standard name (such as
lobby, or __settings__) would work as well, but __main__ is what we
have, for backwards compatibility.
-jJ
___
Python-Dev mailing list
Pytho
Guido van Rossum wrote:
>> Real-world usage case for import __main__? Otherwise, I say screw it
>> :) [...] My personal argument is that if __name__ == '__main__' is
>> totally counter-intuitve and unpythonic. It also proves my memory:
>> after many years, I still have to think a couple of seconds
On 6/29/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Real-world usage case for import __main__? Otherwise, I say screw it :)
[...]
> My personal argument is that if __name__ == '__main__' is totally
> counter-intuitve and unpythonic. It also proves my memory: after many years,
> I still have to t
On Thursday 29 June 2006 20:56, Nick Coghlan wrote:
> Guido van Rossum wrote:
> > On 6/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> >> The workaround to replace __name__ with __module_name__ in order
> >> to enable
> >> relative imports turned out to be pretty ugly, so I also worked
> >> up a p
Nick Coghlan wrote:
> Writing modules that use the approach but want to work with both 2.5
> and 2.6 becomes a little more annoying - such modules have to finish
> with the coda:
>
> if __name__ == '__main__':
>from sys import version_info, argv
>if version_info < (2, 6):
>sys.exit
Giovanni Bajo wrote:
> Guido van Rossum wrote:
>
This is where I wonder why the "def __main__()" PEP was rejected in
the first place. It would have solved this problem as well.
>>> Could this be reconsidered for Py3k?
>> You have a point.
>
> AFAICT, there's nothing preventing it from b
Guido van Rossum wrote:
> On 6/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
>> The workaround to replace __name__ with __module_name__ in order to
>> enable
>> relative imports turned out to be pretty ugly, so I also worked up a
>> patch to
>> import.c to get it to treat __module_name__ as a
Guido van Rossum wrote:
> On 6/27/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Giovanni Bajo wrote:
>>
>> > This is where I wonder why the "def __main__()" PEP was rejected in the
>> > first place. It would have solved this problem as well.
>>
>> Could this be reconsidered for Py3k?
>
> You have a
Guido van Rossum wrote:
>>> This is where I wonder why the "def __main__()" PEP was rejected in
>>> the first place. It would have solved this problem as well.
>>
>> Could this be reconsidered for Py3k?
>
> You have a point.
AFAICT, there's nothing preventing it from being added in 2.6. It won't
On 6/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The workaround to replace __name__ with __module_name__ in order to enable
> relative imports turned out to be pretty ugly, so I also worked up a patch to
> import.c to get it to treat __module_name__ as an override for __name__ when
> __name__
Nick Coghlan wrote:
> Guido van Rossum wrote:
>> However, I'm fine with setting *another* variable to the full package
>> name so someone who *really* wants to do relative imports here knows
>> the package name.
>
> OK, I'll do that. Any objections to __module_name__ as the name of the
> variable?
Guido van Rossum wrote:
> However, I'm fine with setting *another* variable to the full package
> name so someone who *really* wants to do relative imports here knows
> the package name.
OK, I'll do that. Any objections to __module_name__ as the name of the
variable? (to keep things simple, run_mo
On 6/27/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Giovanni Bajo wrote:
>
> > This is where I wonder why the "def __main__()" PEP was rejected in the
> > first place. It would have solved this problem as well.
>
> Could this be reconsidered for Py3k?
You have a point.
--
--Guido van Rossum (hom
Giovanni Bajo wrote:
> This is where I wonder why the "def __main__()" PEP was rejected in the
> first place. It would have solved this problem as well.
Could this be reconsidered for Py3k?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http
Guido van Rossum wrote:
> Bad idea IMO. The __name__ == "__main__" rule is so ingrained, you
> don't want to mess with it.
It would only make a difference for main modules inside
packages. Wouldn't that be fairly rare? The vast majority
of existing __name__ == "__main__" uses ought to be
unaffect
On Tue, Jun 27, 2006, Phillip J. Eby wrote:
> At 08:08 AM 6/27/2006 -0700, Guido van Rossum wrote:
>>
>>Bad idea IMO. The __name__ == "__main__" rule is so ingrained, you
>>don't want to mess with it.
>
> Actually, maybe we *do* want to, for this usage.
>
> Note that until Python 2.5, it was not
On 6/27/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 08:08 AM 6/27/2006 -0700, Guido van Rossum wrote:
> >Bad idea IMO. The __name__ == "__main__" rule is so ingrained, you
> >don't want to mess with it.
>
> Actually, maybe we *do* want to, for this usage.
>
> Note that until Python 2.5, it w
On 6/27/06, Nicko van Someren <[EMAIL PROTECTED]> wrote:
> Hum... other than effecting more or less every runnable python module
> around it should be very little impact. That sounds like quite a bit
> of impact to me!
Going from "__name__ == '__main__'" to "__name__.endswith('__main__')"
can be
Phillip J. Eby wrote:
> Actually, maybe we *do* want to, for this usage.
>
> Note that until Python 2.5, it was not possible to do "python -m
> nested.module", so this change merely prevents *existing* modules from
> being run this way -- when they could not have been before!
>
> So, such modules
At 08:08 AM 6/27/2006 -0700, Guido van Rossum wrote:
>Bad idea IMO. The __name__ == "__main__" rule is so ingrained, you
>don't want to mess with it.
Actually, maybe we *do* want to, for this usage.
Note that until Python 2.5, it was not possible to do "python -m
nested.module", so this change m
On 27 Jun 2006, at 13:03, Nick Coghlan wrote:
> ...
> It occurred to me that a slight modification to PEP 338 might solve
> the
> problem fairly cleanly: instead of simply setting __name__ to
> '__main__' for a
> module in a package, the -m switch could prepend the package name
> so that
> re
On 6/27/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Mitch Chapman [1] tripped over the fact that relative imports don't like main
> modules because __name__ doesn't contain any package hierarchy information.
>
> It occurred to me that a slight modification to PEP 338 might solve the
> problem fai
Mitch Chapman [1] tripped over the fact that relative imports don't like main
modules because __name__ doesn't contain any package hierarchy information.
It occurred to me that a slight modification to PEP 338 might solve the
problem fairly cleanly: instead of simply setting __name__ to '__main_
"Thomas Wouters" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The one open point that Aahz forwarded me, and is expressed somewhat in
> http://mail.python.org/pipermail/python-dev/2004-September/048695.html ,
> is
> the case where you have a package that you want to transparentl
On 2/25/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
> Since I implemented[*] PEP 328, Aahz suggested I take over editing the PEP,
> too, as there were some minor discussion points to add still. I haven't been
> around for the discussioons, though, and it's been a while for everone else,
> I thi
Since I implemented[*] PEP 328, Aahz suggested I take over editing the PEP,
too, as there were some minor discussion points to add still. I haven't been
around for the discussioons, though, and it's been a while for everone else,
I think, so I'd like to rehash and ask for any other open points.
T
Guido van Rossum wrote:
> On 11/1/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
>>At 10:22 AM 11/1/2005 -0700, Guido van Rossum wrote:
>>
>>>* PEP 328 - absolute/relative import
>>
>>I assume that references to 2.4 in that PEP should be changed to 2.5, and
>>so on.
>
>
> For the part that hasn
33 matches
Mail list logo
