[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Nick Coghlan]

On Sat, 27 Mar 2021, 9:24 am Guido van Rossum,  wrote:

> Everyone,
>
> Given the resounding silence I'm inclined to submit this to the Steering
> Council. While I'm technically a co-author, Irit has done almost all the
> work, and she's done a great job. If there are no further issues I'll send
> this SC-wards on Monday.
>

+1 from me. I remember talking to Nathaniel (and Yury IIRC) about early
iterations of the MultiError handling in trio at PyCon years ago, so it's
great to see the way the concept has matured in the intervening time.

The one thing I did think was that it might be good to mention
concurrent.futures and contextlib in the PEP as modules that could
potentially take advantage of exception groups. I'm not sure it's really
necessary though, as the presentation is already compelling as it is.

Cheers,
Nick.

P.S. The potential use case I see in contextlib: the way ExitStack nests
dynamic resource handling *works*, but the tracebacks when multiple clean
up steps fail can be spectacularly cryptic. With exception groups
available, it should be possible to define a new "context lib.ExitGroup"
API that flattens out the resource clean up and collects any exceptions
that occur into a more comprehensible exception group, rather than building
a nested exception context tree the way ExitStack does.




> --Guido
>
> On Sat, Mar 20, 2021 at 10:05 AM Irit Katriel 
> wrote:
>
>>
>> We would like to present for feedback a new version of PEP 654, which
>> incorporates the feedback we received in the discussions so far:
>> https://www.python.org/dev/peps/pep-0654/
>> The reference implementation has also been updated along with the PEP.
>>
>> The changes we made since the first post are:
>>
>> 1. Instead of ExceptionGroup(BaseException), we will have two new builtin
>> types: BaseExceptionGroup(BaseException) and
>> ExceptionGroup(BaseExceptionGroup, Exception).
>> This is so that "except Exception" catches ExceptionGroups (but not
>> BaseExceptionGroups). BaseExceptionGroup.__new__ inspects the wrapped
>> exceptions, and if they are all Exception subclasses, it creates an
>> ExceptionGroup instead of a BaseExceptionGroup.
>>
>> 2. The exception group classes are not final - they can be subclassed and
>> split()/subgroup() work correctly if the subclass overrides the derive()
>> instance method as described here:
>> https://www.python.org/dev/peps/pep-0654/#subclassing-exception-groups
>>
>> 3. We had some good suggestions on formatting exception groups, which we
>> have implemented as you can see in the output shown for the examples in the
>> PEP.
>>
>> 4. We expanded the section on handling Exception Groups, to show how
>> subgroup can be used (with side effects) to do something for each leaf
>> exception, and how to iterate correctly when the tracebacks of leaf
>> exceptions are needed:
>> https://www.python.org/dev/peps/pep-0654/#handling-exception-groups
>>
>> 5. We expanded the sections on rationale and backwards compatibility to
>> explain our premise and expectations regarding how exception groups will be
>> used and how the transition to using them will be managed.
>>
>> 6. We added several items to the rejected ideas section.
>>
>> We did not receive any comments (or make any changes) to the proposed
>> semantics of except*, hopefully this is because everyone thought they are
>> sensible.
>>
>> Irit, Yury and Guido
>>
>>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> 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/AQGDIZDZOJDR4HNRYCJVFA2XJ7YOOXS5/
> 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/GEERSVTZECXPM6KIRCJS7Z2VO3XJCOL5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP-376 and PEP-427 interpretation

[MRAB]

On 2021-03-27 01:54, Theallredman via Python-Dev wrote:
Forgive me if this isn't the correct venue for this question and I ask 
your help directing me to the correct place if it is not.


In PEP-376 it states with respect to the valid hashes in a Wheel RECORD 
file:


"The hash is either the empty string or the hash algorithm as named in 
hashlib.algorithms_guaranteed, followed by the equals character =, 
followed by the urlsafe-base64-nopad encoding of the digest 
(base64.urlsafe_b64encode(digest) with trailing = removed)."


In PEP-427 it further restricts the valid hashes to omit md5 and sha1 
and says:


"The hash algorithm must be sha256 or better; specifically, md5 and sha1 
are not permitted."


No where does it define what on what dimension of a hash "better" should 
consider.  From the context talking about the security of the algorithm 
I'd infer that "better" is with respect to collision resistance.  If so 
does that mean sha224 should also be excluded from wheel RECORD file hashes?


