Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #80626 > unrolled thread

How about some syntactic sugar for " __name__ == '__main__' "?

Back to article view | Back to comp.lang.python

Contents

  How about some syntactic sugar for " __name__ == '__main__' "? John Ladasky <john_ladasky@sbcglobal.net> - 2014-11-12 13:02 -0800
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Joel Goldstick <joel.goldstick@gmail.com> - 2014-11-12 16:07 -0500
    Re: How about some syntactic sugar for " __name__ == '__main__' "? John Ladasky <john_ladasky@sbcglobal.net> - 2014-11-12 13:17 -0800
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Ethan Furman <ethan@stoneleaf.us> - 2014-11-12 13:19 -0800
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Chris Kaynor <ckaynor@zindagigames.com> - 2014-11-12 13:33 -0800
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Marko Rauhamaa <marko@pacujo.net> - 2014-11-12 23:52 +0200
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-12 14:51 -0700
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Skip Montanaro <skip.montanaro@gmail.com> - 2014-11-12 15:55 -0600
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Chris Kaynor <ckaynor@zindagigames.com> - 2014-11-12 14:09 -0800
      Re: How about some syntactic sugar for " __name__ == '__main__' "? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-15 22:09 +1100
        Re: How about some syntactic sugar for " __name__ == '__main__' "? Marko Rauhamaa <marko@pacujo.net> - 2014-11-15 13:54 +0200
        Re: How about some syntactic sugar for " __name__ == '__main__' "? Vito De Tullio <vito.detullio@gmail.com> - 2014-11-16 11:26 +0100
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-12 15:19 -0700
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Terry Reedy <tjreedy@udel.edu> - 2014-11-12 18:19 -0500
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Chris Angelico <rosuav@gmail.com> - 2014-11-13 10:26 +1100
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Terry Reedy <tjreedy@udel.edu> - 2014-11-12 19:35 -0500
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Chris Angelico <rosuav@gmail.com> - 2014-11-13 11:54 +1100
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Ethan Furman <ethan@stoneleaf.us> - 2014-11-13 10:32 -0800
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-13 13:33 -0700
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Ethan Furman <ethan@stoneleaf.us> - 2014-11-13 12:43 -0800
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Skip Montanaro <skip.montanaro@gmail.com> - 2014-11-13 14:44 -0600
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Skip Montanaro <skip.montanaro@gmail.com> - 2014-11-13 14:53 -0600
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-13 15:48 -0700
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-13 15:56 -0700
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-15 21:52 +1100
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Vito De Tullio <vito.detullio@gmail.com> - 2014-11-16 11:39 +0100
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-16 10:15 -0700
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Ethan Furman <ethan@stoneleaf.us> - 2014-12-01 15:19 -0800
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Ethan Furman <ethan@stoneleaf.us> - 2014-12-01 16:45 -0800
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Chris Angelico <rosuav@gmail.com> - 2014-12-02 12:15 +1100
    Re: How about some syntactic sugar for " __name__ == '__main__' "? Ethan Furman <ethan@stoneleaf.us> - 2014-12-02 02:17 -0800

Page 1 of 2  [1] 2  Next page →

#80626 — How about some syntactic sugar for " __name__ == '__main__' "?

I have taught Python to several students over the past few years.  As I have worked with my students, I find myself bothered by the programming idiom that we use to determine whether a module is being executed or merely imported:

  "if __name__ == '__main__':"

The use of two dunder tokens -- one as a name in a namespace, and the other as a string, is intimidating.  It exposes too much of Python's guts.  As such, I think that it is less Pythonic than we might want.  Myself, I've been programming in Python for a decade, and I still haven't dug very deeply into what exactly __name__ means or does.

I would like to start a discussion about whether Python should include a function which executes this evaluation, and hides all of the unfriendly dunderish details.  And if that's a good idea, I would invite a discussion of how, exactly, it should be implemented.  I'm nowhere near proposing a PEP, but that may come later.

Thanks for your thoughts.

[toc] | [next] | [standalone]

#80627

On Wed, Nov 12, 2014 at 4:02 PM, John Ladasky
<john_ladasky@sbcglobal.net> wrote:
> I have taught Python to several students over the past few years.  As I have worked with my students, I find myself bothered by the programming idiom that we use to determine whether a module is being executed or merely imported:
>
>   "if __name__ == '__main__':"
>
> The use of two dunder tokens -- one as a name in a namespace, and the other as a string, is intimidating.  It exposes too much of Python's guts.  As such, I think that it is less Pythonic than we might want.  Myself, I've been programming in Python for a decade, and I still haven't dug very deeply into what exactly __name__ means or does.
>
> I would like to start a discussion about whether Python should include a function which executes this evaluation, and hides all of the unfriendly dunderish details.  And if that's a good idea, I would invite a discussion of how, exactly, it should be implemented.  I'm nowhere near proposing a PEP, but that may come later.
>
> Thanks for your thoughts.
> --
> https://mail.python.org/mailman/listinfo/python-list

