With normal synchronous code you can use `contextvars.Context.run()` to change what context code is executing within. However, there is no analagous concept for asyncio code. I'm proposing something similar, for example:
coro = foo()
my_context = convextvars.Context()
await asyncio.run_in_context(coro)
Currently the workaround is to run the coroutine on a separate task.
coro = foo()
my_context = convextvars.Context()
await my_context.run(asycnio.create_task, coro)
However this is not exactlly the same as the task will inherit a copy of my_context rather than running directly on my_context. Additionally (obviously) it will also be running in a separate task.
Similarly it would be nice if create_task and the Task constructor could take an optional context kwarg to use as the task context rather than the default of copying the calling context.
Pull request with sample implementation (although I think missing the change to create_task): https://github.com/python/cpython/pull/26664
Off-topic
Someone on this list wrote:
Mu.
>
> https://en.wikipedia.org/wiki/Mu_(negative)#%22Unasking%22_the_question
This is a koan, a device in Zen Buddhism used by a teacher to help the
student liberate themselves from being imprisoned by rational discursive
thought.
Here is another koan.
A Zen student told Ummon: "Brilliancy of Buddha illuminates the whole
universe."
Before he finished the phrase Ummon asked: "You are reciting another's
poem, are you not?"
"Yes," answered the student.
"You are sidetracked," said Ummon.
Here's my commentary. The teacher neither agrees or disagrees with the
student's statement. This is "Mu" if you wish. Instead the teacher
directly observes the student's mental processes, confirms the observation,
and provides helpful advice.
The teacher is not trapped by rational discursive thought. Here the teacher
uses only 12 words. Sometimes a teacher uses a single word, or no words at
all.
You'll find this koan and further commentary at
https://www.sacred-texts.com/bud/glg/glg39.htm.
--
Jonathan
Hi all, I came across the following performance issue with the sum function
while summing lists: https://bugs.python.org/issue18305 It's been discussed
previously in this list and other issues.
The rationale in that ticket makes the case that performance won't be fixed
because sum() should not be treated as a generic way to concatenate
sequences (and there is documentation saying this).
Having non-linear complexity is not a suitable way to discourage this
behaviour though. Non-linearity is hard to detect in testing and
development, so is more likely to lead to performance bugs in libraries and
production, than to discourage use from the outset. Moreover, it is
confusing to end users to have a feature while discouraging its use through
a somewhat passive-aggressive runtime. New users, and experienced users who
do not pour through the documentation will use sum because it supports this
API, and one would assume that's intentional.
On the other hand, the behaviour for strings is a far superior
user-experience. When attempting to use sum() on strings, users are
presented with a TypeError and a handy tip (use "".join(seq) instead). It
is clear to users that they are attempting an anti-pattern and how to
correct it.
So I propose moving (eventually) to the same system with lists as for
strings. Or else removing the performance trip-hazard from the sum function
with lists.
Best regards,
Oliver
Python raises TypeError when NotImplemented is returned from __add__, __invert__ etc. and __radd__ etc. aren't available.
However, this disallows the customization of error messages. For example, in Python 3.8, __float__ etc. were removed from complex to allow methods like __rfloat__. But this makes abs(z) undiscoverable for many users. The original error message is very helpful.
I suggest to make a way for this usage. Maybe NotImplementedType can accept *args, and NotImplemented can be callable, equal to __init__:
>>> class A:
def __add__(self, other):
return NotImplemented # Just like before
def __neg__(self, other):
return NotImplemented(f'bad operand type for unary -: {type(self).__name__!r}; use ~ to invert') # <--
def __invert__(self):
return ~5
>>> a = A()
>>> a + 2
TypeError: unsupported operand type(s) for +: 'A' and 'int'
>>> -a
TypeError: bad operand type for unary -: 'A'; use ~ to invert
>>> ~a
-6
Functionalities are similar to Go channel but with topics or consumers like a message queue.
Possible syntax:
```python
async def main():
ch = Channel()
await ch.put(1) # put
await ch.get() # get
await ch.close() # close
c1 = ch.consumer()
c2 = ch.consumer()
async for data in c1: # two consumer are indpendent
...
async for data in c2: # async for syntax
...
```
Related project:
https://github.com/Drakkar-Software/Async-Channelhttps://github.com/tbug/aiochannelhttps://github.com/ebb29c/asyncio-channelhttps://github.com/navytux/pygolang
Though it can be implemented by using asyncio.Queue，If this can be added into the asyncio library?
Sometimes it would be useful to be able to write:
def foo():
try: return thing()
except ValueError;
try: return otherthing()
except ValueError;
try: return yetotherthing()
except ValueError;
if shouldraise(): raise
But currently this needs to be written like so:
def foo():
try: return thing()
except ValueError:
try: return otherthing()
except ValueError:
try: return yetotherthing()
except ValueError:
if shouldraise(): raise
Look at all that unnecessary indentation! Would be nice to get rid of it.
Many times a programmer would want a variable that will be a constant. The programmer could have been careless and suddenly changed a very important variable. Proposed syntax,
constant variable = 10
variable = 20 # Error
Now constant means making a variable value immutable. It means now we can neither change the variable to point to another value nor the value itself anymore. For example, if we have a list we cannot change it. If we try to then "Error". So for lists,
constant variable = ["List"]
variable.append("Some") # Error
variable = ["Another"] # Error
Usually if we have a constant we don't create another reference to it. So do not support two references. Why not? Many reasons, especially deallocation problems.
Thanking you,
With Regards
Hello all,
I recently opened a feature request for pytest (https://github.com/pytest-dev/pytest/issues/8768) to find out if a warnings filter capture anything.
Basic use-case: In big project with a lot of dependencies, the warnings filter list can grow a lot. Currently the only safe way to find out if a filter is still needed, is to remove it and then to run your code.
Therefore it would be nice to have a more automatic approach.
Suggestion for the warnings module: A new method wich returns all filtered warnings as well as the filter which caused the filtering.
The "capturing" could even be placed inside a context generator to avoid a unnecessary collection and a global state.
Afterwards it would be possible for tools like pytest to take a look at all applied filters and then to report, which filters were not applied.
Additional benefits: A user can e.g. see if a previous general written filter (e.g. without a module) can be more specific.
The syntax to define a class looks like this:
class MyClass:
pass
Nice and neat.
***
And the syntax to define a function looks like this:
def my_function():
pass
Hmmm...
***
What if we could define functions (that don't have any parameters) like this:
def my_function:
pass
***
Is that a possible scenario at this point, or even desirable?
Hi,
I have a crazy idea how to extend Python for web development.
What do you think? What are the next steps?
Original: https://github.com/guettli/python-custom-strings
Python Custom Strings
Python Custom Strings want to combine two great things:
- Python's f-strings
<https://docs.python.org/3/tutorial/inputoutput.html#formatted-string-litera…>
- Django's conditional_escape()
<https://docs.djangoproject.com/en/3.2/ref/utils/#django.utils.html.conditio…>
Python Custom Strings is a proposal to enhance Python, to give developers
new ways to create escaped strings.
The Python Custom Strings proposal is not related to Django or HTML. This
text uses HTML and Django just as an example.
<https://github.com/guettli/python-custom-strings/blob/main/README.md#motiva…>
Motivation
I could create HTML in Python with the help of Django's format_html()
<https://docs.djangoproject.com/en/3.2/ref/utils/#django.utils.html.format_h…>
like
this:
html = format_html('''
<h1>Hi {username}</h1>
Your messages: {messages}''',
username=username,
messages=messages
)
With "username" being a simple string that gets quoted. For example Mary &
Bob will get Mary & Bob.
With "messages" being a previously escaped string. For example
<ul><li>line1</li><li>line2</li></ul>. It does not get escaped, since it is
already escaped.
This "magic" detection whether escaping should be done or not gets handled
by conditional_escape()
<https://docs.djangoproject.com/en/3.2/ref/utils/#django.utils.html.conditio…>
.
<https://github.com/guettli/python-custom-strings/blob/main/README.md#goal>
Goal
I would like to shorten the above code to something similar to this:
html = h'''
<h1>Hi {username}</h1>
Your messages: {messages}'''
The developer should not need to type these line:
username=username,
messages=messages
These lines are meaningless and distracting. Avoiding them reduces the
cognitive load, especially for the reader of the code.
<https://github.com/guettli/python-custom-strings/blob/main/README.md#custom…>
Customization
To make this customizable, the user needs to define the methods which
should get used.
In the above example the h prefix of this snippet:
html = h'''
<h1>Hi {username}</h1>
Your messages: {messages}'''
Should be executed like
html = mark_safe('''
<h1>Hi {username}</h1>
Your messages: {messages}''',
username=conditional_escape(username),
messages=conditional_escape(message))
Python does not know about these methods mark_safe() and
conditional_escape().
So we need a way to define that.
<https://github.com/guettli/python-custom-strings/blob/main/README.md#defini…>Defining
custom strings
Somehow, there needs to be a definition of the custom strings. Up to now I
open concerning "how to define custom strings?".
The syntax could look like this:
register_custom_string('h', pre_return, pre_insert)
With pre_return() and pre_insert() being methods which get executed to
create the custom string.
In the above example you would use this:
register_custom_string('h', mark_safe, conditional_escape)
This is just a first idea. I guess there are better ways to define both
methods. Please speak up if you have a better idea.
The letter h is just an example. The developer should be able to choose his
prefered character. Replacing the already used letteres like r, b, u is not
possible and results in an exception.
TODO: What should happen if register_custom_string() gets called twice for
the same character?
<https://github.com/guettli/python-custom-strings/blob/main/README.md#what-i…>What
is inside curly braces?
In the above example, we just use a variable name. But having more is
better.
Custom strings are meant for developers, so arbitrary code execution is
fine.
Arbitrary code in curly braces should be allowed:
html = h'''...{my_object.my_method(some_arg)}...'''
<https://github.com/guettli/python-custom-strings/blob/main/README.md#why-no…>Why
not just this hack?
Instead of h'...' you could use this hack to get the desired implementation:
def h(html):
"""
Django's format_html() on steroids
"""
def replacer(match):
call_frame = sys._getframe(3)
return conditional_escape(
eval(match.group(1), call_frame.f_globals, call_frame.f_locals))
return mark_safe(re.sub(r'{(.*?)}', replacer, html))
The above implementation has one big drawback:
IDEs and linters don't know that variables get used inside the custom
string.
This means IDEs and linters think variables (or imports) don't get used and
act accordingly.
Nevertheless it makes no sense to type myvar=mvar again and again, just to
make IDEs/linters happy.
<https://github.com/guettli/python-custom-strings/blob/main/README.md#concer…>
Concerns
"Custom strings will downgrade Python to the level of PHP".
I think Separation of Concerns makes sense. But sometimes Locality of
Behaviour <https://htmx.org/essays/locality-of-behaviour/> makes more sense.
It really depends on the context. Sometimes it makes sense to have external
templates, sometimes it makes senes to have inline templates.
Don't judge this proposal just because your context never requires external
templates.
<https://github.com/guettli/python-custom-strings/blob/main/README.md#backgr…>
Background
If you use the html-fragments-over-the-wire approach to web development
(for example with htmx <https://htmx.org/>), then you create many small
methods returning small html snippets.
If you have small methods, then keeping the HTML inside one file together
with your Python logic simplifies the development process. (See Locality of
Behaviour (LoB) <https://htmx.org/essays/locality-of-behaviour/>)
I guess a lot of people won't like this. Nevertheless some people like to
mix Python and HTML. Those people who don't like this, still can create
HTML in the way they like it.
<https://github.com/guettli/python-custom-strings/blob/main/README.md#pep>
PEP?
Do you think this could make it to a PEP? Please let me know: Just create
an issue here at Github.
