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

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

can't add variables to instances of built-in classes

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

Contents

  can't add variables to instances of built-in classes Kent Tong <kent.tong.mo@gmail.com> - 2016-07-17 03:57 -0700
    Re: can't add variables to instances of built-in classes Peter Otten <__peter__@web.de> - 2016-07-17 13:40 +0200
      Re: can't add variables to instances of built-in classes Wilson Ong <wilsonokw@gmail.com> - 2016-07-17 04:50 -0700
        Re: can't add variables to instances of built-in classes Chris Angelico <rosuav@gmail.com> - 2016-07-17 22:02 +1000
        Re: can't add variables to instances of built-in classes Steven D'Aprano <steve@pearwood.info> - 2016-07-18 01:04 +1000
          Re: can't add variables to instances of built-in classes Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-17 20:00 -0700
            Re: can't add variables to instances of built-in classes Peter Otten <__peter__@web.de> - 2016-07-18 09:38 +0200
              Re: can't add variables to instances of built-in classes Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-18 14:48 -0700
                Re: can't add variables to instances of built-in classes breamoreboy@gmail.com - 2016-07-18 16:12 -0700
                  Re: can't add variables to instances of built-in classes Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-18 19:53 -0700
                    Re: can't add variables to instances of built-in classes breamoreboy@gmail.com - 2016-07-19 14:24 -0700
                      Re: can't add variables to instances of built-in classes Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-19 16:58 -0700
                        Re: can't add variables to instances of built-in classes Chris Angelico <rosuav@gmail.com> - 2016-07-20 16:19 +1000
                          Re: can't add variables to instances of built-in classes Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-19 23:45 -0700
                            Re: can't add variables to instances of built-in classes Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-07-20 17:22 +1000
                            Re: can't add variables to instances of built-in classes Peter Otten <__peter__@web.de> - 2016-07-20 09:26 +0200
                              Re: can't add variables to instances of built-in classes Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-20 01:50 -0700
                                Re: can't add variables to instances of built-in classes Peter Otten <__peter__@web.de> - 2016-07-20 11:15 +0200
                                  Re: can't add variables to instances of built-in classes Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-20 15:11 -0700
                                    Re: can't add variables to instances of built-in classes Chris Angelico <rosuav@gmail.com> - 2016-07-21 12:29 +1000
                                      Re: can't add variables to instances of built-in classes Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-08-03 19:34 -0700
                                        Re: can't add variables to instances of built-in classes Chris Angelico <rosuav@gmail.com> - 2016-08-04 13:00 +1000
                                          Re: can't add variables to instances of built-in classes Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-08-04 16:57 -0700
                                    Re: can't add variables to instances of built-in classes Steven D'Aprano <steve@pearwood.info> - 2016-07-21 12:48 +1000
                                Re: can't add variables to instances of built-in classes Steven D'Aprano <steve@pearwood.info> - 2016-07-20 22:10 +1000
                                  Re: can't add variables to instances of built-in classes Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-20 14:48 -0700
                                    Re: can't add variables to instances of built-in classes breamoreboy@gmail.com - 2016-07-20 18:04 -0700
                                      Re: can't add variables to instances of built-in classes Peter Otten <__peter__@web.de> - 2016-07-21 08:59 +0200
                Re: can't add variables to instances of built-in classes Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-20 02:10 -0700
        Re: can't add variables to instances of built-in classes Ethan Furman <ethan@stoneleaf.us> - 2016-07-18 06:10 -0700
    Re: can't add variables to instances of built-in classes Kent Tong <kent.tong.mo@gmail.com> - 2016-07-17 04:53 -0700

Page 1 of 2  [1] 2  Next page →

#111567 — can't add variables to instances of built-in classes

Hi,

I can add new variables to user-defined classes like:

>>> class Test:
...     pass
... 
>>> a=Test()
>>> a.x=100

but it doesn't work if the instances belong to a built-in class such as str or list:

