Mailman 3 July 2016 - Python-ideas

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

Dec. 16, 2020

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 … [View More]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 [View Less]

10 15

Specify number of items to allocate for array.array() constructor
by Sven Rahmann Feb. 22, 2020

Feb. 22, 2020

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 … [View More]

14 20

Implicit string literal concatenation considered harmful?
by Guido van Rossum March 14, 2018

March 14, 2018

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 '+' … [View More]

51 165

https://docs.python.org/fr/ ?
by Julien Palard Feb. 2, 2017

Feb. 2, 2017

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 … [View More]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 [View Less]

7 8

proposal: "python -m foo" should bind sys.modules['foo']
by Cameron Simpson Jan. 18, 2017

Jan. 18, 2017

Hello all, This is a writeup of a proposal I floated here: https://mail.python.org/pipermail/python-list/2015-August/694905.html last Sunday. If the response is positive I wish to write a PEP. Briefly, it is a natural expectation in users that the command: python -m module_name ... used to invoke modules in "main program" mode on the command line imported the module as "module_name". It does not, it imports it as "__main__". An import within the program of "module_name" makes a new … [View More]instance of the module, which causes cognitive dissonance and has the side effect that now the program has two instances of the module. What I propose is that the above command line _should_ bind sys.modules['module_name'] as well as binding '__main__' as it does currently. I'm proposing that the python -m option have this effect (python pseudocode): % python -m module.name ... runs: # pseudocode, with values hardwired for clarity import sys M = new_empty_module(name='__main__', qualname='module.name') sys.modules['__main__'] = M sys.modules['module.name'] = M # load the module code from wherever (not necessarily a file - CPython # already must do this phase) M.execfile('/path/to/module/name.py') Specificly, this would have the following two changes to current practice: 1) the module is imported _once_, and bound to both its canonical name and also to __main__. 2) imported modules acquire a new attribute __qualname__ (analogous to the recent __qualname__ on functions). This is always the conanoical name of the module as resolved by the importer. For most modules __name__ will be the same as __qualname__, but for the "main" module __name__ will be '__main__'. This change has the following advantages: The current standard boilerplate: if __name__ == '__main__': ... invoke "main program" here ... continues to work unchanged. Importantly, if the program then issues "import module_name", it is already there and the existing instance is found and used. The thread referenced above outlines my most recent encounter with this and the trouble it caused me. Followup messages include some support for this proposed change, and some criticism. The critiquing article included some workarounds for this multiple module situation, but they were (1) somewhat dependent on modules coming from a file pathname and (2) cumbersome and require every end user to adopt these changes if affected by the situation. I'd like to avoid that. Cheers, Cameron Simpson <cs(a)zip.com.au> The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw [View Less]

5 13

Importing public symbols and simultainiously privatizing them, is too noisy
by Rick Johnson Dec. 29, 2016

Dec. 29, 2016

Has anyone else found this to be too syntactically noisy? from module import Foo as _Foo, bar as _bar That is horrifically noisy IMO. The problem is, how do we remove the noise without sacrificing intuitiveness? My first idea was to do this: from module import_private Foo, bar And while it's self explanatory, it's also too long. So i thought... from module _import Foo, bar I'm leaning more towards the latter, but i'm not loving it either. Any ideas?

9 17

Consider adding clip or clamp function to math
by Neil Girdhar Aug. 13, 2016

Aug. 13, 2016

It's common to want to clip (or clamp) a number to a range. This feature is commonly needed for both floating point numbers and integers: http://stackoverflow.com/questions/9775731/clamping-floating-numbers-in-pyt… http://stackoverflow.com/questions/4092528/how-to-clamp-an-integer-to-some-… There are a few approaches: * use a couple ternary operators (e.g. https://github.com/scipy/scipy/pull/5944/files line 98, which generated a lot of discussion) * use a min/max construction, * call … [View More]

19 60

