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

[Stephen J. Turnbull]

Richard Damon writes:

 > I wasn't imply local to the match statement, but if the match is used
 > inside a function, where using the binding operatior = will create a
 > local name, even if there is a corresponding global name that matches
 > (unless you use the global statement), will a match statement that binds
 > to a name that hasn't bee made a local name by having an explicit
 > assignment to it, actually bind to a global that might be present, or
 > will it create a local?

All names are global, in some relevent sense.  It's the bindings to
objects that are scoped, and a binding in an inner scope shadows that
of an outer scope.  This just works, as I'm sure you've experienced.
In this case, the match statement will create a binding in the current
scope (in the case you present, local scope for that function).  The
problem for internationalization is not your example:

 >     match baz:
 > 
 >     case 1: print('baz was one')
 > 
 >     case foo: print('baz was ', foo)

but this kind of situation:

match baz:
case 1: print(_('baz was one'))
case _: print(_('baz was '), _(foo))

where _() marks a string that should be translated to another
language, and also implements the lookup at runtime.  If "case _"
binds "_", the _() in the print statement in that arm of the match
will very likely raise, and later _() will as well, until the end of
the scope.  It's very unlikely it will do what's desired!

Do translatable strings have to be marked with _()?  In theory, no, in
fact "_" is an alias for the gettext function, which could also be
used.  But in practice the marking aspect is used by a wide variety of
translation support software searching for strings to translate, and
it's also important to the readability of strings in the source that
the mark be as lightweight as possible.  So for internationalization
it's useful that "case _" does not bind an object to the name "_".

It's a very special case, and it's fortunate that it works out this
way that there's no conflict between the two uses of "_".  Or maybe
Lady Fortune is Dutch. :-)

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

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

[Stephen J. Turnbull]

Daniel. writes:

 > IMHO, the most obvious solution is that the bind should be available only
 > inside case block and if you need to change a global or a nonlocal you do
 > this explicitly inside the case block,

Do you mean

case x:
x = x

?

 > if this is the case you can pickup a bind name that doesn't shadow
 > the desired variable.

But you can already do that in the case clause itself.

 > This way the intention to overwrite a global/nonlocal is clear in
 > code

But you can't "overwrite" a global or nonlocal without a declaration.
You can only shadow it, and as I wrote above, if you want to avoid
shadowing that global or nonlocal you choose a different name in the
case clause.

Regarding the proposal itself, it's a major change, because that's not
the way binding works anywhere else in Python.  There are two
differences.  The first is that there are no statements besides class
and def that create scopes, and the other two scopes that I know of
are module and comprehension (I seem to recall that comprehension
scope is based on the idea that the code inside the brackets is
actually syntactic sugar for a generator def, so that special case
would be derivative of function scope).

The second difference is that you can't change the binding of a name
in an outer local scope without a nonlocal declaration.  That means if
case scope follows that rule and you want to have a binding inside the
case scope that persists outside it, you'd need to declare it.
Probably you don't want to have to declare those "external" names, so
the names bound by the case clause would be very special.  I haven't
thought carefully about it, but it seems to me this could be a bug
magnet.

So, you could do this, but it would make scoping much more complex
than it currently is, and require a lot of redundancy (every binding
you want to preserve for later use would need to be made twice, once
in the case clause and again in the case body).  And I don't think
it's that useful.  It doesn't help with the I18N problem, since you
might want to use a marked string in the "case _" suite.  And the main
complexity from the current scoping rules comes from the fact that it
seems likely that different arms of the match will bind different sets
of names, so NameErrors become more likely in the following code.  But
your proposal doesn't help with that, and may make it more likely by
proliferating names.

Regards,
Steve
___
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/YDEORTNVLYXHX72FJ6CWXGZZ7C32ECKV/
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

[Steve Holden]

It's broadly accepted among professional writers that the language used
should be acceptable and comprehensible to the audience. This seems
uncontentious.

Posting a straightforward change representing a relaxation of standards
(which were not in any case being enforced) should also be uncontentious.

The commit message used, however, reveals implementation details of the
change which are irrelevant to the stated aim, which is making the
documentation clear and concise. Use of such language is certainly
regrettable, since it carries with it the implication that the Python
developer community has somehow been wilfully sanctioning "relics of white
supremacy" up until the change was made.

There certainly is a place in tech for politics, as I have argued many
times, and I am sure nobody wishes to continue to use language that might
be offensive to readers. But I would suggest that the politics can safely
be omitted from commit messages, since they can only properly be fully
addressed in the conversation about the PR in advance. The wording of the
commit message has the appearance (probably specious) of wanting to rub
former misdeeds in the face of a largely innocent community, and that is
the principal reason I found it distasteful and unnecessary.

Kind regards,
Steve

PS: I also think there is still room for the PEP to remind writers that
many readers of the documentation who graciously allow us to use English
without complaint are using it as their second or even third language, and
all writers should be sympathetic to their needs as a matter of
professional courtesy.



On Sun, Jun 28, 2020 at 10:18 PM Paul Sokolovsky  wrote:

> Hello,
>
> Shouldn't such feedback be also cross-posted to the python-dev mailing
> list? Also note the original pull request,
> https://github.com/python/peps/pull/1470, and differences of what was
> written in the pull request description and what went in the commit
> message.
>
>
> On Sun, 28 Jun 2020 22:10:14 +0200
> "Giampaolo Rodola'"  wrote:
>
> > From:
> >
> https://github.com/python/peps/commit/0c6427dcec1e98ca0bd46a876a7219ee4a9347f4
> >
> > > 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.
> >
> > This has nothing to do with making the wording "clear and
> > understandable" (I agree on that). It's about, once again, bringing
> > race-based politics into Python, and spreading hate towards a
> > specific group of people: whites. Whether you're aware of it or not,
> > there is a term for this: it's racism. I want to remind everyone that
> > most of us here simply want to contribute code. We do it for free,
> > and don't want to be involved in "this", because frankly it's
> > disgusting. Doing something out of passion and for free, and at the
> > same time seeing these sorts of things happening on a regular basis,
> > looks and feels like an insult, and will only lead to people leaving
> > this place.
> >
> > On Fri, Jun 26, 2020 at 11:27 PM Keara Berlin 
> > wrote:
> >
> > > Hi all, this is a very small change, but I thought I would field it
> > > here to see if anyone has suggestions or ideas. Instead of
> > > requiring that comments be written in Strunk & White Standard
> > > English, PEP-8 should require instead that English-language
> > > comments be clear and easily understandable by other English
> > > speakers. This accomplishes the same goal without alienating or
> > > putting up barriers for people (especially people of color) 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. This change may even make the requirement more
> > > clear to people who are not familiar with Strunk & White, since for
> > > programmers, the main relevant aspect of that standard is "be clear
> > > and concise;" simply saying that instead of referencing Strunk &
> > > White may communicate this more effectively. Here is the current
> > > line in PEP-8: "When writing English, follow Strunk and White."
> > > I propose changing this line to "When writing English, ensure that
> > > your comments are clear and easily understandable to other English
> > > speakers." ___
> > > Python-ideas mailing list -- python-id...@python.org
> > > To unsubscribe send an email

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

[Victor Stinner]

Hi Stefan,

I'm interested in experimenting with a moving GC in CPython, but also
by modifying the C API to make sure that it is efficient on PyPy or
another Python implementation which uses a moving GC.

As Carl in the other thread, currently, other Python implementations
have to emulate PyObject** which is inefficient.

Right now, the C API is an exact mapping of CPython internals which
prevents us to enhance or optimize CPython, but also makes other
Python implementations inefficient when running C extensions.

Victor

Le ven. 26 juin 2020 à 23:37, Stefan Behnel  a écrit :
>
> Victor Stinner schrieb am 26.06.20 um 14:39:
> > Well, the general problem is to track when the caller ends using a resource.
>
> Although that is less of a problem if you only allow exposing the internal
> data representation and nothing else. In that case, you can tie the
> lifetime of the data access to the lifetime of the object.
>
> Minus moving GCs, as Carl also pointed out. But even there, you could get
> away (probably for quite a while) with pinning the data if someone asked
> for it.
>
> Stefan
> ___
> 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/NS5MTQFCD7TRZCXS4ZSI3PCPEA5OL6PJ/
> 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/XSSVMKWRWZETPKEJR5P4LGRABSQJ4MTC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Victor Stinner]

Le dim. 28 juin 2020 à 04:39, Inada Naoki  a écrit :
> ## Documented and have Py_DEPRECATED
>
> * PyLong_FromUnicode
> * PyUnicode_AsUnicodeCopy
> * PyUnicode_Encode
> * PyUnicode_EncodeUTF7
> * PyUnicode_EncodeUTF8
> * PyUnicode_EncodeUTF16
> * PyUnicode_EncodeUTF32
> * PyUnicode_EncodeUnicodeEscape
> * PyUnicode_EncodeRawUnicodeEscape
> * PyUnicode_EncodeLatin1
> * PyUnicode_EncodeASCII
> * PyUnicode_EncodeCharmap
> * PyUnicode_TranslateCharmap
> * PyUnicode_EncodeMBCS
>
> These APIs are documented.  The document has ``.. deprecated:: 3.3
> 4.0`` directive.
> They have been `Py_DEPRECATED` since Python 3.6 too.
>
> Plan: Change the document to ``.. deprecated:: 3.0 3.10`` and remove
> them in Python 3.10.

".. deprecated" markups are nice, but not easy to discover. I would
help to add a "Deprecated" section of C API Changes and list functions
scheduled for removal in the next Python version:
https://docs.python.org/dev/whatsnew/3.9.html#c-api-changes

