[issue42943] singledispatchmethod should expose registry of all known overloads

[Ilya Kulakov]

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
def _(message: MessageA): ...

@on_message.register
def _(message: MessageB): ...

loop = ...
condition = ...
messages = []

def receive_message_on_thread(message):
if ...:  # only signal to asyncio if message can be handled
messages.append(message)
loop.call_soon_threadsafe(condition.notify_all)
else:
...

async def process_messages_on_asyncio():
while True:
await condition.wait_for(lambda: len(messages) > 0)

while len(messages):
m = messages.pop(0)
...


Here messages are delivered outside of asyncio in a separate thread and thus 
they need to be forwarded into asyncio for further processing in the app. If 
the flow of messages is high it is desirable to filter inside the thread 
handler before signaling asyncio.

There are multiple approaches to describe which messages can be handled by the 
asyncio processor, but singledispatchmethod is the most elegant as it allows to 
keep everything in one place without if/else or code duplication.

Having a registry (trivially) exposed would allow to write the condition as 
`isinstance(message, tuple(on_message.registry.keys()))`.

--
components: Library (Lib)
messages: 385151
nosy: Ilya.Kulakov, lukasz.langa, methane, ncoghlan
priority: normal
severity: normal
status: open
title: singledispatchmethod should expose registry of all known overloads
type: enhancement
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue42943>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17013] Allow waiting on a mock

[Ilya Kulakov]

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 instead of extending 
called for backwards compatibility.

--

___
Python tracker 
<https://bugs.python.org/issue17013>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17013] Allow waiting on a mock

[Ilya Kulakov]

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 with the planned `awaited` property for asyncio mocks (see 
description in the PR).

--

___
Python tracker 
<https://bugs.python.org/issue17013>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17013] Allow waiting on a mock

[Ilya Kulakov]

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 / False is discouraged and is rarely used by itself, let alone 
in combination with .called

> Wouldn't that also break any mock that is mocking an object with a 
> "called_event" attribute?

It should break them in the same way as "called" breaks them now.

--

___
Python tracker 
<https://bugs.python.org/issue17013>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17013] Allow waiting on a mock

[Ilya Kulakov]

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

> On Jun 9, 2020, at 11:56 PM, Pablo Galindo Salgado  
> wrote:
> 
> 
> Pablo Galindo Salgado  added the comment:
> 
> isn't PR 20759 backwards incompatible? If I understand correctly, this would 
> break anyone that is checking for identity as :
> 
> assert mymock.called is True
> 
> --
> nosy: +pablogsal
> 
> ___
> Python tracker 
> <https://bugs.python.org/issue17013>
> ___

--

___
Python tracker 
<https://bugs.python.org/issue17013>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17013] Allow waiting on a mock

[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/issue17013>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17013] Allow waiting on a mock

[Ilya Kulakov]

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].

The key features of my implementation [2]:

- Gives meaning to the existing Mock.called property, otherwise not much useful
- Does not require end users to do anything: change is automatically available 
in every Mock (and any subclass of mock that does not override `called`)
- Use of conditionals provides API that allows much richer extension: instead 
of hardcoding conditions as events it allows to wait until arbitrary predicate 
becomes true
- Utilizes existing semantics of python conditionals (both asyncio and 
threading)

Accepting this PR will allow me to bring _AwaitEvent thereby completing mock.py 
with waiting mechanics with identical semantics for both threading-based and 
asyncio-based cases.


0: 
https://github.com/Martiusweb/asynctest/blob/4b1284d6bab1ae90a6e8d88b882413ebbb7e5dce/asynctest/mock.py#L428
1: https://github.com/python/cpython/pull/9296
2: https://github.com/python/cpython/pull/17133

--
nosy: +Kentzo

___
Python tracker 
<https://bugs.python.org/issue17013>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17013] Allow waiting on a mock

[Ilya Kulakov]

Change by Ilya Kulakov :


--
pull_requests: +16643
pull_request: https://github.com/python/cpython/pull/17133

