Re: [python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Barry Warsaw
On Sep 25, 2018, at 18:57, Victor Stinner  wrote:
> 
> IMHO It's time to discuss again modifying the "python" program to always 
> point to the latest Python version.

This just came up again on linux-sig, but...

> What is the status of Brett's UNIX Python launcher "py" by the way?

...I forgot to mention this.

FWIW, I still think we shouldn’t recommend a change here until 2.7 is done and 
done.  However, the launcher might be a good way out.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Victor Stinner
Serhiy:
> And changing the major version number itself is significant breaking
change. From the name of the executable (python3 vs python4) hardcoded in
Python

IMHO It's time to discuss again modifying the "python" program to always
point to the latest Python version.

What is the status of Brett's UNIX Python launcher "py" by the way?

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Donald Stufft


> On Sep 25, 2018, at 6:39 PM, Yury Selivanov  wrote:
> 
> I think we all have seen code like that; it's a common pattern.  So by
> just bumping the version to 4.0 you would break the compatibility for
> some libraries and frameworks.  And maybe breaking it is fine if
> there's a very strong technical reason, but doing that just to make a
> statement isn't worth it, IMHO.


Breaking a bunch of software to make the statement that you’re not going to 
break backwards compatibility anymore sounds like something out of a Monty 
Python skit though ;)___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Yury Selivanov
On Tue, Sep 25, 2018 at 6:33 PM Victor Stinner  wrote:
>
> Hi,
>
> I would prefer to never ever break the backward compatibility in Python. To 
> make it clear I suggest to use 4.0 for the release following Python 3.7.

I think Serhiy made a strong argument that the code like below would
break if we release Python 4.0:

 PY3 = sys.version_info[0] == 3
 if not PY3:
 ... # implies Python 2

I think we all have seen code like that; it's a common pattern.  So by
just bumping the version to 4.0 you would break the compatibility for
some libraries and frameworks.  And maybe breaking it is fine if
there's a very strong technical reason, but doing that just to make a
statement isn't worth it, IMHO.

Yury
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Victor Stinner
Hi,

I would prefer to never ever break the backward compatibility in Python. To
make it clear I suggest to use 4.0 for the release following Python 3.7.

More and more data confirm me frequently that we already reached the
critical mass to declare that the migration to Python 3 is done.

There was no Python 2.8, I suggest to skip 3.8. Ten years is enough between
two major versions...

To be clear, I only propose to change the version number. Not break
anything. Not remove anything. Any pending removal scheduled for 4.0 must
be postponed, maybe to 4.1, maybe 4.2, maybe never.

Linux switched from 3.x to 4.x and didn't break anything. We can do the
same.

--

Ok, some people like me want to break the backward compatibility. You have
to fight against that and make sure that incompatible changes are limited
and very small per release.

Please don't use the C API as any promise of anything. This project is
highly experimental and don't iffer anaything except pain at this point ;-)

Victor

Le mardi 25 septembre 2018, Yury Selivanov  a
écrit :
> What's the current plan for what version of Python we release after 3.9?
>
> The reason I'm asking this is because I frequently need to refer to
> *that version* of Python in the documentation, especially when I'm
> deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
> implying that 4.0 will be released right after 3.9.
>
> I've heard multiple opinions on this subject. One of them is that we
> should release 4.0 when we have a major new change, like removal of
> the GIL or introduction of a JIT compiler.  On the other hand, we have
> no estimate when we have such a change. We also don't want Python 4.0
> to be backwards incompatible with Python 3.0 (at least not at the
> scale of 2 vs 3).  So to me, it seems logical that we simply release
> Python 4.0 after Python 3.9.  After all, after 3.9 Python will be
> drastically different from 3.0 and from 2.7.  It sounds better. :)
>
> Finally, I'm not sure we need a new governance in place to make this
> decision or maybe we can make it now. That's why I'm posting this to
> python-committers to see if core devs already have a consensus on
> this.
>
> Yury
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Facundo Batista
2018-09-25 16:30 GMT-03:00 Yury Selivanov :

> deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
> implying that 4.0 will be released right after 3.9.
>
> I've heard multiple opinions on this subject. One of them is that we
> should release 4.0 when we have a major new change, like removal of
> the GIL or introduction of a JIT compiler.  On the other hand, we have
> no estimate when we have such a change. We also don't want Python 4.0
> to be backwards incompatible with Python 3.0 (at least not at the
> scale of 2 vs 3).  So to me, it seems logical that we simply release
> Python 4.0 after Python 3.9.  After all, after 3.9 Python will be
> drastically different from 3.0 and from 2.7.  It sounds better. :)

