[Python-Dev] Re: pth file encoding

[Dan Stromberg]

On Wed, Mar 17, 2021 at 1:11 AM Michał Górny  wrote:

> On Wed, 2021-03-17 at 13:55 +0900, Inada Naoki wrote:
> > OK. setuptools doesn't specify encoding at all. So locale-specific
> > encoding is used.
> > We can not fix it in short term.
>
> How about writing paths as bytestrings in the long term?  I think this
> should eliminate the necessity of knowing the correct encoding for
> the filesystem.
>
On Linux and many Unixes, there is no "correct" filesystem encoding.  ASCII
and UTF-8 are probably the most common encodings for individual files,
maybe even large collections of files, but nevertheless, paths are
bytestrings.  Treating paths as UTF-8 works fine for most files, but once
in a while there'll be a filename that fails to convert, and that's not the
fault of the filename.

For example, what happens if you need a file to be named touch "Ma$(echo |
tr '\012' '\361')ana" ?

For a presentation application (for EG), assuming UTF-8 is probably fine,
maybe even a good thing.  But for a filesystem backup tool, it's important
to not assume an encoding so you can back up and restore all filenames
irrespective of what the files' creators intended encodingwise.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HLTFATPMRA57UU3KQOXHIMELZZGXUUJJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merge Request Review Reminder

[Guido van Rossum]

Honestly this is an example of a module that would have been better off
outside the stdlib.

On Fri, Mar 19, 2021 at 14:43 Senthil Kumaran  wrote:

> On Mon, Feb 15, 2021 at 8:36 AM Faisal Mahmood
>  wrote:
> >
> > Hello,
> >
> > I hope you are all well, I currently have an issue / merge request that
> has become stale and as per the guidelines I am sending this e-mail to
> request someone to review it for me please.
> >
> > Issue Number: 42861 (https://bugs.python.org/issue42861)
> > Pull Request: 24180 (https://github.com/python/cpython/pull/24180)
> >
>
> Could you share some motivation references that could help explain why
> this next_network method will be helpful? Is this common enough to
> warrant a method in the stdlib IP-Address module?
> If there is prior-art in other external libraries or libraries of
> other languages, that will be helpful to know and review too.
>
> I had looked at this a month ago when you pinged for review, but I
> could not immediately determine the benefit of having this method in
> stdlib, irrespective of implementation correctness or API Signature.
> I also lack extensive experience with ipv6.
>
> Thanks,
> Senthil
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/OABKRDE2JH2J42DIM2HAIRFDHDF6WFOA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5Q64OGKOMGZQHUZZOAJWG3QJFDZGCNBB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: aiter/anext review request

[Terry Reedy]

On 3/19/2021 6:11 PM, Joshua Bronson wrote:

Discussion here so far is converging on resurrecting my original PR from 
2018 adding these to operator.

I prefer this too.

--
Terry Jan Reedy

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BTHQ5DDLRA4I6UXNCE4ZMUAJULU5LXBS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: aiter/anext review request

[Joshua Bronson]

Thanks for all the feedback so far (and for the kind words, Guido! 😊).

Discussion here so far is converging on resurrecting my original PR from
2018 adding these to operator. Anyone else we should hear from before
considering the more recent PR not worth pursuing for now? Would be good to
hear from Yury given his previous feedback, but seems like he’s been too
busy to respond. Should we wait (for some limited amount of time, in light
of the upcoming 3.10 feature freeze?) for more feedback?

I’m ready to update whichever PR we’re going ahead with, once I know which
one that is.

Thanks,
Josh


On Fri, Mar 19, 2021 at 17:23 Brett Cannon  wrote:

> I personally would be okay with aiter() (with the modern API 😉) and
> next() in the `operator` module. There's already precedent in having things
> there that are rarely used directly but still implement the use of a
> special method, e.g. operator.index() (
> https://docs.python.org/3/library/operator.html#operator.index).
>
> On Fri, Mar 19, 2021 at 10:29 AM Guido van Rossum 
> wrote:
>
>> I assume that one of the concerns is that these functions are trivial.
>> aiter(x) is just x.__aiter__(), and anext(it) is just it.__next__(). I’m
>> not convinced that we need aiter(x, sentinel) at all — for iter() it’s
>> mostly a legacy compatibility API.
>>
>> If you use these a lot it’s simple enough to add one-liners to the top of
>> your module or to your project’s utilities.
>>
>> I also feel (but I may be alone in this) that maybe we went overboard
>> with the design of async for (and async with).
>>
>> That said the work itself is impeccable. While you’re waiting for a
>> resolution you may want to try working on other contributions!
>>
>> —Guido
>>
>> On Fri, Mar 19, 2021 at 09:59 Luciano Ramalho 
>> wrote:
>>
>>> OK, but it seems clear to me that if there are any lingering doubts it
>>> would be better to add the functions to a module than to the built-ins, and
>>> later promote them to built-ins if people actually find them widely useful.
>>>
>>> On the other hand, adding something to built-ins that turns out to be
>>> rarely useful adds unnecessary noise and is much harder to fix later
>>> without causing further problems.
>>>
>>> Best,
>>>
>>> Luciano
>>>
>>>
>>> On Fri, Mar 19, 2021 at 1:22 PM Joshua Bronson 
>>> wrote:
>>>
 Thanks for taking a look at this, Luciano.

 Yury immediately replied 
 to the comment from Jelle that you quoted with the following:

 > Do these really need to be builtins?
>
> We're only beginning to see async iterators being used in the wild, so
> we can't have a definitive answer at this point.
>
> > They seem too specialized to be widely useful; I've personally never
> needed them in any async code I've written. It would make more sense to me
> to put them in a module like operators.
>
> I think putting them to the operators module makes sense, at least for
> 3.8.  Do you want to work on a pull request?



 That was on 2018-06-14. On 2018-08-24, I submitted
 https://github.com/python/cpython/pull/8895, "Add operator.aiter and
 operator.anext". On 2018-09-07, Yury left the following comment
 
 on that PR:

 Please don't merge this yet. I'm not convinced that aiter and anext
> shouldn't be builtins.



 So there has been some back-and-forth on this, and some more years have
 passed, but all the latest signals we've gotten up to now have indicated a
 preference for adding these to builtins.

 In any case, as of my latest PR
 , the Python core
 developers now have both options to choose from.

 As community contributors, is there anything further we can do to help
 drive timely resolution on this one way or another?

 Thanks,
 Josh


 On Fri, Mar 19, 2021 at 11:29 AM Luciano Ramalho 
 wrote:

> Thanks for working on this, Joshua. I agree 100% with Jelle Zijlstra
> in the issue tracker:
>
> Do these really need to be builtins?
>
> They seem too specialized to be widely useful; I've personally never 
> needed them in any async code I've written. It would make more sense to 
> me to put them in a module like operators.
>
>
> (sorry for the weird formatting, posting from an iPad)
>
> On Wed, Mar 17, 2021 at 21:01 Joshua Bronson 
> wrote:
>
>> Dear python-dev,
>>
>> New here (but not to Python). 👋 Brett Cannon recommended I start a
>> thread here (thanks, Brett!).
>>
>> In December, two colleagues and I submitted
>> https://github.com/python/cpython/pull/23847, "Add aiter and anext
>> to builtins", which would fix https://bugs.python.org/issue31861.
>>
>> Would any core developers who may be rea

[Python-Dev] Re: Merge Request Review Reminder

[Senthil Kumaran]

On Mon, Feb 15, 2021 at 8:36 AM Faisal Mahmood
 wrote:
>
> Hello,
>
> I hope you are all well, I currently have an issue / merge request that has 
> become stale and as per the guidelines I am sending this e-mail to request 
> someone to review it for me please.
>
> Issue Number: 42861 (https://bugs.python.org/issue42861)
> Pull Request: 24180 (https://github.com/python/cpython/pull/24180)
>

Could you share some motivation references that could help explain why
this next_network method will be helpful? Is this common enough to
warrant a method in the stdlib IP-Address module?
If there is prior-art in other external libraries or libraries of
other languages, that will be helpful to know and review too.

I had looked at this a month ago when you pinged for review, but I
could not immediately determine the benefit of having this method in
stdlib, irrespective of implementation correctness or API Signature.
I also lack extensive experience with ipv6.

Thanks,
Senthil
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OABKRDE2JH2J42DIM2HAIRFDHDF6WFOA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merge Request Review Reminder

[Brett Cannon]

On Fri, Mar 19, 2021 at 9:29 AM Faisal Mahmood 
wrote:

> Hello,
>
> Following my previous e-mail last month, thank you for responding.  I
> almost immediately got two reviewers who posted helpful comments on my PR
> which I believe have all been resolved now.
>
> Today, I got a notification to say my branch is stale again so wanted to
> understand what the next steps are.
>
> Is there anything else I can do to get my PR merged? This is my first time
> submitting a PR to Cpython so not sure of the workflow, or if I have missed
> something so would appreciate your guidance.
>

At this point it's up to a core dev to have the time and inclination to
look at the PR and either give feedback or to merge it (unfortunately I
personally lack the knowledge to help out with this PR).

-Brett


>
> SIDE QUESTION: Also, when I originally submitted this PR, I used a
> different Git config and user called "KillerKode" - however I was asked to
> change this, which is totally understandable so I changed everything to my
> name, however the commit history of that PR now contains some commits from
> my old Git config (as KillerKode) and some with my new Git config (as
> Faisal Mahmood).  I am wondering, when this gets merged, how can I make
> sure that the commits are squashed and any history of my previous git
> config (i.e. KillerKode) do not show?
>
> Kind regards,
>
> Faisal.
>
> On Mon, 15 Feb 2021 at 14:20, Faisal Mahmood 
> wrote:
>
>> Hello,
>>
>> I hope you are all well, I currently have an issue / merge request that
>> has become stale and as per the guidelines I am sending this e-mail to
>> request someone to review it for me please.
>>
>> Issue Number: 42861 (https://bugs.python.org/issue42861)
>> Pull Request: 24180 (https://github.com/python/cpython/pull/24180)
>>
>> This is my first contribution to CPython and I am very keen to get this
>> added as I think it is an almost essential enhancement missing from the
>> ipaddress module.  I would greatly appreciate if someone can take a look
>> and give me feedback, I am more than happy to help explain things, as I
>> appreciate this is not the most straightforward thing to do.
>>
>> Effectively, this method allows you to get the next closest network of
>> any prefix size, it works by effectively adding 1 to the host portion of
>> the network.  There is actually a very nice guide someone made on
>> stackexchange explaining how to do this calculation manually, I simply
>> followed this logic and have tested it as much as possible and it seems to
>> work great.  See here:
>> https://networkengineering.stackexchange.com/questions/7106/how-do-you-calculate-the-prefix-network-subnet-and-host-numbers/53994#53994
>>
>> Please let me know if there is anything else I can do to help get this
>> merged.
>>
>> Kind regards,
>>
>> Faisal.
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/DUL55S2S5C5AJO33LAPSL7MAOI5Y76WV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7IOSA6ALD42A6SDQX2525UCBTNYTGT2X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: aiter/anext review request

[Brett Cannon]

I personally would be okay with aiter() (with the modern API 😉) and next()
in the `operator` module. There's already precedent in having things there
that are rarely used directly but still implement the use of a special
method, e.g. operator.index() (
https://docs.python.org/3/library/operator.html#operator.index).

On Fri, Mar 19, 2021 at 10:29 AM Guido van Rossum  wrote:

> I assume that one of the concerns is that these functions are trivial.
> aiter(x) is just x.__aiter__(), and anext(it) is just it.__next__(). I’m
> not convinced that we need aiter(x, sentinel) at all — for iter() it’s
> mostly a legacy compatibility API.
>
> If you use these a lot it’s simple enough to add one-liners to the top of
> your module or to your project’s utilities.
>
> I also feel (but I may be alone in this) that maybe we went overboard with
> the design of async for (and async with).
>
> That said the work itself is impeccable. While you’re waiting for a
> resolution you may want to try working on other contributions!
>
> —Guido
>
> On Fri, Mar 19, 2021 at 09:59 Luciano Ramalho  wrote:
>
>> OK, but it seems clear to me that if there are any lingering doubts it
>> would be better to add the functions to a module than to the built-ins, and
>> later promote them to built-ins if people actually find them widely useful.
>>
>> On the other hand, adding something to built-ins that turns out to be
>> rarely useful adds unnecessary noise and is much harder to fix later
>> without causing further problems.
>>
>> Best,
>>
>> Luciano
>>
>>
>> On Fri, Mar 19, 2021 at 1:22 PM Joshua Bronson 
>> wrote:
>>
>>> Thanks for taking a look at this, Luciano.
>>>
>>> Yury immediately replied 
>>> to the comment from Jelle that you quoted with the following:
>>>
>>> > Do these really need to be builtins?

 We're only beginning to see async iterators being used in the wild, so
 we can't have a definitive answer at this point.

 > They seem too specialized to be widely useful; I've personally never
 needed them in any async code I've written. It would make more sense to me
 to put them in a module like operators.

 I think putting them to the operators module makes sense, at least for
 3.8.  Do you want to work on a pull request?
>>>
>>>
>>>
>>> That was on 2018-06-14. On 2018-08-24, I submitted
>>> https://github.com/python/cpython/pull/8895, "Add operator.aiter and
>>> operator.anext". On 2018-09-07, Yury left the following comment
>>> 
>>> on that PR:
>>>
>>> Please don't merge this yet. I'm not convinced that aiter and anext
 shouldn't be builtins.
>>>
>>>
>>>
>>> So there has been some back-and-forth on this, and some more years have
>>> passed, but all the latest signals we've gotten up to now have indicated a
>>> preference for adding these to builtins.
>>>
>>> In any case, as of my latest PR
>>> , the Python core
>>> developers now have both options to choose from.
>>>
>>> As community contributors, is there anything further we can do to help
>>> drive timely resolution on this one way or another?
>>>
>>> Thanks,
>>> Josh
>>>
>>>
>>> On Fri, Mar 19, 2021 at 11:29 AM Luciano Ramalho 
>>> wrote:
>>>
 Thanks for working on this, Joshua. I agree 100% with Jelle Zijlstra
 in the issue tracker:

 Do these really need to be builtins?

 They seem too specialized to be widely useful; I've personally never 
 needed them in any async code I've written. It would make more sense to me 
 to put them in a module like operators.


 (sorry for the weird formatting, posting from an iPad)

 On Wed, Mar 17, 2021 at 21:01 Joshua Bronson 
 wrote:

> Dear python-dev,
>
> New here (but not to Python). 👋 Brett Cannon recommended I start a
> thread here (thanks, Brett!).
>
> In December, two colleagues and I submitted
> https://github.com/python/cpython/pull/23847, "Add aiter and anext to
> builtins", which would fix https://bugs.python.org/issue31861.
>
> Would any core developers who may be reading this be willing and able
> to provide a code review?
>
> We would love to try to address any review feedback before having to
> fix (another round of) merge conflicts. (And ideally maybe even get this
> landed in time for the 3.10 feature freeze in early May?)
>
> Thanks and hope this finds you well.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/5XUVPB5H4PFUGTC5F7KAN4STKAEOFBQM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>

[Python-Dev] Re: Merge Request Review Reminder

[Paul Moore]

On Fri, 19 Mar 2021 at 17:26, Hasan Diwan  wrote:
>
> For the side question,  you can always use rebase instead of merge. Let me 
> know if you need further particulars? -- H

There should be no need though, as the Python project has a policy of
squash-merging all PRs.
Paul
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DZ3QCEDDZTT5H4IAURXD2YSVXJ4VZZLT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: aiter/anext review request

[Joao S. O. Bueno]

On Fri, 19 Mar 2021 at 14:38, Paul Bryan  wrote:

> On Fri, 2021-03-19 at 10:22 -0700, Guido van Rossum wrote:
>
> I’m not convinced that we need aiter(x, sentinel) at all — for iter() it’s
> mostly a legacy compatibility API.
>
>
> I'm feel like I'm going to learn something today. To date, the pattern
> I've used for getting the first item from an iterable:
>
> next(iter(i))
>
>
> What's the recommended alternative?
>

I end up doing this most times:

def first(i):
return next(iter(i))

Seens too simple to request to be in the sdlib, and it is so simple that
would be forgotten if it were
in any 3rd party extension


>
> Paul
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/2XNN6NYR6WXKVQN5UDCPVMY7KRDKF3BG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PVR3LAKIXS24MC5FAUYNERIBDFI6KJKQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2021-03-12 - 2021-03-19)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7481 ( +3)
  closed 47813 (+75)
  total  55294 (+78)

Open issues with patches: 2980 


Issues opened (66)
==

#35943: PyImport_GetModule() can return partially-initialized module
https://bugs.python.org/issue35943  reopened by pitrou

#37788: fix for bpo-36402 (threading._shutdown() race condition) cause
https://bugs.python.org/issue37788  reopened by mark.dickinson

#42161: Remove private _PyLong_Zero and _PyLong_One variables
https://bugs.python.org/issue42161  reopened by rhettinger

#43334: venv does not install libpython
https://bugs.python.org/issue43334  reopened by anuppari

#43439: [security] Add audit events on GC functions giving access to a
https://bugs.python.org/issue43439  reopened by steve.dower

#43481: PyEval_EvalCode() namespace issue not observed in Python 2.7.
https://bugs.python.org/issue43481  opened by chrisgmorton

#43482: Py_AddPendingCall Inserted Function Never Called in 3.8, works
https://bugs.python.org/issue43482  opened by chrisgmorton

#43484: we can create valid datetime objects that become invalid if th
https://bugs.python.org/issue43484  opened by zzzeek

#43486: Python 3.9 installer not updating ARP table
https://bugs.python.org/issue43486  opened by codaamok

#43487: Rename __unicode__ methods to __str__ in 2to3 conversion
https://bugs.python.org/issue43487  opened by bartbroere

#43490: IDLE freezes at random
https://bugs.python.org/issue43490  opened by aledeaux

#43492: Upgrade to SQLite 3.35.2 in macOS and Windows
https://bugs.python.org/issue43492  opened by erlendaasland

#43493: EmailMessage mis-folding headers of a certain length
https://bugs.python.org/issue43493  opened by mglover

#43494: Minor changes to Objects/lnotab_notes.txt
https://bugs.python.org/issue43494  opened by skip.montanaro

#43495: Missing frame block push in compiler_async_comprehension_gener
https://bugs.python.org/issue43495  opened by tomkpz

#43497: SyntaxWarning for "assertion is always true, perhaps remove pa
https://bugs.python.org/issue43497  opened by darke

#43498: "dictionary changed size during iteration" error in _ExecutorM
https://bugs.python.org/issue43498  opened by kulikjak

#43500: Add filtercase() into fnmatch
https://bugs.python.org/issue43500  opened by wyz23x2

#43501: email._header_value_parse throws AttributeError on display nam
https://bugs.python.org/issue43501  opened by elenril

#43502: [C-API] Convert obvious unsafe macros to static inline functio
https://bugs.python.org/issue43502  opened by erlendaasland

#43503: [subinterpreters] PyObject statics exposed in the limited API 
https://bugs.python.org/issue43503  opened by eric.snow

#43504: effbot.org down
https://bugs.python.org/issue43504  opened by mdk

#43505: [sqlite3] Explicitly initialise and shut down sqlite3
https://bugs.python.org/issue43505  opened by erlendaasland

#43508: Miscompilation information for tarfile.open() when given too m
https://bugs.python.org/issue43508  opened by xxm

#43509: CFunctionType object should be hashable in Python
https://bugs.python.org/issue43509  opened by xxm

#43510: PEP 597: Implemente encoding="locale" option and EncodingWarni
https://bugs.python.org/issue43510  opened by methane

#43511: tkinter with Tk 8.6.11 is slow on macOS
https://bugs.python.org/issue43511  opened by thomaswamm

#43513: venv: recreate symlinks on --upgrade
https://bugs.python.org/issue43513  opened by ThiefMaster

#43514: Disallow fork in a subinterpreter affects multiprocessing plug
https://bugs.python.org/issue43514  opened by franku

#43517: Fix false positives in circular import detection with from-imp
https://bugs.python.org/issue43517  opened by pitrou

#43518: textwrap.shorten does not always respect word boundaries
https://bugs.python.org/issue43518  opened by annesylvie

#43520: Fraction only handles regular slashes ("/") and fails with oth
https://bugs.python.org/issue43520  opened by weightwatchers-carlanderson

#43522: SSLContext.hostname_checks_common_name appears to have no effe
https://bugs.python.org/issue43522  opened by Quentin.Pradet

#43523: Handling Ctrl+C while waiting on I/O in Windows
https://bugs.python.org/issue43523  opened by sovetov

#43524: Addition of peek and peekexactly methods to asyncio.StreamRead
https://bugs.python.org/issue43524  opened by awalgarg

#43525: pathlib: Highlight pathlib operator behavior with anchored pat
https://bugs.python.org/issue43525  opened by diegoe

#43526: Programmatic management of BytesWarning doesn't work for nativ
https://bugs.python.org/issue43526  opened by xmorel

#43527: Support full stack trace extraction in warnings.
https://bugs.python.org/issue43527  opened by xmorel

#43528: "connect_read_pipe" raises errors on Windows for STDIN
https://bugs.python.org/issue43528  opened by i

[Python-Dev] Re: aiter/anext review request

[Luciano Ramalho]

I see the value of having `aiter` and `anext` in the standard library,
mostly because we should not encourage people to call dunder methods
themselves unless they are doing something really tricky.

Also, if written in C, those functions may save the attribute fetch
overhead of a method call for asynchronous iterables and iterators written
with the Python/C API.

My feeling is `aiter` and `anext` should go in the operator module, where
we already have lots of functions that are thin wrappers around dunder
methods.

I think the builtin module is already overcrowded. Not advocating to remove
anything, just saying we should think very carefully about adding two more
functions to it.

Cheers,

Luciano

PS. I do think it was a good idea to remove `reduce` from the builtins in
Python 3, as it was often used to do what `sum`, `all`, and `any` do more
easily and efficiently.


On Fri, Mar 19, 2021 at 2:22 PM Guido van Rossum  wrote:

> I assume that one of the concerns is that these functions are trivial.
> aiter(x) is just x.__aiter__(), and anext(it) is just it.__next__(). I’m
> not convinced that we need aiter(x, sentinel) at all — for iter() it’s
> mostly a legacy compatibility API.
>
> If you use these a lot it’s simple enough to add one-liners to the top of
> your module or to your project’s utilities.
>
> I also feel (but I may be alone in this) that maybe we went overboard with
> the design of async for (and async with).
>
> That said the work itself is impeccable. While you’re waiting for a
> resolution you may want to try working on other contributions!
>
> —Guido
>
> On Fri, Mar 19, 2021 at 09:59 Luciano Ramalho  wrote:
>
>> OK, but it seems clear to me that if there are any lingering doubts it
>> would be better to add the functions to a module than to the built-ins, and
>> later promote them to built-ins if people actually find them widely useful.
>>
>> On the other hand, adding something to built-ins that turns out to be
>> rarely useful adds unnecessary noise and is much harder to fix later
>> without causing further problems.
>>
>> Best,
>>
>> Luciano
>>
>>
>> On Fri, Mar 19, 2021 at 1:22 PM Joshua Bronson 
>> wrote:
>>
>>> Thanks for taking a look at this, Luciano.
>>>
>>> Yury immediately replied 
>>> to the comment from Jelle that you quoted with the following:
>>>
>>> > Do these really need to be builtins?

 We're only beginning to see async iterators being used in the wild, so
 we can't have a definitive answer at this point.

 > They seem too specialized to be widely useful; I've personally never
 needed them in any async code I've written. It would make more sense to me
 to put them in a module like operators.

 I think putting them to the operators module makes sense, at least for
 3.8.  Do you want to work on a pull request?
>>>
>>>
>>>
>>> That was on 2018-06-14. On 2018-08-24, I submitted
>>> https://github.com/python/cpython/pull/8895, "Add operator.aiter and
>>> operator.anext". On 2018-09-07, Yury left the following comment
>>> 
>>> on that PR:
>>>
>>> Please don't merge this yet. I'm not convinced that aiter and anext
 shouldn't be builtins.
>>>
>>>
>>>
>>> So there has been some back-and-forth on this, and some more years have
>>> passed, but all the latest signals we've gotten up to now have indicated a
>>> preference for adding these to builtins.
>>>
>>> In any case, as of my latest PR
>>> , the Python core
>>> developers now have both options to choose from.
>>>
>>> As community contributors, is there anything further we can do to help
>>> drive timely resolution on this one way or another?
>>>
>>> Thanks,
>>> Josh
>>>
>>>
>>> On Fri, Mar 19, 2021 at 11:29 AM Luciano Ramalho 
>>> wrote:
>>>
 Thanks for working on this, Joshua. I agree 100% with Jelle Zijlstra
 in the issue tracker:

 Do these really need to be builtins?

 They seem too specialized to be widely useful; I've personally never 
 needed them in any async code I've written. It would make more sense to me 
 to put them in a module like operators.


 (sorry for the weird formatting, posting from an iPad)

 On Wed, Mar 17, 2021 at 21:01 Joshua Bronson 
 wrote:

> Dear python-dev,
>
> New here (but not to Python). 👋 Brett Cannon recommended I start a
> thread here (thanks, Brett!).
>
> In December, two colleagues and I submitted
> https://github.com/python/cpython/pull/23847, "Add aiter and anext to
> builtins", which would fix https://bugs.python.org/issue31861.
>
> Would any core developers who may be reading this be willing and able
> to provide a code review?
>
> We would love to try to address any review feedback before having to
> fix (another round of) merge conflicts. (And ideally maybe even get 

[Python-Dev] Re: aiter/anext review request

[Paul Bryan]

I did learn something today! 🙂

On Fri, 2021-03-19 at 10:37 -0700, Guido van Rossum wrote:
> I was only talking about the two-argument version, iter(x, sentinel).
> Betcha you didn’t even know that existed. :-)
> 
> On Fri, Mar 19, 2021 at 10:34 Paul Bryan  wrote:
> > On Fri, 2021-03-19 at 10:22 -0700, Guido van Rossum wrote:
> > 
> > > I’m not convinced that we need aiter(x, sentinel) at all — for
> > > iter() it’s mostly a legacy compatibility API.
> > 
> > 
> > I'm feel like I'm going to learn something today. To date, the
> > pattern I've used for getting the first item from an iterable:
> > 
> > next(iter(i))
> > 
> > 
> > What's the recommended alternative?
> > 
> > Paul
> > 

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4DTORCDVGMSPZ3TXEMZ3EYAVJ3GLJEUZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: aiter/anext review request

[Guido van Rossum]

I was only talking about the two-argument version, iter(x, sentinel).
Betcha you didn’t even know that existed. :-)

On Fri, Mar 19, 2021 at 10:34 Paul Bryan  wrote:

> On Fri, 2021-03-19 at 10:22 -0700, Guido van Rossum wrote:
>
> I’m not convinced that we need aiter(x, sentinel) at all — for iter() it’s
> mostly a legacy compatibility API.
>
>
> I'm feel like I'm going to learn something today. To date, the pattern
> I've used for getting the first item from an iterable:
>
> next(iter(i))
>
>
> What's the recommended alternative?
>
> Paul
>
> --
--Guido (mobile)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/54OFTLLED2F47R7KHDDT6ZATNT4FGNHG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: aiter/anext review request

[Paul Bryan]

On Fri, 2021-03-19 at 10:22 -0700, Guido van Rossum wrote:

> I’m not convinced that we need aiter(x, sentinel) at all — for iter()
> it’s mostly a legacy compatibility API.

I'm feel like I'm going to learn something today. To date, the pattern
I've used for getting the first item from an iterable:

next(iter(i))

What's the recommended alternative?

Paul

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2XNN6NYR6WXKVQN5UDCPVMY7KRDKF3BG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: aiter/anext review request

[Guido van Rossum]

No, and there shouldn’t be written criteria. That would just give people
more incentive to argue forever.

On Fri, Mar 19, 2021 at 10:12 Luciano Ramalho  wrote:

> Now is a good time to ask: what are the criteria for adding functions to
> the builtins module?
>
> Is there a written record of those criteria?
>
> Thanks!
>
>
> On Fri, Mar 19, 2021 at 1:55 PM Luciano Ramalho 
> wrote:
>
>> OK, but it seems clear to me that if there are any lingering doubts it
>> would be better to add the functions to a module than to the built-ins, and
>> later promote them to built-ins if people actually find them widely useful.
>>
>> On the other hand, adding something to built-ins that turns out to be
>> rarely useful adds unnecessary noise and is much harder to fix later
>> without causing further problems.
>>
>> Best,
>>
>> Luciano
>>
>>
>> On Fri, Mar 19, 2021 at 1:22 PM Joshua Bronson 
>> wrote:
>>
>>> Thanks for taking a look at this, Luciano.
>>>
>>> Yury immediately replied 
>>> to the comment from Jelle that you quoted with the following:
>>>
>>> > Do these really need to be builtins?

 We're only beginning to see async iterators being used in the wild, so
 we can't have a definitive answer at this point.

 > They seem too specialized to be widely useful; I've personally never
 needed them in any async code I've written. It would make more sense to me
 to put them in a module like operators.

 I think putting them to the operators module makes sense, at least for
 3.8.  Do you want to work on a pull request?
>>>
>>>
>>>
>>> That was on 2018-06-14. On 2018-08-24, I submitted
>>> https://github.com/python/cpython/pull/8895, "Add operator.aiter and
>>> operator.anext". On 2018-09-07, Yury left the following comment
>>> 
>>> on that PR:
>>>
>>> Please don't merge this yet. I'm not convinced that aiter and anext
 shouldn't be builtins.
>>>
>>>
>>>
>>> So there has been some back-and-forth on this, and some more years have
>>> passed, but all the latest signals we've gotten up to now have indicated a
>>> preference for adding these to builtins.
>>>
>>> In any case, as of my latest PR
>>> , the Python core
>>> developers now have both options to choose from.
>>>
>>> As community contributors, is there anything further we can do to help
>>> drive timely resolution on this one way or another?
>>>
>>> Thanks,
>>> Josh
>>>
>>>
>>> On Fri, Mar 19, 2021 at 11:29 AM Luciano Ramalho 
>>> wrote:
>>>
 Thanks for working on this, Joshua. I agree 100% with Jelle Zijlstra
 in the issue tracker:

 Do these really need to be builtins?

 They seem too specialized to be widely useful; I've personally never 
 needed them in any async code I've written. It would make more sense to me 
 to put them in a module like operators.


 (sorry for the weird formatting, posting from an iPad)

 On Wed, Mar 17, 2021 at 21:01 Joshua Bronson 
 wrote:

> Dear python-dev,
>
> New here (but not to Python). 👋 Brett Cannon recommended I start a
> thread here (thanks, Brett!).
>
> In December, two colleagues and I submitted
> https://github.com/python/cpython/pull/23847, "Add aiter and anext to
> builtins", which would fix https://bugs.python.org/issue31861.
>
> Would any core developers who may be reading this be willing and able
> to provide a code review?
>
> We would love to try to address any review feedback before having to
> fix (another round of) merge conflicts. (And ideally maybe even get this
> landed in time for the 3.10 feature freeze in early May?)
>
> Thanks and hope this finds you well.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/5XUVPB5H4PFUGTC5F7KAN4STKAEOFBQM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
 --
 Luciano Ramalho
 |  Author of Fluent Python (O'Reilly, 2015)
 | http://shop.oreilly.com/product/0636920032519.do
 |  Technical Principal at ThoughtWorks
 |  Twitter: @ramalhoorg

>>>
>>
>> --
>> Luciano Ramalho
>> |  Author of Fluent Python (O'Reilly, 2015)
>> | http://shop.oreilly.com/product/0636920032519.do
>> |  Technical Principal at ThoughtWorks
>> |  Twitter: @ramalhoorg
>>
>
>
> --
> Luciano Ramalho
> |  Author of Fluent Python (O'Reilly, 2015)
> | http://shop.oreilly.com/product/0636920032519.do
> |  Technical Principal at ThoughtWorks
> |  Twitter: @ramalhoorg
> ___
> Python-Dev mailing list -- pyth

[Python-Dev] Re: aiter/anext review request

[Guido van Rossum]

I assume that one of the concerns is that these functions are trivial.
aiter(x) is just x.__aiter__(), and anext(it) is just it.__next__(). I’m
not convinced that we need aiter(x, sentinel) at all — for iter() it’s
mostly a legacy compatibility API.

If you use these a lot it’s simple enough to add one-liners to the top of
your module or to your project’s utilities.

I also feel (but I may be alone in this) that maybe we went overboard with
the design of async for (and async with).

That said the work itself is impeccable. While you’re waiting for a
resolution you may want to try working on other contributions!

—Guido

On Fri, Mar 19, 2021 at 09:59 Luciano Ramalho  wrote:

> OK, but it seems clear to me that if there are any lingering doubts it
> would be better to add the functions to a module than to the built-ins, and
> later promote them to built-ins if people actually find them widely useful.
>
> On the other hand, adding something to built-ins that turns out to be
> rarely useful adds unnecessary noise and is much harder to fix later
> without causing further problems.
>
> Best,
>
> Luciano
>
>
> On Fri, Mar 19, 2021 at 1:22 PM Joshua Bronson 
> wrote:
>
>> Thanks for taking a look at this, Luciano.
>>
>> Yury immediately replied 
>> to the comment from Jelle that you quoted with the following:
>>
>> > Do these really need to be builtins?
>>>
>>> We're only beginning to see async iterators being used in the wild, so
>>> we can't have a definitive answer at this point.
>>>
>>> > They seem too specialized to be widely useful; I've personally never
>>> needed them in any async code I've written. It would make more sense to me
>>> to put them in a module like operators.
>>>
>>> I think putting them to the operators module makes sense, at least for
>>> 3.8.  Do you want to work on a pull request?
>>
>>
>>
>> That was on 2018-06-14. On 2018-08-24, I submitted
>> https://github.com/python/cpython/pull/8895, "Add operator.aiter and
>> operator.anext". On 2018-09-07, Yury left the following comment
>> 
>> on that PR:
>>
>> Please don't merge this yet. I'm not convinced that aiter and anext
>>> shouldn't be builtins.
>>
>>
>>
>> So there has been some back-and-forth on this, and some more years have
>> passed, but all the latest signals we've gotten up to now have indicated a
>> preference for adding these to builtins.
>>
>> In any case, as of my latest PR
>> , the Python core
>> developers now have both options to choose from.
>>
>> As community contributors, is there anything further we can do to help
>> drive timely resolution on this one way or another?
>>
>> Thanks,
>> Josh
>>
>>
>> On Fri, Mar 19, 2021 at 11:29 AM Luciano Ramalho 
>> wrote:
>>
>>> Thanks for working on this, Joshua. I agree 100% with Jelle Zijlstra in
>>> the issue tracker:
>>>
>>> Do these really need to be builtins?
>>>
>>> They seem too specialized to be widely useful; I've personally never needed 
>>> them in any async code I've written. It would make more sense to me to put 
>>> them in a module like operators.
>>>
>>>
>>> (sorry for the weird formatting, posting from an iPad)
>>>
>>> On Wed, Mar 17, 2021 at 21:01 Joshua Bronson 
>>> wrote:
>>>
 Dear python-dev,

 New here (but not to Python). 👋 Brett Cannon recommended I start a
 thread here (thanks, Brett!).

 In December, two colleagues and I submitted
 https://github.com/python/cpython/pull/23847, "Add aiter and anext to
 builtins", which would fix https://bugs.python.org/issue31861.

 Would any core developers who may be reading this be willing and able
 to provide a code review?

 We would love to try to address any review feedback before having to
 fix (another round of) merge conflicts. (And ideally maybe even get this
 landed in time for the 3.10 feature freeze in early May?)

 Thanks and hope this finds you well.
 ___
 Python-Dev mailing list -- python-dev@python.org
 To unsubscribe send an email to python-dev-le...@python.org
 https://mail.python.org/mailman3/lists/python-dev.python.org/
 Message archived at
 https://mail.python.org/archives/list/python-dev@python.org/message/5XUVPB5H4PFUGTC5F7KAN4STKAEOFBQM/
 Code of Conduct: http://python.org/psf/codeofconduct/

>>> --
>>> Luciano Ramalho
>>> |  Author of Fluent Python (O'Reilly, 2015)
>>> | http://shop.oreilly.com/product/0636920032519.do
>>> |  Technical Principal at ThoughtWorks
>>> |  Twitter: @ramalhoorg
>>>
>>
>
> --
> Luciano Ramalho
> |  Author of Fluent Python (O'Reilly, 2015)
> | http://shop.oreilly.com/product/0636920032519.do
> |  Technical Principal at ThoughtWorks
> |  Twitter: @ramalhoorg
> ___
> Python-Dev mailing list -- python-dev@python.org
> To 

[Python-Dev] Re: aiter/anext review request

[Paul Bryan]

Sample size of 1: I have code calling __aiter__ and __anext__. It would
be nice to have representative functions—in some module—for the 3.10
release.

I would think the bar for inclusion in builtins should be quite high.
Looking at what's in the operator module, it does seem like a more
appropriate location than builtins; if setitem doesn't warrant
inclusion in builtins, hard to justify aiter and anext.

Paul

On Fri, 2021-03-19 at 13:55 -0300, Luciano Ramalho wrote:
> OK, but it seems clear to me that if there are any lingering doubts
> it would be better to add the functions to a module than to the
> built-ins, and later promote them to built-ins if people actually
> find them widely useful.
> 
> On the other hand, adding something to built-ins that turns out to be
> rarely useful adds unnecessary noise and is much harder to fix later
> without causing further problems.
> 
> Best,
> 
> Luciano
> 
> 
> On Fri, Mar 19, 2021 at 1:22 PM Joshua Bronson 
> wrote:
> > Thanks for taking a look at this, Luciano.
> > 
> > Yury immediately replied to the comment from Jelle that you quoted
> > with the following:
> > 
> > > > Do these really need to be builtins?
> > > 
> > > We're only beginning to see async iterators being used in the
> > > wild, so we can't have a definitive answer at this point.
> > > 
> > > > They seem too specialized to be widely useful; I've personally
> > > never needed them in any async code I've written. It would make
> > > more sense to me to put them in a module like operators.
> > > 
> > > I think putting them to the operators module makes sense, at
> > > least for 3.8.  Do you want to work on a pull request?
> > > 
> > 
> > 
> > 
> > That was on 2018-06-14. On 2018-08-24, I
> > submitted https://github.com/python/cpython/pull/8895, "Add
> > operator.aiter and operator.anext". On 2018-09-07, Yury left the
> > following comment on that PR:
> > 
> > > Please don't merge this yet. I'm not convinced that aiter and
> > > anext shouldn't be builtins.
> > > 
> > 
> > 
> > 
> > So there has been some back-and-forth on this, and some more years
> > have passed, but all the latest signals we've gotten up to now have
> > indicated a preference for adding these to builtins.
> > 
> > In any case, as of my latest PR, the Python core developers now
> > have both options to choose from.
> > 
> > As community contributors, is there anything further we can do to
> > help drive timely resolution on this one way or another?
> > 
> > Thanks,
> > Josh
> > 
> > 
> > On Fri, Mar 19, 2021 at 11:29 AM Luciano Ramalho
> >  wrote:
> > > Thanks for working on this, Joshua. I agree 100% with Jelle
> > > Zijlstra in the issue tracker:
> > > 
> > > Do these really need to be builtins?
> > > 
> > > They seem too specialized to be widely useful; I've personally
> > > never needed them in any async code I've written. It would make
> > > more sense to me to put them in a module like operators.
> > > 
> > > (sorry for the weird formatting, posting from an iPad)
> > > 
> > > On Wed, Mar 17, 2021 at 21:01 Joshua Bronson
> > >  wrote:
> > > > Dear python-dev,
> > > > 
> > > > New here (but not to Python). 👋 Brett Cannon recommended I
> > > > start a thread here (thanks, Brett!).
> > > > 
> > > > In December, two colleagues and I submitted
> > > > https://github.com/python/cpython/pull/23847, "Add aiter and
> > > > anext to builtins", which would fix
> > > > https://bugs.python.org/issue31861.
> > > > 
> > > > Would any core developers who may be reading this be willing
> > > > and able to provide a code review?
> > > > 
> > > > We would love to try to address any review feedback before
> > > > having to fix (another round of) merge conflicts. (And ideally
> > > > maybe even get this landed in time for the 3.10 feature freeze
> > > > in early May?)
> > > > 
> > > > Thanks and hope this finds you well.
> > > > ___
> > > > Python-Dev mailing list -- python-dev@python.org
> > > > To unsubscribe send an email to python-dev-le...@python.org
> > > > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > > > Message archived at
> > > >
> > >
> >
> https://mail.python.org/archives/list/python-dev@python.org/message/5XUVPB5H4PFUGTC5F7KAN4STKAEOFBQM/
> > > > Code of Conduct: http://python.org/psf/codeofconduct/
> > > -- 
> > > Luciano Ramalho
> > > |  Author of Fluent Python (O'Reilly, 2015)
> > > |     http://shop.oreilly.com/product/0636920032519.do
> > > |  Technical Principal at ThoughtWorks
> > > |  Twitter: @ramalhoorg
> 
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/R3I7WIXNZNVA534XFABDQJRHHKRB6X2S/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Pyt

[Python-Dev] Re: Merge Request Review Reminder

[Hasan Diwan]

For the side question,  you can always use rebase instead of merge. Let me
know if you need further particulars? -- H

On Fri, 19 Mar 2021 at 09:31, Faisal Mahmood 
wrote:

> Hello,
>
> Following my previous e-mail last month, thank you for responding.  I
> almost immediately got two reviewers who posted helpful comments on my PR
> which I believe have all been resolved now.
>
> Today, I got a notification to say my branch is stale again so wanted to
> understand what the next steps are.
>
> Is there anything else I can do to get my PR merged? This is my first time
> submitting a PR to Cpython so not sure of the workflow, or if I have missed
> something so would appreciate your guidance.
>
> SIDE QUESTION: Also, when I originally submitted this PR, I used a
> different Git config and user called "KillerKode" - however I was asked to
> change this, which is totally understandable so I changed everything to my
> name, however the commit history of that PR now contains some commits from
> my old Git config (as KillerKode) and some with my new Git config (as
> Faisal Mahmood).  I am wondering, when this gets merged, how can I make
> sure that the commits are squashed and any history of my previous git
> config (i.e. KillerKode) do not show?
>
> Kind regards,
>
> Faisal.
>
> On Mon, 15 Feb 2021 at 14:20, Faisal Mahmood 
> wrote:
>
>> Hello,
>>
>> I hope you are all well, I currently have an issue / merge request that
>> has become stale and as per the guidelines I am sending this e-mail to
>> request someone to review it for me please.
>>
>> Issue Number: 42861 (https://bugs.python.org/issue42861)
>> Pull Request: 24180 (https://github.com/python/cpython/pull/24180)
>>
>> This is my first contribution to CPython and I am very keen to get this
>> added as I think it is an almost essential enhancement missing from the
>> ipaddress module.  I would greatly appreciate if someone can take a look
>> and give me feedback, I am more than happy to help explain things, as I
>> appreciate this is not the most straightforward thing to do.
>>
>> Effectively, this method allows you to get the next closest network of
>> any prefix size, it works by effectively adding 1 to the host portion of
>> the network.  There is actually a very nice guide someone made on
>> stackexchange explaining how to do this calculation manually, I simply
>> followed this logic and have tested it as much as possible and it seems to
>> work great.  See here:
>> https://networkengineering.stackexchange.com/questions/7106/how-do-you-calculate-the-prefix-network-subnet-and-host-numbers/53994#53994
>>
>> Please let me know if there is anything else I can do to help get this
>> merged.
>>
>> Kind regards,
>>
>> Faisal.
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/DUL55S2S5C5AJO33LAPSL7MAOI5Y76WV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
OpenPGP: https://hasan.d8u.us/openpgp.asc
If you wish to request my time, please do so using
*bit.ly/hd1AppointmentRequest
*.
Si vous voudrais faire connnaisance, allez a *bit.ly/hd1AppointmentRequest
*.

Sent
from my mobile device
Envoye de mon portable
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GNU2ZYFMDAMJURLZ7ECH5T5ZI7BG5V5R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: aiter/anext review request

[Luciano Ramalho]

Now is a good time to ask: what are the criteria for adding functions to
the builtins module?

Is there a written record of those criteria?

Thanks!


On Fri, Mar 19, 2021 at 1:55 PM Luciano Ramalho  wrote:

> OK, but it seems clear to me that if there are any lingering doubts it
> would be better to add the functions to a module than to the built-ins, and
> later promote them to built-ins if people actually find them widely useful.
>
> On the other hand, adding something to built-ins that turns out to be
> rarely useful adds unnecessary noise and is much harder to fix later
> without causing further problems.
>
> Best,
>
> Luciano
>
>
> On Fri, Mar 19, 2021 at 1:22 PM Joshua Bronson 
> wrote:
>
>> Thanks for taking a look at this, Luciano.
>>
>> Yury immediately replied 
>> to the comment from Jelle that you quoted with the following:
>>
>> > Do these really need to be builtins?
>>>
>>> We're only beginning to see async iterators being used in the wild, so
>>> we can't have a definitive answer at this point.
>>>
>>> > They seem too specialized to be widely useful; I've personally never
>>> needed them in any async code I've written. It would make more sense to me
>>> to put them in a module like operators.
>>>
>>> I think putting them to the operators module makes sense, at least for
>>> 3.8.  Do you want to work on a pull request?
>>
>>
>>
>> That was on 2018-06-14. On 2018-08-24, I submitted
>> https://github.com/python/cpython/pull/8895, "Add operator.aiter and
>> operator.anext". On 2018-09-07, Yury left the following comment
>> 
>> on that PR:
>>
>> Please don't merge this yet. I'm not convinced that aiter and anext
>>> shouldn't be builtins.
>>
>>
>>
>> So there has been some back-and-forth on this, and some more years have
>> passed, but all the latest signals we've gotten up to now have indicated a
>> preference for adding these to builtins.
>>
>> In any case, as of my latest PR
>> , the Python core
>> developers now have both options to choose from.
>>
>> As community contributors, is there anything further we can do to help
>> drive timely resolution on this one way or another?
>>
>> Thanks,
>> Josh
>>
>>
>> On Fri, Mar 19, 2021 at 11:29 AM Luciano Ramalho 
>> wrote:
>>
>>> Thanks for working on this, Joshua. I agree 100% with Jelle Zijlstra in
>>> the issue tracker:
>>>
>>> Do these really need to be builtins?
>>>
>>> They seem too specialized to be widely useful; I've personally never needed 
>>> them in any async code I've written. It would make more sense to me to put 
>>> them in a module like operators.
>>>
>>>
>>> (sorry for the weird formatting, posting from an iPad)
>>>
>>> On Wed, Mar 17, 2021 at 21:01 Joshua Bronson 
>>> wrote:
>>>
 Dear python-dev,

 New here (but not to Python). 👋 Brett Cannon recommended I start a
 thread here (thanks, Brett!).

 In December, two colleagues and I submitted
 https://github.com/python/cpython/pull/23847, "Add aiter and anext to
 builtins", which would fix https://bugs.python.org/issue31861.

 Would any core developers who may be reading this be willing and able
 to provide a code review?

 We would love to try to address any review feedback before having to
 fix (another round of) merge conflicts. (And ideally maybe even get this
 landed in time for the 3.10 feature freeze in early May?)

 Thanks and hope this finds you well.
 ___
 Python-Dev mailing list -- python-dev@python.org
 To unsubscribe send an email to python-dev-le...@python.org
 https://mail.python.org/mailman3/lists/python-dev.python.org/
 Message archived at
 https://mail.python.org/archives/list/python-dev@python.org/message/5XUVPB5H4PFUGTC5F7KAN4STKAEOFBQM/
 Code of Conduct: http://python.org/psf/codeofconduct/

>>> --
>>> Luciano Ramalho
>>> |  Author of Fluent Python (O'Reilly, 2015)
>>> | http://shop.oreilly.com/product/0636920032519.do
>>> |  Technical Principal at ThoughtWorks
>>> |  Twitter: @ramalhoorg
>>>
>>
>
> --
> Luciano Ramalho
> |  Author of Fluent Python (O'Reilly, 2015)
> | http://shop.oreilly.com/product/0636920032519.do
> |  Technical Principal at ThoughtWorks
> |  Twitter: @ramalhoorg
>


-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/U6XHIDU43A2WGEUU5PCMH6SHD6NXQ273/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: aiter/anext review request

[Luciano Ramalho]

OK, but it seems clear to me that if there are any lingering doubts it
would be better to add the functions to a module than to the built-ins, and
later promote them to built-ins if people actually find them widely useful.

On the other hand, adding something to built-ins that turns out to be
rarely useful adds unnecessary noise and is much harder to fix later
without causing further problems.

Best,

Luciano


On Fri, Mar 19, 2021 at 1:22 PM Joshua Bronson  wrote:

> Thanks for taking a look at this, Luciano.
>
> Yury immediately replied 
> to the comment from Jelle that you quoted with the following:
>
> > Do these really need to be builtins?
>>
>> We're only beginning to see async iterators being used in the wild, so we
>> can't have a definitive answer at this point.
>>
>> > They seem too specialized to be widely useful; I've personally never
>> needed them in any async code I've written. It would make more sense to me
>> to put them in a module like operators.
>>
>> I think putting them to the operators module makes sense, at least for
>> 3.8.  Do you want to work on a pull request?
>
>
>
> That was on 2018-06-14. On 2018-08-24, I submitted
> https://github.com/python/cpython/pull/8895, "Add operator.aiter and
> operator.anext". On 2018-09-07, Yury left the following comment
> 
> on that PR:
>
> Please don't merge this yet. I'm not convinced that aiter and anext
>> shouldn't be builtins.
>
>
>
> So there has been some back-and-forth on this, and some more years have
> passed, but all the latest signals we've gotten up to now have indicated a
> preference for adding these to builtins.
>
> In any case, as of my latest PR
> , the Python core
> developers now have both options to choose from.
>
> As community contributors, is there anything further we can do to help
> drive timely resolution on this one way or another?
>
> Thanks,
> Josh
>
>
> On Fri, Mar 19, 2021 at 11:29 AM Luciano Ramalho 
> wrote:
>
>> Thanks for working on this, Joshua. I agree 100% with Jelle Zijlstra in
>> the issue tracker:
>>
>> Do these really need to be builtins?
>>
>> They seem too specialized to be widely useful; I've personally never needed 
>> them in any async code I've written. It would make more sense to me to put 
>> them in a module like operators.
>>
>>
>> (sorry for the weird formatting, posting from an iPad)
>>
>> On Wed, Mar 17, 2021 at 21:01 Joshua Bronson  wrote:
>>
>>> Dear python-dev,
>>>
>>> New here (but not to Python). 👋 Brett Cannon recommended I start a
>>> thread here (thanks, Brett!).
>>>
>>> In December, two colleagues and I submitted
>>> https://github.com/python/cpython/pull/23847, "Add aiter and anext to
>>> builtins", which would fix https://bugs.python.org/issue31861.
>>>
>>> Would any core developers who may be reading this be willing and able to
>>> provide a code review?
>>>
>>> We would love to try to address any review feedback before having to fix
>>> (another round of) merge conflicts. (And ideally maybe even get this landed
>>> in time for the 3.10 feature freeze in early May?)
>>>
>>> Thanks and hope this finds you well.
>>> ___
>>> Python-Dev mailing list -- python-dev@python.org
>>> To unsubscribe send an email to python-dev-le...@python.org
>>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>>> Message archived at
>>> https://mail.python.org/archives/list/python-dev@python.org/message/5XUVPB5H4PFUGTC5F7KAN4STKAEOFBQM/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>> --
>> Luciano Ramalho
>> |  Author of Fluent Python (O'Reilly, 2015)
>> | http://shop.oreilly.com/product/0636920032519.do
>> |  Technical Principal at ThoughtWorks
>> |  Twitter: @ramalhoorg
>>
>

-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/R3I7WIXNZNVA534XFABDQJRHHKRB6X2S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: aiter/anext review request

[Joshua Bronson]

Thanks for taking a look at this, Luciano.

Yury immediately replied  to
the comment from Jelle that you quoted with the following:

> Do these really need to be builtins?
>
> We're only beginning to see async iterators being used in the wild, so we
> can't have a definitive answer at this point.
>
> > They seem too specialized to be widely useful; I've personally never
> needed them in any async code I've written. It would make more sense to me
> to put them in a module like operators.
>
> I think putting them to the operators module makes sense, at least for
> 3.8.  Do you want to work on a pull request?



That was on 2018-06-14. On 2018-08-24, I submitted
https://github.com/python/cpython/pull/8895, "Add operator.aiter and
operator.anext". On 2018-09-07, Yury left the following comment

on that PR:

Please don't merge this yet. I'm not convinced that aiter and anext
> shouldn't be builtins.



So there has been some back-and-forth on this, and some more years have
passed, but all the latest signals we've gotten up to now have indicated a
preference for adding these to builtins.

In any case, as of my latest PR
, the Python core developers
now have both options to choose from.

As community contributors, is there anything further we can do to help
drive timely resolution on this one way or another?

Thanks,
Josh


On Fri, Mar 19, 2021 at 11:29 AM Luciano Ramalho 
wrote:

> Thanks for working on this, Joshua. I agree 100% with Jelle Zijlstra in
> the issue tracker:
>
> Do these really need to be builtins?
>
> They seem too specialized to be widely useful; I've personally never needed 
> them in any async code I've written. It would make more sense to me to put 
> them in a module like operators.
>
>
> (sorry for the weird formatting, posting from an iPad)
>
> On Wed, Mar 17, 2021 at 21:01 Joshua Bronson  wrote:
>
>> Dear python-dev,
>>
>> New here (but not to Python). 👋 Brett Cannon recommended I start a
>> thread here (thanks, Brett!).
>>
>> In December, two colleagues and I submitted
>> https://github.com/python/cpython/pull/23847, "Add aiter and anext to
>> builtins", which would fix https://bugs.python.org/issue31861.
>>
>> Would any core developers who may be reading this be willing and able to
>> provide a code review?
>>
>> We would love to try to address any review feedback before having to fix
>> (another round of) merge conflicts. (And ideally maybe even get this landed
>> in time for the 3.10 feature freeze in early May?)
>>
>> Thanks and hope this finds you well.
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/5XUVPB5H4PFUGTC5F7KAN4STKAEOFBQM/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> --
> Luciano Ramalho
> |  Author of Fluent Python (O'Reilly, 2015)
> | http://shop.oreilly.com/product/0636920032519.do
> |  Technical Principal at ThoughtWorks
> |  Twitter: @ramalhoorg
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GBB2HTTDIYVWQ5ETUTTV34BL73FGWWKV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merge Request Review Reminder

[Faisal Mahmood]

Hello,

Following my previous e-mail last month, thank you for responding.  I
almost immediately got two reviewers who posted helpful comments on my PR
which I believe have all been resolved now.

Today, I got a notification to say my branch is stale again so wanted to
understand what the next steps are.

Is there anything else I can do to get my PR merged? This is my first time
submitting a PR to Cpython so not sure of the workflow, or if I have missed
something so would appreciate your guidance.

SIDE QUESTION: Also, when I originally submitted this PR, I used a
different Git config and user called "KillerKode" - however I was asked to
change this, which is totally understandable so I changed everything to my
name, however the commit history of that PR now contains some commits from
my old Git config (as KillerKode) and some with my new Git config (as
Faisal Mahmood).  I am wondering, when this gets merged, how can I make
sure that the commits are squashed and any history of my previous git
config (i.e. KillerKode) do not show?

Kind regards,

Faisal.

On Mon, 15 Feb 2021 at 14:20, Faisal Mahmood 
wrote:

> Hello,
>
> I hope you are all well, I currently have an issue / merge request that
> has become stale and as per the guidelines I am sending this e-mail to
> request someone to review it for me please.
>
> Issue Number: 42861 (https://bugs.python.org/issue42861)
> Pull Request: 24180 (https://github.com/python/cpython/pull/24180)
>
> This is my first contribution to CPython and I am very keen to get this
> added as I think it is an almost essential enhancement missing from the
> ipaddress module.  I would greatly appreciate if someone can take a look
> and give me feedback, I am more than happy to help explain things, as I
> appreciate this is not the most straightforward thing to do.
>
> Effectively, this method allows you to get the next closest network of any
> prefix size, it works by effectively adding 1 to the host portion of the
> network.  There is actually a very nice guide someone made on stackexchange
> explaining how to do this calculation manually, I simply followed this
> logic and have tested it as much as possible and it seems to work great.
> See here:
> https://networkengineering.stackexchange.com/questions/7106/how-do-you-calculate-the-prefix-network-subnet-and-host-numbers/53994#53994
>
> Please let me know if there is anything else I can do to help get this
> merged.
>
> Kind regards,
>
> Faisal.
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DUL55S2S5C5AJO33LAPSL7MAOI5Y76WV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: aiter/anext review request

[Luciano Ramalho]

Thanks for working on this, Joshua. I agree 100% with Jelle Zijlstra in the
issue tracker:

Do these really need to be builtins?

They seem too specialized to be widely useful; I've personally never
needed them in any async code I've written. It would make more sense
to me to put them in a module like operators.


(sorry for the weird formatting, posting from an iPad)

On Wed, Mar 17, 2021 at 21:01 Joshua Bronson  wrote:

> Dear python-dev,
>
> New here (but not to Python). 👋 Brett Cannon recommended I start a thread
> here (thanks, Brett!).
>
> In December, two colleagues and I submitted
> https://github.com/python/cpython/pull/23847, "Add aiter and anext to
> builtins", which would fix https://bugs.python.org/issue31861.
>
> Would any core developers who may be reading this be willing and able to
> provide a code review?
>
> We would love to try to address any review feedback before having to fix
> (another round of) merge conflicts. (And ideally maybe even get this landed
> in time for the 3.10 feature freeze in early May?)
>
> Thanks and hope this finds you well.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/5XUVPB5H4PFUGTC5F7KAN4STKAEOFBQM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XQL3YTLCJM54KY6E52XYMTY5LQMZTJVX/
Code of Conduct: http://python.org/psf/codeofconduct/