[Python-Dev] Re: Merging PRs without CLA signed

[Nick Coghlan]

On Mon, 24 Feb 2020 at 14:51, Kyle Stanley  wrote:
>
> > Note that if you open a PR, and _then_ sign the CLA, the label is not 
> > updated (at least, that's what I experienced before I did). So this list is 
> > likely inaccurate.
>
> I believe that I might have seen this happen a few times, but in the majority 
> cases the label is updated from "CLA not signed" => "CLA signed". There's a 
> bit of delay (~24-48 hours) from the time you sign the CLA to when it's 
> updated in the heroku app, so if the PR gets merged during that time the 
> label might not ever update.
>
> For my own first PR, it was initially not signed when I opened it, and then 
> the label updated to signed within a couple days after signing the CLA. This 
> has also been the case in the majority of PRs I've reviewed from first-time 
> contributors.

I don't remember if there's a magic comment that contributors can
leave to get the bot to check again on its own, but the usual trigger
for this is the submitter posting to say they've signed it, a core dev
or triager seeing that and removing the "CLA Not Signed" label, and
then the bot adding the "CLA signed" label (confirming that the CLA
has, in fact, been signed, and the PSF records have been updated
accordingly).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/22ZP56KOHIPRPSD5H72KIGTEEAY5DNVZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 584: Add Union Operators To dict

[Nick Coghlan]

On Mon, 24 Feb 2020 at 12:10, Guido van Rossum  wrote:
>
> On Sat, Feb 22, 2020 at 4:45 PM Brandt Bucher  wrote:
>>
>> [quoting Nick]
>> > collections.Mapping and collections.MutableMapping could provide concrete 
>> > method implementations that make subclasses behave in a way that's similar 
>> > to built-in dicts
>>
>> Hm, haven't thought too much about this (I don't have much experience with 
>> the ABCs). Would they return dicts, or call the self.copy and self.update 
>> methods?
>>
>> Those are just hypothetical questions for now; I don't necessarily want to 
>> dig too far into that discussion again. But I agree that it's definitely 
>> worth considering. ;)
>
> Mapping and MutableMapping don't have copy() methods -- these are 
> intentionally narrower interfaces than dict. I think we should leave them 
> alone. The PEP does *not* propose to add `|` to Mapping, and that's 
> intentional. Because of this I think we should also not add `|=` to 
> MutableMapping, even though it does have an update() method. Adding it (even 
> with a default implementation) could cause discrepancies to virtual 
> subclasses registered with MutableMapping.register(C).

That's an excellent point regarding virtual subclasses - I was only
thinking about concrete subclasses. So if folks want to mimic the full
dict API, they can inherit from UserDict, while Mapping and
MutableMapping continue with their existing narrower APIs.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/E5V4RK4HCLZBKC2Z4HXXO4FZWWKGWZHX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 585: Type Hinting Generics In Standard Collections

[Nick Coghlan]

On Tue, 25 Feb 2020 at 15:19, Ethan Smith  wrote:
>
> The discussion on the name change came from Łukasz  
> https://github.com/python/cpython/pull/18239#discussion_r380996908
>
> I suggested "GenericType" to be in line with other things in types.py.

Quoting Łukasz question: "I know it's late for this bikeshedding but I
was always a bit puzzled by the name "GenericAlias". What is it
aliasing?"

The "GenericAlias" name seemed appropriate to me as these aren't real
types - they're aliases for the corresponding container type with some
extra metadata attached. So "list[str]" is *mostly* just a different
way of writing "list" at runtime - it's primarily typecheckers that
will treat it differently (while the runtime typechecking machinery
will reject it as too specific to be checked non-destructively).

"GenericAliasForAConcreteContainerType" would be excessively wordy
though, hence "GenericAlias".

By contrast, I'd expect something called "GenericType" to actually be
able to do full runtime typechecking and enforcement (e.g. having
instances throw TypeError if you tried to insert a value of the wrong
type).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/RB3DOICJURSPGMNYLJDGTPZO3MZ3EVKN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merging PRs without CLA signed

[Mariatta]

don't remember if there's a magic comment that contributors can
leave to get the bot to check again on its own, but the usual trigger
for this is the submitter posting to say they've signed it, a core dev
or triager seeing that and removing the "CLA Not Signed" label,



There is no magic comment, and to reduce work from core dev/triager,
contributors can use this to update their own PRs
https://check-python-cla.herokuapp.com/

Being able to update the CLA as soon as it gets signed instead of waiting a
couple days, is on top of my wishlist:

https://github.com/python/core-workflow/issues/360
___
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/FUUEN6OBXNYJ4K3ENXKAQNLXX5ENAFBF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 585: Type Hinting Generics In Standard Collections

[Guido van Rossum]

OK, it's certainly easier *not* to change it, so I'm happy with this
argument for the current name.

Łukasz, do you agree?

Then I think we can submit this to the SC for acceptance.

On Tue, Feb 25, 2020 at 6:27 AM Nick Coghlan  wrote:

