creating class objects inside methods

[Carl Banks]

On Oct 3, 11:45 pm, horos11 <horo... at gmail.com> wrote:
> > It's not a bug.  In Python classes and global variables share the same
> > namespace.
>
> > Don't you think you should learn a bit more about how Python manages
> > objects and namespaces before going around calling things bugs?
>
> > Carl Banks
>
> No, I don't think so..
>
> Say you went to another country, where the people wore lead shoes,
> hence not only going slower, but getting lead poisoning from time to
> time.
>
> Pointing out that shoes made of fabric might just be better should not
> be heresy.

This analogy is wrong on two counts:

1. Pointing out that the "fabric might be better" is not analogous to
what you did.  You claimed that Python's behavior was a bug, which
would be analogous to me saying, "lead shoes should be illegal".

2. I know enough about the properties of fabric and lead to make an
informed complaint over the use of lead for shoes, even if I am new to
the country.   However you very clearly have a poor understanding of
Python's namespace and object models, and so you have little standing
to claim that Python is buggy in how it treats its namespaces.

I'd say the strongest claim you have grounds to make, given the level
of understanding you've shown, is "this is very confusing to noobs".

BTW, the Python maintainers are very particular to define "bug" as
"Python behaves differently than it is documentated to", and Python is
most definitely documented as acting the way it does.


> In this case, I think the overall goal was syntax simplicity, but it
> sure as hell makes things confusing. No warning, or anything. The sane
> behavior IMO would be to disallow the assignment unless put through a
> special function, something like:
>
> class(state) = ...
> After all, python does have a precedent when you try to join, when:
>
> ":".join([1,2])
>
> does not work because [1,2] is an array of ints, whereas
>
> ":" . join( str(x) for x in [1,2])
>
> does.

No, it really isn't a precedent.  Yes, Python does type-checking quite
a bit, however there is no precedent at all for customizing assignment
to a regular variable.  When you write "a = b", a gets bound to the
same object as b is bound to, end of story.  You can't customize it,
you can't prevent it, you can hook into it, and neither object is
notified that an assignment is happening.  This is true even if a or b
happen to be a class.

And if you say, "Well you should be able to customize assigment", my
answer is, "You were saying there was a precedent, I said there was
not".  If you want to argue that it should be possible to customize
assignment, be my guest, but you'll have to do it without the benefit
of a precedent.

(You can customize assignment to an attribute or item, but that is not
what we're talking about, especially since classes are hardly ever
attributes or items.)


Carl Banks