___
Python tracker 
<https://bugs.python.org/issue17013>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26467] Add async magic method support to unittest.mock.Mock

[Ilya Kulakov]

Change by Ilya Kulakov :


--
pull_requests: +16639
pull_request: https://github.com/python/cpython/pull/17130

___
Python tracker 
<https://bugs.python.org/issue26467>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29302] add contextlib.AsyncExitStack

[Ilya Kulakov]

Change by Ilya Kulakov :


--
pull_requests: +16640
pull_request: https://github.com/python/cpython/pull/17130

___
Python tracker 
<https://bugs.python.org/issue29302>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35548] memoryview needlessly (?) requires represented object to be hashable

[Ilya Kulakov]

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 -> open

___
Python tracker 
<https://bugs.python.org/issue35548>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35548] memoryview needlessly (?) requires represented object to be hashable

[Ilya Kulakov]

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 attempt to guarantee immutability 
of its objects, it cannot guarantee immutability of the outside data. Therefore 
a hashable object is an object immutable from the perspective of Python's 
runtime.
Memory views connect Python objects with outside data. They can be marked as 
immutable by Python's runtime. Therefore it should be sufficient to be hashable 
regardless of volatility of outside data.

In your example the immutability of the ndarray is indeed bypassed via a view 
created beforehand. But that's implementation detail and may actually be a flaw 
(i.e. being unable to propagate the change). The documentation [1] somewhat 
warns your that this behavior might change:

> However, **currently**, locking a base object does not lock any views that 
> already reference it, so under that circumstance it is possible to alter the 
> contents of a locked array via a previously created writeable view onto it.

1: 
https://docs.scipy.org/doc/numpy-1.15.0/reference/generated/numpy.ndarray.flags.html

--

___
Python tracker 
<https://bugs.python.org/issue35548>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35548] memoryview needlessly (?) requires represented object to be hashable

[Ilya Kulakov]

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 defined as hash(m) == 
> hash(m.tobytes()):

However it's not clear why original type needs to be hashable given that 
memoryview deals with 1-dimensional read-only bytes representation of an 
object. Not only it requires the developer to make an extra copy of C-bytes, 
but also calls __hash__ of a represented object without using the result other 
than to detect an error.

My particular use case involves a memory view of a readonly numpy's ndarray. My 
view satisfies the following constraints:

>>> print(data.format, data.readonly, data.shape, data.c_contiguous)
b True (25,) True

But nevertheless the hashing fails because ndarray itself is not hashable.

Stefan Krah wrote [2]:

> Note that memory_hash() raises an error if the exporter *itself* is
not hashable, so it only hashes immutable objects by design.

But while __hash__ indeed tells that object is (supposed to be) immutable, 
there is no requirement for all immutable objects to have __hash__.

Both threads I have found ([3], [4]) are quite lengthy and show certain discord 
in opinions regarding the issue. Perhaps after 6 years since the release of the 
feature the view on the problem has changed?

1: 
https://github.com/python/cpython/blob/d1e717588728a23d576c4ead775f7dbd68149696/Objects/memoryobject.c#L2829-L2876
2: https://bugs.python.org/issue15814#msg169510
3: https://bugs.python.org/issue15573
4: https://bugs.python.org/issue15573

--
components: Library (Lib)
messages: 332280
nosy: Kentzo, skrah
priority: normal
severity: normal
status: open
title: memoryview needlessly (?) requires represented object to be hashable
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 
<https://bugs.python.org/issue35548>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.

[Ilya Kulakov]

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 
<https://bugs.python.org/issue30811>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32363] Deprecate task.set_result() and task.set_exception()

[Ilya Kulakov]

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.python.org>
<https://bugs.python.org/issue32363>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32363] Deprecate task.set_result() and task.set_exception()

[Ilya Kulakov]

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 tests: 
https://github.com/Kentzo/async_app/blob/250ee7a05d2af8035806ce1d86f57d0f00283db0/tests/test_utils.py#L73-L91

