Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue21233>
___
___
Python-bugs-list mailing list
Unsubscribe:
Josh Rosenberg added the comment:
General comment on patch: For the flag value that toggles zero-ing, perhaps use
a different name, e.g. setzero, clearmem, initzero or somesuch instead of
calloc? calloc already gets used to refer to both the C standard function and
the function pointer
Josh Rosenberg added the comment:
Additional comment on clarity: Might it make sense to make the calloc structure
member take both the num and size arguments that the underlying calloc takes?
That is, instead of:
void* (*calloc) (void *ctx, size_t size);
Declare it as:
void* (*calloc) (void
Josh Rosenberg added the comment:
Sorry for breaking it up, but the same comment on consistent prototypes
mirroring the C standard lib calloc would apply to all the API functions as
well, e.g. PyMem_RawCalloc, PyMem_Calloc, PyObject_Calloc and
_PyObject_GC_Calloc, not just the structure
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Python-bugs-list mailing list
Unsubscribe:
Josh Rosenberg added the comment:
I think the suggestion is intended for "how do I keep Python 2 semantics in
Python 3?", not "how can I write my Python 2 code so it will run equivalently
in Python 3?"
It wouldn't be a bad idea to point out that you can adopt Py3 sema
Josh Rosenberg added the comment:
Julian: No. See the diff:
http://bugs.python.org/review/21233/diff/11644/Objects/typeobject.c
The original GC_Malloc was explicitly memset-ing after confirming that it
received a non-NULL pointer from the underlying malloc call; that memset is
removed in
Josh Rosenberg added the comment:
Well, to be more specific, PyType_GenericAlloc was originally calling one of
two methods that didn't zero the memory (one of which was GC_Malloc), then
memset-ing. Just realized you're talking about something else; not sure if
you're correct
Josh Rosenberg added the comment:
For the record, I have intentionally used bytes.maketrans to make translation
table for str.translate for precisely this reason; it's much faster to look up
a ordinal in a bytes object than in a dictionary. Before the recent (partial)
patch for str.tran
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue21308>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue21305>
___
___
Python-bugs-list mailing list
Unsubscribe:
Josh Rosenberg added the comment:
I don't know about the other bits, but that trailing '/' is how Argument Clinic
(which makes full featured inspection available to built-in functions) notes
that the parameters are positional only, and cannot be passed by keyword. See
PEP436.
Josh Rosenberg added the comment:
For TransmitFile support, the Windows function to turn an integer file
descriptor into a WinAPI file HANDLE should be _get_osfhandle:
http://msdn.microsoft.com/en-us/library/ks2530z6.aspx
--
nosy: +josh.rosenberg
Josh Rosenberg added the comment:
Why would an subclass of object that doesn't redefine either __eq__ or __ne__
have a different behavior for inequality than object itself? Bar never defined
__eq__, so it shouldn't have an implicit __ne__ any more than object itself
does...
Sayin
Josh Rosenberg added the comment:
Looks like you forgot to actually use the use_calloc parameter you put in the
long_alloc prototype. It accepts it, but it's never used or passed to another
function. So right now, the only difference in behavior is that there is an
extra layer of fun
Josh Rosenberg added the comment:
Given your benchmarks show improvements (you posted while I was typing my last
comment), I'm guessing it's just the posted patch that's wrong, and your local
changes actually use use_calloc?
--
___
Josh Rosenberg added the comment:
While you're doing this, might it make sense to add a special case to long_pow
so it identifies cases where a (digit-sized) value with an absolute value equal
to a power of 2 is being raised to a positive integer exponent, and convert
said cases to equiv
Josh Rosenberg added the comment:
I swear, I need to refresh before I post a long comment.
If this is slowing everything down a little just to make 1 << (2 ** 29) faster
(and did you really mean 1 << (1 << 29) ? :-) ), th
Josh Rosenberg added the comment:
One possible way to salvage it: Have you considered declaring long_alloc as
Py_LOCAL_INLINE, or, now that I've checked #5553, a macro for long_alloc, so it
gets inlined, and doesn't add the check overhead to everything (since properly
inlining with
Josh Rosenberg added the comment:
And now that I'm thinking about it, the probable cause of the slowdown is that,
for any PyLongObject that's smaller than PAGESIZE (give or take), using Calloc
means calloc is just calling memset to zero the PyLongObject header and the
"used&qu
New submission from Josh Rosenberg:
Unlike the other collections ABCs, MappingView and its subclasses
(Keys|Items|Values)View don't define __slots__, so users inheriting them to
take advantage of the mix-in methods get a __dict__ and __weakref__, even if
they try to avoid it by decl
Josh Rosenberg added the comment:
Hmm... First patch isn't generating a review diff (I'm guessing because my VM's
time sync went farkakte). Trying again.
--
Added file: http://bugs.python.org/file35142/slots_for_mappingview_abcs.patch
___
Changes by Josh Rosenberg :
Removed file: http://bugs.python.org/file35141/slots_for_mappingview_abcs.patch
___
Python tracker
<http://bugs.python.org/issue21421>
___
___
Josh Rosenberg added the comment:
I also wrote a slightly more thorough patch that simplifies some of the method
implementations (largely just replacing a bunch of for/if/return True/False
else return False/True with any/all calls against a generator expression).
The one behavior difference
Josh Rosenberg added the comment:
Cool. Thanks for the feedback. I split it into two patches for a reason; I
wasn't wedded to the simplification.
--
___
Python tracker
<http://bugs.python.org/is
Josh Rosenberg added the comment:
Do you mean ProcessPoolExecutor? Thread based pools don't involve serialization.
It would be good for ThreadPoolExecutor to have it as well, to make it easier
to switch between executors, but only ProcessPoolExecutor is suffering from
serialization ove
New submission from Josh Rosenberg:
_PyUnicode_CompareWithId is used exclusively for equality comparisons (after
all, identifiers aren't really sortable in a meaningful way; they're isolated
values, not a continuum). But because _PyUnicode_CompareWithId maintains the
general
Josh Rosenberg added the comment:
I'm not a core developer, but writing the patch is usually considered helpful.
Two notes:
1. Make sure to write unit tests for any new behavior
2. I'd suggest making any such argument keyword-only; if we move closer to the
Java executor model,
Josh Rosenberg added the comment:
It seems to me like that is one of the most obvious consequences. How is this
not an immediately obvious consequence?
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue21
Josh Rosenberg added the comment:
I think the argument against using PyObject_LengthHint for the general iterable
case is that for inputs other than sets or dicts, the assumption is that
significant deduplication will occur. With your patch, if I run:
myset = frozenset([0] * 100)
it will
Josh Rosenberg added the comment:
You'd prefer it say it returns 1 on success and 0 on failure? Or non-zero on
success, zero on failure?
Is true/false that bad? After all, C says 0 is false, all other integer values
are true; phrasing it as zero vs. non-zero may be slightly more techni
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue21513>
___
___
Python-bugs-list mailing list
Unsubscribe:
Josh Rosenberg added the comment:
Changing the docs isn't the main hurdle; the problem is that if we told people
they could test == 1, rather than != 0, then new success return codes couldn't
be added without a long period of warning.
I don't think the convention is consi
Josh Rosenberg added the comment:
Not sure how much that really helps. If I understand you correctly, it would be
a memory optimization that would require a round of rehashing to use?
If you wanted to make a change that got "guaranteed" better performance, you
might add support
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue21515>
___
___
Python-bugs-list mailing list
Unsubscribe:
Josh Rosenberg added the comment:
+1. Makes it easier to swap Executors (which is a big selling point for the
Executor framework), and number of cores is a reasonable default value.
--
nosy: +josh.rosenberg
___
Python tracker
<h
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue20260>
___
___
Python-bugs-list mailing list
Unsubscribe:
Josh Rosenberg added the comment:
Adding warnings for something that is clearly documented (both in the
constructor prototype line and again in the spelled out documentation of the
"mode" argument) is wasteful, particularly when accidental misuse would
immediately lead to an excep
Josh Rosenberg added the comment:
It usually doesn't just mean "outside a required range", it means "outside the
range of values representable due to implementation specific limitations (e.g.
the function is converting to a C type)". You don't raise OverflowErr
Josh Rosenberg added the comment:
I've found it rather ugly to even understand from the lack of code comments for
the C level API it's wrapping. If nothing else, comments explaining the usage
and purpose might be helpful.
--
nosy: +josh
Josh Rosenberg added the comment:
Copying my comment from the previous issue:
For TransmitFile support, the Windows function to turn an integer file
descriptor into a WinAPI file HANDLE should be _get_osfhandle:
http://msdn.microsoft.com/en-us/library/ks2530z6.aspx
This was mentioned on the
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue21744>
___
___
Python-bugs-list mailing list
Unsubscribe:
Josh Rosenberg added the comment:
I would think that allowing the special case optimization would be a good idea.
As is, if you want to take slices of buffers without making copies, you can use
memoryview and get O(1) views of a slice of the memory. But there's nothing
built-in that
Josh Rosenberg added the comment:
I was already thinking of the same solution Christian.Tismer proposed before I
reached his post. namedtuples seem cleaner if they naturally act as singletons,
so (potentially whether or not pickling is involved) declaring a namedtuple
with the same name and
Josh Rosenberg added the comment:
I will admit, on further consideration, a dedicated sequenceview might work
more nicely. islice's interface is limited by its generality; since it doesn't
assume a length, you can't use a negative value for end.
Does anyone think a general seq
Josh Rosenberg added the comment:
I see a few issues with this:
1. Changing the default behavior is a compatibility issue. I've written code
that depends on exceptions being raised if slice assignment sizes don't match.
2. The performance cost is high; changing from rewriting i
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue21679>
___
___
Python-bugs-list mailing list
Unsubscribe:
Josh Rosenberg added the comment:
I don't think you understand how wrapping works. At the time you're enumerating
the stack, the wrapped function has not actually been called. Only the wrapper
has been called. If the stack included "junk" when junk had not yet been
execu
Josh Rosenberg added the comment:
Correct me if I'm wrong, but wouldn't this only become a concern if:
1. You're storing both IPv4 and IPv6 addresses side-by-side
2. You're storing well over a billion IP addresses
3. Hash codes for the hex string of an IP address were pr
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue21817>
___
___
Python-bugs-list mailing list
Unsubscribe:
Josh Rosenberg added the comment:
@Tim: Sorry, forgot the internals there (I read all that a while ago, but it's
not easy to keep all the details in mind). Apparently there are four reasons
this isn't actually a problem. :-)
I agree it's kind of silly that it's conve
Josh Rosenberg added the comment:
Patch needs some work. See comments on patch.
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue18
Josh Rosenberg added the comment:
Are you 100% sure your CA files is in the precise PEM format required by Python
for CA certs, as described in
https://docs.python.org/3/library/ssl.html#ssl-certificates ?
The most likely cause of your failure and success would be if you were using
some
Changes by Josh Rosenberg :
--
title: mmap ehancement - resize with sequence notation -> mmap enhancement -
resize with sequence notation
___
Python tracker
<http://bugs.python.org/iss
Josh Rosenberg added the comment:
No. The first form, raise Class, is in fact a shorthand for raise Class().
That's the point. You only actually raise instances, but if you pass it a class
directly, it instantiates it by calling its constructor with no arguments. The
second form i
Josh Rosenberg added the comment:
I think the section could use some additional rewording actually. The wording
about deriving from type dates back to the Python 2 days; nowadays, all
exceptions are actually required to derive from BaseException. The section
definitely needs rewording
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue10978>
___
___
Python-bugs-list mailing list
Unsubscribe:
Josh Rosenberg added the comment:
Just to be clear, when you say "1 - 5 times per 1000 downloaded files", have
you confirmed that redownloading the same file a second time produces the same
error? Just making sure we've ruled out corruption during transfer over the
network; sma
Josh Rosenberg added the comment:
Never know whether to comment on issue itself, but just in case:
There are issues with the patch when n < 0 is passed, as n is not sanity
checked, which would break the Semaphore invariant (value must be >= 0). n == 0
is also a weird value, but harml
Josh Rosenberg added the comment:
Is it common for C implementations to introspect to figure out their "real"
name? I do this manually for reprs of my user defined classes, but I haven't
noticed many built-ins that consider extensibility for the repr. Maybe I'm just
not us
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue21906>
___
___
Python-bugs-list mailing list
Unsubscribe:
Josh Rosenberg added the comment:
+1; I've had several cases where I'd have used something like this (for the
exact purpose mentioned, to destructively consume an input iterable). I don't
think it's more or less useful than the sentinel version, which is convenient
for
Josh Rosenberg added the comment:
TypeError also should be more specific because it can occur for a multitude of
reasons; along with stuff like AttributeError, it's one of those exceptions
that could arise from multiple causes on a single line of code, none of them
obvious. For the spe
Josh Rosenberg added the comment:
As I said, the main reason is that every feature has to start at minus 100
points. It's not that your idea is bad, it's that it has to be sufficiently
good to warrant the risks that come with any code churn, no matter how small.
"Simple and ob
Josh Rosenberg added the comment:
Have an idea for a name? It already has a done method, which happens to cover
the case of a Future having completed successfully, completed due to an
exception or having been cancelled. Simply calling it "finished()",
"completed()"
Josh Rosenberg added the comment:
Ugh. Left out a key word:
"I see this as making it even easier to do threading *badly*, rather than a
legitimate improvement."
--
___
Python tracker
<http://bugs.python.o
Josh Rosenberg added the comment:
If any of these actually return borrowed references, I'd consider it a serious
documentation bug to not mention it. New reference semantics are the default,
and while it's best to call them out, it can be assumed in most cases.
Returning borrowed
Josh Rosenberg added the comment:
+1. I've been assuming writelines handled arbitrary generators without an
issue; guess I've gotten lucky and only used the ones that do. I've fed stuff
populated by enormous (though not infinite) generators created from stuff like
itertools.
Josh Rosenberg added the comment:
I agree the design requiring it to pass the same information over and over is a
bit odd (I've occasionally had cause to "borrow" some of ipython's niftyness
for a plain Python terminal, and making custom completers work is one of the
more
Josh Rosenberg added the comment:
So you want it to raise the same exception that is raised in Python 3.4? Either
way, I don't think this is a deadlock (to get a deadlock, you'd have to have
contested locks; this lock is being acquired only once). You're explicitly
violati
Josh Rosenberg added the comment:
Similar reference regarding the same basic behavior:
http://blogs.msdn.com/b/oldnewthing/archive/2012/09/07/10347136.aspx
Short version: Indexing and anti-virus tools prevent deletion from occurring.
Longer version:
DeleteFile (and all the stuff that
Josh Rosenberg added the comment:
Please pretend I didn't leave off the actual os.remove call at the end of my
second example that bypasses the issue.
--
___
Python tracker
<http://bugs.python.org/issu
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue21922>
___
___
Python-bugs-list mailing list
Unsubscribe:
Josh Rosenberg added the comment:
Antoine: It's possible this is a legitimate failure in the signal handling
code. The lack of a RuntimeError seems more likely to be due to the code never
executing, not an issue with Condition.wait/Condition.n
Josh Rosenberg added the comment:
Looking at a single lookup performed over and over isn't going to get you a
very good benchmark. If your keys are constantly reused, most of the losses
won't show themselves. A more fair comparison I've used before is the
difference between
Josh Rosenberg added the comment:
This is a natural consequence of Python using reference semantics.
x = y
just makes x and y references to the same object. For immutable objects like
int and str, you'll never notice consequences of this, since changes to the
value (x += 1) replac
Josh Rosenberg added the comment:
Short answer: This is not a bug. Run through one of the comprehensive Python
tutorials on the net (or in Learning Python); reference semantics and their
fairly varied consequences are covered in detail in most of them
Josh Rosenberg added the comment:
On: if (... a+b will not overflow ...) {
Since you limited the optimization for addition to single digit numbers, at
least for addition and subtraction, overflow is impossible. The signed twodigit
you use for the result is guaranteed to be able to store far
Josh Rosenberg added the comment:
It's unlikely to have hung the system entirely. It will slow down a lot though,
as it will consume ridiculous amounts of RAM, and occasionally involve copying
the existing data due to reallocation. The cost of performing this pointless
work may consume e
Josh Rosenberg added the comment:
The main example that comes to mind was a variant of functools.lru_cache I
wrote that expired cache entries after they reached a staleness threshold. The
details elude me (this was a work project from a year ago), but it was
basically what I was describing; a
Josh Rosenberg added the comment:
How often do people need to convert to do platform independent locale encoding
before Python is initialized? Encouraging use of platform dependent wchar_t's
seems like a bad idea when PyUnicode abstracts away the difference ever since
3.3 rel
Josh Rosenberg added the comment:
Note: To my knowledge there is little or no benefit to using maxtasksperchild
when the implementation is using threads. Cleaning up worker processes
intermittently will guarantee that memory, handles, etc., are returned to the
OS. But memory and handles
Josh Rosenberg added the comment:
Actually, now that I think about, most thread local stuff wouldn't be freed
automatically either, since it's still allocated from a common pool of memory,
and interleaved allocations would still prevent memory blocks from being
returned to the OS.
Josh Rosenberg added the comment:
Minor correction to example. That should be:
class MySet(Set):
update = Set.__ior__
(no paren after __ior__, since we're assigning, not calling)
--
nosy: +josh.rosenberg
___
Python tracker
New submission from Josh Rosenberg:
To do what?
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue15986>
___
___
Python-bugs-list mailin
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue11271>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue22181>
___
___
Python-bugs-list mailing list
Unsubscribe:
Josh Rosenberg added the comment:
Okay, dumb question: Is there a reason the Windows code explicitly initializes
c2pwrite in the "stdout not passed" case, while the Linux code leaves it as -1?
Windows doesn't look like it would have the problem (because c2pwrite is always
set t
Josh Rosenberg added the comment:
Can you explain what benefit this would provide? Forcing the thread to exit
gets you relatively little benefit. If it's an infrequently used executor, I
suppose you avoid the cost of leaving worker threads blocked waiting for work,
but that cost is tiny
Josh Rosenberg added the comment:
This sounds like a bug in Numpy. You should probably post it to their tracker:
https://github.com/numpy/numpy/issues
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue22
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue22427>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue19380>
___
___
Python-bugs-list mailing list
Unsubscribe:
Josh Rosenberg added the comment:
LGTM. About a straightforward as it gets.
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue22
Changes by Josh Rosenberg :
--
nosy: +josh.rosenberg
___
Python tracker
<http://bugs.python.org/issue22515>
___
___
Python-bugs-list mailing list
Unsubscribe:
Josh Rosenberg added the comment:
Reading the note on the Counter class (about intent vs. actual use), it looks
like changing this behavior would involve potentially breaking a lot of code.
If you're using Counters that are intended to maintain positive counts
(treating a count <= 0 a
Josh Rosenberg added the comment:
If it affects the decision, I just had to debug some code at work that
triggered a "excessive recursion" bug because they used functools.partial over
and over on the same base function, thinking they could safely replace some
keyword bindings ove
Josh Rosenberg added the comment:
The use case in question, simplified, was:
from functools import partial
class Foo:
Bar = othermodule.Bar
def __new__(cls, ...):
...
cls.Bar(...)
...
def bind_stuff(cls, *args, **kwargs):
cls.Bar = partial(Bar
Josh Rosenberg added the comment:
It's not out of memory at all. It's (probably) a blown stack during compilation
optimization. Modern Py3 has "fixed" this by simply preventing silly levels of
literal concatenation like this causing indefinite call stack expansion; the
old
Josh Rosenberg added the comment:
You're supposed to use that code to create a file (the output file is just
""+""+""+""+""+""+""+""+""+...+"").
If you want something that won'
Josh Rosenberg added the comment:
_check_int_field seems needlessly complex. When you want a value that is
logically an integer (not merely capable of being coerced to an integer), you
want object.__index__, per PEP 357, or to avoid explicit calls to special
methods, use operator.index. Any
401 - 500 of 727 matches
Mail list logo