The "256" part refers to it generating a 256-bit signature, so a 
"better" one is one that generates a signature that's longer, e.g. 
"sha384" and "sha512".

___
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/6RAUURQDHYGQEFNNEZTIEOJ2J3BUMN5B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP-376 and PEP-427 interpretation

[Theallredman via Python-Dev]

Forgive me if this isn't the correct venue for this question and I ask your 
help directing me to the correct place if it is not.

In PEP-376 it states with respect to the valid hashes in a Wheel RECORD file:

"The hash is either the empty string or the hash algorithm as named in 
hashlib.algorithms_guaranteed, followed by the equals character =, followed by 
the urlsafe-base64-nopad encoding of the digest 
(base64.urlsafe_b64encode(digest) with trailing = removed)."

In PEP-427 it further restricts the valid hashes to omit md5 and sha1 and says:

"The hash algorithm must be sha256 or better; specifically, md5 and sha1 are 
not permitted."

No where does it define what on what dimension of a hash "better" should 
consider. From the context talking about the security of the algorithm I'd 
infer that "better" is with respect to collision resistance. If so does that 
mean sha224 should also be excluded from wheel RECORD file hashes?

Eldon___
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/TP5DEDAW5TUQS44BY6RE2HHRRGOL56HZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Terry Reedy]

On 3/26/2021 7:19 PM, Guido van Rossum wrote:

Everyone,

Given the resounding silence I'm inclined to submit this to the Steering 
Council. While I'm technically a co-author, Irit has done almost all the 
work, and she's done a great job. If there are no further issues I'll 
send this SC-wards on Monday.


The current version looks very carefully done.  I leave it to the SC to 
review the details.  But two thoughts on other possible uses.


1. unittests already uses the idea of exception groups by catching 
test_xyz exceptions and adding them to a group, to be printed it when 
all those for a file are run.  If the PEP is accepted, someone might 
request an option to have them packaged as an ExceptionGroup.


2. At least some compilers for other languages can report multiple 
syntax exceptions, but at least for C, the usefulness of more than 2 or 
3 is crippled by the synchronization problem.  Python's compile() only 
reports the first, but I imagine that the usually dependable parsing 
into statements might make multiple reports for Python useful.  I am 
thinking of a 'multiple' mode that repeatedly and recursively did 
'single' compiles. (There would still be only one report per statement 
or compound statement header.)  I have seen newbie code posted on 
Stackoverflow that needed a multi-error report.


--
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/CT2SLYRZLNEDCPOSNGFZGTUHRRNJUUBE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Guido van Rossum]

Everyone,

Given the resounding silence I'm inclined to submit this to the Steering
Council. While I'm technically a co-author, Irit has done almost all the
work, and she's done a great job. If there are no further issues I'll send
this SC-wards on Monday.

--Guido

On Sat, Mar 20, 2021 at 10:05 AM Irit Katriel 
wrote:

>
> We would like to present for feedback a new version of PEP 654, which
> incorporates the feedback we received in the discussions so far:
> https://www.python.org/dev/peps/pep-0654/
> The reference implementation has also been updated along with the PEP.
>
> The changes we made since the first post are:
>
> 1. Instead of ExceptionGroup(BaseException), we will have two new builtin
> types: BaseExceptionGroup(BaseException) and
> ExceptionGroup(BaseExceptionGroup, Exception).
> This is so that "except Exception" catches ExceptionGroups (but not
> BaseExceptionGroups). BaseExceptionGroup.__new__ inspects the wrapped
> exceptions, and if they are all Exception subclasses, it creates an
> ExceptionGroup instead of a BaseExceptionGroup.
>
> 2. The exception group classes are not final - they can be subclassed and
> split()/subgroup() work correctly if the subclass overrides the derive()
> instance method as described here:
> https://www.python.org/dev/peps/pep-0654/#subclassing-exception-groups
>
> 3. We had some good suggestions on formatting exception groups, which we
> have implemented as you can see in the output shown for the examples in the
> PEP.
>
> 4. We expanded the section on handling Exception Groups, to show how
> subgroup can be used (with side effects) to do something for each leaf
> exception, and how to iterate correctly when the tracebacks of leaf
> exceptions are needed:
> https://www.python.org/dev/peps/pep-0654/#handling-exception-groups
>
> 5. We expanded the sections on rationale and backwards compatibility to
> explain our premise and expectations regarding how exception groups will be
> used and how the transition to using them will be managed.
>
> 6. We added several items to the rejected ideas section.
>
> We did not receive any comments (or make any changes) to the proposed
> semantics of except*, hopefully this is because everyone thought they are
> sensible.
>
> Irit, Yury and Guido
>
>

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/AQGDIZDZOJDR4HNRYCJVFA2XJ7YOOXS5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: On the migration from master to main