My use case was outside control of otherwise unconditionally blocking task (for 
tests only). What replacement (if any) would you suggest?

--
nosy: +Ilya.Kulakov

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32363>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22273] abort when passing certain structs by value using ctypes

[Ilya Kulakov]

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.org/issue22273>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29890] Constructor of ipaddress.IPv*Interface does not follow documentation

[Ilya Kulakov]

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.org/issue29890>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31489] Signal delivered to a subprocess triggers parent's handler

[Ilya Kulakov]

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.org/issue31489>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29302] add contextlib.AsyncExitStack

[Ilya Kulakov]

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.python.org>
<https://bugs.python.org/issue29302>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29302] add contextlib.AsyncExitStack

[Ilya Kulakov]

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.python.org/issue29302>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32162] typing.Generic breaks __init_subclass__

[Ilya Kulakov]

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__(**kwargs)

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32162>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32162] typing.Generic breaks __init_subclass__

[Ilya Kulakov]

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 called.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32162>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32162] typing.Generic breaks __init_subclass__

[Ilya Kulakov]

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.org/issue32162>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32162] typing.Generic breaks __init_subclass__

[Ilya Kulakov]

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 chain.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32162>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32162] typing.Generic breaks __init_subclass__

[Ilya Kulakov]

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, **kwargs):
super().__init_subclass__(**kwargs)
cls.attr = 42

class Y(X):
pass

Y.attr  # 42
X.attr  # AttributeError

With Generic it does not:

import typing

T = typing.TypeVar('T')

class X(typing.Generic[T]):
def __init_subclass__(cls, **kwargs):
super().__init_subclass__(**kwargs)
cls.attr = 42

class Y(X):
pass

Y.attr  # 42
X.attr  # 42

--
messages: 307182
nosy: Ilya.Kulakov
priority: normal
severity: normal
status: open
title: typing.Generic breaks __init_subclass__
type: behavior
versions: Python 3.6

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32162>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

[Ilya Kulakov]

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.org/issue31701>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

[Ilya Kulakov]

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.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31701>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

[Ilya Kulakov]

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 at [1]:

If the exception is still not handled after all your frame based SEH handlers 
are called, vectored continue handler will be called. This gives you the last 
opportunity to handle the exception in a way you want.

1: 
https://blogs.msdn.microsoft.com/zhanli/2010/06/24/c-tips-addvectoredexceptionhandler-addvectoredcontinuehandler-and-setunhandledexceptionfilter/

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31701>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

[Ilya Kulakov]

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).aspx

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31701>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

[Ilya Kulakov]

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 SetUnhandledExceptionFilter for everything 
and AddVectoredExceptionHandler only for those exceptions that cannot be 
handled by the former, like c374.

I couldn't find a list, so guess it will be an ongoing WIP.

1: 
https://stackoverflow.com/questions/19656946/why-setunhandledexceptionfilter-cannot-capture-some-exception-but-addvectoredexc

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31701>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

[Ilya Kulakov]

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.org/issue31701>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32041] Cannot cast '\0' to c_void_p

[Ilya Kulakov]

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.org/issue32041>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32041] Cannot cast '\0' to c_void_p

[Ilya Kulakov]

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.org/issue32041>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

[Ilya Kulakov]

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 tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31701>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32041] Cannot cast '\0' to c_void_p

[Ilya Kulakov]

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
priority: normal
severity: normal
status: open
title: Cannot cast '\0' to c_void_p
type: behavior
versions: Python 3.6

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32041>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM

[Ilya Kulakov]

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.python.org/issue31909>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM

[Ilya Kulakov]

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>
<https://bugs.python.org/issue31909>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM

[Ilya Kulakov]

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 tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31909>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM

[Ilya Kulakov]

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 since it's not defined, does 
not use it. This fails compilation with up to date libexpact due to a new 
condition [1].

[1] 
https://github.com/python/cpython/blob/master/Modules/expat/xmlparse.c#L87-L91

