Re: [Python-ideas] discontinue iterable strings
On 22 August 2016 at 19:47, Stephen J. Turnbullwrote: > 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 by code > > point. > > Sure, but code points aren't strings in any language I use except > Python. And AFAIK strings are the only case in Python where a > singleton *is* an element, and an element *is* a singleton. Sure, but the main concern at hand ("list(strobj)" giving a broken out list of individual code points rather than TypeError) isn't actually related to the fact those individual items are themselves length-1 strings, it's related to the fact that Python normally considers strings to be a sequence type rather than a scalar value type. str is far from the only builtin container type that NumPy gives the scalar treatment when sticking it into an array: >>> np.array("abc") array('abc', dtype=' >> np.array(b"abc") array(b'abc', dtype='|S3') >>> np.array({1, 2, 3}) array({1, 2, 3}, dtype=object) >>> np.array({1:1, 2:2, 3:3}) array({1: 1, 2: 2, 3: 3}, dtype=object) (Interestingly, both bytearray and memoryview get interpreted as "uint8" arrays, unlike the bytes literal - presumably the latter discrepancy is a requirement for compatibility with NumPy's str/unicode handling in Python 2) That's why I suggested that a scalar proxy based on wrapt.ObjectProxy that masked all container related protocols could be an interesting future addition to the standard library (especially if it has been battle-tested on PyPI first). "I want to take this container instance, and make it behave like it wasn't a container, even if other code tries to use it as a container" is usually what people are after when they find str iteration inconvenient, but "treat this container as a scalar value, but otherwise expose all of its methods" is an operation with applications beyond strings. Not-so-coincidentally, that approach would also give us a de facto "code point" type: it would be the result of applying the scalar proxy to a length 1 str instance. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
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 by code > point. Sure, but code points aren't strings in any language I use except Python. And AFAIK strings are the only case in Python where a singleton *is* an element, and an element *is* a singleton. (Except it isn't: "ord('ab')" is a TypeError, even though "type('a')" returns "". ) I thought this was cute when I first encountered it (it happens that I was studying how you can embed a set of elements into the semigroup of sequences of such elements in algebra at the time), but it has *never* been of practical use to me that indexing or iterating a str returns str (rather than a code point). "''.join(list('abc'))" being an identity is an interesting, and maybe useful, fact, but I've never missed it in languages that distinguish characters from strings. Perhaps that's because they generally have a split function defined so that "''.join('abc'.split(''))" is also available for that identity. (N.B. Python doesn't accept an empty separator, but Emacs Lisp does, where "'abc'.split('')" returns "['', 'a', 'b', 'c', '']". I guess it's too late to make this change, though.) The reason that switching to bytes is a pain is that we changed the return type of indexing bytes to something requiring conversion of literals. You can't write "bytething[i] == b'a'", you need to write "bytething[i] == ord(b'a')", and "b''.join(list(b'abc')) is an error, not an identity. Of course the world broke! > But we're not designing a language from scratch - we're iterating > on one with a 25 year history of design, development, and use. +1 to that. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
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. > It could; but that just changes what *literals* make. But what about other sources of strings - str()? bytes.decode()? format()? repr()? Which ones get changed, and which don't? There's no easy way to do this. ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
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 distinguish between char and string" calls are somewhat irritating. I need to work with such languages at work sometimes and honestly: it sucks (but that may just be me). Furthermore, I don't see much benefit at all. First, the initial run and/or the first test will reveal the wrong behavior. Second, it just makes sense if people use a generic variable (say 'var') for different types of objects. But, well, people shouldn't do that in the first place. Third, it would make iterating over a string more cumbersome. Especially the last point makes me -1 on this proposal. My 2 cents, Sven ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
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 <python-ideas@python.org> Subject: Re: [Python-ideas] discontinue iterable strings On Sun, Aug 21, 2016 at 12:28 AM Alexander Heger <mailto:pyt...@2sn.net> 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(''), chars(), and substring[] (Python 3.7). When indexing becomes disallowed (Python 3.10 / 4.0) attempts to iterate (or slice) will raise TypeError. The fixes overall will be a lot easier and obvious than introduction of unicode as default string type in Python 3.0. It could already be used/test starting with Python 3.7 using 'from future import __monolythic_strings__`. Is there any equivalent __future__ import with such deep semantic implications? Most imports I can think of are mainly syntactic. And what would it do? change the type of string literals? change the behavior of str methods locally in this module? globally? How will this play with 3rd party libraries? Sounds like it will break stuff in a way that cannot be locally fixed. ~Elazar 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. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
On Sun, Aug 21, 2016 at 2:46 AM eryk sunwrote: > 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 technique of not defining __iter__ rather than defining it as > > None, NotImplemented, etc. This is superior, because we don't want > __iter__ > > to show up in a dir(), help(), or other tools. > > The point is to be able to define __getitem__ without falling back on > the sequence iterator. > > I wasn't aware of the recent commit that allows anti-registration of > __iter__. This is perfect: > > >>> class C: > ... __iter__ = None > ... def __getitem__(self, index): return 42 > ... >>>> iter(C()) > Traceback (most recent call last): > File "", line 1, in > TypeError: 'C' object is not iterable > >>> isinstance(C(), collections.abc.Iterable) > False > 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 would be silly. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
On Sun, Aug 21, 2016 at 6:34 AM, Michael Selikwrote: > 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 technique of not defining __iter__ rather than defining it as > None, NotImplemented, etc. This is superior, because we don't want __iter__ > to show up in a dir(), help(), or other tools. The point is to be able to define __getitem__ without falling back on the sequence iterator. I wasn't aware of the recent commit that allows anti-registration of __iter__. This is perfect: >>> class C: ... __iter__ = None ... def __getitem__(self, index): return 42 ... >>> iter(C()) Traceback (most recent call last): File "", line 1, in TypeError: 'C' object is not iterable >>> isinstance(C(), collections.abc.Iterable) False ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
On Sun, Aug 21, 2016 at 1:27 AM Chris Angelicowrote: > 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 sure, an __iter__ that raises would cover > that. > 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 technique of not defining __iter__ rather than defining it as None, NotImplemented, etc. This is superior, because we don't want __iter__ to show up in a dir(), help(), or other tools. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
On 21 August 2016 at 16:02, eryk sunwrote: > 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 sure, an __iter__ that raises would cover >> that. > > PyObject_GetIter calls __iter__ (i.e. tp_iter) if it's defined. To get > a TypeError, __iter__ can return an object that's not an iterator, > i.e. an object that doesn't have a __next__ method (i.e. tp_iternext). I believe Chris's concern was that "isintance(obj, collections.abc.Iterable)" would still return True. That's actually a valid concern, but Python 3.6 generalises the previously __hash__ specific "__hash__ = None" anti-registration mechanism to other protocols, including __iter__: https://hg.python.org/cpython/rev/72b9f195569c Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
On Sun, Aug 21, 2016 at 5:27 AM, Chris Angelicowrote: > 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 sure, an __iter__ that raises would cover > that. PyObject_GetIter calls __iter__ (i.e. tp_iter) if it's defined. To get a TypeError, __iter__ can return an object that's not an iterator, i.e. an object that doesn't have a __next__ method (i.e. tp_iternext). For example: >>> class C: ... def __iter__(self): return self ... def __getitem__(self, index): return 42 ... >>> iter(C()) Traceback (most recent call last): File "", line 1, in TypeError: iter() returned non-iterator of type 'C' If __iter__ isn't defined but __getitem__ is defined, then PySeqIter_New is called to get a sequence iterator. >>> class D: ... def __getitem__(self, index): return 42 ... >>> it = iter(D()) >>> type(it) >>> next(it) 42 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
On 21 August 2016 at 15:22, Nick Coghlanwrote: > 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 supports all the other usual > string operations. (Similar to the way that types.MappingProxyType > lets you provide a read-only view of an otherwise mutable mapping, and > that collections.KeysView, ValuesView and ItemsView provide different > interfaces for a common underlying mapping) Huh, prompted by Brendan Barnwell's comment, I just realised that a discussion I was having with Graham Dumpleton at PyCon Australia about getting the wrapt module (or equivalent functionality) into Python 3.7 (not 3.6 just due to the respective timelines) is actually relevant here: given wrapt.ObjectProxy (see http://wrapt.readthedocs.io/en/latest/wrappers.html#object-proxy ) it shouldn't actually be that difficult to write an "atomic_proxy" implementation that wraps arbitrary container objects in a proxy that permits most operations, but actively *prevents* them from being treated as collections.abc.Container instances of any kind. So if folks are looking for a way to resolve the perennial problem of "How do I tell container processing algorithms to treat *this particular container* as an opaque blob?" that arise most often with strings and binary data, I'd highly recommend that as a potentially fruitful avenue to start exploring. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
On Sun, Aug 21, 2016 at 12:52 PM, Steven D'Apranowrote: >> > 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-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. Pretty > much everything is easier and more obvious than changing to Unicode. :-) > (Possibly not bringing peace to the Middle East.) And yet it's so simple. We can teach novice programmers about two's complement [1] representations of integers, and they have no trouble comprehending that the abstract concept of "integer" is different from the concrete representation in memory. We can teach intermediate programmers how hash tables work, and how to improve their performance on CPUs with 64-byte cache lines - again, there's no comprehension barrier between "mapping from key to value" and "puddle of bytes in memory that represent that mapping". But so many programmers are entrenched in the thinking that a byte IS a character. > 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 see how they would look using > this proposal. Python still has a rule that you can iterate over anything that has __getitem__, and it'll be called with 0, 1, 2, 3... until it raises IndexError. So you have two options: Remove that rule, and require that all iterable objects actually define __iter__; or make strings non-subscriptable, which means you need to do something like "asdf".char_at(0) instead of "asdf"[0]. IMO the second option is a total non-flyer - good luck convincing anyone that THAT is an improvement. The first one is possible, but dramatically broadens the backward-compatibility issue. You'd have to search for any class that defines __getitem__ and not __iter__. If that *does* get considered, it wouldn't be too hard to have a compatibility function, maybe in itertools. def subscript(self): i = 0 try: while "moar indexing": yield self[i] i += 1 except IndexError: pass class Demo: def __getitem__(self, item): ... __iter__ = itertools.subscript But there'd have to be the full search of "what will this break", even before getting as far as making strings non-iterable. ChrisA [1] Not "two's compliment", although I'm told that Two can say some very nice things. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
On Sun, Aug 21, 2016 at 12:28 AM Alexander Hegerwrote: > 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(''), chars(), and substring[] (Python 3.7). > > When indexing becomes disallowed (Python 3.10 / 4.0) attempts to iterate > (or slice) will raise TypeError. The fixes overall will be a lot easier > and obvious than introduction of unicode as default string type in Python > 3.0. It could already be used/test starting with Python 3.7 using 'from > future import __monolythic_strings__`. > > Is there any equivalent __future__ import with such deep semantic implications? Most imports I can think of are mainly syntactic. And what would it do? change the type of string literals? change the behavior of str methods locally in this module? globally? How will this play with 3rd party libraries? Sounds like it will break stuff in a way that cannot be locally fixed. ~Elazar ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
> > 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 other objects. But it does not have to be that way. >> > > You can quibble with the original design choice, but unless you borrow > Guido's time machine, there's not much point to that discussion. > Just to be clear, at the time it was designed, it surely was a genious idea with its obvious simplicity. I spend much of my time refactoring codes and interfaces from previous "genius" ideas, as usage matures. > Instead, let's talk about the benefits and problems that your change > proposal would cause. > > Benefits: > - no more accidentally using str as an iterable > > Problems: > - any code that subscripts, slices, or iterates over a str will break > I would try to keep indexing and slicing, but not iterating. Though there have been comments that may not be straightforward to implement. Not sure if strings would need to acquire a "substring" attribute that can be indexed and sliced. 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(''), chars(), and substring[] (Python 3.7). When indexing becomes disallowed (Python 3.10 / 4.0) attempts to iterate (or slice) will raise TypeError. The fixes overall will be a lot easier and obvious than introduction of unicode as default string type in Python 3.0. It could already be used/test starting with Python 3.7 using 'from future import __monolythic_strings__`. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
On Sat, Aug 20, 2016 at 4:57 PM Alexander Hegerwrote: > 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 other > objects. But it does not have to be that way. > You can quibble with the original design choice, but unless you borrow Guido's time machine, there's not much point to that discussion. Instead, let's talk about the benefits and problems that your change proposal would cause. Benefits: - no more accidentally using str as an iterable Problems: - any code that subscripts, slices, or iterates over a str will break 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? ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
On Sat, Aug 20, 2016 at 3:48 AM Chris Angelicowrote: > 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' > A separate character type would solve that issue. While Alexander Heger was advocating for a "monolithic object," and may in fact not want subscripting, I think he's more frustrated by the fact that iterating over a string gives other strings. If instead a 1-length string were a different, non-iterable type, that might avoid some problems. However, special-casing a character as a different type would bring its own problems. Note the annoyance of iterating over bytes and getting integers. In case it's not clear, I should add that I disagree with this proposal and do not want any change to strings. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
On Sat, Aug 20, 2016 at 4:28 PM, Alexander Hegerwrote: > 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: class IsThisIterable: def __getitem__(self, idx): if idx < 5: return idx*idx raise IndexError >>> iti = IsThisIterable() >>> for x in iti: print(x) ... 0 1 4 9 16 So you can't lose iteration without also losing subscripting. ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
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 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. > But it does deal with strings as monolithic objects, Seems to me that Numpy treats strings as "I, uh, don't really know what you want me to do with this" objects. That kinda makes sense for Numpy, because, uh, what DO you want Numpy to do with strings? Numpy is NOT designed to mess around with strings, and Numpy does NOT have as high a proportion of programmers using it for strings, so Numpy does not have much insight into what's good and what's useful for programmers who need to mess around with strings. In summary, Numpy isn't a good example of "strings done right, through more experience", because they are barely "done" at all. > doing away with many of the pitfalls of strings in Python. Please start listing the pitfalls, and show how alternatives will be an improvement. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
> > > 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 can you > > even do with it? > > In my poking around I found that you can index it with [()] or access > with .item() and .itemset(value). Still seems more like a party trick > than the well-reasoned practical implementation choice he implied it > was. my apologies about the confusion, the dim=() was not the point, but rather that numpy treats the string as a monolithic object rather than disassembling it as it would do with other iterables. I was just trying to give the simplest possible example. Numpy still does >>> np.array([[1,2],[3,4]]) array([[1, 2], [3, 4]]) >>> np.array([[1,2],[3,4]]).shape (2, 2) but not here >>> np.array(['ab','cd']) array(['ab', 'cd'], dtype='>> np.array(['ab','cd']).shape (2,) -Alexander ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
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. you can always define __len__ and __index__ independently. I do this for many objects. But it is a point I have not considered. While I believe your proposal was well intentioned, IMHO it would cause a giant inconsistency in Python (why would one of our core sequences not be iterable?) Yes, I am aware it will cause a lot of backward incompatibilities, but this is based on all the lengthy discussions about "string but not iterable" type determinations. If sting was not iterable, a lot of things would also be easier. You could also argue why an integer cannot be iterated over its bits? As had been noted, is one of few objects of which the component can be the object itself. 'a'[0] == 'a' I do not iterate over strings so often that it could not be done using, e.g., str.chars(): for c in str.chars(): print(c) On 20 August 2016 at 13:24, Edward Minnixwrote: > 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. > > While I believe your proposal was well intentioned, IMHO it would cause a > giant inconsistency in Python (why would one of our core sequences not be > iterable?) > > - Ed > > > On Aug 19, 2016, at 11:13 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 language use. For example, numpy has no issues > > > > >>> np.array('abc') > > array('abc', dtype=' > > > whereas, as all know, > > > > >>> list('abc') > > ['a', 'b', 'c'] > > > > Numpy was of course design a lot later, with more experience in > practical use (in mind). > > > > Maybe a starting point for transition that latter operation also returns > ['abc'] in the long run, could be to have an explicit split operator as > recommended use, e.g., > > > > 'abc'.split() > > 'abc'.split('') > > 'abc'.chars() > > 'abc'.items() > > > > the latter two could return an iterator whereas the former two return > lists (currently raise exceptions). > > Similar for bytes, etc. > > > > > > > > ___ > > Python-ideas mailing list > > Python-ideas@python.org > > https://mail.python.org/mailman/listinfo/python-ideas > > Code of Conduct: http://python.org/psf/codeofconduct/ > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
On 20 August 2016 at 15:47, Franklin? Leewrote: 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 language use. I'm bothered by it whenever I want to write code that takes a sequence and returns a sequence of the same type. But I don't think that the answer is to remove the concept of strings as sequences. And I don't want strings to be sequences of character code points, because that's forcing humans to think on the implementation level. Please explain the problem with the status quo, preferably with examples where it goes wrong. > For example, numpy has no issues > > >>> np.array('abc') > array('abc', dtype=' >> a = np.array('abc') >>> a[()] 'abc' >>> a[()][2] 'c' 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,) Numpy is for numbers. It was designed with numbers in mind. Numpy's relevant experience here is wy less than general Python's. But it does deal with strings as monolithic objects, doing away with many of the pitfalls of strings in Python. And yes, it does a lot about memory management, so it is fully aware of strings and bytes ... ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
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 probably won't let you index either one. What can you > even do with it? In my poking around I found that you can index it with [()] or access with .item() and .itemset(value). Still seems more like a party trick than the well-reasoned practical implementation choice he implied it was. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] discontinue iterable strings
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', as your next statement suggests. It seem to be a zero-dimensional array? > Maybe a starting point for transition that latter operation also returns > ['abc'] in the long run Just to be clear, are you proposing a generalized list(obj: non-iterable) constructor that returns [obj]? ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/