Re: isinstance() bug

Discussion in 'Python' started by Michal Vitecek, Jan 28, 2004.

  1. Skip Montanaro wrote:
    >You imported the module twice (look at sys.modules) so you have two
    >different A classes. I believe isinstance() uses the __class__ attribute
    >and the class's __bases__ attribute to work its way up the class chain
    >looking for a match. Even though they are defined identically, you have two
    >different A classes. An instance of one can't also be an instance of the
    >other.


    i think that if absolute path was somehow put into the classes internal
    information this inconsistency would be put away.

    it's my belief that if i'm instantiating a class from the same location
    no matter how i imported its definition, its instances are always of
    the same class.

    and as to the sys.modules thing: this could be considered as just two
    references to the same module (again its absolute path would be taken
    into account), not two different modules.

    does it make sense?

    --
    fuf ()
     
    Michal Vitecek, Jan 28, 2004
    #1
    1. Advertising

  2. Michal Vitecek

    John Roth Guest

    "Michal Vitecek" <> wrote in message
    news:...
    > Skip Montanaro wrote:
    > >You imported the module twice (look at sys.modules) so you have two
    > >different A classes. I believe isinstance() uses the __class__ attribute
    > >and the class's __bases__ attribute to work its way up the class chain
    > >looking for a match. Even though they are defined identically, you have

    two
    > >different A classes. An instance of one can't also be an instance of the
    > >other.

    >
    > i think that if absolute path was somehow put into the classes internal
    > information this inconsistency would be put away.
    >
    > it's my belief that if i'm instantiating a class from the same location
    > no matter how i imported its definition, its instances are always of
    > the same class.
    >
    > and as to the sys.modules thing: this could be considered as just two
    > references to the same module (again its absolute path would be taken
    > into account), not two different modules.
    >
    > does it make sense?


    It depends on the operating system. I think it's quite possible to
    resolve the absolute path on, for example, Windows, while it's
    not possible in the general case on, for example, Unix. If you have
    two different paths hard linked to the same file, which one is the
    "correct" path? It gets even worse if you're accessing the file from
    a file server where you may not have the least idea what the aliasing
    policies are.

    The best advice I have is the same advice I give to anyone
    who burns themselves doing something that doesn't work quite
    the way they expect: don't do that. Imports need to be considered
    thoughtfully.

    John Roth
    >
    > --
    > fuf ()
    >
     
    John Roth, Jan 28, 2004
    #2
    1. Advertising

  3. Michal Vitecek

    Peter Otten Guest

    Michal Vitecek wrote:

    > does it make sense?


    Which reminds me - why do you want to put a package directory into your
    python path in the first place?. Before spending to much effort on fixing
    the problems that this practice entails, what are the benefits?

    Peter
     
    Peter Otten, Jan 28, 2004
    #3
  4. Peter Otten wrote:
    >Which reminds me - why do you want to put a package directory into your
    >python path in the first place?. Before spending to much effort on fixing
    >the problems that this practice entails, what are the benefits?


    i never said i wanted to do it - and i don't do it. it's just i've come
    across this buggy behaviour and thought to ask/report it for other
    thoughts on the issue.

    --
    fuf ()
     
    Michal Vitecek, Jan 28, 2004
    #4
  5. Michal Vitecek

    Rainer Deyke Guest

    Michal Vitecek wrote:
    > it's my belief that if i'm instantiating a class from the same
    > location no matter how i imported its definition, its instances are
    > always of the same class.


    Your belief is incorrect. 'package.module.A' and 'module.A' are distinct
    classes. Modifications to one do not show up in the other. If 'isinstance'
    reported that an instance of 'package.module.A' is an instance of
    'module.A', 'isinstance' would be broken and unusable.


    --
    Rainer Deyke - - http://eldwood.com
     
    Rainer Deyke, Jan 28, 2004
    #5
  6. Rainer Deyke wrote:
    >Michal Vitecek wrote:
    >> it's my belief that if i'm instantiating a class from the same
    >> location no matter how i imported its definition, its instances are
    >> always of the same class.

    >
    >Your belief is incorrect. 'package.module.A' and 'module.A' are distinct
    >classes. Modifications to one do not show up in the other. If 'isinstance'
    >reported that an instance of 'package.module.A' is an instance of
    >'module.A', 'isinstance' would be broken and unusable.


    could you elaborate further why do you consider the current behaviour
    to be correct? you've only described how it works currently. i'd be
    interested what's the reasoning behind that.

    i'm inclined to think that the current behaviour is a side-effect of
    the implementation (perhaps to which some got used to?).

    --
    fuf ()
     
    Michal Vitecek, Jan 29, 2004
    #6

  7. >>> it's my belief that if i'm instantiating a class from the same
    >>> location no matter how i imported its definition, its instances are
    >>> always of the same class.


    >> Your belief is incorrect. 'package.module.A' and 'module.A' are
    >> distinct classes.


    Michal> could you elaborate further why do you consider the current
    Michal> behaviour to be correct? you've only described how it works
    Michal> currently. i'd be interested what's the reasoning behind that.

    It's not necessarily a bug. More likely it's a feature. It does what you
    expect -- if your mental model of how things work corresponds to how things
    really work. ;-)

    Michal> i'm inclined to think that the current behaviour is a
    Michal> side-effect of the implementation (perhaps to which some got
    Michal> used to?).

    Before Python had packages this sort of thing occurred much less frequently.
    If CPython's behavior was changed now (I don't know if Jython's behavior is
    the same) the change might raise subtle, hard-to-find errors. Maybe you can
    solve it by adding a shadow dictionary keyed by inode number. It would
    probably need to be exposed in sys as something like sys.module_inodes, so
    that programmers can explicitly force module deletion from the runtime. Any
    place sys.modules is tweaked sys.module_inodes would have to be as well.

    Skip
     
    Skip Montanaro, Jan 29, 2004
    #7
  8. Michal Vitecek

    Rainer Deyke Guest

    Michal Vitecek wrote:
    > Rainer Deyke wrote:
    >> Michal Vitecek wrote:
    >>> it's my belief that if i'm instantiating a class from the same
    >>> location no matter how i imported its definition, its instances are
    >>> always of the same class.

    >>
    >> Your belief is incorrect. 'package.module.A' and 'module.A' are
    >> distinct classes. Modifications to one do not show up in the other.
    >> If 'isinstance' reported that an instance of 'package.module.A' is
    >> an instance of 'module.A', 'isinstance' would be broken and unusable.

    >
    > could you elaborate further why do you consider the current behaviour
    > to be correct? you've only described how it works currently. i'd be
    > interested what's the reasoning behind that.


    'isinstance' does the only possible correct thing. Even without loading the
    same file as multiple modules, a module can create many distinct classes
    with the same name. For example:

    def create_unique_class():
    class C(object): pass
    return C

    a_bunch_of_classes = [create_unique_class() for i in range(8)]

    Treating these separate classes as a single class would be just plain wrong.

    If there's a problem with the current implementation, it is that it allows
    modules in packages to be imported as top level modules.


    --
    Rainer Deyke - - http://eldwood.com
     
    Rainer Deyke, Jan 29, 2004
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Joona I Palaste

    Re: isInstance problem

    Joona I Palaste, Jul 1, 2003, in forum: Java
    Replies:
    4
    Views:
    1,041
    George W. Cherry
    Jul 2, 2003
  2. Ben Jessel

    Re: isInstance problem

    Ben Jessel, Jul 10, 2003, in forum: Java
    Replies:
    0
    Views:
    410
    Ben Jessel
    Jul 10, 2003
  3. Michal Vitecek

    isinstance() bug

    Michal Vitecek, Jan 28, 2004, in forum: Python
    Replies:
    6
    Views:
    456
    Sidharth Kuruvila
    Jan 28, 2004
  4. Mac

    bug with isinstance() ?

    Mac, Jun 1, 2005, in forum: Python
    Replies:
    7
    Views:
    350
  5. dmitrey

    seems like a bug in isinstance()

    dmitrey, May 6, 2011, in forum: Python
    Replies:
    6
    Views:
    625
    Gregory Ewing
    May 7, 2011
Loading...

Share This Page