I'm a little confused by the benchmark. Using re looks pretty competitive
in terms of speed, and should be much more memory efficient.
# https://www.gutenberg.org/cache/epub/100/pg100.txt (5.7mb; ~170K lines)
with open('/tmp/shakespeare.txt', 'r') as f:
text = f.read()
import re
from
Good catch! One correction here, I somewhat mixed up the benchmarks. I
forgot both projects of mine required support for universal line endings
exactly like splitlines() does this out of the box. That requires a more
complex regex pattern. I was actually using:
re.compile(r"\n|\r(?!\n)")
And then
On Sat, Jun 18, 2022, 9:21 PM Rob Cliffe
> Sorry again, but IMO discussing any model except one where late-bound
> defaults are evaluated at function call time is just adding FUD.
>
It's definitely rude to repeatedly state that anyone who's opinion is
different from yours is "adding FUD" and
On Sat, 18 Jun 2022 at 03:45, Chris Angelico wrote:
> > This raises another choice: should lazy defaults be evaluated before
> > entering the body of the function, or at the point where the parameter
> > is used? Which would be more useful?
> >
> > # `defer n=len(items)`
> > def
On 18/06/2022 03:28, Steven D'Aprano wrote:
On Fri, Jun 17, 2022 at 06:32:36AM +0100, Rob Cliffe wrote:
The bar for adding a new hard keyword to Python is very high.
Likewise for new syntax.
I would suggest less so, provided that it was previously illegal,
because it's backward-compatible,
My first thought is that you are using the wrong data structure here—
perhaps a list of lines would make more sense than one big ol’ string.
That being said, a way to get all the indexes of a character could be
useful I’d support that idea.
-CHB
On Fri, Jun 17, 2022 at 10:13 PM Jonathan
Chris Angelico writes:
> And there we have it. People are complaining loudly, but then ALSO
> saying that they don't support the proposal anyway. Why are you
> bothering to debate this if you've already made your decision?
I can't speak for Brendan, but I have two reasons for discussing
On Sat, 18 Jun 2022 at 15:53, Stephen J. Turnbull
wrote:
> I don't find that burdensome enough to want syntax, and I can't guess
> how quickly I'd start using it if available, that probably depends on
> how often the community seems to be using it (ie, in the code I'm
> reading).
To be honest, I
I think the example that Steven gave, and Stephen approximately repeats is
good.
def func(items=[], n=later len(items)):
items.append("Hello")
print(n)
func()
> I guess Chris will say 0 and David will say 1, but I might be wrong about
either of them.
This is correct.
Steven D'Aprano writes:
> The match...case statement didn't "need" keywords either, we could have
> picked symbols instead if we wanted to look like APL. Remember that
> keywords have advantages as well as disadvantages. Given the existence
> of community support for keywords, the PEP
On Sat, 18 Jun 2022 at 21:57, Jonathan Slenders wrote:
>
> Good catch! One correction here, I somewhat mixed up the benchmarks. I forgot
> both projects of mine required support for universal line endings exactly
> like splitlines() does this out of the box. That requires a more complex
>
On 6/18/2022 5:34 PM, Paul Moore wrote:
After all, it has the
advantage of working on older versions of Python (and given that one
of your use cases is Textual, I can't imagine anyone would be happy if
that required Python 2.12+...)
Guido's "no 2.8" shirt apparently didn't stop 2.9 through
On Sat, 18 Jun 2022 at 23:15, Eric V. Smith via Python-ideas
wrote:
>
> On 6/18/2022 5:34 PM, Paul Moore wrote:
> > After all, it has the
> > advantage of working on older versions of Python (and given that one
> > of your use cases is Textual, I can't imagine anyone would be happy if
> > that
> This makes me realize that `str.indexes(char)` is actually not what I need,
> but really a `str.line_offsets()` which returns exactly the positions that
> `str.splitlines()` would use. Does that make sense?
I'm also thinking of a generic `str.split_indices(char)` that handles all
characters
On 2022-06-18 21:55, Jonathan Slenders wrote:
Good catch! One correction here, I somewhat mixed up the benchmarks. I
forgot both projects of mine required support for universal line endings
exactly like splitlines() does this out of the box. That requires a more
complex regex pattern. I was
To me, the natural implementation of slicing on a non-reusable iterator
(such as a generator) would be that you are not allowed to go backwards
or even stand still:
mygen[42]
mygen[42]
ValueError: Element 42 of iterator has already been used
(Apologies if I don't know the difference
On Sat, Jun 18, 2022 at 5:13 AM Jonathan Slenders wrote:
> First time, it was needed in prompt_toolkit, where I spent a crazy amount of
> time looking for the most performant solution.
> Third time is for the Rich/Textual project from Will McGugan. (See:
>
Sorry, but I think all this talk about lazy evaluation is a big red herring:
(1) Python is not Haskell or Dask.
(2) Lazy evaluation is something Python doesn't have, and would be
a HUGE amount of work for Chris (or anyone) to implement (much more, I
would think, than he has already put
18 matches
Mail list logo