> On Tue, 25 Feb 2020 at 15:19, Ethan Smith  wrote:
> >
> > The discussion on the name change came from Łukasz
> https://github.com/python/cpython/pull/18239#discussion_r380996908
> >
> > I suggested "GenericType" to be in line with other things in types.py.
>
> Quoting Łukasz question: "I know it's late for this bikeshedding but I
> was always a bit puzzled by the name "GenericAlias". What is it
> aliasing?"
>
> The "GenericAlias" name seemed appropriate to me as these aren't real
> types - they're aliases for the corresponding container type with some
> extra metadata attached. So "list[str]" is *mostly* just a different
> way of writing "list" at runtime - it's primarily typecheckers that
> will treat it differently (while the runtime typechecking machinery
> will reject it as too specific to be checked non-destructively).
>
> "GenericAliasForAConcreteContainerType" would be excessively wordy
> though, hence "GenericAlias".
>
> By contrast, I'd expect something called "GenericType" to actually be
> able to do full runtime typechecking and enforcement (e.g. having
> instances throw TypeError if you tried to insert a value of the wrong
> type).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>


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

[Python-Dev] Hang with parallel make

[e2lahav]

Hello,

I have successfully built Python 3.8.1 on QNX, but ran into a problem when 
using 'make -j4'. The build process invariably hangs with multiple 
single-threaded child processes stuck indefinitely waiting on semaphores. These 
semaphores will clearly never be posted to, as the processes are all single 
threaded and the semaphores are not shared with any other process.
A backtrace shows that the the offending calls come from run_at_forkers(), 
which is not surprising. I consider a multi-threaded fork() to be an 
ill-defined operation and my arch-nemesis... The problem here is that the value 
of the semaphore inherited from the parent shows the semaphore to be 
unavailable, even though the semaphore *object* itself is not the same as the 
one used by the parent (they share the same virtual address, but in different 
address spaces with different backing memory).

A few (noob) questions:
1. Is there a way to correlate the C backtrace from the core dump to the Python 
code that resulted in this hang?
2. It is well-known that a multi-threaded fork() is inherently unsafe, and 
POSIX says that no non-async-signal-safe operations are allowed between the 
fork() and exec() calls. I even saw comments to this effect in the Python 
source code ;-) So why is it done?
3. Any reason not to use posix_spawn() instead of fork()/exec()? While some 
systems implement posix_spawn() with fork()/exec() others (at least QNX) 
implements it without first creating a duplicate of the parent, making it both 
more efficient and safer in a multi-threaded parent.
4. thread_pthread.h seems to go to great lengths to implement locks without 
using native mutexes. I found one reference in the code dating to 1994 as to 
why that is done. Is it still applicable? Contrary to the claim in that comment 
the semantics for trying to lock an already-locked mutex and for unlocking an 
unowned mutex are well-defined.

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

[Python-Dev] Re: PEP 585: Type Hinting Generics In Standard Collections

[Łukasz Langa]

> On 25 Feb 2020, at 16:22, Guido van Rossum  wrote:
> 
> Łukasz, do you agree?

As long as we include a form of Nick's explanation in the docs for the type, 
I'm fine with that.

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

[Python-Dev] Python 3.8.2 and 3.9.0a4 are now available

[Łukasz Langa]

On behalf of the entire Python development community, and the currently serving 
Python release team in particular, I’m pleased to announce the release of two 
of the latest Python editions.

Python 3.8.2

Python 3.8.2 is the second maintenance release of Python 3.8 and contains two 
months worth of bug fixes. Detailed information about all changes made in 3.8.2 
can be found in its change log 
.
 Note that compared to 3.8.1, version 3.8.2 also contains the changes 
introduced in 3.8.2rc1 and 3.8.2rc2.

The Python 3.8 series is the newest feature release of the Python language, and 
it contains many new features and optimizations. You can find Python 3.8.2 here:
https://www.python.org/downloads/release/python-382/ 

See the “What’s New in Python 3.8 
” document for more information 
about features included in the 3.8 series.

Maintenance releases for the 3.8 series will continue at regular bi-monthly 
intervals, with 3.8.3 planned for April 2020 (at the PyCon US sprints 
).

Python 3.9.0a4

An early developer preview of Python 3.9 is also ready:
https://www.python.org/downloads/release/python-390a4/ 

Python 3.9 is still in development. This releasee, 3.9.0a4 is the fourth of six 
planned alpha releases. Alpha releases are intended to make it easier to test 
the current state of new features and bug fixes and to test the release 
process. During the alpha phase, features may be added up until the start of 
the beta phase (2020-05-18) and, if necessary, may be modified or deleted up 
until the release candidate phase (2020-08-10). Please keep in mind that this 
is a preview release and its use is not recommended for production environments.

We hope you enjoy both!

Thanks to all of the many volunteers who help make Python Development and these 
releases possible! Please consider supporting our efforts by volunteering 
yourself or through organization contributions to the Python Software 
Foundation.
https://www.python.org/psf/ 
Your friendly release team,
Ned Deily
Steve Dower
Łukasz Langa___
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/YLMHMKLQB23XBMQGSG6HOTK6URA2FB5L/
Code of Conduct: http://python.org/psf/codeofconduct/