New submission from Ilya Kulakov :
The wrapper created by singledispatchmethod does not (trivially) expose
registry of all known overloads.
Consider the following example:
@singledispatchmethod
def on_message(message):
raise NotImplementedError
@on_message.register
Ilya Kulakov added the comment:
> That is not true, is actually encouraged to check for singletons like True,
> False and None.
You're right, just never used it as I never needed an identity check against
True / False
The PR is re-done to use an additional property call_event i
Ilya Kulakov added the comment:
As far as I understand it introduces 3 methods that may clash. It's unlikely
but (I speculate)
is still more likely than an identity check with called.
That being said, the PR can be redone as a subclass. But that implementation
will not play
as nicely
Ilya Kulakov added the comment:
> Unfortunately, we take backwards compatibility very seriously in the core
> team and this is a big downside of this proposal.
Current implementation relies on that:
1. called is almost never used in practice (people just use .assert*)
2. The is True /
Ilya Kulakov added the comment:
Correct, it is not backward compatible in that respect. I did not check
thoroughly, but a quick lookup shown no such use among public repos on GitHub.
I can instead add the called_event property and make the CallEvent “public”.
Best Regards
Ilya Kulakov
Change by Ilya Kulakov :
--
nosy: +Ilya.Kulakov
nosy_count: 11.0 -> 12.0
pull_requests: +19958
pull_request: https://github.com/python/cpython/pull/20759
___
Python tracker
<https://bugs.python.org/issu
Ilya Kulakov added the comment:
I have submitted an alternative implementation of this feature heavily inspired
by _AwaitEvent I wrote for asynctest [0].
There was recently an interest from the community towards asynctest to the
point that got some of its measures merged into CPython [1
Change by Ilya Kulakov :
--
pull_requests: +16643
pull_request: https://github.com/python/cpython/pull/17133
___
Python tracker
<https://bugs.python.org/issue17
Change by Ilya Kulakov :
--
pull_requests: +16639
pull_request: https://github.com/python/cpython/pull/17130
___
Python tracker
<https://bugs.python.org/issue26
Change by Ilya Kulakov :
--
pull_requests: +16640
pull_request: https://github.com/python/cpython/pull/17130
___
Python tracker
<https://bugs.python.org/issue29
Ilya Kulakov added the comment:
Perhaps another path is optionally allow hashing of memoryviews (all current
conditions - hashability of the original object) via a parameter? Like
unsafe_hash like in dataclass.
--
status: pending -> o
Ilya Kulakov added the comment:
True, but perhaps it's too strict to require both memoryview and the
represented object to be immutable?
The logic is as follows:
Every object in Python can be seen as a view of some outside data (in memory,
on disk etc.). And while Python's runtime may
New submission from Ilya Kulakov :
Implementation of memoryview's hashing method [1] imposes the following
constraints in order to be hashable (per documentation):
> One-dimensional memoryviews of hashable (read-only) types with formats ‘B’,
> ‘b’ or ‘c’ are also hashable. The hash is d
Ilya Kulakov added the comment:
Also hit this issue while trying to run venv on Travis.
Perhaps venv should detect if it's running under virtualenv (e.g. the
VIRTUAL_ENV env is present) and issue a warning?
--
nosy: +Kentzo
___
Python tracker
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
cancel will work in my case, but it's somewhat limited.
In other hand it's probably a job of a testing library to provide an utility
function.
--
___
Python tracker <rep...@bugs.p
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
Andrew, Yury
I test my lib against dev versions of Python and recently got an error in one
of the tests due to the deprecation.
I do not argue the reason behind removing this methods, but Task.set_exception
was working for me in
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
Is there anything to be done for this patch to get merged?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
Do you need any help with the change?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
Can you suggest an alternative to ProcessPoolExecutor for 3.6?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
Charyl, I made the PR.
Where is the AbstractAsyncContextManager? I see that typing.py references it,
but there is no actual implementation.
--
___
Python tracker <rep...@bugs.p
Change by Ilya Kulakov <kulakov.i...@gmail.com>:
--
keywords: +patch
pull_requests: +4690
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
That's a better workaround:
class X(typing.Generic[T]):
def __init_subclass__(cls, **kwargs):
super(typing.GenericMeta, cls).__setattr__('_gorg', cls)
super().__init_subclass__(**
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
Nah, that's a bad one: you cannot use Generic classes as intended by specifying
types.
It looks like it happens because cls._grog is not yet set properly by the time
__init_subclass__ is
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
Current workaround is
class X(typing.Generic[T] if typing.TYPE_CHECKING else object):
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
This issue is more server that I expected: it doesn't just propagate value to
superclasses, but overrides them. The last subclass created by Python runtime
will overwrite value for the whole
New submission from Ilya Kulakov <kulakov.i...@gmail.com>:
When superclass inherits from Generic, attributes set for a subclass are
incorrectly propagated to its superclass.
Without Generic attribute access raises an exception:
class X:
def __init_subclass__(cls, **
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
Victor, it's very helpful to analyze which Python stack caused exceptions in
native code on user's machines.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
Please ignore everything I said about AddVectoredContinueHandler. I finally got
a chance to test the code on Windows and the way it's called is not suitable
for faulthandler.
--
___
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
Steve, the difficulty with SetUnhandledExceptionFilter is that it can replace
filter installed by the user (e.g. one of loaded libraries).
The information about AddVectoredContinueHandler is scarce, but according to
what I found
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
Another option is to use AddVectoredContinueHandler [1]. It seems to be called
if both VEH and SEH failed to handle the error.
1:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms679273(v=vs.85
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
I think faulthandler should use both. E.g. in [1] you can read about an
exception that can be handled by AddVectoredExceptionHandler but not
SetUnhandledExceptionFilter.
Perhaps implementation should use SetUnhandledException
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
May I ask why AddVectoredExceptionHandler is used instead of
SetUnhandledExceptionFilter?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
I have fixed that problem by ensuring that ctypes-facing code passes bytes, not
strings.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
That's the change that introduced the bug:
https://github.com/python/cpython/pull/2285
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
Victor,
Does this change imply that no python-traceback-for-every-thread will be
printed upon both handled and unhandled C++ exception?
--
nosy: +Ilya.Kulakov
___
Python tracke
New submission from Ilya Kulakov <kulakov.i...@gmail.com>:
Happens on 3.6.3 only:
>>> import ctypes
>>> ctypes.cast('\0', ctypes.c_void_p)
ctypes.ArgumentError: argument 1: : embedded null character
--
components: ctypes
messages: 306307
nosy: Ilya.Kulakov
p
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
Not a bug in Python.
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bugs.
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
nvm my last question.
My process is as per README: ./configure && make
I'll take a further look at what's wrong.
--
___
Python tracker <rep...@bugs.python.org>
<
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
Just compiling Python 3.6.3 from sources on Ubuntu 16.04
Is there any reason to fall back to XML_POOR_ENTROTPY when proper source is
actually available?
--
___
Python tracke
New submission from Ilya Kulakov <kulakov.i...@gmail.com>:
Python 3.5 and 3.6 in their corresponding configure.ac try to detect presence
of sys_getrandom. The result is written into the `HAVE_GETRANDOM_SYSCALL`
definition.
libexpact checks for `HAVE_SYSCALL_GETRANDOM` and sinc
Ilya Kulakov <kulakov.i...@gmail.com> added the comment:
Can this be included into the next bugfix release?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ilya Kulakov added the comment:
I think either loop's signal handler should not be called from a subprocess or
at the very least, os.getpid / os.getpgrp should report correctly.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.p
New submission from Ilya Kulakov:
It looks like a signal delivered to multiprocessing's process implicitly
created by ProcessPoolExecutor triggers signal handler in the parent:
```
from concurrent.futures import ProcessPoolExecutor
import asyncio
import os
import signal
import sys
import time
Ilya Kulakov added the comment:
> On Python 3.5, PyUnicode_FSConverter() uses MBCS, which is CP-1552 on your
> system.
Will the behavior of Python 3.6 be different? Could you point me to relevant
notes or code?
> If I understood correctly, it's possible to work around the issue by
Ilya Kulakov added the comment:
Christian,
If you have windows under your hand and can try an alike path, you should see
the problem right away if it's still there.
I think the original problem was unnecessary PyUnicode_FSConverter: it failed
to encode string into mbcs, while OpenSSL did
New submission from Ilya Kulakov:
There are 2 venvs. One has the pkg_resources (pkgr_venv) package installed,
another (venv) doesn't.
Venv without pkg_resources is currently active.
Works: $ /python -c "import pkg_resources"
Doesn't work: $ python -c "im
Ilya Kulakov added the comment:
> but at the same time rejected by the 'async with' statement.
Perhaps unittest.mock (or type) needs to be adjusted to allow mocking via spec=
without subclassing?
> By all means you can submit a PR!
I'll take
Ilya Kulakov added the comment:
I'm not sure about type() to get a class object and calling __aenter__,
__aexit__ through it: that makes it hard to mock these classes as Mock's spec=
relies on __class__ and type() seem to ignore it (learned it a hard way.
Yury, I could take a second look
New submission from Ilya Kulakov:
As per documentation, it should understand the same arguments as IPv*Network.
Unfortunately it does not recognize netmask in string form. Hence the following
code will fail:
ipaddress.ip_interface(('192.168.1.10', '255.255.255.0'))
while the following
Ilya Kulakov added the comment:
You can initialize ip_interface via a tuple of 2 elements: IP address and a
prefix (prefixlen or string representation of a netmask).
I believe the issue can be closed now.
--
nosy: +Ilya.Kulakov
___
Python tracker
New submission from Ilya Kulakov:
See this post: https://github.com/kennethreitz/requests/issues/3578
The current workaround for requests is to have a no-op import somewhere in the
code.
However, that doesn't really work for us: our python and stdlib are bundled by
pyqtdeploy as in Qt
Ilya Kulakov added the comment:
I was not able to reproduce it.
The origin "unhandeled" exception happens after ctypes.cdll.LoadLibrary fails
to load a library:
Traceback (most recent call last):
File "...", line 852, in ...
File ":/ctypes/__init__.py", l
New submission from Ilya Kulakov:
I'm using Python 3.5.2 to be precise. I have code that is roughly equivalent to:
import sys
import traceback
def handle_exception(exc_type, exc_value, exc_traceback):
traceback.TracebackException(exc_type, exc_value, exc_traceback
Changes by Ilya Kulakov <kulakov.i...@gmail.com>:
--
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24699>
___
_
New submission from Ilya Kulakov:
When SSLContext cannot be created, python raises an SSLError exception with
"failed to allocate SSL context".
https://hg.python.org/cpython/file/4def2a2901a5/Modules/_ssl.c#l2260
This is completely useless to debug the error. In fact many errors r
Ilya Kulakov added the comment:
I'm very happy that the issue is finally resolved.
But a bit offended that it took Andrew only 4 days to push it :)
> On 07 Nov 2016, at 17:04, Yury Selivanov <rep...@bugs.python.org> wrote:
>
>
> Yury Selivanov added the comment:
>
>
Ilya Kulakov added the comment:
I checked the source code of OpenSSL, specifically the `bss_file.c:file_fopen`
function
(https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h/crypto/bio/bss_file.c#L118-L167).
As you can see it support UTF-8 encoded strings under Windows. Python must
follow
Ilya Kulakov added the comment:
Viktor, I also came across this thread but it is rather old (we're using
OpenSSL 1.0.2h). And it would only explain if _neither_ of my methods had
worked.
But as you can see, the last one (passing UTF-8 encoded bytes) works
Ilya Kulakov added the comment:
I believe this is a bug, because path suitable for os.path (or pathlib), should
be equally suitable for load_verify_locations.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Ilya Kulakov:
On Windows 8.1 x64 with Python 3.5.1 I was able to reproduce the issue by
attempting to load a file at
"C:\Users\غازي\AppData\Local\Temp\_غازي_70e5wbxo\cacert.pem".
locale.getdefaultlocale()
> ('en_US', 'cp1252')
locale.getpref
Ilya Kulakov added the comment:
Could someone provide a patch for Python 3.5?
--
nosy: +Ilya.Kulakov
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ilya Kulakov added the comment:
Yury, as you suggested posted to python-ideas
(https://groups.google.com/forum/#!topic/python-ideas/ABOe22Mib44)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ilya Kulakov added the comment:
Yury,
> `get_event_loop()` will then try to use the `running_loop` object first, and
> if nothing is there, fall back to its current implementation.
Do you think hiding "default" event loop completly from a currently executing
c
Ilya Kulakov added the comment:
Yury,
> Not sure I understand the question.
If I understood it correctly, get_event_loop() would never return "default"
event loop (in terms of current implementation) for a running task, because it
always be overridden with "running"
Ilya Kulakov added the comment:
Yury,
> I now think that we don't need a new function for getting the currently
> running event loop.
May I ask you to elaborate on this? Asynchronous API I'm aware of (including
other languages) typically allows to get "main" (which in a
Ilya Kulakov added the comment:
> TBH, I don't fully understand Ilya's case with threads, synchronous
> coroutines, possible deadlocks etc.
I feel sorry for sharing that example. It didn't help and made my points
regarding original issue unclear, hidden behind example's comp
Ilya Kulakov added the comment:
Yury, we're building our own CPython anyway (and we just updated to 3.5.1). I'd
be glad to test the patch during the next iteration.
Guido, I think my use case mixes up other things I find confusing about
asyncio: e.g. inablitity to synchronously perform code
Ilya Kulakov added the comment:
Yury, could you submit a patch implements this feature?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ilya Kulakov added the comment:
> If you're worried about blocking the event loop just to acquire the threading
> lock that's part of threading.Event, you can use run_in_executor()
I'm more worried to delay invocation of a "synchronous" report because of
outstanding tasks
Ilya Kulakov added the comment:
> You don't know what else that coroutine is waiting for, and it may be waiting
> for some I/O whose socket is registered with the other event loop. Since the
> other event loop won't make progress, you'd be deadlocked.
As an end user I know what my c
Ilya Kulakov added the comment:
Guido, Probably a legitimate example of having multiple event loops in a single
thread: you want to run certain coroutine synchronously without running
thread's own event loop.
--
___
Python tracker <
Ilya Kulakov added the comment:
> Update some places in asyncio where we currently use "get_event_loop()", such
> as Future constructor, Task.current_task, etc.
Yury, do you have an idea how it could be done?
--
___
Pyt
Ilya Kulakov added the comment:
Yury, that would do it.
Guido, that's indeed might be an anti-pattern. But it looks like passing event
loop around is just a worse version of it.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Ilya Kulakov added the comment:
> In this case I'm not sure how this is different from the current
> "get_event_loop"
Thread may have multiple event loops, but only one, explicitly associated, is
default. And it's not necessary one which is currently running.
I think what I
Ilya Kulakov added the comment:
> Why does it have to be a standard part of asyncio?
I've only seen few libraries that deal with asyncio so far (aiohttp, pyzmq),
but my general impression is that this is a generic problem.
With asyncio code should be (ideally) written as a set of corouti
New submission from Ilya Kulakov:
Currently if one needs lazily resolve event loop depending on where awaitable
is being awaited have to pass loop everywhere explicitly. That quickly becomes
an unnecessary noise in interfaces of callables.
Consider an example where a coroutine which
Ilya Kulakov added the comment:
Why is it important to hide these 2 macroses behind Py_BUILD_CORE?
Certain tools for embedding python may try to compile modules independently. I
realize that it's not a problem of Python to take care of that, but in that
particular case if hiding these 2
New submission from Ilya Kulakov:
According to the most recent documentation:
Return the current stream position as an opaque number. The number does not
usually represent a number of bytes in the underlying binary storage.
Therefore stream should be opened as 'ab' by using value
Ilya Kulakov added the comment:
Steve,
What's going to be the required msvc compiler for 3.5 on Windows?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17797
Ilya Kulakov added the comment:
I see issue to be fixed but patch wasn't applied yet. Is it still supposed to
be included in 3.5 or there is something wrong?
--
nosy: +Ilya.Kulakov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
New submission from Ilya Kulakov:
I'm seeing the issue using python 3.4.3 on Windows 8
In the __init__.py method of my package I define temporary directory at the
module level like this:
_TempDir = tempfile.TemporaryDirectory(prefix='...'))
tempfile.tempdir = _TempDir.name
I expect
Ilya Kulakov added the comment:
This issue is marked as closed as a duplicate without a reference to the
original task.
I still have this issues on Python 3.4.2, on Windows when shutil.rmtree fails to
--
nosy: +Ilya.Kulakov
title: shutil.rmtree() fails on invalid filename - finalizer
Ilya Kulakov added the comment:
The structure hack does not work on Windows 8, x64.
--
nosy: +Ilya.Kulakov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22273
83 matches
Mail list logo