--
components: Build
messages: 305270
nosy: Ilya.Kulakov
priority: normal
severity: normal
status: open
title: Missing definition of HAVE_SYSCALL_GETRANDOM
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31909>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29890] Constructor of ipaddress.IPv*Interface does not follow documentation

[Ilya Kulakov]

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.org/issue29890>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31489] Signal delivered to a subprocess triggers parent's handler

[Ilya Kulakov]

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.python.org/issue31489>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31489] Signal delivered to a subprocess triggers parent's handler

[Ilya Kulakov]

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


def background_task():
print(f"Running background task {os.getpid()}", file=sys.stderr)
time.sleep(15)
print("Exiting background task", file=sys.stderr)


async def task():
print("Running task")

executor = ProcessPoolExecutor()
with executor:
loop = asyncio.get_event_loop()

try:
await loop.run_in_executor(executor, background_task)
except asyncio.CancelledError:
print("Cancelling task 1", file=sys.stderr)

try:
await asyncio.sleep(15)
except asyncio.CancelledError:
print("Cancelling task 2", file=sys.stderr)
raise

raise

def main():
def terminate(coro):
print(f"Terminating {os.getpid()}")
coro.cancel()

loop = asyncio.get_event_loop()
t = asyncio.ensure_future(task())
loop.add_signal_handler(signal.SIGTERM, terminate, t)

try:
print(f"Running {os.getpid()}", file=sys.stderr)
loop.run_until_complete(t)
finally:
loop.run_until_complete(loop.shutdown_asyncgens())
loop.close()


