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 <report@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 <report@bugs.python.org>
> <http://bugs.python.org/issue22563>
> _______________________________________
>