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 Windows, and every
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()`? If
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
make the changes
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 called
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
relying on tornado's
Change by Jeong-Min Lee :
--
nosy: +falsetru
___
Python tracker
<https://bugs.python.org/issue38947>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeong-Min Lee :
--
nosy: +falsetru
___
Python tracker
<https://bugs.python.org/issue38529>
___
___
Python-bugs-list mailing list
Unsubscribe:
Min RK <benjami...@gmail.com> 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
Min <mamamia...@gmail.com> added the comment:
Sorry again, the sample code offered is issue of re.sub(), not findall() :o)))
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Min <mamamia...@gmail.com> added the comment:
Sorry, forgot I have upgraded to 3.6.2, not 3.5
--
versions: +Python 3.6 -Python 3.5
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Min <mamamia...@gmail.com>:
Firstly, I wrote something like this:
patn = r"\bROW\s*\((\d+|\*)\)(.|\s)*?\)"
newlines = re.sub(patn, "\nY\n", newlines)
but if the file(or string) ended without the expe
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 <
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'll add
Changes by Min RK <benjami...@gmail.com>:
--
title: Memory leak in dictionary resize -> Memory leak in new 3.6 dictionary
resize
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
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 minu
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 that I
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 <rep...@bugs.python.org>
<http://bugs.python.org/issue25544>
___
___
Changes by Min RK <benjami...@gmail.com>:
Added file: http://bugs.python.org/file41659/main.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Min RK <benjami...@gmail.com>:
Added file: http://bugs.python.org/file41658/b.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Min RK <benjami...@gmail.com>:
Added file: http://bugs.python.org/file41657/a.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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:
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/dist-packages
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 very long
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 maintainers instead.
Yes, that's
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
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/Library
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
pyzmq
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 rep...@bugs.python.org
http://bugs.python.org/issue21351
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
New submission from Jeong-Min Lee:
Running the Pretty top example
(http://docs.python.org/dev/library/tracemalloc.html#pretty-top) in the
tracemalloc module documentation causes a ValueError.
Traceback (most recent call last):
File t.py, line 32, in module
display_top
Changes by Jeong-Min Lee false...@gmail.com:
--
title: tracemalloc example - tracemalloc example - Pretty Top
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20814
Changes by Jeong-Min Lee false...@gmail.com:
--
nosy: +Jeong-Min.Lee
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18851
___
___
Python-bugs-list
Changes by Jeong-Min Lee false...@gmail.com:
--
nosy: +falsetru
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10169
___
___
Python-bugs-list
Jeong-Min Lee false...@gmail.com added the comment:
Some exceptions are reported correctly.
def g():
... 1 / 0
... yield 1, 2
... yield 3, 4
...
zip(*g())
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 2, in g
ZeroDivisionError: integer
New submission from Jeong-Min Lee false...@gmail.com:
Expected TypeError: cannot concatenate 'str' and 'int' objects exception
raised, but got following result.
def g():
... '1' + 0
... yield 1, 2
... yield 3, 4
...
zip(*g())
Traceback (most recent call last):
File stdin, line
Changes by Jeong-Min Lee false...@gmail.com:
--
versions: +Python 3.2 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11944
Changes by Jeong-Min Lee false...@gmail.com:
--
nosy: +falsetru
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1195
___
___
Python-bugs-list
New submission from Jeong-Min Lee false...@gmail.com:
According to the documentation, itertools.product is equivalent to nested
for-loops in a generator expression.
But, itertools.product(itertools.count(2010)) is not.
import itertools
(year for year in itertools.count(2010))
generator
Changes by Jeong-Min Lee false...@gmail.com:
--
nosy: +falsetru
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5879
___
___
Python-bugs-list
Changes by Jeong-Min Lee false...@gmail.com:
--
nosy: +falsetru
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6902
___
___
Python-bugs-list
New submission from Jeong-Min Lee false...@gmail.com:
In Python 2.6,
'{0:030}'.format(1)
'10'
'{0:-30}'.format(1)
'1-'
In Python 2.7a / 3.1,
'{0:030}'.format(1)
'01'
'{0:-30}'.format(1)
'1
New submission from Jeong-Min Lee false...@gmail.com:
format(datetime_obj, format_string) return format_string. (when
format_string is not empty.)
import datetime
d = datetime.datetime.now()
format(d)
'2009-06-20 23:51:54.243428'
format(d, '')
'2009-06-20 23:51:54.243428'
d
Jeong-Min Lee false...@gmail.com added the comment:
I got it.
By the way, It would be good to document that this behaviour (at least
about datetime.__format__)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6316
New submission from Jeong-Min Lee:
In the middle of 3.1.4 Lists, it reads as follow
-
a
[]
The built-in function len() also applies to lists:
len(a)
8
-
but it should be ..
-
a
[]
The built-in function len() also applies to lists:
len(a)
0
-
http://docs.python.org/tut
New submission from Jeong-Min Lee:
lambda (x): x
should be transformed to
lambda x: x
not
lambda x1: x1[0]
--
components: Demos and Tools
files: 2to3_lambda_nontuple_param.diff
messages: 55654
nosy: falsetru, gvanrossum
severity: normal
status: open
title: [patch] 2to3, lambda
Jeong-Min Lee added the comment:
I found this while 2to3ing BeautifulSoup.py.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1107
__
___
Python-bugs-list mailing list
57 matches
Mail list logo
