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

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-20 Thread Brendan Barnwell
On 2016-08-19 13:11, C Anthony Risinger wrote: It might be harder to find the end of an f-string in one shot, but I think that's the crux of the issue: to a reader/developer, is an f-string conceptually one thing or a compound thing? To me (someone who would like to see f-string expressions

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-20 Thread Brendan Barnwell
On 2016-08-19 20:57, C Anthony Risinger wrote: In a quality editor, everything about the {...} will tell me I'm writing a Python expression. It'll be colored like an expression. It'll do fancy completion like an expression. Aw shucks, it*IS* a Python expression! Except for one tiny detail: I'm

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

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

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.

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

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-20 Thread Stephen J. Turnbull
C Anthony Risinger writes: > The only time I personally use a different quote is when it somehow > makes the data more amenable to the task at hand. The data! The > literal data! Not the expressions I'm conveniently inlining with > the help of f-strings. You do *not* know that yet! *Nobody*

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-20 Thread Paul Moore
On 20 August 2016 at 04:57, C Anthony Risinger wrote: > The two string parts are string-colored and the x.partition bits would look > like > any other code in the file. It won't look like concatenation at that point. That's entirely subjective and theoretical (unless you've

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

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 >

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-20 Thread Eric V. Smith
On 8/19/2016 2:57 PM, Guido van Rossum wrote: I don't think we should take action now. Would it make sense, as a precaution, to declare the PEP provisional for one release? Then we can develop a sense of whether the current approach causes real problems. We could also emit some kind of warning

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 >

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

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 >

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

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? > >