Guido van Rossum wrote:
There are quite a few core APIs that accept no
substitutes, and being an instance of basestring was intended to
guarantee that a value is accepted by such APIs.
In that case, the idea of a user-defined string class
that doesn't inherit from str or unicode seems to be
a l
On Sun, Jun 1, 2008 at 3:54 AM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> The use case that was cited was recognising subclasses of
> UserString, and that's what I was responding to. If
> basestring were made subclassable and UserString inherited
> from it, that use case would be covered.
UserString
Armin Ronacher wrote:
basestring is not subclassable for example. Also it requires subclassing
which ABCs do not.
The use case that was cited was recognising subclasses of
UserString, and that's what I was responding to. If
basestring were made subclassable and UserString inherited
from it, t
Steven D'Aprano schrieb:
but also does it provide a very cool way to get custom
sets or lists going with few extra work. Subclassing builtins was
always very painful in the past
"Always" very painful?
class ListWithClear(list):
def clear(self):
self[:] = self.__class__()
Not so
On Sat, 31 May 2008 12:48:41 am Armin Ronacher wrote:
> Greg Ewing canterbury.ac.nz> writes:
> > Well, I'm skeptical about the whole ABC thing in the
> > first place -- it all seems very unpythonic to me.
>
> I think it's very pythonic and the very best solution to interfaces
> *and* duck typing.
Michael Foord wrote:
I would be strongly +1 on a string ABC. Currently (to my knowledge)
there is no way of using duck typing for built-in APIs that expect a
string. How do I pass in an object to 'open' for example that isn't
actually a string or subclass?
Implement the character buffer API,
Armin Ronacher wrote:
Greg Ewing canterbury.ac.nz> writes:
Well, I'm skeptical about the whole ABC thing in the
first place -- it all seems very unpythonic to me.
I think it's very pythonic and the very best solution to interfaces *and*
duck typing. Not only does it extend duck-typin
Greg Ewing canterbury.ac.nz> writes:
> Well, I'm skeptical about the whole ABC thing in the
> first place -- it all seems very unpythonic to me.
I think it's very pythonic and the very best solution to interfaces *and*
duck typing. Not only does it extend duck-typing in a very, very cool way
but
Georg Brandl wrote:
Greg Ewing schrieb:
A better solution to that might be to have UserString
inherit from basestring.
But with that argument you could throw out the whole ABC machinery,
just let all lists inherit from list, all dicts from dict, etc.
Well, I'm skeptical about the whole ABC
Greg Ewing schrieb:
Georg Brandl wrote:
Greg Ewing schrieb:
>
Doesn't isinstance(x, basestring) already cover that?
That doesn't cover UserString, for example.
A better solution to that might be to have UserString
inherit from basestring.
But with that argument you could throw out the w
Georg Brandl wrote:
Greg Ewing schrieb:
>
Doesn't isinstance(x, basestring) already cover that?
That doesn't cover UserString, for example.
A better solution to that might be to have UserString
inherit from basestring.
--
Greg
___
Python-Dev mail
Mike Klaas wrote:
I agree that it would be perverse to disallowing iterating over a
string.
Just to be clear, I'm saying that it would be perverse
to disallow iterating *but* to allow indexing of
individual characters. Either you should have both or you
should have neither.
--
Greg
Greg Ewing schrieb:
Bill Janssen wrote:
Look, even if there were *no* additional methods, it's worth adding
the base class, just to differentiate the class from the Sequence, as
a marker, so that those of us who want to ask "isinstance(o, String)"
can do so.
Doesn't isinstance(x, basestring)
On 28-May-08, at 5:44 PM, Greg Ewing wrote:
Mike Klaas wrote:
In my perfect world, strings would be indicable and sliceable, but
not iterable.
An object that was indexable but not iterable would
be a very strange thing. If it has __len__ and __getitem__,
there's nothing to stop you iterat
Mike Klaas wrote:
In my perfect world, strings would be indicable and sliceable, but not
iterable.
An object that was indexable but not iterable would
be a very strange thing. If it has __len__ and __getitem__,
there's nothing to stop you iterating over it by hand
anyway, so disallowing __ite
Bill Janssen wrote:
Look, even if there were *no* additional methods, it's worth adding
the base class, just to differentiate the class from the Sequence, as
a marker, so that those of us who want to ask "isinstance(o, String)"
can do so.
Doesn't isinstance(x, basestring) already cover that?
On 28-May-08, at 2:33 PM, Bill Janssen wrote:
From what's been discussed so far, I don't see any advantage
of isinstance(o, String) over hasattr(o, 'encode') or somesuch.
Look, even if there were *no* additional methods, it's worth adding
the base class, just to differentiate the class from
> >>> I'm not against this, but so far I've not been able to come up with a
> >>> good set of methods to endow the String ABC with.
> >>
> >> If we stay minimalistic we could consider that the three basic operations
> >> that
> >> define a string are:
> >> - testing for substring containment
> >>
I'm not against this, but so far I've not been able to come up with a
good set of methods to endow the String ABC with.
If we stay minimalistic we could consider that the three basic operations that
define a string are:
- testing for substring containment
- splitting on a substring into a list o
On 27/05/2008, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Conceptually, this is a fine idea, but three things bug me.
>
> First, there is a mismatch between the significance of the problem
> being addressed versus the weight of the solution.
Agreed, absolutely.
> Second, this seems like the w
Armin Ronacher wrote:
Basically *the* problematic situation with iterable strings is something like
a `flatten` function that flattens out every iterable object except of strings.
To flesh out the span of your "something like", recently I had a WSGI-based app
that to some request mistakenly r
"Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Just throwing a suggestion out there...
def atomic(obj, _atomic=(basestring,)):
try:
return bool(obj.__atomic__)
except AttributeError:
if isinstance(obj, _atomic):
return True
Steven D'Aprano" <[EMAIL PROTECTED]>
If built-in objects grew an __atomic__ attribute, you could
simplify the atomic() function greatly:
I may not have been clear enough in my previous post.
Atomicity is not an intrinsic property of an object or class.
How could you know in advance what various
(If you receive this twice, please excuse the duplicate email.
User-error on my part, sorry.)
On Wed, 28 May 2008 08:23:38 am Raymond Hettinger wrote:
> A flatten() implementation doesn't really care about whether
> an input is a string which supports all the string-like methods
> such as capita
"Armin Ronacher" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Basically *the* problematic situation with iterable strings is something
like
| a `flatten` function that flattens out every iterable object except of
strings.
In most real cases I can imagine, this is way too broad
[Armin Ronacher]
Basically *the* problematic situation with iterable strings is something like
a `flatten` function that flattens out every iterable object except of strings.
Stated more generally: The problematic situation is that flatten()
implementations typically need some way to decide wh
Georg Brandl gmx.net> writes:
> You wrote:
>
> > If we stay minimalistic we could consider that the three basic
operations that
> > define a string are:
> > - testing for substring containment
> > - splitting on a substring into a list of substrings
> > - slicing in order to extract a substr
Antoine Pitrou schrieb:
Georg Brandl gmx.net> writes:
It does, but I don't see how it contradicts my proposition. find() takes a
substring as well.
Well, I'm not sure what your proposal was :-)
Did you mean to keep split() out of the String interface, or to provide a
default implementation o
Georg Brandl gmx.net> writes:
>
> It does, but I don't see how it contradicts my proposition. find() takes a
> substring as well.
Well, I'm not sure what your proposal was :-)
Did you mean to keep split() out of the String interface, or to provide a
default implementation of it based on find() a
Antoine Pitrou schrieb:
Georg Brandl gmx.net> writes:
I'd argue that "find" is more primitive than "split" -- split is intuitively
implemented using find and slicing, but implementing find using split and
len is unintuitive. (Of course, "index" can be used instead of "find".)
I meant semanti
Hi,
Georg Brandl gmx.net> writes:
> I'd argue that "find" is more primitive than "split" -- split is intuitively
> implemented using find and slicing, but implementing find using split and
> len is unintuitive. (Of course, "index" can be used instead of "find".)
It surely is, but it would proba
Georg Brandl gmx.net> writes:
> I'd argue that "find" is more primitive than "split" -- split is intuitively
> implemented using find and slicing, but implementing find using split and
> len is unintuitive. (Of course, "index" can be used instead of "find".)
I meant semantically primitive. I thi
Antoine Pitrou schrieb:
(just my 2 eurocents)
Guido van Rossum python.org> writes:
I'm not against this, but so far I've not been able to come up with a
good set of methods to endow the String ABC with.
If we stay minimalistic we could consider that the three basic operations that
define a
(just my 2 eurocents)
Guido van Rossum python.org> writes:
>
> I'm not against this, but so far I've not been able to come up with a
> good set of methods to endow the String ABC with.
If we stay minimalistic we could consider that the three basic operations that
define a string are:
- testing
On Tue, May 27, 2008 at 3:42 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [+python-3000]
>
> On Tue, May 27, 2008 at 12:32 PM, Armin Ronacher
> <[EMAIL PROTECTED]> wrote:
>> Basically *the* problematic situation with iterable strings is something like
>> a `flatten` function that flattens out
[+python-3000]
On Tue, May 27, 2008 at 12:32 PM, Armin Ronacher
<[EMAIL PROTECTED]> wrote:
> Strings are currently iterable and it was stated multiple times that this is a
> good idea and shouldn't change. While I still don't think that that's a good
> idea I would like to propose a solution for
36 matches
Mail list logo
