[Python-Dev] PEP 622 pattern matching syntax

2020-06-30 Thread i.r.galahad
Hello Python Devs,
For some time I've been hoping to be able to use pattern matching in
Python, so PEP 622 is an exciting proposition. I do have some concerns,
mostly about the syntax, because it doesn't currently match the style the
rest of Python seems to lay out.

The thing I'd most suggest changing is the syntax for constants within
patterns from `.CONSTANT`. Dots can already be in patterns as part of
attribute access, so the viewer will need to distinguish between different
uses when they see one. Instead I propose an at-symbol, like `@CONSTANT`.
The `@` is a symbol used in Python syntax already, so it would not require
changes to the tokeniser. However, it can never currently appear in
patterns; neither decorators nor the matmul operator would create any
ambiguity for a human trying to skim over a pattern, unlike the currently
proposed syntax. The `@` does share a downside with the dot, which is lack
of precedent. The PEP alludes to `.name` having an entirely different use
in imports, and the use of `@name` in decorators does not relate to this
new pattern syntax either. All the same, `@` would still make for a clearer
symbol because it would be more distinct from attributes. (There is a weak
argument that `@CONSTANT` already has a precedent because of its use in
decorators, because decorators are names that are used at the top level,
and because the `@CONSTANT` syntax in patterns would mostly also refer to
top level names. However, users will adapt to whichever syntax is settled
on.)

I have two aesthetic suggestions, which have smaller impacts on clarity
than the above. Firstly, replacing `|` for delimiting patterns with the
more explicit keyword `or`. Python favours keywords where other languages
might use punctuation, such as `range(1, 10)` rather than `1..10`, because
full words are closer to natural language than punctuation is. Secondly, I
prefer the look of `(_, _) as point` over `point := (_, _)` for named
sub-patterns. This one is harder to justify because it's a personal
preference. All the same, it's worth considering if you haven't already
done so.

Finally, I dislike the way the underscore variable name seems like magic.
That is, it is a variable name that behaves differently from other names. I
recognise that there is a history of Python code treating `_` differently —
such as referring to the previous result in the REPL — and I can't offer
any better alternatives, just my opinion.
I hope you consider these perspectives, especially the change from
`.CONSTANT` to `@CONSTANT`. I'm anxious to get my hands on pattern matching
syntax, in whatever form it eventually takes.

Best wishes,
IFcoltransG
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JJMQEWZEAF224BEYBUJTYUNP4B5PAEZJ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 620: Hide implementation details from the C API

2020-06-30 Thread Inada Naoki
On Tue, Jun 30, 2020 at 6:45 AM Raymond Hettinger
 wrote:
>
>
> > Converting macros to static inline functions should only impact very few
> > C extensions which use macros in unusual ways.
>
> These should be individually verified to make sure they actually get inlined 
> by the compiler.  In https://bugs.python.org/issue39542 about nine PRs were 
> applied without review or discussion.  One of those, 
> https://github.com/python/cpython/pull/18364 , converted PyType_Check() to 
> static inline function but I'm not sure that it actually does get inlined.  
> That may be the reason named tuple attribute access slowed by about 25% 
> between Python 3.8 and Python 3.9.¹  Presumably, that PR also affected every 
> single type check in the entire C codebase and will affect third-party 
> extensions as well.
>

I confirmed the performance regression, although the difference is 12%.
And I find the commit cause the regression.

https://github.com/python/cpython/commit/45ec5b99aefa54552947049086e87ec01bc2fc9a
https://bugs.python.org/issue40170

The regression is not caused by "static inline" function is not
inlined by compiler.
The commit changed PyType_HasFeature to call regular function
PyType_GetFlags always.

Regards,
-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FOKJXG2SYMXCHYPGUZWVYMHLDR42BYFB/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Stable ABI question.

2020-06-30 Thread Inada Naoki
Hi, folks.

I found PyEval_AcquireLock and PyEval_ReleaseLock are deprecated since
Python 3.2.
But the same time, stable ABI is defined in Python 3.2 too.
The deprecated APIs are stable ABI too because `ceval.h` is not
excluded from the stable ABI PEP.

As far as my understanding, we can not remove them until Python 4.0. Am I right?

I will add comment like this.
/* This is a part of stable ABI. Do not remove until Python 4.0 */

Regards,
-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EJF67ZM2HMLWCVKAYNU4JCATO7CRILOS/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Giampaolo Rodola'
On Wed, Jul 1, 2020 at 2:34 AM Greg Ewing  wrote:
>
> Sorry for fanning the flames, but this whole thread is so over
> the top I'm finding it kind of entertaining.
>
> On 1/07/20 2:23 am, Piper Thunstrom wrote:
> > The grammarian movement, in general, was built on
> > elevating a very specific form of English over others. It specifically
> > was chosen to avoid "lower class" usages
>
> This argument seems to rest on the assumption that "lower
> class" equates to "non-white". This is an extremely US-centric
> idea. It could possibly even be described as exhibiting a
> "breathtaking level of ignorance"...
>
> > the
> > Elements of Style (And many works like it) are built on a system of
> > white supremacy.
>
> If that's true, then the entirety of Western culture is built
> on a system of white supremacy. That includes all our modern
> technology. It includes the Python programming language. We'd
> better stop recommending Python to people!
>
> > Each individual who likes
> > Elements of Style is not wrong for liking the book, you can keep it on
> > your shelf and no one will be angry.
>
> Okay, I'm confused. S&W is a symbol of white supremacy that
> shall never be recommended or mentioned in polite company, but
> it's all right to have one on your shelf, as long as you keep it
> to yourself... or something?
>
> You can't have it both ways.

Not if you keep the book between a rainbow and a unicorn.

-- 
Giampaolo - gmpy.dev
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CBHLMDEMEKQC5Z4P5OMMZJZ6X4BBTC4Z/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Please refrain from posting on the PEP 8 threads for 24 hours

2020-06-30 Thread Richard Damon
On 6/30/20 4:32 PM, Tim Peters wrote:
> [Victor Stinner ]
>> If someone continues to feed the PEP 8 discussion, would it be
>> possible to change their account to require moderation for 1 day or
>> maybe even up to 1 week? I know that Mailman 3 makes it possible.
> I see no such capability.  I could, for example, manually fiddle
> things so that messages from your email address are held for
> moderation, but that would persist until I manually undid it egain.
>
> But there seem to be many things Mailman 3 is theoretically capable of
> that aren't available via the list owner web UI. That's the only admin
> access I have (or want).
I've never heard of it having the ability to automatically time out a
moderation flag. What could be done (I think Mailman3 has it) is put a
filter on the topic subject to hold those messages for moderation, and
then remove that after things calm down. That depends on the moderator
being willing to take on that job (like the graphite rods in a reactor).

-- 
Richard Damon
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UP2JEEF2XKSENJT4GGOLDSIT2DB3Q5W4/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Greg Ewing

Sorry for fanning the flames, but this whole thread is so over
the top I'm finding it kind of entertaining.

On 1/07/20 2:23 am, Piper Thunstrom wrote:

The grammarian movement, in general, was built on
elevating a very specific form of English over others. It specifically
was chosen to avoid "lower class" usages


This argument seems to rest on the assumption that "lower
class" equates to "non-white". This is an extremely US-centric
idea. It could possibly even be described as exhibiting a
"breathtaking level of ignorance"...


the
Elements of Style (And many works like it) are built on a system of
white supremacy.


If that's true, then the entirety of Western culture is built
on a system of white supremacy. That includes all our modern
technology. It includes the Python programming language. We'd
better stop recommending Python to people!


Each individual who likes
Elements of Style is not wrong for liking the book, you can keep it on
your shelf and no one will be angry.


Okay, I'm confused. S&W is a symbol of white supremacy that
shall never be recommended or mentioned in polite company, but
it's all right to have one on your shelf, as long as you keep it
to yourself... or something?

You can't have it both ways.

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


[Python-Dev] Re: PEP 622: Structural Pattern Matching

2020-06-30 Thread Daniel Moisset
Hi, thank you for the comments

On Tue, 30 Jun 2020 at 07:18, Greg Ewing 
wrote:

> On 29/06/20 8:47 am, Daniel Moisset wrote:
> > <
> https://github.com/dmoisset/notebook/blob/811bf66/python/pep622/understanding-pep-622.md>
>  .
>
>
> You seem to be trying to shoehorn all Python data structures into
> looking like alebraic types, for the sole purpose of being able to
> claim that PEP 622 is really about algebraic types rather than
> pattern matching.
>

There may be a bit of this, I like "unifying concepts". But if I have a
bias, I was heavily pushed by the writing on the PEP. Their inspirations
are explicitly Rust and Scala (which have a very strong "algebraic type"
core),, and in discussions I've seen the authors discuss F# and Haskell
(again with a strong algebraic type influence). If they started on "we were
inspired by C's and Javascript's switch statement and then added some extra
features" I would have a different vision that the focus is
multiple-choice-conditional and the rest are extras. If they mentioned
Javascript destructuring operations as inspiration I would think instead
that the focus is decomposing builtin types and the rest are extras. The
motivation starts discussing about isinstance() checks and extracting
attributes which sounds more like "we added this to have algebraic data
types and hey, now that we're here we can also include some unpacking and
have a switch statement too".

The goal of my notes was to read the PEP between lines, so there's some
personal guess and bias, but it's not out of the blue :)

I don't think that's a helpful way of looking at things. Pattern
> matching with destructuring is a more general concept. Algebraic
> types is just one of its applications.
>

I agree on this statement (except the first sentence :) )... what I'm
trying to say is that the PEP has some underlying algebraic type style and
making it explicit is a way to understand it with different eyes.


> I think your viewpoint is coloured by languages in which algebraic
> types play a much more central role than they do in Python. For
> example, in Haskell, the usual notation for lists is syntactic
> sugar for an algebraic type representing a linked list.
>

Haskell also does some shoe-horning... integers in haskell are supposed to
be an algebraic type made by the union of infinite constructors named "1",
"2", "3", ... :) Even if the implementation is nothing like that, this kind
of shoe-horning is useful allows you to have a coherent story and design,
so I'm looking for somehting close to that in Python.


> But Python lists are not linked lists, they're flexible-sized
> arrays, and you have to squint very hard indeed to see them as
> being fundamentally an algebraic type. Yet pattern matching on
> them makes perfectly good sense.
>

True.  And python has already had that for ages. I'm *guessing* intent here
again, but I believe that was included into the PEP because it was easy,
not because it was the main concern to address.

> returning by default an object __dict__ or some sort of mapping view
> > on the attributes could still be fine. It's not clear to me why the
> > "keys" of this structure are placed separately.
>
> I think the PEP explains the rationale behind the design of the
> matching protocol quite well. The goal is to make it as simple as
> possible to implement in the most common cases.
>

I have improved my understanding of this. I still find the protocol weak
(but mostly the match, not the matched_args) even for the cases that are
desired to be covered, but I'm already discussing those directly with the
authors.

> For me, there should be an instance method in object (that
> > subclasses  can override) that returns the algebraic structure of the
> value.
> > The PEP as-is creates different destructuring views depending on
> > which matching class you use (whicch I think relates to something
> > that was mentioned but not discussed a lot in the python-dev list
> > about Liskov sustitability).
> I think the PEP has this right. Liskov substitutability doesn't apply
> to constructors -- they're not methods, and the constructor of a
> subclass doesn't have to accept the same arguments as that of its
> base class. The same thing applies to deconstructors, since they have
> to mirror the signature of their corresponding constructors. (...)


You're right, it was not Liskov related, but the single argument default
behaviour. I was wrong about this.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ONVWLWDJZWW2KGCRZPFZ3XXVKTB2JTT7/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Please refrain from posting on the PEP 8 threads for 24 hours

2020-06-30 Thread Tim Peters
[Victor Stinner ]
> If someone continues to feed the PEP 8 discussion, would it be
> possible to change their account to require moderation for 1 day or
> maybe even up to 1 week? I know that Mailman 3 makes it possible.

I see no such capability.  I could, for example, manually fiddle
things so that messages from your email address are held for
moderation, but that would persist until I manually undid it egain.

But there seem to be many things Mailman 3 is theoretically capable of
that aren't available via the list owner web UI. That's the only admin
access I have (or want).
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FSIQ36ZYGUMPCYXUOABBV6TCDVU2H467/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Please refrain from posting on the PEP 8 threads for 24 hours

2020-06-30 Thread Victor Stinner
If someone continues to feed the PEP 8 discussion, would it be
possible to change their account to require moderation for 1 day or
maybe even up to 1 week? I know that Mailman 3 makes it possible.

Victor

