Ilya Kulakov 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
<https://bugs.python.org/issue29
Ilya Kulakov added the comment:
Can you suggest an alternative to ProcessPoolExecutor for 3.6?
--
___
Python tracker
<https://bugs.python.org/issue31489>
___
___
Ilya Kulakov added the comment:
Do you need any help with the change?
--
___
Python tracker
<https://bugs.python.org/issue29890>
___
___
Python-bugs-list mailin
Ilya Kulakov added the comment:
Is there anything to be done for this patch to get merged?
--
___
Python tracker
<https://bugs.python.org/issue22273>
___
___
Ilya Kulakov 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
Ilya Kulakov 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
<https://bugs.python.o
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 tr
Ilya Sandler added the comment:
Here is what's happening: when pdb starts up it sets tracing and several
trace events happen before the pdb reaches the first line of the
debugged program. So, pdb has some logic to ignore certain events on
startup (_wait_for_main_pyfile).
On normal startup
New submission from Ilya Sandler :
Currently, pressing Ctrl-C in pdb will terminate the program and throw
the user into post-mortem debugging.
Other debuggers (e.g gdb and pydb) treat Ctrl-C differently: Ctrl-C only
stops the program and the user can resume it if needed.
I believe current pdb
Ilya Sandler added the comment:
No,I don't think patch in the issue #1294 addresses the problem which
I'm trying to solve.
I tried applying patch#1294, and Ctrl-C will still throws your debugger
into postmortem mode and I don't think you can change that by overriding
do_Ke
Ilya Sandler added the comment:
Is not this patch backward incompatible?
E.g any cmd-based application which expects Ctrl-C to propagate to the
top level will be broken by this patch.
As for pdb, I don't think pdb will benefit from this patch: as I believe
that pdb needs something alon
Ilya Sandler added the comment:
> But currently, CTRL-C terminates the session instead of propagating
upstream
I am not sure I understand: currently Ctrl-C generates a
KeyboardInterrupt, which can be caught by the application which can
then decide how to proceed (in particular it can st
Ilya Sandler added the comment:
Here is another case, which I think is even worse.
Range checks are done inconsistently as well:
.../trunk> ./python -c 'import struct; struct.pack("B", 257)
'Traceback (most recent call last):
File "", line 1, in
stru
Ilya Sandler added the comment:
It appears that the different behavior results from trying to preserve
backward compatibility with earlier version of Python
see: http://bugs.python.org/issue1229380
___
Python tracker
<http://bugs.python.org/issue5
Ilya Sandler added the comment:
I think this would be useful for anyone who builds cpython on a
non-mainstream platform.
I know this would have been useful for me when I tried to build cpython
on an older linux distro where libs were installed in a non-std location.
--
nosy: +isandler
Ilya Sandler added the comment:
I tried to understand the cause of failures and I don't see how test_pdb2 could
have caused them ;-).
Here is the relevant part of buildbot timeline:
http://www.python.org/dev/buildbot/trunk/?last_time=1273368351&show_time=7400
The only test failu
New submission from Ilya Sandler :
the token module defines constants for token types e.g
NAME = 1
NUMBER = 2
STRING = 3
NEWLINE = 4
etc.
These constants are very useful for any code which needs to tokenize python
source, yet they are not listed in the documentation.
Is this a
Ilya Sandler added the comment:
I'm attaching a documentation patch.
Do note that there is also a bit of code-level inconsistency: a few tokens
(COMMENT, NL) are defined in tokenize module which is strange and inconvenient.
Should that be fixed too? (by moving token definitions into
Ilya Sandler added the comment:
> * I would list them all in one directive, like this:
Ok, done. Attaching the updated patch
> There is no description in that directive. Best move part of the
description above them in it.
I am not sure I understand your request. Could you clarify?
New submission from Ilya Sandler :
a session attached:
cheetah:~/wrk/svn/psi-poly5/poly/aut/prof> ~/comp/python/trunk/python -m pstats
prof.out
Welcome to the profile statistics browser.
% stats 20 \
Thu Jul 8 17:50:27 2010prof.out
197258358 function calls (197187736 primit
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
Changes by Ilya Kulakov :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue24699>
___
___
Python-bugs-list mailing list
Unsubscrib
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_trac
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:
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
Ilya Kulakov added the comment:
Could someone provide a patch for Python 3.5?
--
nosy: +Ilya.Kulakov
___
Python tracker
<http://bugs.python.org/issue18
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')
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
<http://bugs.python.org/issue27
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)
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
Changes by Ilya Konkov :
--
nosy: +eruart
___
Python tracker
<http://bugs.python.org/issue17732>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ilya Kulakov added the comment:
The structure hack does not work on Windows 8, x64.
--
nosy: +Ilya.Kulakov
___
Python tracker
<http://bugs.python.org/issue22
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 -> finali
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
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
<http://bugs.python.org/is
Ilya Kulakov added the comment:
Steve,
What's going to be the required msvc compiler for 3.5 on Windows?
--
___
Python tracker
<http://bugs.python.org/is
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 va
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 th
Ilya Kamenshchikov added the comment:
please fix spent half a day to understand I need C compiler
--
nosy: +Ilya Kamenshchikov
___
Python tracker
<http://bugs.python.org/issue2
New submission from Ilya Kreymer:
This is a peculiar regression in 3.5 where a comma-separated cookie following
an expires field is considered invalid:
Ex: which results in a silent error/empty cookie in 3.5.1
Python 3.5.1 (default, Dec 26 2015, 18:11:22)
[GCC 4.2.1 Compatible Apple LLVM
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 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 co
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 thi
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
<http://bugs.python.org/is
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?
--
___
Pytho
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:
> 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
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
ou
Ilya Kulakov added the comment:
Yury, could you submit a patch implements this feature?
--
___
Python tracker
<http://bugs.python.org/issue26969>
___
___
Pytho
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 pe
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
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" (
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,
> `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, as you suggested posted to python-ideas
(https://groups.google.com/forum/#!topic/python-ideas/ABOe22Mib44)
--
___
Python tracker
<http://bugs.python.org/issue26
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 wrote:
>
>
> Yury Selivanov added the comment:
>
> See https://github.com/
101 - 156 of 156 matches
Mail list logo
