New submission from Eric Snow ericsnowcurren...@gmail.com:
While perhaps esoteric, it looks like exec'ing a code object that has freevars,
using a closure that has too few cells causes a segfault. I believe the
problem is around line 3276 of ceval.c at the PyTuple_GET_ITEM call
Eric Snow ericsnowcurren...@gmail.com added the comment:
I'm hoping to release it this week. Nick helped be a bunch with it during
pycon sprints. I basically took call_function in ceval.c and got it working
for arbitrary code blocks and exposed it as exec_closure to look like exec.
On Thu
Eric Snow ericsnowcurren...@gmail.com added the comment:
It's a C function that for now I have in an extension module. If it turns
out to be useful I am going to try to get it put into the builtins, but I
don't want to get ahead of myself.
--
Added file: http://bugs.python.org
Eric Snow ericsnowcurren...@gmail.com added the comment:
In 2.7 I get the following (if Y does not inherit from object):
print('res:', 1 in y)
('X contains:', 1)
('res:', False)
This makes sense with old style classes. With Y(object):
print('res:', 1 in y)
Y iter
('res:', True
Eric Snow ericsnowcurren...@gmail.com added the comment:
Duplicate of issue8130.
When an exception has been assigned using as target, it is cleared at the end
of the except clause. [1]
See:
[1] http://docs.python.org/py3k/reference/compound_stmts.html#the-try-statement
[2] http
Eric Snow ericsnowcurren...@gmail.com added the comment:
Wow! I was literally working on this problem yesterday. The abstract check is
done at instantiation time (in object.__new__, typeobject.c). So as it stands
__new__ has no way to validate that all your abstract properties have been
Eric Snow ericsnowcurren...@gmail.com added the comment:
As far as I have found, there isn't a way to make it work implicitly without
changing object.__new__. I just posted some of the approaches I could think of
to python-list:
http://mail.python.org/pipermail/python-list/2011-May/1272604
New submission from Eric Snow ericsnowcurren...@gmail.com:
Here's a patch to add a page to the devguide on running a build slave. I
copied pretty liberally from the wiki (http://wiki.python.org/moin/BuildBot).
That page may or may not be up to date (I don't know), so the bulk of this new
Eric Snow ericsnowcurren...@gmail.com added the comment:
Great feedback! Keep in mind that nearly all the content in my patch is pulled
unedited from either the wiki page and the python-dev thread I mentioned.
I'll work on cleaning it up when I get a chance (probably after Wednesday's
PyCon
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8087
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
Could you just cancel the chained exception?
try: {}[asdf]
... except KeyError:
... try: raise Exception()
... except Exception as x:
... x.__cause__ = None
... x.__context__ = None
... x
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13187
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue415492
___
___
Python-bugs
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13192
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
Are you suggesting raising the OSError (or something else) rather than an
ImportError? If so, would it make sense to chain the exception instead. That
way the existing code that expects ImportError continues to work, while still
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12915
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
Per Ezio's and Stefan's feedback I cleaned things up a little:
* consolidated on Buildbot
* clarified the meaning of the standard development toolchain
* % changed to $
* cleaned up the network ports section
* removed a bunch of outdated
Changes by Eric Snow ericsnowcurren...@gmail.com:
Added file: http://bugs.python.org/file23479/devguide-buildbots-2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13124
New submission from Eric Snow ericsnowcurren...@gmail.com:
Looks like Parser/asdl_c.py did not get all the way updated when _Py_identifier
switched over to _Py_IDENTIFER. I've included a patch that fixes it (though
it's relatively trivial). With this fix I did not notice any further problems
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10977
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
FYI, the following changesets were also for this issue. They had the wrong
issue number (#13661, which doesn't actually exist so no big deal), which is
why they didn't show up in this issue automatically.
New changeset 5f3b7528b144
Eric Snow ericsnowcurren...@gmail.com added the comment:
@msg147513
Why don't you just write
self.assertIs(type(myobj), sometype)
+1
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13387
Eric Snow ericsnowcurren...@gmail.com added the comment:
4) she got annoyed that two completely different notations where used
for two very close concepts
This is a good point, and we are trying to move to the arg=default
notation. Unfortunately there are still places that use the old
Eric Snow ericsnowcurren...@gmail.com added the comment:
For the stat module in the Obsolete section[1], should the entry be updated
to indicate that the module was left alone (see issue 2874)?
Would it be worth having the Merging C and Python Impl... section[2] include
a reference to PEP 399
Eric Snow ericsnowcurren...@gmail.com added the comment:
Me too. (Can you give the #ids of these other issues?)
#13012 is the one that I was thinking of (msg144328 specifically). However,
I'm sure there was one more recently (which I can't find now
Eric Snow ericsnowcurren...@gmail.com added the comment:
@msg147671
+1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13386
___
___
Python-bugs
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13411
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13429
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
@eric.smith: +1
@Retro: If you are intent on pushing this, please take it to
python-id...@python.org. However, judging from the response in this ticket and
#10562, you won't get much traction.
--
nosy: +eric.snow
Eric Snow ericsnowcurren...@gmail.com added the comment:
@brian.curtin: +1
@Retro: as noted in #10621, please take this to python-id...@python.org
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10562
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13402
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13445
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12618
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10854
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13224
___
___
Python-bugs-list
New submission from Eric Snow ericsnowcurren...@gmail.com:
The doc on code execution[1] leaves out mention of the -m flag. Seems like it
belongs there too.
[1] Doc/reference/executionmodel.rst
--
assignee: docs@python
components: Documentation
messages: 148288
nosy: docs@python
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
+1 Both the -p and --nopath0 would be great additions and a good match for PEP
395.
So -p . would be equivalent to the current implicit sys.path[0]
initialization, right? Would any other effects happen with -p than
sys.path[0
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8754
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
The current behavior is an implicit -p ., which causes all sorts of
hard-to-figure-out problems, most of which PEP 395 is rightly trying to fix.
I'm suggesting that the next step would be to make --nopath0 the default
(rendering
Eric Snow ericsnowcurren...@gmail.com added the comment:
Éric has addressed this in http://hg.python.org/peps/rev/6c7415a4f0f3 (thanks
Éric). Do the docs for python.org have to be manually rebuilt or is that on a
cron?
--
___
Python tracker rep
Eric Snow ericsnowcurren...@gmail.com added the comment:
First of all, I don't want Nick's proposal in this issue (the -p and --nopath0
flags) to be misunderstood because of me. His is a great idea that will make a
really useful shortcut available and will _not_ change any current behavior
Eric Snow ericsnowcurren...@gmail.com added the comment:
Yeah, the more I think about it, the more I agree it's Python 4 fodder.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13475
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13457
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
Thanks, Éric. That's what I figured. I asked because the PEPs page doesn't
appear to reflect the change:
http://www.python.org/dev/peps/
I checked to be sure it fixed it before I submitted the patch. That's why I
asked about auto
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13487
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
Thanks, Éric. That looks good. I'll keep that HTML title thing in mind. :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12307
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1877
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6816
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11374
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13533
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11051
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2919
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13588
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
Check out: http://code.activestate.com/recipes/
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13585
Eric Snow ericsnowcurren...@gmail.com added the comment:
Just following up on this ticket. Anyone have any objections to Brian's patch?
Also, would 'fullname' be more appropriate than 'name', to be more in sync with
that identifier in importlib
Eric Snow ericsnowcurren...@gmail.com added the comment:
AFAICT, #1559549 is the ImportError attribute ticket.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2377
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11957
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13592
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2134
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
I'm guessing that more than just Python/import.c should be updated, and more
than one spot in import.c.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1559549
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12082
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1785
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8098
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13645
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13607
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
My response to a similar query:
What it enables is the ability to introspect the *actual* function object
belonging to the currently executing code, whether in the same execution frame
or in a later one on the stack. We don't have
Eric Snow ericsnowcurren...@gmail.com added the comment:
with f_func (see #12857) you would get that for free:
frame.f_func.__qualname__
'A.f1'
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13672
Eric Snow ericsnowcurren...@gmail.com added the comment:
True. I wonder, though if perhaps a co_func (as a weak ref) or co_orig_func
would be better, since co_qualname would be built from the original function
anyway. Then you could call code.co_func.func_qualname.
One sticky point
Eric Snow ericsnowcurren...@gmail.com added the comment:
Interesting thought, the syntax seems unnecessary. Adding new syntax to the
language is something that happens rarely and only with a _lot_ of
consideration.
As a slightly more verbose alternative, currently you can do this:
def
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13562
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
see http://docs.python.org/library/sys.html#sys.path
As initialized upon program startup, the first item of this list, path[0], is
the directory containing the script that was used to invoke the Python
interpreter. If the script
Eric Snow ericsnowcurren...@gmail.com added the comment:
The vulnerability is known since 2003 (Usenix 2003): read Denial of
Service via Algorithmic Complexity Attacks by Scott A. Crosby and Dan
S. Wallach.
Crosby started a meaningful thread on python-dev at that time similar to the
current
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6531
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
FYI: unless importlib took undue liberties (unlikely), frozen modules also
precede path-based modules. See the implicit additions to sys.meta_path in
Lib/importlib/_bootstrap.py.
Whether or not to include a mention of frozen modules
Eric Snow ericsnowcurren...@gmail.com added the comment:
what value do you see for __package__ in pkgA?
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13912
Eric Snow ericsnowcurren...@gmail.com added the comment:
Jason: just a warning. importlib_backport is a relatively naive tool for
generating the backport from the py3k source. It's also relatively fragile and
at this point probably doesn't work with the default branch
Eric Snow ericsnowcurren...@gmail.com added the comment:
The problem is your level is off and the name is incomplete.
master.pkgA.foo.py should have the following:
__import__('pkgB.bar', master.pkgA.__dict__, level=2).bar
or
__import__('pkgB.bar', master.pkgA.__dict__, fromlist
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13405
___
___
Python-bugs-list
Eric Snow added the comment:
What is wrong with the following?
class Point(namedtuple('Point', 'x y')):
A 2-dimensional coordinate
x - the abscissa
y - the ordinate
This seems more clear to me. namedtuple is in some ways a quick-and-dirty
type, essentially a more true
Eric Snow added the comment:
+1, Terry
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16669
___
___
Python-bugs-list mailing list
Unsubscribe
Eric Snow added the comment:
Patch looks good to me. Are there any other exceptions that might be included
here?
--
nosy: +brett.cannon, eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16730
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16795
___
___
Python-bugs-list
Eric Snow added the comment:
Looks like a case where the concrete dict API is ignoring subtype
implementations.
In your example the attribute access will be handled by a LOAD_ATTR which calls
PyObject_GetAttr() (Python/ceval.c:2369). That ends up calling
PyFunction_Type.tp_getattro
New submission from Eric Snow:
Here's an initial stab at writing OrderedDict in C. Though, the implementation
is not heavily optimized and isn't super subclass-friendly, my hope is that
it's relatively close to the final version. I'm getting this up now to get
some eyes on it.
The spot
Eric Snow added the comment:
@Benjamin: Yeah, I've fixed that.
@Ezio: Good point. I've touched that up.
Once I have cleared up reference counting issues I'll put up a new patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16803
___
___
Python-bugs-list
Eric Snow added the comment:
Also missing a pure-Python implementation:
collections.defaultdict (relatively trivial)
collections.deque
In the spirit of what Brett said, I found that PyPy has an implementation
already:
https://bitbucket.org/pypy/pypy/src/default/lib_pypy/_collections.py
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1674555
___
___
Python-bugs
Eric Snow added the comment:
Here's a cleanup of test.test_collections that helps keep the subsequent patch
(still forthcoming) cleaner.
--
Added file: http://bugs.python.org/file28839/cleanup-test-collections.diff
___
Python tracker rep
New submission from Eric Snow:
Related to issue #16817 and to my efforts on a C OrderedDict, I think it would
be nice to have a class decorator that handles most of the PEP 399 requirements
for you. The attached patch adds such a decorator to test.support.
--
assignee: eric.snow
Eric Snow added the comment:
So the current solution is to temporarily put the relevant module in place in
sys.modules, right? That seems to be the solution that Stefan recommended and
used in the decimal module. Sounds good to me.
I'm hitting this while doing the PEP 399 two-step
Eric Snow added the comment:
One lingering doubt I have is about how I throw the two new test case classes
into the globals. They're already getting bound, as a pair, to the original
test class's name...
--
___
Python tracker rep
Eric Snow added the comment:
One step I left out is handling the whole pickle/copyreg case outlined by
#16817.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17037
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14715
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16737
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16748
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11995
___
___
Python-bugs-list
Eric Snow added the comment:
The decorator also mitigates the problem described in issue #16835.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17037
1 - 100 of 2619 matches
Mail list logo