I understand that these ".. deprecated" markups will be added to 3.8
and 3.9 documentation, right?

For each function, I would be nice to suggest a replacement function.
For example, PyUnicode_EncodeMBCS() (Py_UNICODE*) can be replaced with
PyUnicode_EncodeCodePage() using code_page=CP_ACP (PyObject*).


> ## PyUnicode_EncodeDecimal
>
> It is not documented.  It has not been deprecated by Py_DEPRECATED.
> Plan: Add Py_DEPRECATED in Python 3.9 and remove it in 3.11.

I understood that the replacement function is the private
_PyUnicode_TransformDecimalAndSpaceToASCII() function. This function
is used by complex, float and int types to convert a string into a
number.


> ## PyUnicode_TransformDecimalToASCII
>
> It is documented, but doesn't have ``deprecated`` directive. It is not
> deprecated by Py_DEPRECATED.
>
> Plan: Add Py_DEPRECATED and ``deprecated 3.3 3.11`` directive in 3.9,
> and remove it in 3.11.

I don't think that we need to expose such function as part of the
public C API. IMHO it only was exposed to be consumed by Python
itself. So I don't think that we need to provide a replacement
function.

After the function will be removed, if someone complains, we can
design a new replacement function. But I prefer to not *guess* what is
the exact use case.



> ## _PyUnicode_ToLowercase, _PyUnicode_ToUppercase
>
> They are not deprecated by PEP 393, but bpo-12736.
>
> They are documented as deprecated, but don't have ``Py_DEPRECATED``.
>
> Plan: Add Py_DEPRECATED in 3.9, and remove them in 3.11.
>
> Note: _PyUnicode_ToTitlecase has Py_DEPRECATED. It can be removed in 3.10.

bpo-12736 is "Request for python casemapping functions to use full not
simple casemaps per Unicode's recommendation". IMHO the replacement
function is to call lower() and method() of a Python str object.

If you change the 3.9 documentation, please also update 3.8 doc.

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

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

[Victor Stinner]

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

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
> to use.

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


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


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

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

[Victor Stinner]

Le lun. 29 juin 2020 à 08:41, Inada Naoki  a écrit :
> That's all.
> Now I think it is safe to override deprecated APIs with private APIs
> accepts Unicode Object.
>
> * _PyUnicode_EncodeUTF7 -> PyUnicode_EncodeUTF7

Use PyUnicode_AsEncodedString("UTF-7"). This encoding is not common
enough to justify to have to maintain a public C API for just it.
Adding public C API functions have a cost in CPython, but also in
other Python implementations which then have to maintain it as well.

The C API is too large, we have to make it smaller, not larger.


> * _PyUnicode_AsUTF8String -> PyUnicode_EncodeUTF8

Use PyUnicode_AsUTF8String(), or PyUnicode_AsEncodedString() if you
need to pass errors.

> * _PyUnicode_EncodeUTF16 -> PyUnicode_EncodeUTF16

Use PyUnicode_AsUTF16String(), or PyUnicode_AsEncodedString() if you
need to pass errors or the byte order.

> * _PyUnicode_EncodeUTF32 -> PyUnicode_EncodeUTF32

Who use UTF32? There is PyUnicode_AsUTF32String().

> * _PyUnicode_AsLatin1String -> PyUnicode_EncodeLatin1

PyUnicode_AsLatin1String()

> * _PyUnicode_AsASCIIString -> PyUnicode_EncodeASCII

PyUnicode_AsASCIIString()

> * _PyUnicode_EncodeCharmap -> PyUnicode_EncodeCharmap

PyUnicode_AsCharmapString()

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

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

[Victor Stinner]

Le dim. 28 juin 2020 à 17:21, Inada Naoki  a écrit :
> More aggressive idea: override current PyUnicode_EncodeXXX() apis.
> Change from `Py_UNICODE *object` to `PyObject *unicode`.
>
> This idea might look crazy.  But PyUnicode_EncodeXXX APIs are
> deprecated for a long time, and there are only a few users.
> I grepped from 3874 source packages in top 4000 downloaded packages.
> (126 packages are wheel-only)

IMO it's a violation of the C API stability warranty. I would prefer
to use different function names to ensure that building an old C
extension fails with a compiler error, rather than emit a compiler
warning and crash at runtime.

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

[Nathaniel Smith]

On Mon, Jun 29, 2020 at 2:31 AM Steve Holden  wrote:
> The commit message used, however, reveals implementation details of the 
> change which are irrelevant to the stated aim, which is making the 
> documentation clear and concise. Use of such language is certainly 
> regrettable, since it carries with it the implication that the Python 
> developer community has somehow been wilfully sanctioning "relics of white 
> supremacy" up until the change was made.
>
> There certainly is a place in tech for politics, as I have argued many times, 
> and I am sure nobody wishes to continue to use language that might be 
> offensive to readers. But I would suggest that the politics can safely be 
> omitted from commit messages, since they can only properly be fully addressed 
> in the conversation about the PR in advance. The wording of the commit 
> message has the appearance (probably specious) of wanting to rub former 
> misdeeds in the face of a largely innocent community, and that is the 
> principal reason I found it distasteful and unnecessary.

I just re-read the commit message, and I think you're being
oversensitive and imagining things that aren't there. The actual
commit message is written in a straightforward and factual way, and
spends special effort on *absolving* the community of this kind of
guilt. In particular, it emphasizes that the new text is accomplishing
"the same goal", "maintaining the original intent", and describes the
old text as a "relic", which is another way of saying that the
problems were only there by historical accident, rather than by anyone
intentionally keeping it there. Merely mentioning the concept of white
supremacy is not an attack on you or the community [1].

-n

[1] https://en.wikipedia.org/wiki/White_defensiveness

-- 
Nathaniel J. Smith -- https://vorpus.org
___
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/5EAQOYAEMKGTRDTTNZQNF4QNJBQGSOYA/
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

[Steve Holden]

Thank you. I understand the need for tolerance in such matters since
opinions vary, and merely wished to voice my own.

If I am being oversensitive it is perhaps because I have trodden in these
waters before, and have frequently been surprised by what other people find
distasteful or offensive. I do not necessarily require my opinions to be
thought reasonable, even by other reasonable people.

Kind regards,
Steve


On Mon, Jun 29, 2020 at 11:22 AM Nathaniel Smith  wrote:

> On Mon, Jun 29, 2020 at 2:31 AM Steve Holden  wrote:
> > The commit message used, however, reveals implementation details of the
> change which are irrelevant to the stated aim, which is making the
> documentation clear and concise. Use of such language is certainly
> regrettable, since it carries with it the implication that the Python
> developer community has somehow been wilfully sanctioning "relics of white
> supremacy" up until the change was made.
> >
> > There certainly is a place in tech for politics, as I have argued many
> times, and I am sure nobody wishes to continue to use language that might
> be offensive to readers. But I would suggest that the politics can safely
> be omitted from commit messages, since they can only properly be fully
> addressed in the conversation about the PR in advance. The wording of the
> commit message has the appearance (probably specious) of wanting to rub
> former misdeeds in the face of a largely innocent community, and that is
> the principal reason I found it distasteful and unnecessary.
>
> I just re-read the commit message, and I think you're being
> oversensitive and imagining things that aren't there. The actual
> commit message is written in a straightforward and factual way, and
> spends special effort on *absolving* the community of this kind of
> guilt. In particular, it emphasizes that the new text is accomplishing
> "the same goal", "maintaining the original intent", and describes the
> old text as a "relic", which is another way of saying that the
> problems were only there by historical accident, rather than by anyone
> intentionally keeping it there. Merely mentioning the concept of white
> supremacy is not an attack on you or the community [1].
>
> -n
>
> [1] https://en.wikipedia.org/wiki/White_defensiveness
>
> --
> Nathaniel J. Smith -- https://vorpus.org
>
___
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/2KNGOQKZOPJXMJWHZYMJ3DQZZVVHMLJ7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Inada Naoki]

Many existing public APIs doesn't have `const char *errors` argument.
As there are very few users, we can ignore that limitation.

On the other hand, some encoding have special options.
* UTF16 and UTF32; `int byteorder` parameter.
* UTF7;  int base64SetO, int base64WhiteSpace

So PyUnicode_AsEncodedString can not replace them.

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

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

[Victor Stinner]

Le lun. 29 juin 2020 à 12:36, Inada Naoki  a écrit :
> * UTF16 and UTF32; `int byteorder` parameter.

* UTF-16 byte_order=0 means "UTF-16" encoding
* UTF-16 byte_order<0 means "UTF-16-BE" encoding
* UTF-16 byte_order>0 means "UTF-16-LE" encoding

Same applies for UTF-32.

> * UTF7;  int base64SetO, int base64WhiteSpace

Does anyone use these parameters? I would prefer to ensure that they
are used before continuing to maintain code to support these
parameters.

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

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

[Inada Naoki]

On Mon, Jun 29, 2020 at 6:51 PM Victor Stinner  wrote:
>
>
> I understand that these ".. deprecated" markups will be added to 3.8
> and 3.9 documentation, right?
>

They are documented as "Deprecated since version 3.3, will be removed
in version 4.0" already.
I am proposing s/4.0/3.10/ in 3.8 and 3.9 documents.

> For each function, I would be nice to suggest a replacement function.
> For example, PyUnicode_EncodeMBCS() (Py_UNICODE*) can be replaced with
> PyUnicode_EncodeCodePage() using code_page=CP_ACP (PyObject*).

Of course.

