> On Jun 29, 2016, at 12:42 AM, Larry Hastings wrote:
>
> By the way, I don't know why you Cc'd Nick and Brett. While they're fine
> fellows, they aren't on the release team, and they aren't involved in these
> sorts of decisions.
We're all i
who are interested, here is a direct link to the PDF that describes
the algorithm.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.22.6990&rep=rep1&type=pdf
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.
cle tells us that "troubles with radix sort are in
implementation, not in conception".
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ce burden.
Having more include files to search through doesn't make it easier to learn
the C code or to maintain it.
Over time, the C code has gotten harder to read with cascades of macros and
from breaking single concept files into multiple inter-dependent files.
Raymond
> On Sep 14, 2016, at 3:50 PM, Eric Snow wrote:
>
>>
>> Then, I'll do same to sets.
>
> Unless I've misunderstood, Raymond was opposed to making a similar
> change to set.
That's right. Here are a few thoughts on the subject before people starting
y packed the keys (as in Serhiy's
non-representative example).
Raymond
P.S. Algorithmically, the compact dict seems to be mostly where it needs to be
(modulo some implementation bugs that are being ironed-out). However, the code
hasn't been tuned and polished as much as the old im
)"
"list(d)"
10 loops, best of 3: 54.7 msec per loop
Repeating the timings, I get consistent results: 12.0 vs 46.7 and 12.0 vs 52.2
and 11.5 vs 44.8.
Raymond
P.S. Timings are from fresh builds on Mac OS X 10.11.6 running on a 2.6 Ghz
Haswell i7 with 16Gb of 1600 Mhz ram: $
nge lots of
code that is currently working just fine.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
have other itertools feature requests, please put
them on the tracker an assign them to me.
Thank you,
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> On Nov 22, 2016, at 6:57 AM, Victor Stinner wrote:
>
> Should I revert these changes?
I don't think reverting any of these would improve the release.
I vote for them to stay.
Raymond
___
Python-Dev mailing list
Python-Dev@py
e search comes up nearly empty.
That said, it might be worthwhile to check with Jeremy to get his thoughts
before removing his code.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Un
essions caused by backported bugfixes
> and make bugfix releases more reliable.
+1 on delaying 2.7.13 for a bit. As long as it doesn't muck up Benjamin's
schedule, the extra time would be helpful (Python 3.6.0 got all the focus
recently).
Raymond
_
s clearer---it's not a list."
>
> I strongly suspect that Raymond H. intentionally choose to consistently
> represent deques as "deque()" With recursion, some current results
> are:
>
> >>> import _collections as c
> >>> d = c.deque()
psort-analysis-part.pdf
If you have other follow-ups, please take this discussion to another list.
This list is for the development of the Python core and not for general
questions about algorithms or use of the language.
Raymond Hettinger
___
P
> On Dec 12, 2016, at 8:12 AM, Raymond Hettinger
> wrote:
>
> The heapify() algorithm is well known and well studied. A quick Google
> search turns up plenty of explanations:
> https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF
it, but I thought I'd ask anyway.
I think what we have has proven itself to be good enough to detect the common
cases, and it isn't worth it to have dicts grow an extra field which has to be
checked or updated on every operation.
Raymond
___
> On Dec 13, 2016, at 8:42 AM, Raymond Hettinger
> wrote:
>
>> On Dec 13, 2016, at 1:51 AM, Max Moroz wrote:
>>
>> Would it be worth ensuring that an exception is ALWAYS raised if a key
>> is added to or deleted from a dictionary during iteration?
&g
s far as I can tell, the adoption rate of Python 3.2 was very low. Python 3's
story didn't become attractive until later.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
out reservations.
Also, I would like the 3.6.0 announcement to not get drowned-out or attenuated
by other announcements around older releases (i.e. it would be nice if 3.6.0
was the actual latest release of any version for a while).
Raymond
___
Python-D
n somewhat of a pain
and have led to many otherwise unnecessary indirections.
Raymond
P.S. I'm not sure if we care about the size of the types but they are growing
at an unprecedented rate (amidst lots of other code churn as well).
__
__set__),
the default position should be to stick with a core usable set of ABCs that are
know to have real value. Each new ABC has a non-trivial maintenance burden and
requires extra effort on the part of users to learn and remember.
Raymond
___
P
> On Jan 22, 2017, at 6:31 PM, Ramsey D'silva wrote:
>
> Nice to meet all of you'll. I'm excited to learn and hopefully contribute
> someday.
Welcome aboard.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http
e of asyncio.
What I'm more concerned about is what the other places actually are. Rather
than putting async variants of everything sprinkled all over the standard
library, I suggest collecting them all together, perhaps in a new asynctools
module.
Raymond
_
Yes. It is perfectly reasonable to backport improvements to the tooling as
long as it doesn't break anyone's existing build process.
Sent from my iPhone
> On May 4, 2017, at 10:13 AM, Victor Stinner wrote:
>
> tl;dr Are you ok to backport my change replacing "make touch" with
> "make regen-a
someone truly cares about the exec time for a particular named tuple, the
_source option makes it trivially easy to just replace the generator call with
the expanded code in that particular circumstance.
Raymond
P.S. I'm fully supportive of Victor's efforts to build-out structseq to make
s won't conflict with field
names in the named tuple itself. For example, we want to allow
Path=namedtuple('Path', ['source', 'destination']).
If I had it all to do over again, it might have been better to have had a
different convention like source_ with a tra
is named tuple
proposal, the complexity is manageable, but the overall trend isn't good and I
get the feeling the aggressive optimization is causing us to forget key par
ts of the zen-of-python.
Cheers,
Raymond
P.S. Ironically, a lot of my consulting work comes from people who have
cre
ry or beneficial. IMO, we're about to turn the
named tuple code into a mess but will find that most users, most of the time
will get nearly zero benefit.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/list
clean way to opt-out of the additional projections (don't
want to leave them high and dry if they happen to have a legitimate use case).
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsu
Dear Python developers,
The help(list) shows in a python console the following documentation
string for the list.sort() method.
sort(self, /, *, key=None, reverse=False)
| Sort the list in ascending order and return None.
|
| The sort is in-place (i.e. the list itself is modified)
(2, 'd'), (3, 'e')]
>>> L.sort(key=itemgetter(0), reverse=True)
>>> L = [(3, 'e'), (2, 'd'), (2, 'b'), (1, 'c'), (1, 'a')]
Should the tuples comparison is in this case, I thought, not be solely
based on the first tup
Dear All,
You are all completely right.
Sorry for the confusion.
Thank you all very much for putting my mind right about this issue.
Best Regards
Raymond Bisdorff
> On 30 Oct 2021, at 19:00, Tim Peters wrote:
>
> [Raymond Bisdorff ]
>> I fully agree with your point. By d
For the benefit of the audience on python-dev, you should also mention that
this proposal and associated PR has been twice discussed and rejected on the
tracker:
https://bugs.python.org/issue45907
https://bugs.python.org/issue45843
The response just given by Skip pretty much matches the c
sed, but I'm hoping it will catch on (just
like people are slowly growing more aware that they can add docstringa to
fields in named tuples).
Raymond
On Fri, Mar 18, 2022 at 4:33 AM Serhiy Storchaka
wrote:
> Currently __slots__ can be either string or an iterable of strings.
>
>
n a "triager" and a "core
developer" is the ability to push the "commit" button. In a way, that is the
least interesting part of the process and is often a foregone conclusion by the
time it happens.
Raymond
___
Python-
e tracker.
I have high hopes for the success of the migration but success isn't a given.
Raymond
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mai
are anonymous or have pseudonyms. Am not sure
how those can be migrated, we know very little about the participant except for
their recurring posts.
Raymond
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-d
ble that
it will be suggested periodically because it is such an obvious thing to
consider.
Raymond
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-de
, but sorted() and min()
are allowed to assume a meaningful total ordering (which might or might not be
true). In other words, containers and functions are allowed, when necessary or
useful, to override the decisions made by their data. This seems like a
reasonable state of affairs.
The current
users by deferring them for
another release.
Raymond
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
http
the identity-implies-equality
step currently in PyObject_RichCompareBool(). It isn't just an optimization,
it is necessary for writing correct application code without tricks such at the
"if x == x: ..." test.
Raymond
___
Python-Dev maili
rything SimpleNamespace already does just so we
can add some supporting dunder methods. Please add more commentary so we can
figure-out the best way to offer this powerful functionality.
Raymond
___
Python-Dev mailing list -- python-dev@pyth
[GvR]
> We should not try to import JavaScript's object model into Python.
Yes, I get that. Just want to point-out that working with heavily nested
dictionaries (typical for JSON) is no fun with square brackets and quotation
marks.
lso, it still leaves you with
using setattr(ns, attrname, attrvalue) or tricks with vars() when doing
updates. The AttrDict recipe is popular for a reason.
Raymond
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pyt
hich sometimes cause mental hiccups
initially being read as if-ilter and is-lice.
Raymond
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.pyt
This will be a nice improvement.
Raymond
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https
just makes a single dict lookup and returns the
value.¹ The lru_cache_make_key() function just increments the empty args tuple
and returns it.² And because it is a C object, calling it will be faster than
for a Python function that just returns a constant, "lambda: some_constant()".
> On Apr 29, 2020, at 12:55 AM, Tom Forbes wrote:
>
> Hey Raymond,
> Thanks for your input here! A new method wouldn’t be worth adding purely for
> performance reasons then, but there is still an issue around semantics and
> locking.
Right.
> it doesn’t actually e
> On Apr 29, 2020, at 4:20 PM, Antoine Pitrou wrote:
>
> On Wed, 29 Apr 2020 12:01:24 -0700
> Raymond Hettinger wrote:
>>
>> The call_once() decorator would need different logic:
>>
>> 1) if the function has already been called and result is known, retur
nce() to block and await a
result are wasted.
4) It would be inconsequential if this function were called twice.
5) A more common way to do this is to move the test into the lookup() function
-- see below.
Raymond
-
CHAR_BASE = {}
def _init_chars():
for code in range
Would either of the existing solutions work for you?
class X:
def __init__(self, name):
self.name = name
@cached_property
def title(self):
print("compute title once")
return self.name.title()
@property
@lru_cache
def upper(self):
print("compute u
> On Apr 30, 2020, at 10:44 AM, Carl Meyer wrote:
>
> On Wed, Apr 29, 2020 at 9:36 PM Raymond Hettinger
> wrote:
>> Do you have some concrete examples we could look at? I'm having trouble
>> visualizing any real use cases and none have been presented so far.
n, tenacity, team play, and overcoming adversity.
May your sub-interpreters be plentiful,
Raymond
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/pyth
s.
The current process doesn't make it likely that a balanced document is created
for decision making purposes.
Raymond
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://m
Most of the work is being done
by one person. Many of the PRs aren't reviewed. The rate and volume of PRs are
so high that almost no one can keep track of what is happening. Mark and Stefan
have pushed back but with no effect.
Raymond
===
ere is a certain irony in making repeated, unsubstantiated promises to make
the language 2x faster and then checking in changes that make the
implementation slower.
Raymond
P.S. What PyPy achieved was monumental. But it took a decade even with a
well-organized and partially-funded team of
always semantically neutral. Your proposed transformation is changes which methods get called and
makes assumptions that the usual relationships between comparison operators holds (but it might not given rich comparisons, for
example, sets use the comparison opera
The online development docs stopped their nightly rebuilds four days ago.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
al machine."
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
eone, I usually assume they intend to work on it at some point. In contrast, unassigned means that no one is
currently handling it.
Just thought I would toss this out since the status of so many bugs/patches is
being updated today.
Raymond
___
Pyt
s.
Thanks for your efforts.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
C:\py27>py27 lib\test\regrtest.py -uall test_tk
test_tk
test test_tk failed -- Traceback (most recent call last):
File "c:\py27\lib\lib-tk\test\test_tkinter\test_text.py", line 32, in
test_search
self.failUnlessEqual(text.search('-test', '1.0', 'end'), '1.2')
AssertionError: != '1.2'
1 test
http://www.latimes.com/news/science/la-sci-satellite-collision15-2009feb15,0,7901281.story
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-de
issubclass() should do what the docs say and start by
testing whether A and B are the same object.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
If someone sets the -3 option to get py3k warnings, should the classic division
warning get turned-on automatically?
Right now, I get no warnings for:
python -3 -c "9 / 5"
Raymond
___
Python-Dev mailing list
Python-Dev@pytho
[Venkatraman S]
the following line
kind of confuses me and wasnt sure what exactly Raymond(et al) is planning,
I think the AST optimization work is being pursued by tlee.
See his current results on the branch: tlee-ast-optimize/
I don't know if this work has stalled but it was off to a
tters (i.e. LibYAML).
There are similar issues with xmlrpclib with the choice of parsers, marshallers,
and unmarshallers. Possibly, the same mechanism can offer the user more
control over which dbm is used when there are several choices.
Ra
ed as
dominant.
- Original Message -
From: Brett Cannon
To: Raymond Hettinger
Cc: Python Dev
Sent: Friday, February 20, 2009 12:41 PM
Subject: Re: [Python-Dev] Choosing a best practice solution for
Python/extensionmodules
On Fri, Feb 20, 2009 at 12:33, Raymond Hett
have patches ready for him to review?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
over
the long-term.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
that ordered dictionaries will be ready:
http://www.python.org/dev/peps/pep-0372/
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
if it turns out to be too slow or thread safety is required.
The corresponding issue in the tracker: http://bugs.python.org/issue5397
Link to the PEP: http://www.python.org/dev/peps/pep-0372/
Anything else that should be done?
Guido, I'm recommending this PEP for acceptance.
s. It's just asking
for problems and it introduces an unnecessary difference
from regular dicts.
Given that either choice will be surprising to someone, we opted
for the simplest API with the fewest special cases and made sure
the choice was clearly not
d and an alternative was provided for people that
needed it.
Outside of your differing judgment on the __eq__ method, are you
basically happy with the ordered dict PEP?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
am.
Once you've decided on __eq__, can I mark the PEP as approved?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
existing code that relies on the returned object having an order insensitive comparison.
A object that currently returns a dict should be able to return an OrderedDict without breaking anything. The proposed change
precludes this possibility as well as the ones mentioned ab
False
OrderedDict-to-OrderedDict comparisons are order sensitive -- matching your
intuition
OrderedDict-to-OtherMappings -- allow me and Armin to have our substitutability
for dicts.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http
[GvR]
This sounds fair. Note that dict.__eq__ actually returns
NotImplemented if not isinstance(other, dict) so you could tighten the
test to isinstance(other, dict) if you wanted to.
Okay. Done deal.
Raymond
___
Python-Dev mailing list
Python-Dev
My preference is OrderedDict.
That says that it is a pure python class like Counter, UserDict, UserList,
MutableMapping and other collections classes.
It is clear and explicit in its intention and doesn't make you try to remember
what the o in odict stands for.
Ra
/bikeshedding
Yes. Also we need to paint it green with pink polka dots :-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40m
he former to be non-communicative.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
e other classes
in
collections are named Counter, UserDict, UserList, UserString, MutableMapping,
etc.
Besides, the lowercase/uppercase distinction helps us distinguish functions
from classes.
This is the way I've see every Python book do it since the daw
tuple() is a factory function that creates a class, it isn't
a class itself. There are no instances of namedtuple(). Most functions
are all lowercase. Don't know if that applies to factory functions too.
Raymond
___
Python-Dev mai
-
From: "Guido van Rossum"
To: "Raymond Hettinger"
Cc: ; "Armin Ronacher"
Sent: Monday, March 02, 2009 3:38 PM
Subject: Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections
ready for pronouncement
On Mon, Mar 2, 2009 at 3:13 PM, Raymond Hett
an entire new
categoy of use cases with only a trivial, easily-understood API extension. Patch is attached at http://bugs.python.org/issue5397
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
I recommend that you either make this a
__private variable (signalling strongly that people shouldn't ever
reference it),
Will do. We want to make sure we can substitute a C implementation that has a completely different underlying structure (hash table
plus a doubly linked list).
Ra
[Forest]
Perhaps a new method like getfirst() would be worth while here?
Guido already gave you a way to access the first item using the existing API.
Using next(iter(d)) also works.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http
can be switched in the
distant future?
Should the names in the __repr__ be changed now or later?
>>> datetime(2008, 7, 31, 12, 0, 0)
datetime.datetime(2008, 7, 31, 12, 0)
Raymond
___
Python-Dev mailing list
Python-Dev@python
that are some variant spelling
OrderedDict except for one which goes by the mysterious name of StableDict.
Am still +1 on painting the class green with pink polka dots, but I'm starting to appreciate why others are insisting on pink with
green polka dots ;-)
Beware, deleting an item from an OrderedDict (in the current
implementation) is O(N).
Am I correct in presuming that that would not be true of .popitem?
Yes. The popitem() method is O(1).
Raymond
___
Python-Dev mailing list
Python-Dev
Just notices that the empty() and full() methods were still there.
IIRC, we agreed to take them out (but leaving qsize() exposed).
The docs entries and test cases were taken out, but the actual
methods were accidentally left in.
Raymond
___
Python-Dev
y.
We discussed removing them and most of the work was done.
Guido, any thoughts?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ar
Yup, I'd need to remove support in multiprocessing too.
ahead and tried adding a warning to my local checkout.
Thanks for quickly checking this out.
Will be nice to get the API cleaned-up.
Leaving out part of the clean-up was a mistake.
Ra
g that 3.1 goes final this summer and that 3.2 follows
18 months later). That being said, I don't really care much.
We don't actually have to do anything. It could stay in forever
and cause no harm.
Raymond
___
Python-Dev mailing list
P
bout its limitations.
I still fail to see the rationale for removing these
two methods.
I believe there was a thread (in January 2008) with a
decision to keep qsize() but to drop empty() and full().
Raymond
___
Python-Dev mailing list
Python
be left out of the docs.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
You want the methods
back and I think that's sufficient reason to bring it back.
The "not reliable" wording in the docstrings was put there by Guido 16 years ago.
http://svn.python.org/view/python/trunk/Lib/Queue.py?revision=3158&view=markup
Speak to him about this. I'
svn.python.org/view/python/trunk/Doc/library/queue.rst?r1=59750&r2=59969
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Benjamin Peterson]
On behalf of the Python development team and the Python community, I'm
happy to announce the first alpha release of Python 3.1.
Thanks for the good work.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
This is precisely the reason why I want Python to continue including its
batteries. If we give that up, it will not come back, and users get
frustrated that they have to collect stuff from many places, and that
the stuff doesn't fit together completely.
I concur.
Ra
201 - 300 of 1495 matches
Mail list logo
