[python-committers] Re: Notification of a three-month ban from Python core development

[Yury Selivanov]

On Thu, Jul 23, 2020 at 8:53 AM Nathaniel Smith  wrote:
>
> On Thu, Jul 23, 2020, 05:25 Jack Diederich  wrote:
>>
>> I'm sorry we had to ban Guido for three months but maybe he'll learn his 
>> lesson and not merge commit messages that include screeds about "relics of 
>> white supremacy".
>
>
> I'm guessing there's some layers of irony or sarcasm in this message, but I'm 
> definitely not able to unpack them, and I think it's spectacularly 
> inappropriate regardless. Maybe you're only joking when you say Guido is at 
> fault here, and maybe you're only joking when you act like the problem with 
> white supremacy is people mentioning the existence of white supremacy. I 
> don't know. I hope so, because both statements are completely false. But 
> there are certainly plenty of people who think both those things, so it 
> doesn't work as a joke.

+1. Toxic emails like this are one of the reasons why I'm not actively
following Python lists anymore.

Yury
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/J35725V5IFBJUNIPP2VSIPHFLV7Y26GV/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Please avoid non-bugfix changes during the beta phase

[Yury Selivanov]

On Mon, Jul 6, 2020 at 7:21 PM Raymond Hettinger
 wrote:

> If not, perhaps we should just have a single beta, frozen except for bugfixes.

+1 for having betas frozen, except for bug fixes. But the bug fixes
need to go somewhere, so I propose to have yet another frozen beta (if
there are bug fixes, of course). Oh wait, that's exactly our current
workflow!

Yury
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/4WJKYHODOSLQUMOV6HHHKWOFUCX6KBML/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Vote to promote Kyle Stanley

[Yury Selivanov]

I created a poll to promote Kyle Stanley as a core dev.

Please read more and vote here:
https://discuss.python.org/t/vote-to-promote-kyle-stanley/3839.

Thank you!

Yury
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/JQSGFJNJSEVHNCMSQJN576I2J6KQZXGW/
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] python-committers is dead, long live discuss.python.org

[Yury Selivanov]

On Sat, Sep 29, 2018 at 10:16 AM Steven D'Aprano  wrote:
[..]
> Well, I could announce it, but nobody would pay any attention. Why
> should we pay attention to this announcement? No offense to Łukasz, but
> how did he get put in charge of this?

You could and everybody would pay attention.

As for Łukasz and Discourse:

(1) I remember asking Brett, Łukasz, Victor, Guido and few other core
devs if we can do something to "fix" python-ideas at the previous core
devs sprint (2 years ago). I also remember Guido saying that PEPs
discussions on mailing lists are super hard to manage, and that he
wishes we can do that on GitHub.  A frustration with our mailing lists
has been a known issue for many core devs for a long time.

(2) Brett has previously expressed that moderating and enforcing CoC
on our mailing lists isn't a pleasant experience.  Discourse provides
way more tools to make discussions more manageable.  Hopefully it will
allow to diffuse heated discussions before anyone needs to even think
about CoC.

(3) We want to try Discource now because discussions on python-ideas,
python-dev, and python-committers became *unbearable* to many core
devs (including myself).  Most of the time I find it inconvenient to
even read them, left alone engage.

(4) E-mail is clearly more convenient to *follow* the discussion to a
lot core devs in this threads.  Discourse, hopefully, will enable many
other core developers to *want* to follow and feel *safe* to engage.

Given all the above, Łukasz *volunteered* his own time to help setup
Discourse and help everyone to migrate to it so that we can all try
it.  When he announced that we want to try Discourse at the sprints,
out of all people there I remember only Barry asking questions about
email integration.  Everybody else including Guido, Brett, Raymond,
Victor, Mariatta, and many others were OK to try Discourse.  As I can
see, Łukasz himself doesn't have any interests in this migration
besides trying to make our communication more enjoyable and welcoming.

Lastly, I understand everybody who likes e-mail and their e-mail
clients.  I'm such a person myself.  Learning a completely new tool
and using browser to access it isn't easy for me either.  But I'm
willing to try to sacrifice some of my convenience in order to see if
the new medium can enable us to have more polite discussions and if
core developers who don't want to engage now become comfortable to
join us again.

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?

[Yury Selivanov]

On Thu, Sep 27, 2018 at 2:19 PM Brett Cannon  wrote:
>
> Since there isn't a way to do this in any fashion I never really thought 
> about it. I think most people either set the shebang to the version of Python 
> they want it to work with, have pip install the entry point which will also 
> set the entry point, or assume that e.g. python3 is new enough to work.
>
> But even setting a minimum is potentially troublesome if there's an 
> incompatibility, e.g. you used 'async' as a variable name and suddenly you 
> installed Python 3.7. :) So I don't know if the desire/utility of having a 
> minimum is worth the added complexity.

I agree.

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?

[Yury Selivanov]

On Wed, Sep 26, 2018 at 1:25 PM Paul Moore  wrote:
[..]
> but I don't know how
> useful it would be in practice - can you give some examples of use
> cases?)

It's hard to give a real life example as "py" doesn't support this,
but I can imagine the following scenario: if I have a script that uses
some new 3.6 feature I could probably run it from other scripts with
'py --min=3.6 myscript.py'.  That way I wouldn't need to write more
code or use other tools to check if the target system has a Python
3.6+ interpreter.

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?

[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?

[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?

[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/

[python-committers] Python 4.0 or Python 3.10?

[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] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)

[Yury Selivanov]

On Thu, Sep 20, 2018 at 4:37 PM Antoine Pitrou  wrote:
>
>
> Apparently it's this one:
> https://mail.python.org/pipermail/python-ideas/2018-September/053482.html

After reading the original email I, personally, am in support of the
WG & Brett's decision.

I also think that we need a neutral third-party to enforce CoC; it's
unfortunate that Brett is the one who has to be dragged though this.

>
> By the way, regardless of this single case, I would like people to think
> of the broader issue we're having.  It's more than a single contentious
> decision.

This is why we want to try Discourse for the upcoming governance
discussions.  We'll see if its tools to organize and moderate
discussions (and some would agree better UX) make a difference.

Yury

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] Organizing an informational PEP on project governance options

[Yury Selivanov]

Hi Antoine,

I'll try to find some time and help. I'm not sure how much time I can
contribute exactly, but I at least can help with a review and maybe
brainstorm. Count me in.

Yury
On Wed, Aug 8, 2018 at 1:39 PM Antoine Pitrou  wrote:
>
>
> Hi all,
>
> I contacted Nathaniel and the people who had mentioned interest in
> private, so as not to lose momentum and try to move this forward.  So
> far only Doug responded.  If anyone else wants to participate, feel free
> to contact me / us (either on-list or in private).
>
> I think we need at least 2 or 3 core developers on this, and of course
> we can also invite non-core developers.
>
> Regards
>
> Antoine.
>
>
> Le 08/08/2018 à 19:02, Mariatta Wijaya a écrit :
> > Hi Nathaniel,
> >
> > I know you mentioned my name earlier, and thanks for thinking of me. But
> > I'm really sorry, I just don't have the bandwidth to help out with this
> > right now.
> >
> > Not sure if you've made any progress yet. Since the intention is to
> > collect information of the various governance models out there, I was
> > thinking perhaps you can ask non core developers to help out with this
> > effort. So that way you're not constrained by the limited number of core
> > devs and their limited free time available.
> >
> > What do you think?
> >
> > Mariatta
> >
> >
> > On Wed, Aug 1, 2018 at 8:17 PM Nathaniel Smith  > > wrote:
> >
> > I'm sorry, I seem to have accidentally licked a cookie [1] here. I'm
> > still keen to see this happen and to be a part of it, and have been
> > trying to be find the spoons to take the lead on organizing, but
> > it's been a few weeks now and that hasn't happened yet [2].
> >
> > Does anyone else want to take the lead here? A number of people have
> > expressed interest in helping or in making introductions to other
> > communities, and I think the next step would be to organize some
> > kind of kick off meeting to rough out an outline and start divvying
> > up work.
> >
> > -n
> >
> > [1] http://communitymgt.wikia.com/wiki/Cookie_Licking
> > [2] not to go into too many details, but basically I'm currently
> > sick, unemployed, and broke, which isn't a crisis but sorting it out
> > is sucking up a lot of energy.
> ___
> 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/



-- 
 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] Reminder of BDFL succession timeline + CFP

