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
Chris Barker writes:
> Sure -- but it's entirely unnecessary, yes? If you don't change
> your code, you'll get py2(bytes) strings as paths in py2, and py3
> (Unicode) strings as paths on py3. So different, yes. But wouldn't
> it all work?
The difference is that if you happen to have a file na
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 implemented
it and re
On 20 August 2016 at 05:02, Random832 wrote:
> On Fri, Aug 19, 2016, at 19:09, Paul Moore wrote:
>> So, to me
>>
>> f'{x.partition(' + ')[0]}'
>>
>> reads as a string concatenation. I'm not sure how you'd expect a
>> syntax highlighter to make it look like anything else, to be honest
>
> One poss
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 Fri, Aug 19, 2016 at 8:55 AM Neil Girdhar wrote:
> Sure.
>
> http://bugs.python.org/issue27802
>
>
> On Friday, August 19, 2016 at 8:36:39 AM UTC-4, Emanuel Barry wrote:
>>
>> Arek Bulski wrote:
>>
>> > Could use all(a==b for zip(seq,seq2))
>>
>>
>>
>> Or even `all(itertools.starmap(operator.e
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 3:54 PM Michael Selik
wrote:
> On Fri, Aug 19, 2016 at 8:55 AM Neil Girdhar
> wrote:
>
>> Sure.
>>
>> http://bugs.python.org/issue27802
>>
>>
>> On Friday, August 19, 2016 at 8:36:39 AM UTC-4, Emanuel Barry wrote:
>>>
>>> Arek Bulski wrote:
>>>
>>> > Could use all(a==b fo
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 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 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
33 matches
Mail list logo
