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.arra
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 ge
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:
&
>
> > 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 ca
>
> 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
>
> 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
>
> for x in seq1 if p1(x)\
> for y in seq2 if p2(y)\
> for z in seq3 if p3(z):
> result.append(f(x, y, z))
>
It think it is not uncommon to have nested loops, maybe with an if/continue
statement at the beginning, with only one logical block that then should go
down only one indentation level
>
> > I think wasting of indentation levels for a single logical block should
> be
> > avoided if possible to make the code more legible, otherwise one hits the
> > suggested line length limit too fast - suppose this is now inside a
> method,
> > you already lose at least 8 char ...
>
> Hence gener
For me the current behaviour does not seem unreasonable as it resembles the
order in which you write out loops outside a comprehension except that the
expression for generated values is provided first.
On 21 October 2016 at 05:03, Sven R. Kunze wrote:
> On 19.10.2016 00:08, Rob Cliffe wrote:
>
>
>
>
>> For me the current behaviour does not seem unreasonable as it resembles
>>> the order in which you write out loops outside a comprehension
>>>
>>
>> That's true, but the main reason for having comprehensions
>> syntax in the first place is so that it can be read
>> declaratively -- as a desc
>
> But let's make str() of a slice more suggestive of actual slicing, and
> as a bonus, make slices easier to create too.
>
> str(slice(None, None, None)) => "slice[:]"
>
following all the later discussion, I'd like to come back to this initial
part of this thread:
An even briefer for for jus
w/r relativistic effects and continental drift - not really. The speed is
about 1cm/yr or v = 1e-18 c. Relativistic effect would go like 0.5 *
(v/c)**2, so more like 5E-37 in relative rate of proper time. You can just
barely capture a few minutes of that even with int128 resolution. As for
fina
​What little documentation I could find, providing a stride on the
assignment target for a list is supposed to trigger 'advanced slicing'
causing element-wise replacement - and hence requiring that the source
iterable has the appropriate number of elements.
>>> a = [0,1,2,3]
>>> a[::2] = [4,5]
>>>
for regular strings one can write
"aaa" + "bbb"
which also works for f-strings, r-strings, etc.; in regular expressions,
there is, e.g., parameter counting and references to numbered matches. How
would that be dealt with in a compound p-string? Either it would have to
re-compiled or not, either
> What's more, it's a tool that should be used
> with considerable reluctance, because REs are essentially unreadable,
> so every time you use one you're creating a maintenance headache.
Well, it requires some experience to read REs, I have written many, and I
still need to test thoroughly even ma
I have lots of code of this kind
>>> e = d1.copy(); e.update(d2)
so the addition operator would be most welcome. I congratulate to this PEP!
In fact, I would have wished, and in early programming had assumed, the
`update` method would return the updated array rather than modifying the
existing
> no one can tell what either '+' or '|' does in this context without
> guessing, because it does do neither "arithmetic addition", nor
> "concatenation", nor "union set" (or bitwise op, or any other op one could
> come up). '+' is more familiar or '|' might even be completely new for some
> users,
20 matches
Mail list logo
