Re: [Python-ideas] discontinue iterable strings

2016-08-22 Thread Nick Coghlan 
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 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

2016-08-22 Thread Stephen J. Turnbull 
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

2016-08-21 Thread Chris Angelico 
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

2016-08-21 Thread Sven R. Kunze 

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

2016-08-21 Thread tritium-list 


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

2016-08-21 Thread Michael Selik 
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'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

2016-08-21 Thread eryk sun 
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
___
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

2016-08-21 Thread Michael Selik 
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 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

2016-08-21 Thread Nick Coghlan 
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 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

2016-08-21 Thread eryk sun 
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).
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

2016-08-20 Thread Nick Coghlan 
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 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

2016-08-20 Thread Chris Angelico 
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-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

2016-08-20 Thread אלעזר 
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(''), 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

2016-08-20 Thread Alexander Heger 
>
> 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

2016-08-20 Thread Michael Selik 
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 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

2016-08-20 Thread Michael Selik 
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'
>

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

2016-08-20 Thread Chris Angelico 
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
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

2016-08-20 Thread Franklin? Lee 
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

2016-08-20 Thread Alexander Heger 
>
> > 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

2016-08-20 Thread Alexander Heger 
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 Minnix  wrote:

> 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

2016-08-20 Thread Alexander Heger 
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, 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

2016-08-20 Thread Random832 
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

2016-08-19 Thread Random832 
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/