[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-21 Thread Baptiste Carvello 
Hi,

Le 21/06/2021 à 04:20, Ezio Melotti a écrit :
> This effort is being tracked at
> : this board reflects
> the current status of the project.  The PEPs (including PEP 588 --
> GitHub Issues Migration Plan) haven't been updated yet and might
> contain outdated information, so please refer to the psf/gh-migration
> repo for the latest updates.

since 2019, I've been waiting for proposed solutions to PEP 588's first
open issue ("A GitHub account should not be a requirement"). Now would
be the time to think about it, but I see no such reflection mentioned in
the repo.

Cheers,
Baptiste
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/2GJQKB27XD6LKGKWJXTXLEURNMF5ZJT7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

2021-06-21 Thread Baptiste Carvello 
Hi,

Le 18/06/2021 à 21:00, Guido van Rossum a écrit :
> Can you elaborate on that use case? Which two applications are you
> thinking of, and what was your goal in driving them? This sounds
> interesting but I haven’t encountered this myself.

Well, I'm not sure the case I was thinking of is still relevant to
anything: that was plotting 3D crystal models using crystallography
library CCTBX [1] and visualization application Mayavi [2], some 15-20
years ago. BTW, I misremembered a bit: only CCTBX insisted on using a
vendored python ("libtbx.python"), Mayavi used the system python.
Anyway, it was more pain to make Mayavi use libtbx.python, than to make
CCTBX work with the system python.

Also, I must admit that even applications embedding the system python
can have some limitations. For example, GIMP and GDB can execute python
scripts, but their API can't be "imported" from the outside. Which means
no arguments passed to the script over the command line ("sys.argv"), no
venvs, no REPL. But at least you can install additional packages (pip /
distro package manager) and limitations can be more or less hacked
around. For a sophisticated example, the debugger extension Voltron [3]
provides REPL access to GDB objects over a client-server connexion.

Cheers,
Baptiste

[1] https://cci.lbl.gov/docs/cctbx/
[2] https://docs.enthought.com/mayavi/mayavi/
[3] https://github.com/snare/voltron

> On Fri, Jun 18, 2021 at 09:44 Baptiste Carvello
>  > wrote:
> 
> Le 18/06/2021 à 08:50, Paul Moore a écrit :
> >
> > IMO it doesn't. However for certain applications (the sort of thing I
> > was referring to) - where the user is writing their own scripts and
> > the embedding API is used merely to expose an interface to the Python
> > language, dynamically linking to whatever version of Python the user
> > has installed can be precisely the right thing to do - the user gets
> > access to the version of the language they expect, the installed
> > packages they expect to see, etc.
> 
> As a user, I second this. When trying to drive applications from the
> outside (as opposed to extending them through plugins), it is annoying
> when two applications won't work together because each one insists on
> using its own vendored python.
> 
> Of course, there are often real blockers, such as incompatible event
> loops. But not always…
> 
> Cheers,
> Baptiste
> ___
> Python-Dev mailing list -- [email protected]
> 
> To unsubscribe send an email to [email protected]
> 
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> 
> https://mail.python.org/archives/list/[email protected]/message/PPKL7466BIG6DPCUIJURLE5ZGFNHBNSM/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> -- 
> --Guido (mobile)
> 

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

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-21 Thread Antoine Pitrou 
On Mon, 21 Jun 2021 11:27:27 +0200
Baptiste Carvello  wrote:
> Hi,
> 
> Le 21/06/2021 à 04:20, Ezio Melotti a écrit :
> > This effort is being tracked at
> > : this board reflects
> > the current status of the project.  The PEPs (including PEP 588 --
> > GitHub Issues Migration Plan) haven't been updated yet and might
> > contain outdated information, so please refer to the psf/gh-migration
> > repo for the latest updates.  
> 
> since 2019, I've been waiting for proposed solutions to PEP 588's first
> open issue ("A GitHub account should not be a requirement"). Now would
> be the time to think about it, but I see no such reflection mentioned in
> the repo.