[Yury Selivanov]

On Thu, Aug 2, 2018 at 3:55 PM Jack Jansen  wrote:
>
> Nathaniel, you strike the nail on the head here.
>
> The reason Guido as BDFL and therefore ultimate authority on what “python” is 
> worked because it is organic: it is not set down in strict rules and 
> regulations and timelines and percentages of votes and what not. It works 
> because a very large fraction of the community accepts it. (And I know I’m 
> mixing past and present tense and I’m doing it on purpose:-)
>
> We need to come up with a new governance model, and I think that a 
> rules-and-regulations model is not a model that Python will thrive by. On the 
> contrary, I think it has the danger of moving people into a 
> rules-and-regulations mindset, and therefore lead to all sorts of decisions 
> being viewed in a “political” light, where before they wouldn’t be.
>
> And my worry is that be introducing deadlines and all that in the process 
> there is the danger that we will inexorably move to a strict governance 
> model. I would much prefer a process where we go here/there/everywhere and 
> slowly a consensus builds up.

I agree and that's why I also don't like the idea of having a strict
set of deadlines for voting on something that hasn't even been
proposed yet.

OTOH, it would be great if we can at least set a date to start the
discussion so that everybody can plan for it and join.  That's the
only way to keep the discussion open and equally accessible for
everyone.  If we do nothing, then naturally, those core devs who know
each other personally will start forming their opinion in isolated
groups. Many people will feel that they are completely removed from
the decision process and will end up in a very uncomfortable position.

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] Reminder of BDFL succession timeline + CFP

[Yury Selivanov]

On Thu, Aug 2, 2018 at 4:43 PM Brett Cannon  wrote:
>
> On Wed, 1 Aug 2018 at 17:58 Yury Selivanov  wrote:
>>
>> On Wed, Aug 1, 2018 at 8:29 PM Mariatta Wijaya
>>  wrote:
>> [..]
>> > I'm open to extend the dates, and even wait another year if we need to.
>> > Or do folks want to come up with a completely different process than what 
>> > I've proposed?
>> >
>> > In the end, I just want to know whether we will come to decision before 
>> > 2019, 2020, 2021, 2022, .. ?
>>
>> IMHO we should tweak the proposal to include just *one date for now*:
>> we want everybody interested to post their proposals by October 1st
>> (we can shift it + 2 weeks if people are on vacations right now).
>
>
> I was actually going to email suggesting this but Mariatta beat me to the 
> subject. :)
>

I think you've confused Mariatta with me here :)

> For me, I think aiming for October 1st to get the initial proposals in is a 
> good goal.

Yeah it looks like people don't oppose having October 1st as our first
*soft* sync point as long as we don't set any other deadlines right
now.

To sum up:

* We want everybody who has ideas about future Python governance model
to submit their initial proposals by that date.

* The discussion will start around October 1st and we'll figure out
what we do next (and when) based on its outcome.

I think this plan is reasonably relaxed, but at the same time will
gently motivate us to move forward.

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] Reminder of BDFL succession timeline + CFP

[Yury Selivanov]

On Wed, Aug 1, 2018 at 8:29 PM Mariatta Wijaya
 wrote:
[..]
> Please don't misunderstand my wanting to set up a deadlines and process as 
> wanting to rush things.

Absolutely, I understand, I didn't want to imply that "[name] is
rushing the process". Sorry if I sounded this way. I do have an
impression, though, that a large population of core devs is OK with
deadlines and the other sizable population doesn't understand why we
need a strict schedule right now.

> I'm open to extend the dates, and even wait another year if we need to.
> Or do folks want to come up with a completely different process than what 
> I've proposed?
>
> In the end, I just want to know whether we will come to decision before 2019, 
> 2020, 2021, 2022, .. ?

IMHO we should tweak the proposal to include just *one date for now*:
we want everybody interested to post their proposals by October 1st
(we can shift it + 2 weeks if people are on vacations right now).

The discussion will inevitably start as soon as we have a couple
proposals on the table.  Some proposals will be withdrawn, some will
require tweaks, people also might come up with new proposals.  We can
then decide what our next steps (and deadlines!) considering what will
be the outcome of these first debates.

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] Reminder of BDFL succession timeline + CFP

[Yury Selivanov]

On Wed, Aug 1, 2018 at 6:44 PM Mariatta Wijaya
 wrote:
>
>
> Thank you for the responses and concerns.
>
> I do want to keep this discussion open and ongoing, and I still think that we 
> do need a set deadline on things.

I talked to a few core developers recently (at EuroPython and over
messengers) and I had an impression that some of them don't like an
idea of making a decision faster than everybody has a chance to say
their word.  Some of them are shy to publicly object to having strict
deadlines, some probably haven't yet seen this thread, some don't have
time to engage right now. You also see a few -1s in this very thread.
All in all, I really don't understand why we need to hurry here.

> Currently any undecided PEP is stalled, and no one can pronounce on them.

And maybe that's OK for a few months? I don't recall Guido ever
accepting PEPs promptly. :)  Setting strict deadlines really seems
like a last-resort option.

> And we probably won't/can't promote any new core devs until we have new 
> governance.

IIRC we always promoted core devs by popular vote, so I don't think
this would be a problem.  Do we have any candidates that are currently
waiting for us deciding on a governance model?

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] Reminder of BDFL succession timeline + CFP

[Yury Selivanov]

On Wed, Aug 1, 2018 at 5:26 PM Nathaniel Smith  wrote:
[..]
> Now we have to figure that out: the legitimacy of any new governance
> system is ultimately going to have to rest on the consensus of the
> core devs. The only way I know to get that is by taking the time to
> work through the difficult conversations. If these deadlines just
> encourage people to keep moving and engaging, then that's great. But I
> worry that if we impose a cut-off like this up front, then we'll take
> that as an excuse to skip doing that work, because there's no time,
> and if someone disagrees it's easier to vote than to actually engage
> and work it out.

+1.  I don't like this idea of having strict deadlines that we must
follow no matter what.

IMO it would be better to set a "recommended date" (Oct 1st is fine)
for submitting governance proposals.  We can start discussing them
publicly after Oct 1st, and will set a strict deadline for voting when
we are all comfortable.

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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Yury Selivanov]

On Thu, Jul 19, 2018 at 5:36 AM Nathaniel Smith  wrote:

> What would be a good date? The core sprint is coming up Sept. 10-14,
> and this seems to be a likely topic of conversation there. And then
> after the sprint, those who aren't present will need time to catch up
> with any discussions that happened at the sprint. So to make things
> concrete, I propose: no governance decisions finalized before October
> 1, 2018.
>

+1.

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] Transfer of power

[Yury Selivanov]

On Sat, Jul 14, 2018 at 10:07 PM Brett Cannon  wrote:
[..]
>> Ideally Guido would accept the PEP but I'm not sure if he is willing to. If 
>> that is indeed the case then how should this be done so that the document is 
>> universally accepted by all committers?
>
>
> In my ideal scenario, people write up PEPs proposing a governance model and 
> Guido chooses one, making it PEP 2.