[Pablo Galindo Salgado]

> f I have branch fix_something that is branched off master from a while
ago, do I need to do anything to it?

In general no, branches are basically a file that points to a given commit
so even if they branched from master the actual
commit sha is what matters. The only case if you have a branch that is
tracking master as a remote, in which case you need
to do those steps for said branch. But this is quite uncommon.

> Or will I just be able to do `git merge main` once master gets renamed,
and it'll just work with the name change making no difference?

You should be able to do that without any problem that I can foresee once
you rename it in your local fork.

> PS If I think hard about it, and ponder the git model of blobs and commits,
etc, I can see that no commits change with the renaming, and
> the names "master" and "main" are just aliases for particular commits. So
I think I've convinced myself that nothing else is needed. But that
> thought process is what I mean by "not obvious" ;-)

Exactly, that's the way I reason about this as well

Pablo


On Fri, 26 Mar 2021 at 21:19, Paul Moore  wrote:

> On Fri, 26 Mar 2021 at 19:54, Mariatta  wrote:
> >
> >
> > The branch has not been renamed. It will be renamed after the release of
> beta 1.
> >
> > There is a pending PR on DevGuide on how to change your existing local
> CPython repository to the new branch:
> >
> https://github.com/python/devguide/pull/662/files#diff-611263234e072dc403733b3dd46d0609cfe44b24d29f05841637b41d093adf0cR157
> >
> > The details and timeline on the branch renaming can be read here:
> >
> >
> https://mail.python.org/archives/list/python-committ...@python.org/message/QWW7KGBW5UH2N5FOZOFXQBQPYELWQM3O/
>
> Thanks, that is the same set of commands I've seen in a few places.
> What isn't obvious to me (but may be to the people writing the
> documentation) is what happens to branches I have. If I have branch
> fix_something that is branched off master from a while ago, do I need
> to do anything to it? Or will I just be able to do `git merge main`
> once master gets renamed, and it'll just work with the name change
> making no difference?
>
> I suspect it *will* just work, in which case all that is needed is a
> brief note making that clear. But to many of us, it's not "obvious"
> that this is the case.
>
> Paul
>
> PS If I think hard about it, and ponder the git model of blobs and
> commits, etc, I can see that no commits change with the renaming, and
> the names "master" and "main" are just aliases for particular commits.
> So I think I've convinced myself that nothing else is needed. But that
> thought process is what I mean by "not obvious" ;-)
> ___
> 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/EZRUP7UEBAS65QGRSTX7UF5WNGO3DXUB/
> 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/VTIWXA2KEH2WZ4MVX5OPGPJMCHCYYASK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: On the migration from master to main

[Paul Moore]

On Fri, 26 Mar 2021 at 19:54, Mariatta  wrote:
>
>
> The branch has not been renamed. It will be renamed after the release of beta 
> 1.
>
> There is a pending PR on DevGuide on how to change your existing local 
> CPython repository to the new branch:
> https://github.com/python/devguide/pull/662/files#diff-611263234e072dc403733b3dd46d0609cfe44b24d29f05841637b41d093adf0cR157
>
> The details and timeline on the branch renaming can be read here:
>
> https://mail.python.org/archives/list/python-committ...@python.org/message/QWW7KGBW5UH2N5FOZOFXQBQPYELWQM3O/

Thanks, that is the same set of commands I've seen in a few places.
What isn't obvious to me (but may be to the people writing the
documentation) is what happens to branches I have. If I have branch
fix_something that is branched off master from a while ago, do I need
to do anything to it? Or will I just be able to do `git merge main`
once master gets renamed, and it'll just work with the name change
making no difference?

I suspect it *will* just work, in which case all that is needed is a
brief note making that clear. But to many of us, it's not "obvious"
that this is the case.

Paul

