Martin Teichmann added the comment:
This is a years old issue, unfortunately it never got neither merged nor
rejected. I just rebased it and hope somebody could finish the review.
--
versions: +Python 3.11 -Python 3.8
___
Python tracker
<ht
New submission from Martin Teichmann :
Currently, fraction.Fractions can be generated from floats via their
as_integer_ratio method. This had been extended to also work with the Decimals
class. It would be more generic - and IMHO more Pythonic - to just allow any
data type, as long as it has
Change by Martin Teichmann :
--
keywords: +patch
pull_requests: +24705
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26064
___
Python tracker
<https://bugs.python.org/issu
Martin Teichmann added the comment:
Hi Andrew,
I still don't get your point. First, this is an extension to the asyncio
library, so concurrency is not an issue. And sure, if you call random methods
of an object without any reason the outcome won't be anything useful, why, in
yo
Martin Teichmann added the comment:
Yes, in the one-producer-many-consumers situation on can indeed to the trick
with the None. But this is just a clumsy hack, cancelling the tasks is IMHO
more in line with asyncio.
In the many-producers-one-consumer scenario this does not work. The one
Martin Teichmann added the comment:
I do not think that exposing the lists of futures does any good. I cannot come
up with a semantics that could be implemented with that other than the one
proposed.
Also I think that close() or cancel() is something a reader intuitively
understands, while
New submission from Martin Teichmann :
When working with queues, it is not uncommon that at some point the producer
stops producing data for good, or the consumer stops consuming, for example
because a network connection broke down or some user simply closed the session.
In this situation it
Change by Martin Teichmann :
--
keywords: +patch
pull_requests: +14061
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14227
___
Python tracker
<https://bugs.python.org/issu
Martin Teichmann added the comment:
I also thought about `.close()` but then found `.cancel()` more intuitive. But
intuition is not universal, so I am open to any wording.
--
___
Python tracker
<https://bugs.python.org/issue37
Martin Teichmann added the comment:
Given the reactions I gather "close" is a better name for the method, so I
changed it accordingly.
In the current implementation, items that had been put on the queue but not
processed yet still get processed after the close, and I think t
New submission from Martin Teichmann:
The arguments of a function which was decorated to be a context manager are
stored inside the context manager, and are thus kept alive.
This is a memory leak.
Example:
@contextmanager
def f(a):
do_something_with(a)
a = None
Changes by Martin Teichmann :
--
pull_requests: +1602
___
Python tracker
<http://bugs.python.org/issue30306>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin Teichmann added the comment:
I personally prefer the current situation. The problem is the following: when
an @contextmanager is first called, we don't know yet whether the user wants to
use it directly, or as a decorator, so we have to have some kind of hybrid
class. Once it'
Martin Teichmann added the comment:
Hi, so where do we go from here? I could write the proposed allow_recreation
flag, but IMHO this adds only dead code, as it is of no need at all. I don't
think code gets more clear by adding dead code...
I opted for one line more of comment, I think
New submission from Martin Teichmann :
asyncio.gather() returns a _GatheringFuture, which inherits from
asyncio.Future. This is weird in current asyncio, as futures are supposed to be
created with loop.create_future(). So I tried to reimplement gather() without
this weird special future. I
Change by Martin Teichmann :
--
keywords: +patch
pull_requests: +6388
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33413>
___
___
Py
Martin Teichmann added the comment:
I looked a bit into the details, and found that bpo-30048 created the described
weird behavior. There they fixed the problem that a cancel is ignored if a
coroutine manages to cancel its own task and return immediately. As shown in
the discussion there
New submission from Martin Teichmann:
This patch is supposed to facilitate using the asyncio
package on the command line. It contains two things:
First, a coroutine version of builtin.input, so that
it can be called while a asyncio event loop is running.
Secondly, it adds a new flag to
Martin Teichmann added the comment:
Hi Guido,
thanks for the quick response, so my response to your post:
to 1: thanks!
to 2: I am trying to put most of the stuff into a 3rd party module,
unfortunately I need changes in the python compiler, and given that
monkey patching is not so simple in
Martin Teichmann added the comment:
As promised, a new patch now for the current head.
Last time I apparently got confused with how hg
works, sorry.
--
Added file: http://bugs.python.org/file36623/patch2
___
Python tracker
<http://bugs.python.
Martin Teichmann added the comment:
well, I beg to differ. Again, to your points:
to a) You claim that my flag would have to be supported by every
python platform. Well, the very same built-in function has another
flag, PyCF_ONLY_AST, whose precise meaning, according to the docs,
"might c
Martin Teichmann added the comment:
Well, so I am giving up, apparenty my work is not wanted here.
But not before submitting at least the last version of my
patch. I seperated out my _input function into two, start_input
and continue_input, which are supposed to work in a loop
as in
Martin Teichmann added the comment:
And as a last comment, just for completeness, a complete
async console. With it you can do cool things like
>>> from asyncio import sleep, async
>>> def f():
...yield from sleep(3)
...print("done")
>>> yield from
New submission from Martin Teichmann:
Python behaves odd with regards to multiple inheritance and classes
written in C. I stumbled over this problem while working with PyQt4,
but soon realized that part of the problem is not actually in that
library, but is deep down in the CPython core. For
Martin Teichmann added the comment:
I've been working a bit on a solution to this issue, one proposal
is in the attached patch. The patch adds a new flag to tp_flags,
called Py_TPFLAGS_SOLID, which marks a class as being solid, i.e.
its memory layout is incompatible with its parent layo
Martin Teichmann added the comment:
I personally prefer the first patch, which iterates over a copy of __dict__.
Making a copy of a dict is actually a pretty fast operation, I would even
expect that it is faster than the proposed alternative, creating tuples.
Even if the second approach
New submission from Martin Teichmann:
when waiting for a gather that times out, everything works as expected, yet a
weird error message is logged. To give a minimal example:
import asyncio
@asyncio.coroutine
def main():
try:
sleep = asyncio.sleep(0.2
Changes by Martin Teichmann :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue29432>
___
___
Python-bugs-list mailing list
Unsubscrib
Martin Teichmann added the comment:
I added a solution to this problem. I just silence the bad error message by
overwriting _GatheringFuture.__del__ to do nothing. This may have undesired
side effects, though.
--
___
Python tracker
<h
New submission from Martin Teichmann:
This is the implementation of PEP 487.
It adds a metaclass to types that calls a method on a class
once it is subclassed. This way one can customize the creation
of classes without the need to write an own metaclass.
As a second functionality, it calls a
Martin Teichmann added the comment:
This is a C implementation of PEP 487, directly in the Python core
--
Added file: http://bugs.python.org/file43611/pep487a.patch
___
Python tracker
<http://bugs.python.org/issue27
Changes by Martin Teichmann :
Removed file: http://bugs.python.org/file43506/pep487.patch
___
Python tracker
<http://bugs.python.org/issue27366>
___
___
Python-bugs-list m
Martin Teichmann added the comment:
Currently, a class is created as follows: the compiler turns the class
statement into a call to __build_class__. This runs the class body. If
__class__ or super() is used within a method of the class, an empty PyCell is
created, to be filled later with the
Changes by Martin Teichmann :
Removed file: http://bugs.python.org/file38604/patch
___
Python tracker
<http://bugs.python.org/issue23722>
___
___
Python-bugs-list mailin
Changes by Martin Teichmann :
Removed file: http://bugs.python.org/file43765/pep487.patch
___
Python tracker
<http://bugs.python.org/issue23722>
___
___
Python-bugs-list m
Changes by Martin Teichmann :
Added file: http://bugs.python.org/file43766/pep487.patch
___
Python tracker
<http://bugs.python.org/issue23722>
___
___
Python-bugs-list m
Changes by Martin Teichmann :
Removed file: http://bugs.python.org/file43611/pep487a.patch
___
Python tracker
<http://bugs.python.org/issue27366>
___
___
Python-bug
Changes by Martin Teichmann :
Added file: http://bugs.python.org/file43834/pep487.patch
___
Python tracker
<http://bugs.python.org/issue27366>
___
___
Python-bugs-list m
Changes by Martin Teichmann :
Removed file: http://bugs.python.org/file43834/pep487.patch
___
Python tracker
<http://bugs.python.org/issue27366>
___
___
Python-bugs-list m
Changes by Martin Teichmann :
Added file: http://bugs.python.org/file43835/pep487.patch
___
Python tracker
<http://bugs.python.org/issue27366>
___
___
Python-bugs-list m
Martin Teichmann added the comment:
Thanks for the nice review!
I made the proposed changes, see attached patch.
I am still waiting for a decision whether type.__setattr__ should call
__set_name__ from python-dev, once that's sorted out I'll implement and test
the one or the othe
Martin Teichmann added the comment:
I looked over the patch once more and found some places where
I didn't follow normal coding standards. I changed that, namely
now the code returns -1 meaning an exception happened and 0 on
success, which is what many functions in typeobject.c do.
So I
New submission from Martin Teichmann:
Currently there is an assert statement asserting that no two
tasks (asyncio tasks, that is) can use StreamWriter.drain at
the same time. This is a weird limitiation, if there are two
tasks writing to the same network socket, there is no reason
why not both
New submission from Martin Teichmann:
When a new class is initialized with __init__ in a metaclass,
the __class__ cell of the class about to be initialized is not
set yet, meaning that super() does not work.
This is a known but fixable problem. The attached patch moves
the initialization of
Martin Teichmann added the comment:
A note on the implementation:
The compiler leaves a __cell__ entry in the class' namespace, which
is then filled by type.__new__, and removed from the namespace by
the latter. This is the same way it is done for __qualname__.
As the patch tampers wit
Martin Teichmann added the comment:
This is the originial patch rebased such that it applies to the current master.
As a detail in the discussion: "__classcell__" is not visible during the
execution of the class body, as it is added at the end of the class body. In
this reg
46 matches
Mail list logo
