Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Guido, do you have a recommendation?
--
assignee: rhettinger - gvanrossum
nosy: +gvanrossum
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8743
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Applied in r84356.
Thank you.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9445
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8743
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9507
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
FWIW, I'm am considering removing this functionality in Py3.3 after the
language moratorium ends.
The swap-bodies technique had been included in the original sets.py and the
technique is similar to the one list.sort() uses
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I didn't disagree with you. The swap bodies implementation technique is not
expected and is exploitable in a number of ways.
What outcome to you want? Eliminate the implicit set-to-frozenset conversion
feature; introduce
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
This should probably be backported to 3.1
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8814
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Okay, I'll do it.
The intention of wrapper assignments was to wrap all of the standard
attributes, so the omission of __annotations__ is a bug.
--
assignee: - rhettinger
status: closed - open
versions: +Python 3.1
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
FWIW, the current docs adequately cover the existing situation:
Note, the elem argument to the __contains__(), remove(), and discard() methods
may be a set. To support searching for an equivalent frozenset, the elem set
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
That question should probably raised on python-dev, not the bug tracker.
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8299
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
These changes are very aggressive and may be doing more harm than good.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9528
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
See r83757, r83756, and r83755.
The existing unittests prove the script does what it is supposed to do. The
new code is just a different approach to the same problem so that it is less
likely to be user visible
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: - rhettinger
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9534
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Do you have a short script that can reproduce the error message?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9534
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
There's not enough information here for me to follow-up.
It's unlikely that dict.clear() would product the message you see and the
existing code for OrderedDict.__del__ and OrderedDict.clear() look correct to
me. The bug
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
None of the other python-dev IRC folks were able to deduce the issue from the
provided information. Closing as invalid. Feel free to reopen if more
actionable information becomes available.
--
resolution
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Backported to Py3.1 in r83807
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8814
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Added a link to the a SortedCollections recipe, added example of how to do
searches, and noted the O(n) performance of the insort() functions.
See r83786
--
status: open - closed
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Applied in r83808 for Python 3.2.
Am not backporting because I don't consider it a bug
and the documented subclassing technique is:
class A(namedtuple('A', 'x y')):
...
--
resolution: - accepted
stage
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Applied in r83793
Thanks for the suggestion.
--
resolution: - accepted
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7734
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Applied in r79810
Thanks for the suggestion.
--
resolution: - accepted
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5479
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Fixed in r83809 and r83810.
--
resolution: - accepted
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4570
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
priority: normal - high
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
priority: normal - high
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9025
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
priority: normal - high
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7871
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I will take a look at the various caches and see if some of their features can
be consolidated. It is okay if some need to have their own strategies or
situation specific approaches, but you're right that common features
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9396
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
For Py3.2, applying the new functools.lru_cache().
See r83871.
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7846
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Applied the lru_cache() to fnmatch and re.
See r83874 r83871.
I did find a simple way to dynamically resize the maxcache, but did not apply
it yet. Will look at more applications to see if it is really needed.
Nick
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I was thinking about the problem of developers wanting a different cache size
than that provided in standard lib modules.
ISTM that now we've offered caching abilities in functools, a developer can
easily add another layer
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I'll be looking at it shortly. Py3.2 is still aways from release so there is
no hurry.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8685
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
This has been rejected before. The core issue is that it is not a very useful
operation because it consumes the iterator.
Also, this isn't an operation worth optimizing because most iterators that do
something
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
This is definitely not covered by the language moratorium. Guido has requested
this change and it needs to go forward.
--
___
Python tracker rep...@bugs.python.org
http
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Great minds think alike. I was just about to propose that functools.wraps add
a standard attribute to point at the underlying function (on the theory that
objects should be introspectable). This would allow a standard way
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
This can be done for Py3.2. It completes needed functionality for string
formatting which is something we all want to take hold and is necessary for the
3.x series to succeed.
--
versions: +Python 3.2 -Python 3.3
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Am rejecting this feature request because of the concerns mentioned in the post
on 4/3. The current requirement for explicit forwarding may be slightly
inconvenient to type but it does add provide clarity that the method
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: - rhettinger
priority: normal - low
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1479611
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
ISTM the space saving of value of __slots__ isn't typically needed in the
context of variable length built-in types.
Guido has long regarded __slots__ as a confusing hack. That should warn us
away for extending its
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
The moratorium only includes builtins and certainly does not apply to pure
python modules (other implementations see those benefits immediately and it
does not interfere with their getting caught-up).
FWIW, I'm +1
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Fixing-up str formatting idiosyncracies does not fall under the moratorium and
is helpful in getting 3.x to be usable.
That being said, I'm not convinced that this is actually a helpful feature.
Not all objects supporting
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
+1 on the basic idea to make error messages more informative where possible,
but am not sure how it would work in any but the more simple cases.
How would work in cases where there are multiple possible expected tokens
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I do not believe that this is covered by the moratorium. It's important for
3.x success to get new string formatting to its highest state of usability.
Matching published standards and practices(i.e. C99) and improving
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
priority: normal - low
stage: unit test needed -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3489
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: - rhettinger
nosy: +rhettinger
priority: normal - low
versions: +Python 3.3 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1491804
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I think this falls under the language moratorium in that it requires core
changes that make it more difficult for other implementations to catch-up.
--
nosy: +rhettinger
versions: +Python 3.3 -Python 3.2
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
priority: normal - low
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1158231
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I concur with Terry.
This is just a fact of life when subclassing builtins.
The objects are open-for-extension, closed-for-modification.
If you want more direct control use UserDict.
--
nosy: +rhettinger
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
FWIW, we should be cautious about documenting all behaviors. It is arguable
that this was an implementation detail and not a guaranteed behavior. As soon
as you document it, people will rely on the API and all other
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Declaring YAGNI and closing.
Thanks Michael.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1173475
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
FWIW, the $name $$ $(name) convention is used many other contexts and I don't
think there is usually support provided to not substitute $$. Even if there
were, there is a usability issue where the final substitution needs
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
This request seems reasonable.
--
keywords: +easy
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3482
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Am rejecting this request because it complicates pprint and makes it harder to
extend. Most use cases of pprint either don't need this or have output
requirements more complicated than proposed (i.e. adding fixed width
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
These synonyms have been around a very long time and many test suites have one
or the other or both. Nothing good can come from breaking those existing test
suites. We don't need to harm our users just to accommodate
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
What a tremendous waste of time and inane exercise. AFAICT, this is a zero
value add.
Also, we try to avoid these sort of search-and-replace exercises because 1)
they are not part of holistic refactoring (Guido's term
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Thank you. Please do the reversion and the docstring fixup.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5416
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Please don't pursue this further. It does not matter at all whether developers
use assertEqual or assertEquals. That is no more than a stylistic preference.
I do not want a commit hook, or for developer patches
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I'm rejecting this feature request on the grounds that the use cases are
sufficiently uncommon to warrant adding API complexity.
Currently, the notions of reverse() and sort() are comparatively simple. They
correspond
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
The effort to backport dictviews was incomplete.
Fixed in r84148.
Thanks for the report.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Can you provide links to the other requests?
This seems to be at odds with the whole premise
of what Queue.join() is trying to do (wait until
all worker threads have marked their tasks as done).
--
assignee
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
FWIW, if you want to do other tasks in a main thread and need to check on the
status task completion in worker threads, you can already loop on:
while q.unfinished_tasks:
do_other_fun_stuff()
q.join
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
One of the provided links is duplicate (repost from StackOverflow). None of
the links offer use cases which can be used to inform the design (i.e. is this
the correct approach, should a timeout raise a RuntimeError like
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I will leave this open for a while.
It may be that it is a good idea
and that some good use cases will
emerge to inform a correct design.
In the meantime, it would be great
if you could post your subclass to
the ASPN Cookbook
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I concur with Nick. If you want to develop your __DECORATORS__ idea further,
it should be done off-list. ISTM, this is more of a shot in the dark than a
concrete plan to solve known, real problems.
--
resolution
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: stutzbach - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8750
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
This needs to stay rejected. I'm unwilling to introduce special cases in the
language just to support a peephole optimization.
--
assignee: gvanrossum - rhettinger
___
Python
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
The was a nice attempt at a peephole optimization.
I'm rejecting it because:
* too many other things need to be changed to support it
* the measured win is somewhat small
* we have a negative bias towards expanding
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I support adding index() and count() to range objects.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9213
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
The patch looks good.
Feel free to apply.
--
assignee: rhettinger - stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8750
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Fixed in r84252, r84252, and r84254.
--
priority: high - normal
resolution: accepted - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: rhettinger - stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9131
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9396
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Fixed in r84255.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7871
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
priority: normal - high
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8743
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Fixed in r84256.
Don't think this needs to be backported.
--
resolution: - fixed
status: open - closed
versions: +Python 3.2 -Python 2.6, Python 2.7
___
Python tracker rep
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Thanks Benjamin. I concur with your conclusion.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9659
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
This seems reasonable. Will look at it in the next few days.
--
assignee: - rhettinger
keywords: +easy
nosy: +rhettinger
priority: normal - low
stage: - needs patch
versions: +Python 3.2 -Python 2.6
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
What change are you proposing?
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9686
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Hello Tim! If you have a chance, please also take a look at issue9685 which I
was planning to work on in the next couple of weeks.
For memoizing tuple hashes, I'm inclined to think the one extra field is worth
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: - giampaolo.rodola
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9686
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Yawn
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9702
___
___
Python
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
The current design has existed for almost twenty years.
It is deeply embedded in the language. For better or
worse, it cannot and won't change.
--
nosy: +rhettinger
___
Python
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
FYI, there is a section of the docs devoted to notifications and attribution
licenses:
http://docs.python.org/license.html#licenses-and-acknowledgements-for-incorporated-software
--
nosy: +rhettinger
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
FWIW, the usual way to spell this in Python is:
my_dict_1.update((k, my_dict_2[k]) for k in ['a', 'c'])
We try to keep filtering operations separate from map/fold operations for
orthognality.
--
nosy: +rhettinger
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
maybe the mention of the SortedCollection recipe should
be a little more prominent.
Thanks for the suggestion. Will look at moving the note higher on the page.
--
components: +Documentation -Library (Lib)
status
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Fixed in r84383.
--
resolution: duplicate - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4356
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Please leave this for me.
Thank you.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8685
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
It would be nice to get this fixed before the next release.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9212
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
+1 for the basic idea.
It could use a better name, Sequence.has_methods(range) reads backwards to me.
Perhaps something like: Sequence.implemented_by(range) or
Sequence.verify_full_api(range) or some such.
Also, when
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
nosy: -rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4819
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
The patch looks fine.
--
nosy: +rhettinger
resolution: - accepted
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9042
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
The operator methods in setobject.c should be liberalized to accept instances
of collections.Set as arguments. For speed, they should continue to check
PyAnySet_Check(other) first and then if that fails, fall back
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I'm marking this one as rejected. The timings have shown mixed results (some
favorable, some not). In general, there is a bias against expanding the number
of opcodes because 1) there aren't that many codes available, 2
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Kelly, thanks for posting the idea.
I'm going to close this one for now
but it can be reopened if compelling
use cases arise.
--
resolution: - rejected
status: open - closed
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Am deferring this to Py3.3. There is a workaround available just using
duck-typing and I would like to wait until more more has been done on StructSeq
before setting committing to an new namedtuple Abstract Base Class (one
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Unassigning, this needs fresh thought and a fresh patch from someone who can
devote a little deep thinking on how to solve this problem cleanly. In the
meantime, it is no problem to simply cast the CSV tuples into named
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
priority: normal - low
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9269
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
This proposal hasn't gotten much love or support and I'm no longer interested
in it. Aside from ''.join and '{}'.format, there doesn't seem to be many
common cases, so there's no big win here.
--
assignee
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: rhettinger - terry.reedy
priority: normal - low
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Rough cut at a first patch is attached.
Still thinking about whether Set operations should be accepting any iterable or
whether they should be tightened to expect other Set instances. The API for
set() came from set.py
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Sorry, this isn't a bug. I think you've rediscovered a property of mutable
objects. See
http://docs.python.org/tutorial/controlflow.html#default-argument-values for an
example.
--
nosy: +rhettinger
resolution
601 - 700 of 9507 matches
Mail list logo