>>> a='abc'
>>> a.x=100
 Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
 AttributeError: 'str' object has no attribute 'x'

What makes this difference?

Thanks in advance!

[toc] | [next] | [standalone]

#111570

Kent Tong wrote:

> Hi,
> 
> I can add new variables to user-defined classes like:
> 
>>>> class Test:
> ...     pass
> ...
>>>> a=Test()
>>>> a.x=100
> 
> but it doesn't work if the instances belong to a built-in class such as
> str or list:
> 
>>>> a='abc'
>>>> a.x=100
>  Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>  AttributeError: 'str' object has no attribute 'x'
> 
> What makes this difference?

By default custom classes have a dictionary (called __dict__) to hold these 
attributes. If for every string or integer there were such a dict that would 
waste a lot of memory. You can subclass if you need it:

>>> class Str(str): pass
... 
>>> s = Str("hello")
>>> s.x = 42
>>> s
'hello'
>>> s.x
42

You can also avoid the dict in your own classes by specifiying slots for 
allowed attributes:

>>> class Test:
...     __slots__ = ("foo", "bar")
... 
>>> t = Test()
>>> t.foo = 42
>>> t.baz = "whatever"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Test' object has no attribute 'baz'

Use this feature sparingly, only when you know that there are going to be 
many (millions rather than thousands) of Test instances.

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

#111571

> Use this feature sparingly, only when you know that there are going to be 
> many (millions rather than thousands) of Test instances.

Why use it sparingly? Is it for extensibility? What if I'm pretty sure that my class is going to have exactly these attributes only?

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

#111574

On Sun, Jul 17, 2016 at 9:50 PM, Wilson Ong <wilsonokw@gmail.com> wrote:
>> Use this feature sparingly, only when you know that there are going to be
>> many (millions rather than thousands) of Test instances.
>
> Why use it sparingly? Is it for extensibility? What if I'm pretty sure that my class is going to have exactly these attributes only?

"Pretty sure" isn't enough justification for a relatively meagre
saving of memory. Much easier to leave it flexible. It's only once the
memory saving stops being "relatively meagre" (for instance, with the
built-in 'str' type - there are a LOT of strings in a Python program,
since your variable names are stored as strings) that it's worth doing
that.

ChrisA

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

#111580

On Sun, 17 Jul 2016 09:50 pm, Wilson Ong wrote:

> 
>> Use this feature sparingly, only when you know that there are going to be
>> many (millions rather than thousands) of Test instances.
> 
> Why use it sparingly? Is it for extensibility? What if I'm pretty sure
> that my class is going to have exactly these attributes only?

It's your own code, you can do anything you like, its not like the Python
Police will come and arrest you.

But *best practice* is for instances to have a __dict__, which allows them
to have instance attributes. Python code expects to be able to inspect, and
write to, the instance __dict__, and if you don't have one, you may break
code that doesn't expect it.

But it is not a hard rule, just a strong recommendation. There are
exceptions. Most built-ins don't have __dict__, partly as an optimization,
and partly to allow sharing of builtins across sub-interpreters;

__slots__ was specifically invented so that classes created in Python could
avoid creating a per-instance __dict__, for cases where you expect to have
vast numbers of instances with only a fixed number of attributes. In this
case, having an unused __dict__ can be wasteful.

But note that in recent versions of Python, there is less need to use
__slots__, and a much smaller benefit. The reason is that the instance
dicts can now share storage for their keys.

https://www.python.org/dev/peps/pep-0412/

__slots__ is not obsolete, but 99% of the time you shouldn't bother with it.



-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

#111587

On Monday, July 18, 2016 at 3:04:13 AM UTC+12, Steven D'Aprano wrote:

> __slots__ is not obsolete, but 99% of the time you shouldn't bother with it.

I find __slots__ very useful. I have them right through my Qahirah classes <https://github.com/ldo/qahirah>, for example.

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

#111595

Lawrence D’Oliveiro wrote:

> On Monday, July 18, 2016 at 3:04:13 AM UTC+12, Steven D'Aprano wrote:
> 
>> __slots__ is not obsolete, but 99% of the time you shouldn't bother with
>> it.
> 
> I find __slots__ very useful. I have them right through my Qahirah classes
> <https://github.com/ldo/qahirah>, for example.

When you remove them, does your library stop working? Is there a significant 
increase of memory consumption? Or is there something I didn't think of that 
makes them useful for you?

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

#111616

On Monday, July 18, 2016 at 7:39:09 PM UTC+12, Peter Otten wrote:
> Lawrence D’Oliveiro wrote:
> 
>> I find __slots__ very useful. I have them right through my Qahirah classes
>> <https://github.com/ldo/qahirah>, for example.
> 
> Or is there something I didn't think of that makes them useful for you?

When you have lots of read/write properties, I find __slots__ to be a good idea.

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

#111617

On Monday, July 18, 2016 at 10:48:15 PM UTC+1, Lawrence D’Oliveiro wrote:
> On Monday, July 18, 2016 at 7:39:09 PM UTC+12, Peter Otten wrote:
> > Lawrence D’Oliveiro wrote:
> > 
> >> I find __slots__ very useful. I have them right through my Qahirah classes
> >> <https://github.com/ldo/qahirah>, for example.
> > 
> > Or is there something I didn't think of that makes them useful for you?
> 
> When you have lots of read/write properties, I find __slots__ to be a good idea.

Please explain why, thank you.

Kindest regards.

Mark Lawrence.

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

#111620

On Tuesday, July 19, 2016 at 11:12:52 AM UTC+12, bream...@gmail.com wrote:
>
> On Monday, July 18, 2016 at 10:48:15 PM UTC+1, Lawrence D’Oliveiro wrote:
>>
>> <https://github.com/ldo/qahirah>
>> When you have lots of read/write properties, I find __slots__ to be a good
>> idea.
> 
> Please explain why, thank you.

I was trying something like

    ctx.dashes = ((0.1, 0.03, 0.03, 0.03), 0)

and wondering why it wasn’t working...

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

#111646

On Tuesday, July 19, 2016 at 3:54:12 AM UTC+1, Lawrence D’Oliveiro wrote:
> On Tuesday, July 19, 2016 at 11:12:52 AM UTC+12, bream...@gmail.com wrote:
> >
> > On Monday, July 18, 2016 at 10:48:15 PM UTC+1, Lawrence D’Oliveiro wrote:
> >>
> >> <https://github.com/ldo/qahirah>
> >> When you have lots of read/write properties, I find __slots__ to be a good
> >> idea.
> > 
> > Please explain why, thank you.
> 
> I was trying something like
> 
>     ctx.dashes = ((0.1, 0.03, 0.03, 0.03), 0)
> 
> and wondering why it wasn’t working...

This makes no sense to me at all.  You appear to be trying to create a tuple, which contains a tuple and an integer.  You then say it doesn't work, but imply that using __slots__ fixes the problem.  So please explain exactly what you were trying to achieve, the exact error you got, with the complete traceback, and how using __slots__ fixed the problem.

Cheers.

Mark Lawrence.

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

#111653

On Wednesday, July 20, 2016 at 9:24:57 AM UTC+12, bream...@gmail.com wrote:
>
> On Tuesday, July 19, 2016 at 3:54:12 AM UTC+1, Lawrence D’Oliveiro wrote:
>>
>> On Tuesday, July 19, 2016 at 11:12:52 AM UTC+12, bream...@gmail.com wrote:
>>>
>>> On Monday, July 18, 2016 at 10:48:15 PM UTC+1, Lawrence D’Oliveiro wrote:
>>>>
>>>> <https://github.com/ldo/qahirah>
>>>> When you have lots of read/write properties, I find __slots__ to be a
>>>> good idea.
>>> 
>>> Please explain why, thank you.
>> 
>> I was trying something like
>> 
>>     ctx.dashes = ((0.1, 0.03, 0.03, 0.03), 0)
>> 
>> and wondering why it wasn’t working...
> 
> This makes no sense to me at all.  You appear to be trying to create a
> tuple, which contains a tuple and an integer.  You then say it doesn't
> work, but imply that using __slots__ fixes the problem.  So please explain
> exactly what you were trying to achieve, the exact error you got, with the
> complete traceback, and how using __slots__ fixed the problem.