On the other hand... the best chance we have to let the world know
that "we will never ever again break everything as we did with the 2
to 3 transition" is to just release 4.0 after 3.9 as a simple follow
up release with just the minor and usual glitches we have from minor
to minor release.

IOW, we're breaking the major/minor revision evolution, but we're
firmly signaling that a transition that could take a decade will not
happen anymore in the future, that we learned the lesson and all
evolution steps will be smooth.

See it as more a political/social decision, than a technical one.

Note 1: I remember Guido saying something like this, but to be fair I
couldn't find any mail with a statement like that in a 10' exploration
I just did.

Note 2: I know we planned 2.7.10 after 2.7.9, but that just reinforces
my point: the idea is to communicate that we'll never have again a
dead end like 2.7.

Regards,

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org.ar/
Twitter: @facundobatista
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Yury Selivanov
On Tue, Sep 25, 2018 at 5:18 PM Nathaniel Smith  wrote:
>
> On Tue, Sep 25, 2018, 12:30 Yury Selivanov  wrote:
>>
>> The reason I'm asking this is because I frequently need to refer to
>> *that version* of Python in the documentation, especially when I'm
>> deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
>> implying that 4.0 will be released right after 3.9.
>
>
> I don't know what we'll end up calling it, but I don't think it matters for 
> this. For warnings about future deprecations and removals, I would use "3.10" 
> regardless.
>
> No one can predict the future; maybe our future selves will change their 
> minds when we get there. But for people reading the documentation now, "3.10" 
> clearly means "the version after 3.9", so they'll understand what you mean. 
> And if it ends up being called 4.0 then that's higher than 3.10 anyway, so no 
> one can claim you didn't warn them.
>
> OTOH if you write "4.0", at least some people will misunderstand, and be 
> grumpy if the feature disappears in 3.10.

Yeah, this makes sense.

Yury
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Nathaniel Smith
On Tue, Sep 25, 2018, 12:30 Yury Selivanov  wrote:

> The reason I'm asking this is because I frequently need to refer to
> *that version* of Python in the documentation, especially when I'm
> deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
> implying that 4.0 will be released right after 3.9.
>

I don't know what we'll end up calling it, but I don't think it matters for
this. For warnings about future deprecations and removals, I would use
"3.10" regardless.

No one can predict the future; maybe our future selves will change their
minds when we get there. But for people reading the documentation now,
"3.10" clearly means "the version after 3.9", so they'll understand what
you mean. And if it ends up being called 4.0 then that's higher than 3.10
anyway, so no one can claim you didn't warn them.

OTOH if you write "4.0", at least some people will misunderstand, and be
grumpy if the feature disappears in 3.10.

-n
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Brian Curtin
On Tue, Sep 25, 2018 at 2:38 PM Serhiy Storchaka 
wrote:

> 25.09.18 22:40, Barry Warsaw пише:
> > On Sep 25, 2018, at 15:31, Antoine Pitrou  wrote:
> >> So my preference would be on 3.10.
> > 3.9 + 0.1 :)
> >
> > Renaming it to Python 4 is fraught with knock-on effects, so I think we
> do reserve that for major changes.  I doubt we’ll ever need for a
> disruptive backward incompatible change *at the Python level* in a Python
> 4, but I absolutely can see the possibility of incompatible changes at the
> public C API layer.  I’m not saying it *will* happen, but that’s what we
> should reserve “Python 4” for if or when it happens.
>
> I concur.
>
> And changing the major version number itself is significant breaking
> change. From the name of the executable (python3 vs python4) hardcoded
> in Python and shell scripts to a number of third-party scripts that
> contain in the best case:
>
>  PY3 = sys.version_info[0] == 3
>  if not PY3:
>  ... # implies Python 2
>
> and in the worst case:
>
>  PY3 = sys.version[0] == '3'
>
> Changing the minor version number from a single-digit to a two-digits
> will break some software too, but I think that this breakage is smaller.
>