PS If I think hard about it, and ponder the git model of blobs and
commits, etc, I can see that no commits change with the renaming, and
the names "master" and "main" are just aliases for particular commits.
So I think I've convinced myself that nothing else is needed. But that
thought process is what I mean by "not obvious" ;-)
___
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/EZRUP7UEBAS65QGRSTX7UF5WNGO3DXUB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: On the migration from master to main

[Mariatta]

The branch has not been renamed. It will be renamed after the release of
beta 1.

There is a pending PR on DevGuide on how to change your existing local
CPython repository to the new branch:
https://github.com/python/devguide/pull/662/files#diff-611263234e072dc403733b3dd46d0609cfe44b24d29f05841637b41d093adf0cR157

The details and timeline on the branch renaming can be read here:

https://mail.python.org/archives/list/python-committ...@python.org/message/QWW7KGBW5UH2N5FOZOFXQBQPYELWQM3O/

On Fri., Mar. 26, 2021, 12:21 p.m. Skip Montanaro, 
wrote:

> Can I distract people for a moment to ask a couple procedural questions
> about this change? I maintain my own fork of
> https://github.com/python/cpython, but don't yet see a main branch on
> python/cpython.
>
>
>- When is the new main branch supposed to appear
>- Once it does, what will I need to do other than to update my fork?
>- I have a branch in my fork (register2) which is a branch from my
>fork's master. Not being a Git whiz, how will I switch so my register2
>branch has the new main as its upstream (I think that's the correct word)?
>- How long will master be around after the switch before going to that
>big branch in the sky?
>
> I was able to scrounge up the few commands necessary to make the change
> to one of my standalone projects and successfully move it from master to
> main. The several articles I at least peeked at all followed pretty much
> the same recipe as this one:
>
>
> https://stevenmortimer.com/5-steps-to-change-github-default-branch-from-master-to-main/
>
> None, however, discuss how the change will affect forks. I'm a bit
> unclear how that part is supposed to work. I thought I might find a process
> PEP about this change, but saw nothing obvious in PEP 0. I'm sure this is a
> trivial few git commands for those more familiar with the toolchain than I
> am, but I see over 18k forks of the repository. I suspect a few people out
> of that crowd will be in the same boat as me.
>
> Thx,
>
> Skip
> ___
> 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/ZPTBTTWIAHTMPLXEMI237LWLBDIPXZDT/
> 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/TKBEVHHYTIB3BFZIER77UNG7VDLH4AGP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: On the migration from master to main

[Skip Montanaro]

Can I distract people for a moment to ask a couple procedural questions
about this change? I maintain my own fork of
https://github.com/python/cpython, but don't yet see a main branch on
python/cpython.


   - When is the new main branch supposed to appear
   - Once it does, what will I need to do other than to update my fork?
   - I have a branch in my fork (register2) which is a branch from my
   fork's master. Not being a Git whiz, how will I switch so my register2
   branch has the new main as its upstream (I think that's the correct word)?
   - How long will master be around after the switch before going to that
   big branch in the sky?

I was able to scrounge up the few commands necessary to make the change to
one of my standalone projects and successfully move it from master to main.
The several articles I at least peeked at all followed pretty much the same
recipe as this one:

https://stevenmortimer.com/5-steps-to-change-github-default-branch-from-master-to-main/

None, however, discuss how the change will affect forks. I'm a bit unclear
how that part is supposed to work. I thought I might find a process PEP
about this change, but saw nothing obvious in PEP 0. I'm sure this is a
trivial few git commands for those more familiar with the toolchain than I
am, but I see over 18k forks of the repository. I suspect a few people out
of that crowd will be in the same boat as me.

Thx,

Skip
___
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/ZPTBTTWIAHTMPLXEMI237LWLBDIPXZDT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Where and how can I contribute?

[Terry Reedy]

On 3/26/2021 6:29 AM, Marco Sulla wrote:

I would contribute to the project in my spare time. Can someone point
me to some easy task? I know C and the Python C API a little.


Review existing PRs.  In some cases (ask), convert existing patches 
posted on bpo issues to PRs.


--
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/WVRSZETZC6DE6SEWKTPHR4VZ2GVYOHSK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2021-03-19 - 2021-03-26)
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:
  open7498 (+17)
  closed 47871 (+58)
  total  55369 (+75)

Open issues with patches: 2984 


Issues opened (54)
==

#33164: Blake 2 module update
https://bugs.python.org/issue33164  reopened by christian.heimes

#42129: Support resources in namespace packages
https://bugs.python.org/issue42129  reopened by vstinner

#43560: Modify SAX/expat parsing to avoid fragmentation of already-tin
https://bugs.python.org/issue43560  opened by ridgerat1611

#43561: Modify XML parsing library descriptions to forewarn of content
https://bugs.python.org/issue43561  opened by ridgerat1611

#43562: test_ssl.NetworkedTests.test_timeout_connect_ex fails if netwo
https://bugs.python.org/issue43562  opened by carljm

#43563: Use dedicated opcodes to speed up calls/attribute lookups with
https://bugs.python.org/issue43563  opened by v2m

#43564: ftp tests in test_urllib2net fail instead of skipping on unrea
https://bugs.python.org/issue43564  opened by carljm

#43565: PyUnicode_KIND macro does not has specified return type
https://bugs.python.org/issue43565  opened by maxbachmann

#43567: regen.vcxproj cannot regenerate some necessary files
https://bugs.python.org/issue43567  opened by pjx206

#43568: Drop support for Mac OS X < 10.3 module linking
https://bugs.python.org/issue43568  opened by jmr

#43570: pyspecific.py >  AuditEvent mess with translations
https://bugs.python.org/issue43570  opened by mdk

#43574: Regression in overallocation for literal list initialization i
https://bugs.python.org/issue43574  opened by Chad.Netzer

#43576: python3.6.4 os.environ error when write chinese to file
https://bugs.python.org/issue43576  opened by rushant

#43578: With asyncio subprocess, send_signal() and the child process w
https://bugs.python.org/issue43578  opened by lincheney

#43579: Leak in asyncio.selector_events._SelectorSocketTransport
https://bugs.python.org/issue43579  opened by begnac

#43582: SSLContext.sni_callback docs inaccurately describe available h
https://bugs.python.org/issue43582  opened by theandrew168

#43583: make test failures, 2 tests failed: test_embed test_tabnan
https://bugs.python.org/issue43583  opened by Pattesvador

#43584: Doc description of str.title() upper case vs. title case.
https://bugs.python.org/issue43584  opened by grant.b.edwards

#43585: perf_counter() returns computers uptime
https://bugs.python.org/issue43585  opened by txhx38

#43588: [Subinterpreters]: use static variable under building Python w
https://bugs.python.org/issue43588  opened by JunyiXie

#43590: Collapse sidebar issue on https://docs.python.org/3/
https://bugs.python.org/issue43590  opened by lucijan345

#43592: test_importlib: test_multiprocessing_pool_circular_import() fa
https://bugs.python.org/issue43592  opened by vstinner

#43593: pymalloc is not aware of Memory Tagging Extension (MTE) and cr
https://bugs.python.org/issue43593  opened by ggardet

#43594: A metaclass that inherits both `ABC`  and `ABCMeta` breaks on 
https://bugs.python.org/issue43594  opened by erezinman

#43595: Can not add a metclass that inherits both ABCMeta & ABC to a U
https://bugs.python.org/issue43595  opened by erezinman

#43596: change assertRaises message when wrong exception is raised
https://bugs.python.org/issue43596  opened by rsk2

#43597: robotparser should support specifying SSL context
https://bugs.python.org/issue43597  opened by Tchinmai7

#43598: test_subprocess logs multiple ResourceWarning warnings
https://bugs.python.org/issue43598  opened by vstinner

#43599: Setting long domain of locale.dgettext() crashes Python interp
https://bugs.python.org/issue43599  opened by xxm

#43600: IDLE: fix highlight locationfor f-string field errors
https://bugs.python.org/issue43600  opened by terry.reedy

#43602: Include Decimal's in numbers.Real
https://bugs.python.org/issue43602  opened by Sergey.Kirpichev

#43604: Fix tempfile.mktemp()
https://bugs.python.org/issue43604  opened by David Luke??

#43605: Issue of scopes unclear in documentation, or wrongly implement
https://bugs.python.org/issue43605  opened by bruno.loff

#43606: PySimpleGUI: initial huge window & no widgets visible
https://bugs.python.org/issue43606  opened by bennett78

#43607: urllib's request.pathname2url not compatible with extended-len
https://bugs.python.org/issue43607  opened by levineds

#43608: `bytes_concat` and Buffer cleanup
https://bugs.python.org/issue43608  opened by seberg

#43609: ast.unparse-ing a FunctionType gives ambiguous result
https://bugs.python.org/issue43609  opened by cleoold

#43610: Ctrl C makes interpreter exit
https://bugs.python.org/issue43610  opened by xxm

#43611: Function tcflow() in module termios can not be interupted when
https://bugs.python.org/issue43611  opened by xxm

#43612: zlib.com

[Python-Dev] Re: Where and how can I contribute?

[Brett Cannon]

devguide.python.org has some guidelines on how to find easy issues to work
on. You can also ask for help on core-mentors...@python.org.

On Fri, Mar 26, 2021 at 3:32 AM Marco Sulla 
wrote:

> I would contribute to the project in my spare time. Can someone point
> me to some easy task? I know C and the Python C API a little.
> ___
> 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/5EQWUYNGSTWGJONZCFRMK6XWXL36WCLR/
> 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/RPQQAEIIGFJMFNXWRLFZKM4RVCWXXWXR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Alternative syntax for Python's lambda

[Brett Cannon]

That discussion has not even made it here yet; it seems to still only be on
python-ideas and thus that's probably the best place to leave a comment on
the subject (for now).

On Thu, Mar 25, 2021 at 9:55 PM Dan Stromberg  wrote:

>
> Please see https://lwn.net/Articles/847960/
>
> :)
>
> On Thu, Mar 25, 2021 at 2:34 PM Ethan Furman  wrote:
>
>> On 3/25/21 1:06 PM, Dan Stromberg wrote:
>> >
>> > I posted this to LWN, and thought I'd share it here too:
>>
>> This post is nearly completely devoid of context -- could you post a
>> link, or what you are responding to, or something?
>>
>> --
>> ~Ethan~
>> ___
>> 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/4BVRW67UU6KQCDER4FMRTZ4WUMBDTNGJ/
>> 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/3PBF272BZAWWF7XWP3O2PQ25VT4Y5HOO/
> 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/I2HC4OPRD3SHEGKTPRBXG6L3ZP6S3EHQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: On the migration from master to main