That would be indeed the ideal scenario, legitimizing the whole thing.

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] Transfer of power

[Yury Selivanov]

On Thu, Jul 12, 2018 at 1:50 PM Brett Cannon  wrote:
[..]
>> One way would be to re-elect them every 5 or so years.  Essentially,
>> an N-virate is a dictator-like entity for a few years.
>
>
> But that doesn't help deal with inconsistency since that just means we have 
> consistency for 2 releases and then we start all over again. If you're 
> suggesting someone forcibly rotates out every 5 years then that's different 
> since that adds in some consistency thanks to the remaining two members.

My worry is that not everybody can stick to to be with Python for a
few decades like Guido.  Ideally, there should be a mechanism for both
leaving the N-virate and being appointed to it.

Another worry -- Guido knows mostly everything about all aspects of
Python design in all fields.  To illustrate my point, I'm particularly
worried about async/await, asyncio/trio/twisted ecosystem -- so far it
seems that it's only Guido and I who've spent a huge chunk of their
time maintaining (or caring about) it.  We have many other critical
fields besides async: general language design, packaging, scientific
ecosystem, web (partially overlaps with async), performance, etc.
Essentially we need to build our N-virate to have knowledgable
representatives (formally known as BDFL-delegates) from all of those
fields, otherwise the language can stop evolving in some important
directions.

IOW I don't see anyone (or some group of 3) who is as well-versed in
everything on Guido's level.  That can be solved if Guido agrees to
join the permanent N-virate though :)

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] Transfer of power

[Yury Selivanov]

On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou  wrote:
>
>
> I'd like to point out that the N-virate idea doesn't handle a key issue:
> once you have a N-virate, how do you evolve its composition according to
> the implication and motivation of its members - but also to remarks or
> frustation by non-virate contributors (especially new contributors who
> will feel there's a perpetual category they're locked out of)?  Do you
> just wait for people to gently step down when required?

One way would be to re-elect them every 5 or so years.  Essentially,
an N-virate is a dictator-like entity for a few years.

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] Transfer of power

[Yury Selivanov]

Thank you, Guido.  This is a sad day for me personally; I really hoped
you'd lead Python for a few more years.  On the other hand, Python is
in good hands, you've built a large enough and diverse community
around it!

As for the new governing model, I imagine that we don't need to make
any decisions *right now*.  As Victor suggested, core devs can simply
count +1/-1 on any language feature and we'll see how it goes.  Or
maybe the first such vote should be on the new governing model? :)  I
really hope that we won't have an excruciating debate on the mailing
list about the governing model though; maybe we can discuss it on the
upcoming core dev sprint.

Yury



On Thu, Jul 12, 2018 at 10:58 AM Guido van Rossum  wrote:
>
> Now that PEP 572 is done, I don't ever want to have to fight so hard for a 
> PEP and find that so many people despise my decisions.
>
> I would like to remove myself entirely from the decision process. I'll still 
> be there for a while as an ordinary core dev, and I'll still be available to 
> mentor people -- possibly more available. But I'm basically giving myself a 
> permanent vacation from being BDFL, and you all will be on your own.
>
> After all that's eventually going to happen regardless -- there's still that 
> bus lurking around the corner, and I'm not getting younger... (I'll spare you 
> the list of medical issues.)
>
> I am not going to appoint a successor.
>
> So what are you all going to do? Create a democracy? Anarchy? A dictatorship? 
> A federation?
>
> I'm not worried about the day to day decisions in the issue tracker or on 
> GitHub. Very rarely I get asked for an opinion, and usually it's not actually 
> important. So this can just be dealt with as it has always been.
>
> The decisions that most matter are probably
> - How are PEPs decided
> - How are new core devs inducted
>
> We may be able to write up processes for these things as PEPs (maybe those 
> PEPs will form a kind of constitution). But here's the catch. I'm going to 
> try and let you all (the current committers) figure it out for yourselves.
>
> Note that there's still the CoC -- if you don't like that document your only 
> option might be to leave this group voluntarily. Perhaps there are issues to 
> decide like when should someone be kicked out (this could be banning people 
> from python-dev or python-ideas too, since those are also covered by the CoC).
>
> Finally. A reminder that the archives of this list are public 
> (https://mail.python.org/pipermail/python-committers/) although membership is 
> closed (limited to core devs).
>
> I'll still be here, but I'm trying to let you all figure something out for 
> yourselves. I'm tired, and need a very long break.
>
> --
> --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/



-- 
 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] Proposing Mark Shannon to be a core developer

[Yury Selivanov]

+1

Yury
-- 
 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] Poll: Do you like the PEP 572 Assignment Expressions?

[Yury Selivanov]

-1
On Wed, May 2, 2018 at 10:02 AM Eric Snow 
wrote:

> On Wed, May 2, 2018 at 3:49 AM, Victor Stinner 
wrote:
> > The poll is on the *current* PEP. I propose 4 choices:
> >
> > * +1: you like the PEP
> > * -1: you dislike the PEP
> > * 0: you are not sure if you like it or not, or you have no opinon
> > * don't reply to this poll :-)
> >
> > Just reply to this email with "+1", "0", "-1". Please don't elaborate
> > here, it's just a quick poll, use python-dev if you want to talk :-)

> -1

> ...and thanks for specifically asking for no elaboration.  I was tempted.
:)

> -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/



-- 
  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] Idea: Create subteams?

[Yury Selivanov]

On Thu, Apr 26, 2018 at 10:12 AM Victor Stinner  wrote:
[..]
> I identified 3 obvious subteams:

> * Documentation
> * IDLE
> * asyncio

Sorry, asyncio isn't an obvious choice for me. There are not so many
low-hanging fruits left in asyncio except improvements to its
documentation. I'm a firm -1 to allow people to merge without Andrew's or
my review at this point, almost no PRs are fine when they are submitted
(including our own). There's a lot of complexity in asyncio which isn't
immediately evident to people who are not working with its internals on a
daily basis.

Now, people who report and submit asyncio PRs seem to do that just fine
without subteams. Although it's rare to see people contributing more than
once, but that's not an asyncio-specific pattern, I see it in every big and
complex project I happen to contribute to.  Even having a dedicated asyncio
mailing list doesn't help to get people to contribute to asyncio more
frequently.

Don't get me wrong, Andrew and I would certainly welcome any help we can
get, but I'd be against running a public experiment with asyncio to see if
2 of us can handle the management of the new sub-teams idea.  Unfortunately
2 of us just don't have capacity for that.

Please pick another project for your idea. Maybe we should try it for
documentation first, where we have a lot of core devs who can help with PR
reviews and management of "subteams".

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] Proposing Petr Viktorin as a specialist core developer

[Yury Selivanov]

+1.

Yury

On Fri, Apr 13, 2018 at 8:13 AM, Nick Coghlan  wrote:
> Hi folks,
>
> I'd like to propose Petr Viktorin as a specialist core developer,
> focusing on extension module imports.
>
> Petr was the primary designer & implementer for the accepted PEP 489
> multi-phase extension module initialisation PEP, and has continued to
> work on changes related to that while mentoring Marcel Plch in the
> development of PEP 547 (which will get extension modules to the point
> where they can even support execution with the -m switch).
>
> When an import system issue specifically related to extension modules
> gets brought to my attention, I'll typically add Petr to the nosy list
> to request his opinion.
>
> Regards,
> Nick.
>
> P.S. While bringing on another extension module import system
> maintainer is my primary motivation for nominating him, I'll also note
> that Petr's also long been my primary point of contact for advice on
> CPython integration into Fedora, RHEL, and CentOS (he's the current
> Python maintenance team lead at Red Hat), and he also has a lot of
> practical Python 2->3 porting experience (as a result of coordinating
> much of the migration effort for Fedora and RHEL, including leading
> the creation of
> https://portingguide.readthedocs.io/en/latest/index.html )
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> 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] Let's give commit privileges to Nathaniel J. Smith

