Mailman 3 July 2020 - Python-Dev

Re: Python-Dev Digest, Vol 204, Issue 59
by Hugh Fisher 08 Jul '20

08 Jul '20

> Date: Wed, 8 Jul 2020 20:00:44 +0300 > From: Paul Sokolovsky <pmiscml(a)gmail.com> > Subject: [Python-Dev] Re: Python is the only language with lack of [ munch ] > Right. So, if someone would like to add something to this thread, I'd > humbly suggest to concentrate on the lack of, and need for, of > const-ness in the Python language core (in comparison to other languages > or not), and usecases it enables, and not on criteria for "popularness". > My view is that the informal Python "don't mess with anything all in upper case" coding convention works at least as well as any more formal language notation for nearly all cases. It conveys intention very well with minimum effort, and does not require programmers to think about the language they're using rather than the problem they are trying to solve. I can see the case for a const annotation/keyword for simple scalar values, almost always numbers, but am dubious about the benefits. If someone really wants to write IMPORTANT_SIN30 = math.sin(45) there's only so much a compiler/interpreter can do to stop them. "If we just provide enough detail we can catch every error" is a mirage that's lured away so much effort for many decades. (That said, I'd be in favour of adding math.PI and similar names because even I find it slightly disturbing that I can write math.pi = 3.0 and it doesn't look wrong.) Even for simple numbers, constness can be argued. Is the value determined when the code is written, or when run? A lot of mutable variables in Pascal/C/Ada programs are really constants, but the value is "number of CPU cores" or something else that can't be determined until first use. So those other languages that supposedly have constness are actually often more like Python. Once you go beyond scalar values, it's just a mess. If I write const myd = { "answer" : 42 } do I mean that myd will always be a reference to that object, or that the object being pointed to has constant members? To see what can happen if you try and build this into the language, look at C++. It has the const keyword for objects and object references. But then the "mutable" keyword got added to describe object members, because programmers needed to be able to modify the internal values of "const" objects! So now "const" in C++ for objects just means you don't intend to change the internal state, but it might do so anyway. Again, I can see a case in embedded systems for "const" meaning "this can be put in ROM". But I don't think that use case is common enough to justify adding to the core language. -- cheers, Hugh Fisher

1 0

Why does _ need to be special ?
by Paul Svensson 08 Jul '20

08 Jul '20

On Wed, 8 Jul 2020, Rhodri James wrote: > On 08/07/2020 11:05, Federico Salerno wrote: >> What I don't like is the use of _ as catch-all, which is different and not >> interdependent with its use as throwaway. > > Any name used as a pattern is a catch-all. The only difference between "case > dummy:" and "case _:" is that "_" doesn't bind to the thing being matched, but > "dummy" does bind to it. Does "_" really deserve that special treatment ? If you don't want to bind to it, you can just use some other dummy, same way you don't use "case print:" if you don want to bind that. /Paul

3 2

[OT] I'm unsubscribing from this tire fire (formerly known as python-dev)
by Christian Heimes 07 Jul '20

07 Jul '20

Y'all, trigger warning: strong opinion The Urban Dictionary defines the term "tire fire": A horrifying mess, either literally or figuratively foul-smelling, that seems to last forever. The term describes my current view of python-dev perfectly. It has always been a problematic and mentally draining place for, sometimes even toxic. But the recent PEP-8 discussion trumps every past incident (reference to US politics intended). To every person still replying on the PEP-8 thread: You are making us sick and should be ashamed of yourself! And I don't mean 'sick' in the figurative sense. You are literally hurting people who are spending their free and personal time to develop open source software for you. I know of at least three cases among Python core developers with symptoms like sleep disorder, tremor, anxiety, and panic attacks. One core dev wrote publicly that they were forced to take psychotropic medicine to counter a panic attack after they have read just a few messages. At one point I have even considered to retire from Python core development completely. I'm profoundly disgusted and appalled by the racist attitudes and self-importance of some people as well as an unrelated incident on BPO last week. The two reasons I'm not leaving are several core developers that I'm happy to call friends and Python communities beyond predominantly male and Western participants on the PEP-8 thread. Communities like PyLadies, PyCon Africa, PyLATAM, and PyCon APAC make me proud and happy to be a member of the Python community. I have met fantastic people at Python and OSS events in the Caribbean, India, and East Europe. I don't want to abandon people I cherish and grew fond of. At least one other core developer has abandoned python-dev last week. Others have stopped participating and posting on python-dev years ago. I will follow their example now. Goodbye Christian

6 5

Recent PEP-8 change
by Ethan Furman 06 Jul '20

06 Jul '20

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

36 108

ML help
by hamza naeem 06 Jul '20

06 Jul '20

Hi , I am making a classifier which basically scans the historical places and detects them .I am using SIFT for taking features of images and then passing them to the neural network . Features are 128 dimensional and model is trained with 97% accuracy but when i am using Single image prediction it is giving error : * ValueError: Input 0 of layer sequential_9 is incompatible with the layer: expected axis -1 of input shape to have value 128 but received input with shape [32, 1]* It's shape is already 128 , but I don't know why it is giving an error . Kindly help me i got stucked in it for several days

2 1

Tips: Searching deprecated API usage.
by Inada Naoki 06 Jul '20

06 Jul '20

Hi, folks. After 3.9 becomes beta, I am searching deprecated APIs we can remove in Python 3.10. I want to share how I am checking how the API is not used. Please teach me if you know an easy and better approach to find deprecated API usage. ## Sourcegraph Github code search is not powerful enough and there is a lot of noise. (e.g. many people copy CPython source code). On the other hand, Sourcegraph only searches from major repositories, and has powerful filtering. This is an example of `PyEval_ReleaseLock` search. https://sourcegraph.com/search?q=PyEval_ReleaseLock+file:.*%5C.%28cc%7Ccxx%… ## Top 4000 packages You can download a list of top 4000 PyPI packages in JSON format from this site. https://hugovk.github.io/top-pypi-packages/ I used this script to download sdist packages from the JSON file. https://github.com/methane/notes/blob/master/2020/wchar-cache/download_sdis… Note that this script doesn't download packages without sdist (e.g. only universal wheel). It is because I have searched Python/C API. We can reduce the pain of the removal by fixing most of top 4000 packages. Regards, -- Inada Naoki <songofacandy(a)gmail.com>

2 1

Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
by Paul Sokolovsky 05 Jul '20

05 Jul '20

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'" <g.rodola(a)gmail.com> wrote: > From: > https://github.com/python/peps/commit/0c6427dcec1e98ca0bd46a876a7219ee4a934… > > > 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 <kearaberlin(a)gmail.com> > 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-ideas(a)python.org > > To unsubscribe send an email to python-ideas-leave(a)python.org > > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > > Message archived at > > https://mail.python.org/archives/list/python-ideas@python.org/message/AE2M7… > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > > -- > Giampaolo - gmpy.dev <https://gmpy.dev/about> -- Best regards, Paul mailto:pmiscml@gmail.com

24 50

Re: PEP 622: Structural Pattern Matching
by Shantanu Jain 04 Jul '20

04 Jul '20

Thank you for this PEP! Pattern matching is really exciting. As the PEP mentions and the thread evidences, the current dot syntax for the “constant value pattern” is a tricky point. Given this, I thought I’d throw another suggestion into the bikeshed. Use percent placeholder to indicate lookup (or even eval) semantics for a given name. For example: ``` FOO = 1 value = 0 match value: case %(FOO): # This would not be matched ... case BAR: # This would be matched ... ``` I like this syntax because it’s reminiscent of named substitution in percent formatted strings. It suggests a substitution / placeholder metaphor that is quite fitting. It has the benefit of not introducing a new symbol into Python and being explicit and hard to miss, including in nested contexts. Note, it seems like it would also be technically possible to use curly braces (the more idiomatic means of named substitution in Python 3): ``` case {FOO}: … ``` The main downside of this is that it could look like some sort of singleton “set pattern” (note that the PEP only supports “sequence patterns” and “mapping patterns”). (But set patterns maybe don’t quite make sense + if your set pattern had multiple elements you’d still get a SyntaxError. For other examples where something in Python looks like a set literal but isn’t, refer to `{}` and f-strings, so it’s maybe not the biggest stretch) Both of these suggestions could also allow us more flexibility for constant value patterns, since currently there isn't a good way to match against a constant expression. For example, we could extend this syntax to allow us to express: ``` case %(2 ** 10): ... ```

3 4

Re: PEP 622: Structural Pattern Matching
by Shantanu Jain 04 Jul '20

04 Jul '20

Thank you for this PEP! Pattern matching is really exciting. As the PEP mentions and the thread evidences, the current dot syntax for the “constant value pattern” is a tricky point. Given this, I thought I’d throw another suggestion into the bikeshed. Use percent placeholder to indicate lookup (or even eval) semantics for a given name. For example: ``` FOO = 1 value = 0 match value: case %(FOO): # This would not be matched ... case BAR: # This would be matched ... ``` I like this syntax because it’s reminiscent of named substitution in percent formatted strings. It suggests a substitution / placeholder metaphor that is quite fitting. It has the benefit of not introducing a new symbol into Python and being explicit and hard to miss, including in nested contexts. Note, it seems like it would also be technically possible to use curly braces (the more idiomatic means of named substitution in Python 3): ``` case {FOO}: … ``` The main downside of this is that it could look like some sort of singleton “set pattern” (note that the PEP only supports “sequence patterns” and “mapping patterns”). (But set patterns maybe don’t quite make sense + if your set pattern had multiple elements you’d still get a SyntaxError. For other examples where something in Python looks like a set literal but isn’t, refer to `{}` and f-strings, so it’s maybe not the biggest stretch) Both of these suggestions could also allow us more flexibility for constant value patterns, since currently there isn't a good way to match against a constant expression. For example, we could extend this syntax to allow us to express: ``` case %(2 ** 10): ... # or case {get_default()}: ... ```

1 0

[RELEASE] Python 3.9.0b4 is now ready for testing
by Łukasz Langa 03 Jul '20

03 Jul '20

On behalf of the entire Python development community, and the currently serving Python release team in particular, I’m pleased to announce the release of Python 3.9.0b4. Get it here: https://www.python.org/downloads/release/python-390b4/ <https://www.python.org/downloads/release/python-390b4/> This is a beta preview of Python 3.9 Python 3.9 is still in development. This release, 3.9.0b4, is the fourth of five planned beta release previews. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. Call to action We strongly encourage maintainers of third-party Python projects to test with 3.9 during the beta phase and report issues found to the Python bug tracker <https://bugs.python.org/> as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (2020-08-10). Our goal is have no ABI changes after beta 5 and as few code changes as possible after 3.9.0rc1, the first release candidate. To achieve that, it will be extremely important to get as much exposure for 3.9 as possible during the beta phase. Please keep in mind that this is a preview release and its use is not recommended for production environments. Major new features of the 3.9 series, compared to 3.8 Some of the new major new features and changes in Python 3.9 are: PEP 584 <https://www.python.org/dev/peps/pep-0584/>, Union Operators in dict PEP 585 <https://www.python.org/dev/peps/pep-0585/>, Type Hinting Generics In Standard Collections PEP 593 <https://www.python.org/dev/peps/pep-0593/>, Flexible function and variable annotations PEP 602 <https://www.python.org/dev/peps/pep-0602/>, Python adopts a stable annual release cadence PEP 615 <https://www.python.org/dev/peps/pep-0615/>, Support for the IANA Time Zone Database in the Standard Library PEP 616 <https://www.python.org/dev/peps/pep-0616/>, String methods to remove prefixes and suffixes PEP 617 <https://www.python.org/dev/peps/pep-0617/>, New PEG parser for CPython BPO 38379 <https://bugs.python.org/issue38379>, garbage collection does not block on resurrected objects; BPO 38692 <https://bugs.python.org/issue38692>, os.pidfd_open added that allows process management without races and signals; BPO 39926 <https://bugs.python.org/issue39926>, Unicode support updated to version 13.0.0; BPO 1635741 <https://bugs.python.org/issue1635741>, when Python is initialized multiple times in the same process, it does not leak memory anymore; A number of Python builtins (range, tuple, set, frozenset, list, dict) are now sped up using PEP 590 <https://www.python.org/dev/peps/pep-0590> vectorcall; A number of Python modules (_abc, audioop, _bz2, _codecs, _contextvars, _crypt, _functools, _json, _locale, operator, resource, time, _weakref) now use multiphase initialization as defined by PEP 489 <https://www.python.org/dev/peps/pep-0489/>; A number of standard library modules (audioop, ast, grp, _hashlib, pwd, _posixsubprocess, random, select, struct, termios, zlib) are now using the stable ABI defined by PEP 384 <https://www.python.org/dev/peps/pep-0384/>. (Hey, fellow core developer, if a feature you find important is missing from this list, let Łukasz know <mailto:lukasz@python.org>.) The next pre-release, the fifth beta release of Python 3.9, will be 3.9.0b5. It is currently scheduled for 2020-07-20. More resources Online Documentation <https://docs.python.org/3.9/> PEP 596 <https://www.python.org/dev/peps/pep-0596/>, 3.9 Release Schedule Report bugs at https://bugs.python.org <https://bugs.python.org/>. Help fund Python and its community <https://discuss.python.org/psf/donations/>. Your friendly release team, Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower> Łukasz Langa @ambv <https://discuss.python.org/u/ambv>

1 0