Le mar. 30 juin 2020 à 19:46, Tim Peters  a écrit :
>
> [Brett Cannon  wrote:]
> > Regardless of what side you fall on, I think we can agree that
> > emotions are running very high at the moment. Nothing is going
> > to change in at least the next 24 hours, so I am personally
> > asking folks to step back for at least that long and think about:
> >
> > Is what you want to say going to contribute to the discussion?
> > Is it being phrased in a polite, constructive fashion?
> >
> > If after 24 hours of reflection you feel your email still meets these
> > criteria then I would say it's reasonable to send that email.
>
> As python-dev's primary moderator, I endorse and second Brett's request.
>
> No, I'm not slapping blanket moderation on the list unless forced to.
> This is just a sensible adult-to-adult request to cool down and
> restore at least a shallow illusion;-) of mutual civility.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/HB22ZQECC5DJPIOFXHHDUAMGD6YN6WFO/
> Code of Conduct: http://python.org/psf/codeofconduct/



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


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Matt White



I am imagining the pain and hurt these conversations will cause for 
people who are not as well positioned and not as comfortable in the 
community.


Just want to throw out a counterpoint to the imagined people - as a real 
person who is not well positioned or comfortable in the community. I've 
been lurking on the list trying to wrap my head around the CPython 
process and how I might contribute.


I think it makes sense to remove the S&W standard, making it more open 
and less intimidating. I'm in a cohort that both agrees with the 
purported goal and disagrees with the execution. It's disappointing that 
anyone bringing up any counterpoint has to have a disclaimer so they 
aren't personally attacked, but this seems to be the level of discourse 
around these topics.


I'm not on Twitter for a reason; the commit message is much more suited 
to that environment. The goal, if it truly was for making a more 
inclusive community, has not been accomplished.


There is an effect - intended or not - making those of us who would 
rather focus on solving technical problems than having yet another 
exhausting emotionally charged rhetorical fight feel unwelcome. The 
personal attacks being thrown around are not helping.


If this was a necessary cost of inclusivity - which is the obvious 
fallback argument - it would be easier to believe the claim that this is 
entirely devoted to creating a more open and welcoming community. But 
the goal of opening things up by removing the S&W guideline could've 
been trivially accomplished without generating any of this drama.


It's baffling claim to promote cohesion and throw a partisan diatribe 
into the commit message.



Mmm. Well, we said what we had to say.


I think this captures the real intentions of the PR.

Best,
Matt White
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TMA4GK4JDFKOG2LV6ZBFPSXSYL6BFV6K/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Lists placed into Emergency Moderation status

2020-06-30 Thread Ernest W. Durbin III
On June 30, 2020 at 11:05:06 AM, Tim Peters (tim.pet...@gmail.com) wrote:
[Thomas Wouters ] 
> Just to clarify: this had nothing to do with the PSF, but with the 
> Steering Council 

My understanding is that the "PSF Executive Director" Ernest cited has 
nothing to do with the Steering Council, but with the PSF ;-) In any 
case, that's why I said "if it's the position of the PSF ...". 
As PSF Staff, the SC isn’t responsible for directing me to do anything in 
particular.

This is why Executive Director was involved at all, to convey their decision to 
me.

I performed the configuration literally at my director's direction.

-Ernest W. Durbin III___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/A2EQ57FFFCHS5HY7SZSMHBZS37ENJBII/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Rhodri James

On 30/06/2020 16:54, Piper Thunstrom wrote:

I do not. We must, as a community, examine our prejudices and aim to
be welcoming or we're going to see a split in Python much worse than
Py2 -> Py3.


Curiously I am yet to see any acknowledgement that the change itself may 
be detrimental to neuro-atypical people, of whom there are a fair number 
in the wider Python community (I've taught a number of them Python, so I 
know that to be true).  I didn't consider the point before Steven and 
Stephen raised it -- like most people, I don't automatically scan for 
prejudices except the ones I know I am prone to -- but it does fit with 
what I know of the Aspergers kids I've met.


The fundamental issue is this: your politics are not my politics. 
Keara's politics are not my politics.  I don't know either of you well 
enough, but I strongly suspect that your politics and Keara's politics 
are not the same either.  That's a perfectly natural state of affairs 
for human beings.


The commit message going with the (mild) relaxation of writing standards 
is a political statement.  I hope there's no argument about that.  That 
sets a precedent.  Unless the Steering Committee pronounce otherwise 
(and I hope they do), it is now OK to publish political statements as 
part of a commit message, presuming they can be contorted to relevance 
somehow (and that's usually not hard).  I guarantee you won't like some 
of those message, _but the precedent is being set._  Just because a 
statement is controversial doesn't mean it can't be accepted.


Ultimately, putting political statements in non-political places is 
divisive.  This whole exercise is a demonstration of that divisiveness. 
That's why I don't think they should be allowed in commit messages, even 
when I agree with them.  And that's why I think the commit message in 
question should be amended ASAP.


--
Rhodri James *-* Kynesim Ltd
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LKLSLDAPRJRDH5SMVBBROLSAGO4RZWFC/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Rhodri James

On 30/06/2020 18:02, Mark Lawrence wrote:
I suggest Geordie or Glaswegian on the grounds that most people outside 
of the UK have probably never heard of them hence they should be 
regarded as neutral in any world wide debate on English.


Possibly not.  I do recall an occasion when a Glaswegian and a Texan (I 
think, he was from somewhere Deep South) tried to communicate.  They had 
to get a passing Dutchman to translate for them.


(No joke, that really happened.)

--
Rhodri James *-* Kynesim Ltd
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JAUQEWNWPHSZQ2L4467Q4SL6O6OFWM3K/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Please refrain from posting on the PEP 8 threads for 24 hours

2020-06-30 Thread Tim Peters
[Brett Cannon  wrote:]
> Regardless of what side you fall on, I think we can agree that
> emotions are running very high at the moment. Nothing is going
> to change in at least the next 24 hours, so I am personally
> asking folks to step back for at least that long and think about:
>
> Is what you want to say going to contribute to the discussion?
> Is it being phrased in a polite, constructive fashion?
>
> If after 24 hours of reflection you feel your email still meets these
> criteria then I would say it's reasonable to send that email.

As python-dev's primary moderator, I endorse and second Brett's request.

No, I'm not slapping blanket moderation on the list unless forced to.
This is just a sensible adult-to-adult request to cool down and
restore at least a shallow illusion;-) of mutual civility.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HB22ZQECC5DJPIOFXHHDUAMGD6YN6WFO/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Mark Lawrence

On 30/06/2020 17:42, Antoine Pitrou wrote:


Hmm, I'm curious: which form of English do you propose Python should
standardize on? 
Regards


Antoine.



I suggest Geordie or Glaswegian on the grounds that most people outside 
of the UK have probably never heard of them hence they should be 
regarded as neutral in any world wide debate on English.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SKAASFLIGVGT65MNHNMNRFFDSJF7SOXN/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Rhodri James

On 30/06/2020 17:48, Alan G. Isaac wrote:

Which people in the Python community are entitled to say that
they find a commit message to be offensive and have that claim
treated seriously, compassionately, and as a good reason for
accommodative action?


Anyone, for any reason.  IMHO, obviously.  We (individually and 
collectively) may decide that their reasons don't hold water, but we 
should always listen.


--
Rhodri James *-* Kynesim Ltd
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BVE4X7PQGPSLBL5QDMKTRZ3TDU3EGT5D/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Please refrain from posting on the PEP 8 threads for 24 hours

2020-06-30 Thread Brett Cannon
Regardless of what side you fall on, I think we can agree that emotions are
running very high at the moment. Nothing is going to change in at least the
next 24 hours, so I am personally asking folks to step back for at least
that long and think about:

   1. Is what you want to say going to contribute to the discussion?
   2. Is it being phrased in a polite, constructive fashion?

If after 24 hours of reflection you feel your email still meets these
criteria then I would say it's reasonable to send that email.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/B2CFXHM2ND3KOYGLTBOYK4H2VMGRZT7J/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Richard Damon
On 6/30/20 12:18 PM, Jim F.Hilliard wrote:
> On Tue, 30 Jun 2020, 17:36 Piper Thunstrom,  > wrote: 
>
> It specifically
> was chosen to avoid "lower class" usages and things like AAVE (though
> that term would not exist for decades after the movement reached a
> furor).
>
>
> I mean, surely not only did it exclude "lower class" terms and AAVE
> (African American vernacular English, for the rest who don't do well
> with acronyms) it also excluded a number of dialects used by groups of
> all colours and backgrounds. I don't think I'd find any Australian
> words in there nor any Scottish ones, would I?
>
> I don't see how standard English is a white supremacist construct. I
> see it as an intersection of most of the dialects around, as a means
> to optimize communication by following a common set of guidelines.
>
> Can you elaborate on why you view this as being white supremacy? 
>
I agree with this, and for one very good reason, old, staid, sooty and
stuffy language has a very big advantage for communicating, and that is
being what it is, it tends to change slowly and people are likely to be
able to understand it.

Local vernaculars, almost by definition change much more rapidly and
aren't as wide spread, so it is much more likely that there are many
terms and constructions in them will be not well understood (if
understood at all) without having to do a lot of research, and even then
you may need to figure out which meaning was meant. If your goal is to
communicate, going to the old core is usually the best.

-- 
Richard Damon
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/U3IGMRZ3GB7P2C4P77L2XFJPPSJQKRIL/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Giampaolo Rodola'
Mmm. Well, we said what we had to say. I think we both agree there's
no point in continuing. ;-)
Cheers.

On Tue, Jun 30, 2020 at 5:54 PM Piper Thunstrom  wrote:
>
> On Tue, Jun 30, 2020 at 11:36 AM Giampaolo Rodola'  wrote:
> > No we don't. Who are you to tell others what they should be aware of
> > or what they should fight for? And why should I join your battle that
> > I don't even agree with? Most of us probably had no idea what Elements
> > of Style was before this thread started, and *none* of us has ever
> > attributed any racial meaning to it in the 19 years since PEP-8 was
> > put in place. I still don't attribute any racial meaning to it,
> > despite all the twisted explanations which were given about the
> > correlation with white supremacy, which AFAIK are only shared by you
> > and the person who pushed this PR, who is also a newcomer. If anybody
> > can come up here for the first time, impose their world view on the
> > majority just "because it's oppressive", and do this sort of
> > pandemonium, then we can kiss Python goodbye. It also means there
> > virtually is no end to this in the long run, because anyone can come
> > up with any sort of funny theory in order to tilt the direction of the
> > language and deviate its culture from the outside.
> >
> > --
> > Giampaolo - gmpy.dev
>
> It's disheartening as hell to watch a core dev so clearly despise the
> idea of growing the Python community.
>
> You have open contempt of the code of conduct, despite the growing
> movement of underrepresented minorities stating that codes of conduct
> make them feel safer in their communities.
>
> You openly belittle the contributions of people you view as "newcomers".
>
> You uphold that grand tradition of technical people who decide that
> because they are ignorant to a specific kind of oppression, that
> oppression doesn't exist.
>
> My focus in Python is not specifically the advancement of the language
> as a language (though I care about that, otherwise why would I be
> subscribed to this list at all?). My focus
> and love for Python is as a community. And I care, specifically, that
> I see three threads that are leaving me breathless and sad for my
> community. I am imagining the pain and hurt
> these conversations will cause for people who are not as well
> positioned and not as comfortable in the community. We are going to
> lose FUTURE contributors because your vitriol
> and hate for people who care about oppression as it intersects the
> Python community.
>
> You may very well think that's the optimal way for a language to be.
>
> I do not. We must, as a community, examine our prejudices and aim to
> be welcoming or we're going to see a split in Python much worse than
> Py2 -> Py3.
>
> Piper Thunstrom
>
> My public key is available at https://keybase.io/pathunstrom
> Public key fingerprint: 8FF9 3F4E C447 55EC 4658 BDCC A57E A7A4 86D2 644F



--
Giampaolo - gmpy.dev
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YU3PRLKET4RZWTP3RPMHSJ4Z73GWBXPE/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Antoine Pitrou
> The grammarian movement, in general, was built on elevating a very specific 
> form of English over others.