It's extremely unlikely that Github would allow participating on the
issue tracker without requiring a Github account, even if Python asks
for it.

Regards

Antoine.


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

[Python-Dev] Re: [RELEASE] Python 3.10.0b3 is available

2021-06-21 Thread Simon Cross 
On Thu, Jun 17, 2021 at 11:36 PM Pablo Galindo Salgado
 wrote:
> #And now for something completely different
>
> There are no green stars. Why?

Thank you! This addition was great. :D
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/PQHHFC2XHTXM3F5RBDELC5W5JN5XPLNA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-21 Thread Victor Stinner 
Hi,

As a bug triager, it's very frustrating when I ask for more
information about a bug, and I get no reply. Usually, such bug is
closed as "out of date" (lack enough information to be debugged).

The requirement for a GitHub account was well known when PEP 581 was
accepted. The PEP was approved. It's now time to move on!

The creation of bugs.python.org account and bugs.python.org
authentication is often broken. It was common that OpenID
authentication was broken for 1 month or longer. Moreover,
bugs.python.org doesn't support 2FA currently, whereas GitHub does.
GitHub looks more reliable *and* more secure.

Also, please don't forget an important point: bugs.python.org is
barely maintained. See the list of open issues:
https://github.com/python/bugs.python.org/issues

For example, "Not receiving email from the bug tracker" was reported
25 days ago and got no answer :-(

It's all about trade-offs. Don't under estimate the cost of operating
our own bug tracker. System administration is not free.

Victor

On Mon, Jun 21, 2021 at 11:46 AM Baptiste Carvello
 wrote:
>
> Hi,
>
> Le 21/06/2021 à 04:20, Ezio Melotti a écrit :
> > This effort is being tracked at
> > : this board reflects
> > the current status of the project.  The PEPs (including PEP 588 --
> > GitHub Issues Migration Plan) haven't been updated yet and might
> > contain outdated information, so please refer to the psf/gh-migration
> > repo for the latest updates.
>
> since 2019, I've been waiting for proposed solutions to PEP 588's first
> open issue ("A GitHub account should not be a requirement"). Now would
> be the time to think about it, but I see no such reflection mentioned in
> the repo.
>
> Cheers,
> Baptiste
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/2GJQKB27XD6LKGKWJXTXLEURNMF5ZJT7/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/JOQKA3AUGEYQZWZ2NJATOKK4APESMBF4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] April Steering Council update

2021-06-21 Thread Pablo Galindo Salgado 
Hi everyone,


The SC has just published the community update for April:


https://github.com/python/steering-council/blob/main/updates
/2021-04-steering-council-update.md

As a reminder, we'll are trying to keep this up monthly. As you can see we
are mainly focusing on clearing the PEP backlog and addressing ongoing
efforts and time-sensitive issues. We have currently a very packed
agenda and we are doing our best to get to it as fast as we can,
prioritizing what's necessary (as bootstrapping the developer in residence
position). Thanks a lot for your patience and understanding meanwhile we get
to review your PEP or request :)

If you have any request or concern, you can open an issue in the SC repo:
https://github.com/python/steering-council

Here is the text for the update (with links):

*April 5*



   -

   The Steering Council discussed PEP 647: User-Defined Type Guards
    and approved it. An
   acceptance notice was sent. It was discussed that after Python 3.10, the
   Steering Council should start a larger discussion around the typing
   language and how it relates to the Python language.
   -

   The Steering Council discussed PEP 654: Exception Groups and except*
    and it was decided that some
   members needed more time to review some of the existing discussion as well
   as Nathaniel's feedback.
   -

   The Steering Council will inform the community around expectations for
   scheduling. No new features (unless straight forward) will be approved
   after the beta freeze.
   -

   The Steering Council discussed accepting the clarification around PyPA
   members being PEP sponsors. The commit with the proposal was merged and the
   issue was closed.
   -

   The group discussed a response to Debian following the ongoing
   discussion around the future of the Python package in the Debian
   distribution and it was decided that Pablo would send the email to the
   Debian group.


