On Jul 30, 2019, at 21:18, Guido van Rossum wrote:
>
> The problem with recommending click or fire is that it doesn't look to me
> like any of those are category killers the way requests became years ago.
Yeah, that’s true.
And honestly, I can’t imagine how any of them _could_ become a categor
I wonder if Nathaniel has something to add? Trio has a different approayto
cancellation. Of course it is also an entirely new library...
On Tue, Jul 30, 2019 at 9:51 PM wrote:
> Oh only now it appears in the list ! I thought the post hadn't working, so
> I posted again :/.
>
> I've fixed my "lib
Oh only now it appears in the list ! I thought the post hadn't working, so I
posted again :/.
I've fixed my "library"
(https://github.com/aure-olli/aiokafka/blob/3acb88d6ece4502a78e230b234f47b90b9d30fd5/syncio.py),
and the `wrapped_consumer2` function. Now no double await, so no risk of
afterw
In asyncio, when a task awaits for another task (or future), it can be
cancelled right after the awaited task finished. Thus, if the awaited task
has consumed data, the data is lost.
For instance, with the following code:
import asyncio
available_data = []
data_ready = asyncio.Future
Ouch, the tutorial definitely should no longer recommend getopt (or
optparse) and just stick to argparse (or sys.argv[1:] if you want simple
:-). I filed newcomer-friendly issue https://bugs.python.org/issue37726.
The problem with recommending click or fire is that it doesn't look to me
like any o
On Jul 30, 2019, at 20:49, Andrew Barnert via Python-ideas
wrote:
>
> There are lots of great third-party libraries that make turning a function
> into a command-line utility a lot easier than using argparse. I think
> whenever you want anything more than argv and don’t want argparse, you shou
On Jul 30, 2019, at 15:21, agustinscaramu...@gmail.com wrote:
>
> Maybe the def __main__() argument is already a dead horse, given the number
> of discussions it has created that have ended nowhere, but I think one
> argument in favour of its implementation would be including argument parsing
>
I think you might find plac[1] and fire[2] rather interesting. I do feel an
explicit __run__ would go against the spirit of "explicit is better than
implicit" a bit...
[1] https://micheles.github.io/plac/
[2] https://github.com/google/python-fire
On Tue, Jul 30, 2019, 8:03 PM wrote:
> Maybe th
Maybe the def __main__() argument is already a dead horse, given the number of
discussions it has created that have ended nowhere, but I think one argument in
favour of its implementation would be including argument parsing in it, for
example:
# main.py
def __run__(first_num, second_num, print_
> On Jul 30, 2019, at 11:38 AM, Guido van Rossum wrote:
>
...
>
> with connect() as stream: # connect() or __enter__() can fail.
> for data in stream: # __next__() can fail
> write(data) # write() can fail
>
> This very much looks like toy networking code to me
Guido van Rossum wrote:
I'm not sure I understand the desire to catch every possible exception
right where it occurs. I've never felt this need somehow.
This is my feeling too. I can't remember having a need for such
needle-sharp targeting of exception catching, and if I ever did,
it would be s
Something I don't like about these kinds of proposals is that
the except clause is far removed from the code that it covers,
hurting readability. By the time you get to the end of a big
for-loop or with-statement and see an "except", it's easy to
forget that it isn't attached to an ordinary try-st
On Tue, Jul 30, 2019 at 1:13 AM Paul Moore wrote:
> On Tue, 30 Jul 2019 at 04:00, Ethan Furman wrote:
> > If this "with...except" leads to more robust code then I think many
> would like to use it, but not if it's confusing as that would lead to less
> robust code.
>
> For me, "it's for robust c
It seems inevitable that if you use await twice you risk being cancelled in
between. The solution is to only use a single await to do all the work,
like asyncio.queue does (and why not use that for your use case?). I don't
think inventing a parallel API of synchronous callbacks is a good idea --
as
On Tue, Jul 30, 2019 at 9:32 AM Rhodri James wrote:
> I've been trying to come up
> with something more like this:
>
>with something_exceptionable() as f:
>do_something_with(f)
>except with SomeException as e:
>handle_exception_in_setup_or_teardown(e)
>except SomeOtherE
On 30/07/2019 02:35, Steven D'Aprano wrote:
On Mon, Jul 29, 2019 at 03:12:21PM +0100, Rhodri James wrote:
I'm afraid I agree with Guido. I don't imagine I will use this feature
very often, and I can see myself making that mistake every time.
Well, if you don't use this feature very often, yo
On 25/07/2019 19.41, Andrew Barnert via Python-ideas wrote:
> On Jul 25, 2019, at 09:46, Batuhan Taskaya wrote:
>> I think it looks very fine when you type {1, 2, 3} * {"a", "b", "c"} and get
>> set(itertools.product({1, 2, 3}, {"a", "b", "c"})). So i am proposing set
>> multiplication implement
I wrote a slightly longer post similar to Guido's, and I'll not bore
you with that. but let me emphasize what I think are the two
important points.
(1) Put it in the devguide and link from the -ideas and corementorship
list blurbs on mail.python.org.
(2) Just go FULL NIKE. do it, one draft, take
In asyncio, when a task awaits for another task (or future), it can be
cancelled right after the awaited task finished (before the callback have been
processed). Thus, if the awaited task has consumed data, the data is lost.
For instance, with the following code:
import asyncio
availab
On Tue, 30 Jul 2019 at 04:00, Ethan Furman wrote:
> If this "with...except" leads to more robust code then I think many would
> like to use it, but not if it's confusing as that would lead to less robust
> code.
For me, "it's for robust code" is sufficient hint that I now remember
what it does
20 matches
Mail list logo
