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
Changes by Joe Jevnik :
Added file: http://bugs.python.org/file39907/operator_subscript_pyonly.patch
___
Python tracker
<http://bugs.python.org/issue24379>
___
___
Pytho
Changes by Joe Jevnik :
Added file: http://bugs.python.org/file39913/operator_subscript_pyonly.patch
___
Python tracker
<http://bugs.python.org/issue24379>
___
___
Pytho
Joe Jevnik added the comment:
I updated the docstring
--
___
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:
Any more comments?
--
___
Python tracker
<http://bugs.python.org/issue24379>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
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:
Sorry about the ideas thread. Thank you for merging this!
--
___
Python tracker
<http://bugs.python.org/issue24379>
___
___
Pytho
Joe Jevnik added the comment:
bumping this issue
--
___
Python tracker
<http://bugs.python.org/issue23926>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
Thanks for review, looking into the reference count issue.
--
___
Python tracker
<http://bugs.python.org/issue25770>
___
___
Pytho
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:
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:
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:
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:
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:
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:
> 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
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:
ping: any decision on this?
--
___
Python tracker
<http://bugs.python.org/issue25770>
___
___
Python-bugs-list mailing list
Unsub
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
Changes by Joe Jevnik :
--
nosy: +ll
___
Python tracker
<http://bugs.python.org/issue26448>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Joe Jevnik added the comment:
bump
--
___
Python tracker
<http://bugs.python.org/issue23926>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
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
Changes by Joe Jevnik :
--
type: -> performance
___
Python tracker
<http://bugs.python.org/issue26802>
___
___
Python-bugs-list mailing list
Unsubscrib
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
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:
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:
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
New submission from Joe Jevnik:
I am working on implementing nameduple in C; I am almost there; however, on the
path of moving to full compatibility, I ran into a refcount issue somewhere.
Hopefully someone can help me work this out.
To describe the issue, When I run the collections tests I
Joe Jevnik added the comment:
Ideally, namedtuple is used to make your code cleaner, using "magic" indecies
is less clear than using a named index in a lot of cases. Because namedtuple is
mainly to make the code more readable, I don't think that it should have an
impact
Joe Jevnik added the comment:
would the idea be to deprecate namedtuple in favor of a public structseq that
is exposed through collections, or change structseq to fit the namedtuple API?
--
___
Python tracker
<http://bugs.python.org/issue23
Joe Jevnik added the comment:
I stripped down the patch to only the descriptor like we had discussed.
--
Added file: http://bugs.python.org/file38896/namedtuple.patch
___
Python tracker
<http://bugs.python.org/issue23
Joe Jevnik added the comment:
# Original version / new python implementation
./python -m timeit -s "from collections import namedtuple;a = namedtuple('a',
'a b c')(1, 2, 3)" "a.a"
1000 loops, best of 3: 0.07 usec per loop
# C implementation
./pyth
Joe Jevnik added the comment:
sorry, I meant pypy
--
___
Python tracker
<http://bugs.python.org/issue23910>
___
___
Python-bugs-list mailing list
Unsubscribe:
Joe Jevnik added the comment:
I have added a patch to update this with conditional compilation.
--
keywords: +patch
nosy: +ll
Added file: http://bugs.python.org/file38934/CAN_RAW_FD_FRAMES.patch
___
Python tracker
<http://bugs.python.
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
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:
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 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 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:
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:
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:
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:
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:
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 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:
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 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:
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 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)
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 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
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
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:
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
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 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:
"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:
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):
...
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:
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
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 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:
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 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:
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 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 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
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:
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 P. Cool <[EMAIL PROTECTED]>:
If I call os.environ.clear in a python program child processes still
see the cleared entries. But when I iterate over the keys like so
names = os.environ.keys()
for k in names:
del os.environ[k]
then the entries are also delet
201 - 274 of 274 matches
Mail list logo