No traceback. The lines were simply coming out solid, instead of dashed.

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

#111659

On Wed, Jul 20, 2016 at 9:58 AM, Lawrence D’Oliveiro
<lawrencedo99@gmail.com> wrote:
> On Wednesday, July 20, 2016 at 9:24:57 AM UTC+12, bream...@gmail.com wrote:
>>
>> On Tuesday, July 19, 2016 at 3:54:12 AM UTC+1, Lawrence D’Oliveiro wrote:
>>>
>>> On Tuesday, July 19, 2016 at 11:12:52 AM UTC+12, bream...@gmail.com wrote:
>>>>
>>>> On Monday, July 18, 2016 at 10:48:15 PM UTC+1, Lawrence D’Oliveiro wrote:
>>>>>
>>>>> <https://github.com/ldo/qahirah>
>>>>> When you have lots of read/write properties, I find __slots__ to be a
>>>>> good idea.
>>>>
>>>> Please explain why, thank you.
>>>
>>> I was trying something like
>>>
>>>     ctx.dashes = ((0.1, 0.03, 0.03, 0.03), 0)
>>>
>>> and wondering why it wasn’t working...
>>
>> This makes no sense to me at all.  You appear to be trying to create a
>> tuple, which contains a tuple and an integer.  You then say it doesn't
>> work, but imply that using __slots__ fixes the problem.  So please explain
>> exactly what you were trying to achieve, the exact error you got, with the
>> complete traceback, and how using __slots__ fixed the problem.
>
> No traceback. The lines were simply coming out solid, instead of dashed.

And __slots__ fixed the problem how, exactly? This sounds like the
sort of cargo cult debugging that I'd expect of PHP programmers ("I
put addslashes around everything and now it works, so in future I'll
use addslashes everywhere"), but around here, we're better than that.

ChrisA

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

#111660

On Wednesday, July 20, 2016 at 6:19:45 PM UTC+12, Chris Angelico wrote:
>
> On Wed, Jul 20, 2016 at 9:58 AM, Lawrence D’Oliveiro wrote:
>>
>> On Wednesday, July 20, 2016 at 9:24:57 AM UTC+12, bream...@gmail.com wrote:
>>>
>>> On Tuesday, July 19, 2016 at 3:54:12 AM UTC+1, Lawrence D’Oliveiro wrote:
>>>>
>>>> On Tuesday, July 19, 2016 at 11:12:52 AM UTC+12, bream...@gmail.com
>>>> wrote:
>>>>>
>>>>> On Monday, July 18, 2016 at 10:48:15 PM UTC+1, Lawrence D’Oliveiro
>>>>> wrote:
>>>>>>
>>>>>> <https://github.com/ldo/qahirah>
>>>>>> When you have lots of read/write properties, I find __slots__ to be a
>>>>>> good idea.
>>>>>
>>>>> Please explain why, thank you.
>>>>
>>>> I was trying something like
>>>>
>>>>     ctx.dashes = ((0.1, 0.03, 0.03, 0.03), 0)
>>>>
>>>> and wondering why it wasn’t working...
>>>
>>> This makes no sense to me at all.  You appear to be trying to create a
>>> tuple, which contains a tuple and an integer.  You then say it doesn't
>>> work, but imply that using __slots__ fixes the problem.  So please explain
>>> exactly what you were trying to achieve, the exact error you got, with the
>>> complete traceback, and how using __slots__ fixed the problem.
>>
>> No traceback. The lines were simply coming out solid, instead of dashed.
> 
> And __slots__ fixed the problem how, exactly?

