Raymond Hettinger added the comment:
> Nor will it achieve world peace.
Please watch the tone. It is borderline abusive and dismissive.
> we can invoke the attached as best_fraction(Fraction("0.001"),
> Fraction("0.0005"), Fraction("0.0015")) to get t
Raymond Hettinger added the comment:
-1
* I concur with Eric that this is mostly not needed. Probably 99.95% of
dataclass use case don't need this. When it is needed, it is trivial to
implement and probably should be explicit rather that implicit.
* Vedran is also correct in noting
Change by Raymond Hettinger :
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue46812>
___
___
Python-bugs-list mailing list
Unsubscribe:
Raymond Hettinger added the comment:
This idea surfaced once before and Guido shot it down. IIRC the rationale was
the exposed implementation details, that would challenging for users to
consistently set the size correctly, and that it may not make sense for other
implementations.
This
Raymond Hettinger added the comment:
To me, this looks like a way too extensive edit jsut to emphasize a corner case
that rarely arises in practice. It bends over backwards to force an awkward
definition regarding what an ABC really is.
A more minimal edit is to just note that
Raymond Hettinger added the comment:
An analogy may help. Release managers must check the list of release blockers
and stop if the list is non-empty. If no release blockers were ever filed, the
release blockers list is empty, but it still exists and its definition hasn't
changed.
Raymond Hettinger added the comment:
FWIW, I’m only -0 on this. It is also perfectly reasonable to say that a
class is abstract if and only if there is at least one remaining abstract
method. After 15 years though, I’m inclined to say that the status quo wins
Raymond Hettinger added the comment:
Note that adding an empty __post_init__ method would be a breaking change. The
following prints out 'B' then 'C'. But if class A adds an empty __post_init__,
then 'B' never gets printed. The arrangement relies on class A b
Raymond Hettinger added the comment:
I'll add a note that the output type is determined by the input type.
--
assignee: docs@python -> rhettinger
nosy: +rhettinger
priority: normal -> low
___
Python tracker
<https://bugs.python.
Raymond Hettinger added the comment:
If this goes forward, my strong preference is to have a separate async_lru()
function just like the referenced external project.
For non-async uses, overloading the current lru_cache makes it confusing to
reason about. It becomes harder to describe
Change by Raymond Hettinger :
--
title: Add a async variant of lru_cache for coroutines. -> Add an async variant
of lru_cache for coroutines.
___
Python tracker
<https://bugs.python.org/issu
Raymond Hettinger added the comment:
I'm going to close this one. Making a new and previously rejected extension to
one of Python's most import APIs requires broad discussion and buy-in. If you
really want to push for this, please take it to the python-ideas list.
--
Raymond Hettinger added the comment:
[Andrew Svetlov]
> A third-party library should either copy all these
> implementation details or import a private function from stdlib
OrderedDict provides just about everything needed to roll lru cache variants.
It simply isn't true this
Raymond Hettinger added the comment:
I would not miss these methods. Unless Mark says they are needed, +1 for
removal.
--
nosy: +mark.dickinson, rhettinger, tim.peters
___
Python tracker
<https://bugs.python.org/issue46
Raymond Hettinger added the comment:
> I think this is more confusing then helpful.
I concur.
--
___
Python tracker
<https://bugs.python.org/issu
Raymond Hettinger added the comment:
The difference is the FLAG_REF which is set to 128 (0x80).
>>> import marshal
>>> var_example = [(1,2,3),(4,5,6)]
>>> vm = marshal.dumps(var_example)
>>> rm = marshal.dumps([(1,2,3),(4,5,6)])
>>> [v ^ r for v,
Raymond Hettinger added the comment:
I concur with Jelle and Methane that we can't do this without breaking code.
Also if you don't care about dict order, the work around is easy. Just remove
the old key:
d.pop(k); d[k] = v
--
nosy: +rhettinger
resolution: -> r
Raymond Hettinger added the comment:
The weakref docs in particular should point out the OP's example and highlight
the workaround.
--
___
Python tracker
<https://bugs.python.org/is
Raymond Hettinger added the comment:
Related issue: https://bugs.python.org/issue43923
--
nosy: +rhettinger
___
Python tracker
<https://bugs.python.org/issue44
Raymond Hettinger added the comment:
The code in the screenshot looks correct.
>>> i = 0
>>> i is int
False
>>> type(i) is int
True
The code above does not get warning because "int" is a variable. This kind of
comparison is always allowed and
Changes by Raymond Hettinger:
--
assignee: -> rhettinger
nosy: +rhettinger
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1165>
__
___
Python-bugs-li
Raymond Hettinger added the comment:
This isn't a bug. Writing
"dict.fromkeys(xrange(1,48),dict.fromkeys(xrange(1,8),0))" results in
the inner expression being evaluated just once and then passed to the
outer function call as a fully evaluated argument. As a result, the
*same
Changes by Raymond Hettinger:
--
resolution: -> fixed
status: open -> closed
versions: +Python 2.6 -Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Raymond Hettinger added the comment:
It's easier to see what is going on if you print the object ids. The
id of self.bla is different than the subsequent c1.bla. The first is
freed before the second gets created.
--
nosy: +rhettinger
__
Tr
Raymond Hettinger added the comment:
Sorry, this has been proposed and rejected previously. One of the
reasons was that the docs already have a C-speed recipe, grouper(),
that shows how to do it with padding and it is even simpler to do it
without padding using only zip() or izip(). Another
Raymond Hettinger added the comment:
FWIW, I find __root__ to be just right. It is not subject
misspelling. It is distinct enough to serve as a mental link to a
specific concept. The leading and trailing underscores cause just
enough typing pain that I wouldn't want anything l
Changes by Raymond Hettinger:
--
assignee: -> rhettinger
nosy: +rhettinger
versions: +Python 2.6 -Python 2.5
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Changes by Raymond Hettinger:
--
assignee: tim_one -> rhettinger
nosy: +rhettinger
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1045>
__
___
P
Raymond Hettinger added the comment:
I'll take a look at it next week -- want to think through the various
cases. The current setup provides nice speedups when the length_hint
is available. Possibly, it may be worthwhile to skip that check when
the input is a generator. For the most
Raymond Hettinger added the comment:
FWIW, the 2.4 to 2.5 timing difference came from renaming __len__ to
__length_hint__. This was at Guido's request so that the value of bool
(iter(obj)) would always be True. The consequence of the change was
that we lost the fast slot lookup for __
Raymond Hettinger added the comment:
Thank you.
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue12959>
___
___
Python-bugs-list mailin
Changes by Raymond Hettinger :
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue12917>
___
___
Python-bugs-
Raymond Hettinger added the comment:
It would be best to think about each of the new links individually rather than
making blanket changes.
The new links need to have relevance and add value to the topic; otherwise,
they are just distractions from the more relevant links that had been
Raymond Hettinger added the comment:
I recommend just closing this.
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue12960>
___
___
Python-bug
Changes by Raymond Hettinger :
--
priority: normal -> low
___
Python tracker
<http://bugs.python.org/issue12961>
___
___
Python-bugs-list mailing list
Unsubscri
Raymond Hettinger added the comment:
This needs to be part of the overall effort to build a better pprint. See
http://bugs.python.org/issue7434
--
assignee: -> rhettinger
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issu
Raymond Hettinger added the comment:
Any additions would need to be motivated by real world problems. The issue is
that adding more generators makes the module harder to learn and remember, so
tools are not usually added "for the sake of complet
Raymond Hettinger added the comment:
Sorry Phillip, I'm closing this feature request because the benefits would
likely be outweighed by the costs (maintenance, learning curve, module
complexity, etc). It was not the goal of the module to become a complete
combinatorics toolkit; rather
Raymond Hettinger added the comment:
These have been rejected before. There is always a trade-off in adding tools
such as this -- it can take more time to learn and remember them than to write
a trivial piece of code to do it yourself. Another issue is that people tend
to disagree on how
Raymond Hettinger added the comment:
I'll add the in-place methods including __iadd__, __isub__, __iand__, and
__ior__.
If speed is your issue, you should continue to use the update() method which
will always be faster because it doesn't have a step to strip zeros and
negative v
Changes by Raymond Hettinger :
--
assignee: -> rhettinger
___
Python tracker
<http://bugs.python.org/issue11085>
___
___
Python-bugs-list mailing list
Un
Raymond Hettinger added the comment:
[Arfrever Frehtes Taifersar Arahesis]
> I suggest to have low-level, POSIX-compatible,
> (int, int)-based interface in os module and add
> high-level, decimal.Decimal-based interface in
> shutil module.
I agree that this is the cleanest appro
Changes by Raymond Hettinger :
--
assignee: -> rhettinger
___
Python tracker
<http://bugs.python.org/issue11457>
___
___
Python-bugs-list mailing list
Un
Changes by Raymond Hettinger :
--
assignee: -> rhettinger
priority: high -> normal
___
Python tracker
<http://bugs.python.org/issue11489>
___
___
Pyth
Raymond Hettinger added the comment:
One other thought: it would be useful to research how nanosecond-resolution
timestamps are going to be supported in other languages.
--
___
Python tracker
<http://bugs.python.org/issue11
Raymond Hettinger added the comment:
This changes behavior so that hash() gets called twice for the key tuple,
resulting in decreased performance.
In an earlier version of the lru_cache before the "with lock" was introduced,
the try/except form was more atomic. It also worked well
Raymond Hettinger added the comment:
Another issue is that I want to keep the related accesses to the OrderedDict
inside the "with lock" in order to avoid a race condition between the
testing-for-membership step and the retrieve-the-cached-
Raymond Hettinger added the comment:
One possibility is to move the call to user_function() outside of the KeyError
exception handler so that user exceptions won't be chained:
def wrapper(*args, **kwds):
nonlocal hits, misses
key = args
if kwds:
key += kwd_mark +
Raymond Hettinger added the comment:
Sorry, I'm not going to introduce a possible race condition because you find
try/except to be less elegant than an if-contains test. Also, I want to keep
the current behavior of calling hash only once. Your original complaint is
valid though, so I&
Changes by Raymond Hettinger :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13177>
___
___
Python-bugs-
Raymond Hettinger added the comment:
Thanks for the bug report and for the test case.
--
___
Python tracker
<http://bugs.python.org/issue13177>
___
___
Python-bug
Raymond Hettinger added the comment:
I concur with Martin and Ezio.
This report was correctly closed as invalid.
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue13
Raymond Hettinger added the comment:
I think this is over-explaining an implementation detail and it makes the docs
for id() harder to understand.
Possibly there can be a FAQ entry about identity but the id() function itself
is no place to go into the quirks of when new objects are created
Changes by Raymond Hettinger :
--
assignee: docs@python -> rhettinger
___
Python tracker
<http://bugs.python.org/issue13203>
___
___
Python-bugs-list mai
Raymond Hettinger added the comment:
I don't see any way of changing this without breaking lots of code that
currently works fine. It may be possible to add a strict-mode (off by default)
or to add warnings.
--
nosy: +rhettinger
___
P
Raymond Hettinger added the comment:
This looks to be a reasonable request.
I think the patch would be better if the filtering were done directly in
get_names(). A subclass can override or extend that method if it wants to
customize the filter.
--
assignee: -> rhettinger
n
Raymond Hettinger added the comment:
This looks like a reasonable use case. That being said, I question whether the
defaults should be attached directly to the template instance or whether they
should be part of the substitution method.
FWIW, there already have a couple of other ways to do
Raymond Hettinger added the comment:
I don't think you can tighten the API at this point. We could however make
Popen complain when options are going to be thrown away. Or it could be made
more liberal about what is accepts (running shlex on string input or join on
list input as n
Raymond Hettinger added the comment:
+1
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue13152>
___
___
Python-bugs-list mailing list
Unsub
Changes by Raymond Hettinger :
Added file: http://bugs.python.org/file23457/counter.diff
___
Python tracker
<http://bugs.python.org/issue13121>
___
___
Python-bugs-list m
Raymond Hettinger added the comment:
I'm thinking that we should offer a strict-option (off by default) and leave it
at that. No need to break existing code. AFAICT, the OP is the only one to
have had problems with this in-practice (the JSON module or its ancestor
simplejson has
Changes by Raymond Hettinger :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13121>
___
___
Python-bugs-
Raymond Hettinger added the comment:
Sorry, I'm going to reject this one. I applied the patch and looked at the
generated docs, finding them to be less readable than before. AFAICT, we've
had no issues with people mis-reading the text as currently presented. Also,
I looked b
Raymond Hettinger added the comment:
Applied many of these changes to 3.2 and 3.3.
If someone is interested, feel free to backport them to 2.7.
--
resolution: -> fixed
status: open -> closed
versions: -Python 3.1, Python 3.2, Python 3.3
___
Raymond Hettinger added the comment:
Thanks for the report.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
New submission from Raymond Hettinger :
Based on a comment from Andrew Koenig, it is suggested that the lru_cache()
offer an option to become type specific so that equal objects of different
typed don't get cached to the same entry.
Here's an example:
@lru_cache(typed=True)
de
Raymond Hettinger added the comment:
Updated patch to include tests and an application to the re module.
--
Added file: http://bugs.python.org/file23475/typed_lru2.diff
___
Python tracker
<http://bugs.python.org/issue13
Raymond Hettinger added the comment:
Nick, Ezio, and Victor, thanks for looking at the code.
Here's an updated the patch:
* optimization for fast globals() are now keyword-only arguments
* now types the keyword values, not the key/values tuples
* expanded tests
* added the doc u
Raymond Hettinger added the comment:
Victor, Ezio, and Nick, thanks for the review.
Andrew, thanks for the feature request.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Raymond Hettinger added the comment:
+1
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue13237>
___
___
Python-bugs-list mailing list
Unsub
Raymond Hettinger added the comment:
Assigning back to me (the current maintainer of the module).
--
assignee: -> rhettinger
___
Python tracker
<http://bugs.python.org/issu
Raymond Hettinger added the comment:
The behavior is undefined for negative inputs, so implementations are free to
the most expedient choices.
--
priority: normal -> low
___
Python tracker
<http://bugs.python.org/issu
Raymond Hettinger added the comment:
There's no reason to switch the implementation. The % formatting isn't going
away and we've decided against doing switch-overs in existing code (it risks
introducing bugs while conferring zero benefits to users).
--
no
Raymond Hettinger added the comment:
Removed the newstyle/oldstyle comments is fine. I don't see the reason for the
type->class change though.
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org
Changes by Raymond Hettinger :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13280>
___
___
Python-bugs-
Raymond Hettinger added the comment:
Barry, any thoughts?
--
assignee: rhettinger -> barry
nosy: +barry
___
Python tracker
<http://bugs.python.org/issu
Changes by Raymond Hettinger :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13274>
___
___
Python-bugs-
Raymond Hettinger added the comment:
I went ahead an added the guards to the pure python code.
Still disagree with your assertion that non-cpython implementations were
somehow broken when an undefined behavior was implemented in a different way --
nsmallest() and nlargest() have no
Raymond Hettinger added the comment:
+1
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue13299>
___
___
Python-bugs-list mailing list
Unsub
Raymond Hettinger added the comment:
I concur with Martin.
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue13279>
___
___
Python-bugs-list m
Raymond Hettinger added the comment:
The relevant code is in _PyEval_SliceIndex() in Python/ceval.c.
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue13
Raymond Hettinger added the comment:
I think this "fix" was too hastily committed.
1) It was an API change.
2) It probably should have been done in _PyEval_SliceIndex().
Be careful. Don't rush to commit. Especially for backports.
--
status:
Raymond Hettinger added the comment:
The API in 2.7 shouldn't be changed.
The error message can be fixed though.
Also, it is not clear that the API should change even in 3.3. The list.index()
method is not required to accept None. It is not different than other APIs
tha
Changes by Raymond Hettinger :
--
assignee: -> rhettinger
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue13355>
___
___
Python-bugs-list mai
Raymond Hettinger added the comment:
> There's still the question whether {list,tuple}.index() should accept None or
> not.
The API should not be changed for Py2.7 and Py3.2. Those changesets should be
reverted.
For Py3.3, it is open to discussion, but we probably don't
Raymond Hettinger added the comment:
One other thought: the API for list.index() doesn't exist in isolation. There
is also str.index, the sequence abstract base class, and tons of code that has
been written to emulate lists. This is an ancient API (approx 20 years) and
should on
Changes by Raymond Hettinger :
--
priority: normal -> high
___
Python tracker
<http://bugs.python.org/issue13357>
___
___
Python-bugs-list mailing list
Un
Raymond Hettinger added the comment:
I concur with Benjamin.
This is a waste of time and a potential source of new errors.
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue13
Raymond Hettinger added the comment:
I thought we had a policy that future imports would never be removed.
--
nosy: +rhettinger
status: closed -> open
___
Python tracker
<http://bugs.python.org/issu
Raymond Hettinger added the comment:
At one point, for 2.x at least, we weren't removing the "from __future__"
imports even after the feature became available.
--
___
Python tracker
<http://bugs.pyt
Raymond Hettinger added the comment:
Thank you for closing this. I think it would only add clutter to a module that
is already puts readers into information overload.
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue13
Raymond Hettinger added the comment:
This patch looks fine.
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue12875>
___
___
Python-bugs-list m
Raymond Hettinger added the comment:
Terry, thanks for closing this. The API for str.split() has been set in stone
for a very long time.
--
___
Python tracker
<http://bugs.python.org/issue13
Raymond Hettinger added the comment:
I've got this one.
--
___
Python tracker
<http://bugs.python.org/issue13355>
___
___
Python-bugs-list mailing list
Changes by Raymond Hettinger :
--
assignee: -> rhettinger
___
Python tracker
<http://bugs.python.org/issue13396>
___
___
Python-bugs-list mailing list
Un
Raymond Hettinger added the comment:
How would this work for other random number generators that don't supply
genrand_int32()?
The API for random is supposed to be easily subclassable and reusable for other
random number generators. The requirements for those generators is
intentio
Raymond Hettinger added the comment:
> genrand_int32 is an internal function,
> only available in C for the Mersenne Twister generator.
Yes, I know. I'm the one added that code ;-)
> I don't know other generators.
The problem is that we need an API that will accom
New submission from Raymond Hettinger :
Currently, an XMLRPC client communicating with a server running Python can make
Python style calls but exceptions get collapsed into a standard FaultException
making it difficult to program in a Pythonic style:
proxy = xmlrpc.client.ServerProxy("
Changes by Raymond Hettinger :
--
components: +Library (Lib)
priority: normal -> low
___
Python tracker
<http://bugs.python.org/issue13397>
___
___
Python-
Raymond Hettinger added the comment:
The differential cost of generating n random bytes is negligible compared to
actually doing anything with the bytes once their generated.
This optimization is close to being a total waste (saving 15 milliseconds for
the abnormal case of generating 1
201 - 300 of 9609 matches
Mail list logo