[Yury Selivanov]

Alright, it's decided!  I now envy Nathaniel a bit, so many people +1-ed!

I've added Nathaniel to devguide/developers.rst, and I believe Victor
has already elevated his permissions on the bug tracker.

Can someone with admin permissions on github.com/python invite
Nathaniel to the Core Developers team?

Yury

On Thu, Jan 25, 2018 at 10:33 AM, Ezio Melotti <ezio.melo...@gmail.com> wrote:
> +1
>
> On Thu, Jan 25, 2018 at 12:23 AM, Yury Selivanov
> <yselivanov...@gmail.com> wrote:
>> Hi,
>>
>> I want to propose granting commit privileges to Nathaniel J. Smith.
>> He's interested in the idea of becoming a core developer, and given
>> the quality of his contributionsI think he won't need any extensive
>> mentoring (although I'll be happy to assist Nathaniel in the
>> beginning).
>>
>> Nathaniel has been a prolific PEP author:
>>
>> * Single-authored: PEP 465 Matrix Multiplication (accepted), PEP 521,
>> PEP 533, PEP 568;
>>
>> * Co-authored: PEP 513 (active), PEP 516, PEP 517 (accepted), PEP 518
>> (accepted), PEP 522.
>>
>> * Many PEPs mention his name in acknowledgements.
>>
>> He also has a few sufficiently complex patches committed, some of
>> which touch complex areas like ceval loop and signals handling:
>>
>> * bpo-32591: Add native coroutine origin tracking
>> * bpo-30579: Allow TracebackType creation and tb_next mutation from Python
>> * bpo-30050: Allow disabling full buffer warnings in signal.set_wakeup_fd
>> * bpo-30039: Don't run signal handlers while resuming a yield from stack
>> * bpo-30038: fix race condition in signal delivery + wakeup fd
>> * etc
>>
>> He's been very active on python-dev, python-ideas, bugs.python.org and
>> github. Here's an example where Nathaniel's research helped us to make
>> a right decision to fix a broken socket object API:
>> https://bugs.python.org/msg308450.
>>
>> He helped me quite a bit with the design of PEP 550 and PEP 567, and
>> he's doing some interesting work in the async/await area.
>>
>> So... let's make it happen? :)
>>
>> 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/

[python-committers] Let's give commit privileges to Nathaniel J. Smith

[Yury Selivanov]

Hi,

I want to propose granting commit privileges to Nathaniel J. Smith.
He's interested in the idea of becoming a core developer, and given
the quality of his contributionsI think he won't need any extensive
mentoring (although I'll be happy to assist Nathaniel in the
beginning).

Nathaniel has been a prolific PEP author:

* Single-authored: PEP 465 Matrix Multiplication (accepted), PEP 521,
PEP 533, PEP 568;

* Co-authored: PEP 513 (active), PEP 516, PEP 517 (accepted), PEP 518
(accepted), PEP 522.

* Many PEPs mention his name in acknowledgements.

He also has a few sufficiently complex patches committed, some of
which touch complex areas like ceval loop and signals handling:

* bpo-32591: Add native coroutine origin tracking
* bpo-30579: Allow TracebackType creation and tb_next mutation from Python
* bpo-30050: Allow disabling full buffer warnings in signal.set_wakeup_fd
* bpo-30039: Don't run signal handlers while resuming a yield from stack
* bpo-30038: fix race condition in signal delivery + wakeup fd
* etc

He's been very active on python-dev, python-ideas, bugs.python.org and
github. Here's an example where Nathaniel's research helped us to make
a right decision to fix a broken socket object API:
https://bugs.python.org/msg308450.

He helped me quite a bit with the design of PEP 550 and PEP 567, and
he's doing some interesting work in the async/await area.

So... let's make it happen? :)

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] Adding Ivan Levkivskyi as a core committer

[Yury Selivanov]

+1 from me.  I first had an idea to give Ivan commit privileges when I
was merging his PEP 526 implementation, so I think it's long overdue.

Yury

On Tue, Dec 5, 2017 at 8:00 PM, Guido van Rossum  wrote:
> I'd like to propose Ivan Levkivskyi as a new core committer. He's
> (re-)written most of the typing.py module and will do so again for Python
> 3.7, he's the sole or primary author on several PEPs (526, 544, 560, 562),
> is co-author on several more (483, 561) and has been acknowledged in yet
> others (557, 563).
>
> He is responsible for at least 16 commits in master.
>
> I have worked with him for a long time on typing.py and on mypy (where he is
> a core dev) and I can vouch for him completely.
>
> --
> --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/
>
___
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-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

[Yury Selivanov]

On Fri, Nov 3, 2017 at 11:30 PM, Nick Coghlan  wrote:
> On 4 November 2017 at 09:52, Jelle Zijlstra  wrote:
>>
>> 2017-11-03 16:44 GMT-07:00 Joao S. O. Bueno :
>>>
>>> This just popped up in Brython's issue tracker discussion:
>>>
>>> """
>>> Pierre Quentel 
>>>
>>> 04:57 (16 hours ago)
>>> to brython-dev/br., Subscribed
>>>
>>> I think it's better to rename all occurences of async now, although
>>> it's strange that :
>>>
>>> there is currently no deprecation warning in CPython with code that
>>> uses it as a variable name, PEP492 said that "async and await names
>>> will be softly deprecated in CPython 3.5 and 3.6"
>>> there is no mention of async and await becoming keywords in What's new
>>> in Python 3.7
>>>
>>> Maybe the idea was finally given up, but I can't find a reference.
>>>
>>> """
>>>
>>> So, what is the status of promoting async and await to full keyword for
>>> 3.7?
>>>
>> This was implemented, and it's in NEWS:
>> https://github.com/python/cpython/pull/1669.
>
> That's a big enough change that it should be in What's New as well (at
> least in the porting section, and probably more prominent than that).
>
> The current lack of DeprecationWarnings in 3.6 is a fairly major
> oversight/bug, though:

There's no oversight.  We had PendingDeprecationWarning for
async/await names in 3.5, and DeprecationWarning in 3.6.  You just
need to enable warnings to see them:

~ » python3 -Wall
Python 3.6.2 (default, Aug  2 2017, 22:29:27)
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> async = 1
:1: DeprecationWarning: 'async' and 'await' will become
reserved keywords in Python 3.7


> So if we're going to go ahead with making them real keywords in 3.7
> (as specified in PEP 492), then the missing DeprecationWarning problem
> in 3.6 needs to be fixed.

They are already keywords in 3.7, I've committed that change a month ago.

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] 4 weeks with the new workflow: what needs changing?

[Yury Selivanov]

On 2017-03-16 12:16 PM, Brett Cannon wrote:



On Wed, 15 Mar 2017 at 20:24 R. David Murray <rdmur...@bitdance.com 
<mailto:rdmur...@bitdance.com>> wrote:


On Wed, 15 Mar 2017 22:56:33 -0400, Yury Selivanov
<yselivanov...@gmail.com <mailto:yselivanov...@gmail.com>> wrote:
> It's not just long waiting times (although it's a huge factor), it's
> that you have to create temporary branches for cherry-picks. With
> scripts or without, it's a lot of bookkeeping. Also, interacting
with a
> console is still much more convenient than using web tools (at
least for
> me).

+100 :)


I'm afraid this one is going to come down to personal preference 
because I actually pref the web UI. :) But we will keep working at 
this to see if we can't find a happy medium somehow.