*April 12*


   -

   The Steering Council discussed at length PEP 654: Exception Groups and
   except* . The group decided
   an email should be sent to python-dev@ asking for more discussion and
   Thomas would draft that email.
   -

   The group worked on the PyCon US 2021 Steering Council keynote
   -

   Pablo mentioned he would send out the email to the Debian folks soon
   (which was sent April 13).


*April 19*


   -

   The Steering Council discussed PEP 646: Variadic Generics
    and was decided that a
   decision will be postponed to after Python 3.10 as there was not enough
   time to properly evaluate the PEP given the other, more time pressing
   issues regarding PEP 649: Deferred Evaluation Of Annotations Using
   Descriptors  and type
   annotations.
   -

   The group discussed at length some concerns raised by a group of users
   and library authors regarding that the current release of 3.10 is going to
   make life very difficult to “pydantic”, users of the library and similar
   libraries that use type annotations at runtime. This is due to some
   limitations in PEP 563:  Postponed Evaluation of Annotations
    that affect users of runtime
   annotations (and is also related with PEP 649: Deferred Evaluation Of
   Annotations Using Descriptors ).
   The Steering Council discussed at length different possibilities with a
   careful evaluation of costs, risks and work to be done and decided that we
   simply can’t risk the compatibility breakage of PEP 563. The group decided
   that for stringified annotations the default must be reverted, at least for
   Python 3.10. Thomas will send an email to python-dev with the decision.


*April 26*

   -

   The Steering Council discussed PEP 654: Exception Groups and except*
   ., deciding to postpone the
   PEP to 3.11, and postpone their decision for 3.11 until after the Language
   Summit.
   -

   The SC discussed PEP 648: Extensible customizations of the interpreter
   at startup , deciding to
   postpone it to 3.11.
   -

   The SC reviewed PEP 467: Minor API improvements for binary sequences
   , which was postponed to 3.11
   by its author.
   -

   The SC planned for the PyCon US keynote and Q&A, which will be recorded
   next week.
   -

   The SC briefly discussed the notion of adding sponsor logos to
   docs.python.org.
   -

   The SC discussed the proposal to delegate typing PEPs to a typing WG or
   BDFL, but deferred further discussion until later.
   -

   The SC discussed the role of CODEOWNERS in CPython and how different
   core devs use the file, and the consensus was that setting expectations for
   both reviewers

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-21 Thread Baptiste Carvello 
Hi,

Le 21/06/2021 à 13:48, Victor Stinner a écrit :
> Hi,
> 
> As a bug triager, it's very frustrating when I ask for more
> information about a bug, and I get no reply. Usually, such bug is
> closed as "out of date" (lack enough information to be debugged).

There seems to be an untold assumption that non-github-users are more
likely to not reply to their own bugs. Not sure why, I may lack context.

> The requirement for a GitHub account was well known when PEP 581 was
> accepted. The PEP was approved. It's now time to move on!

PEP 588 has been saying the exact opposite for 2 years (maybe they did
not really mean it, but that's what's written).

> [...]

> It's all about trade-offs. Don't under estimate the cost of operating
> our own bug tracker. System administration is not free.

Note, however, that requiring a github account for reporting bugs is a
whole different trade-off than requiring it for development. The second
makes python an unwelcoming project for privacy-conscious people, but I
understand that such is the price to pay for more efficient freeware
tools. And it's an already made choice anyway.

By contrast, requiring a github account for reporting bugs also makes
python an unwelcoming place for non-developers in general. Github is a
developers' social network, "mere" users are much less likely to want to
be part of it. Many will just silently abandon their bug report.

Cheers,
Baptiste