FWIW, we had a similar bump in 2015 (?) when 2.7.10 was about to come out.
Moving up to two digits might break some assumptions, though users misusing
things isn't really our problem. Someone out there is parsing
`sys.version[:5]` or `platform.python_version()` instead of the
alternatives that are better suited to getting specific parts of the
version.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Yury Selivanov
On Tue, Sep 25, 2018 at 4:38 PM Serhiy Storchaka  wrote:
[..]
> And changing the major version number itself is significant breaking
> change. From the name of the executable (python3 vs python4) hardcoded
> in Python and shell scripts to a number of third-party scripts that
> contain in the best case:
>
>  PY3 = sys.version_info[0] == 3
>  if not PY3:
>  ... # implies Python 2
>
> and in the worst case:
>
>  PY3 = sys.version[0] == '3'
>
> Changing the minor version number from a single-digit to a two-digits
> will break some software too, but I think that this breakage is smaller.

I think this is the last nail in the coffin of the "Python 4.0 after 3.9" idea.

Seems that we've reached the consensus: we release Python 3.10 after
Python 3.9.  We maybe release Python 4.0 at some point if there's a
significant backwards incompatible change.

Yury
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Serhiy Storchaka

25.09.18 22:40, Barry Warsaw пише:

On Sep 25, 2018, at 15:31, Antoine Pitrou  wrote:

So my preference would be on 3.10.

3.9 + 0.1 :)

Renaming it to Python 4 is fraught with knock-on effects, so I think we do 
reserve that for major changes.  I doubt we’ll ever need for a disruptive 
backward incompatible change *at the Python level* in a Python 4, but I 
absolutely can see the possibility of incompatible changes at the public C API 
layer.  I’m not saying it *will* happen, but that’s what we should reserve 
“Python 4” for if or when it happens.


I concur.

And changing the major version number itself is significant breaking 
change. From the name of the executable (python3 vs python4) hardcoded 
in Python and shell scripts to a number of third-party scripts that 
contain in the best case:


    PY3 = sys.version_info[0] == 3
    if not PY3:
    ... # implies Python 2

and in the worst case:

    PY3 = sys.version[0] == '3'

Changing the minor version number from a single-digit to a two-digits 
will break some software too, but I think that this breakage is smaller.

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Eric Snow
On Tue, Sep 25, 2018 at 1:30 PM Yury Selivanov  wrote:
> What's the current plan for what version of Python we release after 3.9?

One idea I've heard is to switch to calendar versioning after 3.9.  So
we'd start with something like "2021" (year) or "2021.06" (year +
month).  sys.version_info would stay monotonic and so would the
version macro in the C-API.  The executable would still be "python3"
so it may still make sense to incorporate "3" into the version.  When
we do get to a major/breaking change we'd change the executable to
"python4" and incorporate "4" into the version.

Switching to calver doesn't necessarily mean we'd tie ourselves to a
fixed release schedule, but doing so would probably fit better with
calver. :)

Anyway, this is just something I've heard discussed which I kind of liked.

-eric
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Paul Moore
On Tue, 25 Sep 2018 at 20:32, Antoine Pitrou  wrote:
>
>
> Le 25/09/2018 à 21:30, Yury Selivanov a écrit :
> > What's the current plan for what version of Python we release after 3.9?
> >
> > The reason I'm asking this is because I frequently need to refer to
> > *that version* of Python in the documentation, especially when I'm
> > deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
> > implying that 4.0 will be released right after 3.9.
> >
> > I've heard multiple opinions on this subject. One of them is that we
> > should release 4.0 when we have a major new change, like removal of
> > the GIL or introduction of a JIT compiler.  On the other hand, we have
> > no estimate when we have such a change. We also don't want Python 4.0
> > to be backwards incompatible with Python 3.0 (at least not at the
> > scale of 2 vs 3).  So to me, it seems logical that we simply release
> > Python 4.0 after Python 3.9.  After all, after 3.9 Python will be
> > drastically different from 3.0 and from 2.7.  It sounds better. :)
>
> Many people have bad memories of the Py2->3 transition, so I think we
> should avoid triggering their sensitivities by announcing a Py4 if
> there's nothing, in terms of changes, to justify the jump.
>
> So my preference would be on 3.10.

I agree. 3.10 seems like the best choice. Even though we don't expect
4.0 to be a major breaking change like 3.0, people do assume something
like semantic versioning, and therefore expect 3.9 -> 4.0 to be a
"bigger" change than 3.9 -> 3.10.

