standard python should discontinue to see strings as iterables of
characters - length-1 strings. I see this as one of the biggest design
flaws of python. It may have seem genius at the time, but it has passed it
usefulness for practical language use. For example, numpy has no issues
>>> np.arra
This would introduce a major inconsistency. To do this, you would need to also
strip string’s of their status as sequences (in collections.abc, Sequence is a
subclass of Iterable). Thus, making string’s no longer iterable would also mean
you could no longer take the length or slice of a string.
On Fri, Aug 19, 2016, at 23:13, Alexander Heger wrote:
> Numpy was of course design a lot later, with more experience in practical
> use (in mind).
The meaning of np.array('abc') is a bit baffling to someone with no
experience in numpy. It doesn't seem to be a one-dimensional array
containing 'abc
This is a feature, not a flaw.
From: Python-ideas
[mailto:python-ideas-bounces+tritium-list=sdamon@python.org] On Behalf Of
Alexander Heger
Sent: Friday, August 19, 2016 11:14 PM
To: python-ideas
Subject: [Python-ideas] discontinue iterable strings
standard python should discontinue
On Aug 19, 2016 11:14 PM, "Alexander Heger" wrote:
>
> standard python should discontinue to see strings as iterables of
characters - length-1 strings. I see this as one of the biggest design
flaws of python. It may have seem genius at the time, but it has passed it
usefulness for practical lang
On Sat, Aug 20, 2016, at 01:47, Franklin? Lee wrote:
> That says, "This is a 0-length array of 3-char Unicode strings." Numpy
> doesn't recognize the string as a specification of an array. Try
> `np.array(4.)` and you'll get (IIRC) `array(4., dtype='float')`, which
> has
> shape `()`. Numpy probabl
On 20 August 2016 at 15:47, Franklin? Lee
wrote:
On Aug 19, 2016 11:14 PM, "Alexander Heger" wrote:
>
> standard python should discontinue to see strings as iterables of
characters - length-1 strings. I see this as one of the biggest design
flaws of python. It may have seem genius at the time,
This would introduce a major inconsistency. To do this, you would need to
also strip string’s of their status as sequences (in collections.abc,
Sequence is a subclass of Iterable). Thus, making string’s no longer
iterable would also mean you could no longer take the length or slice of a
string.
yo
>
> > That says, "This is a 0-length array of 3-char Unicode strings." Numpy
> > doesn't recognize the string as a specification of an array. Try
> > `np.array(4.)` and you'll get (IIRC) `array(4., dtype='float')`, which
> > has
> > shape `()`. Numpy probably won't let you index either one. What ca
On Aug 20, 2016 2:27 AM, "Alexander Heger" wrote:
> The point is it does not try to disassemble it into elements as it would
do with other iterables
>
> >>> np.array([1,2,3])
> array([1, 2, 3])
> >>> np.array([1,2,3]).shape
> (3,)
It isn't so much that strings are special, it's that lists and tup
On Sat, Aug 20, 2016 at 4:28 PM, Alexander Heger wrote:
> Yes, I am aware it will cause a lot of backward incompatibilities...
Tell me, would you retain the ability to subscript a string to get its
characters?
>>> "asdf"[0]
'a'
If not, you break a ton of code. If you do, they are automatically
On Sat, Aug 20, 2016 at 3:48 AM Chris Angelico wrote:
> On Sat, Aug 20, 2016 at 4:28 PM, Alexander Heger wrote:
> > Yes, I am aware it will cause a lot of backward incompatibilities...
>
> Tell me, would you retain the ability to subscript a string to get its
> characters?
>
> >>> "asdf"[0]
> 'a
On Sat, Aug 20, 2016 at 10:31 PM, Michael Selik wrote:
> On Sat, Aug 20, 2016 at 3:48 AM Chris Angelico wrote:
>>
>> On Sat, Aug 20, 2016 at 4:28 PM, Alexander Heger wrote:
>> > Yes, I am aware it will cause a lot of backward incompatibilities...
>>
>> Tell me, would you retain the ability to su
On Sat, Aug 20, 2016 at 4:54 PM Chris Angelico wrote:
> I'm firmly of the opinion that this should not change. Code clarity is
> not helped by creating a brand-new "character" type and not having a
> corresponding literal for it, and the one obvious literal, given the
> amount of prior art using
On Sat, Aug 20, 2016, at 13:26, אלעזר wrote:
> It's possible (though not so pretty or obvious) to use $a for the
> character "a".
This isn't Lisp. If I were inventing a character literal for Python I
would probably spell it c'a'.
___
Python-ideas mailing
>
> It isn't so much that strings are special, it's that lists and tuples are
> special. Very few iterables can be directly converted to Numpy arrays. Try
> `np.array({1,2})` and you get `array({1, 2}, dtype=object)`, a
> 0-dimensional array.
>
there is no representation for sets as unordered data
>
> Agreed. One of the handy traits of cross-platform code is that MANY
> languages let you subscript a double-quoted string to get a
> single-quoted character. Compare these blocks of code:
>
> if ("asdf"[0] == 'a')
> write("The first letter of asdf is a.\n");
>
> if ("asdf"[0] == 'a'):
>
>
> I was not proposing a character type, only that strings are not iterable:
>
> for i in 'abc':
> print(i)
>
> TypeError: 'str' object is not iterable
>
but
for i in 'abc'.chars():
print(i)
a
b
c
___
Python-ideas mailing list
Python-ideas@pyt
>
> > Yes, I am aware it will cause a lot of backward incompatibilities...
>
> Tell me, would you retain the ability to subscript a string to get its
> characters?
>
> >>> "asdf"[0]
> 'a'
>
> If not, you break a ton of code. If you do, they are automatically
> iterable *by definition*. Watch:
>
> c
On Sat, Aug 20, 2016 at 4:57 PM Alexander Heger wrote:
> So you can't lose iteration without also losing subscripting.
>>
>
> Python here does a lot of things implicitly. I always felt the (explicit)
> index operator in strings in many other languages sort of is syntactic
> sugar, in python it w
>
> So you can't lose iteration without also losing subscripting.
>>>
>>
>> Python here does a lot of things implicitly. I always felt the
>> (explicit) index operator in strings in many other languages sort of is
>> syntactic sugar, in python it was taken to do literally the same things as
>> on
On Sun, Aug 21, 2016 at 12:28 AM Alexander Heger wrote:
> Did I leave anything out?
>> How would you weigh the benefits against the problems?
>> How would you manage the upgrade path for code that's been broken?
>>
>
> FIrst one needs to add the extension string attributes like
> split()/split(''
On Sat, Aug 20, 2016 at 5:27 PM Alexander Heger wrote:
> - any code that subscripts, slices, or iterates over a str will break
>>
>
> I would try to keep indexing and slicing, but not iterating.
>
So anything that wants to loop over a string character by character would
need to construct a new o
On Sun, Aug 21, 2016 at 12:34:02AM +, Michael Selik wrote:
> So anything that wants to loop over a string character by character would
> need to construct a new object, like ``for c in list(s)``? That seems
> inefficient. I suppose you might advocate for a new type, some sort of
> stringview t
On Sun, Aug 21, 2016 at 12:52 PM, Steven D'Aprano wrote:
>> > The fixes overall will be a lot easier and obvious than introduction of
>> > unicode as default string type in Python 3.0.
>>
>> That's a bold claim. Have you considered what's at stake if that's not true?
>
> Saying that these so-calle
On 2016-08-20 21:10, Chris Angelico wrote:
>I think that while the suggestion does bring some benefit, the benefit
>isn't enough to make up for the code churn and disruption it would
>cause. But I encourage the OP to go through the standard library, pick a
>couple of modules, and re-write them to
On 21 August 2016 at 14:10, Chris Angelico wrote:
> On Sun, Aug 21, 2016 at 12:52 PM, Steven D'Aprano wrote:
>> I think that while the suggestion does bring some benefit, the benefit
>> isn't enough to make up for the code churn and disruption it would
>> cause. But I encourage the OP to go throu
On Sun, Aug 21, 2016 at 3:06 PM, Brendan Barnwell wrote:
> On 2016-08-20 21:10, Chris Angelico wrote:
>>>
>>> >I think that while the suggestion does bring some benefit, the benefit
>>> >isn't enough to make up for the code churn and disruption it would
>>> >cause. But I encourage the OP to go thr
On 21 August 2016 at 15:22, Nick Coghlan wrote:
> There may also be a case to be made for introducing an AtomicStr type
> into Python's data model that works like a normal string, but
> *doesn't* support indexing, slicing, or iteration, and is instead an
> opaque blob of data that nevertheless sup
On Sun, Aug 21, 2016 at 5:27 AM, Chris Angelico wrote:
> Hmm. It would somehow need to be recognized as "not iterable". I'm not
> sure how this detection is done; is it based on the presence/absence
> of __iter__, or is it by calling that method and seeing what comes
> back? If the latter, then su
On 21 August 2016 at 16:02, eryk sun wrote:
> On Sun, Aug 21, 2016 at 5:27 AM, Chris Angelico wrote:
>> Hmm. It would somehow need to be recognized as "not iterable". I'm not
>> sure how this detection is done; is it based on the presence/absence
>> of __iter__, or is it by calling that method an
On Sun, Aug 21, 2016 at 1:27 AM Chris Angelico wrote:
> Hmm. It would somehow need to be recognized as "not iterable". I'm not
> sure how this detection is done; is it based on the presence/absence
> of __iter__, or is it by calling that method and seeing what comes
> back? If the latter, then su
On Sun, Aug 21, 2016 at 6:34 AM, Michael Selik wrote:
> The detection of not hashable via __hash__ set to None was necessary, but
> not desirable. Better to have never defined the method/attribute in the
> first place. Since __iter__ isn't present on ``object``, we're free to use
> the better tech
On Sun, Aug 21, 2016 at 2:46 AM eryk sun wrote:
> On Sun, Aug 21, 2016 at 6:34 AM, Michael Selik
> wrote:
> > The detection of not hashable via __hash__ set to None was necessary, but
> > not desirable. Better to have never defined the method/attribute in the
> > first place. Since __iter__ isn'
On Sun, Aug 21, 2016 at 2:53 AM Michael Selik
wrote:
> On Sun, Aug 21, 2016 at 2:46 AM eryk sun wrote:
>
>> On Sun, Aug 21, 2016 at 6:34 AM, Michael Selik
>> wrote:
>> > The detection of not hashable via __hash__ set to None was necessary,
>> but
>> > not desirable. Better to have never defined
On Sun, Aug 21, 2016, at 02:53, Michael Selik wrote:
> For that to make sense, Iterable should be a parent of C, or C should
> be a subclass of something registered as an Iterable. Otherwise it'd
> be creating a general recommendation to say ``__iter__ = None`` on
> every non-Iterable class, which
On Sun, Aug 21, 2016 at 6:53 AM, Michael Selik wrote:
> For that to make sense, Iterable should be a parent of C, or C should be a
> subclass of something registered as an Iterable. Otherwise it'd be creating
> a general recommendation to say ``__iter__ = None`` on every non-Iterable
> class, whic
On Aug 21, 2016 1:23 AM, "Nick Coghlan" wrote:
> Now, if we were designing a language from scratch today, there's a
> strong case to be made that the *right* way to represent text is to
> have a stream-like interface (e.g. StringIO, BytesIO) around an atomic
> type (e.g. CodePoint, int). But we're
willing to make between 2 and 3.
From: Python-ideas
[mailto:python-ideas-bounces+tritium-list=sdamon@python.org] On Behalf Of
Alexander Heger
Sent: Saturday, August 20, 2016 4:52 PM
To: Chris Angelico
Cc: python-ideas
Subject: Re: [Python-ideas] discontinue iterable strings
I was not
From: Python-ideas
[mailto:python-ideas-bounces+tritium-list=sdamon@python.org] On Behalf Of
?
Sent: Saturday, August 20, 2016 5:56 PM
To: python-ideas
Subject: Re: [Python-ideas] discontinue iterable strings
On Sun, Aug 21, 2016 at 12:28 AM Alexander Heger <mailto:pyt...@2sn.
On 21.08.2016 04:52, Steven D'Aprano wrote:
Saying that these so-called "fixes" (we haven't established yet that
Python's string behaviour is a bug that need fixing) will be easier and
more obvious than the change to Unicode is not that bold a claim.
Agreed. Especially those "we need to disting
On Sun, Aug 21, 2016 at 6:08 PM, wrote:
>
> from __future__ import unicode_literals outright changes the type of object
> string literals make (in python 2). If you were to create a non-iterable,
> non-sequence text type (a horrible idea, IMO) the same thing can be done done
> for that.
>
I
Nick Coghlan writes:
> However, the real problem with this proposal (and the reason why the
> switch from 8-bit str to "bytes are effectively a tuple of ints" in
> Python 3 was such a pain), is that there are a lot of bytes and text
> processing operations that *really do* operate code point b
On 22 August 2016 at 19:47, Stephen J. Turnbull
wrote:
> Nick Coghlan writes:
>
> > However, the real problem with this proposal (and the reason why the
> > switch from 8-bit str to "bytes are effectively a tuple of ints" in
> > Python 3 was such a pain), is that there are a lot of bytes and te
44 matches
Mail list logo