I just discovered this handy tool: https://github.com/github/hub. Will 
try to use it and will share my experience.


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] 4 weeks with the new workflow: what needs changing?

[Yury Selivanov]

Hi Brett,

On 2017-03-14 6:00 PM, Brett Cannon wrote:
[..]



Yesterday I was working on a few asyncio PRs and a bug in async/await.
All PRs required cherry-picking.  Again, I was spending significant
amount of time just creating branches/PRs for cherry-picking.


Were you creating the branches manually or using Mariatta's script?


I'll check it out!


  Again
waiting for CI checks (even though I always run the test suite
before I
push).  In the end of the day, I was so frustrated and discouraged
that
I just stopped working on CPython.


Our Travis runs just got increased today so this should be improved. 
As I have also previously said we can consider scaling back the number 
of things we're building if necessary (i.e. we could go as low as 3 
instead of the 5 we currently have or trying building using g++ to 
combine gcc and the C++ header check).


Yeah, reducing the number of tasks would really help.  Anything that can 
make required CI checks quicker.


It's a double-edged sword when you don't gate on CI but you have it 
for all PRs. When Serhiy accidentally broke the build when I turned 
off Travis gating for you, all PRs for a few hours came in as failing 
and it confused some external contributors as to why their PR was 
coming up red.


Ah, OK, I now better understand the rationale for requiring CI pass.

[..]
 If all of those things are tried and we are still seeing unacceptably 
long wait times on PRs, then we can talk about turning off the CI 
gating. Does that seem fair?


It's not just long waiting times (although it's a huge factor), it's 
that you have to create temporary branches for cherry-picks. With 
scripts or without, it's a lot of bookkeeping. Also, interacting with a 
console is still much more convenient than using web tools (at least for 
me).


Anyways, while I don't totally enjoy the current workflow I see why it 
is as it is right now. I'll try to get used to it.


Thank you,
Yury

P.S. Thanks to everybody who's been working on GH migration. Overall 
it's a very positive change!


___
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] 4 weeks with the new workflow: what needs changing?

[Yury Selivanov]

Hi,

First, I'm really happy that we moved to git and GH.  The GH review tool 
is super convenient and CI integration helps.


I'm less happy about requiring to make a PR for every commit. It's a no 
problem for new features development, but it's a huge pain for a bug 
fixing workflow.  Last week I needed to push a bunch of bug fixes to 
3.7/3.6/3.5.  I had about 6 pull requests to the master branch, + 12 
more for 3.6 and 3.5.  I basically killed my entire second half of the 
day waiting until CI checks clear out.  I spend a few hours pushing just 
3 (!!) committs to all branches.  Thanks to Brett, who disabled the push 
CI check for a while, I was able to push the remaining 3 bug fixes and 
their cherry picks in under 10 minutes.


Yesterday I was working on a few asyncio PRs and a bug in async/await.  
All PRs required cherry-picking.  Again, I was spending significant 
amount of time just creating branches/PRs for cherry-picking.  Again 
waiting for CI checks (even thougn I always run the test suite before I 
push).  In the end of the day, I was so frustrated and discouraged that 
I just stopped working on CPython.


The current workflow makes it significantly harder for me to be 
productive.  At this point I'm so discouraged of working on any bug 
fixes that I consider to stop working on them until the full 
cherry-picking automation is implemented.


So I guess what I'm asking for is to consider turning the CI/PR push 
requirement off until we have automatic cherry-picking and a new NEWS 
file workflow.  We lived without this check for many years with 
mercurial.  Yes, all of us pushed some broken commits, but we have 
buildbots and CI, so nothing horrible ever happended.


Thank you,
Yury


On 2017-03-10 5:13 PM, Brett Cannon wrote:
I can't believe it's been 4 weeks. It feels like it was ages/yesterday 
when we moved. :)


First, I hope people are not regretting letting/having me make this 
migration. I know there have been some things to work through (and 
others still to come), but I hope this is all a net positive (either 
now or in the near future).


Second, I wanted to get initial feedback on things we can easily tweak:

  * Requiring Travis to pass (I *really* don't want to turn this off
as we already had a broken build when I temporarily turned it off
at someone's request when Travis was backed up from the AWS S3
outage; I also don't plan to make AppVeyor required unless there's
a way to make it be skipped for doc-only changes)
  * Cherry-picking working out? (We can go back to forward merging if
people really want to, but I think long-term cherry-picking will
allow for more automation)
  o Along with that, are the labels for cherry-picking working
out? (Some devs seem to like using title labels like `[3.6]`
to flag cherry-picks so it's more obvious in emails so I don't
know if the labels are really that useful)
  * Is the mention bot helpful? (Our config is at
https://github.com/python/cpython/blob/master/.mention-bot and the
docs are at https://github.com/facebook/mention-bot)
  * Anything to tweak about the coverage bot and reports? (Our config
is at
https://github.com/python/cpython/blob/master/.codecov.yml and
docs at https://docs.codecov.io/docs/codecov-yaml)

Third, I wanted to point out some of the more critical discussions 
going on at https://github.com/python/core-workflow/issues. 
Specifically, https://github.com/python/core-workflow/issues/6 is 
working towards a solution for Misc/NEWS so if you care about the 
final solution you should participate there. After Misc/NEWS is solved 
the next step becomes solving the cherry-picking overhead with a more 
automated approach. We are also discussing closed branches to make the 
list of branches more manageable at 
https://github.com/python/core-workflow/issues/31.


Fourth, the lack of messages showing up on bugs.python.org 
 after a commit is being tracked at 
http://psf.upfronthosting.co.za/roundup/meta/issue613. I'm sure Ezio 
and Maciej would appreciate any help people may be able to volunteer 
to help in solving the problem.


Fifth, anything I missed? :)


___
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] My cavalier and aggressive manner, API change and bugs introduced for basically zero benefit

[Yury Selivanov]

On 2017-01-20 5:02 PM, Lukasz Langa wrote:

On Jan 20, 2017, at 9:26 AM, Yury Selivanov <yselivanov...@gmail.com> wrote:

I think that we need to become less conservative about
development of CPython internals.  At this point it's impossible
to make CPython any faster without invasive refactorings, and
I think it's OK to trust our core developers to make them.

I agree with the sentiment but I'm worried about the implications. Your 
suggested approach only makes sense if we have a good safety net in place to 
catch regressions early. Unfortunately, apart from regrtest, buildbots, and 
dumb luck, we don't. Betas have very limited adoption, too limited to be useful 
in my experience. I tried and failed to introduce 3.6 during beta phase at work 
because there was too much risk it would be picked up by unsuspecting users. 
Other users seem to be in the same camp. Consequently, most x.y.0 releases are 
relatively lower quality.

I wonder if there's any way for us to incentivize beta usage in some key areas. For example, if 
every Python 3 project on Travis CI also ran on "3.7-dev" or "nightly", that 
would already give us better real world coverage. Actually *running* dev builds in production seems 
too risky for me for the reasons that Raymond and Victor state in this thread: too much lightly 
reviewed changes.

Summing up, I don't think we can really start "moving fast and breaking things" 
until we have wider adoption of dev builds in the wild. To put money where my mouth is, I 
am currently working on introducing the dev version of 3.7 to the build system at work. 
But this is not going to be enough on its own.

- Ł



Lukasz, I understand what you are saying here.  But on the other hand, 
we should not stop improving CPython.  Sometimes stuff will break 
because of our "loose" safety net, but this is inevitable.  It happens 
virtually in any software project (including other languages and compilers).


My experience shows that even extensive code reviews don't spot all 
bugs.  E.g. I missed a bug in one asyncio patch that caused 
"loop.sock_connect" to be broken in 3.5.2.  Another one: due to a design 
mistake in PEP 492, we had to change how __aiter__ behaves in 3.5.3 and 
3.6.  PEP 492 was thoroughly discussed, the patches were reviewed, and 
we merged everything a few months before we released Python 3.5.0; that 
wasn't enough apparently.


