Leo added the comment: The idea was based on a misunderstanding of the typename argument. I had erroneously inferred that the namedtuple class object would be bound to some namespace whereas the only binding is achieved by the assignment to a local name which may be different from the typename. And typename can probably even be an empty string.
I agree that the oddities shown in the two code examples are just an example of a misuse of the freedom a dynamic language grants. Rereading the docs on nametuple, I think a clarification on the purpose and proper use of typename might be in order. Most people have been declaring classes for many years using the class statement. This implicitly binds the class name to the current namespace. This is why I was mislead. Thanks for the helpful feedback. Leo On 06/10/2014, Mark Dickinson <rep...@bugs.python.org> wrote: > > Mark Dickinson added the comment: > > Right; the underlying problem of having objects that appear to be instances > of the wrong class has nothing to do with namedtuples. After this > sequence: > >>>> class A: pass > ... >>>> a = A() >>>> >>>> class A: pass > ... > > We get the following somewhat confusing results: > >>>> type(a) > <class '__main__.A'> >>>> A > <class '__main__.A'> >>>> isinstance(a, A) > False > > Class factories like namedtuple make it somewhat easier to run into this > issue, but it's nothing really to do with namedtuple itself, and it's not > something that could be "fixed" without significant language redesign. > > ---------- > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue22563> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22563> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
