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

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

Is vars() the most useless Python built-in ever?

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

Contents

  Is vars() the most useless Python built-in ever? Steven D'Aprano <steve@pearwood.info> - 2015-12-01 12:00 +1100
    Re: Is vars() the most useless Python built-in ever? Josef Pktd <josef.pktd@gmail.com> - 2015-11-30 19:45 -0800
    Re: Is vars() the most useless Python built-in ever? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-11-30 21:54 -0800
      Re: Is vars() the most useless Python built-in ever? Marko Rauhamaa <marko@pacujo.net> - 2015-12-01 09:34 +0200
        Re: Is vars() the most useless Python built-in ever? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-12-11 13:06 -0800
      Re: Is vars() the most useless Python built-in ever? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-12-01 18:55 +1100
        Re: Is vars() the most useless Python built-in ever? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-12-01 12:33 -0800
          Re: Is vars() the most useless Python built-in ever? Steven D'Aprano <steve@pearwood.info> - 2015-12-02 11:57 +1100
          Re: Is vars() the most useless Python built-in ever? Ian Kelly <ian.g.kelly@gmail.com> - 2015-12-01 22:48 -0600
            Re: Is vars() the most useless Python built-in ever? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-12-11 14:13 -0800
              Re: Is vars() the most useless Python built-in ever? Steven D'Aprano <steve@pearwood.info> - 2015-12-12 15:44 +1100
                Re: Is vars() the most useless Python built-in ever? Chris Angelico <rosuav@gmail.com> - 2015-12-12 16:56 +1100
                Re: Is vars() the most useless Python built-in ever? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-12-14 18:33 -0800
        Re: Is vars() the most useless Python built-in ever? Ben Finney <ben+python@benfinney.id.au> - 2015-12-02 12:47 +1100
      Re: Is vars() the most useless Python built-in ever? John Gordon <gordon@panix.com> - 2015-12-01 16:56 +0000
        Re: Is vars() the most useless Python built-in ever? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-12-01 13:15 -0800
          Re: Is vars() the most useless Python built-in ever? "Albert Visser" <albert.visser@gmail.com> - 2015-12-02 19:08 +0100
      Re: Is vars() the most useless Python built-in ever? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-12-02 13:14 +1300
    Re: Is vars() the most useless Python built-in ever? eryk sun <eryksun@gmail.com> - 2015-12-01 01:22 -0600
      Re: Is vars() the most useless Python built-in ever? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-12-01 18:57 +1100
    Re: Is vars() the most useless Python built-in ever? Manolo Martínez <manolo@austrohungaro.com> - 2015-12-01 09:44 +0100
      Re: Is vars() the most useless Python built-in ever? Steven D'Aprano <steve@pearwood.info> - 2015-12-02 12:12 +1100
        Re: Is vars() the most useless Python built-in ever? Peter Otten <__peter__@web.de> - 2015-12-02 08:51 +0100
    Re: Is vars() the most useless Python built-in ever? Peter Otten <__peter__@web.de> - 2015-12-01 11:40 +0100
    Re: Is vars() the most useless Python built-in ever? Manolo Martínez <manolo@austrohungaro.com> - 2015-12-01 22:31 +0100
    Re: Is vars() the most useless Python built-in ever? Peter Otten <__peter__@web.de> - 2015-12-01 23:41 +0100
    Re: Is vars() the most useless Python built-in ever? boB Stepp <robertvstepp@gmail.com> - 2015-12-01 20:20 -0600
    Re: Is vars() the most useless Python built-in ever? wxjmfauth@gmail.com - 2015-12-01 23:46 -0800
    Re: Is vars() the most useless Python built-in ever? Serhiy Storchaka <storchaka@gmail.com> - 2015-12-02 10:22 +0200
    Re: Is vars() the most useless Python built-in ever? Manolo Martínez <manolo@austrohungaro.com> - 2015-12-02 10:09 +0100
    Re: Is vars() the most useless Python built-in ever? Chris Angelico <rosuav@gmail.com> - 2015-12-02 20:28 +1100
    Re: Is vars() the most useless Python built-in ever? Chris Angelico <rosuav@gmail.com> - 2015-12-02 20:33 +1100
    Re: Is vars() the most useless Python built-in ever? Manolo Martínez <manolo@austrohungaro.com> - 2015-12-02 10:40 +0100
    Re: Is vars() the most useless Python built-in ever? Peter Otten <__peter__@web.de> - 2015-12-02 11:48 +0100
    Re: Is vars() the most useless Python built-in ever? Chris Angelico <rosuav@gmail.com> - 2015-12-02 22:02 +1100
    Re: Is vars() the most useless Python built-in ever? eryk sun <eryksun@gmail.com> - 2015-12-02 05:34 -0600
    Re: Is vars() the most useless Python built-in ever? Serhiy Storchaka <storchaka@gmail.com> - 2015-12-04 10:42 +0200