I'm not suggesting that we should "move fast", merge things without 
reviews / tests / benchmarks.  In Victor's case, he started working on 
FASTCALL in 3.6, and we already shipped some of his improvements (I 
reviewed a few FASTCALL patches myself).  Now he (with help of Serhiy 
and Inada-san) simply continues to work on the project, gradually 
refactoring the code, improving Argument Clinic etc.  We are still early 
in 3.7 development cycle, and I don't think we should stop the project 
just because we had a couple of minor regressions.


Thank you,
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] My cavalier and aggressive manner, API change and bugs introduced for basically zero benefit

[Yury Selivanov]

Thanks for this email Victor, it illustrates a lot of pain-points
that some core devs have with CPython development process.

I think that we are lucky that we have you and Serhiy who spend
so much time to push so many improvements to the CPython internals.
I think that while we are working on a new major version of
CPython (3.7 now), it's acceptable to push performance
optimizations without a lengthy discussion on python-dev and a
thorough review by 3+ core developers.  An issue on the bug
tracker explaining the change and showing some benchmarks
should be enough.

Those who want to see the results of Serhiy's and Victor's work
can look at https://speed.python.org/comparison/ and see for
themselves that 3.7 is already faster than 3.6 and 2.7 in most
cases.

To reflect on my own experience: I had a patch to speed up
LOAD_GLOBAL, LOAD_ATTR and LOAD_METHOD early in 3.6 development
cycle.  The patch promised to improve performance 5-20% on some
benchmaks. I sent a few emails to python-dev explaining the
change, explaining the memory usage changes etc.  What I saw is
that only one or two people were interested in the change, and
almost nobody wanted to actually review the change.  I became less
motivated, and in the end I decided to focus on other areas and
postpone my work on that optimization until later.  And later I
regretted that: I should have pushed the change, and we would
have few months to improve and test it, and we would have an
even faster 3.6.  (I'll continue my work on the patch soon).

I think that we need to become less conservative about
development of CPython internals.  At this point it's impossible
to make CPython any faster without invasive refactorings, and
I think it's OK to trust our core developers to make them.

Any public API changes/enhancements should be discussed on
python-dev and thoroughly reviewed though.  API design is
something that a single person usually cannot do well.

Thank you,
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] My cavalier and aggressive manner, API change and bugs introduced for basically zero benefit

[Yury Selivanov]

On 2017-01-20 8:38 AM, Stefan Krah wrote:

I'm still very interested of course to have an official FASTCALL API
for third party modules that don't (and probably should not) use AC.


AFAIK, even though FASTCALL isn't "official", Cython already
uses it.

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] daily reference leaks

[Yury Selivanov]

Does anyone know where's "daily reference leaks"?  Last email was sent 
on Sun Jul 10 05:57:30 EDT 2016.  Just today I found two memory leaks in 
3.6, it might be many more that we don't know about.



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] commit privileges for INADA Naoki

[Yury Selivanov]

Thanks, Victor!

On Mon, Sep 26, 2016 at 5:27 PM, Victor Stinner
<victor.stin...@gmail.com> wrote:
> https://docs.python.org/devguide/coredev.html gives some steps ;-)
>
> 2016-09-26 17:23 GMT+02:00 Yury Selivanov <yselivanov...@gmail.com>:
>> Thank you guys. I'll send a detailed email to INADA, explaining most
>> basic things (and a link to devguide).  And sure thing, I'm OK with
>> mentoring.
>>
>> Who should I ask to issue commit privileges / update bug tracker info for 
>> INADA?
>>
>> Yury
>>
>> On Mon, Sep 26, 2016 at 6:05 AM, Guido van Rossum <gu...@python.org> wrote:
>>> I'm with Nick. Assuming Yuri wants to mentor Inada I'm all for giving
>>> him commit privileges!
>>>
>>> On Sun, Sep 25, 2016 at 9:00 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>>>> On 26 September 2016 at 03:52, Raymond Hettinger
>>>> <raymond.hettin...@gmail.com> wrote:
>>>>>
>>>>>> On Sep 25, 2016, at 8:38 AM, Yury Selivanov <yselivanov...@gmail.com> 
>>>>>> wrote:
>>>>>>
>>>>>> I want to propose to give commit privileges to INADA Naoki.  He's the 
>>>>>> guy behind compact dict implementation for CPython 3.6, which was a 
>>>>>> super complex patch.
>>>>>
>>>>> I would like to see him do some work reviewing other people's patches and 
>>>>> to show that he is making good judgments about what should and shouldn't 
>>>>> be done.  In a way, making a single big patch is one of the least 
>>>>> important parts of being a core developer.
>>>>
>>>> This has come up a couple of times, but I think it carries a mistaken
>>>> assumption that there's only one way to be a core developer, when
>>>> "core development" covers a whole range of different activities, from
>>>> general bug fixing, to facilitating acceptance of other people's
>>>> patches, to assuming maintenance & design responsibility for
>>>> particular modules and interpreter subsystems.
>>>>
>>>> I know when I nominated Yury himself for commit privileges it wasn't
>>>> due to his work reviewing other people's patches - it was due to the
>>>> fact that I trusted him to ask for a second opinion when he needed one
>>>> in the areas where we'd been working together, and that the
>>>> requirement for his patches to go through me in order to be merged was
>>>> becoming inefficient relative to just granting him the ability to
>>>> check them in himself after I had looked at them.
>>>>
>>>> If Yury feels the same way regarding Inada-san's contributions to
>>>> asyncio and the interpreter core, and is prepared to support him in
>>>> managing the additional responsibilities that come along with that,
>>>> then I don't see a strong reason to veto that. At most I see reason
>>>> for a directive to be judicious in how the new access is used, but my
>>>> experience is that new core developers already naturally take some
>>>> time to become confident in using their own judgement over asking
>>>> their sponsor's opinion.
>>>>
>>>> Regards,
>>>> Nick.
>>>>
>>>> P.S. My perspective on this is also influenced by the fact that I
>>>> gained my own commit privileges back in the CVS days specifically to
>>>> work on updates to PEP 346 rather than due to my work on the activity
>>>> of general patch wrangling (which I still generally don't do outside
>>>> my particular areas of interest, and even then, hitting a bug or API
>>>> limitation myself is often the main motivator for applying someone
>>>> else's patch)
>>>>
>>>> --
>>>> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>>>> ___
>>>> 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/
>>>
>>>
>>>
>>> --
>>> --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/
>> ___
>> 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] commit privileges for INADA Naoki

[Yury Selivanov]

Thank you guys. I'll send a detailed email to INADA, explaining most
basic things (and a link to devguide).  And sure thing, I'm OK with
mentoring.

Who should I ask to issue commit privileges / update bug tracker info for INADA?

Yury