One thing that *will* need work is places that assume single-digit
version components (for example the wheel spec uses pyXY to mark
compatibility with Python X.Y - that will need tweaking to allow for
3.10). IMO, we should make it clear sooner rather than later that
version numbering will be going 3.8, 3.9, 3.10, 3.11, ... to give
people a chance to prepare. Otherwise we might inadvertently have
another major compatibility issue right after 3.9 :-( The uncertainty
simply lets people assume whatever's least disruptive for them, and
not be ready.

Paul
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Barry Warsaw
On Sep 25, 2018, at 15:31, Antoine Pitrou  wrote:
> 
> So my preference would be on 3.10.

3.9 + 0.1 :)

Renaming it to Python 4 is fraught with knock-on effects, so I think we do 
reserve that for major changes.  I doubt we’ll ever need for a disruptive 
backward incompatible change *at the Python level* in a Python 4, but I 
absolutely can see the possibility of incompatible changes at the public C API 
layer.  I’m not saying it *will* happen, but that’s what we should reserve 
“Python 4” for if or when it happens.

-Barry





signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Matthias Klose
On 25.09.2018 21:30, Yury Selivanov wrote:
> What's the current plan for what version of Python we release after 3.9?
> 
> The reason I'm asking this is because I frequently need to refer to
> *that version* of Python in the documentation, especially when I'm
> deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
> implying that 4.0 will be released right after 3.9.
> 
> I've heard multiple opinions on this subject. One of them is that we
> should release 4.0 when we have a major new change, like removal of
> the GIL or introduction of a JIT compiler.  On the other hand, we have
> no estimate when we have such a change. We also don't want Python 4.0
> to be backwards incompatible with Python 3.0 (at least not at the
> scale of 2 vs 3).  So to me, it seems logical that we simply release
> Python 4.0 after Python 3.9.  After all, after 3.9 Python will be
> drastically different from 3.0 and from 2.7.  It sounds better. :)

why call it 4.0 when there are no significant changes?  Just calling it
4.something sends the wrong signal, that probably people try to skip 3.x and
keep going with 2.7 ...

> Finally, I'm not sure we need a new governance in place to make this
> decision or maybe we can make it now. That's why I'm posting this to
> python-committers to see if core devs already have a consensus on
> this.

sorry, for me that sounds like a non-decision.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Antoine Pitrou

Le 25/09/2018 à 21:30, Yury Selivanov a écrit :
> What's the current plan for what version of Python we release after 3.9?
> 
> The reason I'm asking this is because I frequently need to refer to
> *that version* of Python in the documentation, especially when I'm
> deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
> implying that 4.0 will be released right after 3.9.
> 
> I've heard multiple opinions on this subject. One of them is that we
> should release 4.0 when we have a major new change, like removal of
> the GIL or introduction of a JIT compiler.  On the other hand, we have
> no estimate when we have such a change. We also don't want Python 4.0
> to be backwards incompatible with Python 3.0 (at least not at the
> scale of 2 vs 3).  So to me, it seems logical that we simply release
> Python 4.0 after Python 3.9.  After all, after 3.9 Python will be
> drastically different from 3.0 and from 2.7.  It sounds better. :)

Many people have bad memories of the Py2->3 transition, so I think we
should avoid triggering their sensitivities by announcing a Py4 if
there's nothing, in terms of changes, to justify the jump.

So my preference would be on 3.10.

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


[python-committers] Python 4.0 or Python 3.10?

2018-09-25 Thread Yury Selivanov
What's the current plan for what version of Python we release after 3.9?

The reason I'm asking this is because I frequently need to refer to
*that version* of Python in the documentation, especially when I'm
deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
implying that 4.0 will be released right after 3.9.

I've heard multiple opinions on this subject. One of them is that we
should release 4.0 when we have a major new change, like removal of
the GIL or introduction of a JIT compiler.  On the other hand, we have
no estimate when we have such a change. We also don't want Python 4.0
to be backwards incompatible with Python 3.0 (at least not at the
scale of 2 vs 3).  So to me, it seems logical that we simply release
Python 4.0 after Python 3.9.  After all, after 3.9 Python will be
drastically different from 3.0 and from 2.7.  It sounds better. :)

Finally, I'm not sure we need a new governance in place to make this
decision or maybe we can make it now. That's why I'm posting this to
python-committers to see if core devs already have a consensus on
this.

Yury
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Council / board (Was: 1 week to Oct 1)

2018-09-25 Thread Brett Cannon
On Tue, 25 Sep 2018 at 09:18, M.-A. Lemburg  wrote:

