Josh Rosenberg added the comment:
#36110 was closed as a duplicate; the superseder is #36109 (which has been
fixed). The change should still be documented, just in case anyone gets bitten
by it.
--
nosy: +josh.r
___
Python tracker
<ht
Josh Rosenberg added the comment:
"One other issue is that the arguments to prod() need not be integers, so a
modulus argument wouldn't make sense in those contexts."
The arguments to pow don't need to be integers either, yet the optional third
argument is only really relevant t
Josh Rosenberg added the comment:
Correction: It should actually be registered as a subclass of MutableSequence
(which should make it a virtual subclass of Sequence too; list is only
registered on MutableSequence as well).
--
___
Python tracker
Change by Josh Rosenberg :
--
versions: +Python 3.7, Python 3.8 -Python 3.5
___
Python tracker
<https://bugs.python.org/issue25737>
___
___
Python-bugs-list m
Josh Rosenberg added the comment:
This should not be closed as a duplicate. Yes, array.array isn't automatically
a Sequence, but since it isn't, the array module should be modified to
explicitly do the equivalent of:
import _collections_abc
_collections_abc.Sequence.register(array)
so
Josh Rosenberg added the comment:
Wait, why should #25737 be closed? This bug is a docs issue; collections.abc
shouldn't claim that all the ABCs do duck-typing checks since Sequence doesn't.
But #25737 is specific: array.array *should* be registered as a Sequence, but
isn't; that requires
Josh Rosenberg added the comment:
Moving from pending back to open (not sure what was "pending" about it?).
The workaround is viable (and used by Python implemented dict subclasses in the
standard library since they must accept **kwargs with arbitrary strings,
including self), b
Josh Rosenberg added the comment:
"your application is using more memory than what is available in the system."
Well, it alone may not be using more memory, but the cumulative usage on the
system is "too high" by whatever metric the OOM killer is using (IIRC the
default
Josh Rosenberg added the comment:
+1 on PR 11830 from me. Can always revisit if #11107 is ever implemented and it
turns out that the reference count manipulation means startup is too slow due
to all the slice interning triggered comparisons (unlikely, but theoretically
possible I guess
Josh Rosenberg added the comment:
Ah, I see Victor posted an alternative PR that avoids the reference counting
overhead by explicitly removing the temporary tuples from GC tracking. I'm
mildly worried by that approach, only because the only documented use case for
PyObject_GC_UnTrack
Josh Rosenberg added the comment:
Victor found the same bug I found while I was composing this, posting only to
incorporate proposed solution:
I *think* I have a cause for this, but someone else with greater understanding
of the cycle collector should check me if the suggested fix has non
Change by Josh Rosenberg :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Josh Rosenberg added the comment:
Closed #35958 as a duplicate of this issue (and updated the title, since
clearly the problem is not specific to dict).
Patch probably needs to be rebased/rewritten against latest trunk (given it
dates from Mercurial days).
--
nosy: +Jon McMahon
Josh Rosenberg added the comment:
Correct me if I'm wrong, but at least initially, the first listed goal of
statistics (per the PEP) was:
"Correctness over speed. It is easier to speed up a correct but slow function
than to correct a fast but buggy one."
numpy already exists for
Change by Josh Rosenberg :
Removed file: https://bugs.python.org/file48088/bq-nix.snapshot.json
___
Python tracker
<https://bugs.python.org/issue35862>
___
___
Python-bug
Josh Rosenberg added the comment:
Why is not having the target assign to the relevant os.environ keys before
doing whatever depends on the environment not an option?
--
nosy: +josh.r
___
Python tracker
<https://bugs.python.org/issue35
Change by Josh Rosenberg :
Removed file: https://bugs.python.org/file48087/core-nix.snapshot.json
___
Python tracker
<https://bugs.python.org/issue35862>
___
___
Pytho
Change by Josh Rosenberg :
Removed file: https://bugs.python.org/file48089/bq-nix.manifest
___
Python tracker
<https://bugs.python.org/issue35862>
___
___
Python-bug
Change by Josh Rosenberg :
--
Removed message: https://bugs.python.org/msg334593
___
Python tracker
<https://bugs.python.org/issue35862>
___
___
Python-bug
Josh Rosenberg added the comment:
I've only got 3.7.1 Ubuntu bash on Windows (also amd64) immediately available,
but I'm not seeing a hang, nor is there any obvious memory leak that might
eventually lead to problems (memory regularly drops back to under 10 MB shared,
24 KB private working
Josh Rosenberg added the comment:
One additional note, just in case you're wondering. slice explicitly does not
set Py_TPFLAGS_BASETYPE (in either Py2 or Py3), so you can't make a subclass of
slice with NULLable fields by accident (you'll get a TypeError the moment you
try to define
Josh Rosenberg added the comment:
Yes, the 2.7 version of _PyEval_SliceIndex would bypass the NULL pointer
dereference, so *if* you could make a slice with a NULL stop value, you could
trigger a read from uninitialized stack memory, rather than dying due to a NULL
pointer dereference
Josh Rosenberg added the comment:
You've got a reference leak in your __index__ based paths. PyNumber_Index is
returning a new reference (either to the existing obj, or a new one, if the
existing obj isn't already an int). You never release this reference. Simplest
fix is to make intobj top
Josh Rosenberg added the comment:
Steven: I'm assuming Brett rearranged the title to put emphasis on the new
function and to place it earlier in the title. Especially important if you're
reading e-mails with the old subject on an e-mail client with limited subject
preview lengths, you end
Josh Rosenberg added the comment:
Your analysis would be (almost) correct if a slice object could have a stop
value of NULL. It's wrong in that the error would be a NULL deference, not a
silent use of an uninitialized value, but it would be a bug. In your scenario
where v == NULL, it would
Josh Rosenberg added the comment:
Not my use case specifically, but my link in the last post (repeated below) was
to a StackOverflow answer to a problem where using buffer was simple and fast,
but memoryview required annoying workarounds. Admittedly, in most cases it's
people wanting to do
Josh Rosenberg added the comment:
The lack of support for the rich comparison operators on even the most basic
memoryviews (e.g. 'B' format) means that memoryview is still a regression from
some of the functionality buffer offered back in Python 2 (
https://stackoverflow.com/a/13574862
Josh Rosenberg added the comment:
Others can correct me if I'm wrong, but I'm fairly sure 2.7 isn't making
changes unless they fix critical or security-related bugs.
The code here is suboptimal, but it's already been fixed in Python 3 (in
#8052), as part of a C accelerator module
Josh Rosenberg added the comment:
The UUID module documentation (and docstring) begin with:
"This module provides immutable UUID objects"
Immutable is a stronger guarantee than __slots__ enforces already, so the
documentation already ruled out adding arbitrary attribut
Josh Rosenberg added the comment:
David, the What's New note about weak references no longer being possible
should be removed as part of this change. I'm not sure the note on arbitrary
attributes no longer being addable is needed either (__setattr__ blocked that
beforehand, it's just even
Josh Rosenberg added the comment:
I assume you meant #35662 (based on the superseder note in the history).
--
___
Python tracker
<https://bugs.python.org/issue29
New submission from Josh Rosenberg :
I don't really expect this to go anywhere until Python 4 (*maybe* 3.9 after a
deprecation period), but it seems like it would have been a good idea to make
NotImplementedType's __bool__ explicitly raise a TypeError (rather than leaving
it unset, so
Josh Rosenberg added the comment:
vstinner: The problem isn't the averaging, it's the type inconsistency. In both
examples (median([1]), median([1, 1])), the median is unambiguously 1 (no
actual average is needed; the values are identical), yet it gets converted to
1.0 only in the latter
Josh Rosenberg added the comment:
Closing as rejected; to my knowledge, *no* built-in Python method both mutate
an object and returns the object just mutated, precisely because:
1. It allows for chaining that leads fairly quickly to unreadable code (Python
is not Perl/Ruby)
2. It creates
New submission from Josh Rosenberg :
I 100% agree with the aim of #30977 (reduce uuid.UUID() memory footprint), but
it broke compatibility for any application that was weak referencing UUID
instances (which seems a reasonable thing to do; a strong reference to a UUID
can be stored
Josh Rosenberg added the comment:
Looks like the cause of the change was when os.pipe was changed to create
non-inheritable pipes by default; if I monkey-patch
multiprocessing.popen_fork.Popen._launch to use os.pipe2(0) instead of
os.pipe() to get inheritable descriptors or just clear
Josh Rosenberg added the comment:
I don't know what triggered the change, but I strongly suspect this is not a
supported use of the multiprocessing module; Process is for worker processes
(still running Python), and it has a lot of coordination machinery set up
between parent and child
Josh Rosenberg added the comment:
divmod imposes higher fixed overhead in exchange for operating more efficiently
on larger values.
Given the differences are small either way, and using divmod reduces
scalability concerns for larger values (which are more likely to occur in code
Josh Rosenberg added the comment:
Given the "feature" in question isn't actually an intended feature (just an
accident of how unbound methods work), I'm closing this. We're not going to try
to make methods callable without self.
--
resolution: -> wont fix
stage: ->
Josh Rosenberg added the comment:
Agreed with everything in Serhiy's comments. This patch disregards why
_PyObject_LookupSpecial and the various _Py_IDENTIFIER related stuff was
created in the first place (to handle a non-trivial task efficiently/correctly)
in favor of trying to avoid C
Josh Rosenberg added the comment:
Batteries-included extension modules aren't limited to the public and/or
limited API; they use tons of undocumented internal APIs (everything to do with
Py_IDENTIFIERs being an obvious and frequently used non-public API).
_PyObject_LookupSpecial
New submission from Josh Rosenberg :
https://docs.python.org/3.8/whatsnew/3.8.html#optimizations begins with:
shutil.copyfile(), shutil.copy(), shutil.copy2(), shutil.copytree() and
shutil.move() use platform-specific “fast-copy” syscalls on Linux, macOS and
Solaris in order to copy the file
Change by Josh Rosenberg :
--
versions: +Python 3.8 -Python 3.5
___
Python tracker
<https://bugs.python.org/issue11107>
___
___
Python-bugs-list mailin
Josh Rosenberg added the comment:
set.union() without constructing the set you call union on only happens to work
for the set.union(a) case because `a` is already a set. union takes arbitrary
iterables, not just sets, and you're just cheating by explicitly passing `a` as
the expected self
Change by Josh Rosenberg :
--
keywords: -3.2regression
___
Python tracker
<https://bugs.python.org/issue19865>
___
___
Python-bugs-list mailing list
Unsub
Change by Josh Rosenberg :
--
keywords: +3.2regression
versions: +Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue19
Josh Rosenberg added the comment:
Finished typing this while Serhiy was closing, but just for further explanation:
This isn't a bug. fnmatch provides "shell-style" wildcards, but that doesn't
mean it supports every shell's extensions to the globbing syntax. It doesn't
even cla
Josh Rosenberg added the comment:
This is completely fixed, right? Just making sure there is nothing left to be
done to close the issue.
--
nosy: +josh.r
___
Python tracker
<https://bugs.python.org/issue35
Josh Rosenberg added the comment:
The "bug" is the expected behavior for 2.7, as previously noted, and does not
exist on Python 3 (where list comprehensions follow the same rules as generator
expressions for scoping), where NameErrors are raised consistently.
--
nos
Josh Rosenberg added the comment:
Keep in mind, had this guarantee been in place in 3.4, the improvement in 3.5
couldn't have been made, and issue17936 might have been closed and never
addressed, even once dicts were ordered, simply because we never rechecked it.
It makes the whole
Josh Rosenberg added the comment:
I wrote the response to the OP's use case before I saw your response; it wasn't
really intended as an additional critique of the proposed change or a
counterargument to your post, just a note that the required behavior could be
obtained on all versions
Josh Rosenberg added the comment:
I'm also a little skeptical of the OP's proposed use case for other reasons. In
any circumstance other than "all classes are defined in the same module", you
can't really make useful guarantees about subclass definition order, because:
1. If the
Josh Rosenberg added the comment:
First off, the OP's original case seems like a use case for
functools.singledispatch. Not really related to the problem, just thought I'd
mention it.
Secondly, are we sure we want to make such a guarantee? That restricts the
underlying storage to ordered
Josh Rosenberg added the comment:
Hmm... Correction to my previous post. communicate itself has a test for:
"if self._communication_started and input:"
that raises an error if it passes, so the second call to communicate can only
be passed None/empty input. And _communicate only
Josh Rosenberg added the comment:
Sounds like the solution you'd want here is to just change each if check in
_communicate, so instead of:
if self.stdout:
selector.register(self.stdout, selectors.EVENT_READ)
if self.stderr:
selector.register(self.stderr
Josh Rosenberg added the comment:
As soon as you use ctypes, you sign up for all the security vulnerabilities,
including denial of service, buffer overrun, use-after-free, etc. that plain
old C programs are subject to. In this case, it's just a NULL pointer
dereference (read: segfault
Josh Rosenberg added the comment:
The TypeError on Py3 would be because functions taking c_char_p need bytes-like
objects, not str, on Python 3. '%s' % directory is pointless when directory is
a str; instead you need to encode it to a bytes-like object, e.g.
opendir(os.fsencode(directory
Change by Josh Rosenberg :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Josh Rosenberg :
The ssl.RAND_status online docs say (with code format on True/False):
"Return True if the SSL pseudo-random number generator has been seeded with
‘enough’ randomness, and False otherwise."
This is incorrect; the function actually retu
Change by Josh Rosenberg :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Assigning and deleting __new__ attr on the class does not allow
to create instances of this class
___
Python tra
Josh Rosenberg added the comment:
Blech. Copy'n'paste error in last post:
a = list(itertools.chain.from_iterable(*my_list))
should be:
a = list(itertools.chain.from_iterable(my_list))
(Note removal of *, which is the whole point of from_iterable
Josh Rosenberg added the comment:
Your example code doesn't behave the way you claim. my_list isn't changed, and
`a` is a chain generator, not a list (without a further list wrapping).
In any event, there is no reason to involve reduce here. chain already handles
varargs what you're trying
Josh Rosenberg added the comment:
Looks like a bug in the typeshed (which mypy depends on to provide typing info
for most of the stdlib, which isn't explicitly typed). Affects both
combinations and combinations_with_replacement from a quick check of the code:
https://github.com/python
Josh Rosenberg added the comment:
Problem: The variables from the nested functions (which comprehensions are
effectively a special case of) aren't actually closure variables for the
function being inspected.
Allowing recursive identification of all closure variables might be helpful
Josh Rosenberg added the comment:
Victor: "I would be interested of the same test on Windows."
Looks like someone performed it by accident, and filed #34943 in response
(because time.monotonic() did in fact return the exact same time twice in a row
Josh Rosenberg added the comment:
to_bytes and from_bytes aren't remotely related to native primitive types,
struct is. If the associated lengths aren't 2, 4 or 8, there is no real
correlation with system level primitives, and providing these defaults makes it
easy to accidentally write non
Josh Rosenberg added the comment:
The actual code receives input by name, but stdin is received in **kwargs. The
test is just:
if input is not None:
if 'stdin' in kwargs:
raise ValueError(...)
kwargs['stdin'] = PIPE
Perhaps just change `if 'stdin' in kwargs
Josh Rosenberg added the comment:
I just tried:
subprocess.run('ls', input=b'', stdin=None)
and I got the same ValueError as for passing using kwargs. Where did you get
the idea subprocess.run('ls', input=b'', stdin=None) worked?
--
nosy: +josh.r
Josh Rosenberg added the comment:
This looks like a duplicate of #28709, though admittedly, that bug hasn't seen
any PRs.
--
nosy: +josh.r
___
Python tracker
<https://bugs.python.org/issue34
Josh Rosenberg added the comment:
The documentation for locals (
https://docs.python.org/3/library/functions.html#locals ) specifically states:
Note: The contents of this dictionary should not be modified; changes may not
affect the values of local and free variables used by the interpreter
Josh Rosenberg added the comment:
"than" is correct; "giving up" in this context would mean "not even trying to
allocate the memory and just preemptively raising OverflowError, like
non-integer numeric types with limited ranges". Rather than giving up that way,
Josh Rosenberg added the comment:
This would presumably be a side-effect of all generic pickling operations of
iterators; figuring out what the iterator produces requires running out the
iterator. You could special case it case-by-case, but that just makes the
behavior unreliable/confusing
Josh Rosenberg added the comment:
Victor, that was a little overboard. By that logic, there doesn't need to be a
Windows version of Python.
That said, Paul doesn't seem to understand that the real resolution limit isn't
1 ms; that's the lower limit on arguments to the API, but the real
Josh Rosenberg added the comment:
That's the documented behavior. Per
https://docs.python.org/3/reference/datamodel.html#object.__getitem__ :
>Note: for loops expect that an IndexError will be raised for illegal indexes
>to allow proper detection of the end of the sequence.
Th
Josh Rosenberg added the comment:
For tuple and list, no, they couldn't have looked at the help (because the help
calls the argument "iterable", while the only keyword accepted was "sequence").
Nor was "sequence" documented in the online docs, nor
Josh Rosenberg added the comment:
Oh, I was checking old docs when I said the online docs didn't call int's
argument "x"; the current docs do, so int, float and bool all justify a change
(barely), it's just tuple and list for which it's completely unj
Josh Rosenberg added the comment:
Bloating the documentation is almost certainly unjustifiable for list and
tuple, and only barely justifiable for int, bool and float, given that:
1. The documentation (at least for Python 3) has *never* claimed the arguments
could be passed by keyword (all
Josh Rosenberg added the comment:
That's a *really* niche use case; you want to store everything to a common
destination list, in order, but distinguish which switch added each one? I
don't know of any programs that use such a design outside of Python (and
therefore, it seems unlikely
Josh Rosenberg added the comment:
Carlo: The point of Xiang's post is that this is only tangentially related to
multiprocessing; the real problem is that tee-ing an iterator implemented in
Python (of which pool.imap_unordered is just one example) and using the
resulting tee-ed iterators
Josh Rosenberg added the comment:
So the bug is that the line number and module are incorrect for the f-string,
right? Nothing else?
--
nosy: +josh.r
___
Python tracker
<https://bugs.python.org/issue34
Josh Rosenberg added the comment:
Why would it "cause an issue if the file is closed before accessing the mmapped
region"? As shown in your own link, the constructor performs the mmap call
immediately after the descriptor is duplicated, with the GIL held; any race
condition that c
Josh Rosenberg added the comment:
Copying from the sorted built-in's docstring would make sense here, given that
sorted is implemented in terms of list.sort in the first place.
--
nosy: +josh.r
___
Python tracker
<https://bugs.python.
Josh Rosenberg added the comment:
In response to Max's comments:
>But consider the case where input is produced slower than it can be processed
>(`iterables` may fetch data from a database, but the callable `fn` may be a
>fast in-memory transformation). Now suppose the `Exe
Josh Rosenberg added the comment:
In any event, sorry to be a pain, but is there any way to get some movement on
this issue? One person reviewed the code with no significant concerns to
address. There have been a duplicate (#30323) and closely related (#34168)
issues opened that this would
Josh Rosenberg added the comment:
Note: While this particular use case wouldn't be fixed (map returns in order,
not as completed), applying the fix from #29842 would make many similar use
cases both simpler to implement and more efficient/possible.
That said, no action has been taken
Josh Rosenberg added the comment:
If [].append == [].append is True in the "unique set of callbacks" scenario,
that implies that it's perfectly fine to not call one of them when both are
registered. But this means that only one list ends up getting updated, when you
tried to reg
Josh Rosenberg added the comment:
memoryview isn't just for bytes strings though; the format can make it a
sequence of many types of different widths, meanings, etc. Calling it a
BytesString would be misleading in many cases.
--
nosy: +josh.r
Change by Josh Rosenberg <shadowranger+pyt...@gmail.com>:
--
title: readline() + seek() on io.EncodedFile breaks next readline() ->
readline() + seek() on codecs.EncodedFile breaks next readline()
___
Python tracker <rep...@bugs.python
Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment:
Note: strftime follows the existing documentation:
>>> datetime.datetime(1970, 1, 1, microsecond=1).strftime('%f')
'01'
The strptime behavior bug seems like a duplicate of #32267, which claims to be
Change by Josh Rosenberg <shadowranger+pyt...@gmail.com>:
--
versions: -Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment:
You named your loop variable i, overlapping the name of your second to last
digit, so you end up replacing the original value of i in each (given the
break, the only) loop.
So before the loop begins, i has the expected
Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment:
None of the actual classes outside of the typing module support this either to
my knowledge. You can't do:
from collections import deque
a: deque[int]
nor can you do:
a: list[int]
Adding Queue to the
Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment:
If the goal is just to suppress stdout, that's what passing subprocess.DEVNULL
is for (doesn't exist in Py2, but opening os.devnull and passing that is a
slightly higher overhead equivalent).
subprocess.run includes
Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment:
Pretty sure this is a problem with classes in general; classes are
self-referencing, and using multiplication to create new ctypes array types is
creating new classes.
--
nosy: +
Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment:
Related: issue29842 "Make Executor.map work with infinite/large inputs
correctly" for a similar problem in concurrent.futures (but worse, since it
doesn't even allow you to begin consuming results
New submission from Josh Rosenberg <shadowranger+pyt...@gmail.com>:
Patch is good, but while we're at it, is there any reason why this
multi-allocation design was even used? It PyMem_Mallocs a buffer, makes a
C-style string in it, then uses PyUnicode_FromString to convert C-style
Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment:
As indicated in the seek docs (
https://docs.python.org/3/library/io.html#io.IOBase.seek ), all three names
were added to the io module in 3.1:
> New in version 3.1: The SEEK_* constants.
Since they're part of the
Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment:
I may have immediately latched onto this, dubbing it the "one-eyed monkey
operator", the moment the generalized unpacking released.
I always hated the lack of an empty set literal, and enjoyed having this exi
Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment:
Serhiy: There is a semi-common case where global constants can be quite
expensive, specifically, initializing a global full of expensive to
compute/serialize data so it will be shared post-fork when doing
multiproc
Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment:
To my knowledge, there is no safe way to do this for other threads for a reason.
If you make all your worker threads daemons, then they will terminate with the
main thread, but they won't perform cleanup actions.
If you
201 - 300 of 723 matches
Mail list logo