Hmm, I'm curious: which form of English do you propose Python should
standardize on? I agree that for code comments it may not matter much,
but it probably does for documentation. There are people who routinely
make small edits to the docs, and they probably do with some kind of
standard in mind (even if it's not "S&W").

Is the intent of the change simply to stop saying "we're following rules
told by grammarians"... but to still follow them, just without saying so
because it makes us feel better?

I'm also unclear how the very brand of English you're using is different
from the "white supremacist" brand of English that "is propping up a
hegemony that affects multiple axes of oppression".  Perhaps that's
because I'm a non-native English speaker.

Regards

Antoine.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7TOCV3JRS4IZNOO5YODHCQUABHX6F3UN/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Alan G. Isaac

Which people in the Python community are entitled to say that
they find a commit message to be offensive and have that claim
treated seriously, compassionately, and as a good reason for
accommodative action?  Under what circumstances is the
appropriate response of the community a dismissive
"you are wrong to take offense"?  Under what circumstances
should a commit message include or imply a contestable,
politically charged historical narrative?

Some concrete guidelines might be helpful in this conversation.

Alan Isaac
(just a long-time Python user, who will not post again)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5I7PZXRNDBW6GZTKZTVYJDHJCSVCSVGJ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] [RELEASE] Python 3.8.4rc1 is now ready for testing

2020-06-30 Thread Łukasz Langa
Python 3.8.4rc1 is the release candidate of the fourth maintenance release of 
Python 3.8. Go get it here:
https://www.python.org/downloads/release/python-384rc1/ 

Assuming no critical problems are found prior to 2020-07-13, the scheduled 
release date for 3.8.4, no code changes are planned between this release 
candidate and the final release.

That being said, please keep in mind that this is a pre-release and as such its 
main purpose is testing.

Maintenance releases for the 3.8 series will continue at regular bi-monthly 
intervals, with 3.8.5 planned for mid-September 2020.

What’s new?

The Python 3.8 series is the newest feature release of the Python language, and 
it contains many new features and optimizations. See the “What’s New in Python 
3.8 ” document for more 
information about features included in the 3.8 series.

This is the first bugfix release that is considerably smaller than the previous 
three. There’s 20% less changes at 130 commits than the average of previous 
three releases. Detailed information about all changes made in version 3.8.4 
specifically can be found in its change log 
.

We hope you enjoy Python 3.8!

Thanks to all of the many volunteers who help make Python Development and these 
releases possible! Please consider supporting our efforts by volunteering 
yourself or through organization contributions to the Python Software 
Foundation.

Your friendly release team,
Ned Deily @nad 
Steve Dower @steve.dower 
Łukasz Langa @ambv ___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VVK3CFZJOB54KKL2QUKCLWSFNSM6BRDV/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Jim F.Hilliard
On Tue, 30 Jun 2020, 17:36 Piper Thunstrom,  wrote:

It specifically
> was chosen to avoid "lower class" usages and things like AAVE (though
> that term would not exist for decades after the movement reached a
> furor).


I mean, surely not only did it exclude "lower class" terms and AAVE
(African American vernacular English, for the rest who don't do well with
acronyms) it also excluded a number of dialects used by groups of all
colours and backgrounds. I don't think I'd find any Australian words in
there nor any Scottish ones, would I?

I don't see how standard English is a white supremacist construct. I see it
as an intersection of most of the dialects around, as a means to optimize
communication by following a common set of guidelines.

Can you elaborate on why you view this as being white supremacy?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XSWX7ETERNPLDDOFM65DSMAQWGPDFLUU/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Piper Thunstrom
On Tue, Jun 30, 2020 at 11:36 AM Giampaolo Rodola'  wrote:
> No we don't. Who are you to tell others what they should be aware of
> or what they should fight for? And why should I join your battle that
> I don't even agree with? Most of us probably had no idea what Elements
> of Style was before this thread started, and *none* of us has ever
> attributed any racial meaning to it in the 19 years since PEP-8 was
> put in place. I still don't attribute any racial meaning to it,
> despite all the twisted explanations which were given about the
> correlation with white supremacy, which AFAIK are only shared by you
> and the person who pushed this PR, who is also a newcomer. If anybody
> can come up here for the first time, impose their world view on the
> majority just "because it's oppressive", and do this sort of
> pandemonium, then we can kiss Python goodbye. It also means there
> virtually is no end to this in the long run, because anyone can come
> up with any sort of funny theory in order to tilt the direction of the
> language and deviate its culture from the outside.
>
> --
> Giampaolo - gmpy.dev

It's disheartening as hell to watch a core dev so clearly despise the
idea of growing the Python community.

You have open contempt of the code of conduct, despite the growing
movement of underrepresented minorities stating that codes of conduct
make them feel safer in their communities.

You openly belittle the contributions of people you view as "newcomers".

You uphold that grand tradition of technical people who decide that
because they are ignorant to a specific kind of oppression, that
oppression doesn't exist.

My focus in Python is not specifically the advancement of the language
as a language (though I care about that, otherwise why would I be
subscribed to this list at all?). My focus
and love for Python is as a community. And I care, specifically, that
I see three threads that are leaving me breathless and sad for my
community. I am imagining the pain and hurt
these conversations will cause for people who are not as well
positioned and not as comfortable in the community. We are going to
lose FUTURE contributors because your vitriol
and hate for people who care about oppression as it intersects the
Python community.

You may very well think that's the optimal way for a language to be.

I do not. We must, as a community, examine our prejudices and aim to
be welcoming or we're going to see a split in Python much worse than
Py2 -> Py3.

Piper Thunstrom

My public key is available at https://keybase.io/pathunstrom
Public key fingerprint: 8FF9 3F4E C447 55EC 4658 BDCC A57E A7A4 86D2 644F
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/E7GOXAR52HMYYTXWRVMSRJ3Y2K7KUBIJ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Giampaolo Rodola'
On Tue, Jun 30, 2020 at 4:39 PM Piper Thunstrom  wrote:
>
> > The original request for the change had absolutely no hint that the current 
> > text was racist in any way; then we find out that, apparently, we've been 
> > harboring white supremacist ideals by prescribing when to use apostrophes 
> > and commas?  That commit message (not the commit itself) took what should 
> > have been a simple change and turned into a platform for political 
> > grandstanding of the worst kind:
> >
> > - False, as far as I can tell (until given confirming examples from the S&W 
> > text)
> > - Only colored people are mentioned (and other /native English speakers/)
> > - Zero mention of non-native English speakers
>
> So, I think I can explain. (Not with references because I've lost most
> of them over the years, but bear with me.)
>
> The actual advice in The Elements of Style are mostly inoffensive when
> taken on their own, and out of context. The problem is that the
> Elements of Style (And many works like it) are built on a system of
> white supremacy. The grammarian movement, in general, was built on
> elevating a very specific form of English over others. It specifically
> was chosen to avoid "lower class" usages and things like AAVE (though
> that term would not exist for decades after the movement reached a
> furor).
>
> The commentary in the commit message is a plain and simple description
> of the effects of the grammarian movement to someone who has studied
> the topic.
>
> Strunk & White is just one possible edifice of that history. As
> mentioned already in this thread, it is not the name of the authors
> that is the problem, but the movement and history of Standard English
> that is the edifice of white supremacy. You cannot evaluate the book
> strictly outside of the context in which it was written and used and
> declare it's not white supremacist.
>
> In summary:
>
> The thing being objected to was the idea that we should choose
> Standard English as our basis for our language guide. Further, S&W, a
> classical work on how to write Standard English well, is a bad guide
> when discussing in light of that fact. Each individual who likes
> Elements of Style is not wrong for liking the book, you can keep it on
> your shelf and no one will be angry. But this argument about Standard
> English is propping up a hegemony that affects multiple axes of
> oppression, and we should be aware of that.

No we don't. Who are you to tell others what they should be aware of
or what they should fight for? And why should I join your battle that
I don't even agree with? Most of us probably had no idea what Elements
of Style was before this thread started, and *none* of us has ever
attributed any racial meaning to it in the 19 years since PEP-8 was
put in place. I still don't attribute any racial meaning to it,
despite all the twisted explanations which were given about the
correlation with white supremacy, which AFAIK are only shared by you
and the person who pushed this PR, who is also a newcomer. If anybody
can come up here for the first time, impose their world view on the
majority just "because it's oppressive", and do this sort of
pandemonium, then we can kiss Python goodbye. It also means there
virtually is no end to this in the long run, because anyone can come
up with any sort of funny theory in order to tilt the direction of the
language and deviate its culture from the outside.

--
Giampaolo - gmpy.dev
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/24G5JXOJTB7YM5BZWHMTLJHIZLBWXTPQ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Keara Berlin
Thank you, Piper. This is exactly what I meant to say, and a very good
explanation. I appreciate your time and energy.

On Tue, Jun 30, 2020, 09:23 Piper Thunstrom  wrote:

> > The original request for the change had absolutely no hint that the
> current text was racist in any way; then we find out that, apparently,
> we've been harboring white supremacist ideals by prescribing when to use
> apostrophes and commas?  That commit message (not the commit itself) took
> what should have been a simple change and turned into a platform for
> political grandstanding of the worst kind:
> >
> > - False, as far as I can tell (until given confirming examples from the
> S&W text)
> > - Only colored people are mentioned (and other /native English speakers/)
> > - Zero mention of non-native English speakers
>
> So, I think I can explain. (Not with references because I've lost most
> of them over the years, but bear with me.)
>
> The actual advice in The Elements of Style are mostly inoffensive when
> taken on their own, and out of context. The problem is that the
> Elements of Style (And many works like it) are built on a system of
> white supremacy. The grammarian movement, in general, was built on
> elevating a very specific form of English over others. It specifically
> was chosen to avoid "lower class" usages and things like AAVE (though
> that term would not exist for decades after the movement reached a
> furor).
>
> The commentary in the commit message is a plain and simple description
> of the effects of the grammarian movement to someone who has studied
> the topic.
>
> Strunk & White is just one possible edifice of that history. As
> mentioned already in this thread, it is not the name of the authors
> that is the problem, but the movement and history of Standard English
> that is the edifice of white supremacy. You cannot evaluate the book
> strictly outside of the context in which it was written and used and
> declare it's not white supremacist.
>
> In summary:
>
> The thing being objected to was the idea that we should choose
> Standard English as our basis for our language guide. Further, S&W, a
> classical work on how to write Standard English well, is a bad guide
> when discussing in light of that fact. Each individual who likes
> Elements of Style is not wrong for liking the book, you can keep it on
> your shelf and no one will be angry. But this argument about Standard
> English is propping up a hegemony that affects multiple axes of
> oppression, and we should be aware of that.
>
> Piper Thunstrom
>
> My public key is available at https://keybase.io/pathunstrom
> Public key fingerprint: 8FF9 3F4E C447 55EC 4658 BDCC A57E A7A4 86D2 644F
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DTPIGABGRPAZVHWHEPCG2WOGVKWNJBYB/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Lists placed into Emergency Moderation status

2020-06-30 Thread Tim Peters
 [Ernest W. Durbin III ]
>>> Reviewing, I may have misinterpreted the message from PSF Executive
>>> Director regarding the situation.
>>>
>>> It does appear that python-ideas moderators contacted postmaster@.
>>> Appears I misread a message saying “it looks like it’s happening on
>>> python-dev too” to mean that the request was for both lists.

[Tim Peters]
>> It depends on who you want to annoy least ;-)
>>
>> If it's the position of the PSF that some kind(s) of messages must be
>> suppressed, then I'll need a more-or-less clear definition, from them,
>> of what those consist of.  At which point I'll agree to enforce them,
>> or step down as a python-dev moderator.

[Thomas Wouters ]
> Just to clarify: this had nothing to do with the PSF, but with the
> Steering Council

My understanding is that the "PSF Executive Director" Ernest cited has
nothing to do with the Steering Council, but with the PSF ;-)  In any
case, that's why I said "if it's the position of the PSF ...".

> and the python-ideas moderators. We were discussing the PEP-8 "controversy"
> last night, after Titus (one of the python-ideas moderators) asked about 
> putting
< *that* list in full moderation, and we talked about how the
discussion had bled
> over into python-dev. We weren't clear among ourselves which lists we were
> talking about anymore when we asked Ernest

So it wasn't the PSF Executive Director.  Regardless, same thing in
the end to me:  if someone who claims authority to do this wants to
enforce some content suppression rules on python-dev, that's a
business I'm very reluctant to get into, but can't judge without a
clearer definition of what's out of bounds.

I do OK with "spam" and "wholly off topic", but Python people telling
each other their attitudes, beliefs, and/or behaviors are disgusting,
unacceptable, evil ... strikes me as being a healthy (if unpleasant)
family fight.  I won't take a side on that in the moderation role.

