Mailman 3 July 2021 - Python-ideas

zip(x, y, z, strict=True)
by Ram Rachum Dec. 1, 2022

Dec. 1, 2022

Here's something that would have saved me some debugging yesterday: >>> zipped = zip(x, y, z, strict=True) I suggest that `strict=True` would ensure that all the iterables have been exhausted, raising an exception otherwise. This is useful in cases where you're assuming that the iterables all have the same lengths. When your assumption is wrong, you currently just get a shorter result, and it could take you a while to figure out why it's happening. What do you think?

27 179

disallow assignment to unknown ssl.SSLContext attributes
by Thomas Grainger June 10, 2022

June 10, 2022

I was debugging some code that was using TLSv1.2 when I expected it to only support TLSv1.3, I tracked it down to a call to: context.miunimum_version = ssl.TLSVersion.TLSv1_3 it should have been: context.minimum_version = ssl.TLSVersion.TLSv1_3 I'd like invalid attribute assignment to be prevented at runtime

13 32

Bringing the print statement back
by Guido van Rossum March 2, 2022

March 2, 2022

In Python 3.10 we will no longer be burdened by the old parser (though 3rd party tooling needs to catch up). One thing that the PEG parser makes possible in about 20 lines of code is something not entirely different from the old print statement. I have a prototype: Python 3.10.0a0 (heads/print-statement-dirty:5ed19fcc1a, Jun 9 2020, 16:31:17) [Clang 11.0.0 (clang-1100.0.33.8)] on darwin Type "help", "copyright", "credits" or "license" for more information. Cannot read termcap database; using … [View More]dumb terminal settings. >>> print 2+2 4 >>> print "hello world" hello world >>> print "hello", input("Name:") Name:Guido hello Guido >>> print 1, 2, 3, sep=", " 1, 2, 3 >>> But wait, there's more! The same syntax will make it possible to call *any* function: >>> len "abc" 3 >>> Or any method: >>> import sys >>> sys.getrefcount "abc" 24 >>> Really, *any* method: >>> class C: ... def foo(self, arg): print arg ... >>> C().foo 2+2 4 >>> There are downsides too, though. For example, you can't call a method without arguments: >>> print <built-in function print> >>> Worse, the first argument cannot start with a parenthesis or bracket: >>> print (1, 2, 3) 1 2 3 >>> C().foo (1, 2, 3) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: C.foo() takes 2 positional arguments but 4 were given >>> print (2+2), 42 4 (None, 42) >>> C().foo [0] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'method' object is not subscriptable >>> No, it's not April 1st. I am seriously proposing this (but I'll withdraw it if the response is a resounding "boo, hiss"). After all, we currently have a bunch of complexity in the parser just to give a helpful error message to people used to Python 2's print statement: >>> print 1, 2, 3 File "<stdin>", line 1 print 1, 2, 3 ^ SyntaxError: Missing parentheses in call to 'print'. Did you mean print(1, 2, 3)? >>> And IIRC there have been a number of aborted attempts at syntactic hacks to allow people to call functions (like print) without parentheses, although (I think) none of them made it into a PEP. The PEG parser makes this much simpler, because it can simply backtrack -- by placing the grammar rule for this syntax (tentatively called "call statement") last in the list of alternatives for "small statement" we ensure that everything that's a valid expression statement (including print() calls) is still an expression statement with exactly the same meaning, while still allowing parameter-less function calls, without lexical hacks. (There is no code in my prototype that checks for a space after 'print' -- it just checks that there's a name, number or string following a name, which is never legal syntax.) One possible extension I didn't pursue (yet -- dare me!) is to allow parameter-less calls inside other expressions. For example, my prototype does not support things like this: >>> a = (len "abc") File "<stdin>", line 1 a = (len "abc") ^ SyntaxError: invalid syntax >>> I think that strikes a reasonable balance between usability and reduced detection of common errors. I could also dial it back a bit, e.g. maybe it's too much to allow 'C().foo x' and we should only allow dotted names (sufficient to access functions in imported modules and method calls on variables). Or maybe we should only allow simple names (allowing 'len x' but disallowing 'sys.getrefcount x'. Or maybe we should really only bring back print statements. I believe there are some other languages that support a similar grammar (Ruby? R? Raku?) but I haven't investigated. Thoughts? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…> [View Less]

42 66

Adding a thin wrapper class around the functions in stdlib.heapq
by bunslow Feb. 17, 2022

Feb. 17, 2022

Nothing so bombastic this time. The heapq functions are basically all named "heapsomething", and basically all take a "heap" for their first argument, with supplementary args coming after. It's a textbook example of the (hypothetical) Object Oriented Manifesto™ where defining a class increases type safety and programmers' conceptual clarity. There're practically no drawbacks, and the code to be added would be very simple. Updating the tests and docs would probably be harder. In pure Python, … [View More]

17 32

Allow syntax "func(arg=x if condition)"
by Peter O'Connor Jan. 19, 2022

Jan. 19, 2022

I often find that python lacks a nice way to say "only pass an argument under this condition". (See previous python-list email in "Idea: Deferred Default Arguments?") Example 1: Defining a list with conditional elements include_bd = True current_way = ['a'] + (['b'] if include_bd else [])+['c']+(['d'] if include_bd else []) new_way = ['a', 'b' if include_bd, 'c', 'd' if include_bd] also_new_way = list('a', 'b' if include_bd, 'c', 'd' if include_bd) Example 2: Deferring to … [View More]

6 9

Python Documentation in Bengali (translation)
by sharifmehedi24＠outlook.com Sept. 16, 2021

Sept. 16, 2021

Hi there all, I am preparing a team to start translating python documentation to Bengali. I'd appreciate some reference materials, comments and ideas about this. Thank you

4 4

Create a @deprecated decorator (annotation)
by Leonardo Freua Aug. 15, 2021

Aug. 15, 2021

[Migrating from https://bugs.python.org/issue44701] Would it be interesting to create a @deprecated decorator to avoid adding warnings.warn("deprecation message", DeprecationWarning, stacklevel=2) in methods body? Using the decorator approach to indicate depreciation would make the methods cleaner (leaving only their responsibilities in the body) and would be easier to identify, as the cue would be close to the method signature and not mixed with the logic inside the body. in some cases it … [View More]

13 16

copy-paste code snippets to the python console
by Raymond Bisdorff Aug. 15, 2021

Aug. 15, 2021

Dear Python developers, It would be helpful, if the following issue with copy-pasting python code-snippets into the standard shell console, could be investigated and corrected. https://stackoverflow.com/questions/2501208/copying-and-pasting-code-into-t… In particular, copying and pasting from sphinx python and pycon code-blocks with copy button (only >>> and ... lines), is at present not generally working due to the "the shell-s de-indent cmd" need for empty lines. See … [View More]

2 1

More natural type hints for built-in containers
by Ignacio Pickering Aug. 1, 2021

Aug. 1, 2021

Currently type hints for built-in containers are, in my opinion, less succint than required. I suspect it is probably not very difficult for a type checker to interpret something like this for example: var1: {str: (int, int)} = {"label": (1, 2)} var2: {str} = {"other_label"} def function(param1: {int: str} = {1: "foo"}, param2: (int, ...) = (1, 2, 3)) -> (int, (str, ...)): return 3, ("foo", "bar") as equivalent to: var1: dict[str, tuple[int, int]] = {"label": (1, 2)} var2: set[str] = … [View More]

5 6

Possibility to specify port in __init__ of ftplib.FTP
by Marty July 31, 2021

July 31, 2021

Hi. If there is possible to connect and login to ftp server within __init__, I think it would make sense to add parameter **port** in ftplib.FTP. It could look like this: ``` def __init__(self, host='', port=0, user='', passwd='', acct='', timeout=_GLOBAL_DEFAULT_TIMEOUT, source_address=None, *, encoding='utf-8'): self.encoding = encoding self.source_address = source_address self.timeout = timeout if host: self.connect(host, port) … [View More]

2 1

Why do we have two obvious ways to create a simple data structure? Let's deprecate one.
by pavel＠lexyr.com July 29, 2021

July 29, 2021

[Migrating the discussion from https://bugs.python.org/issue44768.] PEP 20 says: > There should be one-- and preferably only one --obvious way to do it. There are two ways to create a simple named type to store data: collections.namedtuple and dataclasses.dataclass. I propose deprecating namedtuple. As far as the interface is concerned, the namedtuple is almost completely equivalent to a frozen dataclass - with some iterability syntactic sugar thrown in. I don't think there are use cases … [View More]

10 21

Make __class__ (and maybe other magic variables) visible to functions that was defined outside a class, but then rebound into a class?
by Yua July 27, 2021

July 27, 2021

For example, the following code would report an error: class base(): def foo(self) -> None: print('Base!') def placement(self) -> None: super().foo() class child(base): def foo(self) -> None: pass foo = placement child().foo() RuntimeError: super(): __class__ cell not found … [View More]

3 3

weakref.link: Keep A alive while B is alive (and/or update WeakKeyDictionary)
by Mark Gordon July 27, 2021

July 27, 2021

Proposal: Have a weakref.link (not at all attached to the naming) primitive that allows one to keep object A alive while object B is alive. This would be functionally similar to adding A as an attribute of B from the GC's perspective without making any assumptions about what attributes are available in B. Here's a really course example of how this might be used: # Associate "extra_data" with "obj" where "extra_data" will lose its reference when "obj" is no longer reachable through strong refs.… [View More]

3 3

Picking Up the Ball on Stuck PRs
by Jack DeVries July 25, 2021

July 25, 2021

Hi! I'm interested in this workflow issue of cpython pull requests that get tons of review and feedback, but, for whatever reason, ultimately lose the attention of the original contributor. I opened a GitHub issue on the dev guide repo where I wrote more about the problem, and proposed some solutions/ideas. I'm hoping that the issue might get more attention if I mentioned it here, too, so I'm wondering if you can take a moment to check it out and continue the conversation on GitHub. https://github.com/python/devguide/issues/731 Thanks!! Jack

1 0

RFC for PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors
by Ethan Furman July 21, 2021

July 21, 2021

PEP: 663 Title: Improving and Standardizing Enum str(), repr(), and format() behaviors Version: $Revision$ Last-Modified: $Date$ Author: Ethan Furman <ethan(a)stoneleaf.us> Discussions-To: python-dev(a)python.org Status: Draft Type: Informational Content-Type: text/x-rst Created: 23-Feb-2013 Python-Version: 3.11 Post-History: 20-Jul-2021 Resolution: Abstract ======== Now that we have a few years experience with Enum usage it is time to update the ``repr()``, ``str()``, and ``format()`` … [View More]of the various enumerations by their intended purpose. Motivation ========== The addition of ``StrEnum`` with its requirement to have its ``str()`` be its ``value`` is inconsistent with other provided Enum's ``str``. Having the ``str()`` of ``IntEnum`` and ``IntFlag`` not be the value causes bugs and extra work when replacing existing constants. Having the ``str()`` and ``format()`` of an enum member be different can be confusing. The iteration of ``Flag`` members, which directly affects their ``repr()``, is inelegant at best, and buggy at worst. Rationale ========= Enums are becoming more common in the standard library; being able to recognize enum members by their ``repr()``, and having that ``repr()`` be easy to parse, is useful and can save time and effort in understanding and debugging code. However, the enums with mixed-in data types (``IntEnum``, ``IntFlag``, and the new ``StrEnum``) need to be more backwards compatible with the constants they are replacing -- specifically, ``str(replacement_enum_member) == str(original_constant)`` should be true (and the same for ``format()``). IntEnum, IntFlag, and StrEnum should be as close to a drop-in replacement of existing integer and string constants as is possible. Towards that goal, the str() output of each should be its inherent value; e.g. if ``Color`` is an ``IntEnum``:: >>> Color.RED <Color.RED: 1> >>> str(Color.RED) '1' >>> format(Color.RED) '1' Note that format() already produces the correct output in 3.10, only str() needs updating. As much as possible, the ``str()`, ``repr()``, and ``format()`` of enum members should be standardized across the stardard library. The repr() of Flag currently includes aliases, which it should not; fixing that will, of course, already change its ``repr()`` in certain cases. Specification ============= There a three broad categories of enum usage: - standard: Enum or Flag a new enum class is created, and the members are used as ``class.member_name`` - drop-in replacement: IntEnum, IntFlag, StrEnum a new enum class is created which also subclasses ``int`` or ``str`` and uses ``int.__str__`` or ``str.__str__``; the ``repr`` can be changed by using the ``global_enum`` decorator - user-mixed enums and flags the user creates their own integer-, float-, str-, whatever-enums instead of using enum.IntEnum, etc. Some sample enums:: # module: tools.py class Hue(Enum): # or IntEnum LIGHT = -1 NORMAL = 0 DARK = +1 class Color(Flag): # or IntFlag RED = 1 GREEN = 2 BLUE = 4 class Grey(int, Enum): # or (int, Flag) BLACK = 0 WHITE = 1 Using the above enumerations, the following table shows the old and new behavior, while the last shows the final result: +-------------+----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | type | enum repr() | enum str() | enum format() | flag repr() | flag str() | flag format() | +-------------+----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | standard | 3.10 | | | | <Color.RED|GREEN: 3> | Color.RED|GREEN | Color.RED|GREEN | | +----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | | new | | | | <Color(3): RED|GREEN> | Color.RED|Color.GREEN | Color.RED|Color.GREEN | +-------------+----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ +-------------+----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | user mixed | 3.10 | | | 1 | <Grey.WHITE: 1> | | 1 | | +----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | | new | | | Grey.WHITE | <Grey(1): WHITE> | | Grey.WHITE | +-------------+----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ +-------------+----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | int drop-in | 3.10 | | Hue.LIGHT | | <Color.RED|GREEN: 3> | Color.RED|GREEN | | | +----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | | new | | -1 | | <Color(3): RED|GREEN> | 3 | | +-------------+----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ +-------------+----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | global | 3.10 | <Hue.LIGHT: -1> | Hue.LIGHT | Hue.LIGHT | <Color.RED|GREEN: 3> | Color.RED|GREEN | Color.RED|GREEN | | +----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | | new | tools.LIGHT | LIGHT | LIGHT | tools.RED|tools.GREEN | RED|GREEN | RED|GREEN | +-------------+----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ +-------------+----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | user mixed | 3.10 | <Grey.WHITE: 1 | Grey.WHITE | Grey.WHITE | <Grey.WHITE: 1> | Grey.WHITE | 1 | | +----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | | new | tools.WHITE | WHITE | WHITE | tools.WHITE | WHITE | WHITE | +-------------+----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ +-------------+----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | int drop-in | 3.10 | <Hue.LIGHT: -1> | Hue.LIGHT | | <Color.RED|GREEN: 3> | Color.RED|GREEN | | | +----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | | new | tools.LIGHT | -1 | | tools.RED|tools.GREEN | 3 | | +-------------+----------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ Which will result in: +-------------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | type | enum repr() | enum str() | enum format() | flag repr() | flag str() | flag format() | +-------------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | standard | <Hue.LIGHT: -1> | Hue.LIGHT | Hue.LIGHT | <Color(3): RED|GREEN> | Color.RED|Color.GREEN | Color.RED|Color.GREEN | +-------------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | user mixed | <Grey.WHITE: 1> | Grey.WHITE | Grey.WHITE | <Grey(1): WHITE> | Grey.WHITE | Grey.WHITE | +-------------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | int drop-in | <Hue.LIGHT: -1> | -1 | -1 | <Color(3): RED|GREEN> | 3 | 3 | +-------------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | global | tools.LIGHT | LIGHT | LIGHT | tools.RED|tools.GREEN | RED|GREEN | RED|GREEN | +-------------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | user mixed | tools.WHITE | WHITE | WHITE | tools.WHITE | WHITE | WHITE | +-------------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ | int drop-in | tools.LIGHT | -1 | -1 | tools.RED|tools.GREEN | 3 | 3 | +-------------+-----------------+------------+-----------------------+-----------------------+------------------------+-----------------------+ As can be seen, ``repr()`` is primarily affected by whether the members are global, while ``str()`` is affected by being global or by being a drop-in replacement, with the drop-in replacement status having a higher priority. Also, the basic ``repr()`` and ``str()`` have changed for flags as the old style was very clunky. The ``repr()`` for Enum vs Flag are different, primarily because the Enum ``repr()`` does not work well for flags. I like being able to tell whether an enum member is a Flag or an Enum based on the ``repr()`` alone, but am open to arguments for changing Enum's ``repr()`` to match Flag's. Backwards Compatibility ======================= My understanding is that ``str()`` and ``repr()`` output has much lower backwards compatibility requirements. Even so, I expect the majority of breakage to be in doc and unit tests. I'm less clear on the policy for ``format()``. Note that by changing the ``str()`` of the drop-in category, we will actually prevent future breakage when ``IntEnum``, et al, are used to replace existing constants. Mitigation ========== Normal usage of enum members will not change: ``re.ASCII`` can still be used as ``re.ASCII`` and will still compare equal to ``256``. If one wants their own enums in their own code to remain the same they will need to write their own base Enum class and then write the appropriate ``repr``, ``str()``, and ``format()`` methods (or copy them from the 3.10 enum module). Copyright ========= This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. [View Less]

1 0

Nested Dictionary Pointers and Logic - "flatten / nested iteration" Proposal
by Sven Voigt July 21, 2021

July 21, 2021

Hello Python-ideas, I am working with lots of JSON objects in my work and need to obtain JSON pointers to particular components of a JSON object. These pointers are defined as part of the JSON-LD specifications as relative IRIs and as part of the JSON-Schema specifications. However, I am not aware of these pointers being part of the JSON specification. The pointers are really straightforward and follow the same syntax as other IRIs (URLs) or file paths. For example, the following flatten … [View More]function illustrates the mapping of nested dictionaries and arrays to a single flat dictionary, where each nested key is mapped to a unique path. d = {"a": 1, "b": {"ba": 2, "bb": [{"bba": 3, "bbb": None}]}} flatten(d) >> {'a': 1, 'b/ba': 2, 'b/bb/0/bba': 3, 'b/bb/0/bbb': None} Not only does this conversion help in generating JSON pointers, but it helps with logic for nested data structures. Specifically, assume there is a dictionary, which includes nested dictionaries, lists, and tuples, and any of these elements are contained within another dictionary or that other dictionaries elements. Then it is not sufficient to simply compare the items of the two dictionaries to check whether the first is a subset of the other. However, the flat structures can be compared directly. 1. A nested dictionary is a subset of another nested dictionary. The flatten function ensures the nested dictionaries are not checked for equivalence but subset of. # Current {"a": 1, "c": {"d": 4}}.items() <= {"a": 1, "b": 2, "c": {"d": 4, "e": 5}}.items() >> False # Proposed flatten({"a": 1, "c": {"d": 4}}).items() <= flatten({"a": 1, "b": 2, "c": {"d": 4, "e": 5}}).items() >> True 2. A nested list or tuple is a subset of a dictionary. # Current {"a": 1, "c": [3]}.items() <= {"a": 1, "b": 2, "c": [3,3]}.items() >> False # Proposed flatten({"a": 1, "c": [3]}).items() <= flatten({"a": 1, "b": 2, "c": [3,3]}).items() >> True Note that these examples only have one level of nesting, but the flatten function must handle any level of nesting. For the current version of the flatten function, I essentially borrowed the JSON "dumps" source code. However, the dumps code doesn't utilize any other functions and I believe there may be a missing "nestedIter" function in python. This function could be used for JSON dumps or flatten or anytime someone wants to visit all nested elements of a dictionary and perform some operation. Therefore, I think this function could be included in the JSON library if python-ideas thinks that the pointers are very specific to JSON or the itertools library, where the nested iteration function could be generally used for all nested data types. Let me know what you think of this proposal and I am looking forward to your responses. Best, Sven [View Less]

5 10

binascii generalization
by Ronald Hoogenboom July 20, 2021

July 20, 2021

I see that the binascii module has several {a2b,b2a}_xyz functions for several flavors of ascii <-> binary conversions. But it misses a general base function set parameterized with a radix. It would be nice to add a generic set of {a2b|b2a}(s, radix=r, case={'u','l'}), where radix is a power of 2 < 36 (2, 4, 8, 16 or 32) and case is only significant for b2a, to cover all trivial ascii <-> binary conversions using an efficient native implementation. Most {a2b,b2a}_xyz can just … [View More]

1 0

builtins for running context managers
by Thomas Grainger July 17, 2021

July 17, 2021

currently lots of code manages contexts incorrectly by doing: ``` @dataclasses.dataclass class WrapCmgr: _cmgr: ContextManager[T] def __enter__(self) -> Wrapped[T]: return wrap(_cmgr.__enter__()) def __exit__(self, \, t: Type[BaseException] | None, v: BaseException, tb: types.TracebackType) -> bool: return _cmgr.__exit__(t, v, tb) ``` since https://bugs.python.org/issue44471 using `with WrapCmgr(cmgr()):` incorrectly raises an AttributeError rather than a … [View More]

5 12

Looking for a PEP sponsor
by Nick Humrich July 15, 2021

July 15, 2021

Hello Python Devs, In accordance to PEP 0, I am looking for a Python-core-developer to sponsor my new PEP. It is essentially a revisit of PEP 501. https:// github.com/nhumrich/peps/blob/master/pep-9999.rst <https://t.co/cCrqfWztAW?amp=1> Please let me know if you have questions, or would be interested in sponsoring this PEP. Nick Humrich

3 2

Advanced RGB Coloring
by z3ntl3discord＠gmail.com July 14, 2021

July 14, 2021

Hey dear community, I want to use advanced RGB Coloring in python for teminals. There are already some modules but not advancrd enough. I hope this feature will be added in the next python versions! ❤ I believe in this strong community, this will powerup our ascii designs in terminals most users made!

3 2

writelines2?
by sandhoners123＠gmail.com July 13, 2021

July 13, 2021

Right now, writelines is a very big misnomer to many python developers, especially beginners who would expect writelines to put new lines at the end of every element in the list My suggestion is to have either a writelines2 or a newline kwarg which does put new lines automatically at the end of every line written

13 21

Deprecation APIs and language tooling
by Sergei Lebedev July 13, 2021

July 13, 2021

Hi python-ideas, The subject is by no means new nor unique, and in fact has been discussed on python-ideas at least once <https://mail.python.org/archives/list/python-ideas@python.org/thread/OPY3E4…> before as well as in python/mypy#2403 <https://github.com/python/mypy/issues/2403>.. However, to date, there seems to be no standard way of deprecating things declaratively, and ~every major library has its own internal API for that. For example, * numpy.deprecate, * similar … [View More]

3 2

Re: Deprecation APIs and language tooling
by Blue July 12, 2021

July 12, 2021

This already exists as `warnings.DeprecationWarning` see the documentation here: https://docs.python.org/3/library/exceptions.html#DeprecationWarning That said, the fact that this is hidden by default [as seen here]( https://docs.python.org/3/library/warnings.html).. > Base category for warnings about deprecated features when those warnings are intended for other Python developers (ignored by default, unless triggered by code in `__main__`). ..makes it almost useless for most. Going back … [View More]

1 0

Pre PEP: Python Literals (was custom strings before)
by Thomas Güttler July 11, 2021

July 11, 2021

Thank you Guido, Chris, Matt and Richard for your feedback to my last email. Here is an updated version called "Template Literals". I am looking for a core developer who can sponsor this PEP. Please speak up if you want to help me. Regards, Thomas Güttler Source and updates: Pre-PEP 9999 <https://github.com/guettli/peps/blob/master/pep-9999.rst> PEP: 9999 Title: Template Literals Author: Thomas Güttler <info at thomas-guettler.de> Sponsor: TODO Status: Draft Type: Standards … [View More]Track Content-Type: text/x-rst </dev/peps/pep-0012> Created: 08-Jun-2021 Python-Version: TODO Post-History: 08-Jun-2021 ------------------------------ Contents - Abstract <#abstract> - Motivation <#motivation> - Rationale <#rationale> - Specification <#specification> - Security Implications <#security-implications> - Reference Implementation <#reference-implementation> - Alternative Ideas <#alternative-ideas> - Rejected Ideas <#rejected-ideas> - Open Issues <#open-issues> - References <#references> - Copyright <#copyright> Abstract <#id6> This PEP adds Template Literals to Python. To avoid code injection like XSS or SQL-injection Template Literals can help you to write save Python code. Template Literals provide an easy way to access the local and global variables (like f-strings), so that passing a dictionary to the Template is not necessary. Motivation <#id7> In the context of web development Python can do more than providing REST APIs via http. With the trend to Server-Side-Rendering, we face a fundamental question: How to create HTML with Python? If you use the FrOW pattern (HTML fragments over the wire) [1] <#frow>, then you will be writing small methods returning small HTML fragments. As a developer I want to pass escaped data into template literals to be as simple as possible. Rationale <#id8> Imagine you want to create a small HTML fragment in Python, and return it as HTTP-Response: HttpResponse(f''' <h1>Hi {name}</h1> Your messages: {messages}''') The problem in above example is, that no escaping gets done. In above example "name" and "messages" should be treated differently. The variable "name" should get escaped. For example if the name is "Mary & Bob", the result should be "Mary & Bob". The variable "messages" contains HTML which is already escaped. It should not be escaped again. Most frameworks have a way to do this conditional escaping. For example Django uses conditional_escape() <https://docs.djangoproject.com/en/3.2/ref/utils/#django.utils.html.conditio…> [2] <#id2> With the help of conditional_escape() the above problem could be solved like this: HttpResponse(f''' <h1>Hi {conditional_escape(name)}</h1> Your messages: {conditional_escape(messages)}''') This solution has two drawbacks: 1. It is too verbose. Typing "conditional_escape(...)" again and again is cumbersome. 2. If a conditional_escape() gets forgotten Cross-site scripting attacks could be possible, since malicious users could inject HTML. Specification <#id9> Template Literals use backticks (like JavaScript Template Literals <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_…> [3] <#id4>) Example: name = 'Mary & Bob' messages = `<ul><li>message1</li><li>message2</li></ul>` return HttpResponse(` <h1>Hi {name}</h1> Your messages: {messages} Today: {datetime.date.today()}`) Expressions within curly braces get handled liked in f-strings (PEP-498). The Template Literal creates an instance of the new class types.TemplateLiteral. types.TemplateLiteral has two attributes: - template: The raw string inside the backticks. - tokens: A list of tuples: (value, is_literal). For above example this would mean: template = ''' <h1>Hi {name}</h1> Your messages: {messages} Today: {datetime.date.today()}''' tokens = [ ('\n <h1>Hi ', True), ('Mary & Bob', False), ('</h1>\n Your messages: ', True), (<TemplateLiteral "<ul><li>message1</li><li>message2</li></ul>">, False), ('\n\n Today: ', True), (<datetime.date(2021, 6, 9)>, False) ] It is outside this PEP how a consumer of TemplateLiteral handles this data structure. For example the Django web framework could transform a TemplateLiteral to a SafeString like this: def template_literal_to_safestring(template_literal): return mark_safe( ''.join( [ conditional_escape(value) if not is_literal else value for (value, is_literal) in template_literal.tokens ] ) ) This PEP is not related or constraint to the Django framework. It is even not related to HTML. It can be used for any kind of templating. Security Implications <#id10> Template Literals can execute arbitrary code (like f-strings). Template Literals get created by Python developers, not by users. If you want to make templates available for users (for example if you develop a CMS), then please use a different solution. Reference Implementation <#id11> TODO Alternative Ideas <#id12> Instead of backticks for example t'...' could be used. Rejected Ideas <#id13> TODO Open Issues <#id14> TODO References <#id15> [1] <#id1> FrOW, "HTML Fragments Over the Wire". Frameworks like Unpoly, Hotwire or htmx. [2] <#id3> https://docs.djangoproject.com/en/3.2/ref/utils/#django.utils.html.conditio… [3] <#id5> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_… Copyright <#id16> This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. [View Less]

19 56

pathlib.Path(...).json() (again)
by Thomas Grainger July 10, 2021

July 10, 2021

It's been brought up a few times eg: https://github.com/python/cpython/pull/12465 but I really think it's time to be re-considered. Specifically I love being able to use `asyncio.to_thread(pathlib.Path(...).read_text, encoding="utf8")` It does exactly the right thing for me! It's great because it interacts with the event loop as few times as possible and uses only the RAM absolutely required. I'm looking to be able to do something like `asyncio.to_thread(pathlib.Path(...).json)` defined … [View More]

3 5