Elvis Pranskevichus added the comment:
The leak was introduced in 3.10a5
(https://github.com/python/cpython/commit/0332e569c12d3dc97171546c6dc10e42c27de34b)
--
___
Python tracker
<https://bugs.python.org/issue46
Elvis Pranskevichus added the comment:
I can confirm that removing the kwargs allocation prevents the leak described
in the asyncpg issue from happening.
--
___
Python tracker
<https://bugs.python.org/issue46
New submission from Elvis Pranskevichus :
https://bugs.python.org/issue43466 added a way to set OpenSSL rpath explicitly
via --with-openssl-rpath=DIR, which is cool! However, the current
configuration code checks for the presence of the specified directory eagerly,
which breaks setups where
Change by Elvis Pranskevichus :
--
pull_requests: +21078
pull_request: https://github.com/python/cpython/pull/21969
___
Python tracker
<https://bugs.python.org/issue37
Change by Elvis Pranskevichus :
--
pull_requests: +21077
pull_request: https://github.com/python/cpython/pull/21968
___
Python tracker
<https://bugs.python.org/issue32
Change by Elvis Pranskevichus :
--
pull_requests: +21076
pull_request: https://github.com/python/cpython/pull/21967
___
Python tracker
<https://bugs.python.org/issue32
Change by Elvis Pranskevichus :
--
nosy: +Elvis.Pranskevichus
nosy_count: 6.0 -> 7.0
pull_requests: +21014
pull_request: https://github.com/python/cpython/pull/21895
___
Python tracker
<https://bugs.python.org/issu
Change by Elvis Pranskevichus :
--
keywords: +patch
nosy: +Elvis.Pranskevichus
nosy_count: 3.0 -> 4.0
pull_requests: +21013
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21894
___
Python tracker
Elvis Pranskevichus added the comment:
Thanks for the lightning-fast turnaround, Pablo!
--
___
Python tracker
<https://bugs.python.org/issue38400>
___
___
Pytho
Elvis Pranskevichus added the comment:
Since https://bugs.python.org/issue38070 was backported to 3.8, shouldn't this
as well? 3.8 is currently broken otherwise.
--
nosy: +Elvis.Pranskevichus
___
Python tracker
<https://bugs.python.
Elvis Pranskevichus added the comment:
I don't think that breaking the .pyc contract by assumption is a good thing.
The desired behavior of never checking the .pyc freshness can be achieved by
using unchecked hash-based compilation, or using hash-based compilation and
--check-hash-based
Change by Elvis Pranskevichus :
--
keywords: +patch
pull_requests: +9638
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue23734>
___
_
Change by Elvis Pranskevichus :
--
pull_requests: +9637
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issue34726>
___
___
Py
Elvis Pranskevichus added the comment:
https://github.com/python/cpython/pull/10327 fixes the remaining test failures.
--
___
Python tracker
<https://bugs.python.org/issue34
Change by Elvis Pranskevichus :
--
pull_requests: +9630
___
Python tracker
<https://bugs.python.org/issue34022>
___
___
Python-bugs-list mailing list
Unsub
Change by Elvis Pranskevichus :
--
pull_requests: +9078
___
Python tracker
<https://bugs.python.org/issue34872>
___
___
Python-bugs-list mailing list
Unsub
Change by Elvis Pranskevichus :
--
pull_requests: +9077
___
Python tracker
<https://bugs.python.org/issue34872>
___
___
Python-bugs-list mailing list
Unsub
Change by Elvis Pranskevichus :
--
keywords: +patch
pull_requests: +9068
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34872>
___
_
Elvis Pranskevichus added the comment:
https://github.com/python/cpython/pull/9607 turns SOURCE_DATE_EPOCH into a
*default* rather than absolute override.
test_cmd_line_script and test_runpy fail due to the lack of support for
hash-based .pycs in zipimport, which needs fixing also
Change by Elvis Pranskevichus :
--
pull_requests: +9005
___
Python tracker
<https://bugs.python.org/issue29708>
___
___
Python-bugs-list mailing list
Unsub
Change by Elvis Pranskevichus :
--
pull_requests: +9004
___
Python tracker
<https://bugs.python.org/issue34022>
___
___
Python-bugs-list mailing list
Unsub
Elvis Pranskevichus added the comment:
Perhaps SOURCE_DATE_EPOCH should only be consulted to determine the default
behavior if invalidation_mode was not passed explicitly to py_compile.compile().
--
___
Python tracker
<https://bugs.python.
Elvis Pranskevichus added the comment:
> In particular, if a build system sets SOURCE_DATE_EPOCH without
specifying a pyc format for py_compile or compileall, Python 3.7 will
give you checked hashes by default
Actually, py_compile will _force_ the CHECKED_HASH mode if SOURCE_DATE_EP
Change by Elvis Pranskevichus :
--
keywords: +patch
pull_requests: +8894
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34022>
___
_
Change by Elvis Pranskevichus :
--
keywords: +patch
pull_requests: +8893
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34537>
___
_
Change by Elvis Pranskevichus :
--
pull_requests: +8800
___
Python tracker
<https://bugs.python.org/issue33649>
___
___
Python-bugs-list mailing list
Unsub
Change by Elvis Pranskevichus :
--
keywords: +patch
pull_requests: +8050
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34075>
___
_
Change by Elvis Pranskevichus :
--
pull_requests: +7599
___
Python tracker
<https://bugs.python.org/issue32996>
___
___
Python-bugs-list mailing list
Unsub
Change by Elvis Pranskevichus :
--
keywords: +patch
pull_requests: +6955
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33736>
___
_
Change by Elvis Pranskevichus :
--
assignee: docs@python
components: Documentation
nosy: Elvis.Pranskevichus, docs@python
priority: normal
severity: normal
status: open
title: Improve the documentation of asyncio stream API
type: enhancement
versions: Python 3.7, Python 3.8
Change by Elvis Pranskevichus :
--
pull_requests: +6862
___
Python tracker
<https://bugs.python.org/issue23859>
___
___
Python-bugs-list mailing list
Unsub
Change by Elvis Pranskevichus :
--
keywords: +patch
pull_requests: +6850
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue23859>
___
_
Change by Elvis Pranskevichus :
--
keywords: +patch
pull_requests: +6849
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33638>
___
_
Change by Elvis Pranskevichus :
--
keywords: +patch
pull_requests: +6848
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32751>
___
_
Change by Elvis Pranskevichus <el...@magic.io>:
--
keywords: +patch
pull_requests: +6679
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Elvis Pranskevichus <el...@magic.io>:
The C API for PEP 567 is currently missing.
--
assignee: docs@python
components: Documentation
messages: 317244
nosy: Elvis.Pranskevichus, docs@python, yselivanov
priority: normal
severity: normal
status: open
title: Do
Change by Elvis Pranskevichus <el...@magic.io>:
--
pull_requests: +6651
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32996>
___
Elvis Pranskevichus <el...@magic.io> added the comment:
Thanks for the feedback Serhiy! I'll make an editorial pass to address the
comments shortly. In general, I prefer thoroughness in the initial What's New
edit to make sure we don't miss something imp
Change by Elvis Pranskevichus <el...@magic.io>:
--
pull_requests: +6633
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32996>
___
Change by Elvis Pranskevichus <el...@magic.io>:
--
pull_requests: +5211
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32622>
___
Elvis Pranskevichus <el...@magic.io> added the comment:
Likewise, on the same builds, running _decimal/tests/bench.py does not show a
significant difference:
https://gist.github.com/elprans/fb31510ee28a3aa091aee3f42fe65e00
--
___
Python t
Elvis Pranskevichus <el...@magic.io> added the comment:
FWIW, I ran bm_telco with pyperformance on a benchmark-tuned system and did not
observe the slowdown. Benchmarks were done on a release build
(--enable-optimizations)
$ sudo (which python3) -m perf system tune
MASTER:
$ pyperfo
Elvis Pranskevichus <el...@magic.io> added the comment:
I think that both the pyiso8601 and boxed/iso8601 implementations parse ISO
8601 strings incorrectly. The standard explicitly says that all truncated
datetime strings are *reduced accuracy timestamps*. In other words, &q
Change by Elvis Pranskevichus <el...@magic.io>:
--
keywords: +patch
pull_requests: +3854
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Elvis Pranskevichus <el...@magic.io>:
pkgutil.get_data() does this:
def get_data(self, pathname):
return open(pathname, "rb").read()
which very obviously leaks open file descriptors. This has been fixed in 3.x
by https://github.com/pytho
New submission from Elvis Pranskevichus:
The attached example shows that `asyncio.get_event_loop` still returns parent
process' event loop in some cases. It appears that the fix in issue #29703 was
incomplete:
PARENT PID: 21947, LOOP: <_UnixSelectorEventLoop running=True closed=False
de
Elvis Pranskevichus added the comment:
I'm pretty sure we're done with What's New for 3.6.0, so, unless it's worth
keeping this open for any 3.6.x edits, I'm for closing this.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Elvis Pranskevichus added the comment:
Here's a patch to add opcode changes to the What's New document. Thanks for
pointing this out Serhiy.
--
Added file:
http://bugs.python.org/file45657/0001-Issue-28635-Document-Python-3.6-opcode-changes.patch
Elvis Pranskevichus added the comment:
On second thought `-VV` isn't really a porting change, so probably a new
section under "Build and C API Changes". Something like "Other Improvements".
--
___
Python tracker <rep...
Elvis Pranskevichus added the comment:
https://docs.python.org/3.6/whatsnew/3.6.html#changes-in-python-command-behavior
seems appropriate.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Elvis Pranskevichus added the comment:
Patch with updates attached. Thanks for the feedback guys!
--
Added file:
http://bugs.python.org/file45474/0001-Issue-28635-what-s-new-in-3.6-add-a-few-more-notes-o.patch
___
Python tracker <
Elvis Pranskevichus added the comment:
Thanks Serhiy. I removed mentions of things that were indeed fixes backported
to 3.5. Other issue references are valid news, including new features to
provisional modules backported to 3.5. It is customary to include these in the
news for the major
Elvis Pranskevichus added the comment:
Attached patch for another pass on what's new.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Elvis Pranskevichus <el...@magic.io>:
Added file:
http://bugs.python.org/file45428/0001-Issue-28635-Fix-a-couple-of-missing-incorrect-versio.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Elvis Pranskevichus added the comment:
This should now be covered in #28635.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Elvis Pranskevichus <el...@magic.io>:
Added file:
http://bugs.python.org/file45429/0002-Issue-28635-What-s-New-in-Python-3.6-updates.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Elvis Pranskevichus added the comment:
I'm actually working on a tool that parses Misc/NEWS, cpython and peps repos,
and roundup to gather and organize the changes to make the news editor's job
easier.
--
___
Python tracker <rep...@bugs.python.
Elvis Pranskevichus added the comment:
The page is a work-in-progress. We'll surely capture all notable changes.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Elvis Pranskevichus:
Issue to track edits to "What's New in Python 3.6"
--
assignee: docs@python
components: Documentation
files: 0001-Inital-pass-on-What-s-New-in-Python-3.6.patch
keywords: patch
messages: 280244
nosy: Elvis.Pranskevichus, docs@python,
Changes by Elvis Pranskevichus <elpr...@gmail.com>:
--
nosy: +Elvis.Pranskevichus
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Elvis Pranskevichus added the comment:
Larry, it looks like the "Detailed Release Information" link on the release
page still points to rc3, which is a 404 now.
Also, there doesn't seem to be a link to the "What's new" document, on
Changes by Elvis Pranskevichus <elpr...@gmail.com>:
--
nosy: +Elvis.Pranskevichus
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Elvis Pranskevichus:
Consider the following:
import decimal
class MyDecimal(decimal.Decimal):
def __new__(cls, value):
return super().__new__(cls, value)
a = decimal.Decimal('1.0')
b = MyDecimal(a)
c = MyDecimal('1.0')
print(type(a), type(b), isinstance(b
Elvis Pranskevichus elpr...@gmail.com added the comment:
I guess, the best workaround would then be to use a decorator (or a metaclass)
and wrap __len__ so that TypeError is caught and wrapped into some other
exception.
On April 1, 2011 07:10:21 PM Benjamin Peterson wrote:
What?? I certainly
New submission from Elvis Pranskevichus elpr...@gmail.com:
Consider the following:
class Test:
... def __init__(self):
... self.items = []
... def __len__(self):
... if not self.items:
... self.items = list(self.calc_items())
... return len
Elvis Pranskevichus elpr...@gmail.com added the comment:
The problem is that the call to __len__ is implicit. The Exception is simply
swallowed by a list/tuple constructor.
The main issue is that the original error is masked which makes it very hard to
pinpoint the actual cause
Elvis Pranskevichus elpr...@gmail.com added the comment:
I think that explicitly raising TypeError in __len__() is wrong in any case. I
would argue something like NotImplementedError is a better choice to signal the
absence of length. Which also makes me think that Python's exceptions
Changes by Elvis Pranskevichus elpr...@gmail.com:
--
versions: -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python
3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11674
Changes by Elvis Pranskevichus elpr...@gmail.com:
--
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11674
___
___
Python-bugs
Elvis Pranskevichus elpr...@gmail.com added the comment:
Please don't provide a wrapper around ptrctrl
prctl is not portable. I always thought that the premise of stdlib is to
provide portable interfaces. BSD, for example, uses setprocname instead
of prctl. Also, prctl does not modify
70 matches
Mail list logo