How about a decorator?

-- 
Joel Goldstick
http://joelgoldstick.com

[toc] | [prev] | [next] | [standalone]

#80628

It appears that I'm not the first person to have thoughts along these lines.  Here's a relevant article:

http://aliles.tumblr.com/post/7455032885/sugar-for-pythons-main

[toc] | [prev] | [next] | [standalone]

#80629

On 11/12/2014 01:02 PM, John Ladasky wrote:
>
> I would like to start a discussion about whether Python should include
>  a function which executes this evaluation, and hides all of the unfriendly
>  dunderish details.  And if that's a good idea, I would invite a discussion
>  of how, exactly, it should be implemented.  I'm nowhere near proposing a
>  PEP, but that may come later.

I believe this has come up before.  You might check the Python-Ideas list to see.  If you do, please write up a summary 
of the past discussions so we can move forward instead of rehashing the same things as before.

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#80631

[Multipart message — attachments visible in raw view] — view raw

On Wed, Nov 12, 2014 at 1:07 PM, Joel Goldstick <joel.goldstick@gmail.com>
wrote:

> On Wed, Nov 12, 2014 at 4:02 PM, John Ladasky
> <john_ladasky@sbcglobal.net> wrote:
> > I have taught Python to several students over the past few years.  As I
> have worked with my students, I find myself bothered by the programming
> idiom that we use to determine whether a module is being executed or merely
> imported:
> >
> >   "if __name__ == '__main__':"
> >
> > The use of two dunder tokens -- one as a name in a namespace, and the
> other as a string, is intimidating.  It exposes too much of Python's guts.
> As such, I think that it is less Pythonic than we might want.  Myself, I've
> been programming in Python for a decade, and I still haven't dug very
> deeply into what exactly __name__ means or does.
> >
> > I would like to start a discussion about whether Python should include a
> function which executes this evaluation, and hides all of the unfriendly
> dunderish details.  And if that's a good idea, I would invite a discussion
> of how, exactly, it should be implemented.  I'm nowhere near proposing a
> PEP, but that may come later.
> >
> > Thanks for your thoughts.
>
> How about a decorator?
>

A decorator is an interesting idea, and should be easy to implement (only
lightly tested):

def main(func):
    if func.__module__ == "__main__":
            func()
    return func # The return could be omitted to block the function from
being manually called after import.

Just decorate the "main" function of the script with that, and it will be
automatically called when ran as a script, but not when imported as a
module.

[toc] | [prev] | [next] | [standalone]

#80633

John Ladasky <john_ladasky@sbcglobal.net>:

> I find myself bothered by the programming idiom that we use to
> determine whether a module is being executed or merely imported:
>
>   "if __name__ == '__main__':"

I find the idiom cute and loveably silly. A typing tongue twister of
sorts. That boilerplate is far less cumbersome than, say, in Java.

> Myself, I've been programming in Python for a decade, and I still
> haven't dug very deeply into what exactly __name__ means or does.

The idiom allows you to include a main function in auxiliary modules.
When imported, the module acts as a library. When executed, it acts as a
command. I have done this a couple of times IRL.

> I would like to start a discussion about whether Python should include
> a function which executes this evaluation, and hides all of the
> unfriendly dunderish details.

Probably not. Idioms are important in that they are immediately spotted
by a casual reader of the code. However ugly you consider those two
lines, it will not waste a measurable amount of your precious time to
begin your brand new project by typing:

   import sys

   def main():
       pass

   if __name__ == "__main__":
       main()


Yes, I always type those in again. I don't copy them over as I do, say,
Java main programs or static HTML pages.


Marko

[toc] | [prev] | [next] | [standalone]

#80634

On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor <ckaynor@zindagigames.com> wrote:
> A decorator is an interesting idea, and should be easy to implement (only
> lightly tested):
>
> def main(func):
>     if func.__module__ == "__main__":
>             func()
>     return func # The return could be omitted to block the function from
> being manually called after import.
>
> Just decorate the "main" function of the script with that, and it will be
> automatically called when ran as a script, but not when imported as a
> module.

This calls it at the wrong time, though. Typically the way this idiom
is used is that you define everything you need (functions, classes,
etc.) within the main script, and then you call the main function.
This would call the main function at the time it's defined, when other
things in the main script may not have been defined yet. One could
place the main function last, but it would be preferable not to be
forced.