> On 25.09.2018 16:28, Mariatta Wijaya wrote:
> > My proposal is taking into consideration The PSF's mission and diversity
> > statement. I will not remove the diversity clause from PEP 8011.
>
> I cannot comment on what you actually have in PEP 8011 as
> diversity clause, since the page is just a placeholder at the
> moment, but please take into consideration that we're *not* debating a
> council which is to represent the Python community or other group of
> people.
>
> The council is intended to be a technical body for steering language
> design and needs experts as members who we all trust and respect
> to make good decisions - regardless of any other criteria and,
> of course, open to all core developers, regardless of background
> (which is what the PSF diversity statement is all about).
>
> > To save us all trouble of discussing this particular issue, for those of
> > you who disagree completely, and have other ideas about how you'd like
> > Python to be governed and who should be in it, you can do one or more of
> > the following:
> >
> > - not vote on my PEP
> > - vote on the other PEPs
> > - write their own PEP
>
> I think we're grown up enough to work on these PEPs together and
> in the usual spirit of coming up with good solutions. We owe
> this to the Python community at large who will be affected by
> whatever we decide.


Correct, but since the PEP isn't ready to be published for discussion this
thread is all speculation based on imperfect information since Mariatta
tried to summarize something ahead of time.

For me personally, I am not going to participate in any discussion about
any PEP until there is a published text to refer to, otherwise the
discussion is ripe for misunderstandings. If a PEP comes out which people
disagree with and want an alternative for I'm sure we can give them an
opportunity to create a tweaked PEP (but I also assume we will have a civil
discussion first in hopes of finding consensus first).
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Council / board (Was: 1 week to Oct 1)

2018-09-25 Thread Donald Stufft


> On Sep 25, 2018, at 12:24 PM, Antoine Pitrou  wrote:
> 
> 
> Le 25/09/2018 à 18:10, Guido van Rossum a écrit :
>>To save us all trouble of discussing this particular issue, for
>>those of you who disagree completely, and have other ideas about how
>>you'd like Python to be governed and who should be in it, you can do
>>one or more of the following:
>> 
>>- not vote on my PEP
>>- vote on the other PEPs
>>- write their own PEP
>> 
>> 
>> I would remind people that it's well documented that diverse group make
>> better decisions.
> 
> Can you point us to such documentation?  It would be nice to know under
> which conditions the assertion holds, according to which metrics, etc.


https://hbr.org/2016/11/why-diverse-teams-are-smarter 
 includes links to 
several studies. There are a lot more results as well to the search “diverse 
teams make better decisions” or “diverse groups decision making” on Google as 
well if those studies are lacking to you.


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Council / board (Was: 1 week to Oct 1)

2018-09-25 Thread Antoine Pitrou

Le 25/09/2018 à 18:10, Guido van Rossum a écrit :
> To save us all trouble of discussing this particular issue, for
> those of you who disagree completely, and have other ideas about how
> you'd like Python to be governed and who should be in it, you can do
> one or more of the following:
> 
> - not vote on my PEP
> - vote on the other PEPs
> - write their own PEP
> 
> 
> I would remind people that it's well documented that diverse group make
> better decisions.

Can you point us to such documentation?  It would be nice to know under
which conditions the assertion holds, according to which metrics, etc.

Also, may I make the matter more concrete?  You have been the BDFL
during 20+ years.  A one-person deciding group of a single white male is
not exactly diverse.  Retrospectively, do you think this led you to take
worse decisions?

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Council / board (Was: 1 week to Oct 1)

2018-09-25 Thread M.-A. Lemburg
On 25.09.2018 16:28, Mariatta Wijaya wrote:
> My proposal is taking into consideration The PSF's mission and diversity
> statement. I will not remove the diversity clause from PEP 8011.

I cannot comment on what you actually have in PEP 8011 as
diversity clause, since the page is just a placeholder at the
moment, but please take into consideration that we're *not* debating a
council which is to represent the Python community or other group of
people.

The council is intended to be a technical body for steering language
design and needs experts as members who we all trust and respect
to make good decisions - regardless of any other criteria and,
of course, open to all core developers, regardless of background
(which is what the PSF diversity statement is all about).

> To save us all trouble of discussing this particular issue, for those of
> you who disagree completely, and have other ideas about how you'd like
> Python to be governed and who should be in it, you can do one or more of
> the following:
> 
> - not vote on my PEP
> - vote on the other PEPs
> - write their own PEP

I think we're grown up enough to work on these PEPs together and
in the usual spirit of coming up with good solutions. We owe
this to the Python community at large who will be affected by
whatever we decide. Personal agendas should put be aside for
the time being.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Sep 25 2018)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Council / board (Was: 1 week to Oct 1)

