On Oct 3, 11:45 pm, horos11 <horo...@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 -- http://mail.python.org/mailman/listinfo/python-list