> > ## PyUnicode_EncodeDecimal
> >
> > It is not documented.  It has not been deprecated by Py_DEPRECATED.
> > Plan: Add Py_DEPRECATED in Python 3.9 and remove it in 3.11.
>
> I understood that the replacement function is the private
> _PyUnicode_TransformDecimalAndSpaceToASCII() function. This function
> is used by complex, float and int types to convert a string into a
> number.
>

Should we make it public?

>
> > ## _PyUnicode_ToLowercase, _PyUnicode_ToUppercase
> >
> > They are not deprecated by PEP 393, but bpo-12736.
> >
> > They are documented as deprecated, but don't have ``Py_DEPRECATED``.
> >
> > Plan: Add Py_DEPRECATED in 3.9, and remove them in 3.11.
> >
> > Note: _PyUnicode_ToTitlecase has Py_DEPRECATED. It can be removed in 3.10.
>
> bpo-12736 is "Request for python casemapping functions to use full not
> simple casemaps per Unicode's recommendation". IMHO the replacement
> function is to call lower() and method() of a Python str object.
>

We have private functions; _PyUnicode_ToTitleFull, _PyUnicode_ToLowerFull,
and _PyUnicode_ToUpperFull.
I am not sure we should make them public too.

> If you change the 3.9 documentation, please also update 3.8 doc.
>

I see.

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

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

[Victor Stinner]

Le lun. 29 juin 2020 à 12:50, Inada Naoki  a écrit :
> > > ## PyUnicode_EncodeDecimal
> > >
> > > It is not documented.  It has not been deprecated by Py_DEPRECATED.
> > > Plan: Add Py_DEPRECATED in Python 3.9 and remove it in 3.11.
> >
> > I understood that the replacement function is the private
> > _PyUnicode_TransformDecimalAndSpaceToASCII() function. This function
> > is used by complex, float and int types to convert a string into a
> > number.
> >
>
> Should we make it public?

In the past, we expose everything "just in case" someone would like to
use it. 30 years later, the C API has hundreds of functions, we don't
know which ones are used or not, the C API is not well tested, etc.

Unless there is a clear user request with a strong use case which
cannot be solved with existing functions, I suggest to *not* add any
new C API function.

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

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

[Rhodri James]

On 28/06/2020 21:47, Daniel Moisset wrote:

I've been going over the PEP this weekend, trying to get a
deeper understanding of what are its main ideas and consequences, and wrote
some notes. I'm not posting the notes directly to this list because it's a
bit of a long read, but I also tried to make it helpful as an analysis for
people involved in the discussion. So here's a link:
https://github.com/dmoisset/notebook/blob/811side
of thingsbf66/python/pep622/understanding-pep-622.md

.
I may update this in master, but for clarity I'm permalinking the current
version.

I'll soon switch to "proposing solutions" mode (rather than "analysis mode"
as this text is) soon, but needed to do this first, and hopefully this
helps someone else in this list organise ideas.


Thank you for that, Daniel.  That's a very nice analysis that makes my 
own misgivings clearer and put some of them to rest.  I think you are 
right that generalised destructuring is probably the thing to 
concentrate on; once we have something cohesive there, pattern syntax 
should become a lot more obvious.


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

[Richard Damon]

On 6/29/20 6:22 AM, Nathaniel Smith wrote:
> and describes the
> old text as a "relic", which is another way of saying that the
> problems were only there by historical accident, rather than by anyone
> intentionally keeping it there. 

I would say that say that I have seen the term "relic" being used as a
'weaponized' word to imply that the old thing WAS there intentionally as
a repressive measure. I am not saying that this usage was intended to be
used that way, but just as the old wording was taken as offensive to
some due to implication, I can see that message as offensive to others
due to implication, all because some people are easy to offend.

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

[Jim F.Hilliard]

I believe I'm not the only one with this question but, how is Strunk &
White connected with white supremacy?

Scanning through this thread, its wikipedia page and doing quick google
search, I wasn't able to find something tangible.


Best Regards,

Jim Fasarakis Hilliard
___
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/3FUFDUX3Z4LXCTFSXCNIPNBED2IFDJ23/
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

[Rhodri James]

On 29/06/2020 11:31, Steve Holden wrote:

If I am being oversensitive it is perhaps because I have trodden in these
waters before, and have frequently been surprised by what other people find
distasteful or offensive. I do not necessarily require my opinions to be
thought reasonable, even by other reasonable people.


I don't think you are being insensitive, I too found that commit message 
offensive.  Personally I think equating standardised English -- 
specifically Strunk and White -- with racist supremacy is itself a 
racist remark which should not have been made.

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

[Richard Damon]

On 6/29/20 7:35 AM, Jim F.Hilliard wrote:
> I believe I'm not the only one with this question but, how is Strunk &
> White connected with white supremacy?
>
> Scanning through this thread, its wikipedia page and doing quick
> google search, I wasn't able to find something tangible. 
>
>
> Best Regards,
> *
> *
> Jim Fasarakis Hilliard

A somewhat flippant answer (hope I don't get in trouble for it) is
because it defines the 'proper' use of English to be what some ancient
'White Guys' said it was as opposed to how some other 'Non-White' guys
use it, and those 'White Guys' were, at least in part, the people the
white supremacy came from, i.e., guilt by association.

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

[Paul Sokolovsky]

Hello,

On Mon, 29 Jun 2020 14:35:08 +0300
"Jim F.Hilliard"  wrote:

> I believe I'm not the only one with this question but, how is Strunk &
> White connected with white supremacy?

I wouldn't be surprised if the only connection between them is the word
"white".

> 
> Scanning through this thread, its wikipedia page and doing quick
> google search, I wasn't able to find something tangible.
> 
> 
> Best Regards,
> 
> Jim Fasarakis Hilliard



-- 
Best regards,
 Paul  mailto:pmis...@gmail.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/TNPPOFA562NKPW3J5CZYEDSNAGACZ6OZ/
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

[Jim F.Hilliard]

On Mon, Jun 29, 2020 at 2:50 PM Paul Sokolovsky  wrote:

>
> I wouldn't be surprised if the only connection between them is the word
> "white".
>
>
I would be *very* surprised. This seems very foreign to me as a European.
___
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/UWPXOYJTNMBNDAG6JX6ZD5YUM6FHTVIB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Rhodri James]

On 27/06/2020 10:36, Stephen J. Turnbull wrote:

Richard Damon writes:
  > As long as the bindings in match also make the symbol a local
  > (which seems reasonable) then you would get a similar restriction.

It's quite different.  First, it surely won't make other symbols
match-local.  Of course there will be times when you do all the work
inside the match statement.  But often you'll want to do bindings in a
match statement, then use those outside.  The second problem is that
this use of '_' isn't optional.  It's part of the syntax.  That means
that you can't use the traditional marking of a translateable string
(and it's not just tradition; there is a lot of external software that
expects it) in that scope.

So it's practically important, if not theoretically necessary, that
'case _' not bind '_'.


That's the clearest explanation of why "_" needs to be treated 
carefully, but I don't think it argues for the PEP's special treatment. 
Those people like me who just write for ourselves and don't care about 
internationalisation use "_" like any other variable with a strong 
implication that it's a dummy, so don't really care.  Those people like 
you who care about internationalisation presumably avoid using "_" 
anyway, so the PEP's usage goes against your current instincts.


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

[Nathaniel Smith]

On Mon, Jun 29, 2020 at 5:04 AM Paul Sokolovsky  wrote:
>
> Hello,
>
> On Mon, 29 Jun 2020 14:35:08 +0300
> "Jim F.Hilliard"  wrote:
>
> > I believe I'm not the only one with this question but, how is Strunk &
> > White connected with white supremacy?
>
> I wouldn't be surprised if the only connection between them is the word
> "white".

It's not Strunk and White per se, it's the idea of enforcing "standard
English", where "standard" here means "talks like a American with an
Ivy league education".

You all are displaying breathtakingly levels of ignorance here.
There's nothing wrong with being ignorant – we can't be experts in
everything, and your education probably didn't spend a lot of time
talking about the long history of language "standards" and the many
ways they've been used, intentionally, systematically, and violently
to enforce racist/classist/etc. policies. But using a thread on
python-dev to make clueless speculations like this is *incredibly*
inappropriate and offensive.

I'm not going to try to educate you on that history – it's completely
off-topic for this list, and you can do your own work if you care to.
But let's let this thread die here.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
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/PDTXLGIK5GGDDM7OBAD3XCHDHGE55NR7/
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

[Paul Sokolovsky]

Hello,

On Mon, 29 Jun 2020 06:21:36 -0700
Nathaniel Smith  wrote:

> On Mon, Jun 29, 2020 at 5:04 AM Paul Sokolovsky 
> wrote:
> >
> > Hello,
> >
> > On Mon, 29 Jun 2020 14:35:08 +0300
> > "Jim F.Hilliard"  wrote:
> >  
> > > I believe I'm not the only one with this question but, how is
> > > Strunk & White connected with white supremacy?  
> >
> > I wouldn't be surprised if the only connection between them is the
> > word "white".  
> 
> It's not Strunk and White per se, it's the idea of enforcing "standard
> English", where "standard" here means "talks like a American with an
> Ivy league education".

Someone might wonder why 2 US American people (the author of the commit
message and yourself), in the wake of events happening in that country,
take so much effort to untangle the situation with English usage for
people for whom English is not native. But not me. Events happen (in
the whole world, not just a particular country), and in general I
consider having opinions is quite normal. And thanks for yours.

