Andrew Barnert via Python-ideas writes:
> > Maybe there needs to be a second-tier recommendation, where a
> > list of packages can be given that aren't category killers, but
> > have been given the blessing of the Python devs as "this is a
> > good-quality, well-maintained package, and can be
Rob Cliffe via Python-ideas writes:
>
>
> On 01/08/2019 19:11:18, Guido van Rossum wrote:
> > Here is someone declaring that the docs are less accessible than the
> > code. I personally am disappointed, given the amount of effort that we
> > put in those docs. But maybe this is true. If w
On Aug 1, 2019, at 14:52, Chris Angelico wrote:
>
> The stdlib does reference a small number of third-party packages
> (requests etc). We don't want to go overboard with that, but I think
> more-itertools is worth referencing. Maybe there needs to be a
> second-tier recommendation, where a list o
On Fri, Aug 2, 2019 at 7:36 AM Ricky Teachey wrote:
>>
>> But what about `pip install more-itertools`? Hopefully you become
>> comfortable with that a lot faster than 3 years in. If not, the packaging
>> team will probably be disappointed to hear it…
>>
>> (I have occasionally had other people i
On 08/01/2019 01:06 PM, Daniel Okey-Okoro wrote:
[an idea]
Two things:
1) please do not cross-post.
2) a PEP is a very particular thing* -- please do not say you have one unless
you do. ;)
--
~Ethan~
* https://www.python.org/dev/peps/pep-0001/
>
> But what about `pip install more-itertools`? Hopefully you become
> comfortable with that a lot faster than 3 years in. If not, the packaging
> team will probably be disappointed to hear it…
>
> (I have occasionally had other people insist that I shouldn’t tell users
> to pip install things… )
On Thu, Aug 1, 2019 at 12:54 PM Ricky Teachey wrote:
> When I show a novice how to import and use cycle, they they get excited
>> and go off and use it. When I show them how to copy and paste grouper, they
>> sometimes seem reluctant—
>>
>
> TLDR: a beginner can read, understand, and use the iter
On Aug 1, 2019, at 12:52, Ricky Teachey wrote:
>
> TLDR: a beginner can read, understand, and use the itertools module
> incredibly easily. But putting a recipe aside for your own use later? Forget
> it. That took my almost 3 years to get comfortable with.
I can understand that. I could tell y
On 01/08/2019 19:11:18, Guido van Rossum wrote:
Here is someone declaring that the docs are less accessible than the
code. I personally am disappointed, given the amount of effort that we
put in those docs. But maybe this is true. If we can't get people to
peruse the docs, should we bother?
On Fri, Aug 2, 2019 at 6:09 AM Daniel Okey-Okoro
wrote:
>
> I think that adding a `no` keyword as an alias for `not` would make for
> more readable, simple, pythonic code.
The bar for creating new keywords is extremely high. Simply making
your code slightly more like English is not a strong enoug
I think they actually read like they would mean slightly different things,
which would make them existing as aliases confusing.
I read `if not val` as "If val isn't true" but i would read `if no val` as
"if val does not exist"
On Thu, Aug 1, 2019 at 4:07 PM Daniel Okey-Okoro
wrote:
> I think th
>
> When I show a novice how to import and use cycle, they they get excited
> and go off and use it. When I show them how to copy and paste grouper, they
> sometimes seem reluctant—
>
TLDR: a beginner can read, understand, and use the itertools module
incredibly easily. But putting a recipe aside
On Aug 1, 2019, at 10:48, Eli Berkowitz wrote:
>
> In terms of an argument for why it should be included, for most Python users
> the itertools recipes remain unseen.
Sure. But do you also know all of the functions in the module? Would you notice
or a new one got added? In practical terms, how
[Guido]
> ,,,
> I learned something in this thread -- I had no idea that the deque datatype
> even has an option to limit its size (and silently drop older values as new
> ones are added), let alone that the case of setting the size to zero is
> optimized in the C code. But more importantly, I don'
On Aug 1, 2019, at 09:27, Christopher Barker wrote:
>
>
>
>> On Thu, Aug 1, 2019 at 9:19 AM Andrew Barnert via Python-ideas
>> wrote:
>
>> > Given that in 3.x every stdlib module is supposed to be in Python with an
>> > optional C accelerator,
>
> Is this written down somewhere? And when w
On Thu, Aug 1, 2019 at 10:49 AM Eli Berkowitz
wrote:
> In terms of an argument for why it should be included, for most Python
> users the itertools recipes remain unseen. I consider myself relatively
> fluent in Python (not compared to y'all of course) and hadn't seen them
> until I started this
On Thu, Aug 1, 2019 at 10:49 AM Eli Berkowitz
wrote:
> In terms of an argument for why it should be included, for most Python
> users the itertools recipes remain unseen. I consider myself relatively
> fluent in Python (not compared to y'all of course) and hadn't seen them
> until I started this
In terms of an argument for why it should be included, for most Python users
the itertools recipes remain unseen. I consider myself relatively fluent in
Python (not compared to y'all of course) and hadn't seen them until I started
this thread. If I had to hazard a guess, they're probably unused
On Thu, Aug 1, 2019 at 9:19 AM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
>
> Given that in 3.x every stdlib module is supposed to be in Python with an
> optional C accelerator,
>
Is this written down somewhere? And when was that policy decided?
When we added math.is_close
> On Aug 1, 2019, at 00:06, Eli Berkowitz wrote:
>
> These are all fair and good points :)
>
> I really like the idea of writing a function that exhausts an iterator and
> using that. It seems like this should be a part of the itertools package at
> least, maybe called `run`, `do`, or `exhaust
These are all fair and good points :)
I really like the idea of writing a function that exhausts an iterator and
using that. It seems like this should be a part of the itertools package at
least, maybe called `run`, `do`, or `exhaust`.
```
from itertools import run
run(list2.append(item * 6) fo
Agree with Aurelien Lambert: if you call task.cancel() there is no
sense for expecting a normal result from a task.
My typical code for task cancellation looks like
task.cancel()
with contextlib.suppress(asyncio.CancelledError):
await task
If you need a partial task result you probably can bu
22 matches
Mail list logo