2018-09-25 Thread Guido van Rossum
On Tue, Sep 25, 2018 at 7:28 AM Mariatta Wijaya  wrote:

> My proposal is taking into consideration The PSF's mission and diversity
> statement. I will not remove the diversity clause from PEP 8011.
>

+1


> To save us all trouble of discussing this particular issue, for those of
> you who disagree completely, and have other ideas about how you'd like
> Python to be governed and who should be in it, you can do one or more of
> the following:
>
> - not vote on my PEP
> - vote on the other PEPs
> - write their own PEP
>

I would remind people that it's well documented that diverse group make
better decisions. And given that there is a historical bias, often
unconscious, towards white men I think it's good to try to counter this
bias explicitly.

I should also think that "merit-based" criteria tend to reinforce the
existing unconscious bias.

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Council / board (Was: 1 week to Oct 1)

2018-09-25 Thread Antoine Pitrou

Le 25/09/2018 à 17:49, Victor Stinner a écrit :
> Le mar. 25 sept. 2018 à 13:57, Antoine Pitrou  a écrit :
>> Not sure what you mean here.  What you are asking for is routinely
>> called, AFAIK, "positive discrimination".  Please correct me if I'm wrong.
>>
>> You ask me to assume positive intent, but you are the one assuming
>> negative intent on my part...
> 
> Note: in french, we say "discrimation positive", but in english, we
> prefer "positive action".

Well, apparently it may be about British English vs. American English:
https://en.oxforddictionaries.com/definition/positive_discrimination

... which brings us back to the linguistic issues I pointed out in a
previous message.

> If anyone is interested to talk about diversity, code of conduct and
> things like that: please contact me in private.
> 
> These topics are difficult to discuss in a public space. At least, I'm
> not comfortable today to talk about them in public. There are good
> reasons why people don't talk about things like that in public.

Perhaps, but there are also good reasons why debates that lead to
governance decisions should be help publicly.

While it's ok for personal anecdotes to only be shared privately,
mandating that general debate takes place privately will only shut down
debate.

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] 1 week to Oct 1

2018-09-25 Thread Antoine Pitrou

Le 25/09/2018 à 17:54, Guido van Rossum a écrit :
> On Tue, Sep 25, 2018 at 7:11 AM Antoine Pitrou  > wrote:
> 
> I would suggest November 1st, so that nobody feels pressured.
> 
> 
> You realize that then exactly the same will happen around that date, right?

Not really.

> Have you ever been on the organizing side of a conference? Both
> paper/talk submissions and attendee registrations tend to happen
> immediately before the deadline.

I'll take your word for it.

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] 1 week to Oct 1

2018-09-25 Thread Guido van Rossum
On Tue, Sep 25, 2018 at 7:11 AM Antoine Pitrou  wrote:

> I would suggest November 1st, so that nobody feels pressured.
>

You realize that then exactly the same will happen around that date, right?

Have you ever been on the organizing side of a conference? Both paper/talk
submissions and attendee registrations tend to happen immediately before
the deadline.

I propose not to move the deadline *unless* the PEP authors ask for an
extension on the eve of Oct 1st.

-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Council / board (Was: 1 week to Oct 1)

2018-09-25 Thread Victor Stinner
Le mar. 25 sept. 2018 à 13:57, Antoine Pitrou  a écrit :
> Not sure what you mean here.  What you are asking for is routinely
> called, AFAIK, "positive discrimination".  Please correct me if I'm wrong.
>
> You ask me to assume positive intent, but you are the one assuming
> negative intent on my part...

Note: in french, we say "discrimation positive", but in english, we
prefer "positive action".

Le mar. 25 sept. 2018 à 14:42, Giampaolo Rodola'  a écrit :
> "white men", "women", "slave"... Personally I find this tendency quite
> worrying and discriminating and frankly I don't understand what it has
> to do with a programming language nor why it's emerging only recently.
> (...)

If anyone is interested to talk about diversity, code of conduct and
things like that: please contact me in private.

These topics are difficult to discuss in a public space. At least, I'm
not comfortable today to talk about them in public. There are good
reasons why people don't talk about things like that in public.

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Council / board (Was: 1 week to Oct 1)