> You all are displaying breathtakingly levels of ignorance here.
> There's nothing wrong with being ignorant – we can't be experts in
> everything, and your education probably didn't spend a lot of time
> talking about the long history of language "standards" and the many
> ways they've been used, intentionally, systematically, and violently
> to enforce racist/classist/etc. policies. But using a thread on
> python-dev to make clueless speculations like this is *incredibly*
> inappropriate and offensive.
> 
> I'm not going to try to educate you

Dude, you totally aren't going to. So please leave your supremacist,
center-of-the-world patronizing tone behind. Thank you. 

> -- 
> Nathaniel J. Smith -- https://vorpus.org



-- 
Best regards,
 Paul  mailto:pmis...@gmail.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/CLHHFZDFQV6XHUJA5WG2EGEYX3RPB7YP/
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

[Jim F.Hilliard]

On Mon, Jun 29, 2020 at 4:21 PM Nathaniel Smith  wrote:

>
> It's not Strunk and White per se, it's the idea of enforcing "standard
> English", where "standard" here means "talks like a American with an
> Ivy league education".
>
You all are displaying breathtakingly levels of ignorance here.
>

I definitely am, hence why I asked the question in the first place.

As it is currently written it isn't clearly understandable to non-US based
people. I just wish that the original email or the commit message did a
better job in justifying this for the rest of us.

But let's let this thread die here.
>

+1
___
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/F43TU3MMBK4NO6UKHNUDFPTUUVAEINK7/
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

[Rhodri James]

On 29/06/2020 15:02, Paul Sokolovsky wrote:

Hello,

On Mon, 29 Jun 2020 06:21:36 -0700
Nathaniel Smith  wrote:

You all are displaying breathtakingly levels of ignorance here.

[snippety snip]


I'm not going to try to educate you


Dude, you totally aren't going to. So please leave your supremacist,
center-of-the-world patronizing tone behind. Thank you.


OK guys, enough.  Paul, you were trying to be good here, but your 
previous comment was flamebait.  Nathaniel, that was exceptionally 
patronising, and I do somewhat take offense.  Both of you know better, 
now please behave like it.


(Yes, I'm allowed to get offended.  I'm half Welsh, growing up on the 
English side of the border with an obviously Welsh name.  I know all 
about language and racism, thank you very much.)


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

[Python-Dev] [RELEASE] mpdecimal-2.5.0

[Stefan Krah]

Hi,

I've released mpdecimal-2.5.0:

   http://www.bytereef.org/mpdecimal/index.html

15417edc8e12a57d1d9d75fa7e3f22b158a3b98f44db9d694cfd2acde8dfa0ca  
mpdecimal-2.5.0.tar.gz


Starting with Python 3.9, this version should be used for an external libmpdec.


Python versions 3.7 and 3.8 should use the previous version mpdecimal-2.4.2.


libmpdec


libmpdec will continue to evolve conservatively.  For the few changes, see:

   http://www.bytereef.org/mpdecimal/changelog.html


libmpdec++
==

mpdecimal now includes libmpdec++.  libmpdec++ is a complete C++ implementation
of the General Decimal Arithmetic Specification.

   http://www.bytereef.org/mpdecimal/doc/libmpdec++/index.html


The library frees users from manual memory management and has an easy API with
inline operators similar to the one in Python's decimal module.  Like Python's
decimal module, libmpdec++ has a thread local context for inline operators and
other functions that use the implicit context.


Depending on the compiler, the speed penalty for the C++ features compared
to libmpdec is 4-10%.

The best compiler I found is gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1), closely
followed by the latest Intel compiler.  Both produce the fastest libmpdec code
and have a speed penalty for C++ of 4%.


Like libmpdec, libmpdec++ has a large test suite.  In addition to the mpdecimal
tests, libmpdec++ has been tested by replacing all libmpdec functions in 
Python's
decimal module with libmpdec++ functions.

libmpdec++ passes both the Python test suite and deccheck.py.


For a short libmpdec++ introduction, see:

   http://www.bytereef.org/mpdecimal/quickstart.html



Stefan Krah

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

[Giampaolo Rodola']

On Mon, Jun 29, 2020 at 12:34 PM Nathaniel Smith  wrote:

> On Mon, Jun 29, 2020 at 2:31 AM Steve Holden  wrote:
> > The commit message used, however, reveals implementation details of the
> change which are irrelevant to the stated aim, which is making the
> documentation clear and concise. Use of such language is certainly
> regrettable, since it carries with it the implication that the Python
> developer community has somehow been wilfully sanctioning "relics of white
> supremacy" up until the change was made.
> >
> > There certainly is a place in tech for politics, as I have argued many
> times, and I am sure nobody wishes to continue to use language that might
> be offensive to readers. But I would suggest that the politics can safely
> be omitted from commit messages, since they can only properly be fully
> addressed in the conversation about the PR in advance. The wording of the
> commit message has the appearance (probably specious) of wanting to rub
> former misdeeds in the face of a largely innocent community, and that is
> the principal reason I found it distasteful and unnecessary.
>
> I just re-read the commit message, and I think you're being
> oversensitive and imagining things that aren't there. The actual
> commit message is written in a straightforward and factual way, and
> spends special effort on *absolving* the community of this kind of
> guilt.
>

"The community" has nothing to be absolved of, "Strunk & White" has nothing
to do with white supremacy and there is no guilt. If you feel guilty
because you're white then that's your problem. I don't feel guilty for
being white, the same way a black person should not feel guilty for being
black. And I have literally ZERO excuses to make to you or anybody else in
here because I'm white. Assuming guilt based on the color of your skin and
constantly attacking that specific group because of that is racist. It's
that simple. I find it astonishing how some people here don't seem to
realize that (or pretend not to).

And what's the goal anyway? Make us all feel guilty, create yet another
heated discussion, widen divisions, wait for the occasional folks who dare
to speak up against this vitriol and kick them out? And then what? What is
the plan here exactly? Don't you folks realize this is a technical forum?
Don't you understand how inappropriate it is to constantly bring up these
kinds of messages up here, and force people to either witness them silently
for fear of repercussions, or to engage in the discussion and risk paying
the consequences in terms of work / hiring / career / status / reputation
etc.? Because that's what happens, and we all know it. This is a very
public forum and we can all be traced back to here. There are professionals
here, people who go to conferences and/or make a living out of Python, who
pay the rent and support their family with it, and that don't want to be
put in this position.

It does not scale. It will never scale. Because whether we like it or not
we have to coexist together in this virtual space, including with people we
don't like. And this is why it is such a good idea to leave politics out of
the door and only stay focused on Python. We will still have different
opinions and occasional clashes, but as long as they are technical they
will be genuine, prolific and everything will be fine as it was before
"this" started (I've been reading this list for 12 years now). Discussing
politics, on the other hand, will only keep bringing conflict over and over
again. There's tons of proof of this already, and I can't envision a
different outcome in the long run. Because most of us are not OK with being
put against a wall and being blamed for "supremacy", "guilt", "privilege"
or whatever term you have in your jargon. I certainly am not. Furthermore,
that jargon makes no sense outside of the US and it's just ridiculous. I'm
European, am split between living here and in Asia, and I can guarantee you
that much.

Please, stop this.

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

[Keara Berlin]

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.

Take care,
Keara


On Sun, Jun 28, 2020, 16:12 Paul Sokolovsky  wrote:

> Hello,
>
> Shouldn't such feedback be also cross-posted to the python-dev mailing
> list? Also note the original pull request,
> https://github.com/python/peps/pull/1470, and differences of what was
> written in the pull request description and what went in the commit
> message.
>
>
> On Sun, 28 Jun 2020 22:10:14 +0200
> "Giampaolo Rodola'"  wrote:
>
> > From:
> >
> https://github.com/python/peps/commit/0c6427dcec1e98ca0bd46a876a7219ee4a9347f4
> >
> > > 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.
> >
> > This has nothing to do with making the wording "clear and
> > understandable" (I agree on that). It's about, once again, bringing
> > race-based politics into Python, and spreading hate towards a
> > specific group of people: whites. Whether you're aware of it or not,
> > there is a term for this: it's racism. I want to remind everyone that
> > most of us here simply want to contribute code. We do it for free,
> > and don't want to be involved in "this", because frankly it's
> > disgusting. Doing something out of passion and for free, and at the
> > same time seeing these sorts of things happening on a regular basis,
> > looks and feels like an insult, and will only lead to people leaving
> > this place.
> >
> > On Fri, Jun 26, 2020 at 11:27 PM Keara Berlin 
> > wrote:
> >
> > > Hi all, this is a very small change, but I thought I would field it
> > > here to see if anyone has suggestions or ideas. Instead of
> > > requiring that comments be written in Strunk & White Standard
> > > English, PEP-8 should require instead that English-language
> > > comments be clear and easily understandable by other English
> > > speakers. This accomplishes the same goal without alienating or
> > > putting up barriers for people (especially people of color) 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. This change may even make the requirement more
> > > clear to people who are not familiar with Strunk & White, since for
> > > programmers, the main relevant aspect of that standard is "be clear
> > > and concise;" simply saying that instead of referencing Strunk &
> > > White may communicate this more effectively. Here is the current
> > > line in PEP-8: "When writing English, follow Strunk and White."
> > > I propose changing this line to "When writing English, ensure that
> > > your comments are clear and easily understandable to other English
> > > speakers." ___
> > > Python-ideas mailing list -- python-id...@python.org
> > > To unsubscribe send an email to python-ideas-le...@python.org
> > > https://mail.python.org/mailman3/lists/python-ideas.python.org/
> > > Message archived at
> > >
> https://mail.python.org/archives/list/python-id...@python.org/message/AE2M7KOIQR37K3XSQW7FSV5KO4LMYHWX/
> > > Code of Conduct: http://python.org/psf/codeofconduct/
> > >
> >
> >
> > --
> > Giampaolo - gmpy.dev 
>
>
>
> --
> Best regards,
>  Paul  mailto:pmis...@gmail.com
> ___
> Python-ideas mailing list -- python-id...@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-id...@python.org/message/66T2R6G3YMX25LYVBHVLGGCREP2AYA7R/
> 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/3AC4B3JNOWWI273OUDLK3QM5BJFQHX37/
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

[David Mertz]

The commit message is simply silly. It introduces numerous contentious and
false claims that have nothing whatsoever to do with the small wording
change. It misunderstands how language, culture, history, and indeed white
supremacism, work.

I would recommend amending the commit message.

The underlying change itself is reasonable, and to my mind a small
improvement. There was unnecessary specificity in using Strunk and White as
reference, and not, say, William Zinsser's _On Writing Well_, which is
almost as well known. In the concrete, it would be exceedingly rare for
these to provide conflicting advice on a specific code comment.

On Mon, Jun 29, 2020 at 7:34 AM Richard Damon 
wrote:

> On 6/29/20 6:22 AM, Nathaniel Smith wrote:
> > and describes the
> > old text as a "relic", which is another way of saying that the
> > problems were only there by historical accident, rather than by anyone
> > intentionally keeping it there.
>
> I would say that say that I have seen the term "relic" being used as a
> 'weaponized' word to imply that the old thing WAS there intentionally as
> a repressive measure. I am not saying that this usage was intended to be
> used that way, but just as the old wording was taken as offensive to
> some due to implication, I can see that message as offensive to others
> due to implication, all because some people are easy to offend.
>
> --
> 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/6EN5RNF5CFDKCF3ZYQV53XH5KTBCSAQ6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/AMH7WMUOOZ4KAFYPVZO2BA5AQLWTCDR6/
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

[Abdur-Rahmaan Janhangeer]

Threads like these are meaningless, does not provide any learning
value and is nowhere near the single vs double quote thread.

It opens the gap for people who are not concerned about development
jump in the game shifting the focus away while nurturing a culture of thrash
I mean you tend to ignore threads from python-dev and python-ideas which
is not probably why you subscribed in the first place

This is not the first time i am saying that you can fly around the world on
official
Python mailing lists. But it's regrettable that it's the first time i am
seeing people
telling that they should educate others and things like that. It can be
based on the
argument and circle around it but personal attacks are off limit

If this was a Github issue, i don't think you list moderators would have
dragged it
around that much. Worst case scenario, someone would have been pinged and
the issue taken care of. A PR or closing and you are done.

I raised the issue of closing a mail thread before and the impractical
nature of
it was discussed but maybe warnings and continued posting after the warning
results in ban can be enforced

And it's annoying that it got dragged to two mailing lists. I respect
Python people
and i am always eager to follow some C code discussions, deprecating this C
API
etc. It's a new world for me.

Maybe active list members should sign a convention or a vetting process can
be setup
before we can discuss it on the lists. Not ideal but might be useful.

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy  | blog

github 
Mauritius


On Mon, Jun 29, 2020 at 8:11 PM David Mertz  wrote:

> The commit message is simply silly. It introduces numerous contentious and
> false claims that have nothing whatsoever to do with the small wording
> change. It misunderstands how language, culture, history, and indeed white
> supremacism, work.
>
> I would recommend amending the commit message.
>
> The underlying change itself is reasonable, and to my mind a small
> improvement. There was unnecessary specificity in using Strunk and White as
> reference, and not, say, William Zinsser's _On Writing Well_, which is
> almost as well known. In the concrete, it would be exceedingly rare for
> these to provide conflicting advice on a specific code comment.
>
> On Mon, Jun 29, 2020 at 7:34 AM Richard Damon 
> wrote:
>
>> On 6/29/20 6:22 AM, Nathaniel Smith wrote:
>> > and describes the
>> > old text as a "relic", which is another way of saying that the
>> > problems were only there by historical accident, rather than by anyone
>> > intentionally keeping it there.
>>
>> I would say that say that I have seen the term "relic" being used as a
>> 'weaponized' word to imply that the old thing WAS there intentionally as
>> a repressive measure. I am not saying that this usage was intended to be
>> used that way, but just as the old wording was taken as offensive to
>> some due to implication, I can see that message as offensive to others
>> due to implication, all because some people are easy to offend.
>>
>> --
>> 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/6EN5RNF5CFDKCF3ZYQV53XH5KTBCSAQ6/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> The dead increasingly dominate and strangle both the living and the
> not-yet born.  Vampiric capital and undead corporate persons abuse
> the lives and control the thoughts of homo faber. Ideas, once born,
> become abortifacients against new conceptions.
> ___
> 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/AMH7WMUOOZ4KAFYPVZO2BA5AQLWTCDR6/
> 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/B426T6LT3TAFJHDNWBBAEWPTZKAFEM2K/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ricky Teachey]

On Mon, Jun 29, 2020 at 10:51 AM Giampaolo Rodola' 
wrote:

>
>
> On Mon, Jun 29, 2020 at 12:34 PM Nathaniel Smith  wrote:
>
>> On Mon, Jun 29, 2020 at 2:31 AM Steve Holden  wrote:
>> > The commit message used, however, reveals implementation details of the
>> change which are irrelevant to the stated aim, which is making the
>> documentation clear and concise. Use of such language is certainly
>> regrettable, since it carries with it the implication that the Python
>> developer community has somehow been wilfully sanctioning "relics of white
>> supremacy" up until the change was made.
>> >
>> > There certainly is a place in tech for politics, as I have argued many
>> times, and I am sure nobody wishes to continue to use language that might
>> be offensive to readers. But I would suggest that the politics can safely
>> be omitted from commit messages, since they can only properly be fully
>> addressed in the conversation about the PR in advance. The wording of the
>> commit message has the appearance (probably specious) of wanting to rub
>> former misdeeds in the face of a largely innocent community, and that is
>> the principal reason I found it distasteful and unnecessary.
>>
>> I just re-read the commit message, and I think you're being
>> oversensitive and imagining things that aren't there. The actual
>> commit message is written in a straightforward and factual way, and
>> spends special effort on *absolving* the community of this kind of
>> guilt.
>>
>
> "The community" has nothing to be absolved of, "Strunk & White" has
> nothing to do with white supremacy and there is no guilt. If you feel
> guilty because you're white then that's your problem. I don't feel guilty
> for being white, the same way a black person should not feel guilty for
> being black. And I have literally ZERO excuses to make to you or anybody
> else in here because I'm white. Assuming guilt based on the color of your
> skin and constantly attacking that specific group because of that is
> racist. It's that simple. I find it astonishing how some people here don't
> seem to realize that (or pretend not to).
>
> And what's the goal anyway? Make us all feel guilty, create yet another
> heated discussion, widen divisions, wait for the occasional folks who dare
> to speak up against this vitriol and kick them out? And then what? What is
> the plan here exactly? Don't you folks realize this is a technical forum?
> Don't you understand how inappropriate it is to constantly bring up these
> kinds of messages up here, and force people to either witness them silently
> for fear of repercussions, or to engage in the discussion and risk paying
> the consequences in terms of work / hiring / career / status / reputation
> etc.? Because that's what happens, and we all know it. This is a very
> public forum and we can all be traced back to here. There are professionals
> here, people who go to conferences and/or make a living out of Python, who
> pay the rent and support their family with it, and that don't want to be
> put in this position.
>
> It does not scale. It will never scale. Because whether we like it or not
> we have to coexist together in this virtual space, including with people we
> don't like. And this is why it is such a good idea to leave politics out of
> the door and only stay focused on Python. We will still have different
> opinions and occasional clashes, but as long as they are technical they
> will be genuine, prolific and everything will be fine as it was before
> "this" started (I've been reading this list for 12 years now). Discussing
> politics, on the other hand, will only keep bringing conflict over and over
> again. There's tons of proof of this already, and I can't envision a
> different outcome in the long run. Because most of us are not OK with being
> put against a wall and being blamed for "supremacy", "guilt", "privilege"
> or whatever term you have in your jargon. I certainly am not. Furthermore,
> that jargon makes no sense outside of the US and it's just ridiculous. I'm
> European, am split between living here and in Asia, and I can guarantee you
> that much.
>
> Please, stop this.
>
> -
> Giampaolo - gmpy.dev 
>
>
The above response is how I feel about this. There is palpable fear right
now that anyone who disagrees that these political types of discussion have
a place in the professional world will be ostracized. I fear it even
writing this short email. And that fear is more than warranted.

The laudable goals of inclusion in the python community, which I support,
are not being served by bringing these politically motivated changes-- a
perfect example of which is this latest claim that S&W, an utterly
inoffensive English language standard that itself has nothing to do with
white supremacy, is a "relic of white supremacy" that has been place for
two (or nearly two) decades in the core python founding PEPs, etc., and the
absurd claim that it is hurtful in some way to non-white people

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

[André Roberge]

Adding my voice to those that ask for such discussions be stopped ... and,
if at all possible, be snipped in the bud and prevented from occurring in
the future.

More below.

On Mon, Jun 29, 2020 at 12:51 PM Ricky Teachey  wrote:

> On Mon, Jun 29, 2020 at 10:51 AM Giampaolo Rodola' 
> wrote:
>
>>
>>
>>
>>
>> And what's the goal anyway? Make us all feel guilty, create yet another
>> heated discussion, widen divisions, wait for the occasional folks who dare
>> to speak up against this vitriol and kick them out? And then what? What is
>> the plan here exactly? Don't you folks realize this is a technical forum?
>>
>> ...

> Please, stop this.
>>
>> -
>> Giampaolo - gmpy.dev 
>>
>>
> The above response is how I feel about this. There is palpable fear right
> now that anyone who disagrees that these political types of discussion have
> a place in the professional world will be ostracized. I fear it even
> writing this short email. And that fear is more than warranted.
>
> The laudable goals of inclusion in the python community, which I support,
> are not being served by bringing these politically motivated changes-- a
> perfect example of which is this latest claim that S&W, an utterly
> inoffensive English language standard that itself has nothing to do with
> white supremacy, is a "relic of white supremacy" that has been place for
> two (or nearly two) decades in the core python founding PEPs, etc., and the
> absurd claim that it is hurtful in some way to non-white people, and these
> sorts of claims not only going unchallenged but even in some ways
> encouraged at the top of the leadership-- to the fore. It is divisive, and
> it makes me want to not want to be a part of the community because of 1.
> fear that I will pay dearly if I speak up (happily I'm not a developer
> although I've thought about a career change, but probably I can kiss that
> goodbye after this email) and 2. it is extremely unpleasant to have no
> realm of life-- not technical/professional, not sports, not even church--
> in which the American politics that permeate all of life these days (and
> seems to be reaching its tendrils across the water into other countries)
> can be put to the side.
>
> I'm tired. Please, please think about how we can make the focus of this
> community be technical considerations.
>

One of my proudest/happiest moments as a general Python contributor was
when I was nominated as a PSF Fellow in 2010.  In 2013, frustrated at
similar social/political discussions taking over some Python forum, and not
having the mental fortitude to speak up, I quietly asked for my status to
be converted to Emeritus (
https://www.python.org/psf/members/#emeritus-fellows) and withdrew for a
few years. This time, rather than be completely silent, I feel like I must
speak (for myself, and possibly for others) and ask to please stop these
non-technical digressions which only bring divisions.

André Roberge





>
> Rick.
>
> ___
> Python-ideas mailing list -- python-id...@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-id...@python.org/message/7AGI7S55LH44DTNYZGME7DZQFYTZFQ2X/
> 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/TLYM7MBDHMQDMF6OQC6ISAISPFG35JBW/
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

[C. Titus Brown via Python-Dev]

Hi all,

as a moderator of python-ideas, I’ve asked postmaster to place python-ideas 
into emergency moderation. (I do not have the tools to do so myself.) I’m 
willing to review messages individually as needed.

best,
—titus

> On Jun 29, 2020, at 9:24 AM, Abdur-Rahmaan Janhangeer  
> wrote:
> 
> Threads like these are meaningless, does not provide any learning
> value and is nowhere near the single vs double quote thread.
> 
> It opens the gap for people who are not concerned about development
> jump in the game shifting the focus away while nurturing a culture of thrash
> I mean you tend to ignore threads from python-dev and python-ideas which 
> is not probably why you subscribed in the first place
> 
> This is not the first time i am saying that you can fly around the world on 
> official
> Python mailing lists. But it's regrettable that it's the first time i am 
> seeing people
> telling that they should educate others and things like that. It can be based 
> on the
> argument and circle around it but personal attacks are off limit
> 
> If this was a Github issue, i don't think you list moderators would have 
> dragged it
> around that much. Worst case scenario, someone would have been pinged and 
> the issue taken care of. A PR or closing and you are done.
> 
> I raised the issue of closing a mail thread before and the impractical nature 
> of 
> it was discussed but maybe warnings and continued posting after the warning
> results in ban can be enforced
> 
> And it's annoying that it got dragged to two mailing lists. I respect Python 
> people
> and i am always eager to follow some C code discussions, deprecating this C 
> API
> etc. It's a new world for me.
> 
> Maybe active list members should sign a convention or a vetting process can 
> be setup
> before we can discuss it on the lists. Not ideal but might be useful.
> 
> Kind Regards,
> 
> Abdur-Rahmaan Janhangeer
> compileralchemy | blog 
> github
> Mauritius
> 
> 
> On Mon, Jun 29, 2020 at 8:11 PM David Mertz  wrote:
> The commit message is simply silly. It introduces numerous contentious and 
> false claims that have nothing whatsoever to do with the small wording 
> change. It misunderstands how language, culture, history, and indeed white 
> supremacism, work.
> 
> I would recommend amending the commit message.
> 
> The underlying change itself is reasonable, and to my mind a small 
> improvement. There was unnecessary specificity in using Strunk and White as 
> reference, and not, say, William Zinsser's _On Writing Well_, which is almost 
> as well known. In the concrete, it would be exceedingly rare for these to 
> provide conflicting advice on a specific code comment.
> 
> On Mon, Jun 29, 2020 at 7:34 AM Richard Damon  
> wrote:
> On 6/29/20 6:22 AM, Nathaniel Smith wrote:
> > and describes the
> > old text as a "relic", which is another way of saying that the
> > problems were only there by historical accident, rather than by anyone
> > intentionally keeping it there. 
> 
> I would say that say that I have seen the term "relic" being used as a
> 'weaponized' word to imply that the old thing WAS there intentionally as
> a repressive measure. I am not saying that this usage was intended to be
> used that way, but just as the old wording was taken as offensive to
> some due to implication, I can see that message as offensive to others
> due to implication, all because some people are easy to offend.
> 
> -- 
> 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/6EN5RNF5CFDKCF3ZYQV53XH5KTBCSAQ6/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> -- 
> The dead increasingly dominate and strangle both the living and the 
> not-yet born.  Vampiric capital and undead corporate persons abuse 
> the lives and control the thoughts of homo faber. Ideas, once born, 
> become abortifacients against new conceptions.
> ___
> 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/AMH7WMUOOZ4KAFYPVZO2BA5AQLWTCDR6/
> 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/B426T6LT3TAFJHDNWBBAEWPTZKAFEM2K/
> Code of Conduct: http://python.org/psf/codeofconduct/

_

[Python-Dev] Lists placed into Emergency Moderation status

[Ernest W. Durbin III]

At the request of the list moderators of python-ideas and python-dev, both 
lists have been placed into emergency moderation mode. All new posts must be 
approved before landing on the list.

When directed by the list moderators, this moderation will be disabled.

-Ernest W. Durbin III
Director of Infrastructure
Python Software Foundation
___
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/M2DBECHTZCHUKYO4KHPAAZJTDARJB6T4/
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

[Rhodri James]

On 29/06/2020 17:24, Abdur-Rahmaan Janhangeer wrote:

Threads like these are meaningless, does not provide any learning
value and is nowhere near the single vs double quote thread.


I'm afraid I couldn't disagree more.  Since the PSF has seen fit to make 
a political statement (re Black Lives Matter, and I don't particularly 
disagree with either the statement or the choice of making it), threads 
like these are both inevitable and necessary.  When such statements are 
made, it is generally a good idea to be reasonably sure that the 
community one is representing is broadly OK with that statement.  (I 
speak in vague terms because you will never get 100% agreement from 
anyone on anything!)


The commit message that sparked this all was, quite unnecessarily, a 
political statement.  The threads have demonstrated that it is not even 
vaguely universally accepted, so it being in the PEPs repository (not 
just a PR, it's there, public, and effectively representing you and me) 
is a problem.  That it's still there now is pretty unacceptable in my book.


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

[Stephen J. Turnbull]

To bring this thread back to encouraging diversity, I must point out
that diverse English dialects are not all there is to diversity, folks.

Nathaniel Smith writes:

 > In particular, it emphasizes that the new text is accomplishing
 > "the same goal", "maintaining the original intent",

That displays a great misunderstanding of that goal and intent in my
opinion.  The original intent clearly includes providing *concrete*
guidelines, because no student of Strunk & White would use a reference
to Strunk & White if the phrase "clear and easily understood" would do.

Strunk & White is not a grammar of "Standard" English.  It is a Zen-
of-Python-like collection of precepts, many of which inform my own
writing in Japanese (!!) as well as in English, and my Japanese and
Chinese students have expressed appreciation for them.  While the
quirkiness of Strunk & White appeals to me personally, replacing it
with an explicit set of guidelines directly modeled on the Zen or an
alternative reference would serve the purpose as well.

But I do not know of a good substitute for this purpose.  I don't
think David's suggestion of Zinsser would serve so well.  It is a
textbook and quite discursive[1], while the table of contents of
Strunk & White is quite Zen-like, and little more than twice as long
as the Zen.

>From the lack of any mention of this aspect of Strunk & White, it's
clear that the commit was made with little or no consideration for the
many developers, current and potential, whose native language is *not*
English, nor for some neuro-atypical programmers, for whom generalities
like "be clear" may be deterring and explicit rules comforting.  That
doesn't mean simple removal of that reference was the wrong thing to
do, but it does mean that removing it without replacement needs more
justification than "it's a 'relic of white supremacy'".

I agree that the goal of encouraging diversity among community members
justifies substantial cost, which is repaid in many ways.  It is
certainly true that some of the precepts of Strunk & White are simple
grammar rules that are specific to Standard English, and in that sense
center whiteness.  But the loss to some, perhaps many, developers from
failing to provide *any* concrete guidelines may be large.  That
should have been considered before committing, and in my opinion,
replacement guidelines or an alternative reference included.  This
loss was mentioned several times in the discussion on Python Ideas --
and ignored.

I sure hope it will be considered now.

Steve


Footnotes: 
[1]  And probably suffers from "centering whiteness," though perhaps
not to the degree that Strunk & White does.  It's been a while since
I've looked at Zinsser.
___
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/45HIBLYFJ2TNWNJZS2MZNP2CSQRKDJW3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stephen J. Turnbull]

Rhodri James writes:

 > That's the clearest explanation of why "_" needs to be treated 
 > carefully, but I don't think it argues for the PEP's special treatment. 

That depends on whether you care about taking advantage of the
convention that "_" is a dummy.  In fact, _ = gettext partakes of that
convention: all the programmer need know about internationalization is
that non-English speakers might like to read the string in their own
language.  From her point of view, _() is a no-op aka dummy.

 > Those people like me who just write for ourselves and don't care about 
 > internationalisation use "_" like any other variable with a strong 
 > implication that it's a dummy, so don't really care.  Those people like 
 > you who care about internationalisation presumably avoid using "_" 
 > anyway, so the PEP's usage goes against your current instincts.

I can't speak for others, but I use "_" as a dummy all the time.  Of
course that means I need to take care to use a different convention in
code that assumes _ == gettext, but it's rarely needed in my
experience.

But if the use of _ as a dummy in "case _" becomes syntax, I can't use
a different dummy, can I?  Or can I use a different dummy (such as
"xx" or "__") at the expense of binding it?

With the non-binding treatment of "case _", I don't have to worry
about it.

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

[Python-Dev] Re: Intended invariants for signals in CPython

[Yonatan Zunger via Python-Dev]

Whew. Nick, Antoine, and Chris, thanks to each of you for your feedback --
with it, I *think* I've managed to write a pure-Python signal suppression
library. I'm nowhere near confident enough in its handling of corner cases
yet to release it to the general public, but hopefully I'll be able to
acquire that faith in it over time and do that.

(It ended up involving a new & improved Semaphore class with some more
functions like pausability, having a signal handler that puts things in a
SimpleQueue [thanks, Antoine] and dequeues them when the semaphore is empty
and paused, creative use of with instead of try/finally to leverage some of
the ideas in the blog post Chris linked and manage reentrancy, and with all
that allow the main thread to meaningfully know when it needs to defer
dealing with a signal until later so that the threads can safely finish.
Whew.)

Good rule of thumb: If your Python code has comments talking about specific
opcodes, you are writing some Really Interesting Python Code. :)

Yonatan

On Sat, Jun 27, 2020 at 10:26 PM Nick Coghlan  wrote:

> On Fri., 26 Jun. 2020, 7:02 am Chris Jerdonek, 
> wrote:
>
>> On Wed, Jun 24, 2020 at 5:15 PM Yonatan Zunger via Python-Dev <
>> python-dev@python.org> wrote:
>>
>>> That said, the meta-question still applies: Are there things which are
>>> generally intended *not* to be interruptible by signals, and if so, is
>>> there some consistent way of indicating this?
>>>
>>
>> Yonatan, Nathaniel Smith wrote an interesting post a few years ago that
>> includes some background about signal handling:
>> https://vorpus.org/blog/control-c-handling-in-python-and-trio/
>>
>
> Related to that is this CPython bug report:
> https://bugs.python.org/issue29988
>
> The short version is that Greg Smith and I tried to close some of the
> remaining signal safety holes a couple of years ago, and I made it as far
> as building better tools for provoking the bugs (this is the origin of
> per-opcode tracing hooks in CPython), but we never came up with an actual
> solution.
>
> So the workaround remains to run anything that absolutely cannot be
> interrupted by poorly timed signals in a subthread, and dedicate the main
> thread to signal handling.
>
> Cheers,
> Nick.
>
>
>
>>

-- 

Yonatan Zunger

Distinguished Engineer and Chief Ethics Officer

He / Him

zun...@humu.com

100 View St, Suite 101

Mountain View, CA 94041

Humu.com   · LinkedIn
  · Twitter

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

[David Mertz]

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 provide any learning
> > value and is nowhere near the single vs double quote thread.
>
> I'm afraid I couldn't disagree more.  Since the PSF has seen fit to make
> a political statement (re Black Lives Matter, and I don't particularly
> disagree with either the statement or the choice of making it), threads
> like these are both inevitable and necessary.  When such statements are
> made, it is generally a good idea to be reasonably sure that the
> community one is representing is broadly OK with that statement.  (I
> speak in vague terms because you will never get 100% agreement from
> anyone on anything!)
>
> The commit message that sparked this all was, quite unnecessarily, a
> political statement.  The threads have demonstrated that it is not even
> vaguely universally accepted, so it being in the PEPs repository (not
> just a PR, it's there, public, and effectively representing you and me)
> is a problem.  That it's still there now is pretty unacceptable in my book.
>
> --
> 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/HP2NJGITNURNCP4XOSUO7Y65IUUIX6KM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/JOPTN4NMBEP3PBQDBGLEIR5GIKV37RLD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Tim Peters]

[Ernest W. Durbin III ]
> At the request of the list moderators of python-ideas and python-dev,
> both lists have been placed into emergency moderation mode. All
> new posts must be approved before landing on the list.
>
> When directed by the list moderators, this moderation will be disabled.

I do at least 99% of python-dev moderation actions, and this was news
to me.  I'm not going to reject anything Python-related based on
whether I (or anyone else) agree(s) with its political spin.  If
that's what's wanted, please contact whichever python-dev moderator(s)
did request this, and tell them the job of actually doing python-dev
moderation is all theirs until this passes.  Otherwise anything
Python-related short of pure abuse will be approved.

Seriously. I'm not going to reject sincere "you're a racist!" posts or
"I know you are, but what am I?" posts.  But I don't even know whether
that's what this is about - all I've seen is some moderately heated
discussion, none of which I would have rejected.
___
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/PYRZRPDJRVVJVICEC3N4YLR2XG2A7SEC/
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

[Antoine Pitrou]

On Mon, 29 Jun 2020 12:43:18 +0100
Rhodri James  wrote:
> On 29/06/2020 11:31, Steve Holden wrote:
> > If I am being oversensitive it is perhaps because I have trodden in these
> > waters before, and have frequently been surprised by what other people find
> > distasteful or offensive. I do not necessarily require my opinions to be
> > thought reasonable, even by other reasonable people.  
> 
> I don't think you are being insensitive, I too found that commit message 
> offensive.  Personally I think equating standardised English -- 
> specifically Strunk and White -- with racist supremacy is itself a 
> racist remark which should not have been made.

>From the outside, this does seem like a reasonable position.

Also, more generally, while I'm sure there are elaborate sociohistorical
arguments to be made about the influence of prejudice (for example
gendered or racist) on language, a Python commit message is not the
place to elaborate such a theory.  If this is important to you, perhaps
one direction is to propose your edits to the corresponding Wikipedia
page (which doesn't seem to list such criticism currently):
https://en.wikipedia.org/wiki/The_Elements_of_Style

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.  

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

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

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

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/

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

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy  | blog

github 
Mauritius


On Mon, Jun 29, 2020 at 11:34 PM Rhodri James  wrote:

> On 29/06/2020 17:24, Abdur-Rahmaan Janhangeer wrote:
> > Threads like these are meaningless, does not provide any learning
> > value and is nowhere near the single vs double quote thread.
>
> I'm afraid I couldn't disagree more.  Since the PSF has seen fit to make
> a political statement (re Black Lives Matter, and I don't particularly
> disagree with either the statement or the choice of making it), threads
> like these are both inevitable and necessary.
>

Good and nice but not on python-dev. The PSF is already taking
appropriate  steps on Twitter and relevant mediums. And in case
of correction of individuals i feel it better be left in the hands of
moderators. I prefer to maintain the purity of threads rather than
seeing members leave or stay aloof after a bitter experience.
___
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/2JNBID2QNBIKGTGTKX33VXCIQJNN7XYH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

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

-Ernest


On June 29, 2020 at 4:20:45 PM, Tim Peters (tim.pet...@gmail.com) wrote:

[Ernest W. Durbin III ]  
> At the request of the list moderators of python-ideas and python-dev,  
> both lists have been placed into emergency moderation mode. All  
> new posts must be approved before landing on the list.  
>  
> When directed by the list moderators, this moderation will be disabled.  

I do at least 99% of python-dev moderation actions, and this was news  
to me. I'm not going to reject anything Python-related based on  
whether I (or anyone else) agree(s) with its political spin. If  
that's what's wanted, please contact whichever python-dev moderator(s)  
did request this, and tell them the job of actually doing python-dev  
moderation is all theirs until this passes. Otherwise anything  
Python-related short of pure abuse will be approved.  

Seriously. I'm not going to reject sincere "you're a racist!" posts or  
"I know you are, but what am I?" posts. But I don't even know whether  
that's what this is about - all I've seen is some moderately heated  
discussion, none of which I would have rejected.  
___
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/MAY2ALBZSKUCVIWH3K53BU3NP5U375HQ/
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

[Antoine Pitrou]

On Mon, 29 Jun 2020 06:21:36 -0700
Nathaniel Smith  wrote:
> 
> You all are displaying breathtakingly levels of ignorance here.

Ah... How about you drop the condescending tone, Nathaniel?
You certainly can make your point without attacking your fellow
contributors.

> But using a thread on
> python-dev to make clueless speculations like this is *incredibly*
> inappropriate and offensive.

Yawn.

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

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

[Raymond Hettinger]

> On Jun 22, 2020, at 5:10 AM, Victor Stinner  wrote:
> 
> Introduce C API incompatible changes to hide implementation details.

How much of the existing C extension ecosystem do you expect to break as a 
result of these incompatible changes? 


> It will be way easier to add new features.

This isn't self-evident.  What is currently difficult that would be easier?


> It becomes possible to experiment with more advanced optimizations in CPython
> than just micro-optimizations, like tagged pointers.

Is there any proof-of-concept to suggest that it is in realm of possibility 
that such an experiment would produce a favorable outcome?  Otherwise, it isn't 
a reasonable justification for an extensive and irrevocable series a sweeping 
changes that affect the entire ecosystem of existing extensions.


> **STATUS**: Completed (in Python 3.9)

I'm not sure that many people are monitoring that huge number of changes that 
have gone in mostly unreviewed.  Mark Shannon and Stephan Krah have both raised 
concerns.  It seems like one person has been given blanket authorization to 
revise nearly every aspect of the internals and to undo the design choices made 
by all the developers who've previously worked on the project.


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

FWIW, I do appreciate the devotion and amount of effort in this undertaking — 
that isn't a question.  However, as a community this needs to be conscious 
decision.  I'm unclear about whether any benefits will ever materialize.  I am 
clear that packages will be broken, that performance will be impacted, and that 
this is one-way trip that can never be undone.  Most of the work is being done 
by one person. Many of the PRs aren't reviewed.  The rate and volume of PRs are 
so high that almost no one can keep track of what is happening. Mark and Stefan 
have pushed back but with no effect.


Raymond 


==

¹ Timings for attribute access

$ python3.8 -m timeit -s 'from collections import namedtuple' -s 
'Point=namedtuple("Point", "x y")'  -s 'p=Point(10,20)' 'p.x; p.y; p.x; p.y; 
p.x; p.y'
200 loops, best of 5: 119 nsec per loop

$ python3.9 -m timeit -s 'from collections import namedtuple' -s 
'Point=namedtuple("Point", "x y")'  -s 'p=Point(10,20)' 'p.x; p.y; p.x; p.y; 
p.x; p.y'
200 loops, best of 5: 152 nsec per loop

==

Python 3.8 disassembly (clean and fast)
---

_tuplegetter_descr_get:
testq   %rsi, %rsi
je  L299
subq$8, %rsp
movq8(%rsi), %rax
movq16(%rdi), %rdx
testb   $4, 171(%rax)
je  L300
cmpq16(%rsi), %rdx
jnb L301
movq24(%rsi,%rdx,8), %rax
addq$1, (%rax)
L290:
addq$8, %rsp
ret


Python 3.9 disassembly (doesn't look in-lined)
---

_tuplegetter_descr_get:
testq   %rsi, %rsi 
pushq   %r12 <-- new cost
pushq   %rbp <-- new cost
pushq   %rbx <-- new cost
movq%rdi, %rbx
je  L382
movq16(%rdi), %r12
movq%rsi, %rbp
movq8(%rsi), %rdi
call_PyType_GetFlags <-- new non-inlined function call
testl   $67108864, %eax
je  L383
cmpq16(%rbp), %r12
jnb L384
movq24(%rbp,%r12,8), %rax
addq$1, (%rax)
popq%rbx <-- new cost
popq%rbp <-- new cost
popq%r12v<-- new cost
ret





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

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

[Victor Stinner]

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."

IMHO it's time to stop wasting our limited developer resources on
micro-optimizations and micro-benchmarks, but think about overall
Python performance and major Python internals redesign to find a way
to make Python overall 2x faster, rather than making a specific
function 10% faster.

I don't think that the performance of accessing namedtuple attributes
is a known bottleneck of Python performance.


Le lun. 29 juin 2020 à 23:37, Raymond Hettinger
 a écrit :
> $ python3.8 -m timeit -s 'from collections import namedtuple' -s 
> 'Point=namedtuple("Point", "x y")'  -s 'p=Point(10,20)' 'p.x; p.y; p.x; p.y; 
> p.x; p.y'
> 200 loops, best of 5: 119 nsec per loop
>
> $ python3.9 -m timeit -s 'from collections import namedtuple' -s 
> 'Point=namedtuple("Point", "x y")'  -s 'p=Point(10,20)' 'p.x; p.y; p.x; p.y; 
> p.x; p.y'
> 200 loops, best of 5: 152 nsec per loop

Measuring benchmarks which take less than 1 second requires being very
careful. For a microbenchmark which takes around 100 ns like this one,
you are very close to the CPU limit and "everything" becomes
important.

Python performance depends on the C compiler, on compiler options, how
you run the microbenchmark, if --enable-shared is used, etc. Giving
microbenchmark results without these information isn't helpful.

On Fedora 32, Python binaries are built by GCC with Link Time
Optimization (LTO) and Profile Guided Optimization (PGO). I simply get
the same performance between Python 3.8.3 and Python 3.9.0b3:

$ python3.9 -m pyperf timeit --compare-to=python3.8 -s 'from
collections import namedtuple' -s 'Point=namedtuple("Point", "x y")'
-s 'p=Point(10,20)' 'p.x; p.y; p.x; p.y; p.x; p.y'
python3.8: . 138 ns +- 2 ns
python3.9: . 136 ns +- 3 ns

Mean +- std dev: [python3.8] 138 ns +- 2 ns -> [python3.9] 136 ns +- 3
ns: 1.01x faster (-1%)

(A difference smaller than 10% on a microbenchmark is not significant.)

The compiler decides to inline or not a static inline function
depending on many complex things. I don't think that there is any need
to elaborate here.

The idea to force inlining was discussed but rejected when first C API
macros have been converted to static inline functions:
https://bugs.python.org/issue35059

C compilers are now really smart to emit the most efficient machine code.

By the way, if you configure Python with --enable-shared, function
calls from libpython to libpython have to go through a procedure
linkage table (PLT) indirection. Python 3.8 and 3.9, on Fedora 32 and
Python 3.8 on RHEL8 are built with -fno-semantic-interposition to
avoid this indirection and so make Python faster. More about this
linker flag:
https://developers.redhat.com/blog/2020/06/25/red-hat-enterprise-linux-8-2-brings-faster-python-3-8-run-speeds/

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

[Giampaolo Rodola']

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?). 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, 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? 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. " == "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.


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 provide any learning
>> > value and is nowhere near the single vs double quote thread.
>>
>> I'm afraid I couldn't disagree more.  Since the PSF has seen fit to make
>> a political statement (re Black Lives Matter, and I don't particularly
>> disagree with either the statement or the choice of making it), threads
>> like these are both inevitable and necessary.  When such statements are
>> made, it is generally a good idea to be reasonably sure that the
>> community one is representing is broadly OK with that statement.  (I
>> speak in vague terms because you will never get 100% agreement from
>> anyone on anything!)
>>
>> The commit message that sparked this all was, quite unnecessarily, a
>> political statement.  The threads have demonstrated that it is not even
>> vaguely universally accepted, so it being in the PEPs repository (not
>> just a PR, it's there, public, and effectively representing you and me)
>> is a problem.  That it's still there now is pretty unacceptable in my
>> book.
>>
>> --
>> 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/HP2NJGITNURNCP4XOSUO7Y65IUUIX6KM/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> The dead increasingly dominate and strangle both the living and the
> not-yet born.  Vampiric capital and undead corporate persons abuse
> the lives and control the thoughts of homo faber. Ideas, once born,
> become abortifacients against new conceptions.
> ___
> 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/JOPTN4NMBEP3PBQDBGLEIR5GIKV37RLD/
> Code of Conduct: http://python

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

[Raymond Hettinger]

> On Jun 29, 2020, at 5:46 PM, 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."
> 
> IMHO it's time to stop wasting our limited developer resources on
> micro-optimizations and micro-benchmarks, but think about overall
> Python performance and major Python internals redesign to find a way
> to make Python overall 2x faster, rather than making a specific
> function 10% faster.

That is a really bold claim.  AFAICT there is zero evidence that this actually 
possible.  Like the sandboxing project, these experiments may all prove to be 
dead-ends.

If we're going to bet the farm on this, there should at least be a 
proof-of-concept. Otherwise, it's just an expensive lottery ticket.

> I don't think that the performance of accessing namedtuple attributes
> is a known bottleneck of Python performance.

This time you missed the point.  Named tuple access was just one point of 
impact — it is not the only code that calls PyTuple_Check().   It looks like 
inlining did not work and that EVERY SINGLE type check in CPython was affected 
(including third party extensions).  Also, there was no review — we have a 
single developer pushing through hundreds of these changes at a rate where no 
one else can keep up.

> Measuring benchmarks which take less than 1 second requires being very
> careful.


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.

There is a certain irony in making repeated, unsubstantiated promises to make 
the language 2x faster and then checking in changes that make the 
implementation slower.


Raymond


P.S. What PyPy achieved was monumental.  But it took a decade even with a 
well-organized and partially-funded team of superstars. It always lagged 
CPython in features. And the results were entirely dependent on a single design 
decision to run a pure python interpreter written in rpython to take advantage 
of its tracing JIT.  I don't imagine CPython can hope to achieve anything like 
this.  Likely, the best we can do is replace reference counting with garbage 
collection.


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

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

[Greg Ewing]

On 29/06/20 8:47 am, Daniel Moisset wrote:
 . 


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.

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

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.


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.


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. For
example, consider

   class Oval:
  def __init__(self, centre, width, height):
 ...

   class Circle(Oval):
  def __init__(self, centre, radius):
 ...

   match shape:
  case Oval(c, w, h):
 ...

If shape happens to be a Circle, you still want to deconstruct it as
an Oval and get centre, width, height, not centre, radius. There's
no way that can happen if the object itself is responsible for its
deconstruction.

(Incidentally, I do think the post that mentioned Liskov
substitutability has a point, but it's a different one --
the default single-positional-argument deconstruction is probably
a bad idea, because it will be wrong for a large number of
existing classes.)

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

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

[Emily Bowman]

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