This also calls the function before it's been assigned to the global,
which would prevent recursive calls of the main function.

Instead of a decorator, I'd prefer to just have this:

def main(func, *args, **kwargs):
    if func.__module__ == '__main__':
        func(*args, **kwargs)

And then I can easily invoke it wherever I want in the main script.

[toc] | [prev] | [next] | [standalone]

#80636

> def main(func):
>     if func.__module__ == "__main__":
>             func()
>     return func # The return could be omitted to block the function from
> being manually called after import.
>
> Just decorate the "main" function of the script with that, and it will be
> automatically called when ran as a script, but not when imported as a
> module.

This won't work (I don't think) if you want to call the "main"
function from another place (like the interpreter prompt).

Skip

[toc] | [prev] | [next] | [standalone]

#80642

[Multipart message — attachments visible in raw view] — view raw

On Wed, Nov 12, 2014 at 1:51 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:

> On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor <ckaynor@zindagigames.com>
> wrote:
> > A decorator is an interesting idea, and should be easy to implement (only
> > lightly tested):
> >
> > def main(func):
> >     if func.__module__ == "__main__":
> >             func()
> >     return func # The return could be omitted to block the function from
> > being manually called after import.
> >
> > Just decorate the "main" function of the script with that, and it will be
> > automatically called when ran as a script, but not when imported as a
> > module.
>
> This calls it at the wrong time, though. Typically the way this idiom
> is used is that you define everything you need (functions, classes,
> etc.) within the main script, and then you call the main function.
> This would call the main function at the time it's defined, when other
> things in the main script may not have been defined yet. One could
> place the main function last, but it would be preferable not to be
> forced.
>
>
I was thinking along the lines of replacing:

if __name__ == "__main__":
    <<<block of code>>>

with

@main
def myFunction()
    <<<<block of code>>

Both blocks of code will be called at the same time.


> This also calls the function before it's been assigned to the global,
> which would prevent recursive calls of the main function.
>
> Instead of a decorator, I'd prefer to just have this:
>
> def main(func, *args, **kwargs):
>     if func.__module__ == '__main__':
>         func(*args, **kwargs)
>
> And then I can easily invoke it wherever I want in the main script.



> On Wed, Nov 12, 2014 at 1:55 PM, Skip Montanaro <skip.montanaro@gmail.com>
 wrote:
>
> This won't work (I don't think) if you want to call the "main"

function from another place (like the interpreter prompt).


With the plain if block, you absolutely cannot call it elsewhere, without
wrapping it in a function anyways.

There is the issue, as mentioned by Ian, that the function will not be in
the module namespace at the time it is called. That does block it, however
it is also easy to work around: make the main function extremely simple,
such as just calling another function.

[toc] | [prev] | [next] | [standalone]

#80818

Chris Kaynor wrote:

> I was thinking along the lines of replacing:
> 
> if __name__ == "__main__":
> <<<block of code>>>
> 
> with
> 
> @main
> def myFunction()
> <<<<block of code>>
> 
> Both blocks of code will be called at the same time.


You can't guarantee that, because you cannot tell ahead of time when the "if
__name__" statement will be run. It is *usually* at the end of the file,
but that's just the normal useful convention, it is not a hard requirement.

The current idiom uses normal, unmagical execution of Python code. When the
interpreter reaches the "if __name__ ..." statement, it executes that
statement, just like every other statement. There's no magic involved here,
and in fact I have written code with *multiple* such "if __name__" blocks.
Here's a sketch of the sort of thing I mean:


import a
import b
if __name__ == '__main__':
    import c as d
else:
    import d

def this(): ...
def that(): ...

flag = __name__ == '__main__'
process(flag)

if __name__ == '__main__' or condition():
    print "still executing"
    main()

print "done loading"


(I haven't ever done *all* of these things in a *single* file, but I have
done all these things at one time or another.)

There's no way that any automatic system can match that for flexibility or
simplicity.




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#80820

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> if __name__ == '__main__' or condition():
>     print "still executing"
>     main()
>
> print "done loading"
>
> (I haven't ever done *all* of these things in a *single* file, but I
> have done all these things at one time or another.)
>
> There's no way that any automatic system can match that for
> flexibility or simplicity.

Our test system has this boilerplate at the end of each test case:

   if __name__ == '__main__':
       run(test)

Nobody claims it's beautiful but nobody has been overly bothered by it,
either.


Marko

[toc] | [prev] | [next] | [standalone]

#80873