On Mon, Sep 26, 2016 at 6:05 AM, Guido van Rossum <gu...@python.org> wrote:
> I'm with Nick. Assuming Yuri wants to mentor Inada I'm all for giving
> him commit privileges!
>
> On Sun, Sep 25, 2016 at 9:00 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> On 26 September 2016 at 03:52, Raymond Hettinger
>> <raymond.hettin...@gmail.com> wrote:
>>>
>>>> On Sep 25, 2016, at 8:38 AM, Yury Selivanov <yselivanov...@gmail.com> 
>>>> wrote:
>>>>
>>>> I want to propose to give commit privileges to INADA Naoki.  He's the guy 
>>>> behind compact dict implementation for CPython 3.6, which was a super 
>>>> complex patch.
>>>
>>> I would like to see him do some work reviewing other people's patches and 
>>> to show that he is making good judgments about what should and shouldn't be 
>>> done.  In a way, making a single big patch is one of the least important 
>>> parts of being a core developer.
>>
>> This has come up a couple of times, but I think it carries a mistaken
>> assumption that there's only one way to be a core developer, when
>> "core development" covers a whole range of different activities, from
>> general bug fixing, to facilitating acceptance of other people's
>> patches, to assuming maintenance & design responsibility for
>> particular modules and interpreter subsystems.
>>
>> I know when I nominated Yury himself for commit privileges it wasn't
>> due to his work reviewing other people's patches - it was due to the
>> fact that I trusted him to ask for a second opinion when he needed one
>> in the areas where we'd been working together, and that the
>> requirement for his patches to go through me in order to be merged was
>> becoming inefficient relative to just granting him the ability to
>> check them in himself after I had looked at them.
>>
>> If Yury feels the same way regarding Inada-san's contributions to
>> asyncio and the interpreter core, and is prepared to support him in
>> managing the additional responsibilities that come along with that,
>> then I don't see a strong reason to veto that. At most I see reason
>> for a directive to be judicious in how the new access is used, but my
>> experience is that new core developers already naturally take some
>> time to become confident in using their own judgement over asking
>> their sponsor's opinion.
>>
>> Regards,
>> Nick.
>>
>> P.S. My perspective on this is also influenced by the fact that I
>> gained my own commit privileges back in the CVS days specifically to
>> work on updates to PEP 346 rather than due to my work on the activity
>> of general patch wrangling (which I still generally don't do outside
>> my particular areas of interest, and even then, hitting a bug or API
>> limitation myself is often the main motivator for applying someone
>> else's patch)
>>
>> --
>> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>> ___
>> 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/
>
>
>
> --
> --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/
___
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] commit privileges for INADA Naoki

[Yury Selivanov]

Hi,

I want to propose to give commit privileges to INADA Naoki.  He's the 
guy behind compact dict implementation for CPython 3.6, which was a 
super complex patch.  He also participated in many asyncio related 
discussions/PRs, on python-ideas and bug tracker.


He's quite interested in becoming a core developer.  I can volunteer to 
help/mentor INADA until he's comfortable with our processes.


Thanks,
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] emails from bugs.python.org are marker as spam

[Yury Selivanov]

Most of the emails from bugs.python.org (and review tool) end up being 
marked as spam in gmail.  I consistently miss 70% of them. Is it 
possible to fix this?


Yury
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] emails from bugs.python.org are marker as spam

[Yury Selivanov]

On 2015-11-18 5:49 PM, Ezio Melotti wrote:

On Thu, Nov 19, 2015 at 12:40 AM, Yury Selivanov
<yselivanov...@gmail.com>  wrote:

>Most of the emails from bugs.python.org (and review tool) end up being
>marked as spam in gmail.  I consistently miss 70% of them. Is it possible to
>fix this?
>

A quick workaround is to create a GMail filter and check "never send to spam".


Great idea, thanks!

Yury
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] daily refleaks

[Yury Selivanov]

On 2015-09-10 3:23 AM, Antoine Pitrou wrote:

Apparently the hg clone had gone in a mess:

pulling from https://hg.python.org/cpython
searching for changes
abort: abandoned transaction found - run hg recover!


I cleaned it up, it should work again next night.


Thank you, Antoine!

Yury

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Co-maintainer(s) for contextlib, dis and/or runpy?

[Yury Selivanov]

Hi Nick,

I've added myself to dis  contextlib modules on the experts list.

Yury

On 2015-06-27 12:47 AM, Nick Coghlan wrote:

Hi folks,

My available time for the fundamentals of stdlib module maintenance is
unfortunately pretty limited these days, which means even reviewed
patches for modules where I'm the sole maintainer aren't necessarily
getting applied in a timely fashion (Serhiy quite rightly nudged me
about this recently in relation to a languishing contextlib patch).

Would anyone be interesting in taking up co-maintainership of one or
more of the affected modules? Timely reviews I can generally manage
(especially for other core developers), it's timely patch application
and new module level development work that I struggle to find the time
for :(

The affected modules:

* contextlib
* dis
* runpy

Regards,
Nick.

P.S. In the specific case of contextlib, I'm also interested in
finding someone willing to take up maintenance of the contextlib2
backport: https://pypi.python.org/pypi/contextlib2



___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] docs.python.org broken for 3.5

[Yury Selivanov]

Benjamin's commits to fix version switcher helped a little bit, but docs 
for 3.5 are still broken (and 3.6 FWIW).


Yury

On 2015-05-27 6:23 PM, Yury Selivanov wrote:

Hi,

docs.python.org is kind of broken for 3.5.  For instance, what's new 
in 3.5 link points now to a missing whatsnew for 3.6 (which gives us 
404 error).  Version switcher extension should also be updated in 2.7, 
3.4, 3.5, and 3.6 branches.  I think I could fix that all myself, but 
I don't have access to the docs server.


Yury


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] Code review tool 500 error

[Yury Selivanov]

Hi,

I can't post messages to the code review tool -- it shows
me 500 error page.

I'm not sure if I'm the only one who is experiencing this.

I tried different browsers, cleaning cookies/local storage
etc.

I can change my password and give my login credentials for
someone to debug/test.

Yury
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

[Yury Selivanov]

Larry,

On 2015-05-12 1:04 PM, Larry Hastings wrote:

Workflow 1
==

When I ship beta 1, we create the 3.5 branch.  trunk become 3.6.

When I ship rc 1, the 3.5 branch becomes 3.5.1.  I maintain a 
publically visible repo /on bitbucket/ for 3.5.0, and we use bitbucket 
pull requests for cherry-picks from 3.5.1 into 3.5.0.


This gives us a pilot project to try out a web GUI for merging. It 
makes my workflow easier, as I can push a button to accept 
cherry-picks.  (If they don't apply cleanly I can tell the author to 
go fix the conflict and resubmit it.)  The downside: it requires core 
devs to have and use bitbucket accounts.



This makes a lot of sense. +1.

Yury
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] new python.org

[Yury Selivanov]

On 2/19/2014, 11:31 PM, Yury Selivanov wrote:

Hi,

Do we have a mail list/group where we can discuss the
python.org site?

I've noticed some typos and have some advices, like:

- Python logo has a little yellow 'BETA' label, which may give
some new users impression, that it is the Python Language Beta,
not the python.org website.

- Upcoming events / Latest news aren't updated since 2012

- Freeback Wanted banner should be removed, or at least,
the word beta should be dropped.

- etc

Yury

I forgot to add, that I don't want to only criticize,
but to offer some help too.

New python.org is great, and I realize that an insane
amount of work was put into it.

Yury
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] review links

[Yury Selivanov]

Hello,

Another quick infrastructure question (is this the right list, btw?):
I don't see 'review' links for some patches. Like in issue #14911,
Kristján uploaded two patches, same day, almost same time, and I
see a review link only for one of them.

Screenshot: http://goo.gl/HK2oer

Thanks,
Yury
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] review links

[Yury Selivanov]

OK, thank you.

Are you sure it's the right thing to do? I.e. a user can create a
patch, ensure that it applies cleanly, and while he uploads it,
someone pushes to the repo. No 'review' link, no notification.

Wouldn't it make sense to always show the review link, and let
the user to resolve the conflicts if there are any?

Yury

On 2/3/2014, 12:20 PM, Antoine Pitrou wrote:

On lun., 2014-02-03 at 09:16 -0800, Guido van Rossum wrote:

IIRC the review link only appears if the patch applies cleanly.

And only if it applies cleanly on the default branch, IIRC :-)

Regards