Page 2 of 2 — ← Prev page 1 [2]

#99778

On 12/01/15 at 12:00pm, Steven D'Aprano wrote:
> I'm trying to understand why vars() exists. Does anyone use it?

Well, I have this little podcast aggregator
(https://github.com/manolomartinez/greg) that I and a bunch of other
people use. I started writing it some years ago, and the code is a bit
of a palimpsest, newer functionality reflecting my (somewhat) better
understanding of the language. One of the oldest bits is this main()
function:

	def main():  # parse the args and call whatever function was selected
		try:
			args = parser.parse_args(sys.argv[1:])
			args.func(vars(args))
		except AttributeError as err:
			if str(err) == "\'Namespace\' object has no attribute \'func\'":
				parser.print_help()
			else:
				print("Something has gone wrong: {}".format(err), file = sys.stderr, flush = True)
	 

To judge by this thread, this is probably wrong/noobish?

Cheers,
Manolo

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

#99839

On Tue, 1 Dec 2015 07:44 pm, Manolo Martínez wrote:

> On 12/01/15 at 12:00pm, Steven D'Aprano wrote:
>> I'm trying to understand why vars() exists. Does anyone use it?
> 
> Well, I have this little podcast aggregator
> (https://github.com/manolomartinez/greg) that I and a bunch of other
> people use. I started writing it some years ago, and the code is a bit
> of a palimpsest, newer functionality reflecting my (somewhat) better
> understanding of the language. One of the oldest bits is this main()
> function:
> 
> def main():  # parse the args and call whatever function was selected
>     try:
>         args = parser.parse_args(sys.argv[1:])
>         args.func(vars(args)) 
>     except AttributeError as err:
>         if str(err) == "\'Namespace\' object has no attribute \'func\'":
>             parser.print_help()
>         else:
>             print("Something has gone wrong: {}".format(err), 
>                   file = sys.stderr, flush = True)
> 
> 
> To judge by this thread, this is probably wrong/noobish?

I've seen worse :-)

Checking the error message in that way is risky. As an absolute last resort,
I guess it works, but it's hack-ish (not in a good way) and fragile. The
problem is, error messages are not part of the Python API and are subject
to change without warning.

(Aside: when I design my language, I'm going to ensure that error messages
vary from one exception to the next, specifically to discourage this :-)

Today, you get an error message 

"'Namespace' object has no attribute 'func'"

(note that there is no need to escape the single quotes) but there's no
guarantee that this will always be the same. Tomorrow it could silently
change to:

'"Namespace" instance does not have a "func" attribute.'

and your code will break. Better and safer is:


def main():  # parse the args and call whatever function was selected
    args = parser.parse_args(sys.argv[1:])
    try:
        func = args.func
    except AttributeError as err:
        parser.print_help()
    else:
        func(vars(args))



-- 
Steven

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

#99847

Steven D'Aprano wrote:

> and your code will break. Better and safer is:
> 
> 
> def main():  # parse the args and call whatever function was selected
>     args = parser.parse_args(sys.argv[1:])
>     try:
>         func = args.func
>     except AttributeError as err:
>         parser.print_help()
>     else:
>         func(vars(args))

I don't think this is any better. You are reponding on a programming error 
in the script as if the user had provided erroneous input. Very confusing.
Just

    args.func(vars(args))

will produce a traceback if the programmer made an error and a help message 
if the user provides arguments that are not recognized. 

That's how it should be.

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

#99786

Manolo Martínez wrote:

> On 12/01/15 at 12:00pm, Steven D'Aprano wrote:
> > I'm trying to understand why vars() exists. Does anyone use it?
> 
> Well, I have this little podcast aggregator
> (https://github.com/manolomartinez/greg) that I and a bunch of other
> people use. I started writing it some years ago, and the code is a bit
> of a palimpsest, newer functionality reflecting my (somewhat) better
> understanding of the language. One of the oldest bits is this main()
> function:
> 
>         def main():  # parse the args and call whatever function was 
selected
>                 try:
>                         args = parser.parse_args(sys.argv[1:])
>                         args.func(vars(args))
>                 except AttributeError as err:
>                         if str(err) == "\'Namespace\' object has no 
attribute \'func\'":
>                                 parser.print_help()
>                         else:
>                                 print("Something has gone wrong: 
{}".format(err), file = sys.stderr, flush = True)
>          
> 
> To judge by this thread, this is probably wrong/noobish?

What probably is typical for a beginner in that snippet is that you don't 
trust the exception system and handle exceptions that will never occur once 
the script is debugged. Just write

args = parser.parse_args()
args.func(vars(args))

Now vars(). I see nothing wrong with it, but when I look into one of your 
func implementations

> def info(args):  # Provides information of a number of feeds
>     session = Session(args)
>     if "all" in args["names"]:
>         feeds = session.list_feeds()
>     else:
>         feeds = args["names"]
>     for feed in feeds:
>         pretty_print(session, feed)

I come to the conclusion that passing args directly could make your life 
easier:

def info(args):  
    """Provides information of a number of feeds"""
    session = Session(args)
    if "all" in args.names:
        feeds = session.list_feeds()
    else:
        feeds = args.names
    for feed in feeds:
        pretty_print(session, feed)

As far as I can see there is only one place where the key is not a constant, 
and you can rewrite that from 

>         try:
>             if args[value]:
>                 return args[value]
>         except KeyError:
>             pass

to

try:
    answer = getattr(args, value)
    if answer: 
        return answer
except AttributeError:
    pass

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

#99822

Peter, thanks for taking the time to look into my code.

On 12/01/15 at 11:40am, Peter Otten wrote:
> Manolo Martínez wrote:
> >         def main():  # parse the args and call whatever function was 
> selected
> >                 try:
> >                         args = parser.parse_args(sys.argv[1:])
> >                         args.func(vars(args))
> >                 except AttributeError as err:
> >                         if str(err) == "\'Namespace\' object has no 
> attribute \'func\'":
> >                                 parser.print_help()
> >                         else:
> >                                 print("Something has gone wrong: 
> {}".format(err), file = sys.stderr, flush = True)
> 
> What probably is typical for a beginner in that snippet is that you don't 
> trust the exception system and handle exceptions that will never occur once 
> the script is debugged. Just write
> 
> args = parser.parse_args()
> args.func(vars(args))

Well, one fully possible situation is for the user to mistype a
subcommand. In that case, the script outputs the help provided by
argparse, so that they know what is and isn't meaningful. That is what
the "if str(err)..." is doing.

The else clause is there to output the traceback (in full trust of the
exception system ;) in case the error was not due to the user mistyping.

Is there a better way to do this?

> Now vars(). I see nothing wrong with it, but when I look into one of your 
> func implementations
> 
> > def info(args):  # Provides information of a number of feeds
> >     session = Session(args)
> >     if "all" in args["names"]:
> >         feeds = session.list_feeds()
> >     else:
> >         feeds = args["names"]
> >     for feed in feeds:
> >         pretty_print(session, feed)
> 
> I come to the conclusion that passing args directly could make your life 
> easier:
> 
> def info(args):  
>     """Provides information of a number of feeds"""
>     session = Session(args)
>     if "all" in args.names:
>         feeds = session.list_feeds()
>     else:
>         feeds = args.names
>     for feed in feeds:
>         pretty_print(session, feed)
> 
> As far as I can see there is only one place where the key is not a constant, 
> and you can rewrite that from 
> 
> >         try:
> >             if args[value]:
> >                 return args[value]
> >         except KeyError:
> >             pass
> 
> to
> 
> try:
>     answer = getattr(args, value)
>     if answer: 
>         return answer
> except AttributeError:
>     pass
> 

This is very helpful, thanks a lot! 

Manolo

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

#99826

Manolo Martínez wrote:

> Peter, thanks for taking the time to look into my code.
> 
> On 12/01/15 at 11:40am, Peter Otten wrote:
>> Manolo Martínez wrote:
>> >         def main():  # parse the args and call whatever function was
>> selected
>> >                 try:
>> >                         args = parser.parse_args(sys.argv[1:])
>> >                         args.func(vars(args))
>> >                 except AttributeError as err:
>> >                         if str(err) == "\'Namespace\' object has no
>> attribute \'func\'":
>> >                                 parser.print_help()
>> >                         else:
>> >                                 print("Something has gone wrong:
>> {}".format(err), file = sys.stderr, flush = True)
>> 
>> What probably is typical for a beginner in that snippet is that you don't
>> trust the exception system and handle exceptions that will never occur
>> once the script is debugged. Just write
>> 
>> args = parser.parse_args()
>> args.func(vars(args))
> 
> Well, one fully possible situation is for the user to mistype a
> subcommand. In that case, the script outputs the help provided by
> argparse, so that they know what is and isn't meaningful. That is what
> the "if str(err)..." is doing.
> 
> The else clause is there to output the traceback (in full trust of the
> exception system ;) in case the error was not due to the user mistyping.
> 
> Is there a better way to do this?

As far as I can see in a correctly written script the AttributeError cannot 
be triggered by the user as argparse handles this case automatically by 
showing the help. For example:

$ cat subparsers.py
#!/usr/bin/env python3
import argparse


def foo(args):
    print(args)


def main():
    parser = argparse.ArgumentParser()
    subparsers = parser.add_subparsers()

    foo_parser = subparsers.add_parser("foo")
    foo_parser.set_defaults(func=foo)

    bar_parser = subparsers.add_parser("bar")
    # programming error --> missing func attribute

    args = parser.parse_args()
    args.func(args)


main()
$ ./subparsers.py foo
Namespace(func=<function foo at 0x7ff18e8a2158>)
$ ./subparsers.py bar
Traceback (most recent call last):
  File "./subparsers.py", line 23, in <module>
    main()
  File "./subparsers.py", line 20, in main
    args.func(args)
AttributeError: 'Namespace' object has no attribute 'func'
$ ./subparsers.py baz # erroneous user input
usage: subparsers.py [-h] {foo,bar} ...
subparsers.py: error: invalid choice: 'baz' (choose from 'foo', 'bar')

The traceback may be a bit intimidating, but with your error handling the 
user will get

$ cat subparsers2.py
#!/usr/bin/env python3
import argparse


def foo(args):
    print(args)


def main():
    parser = argparse.ArgumentParser()
    subparsers = parser.add_subparsers()

    foo_parser = subparsers.add_parser("foo")
    foo_parser.set_defaults(func=foo)

    bar_parser = subparsers.add_parser("bar")
    # programming error --> missing func attribute


    try:
        args = parser.parse_args()
        args.func(args)
    except AttributeError as err:
        if str(err) == "\'Namespace\' object has no attribute \'func\'":
            print("WE ARE HERE")
            parser.print_help()
        else:
            print("Something has gone wrong: {}".format(err), file = 
sys.stderr, flush = True)

main()
$ ./subparsers2.py foo
Namespace(func=<function foo at 0x7ff9f6fedbf8>)
$ ./subparsers2.py baz # erroneous user input does not trigger your error 
handling
usage: subparsers2.py [-h] {foo,bar} ...
subparsers2.py: error: invalid choice: 'baz' (choose from 'foo', 'bar')
$ ./subparsers2.py bar # but an error in your script does
WE ARE HERE
usage: subparsers2.py [-h] {foo,bar} ...

positional arguments:
  {foo,bar}

optional arguments:
  -h, --help  show this help message and exit

which is very confusing. Again, don't replace the traceback unless you are 
absolutely sure you can do better than the Python interpreter.

By the way, I recommend coverage.py to find dead code. I have not used it 
for too long, and I regret it ;)

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

#99843

On Mon, Nov 30, 2015 at 7:00 PM, Steven D'Aprano <steve@pearwood.info> wrote:

>
> Either way, vars() doesn't solve the problem. What problem does it solve?
>

I'm way out of my depth here (I normally post on Tutor, as Steve
knows), but when I looked vars() up in Lutz's "Python Pocket
Reference, 5th ed.", he ended his description of it with:  "... Hint:
useful for referring to variables in string formatting."  This is
probably something obvious to you, but I thought I'd throw it out
there in case it's of any value, since I did not see this mentioned
elsewhere in this thread.  Just trying to learn more ...


-- 
boB

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

#99846

To print or to write?

It still remains, that in December 2015 (!) a Windows
user see her/his Python 3 crashes when she/he prints/writes
something like latin characters (to take something common).

After more than 20 years of development...

I never succeded to reproduce the same behaviour with
Go, Ruby or C#.

---

More generally, I can make Python fail or crash with
any string I wish.

jmf

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

#99849

On 01.12.15 03:00, Steven D'Aprano wrote:
> I'm trying to understand why vars() exists. Does anyone use it?

I use vars() exclusively for introspection in interactive environment. 
As well as dir() and help(). Sad that it doesn't work with __slots__.

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

#99855

Dear Peter, and Steven, thanks again for engaging with my script. I'm
fully aware that this is not the tutor mailing list :)

Peter Otten wrote:
> As far as I can see in a correctly written script the AttributeError cannot 
> be triggered by the user as argparse handles this case automatically by 
> showing the help. 

This... is true. I could have sworn that's not the way argparse behaved
when I wrote that snippet, but I've been very wrong before about similar
things. Anyway my main() function looks much better now :)

> By the way, I recommend coverage.py to find dead code. I have not used
> it for too long, and I regret it ;)

I blush to confess I would first need to write a test suite. But yeah,
will do both, thanks for the recommendation.

Cheers,
Manolo

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

#99858

On Wed, Dec 2, 2015 at 7:22 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
> On 01.12.15 03:00, Steven D'Aprano wrote:
>>
>> I'm trying to understand why vars() exists. Does anyone use it?
>
>
> I use vars() exclusively for introspection in interactive environment. As
> well as dir() and help(). Sad that it doesn't work with __slots__.

Maybe the upshot of all this is a post to python-ideas recommending
that vars() grow support for __slots__ types? If it's most often used
interactively, this would make it more useful there, and it wouldn't
break backward compatibility unless there's some way that people are
depending on it raising an exception.

ChrisA

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

#99859

On Wed, Dec 2, 2015 at 8:09 PM, Manolo Martínez
<manolo@austrohungaro.com> wrote:
> Peter Otten wrote:
>> As far as I can see in a correctly written script the AttributeError cannot
>> be triggered by the user as argparse handles this case automatically by
>> showing the help.
>
> This... is true. I could have sworn that's not the way argparse behaved
> when I wrote that snippet, but I've been very wrong before about similar
> things. Anyway my main() function looks much better now :)

I would recommend not using argparse directly. Pick up a wrapper like
clize, and then define everything through docstrings.

Clize usage example:
https://github.com/Rosuav/LetMeKnow/blob/master/letmeknow.py

https://pypi.python.org/pypi/clize

ChrisA

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

#99862

On 12/02/15 at 08:33pm, Chris Angelico wrote:
> On Wed, Dec 2, 2015 at 8:09 PM, Manolo Martínez
> > This... is true. I could have sworn that's not the way argparse behaved
> > when I wrote that snippet, but I've been very wrong before about similar
> > things. Anyway my main() function looks much better now :)
> 
> I would recommend not using argparse directly. Pick up a wrapper like
> clize, and then define everything through docstrings.
> 
> Clize usage example:
> https://github.com/Rosuav/LetMeKnow/blob/master/letmeknow.py
> 
> https://pypi.python.org/pypi/clize

I try to do as much as I can with standard library tools. As a user, I
find it somewhat off-putting when a tiny project asks you to install any
number of seemingly unrelated libraries. But clize does look like a good
idea, thanks for the pointer.

Manolo

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

#99866

Manolo Martínez wrote:

> On 12/02/15 at 08:33pm, Chris Angelico wrote:
>> On Wed, Dec 2, 2015 at 8:09 PM, Manolo Martínez
>> > This... is true. I could have sworn that's not the way argparse behaved
>> > when I wrote that snippet, but I've been very wrong before about
>> > similar things. Anyway my main() function looks much better now :)
>> 
>> I would recommend not using argparse directly. Pick up a wrapper like
>> clize, and then define everything through docstrings.
>> 
>> Clize usage example:
>> https://github.com/Rosuav/LetMeKnow/blob/master/letmeknow.py
>> 
>> https://pypi.python.org/pypi/clize
> 
> I try to do as much as I can with standard library tools. As a user, I
> find it somewhat off-putting when a tiny project asks you to install any
> number of seemingly unrelated libraries. But clize does look like a good
> idea, thanks for the pointer.