2018-09-25 Thread Paul Moore
On Tue, 25 Sep 2018 at 15:28, Mariatta Wijaya  wrote:
>
> My proposal is taking into consideration The PSF's mission and diversity 
> statement. I will not remove the diversity clause from PEP 8011.
>
> To save us all trouble of discussing this particular issue, for those of you 
> who disagree completely, and have other ideas about how you'd like Python to 
> be governed and who should be in it, you can do one or more of the following:
>
> - not vote on my PEP
> - vote on the other PEPs
> - write their own PEP

Or presumably

- discuss the concerns during the debate phase of the process

?

At the moment the discussion seems to be about a possible
misinterpretation of a possible misquote of something the PEP might
end up saying. It seems like it's probably worth waiting until the
facts are clear before saying anything more. But once there's an
actual PEP (not a placeholder) in place, I assume that discussions
about the content *will* be acceptable (as long as they are reasonable
and respectful, obviously). I don't recall the expected details of the
actual process (if they've been published yet) but I don't expect them
to be simply "here's the PEPs, let's vote!".

Paul
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] 1 week to Oct 1

2018-09-25 Thread Antoine Pitrou


Le 25/09/2018 à 16:07, Barry Warsaw a écrit :
> On Sep 24, 2018, at 14:32, Mariatta Wijaya  wrote:
>>
>> 1. Is everyone still ok with the Oct 1 as deadline for coming up with 
>> governance PEPs?
> 
> I’m afraid that I may not be, actually.  I expected to have time to work on 
> my PEP while I was on leave for my son’s wedding, but y’know, family! :)  
> Mariatta and I are collaborating a bit on 8011, but I haven’t really had time 
> to work on 8010.  I don’t want to push it back too far, but a couple of weeks 
> would really help.

I would suggest November 1st, so that nobody feels pressured.

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] 1 week to Oct 1

2018-09-25 Thread Barry Warsaw
On Sep 24, 2018, at 14:32, Mariatta Wijaya  wrote:
> 
> 1. Is everyone still ok with the Oct 1 as deadline for coming up with 
> governance PEPs?

I’m afraid that I may not be, actually.  I expected to have time to work on my 
PEP while I was on leave for my son’s wedding, but y’know, family! :)  Mariatta 
and I are collaborating a bit on 8011, but I haven’t really had time to work on 
8010.  I don’t want to push it back too far, but a couple of weeks would really 
help.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Council / board (Was: 1 week to Oct 1)

2018-09-25 Thread Giampaolo Rodola'
On Tue, Sep 25, 2018 at 1:52 PM Mariatta Wijaya  wrote:
>
> > * Mariatta proposed to require to have a least one woman in that
> > council.
>
> > Why stop at women?
>
>
> My actual wording was: "not all white men", which actually means quite 
> different from "must include one woman".
>
> I don't appreciate you jumping straight to accusing me for discrimination. 
> Assume positive intent, and ask for clarity before scrutinizing and making 
> accusations.

"white men", "women", "slave"... Personally I find this tendency quite
worrying and discriminating and frankly I don't understand what it has
to do with a programming language nor why it's emerging only recently.
Whoever ends up in the council, approves a PEP, writes a patch, merges
a PR... I think that person should be elected based *entirely* on
their merits, not because of their gender or skin color. Electing
someone just to represent a minority doesn't have anything to do with
IT and cannot lead to a good outcome in the long run IMHO.
--
Giampaolo - http://grodola.blogspot.com
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Council / board (Was: 1 week to Oct 1)

2018-09-25 Thread Antoine Pitrou

Le 25/09/2018 à 13:52, Mariatta Wijaya a écrit :
> I don't appreciate you jumping straight to accusing me for
> discrimination. Assume positive intent, and ask for clarity before
> scrutinizing and making accusations.

Not sure what you mean here.  What you are asking for is routinely
called, AFAIK, "positive discrimination".  Please correct me if I'm wrong.

You ask me to assume positive intent, but you are the one assuming
negative intent on my part...

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Council / board (Was: 1 week to Oct 1)

2018-09-25 Thread Mariatta Wijaya
> * Mariatta proposed to require to have a least one woman in that
> council.

> Why stop at women?


My actual wording was: "not all white men", which actually means quite
different from "must include one woman".

I don't appreciate you jumping straight to accusing me for discrimination.
Assume positive intent, and ask for clarity before scrutinizing and making
accusations.

My PEP will provide guideline on how members of the group should be
nominated, and it is a long list. It will not name names. Only once the PEP
has been accepted that people can nominate folks to fill the role, and
there will be another round of voting.

Some of the questions asked by Victor will be answered in the PEP that I'm
writing, so I will not answer now.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Council / board (Was: 1 week to Oct 1)