Steven D'Aprano wrote:

> Chris Kaynor wrote:
> 
>> I was thinking along the lines of replacing:
>> 
>> if __name__ == "__main__":
>> <<<block of code>>>
>> 
>> with
>> 
>> @main
>> def myFunction()
>> <<<<block of code>>
>> 
>> Both blocks of code will be called at the same time.
> 
> 
> You can't guarantee that, because you cannot tell ahead of time when the
> "if __name__" statement will be run. It is *usually* at the end of the
> file, but that's just the normal useful convention, it is not a hard
> requirement.


sure you can: simply the main decorator is just something like

def main(myMainFunction):
    if myMainFunction.__module__ == '__main__':
        myMainFunction()
    return myMainFunction




-- 
By ZeD

[toc] | [prev] | [next] | [standalone]

#80644

On Wed, Nov 12, 2014 at 3:09 PM, Chris Kaynor <ckaynor@zindagigames.com> wrote:
> I was thinking along the lines of replacing:
>
> if __name__ == "__main__":
>     <<<block of code>>>
>
> with
>
> @main
> def myFunction()
>     <<<<block of code>>
>
> Both blocks of code will be called at the same time.

99% of the time the content of <<<block of code>>> is just "main()",
so then you're proposing replacing this:

if __name__ == "__main__":
    main()

with this:

@main
def myFunction():
    my_main()

Which feels redundant to me. Why have a function here that does
nothing but call another function?

I think if this is the goal then a simple predicate would be clearer:

if is_main_module():
    main()

[toc] | [prev] | [next] | [standalone]

#80658

On 11/12/2014 4:02 PM, John Ladasky wrote:
> I have taught Python to several students over the past few years.  As
> I have worked with my students, I find myself bothered by the
> programming idiom that we use to determine whether a module is being
> executed or merely imported:
>
> "if __name__ == '__main__':"
>
> The use of two dunder tokens -- one as a name in a namespace, and the
> other as a string, is intimidating.  It exposes too much of Python's
> guts.  As such, I think that it is less Pythonic than we might want.
> Myself, I've been programming in Python for a decade, and I still
> haven't dug very deeply into what exactly __name__ means or does.
>
> I would like to start a discussion about whether Python should
> include a function which executes this evaluation, and hides all of
> the unfriendly dunderish details.  And if that's a good idea, I would
> invite a discussion of how, exactly, it should be implemented.  I'm
> nowhere near proposing a PEP, but that may come later.

