Min RK added the comment:
It appears that connect_read_pipe also doesn't accept pipes returned by
`os.pipe`. If that's the case, what _does_ ProactorEventLoop.connect_read_pipe
accept? I haven't been able to find any examples of `connect_read_pipe` that
work on Win
Min RK added the comment:
Oops, I interpreted "not deprecated by oversight" as the opposite of what you
meant. Sorry! All clear, now.
--
___
Python tracker
<https://bugs.python.o
Min RK added the comment:
Thank you! I think I have enough information to update.
> IMHO, asyncio.set_event_loop()...[is] not deprecated by oversight.
I'm curious, what is an appropriate use of `asyncio.set_event_loop()` if you
can never get the event loop with `get_event_loop()`
Min RK added the comment:
Further digging reveals that `policy.get_event_loop()` is _not_ deprecated
while `asyncio.get_event_loop()` is. Is that intentional? Does that mean
switching our calls to `get_event_loop_policy().get_event_loop()` should
continue to work without deprecation
Min RK added the comment:
The comments in this thread suggest that `set_event_loop` should also be
deprecated, but it hasn't been. It doesn't seem to have any use without
`get_event_loop()`.
I'm trying to understand the consequences of these changes for IPython, and
m
Min RK added the comment:
We just ran into this in Jupyter where we've removed a pre-processing step for
data structures passed to json.dumps, which took care of this, but was
expensive https://github.com/jupyter/jupyter_client/pull/706
My expectation was that our `default` would be c
Change by Min RK :
--
nosy: +minrk
nosy_count: 5.0 -> 6.0
pull_requests: +27016
pull_request: https://github.com/python/cpython/pull/28648
___
Python tracker
<https://bugs.python.org/issu
Min RK added the comment:
A hiccup to using uvloop is that it doesn't support Windows yet
(https://github.com/MagicStack/uvloop/issues/14), so it can't be used in the
affected environment.
I'm exploring this again for pyzmq / Jupyter, and currently investigating
relyi
Min RK added the comment:
In the A/B vote, I cast mine for B, for what it is worth, but it is not
strongly held.
>From the IPython side, I don't view our particular issue as a major regression
>for users. The only affected case for us is interactively typed string
>lite
Min RK added the comment:
This affects IPython (specifically the traitlets component), which is what
prompted the report. We were able to push out a release of traitlets with a
workaround for the bug (4.3.1), but earlier versions of IPython / traitlets
will still be affected (all IPython >
New submission from Min RK:
HMAC digest methods call inner.digest() with no arguments, but new-in-3.6 shake
algorithms require a length argument.
possible solutions:
1. add optional length argument to HMAC.[hex]digest, and pass through to inner
hash object
2. set hmac.digest_size, and use
Min RK added the comment:
I pulled just now and saw changes in dictobject.c, and just wanted to confirm
the memory growth bug is still in changeset 56294e03ad89 (I think I used the
right hash, this time).
--
___
Python tracker
<h
Min RK added the comment:
> Ah, is the leak happen in 3.6b1?
The leak happens in 3.6b1 and master as of an hour ago (git:
3c06edfe9463f1cf81bc34b702f165ad71ff79b8, hg:r103797)
--
title: Memory leak in new 3.6 dictionary resize -> Unbounded memory growth
resizing split-table
Min RK added the comment:
> dictresize() is called for converting split table to combined table.
> How is it triggered many times?
every `self.__dict__.pop` triggers a resize. According to
https://www.python.org/dev/peps/pep-0412/#split-table-dictionaries
`obj.__dict__` is always a
Min RK added the comment:
I can add the cpython_only decorator, but I'm not sure it is the right thing to
do. I would expect the code in the test to pass on any Python implementation,
which would suggest that it should not be cpython_only, right? If you still
think so, I'
Changes by Min RK :
--
title: Memory leak in dictionary resize -> Memory leak in new 3.6 dictionary
resize
___
Python tracker
<http://bugs.python.org/issu
Min RK added the comment:
This patch fixes the memory leak in split-dict resizing.
Each time dict_resize is called, it gets a new, larger size `> minused`. If
this is triggered many times, it will keep growing in size by a factor of two
each time, as the previous size is passed as minused
New submission from Min RK:
There is a memory leak in the new dictionary resizing in 3.6, which can cause
memory exhaustion in just a few iterations.
I don't fully understand the details of the bug, but it happens when resizing a
dict with a split table several times. The only way t
Min RK added the comment:
update patch to use file context manager on temporary source file
it should apply cleanly on current default (778ccbe3cf74)
--
Added file:
http://bugs.python.org/file42399/0001-cleanup-tempfiles-in-has_function.patch
Min RK added the comment:
Absolutely, I'll try to do that tomorrow.
--
___
Python tracker
<http://bugs.python.org/issue25544>
___
___
Python-bugs-list m
Changes by Min RK :
Added file: http://bugs.python.org/file41658/b.py
___
Python tracker
<http://bugs.python.org/issue26153>
___
___
Python-bugs-list mailing list
Unsub
Changes by Min RK :
Added file: http://bugs.python.org/file41659/main.py
___
Python tracker
<http://bugs.python.org/issue26153>
___
___
Python-bugs-list mailing list
Unsub
New submission from Min RK:
PyImport_GetModuleDict: no module dictionary! can be raised during interpreter
shutdown if a `__del__` method results in a warning. This only happens on
Python 3.5.
The prompting case is IPython 4.0.2 and traitlets 4.1.0. An IPython
ExtensionManager calls
Changes by Min RK :
Added file: http://bugs.python.org/file41657/a.py
___
Python tracker
<http://bugs.python.org/issue26153>
___
___
Python-bugs-list mailing list
Unsub
New submission from Min RK:
One of the nits noted in http://bugs.python.org/issue717152, which introduced
ccompiler.has_function, was that it does not clean up after itself.
This patch uses a TemporaryDirectory context to ensure that the files created
during has_function are cleaned up
Min RK added the comment:
On a bit of further investigation, the NFS files have an xattr
`system.nfs4_acl`. This can be read, but attempting to write it fails with
EINVAL. Attempting to copy from NFS to non-NFS fails with ENOTSUP, which is
caught and ignored, but copying from NFS to NFS
Min RK added the comment:
> Just because a feature can be misused doesn't make it a bad feature.
That's fair. I'm just not aware of any uses of this feature that aren't
misuses, hence the patch.
> Perhaps you could submit a fix for this to the setuptools maintai
Min RK added the comment:
> Could you please post an example of where the feature is problematic ?
setuptools/easy_install is the major one, which effectively does `sys.path[:0]
= pth_contents`, breaking import priority. This has been known to result in
adding `/usr/lib/pythonX.Y/d
Min RK added the comment:
Thanks for the feedback, I thought it might be a long shot. I will go back to
removing the *use* of the feature everywhere I can find it, since it is so
problematic and rarely, if ever, desirable.
> it's an essential feature that has been documented for a v
New submission from Min RK:
.pth files currently allow execution of arbitrary code, triggered by lines
starting with `import`. This is a rarely understood, and often misbehaving
feature. easy_install has used this feature to ensure that its packages are
highest priority (even higher than
Min RK added the comment:
`--prefix` vs `--user` is the only conflict I have encountered, but based on
the way it works, it could just as easily happen with any of the various other
conflicting options in install (install_base, exec_prefix, etc.), though that
might not be very common.
There
New submission from Min RK:
Background:
Some Python distros (OS X, Debian, Homebrew, others) want the default
installation prefix for packages to differ from sys.prefix. OS X and Debian
accomplish this by patching distutils itself, with special cases like `if
sys.prefix == '/System/Li
Min RK added the comment:
Thanks for your help and patience. Closing as slightly unfortunate, but not
unintended behavior.
--
resolution: -> not a bug
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Min RK added the comment:
Thanks for clarifying that there is indeed a reference cycle by way of the
module, I hadn't realized that.
The gc blocking behavior is exactly why I brought up the issue. The real code
where this causes a problem (rather than the toy example I attached) is in
New submission from Min RK:
Reference counts appear to be ignored at process cleanup, which allows
inter-dependent `__del__` methods to hang on exit. The problem does not seem to
occur for garbage collection of any other context (functions, etc.).
I have a case where one object must be
35 matches
Mail list logo
