+1.
I find the offline versions to be vital.
Sent from my iPhone
On Sep 19, 2008, at 12:20 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin points out that in the past, as part of the release process,
we've built separate downloadable documen
ld bug" myth
http://fastcompression.blogspot.com/2014/06/debunking-lz4-20-years-old-bug-myth.html
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/opti
early zero benefit.
IMO, the proposed quest for purity is misguided.
There are many practical reasons to let the builtin
containers continue work as the do now.
Raymond ___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listi
timization was put in because
it was common for people to accidentally incur
the performance penalty.
With sum(), we don't seem to have that problem
(I don't see people using it to add lists except
just to show that could be done).
Raymond
___
#x27;t have to while the 2 to 3 transition is still in progress.
Every new deprecation of APIs that existed in Python 2.7 just adds another
obstacle to converting code. Individually, the differences are trivial.
Collectively, they present a good reason to never migrate cod
isn't flat-out broken either. There is some
unfortunate asymmetry between bytes() and bytearray() in Python 2,
but that ship has sailed. The current API for Python 3 is pretty good
(though there is still a tension between wanting to be like lists and like
strings both at the same time).
R
f = bytearray(1024)" means. That is
not an actual problem that needs solving (or breaking).
What may be an actual problem is code like "char = bytes(1024)"
though I'm unclear what a user might have actually been trying
to do with code like that.
Raymond
--- excerp
forward with adding it (and I don't see why), then as an
alternate
constructor, the name should be from_int() or some such to avoid ambiguity
and to make clear that it is a class method.
> iterbytes() isn't especially attractive as a method name, but it's far more
&g
On Sep 12, 2014, at 5:34 PM, Benjamin Peterson wrote:
> The
> new VM is a bit beefier and has what I think is better network
> connectivity, so hopefully that will improving the speed of repository
> operations.
Thanks Benjamin, the repo is noticeably faste
> On Nov 5, 2014, at 8:33 AM, Ethan Furman wrote:
>
> I'm looking for real-world uses of collections.Counter, specifically to see
> if anyone has been surprised by, or had to spend extra-time debugging, issues
> with the in-place operators.
Please stop using the mailing lists as way to make a
eautiful that it is now, and I think that
matters.
Lastly, as I mentioned on python-ideas, if we really want people to migrate to
Python 3, there should be a strong aversion to further increasing the semantic
difference between Python 2 and Python 3 without a really good reason.
Raymond
P.S
> On Nov 22, 2014, at 6:31 AM, Nick Coghlan wrote:
>
> I'm definitely coming around to the point of view that, even if we wouldn't
> design it the way it currently works given a blank slate, the alternative
> design doesn't provide sufficient benefit to justify the cost of changing the
> beha
es[-1])
yield word
return ''.join(_generator())
I could scan for even more examples, but I think you get the gist.
All I'm asking is that you consider that your proposal will do more
harm than good. It doesn't add any new capability at all.
It just kill
> On Nov 27, 2014, at 8:52 AM, Guido van Rossum wrote:
>
> I understand that @allow_import_stop represents a compromise, an attempt at
> calming the waves that PEP 479 has caused. But I still want to push back
> pretty hard on this idea.
>
> - It means we're forever stuck with two possible se
Hello my name is Raymond and I would like to fix a broken link on pep 3. If
you go to
https://www.python.org/dev/peps/pep-0003/ and click on link
http://www.python.org/dev/workflow/, it returns a 404.
What is the correct url? Should we also update the description "It has
been replaced b
ferred
mapping (an ordereddict, a persistentdict, a chainmap, etc) and
the flexibility of establishing your own rules for whether and
how to do a reverse lookup.
Raymond Hettinger
P.S. Besides the core conceptual issues listed above, there
are a number of smaller issues with the TD that surfaced
n't tell me
much. Instead, it would be nice to have something suggestive of what it
actually does which is automatically adding boilerplate methods to a general
purpose class. Perhaps, @boilerplate or @autoinit or some such.
Raymond
___
Python-De
re things lazy is a
false optimization unless those things never get used. Otherwise, all we're
doing is ending the timing before all the relevant work is done. If the lazy
object does get used, we've made the actual total execution time worse (because
of the overhead of t
, "hg log" or "hg commit" will likely be instructive about what
portion of the imports actually get used. A push or pull will likely be I/O
bound so those commands are less informative.
Raymond
- Quick timing for a minimal script using the requests module
---
quot;, "from itertools import product" and "from collections import
namedtuple".
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org
rwise).
Also, the time to argue and change APIs is BEFORE they are released, not a
decade or two after they've lived successfully in the wild.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/p
he people who designed those
classes, and breaking all user code that reasonably relied on those useful and
intentional behaviors?
Raymond
P.S. Possibly related: We've gone out of way in many classes to have a
__repr__ that uses the name of the subclass. Presumably, this is to make lif
te versions of requests, typeshed, jinja2, etc).
Already, we've have updates to typing.py in the point releases of Python
because those updates were considered so useful and important.
Raymond
___
Python-Dev mailing list
Python-Dev@pytho
g insertion order.
Summary: I think MicroPython will be just fine and if needed I will help
create the patch that implements compact-and-ordered behavior.
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
ill be even easier for them than it was for us (the code is simpler because it
doesn't have special cases for key-sharing, unicode optimizations, and whatnot).
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/li
REST APIs, it is nice have the parameter order match
documented examples.
We've lived without order for so long that it seems that some of us now think
data scrambling is a virtue. But it isn't. Scrambled data is the opposite of
human friendly.
Raymond
P.S. Especially during debu
ld have a preference to not grow the stable C API.
Bigger APIs are harder to learn and remember, not so much for you and Victor
who use these frequently, but for everyone else who has to lookup all the
macros whose function isn't immediately self-evident.
Raymond
__
exity or decrease in complexity?
My personal experience with the macros hasn't been positive. Perhaps everyone
else thinks it's fine. If so, I won't stand in your way.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://ma
eout ?? local_timeout ?? global_timeout
'foo' in (None ?? ['foo', 'bar'])
requested_quantity ?? default_quantity * price
name?.strip()[4:].upper()
user?.first_name.upper()
Raymond
___
Python-Dev mailing
> On Dec 4, 2017, at 9:17 AM, Guido van Rossum wrote:
>
> And with this, I'm accepting PEP 557, Data Classes.
Woohoo! I think everyone was looking forward to this moment.
Raymond
___
Python-Dev mailing list
Python-Dev@py
Both typing.NamedTuple and dataclasses.dataclass use the somewhat beautiful PEP
526 variable notations at the class level:
@dataclasses.dataclass
class Color:
hue: int
saturation: float
lightness: float = 0.5
and
class Color(typing.NamedTuple):
hue: i
> On Dec 7, 2017, at 12:47 PM, Eric V. Smith wrote:
>
> On 12/7/17 3:27 PM, Raymond Hettinger wrote:
> ...
>
>> I'm looking for guidance or workarounds for two issues that have arisen.
>>
>> First, the use of default values seems to completely preclude
er.
The proposal would make it possible for instructors to teach dataclasses
without having to teach typing as a prerequisite. And, it would make
dataclasses usable for projects that have elected not to use static typing.
Raymond
___
Python-Dev mailin
> On Dec 10, 2017, at 1:37 PM, Eric V. Smith wrote:
>
> On 12/10/2017 4:29 PM, Ivan Levkivskyi wrote:
>> On 10 December 2017 at 22:24, Raymond Hettinger
>> mailto:raymond.hettin...@gmail.com>> wrote:
>>Without typing (only the first currently works):
>
teed
while Z is not.
I think an ordering guarantee for regular dicts would be a nice Christmas
present for our users and developers.
Cheers,
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listin
he core design of OrderedDicts against my wishes.
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
For example, have namedtuples's _asdict() go
back to returning a plain dict as it did in its original incarnation. Also, it
looks like argparse could save an import by using a regular dict.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
I don’t see the crashes on the buildbots.
>
> Can anyone verify?
I saw this same test failure. After a "make distclean", it went away.
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
you still have the keys to the time machine?
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 Dec 15, 2017, at 1:47 PM, Guido van Rossum wrote:
>
> On Fri, Dec 15, 2017 at 12:45 PM, Raymond Hettinger
> wrote:
>
> > On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote:
> >
> > Make it so. "Dict keeps insertion order" is the ruling.
>
ll__
['dataclass', 'field', 'FrozenInstanceError', 'InitVar', 'fields', 'asdict',
'astuple', 'make_dataclass', 'replace']
Also, remember that dataclasses have a dual role as a data holder (which is
collection-li
...
The @dataclass decorator has a much broader mandate and we have almost no
experience with it, so it is hard to know what legitimate use cases will arise.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python
m dataclasses import dataclass
>>> @dataclass(hash=False)
class A:
x: int
>>> hash(A(1))
285969507
I'm hoping that this part of the API gets thought through before it gets set in
stone. Since dataclasses code never got a chance to live in the wild (on PyPI
or some
I
recommend putting various correct and incorrect examples in front of other
users (preferably experienced Python programmers) and asking them to predict
what the code does based on the source code.
Raymond
___
Python-Dev mailing list
Pytho
inheriting
> from tuple, and it should just be solved right, somehow.)
Perhaps a new variant of __init_subclass__ would work.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-de
e):
pass
>>> t = T([10, 20, 30])
>>> t.cached = True
>>> class F(frozenset):
pass
>>> f = F([10, 20, 30])
>>> f.cached = True
>>> class B(bytes):
pass
>>> b = B(
rtunity to decline. That said, proponents of symmetry requests tend to
feel strongly about it and tend to never fully accept such a request being
declined (it leaves them with a sense that Python is disordered and unbalanced).
Raymond
My thoughts on the feature request -
What is the propo
is_integer()
> So I think the OP of the bug has a valid point, 27 years without this feature
> notwithstanding.
Okay, I'll ask the OP to update his patch :-)
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
ts rather than letting you decompose to more
more basic types. It's nice to have a way to move down the chain from ℚ, ℝ, or
ℂ to the more basic ℤ (of course, that only works because floats and complex
are implemented in a way that precludes exact irrationals).
Raymond
___
> On Mar 13, 2018, at 12:07 PM, Guido van Rossum wrote:
>
> OK, please make it so.
Will do. I'll create a tracker issue right away.
Since this one looks easy (as many things do at first), I would like to assign
it to Nofar Schnider (one of my mentees).
Raymond
>
>
et benefits of
key-sharing. That benefit is lost only when the instance dict keys are
modified downstream from __init__(). So, from a dict size point of view, your
optimization is fine.
Still, you should look at whether this would affect static type checkers, lint
tools, and other tooling.
R
On Mar 25, 2018, at 8:08 AM, Tin Tvrtković wrote:
>
> That's reassuring, thanks.
I misspoke. The object size is the same but the underlying dictionary loses
key-sharing and doubles in size.
Raymond
___
Python-Dev mailing list
Python-Dev
d I think it still serves a useful
purpose. So, unless it is considered broken, I don't think it should be
deprecated.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ld, code that would be broken if the distinction is
lost.
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
27;s usually pretty easy to fix.
I don't think that confidence is warranted. The world of Python is very large.
When public APIs (such as that in the venerable types module) get changed, is
virtually assured that some code will break.
Raymond
___
less appealing. The proposal
also messes with my mental model for the distinction between
expressions and statements.
It probably doesn't matter at this point (minds already seem to be made up),
but put me down for -1. This is a proposal we can all easily live without.
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 Apr 26, 2018, at 12:40 AM, Tim Peters wrote:
>
> [Raymond Hettinger ]
>> After re-reading all the proposed code samples, I believe that
>> adopting the PEP will make the language harder to teach to people
>> who are not already software engineers.
>
> C
orical trick for dismissing a bunch of
thoughtful posts.
Adding this new syntax is a one-way trip -- we don't get to express
regrets later. Accordingly, it would be nice if the various concerns
being presented were addressed directly rather than being
dismissed with a turn of p
le reading, do something
> }
Thanks Antoine, this is an important point that I hope doesn't get lost.
In a language with exceptions, assignment expressions are less needful.
Also, the pattern of having of having mutating methods return None
further limits the utility.
Raymond
__
e that integers hash to themselves.
That is very fast to compute :-) Also, it tends to prevent hash collisions for
consecutive integers.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-
ould be nice for __reversed__ to already be
supported so that people won't be tempted to implement an ugly workaround using
popitem() calls followed by reinsertions.
Raymond
.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pytho
proportional to size, so
compression is likely to be a net win (much as it was for header compression in
HTTP/2).
The PEP lists compression as a possible a refinement only for large objects,
but I expect is will be a win for most pickles to compress them in their
entirety.
Raymond
___
easily iterate in reverse?
It really doesn't matter whether an implementer uses a dense array of keys or a
doubly-linked-list; either way, looping backward is as easy as going forward.
Raymond
P.S. It isn't going to be hard to update MicroPython to have a compact and
ordered dict (
89 is
> now accepted.
I echo that sentiment. Thank you for your work.
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
ABI or API level.
+1 from me a well. We probably should have done this long ago.
Raymond Hettinger
___
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
is a red-herring (an orthogonal issue).
If you care about 2-to-3 migration, then start
opposing proposals for API changes that increase
the semantic difference between 2 and 3.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.
FWIW, it took me 100+ hours. Doing this right is a non-trivial undertaking
(in modern times, there are an astonishing number of changes per release).
That said, it is rewarding work that makes a difference.
Raymond
[David Murray]
I can tell you that 3.4 took me approximately 67 hours
fooled the way you describe. The difference this time is
that it results in a crash rather than a wrong answer. I've rolled back the
commit so we are back to where we've always been.
Raymond
P.S. I don't think python-dev post was necessary or helpful (and I still
haven't
matic, saving us a little typing.
The above above are random thoughts based a first quick read. Don't take
them too seriously. Some are just shooting from the hip and are listed as food
for thought.
Raymond
___
Python-Dev mailing list
Pyth
fit the itertools
and because documenting them as classes suggest that they should
each have a list of methods on that class (which doesn't make send
because the itertools are each one trick ponies with no aspirations
to grow a pool of methods).
When I get a chan
life unnecessarily difficult.
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
now because I've
never thought about it. As far as I can tell, this question has never
come up in the 13 years of itertools existence and you may be the
first person to have ever cared about this.
Raymond
___
Python-Dev mailing list
y in some section that describes what happens to any C type
that defines sets the Py_TPFLAGS_BASETYPE flag. In general, all of
the exposed dunder methods are overridable or extendable by subclassers.
Raymond
P.S. Threads like this are why I've developed an aversion to python-dev.
as the recent check-in replacing redundant
code in deque_repeat with a call to the common code in deque_inplace_repeat).
My schedule lately hasn't given me any big blocks of time to work with, so I do
the steps piecemeal as I get snippets of development time.
Raymond
P.S. For those who
Python 3 into an effective
tool that makes people *want* to adopt it and to be honest with
anyone who asks us about the pros and cons of switching over.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listin
#x27;3.14') + 2.71828
Traceback (most recent call last):
File "", line 1, in
Decimal('3.14') + 2.71828
TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'float'
Raymond Hettinger
__
visible coercions being more likely to
cause pain than relieve pain).
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
, 10820, 10820] references, sum=32460
>>> test_threading leaked [2842, 2844, 2844] memory blocks, sum=8530
>
> Bisection shows they were probably introduced by:
>
> changeset: 97413:dccc4e63aef5
> user:Raymond Hettinger
> date:Sun Aug 16 19:43:34 2015
> On Oct 25, 2015, at 12:33 PM, Raymond Hettinger
> wrote:
>
>> On Oct 22, 2015, at 10:02 AM, Brett Cannon wrote:
>>
>> So my question is, the byte code generator removes the unused functions,
>> variables etc…, is it right?
>>
>> Technical
can't avoid it.
IIRC, the code was never generated in the first place (before the peephole
pass). This used to be true before the AST branch was added and I think it may
still be true.
Raymond Hettinger
___
Python-Dev mailing list
P
> On Nov 11, 2015, at 10:50 PM, Benjamin Peterson wrote:
>
>> +if (Py_SIZE(deque) == 0)
>> +return;
>> +
>
> dequeue is not varsized in Python 2.7, so using Py_SIZE() is incorrect.
Fixed in a2a518b6ded4.
-if (Py_SIZE(deque) == 0)
+
gt; possibility.
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
ou have two ways of doing counter math:
1. Normal integer arithmetic using update() and subtract() does straight
addition and subtraction, either starting with or ending-up with negative
values.
2. Saturating arithmetic using the operators: + - & | excludes non-positive
results. This suppo
ar's Pycon)
Almost nothing that is wrong with CPython is stylistic, the real issues are
more substantive. That is where you should devote your talents.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/m
about it on StackOverflow, so we do know that there is at least some interest.
I'm not sure that it needs to live in the standard library though.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/l
> On Apr 10, 2016, at 11:43 AM, Guido van Rossum wrote:
>
> I will approve the PEP as soon as you've updated the two function
> names in the PEP.
Congratulations Steven.
Raymond
___
Python-Dev mailing list
Python-Dev
expected secondary effects.
perfect-is-the-enemy-of-good-ly yours,
Raymond
P.S. The patch is smaller, more tractable, and in better shape than the C
version of OrderedDict was when it went in.
___
Python-Dev mailing list
Python-Dev@python.org
https
ting out
our actual objective.
The OPs original patch had already gotten this part done and it ran fine for me.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python
> On Apr 24, 2016, at 2:31 PM, Victor Stinner wrote:
>
> 2016-04-24 23:16 GMT+02:00 Raymond Hettinger :
>>> On Apr 24, 2016, at 1:16 PM, Victor Stinner
>>> wrote:
>>> I proposed to not try to optimize ceval.c to fetch (oparg, opval) in a
>>>
hether some of them
are standard-library worthy (i.e. we will have them around forever).
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
I have mixed feelings on this one, at once applauding efforts to simplify an
eternally messy part of the eval loop and at the same time worried that it
throws aways years of tweaks and improvements that came beforehand. This is
more of a major surgery than the other patches.
Raymond Hettinger
lp() rather than
limiting introspection by way of less clean coding practices.
Raymond
current code for suppress()
class _SuppressExceptions:
"""Helper for suppress."""
def __init__(self, *exceptions):
self._exceptions = ex
On Oct 20, 2013, at 9:21 AM, Eric Snow wrote:
> If anyone is interested in having a (faithful) C implementation of
> OrderedDict for the 3.4 release, I have a patch up [1]. My interest
> in having the patch applied is relative to proposals that won't apply
> to 3.4, so I haven't felt the need t
case-preserving feature.
That said, I find the TD to be fascinating and there's more work
to do before making a decision.
Hopefully, this post will make the thought process more transparent.
Cheers,
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 Jan 14, 2014, at 9:12 PM, Antoine Pitrou wrote:
> I'm +1 on the sidefile approach. +0 on the various buffer approaches.
> -0.5 on the current "sprinkled everywhere" approach.
I concur with Antoine except that I'm a full -1 on commingling
generated code with hand edited code. Sprinked every
On Jan 25, 2014, at 5:29 AM, Ezio Melotti wrote:
> Nick also suggested to document
> our deprecation policy in PEP 5 (Guidelines for Language Evolution:
> http://www.python.org/dev/peps/pep-0005/ ).
Here's a few thoughts on deprecations:
* If we care at all about people moving to Python 3, the
On Jan 25, 2014, at 4:01 PM, Brett Cannon wrote:
> As the author of the PEP and I can say that `lambda (x, y): x + y` can just
> as easily be expressed as `lambda x, y: x + y` and then be called by using
> *args in the argument list. Anything that gets much fancier typically calls
> for a def
ets there).
* That said, it is a reasonable possibility that the standard library would
benefit from some kind sorted collection (the idea comes up from time
to time).
Raymond Hettinger___
Python-Dev mailing list
Python-Dev@python.org
https://mail.p
On Feb 18, 2014, at 1:09 PM, Terry Reedy wrote:
> While the function could be implemented as one 70-line function, it happens
> to be implemented as a 4-line wrapper for a completely undocumented
> (Untokenizer class with 4 methods. (It is unmentioned in the doc and there
> are currently no d
it up
in perpetuity.
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
1 - 100 of 1495 matches
Mail list logo
