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
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
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
>
> > 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
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
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 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
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*
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
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
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
>
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
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
>
>
> 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
>
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
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?
>
>
17 matches
Mail list logo