On Mon, May 03, 2021 at 11:49:31AM -0700, Christopher Barker wrote:
> To be clear, I'm -1 as well -- we just don't need it. but a few thoughts:
>
> On Mon, May 3, 2021 at 6:32 AM Steven D'Aprano wrote:
> > If we have str comprehensions, we'd need at least two prefixes: one for
>
> > raw strings
Bruce Leban writes:
> where *!j* means join. It could optionally take a separator string as in
> this example:
Converters *could* take arguments but they currently don't: it's a
simple switch on a str argument.
We already have one complex minilanguage inside {}, do we really want
another?
May
On Tue, May 4, 2021 at 5:16 AM Caleb Donovick wrote:
>
> For the record I am definitely a -1 on this. The arguments against are
> overwhelming and the arguments for are pretty weak. However I felt the need
> to rebut:
>
> > Tests don't really count, so there's a small handful here.
>
> Tests
For the record I am definitely a -1 on this. The arguments against are
overwhelming and the arguments for are pretty weak. However I felt the
need to rebut:
> Tests don't really count, so there's a small handful here.
Tests 100% count as real use cases. If this is a pattern that would be
usef
On Fri, Apr 30, 2021 at 9:06 AM David Álvarez Lombardi <
alvarezd...@gmail.com> wrote:
> I propose a syntax for constructing/filtering strings analogous to the one
> available for all other builtin iterables. It could look something like
> this.
>
> >>> dirty = "f8sjGe7"
> >>> clean = c"char for c
To be clear, I'm -1 as well -- we just don't need it. but a few thoughts:
On Mon, May 3, 2021 at 6:32 AM Steven D'Aprano wrote:
> If we have str comprehensions, we'd need at least two prefixes: one for
> raw strings, one for regular (cooked) strings.
would we? I don't think so -- because of th
On Mon, May 3, 2021 at 9:04 AM Paul Moore wrote:
> On Mon, 3 May 2021 at 04:00, David Álvarez Lombardi
> > This is the mindset that I had. I understand there are other ways to do
> what I am asking. (I provided one in my initial post.) I am saying it
> relies on what I believe to be a notoriously
On Sun, May 02, 2021 at 10:57:59PM -0400, David Álvarez Lombardi wrote:
> I really appreciate all the feedback and all of the thought put into this
> idea. I wanted to make a couple of comments on some of the responses and
> provide my current thoughts on the idea.
>
> --- Responses to comments --
On Mon, May 3, 2021 at 10:08 PM Steven D'Aprano wrote:
>
> On Mon, May 03, 2021 at 09:04:51PM +1000, Chris Angelico wrote:
>
> > > My understanding of the situation is that the list comprehension [
> > > x*x for x in range(5) ] is a shorthand for list( x*x for x in
> > > range(5) ).
> >
> > Sorta-
On Mon, May 03, 2021 at 09:04:51PM +1000, Chris Angelico wrote:
> > My understanding of the situation is that the list comprehension [
> > x*x for x in range(5) ] is a shorthand for list( x*x for x in
> > range(5) ).
>
> Sorta-kinda. It's not a shorthand in the sense that you can't simply
> rep
On Mon, May 3, 2021 at 8:03 PM Jonathan Fine wrote:
> Difference.
> >>> tmp = (x*x for x in range(5)) ; list(tmp)
> [0, 1, 4, 9, 16]
> >>> tmp = (x*x for x in range(5)) ; [ tmp ]
> [ at 0x7fec02319678>]
Closer parallel:
>>> tmp = (x*x for x in range(5)) ; [ *tmp ]
[0, 1, 4, 9, 16]
Summary: The argument in list(arg) must be iterable. The argument in
str(arg) can be anything. Further, in [ a, b, c, d ] the content of the
literal must be read by the Python parser as a Python expression. But in
"this and that" the content need not be a Python expression.
Hi David
I find your s
On Mon, 3 May 2021 at 04:00, David Álvarez Lombardi
wrote:
> This is the mindset that I had. I understand there are other ways to do what
> I am asking. (I provided one in my initial post.) I am saying it relies on
> what I believe to be a notoriously unintuitive method (str.join) and an even
On Mon, May 3, 2021 at 1:00 PM David Álvarez Lombardi
wrote:
> > Rather than toy examples, how about scouring the Python standard library
> > for some real examples?
>
> Here are 73 of them that I found by grepping through Lib.
>
> https://github.com/python/cpython/blob/master/Lib/email/_encoded_
I really appreciate all the feedback and all of the thought put into this
idea. I wanted to make a couple of comments on some of the responses and
provide my current thoughts on the idea.
--- Responses to comments ---
> *All* others?
>
> Tuple, frozenset, bytes, bytearray, memoryview, enumerate,
Valentin Berlier writes:
> f"""
> Guest list ({len(people)} people):
> {person.name + '\n' for person in people}
> """
That's nice! It's already (almost[1]) legal syntax, but it prints the
repr of the generator function. This could work, though:
f"""
> But that was not the primary motivator for adding them to the language.
I don't think the original author thinks that way either about string
comprehensions. I was asked about the kind of speed benefits that string
comprehensions would have over using a generator with "".join() and I used
f-s
I started seeing this, as the objecting people are putting, something that
is
really outside of the scope.
But it just did occur to me that having to use str.join _inside_ an
f-string
expression is somewhat cumbersome
I mean, think of a typical repr for a sequence class:
return f"MyClass({', '.j
On Fri, Apr 30, 2021 at 11:15 PM Valentin Berlier
wrote:
> > You could say that f-strings are redundant because they can't do
> anything that str.format can't, but they make it possible to shave off the
> static overhead of going through python's protocols and enable additional
> optimizations.
On 2021-04-30 11:14, David Álvarez Lombardi wrote:
To me, it is hard to see how any argument against this design (for
anything other than implementation-difficulty or something along these
lines) can be anything but an argument against iter comprehensions in
general... but if someone disagrees,
On Fri, 30 Apr 2021 at 17:08, David Álvarez Lombardi
wrote:
> I propose a syntax for constructing/filtering strings analogous to the one
> available for all other builtin iterables. It could look something like
> this.
>
> >>> dirty = "f8sjGe7"
> >>> clean = c"char for char in dirty if char in st
> you talked about builtin *iterables*
My mistake, I reused the terminology used by the original author to make it
easier to follow.
> The point of iterators like map, zip and filter is to *avoid* performing the
> computation until it is required.
Of course. Maybe I wasn't clear enough. I don'
On Sat, May 01, 2021 at 06:21:43AM -, Valentin Berlier wrote:
> > The builtin interables bytearray, bytes, enumerate, filter
> > frozenset, map, memoryview, range, reversed, tuple and zip suggest
> > differently.
>
> enumerate, filter, map, range, reversed and zip don't apply because
> the
> The builtin interables bytearray, bytes, enumerate, filter frozenset, map,
> memoryview, range, reversed, tuple and zip suggest differently.
enumerate, filter, map, range, reversed and zip don't apply because they're not
collections, you wouldn't be able to store the result of the computation
> c"f(c) for c in some_string if g(c)"
Even this example would allow the interpreter to skip building the generator
object and having to feed the result of every f(c) back into the iterator
protocol. This is similar to f-strings vs str.format. You could say that
f-strings are redundant because
I thought I had sent a response to this a few hours ago, but it seems to
have been eaten by the email gremlins.
Apologies if this ends up as a duplicate.
On Fri, Apr 30, 2021 at 12:03:15PM -0400, David Álvarez Lombardi wrote:
> I propose a syntax for constructing/filtering strings analogous to t
On Sat, May 01, 2021 at 03:05:51AM -, Valentin Berlier wrote:
> It's kind of weird that people seem to be missing the point about
> this. Python already has comprehensions for all the iterable builtins
> except strings.
No it doesn't.
I count 15 builtin iterables, only three have comprehen
On Sat, May 1, 2021 at 1:43 PM Valentin Berlier wrote:
>
> > the ONLY predicate that can be expressed about a single character is it
> > being a member of a subset of all Unicode characters
>
> You seem to be assuming that the comprehension would be purposefully
> restricted to iterating over st
On 2021-05-01 at 03:05:51 -,
Valentin Berlier wrote:
> Also I haven't seen anyone acknowledge the potential performance
> benefits of string comprehensions. The "".join() idiom needs to go
> through the entire generator machinery to assemble the final string,
> whereas a decent implementation
Ok... If the suggestion is trying concatenation of arbitrary objects that
aren't strings, I go from thinking it's unnecessary to thinking it's a
massively horrible idea.
On Fri, Apr 30, 2021, 11:43 PM Valentin Berlier wrote:
> > the ONLY predicate that can be expressed about a single character i
> the ONLY predicate that can be expressed about a single character is it being
> a member of a subset of all Unicode characters
You seem to be assuming that the comprehension would be purposefully restricted
to iterating over strings. The original author already provided examples with
predicat
Strings are VERY different from other iterables. Every item in a string is
itself an (iterables) string. In many ways, strings are more like scalars,
and very often we treat them as such.
You could make an argument that e.g. a NumPy array of homogenous scalars is
similar. However, that would be a
It's kind of weird that people seem to be missing the point about this. Python
already has comprehensions for all the iterable builtins except strings. The
proposed syntax doesn't introduce any new concept and would simply make strings
more consistent with the rest of the builtins. The argument
Given that there is very little you can test about a single character, a
new construct feels excessive. Basically, the only possible question is "is
it in this subset of codepoints?"
However, that use is perfectly covered by the str.translate() method
already. Regular expressions also cover this w
On Sat, May 1, 2021 at 6:23 AM Rob Cliffe via Python-ideas
wrote:
> Yes I agree your examples read nicely, without the usual boilerplate.
> Whether this is worth adding to the language is a moot point. Every addition
> increases the size of the compiler/interpreter, increases the maintenance
On 30/04/2021 19:14, David Álvarez Lombardi wrote:
I appreciate the feedback, but I don't think the proposed ideas
address any of my points.
1. *Consistency *(with other comprehensions)
You're actually adding an inconsistency: having a comprehension inside
string quotes instead of not.
On 2021-04-30 at 14:14:50 -0400,
David Álvarez Lombardi wrote:
[...]
> new = c"x.lower() for x in old if x in HARDCODED_LIST" # filter-in chars
> that appear in earlier-defined HARDCODED_LIST and convert to lower
> new = c"x for x in old if not x.isprintable()" # filter-in
> non-printable char
Small correction: isinstance(x, int) should be x.isdigit() in the last
example.
On Fri, Apr 30, 2021 at 2:14 PM David Álvarez Lombardi <
alvarezd...@gmail.com> wrote:
> I appreciate the feedback, but I don't think the proposed ideas address
> any of my points.
>
>1. *Consistency *(with other
I appreciate the feedback, but I don't think the proposed ideas address any
of my points.
1. *Consistency *(with other comprehensions)
2. *Intuitiveness *(as opposed to str.join(iter) which is widely deemed
to be confusing and seemingly-backwards)
3. *Efficiency *(with respect to line
On Fri, Apr 30, 2021 at 6:00 PM Chris Angelico wrote:
For those cases where you're merging literal parts and generated
> parts, it may be of value to use an f-string:
>
> >>> f"[{','.join('0123')}]"
> '[0,1,2,3]'
>
> The part in the braces is evaluated as Python code, and the rest is
> simple lit
On Sat, May 1, 2021 at 2:52 AM Jonathan Fine wrote:
>
> Hi David
>
> I see where you are coming from. I find it helps to think of sep.join as a
> special case. Here's a more general join, with sep.join equivalent to
> genjoin(sep, '', '').
>
> def genjoin(sep, left, right):
> def fn(
Hi David
I see where you are coming from. I find it helps to think of sep.join as a
special case. Here's a more general join, with sep.join equivalent to
genjoin(sep, '', '').
def genjoin(sep, left, right):
def fn(items):
return left + sep.join(items) + right
retur
42 matches
Mail list logo
