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
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
22 matches
Mail list logo
