Change by Joe Jevnik :
--
keywords: +patch
pull_requests: +13925
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14066
___
Python tracker
<https://bugs.python.org/issu
New submission from Joe Jevnik :
When using PyType_FromSpec, the memory for PyType_Spec.name, Py_tp_methods, and
Py_tp_members needs to somehow outlive the resulting type. This makes it hard
to use this interface to generate types without just leaking the memory for
these arrays, which is
Joe Jevnik added the comment:
Thank you for reviewing this so quickly!
--
___
Python tracker
<https://bugs.python.org/issue36068>
___
___
Python-bugs-list mailin
Change by Joe Jevnik :
--
keywords: +patch
pull_requests: +12006
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36068>
___
___
Py
New submission from Joe Jevnik :
The new _tuplegetter objects for accessing fields of a namedtuple are no longer
serializable with pickle. Cloudpickle, a library which provides extensions to
pickle to facilitate distributed computing in Python, depended on being able to
pickle the members of
Change by Joe Jevnik :
--
pull_requests: +7946
___
Python tracker
<https://bugs.python.org/issue23927>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Joe Jevnik :
--
pull_requests: +7754
___
Python tracker
<https://bugs.python.org/issue23926>
___
___
Python-bugs-list mailing list
Unsubscribe:
Joe Jevnik added the comment:
I added a benchmark suite (using Victor's perf utility) to cnamedtuple. The
results are here: https://github.com/ll/cnamedtuple#benchmarks
To summarize: type creation is much faster; instance creation and named
attribute access are a bit f
Changes by Joe Jevnik :
--
pull_requests: +1919
___
Python tracker
<http://bugs.python.org/issue13349>
___
___
Python-bugs-list mailing list
Unsubscribe:
Joe Jevnik added the comment:
As a more meta question: I have noticed that many error messages in the stdlib
use PyErr_SetString, or choose to use the type name instead of the repr of the
object. Is there a reason for this? I normally try to fill the error message
with as much context as
Joe Jevnik added the comment:
I agree, "%R in tuple" is enough information for me. This would also remove the
need to manually repr the object.
--
type: enhancement ->
___
Python tracker
<http://bugs.pytho
New submission from Joe Jevnik:
The old error of tuple.index(x): x not in tuple seemed very confusing to me. It
was also harder to quickly understand what the program was doing wrong. This
saves people a second pass through the program under the debugger because they
can just see what the
New submission from Joe Jevnik:
I opened a pr to remove a line in the docs about $ needing to follow | in
PyArg_ParseTupleAndKeywords. In practice, you can just use a $ to create
required keyword arguments which intuitively makes sense. I was told this
should raise a SystemError; however, you
Changes by Joe Jevnik :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
___
Python tracker
<http://bugs.python.org/issue30180>
___
_
New submission from Joe Jevnik:
In zipfile.py only OSError is checked to see if seek fails:
```
def _EndRecData64(fpin, offset, endrec):
"""
Read the ZIP64 end-of-archive records and use that to update endrec
"""
try:
fpin.seek(offse
Joe Jevnik added the comment:
The issue appears to be in ceval.c:unicode_concatenate (or the py2 equivalent)
The code sets the local variable on the lhs to NULL before doing a potentially
inplace append to the string. This means that if a signal is raised during the
concat, we never hit the
Joe Jevnik added the comment:
I definitely could have used PyImport_Import and PyObject_Call to accomplish
this task; however, when I looked at at the implementation of these functions
it seemed like a lot of overhead and book keeping just to set a boolean. Since
I was already in a C
New submission from Joe Jevnik:
I was writing an extension module that was working with weakrefs and wanted to
ensure that the GC would not run for a block of code. I noticed that
gc.enable/gc.disable are not exposed to C and the state of the gc is in a
static variable so it cannot be mutated
Joe Jevnik added the comment:
bump
--
___
Python tracker
<http://bugs.python.org/issue27241>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Joe Jevnik added the comment:
Sorry about undoing the settings, that was unintentional. The UI around these
settings is sort of unintuitive.
I was waiting to propose this on python-dev until I got it working, but I
wanted to push up what I did have as a work in progress so I could try to get
Joe Jevnik added the comment:
Assuming all dicts are ordered, there will be no need for this (as long as the
parser preserves order) so I am okay with dropping this.
One of the main use cases I have for wanting nice literals is when I am working
on tests. I find it very nice to be able to
New submission from Joe Jevnik:
This proposes the following syntax for creating OrderedDict literals:
OrderedDict[k1: v1, k2: v2, ...]
This is implemented by putting a metaclass on OrderedDict which has a getitem
that turns the slices into a list of tuples (after validation).
The idea is
New submission from Joe Jevnik:
I was trying to add a file and accidently mistyped the name which crashed the
repl session. I think it would be nicer to report the failure but bring me back
to the prompt so I can decide what I would like to do.
This patch catches any IOErrors that can be
Joe Jevnik added the comment:
This seems to just be a bug in the implementation of remove. I have a patch to
fix this and a test case.
--
keywords: +patch
nosy: +ll
Added file: http://bugs.python.org/file42875/bytearray-remove.patch
Joe Jevnik added the comment:
people have had some time to think about this, whats should the name be so we
can merge this?
--
___
Python tracker
<http://bugs.python.org/issue25
Joe Jevnik added the comment:
CALL_FUNCTION doesn't use extended arg; I don't see what we get by adding some
opcode to convert the sequence into a tuple. We also don't want to box up the
stack arguments into a tuple because when we do a CALL_FUNCTION to a python
function w
Joe Jevnik added the comment:
> It's possible that stararg is already an empty tuple. Is it worth to use it?
PyTuple_New(0) should return the unit tuple in most cases:
#if PyTuple_MAXSAVESIZE > 0
if (size == 0 && free_list[0]) {
op = free_list[0];
Py
Changes by Joe Jevnik :
--
type: -> performance
___
Python tracker
<http://bugs.python.org/issue26802>
___
___
Python-bugs-list mailing list
Unsubscrib
Joe Jevnik added the comment:
in _PyEval_EvalCodeWithName we will have already pulled the underlying array
out of the tuple subclass and the then we will reconstruct the vararg value in
the locals from this array. This means that with this patch we can get:
>>> class C(tup
Joe Jevnik added the comment:
bump
--
___
Python tracker
<http://bugs.python.org/issue23926>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from Joe Jevnik:
When star unpacking positions into a function we can avoid a copy iff there are
no extra arguments coming from the stack. Syntactically this looks like:
`f(*args)`
This reduces the overhead of the call by about 25% (~30ns on my machine) based
on some light
Changes by Joe Jevnik :
--
nosy: +ll
___
Python tracker
<http://bugs.python.org/issue26448>
___
___
Python-bugs-list mailing list
Unsubscribe:
Joe Jevnik added the comment:
The recipe you showed looks like it is very complicated for the expected use
case of decompressing all of the data into a mutable buffer. One difference I
see with this and struct.pack_into or socket.recv_into is that in both of those
cases we know how large our
Joe Jevnik added the comment:
ping: any decision on this?
--
___
Python tracker
<http://bugs.python.org/issue25770>
___
___
Python-bugs-list mailing list
Unsub
New submission from Joe Jevnik:
Adds a keyword only flag to zlib.decompress and zlib.Decompress.decompress
which marks that the return type should be a bytearray instead of bytes.
The use case for this is reading compressed data into a mutable array to do
further operations without requiring
Joe Jevnik added the comment:
> and the latter might give the impression it was some sort of special
> method/attribute when it was not.
Wouldn't adding this be special because it is specifically reserved by CPython
as an implementation detail?
Also, would adding this name
Joe Jevnik added the comment:
Is there a decision on the name? I can update the patch if needed.
--
___
Python tracker
<http://bugs.python.org/issue25770>
___
___
Joe Jevnik added the comment:
partial's unique usage is why I feel like it would be so jarring for them do be
named differently. I would be happiest having this feature at all so I will
change the name to 'kwargs' if you would like. I just want to be sure that my
reasons fo
Joe Jevnik added the comment:
I agree that it is a strange name and I also think that it could be immutable
or a copy of the internal dict; however, I think that consistency with existing
APIs in the standard library is more important. 'keywords' is still very clear
in context and
Joe Jevnik added the comment:
I only want this feature to keep the usage close to functools.partial. I was
actually sort of surprised to see that mutation of the dict held in partial,
but I would rather be consistent.
--
___
Python tracker
<h
Joe Jevnik added the comment:
Added a test case for the mutation of keywords.
--
Added file: http://bugs.python.org/file41204/methodcaller-attrs-2.patch
___
Python tracker
<http://bugs.python.org/issue25
Joe Jevnik added the comment:
Thanks for pointing me at the refleak, uploading an update
--
Added file: http://bugs.python.org/file41203/methodcaller-attrs-1.patch
___
Python tracker
<http://bugs.python.org/issue25
Joe Jevnik added the comment:
Thanks for review, looking into the reference count issue.
--
___
Python tracker
<http://bugs.python.org/issue25770>
___
___
Pytho
New submission from Joe Jevnik:
This patch adds 3 properties to methodcaller objects for inspecting the object
at runtime:
1. 'name': the name of the method to call
2. 'args': the position arguments to pass to the method
3. 'keywords': the keyword arguments t
Joe Jevnik added the comment:
bumping this issue
--
___
Python tracker
<http://bugs.python.org/issue23926>
___
___
Python-bugs-list mailing list
Unsubscribe:
Joe Jevnik added the comment:
Sorry about the ideas thread. Thank you for merging this!
--
___
Python tracker
<http://bugs.python.org/issue24379>
___
___
Pytho
Joe Jevnik added the comment:
I posted this to python Ideas on June 10th of this year. That is where we
decided to rename it from `slice.literal` to `operator.subscript`.
--
___
Python tracker
<http://bugs.python.org/issue24
Joe Jevnik added the comment:
bumping so that we don't forget about this.
--
___
Python tracker
<http://bugs.python.org/issue23926>
___
___
Python-bugs-list m
Joe Jevnik added the comment:
Any more comments?
--
___
Python tracker
<http://bugs.python.org/issue24379>
___
___
Python-bugs-list mailing list
Unsubscribe:
Joe Jevnik added the comment:
Sorry it took so long to get back to this. I didn't realize this was still
open. I have provided the update to the docs and moved it to the 3.6 section. I
also made sure the patch still applies and the tests all pass.
--
Added file: http://bugs.pytho
Joe Jevnik added the comment:
I updated the docstring
--
___
Python tracker
<http://bugs.python.org/issue24379>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Joe Jevnik :
Added file: http://bugs.python.org/file39913/operator_subscript_pyonly.patch
___
Python tracker
<http://bugs.python.org/issue24379>
___
___
Pytho
Changes by Joe Jevnik :
Added file: http://bugs.python.org/file39907/operator_subscript_pyonly.patch
___
Python tracker
<http://bugs.python.org/issue24379>
___
___
Pytho
Joe Jevnik added the comment:
is it normal to get a lot of 500s when using the review system?
--
Added file: http://bugs.python.org/file39906/operator_subscript_pyonly.patch
___
Python tracker
<http://bugs.python.org/issue24
Joe Jevnik added the comment:
updating to address the docs and order of assertions
--
Added file: http://bugs.python.org/file39904/operator_subscript_pyonly.patch
___
Python tracker
<http://bugs.python.org/issue24
Joe Jevnik added the comment:
updating with the slots change
This also adds a ton of test cases
--
Added file: http://bugs.python.org/file39902/operator_subscript_pyonly.patch
___
Python tracker
<http://bugs.python.org/issue24
Joe Jevnik added the comment:
Ah, I hadn't seen that, I will address those now, sorry about that.
--
___
Python tracker
<http://bugs.python.org/is
Joe Jevnik added the comment:
ping: is there anything blocking this?
--
___
Python tracker
<http://bugs.python.org/issue24379>
___
___
Python-bugs-list mailin
Joe Jevnik added the comment:
I removed the C implementation.
--
Added file: http://bugs.python.org/file39792/operator_subscript_pyonly.patch
___
Python tracker
<http://bugs.python.org/issue24
Joe Jevnik added the comment:
I just moved it over since I implemented it for slice originally, I can drop
the C implementation.
--
___
Python tracker
<http://bugs.python.org/issue24
Joe Jevnik added the comment:
Based on some discussion on python-ideas, this is being renamed to
operator.subscript. Here is the patch that makes the correct the changes to
move this object into the operator module.
--
components: +Extension Modules -Interpreter Core
title
Joe Jevnik added the comment:
It is a singleton, does not accept the `maketuple` flag, and is written in C. I
did not know about the s_ attribute of numpy before writing this; however, I
still think that moving this object to slice improves code clarity (s_ is not a
super clear name). I also
Joe Jevnik added the comment:
>>> slice.literal[0]
0
>>> y = slice.literal[1:2]
slice(1, 2, None)
>>> slice.literal[0:1, ..., 3]
(slice(0, 1, None), Ellipsis, 3)
The way this object works right now does not create instances of some inner
class of slice, instead,
Joe Jevnik added the comment:
> What I'm missing is a way to use such an object to actually index/slice
> something
Sorry, I am not sure I understand what you mean by this? You can pass a slice
object, or a tuple of slices in subscript notation.
>>> [1, 2, 3, 4][slice(2)]
Joe Jevnik added the comment:
> Why not index the slice type itself? slice[1:2]
I originally considered this and I personally really like this syntax, but I
was concerned with ambiguity with the typing module
> The only question in my mind is what slice should do when given just a
Joe Jevnik added the comment:
Here is the patch that includes the updates to 'slice.__repr__'
--
Added file: http://bugs.python.org/file39615/slicerepr.patch
___
Python tracker
<http://bugs.python.o
New submission from Joe Jevnik:
I often find that when working with pandas and numpy I want to store slice
objects in variables to pass around and re-use; however, the syntax for
constructing a slice literal outside of an indexer is very different from the
syntax used inside of a subscript
Joe Jevnik added the comment:
I don't think that we need to worry about reusing the single argument tuple in
a recursive situation because we never need the value after we start the call.
We also just write our new value and then clean up with a NULL to make sure
that we don't blow
Joe Jevnik added the comment:
I am currently on a different machine so these numbers are not relative to the
others posted earlier.
* default
./python -m timeit -s "from collections import namedtuple as n;a = n('n', 'a b
c')(1, 2, 3)" "a.a"
100
Joe Jevnik added the comment:
I don't think that I can cache the __call__ of the fget object because it might
be an instance of a heaptype, and if someone changed the __class__ of the
object in between calls to another heaptype that had a different __call__, you
would still get the __c
Joe Jevnik added the comment:
I switched to the static tuple.
--
Added file: http://bugs.python.org/file39216/with-static-tuple.patch
___
Python tracker
<http://bugs.python.org/issue23
Joe Jevnik added the comment:
This was very exciting, I have never run gprof before; so just to make sure I
did this correctly, I will list my steps:
1. compile with the -pg flag set
1. run the test with ./python -m timeit ...
1. $ gprof python gmon.out > profile.out
Here is default:
E
Joe Jevnik added the comment:
I was unable to see a performance increase by playing with the
itemgetter.__call__ code; however, updating the propery code seemed to show a
small improvement. I think that for simple indexing the cost of checking if it
is a sequence outways the faster dispatch
Joe Jevnik added the comment:
I tried bumping the magic number; however, I still cannot get consistent
results when running benchmark locally. I guess I will close this as I cannot
consistently show an improvement.
--
status: open -> clo
Joe Jevnik added the comment:
I am actually getting inconsistent results from running benchmark; I am pretty
surprised by this. I could look into making the second pass only happen if the
code has the CO_OPTIMIZED bit set; however, based on the results I am seeing
from the benchmark runs, I
New submission from Joe Jevnik:
There are a lot of optimizations that are being missed by only running a single
pass of PyCode_Optimize. I originally started by trying to optimize for De
Morgan's Laws in if tests; however, I realized that the issue actually went
away if you run the opti
Joe Jevnik added the comment:
This is a different case from raising an AttributeError inside the __call__;
>>> class C(object):
... def __call__(self):
... raise AttributeError()
...
>>> hasattr(C(), '__call__')
True
>>> class D(object):
...
Joe Jevnik added the comment:
"The purpose of callable is to report whether an instance is callable or not"
I am totally with you so far until you get to: "and that information is
available on the instance's class, via the presence of __call__". I don't
understa
Joe Jevnik added the comment:
I don't see how it is a bug that you can make __call__ an arbitrary descriptor
as long as it returns a valid callable. if n.__call__ is a valid callable, why
should it matter that it was looked up as a descriptor or as an instancemethod?
--
Joe Jevnik added the comment:
As ionelmc mentioned, it does address the issue proposed originally and in the
patch this is added as another test case for the callable function
--
___
Python tracker
<http://bugs.python.org/issue23
Joe Jevnik added the comment:
I don't think that using a property to define a callable in the class is a bug;
while it seems less ideal, I don't understand why it would be unsupported with
callable when it executes correctly.
--
___
Pyth
Changes by Joe Jevnik :
Removed file: http://bugs.python.org/file39090/callable.diff
___
Python tracker
<http://bugs.python.org/issue23990>
___
___
Python-bugs-list mailin
Joe Jevnik added the comment:
Oops, I messed up the test case; here is a fixed version (the class name was
wrong). Just a note: all the existing test cases passed AND the one proposed in
this thread.
I understand that it is currently working as intended; however, the argument is
that the
Joe Jevnik added the comment:
I am also confused by this; I would imagine that callable(obj) would respect
the descriptor protocol.
I have a proposed patch that would make this work with descriptors.
--
keywords: +patch
Added file: http://bugs.python.org/file39090/callable.diff
Changes by Joe Jevnik :
--
nosy: +ll
___
Python tracker
<http://bugs.python.org/issue23990>
___
___
Python-bugs-list mailing list
Unsubscribe:
Joe Jevnik added the comment:
I have added a patch to add these to UserString. I also wrote a test case that
would check the UserString, UserList, and UserDict's methods to make sure that
new methods to str, list, or dict (or the removal of one of those methods from
the User* version)
Joe Jevnik added the comment:
I can look into rewriting the framework to use multiprocessing; however, should
we split this into a separate issue or block this one until that work is done.
--
___
Python tracker
<http://bugs.python.org/issue5
Joe Jevnik added the comment:
I think that the idea is not to get as close to the limit as possible but just
to hard cap the memory usage of the test suite so that it doesn't get
oom-killed. twouters, does this sound correct? Also, I think that this means
that the new decorator is report
Joe Jevnik added the comment:
Has the test passed or is it still hung? Also, I guess this means that the
tuple is over-allocating, maybe I need to revise the memory assumptions to
account for the growth algorithm.
--
___
Python tracker
<h
Joe Jevnik added the comment:
I am updating the patch to include an entry in Misc/NEWS.
--
Added file: http://bugs.python.org/file38994/namedtuple-indexer-with-news.patch
___
Python tracker
<http://bugs.python.org/issue23
Joe Jevnik added the comment:
The tests need to be run with higher memory caps, this can be set with the -M
flag, like "python -m test -M 64G test_bigmem". I am under the impression that
these tests don't get run all the time so we might want to
Joe Jevnik added the comment:
I am not sure yet; I don't have access to a machine that can run the test.
--
___
Python tracker
<http://bugs.python.org/i
Joe Jevnik added the comment:
Steve, we talked about the possibility of having you run some of these tests on
a machine with a large amount of ram; I am adding you to the nosy list.
--
nosy: +steve.dower
___
Python tracker
<http://bugs.python.
Joe Jevnik added the comment:
So I think the patch could be applied to 3.4; I will look into moving the other
back sometime this week.
--
___
Python tracker
<http://bugs.python.org/issue22
Joe Jevnik added the comment:
here is a patch and test case.
I added an entry to Misc/NEWS. I tried to follow the format; however, let me
know if I have done this incorrectly.
--
keywords: +patch
nosy: +ll
Added file: http://bugs.python.org/file38972/skipitems.patch
Joe Jevnik added the comment:
I tried to provide a summary of the Linux page on the topic and then said that
it was fully documented there.
--
Added file: http://bugs.python.org/file38957/CAN_RAW_FD_FRAMES-doc.patch
___
Python tracker
<h
Joe Jevnik added the comment:
I have updated the test to make another test that does not have a __len__.
--
Added file: http://bugs.python.org/file38952/bigmem-update.patch
___
Python tracker
<http://bugs.python.org/issue5
Joe Jevnik added the comment:
I am not going to be able to write docs on this because I am not totally sure
how you would use this; There is an entry in the docs for CAN_* so that might
be enough. I have a line now saying that this particular flag is available as
of 3.5 though
Joe Jevnik added the comment:
I am now computing the size based on the system's int and pointer size.
--
keywords: +patch
nosy: +ll
Added file: http://bugs.python.org/file38945/bigmem.patch
___
Python tracker
<http://bugs.py
Joe Jevnik added the comment:
To show where I got my sources:
https://github.com/torvalds/linux/commit/e2d265d3b587f5f6f8febc0222aace93302ff0be
There does not appear to be any new structures needed other than supporting the
constant.
--
nosy: +larry
1 - 100 of 107 matches
Mail list logo
