Eric Snow added the comment:
Looks like setuptool's pkg_resources is directly importing
importlib._bootstrap. I've filed a bug:
https://bitbucket.org/pypa/setuptools/issue/378. In the meantime, what are our
options for getting that te
Eric Snow added the comment:
Here's the correct patch.
--
Added file: http://bugs.python.org/file39272/path-based-importlib.diff
___
Python tracker
<http://bugs.python.org/is
Changes by Eric Snow :
Removed file: http://bugs.python.org/file39271/path-based-importlib.diff
___
Python tracker
<http://bugs.python.org/issue23911>
___
___
Python-bug
Eric Snow added the comment:
Gah. I had tried exactly that but did it in the wrong spot. Here's an updated
patch which fixes the test.
--
Added file: http://bugs.python.org/file39273/path-based-importlib.diff
___
Python tracker
Changes by Eric Snow :
Removed file: http://bugs.python.org/file39273/path-based-importlib.diff
___
Python tracker
<http://bugs.python.org/issue23911>
___
___
Python-bug
Changes by Eric Snow :
Added file: http://bugs.python.org/file39274/path-based-importlib.diff
___
Python tracker
<http://bugs.python.org/issue23911>
___
___
Python-bug
Changes by Eric Snow :
Added file: http://bugs.python.org/file39275/path-based-importlib.diff
___
Python tracker
<http://bugs.python.org/issue23911>
___
___
Python-bug
Changes by Eric Snow :
Removed file: http://bugs.python.org/file39274/path-based-importlib.diff
___
Python tracker
<http://bugs.python.org/issue23911>
___
___
Python-bug
Changes by Eric Snow :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Eric Snow :
--
resolution: -> fixed
status: open -> pending
___
Python tracker
<http://bugs.python.org/issue23911>
___
___
Python-bugs-list
Changes by Eric Snow :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue23911>
___
___
Python-bugs-list mailing list
Unsubscrib
Eric Snow added the comment:
Thanks for pointing this out, Ned. Early on I ran into a problem when running
_freeze_importlib without the flag set. However, I expect that it was not
necessary after a certain point (e.g. once I had a valid
_importlib_external.h). I'll remove the fl
Eric Snow added the comment:
changeset: 95887:3bea670c9830
user:Eric Snow
date:Tue May 05 21:29:31 2015 -0600
summary: Remove an unnecessary flag.
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -&g
Eric Snow added the comment:
Just in case, please take a look at issues #17457 and #23882 to see if they
already cover the bug.
--
nosy: +eric.snow, rbcollins
___
Python tracker
<http://bugs.python.org/issue24
Eric Radman added the comment:
Thanks for posting some simple examples.
Here is the commit that I wrote to solve this problem when I encountered it in
the wild:
https://bitbucket.org/tk0miya/testing.postgresql/commits/3f145860cfd91e3f03f24b87c4b3b41c3a974037
Closing since I am also not able
Eric Snow added the comment:
@Yury, I'm mostly just waiting for Raymond to give it at least a quick
sanity-check. I know there is at least 1 ref leak, but that can be sorted out.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Eric Snow :
--
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Python-bugs-list mailing list
Un
Eric Snow added the comment:
The problem is right where the traceback says. Apparently there is a gap in
the namespace package tests that I slipped through with my recent work to split
out path-based import. I'll work up a patch.
--
___
P
Eric Snow added the comment:
Hmm, look like the test suite masks the issue due to the fact that importlib
gets imported before running the applicable tests in test_namespace_pkgs.py.
This causes _frozen_importlib.__package__ to get set properly, thus masking the
problem.
The problem is the
Eric Snow added the comment:
Here's a fix. If I don't hear from anyone right away I'll push it in a few
hours (or tomorrow morning).
--
keywords: +patch
stage: -> patch review
Added file: http://bugs.python.org/file39386/issue24192.diff
Changes by Eric Snow :
--
assignee: -> eric.snow
___
Python tracker
<http://bugs.python.org/issue24192>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Eric Snow :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> pending
type: -> behavior
___
Python tracker
<http://bugs.python
Eric Snow added the comment:
Great! The buildbots are happy too. :)
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue24192>
___
___
Py
Eric Snow added the comment:
Thanks for taking a look, Yury. I'll follow up on the ref leak soon.
--
___
Python tracker
<http://bugs.python.org/is
Eric Snow added the comment:
I've updated the cordereddict branch on the feature repo to fix the ref leak on
None. I'm still seeing other leaks (regrtest -R 3:3), but I don't think that
should block landing before the feature freeze.
However, I'm concerned about a segfaul
Eric Snow added the comment:
Agreed. I wanted to be clear about what is blocking landing the patch.
--
___
Python tracker
<http://bugs.python.org/issue16
Eric Snow added the comment:
These are the leaks I'm seeing in test_collections (14/24 tests):
test_copying : 178
test_iterators : 40
test_update : 29
test_init: 22
test_move_to_end : 21
test_sorted_iterators: 20
test_setdefault
Eric Snow added the comment:
I've fixed most of the leaks now. The only remaining ones are:
test_clear : 5
test_repr_recursive : 3
--
___
Python tracker
<http://bugs.python.org/is
Eric Snow added the comment:
Regarding the segfault, the following does not fail:
./python -m test.regrtest --forever -m test_basic test_configparser
but this does:
for i in `seq 1 20`; do ./python -m test.regrtest -m test_basic
test_configparser ; done
Eric Snow added the comment:
Here's a diff from the current cordereddict branch of the feature repo.
--
Added file: http://bugs.python.org/file39445/cOrderedDict-4.diff
___
Python tracker
<http://bugs.python.org/is
New submission from Eric Snow:
Here's a work-in-progress patch that uses OrderedDict as the default class
definition namespace (instead of dict). While the actual class namespace is a
dict, the definition order is preserved on a new attribute on class objects:
__definition_order__. Th
Eric Snow added the comment:
Thanks for looking into this, Ned. I've changed that size_t to ssize_t which I
expect will quiet that clang warning you saw. I'm glad you pointed it out
because it means that that branch was never executing! Unfortunately fixing
that does not so
Eric Snow added the comment:
Cool. The following gives consistent failures at certain seed values:
for i in `seq 1 100`; do echo $i; PYTHONHASHSEED=$i ./python -m test.regrtest
-m test_basic test_configparser ; done
Through 100 I get segfaults with 7, 15, 35, 37, 39, 40, 42, 47, 50, 66, 67
Eric Snow added the comment:
Here's a patch that drops adding __definition_order__. You can get the same
effect by adding `__definition_order__ = list(locals())` at the bottom of your
class definition. The benefit of having `__definition_order__` is that the
information is automati
Eric Snow added the comment:
I've spent a bit of time exploring the segfault. Here's some data that might
help relative to the configparser test.
I put the following at the beginning of _odict_resize:
Py_ssize_t len = PyObject_Size((PyObject *)od);
if
Eric Snow added the comment:
As far as I can tell there aren't any patterns that repeat across multiple
seeds (which makes sense).
--
___
Python tracker
<http://bugs.python.org/is
Eric Snow added the comment:
Here are the last 10 frames from the backtrace (gdb):
#0 0x005b15d0 in odictiter_iternext (di=) at
Objects/odictobject.c:1888
#1 0x00453179 in PyIter_Next (iter=) at
Objects/abstract.c:2760
#2 0x005881e7 in chain_next (lz=0x72b8d878
Eric Snow added the comment:
The segfault happens at line 1888 of odictobject.c when it tries to Py_INCREF a
NULL value. The problem is that the value that gets looked up for a presumably
valid key is returned as NULL. So either the value is messed up, lookup is
broken, or the wrong key is
Eric Snow added the comment:
Yeah, Ned pointed that one out. I fixed it but haven't pushed the change.
--
___
Python tracker
<http://bugs.python.org/is
Eric Snow added the comment:
Include/opcode.h shouldn't be in the change (and won't be when committed). I'm
guessing it being there is related to one of the recent merges I did from
default into the feature branch.
--
___
Python
Eric Snow added the comment:
Just to narrow things down a bit further, the failure happens specifically
under ConfigParserTestCaseNoValue:
PYTHONHASHSEED=7 ./python -m unittest
test.test_configparser.ConfigParserTestCaseNoValue.test_basic -v
Eric Snow added the comment:
If I still the following at Lib/test/test_configparser.py:328:
print(len(cf._proxies), len(list(cf._proxies)), list(cf._proxies))
print(len(cf._sections), len(list(cf._sections)), list(cf._sections))
I get unexpected results that are a clear indication of a
Eric Snow added the comment:
Good point, Nick. I'd checked that earlier but did not see any relationship.
At this point it's worth checking again. :)
--
___
Python tracker
<http://bugs.python.o
Eric Snow added the comment:
Good catch. I've fixed odictiter_new in the feature branch. However, I'm not
sure there's anything to be fixed in odict_new. It follows the same pattern as
dict_new (over in Objects/dictobject.c).
--
___
Changes by Eric Snow :
--
hgrepos: +309
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
hgrepos: +310
___
Python tracker
<http://bugs.python.org/issue24254>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
@mrab
gah! I could swear I originally had the _odict_clear_node first and had
switched them due to a segfault. It even crossed my mind on Friday but I
didn't pursue it. I'm guessing I did put the _odict_clear_node call first at
some point but los
Eric Snow added the comment:
@Jim,
You've got some good questions. I'll look into them today.
--
___
Python tracker
<http://bugs.python.org/issue16991>
___
__
Changes by Eric Snow :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Eric Snow added the comment:
I have verified that this is still a problem (basically 3.6b1).
Fatal Python error: Py_Initialize: Unable to get the locale encoding
Traceback (most recent call last):
File "/opt/python3.6/lib/python3.6/encodings/__init__.py", line 99, in
search_funct
Eric Snow added the comment:
After looking more closely, it looks like we should be ignoring such bogus
modules. Here's a patch to do so.
--
keywords: +patch
stage: test needed -> patch review
Added file: http://bugs.python.org/file44424/issue16
New submission from Eric Snow:
As indicated by issue #16384, the import machinery is not consistent in raising
ImportError. Some places in _bootstrap.py (and _bootstrap_external.py) raise
ImportError and others make no effort to wrap errors that get encountered. I
would expect the import
New submission from Eric Snow:
In Lib/encodings/__init__.py, search_function() looks up an encoding by name.
It loads the encoding by importing the corresponding module in the encodings
package. If there's an ImportError while importing that module then the
encoding gets silently ig
Eric Snow added the comment:
Here's an updated patch. Per a suggestion from Brett, I've chained the
original EOFError with an ImportError. The consequence is that the problematic
encoding is skipped (silently) rather than causing the interpreter to abort.
FYI, I've opened
Changes by Eric Snow :
Removed file: http://bugs.python.org/file44424/issue16384.diff
___
Python tracker
<http://bugs.python.org/issue16384>
___
___
Python-bugs-list m
Changes by Eric Snow :
--
assignee: brett.cannon -> eric.snow
resolution: rejected ->
stage: -> needs patch
status: closed -> open
versions: +Python 3.6 -Python 3.4
___
Python tracker
<http://bugs.python
New submission from Eric Snow:
As pointed out in #16384, a bad .pyc file will cause a module to fail
importing. Sometimes the .py file is okay, however. The question posed in the
other issue is if it would be desirable to fall back to the .py file.
FWIW, I don't think it'
Eric Snow added the comment:
I've opened #28007 to cover the concerns about bad a .pyc file blocking import
from a valid .py file.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Eric Snow :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Eric Snow added the comment:
I've applied the patch with a couple small changes. Thanks for the help!
--
nosy: +eric.snow
resolution: -> fixed
stage: -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4
___
Python
Eric Snow added the comment:
Thanks for the patch Meador.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.3
___
Python tracker
<http://bugs.python.or
Changes by Eric Snow :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Eric Snow added the comment:
pkgutil has since been updated to use importlib, meaning it relies on importlib
to sort this out.
--
components: +Library (Lib)
resolution: -> out of date
stage: needs patch -> resolved
status: open -> closed
versions: +Python 3.6 -P
Eric Snow added the comment:
What ended up happening with this?
--
nosy: +eric.snow
versions: +Python 3.6 -Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue16
New submission from Eric Snow:
In Lib/importlib/_bootstrap.py, module_from_spec() specifies that the current
deprecation warning should be an error in 3.6. So, here's a patch.
--
assignee: eric.snow
components: Interpreter Core
files: module_from_spec.diff
keywords: patch
mes
Changes by Eric Snow :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Eric Snow:
Doc/reference/compound_stmts.rst needs to be updated to reflect the changes
from PEP 468.
--
assignee: eric.snow
components: Documentation
messages: 275153
nosy: eric.snow
priority: normal
severity: normal
status: open
title: Update the language reference
Changes by Eric Snow :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue28030>
___
Eric Snow added the comment:
Note that most of the changes here have been reverted in changeset
103366:a964b8d2324e9f22a66e458ea72e6d5c8c1fcc93.
--
___
Python tracker
<http://bugs.python.org/issue24
Changes by Eric Snow :
--
Removed message: http://bugs.python.org/msg275185
___
Python tracker
<http://bugs.python.org/issue24254>
___
___
Python-bugs-list mailin
Eric Snow added the comment:
It may be worth refactoring the patch relative to the new C99 support.
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue22
Changes by Eric Snow :
--
assignee: eric.snow ->
___
Python tracker
<http://bugs.python.org/issue16221>
___
___
Python-bugs-list mailing list
Unsubscrib
Eric Snow added the comment:
Thanks for pointing this out, Alexander.
--
___
Python tracker
<http://bugs.python.org/issue27576>
___
___
Python-bugs-list mailin
Changes by Eric Snow :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Eric Snow :
--
assignee: eric.snow ->
___
Python tracker
<http://bugs.python.org/issue17421>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Eric Snow :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python
Eric Snow added the comment:
LGTM
--
___
Python tracker
<http://bugs.python.org/issue28053>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Changes by Eric Snow :
--
assignee: -> eric.snow
___
Python tracker
<http://bugs.python.org/issue28007>
___
___
Python-bugs-list mailing list
Unsubscrib
Eric Snow added the comment:
Here's a patch to soften the impact of pyc-related problems.
Note:
* Each pyc-related case that previously caused import to fail now results in an
ImportWarning. This applies to both reading and writing .pyc files.
* Each warning has __cause__ set to the c
Changes by Eric Snow :
Added file: http://bugs.python.org/file44604/issue28007.diff
___
Python tracker
<http://bugs.python.org/issue28007>
___
___
Python-bugs-list mailin
Changes by Eric Snow :
Removed file: http://bugs.python.org/file44601/issue28007.diff
___
Python tracker
<http://bugs.python.org/issue28007>
___
___
Python-bugs-list m
Eric Snow added the comment:
I was going to ask Ned, but I'm fine with holding off until 3.7. :)
--
___
Python tracker
<http://bugs.python.org/issue28007>
___
___
Eric Snow added the comment:
With issue #28007 wrapped up, there isn't a lot left to do here. I was
considering that we don't want to abort when we have problems loading a codec
during startup. However, Steve Dower made the point to me that a problem with
the main codec duri
Eric Snow added the comment:
To make sure I'm understanding:
* you are using PyDict_DelItemString() on sys.modules
* a module-level variable in the module is not getting cleaned up when the
module is deleted from sys.modules
* this worked in Python 3.3 but not in 3.5
It may help to h
Eric Snow added the comment:
I agree with Serhiy that __set_name__ should be looked up on the class like all
other special methods. Pickle is a great example why lookup (of __reduce__) on
the instance is a pain.
--
nosy: +eric.snow
___
Python
Eric Snow added the comment:
Hmm. It's not clear what you're after here. The error from your example code
is correct. The valid invocation is:
b.__getattribute__(abs, 'x')
That works just fine. If you want to look up *class* attributes then you must
call __getattrib
New submission from Eric Snow:
tl;dr PyInterpreterState does not need a "modules" field. Attached is a patch
that removes it.
During interpreter startup [1] the sys module is imported using the same C API
[2] as any other builtin module. That API only requires one bit of imp
Eric Snow added the comment:
What's the benefit to adding PyInterpreterState_GetModuleCache()? TBH, it
should only be needed in this short period during startup when the import
system hasn't been bootstrapped yet. After that code can import sys and access
sys.modules from there.
Eric Snow added the comment:
Hmm, actually _PyImport_GetModuleDict() isn't needed to solve the startup
issue. It's still rather internally focused but the same could be said for
PyImport_GetModuleDict(). I guess I'm still not sold on adding a new public
API function for wh
Eric Snow added the comment:
Meh, there really isn't any need for _PyImport_GetModuleDict(). I'll drop it.
Problem solved! :)
--
___
Python tracker
<http://bugs.python.o
New submission from Eric Appelt:
Increase test coverage of the json library, specifically the detect_encoding()
function in the __init__ module, which is used to handle the autodetection of
the encoding of a bytes object passed to json.loads().
This function was added in issue 17909 which
Eric Appelt added the comment:
I looked back and something is clearly wrong with my coverage reporting setup,
sorry :(
When I move the test introduced in issue 17909, 'test_bytes_decode' from the
module Lib/test/test_json/test_unicode.py to Lib/test/test_json/test_decode.py
that
Eric Appelt added the comment:
Thanks for the feedback. I agree that the comment is incorrect for several
iterations of the loop that really don't need to be tested at all for '5'. I
read the previous issue 17909 more carefully along with RFC 4627, 7159, and
EMCA 404 to prop
Eric Snow added the comment:
The syntax is working correctly. Precedence rules are throwing you off. It
should be more clear if we use parentheses to demonstrate precedence explicitly.
You expected:
a, b = (obj.a, obj.b) if obj else [None, None]
However, what you wrote is equivalent to:
a
Eric Appelt added the comment:
I was able to inspect the review, and implemented your suggestions. This is
attached as a new patch. Please let me know if this is not the correct workflow.
Thank you for the prompt review and help as I learn the python tracking and
review process
Eric Appelt added the comment:
I dug into this failure a little bit and verified that it is specifically the
"letter_range" portion of the test that sporadically fails. The hash of any
frozenset constructed from floats, ints, or the empty frozenset, as well as
frozensets r
Eric Appelt added the comment:
I also looked at hashes of strings themselves rather than frozensets to check
the hashing of strings directly.
For example, n=3:
['', 'a', 'b', 'c', 'ab', 'ac', 'bc', 'abc'
Eric Appelt added the comment:
I spent some time looking at the Objects/setobject.c code where the hashing
scheme for frozensets, which essentially works by XOR-ing together the hashes
from all its entries. Significant care is taken to shuffle bits at various
stages, and the algorithm seems
Eric Appelt added the comment:
Ugh... so I think I made a mental error (i.e. confused myself) in the last
comment. The result looked a bit "to good to be true" and I think that there is
at least one error in my thinking about the problem.
I tried testing with the width set to 2 and
Eric Appelt added the comment:
If I understand the reporting properly all tests so far have used SipHash24:
Python 3.7.0a0 (default:5b33829badcc+, Oct 30 2016, 17:29:47)
[GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31)] on darwin
Type "help", "copyright", "credi
3801 - 3900 of 6702 matches
Mail list logo