[Chris Angelico]

On Sat, Mar 27, 2021 at 3:33 AM Baptiste Carvello
 wrote:
>
> Le 25/03/2021 à 15:59, Stefano Borini a écrit :
> > On Tue, 23 Mar 2021 at 21:39, Python Steering Council
> >  wrote:
> >> This isn’t just about ‘master’ being rooted in slavery.
> >
> > No it's not and I am shocked that such ignorance would exist to believe 
> > that.
>
> It is indeed not, but the peculiar bitkeeper/git usage is.
>
> If both sides would agree on this, we could finally move on.
>

The one thing we can agree on is that it's easier to roll over and let
the change happen than to try to fight against politically-motivated
changes. Politics, truth to tell, is more important than technical
matters.

Sometimes, it's just not worth arguing any more.

ChrisA
___
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/FZPLVZS27KXYSPHOBYQFBXZE7BW72LWQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: On the migration from master to main

[Baptiste Carvello]

Le 25/03/2021 à 15:59, Stefano Borini a écrit :
> On Tue, 23 Mar 2021 at 21:39, Python Steering Council
>  wrote:
>> This isn’t just about ‘master’ being rooted in slavery.
> 
> No it's not and I am shocked that such ignorance would exist to believe that.

It is indeed not, but the peculiar bitkeeper/git usage is.