> 
> Victor
> 
> On Mon, Jun 21, 2021 at 11:46 AM Baptiste Carvello
>  wrote:
>>
>> Hi,
>>
>> Le 21/06/2021 à 04:20, Ezio Melotti a écrit :
>>> This effort is being tracked at
>>> : this board reflects
>>> the current status of the project.  The PEPs (including PEP 588 --
>>> GitHub Issues Migration Plan) haven't been updated yet and might
>>> contain outdated information, so please refer to the psf/gh-migration
>>> repo for the latest updates.
>>
>> since 2019, I've been waiting for proposed solutions to PEP 588's first
>> open issue ("A GitHub account should not be a requirement"). Now would
>> be the time to think about it, but I see no such reflection mentioned in
>> the repo.
>>
>> Cheers,
>> Baptiste
>> ___
>> Python-Dev mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at 
>> https://mail.python.org/archives/list/[email protected]/message/2GJQKB27XD6LKGKWJXTXLEURNMF5ZJT7/
>> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> 

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

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-21 Thread Lele Gaifax 
Baptiste Carvello  writes:

> By contrast, requiring a github account for reporting bugs also makes
> python an unwelcoming place for non-developers in general. Github is a
> developers' social network, "mere" users are much less likely to want to
> be part of it. Many will just silently abandon their bug report.

On Gitlab there is a "create-issue-by-email" feature, but a quick search
didn't reveal an equivalent [builtin] way for Github.

However, I found a few addons that implement that, for example
https://fire.fundersclub.com/.

Maybe that could be an acceptable compromise?

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
[email protected]  | -- Fortunato Depero, 1929.

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

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

2021-06-21 Thread Guido van Rossum 
Okay, I think your evidence can then be discounted. Really, any app that
relies on the publicly installed Python runs a serious risk of breaking
when that Python gets updated, regardless of whether the ABI changes or not.

On Mon, Jun 21, 2021 at 2:46 AM Baptiste Carvello <
[email protected]> wrote:

> Hi,
>
> Le 18/06/2021 à 21:00, Guido van Rossum a écrit :
> > Can you elaborate on that use case? Which two applications are you
> > thinking of, and what was your goal in driving them? This sounds
> > interesting but I haven’t encountered this myself.
>
> Well, I'm not sure the case I was thinking of is still relevant to
> anything: that was plotting 3D crystal models using crystallography
> library CCTBX [1] and visualization application Mayavi [2], some 15-20
> years ago. BTW, I misremembered a bit: only CCTBX insisted on using a
> vendored python ("libtbx.python"), Mayavi used the system python.
> Anyway, it was more pain to make Mayavi use libtbx.python, than to make
> CCTBX work with the system python.
>
> Also, I must admit that even applications embedding the system python
> can have some limitations. For example, GIMP and GDB can execute python
> scripts, but their API can't be "imported" from the outside. Which means
> no arguments passed to the script over the command line ("sys.argv"), no
> venvs, no REPL. But at least you can install additional packages (pip /
> distro package manager) and limitations can be more or less hacked
> around. For a sophisticated example, the debugger extension Voltron [3]
> provides REPL access to GDB objects over a client-server connexion.
>
> Cheers,
> Baptiste
>
> [1] https://cci.lbl.gov/docs/cctbx/
> [2] https://docs.enthought.com/mayavi/mayavi/
> [3] https://github.com/snare/voltron
>
> > On Fri, Jun 18, 2021 at 09:44 Baptiste Carvello
> >  > > wrote:
> >
> > Le 18/06/2021 à 08:50, Paul Moore a écrit :
> > >
> > > IMO it doesn't. However for certain applications (the sort of
> thing I
> > > was referring to) - where the user is writing their own scripts and
> > > the embedding API is used merely to expose an interface to the
> Python
> > > language, dynamically linking to whatever version of Python the
> user
> > > has installed can be precisely the right thing to do - the user
> gets
> > > access to the version of the language they expect, the installed
> > > packages they expect to see, etc.
> >
> > As a user, I second this. When trying to drive applications from the
> > outside (as opposed to extending them through plugins), it is
> annoying
> > when two applications won't work together because each one insists on
> > using its own vendored python.
> >
> > Of course, there are often real blockers, such as incompatible event
> > loops. But not always…
> >
> > Cheers,
> > Baptiste
> > ___
> > Python-Dev mailing list -- [email protected]
> > 
> > To unsubscribe send an email to [email protected]
> > 
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> >
> https://mail.python.org/archives/list/[email protected]/message/PPKL7466BIG6DPCUIJURLE5ZGFNHBNSM/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
> > --
> > --Guido (mobile)
> >
>
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/KP3SE6UWSV3VDCJOWCXUZIBPDWFJHRLU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


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

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

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-21 Thread Christopher Barker 
> By contrast, requiring a github account for reporting bugs also makes
> python an unwelcoming place for non-developers in general. Github is a
> developers' social network, "mere" users are much less likely to want to
> be part of it. Many will just silently abandon their bug report.