2018-09-25 Thread Antoine Pitrou

Hi,

Le 25/09/2018 à 12:14, Victor Stinner a écrit :
> 
> Since there are no concrete PEPs, I don't know where I should post my
> comments. I decided to send them here :-)
> 
> For the new council/board idea (group of 3 or 5 peoples):
> 
> * Can we require that each people comes from a different company? At
> least, require that no all of them work for the same company. I would
> mean that a member of this council would have to nominate someone else
> if they decide to move to a different company which already has ("too
> many") council members.

The details must be ironed out, but that sounds like a good idea.  There
were routinely concerns about  influencing the Python
development process.  Once it was Google, nowadays it seems to be Microsoft.

(admittedly, Google probably didn't influence us very much in the end,
but I'm not sure it's because we are immune to such a danger, rather
than Python simply not being an attractive target enough, as opposed to
e.g. Go or Javascript)

> * Mariatta proposed to require to have a least one woman in that
> council. What do you think of this idea? Honestly, I have no opinion
> yet, since I don't think this idea has been discussed enough yet. I
> would expect that only core developers could join the council and
> right now, there are 4 women core developers: Mariatta, Carol, Emily,
> Lisa.

Why stop at women?  There are many underrepresented groups.  You could
discriminate based on gender, skin colour, nationality, socio-economic
origins, etc.

The main problem, though, is we are talking about a very little group
chosen amongst a likely very small number of candidates (I don't expect
more than a dozen candidates, two dozens at most).  If you start doing
positive discrimination amongst such a small number of people, you
disrupt the democratic process (by which I mean voting) a *lot*.

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)

2018-09-25 Thread M.-A. Lemburg
On 21.09.2018 14:59, Paul Moore wrote:
> Balance, forgiveness, and a mature level of empathy are what's
> *really* needed ("among the things that are needed...":-)). Not
> policies. Policies should be weapons of last resort.

Agreed.

I guess we'll also have to learn that flamebait as we had it in the
old days is now often launched as cocbait.

It'll take some time to get used to this, but we'll have to try
not to fall for it.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Sep 25 2018)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] 1 week to Oct 1

2018-09-25 Thread Victor Stinner
I wanted to read these 4 PEPs:

Le lun. 24 sept. 2018 à 20:32, Mariatta Wijaya
 a écrit :
> - https://www.python.org/dev/peps/pep-8001 Python Governance Voting Process
> - https://www.python.org/dev/peps/pep-8010 The BDFL Governance Model
> - https://www.python.org/dev/peps/pep-8011 The Council Governance Model (I'm 
> claiming this PEP)
> - https://www.python.org/dev/peps/pep-8012 The Community Governance Model

All of them are empty.

> 1. Is everyone still ok with the Oct 1 as deadline for coming up with 
> governance PEPs?

It doesn't make sense to me:

* Nothing explains how we take a decision: PEP 8001 is empty
* Governance PEPs are empty: how are we supposed to take a decision on
an empty PEP?

> 2. How do we discuss these PEPs?

I suggest to use emails as we did previously, but only on
python-committers. If someone wants to change that, I suggest to wait
after the new governance is decided.

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] 1 week to Oct 1

2018-09-25 Thread Antoine Pitrou

Le 24/09/2018 à 20:32, Mariatta Wijaya a écrit :
> It is now 7 days until October 1, the deadline for coming up with Python
> Governance PEPs.
> 
> Some still relevant links:
> 
> - https://www.python.org/dev/peps/pep-8000/ Python Language Governance
> Proposal Overview
> - https://www.python.org/dev/peps/pep-8001 Python Governance Voting Process
> - https://www.python.org/dev/peps/pep-8002 Open source governance survey
> 
> These are current ideas and proposals, some are placeholders still.
> 
> - https://www.python.org/dev/peps/pep-8010 The BDFL Governance Model
> - https://www.python.org/dev/peps/pep-8011 The Council Governance Model
> (I'm claiming this PEP)
> - https://www.python.org/dev/peps/pep-8012 The Community Governance Model
> - https://www.python.org/dev/peps/pep-8013/ The External Council
> Governance Model
> - https://www.python.org/dev/peps/pep-8014/ The Commons Governance Model
> 
> I have some questions:
> 
> 1. Is everyone still ok with the Oct 1 as deadline for coming up with
> governance PEPs?

As I predicted, Oct 1 seems to be coming up too early.

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/