If both sides would agree on this, we could finally move on.

Cheers, Baptiste
___
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/D62N37HAFWYTXTRB5U5AQQBX3F2ODZ6C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Where and how can I contribute?

[Erlend Aasland]

Hi, Marco! I'd suggest taking a look at the issues that are marked as "Easy 
Tasks" on http://bugs.python.org. Not all of them are trivial, though (there 
may not be consensus on how to solve the issue), but you should be able to find 
something to work on there :)


Erlend

On 26 Mar 2021, at 11:29, Marco Sulla 
mailto:marco.sulla.pyt...@gmail.com>> wrote:

I would contribute to the project in my spare time. Can someone point
me to some easy task? I know C and the Python C API a little.
___
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/5EQWUYNGSTWGJONZCFRMK6XWXL36WCLR/
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/PRQHC42ZBDAOV3QRH7GXATYTS57DVJ23/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] failing doc test

[Ethan Furman]

I have this documentation:



.. class:: FlagBoundary

   *FlagBoundary* controls how out-of-range values are handled in *Flag* and its
   subclasses.

   .. attribute:: STRICT

  Out-of-range values cause a :exc:`ValueError` to be raised.  This is the
  default for :class:`Flag`::

 >>> from enum import STRICT
 >>> class StrictFlag(Flag, boundary=STRICT):
 ... RED = auto()
 ... GREEN = auto()
 ... BLUE = auto()
 >>> StrictFlag(2**2 + 2**4)
 Traceback (most recent call last):
 ...
 ValueError: StrictFlag: invalid value: 20
 given 0b0 10100
   allowed 0b0 00111

   .. attribute:: CONFORM

  Out-of-range values have invalid values removed, leaving a valid *Flag*
  value::

 >>> from enum import CONFORM
 >>> class ConformFlag(Flag, boundary=CONFORM):
 ... RED = auto()
 ... GREEN = auto()
 ... BLUE = auto()
 >>> ConformFlag(2**2 + 2**4)
 ConformFlag.BLUE

   .. attribute:: EJECT

  Out-of-range values lose their *Flag* membership and revert to 