But you don’t need to be “part of it” in any meaningful way. One only needs
to create an account, which could be quite anonymous, and even temporary.

And is no harder, and probably easier, than creating an account on a
Python-specific site.

Also: cPython is a large, complex, and mature project. I don't think many
non-developers can even identify a true bug, much less write a helpful big
report. There are many other ways to be involved in and contribute to the
Python community that don't require a gitHub (or any) account.

I understand the issue here — I feel that way about businesses that use
Facebook for their website. But in that case, I can’t even read it without
a Facebook account. I don’t mind needing an account to contribute to a
conversation.

And while GitHub  has become the dominant player in Open Source
development— it has not (yet?) reached out to control much else.

-CHB




> Cheers,
> Baptiste
>
> >
> > Victor
> >
> > On Mon, Jun 21, 2021 at 11:46 AM Baptiste Carvello
> >  wrote:
> >>
> >> Hi,
> >>
> >> Le 21/06/2021 à 04:20, Ezio Melotti a écrit :
> >>> This effort is being tracked at
> >>> : this board reflects
> >>> the current status of the project.  The PEPs (including PEP 588 --
> >>> GitHub Issues Migration Plan) haven't been updated yet and might
> >>> contain outdated information, so please refer to the psf/gh-migration
> >>> repo for the latest updates.
> >>
> >> since 2019, I've been waiting for proposed solutions to PEP 588's first
> >> open issue ("A GitHub account should not be a requirement"). Now would
> >> be the time to think about it, but I see no such reflection mentioned in
> >> the repo.
> >>
> >> Cheers,
> >> Baptiste
> >> ___
> >> Python-Dev mailing list -- [email protected]
> >> To unsubscribe send an email to [email protected]
> >> https://mail.python.org/mailman3/lists/python-dev.python.org/
> >> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/2GJQKB27XD6LKGKWJXTXLEURNMF5ZJT7/
> >> Code of Conduct: http://python.org/psf/codeofconduct/
> >
> >
> >
>
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/ETQO4M3IUCXATK2UL56PSYE6FZPNZHIY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/6WC5YBPUGL2NDWO26FBIQM2PBEUPV3V3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-21 Thread Glenn Linderman 

On 6/21/2021 2:31 PM, Christopher Barker wrote:


By contrast, requiring a github account for reporting bugs also makes
python an unwelcoming place for non-developers in general. Github is a
developers' social network, "mere" users are much less likely to
want to
be part of it. Many will just silently abandon their bug report.


But you don’t need to be “part of it” in any meaningful way. One only 
needs to create an account, which could be quite anonymous, and even 
temporary.


And is no harder, and probably easier, than creating an account on a 
Python-specific site.


Also: cPython is a large, complex, and mature project. I don't think 
many non-developers can even identify a true bug, much less write a 
helpful big report. There are many other ways to be involved in and 
contribute to the Python community that don't require a gitHub (or 
any) account.


I understand the issue here — I feel that way about businesses that 
use Facebook for their website. But in that case, I can’t even read it 
without a Facebook account. I don’t mind needing an account to 
contribute to a conversation.


And while GitHub  has become the dominant player in Open Source 
development— it has not (yet?) reached out to control much else.


-CHB


With all due respect to Microsoft, who has contributed significantly to 
Python development, and continues to do, some people don't care for some 
of Microsoft's policy and actions, and Microsoft owns GitHub, so your 
last paragraph is somewhat naive, at best.


So what is the difference between a GitHub account, and Microsoft 
account?  Skype used to have its own accounts... then they were 
converted to be Microsoft accounts...


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