Addition to operator module: starcaller
by Daniel Spitz Aug. 6, 2016

Aug. 6, 2016

Hello, I have run into a use case where I want to create a wrapper object that will star-unpack a sequence of arguments to pass to a function. Currently one way to construct this is to create a function: def starcaller(f): def wrapper(args): return f(*args) return wrapper Such a function feels simple enough, and specific enough to the language, that it would fit in well in the operator module of the standard library. We already have a similar representation of this … [View More]

7 11

Sequence views
by Serhiy Storchaka Aug. 4, 2016

Aug. 4, 2016

Maybe it's time to add a new module for sequence-specific functions (seqtools?). It should contain at least two classes or fabric functions: 1. A view that represents a sliced subsequence. Lazy equivalent of seq[start:end:step]. This feature is implemented in third-party module dataview [1]. 2. A view that represents a linear sequence as 2D array. Iterating this view emits non-intersecting chunks of the sequence. For example it can be used for representing the bytes object as a sequence … [View More]

8 11

proper naming of Enum members
by Ethan Furman Aug. 4, 2016

Aug. 4, 2016

There are currently a few locations in the stdlib, such as http and socket, that are now using Enums to replace constants; those names are all upper-case -- those aren't the names I am speaking of. The names I am speaking of are those in brand-new enumerations where we have full control. As an example: class FederalHoliday(AutoNumberEnum): NewYear = "First day of the year.", 'absolute', JANUARY, 1 MartinLutherKingJr = "Birth of Civil Rights leader.", 'relative', JANUARY, MONDAY, 3 … [View More] President = "Birth of George Washington", 'relative', FEBRUARY, MONDAY, 3 Memorial = "Memory of fallen soldiers", 'relative', MAY, MONDAY, 5 Independence = "Declaration of Independence", 'absolute', JULY, 4 Labor = "American Labor Movement", 'relative', SEPTEMBER, MONDAY, 1 Columbus = "Americas discovered", 'relative', OCTOBER, MONDAY, 2 Veterans = "Recognition of Armed Forces service", 'relative', NOVEMBER, 11, 1 Thanksgiving = "Day of Thanks", 'relative', NOVEMBER, THURSDAY, 4 Christmas = "Birth of Jesus Christ", 'absolute', DECEMBER, 25 def __init__(self, doc, type, month, day, occurance=None): self.__doc__ = doc self.type = type self.month = month self.day = day self.occurance = occurance def date(self, year): """ returns the observed date of the holiday for `year` """" ... @classmethod def next_business_day(cls, date, days=1): """ Return the next `days` business day from date. """ ... @classmethod def count_business_days(cls, date1, date2): """ Return the number of business days between 'date1' and 'date2'. """ ... @classmethod def year(cls, year): """ Return a list of the actual FederalHoliday dates for `year`. """ ... Take the name "NewYear": if it had been a global constant I would have named it "NEWYEAR"; if it had been a normal class attribute I would have named it "new_year"; however, being an Enum member, it is neither of those things. <context switch> I've written some custom data types as part of my dbf package, and a few of them have instances that are singletons that are created in the global (okay, module) namespace, and for them I followed Python's lead in naming singletons: Python has used Title Case in such things as None, True, and False, so I followed suit and named mine -- Null, NullDate, NullTime, NullDateTime, etc. </context switch> Given my past history with using and creating singleton objects, I followed suit when creating my own Enum classes. I was recently queried about my apparent break with PEP 8 for naming Enum members, to which I replied: > Considering the strange beast that an Enum is, there is not much precedent for it anywhere. > > Consider: > > - Enum is a class > - but it is a container > - and can be iterated over > - and it has a length (which can be zero) > - but it's always True in a boolean sense > > - Enum members are instances of the Enum class > - but are pre-created > - and new ones cannot be created > - but are available as attributes on the class > > Given all that I have been using Title case (or CamelCase) to name the members as it helps > distinguish an Enum member from an ordinary attribute (which Enum classes can also have). I forgot to include in that reply that I think CamelCase also helps to emphasize the special singleton nature of Enum members. My question for the community: Your thoughts/opinions of my reasoning, and if you don't agree then which casing choice would you recommend and use, and why? (Reminder: this question does not include Enums whose names are replacements for existing constants and so the names cannot be changed.) -- ~Ethan~ [View Less]