:class:`int`.
  This is the default for :class:`IntFlag`::

 >>> from enum import EJECT
 >>> class EjectFlag(Flag, boundary=EJECT):
 ... RED = auto()
 ... GREEN = auto()
 ... BLUE = auto()
 >>> EjectFlag(2**2 + 2**4)
 20

   .. attribute:: KEEP

  Out-of-range values are kept, and the *Flag* membership is kept.  This is
  used for some stdlib flags:

 >>> from enum import KEEP
 >>> class KeepFlag(Flag, boundary=KEEP):
 ... RED = auto()
 ... GREEN = auto()
 ... BLUE = auto()
 >>> KeepFlag(2**2 + 2**4)
 KeepFlag.BLUE|0x10



and I'm getting this error:



Warning, treated as error:
**
File "library/enum.rst", line ?, in default
Failed example:
class KeepFlag(Flag, boundary=KEEP):
RED = auto()
GREEN = auto()
BLUE = auto()
Exception raised:
Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/doctest.py", line 1337, in 
__run
exec(compile(example.source, filename, "single",
  File "", line 1, in 
class KeepFlag(Flag, boundary=KEEP):
NameError: name 'Flag' is not defined



`Flag` has been imported before, the first three examples using `Flag` pass...
any ideas on why the fourth test cannot find `Flag`?

--
~Ethan~
___
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/VW4QL2URYXQUUNIA3OGDXZOHKS3LSDIK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Where and how can I contribute?

[Marco Sulla]

I would contribute to the project in my spare time. Can someone point
me to some easy task? I know C and the Python C API a little.
___
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/5EQWUYNGSTWGJONZCFRMK6XWXL36WCLR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New public C API functions must not steal references or return borrowed references

[Antoine Pitrou]

On Thu, 25 Mar 2021 23:37:46 -0700
"Gregory P. Smith"  wrote:
> On Thu, Mar 25, 2021 at 11:58 AM Mark Shannon  wrote:
> 
> > Hi Victor,
> >
> > I'm with you 100% on not returning borrowed references, doing so is just
> > plain dangerous.
> >
> > However, is a blanket ban on stealing references the right thing?
> >
> > Maybe the problem is the term "stealing".
> > The caller is transferring the reference to the callee.
> > In some circumstances it can make a lot of sense to do so, since the
> > caller has probably finished with the reference and the callee needs a
> > new one.
> >
> > Cheers,
> > Mark.
> >  
> 
> When was the last time a non-internal API that transferred references added?
> 
> I suggest keeping the restriction on new APIs in place until we actually
> find a situation where we think we "need" one outside of Include/internal/
> to help force the discussion as to why that needs to be public.

+1.

Regards

Antoine.


___
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/TH6PGVQIVOXWAF5OL3USQWFUPKUPKO5U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New public C API functions must not steal references or return borrowed references

[Simon Cross]

I (with a lot of help and input from other people) wrote up some of
the thinking behind these kinds of API issues for the HPy project --
https://github.com/hpyproject/hpy/wiki/c-api-next-level-changes#what-needs-to-change-and-why

It's written from an HPy point of view and if you've already thought
about these things a lot none of it may be new to you and you may have
your own opinions, but hopefully it's a good introduction to the
issues if one is new to them.
___
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/6VHFDRL4T2IVS5ALDKD4M2ZY7HFDZGQN/
Code of Conduct: http://python.org/psf/codeofconduct/