Mailman 3 April 2020 - Python-ideas

macaddress or networkaddress module
by Pete Wicken 06 Apr '20

06 Apr '20

Currently in Python 3 we have an ipaddress module which allows easy manipulation of IP version 4 and 6 addresses and networks. Examples of this are getting the packed bytes representation of an address, checking if an address is of a specific type according to the RFC (private, multicast, etc.) My proposal is that we have something with a similar API for MAC addresses. A lot of these operations that we have for IPv4 and IPv6 addresses are also applicable for MAC addresses. We can take in concatenated, hyphenated or dotted notations. Some of the methods could include packed is_multicast is_broadcast is_universal get_oui and optionally format outputs dotted(upper=False) hyphenated(upper=False) concatenated(upper=False) get_oui could initially just return the OUI part of the address without resolving. However, it is possible that on build of Python we pull down the latest OUIs from IEEE into a python file. My initial thought if people are in agreement was to have a macaddress.py module. However if the APIs for these are similar enough, perhaps it warrants having a networkaddress.py module that contains both the old ipaddress code and the new macaddress code? I would be grateful to hear people's thoughts on this. Pete Wicken

5 9

Changing Package Representation On Shell
by Abdur-Rahmaan Janhangeer 03 Apr '20

03 Apr '20

After a question i asked on python-list, Let's say i have a package. >>> import package >>> package <module 'package' from '<path>'> would it be nice to be able to change the repr of the package to >>> package package something some message .... ? Thanks! Kind Regards, Abdur-Rahmaan Janhangeer compileralchemy.com <https://www.compileralchemy.com> | github <https://github.com/Abdur-rahmaanJ/> Mauritius

7 20

Re: Explicitly defining a string buffer object (aka StringIO += operator)
by Steven D'Aprano 02 Apr '20

02 Apr '20

On Tue, Mar 31, 2020 at 12:39:56AM -0700, Christopher Barker wrote: > But while the OP specifically suggested adding += to stringIO, you might > note that he did not suggest it as an extension to the file protocol, which > StringIO mimics. Rather, he suggested that there should be something that > can be used as an efficient buffer to build up strings, that had the same > API as str does. He figures that it would be pretty easy to get that by > adding += to StringIO. > > But wouldn’t a mutable string type satisfy that as well? Indeed it would, and if I ask for a nutcracker to crack open peanuts a nuclear powered 200 tonne bulldozer would satisfy the requirements too. What Paul asked for: https://media.qcsupply.com/media/catalog/product/cache/122b61bfb663175d7f1b… What we're talking about instead: http://media.firebox.com/pic/p1861_column_grid_12.jpg If you want a mutable string type, you have to support a rather extensive string API that includes at least ten operators: + * % == != in < <= >= > plus slicing and about 45 methods. (There may be some things I have missed.) Paul asked for *one* operator, `+=`. > And why WOULD folks that want a buffer to build strings in use string > concatenation? Maybe because in the end they want a string? But even if > StringIO grew +=, then they get a StringIO object at the end, and would > need to call .getvalue() to get a str. Yes, rather like the way you have to call `''.join(buf)` if you use a list. If your point is a criticism of the StringIO proposal, it is equally a criticism of the recommended list+join idiom, but we still tell people to use list+join, so it can't be a very important issue. And if it's not a valid criticism of the list+join idiom, or at least a very minor, unimportant one, then precisely the same applies to StringIO. > So how exactly does this meet the use case of being able to drop it into > code that’s written to use strings? This has been covered at least twice, once by Paul and once by me. When you are refactoring the "string concatenation" idiom to list append, you have to change three things: 1. the buffer initialisation: `buf = ''` --> `buf = []`; 2. add a conversion to the end: `result = ''.join(buf)`; 3. and potentially dozens of instances of `buf += s` to `buf.append(s)`. The third may be scattered around multiple functions. It is not always an easy refactoring. We should not assume that every append to the buffer will be in a single place or even a single function. Under Paul's suggestion, you change the buffer initialisation, add the conversion, and nothing else needs to be touched. You also get a performance boost (by my testing, using StringIO is about halfway in speed between string concat and list+join), and potentially a memory saving relative to the list version. (Although Paul's calculations on that have been disputed, and I don't think we have a definite answer on that one just yet.) > BTW, what about folks that concatenaste strings with plain + ? You couldn’t > drop StringIO in there reasonably either. Do you mean people who write `buf = buf + substring`? Maybe that's an argument to support `+` as well. Perhaps it would be weird and surprising to support augmented assignment for an operator without supporting the operator? But I don't have a strong feeling either way. Or maybe that's just an argument that no solution is going to solve *every* problem. What do we do about people who write this: buf = f'{buf}{substring}' inside a loop? We can't fix everyone's code with one change. > If we want to provide a way for folks to not do naive string concatenation— > adding += to StringIO is not any better than telling them to use a list and > .join() — it’s still a whole other way of doing it. It's not really. The point is to minimise how many things need to change. Instead of changing every `buf += s` into `buf.append(s)`, you just leave them alone. In that regard, it's *the same way* of doing it, the only difference is that the buffer changes from an immutable string to a builder. We should be careful to avoid exaggerating tiny differences, especially when that involves a double-standard. Is it a problem for the recommended list+join idiom that it is "a whole other way of doing it"? If no, then its not a problem for StringIO either. If the answer is yes, then StringIO is no worse than what people are already told to do, so it's not really much of a problem. > And the list and join() method uses two of the most common builtins— there > is a real advantage to that. Again, we must beware of double-standards. This list often says: "Not everything needs to be a builtin, just put it in a module." Also this list: "Being a builtin is a real advantage, we can't use StringIO because it comes from a module that needs importing." We can't have it both ways. In this case, using StringIO does involve one extra import. Okay, that's fine, the standard library is full of things that require one extra import but nevertheless are a common, or even sometimes recommended, way to do it. itertools comes to mind especially, using iterators in Python is ubiquitous and yet we still require people to import a module to do something as fundamental as slice an iterator. But maybe we can consider an alternative that doesn't require that import. > Anyway, I’m not proposing a mutable string type. It was really just an > example of: if this was really needed, it would have been done. Ah, so by that argument, *every* new proposal can be immediately rejected. If this were really needed, it would have already been done. Python 3.8 is the optimal language with literally every single desirable feature, nothing to be added, and no unneeded cruft to be removed. I trust that's not what you intended to say :-) -- Steven

2 3

PEP 9999: Retire animal-unfriendly language
by Gerrit Holl 01 Apr '20

01 Apr '20

(needs a sponsor) latest version at https://github.com/gerritholl/peps/blob/animal-friendly/pep-9999.rst PEP: 9999 Title: Retire animal-unfriendly language Author: Gerrit Holl <gerrit.holl(a)gmail.com> Discussions-To: python-ideas(a)python.org Status: Draft Type: Informational Content-Type: text/x-rst Created: 01-Apr-2020 Post-History: 01-Apr-2020 Sponsor: Abstract ======== Python has long used metasyntactic variables that are based on the consumption of meat and dairy products, such as "spam", "ham", and "eggs". This language is not considerate to pigs or chicken and violates the spirit of the Code of Conduct. This PEP proposes to retire the use of those names in official Python documentation and source code and to recommend users of Python to do the same. Motivation and Rationale ======================== Estimates for the number of animals slaughtered for meat every year vary, but `worldindata`_ estimates around 80 billion individuals. Farmed animals are often kept in small cages with little to no access to daylight, suffer stress during life and slaughter, or are otherwise systematically mistreated. The `Python Code of Conduct`_ describes that community members are open, considerate, and respectful. The Python standard library and documentation contain numerous references to meat or dairy based food products that are not respectful to our fellow inhabitants of planet Earth. Examples include "spam", "bacon", and "eggs". To align the language use in the standard library and documentation with the Code of Conduct, use of such language should be retired. Current practice ================ There is a widespread tradition in the Python standard library, the documentation, and the wider community, to include references to Monty Pythons Flying Circus. The use of "spam", "bacon", "sausage", and "eggs" can be traced back to the `"Spam" sketch`_ originally broadcast by the British Broadcasting Corporation (BBC) on 8 September 1972. In this sketch, a couple are trying to order food in a diner where all items contain spam. The woman does not like spam and wants to order food without spam. A group of horned vikings then sing about the wonderful spam. To get an overview of the usage in the current standard library, the command ``cat $(find . -name '*.py') | grep -oi term | wc -l`` was used. This showed 2615 occurences for spam, 593 for ham (this include some false positives, among other reasons due to references to people whose name innociously contains the substring ham), 517 for eggs, 57 for bacon, and 10 for sausage. Searching ``*.rst`` in the documentation revealed 391 occurrences for spam, 82 for ham, 96 for eggs, 28 for bacon, and 10 for sausage. The source code for cpython revealed just 2 usages for spam and 1 for eggs. Proposed alternatives ===================== Keeping with the good practice of referencing sketches from Monty Python's Flying Circus, this PEP proposes to adopt the fruits mentioned in the `"Self-Defence Against Fresh Fruit" sketch`_: * raspberry (not currently in use) * banana (68 times in standard library) * apricot (not currently in use) * pineapple (8 times in standard library) * peach (once in standard library) * redcurrant (not currently in use) * damson (not currently in use) * prune (23 times in standard library) Other possible alternatives keeping with food items: * salad (occurs once in standard library) * aubergine (referred to in the spam sketch) * shallot (the same) * tofu (vegan protein alternative) Specification ============= For the reasons mentioned in the rationale, all references to meat or dairy products shall be removed from the Python standard library, the documentation, and the cpython source code. The wider Python community is recommended to follow this practice. In core Python: * Programmers SHALL NOT use the metasyntactic variables "spam", "ham", "bacon", or "sausage", neither as variable names, nor in example strings, nor in documentation. * Programmers SHALL NOT use the metasyntactic variable "eggs" in context with food items, but may still use it in context of other body parts. Prohibited: ``["salad", "eggs"]``. Allowed: ``["ovaries", "pouch", "eggs"]``. * Programmers SHALL NOT use any other metasyntactic variable that is unfriendly to animals. The wider Python community is encouraged to adopt these practices as well, but the continued use of animal-unfriendly metasyntactic variables will not be considered a violation of the code of conduct. Rejected ideas ============== The authors carefully considered the widespread use of the word "bug" in the meaning of a source code error. Insects including bugs play a crucial role in ecosystems around the world, and it is not fair to blame them for an error that can only be the programmer's. However, the use of the word "bug" for a source code error is too much ingrained into daily use, it far predates the Python community, is not limited to the Python community, and the word "bug" is less unfriendly than "spam", "ham", or "bacon". Therefore, the word "bug" may still be used. Reference Implementation ======================== The author promises to provide a reference implementation for Python 3.10, should this PEP be accepted. References ========== .. _worldindata: https://ourworldindata.org/meat-production .. _Python code of conduct: https://www.python.org/psf/conduct/ .. _"Spam" sketch: http://www.montypython.net/scripts/spam.php .. _"Self-Defence Against Fresh Fruit" sketch: http://www.montypython.net/scripts/fruit.php Copyright ========= This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

17 24