> to see about emergency moderation mode (which wasn't as easy as we
> would've expected),

To judge from the change I undid myself for python-dev, it appeared to
amount to no more than putting ".*" in a regexp field to match all
Subject lines. (To be clear, I undid this for python-dev; Ernest did
not, so blame me - as the night wore on, I wanted to kill the change
before I went to sleep, so people posting overnight (from my POV)
wouldn't have to wait hours & hours for posts to go through.)

> which is why Ernest did it for both lists. We should've been more careful
> about this, and looped in the python-dev moderators straight away. Sorry
> about that.

Not a real problem! Just another minor computer-related busy-work
annoyance, in a life overflowing with such for decade after decade
after decade ;-)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AAXZP3GD6PWW36FNQLHUD545NM7W6MX4/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread David Mertz
On Tue, Jun 30, 2020, 10:38 AM Piper Thunstrom

> The actual advice in The Elements of Style are mostly inoffensive when
> taken on their own, and out of context. The problem is that the Elements of
> Style (And many works like it) are built on a system of white supremacy.
> The grammarian movement, in general, was built on
> elevating a very specific form of English over others. It specifically
> was chosen to avoid "lower class" usages and things like AAVE (though
> that term would not exist for decades after the movement reached a furor).
>

I don't think this is the place for critical literary theory. I am well
aware of the social history of the grammarian movement. But I'm also well
aware of the "death of the author", and Roland Barthes, and Jacques
Derrida, and of the essential role of active readership in giving meaning
to texts like S&W.

I think the story told in the commit message is well intentioned and mostly
wrong because it commits to a naive logocentrism in it's analysis. But
surely this isn't the debate needed on GH logs, nor even on python-dev.

All we needed was "Removed specific style guide recommendation" ... The MLA
conference is two doors down, and to the left.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/T5GZQVP6S3B6KRHY2IP554TFJSJBMNOO/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Stéfane Fermigier
I didn't want to participate in this discussion, but I will, probably for
the following reasons:

- I'm French
- I bought a copy of Strunk & White during my first trip to the US, in
1990, in a desperate attempt to improve my english writing style.
- I can't say it changed my life, but I found the advice it contains useful
- and, as noted by others, not just for english speakers.
- For this reason, I have some fondness for this book (I know it has its
limitations too...).
- I'm puzzled by how some people might equate S&W with white supremacy.

I was still puzzled, as many others in this thread, until I googled for it,
and found some reference to this story:

*His former executive assistant, Cassie Jones, who is black, quit shortly
after he gave her a gift she considered insulting, three people with
knowledge of the matter said.*

> *In November, after she had spent four months working for him, Mr. Lynch
called Ms. Jones into his office and handed her “The Elements of Style,” a
guide to standard English usage by William Strunk Jr. and E.B. White. Mr.
Lynch said he thought she could benefit from it.*

> *With its suggestion that her own language skills were lacking, the gift
struck Ms. Jones as a microaggression, the people said. A few days later,
she quit. Before leaving the headquarters at 1 World Trade in Lower
Manhattan, she placed the book on his desk.*

*Mr. Lynch said he hadn’t meant to insult Ms. Jones, who declined to
comment for this article. “I really only had the intention — like every
time I’ve given it before — for it to be a helpful resource, as it has been
for me,” he said. “I still use it today. I’m really sorry if she
interpreted it that way.”*

https://www.nytimes.com/2020/06/13/business/media/conde-nast-racial.html

So I guess this gives some context to this discussion.

Additional personal remark: I have many times in my professional life given
or been given a book about specific work-related topics when I or the other
party thought that one could benefit from it in terms of useful
work-related skill acquisition. I find it quite hard to understand how
someone would reject such a gift and take it as a reason to resign (unless
of course there were other things going on in this company, in which case,
why bring the focus on S&W ?).

  S.


On Tue, Jun 30, 2020 at 3:29 PM Kyle Stanley  wrote:

> > Basically, it feels like we were lied to.  And if that wasn't bad
> enough, to see that Guido accepted that vitriolic commit message and merged
> it in ... it makes me embarrassed to be a Python supporter.
>
> Only Guido could attest to this, but as someone who spoke in support of
> the change, I personally missed the commit message until attention was
> drawn to it in the python-ideas thread. When reviewing PRs, I'll admit that
> I don't pay a whole lot of attention to the individual commit messages
> (particularly extended descriptions); most of my attention is on the actual
> changes made. So, perhaps he did the same?
>
> Either way, I don't think I would go as far as to say that it embarrasses
> me as a Python contributor. That being said, it did very much feel like it
> went in a completely different direction than the PR description, and I'm
> uncomfortable with it as well for that reason. So, my vote would be to
> amend the commit message based on the description of the PR and proposal
> made in python-ideas.
>
> On Tue, Jun 30, 2020 at 8:53 AM Ethan Furman  wrote:
>
>> On 06/30/2020 05:03 AM, Łukasz Langa wrote:
>> >
>> >> On 30 Jun 2020, at 12:44, Ethan Furman > et...@stoneleaf.us>> wrote:
>> >>
>> >> Of course I don't know if Keara or Guido knew any of this, but it
>> certainly feels to me that the commit message is ostracizing an entire
>> family line because they had the misfortune to have the wrong last name.
>> In fact, it seems like Strunk & White is making changes to be inclusive in
>> its advice -- exactly what I would have thought we wanted on our side ("our
>> side" being the diverse and welcoming side).
>> >
>> > In any case, saying that Keara and Guido mistook the family name of one
>> of the authors for skin color feels derogatory.
>>
>> My apologies, that was not my intent.  As I said, I never knew what it
>> was until today (er, yesterday now).
>>
>> > The commit message clearly is controversial but when you say the change
>> itself was unnecessary, consider that English is now a language
>> predominantly used outside of USA and Great Britain. Relaxing the
>> recommendation to use S & L Standard English in the CPython codebase isn't
>> problematic in this sense. That recommendation was largely ignored anyway,
>> as core developer voices in the other threads already admitted. So, chaos
>> won't ensue. We still want to maintain consistency, as PEP 8 recommends. I
>> don't think you have to worry now about seeing organization and
>> organisation in the same docstring.
>>
>> Well, that wouldn't bother me -- as often as not I use non-US-English
>> spellings; I just appreciate if i

[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Piper Thunstrom
> The original request for the change had absolutely no hint that the current 
> text was racist in any way; then we find out that, apparently, we've been 
> harboring white supremacist ideals by prescribing when to use apostrophes and 
> commas?  That commit message (not the commit itself) took what should have 
> been a simple change and turned into a platform for political grandstanding 
> of the worst kind:
>
> - False, as far as I can tell (until given confirming examples from the S&W 
> text)
> - Only colored people are mentioned (and other /native English speakers/)
> - Zero mention of non-native English speakers

So, I think I can explain. (Not with references because I've lost most
of them over the years, but bear with me.)

The actual advice in The Elements of Style are mostly inoffensive when
taken on their own, and out of context. The problem is that the
Elements of Style (And many works like it) are built on a system of
white supremacy. The grammarian movement, in general, was built on
elevating a very specific form of English over others. It specifically
was chosen to avoid "lower class" usages and things like AAVE (though
that term would not exist for decades after the movement reached a
furor).

The commentary in the commit message is a plain and simple description
of the effects of the grammarian movement to someone who has studied
the topic.

Strunk & White is just one possible edifice of that history. As
mentioned already in this thread, it is not the name of the authors
that is the problem, but the movement and history of Standard English
that is the edifice of white supremacy. You cannot evaluate the book
strictly outside of the context in which it was written and used and
declare it's not white supremacist.

In summary:

The thing being objected to was the idea that we should choose
Standard English as our basis for our language guide. Further, S&W, a
classical work on how to write Standard English well, is a bad guide
when discussing in light of that fact. Each individual who likes
Elements of Style is not wrong for liking the book, you can keep it on
your shelf and no one will be angry. But this argument about Standard
English is propping up a hegemony that affects multiple axes of
oppression, and we should be aware of that.

Piper Thunstrom

My public key is available at https://keybase.io/pathunstrom
Public key fingerprint: 8FF9 3F4E C447 55EC 4658 BDCC A57E A7A4 86D2 644F
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SD2QHQRDFXVHQ54C5TBGPY2THU5YBVNN/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

2020-06-30 Thread Rhodri James

On 30/06/2020 13:58, Thomas Wouters wrote:

I wasn't speaking for the PSF or the Steering Council,


I'm afraid as politicians around the world discover on a daily basis, it 
doesn't work that way.  Particularly on political matters such as this, 
you do speak as a Steering Council member and PSF board member unless 
you very explicitly say otherwise, and even then your comments will 
reflect on both organisations.  This is the sort of behaviour that gets 
local politicians suspended from their parties.



nor was my intent to
"silence or force out people guilty of thought-crime and holding the wrong
opinion".


Perhaps you should re-read what you wrote.  "Unfriendly" is an extremely 
polite term for the tone of it, and I for one felt threatened.


[Steven D'Aprano said:]

I think that Thomas' post violated the CoC:


Please report all CoC violations to the CoC WG.


Good point.  Duly done.

--
Rhodri James *-* Kynesim Ltd
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/P77K5QFSYLZU3ROHJP354JQZCGGH3KEG/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

2020-06-30 Thread Giampaolo Rodola'
On Tue, Jun 30, 2020 at 3:16 PM Thomas Wouters  wrote:
>
>
>
> On Tue, Jun 30, 2020 at 2:36 PM Steven D'Aprano  wrote:
>>
>> It needs to be pointed out that Thomas Wouters was recently re-elected
>> to the PSF board. I think we need to know whether Thomas speaks for the
>> entire PSF board.Giampaolo feared this:
>>
>> "It's gonna happen again and again, until everybody gets in line, shuts
>> up or leaves due to exhaustion."
>>
>> and Thomas replied:
>>
>> "I'm not sure how much more clear python-dev and the PSF could have been
>> that this is true."
>>
>> So is it true? Do the core devs and the PSF have a policy of
>> pushing divisive political changes to silence and force out of the
>> community people who are guilty of thought-crime and holding the wrong
>> opinion on political matters?
>
>
> I wasn't speaking for the PSF or the Steering Council, nor was my intent to 
> "silence or force out people guilty of thought-crime and holding the wrong 
> opinion".
>
>>
>>
>> I think that Thomas' post violated the CoC:
>
>
> Please report all CoC violations to the CoC WG.

Please don't. As far as I'm concerned, me and Thomas are fine. Also,
as I said, I don't like CoCs nor appealing to them.

-- 
Giampaolo - gmpy.dev
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CP6ILO3OVZ6SLOHJUZKWDTCMOOCYQFTG/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

2020-06-30 Thread Rhodri James

On 30/06/2020 13:43, Emily Bowman wrote:

I completely agree with this, that UTF-8 has become the One True
Encoding(tm), and UCS-2 and UTF-16 are hardly found anywhere outside of the
Win32 API. Nearly all basic emoji can't be represented in UCS-2 wchar_t,
let alone composite emoji.


You say that as if it's a bad thing :-)


So how to make that C-compatible? Make everything a void* and it just comes
back with as many bytes as it gets?


I'd be inclined to something like that.  You really don't want people 
trying to roll their own UTF-8 handling if you can help it.  That does 
imply the C API will need to be pretty comprehensive, though.


(If you want nightmares, take a look at the parsing code in Expat. 
Multiple layers of macros and function tables make it a horror to 
comprehend.)


--
Rhodri James *-* Kynesim Ltd
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7HPGNVZ46ROP3HMRUJXJXX2WI4LI4JAL/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Kyle Stanley
> Basically, it feels like we were lied to.  And if that wasn't bad enough,
to see that Guido accepted that vitriolic commit message and merged it in
... it makes me embarrassed to be a Python supporter.

Only Guido could attest to this, but as someone who spoke in support of the
change, I personally missed the commit message until attention was drawn to
it in the python-ideas thread. When reviewing PRs, I'll admit that I don't
pay a whole lot of attention to the individual commit messages
(particularly extended descriptions); most of my attention is on the actual
changes made. So, perhaps he did the same?

Either way, I don't think I would go as far as to say that it embarrasses
me as a Python contributor. That being said, it did very much feel like it
went in a completely different direction than the PR description, and I'm
uncomfortable with it as well for that reason. So, my vote would be to
amend the commit message based on the description of the PR and proposal
made in python-ideas.

On Tue, Jun 30, 2020 at 8:53 AM Ethan Furman  wrote:

> On 06/30/2020 05:03 AM, Łukasz Langa wrote:
> >
> >> On 30 Jun 2020, at 12:44, Ethan Furman  et...@stoneleaf.us>> wrote:
> >>
> >> Of course I don't know if Keara or Guido knew any of this, but it
> certainly feels to me that the commit message is ostracizing an entire
> family line because they had the misfortune to have the wrong last name.
> In fact, it seems like Strunk & White is making changes to be inclusive in
> its advice -- exactly what I would have thought we wanted on our side ("our
> side" being the diverse and welcoming side).
> >
> > In any case, saying that Keara and Guido mistook the family name of one
> of the authors for skin color feels derogatory.
>
> My apologies, that was not my intent.  As I said, I never knew what it was
> until today (er, yesterday now).
>
> > The commit message clearly is controversial but when you say the change
> itself was unnecessary, consider that English is now a language
> predominantly used outside of USA and Great Britain. Relaxing the
> recommendation to use S & L Standard English in the CPython codebase isn't
> problematic in this sense. That recommendation was largely ignored anyway,
> as core developer voices in the other threads already admitted. So, chaos
> won't ensue. We still want to maintain consistency, as PEP 8 recommends. I
> don't think you have to worry now about seeing organization and
> organisation in the same docstring.
>
> Well, that wouldn't bother me -- as often as not I use non-US-English
> spellings; I just appreciate if it's a correct spelling /somewhere/.
>
> >> That's what it felt like:  betrayal.
> >
> > This entire section of your message is confusing to me. Mind explaining?
> How does a commit message equate stabbing somebody who helped you? What is
> being betrayed in this commit?
>
> The original request for the change had absolutely no hint that the
> current text was racist in any way; then we find out that, apparently,
> we've been harboring white supremacist ideals by prescribing when to use
> apostrophes and commas?  That commit message (not the commit itself) took
> what should have been a simple change and turned into a platform for
> political grandstanding of the worst kind:
>
> - False, as far as I can tell (until given confirming examples from the
> S&W text)
> - Only colored people are mentioned (and other /native English speakers/)
> - Zero mention of non-native English speakers
>
> Basically, it feels like we were lied to.  And if that wasn't bad enough,
> to see that Guido accepted that vitriolic commit message and merged it in
> ... it makes me embarrassed to be a Python supporter.
>
> --
> ~Ethan~
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/T55AGV7XPQ7YHU2VFIBHAWUZHEMZ43R3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DOM5V5QSKFJSD3FKVXIF4C4X3AFE6QNR/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

2020-06-30 Thread David Mertz
On Tue, Jun 30, 2020, 8:39 AM Steven D'Aprano  wrote:

> It needs to be pointed out that Thomas Wouters was recently re-elected to
> the PSF board. I think we need to know whether Thomas speaks for the entire
> PSF board.
>

That seems silly. Of course Thomas doesn't speak for the Board here, and
nothing suggests he does. That doesn't mean the rest of the board
disagrees, but neither does it mean they agree. They can speak for
themselves.

In the very unlikely event that the PSF Board takes an official action in
relation to this stuff, it would be very clearly marked as such. Directors
are just people, y'know.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KEDL2NUSUFZ5DA6SC43IMQ3OFZMXZHB4/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

2020-06-30 Thread Victor Stinner
Le mar. 30 juin 2020 à 13:53, M.-A. Lemburg  a écrit :
> > I would prefer to analyze the list on a case by case basis. I don't
> > think that it's useful to expose every single encoding supported by
> > Python as a C function.
>
> (...)
> This does not mean we have to give up the symmetry in the C API,
> or that the encoding APIs are now suddenly useless. It only means
> that we have to replace Py_UNICODE with one of the supported data
> for storing Unicode.

Let's agree to disagree :-)

I don't think that completeness is a good rationale to design the C API.

The C API is too large, we have to make it smaller. A specialized
function, like PyUnicode_AsUTF8String(), can be justified by different
reasons:

* It is a very common use case and so it helps to write C extensions
* It is significantly faster than the alternative generic function

In C, you can execute arbitrary Python code by calling methods on
Python str objects. For example, "abc".encode("utf-8",
"surrogateescape") in Python becomes PyObject_CallMethod(obj,
"encode", "ss", "utf-8", "surrogatepass") in C. Well, there is already
a more specialized and generic PyUnicode_AsEncodedObject() function.

We must not add a C API function for every single Python feature,
otherwise it would be too expensive to maintain, and it would become
impossible for other Python implementations to implement the fully C
API. Well, even today, PyPy already only implements a small subset of
the C API.


> Since the C world has adopted wchar_t for this purpose, it's the
> natural choice.

In my experience, in C extensions, there are two kind of data:

* bytes is used as a "char*": array of bytes
* Unicode is used as a Python object

For the very rare cases involving wchar_t*, PyUnicode_FromWideChar()
can be used. I don't think that performance justifies to duplicate
each function, once for a Python str object, once for wchar_t*. I
mostly saw code involving wchar_t* to initialize Python. But this code
was wrong since it used PyUnicode function *before* Python was
initialized. That's bad and can now crash in recent Python versions.
The new PEP 587 has a different design and avoids Python objects and
anything related to the Python runtime:
https://docs.python.org/dev/c-api/init_config.html#c.PyConfig_SetString

Moreover, CPython implements functions taking wchar_t* string by
calling PyUnicode_FromWideChar() internally...


> PyUnicode_AsEncodedString() converts Unicode objects to a
> bytes object. This is not an symmetric replacement for the
> PyUnicode_Encode*() APIs, since those go from Py_UNICODE to
> a bytes object.

I don't see which feature is missing from PyUnicode_AsEncodedString().
If it's about parameters specific to some encodings like UTF-7, I
already replied in another email.


> Since the C API is not only meant to be used by the CPython interpreter,
> we should stick to standards rather than expecting the world to adapt
> to our implementations. This also makes the APIs future proof, e.g.
> in case we make another transition from the current hybrid internal
> data type for Unicode towards UTF-8 buffers as internal data type.

Do you know C extensions in the wild which are using wchar_t* on
purpose? I haven't seen such a C extension yet.

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


[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

2020-06-30 Thread Richard Damon
On 6/30/20 8:43 AM, Emily Bowman wrote:
> I completely agree with this, that UTF-8 has become the One True
> Encoding(tm), and UCS-2 and UTF-16 are hardly found anywhere outside
> of the Win32 API. Nearly all basic emoji can't be represented in UCS-2
> wchar_t, let alone composite emoji.
>
> So how to make that C-compatible? Make everything a void* and it just
> comes back with as many bytes as it gets?

Actually, in C you would tend to represent UTF-8 as a char* (or maybe an
unsigned char*) type. This points out that straight 'ASCII' strings are
also UTF-8, and that many of the string functions will actually work ok
with UTF-8 strings. This was an intentional part of the design of UTF-8.
Anything looking for specific character values will tend to 'just work',
as long as those values really represent a character. The code also
needs to take account of that now bytes != characters, so if you want to
actually count how many characters are in a string, you need to be
aware, and avoid splitting a string in the middle of a code-point, but a
lot will still just work.

-- 
Richard Damon
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YQWLGMN2M4JDVFSOYGFMOPUB7QAAWH2U/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

2020-06-30 Thread Thomas Wouters
On Tue, Jun 30, 2020 at 2:36 PM Steven D'Aprano  wrote:

> It needs to be pointed out that Thomas Wouters was recently re-elected
> to the PSF board. I think we need to know whether Thomas speaks for the
> entire PSF board.Giampaolo feared this:
>
> "It's gonna happen again and again, until everybody gets in line, shuts
> up or leaves due to exhaustion."
>
> and Thomas replied:
>
> "I'm not sure how much more clear python-dev and the PSF could have been
> that this is true."
>
> So is it true? Do the core devs and the PSF have a policy of
> pushing divisive political changes to silence and force out of the
> community people who are guilty of thought-crime and holding the wrong
> opinion on political matters?
>

I wasn't speaking for the PSF or the Steering Council, nor was my intent to
"silence or force out people guilty of thought-crime and holding the wrong
opinion".


>
> I think that Thomas' post violated the CoC:
>

Please report all CoC violations to the CoC WG.


>
> * not open, considerate, or respectful;
>
> * dismissive of Giampaolo's efforts;
>
> * not respectful of differing viewpoints;
>
> * lacking empathy towards others with alternative perspectives.
>
> The CoC doesn't mention the word "tolerant" or "tolerance", but there
> was nothing of either in Thomas' post. And coming from a PSF Board
> member, I think that is extremely worrying.
>
>
> Steven
>
>
>
> On Tue, Jun 30, 2020 at 12:42:40PM +0200, Antoine Pitrou wrote:
> > On Tue, 30 Jun 2020 11:52:52 +0200
> > Thomas Wouters  wrote:
> > >
> > > I'm not sure who 'our' is in this sentence, but I'm certainly not glad
> > > Python ever took any of your patches.
> >
> > Really?
> >
> > You know, I don't care (and few people probably care) what you think
> > personally of other core developers.  But that you aren't even able to
> > keep those thoughts for yourself and instead think it's ok to launch
> > vitriolic attacks publicly, doesn't reflect very well on you.
> >
> > Personally, I'm glad Giampaolo contributes to the project, as well as
> > to the community (psutil is invaluable).  And I think you should just
> > police yourself instead of attacking him personally.
> >
> > > We want to be more welcoming, not less --
> >
> > But do you *personally*? You certainly do not sound like you want to be
> > "more welcoming".  Your belliquous attitude doesn't support that.  You
> > sound like you have an axe to grind.
> >
> > If your stated intentions are contradicted by your own behaviour,
> > you're doing it wrong.
> >
> >
> > ___
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-le...@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/BRVIF7HDKQ3KRRSBLNIETRUFINDOHIX3/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/4HKNJ65YUMIEF4ESQ45TV47DS5QKJNB7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/I4PCXJX45TNPQ3NUW6RYKXQTTXS4UU3M/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

2020-06-30 Thread Emily Bowman
I completely agree with this, that UTF-8 has become the One True
Encoding(tm), and UCS-2 and UTF-16 are hardly found anywhere outside of the
Win32 API. Nearly all basic emoji can't be represented in UCS-2 wchar_t,
let alone composite emoji.

So how to make that C-compatible? Make everything a void* and it just comes
back with as many bytes as it gets?

On Tue, Jun 30, 2020 at 5:22 AM Richard Damon 
wrote:

> On 6/30/20 7:53 AM, M.-A. Lemburg wrote:
> > Since the C world has adopted wchar_t for this purpose, it's the
> > natural choice.
>
> I would disagree with this comment. Microsoft Windows has chosen to use
> 'wchar_t' for Unicode, because they adopted UCS-2 before it morphed into
> UTF-16 due to the expansion of Unicode above 16 bits. The *nix side of
> the world has chosen to use UTF-8 as the preferred way to store Unicode
> characters.
>
> Also, in Windows, wchar_t doesn't really meet the requirements for what
> C defines wchar_t to mean, as wchar_t is supposed to represent every
> character as a single unit, and thus would need to be at least a 21 bit
> type (typically, it would be a 32 bit type), but Windows makes it a 16
> bit type due to ABIs being locked before the Unicode expansion.
>
> --
> Richard Damon
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/TA2ITVZY6ZGH2Y42JAXD243RSG7MONTV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KHFCEVSMTF6LIJAKHCAKTYAYWU6JEBNB/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 620: Hide implementation details from the C API

2020-06-30 Thread Petr Viktorin

On 2020-06-30 02:46, Victor Stinner wrote:

You missed the point of the PEP: "It becomes possible to experiment
with more advanced optimizations in CPython than just
micro-optimizations, like tagged pointers."


I don't think experiments are a good motivation.

When the C API is broken, everyone that uses it pays the price -- they 
have to update their code. They pay the price even if the experiment 
fails, or if it's never started in the first place.


Can we treat the C API not as a place for experiments, but as a stable 
foundation to build on?


For example, could we only deprecate the bad parts, but not remove them 
until the experiments actually show that they are preventing a 
beneficial change?


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


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Ethan Furman

On 06/30/2020 05:03 AM, Łukasz Langa wrote:



On 30 Jun 2020, at 12:44, Ethan Furman mailto:et...@stoneleaf.us>> wrote:

Of course I don't know if Keara or Guido knew any of this, but it certainly feels to me that 
the commit message is ostracizing an entire family line because they had the misfortune to 
have the wrong last name.  In fact, it seems like Strunk & White is making changes to be 
inclusive in its advice -- exactly what I would have thought we wanted on our side ("our 
side" being the diverse and welcoming side).


In any case, saying that Keara and Guido mistook the family name of one of the 
authors for skin color feels derogatory.


My apologies, that was not my intent.  As I said, I never knew what it was 
until today (er, yesterday now).


The commit message clearly is controversial but when you say the change itself was 
unnecessary, consider that English is now a language predominantly used outside of 
USA and Great Britain. Relaxing the recommendation to use S & L Standard 
English in the CPython codebase isn't problematic in this sense. That 
recommendation was largely ignored anyway, as core developer voices in the other 
threads already admitted. So, chaos won't ensue. We still want to maintain 
consistency, as PEP 8 recommends. I don't think you have to worry now about seeing 
organization and organisation in the same docstring.


Well, that wouldn't bother me -- as often as not I use non-US-English 
spellings; I just appreciate if it's a correct spelling /somewhere/.


That's what it felt like:  betrayal.


This entire section of your message is confusing to me. Mind explaining? How 
does a commit message equate stabbing somebody who helped you? What is being 
betrayed in this commit?


The original request for the change had absolutely no hint that the current 
text was racist in any way; then we find out that, apparently, we've been 
harboring white supremacist ideals by prescribing when to use apostrophes and 
commas?  That commit message (not the commit itself) took what should have been 
a simple change and turned into a platform for political grandstanding of the 
worst kind:

- False, as far as I can tell (until given confirming examples from the S&W 
text)
- Only colored people are mentioned (and other /native English speakers/)
- Zero mention of non-native English speakers

Basically, it feels like we were lied to.  And if that wasn't bad enough, to 
see that Guido accepted that vitriolic commit message and merged it in ... it 
makes me embarrassed to be a Python supporter.

--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/T55AGV7XPQ7YHU2VFIBHAWUZHEMZ43R3/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

2020-06-30 Thread Rhodri James

On 30/06/2020 13:16, Richard Damon wrote:

On 6/30/20 7:53 AM, M.-A. Lemburg wrote:

Since the C world has adopted wchar_t for this purpose, it's the
natural choice.


I would disagree with this comment. Microsoft Windows has chosen to use
'wchar_t' for Unicode, because they adopted UCS-2 before it morphed into
UTF-16 due to the expansion of Unicode above 16 bits. The *nix side of
the world has chosen to use UTF-8 as the preferred way to store Unicode
characters.

Also, in Windows, wchar_t doesn't really meet the requirements for what
C defines wchar_t to mean, as wchar_t is supposed to represent every
character as a single unit, and thus would need to be at least a 21 bit
type (typically, it would be a 32 bit type), but Windows makes it a 16
bit type due to ABIs being locked before the Unicode expansion.


Seconded.  I've had to do cross-platform (Linux and Windows)* unicode 
work in C.  Using wchar_t was eventually rejected as infeasible.


* Sorry, I had a Blues Brothers moment.

--
Rhodri James *-* Kynesim Ltd
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Y5SZNQYUULRY75CVHV34CSQTUI2FBUZ6/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Charalampos Stratakis



- Original Message -
> From: "Ethan Furman" 
> To: "Python Development List" 
> Cc: "Keara Berlin" 
> Sent: Tuesday, June 30, 2020 12:44:33 PM
> Subject: [Python-Dev] Recent PEP-8 change
> 
> On 06/29/2020 08:13 AM, Keara Berlin wrote:
> 
> > Hi all, I didn't mean for there to be significant differences between what
> > I posted here versus in the commit message. Sorry for any confusion around
> > that! Thank you for putting them both in one place here - that is helpful.
> 
> To be clear, the proposed change:
> 
> > "When writing English, ensure that your comments are clear and easily
> > understandable to other English speakers."
> 
> And the commit message:
> 
> > Instead of requiring that comments be written in Strunk & White Standard
> > English, require instead that English-language comments be clear and
> > easily understandable by other English speakers. This accomplishes the
> > same goal without upholding relics of white supremacy. Many native English
> > speakers do not use Standard English as their native dialect, so requiring
> > conformation to Standard English centers whiteness in an inappropriate and
> > unnecessary way, and can alienate and put up barriers for people of color
> > and those whose native dialect of English is not Standard English. This
> > change is a simple way to correct that while maintaining the original
> > intent of the requirement.
> 
> I find it difficult to express my horror and outrage with this commit
> message, but let me try:  Picture this scene from a movie I watched a long
> time ago: towards the end of the US Civil War a small band of deserters
> approach a large home; only one man, his wife, and their baby are home as
> the man's father and brothers have left to run errands.  The leader of the
> small band approaches the man and asks for water.  The man, happily and
> cheerfully, obliges and draws a bucket of fresh well water for them.  When
> he turns around to give them the bucket of water, the leader runs him
> through with his saber (stabs him in his guts all the way to the hilt).
> 
> That's what it felt like:  betrayal.
> 
> Before the PEP-8 amendment thread I thought Strunk & White was some popular
> culture reference, and as such I had no interest in it.  However, given the
> brouhaha that ensued I did some digging to discover for myself what it was.
> Here is what I have found:
> 
> - it has had at least four editions thus far
> - it has been modernized as times have changed (the 2000 edition removed the
> advice
>to use masculine pronouns whenever possible, and warns that some will find
>unnecessary
>masculine usage offensive)
> - its advice is hotly debated amongst linguists (not surprising)
> 
> and perhaps the most relevant:
> 
> - White is the last name of the second author.
> 
> Of course I don't know if Keara or Guido knew any of this, but it certainly
> feels to me that the commit message is ostracizing an entire family line
> because they had the misfortune to have the wrong last name.  In fact, it
> seems like Strunk & White is making changes to be inclusive in its advice --
> exactly what I would have thought we wanted on our side ("our side" being
> the diverse and welcoming side).
> 
> According to whichever dictionary Google uses, white supremacy is:
> 
> > noun
> > the belief that white people are superior to those of all other races,
> > especially the black race, and should therefore dominate society.
> 
> Does Keara, Guido, or anyone, have any such examples from Strunk & White?
> 
> Finally, what's wrong with having a standard?  Communication, especially in
> written form, is difficult enough without everyone using whatever
> style/grammar/colloquialisms happen to suit their fancy at the time.  As a
> silly example:  when I started using Python having the first parameter of a
> class method be `self` irked me, so I used `yo` instead (Spanish word for
> "I") -- it was shorter, and it tickled my fancy.  Two years into using
> Python and I replaced every instance of `yo` in my libraries to `self`; the
> cognitive dissonance between my code and everyone else's was an unnecessary
> distraction.
> 
> Speaking of unnecessary, I think the change to PEP-8 was unnecessary.  I
> think it was pushed through without any consideration for those against it,
> and I think the commit message was extremely offensive.
> 
> To hopefully stave off some attacks against me:
> 
> - I am not white
> - I am not Ivy League educated
> - Black lives do matter
> - Police are terrifying
> 
> --
> ~Ethan~
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/PJPZBLXM3ERJP66O5IEZYLRSBDN66HI5/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 

Without having followed the 

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

2020-06-30 Thread Steven D'Aprano
It needs to be pointed out that Thomas Wouters was recently re-elected 
to the PSF board. I think we need to know whether Thomas speaks for the 
entire PSF board.Giampaolo feared this:

"It's gonna happen again and again, until everybody gets in line, shuts
up or leaves due to exhaustion."

and Thomas replied:

"I'm not sure how much more clear python-dev and the PSF could have been
that this is true."

So is it true? Do the core devs and the PSF have a policy of 
pushing divisive political changes to silence and force out of the 
community people who are guilty of thought-crime and holding the wrong 
opinion on political matters?

I think that Thomas' post violated the CoC:

* not open, considerate, or respectful;

* dismissive of Giampaolo's efforts;

* not respectful of differing viewpoints;

* lacking empathy towards others with alternative perspectives.

The CoC doesn't mention the word "tolerant" or "tolerance", but there 
was nothing of either in Thomas' post. And coming from a PSF Board 
member, I think that is extremely worrying.


Steven



On Tue, Jun 30, 2020 at 12:42:40PM +0200, Antoine Pitrou wrote:
> On Tue, 30 Jun 2020 11:52:52 +0200
> Thomas Wouters  wrote:
> > 
> > I'm not sure who 'our' is in this sentence, but I'm certainly not glad
> > Python ever took any of your patches.
> 
> Really?
> 
> You know, I don't care (and few people probably care) what you think
> personally of other core developers.  But that you aren't even able to
> keep those thoughts for yourself and instead think it's ok to launch
> vitriolic attacks publicly, doesn't reflect very well on you.
> 
> Personally, I'm glad Giampaolo contributes to the project, as well as
> to the community (psutil is invaluable).  And I think you should just
> police yourself instead of attacking him personally.
> 
> > We want to be more welcoming, not less --
> 
> But do you *personally*? You certainly do not sound like you want to be
> "more welcoming".  Your belliquous attitude doesn't support that.  You
> sound like you have an axe to grind.
> 
> If your stated intentions are contradicted by your own behaviour,
> you're doing it wrong.
> 
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/BRVIF7HDKQ3KRRSBLNIETRUFINDOHIX3/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4HKNJ65YUMIEF4ESQ45TV47DS5QKJNB7/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

2020-06-30 Thread Richard Damon
On 6/30/20 7:53 AM, M.-A. Lemburg wrote:
> Since the C world has adopted wchar_t for this purpose, it's the
> natural choice.

I would disagree with this comment. Microsoft Windows has chosen to use
'wchar_t' for Unicode, because they adopted UCS-2 before it morphed into
UTF-16 due to the expansion of Unicode above 16 bits. The *nix side of
the world has chosen to use UTF-8 as the preferred way to store Unicode
characters.

Also, in Windows, wchar_t doesn't really meet the requirements for what
C defines wchar_t to mean, as wchar_t is supposed to represent every
character as a single unit, and thus would need to be at least a 21 bit
type (typically, it would be a 32 bit type), but Windows makes it a 16
bit type due to ABIs being locked before the Unicode expansion.

-- 
Richard Damon
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TA2ITVZY6ZGH2Y42JAXD243RSG7MONTV/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Recent PEP-8 change

2020-06-30 Thread Łukasz Langa

> On 30 Jun 2020, at 12:44, Ethan Furman  wrote:
> 
> Of course I don't know if Keara or Guido knew any of this, but it certainly 
> feels to me that the commit message is ostracizing an entire family line 
> because they had the misfortune to have the wrong last name.  In fact, it 
> seems like Strunk & White is making changes to be inclusive in its advice -- 
> exactly what I would have thought we wanted on our side ("our side" being the 
> diverse and welcoming side).

The claim in the commit message that the Strunk & White style contains relics 
of white supremacy might be fair or it might be overblown. I don't know, I'm 
not an expert. Your research on the updated editions and evolving advice looks 
good. (Just note that the most popular edition for people to find is very old 
because it's in the public domain.) In any case, saying that Keara and Guido 
mistook the family name of one of the authors for skin color feels derogatory.

The commit message clearly is controversial but when you say the change itself 
was unnecessary, consider that English is now a language predominantly used 
outside of USA and Great Britain. Relaxing the recommendation to use S & L 
Standard English in the CPython codebase isn't problematic in this sense. That 
recommendation was largely ignored anyway, as core developer voices in the 
other threads already admitted. So, chaos won't ensue. We still want to 
maintain consistency, as PEP 8 recommends. I don't think you have to worry now 
about seeing organization and organisation in the same docstring.


> That's what it felt like:  betrayal.

This entire section of your message is confusing to me. Mind explaining? How 
does a commit message equate stabbing somebody who helped you? What is being 
betrayed in this commit?

- Ł

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


[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

2020-06-30 Thread M.-A. Lemburg
On 29.06.2020 11:57, Victor Stinner wrote:
> Le dim. 28 juin 2020 à 11:22, M.-A. Lemburg  a écrit :
>> as you may remember, I wasn't happy with the deprecations of the
>> APIs in PEP 393, since there are no C API alternatives for
>> the encoding APIs deprecated in the PEP, which allow direct
>> encoding provided by these important codecs.
>>
>> AFAIK, the situation hasn't changed since then.
> 
> I would prefer to analyze the list on a case by case basis. I don't
> think that it's useful to expose every single encoding supported by
> Python as a C function.

I designed the Unicode C API as a rich API, so that it's easy
to use from C extensions and the interpreter as well.

The main theme was to have symmetric API for both encoding and
decoding. The PEP now suggests to remove the API on the basis of
deprecating Py_UNICODE, which is a change in data type.

This does not mean we have to give up the symmetry in the C API,
or that the encoding APIs are now suddenly useless. It only means
that we have to replace Py_UNICODE with one of the supported data
for storing Unicode.

Since the C world has adopted wchar_t for this purpose, it's the
natural choice.

> I would prefer to only have a fast-path for the most common encodings:
> ASCII, Latin1, UTF-8, Windows ANSI code page. That's all.
> 
> For any other encodings, the general PyUnicode_AsEncodedString() and
> PyUnicode_Decode() function are good enough.

PyUnicode_AsEncodedString() converts Unicode objects to a
bytes object. This is not an symmetric replacement for the
PyUnicode_Encode*() APIs, since those go from Py_UNICODE to
a bytes object.

> If someone expects an overhead of passing a string, please prove it
> with a benchmark. But IMO a small overhead is acceptable for rare
> encodings.
> 
> Note: PyUnicode_AsEncodedString() and PyUnicode_Decode() also have
> "fast paths" for most common encodings: ASCII, UTF-8, "mbcs" (Python
> alias of the Windows ANSI code page), Latin1. But also UTF-16 and
> UTF-32: I'm not if it's really worth it to have these ones, but it was
> cheap to have them :-)
> 
> 
>> We can't just remove access to one half of a codec (the decoding
>> part) without at least providing an alternative for C extensions

Sorry, I meant the "encoding part".

>> to use.
> 
> I disagree, we can. The alternative exists since Python 2:
> PyUnicode_AsEncodedString() and PyUnicode_Decode().

See above.

If we remove the direct encoding/decoding C APIs we should at the
very least provide generic alternatives which can be used as drop-in
replacement for the PyUnicde_Encode*() APIs.

>> Given PEP 393, this would be APIs which use wchar_t instead of
>> Py_UNICODE.
> 
> Using wchar_t is inefficient on all platforms using 16-bit wchar_t
> since surrogate pairs need a special code path. For example,
> PyUnicode_FromWideChar() has to scan the string twice: the first time
> to count the number of surrogate pairs, to allocate the exact buffer
> size.

If you want full UCS4 compatibility, that's true, but those platforms
suffer from this deficiency platform wide, so Python is in no way
special.

The main point is that wchar_t is the standard in C to represent
Unicode code points, so it's a natural choice as replacement for
Py_UNICODE.

Since the C API is not only meant to be used by the CPython interpreter,
we should stick to standards rather than expecting the world to adapt
to our implementations. This also makes the APIs future proof, e.g.
in case we make another transition from the current hybrid internal
data type for Unicode towards UTF-8 buffers as internal data type.

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts
>>> 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-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XWYHZK6LPAM2MV3E7AXGKZSIPJ43MMFX/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

2020-06-30 Thread Giampaolo Rodola'
On Tue, Jun 30, 2020 at 11:53 AM Thomas Wouters  wrote:
> On Tue, Jun 30, 2020 at 4:28 AM Giampaolo Rodola'  wrote:
>>
>> This is not about the commit message. It’s way more than that. It's been 
>> going on non-stop and got increasingly worse since at least the preparation 
>> of the Python elections ~2 years ago. It is not normal what is going on 
>> here. People are scared. And it is pretty much guaranteed that this is not 
>> gonna be the last occurrence of it. On the horizon we have other 
>> language-related controversies like "whitelist" / "blacklist", renaming 
>> "master" to "main" in GIT, and who knows what else (maybe "whitespace"? or 
>> @property?).
>
>
> I don't have words for the irony of complaining about changing words while 
> objecting to the wording in a commit message.

They are two different things.
One thing is changing some words to make a concept more clear. I said
I agree with it.
Another thing is using that as an excuse to deliver a political
message. That I don't agree with.
I'm tired of it. I'm literally overwhelmed by it. I open Twitter and I
see politics. I open Facebook and I see politics. That's fine. But why
should I see politics also here? I don't know.

>> And every time that's gonna happen the motivation is gonna be about white 
>> supremacy/privilege/guilt etc. Because it's always about that, and we'll be 
>> having this discussion once again. On one hand Python gladly takes our 
>> patches and everything is smooth,
>
>
> I'm not sure who 'our' is in this sentence, but I'm certainly not glad Python 
> ever took any of your patches. No contribution to Python outweighs the harm 
> you're doing by espousing and advocating for these views. This kind of 
> sentiment scares away a lot of valuable contributors -- I know this because 
> *they have told me* --

I can say exactly the same thing. There are different people in this
thread and other threads who publicly said they are uncomfortable with
this situation. They don't espouse or advocate for any view in
particular. And me neither, because complaining about X doesn't
necessarily mean wanting to push for Y. I don't want to push for X nor
Y. And I don't want to be put in a situation where I am forced to
advocate for X or Y, or be vilified if I don't agree with X as it
happens here. It's just not the right place because it's too close to
the personal sphere (work, etc.). Some texted me privately exactly as
they did with you, because they are afraid of repercussions in that
regard (work). Others posted anonymously for the same reason. Does
that seem normal, sane or "welcoming" to you? Do you think it's
helping anybody anywhere? It is not. It is not me who's doing this *in
the least*. I'm merely calling it out.

>> on the other hand it wants us to not only accept "this" and be quiet, but 
>> also to take a stand and be an ally in the battle against the vocabulary "or 
>> else". So what's the point of contributing if the emotional distress and the 
>> risk that comes with it are so high?
>
>
> This is exactly why we want you to stop, yes. You're causing a lot of 
> emotional distress in people, and putting people at risk. You're even causing 
> it in people *in your purported demographic*, like me, let alone the people 
> you're trying to disadvantage. Stop it.

I'm not putting anybody at risk except myself.

>> In the previous discussion preceding this one where one PSF member left 
>> because it all got so political, somebody posted anonymously (and gently) 
>> for fear of repercussions. The same fear has been expressed in this thread. 
>> In the other thread it has even been suggested that "being silent re. > cause>" == "being complicit". I mean, are you serious? I explicitly avoided 
>> to comment on that because I didn't even know where to begin to explain how 
>> profoundly wrong that is on so many different levels. How irrespectful it is 
>> to ask people who just want to contribute some code here to take precise 
>> political sides or be damned if they don't. How unfair it is to do that 
>> especially towards old-time contributors. And now I even have to hope some 
>> moderator will be reasonable enough not to mark my emails as "white 
>> suprematism" (LOL) and send them through. This is just ridiculous. I've 
>> never been pro-CoC, but even if I were, this is what the enforcement part of 
>> the CoC dictates:
>>
>> > https://www.python.org/psf/conduct/enforcement/
>> > Reports that are not made in good faith (such as "reverse sexism" or 
>> > "reverse racism") may receive no response.
>>
>> ...so even the CoC won't help. So this is why this problem is more profound 
>> than a simple commit message. It's gonna happen again and again, until 
>> everybody gets in line, shuts up or leaves due to exhaustion.
>
>
> I'm not sure how much more clear python-dev and the PSF could have been that 
> this is true. Your complaints of "racism against whites" here haven't gone 
> unheard, unfortunately. They reflect very badly on you.

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

2020-06-30 Thread Kyle Stanley
I tend to keep out of these types of discussions because they have a
tendency to be rather polarizing, and when introduced in an unrelated
environment (such as python-ideas or python-dev), tend to do nothing other
than set people against each other. But, after the above message, I feel
obligated to respond. Also, keep in mind that I'm stating this as someone
who fully agreed with the change made (as mentioned earlier in the thread).

Thomas Wouters wrote:
> I'm not sure who 'our' is in this sentence, but I'm certainly not glad
Python ever took any of your patches

Regardless of thoughts on the above matter, this is absolutely uncalled for
Thomas, especially coming from someone who has served on the PSF board and
was elected for the upcoming term. As someone who voted for you in the
recent election thinking you would represent the core development team
well, the above statement does make me question that to some degree. I hope
this situation is an outlier, and not indicative of how problems will be
addressed in the future.

I for one greatly appreciate the contributions by Giampaolo. Our CI would
be nowhere near where it is today without his help, not to mention the
countless refleaks, bug fixes, and expertise provided on a vast number of
issues. I could go on, but quite frankly it's not especially relevant,
because I'd say the same for any other member of the core team or active
contributor.

I really can't imagine in any way how this statement isn't a clear
violation of the CoC (https://www.python.org/psf/conduct/).

> *Acknowledging time and effort*. We're respectful of the volunteer
efforts that permeate the Python community. We're thoughtful when
addressing the efforts of others, keeping in mind that often times the
labor was completed simply for the good of the community.

The statement completely disregards the time and effort put into
Giampaolo's contributions to Python.

> Showing empathy towards other community members. We're attentive in our
communications, whether in person or online, and *we're tactful when
approaching differing views*.

> *Being respectful.* We're respectful of others, their positions, their
skills, their commitments, and their efforts.

The statement is clearly not tactful or respectful of his differing
viewpoint.

> I'm not sure how much more clear python-dev and the PSF could have been
that this is true. Your complaints of "racism against whites" here haven't
gone unheard, unfortunately. They reflect very badly on you. They are
incredibly harmful to many python-dev members and the Python community as a
whole, and they reflect very badly on all of us.

I can see how the "racism against whites" argument could come across as
being non-inclusive towards others, particularly because these arguments
are often put forth by white supremacists for ill-intended purposes.
However, telling someone who has devoted countless hours towards
contributing to Python that "I'm certainly not glad Python ever took any of
your patches" is pretty much the exact opposite of a tactful way to
approach this issue. Even assuming that Giampolo's views are in violation
of the CoC (which I'm not saying they are or aren't), the way to handle it
is most certainly not also by violating the CoC against him.

If those views reflect badly on us, I think it reflects even worse on us
that we have to resort to telling people that their contributions are not
valued because they have a different point of view, even if that view is
offensive to others. Are we not capable of having this discussion in a
civil manner? I realize that this is a topic that is dear to many people
(including myself, as someone who is politically progressive), but that
does not make this sort of exchange acceptable.



On Tue, Jun 30, 2020 at 5:59 AM Thomas Wouters  wrote:

>
>
> On Tue, Jun 30, 2020 at 4:28 AM Giampaolo Rodola' 
> wrote:
>
>> This is not about the commit message. It’s way more than that. It's been
>> going on non-stop and got increasingly worse since at least the preparation
>> of the Python elections ~2 years ago. It is not normal what is going on
>> here. People are scared. And it is pretty much guaranteed that this is not
>> gonna be the last occurrence of it. On the horizon we have other
>> language-related controversies like "whitelist" / "blacklist", renaming
>> "master" to "main" in GIT, and who knows what else (maybe "whitespace"? or
>> @property?).
>>
>
> I don't have words for the irony of complaining about changing words while
> objecting to the wording in a commit message. Especially considering the
> commit message isn't nearly as visible as the places that people have
> actually been fixing things like master/slave.
>
>
>> And every time that's gonna happen the motivation is gonna be about white
>> supremacy/privilege/guilt etc. Because it's always about that, and we'll be
>> having this discussion once again. On one hand Python gladly takes our
>> patches and everything is smooth,
>>
>
> I'm not sure who 'our'

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

2020-06-30 Thread Edwin Zimmerman


On 6/30/2020 5:52 AM, Thomas Wouters wrote:
>
>
> On Tue, Jun 30, 2020 at 4:28 AM Giampaolo Rodola'  > wrote:
>
> This is not about the commit message. It’s way more than that. It's been 
> going on non-stop and got increasingly worse since at least the preparation 
> of the Python elections ~2 years ago. It is not normal what is going on here. 
> People are scared. And it is pretty much guaranteed that this is not gonna be 
> the last occurrence of it. On the horizon we have other language-related 
> controversies like "whitelist" / "blacklist", renaming "master" to "main" in 
> GIT, and who knows what else (maybe "whitespace"? or @property?).
>
>
> I don't have words for the irony of complaining about changing words while 
> objecting to the wording in a commit message. Especially considering the 
> commit message isn't nearly as visible as the places that people have 
> actually been fixing things like master/slave.
>  
>
> And every time that's gonna happen the motivation is gonna be about white 
> supremacy/privilege/guilt etc. Because it's always about that, and we'll be 
> having this discussion once again. On one hand Python gladly takes our 
> patches and everything is smooth,
>
>
> I'm not sure who 'our' is in this sentence, but I'm certainly not glad Python 
> ever took any of your patches. No contribution to Python outweighs the harm 
> you're doing by espousing and advocating for these views. This kind of 
> sentiment scares away a lot of valuable contributors -- I know this because 
> *they have told me* -- and that you're doing it while arguing against a 
> change to a different (unintentional but still harmful) gatekeeping mechanism 
> just makes it so much worse.
Note to self:  It's kind of hard to convince the opposition to take an honest 
look at my viewpoint when I start by attacking them personally.

To everyone else:  I saw this flame war coming the minute I read the original 
post.  Unfortunately, it seems no longer possible to discuss this subject in 
any reasonable way.  Everyone seems to have forgotten that you can attack an 
idea without attacking the person presenting it.  Moderators, please, can this 
thread just be stopped?

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


[Python-Dev] Recent PEP-8 change

2020-06-30 Thread Ethan Furman

On 06/29/2020 08:13 AM, Keara Berlin wrote:


Hi all, I didn't mean for there to be significant differences between what I 
posted here versus in the commit message. Sorry for any confusion around that! 
Thank you for putting them both in one place here - that is helpful.


To be clear, the proposed change:


"When writing English, ensure that your comments are clear and easily understandable 
to other English speakers."


And the commit message:


Instead of requiring that comments be written in Strunk & White Standard 
English, require instead that English-language comments be clear and easily 
understandable by other English speakers. This accomplishes the same goal without 
upholding relics of white supremacy. Many native English speakers do not use 
Standard English as their native dialect, so requiring conformation to Standard 
English centers whiteness in an inappropriate and unnecessary way, and can alienate 
and put up barriers for people of color and those whose native dialect of English 
is not Standard English. This change is a simple way to correct that while 
maintaining the original intent of the requirement.


I find it difficult to express my horror and outrage with this commit message, 
but let me try:  Picture this scene from a movie I watched a long time ago: 
towards the end of the US Civil War a small band of deserters approach a large 
home; only one man, his wife, and their baby are home as the man's father and 
brothers have left to run errands.  The leader of the small band approaches the 
man and asks for water.  The man, happily and cheerfully, obliges and draws a 
bucket of fresh well water for them.  When he turns around to give them the 
bucket of water, the leader runs him through with his saber (stabs him in his 
guts all the way to the hilt).

That's what it felt like:  betrayal.

Before the PEP-8 amendment thread I thought Strunk & White was some popular 
culture reference, and as such I had no interest in it.  However, given the 
brouhaha that ensued I did some digging to discover for myself what it was.  Here 
is what I have found:

- it has had at least four editions thus far
- it has been modernized as times have changed (the 2000 edition removed the 
advice
  to use masculine pronouns whenever possible, and warns that some will find 
unnecessary
  masculine usage offensive)
- its advice is hotly debated amongst linguists (not surprising)

and perhaps the most relevant:

- White is the last name of the second author.

Of course I don't know if Keara or Guido knew any of this, but it certainly feels to me that 
the commit message is ostracizing an entire family line because they had the misfortune to 
have the wrong last name.  In fact, it seems like Strunk & White is making changes to be 
inclusive in its advice -- exactly what I would have thought we wanted on our side ("our 
side" being the diverse and welcoming side).

According to whichever dictionary Google uses, white supremacy is:


noun
the belief that white people are superior to those of all other races, 
especially the black race, and should therefore dominate society.


Does Keara, Guido, or anyone, have any such examples from Strunk & White?

Finally, what's wrong with having a standard?  Communication, especially in written form, 
is difficult enough without everyone using whatever style/grammar/colloquialisms happen 
to suit their fancy at the time.  As a silly example:  when I started using Python having 
the first parameter of a class method be `self` irked me, so I used `yo` instead (Spanish 
word for "I") -- it was shorter, and it tickled my fancy.  Two years into using 
Python and I replaced every instance of `yo` in my libraries to `self`; the cognitive 
dissonance between my code and everyone else's was an unnecessary distraction.

Speaking of unnecessary, I think the change to PEP-8 was unnecessary.  I think 
it was pushed through without any consideration for those against it, and I 
think the commit message was extremely offensive.

To hopefully stave off some attacks against me:

- I am not white
- I am not Ivy League educated
- Black lives do matter
- Police are terrifying

--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PJPZBLXM3ERJP66O5IEZYLRSBDN66HI5/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

2020-06-30 Thread Antoine Pitrou
On Tue, 30 Jun 2020 11:52:52 +0200
Thomas Wouters  wrote:
> 
> I'm not sure who 'our' is in this sentence, but I'm certainly not glad
> Python ever took any of your patches.

Really?

You know, I don't care (and few people probably care) what you think
personally of other core developers.  But that you aren't even able to
keep those thoughts for yourself and instead think it's ok to launch
vitriolic attacks publicly, doesn't reflect very well on you.

Personally, I'm glad Giampaolo contributes to the project, as well as
to the community (psutil is invaluable).  And I think you should just
police yourself instead of attacking him personally.

> We want to be more welcoming, not less --

But do you *personally*? You certainly do not sound like you want to be
"more welcoming".  Your belliquous attitude doesn't support that.  You
sound like you have an axe to grind.

If your stated intentions are contradicted by your own behaviour,
you're doing it wrong.


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


[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

2020-06-30 Thread Rhodri James

On 30/06/2020 10:52, Thomas Wouters wrote:

I don't have words for the irony of complaining about changing words while
objecting to the wording in a commit message. Especially considering the
commit message isn't nearly as visible as the places that people have
actually been fixing things like master/slave.


I'm sorry, I was a little deafened by the irony that it's only wrong to 
complain about changes you agree with.


The commit was over-hasty, but that's not a crime.  It improves matters 
for those who find the idea of writing formal English daunting, but at 
the expense of those who find the idea of filling a blank box with words 
terrifying.  A little more thought could have catered for both, but it's 
not the end of the world.  With a sufficient supply of round tuits I can 
always submit a PR myself.


The commit message is a political message that flatly does not belong in 
the repository.


Do you see the difference?

I really wish you hadn't brought up the master/slave debacle again.  I 
may feel obliged to submit PRs to restore the accepted usage because, 
and I can't believe I have to keep saying this, *creating taboos only 
ever makes things worse.*


--
Rhodri James *-* Kynesim Ltd
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/H3NRQMSKAMC7HO4WZB4WF7VYO7CLJ54I/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Lists placed into Emergency Moderation status

2020-06-30 Thread Thomas Wouters
On Mon, Jun 29, 2020 at 10:56 PM Tim Peters  wrote:

> [Ernest W. Durbin III ]
> > Reviewing, I may have misinterpreted the message from PSF Executive
> > Director regarding the situation.
> >
> > It does appear that python-ideas moderators contacted postmaster@.
> > Appears I misread a message saying “it looks like it’s happening on
> > python-dev too” to mean that the request was for both lists.
> >
> > Should I disable moderation on python-dev?
>
> It depends on who you want to annoy least ;-)
>
> If it's the position of the PSF that some kind(s) of messages must be
> suppressed, then I'll need a more-or-less clear definition, from them,
> of what those consist of.  At which point I'll agree to enforce them,
> or step down as a python-dev moderator.
>

Just to clarify: this had nothing to do with the PSF, but with the Steering
Council and the python-ideas moderators. We were discussing the PEP-8
"controversy" last night, after Titus (one of the python-ideas moderators)
asked about putting *that* list in full moderation, and we talked about how
the discussion had bled over into python-dev. We weren't clear among
ourselves which lists we were talking about anymore when we asked Ernest to
see about emergency moderation mode (which wasn't as easy as we would've
expected), which is why Ernest did it for both lists. We should've been
more careful about this, and looped in the python-dev moderators straight
away. Sorry about that.



>
> Otherwise, as I said, I've seen nothing on python-dev so far that I
> would have rejected.  So all "emergency moderation status" is doing
> for python-dev so far is annoying me with more email to go approve
> messages waiting in the queue, and to annoy those messages' senders
> with delays (waiting for moderator action).
>
> So it's not, in reality, accomplishing anything of value here.  So, if
> I were you, I'd disable emergency moderation status on python-dev.
> But then I'm old, retired, and notoriously pig-headed ;-)
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/LZVR6SLZN4LCGD4SC4BCVHKMUH6GKA6D/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HCEL5YDRSKFHSAHATGDE7OQS44Y4XEPC/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

2020-06-30 Thread Thomas Wouters
On Tue, Jun 30, 2020 at 4:28 AM Giampaolo Rodola' 
wrote:

> This is not about the commit message. It’s way more than that. It's been
> going on non-stop and got increasingly worse since at least the preparation
> of the Python elections ~2 years ago. It is not normal what is going on
> here. People are scared. And it is pretty much guaranteed that this is not
> gonna be the last occurrence of it. On the horizon we have other
> language-related controversies like "whitelist" / "blacklist", renaming
> "master" to "main" in GIT, and who knows what else (maybe "whitespace"? or
> @property?).
>

I don't have words for the irony of complaining about changing words while
objecting to the wording in a commit message. Especially considering the
commit message isn't nearly as visible as the places that people have
actually been fixing things like master/slave.


> And every time that's gonna happen the motivation is gonna be about white
> supremacy/privilege/guilt etc. Because it's always about that, and we'll be
> having this discussion once again. On one hand Python gladly takes our
> patches and everything is smooth,
>

I'm not sure who 'our' is in this sentence, but I'm certainly not glad
Python ever took any of your patches. No contribution to Python outweighs
the harm you're doing by espousing and advocating for these views. This
kind of sentiment scares away a lot of valuable contributors -- I know this
because *they have told me* -- and that you're doing it while arguing
against a change to a different (unintentional but still harmful)
gatekeeping mechanism just makes it so much worse.


> on the other hand it wants us to not only accept "this" and be quiet, but
> also to take a stand and be an ally in the battle against the vocabulary
> "or else". So what's the point of contributing if the emotional distress
> and the risk that comes with it are so high?
>

This is exactly why we want you to stop, yes. You're causing a lot of
emotional distress in people, and putting people at risk. You're even
causing it in people *in your purported demographic*, like me, let alone
the people you're trying to disadvantage. Stop it.


> In the previous discussion preceding this one where one PSF member left
> because it all got so political, somebody posted anonymously (and gently)
> for fear of repercussions. The same fear has been expressed in this thread.
> In the other thread it has even been suggested that "being silent re.  cause>" == "being complicit". I mean, are you serious? I explicitly avoided
> to comment on that because I didn't even know where to begin to explain how
> profoundly wrong that is on so many different levels. How irrespectful it
> is to ask people who just want to contribute some code here to take precise
> political sides or be damned if they don't. How unfair it is to do that
> especially towards old-time contributors. And now I even have to hope some
> moderator will be reasonable enough not to mark my emails as "white
> suprematism" (LOL) and send them through. This is just ridiculous. I've
> never been pro-CoC, but even if I were, this is what the enforcement part
> of the CoC dictates:
>
> > https://www.python.org/psf/conduct/enforcement/
> > Reports that are not made in good faith (such as "reverse sexism" or
> "reverse racism") may receive no response.
>
> ...so even the CoC won't help. So this is why this problem is more
> profound than a simple commit message. It's gonna happen again and again,
> until everybody gets in line, shuts up or leaves due to exhaustion.
>

I'm not sure how much more clear python-dev and the PSF could have been
that this is true. Your complaints of "racism against whites" here haven't
gone unheard, unfortunately. They reflect very badly on you. They are
incredibly harmful to many python-dev members and the Python community as a
whole, and they reflect very badly on all of us. The option you should take
is to learn how wrong you are in this. There are very, very many resources
online explaining why reverse racism isn't a thing, *even if* someone was
racist against you for being white (rather than judging you on your words
or actions, as I'm doing here). Nobody here is being racist against (cis,
het, etc) white males, even though we want to be *less* racist (and sexist,
ablist, etc.) against others. We want to be more welcoming, not less --
but not to people who make the community less welcoming. If you can't
accept this, please leave the community.



>
>
> On Mon, 29 Jun 2020 at 22:28, David Mertz  wrote:
>
>> Can we simply revise the commit message to something neutral like
>> "Removed specific reference to Strunk and White in favor of generic urge
>> for language clarity."
>>
>> That's all the change actually was; there's no need for the other debate
>> or broad political background.
>>
>> On Mon, Jun 29, 2020 at 3:28 PM Rhodri James 
>> wrote:
>>
>>> On 29/06/2020 17:24, Abdur-Rahmaan Janhangeer wrote:
>>> > Threads like these are meaningless, does not provi

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

2020-06-30 Thread Rhodri James

On 29/06/2020 21:40, Antoine Pitrou wrote:

IMHO, the fact that the "Strunk & White standard" is not known by
everybody (it's certainly not by me) was enough of a reason to remove
that wording and replace it with a clearer phrasing.


Or perhaps to amplify on why something like S&W is a good guide (and not 
a standard) in how to write formal English?  If you aren't interested in 
the nuts and bolts of the English language there's no reason for you to 
know of Strunk and White, the Chicago Manual of Style or any of a number 
of other similar books on the subject.  They are all useful to someone 
who intends to write much, though.


--
Rhodri James *-* Kynesim Ltd
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZW67TJBA4Q6OQWTY6CO7JVRNQZRAD2WF/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 620: Hide implementation details from the C API

2020-06-30 Thread Antoine Pitrou
On Mon, 29 Jun 2020 23:31:31 -0700
Emily Bowman  wrote:
> On Mon, Jun 29, 2020 at 7:41 PM Raymond Hettinger <
> raymond.hettin...@gmail.com> wrote:  
> 
> > Perhaps you don't want to believe the results, but the timings are
> > careful, stable, repeatable, and backed-up by a disassembly that shows the
> > exact cause.  The builds used for the timings were the production macOS
> > builds as distributed on python.org.
> >  
> 
> This points more to specific builds needing to be fixed, if their build
> options result in significantly un-optimized code on the same cpu
> architecture.

I agree in this specific instance _PyType_GetFlags() should definitely
get inlined.  The whole point of the type check flags is to make
instance checks for built-in types such as long or tuple faster than by
the regular algorithm.

Regards

Antoine.

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