Same here ;)

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

#99868

On Wed, Dec 2, 2015 at 9:48 PM, Peter Otten <__peter__@web.de> wrote:
>> I try to do as much as I can with standard library tools. As a user, I
>> find it somewhat off-putting when a tiny project asks you to install any
>> number of seemingly unrelated libraries. But clize does look like a good
>> idea, thanks for the pointer.
>
> Same here ;)

I found out about clize by developing my own module that did the same
job - and then found that, by compromising VERY slightly on some
specifics, I could turn my usage directly to clize :)

One thing I didn't want to compromise on was the simplicity of setup
that I'd had - just slap a decorator onto every function that you want
to make into a callable. So I made my own decorator that collects up
the functions. Total cost: Three lines at the top, two at the bottom
(if name is main, clize.run), and one line per function, plus the
encoded docstring. That's a LOT cheaper than argparse normally is.

ChrisA

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

#99871

On Wed, Dec 2, 2015 at 3:28 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, Dec 2, 2015 at 7:22 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
>>
>> I use vars() exclusively for introspection in interactive environment. As
>> well as dir() and help(). Sad that it doesn't work with __slots__.
>
> Maybe the upshot of all this is a post to python-ideas recommending
> that vars() grow support for __slots__ types? If it's most often used
> interactively, this would make it more useful there, and it wouldn't
> break backward compatibility unless there's some way that people are
> depending on it raising an exception.

Let vars() continue in its antediluvian ways. Maybe the standard
library could add an inspect.getdata function that returns a union of
an object's __dict__ items and data-descriptor attributes.

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

#99998

On 02.12.15 11:28, Chris Angelico wrote:
> On Wed, Dec 2, 2015 at 7:22 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
>> On 01.12.15 03:00, Steven D'Aprano wrote:
>>> I'm trying to understand why vars() exists. Does anyone use it?
>> I use vars() exclusively for introspection in interactive environment. As
>> well as dir() and help(). Sad that it doesn't work with __slots__.
> Maybe the upshot of all this is a post to python-ideas recommending
> that vars() grow support for __slots__ types? If it's most often used
> interactively, this would make it more useful there, and it wouldn't
> break backward compatibility unless there's some way that people are
> depending on it raising an exception.

It already was discussed few times. And there is even open issue for 
this: http://bugs.python.org/issue13290.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web