8 8

Making the stdlib consistent again
by Ralph Broenink Aug. 3, 2016

Aug. 3, 2016

Hi python-ideas, As you all know, the Python stdlib can sometimes be a bit of an inconsistent mess that can be surprising in how it names things. This is mostly caused by the fact that several modules were developed before the introduction of PEP-8, and now we're stuck with the older naming within these modules. It has been said and discussed in the past [1][2] that the stdlib is in fact inconsistent, but fixing this has almost always been disregarded as being too painful (after all, we don't … [View More]want a new Python 3 all over again). However, this way, we will never move away from these inconsistencies. Perhaps this is fine, but I think we should at least consider providing function and class names that are unsurprising for developers. While maintaining full backwards compatibility, my idea is that we should offer consistently named aliases in -eventually- all stdlib modules. For instance, with Python 2.6, the threading module received this treatment, but unfortunately this was not expanded to all modules. What am I speaking of precisely? I have done a quick survey of the stdlib and found the following examples. Please note, this is a highly opinionated list; some names may have been chosen with a very good reason, and others are just a matter of taste. Hopefully you agree with at least some of them: * The CamelCasing in some modules are the most obvious culprits, e.g. logging and unittest. There is obviously an issue regarding subclasses and methods that are supposed to be overridden, but I feel we could make it work. * All lower case class names, such as collections.defaultdict and collections.deque, should be CamelCased. Another example is datetime, which uses names such as timedelta instead of TimeDelta. * Inconsistent names all together, such as re.sub, which I feel should be re.replace (cf. str.replace). But also re.finditer and re.findall, but no re.find. * Names that do not reflect actual usage, such as ssl.PROTOCOL_SSLv23, which can in fact not be used as client for SSLv2. * Underscore usage, such as tarfile.TarFile.gettarinfo (should it not be get_tar_info?), http.client.HTTPConnection.getresponse vs set_debuglevel, and pathlib.Path.samefile vs pathlib.Path.read_text. And is it pkgutil.iter_modules or is it pathlib.Path.iterdir (or re.finditer)? * Usage of various abbreviations, such as in filecmp.cmp * Inconsistencies between similar modules, e.g. between tarfile.TarFile.add and zipfile.ZipFile.write. These are just some examples of inconsistent and surprising naming I could find, other categories are probably also conceivable. Another subject for reconsideration would be attribute and argument names, but I haven't looked for those in my quick survey. For all of these inconsistencies, I think we should make a 'consistently' named alternative, and alias the original variant with them (or the other way around), without defining a deprecation timeline for the original names. This should make it possible to eventually make the stdlib consistent, Pythonic and unsurprising. What would you think of such an effort? Regards, Ralph Broenink [1] https://mail.python.org/pipermail/python-ideas/2010-January/006755.html [2] https://mail.python.org/pipermail/python-dev/2009-March/086646.html [View Less]

18 29

size of the installation of Python on mobile devices
by Xavier de Gaye Aug. 3, 2016

Aug. 3, 2016

Issue 26852 [1] proposes an enhancement to reduce the size of the Python installation by using a sourceless distribution. It seems that discussion on this problem (the size of the Python installation on mobile devices) should be moved here. IMHO there is no need to debate on the fact that a full install of Python on a mobile device today is a problem. As a reference, here is a raw estimation of the sizes of the different installs: full install: 111M without the test suite: 53M … [View More]

11 28

An ABC representing "Iterable, Sized, Container"
by Guido van Rossum July 30, 2016

July 30, 2016

