[Python-Dev] Alternative to more ABCs [was:] Iterable String Redux (aka String ABC)

Guido van Rossum guido at python.org
Sun Jun 1 00:29:18 CEST 2008


I'm willing to meet you halfway. I really don't want isinstance(x,
str) to return True for something that doesn't inherit from the
concrete str type; this is bound to lead to too  much confusion and
breakage. But I'm fine with a String ABC (or any other ABC, e.g.
Atomic?) that doesn't define any methods but can be used for type
testing. How about that?

--Guido

On Sat, May 31, 2008 at 5:25 AM, Raymond Hettinger <python at rcn.com> wrote:
> ISTM, the whole reason people are asking for a String ABC is so you can
> write isinstance(obj, String) and allow registered string-like objects to be
> accepted.
>
> The downside is that everytime you want this for a concrete class or type,
> it is necessary to write a whole new ABC listing all of the required
> methods.  Also, you have to change all of the client code's isinstance tests
> from concrete to abstract.
>
> I propose a simpler approach.  Provide an alternative registration function
> that overrides isinstance() so that objects can explicitly fake any concrete
> type:
>
>  s = UserString('whiffleball')
>  print isinstance(s, str)            --> False
>  register_lookalike(UserString, str)
>  print isinstance(s, str)            --> True
>
> Besides saving us from writing tons of new ABCs, the approach works with
> existing code that already uses isinstance() with concrete types.
>
> The ABCs that would remain are ones that are truly abstract, that define a
> generic interface (like mappings and sequences) and ones that offer some
> useful mixin behavior.  The remaining ABCs are ones where you have a
> fighting chance of actually being able to implement the interface (unlike
> String where it would be darned tricky to fully emulate encode(), split(),
> etc.)
>
> This would completely eliminate the need for numbers.Integral for example.
>  AFAICT, its sole use case is to provide a way for numeric's integral types
> (like int8, int32) to pass themselves off as having the same API as regular
> ints.  Unfortunately, the current approach requires all consumer code to
> switch from isinstance(x,int) to isinstance(x,Integral).  It would be more
> useful if we could simply write register_lookalike(x,int) and be done with
> it (no need for numbers.py and its attendant abc machinery).
>
> If we don't do this, then String won't be the last request.  People will
> want Datetime for example.  Pretty much any concrete type could have a
> look-a-like that wanted its own ABC and for all client code to switch from
> testing concrete types.
>
>
> Raymond
>
>
>
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list