if __name__ == '__main__':
main()
```

1. Normal execution:

> Running 1000
> Running task
> Running background task 
> Exiting background task

2. Sending SIGTERM to parent once:

> Running 1000
> Running task
> Running background task 

< kill -s SIGTERM 

> Terminating 1000
> Cancelling task 1
> Exiting background task


3. Sending SIGTERM to parent twice:

> Running 1000
> Running task
> Running background task 

< kill -s SIGTERM 1000

> Terminating 1000
> Cancelling task 1

< kill -s SIGTERM 1000

> Terminating 1000
> Cancelling task 2
> Exiting background task


4. Sending SIGTERM to once to parent and once to child:

> Running 1000
> Running task
> Running background task 

< kill -s SIGTERM 1000

> Terminating 1000
> Cancelling task 1

< kill -s SIGTERM 

> Terminating 1000
> Cancelling task 2
> Exiting background task


As you can see, sending SIGTERM into a subprocess somehow triggered a signal 
handler inside a parent. This is unexpected.

--
components: asyncio
messages: 302321
nosy: Ilya.Kulakov, yselivanov
priority: normal
severity: normal
status: open
title: Signal delivered to a subprocess triggers parent's handler
type: behavior
versions: Python 3.6

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31489>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27354] SSLContext.load_verify_locations cannot handle paths on Windows which cannot be encoded using mbcs

[Ilya Kulakov]

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 encoding 
> the filename manually to utf-8.

That's correct. I'm not sure that this is true for all versions though.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27354>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27354] SSLContext.load_verify_locations cannot handle paths on Windows which cannot be encoded using mbcs

[Ilya Kulakov]

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 not have any problems 
understanding a UTF-8 on Windows.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27354>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31363] __PYVENV_LAUNCHER__ breaks calling another venv's interpreter

[Ilya Kulakov]

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 "import subprocess; 
subprocess.check_call(['/python', '-c', 'import pkg_resources'])"

Works: $ python -c "import os, subprocess; env = os.environ.copy(); 
env.pop('__PYVENV_LAUNCHER__'); subprocess.check_call(['< pkgr_venv>/python', 
'-c', 'import pkg_resources'], env=env)"

--
messages: 301454
nosy: Ilya.Kulakov
priority: normal
severity: normal
status: open
title: __PYVENV_LAUNCHER__ breaks calling another venv's interpreter
versions: Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31363>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29302] add contextlib.AsyncExitStack

[Ilya Kulakov]

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 a look then.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29302>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29302] add contextlib.AsyncExitStack

[Ilya Kulakov]

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 and try to change this into a patch if that's 
OK.

--
nosy: +Ilya.Kulakov

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29302>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29890] Constructor of ipaddress.IPv*Interface does not follow documentation

[Ilya Kulakov]

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 will work:

ipaddress.ip_network(('192.168.1.10', '255.255.255.0'), strict=False)

--
messages: 290062
nosy: Ilya.Kulakov
priority: normal
severity: normal
status: open
title: Constructor of ipaddress.IPv*Interface does not follow documentation
type: behavior
versions: Python 3.5, Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29890>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22962] ipaddress: Add optional prefixlen argument to ip_interface and ip_network

[Ilya Kulakov]

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 <rep...@bugs.python.org>
<http://bugs.python.org/issue22962>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29288] Lookup Error while importing idna from a worker thread

[Ilya Kulakov]

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 resources system and we frequently see this error. On 
certain machines. Workaround that seems to work more reliably is a no-op look 
up via ''.encode('ascii').decode('idna').

--
components: Library (Lib)
messages: 285586
nosy: Ilya.Kulakov
priority: normal
severity: normal
status: open
title: Lookup Error while importing idna from a worker thread
versions: Python 3.5

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29288>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29219] TracebackException(capture_locals=True) may fail with RecursionError

[Ilya Kulakov]

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", line 425, in LoadLibrary
  File ":/ctypes/__init__.py", line 347, in __init__
OSError: [WinError 126] 找不到指定的模組

Then we raise our own exception.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29219>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29219] TracebackException(capture_locals=True) may fail with RecursionError

[Ilya Kulakov]

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, 
capture_locals=True)

sys.excepthook = handle_exception

For one of the clients the following error happened:

Traceback (most recent call last):
  File "...", line 222, in ...
  File "...", line 160, in ...
  File "...", line 878, in ...
  File ":/traceback.py", line 463, in __init__
  File ":/traceback.py", line 474, in __init__
  File ":/traceback.py", line 352, in extract
  File ":/traceback.py", line 257, in __init__
  File ":/traceback.py", line 257, in 
  File ":/ctypes/__init__.py", line 354, in __repr__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
  File ":/ctypes/__init__.py", line 360, in __getattr__
  File ":/ctypes/__init__.py", line 365, in __getitem__
 

[issue24699] TemporaryDirectory is cleaned up twice

[Ilya Kulakov]

Changes by Ilya Kulakov <kulakov.i...@gmail.com>:


--
status: open -> closed

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24699>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28958] Python should return comperhansive error when SSLContext cannot be created

[Ilya Kulakov]

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 raised from 
_ssl.c are non-helpful.

Python's SSLError should be extended to include comprehensive information about 
OpenSSL's error stack which can be extracted with `ERR_get_error_line`.

--
assignee: christian.heimes
components: SSL
messages: 283078
nosy: Ilya.Kulakov, christian.heimes
priority: normal
severity: normal
status: open
title: Python should return comperhansive error when SSLContext cannot be 
created
type: enhancement
versions: Python 3.5, Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28958>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

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:
> 
> See https://github.com/python/asyncio/pull/452. I believe that the issue is 
> not resolved (almost).
> 
> What's left is documenting how to use get_event_loop and when to use 
> explicit/implicit loop passing.
> 
> Closing this issue.  Will open a new one for the documentation update.
> 
> --
> resolution:  -> fixed
> stage:  -> resolved
> status: open -> closed
> 
> ___
> Python tracker <rep...@bugs.python.org>
> <http://bugs.python.org/issue26969>
> ___

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26969>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27354] SSLContext.load_verify_locations cannot handle paths on Windows which cannot be encoded using mbcs

[Ilya Kulakov]

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 up.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27354>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27354] SSLContext.load_verify_locations cannot handle paths on Windows which cannot be encoded using mbcs

[Ilya Kulakov]

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.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27354>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27354] SSLContext.load_verify_locations cannot handle paths on Windows which cannot be encoded using mbcs

[Ilya Kulakov]

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/issue27354>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27354] SSLContext.load_verify_locations cannot handle paths on Windows which cannot be encoded using mbcs

[Ilya Kulakov]

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.getpreferredencoding()
> 'cp1252'

sys.getfilesystemencoding()
> 'mbcs'

sys.getdefaultencoding()
> 'utf-8'

c = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)


c.load_verify_locations(cafile=r"C:\Users\غازي\AppData\Local\Temp\_غازي_70e5wbxo\cacert.pem")
> TypeError: cafile should be a valid filesystem path


c.load_verify_locations(cafile=r"C:\Users\غازي\AppData\Local\Temp\_غازي_70e5wbxo\cacert.pem".encode(sys.getfilesystemencoding()))
> UnicodeEncodeError: 'mbcs' codec can't encode characters in positions 
0--1: invalid character


c.load_verify_locations(cafile=r"C:\Users\غازي\AppData\Local\Temp\_غازي_70e5wbxo\cacert.pem".encode('utf-8'))
> ok

--
components: Extension Modules, Unicode, Windows
messages: 268880
nosy: Ilya.Kulakov, ezio.melotti, haypo, paul.moore, steve.dower, tim.golden, 
zach.ware
priority: normal
severity: normal
status: open
title: SSLContext.load_verify_locations cannot handle paths on Windows which 
cannot be encoded using mbcs
versions: Python 3.5

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27354>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English

[Ilya Kulakov]

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/issue18378>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

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/issue26969>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

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 
coroutine is safe?

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26969>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

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" event loop. If it's so, are you sure it 
won't raise any problems with backward compatibility?

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26969>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

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 asyncio is lazily 
created for main thread only), and "current". Sometimes there is also a 
convenient "global" which can be used when you want to do some async work 
outside. E.g. take a look at public API of Apple's Grand Central Dispatch, 
specifically `dispatch_get_current_queue`.

Even Python's thread module allows to get "current_thread" instead of passing 
it into run callback and requiring a user to carry it around by hand.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26969>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

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 complexity.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26969>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

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 written as standalone 
coroutine. It deserves its own task and discussion.

The purpose of this request is that access to a running loop is handy within 
coroutine. It's already there, since coroutine is executed within its context. 
However, instead of "self" library provides API to only access some globally 
default loop.

Python does not require a user to pass self whenever instance methods needs to 
be called. I consider relationship between event loop and awaitables alike.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26969>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

Ilya Kulakov added the comment:

Yury, could you submit a patch implements this feature?

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26969>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

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 in event loop's queue. Given my situtation, that may not even 
happen because outstanding tasks may stop the loop by raising their own 
exceptions.

I'm willing to sacrifice them (i.e. I'm ok with not sending them) in order to 
send information about exception "for sure".

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26969>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

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 coroutines may be waiting for. It's out of 
question to expect an ability to reuse coroutine and its associated context in 
multiple loops.

> PS. If you have something you sometimes want to run synchronously and 
> sometimes as a coroutine, you probably need to refactor it somehow.

We have a service that is responsible for reporting various stages about our 
application's lifetime. Most of the time app does not care about when (and 
whether) data will be actually sent, so we run this service in its own thread, 
the rest of the app just schedules coroutines in its event loop (hidden and 
managed by service's API). However sometimes it does care and moreover needs to 
do that synchronously (i.e. when we handle fatal / unhandled exception. In 
order to reuse remaining code that constructs coroutines, in the place of 
invocation we create a temporary event loop and use run_until_complete.

This is all practical problem. The conceptual problem is that current API is 
not flexible enough to create an event policy that would do something more 
useful that changing default type of an event loop.

Having the ability to get currently running event loop from within executing 
coroutine sounds pretty convenient and in my opinion would greatly reduce the 
amount of passing loops everywhere for end users (library developery, 
unfortunately, have no chance to avoid this).

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26969>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

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 <rep...@bugs.python.org>
<http://bugs.python.org/issue26969>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

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?

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26969>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

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.python.org/issue26969>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

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 propose here can be expressed in Python terms as an implicit 
context manager that replaces Thread's default event loop once while it "runs" 
particular event loop then switches it back (possible to None) once loop is 
stopped.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26969>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

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 coroutines which 
schedule each other or are called in response to monitored events. That means 
(and asyncio very implementation shows that) loop has to be "self" for all 
coroutines it executes.

Thread-local default event loop is a good solution to get an entry point into 
the event loop from an out-of-event-loop execution location. But (ideally) 
there will be exactly one place in code where this behavior is convenient: when 
you "instantiate" and run event loop. After that the event loop becomes "self" 
for each coroutine it may run and therefore it's now convenient for 
get_event_loop to return currently running event loop.

Probably it would make sense to modify behavior of the default policy to make 
get_event_loop to return Thread-local event loop when called from 
out-of-event-loop and return currently running event loop when called from 
within a coroutine.

> Why don't you just use 'loop = asyncio.get_event_loop()' in places where you 
> need the loop?

As David pointed out, I'm not using thread-local event loop.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26969>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

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 constructs other awaitables can be 
executed in arbitrary loop:

import asyncio
import datetime

async def foo_coro(loop):
await some_other_coro(loop)

async def bar_coro(loop):
await asyncio.ensure_future(..., loop=loop)

async def baz_coro(loop):
await asyncio.gather(foo_coro(loop), bar_coro(loop), loop=loop)

loop = asyncio.get_event_loop()
loop.run_until_complete(multiple_coros(loop))
loop.close()

It would be nice, if all functions that belong to an event loop instance as 
well as asyncio helpers that accept a loop would set default event loop to one 
that was passed to these functions. So that the example above could be 
rewritten as:

import asyncio
import datetime

async def foo_coro():
await some_other_coro()

async def bar_coro():
await asyncio.ensure_future(...)

async def baz_coro():
await asyncio.gather(foo_coro(), bar_coro())

loop = asyncio.get_event_loop()
loop.run_until_complete(multiple_coros())
loop.close()

--
components: asyncio
messages: 264941
nosy: Ilya.Kulakov, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: ascynio should provide a policy to address pass-loop-everywhere problem
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26969>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24575] timemodule build fail - missing definitions for _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH

[Ilya Kulakov]

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 macroses behind Py_BUILD_CORE is not 
required, it may help to retain compatibility with such tools.

--
nosy: +Ilya.Kulakov

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24575>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24940] RotatingFileHandler uses tell in non-binary mode to determine size of the file in bytes

[Ilya Kulakov]

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 of the encoding 
argument or sys.getdefaultencoding if it's None.

--
messages: 249177
nosy: Ilya.Kulakov
priority: normal
severity: normal
status: open
title: RotatingFileHandler uses tell in non-binary mode to determine size of 
the file in bytes
versions: Python 2.7, Python 3.4, Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24940
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program

[Ilya Kulakov]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program

[Ilya Kulakov]

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/issue17797
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24699] TemporaryDirectory is cleaned up twice

[Ilya Kulakov]

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 it to be deleted on exit.

However, _sometimes_, I'm seeing the following exception on exit:

Traceback (most recent call last):
  File :/weakref.pyo, line 582, in _exitfunc
  File :/weakref.pyo, line 506, in __call__
  File :/tempfile.pyo, line 674, in _cleanup
  File :/shutil.pyo, line 478, in rmtree
  File :/shutil.pyo, line 360, in _rmtree_unsafe
  File :/shutil.pyo, line 358, in _rmtree_unsafe
FileNotFoundError: [WinError 3] The system cannot find the path specified: 'C:\\
Users\\BC79~1\\AppData\\Local\\Temp\\..._s9wqmyo_'

--
messages: 247233
nosy: Ilya.Kulakov
priority: normal
severity: normal
status: open
title: TemporaryDirectory is cleaned up twice
type: behavior
versions: Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24699
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3616] finalizer

[Ilya Kulakov]

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

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3616
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22273] abort when passing certain structs by value using ctypes

[Ilya Kulakov]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com