Antoine.



___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Code review tool (rietveld) bug

[Yury Selivanov]

On 1/28/2014, 2:07 AM, Martin v. Löwis wrote:

Am 27.01.14 23:37, schrieb Yury Selivanov:

So, the JS code is clearly working.

Unfortunately, I have no idea what the root problem might be.
a) I cannot reproduce it. Following your steps, I manage to post a
reply every time.
b) It really ought to work. The specific error suggests that the message
lookup failed. However, the message in question is certainly there,
and it does work for other people.

Feel free to submit a bug report to the metatracker, but chances are low
that it gets fixed (unless by accident, e.g. when upgrading to a new
Rietveld code base fixes the problem).


Martin,

Thank you for looking into this. I guess I'll try to
debug this myself too, maybe on the weekend.

Yury
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] Code review tool (rietveld) bug

[Yury Selivanov]

Hello,

I'm having difficulty with replying to a message in rietveld.

Here's a screenshot of the exception: http://goo.gl/70iQ5v
(AttributeError at /review/20356/publish)

Is this a known issue? Maybe I'm doing something wrong?

Yury
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Code review tool (rietveld) bug

[Yury Selivanov]

I've tried multiple times, yes.

Yury

On 1/27/2014, 2:56 PM, Antoine Pitrou wrote:

On lun., 2014-01-27 at 14:52 -0500, Yury Selivanov wrote:

Hello,

I'm having difficulty with replying to a message in rietveld.

Here's a screenshot of the exception: http://goo.gl/70iQ5v
(AttributeError at /review/20356/publish)

Is this a known issue? Maybe I'm doing something wrong?

Have you tried more than once? I've experienced sporadic errors at
times.

Regards

Antoine.


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Code review tool (rietveld) bug

[Yury Selivanov]

OK, I've tried another browser (regularly I use Safari, this
time I was trying it with Chrome) -- same thing.

For those who want to try to reproduce it:

1. Open http://bugs.python.org/issue20356
2. Click 'review' for pos_only_format_02.patch
3. Click on message from @larry
4. Hit 'reply' link for it
5. Erase everything from the text area and type something in
5. Submit the form.

Yury

On 1/27/2014, 3:13 PM, R. David Murray wrote:

On Mon, 27 Jan 2014 14:52:16 -0500, Yury Selivanov yselivanov...@gmail.com 
wrote:

Hello,

I'm having difficulty with replying to a message in rietveld.

Here's a screenshot of the exception: http://goo.gl/70iQ5v
(AttributeError at /review/20356/publish)

Is this a known issue? Maybe I'm doing something wrong?

There have been occasional problems with the email interface in our
rietveld instance.  I'm not sure if your traceback matches the other
problems, and I don't remember if those problems were actually solved.
If you restart your session (starting from the bug tracker) does the
problem reproduce?

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Code review tool (rietveld) bug

[Yury Selivanov]

On more note:

I'm using open-id (google) to sign in on bugs.python.org

Yury

On 1/27/2014, 3:24 PM, Antoine Pitrou wrote:

On lun., 2014-01-27 at 15:18 -0500, Yury Selivanov wrote:

OK, I've tried another browser (regularly I use Safari, this
time I was trying it with Chrome) -- same thing.

For those who want to try to reproduce it:

1. Open http://bugs.python.org/issue20356
2. Click 'review' for pos_only_format_02.patch
3. Click on message from @larry
4. Hit 'reply' link for it
5. Erase everything from the text area and type something in
5. Submit the form.

Well, it worked here (Firefox).
As a sidenote, why is Larry green on this page?

Regards

Antoine.


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Code review tool (rietveld) bug

[Yury Selivanov]

Martin,

On 1/27/2014, 5:01 PM, Martin v. Löwis wrote:

Am 27.01.14 21:18, schrieb Yury Selivanov:

OK, I've tried another browser (regularly I use Safari, this
time I was trying it with Chrome) -- same thing.

For those who want to try to reproduce it:

1. Open http://bugs.python.org/issue20356
2. Click 'review' for pos_only_format_02.patch
3. Click on message from @larry
4. Hit 'reply' link for it
5. Erase everything from the text area and type something in
5. Submit the form.

I can add a message just fine, but I think something is broken still.

Can you get your web browser to see the source of the reply form? I get

 form method=POST action=/review/20356/publish
   id=message-reply-form
   input type=hidden name=xsrf_token
value=7e667aa15c51043fea022aa837edaaa5
   div/div
   input type=hidden name=in_reply_to value= /
   input type=hidden name=subject value=fix formatting of
positional-only parameters in inspect.Signature /
   input type=hidden name=message_only value=1 /
   input type=submit value=Send Message /
   input type=button value=Discard name=discard /
   input type=checkbox name=send_mail value=1
  id=message-reply-send-mail checked=checked /
   labelSend mail to reviewers/label
 /form

I believe the issue is the hidden in_reply_to field.

a) it shouldn't be an empty string (I think); if it wasn't, Rietveld
might actually make insert it in a threaded way. IIUC, js ought
to have inserted a value for in_reply_to.
b) if it is empty, it apparently crashes for you because it then finds
that there is no message with the id .

Looking a bit further - maybe Safari doesn't tell me the dynamic code.
I also see

a href=javascript:M_replyToMessage('0', '2014/01/25 11:25:44',
'larry', 'Message_2687')
  id=message-reply-href-0Reply/a

which really ought to fill out the in_reply_to field (with Message_2687)


Sure, here is the form markup:


form method=POST action=/review/20356/publish 
id=message-reply-formtextarea rows=7 cols=70 name=message 
style=/textarea
  input type=hidden name=xsrf_token 
value=769e2ad622940b39cde28df56f486977

  div/div
  input type=hidden name=in_reply_to value=Message_2687
  input type=hidden name=subject value=fix formatting of 
positional-only parameters in inspect.Signature

  input type=hidden name=message_only value=1
  input type=submit value=Send Message
  input type=button value=Discard name=discard
  input type=checkbox name=send_mail value=1 
id=message-reply-send-mail-0 checked=checked

  label for=message-reply-send-mail-0Send mail to reviewers/label
/form

And here is what browser (Chrome, again) actually had sent to the server:

1.
   message:
   Test
2.
   xsrf_token:
   769e2ad622940b39cde28df56f486977
3.
   in_reply_to:
   Message_2687
4.
   subject:
   fix formatting of positional-only parameters in inspect.Signature
5.
   message_only:
   1
6.
   send_mail:
   1


So, the JS code is clearly working.

Yury
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] introduction

[Yury Selivanov]

Hello,

Thank you very much for accepting me as a member of your team!
Python is the most beautiful, simple and complex language I
ever knew, and it's an honor for me to help to make it better.

Just to give you an idea of how passionate I am about python,
I'd like to tell you a short story.  When I just started to
work on PEP 362 with Brett and Larry, we had a few discussions
of how things should be going and I promised them to draft a
first version of the PEP and implementation by the end of the
week. On Friday, I decided to make a surprise for my girlfriend
and booked a weekend in Montreal, and in the morning of
Saturday I woke up with a fever of 37 degrees. Well, it's just
37, I'll be OK by the time we drive there. Hell I was wrong.
For two days, the only thing I was romantically attached to,
was my bed in the hotel room. And midday of Sunday, I realized
that I have a promise to fulfill. So here I was, sitting on the
bed, with a fever of 39 degrees, with one eye closed, and the
other one so filled with tears so I had to squish it to have
a clear spot on the screen, working on that draft and writing
unittests. All because I knew that while it'd be OK to wait a
few days, we didn't actually have time for that, because the
release was just around the corner, and every day was important.

So, again, thank you very much!  I now have to break the
buildbot I guess..

Yury
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers