Mailman 3 January 2017 - Python-ideas

@classproperty, @abc.abstractclasspropery, etc.
by K. Richard Pixley 16 Dec '20

16 Dec '20

There's a whole matrix of these and I'm wondering why the matrix is currently sparse rather than implementing them all. Or rather, why we can't stack them as: class foo(object): @classmethod @property def bar(cls, ...): ... Essentially the permutation are, I think: {'unadorned'|abc.abstract}{'normal'|static|class}{method|property|non-callable attribute}. concreteness implicit first arg type name comments {unadorned} {unadorned} method def foo(): exists now {unadorned} {unadorned} property @property exists now {unadorned} {unadorned} non-callable attribute x = 2 exists now {unadorned} static method @staticmethod exists now {unadorned} static property @staticproperty proposing {unadorned} static non-callable attribute {degenerate case - variables don't have arguments} unnecessary {unadorned} class method @classmethod exists now {unadorned} class property @classproperty or @classmethod;@property proposing {unadorned} class non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract {unadorned} method @abc.abstractmethod exists now abc.abstract {unadorned} property @abc.abstractproperty exists now abc.abstract {unadorned} non-callable attribute @abc.abstractattribute or @abc.abstract;@attribute proposing abc.abstract static method @abc.abstractstaticmethod exists now abc.abstract static property @abc.staticproperty proposing abc.abstract static non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract class method @abc.abstractclassmethod exists now abc.abstract class property @abc.abstractclassproperty proposing abc.abstract class non-callable attribute {degenerate case - variables don't have arguments} unnecessary I think the meanings of the new ones are pretty straightforward, but in case they are not... @staticproperty - like @property only without an implicit first argument. Allows the property to be called directly from the class without requiring a throw-away instance. @classproperty - like @property, only the implicit first argument to the method is the class. Allows the property to be called directly from the class without requiring a throw-away instance. @abc.abstractattribute - a simple, non-callable variable that must be overridden in subclasses @abc.abstractstaticproperty - like @abc.abstractproperty only for @staticproperty @abc.abstractclassproperty - like @abc.abstractproperty only for @classproperty --rich

10 15

Specify number of items to allocate for array.array() constructor
by Sven Rahmann 21 Feb '20

21 Feb '20

At the moment, the array module of the standard library allows to create arrays of different numeric types and to initialize them from an iterable (eg, another array). What's missing is the possiblity to specify the final size of the array (number of items), especially for large arrays. I'm thinking of suffix arrays (a text indexing data structure) for large texts, eg the human genome and its reverse complement (about 6 billion characters from the alphabet ACGT). The suffix array is a long int array of the same size (8 bytes per number, so it occupies about 48 GB memory). At the moment I am extending an array in chunks of several million items at a time at a time, which is slow and not elegant. The function below also initializes each item in the array to a given value (0 by default). Is there a reason why there the array.array constructor does not allow to simply specify the number of items that should be allocated? (I do not really care about the contents.) Would this be a worthwhile addition to / modification of the array module? My suggestions is to modify array generation in such a way that you could pass an iterator (as now) as second argument, but if you pass a single integer value, it should be treated as the number of items to allocate. Here is my current workaround (which is slow): def filled_array(typecode, n, value=0, bsize=(1<<22)): """returns a new array with given typecode (eg, "l" for long int, as in the array module) with n entries, initialized to the given value (default 0) """ a = array.array(typecode, [value]*bsize) x = array.array(typecode) r = n while r >= bsize: x.extend(a) r -= bsize x.extend([value]*r) return x

14 20

Implicit string literal concatenation considered harmful?
by Guido van Rossum 14 Mar '18

14 Mar '18

I just spent a few minutes staring at a bug caused by a missing comma -- I got a mysterious argument count error because instead of foo('a', 'b') I had written foo('a' 'b'). This is a fairly common mistake, and IIRC at Google we even had a lint rule against this (there was also a Python dialect used for some specific purpose where this was explicitly forbidden). Now, with modern compiler technology, we can (and in fact do) evaluate compile-time string literal concatenation with the '+' operator, so there's really no reason to support 'a' 'b' any more. (The reason was always rather flimsy; I copied it from C but the reason why it's needed there doesn't really apply to Python, as it is mostly useful inside macros.) Would it be reasonable to start deprecating this and eventually remove it from the language? -- --Guido van Rossum (python.org/~guido)

51 165

Using Python for end user applications
by Paul Moore 15 Feb '17

15 Feb '17

On 28 January 2017 at 02:11, C Anthony Risinger <anthony(a)xtfx.me> wrote: > I can't articulate it we'll, or even fully isolate the reasons for it. All I > really know is how I feel when peers ask me about Python or the reading I > get when others speak about their experience using it. Python is absolutely > one of my favorite languages to write, yet I find myself recommending > against it, and watching others do the same. Python comes with caveats and > detailed explanations out the gate and people simply perceive higher > barriers and more chores. Picking up on this and the comment you made in the original post > With a still difficult distribution/compatibility story, I've watched dozens of instances > where people choose something else, usually Node or Golang. Can you explain why you recommend against Python, in a bit more detail? If you are an enthusiastic Python user, but you are steering people away from Python, then it would be worth understanding why. As you mention end user applications and distribution, one of my first questions would be what platform you work on. Following on from that, what sort of end user applications are you looking at? If we're talking here about games for iOS, then that's a much different situation than GUI apps for Windows or command line tools for Linux. My personal feeling is that Python happily works in the "Command line tools for Linux" area (except possibly with regard to C extensions where the plethora of Linux ABIs makes things hard). But other areas less so. I've been having good experiences making standalone applications with the new Windows "embedded" distributions, but that is relatively new, and still has a lot of rough edges. I'm working on a project to bundle a working zipapp with the embedded distribution to make a standalone exe - would having something like that make any difference in your environment? So I think it would be good to understand precisely where and why you feel that you need to recommend Go or Node over Python. It's possible that we have to accept that your situation is simply not a use case that Python is well suited for, but equally it may be that there's something we can do. Paul

5 5

Is it Python 3 yet?
by Victor Stinner 07 Feb '17

07 Feb '17

Hi, The download button of https://www.python.org/ currently gives the choice between Python 2.7 and 3.6. I read more and more articles saying that we reached a point where Python 3 became more popular than Python 2, Python 3 has now enough new features to convince developers, etc. Is it time to "hide" Python 2.7 from the default choice and only show Python 3.6 *by default*? For example, I expect a single big [DOWNLOAD] button which would start the download of Python 3.6 for my platform. If we cannot agree on hiding Python 2 by default, maybe we can at least replace the big [DOWNLOAD] button of Python 2 with a smaller button or replace it with a link to a different download page? Latest news: Django 2.0 and Pyramid 2.0 will simply drop Python 2 support. Victor

19 27

OS related file operations (copy, move, delete, rename...) should be placed into one module
by George Fischhof 02 Feb '17

02 Feb '17

Hi There, OS related file operations (copy, move, delete, rename...) should be placed into one module... As it quite confusing that they are in two moduls (os and shutil). I have read that one is higher level than other, but actually to use them I have to think which function can be found in which module. It is confuse for beginners, and makes the usage more complex instead of make it more simple (as Zen of Python says ;-) ) An alias could good, not to cause incompatibility. Best regards, George

5 6

https://docs.python.org/fr/ ?
by Julien Palard 02 Feb '17

02 Feb '17

o/ The french translation of the Python Documentation [1][2] has translated 20% of the pageviews of docs.python.org. I think it's the right moment to push it do docs.python.org. So there's some questions ! And I'd like feedback. TL;DR (with my personal choices): - URL may be "http://docs.python.org/fr/" - For localized variations of languages we should use dash and lowercase like "docs.python.org/pt-br/" - po files may be hosted on the python's github - existing script to build doc may be patched to build translations - each translations may crosslink to others - untranslated strings may be visually marked as so I also opened: http://bugs.python.org/issue26546. # Chronology, dependencies The only blocking decision here is the URL, (also reviewing my patch ...), with those two, translated docs can be pushed to production, and the other steps can be discussed and applied one by one. # The URL ## CCTLD vs path vs subdomain I think we should use a variation of "docs.python.org/fr/" for simplicity and clarity. I think we should avoid using CCTLDs as they're sometime hard or near impossible to obtain (may cost a lot of time), also some are expensive, so it's time and money we clearly don't need to loose. Last possibility I see is to use a subdomain, like fr.docs.python.org or docs.fr.python.org but I don't think it's the role / responsibility of the sub-domain to do it. So I'm for docs.python.org/LANGUAGE_TAG/ (without moving current documentation inside a /en/). ## Language tag in path ### Dropping the default locale of a language I personally think we should not show the region in case it's redundant: so to use "fr" instead of "fr-FR", "de" instead of "de-DE", but keeping the possibility to use a locale code when it's not redundant like for "pt-br" or "de-AT" (German ('de') as used in Austria ('AT')). I think so because I don't think we'll have a lot of locale variations (like de-AT, fr-CH, fr-CA, ...) so it will be most of the time redundant (visually heavy, longer to type, longer to read) but we'll still need some locale (pt-BR typically). ### gettext VS IETF language tag format gettext goes by using an underscore between language and locale [3] and IETF goes by using a dash [4][5]. As sphinx is using gettext, and gettext uses underscore we may choose underscore too. But URLs are not here to leak the underlying implementation, and the IETF looks like to be the standard way to represent language tags. Also I visually prefer the dash over the underscore, so I'm for the dash here. ### Lower case vs upper case local tag RFC 5646 section-2.1 tells us language tags are not case sensitive, yet ISO3166-1 recommends that country codes (part of the language tag) be capitalized. I personally prefer the all-lowercase one as paths in URLs typically are lowercase. I searched for `inurl:"pt-br"` to see if I'm not too far away from the usage here and usage seems to agree with me, although there's some "pt-BR" in urls. # Where to host the translated files Currently we're hosting the *po* files in the afpy's (Francophone association for python) [6] github [1] but it may make sense to use (in the generation scripts) a more controlled / restricted clone in the python github, at least to have a better view of who can push on the documentation. We may want to choose between aggregating all translations under the same git repository but I don't feel it's useful. # How to Currently, a python script [7] is used to generate `docs.python.org`, I proposed a patch in [8] to make this script clone and build the french translation too, it's a simple and effective way, I don't think we need more ? Any idea welcome. In our side, we have a Makefile [12] to build the translated doc which is only a thin layer on top of the Sphinx Makefile. So my proposed patch to build scripts "just" delegate the build to our Makefile which itself delegate the hard work to the Sphinx Makefile. # Next ? ## Document how to translate Python I think I can (should) write a documentation on "how to start a Python doc translation project" and "how to migrate existing [9][10][11] python doc translation projects to docs.python.org" if french does goes docs.python.org because it may hopefully motivate people to do the same, and I think our structure is a nice way to do it (A Makefile to generate the doc, all versions translated, people mainly working on latest version, scripts to propagating translations to older version, etc...). ## Crosslinking between existing translations Once the translations are on `docs.python.org`, crosslinks may be established so people on a version can be aware of other version, and easily switch to them. I'm not a UI/UX man but I think we may have a select box right before the existing select box about version, on the top-left corner. Right before because it'll reflect the path: /fr/3.5/ -> [select box fr][select box 3.5]. ## Marking as "untranslated, you can help" the untranslated paragraphs The translations will always need work to follow upstream modifications: marking untranslated paragraphs as so may transform the "Oh they suck, this paragraph is not even translated :-(" to "Hey, nice I can help translating that !". There's an opened sphinx-doc ticket to do so [13] but I have not worked on it yet. As previously said I'm real bad at designing user interfaces, so I don't even visualize how I'd like it to be. [1] http://www.afpy.org/doc/python/3.5/ [2] https://github.com/afpy/python_doc_fr [3] https://www.gnu.org/software/gettext/manual/html_node/Locale-Names.html [4] http://tools.ietf.org/html/rfc5646 [5] https://en.wikipedia.org/wiki/IETF_language_tag [6] http://www.afpy.org/ [7] https://github.com/python/docsbuild-scripts/ [8] http://bugs.python.org/issue26546 [9] http://docs.python.jp/3/ [10] https://github.com/python-doc-ja/python-doc-ja [11] http://docs.python.org.ar/tutorial/3/index.html [12] https://github.com/AFPy/python_doc_fr/blob/master/Makefile [13] https://github.com/sphinx-doc/sphinx/issues/1246 -- Julien Palard

7 8

A decorator to call super()
by Roberto Martínez 01 Feb '17

01 Feb '17

Hi, I find this type of code quite often: class MyOverridedClass(MyBaseClass): def mymethod(self, foo, **kwargs): # Do something return super().mymethod(**kwargs) What about creating a decorator to call super() after/before the overrided method? Something like that: class MyOverridedClass(MyBaseClass): @extendsuper def mymethod(self, foo): # Do something Sorry if this has already been proposed, I have not found anything similar in the list. Best regards, Roberto

9 11

A more readable way to nest functions
by Brent Brinkley 31 Jan '17

31 Jan '17

HI Everyone, I’m relatively new to the world of python but in my short time here I’ve fallen in love with how readable this language is. One issue that I’ve seen in a lot of languages struggle with is nested function calls. Parenthesis when nested inherently create readability issues. I stumbled upon what I believe is an elegant solution within the elm platform in their use of the backward pipe operator <|. Current Ex. Suggested Structure This aligns with the Zen of Python in the following ways Simple is better than complex Flat is better than nested Sparse is better than dense Readability counts Practicality beats purity Ways it may conflict Explicit is better than implicit Special cases aren't special enough to break the rules Just curious to see what the rest of the community thinks 😊 Best Regards, Brent

13 16

What are your opinions on .NET Core vs Python?
by Gerald Britton 29 Jan '17

29 Jan '17

It's an apples/oranges comparison. .NET is a library that can be used from many languages, including Python. (Not just IronPython, but also Python for .NET (pythonnet.sourceforge*.*net *))* Python is a language that can use many libraries, including .NET The set of libraries that can be used from all the languages that can also use .NET (out of the box, that is) is smaller.

2 1