At Dropbox I see a lot of people who want to start using type annotations (PEP 484, mypy) struggle with the collection ABCs. It's pretty common to want to support both sets and lists of values, as these have a lot of useful behavior: they are (re)iterable, have a size, and implement `__contains__` (i.e. x in c, x not in c). It's pretty common for people to think that Iterable is the answer, but it's not. I'm beginning to think that it would be useful to add another ABC to collections.abc (and … [View More]

20 38

Re: [Python-ideas] Make types.MappingProxyType hashable
by אלעזר July 29, 2016

July 29, 2016

> Date: Thu, 28 Jul 2016 22:23:35 +0000 > From: Emanuel Barry <vgr255(a)live.ca> > To: "guido(a)python.org" <guido(a)python.org> > Cc: "python-ideas(a)python.org" <python-ideas(a)python.org> > Subject: Re: [Python-ideas] Make types.MappingProxyType hashable >> What real-world use case do you have for this? > Not me, actually. Someone in #python asked about an immutable dict, > and I pointed them towards mappingproxy, only to realize it wasn't … [View More]

1 0

Make types.MappingProxyType hashable
by Emanuel Barry July 29, 2016

July 29, 2016

Hello Python-ideas, While answering a question earlier today, I realized that types.MappingProxyType is immutable and unhashable. It seems to me that if all values are hashable (all keys are already guaranteed to be hashable), then the mappingproxy itself should be hashable. Should I go ahead and make a patch for this, or is this a bad idea? Cheers, -Emanuel

4 6

add jsonrpc to stdlib "Internet Protocols and Support" akin to xmlrpc
by Achim Andreas von Roznowski July 25, 2016

July 25, 2016

Hi I am new to this mailing list, hopefully this idea hasn't been raised already - I searched the PEPs and python-ideas and couldn't find anything similar, so decided to post this idea. Please forgive me if it is a duplicate. Idea: add jsonprc server and client to stdlib "Internet Protocols and Support" Details I would like to suggest adding a jsonrpc server and client to the stdlib "Internet Protocols and Support" with identical functionality to the existing xmlrpc.server and … [View More]

2 1

Good uses for staticmethod
by Edward Minnix July 24, 2016

July 24, 2016

Hello, I have been reading Luciano Ramalho’s Fluent Python, and in the book he says he cannot think of a good use for staticmethod, I have been thinking about that, and so far I have only thought of one good use case: when you have a version of a common function, e.g., sum, and you want to qualify it with a better name but something like sumLineItems would sound wrong (to me at least). Would this be a good choice for something like: class LineItem: . . . . . . . . def __add__(self, other): … [View More]

5 6

allow `lambda' to be spelled λ
by Stephan Houben July 21, 2016

July 21, 2016

Hi list, Here is my speculative language idea for Python: Allow the following alternative spelling of the keyword `lambda': λ (That is "Unicode Character 'GREEK SMALL LETTER LAMDA' (U+03BB).") Background: I have been using the Vim "conceal" functionality with a rule which visually replaces lambda with λ when editing Python files. I find this a great improvement in readability since λ is visually less distracting while still quite distinctive. (The fact that λ is syntax-colored as a … [View More]

30 79

Error handling for unknown Unicode characters (was Re: allow `lambda' to be spelled λ)
by Nick Coghlan July 21, 2016

July 21, 2016

On 21 July 2016 at 15:08, Rustom Mody <rustompmody(a)gmail.com> wrote: > My “wrongheaded” was (intended) quite narrow and technical: > > - The embargo on non-ASCII everywhere in the language except identifiers > (strings > and comments obviously dont count as “in” the language > - The opening of identifiers to large swathes of Unicode widens as you say > hugely the surface area of attack > > This was solely the contradiction I was pointing out. OK, thanks … [View More]

2 3

Re: [Python-ideas] allow `lambda' to be spelled λ
by David Mertz July 21, 2016

July 21, 2016

This idea of "visually confusable" seems like a very silly thing to worry about, as others have noted. It's not just that completely different letters from different alphabets may "look similar", it's also that the similarity is completely dependent on the specific font used for display. My favorite font might have clearly distinguished glyphs for the Cyrillic, Roman, and Greek "A", even if your font uses identical glyphs. So in this crazy scenario, Python would have to gain awareness of the … [View More]fonts installed in every text editor and display device of every user. On Jul 21, 2016 12:55 AM, "Chris Angelico" <rosuav(a)gmail.com> wrote: On Thu, Jul 21, 2016 at 5:47 PM, Rustom Mody <rustompmody(a)gmail.com> wrote: >> On Thu, Jul 21, 2016 at 4:26 PM, Rustom Mody <rusto...(a)gmail.com> wrote: >> > IOW >> > 1. Disallow co-existence of confusables (in identifiers) >> > 2. Identify confusables to a normal form — like case-insensitive >> > comparison >> > and like NKFC >> > 3. Leave the confusables to confuse >> > >> > My choice >> > 1 better than 2 better than 3 >> >> So should we disable the lowercase 'l', the uppercase 'I', and the >> digit '1', because they can be confused? What about the confusability >> of "m" and "rn"? O and 0 are similar in some fonts. And case >> insensitivity brings its own problems - is "ss" equivalent to "ß", and >> is "ẞ" equivalent to either? Turkish distinguishes between "i", which >> upper-cases to "İ", and "ı", which upper-cases to "I". >> >> We already have interminable debates about letter similarities across >> scripts. I'm sure everyone agrees that Cyrillic "и" is not the same >> letter as Latin "i", but we have "AАΑ" in three different scripts. >> Should they be considered equivalent? I think not, because in any >> non-trivial context, you'll know whether the program's been written in >> Greek, a Slavic language, or something using the Latin script. But >> maybe you disagree. Okay; are "BВΒ" all to be considered equivalent >> too? What about "СC"? "XХΧᚷ"? They're visually similar, but they're >> not equivalent in any other way. And if you're going to say things >> should be considered equivalent solely on the basis of visuals, you >> get into a minefield - should U+200B ZERO WIDTH SPACE be completely >> ignored, allowing "AB" to be equivalent to "A\u200bB" as an >> identifier? >> >> > > I said 1 better than 2 better than 3 > Maybe you also want to add: > > Special cases aren't special enough to break the rules. > Although practicality beats purity. > > followed by > > Errors should never pass silently. > > IOW setting out 1 better than 2 better than 3 does not necessarily imply its > completely achievable No; I'm not saying that. I'm completely disagreeing with #1's value. I don't think the language interpreter should concern itself with visually-confusing identifiers. Unicode normalization is about *equivalent characters*, not confusability, and I think that's as far as Python should go. ChrisA _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ [View Less]

1 0

@Override decorator
by Shrey Desai July 20, 2016

July 20, 2016

Python Ideas, While working on some object-oriented projects in Java, I noticed that Python does not have an @override decorator for methods that are derived from a parent class but overridden for the unique purposes of a base class. With the creation of the @abstractmethod decorator, the override decorator could follow in clearly distinguishing the logic and design between parent/base classes. Why I would think an override decorator might be useful: For other people reading the code, it … [View More]

10 18

Cross-platform pickling of Path objects
by Antony Lee July 16, 2016

July 16, 2016

Hi all, I have opened http://bugs.python.org/issue27175 a month and a half ago but didn't get any feedback there, so I'll copy-paste it here for comments: Currently, pickling Path objects lead to issues when working across platforms: Paths (and, thus, objects that contain Paths) created on a POSIX platform (PosixPaths) cannot be unpickled on Windows and vice versa. There are a few possibilities around this issue. - Don't do anything about it, you should use PurePaths if you care about cross-… [View More]

3 3

Use unbound bytes methods with objects supporting the buffer protocol
by Serhiy Storchaka July 14, 2016

July 14, 2016

Unbound methods can be used as functions in python. bytes.lower(b) is the same as b.lower() if b is an instance of bytes. Many functions and methods that work with bytes accept not just bytes, but arbitrary objects that support the buffer protocol. Including bytes methods: >>> b'a:b'.split(memoryview(b':')) [b'a', b'b'] But the first argument of unbound bytes method can be only a bytes instance. >>> bytes.split(memoryview(b'a:b'), b':') Traceback (… [View More]

4 4

Re: [Python-ideas] allow `lambda' to be spelled ?
by אלעזר July 14, 2016

July 14, 2016

`def` is a much more readable alternative, which will be more familiar to newcomers. The expression/block ambiguity can be resolved using different token instead of colon (perhaps := or an arrow). I can't understand the reaching for the Greek letter - it is a computer-science specific term with no intuitive meaning. On Thu, Jul 14, 2016 at 4:49 PM <python-ideas-request(a)python.org> wrote: > Send Python-ideas mailing list submissions to > python-ideas(a)python.org > … [View More]> To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/python-ideas > or, via email, send a message with subject or body 'help' to > python-ideas-request(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-ideas digest..." > > > Today's Topics: > > 1. Re: allow `lambda' to be spelled ? (David Mertz) > 2. Re: Use unbound bytes methods with objects supporting the > buffer protocol (Nick Coghlan) > 3. Re: allow `lambda' to be spelled ? (Random832) > 4. Re: allow `lambda' to be spelled ? (SW) > 5. Re: allow `lambda' to be spelled ? (Chris Angelico) > 6. Re: allow `lambda' to be spelled ? (SW) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 13 Jul 2016 23:39:26 -0700 > From: David Mertz <mertz(a)gnosis.cx> > To: "Steven D'Aprano" <steve(a)pearwood.info> > Cc: python-ideas <python-ideas(a)python.org> > Subject: Re: [Python-ideas] allow `lambda' to be spelled ? > Message-ID: > < > CAEbHw4aVKCXLu2DC7K6ArxVHAjOkc15yk+irtPKfBa5xEy0G2A(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Wed, Jul 13, 2016 at 7:44 PM, Steven D'Aprano <steve(a)pearwood.info> > wrote: > > > - suppose that reading ? has a *tiny* benefit of 1% over "lambda" > > (for those who have learned what it means); > > - but typing it is (lets say) 50 times harder than typing "lambda"; > > - but we read code 50 times as often as we type it; > > - so the total benefit (50*1.01 - 50) is positive. > > > I actually *do* think ? is a little bit more readable. And I have no idea > how to type it directly on my El Capitan system with the ABC Extended > keyboard. But I still get 100% of the benefit in readability simply by > using vim's conceal feature. If I used a different editor I'd have to hope > for a similar feature (or program it myself), but this is purely a display > question. Similarly, I think syntax highlighting makes my code much more > readable, but I don't want colors for keywords built into the language. > That is, and should remain, a matter of tooling not core language (I don't > want https://en.wikipedia.org/wiki/ColorForth for Python). > > FWIW, my conceal configuration is at link I give in a moment. I've > customized a bunch of special stuff besides lambda, take it or leave it: > > http://gnosis.cx/bin/.vim/after/syntax/python.vim > > -- > Keeping medicines from the bloodstreams of the sick; food > from the bellies of the hungry; books from the hands of the > uneducated; technology from the underdeveloped; and putting > advocates of freedom in prisons. Intellectual property is > to the 21st century what the slave trade was to the 16th. > [View Less]

1 0

Proposal to add const-ness type hints to PEP-484
by Siva Chandra July 11, 2016

July 11, 2016

Hello, I have submitted a proposal to add const-ness type hint constructs here: https://github.com/python/typing/issues/242 Looking for feedback on the proposal. Thanks, Siva Chandra

2 1