aleax at aleax.it
Fri Jan 31 08:15:52 CET 2003
On Friday 31 January 2003 04:36 am, Christian Tismer wrote:
> Besides th fact that I believe strings as sequences
> should be deprecated, since nobody makes use of it,
This is an overbid, IMHO: some (small) fraction of the time,
say 10%, I'm quite happy that strings are sequences for
looping purposes; and far more often than that, for purposes
of slicing, concatenation, repetition. Deprecation can maybe
be mooted for Python 3.0, of course, but no earlier.
> but everybody fights it...
In the relatively-rare case where I need to _distinguish_
between sequences and non-sequences, then it's indeed
more often the case that I want strings to be atoms. But
the need to draw such distinctions is not exactly an
everyday task, anyway -- hardly worth something as
drastic as deprecating strings' sequence status, IMHO,
unless many more use-cases can be collected.
> ... I can't see the relevance of UserString.
> Wasn't getting rid of UserAnything one of the reasons
> for the introduction of the unified type/class system?
You may think that about the UserList module (though
one might find counter-arguments), but I think it's clearly
off-base for UserString -- how is inheritance going to
give you *mutable* strings, for example?
> UserString is only a compatibility module, IMHO.
M own HO differs. The *ability* to inherit built-ins must
not turn into a *constraint* that you _have_ to inherit from
built-ins, even *without* using your base class's data
and method machinery (for example, you couldn't use
them to develop a mutable-string). This would confuse
the role of inheritance as a code-reuse device with the
role of inheritance as a "type-tag" (a common enough
confusion, to be sure, but still a deleterious one).
In other words, there's still a space for the idiom "wrap
and delegate", and even for reimplementation without
even any wrapping. It's a narrower space than it was
up to 2.1, when inheritance from built-ins wasn't allowed,
because now if you're HAPPY to get the base class's
data and machinery inheritance becomes natural -- but
too often you DON'T want to get them, though you DO
want to "be usable interchangeably with". Forcing you
to inherit implementation (and then override it all) in
order to get polymorphic substitutability would be BAD.
> But maybe we could simplify matters by providing something
> like a stringlike() inquiry function.
One more special case? Sure, that's what I proposed as
isstringlike. But then do you also want isfilelike, isdictlike,
etc, for other such cases? Protocol adaptation (the PEP
that refuses to die...) would be the right general framework
to use for framing all of such issues, IMHO.
> Strings being seen as sequences always have been a PITA
> for me, especially in user argument lists vs non lists.
If we were designing a Python-like language from scratch I
might agree (perhaps strings could be non-iterable but still
sliceable etc, for example, and an iterator might be gotten
by some explicit call to e.g. an .iter() method for those rare
instances where it's needed). But in terms of modifications
to the existing Python language, I'm just not sure this issue
is compelling enough to be worth any modification.
More information about the Python-list