Functions have an implicit 'return None' at the end (which, in CPython, 
become an explicit pair of bytecodes, even when the function already 
ends with return something'.  The simplest proposal is that modules have 
an implicit "if __name__ == '__main__': main()" at the end.  I think 
this would not have to be added to the bytecode.

This magical invocation mimics C and some other languages, and I think 
it works well.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#80660

On Thu, Nov 13, 2014 at 10:19 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> Functions have an implicit 'return None' at the end (which, in CPython,
> become an explicit pair of bytecodes, even when the function already ends
> with return something'.  The simplest proposal is that modules have an
> implicit "if __name__ == '__main__': main()" at the end.  I think this would
> not have to be added to the bytecode.
>
> This magical invocation mimics C and some other languages, and I think it
> works well.

Yes, but it conflicts with the existing and common usage of having
that explicitly in the code. Safer - and more in line with the way
other such functions are written - would be a dunder function:

if __name__ == '__main__': __main__()

ChrisA

[toc] | [prev] | [next] | [standalone]

#80664

On 11/12/2014 6:26 PM, Chris Angelico wrote:
> On Thu, Nov 13, 2014 at 10:19 AM, Terry Reedy <tjreedy@udel.edu> wrote:
>> Functions have an implicit 'return None' at the end (which, in CPython,
>> become an explicit pair of bytecodes, even when the function already ends
>> with return something'.  The simplest proposal is that modules have an
>> implicit "if __name__ == '__main__': main()" at the end.  I think this would
>> not have to be added to the bytecode.
>>
>> This magical invocation mimics C and some other languages, and I think it
>> works well.
>
> Yes, but it conflicts with the existing and common usage of having
> that explicitly in the code.

Yeh, calling main twice could be a problem.

> Safer - and more in line with the way
> other such functions are written - would be a dunder function:
>
> if __name__ == '__main__': __main__()

I presume you mean that calling __main__ implicitly would be both 
consistent and safer.  No code should be using that now.


-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#80666

On Thu, Nov 13, 2014 at 11:35 AM, Terry Reedy <tjreedy@udel.edu> wrote:
>> Safer - and more in line with the way
>> other such functions are written - would be a dunder function:
>>
>> if __name__ == '__main__': __main__()
>
>
> I presume you mean that calling __main__ implicitly would be both consistent
> and safer.  No code should be using that now.

That's what I mean. Like changing iter.next() to iter.__next__() in
Py3, it'd be using a name that emphasizes that the interpreter, not
userland code, should be calling this function.

Of course, it'd still be optional. Top-level code would be executed
top-down, same as it now is.

ChrisA

[toc] | [prev] | [next] | [standalone]

#80695

On 11/12/2014 01:51 PM, Ian Kelly wrote:
> On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor wrote:
>>
>> A decorator is an interesting idea, and should be easy to implement (only
>> lightly tested):
>>
>> def main(func):
>>      if func.__module__ == "__main__":
>>              func()
>>      return func # The return could be omitted to block the function from
>> being manually called after import.
>
> This calls it at the wrong time, though.  [...]

One decorator that won't call too early is atexit.register().

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#80700

On Thu, Nov 13, 2014 at 11:32 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
> On 11/12/2014 01:51 PM, Ian Kelly wrote:
>>
>> On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor wrote:
>>>
>>> A decorator is an interesting idea, and should be easy to implement (only
>>> lightly tested):
>>>
>>> def main(func):
>>>      if func.__module__ == "__main__":
>>>              func()
>>>      return func # The return could be omitted to block the function from
>>> being manually called after import.
>>
>> This calls it at the wrong time, though.  [...]
>
> One decorator that won't call too early is atexit.register().

Nice. That feels like an abuse, though. The actual program won't be
able to register its own atexit handlers, because the program will
already be exiting, and other things decorated with atexit.register
might actually be called before the main function.

[toc] | [prev] | [next] | [standalone]

#80701

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/13/2014 12:33 PM, Ian Kelly wrote:
> On Thu, Nov 13, 2014 at 11:32 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
>> On 11/12/2014 01:51 PM, Ian Kelly wrote:
>>> 
>>> On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor wrote:
>>>> 
>>>> A decorator is an interesting idea, and should be easy to implement (only lightly tested):
>>>> 
>>>> def main(func): if func.__module__ == "__main__": func() return func # The return could be omitted to block
>>>> the function from being manually called after import.
>>> 
>>> This calls it at the wrong time, though.  [...]
>> 
>> One decorator that won't call too early is atexit.register().
> 
> Nice. That feels like an abuse, though. The actual program won't be able to register its own atexit handlers,
> because the program will already be exiting, and other things decorated with atexit.register might actually be
> called before the main function.

It's definitely a niche use-case -- such as a cli-helper lib:  import said lib, and when it's decorators are used set
the atexit handler to call the lib's __main__ function, which checks that the module name of the decorated function is
'__main__', and if it is, run stuff!

Hmmm... hopefully that wasn't difficult to explain.  ;)

- --
~Ethan~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUZRfjAAoJENZ7D1rrH75Nx4IP/3tuR4JhVK6Acv04+DiHm32H
BHGmBRZGtXQrHGEBcv8BlvUiztmrHqjV+Lkm78zKF3n9R8Ta9qTeSjqIsjRWUMtR
JVraCSH6usUwmcGITXIYKQHdXynl+ylu9p8Hr3NT2aNoICqowVGSvK3Ie1NmJuf3
lJcl8tXiXgUrGCwBwEgdrBKTdaATe4QT9XFQJx1QbXpF3qT1Za5hPYthY3fH/Pd9
Nl9NHyA6F5x4sSO7itD23UtUpnRBHWl7blwsKkBi7ClfacxJMrYjFAMUaxUaiTFF
/bygveskmMAZw87ISLtjkmOcKtsi0i2BQSQEjpBDZTiveCD/wyDDhJ+5pmZKzll0
Q+pISt4jG9hkArd+JCCxPuTCCo2xm+cMIB4/oSeONd760u6vURLPUNZ5tmNsRkiZ
o0/EwyRhWPZotiLoyi7kDNyfpj/BSKV0A6Ph+M40UXOkTZFUf0E84OFEpB359MTO
rIvHDpd6Tzch2Dliuj6UKZ1OOygIZauv2ebmEBHHNDMdsVbhdtTElS1Rh2JtDVyZ
tUd67KTmE9CwOPcFIbYKHXGIf4FWDAgeaz9x8RY4UUPaDRlyG1eqSxx8Vob2AG9c
MEawmA48JCj52ZeICQf6nnIFdIowFkV7QssUgte3cVfbcMBYnPx/nuJWWMjULo77
WrIUpisDf/juvXn4VtuO
=oczI
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web