The Context attribute that controls the dash settings is called “dash”, not “dashes”.

> This sounds like the sort of cargo cult debugging that I'd expect of PHP
> programmers ("I put addslashes around everything and now it works, so in
> future I'll use addslashes everywhere"), but around here, we're better than
> that.

OK, boss.

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

#111663

On Wednesday 20 July 2016 16:45, Lawrence D’Oliveiro wrote:

>>>>> I was trying something like
>>>>>
>>>>>     ctx.dashes = ((0.1, 0.03, 0.03, 0.03), 0)
>>>>>
>>>>> and wondering why it wasn’t working...

And so are we. Since you've already solved the problem, maybe you could 
enlighten us?

>>>> This makes no sense to me at all.  You appear to be trying to create a
>>>> tuple, which contains a tuple and an integer.  You then say it doesn't
>>>> work, but imply that using __slots__ fixes the problem.  So please explain
>>>> exactly what you were trying to achieve, the exact error you got, with the
>>>> complete traceback, and how using __slots__ fixed the problem.
>>>
>>> No traceback. The lines were simply coming out solid, instead of dashed.
>> 
>> And __slots__ fixed the problem how, exactly?
> 
> The Context attribute that controls the dash settings is called “dash”, not
> “dashes”.

Ah, finally, an actually *useful* reply. Honestly Lawrence, couldn't you have 
just said this right at the start, instead of having us drag the answer out of 
you over multiple email exchanges?

If you had said right at the beginning "I have a habit of mistyping attribute 
names, and using __slots__ ensures I get an immediate error" then we would have 
understood you. Instead, you waste our time, *and yours*, leading us up the 
garden path by implying that you fixed a display bug by changing something 
like:

class Context(object):
    def __init__(self):
        self.dashes = something

to:

class Context(object):
    __slots__ = ("dashes",)
    def __init__(self):
        self.dashes = something

Perhaps now you understand why you gave us the impression of cargo-cult 
debugging.




-- 
Steve

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

#111665

Lawrence D’Oliveiro wrote:

> On Wednesday, July 20, 2016 at 6:19:45 PM UTC+12, Chris Angelico wrote:
>>
>> On Wed, Jul 20, 2016 at 9:58 AM, Lawrence D’Oliveiro wrote:
>>>
>>> On Wednesday, July 20, 2016 at 9:24:57 AM UTC+12, bream...@gmail.com
>>> wrote:
>>>>
>>>> On Tuesday, July 19, 2016 at 3:54:12 AM UTC+1, Lawrence D’Oliveiro
>>>> wrote:
>>>>>
>>>>> On Tuesday, July 19, 2016 at 11:12:52 AM UTC+12, bream...@gmail.com
>>>>> wrote:
>>>>>>
>>>>>> On Monday, July 18, 2016 at 10:48:15 PM UTC+1, Lawrence D’Oliveiro
>>>>>> wrote:
>>>>>>>
>>>>>>> <https://github.com/ldo/qahirah>
>>>>>>> When you have lots of read/write properties, I find __slots__ to be
>>>>>>> a good idea.
>>>>>>
>>>>>> Please explain why, thank you.
>>>>>
>>>>> I was trying something like
>>>>>
>>>>>     ctx.dashes = ((0.1, 0.03, 0.03, 0.03), 0)
>>>>>
>>>>> and wondering why it wasn’t working...
>>>>
>>>> This makes no sense to me at all.  You appear to be trying to create a
>>>> tuple, which contains a tuple and an integer.  You then say it doesn't
>>>> work, but imply that using __slots__ fixes the problem.  So please
>>>> explain exactly what you were trying to achieve, the exact error you
>>>> got, with the complete traceback, and how using __slots__ fixed the
>>>> problem.
>>>
>>> No traceback. The lines were simply coming out solid, instead of dashed.
>> 
>> And __slots__ fixed the problem how, exactly?
> 
> The Context attribute that controls the dash settings is called “dash”,
> not “dashes”.
> 
>> This sounds like the sort of cargo cult debugging that I'd expect of PHP
>> programmers ("I put addslashes around everything and now it works, so in
>> future I'll use addslashes everywhere"), but around here, we're better
>> than that.
> 
> OK, boss.

pylint can detect candidates for accidental attribute creation:

$ cat attrib.py
class Context:
    def __init__(self):
        self.dashes = None

ctx = Context()
ctx.dasehs = ("foo", "bar")
$ pylint attrib | grep dasehs
W:  6, 4: Attribute 'dasehs' defined outside __init__ (attribute-defined-
outside-init)

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

#111666

On Wednesday, July 20, 2016 at 7:26:36 PM UTC+12, Peter Otten wrote:

> pylint can detect candidates for accidental attribute creation:

And __slots__ will prevent them outright.

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

#111668

Lawrence D’Oliveiro wrote:

> On Wednesday, July 20, 2016 at 7:26:36 PM UTC+12, Peter Otten wrote:
> 
>> pylint can detect candidates for accidental attribute creation:
> 
> And __slots__ will prevent them outright.

And attributes added intentionally.

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

#111684

On Wednesday, July 20, 2016 at 9:16:30 PM UTC+12, Peter Otten wrote:
>
> Lawrence D’Oliveiro wrote:
> 
>> On Wednesday, July 20, 2016 at 7:26:36 PM UTC+12, Peter Otten wrote:
>> 
>>> pylint can detect candidates for accidental attribute creation:
>> 
>> And __slots__ will prevent them outright.
> 
> And attributes added intentionally.

You mean, being able to dynamically add new attributes to an object?

Probably not a good idea to mix that with read/write properties...

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

#111688

On Thu, Jul 21, 2016 at 8:11 AM, Lawrence D’Oliveiro
<lawrencedo99@gmail.com> wrote:
> On Wednesday, July 20, 2016 at 9:16:30 PM UTC+12, Peter Otten wrote:
>>
>> Lawrence D’Oliveiro wrote:
>>
>>> On Wednesday, July 20, 2016 at 7:26:36 PM UTC+12, Peter Otten wrote:
>>>
>>>> pylint can detect candidates for accidental attribute creation:
>>>
>>> And __slots__ will prevent them outright.
>>
>> And attributes added intentionally.
>
> You mean, being able to dynamically add new attributes to an object?
>
> Probably not a good idea to mix that with read/write properties...

This is exactly what Steven was talking about. If you can't handle
dynamic read-write attributes (whether they're properties or simple
attributes is orthogonal to this), why even use Python? You can get a
linter to tell you about misspelled attribute names, which has a huge
advantage over __slots__ in that it can give you the information prior
to actually hitting that line of code (prior to even running the
program - and some editors have integrated linters, so you don't even
need to consciously run the linter, you just see the results as you
type). That gives you virtually the same benefit as C/Java style of
coding, where you're forced to declare all your members in the class;
but as an added bonus, you can *dynamically add attributes*! Don't
think that's useful? Well, the other day I wanted to add a wrapper
around the constructor for someone else's object to stash a bit of
extra information into it (to track down a resource leak - turned out
there was an ever-growing collection of objects, because they weren't
being removed from that object), and if I'd been using Java, the
response would have been "no way does that even make sense". Thanks to
dynamic code, I could do what I needed to and track down the leak. If
the author of that object had used __slots__, though, I'd have been
utterly stuck.

Using __slots__ basically takes your object down to the level of a
Java one. That's generally fine for something immutable (you really
don't need to be adding attributes to the integer 42), but even with
immutables, I've sometimes wanted to add hidden attributes; with
mutable objects, it's common enough that you want to leave the option
open unless you have good reason not to. And "my editor sucks" is not
a good reason; nor is "my debugging skills suck".

ChrisA

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web