On 06/02/2017 02:46 AM, Victor Stinner wrote:
I would be curious of another test: use pymalloc for objects larger
than 512 bytes. For example, allocate up to 4 KB?
In the past, we already changed the maximum size from 256 to 512 to
support most common Python objects on 64-bit platforms. Since
On 06/02/2017 12:09 PM, Tim Peters wrote:
I should note that Py_ADDRESS_IN_RANGE is my code - this isn't a
backhanded swipe at someone else.
One minor note. During the development of 3.6, CPython started
permitting some C99-isms, including static inline functions.
Py_ADDRESS_IN_RANGE was th
On 06/02/2017 02:38 AM, Antoine Pitrou wrote:
I hope those are not the actual numbers you're intending to use ;-)
I still think that allocating more than 1 or 2MB at once would be
foolish. Remember this is data that's going to be carved up into
(tens of) thousands of small objects. Large objec
On 06/04/2017 01:18 PM, Tim Peters wrote:
[Larry Hastings ]
...
Yet CPython's memory consumption continues to grow. By the time a current
"trunk" build of CPython reaches the REPL prompt it's already allocated 16
arenas.
I'd be surprised if that's true ;-) T
It's time to start planning the next 3.5 release, 3.5.4. Note that this
will be the last 3.5 "bugfix" release; after 3.5.4, the 3.5 branch will
only be open for security fixes. 3.5.4 will also be the last release of
3.5 with binary installers.
I propose to tag and release 3.5.4 on these d
On 06/22/2017 01:04 AM, Victor Stinner wrote:
About the cipher list in ssl, the change itself is simple but it's to
blacklist DES and 3DES since it has been proved that these ciphers are
really too weak nowadays:
http://python-security.readthedocs.io/vuln/cve-2016-2183_sweet32_attack_des_3des
On 06/23/2017 01:55 AM, Victor Stinner wrote:
Larry: would you be ok to turn this protection off on the 3.4 branch?
Or would you feel more confortable if only a few people would be
allowed to push to the 3.4 branch, so add me a whitelist group or
something like that?
Actually I kind of like the
On 06/21/2017 07:58 PM, Larry Hastings wrote:
If you have any feedback / concerns about this schedule, or if you
think it's important that I release 3.4.7 with these minor changes,
please reply here. If I don't hear anything back in a day or two I'll
go ahead and make th
One minor but ongoing problem we've had in CPython core development has
been the mess of updating Misc/NEWS. Day-to-day developers may have a
conflict if they lose a push race, which means a little editing. You'll
have a similar, if slightly worse, problem when cherry-picking a fix
between
On 06/24/2017 01:53 AM, Antoine Pitrou wrote:
Would you like to make it 3.5-compatible? 3.6 is quite young and not
all systems have it (e.g. Ubuntu 16.04, which many people use, has 3.5).
Well, tbh I think that's a bit silly. First of all, it shouldn't be
installed in your system-wide python
On 06/23/2017 10:55 PM, Nick Coghlan wrote:
Aye, towncrier and OpenStack's reno were the two main alternatives we
looked at in addition to Larry's offer of creating a tool specifically
for CPython: https://github.com/python/core-workflow/issues/6
Fun fact: all three tools started at about the s
On 06/23/2017 11:25 PM, Serhiy Storchaka wrote:
I have installed it, but how to use it?
$ python3 -m pip install --user blurb
Collecting blurb
Using cached blurb-1.0-py3-none-any.whl
Installing collected packages: blurb
Successfully installed blurb-1.0
$ python3 -m blurb
/usr/bin/python3: No
On 06/24/2017 09:40 AM, Terry Reedy wrote:
On 6/23/2017 11:24 PM, Larry Hastings wrote:
> You can install blurb from pip:
>
> % pip3.6 install blurb
This does not seem to work right. On Windows:
C:\Users\Terry>py -3 -m pip install blurb
Collecting blurb
Downloading blurb-
On 06/24/2017 10:21 AM, Antoine Pitrou wrote:
One thing you didn't mention: is the switch on all branches or only
master?
All active branches: 2.7 3.3 3.4 3.5 3.6 master
You should see a Misc/NEWS.d directory on each of those with an
up-to-date clone.
//arry/
__
On 06/24/2017 10:30 AM, Terry Reedy wrote:
Solution: name the file blurb.py and put it in site-packages. This is
standard and what is done by all other pip-installs that I have run.
Put a copy in /Scripts if you want, but that is really optional and
only sometimes effective.
Brett redid th
On 06/24/2017 06:56 PM, Terry Reedy wrote:
And what if there isn't? There are sometimes good reasons to have
multiple patches on an issue, whereas an issue usually gets only one
news item.
There's nothing about blurb--or anything else in the workflow IIUC--that
says you can't have multiple
On 06/24/2017 09:14 PM, Serhiy Storchaka wrote:
Not only core developers make PRs for CPython. Since all non-trivial
changes need to be mentioned in Misc/NEWS, blurb becomes a required
tool for all committers.
Well, no. *Writing blurb-compatible files* becomes a required step for
all committ
On 06/25/2017 01:33 AM, Antoine Pitrou wrote:
On Sat, 24 Jun 2017 21:37:46 -0700
Larry Hastings wrote:
Well, no. *Writing blurb-compatible files* becomes a required step for
all committers. And blurb makes that easy. But it's pretty easy to
write them by hand; that's why we p
On 06/25/2017 10:02 AM, Nathaniel Smith wrote:
My dudes, in a previous life I helped invent distributed VCS, but I
still get confused by fiddly git BS just like everyone else.
Really? I thought Bitkeeper was out before the monotone project even
started--and TeamWare had monotone beat by mos
On 06/25/2017 11:01 AM, Nathaniel Smith wrote:
On Jun 25, 2017 10:27, "Larry Hastings" <mailto:la...@hastings.org>> wrote:
On 06/25/2017 10:02 AM, Nathaniel Smith wrote:
My dudes, in a previous life I helped invent distributed VCS, but
I still get confused by
I'm scheduled to tag and release 3.5.4rc1 next weekend. I've been
releasing 3.4 and 3.5 at the same time for the last year; this is
convenient for me as it halves the frequency with which I have to put on
the "release manager" hat.
There are currently no scheduled dates to release 3.4.7.
Just a quick reminder. I'll be tagging 3.5.4rc1 next Saturday, July 22.
3.5.4 final will be the last release of 3.5.4 that accepts bugfixes;
after that, the 3.5 branch will transition to security-fixes-only mode.
If you have bugfixes you want to ship with 3.5.4, please get them
committed i
In reply to my proposal of a few days ago, I received two +1s and no
other feedback. So I'm going to issue 3.4.7 with relatively-little notice.t
Here's the schedule for 3.4.7; it mirrors the schedule for 3.5.4.
Saturday, July 22, 2017 - tag 3.4.7 rc1
Sunday, July 23, 2017 - r
On 07/17/2017 07:25 PM, Nathaniel Smith wrote:
I think the intention is to allow users with a certain kind of
security requirement to opt in to a restricted version of the language
that doesn't support exec. This is difficult if the stdlib is calling
exec all over the place. But nobody is sug
On 07/19/2017 05:59 AM, Victor Stinner wrote:
Mercurial startup time is already 45.8x slower than Git whereas tested
Mercurial runs on Python 2.7.12. Now try to sell Python 3 to Mercurial
developers, with a startup time 2x - 3x slower...
When Matt Mackall spoke at the Python Language Summit s
On 07/21/2017 03:28 PM, Barry Warsaw wrote:
The TPI (Terrible Python Idea) I had at Pycon was some kind of (local)
memcached of imported Python modules, which would theoretically allow avoiding
loading the modules from the file system on start up.
There would be all kinds of problems with this
Release engineering for 3.5.4rc1 and 3.4.7rc1 took a lot longer than
expected, because this is the first release using "blurb", and it turned
out there was a lot of work left to do and a couple dark corners yet to
stumble over. 3.5.4rc1 and 3.4.7rc1 will be released Monday, July 24,
2017.
On behalf of the Python development community and the Python 3.4 and
Python 3.5 release teams, I'm relieved to announce the availability of
Python 3.4.7rc1 and Python 3.5.4rc1.
Python 3.4 is now in "security fixes only" mode. This is the final
stage of support for Python 3.4. Python 3.4 no
As previously requested: please take this discussion to python-ideas.
If you reply, remove python-dev from the To: and Cc: lists, and add
python-ideas instead. This speculative discussion was never appropriate
for python-dev.
//arry/
On 07/28/2017 03:11 PM, Rob Cliffe wrote:
On 28/07
On 08/07/2017 05:11 PM, Patrick Rutkowski wrote:
Does anyone have any ideas here?
My one idea: the GIL isn't initialized until you create a new thread.
//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinf
On behalf of the Python development community and the Python 3.5 release
team, I'm pleased to announce the availability of Python 3.5.4.
Python 3.5.4 is the final 3.5 release in "bug fix" mode. The Python
3.5 branch has now transitioned into "security fixes mode"; all future
improvements i
The Python 3.5 branch has now entered "security fixes only" mode. No
more bugfixes will be accepted into the 3.5 branch.
In keeping with our modern workflow, I have changed the permissions on
the 3.5 branch on Github so that only release managers can accept PRs
into the branch. Please add
On behalf of the Python development community and the Python 3.4 release
team, I'm pleased to announce the availability of Python 3.4.7.
Python 3.4 is now in "security fixes only" mode. This is the final
stage of support for Python 3.4. Python 3.4 now only receives security
fixes, not bug
Yesterday I "blurbified" the 2.7, 3.6, and master branches in CPython.
It's finally official: all* branches have now been "blurbified". This
means that Misc/NEWS is no longer present in any of CPython's active
branches. Instead, Misc/NEWS has been broken up into a zillion little
files in
I've written a PEP proposing a language change:
https://www.python.org/dev/peps/pep-0549/
The TL;DR summary: add support for property objects to modules. I've
already posted a prototype.
How's that sound?
//arry/
___
Python-Dev mailing list
(off-list)
On 10/11/21 2:09 PM, Sam Gross wrote:
The ccbench results look pretty good: about 18.1x speed-up on "pi
calculation" and 19.8x speed-up on "regular expression" with 20
threads (turbo off). The latency and throughput results look good too.
JESUS CHRIST
//arry/
___
Oops! Sorry everybody, I meant that to be off-list.
Still, I hope you at least enjoyed my enthusiasm!
/arry
On Tue, Oct 12, 2021, 12:55 Larry Hastings wrote:
>
> (off-list)
>
>
> On 10/11/21 2:09 PM, Sam Gross wrote:
>
> The ccbench results look pretty good: about
On 10/21/21 5:01 AM, Henry Fredrick Schreiner wrote:
PEP 649 was about the same as the current performance, but PEP 563 was
significantly faster, since it doesn’t instantiate or deal with
objects at all, which both the current default and PEP 563 do.
I don't understand what you're saying abou
On 10/21/21 5:42 PM, Damian Shaw wrote:
Sorry for the naive question but why doesn't "TYPE_CHECKING" work
under PEP 649?
I think I've seen others mention this but as the code object isn't
executed until inspected then if you are just using annotations for
type hints it should work fine?
Ye
; if the latter, Pydantic et al would have to
iterate over every value in an annotation to look for this special value.
As a consumer of annotations at runtime, I'd definitely prefer that they
raise NameError rather than silently substitute in this alternative value.
//arry
/
On 10/21/21 8
On 10/21/21 1:17 AM, Steven D'Aprano wrote:
On Thu, Oct 21, 2021 at 04:48:28PM -0400, Larry Hastings wrote:
In Python, if you evaluate an undefined name, Python raises a
NameError. This is so consistent I'm willing to call it a "rule".
Various folks have proposed an exc
On 10/22/21 1:45 AM, Steven D'Aprano wrote:
Any other runtime annotation tool has to support strings, otherwise the
"from __future__ import annotations" directive will have already broken
it. If the tool does type-checking, then it should support stringified
annotations. They have been a standar
On 10/26/21 5:22 PM, Bluenix wrote:
* Functions having the same signature share the same annotation tuple.
Is this true with code that have a mutable default?
[... examples deleted...]
You're confusing two disjoint concepts.
First of all, all your examples experiment with default values whi
Hey, as public mailing list mistakes go, that one's pretty mild.
//arry/
On 10/28/21 6:35 PM, Jeremiah Vivian wrote:
Sorry for the two replies, I didn't think the first one would be sent.
___
Python-Dev mailing list -- python-dev@python.org
To unsu
I guess this is part of the migration from bpo to GitHub issues? Maybe
the initial work could be done in a private repo, to cut down on the
spurious email notifications to literally everybody subscribed to
cpython? Which is a lot of people.
//arry/
On 11/29/21 2:56 PM, Barry Warsaw wrote:
PEP 563 and 649 have visible effects that even within that domain can have
important side effects. For example, PEP 563’s loss of local scope, which even
“de-stringify-ing” can’t recover. This is what we need help with.
Well, sure. If PEP 563 and 6
On 11/29/21 7:10 PM, Inada Naoki wrote:
Anyone against making a statement that "PEP 563 will never be the
default behavior"?
I think only the SC is empowered to make such a statement.
Then, we do not need to decide "PEP 563 or 649".
We can focus on whether we can replace "stock semantics +
On 1/26/22 3:02 PM, Victor Stinner wrote:
Hi,
My PEP 674 proposed to change PyDescr_TYPE() and PyDescr_NAME()
macros. This change breaks M2Crypto and mecab-python3 projects in code
generated by SWIG. I tried two solutions to prevent SWIG accessing
PyDescrObject members directly:
https://bugs.pyt
I experimented with this at the EuroPython sprints in Berlin years ago.
I was sitting next to MvL, who had an interesting observation about it.
He suggested(*) all the constants unmarshalled as part of loading a
module should be "immortal", and if we could rejigger how we allocated
them to
On 2/19/22 04:41, Antoine Pitrou wrote:
On Fri, 18 Feb 2022 14:56:10 -0700
Eric Snow wrote:
On Wed, Feb 16, 2022 at 11:06 AM Larry Hastings wrote:
He suggested(*) all the constants unmarshalled as part of loading a module should be
"immortal", and if we could rejigger how we
les enough times this could waste a
significant amount of memory), I think the former is more important.
//arry/
On 2/20/22 06:01, Antoine Pitrou wrote:
On Sat, 19 Feb 2022 12:05:22 -0500
Larry Hastings wrote:
On 2/19/22 04:41, Antoine Pitrou wrote:
On Fri, 18 Feb 2022 14:56:10 -0700
Eric Snow wrote
On 2/21/22 21:44, Larry Hastings wrote:
While I don't think it's fine to play devil's advocate,"
Oh! Please ignore the word "don't" in the above sentence. I /do/ think
it's fine to play devil's advocate.
Sheesh,
//arry/
_
On 2/21/22 22:06, Chris Angelico wrote:
On Mon, 21 Feb 2022 at 16:47, Larry Hastings wrote:
While I don't think it's fine to play devil's advocate, given the choice between "this will
help a common production use-case" (pre-fork servers) and "this could hurt
On 2/22/22 6:00 PM, Eric Snow wrote:
On Sat, Feb 19, 2022 at 12:46 AM Eric Snow wrote:
Performance
---
A naive implementation shows `a 4% slowdown`_.
Several promising mitigation strategies will be pursued in the effort
to bring it closer to performance-neutral. See the `mitigation`_
On 3/14/22 20:31, Brett Cannon wrote:
On Fri, Mar 11, 2022 at 5:17 PM Victor Stinner
wrote:
It would be great to have the list of supported platforms per
Python version!
I could see the table in PEP 11 being copied into the release PEPs.
By "release PEPs", you mean the release
This document is a loose proto-PEP for a new "forward class" / "continue
class" syntax. Keep in mind, the formatting is a mess. If I wind up
submitting it as a real PEP I'll be sure to clean it up first.
/arry
--
PEP : Forward declaration of class
Here's one alternate idea for how to implement the "forward class" syntax.
The entire point of the "forward class" statement is that it creates
the real actual class object. But what if it wasn't actually the
"real" class object? What if it was only a proxy for the real object?
In this scenar
Just a quick note from me on the proto-PEP and the two proposed
implementations. When I started exploring this approach, I didn't
suspect it'd require such sweeping changes to be feasible. Specifically,
I didn't think I was going to propose changing the fundamental mechanism
used to create
On 4/22/22 19:17, Chris Angelico wrote:
I'm unsure about the forward class. How is it different from subclassing an ABC?
They're just different objects. A subclass of an ABC is either itself
another abstract base class, which will never be instantiatable, or a
non-abstract class, which is i
On 4/22/22 19:36, Terry Reedy wrote:
On 4/22/2022 9:13 PM, Larry Hastings wrote:
forward class X()
New keywords are a nuisance. And the proposed implementation seems
too complex.
My proposed implementation seemed necessary to handle the complexity of
the problem. I would welcome a
On 4/22/22 20:58, Steven D'Aprano wrote:
On Fri, Apr 22, 2022 at 06:13:57PM -0700, Larry Hastings wrote:
This PEP proposes an additional syntax for declaring a class which splits
this work across two statements:
* The first statement is `forward class`, which declares the class and
On 4/22/22 22:03, Chris Angelico wrote:
Anyhow, [a forward-defined class object is] a class, with some special
features (notably that you can't instantiate it).
Yes. Specifically, here's my intention for "forward-defined class
objects": you can examine some generic dunder values (__name__,
On 4/22/22 23:41, Mehdi2277 wrote:
My main question for this approach is how would this work with type checkers?
It would be new syntax for Python, so type checkers would have to
understand it.
Is there any restriction that forward class's continuation must appear in same
module?
No.
On 4/23/22 00:53, Steven D'Aprano wrote:
It's a "forward-declared class object". It's the real class object, but
it hasn't been fully initialized yet, and won't be until the "continue
class" statement.
The only thing that makes it not fully initialised is that it has a bozo
bit dunder "__forwa
On 4/23/22 01:14, Steven D'Aprano wrote:
On Sat, Apr 23, 2022 at 12:46:37AM -0700, Larry Hastings wrote:
But rather than speculate further, perhaps someone who works on one of
the static type analysis checkers will join the discussion and render an
informed opinion about how easy or ha
On 4/23/22 03:10, Terry Reedy wrote:
On 4/22/2022 11:16 PM, Larry Hastings wrote:
So I still prefer "forward class".
I don't think it's as clear as "forward class"
'forward class' for an incomplete class is not at all clear to me. It
is not clear
I should have said "numpy_forward", not "numpy.forward". I changed my mind
at the last second as I was writing that email, and momentarily forgot that
when you import x.y you implicitly import x.
/arry
On Sat, Apr 23, 2022, 01:53 Larry Hastings wrote:
>
> On 4/23
On 4/23/22 06:55, Jelle Zijlstra wrote:
So to reiterate, your proposal would be to write this as:
forward class B:
pass
class A:
value: B
continue class B:
value: A
Not quite; the "forward class" statement doesn't have a colon or a class
body. This would be written as:
fo
On 4/23/22 08:57, Eric V. Smith wrote:
On 4/23/2022 9:55 AM, Jelle Zijlstra wrote:
However, it doesn't solve the problem for base classes. For example,
str is conceptually defined as `class str(Sequence["str"]):`. A
forward reference can't make `str` defined when the bases are
evaluated, be
Sorry, folks, but I've been busy the last few days--the Language Summit
is Wednesday, and I had to pack and get myself to SLC for PyCon, &c.
I'll circle back and read the messages on the existing threads
tomorrow. But for now I wanted to post "the wonderful third option" for
forward class d
On 4/25/22 23:56, Ronald Oussoren wrote:
A problem with this trick is that you don’t know how large a class
object can get because a subclass of type might add new slots. This is
currently not possible to do in Python code (non-empty ``__slots__``
in a type subclass is rejected at runtime), bu
On 4/26/22 09:31, MRAB wrote:
On 2022-04-26 06:32, Larry Hastings wrote:
Note that this spelling is also viable:
class C
I don't like that because it looks like you've just forgotten the colon.
Perhaps:
class C: ...
That's not a good idea. Every other place
FWIW, I'm in agreement. My "forward class" proposal(s) were me trying
to shine a light to find a way forward; I'm in no way adamant that we go
that direction. If we can make 649 palatable without introducing
forward declarations for classes, that's great! If in the future we
discover more
On 5/1/22 15:44, Paul Bryan wrote:
Can someone state what's currently unpalatable about 649? It seemed to
address the forward-referencing issues, certainly all of the cases I
was expecting to encounter.
Carl's talk was excellent here; it would be lovely if he would chime in
and reply. Here
Howdy howdy. Here's what I'm thinking for the next release of 3.5.
This week I'm going to merge / reject all the outstanding PRs for 3.5,
then cut rc1 at the Python Core Dev sprints next week, either Monday
(2019/9/9) or Tuesday (2019/9/10). This isn't a lot of notice, but
things have slow
On behalf of the Python development community, I'm chuffed to announce
the availability of Python 3.5.8rc1.
Python 3.5 is in "security fixes only" mode. This new version only
contains security fixes, not conventional bug fixes, and it is a
source-only release.
You can find Python 3.5.8rc1
in a fix, or we need to downgrade
the issue from Release Blocker.
As I mention on the issue, depending on the complexity of the fix for
this issue (if we go that route) I may do another rc before final.
In a holding pattern,
//arry/
On 9/1/19 11:53 AM, Larry Hastings wrote:
Howdy
On behalf of the Python development community, I'm relieved to announce
the availability of Python 3.5.8rc2. It's been a month after Python
3.5.8rc1, and since then we've added a small amount of new code to fix
an API-level regression in http client, updated expat to 2.2.8, and
upgraded the
On behalf of the Python development community, I'm relieved to announce
the availability of Python 3.5.8.
Python 3.5 is in "security fixes only" mode. This new version only
contains security fixes, not conventional bug fixes, and it is a
source-only release.
You can find Python 3.5.8 here
Due to awkward CDN caching, some users who downloaded the source code
tarballs of Python 3.5.8 got a preliminary version instead of the final
version. As best as we can tell, this only affects the .xz release;
there are no known instances of users downloading an incorrect version
of the .tgz
On behalf of the Python development community, I'm slightly chagrined to
announce the availability of Python 3.5.9. There were no new changes in
version 3.5.9; 3.5.9 was released only because of a CDN caching problem,
which resulted in some users downloading a prerelease version of the
3.5.8
On 11/12/19 2:03 PM, Victor Stinner wrote:
Hi,
Are you ok to modify internal C functions to pass explicitly tstate?
I did exactly that in the Gilectomy prototype. Pulling it out of TLS
was too slow, and storing it in a global wouldn't work with multiple
actually-concurrent threads.
//ar
On 11/13/19 5:52 AM, Victor Stinner wrote:
Le mer. 13 nov. 2019 à 14:28, Larry Hastings a écrit :
I did exactly that in the Gilectomy prototype. Pulling it out of TLS was too
slow,
What do you mean? Getting tstate from a TLS was a performance
bottleneck by itself? Reading a TLS variable
My random Googling turned up a new hash function tonight:
"HighwayHash". It's a keyed hash function like the SipHash we now use
for hashing strings / bytes / etc for our lovely dicts.
Key points:
* Apache 2 license
* Can use SIMD
* "5x faster than SipHash"
I think they mean 5x faster th
As of 3.7, dict objects are guaranteed to maintain insertion order. But
set objects make no such guarantee, and AFAIK in practice they don't
maintain insertion order either. Should they?
I do have a use case for this. In one project I maintain a "ready" list
of jobs; I need to iterate over
they maintained insertion
order? Are there operations on set objects that would no longer be
possible?
//arry/
On 12/15/19 6:58 PM, Tim Peters wrote:
[Larry Hastings ]
As of 3.7, dict objects are guaranteed to maintain insertion order. But set
objects make no such guarantee, and AFAIK in pra
On 12/15/19 8:25 PM, Raymond Hettinger wrote:
On Dec 15, 2019, at 6:48 PM, Larry Hastings wrote:
As of 3.7, dict objects are guaranteed to maintain insertion order. But set
objects make no such guarantee, and AFAIK in practice they don't maintain
insertion order either. Should the
On 12/16/19 10:59 AM, Tim Peters wrote:
BTW, what should
{1, 2} | {3, 4, 5, 6, 7}
return as ordered sets? Beats me.;
The obvious answer is {1, 2, 3, 4, 5, 6, 7}. Which is the result I got
in Python 3.8 just now ;-) But that's just a side-effect of how hashing
numbers works, the impl
On 12/16/19 6:30 PM, Tim Peters wrote:
If it's desired that "insertion order" be consistent across runs,
platforms, and releases, then what "insertion order" _means_ needs to
be rigorously defined & specified for all set operations. This was
comparatively trivial for dicts, because there are, e
On 12/16/19 7:43 PM, Tim Peters wrote:
[Petr Viktorin ]
Here's one (very simplified and maybe biased) view of the history of dicts:
* 2.x: Dicts are unordered, please don't rely on the order.
* 3.3: Dict iteration order is now randomized. We told you not to rely
on it!
* 3.6: We now use an opt
On 12/16/19 10:32 PM, Tim Peters wrote:
[Larry]
Python is the language where speed, correctness, and readability trump
performance every time.
Speed trumping performance didn't make any sense ;-)
Sorry, that /was/ super unclear! I honestly meant speed of /development/.
D'oh,
//arry/
__
On 12/17/19 2:02 AM, Steven D'Aprano wrote:
Without being facetious[1] if you don't care about performance, you
don't need a set, you could use a list.
Lists don't enforce uniqueness. Apart from that a list would probably
work fine for my needs; in my admittedly-modest workloads I would
pr
(mixing together messages in the thread, sorry threaded-view readers)
On 12/19/19 3:15 PM, Tim Peters wrote:
[Nick]
I took Larry's request a slightly different way:
[...]
Only Larry can answer whether that would meet his perceived need. My
_guess_ is that he wouldn't know OrderedSet existed,
On 12/23/19 8:09 PM, Kyle Stanley wrote:
Chris Angelico wrote:
> I think this is an artifact of Python not having an empty set literal.
> [snip]
> When both use the constructor call or both use a literal, the
> difference is far smaller. I'd call this one a wash.
Ah, good catch. I hadn't consi
uot; to it.
Here is the original description of my problem, from the original email
in this thread. I considered this an adequate explanation of my problem
at the time.
On 12/15/19 6:48 PM, Larry Hastings wrote:
I do have a use case for this. In one project I maintain a "ready"
list o
On 12/28/19 6:24 PM, Tim Peters wrote:
[Larry]
Here is the original description of my problem, from the original email in
this thread. I considered this an adequate explanation of my problem
at the time.
I do have a use case for this. In one project I maintain a "ready" list of
jobs; I need t
On 2/3/20 3:07 PM, Sebastian Berg wrote:
That would mean adding `operator.equivalent(a, b) -> bool` which would
allow float to override the result and let
`operator.equivalent_value(float("NaN"), float("NaN))` return True;
luckily very few types would actually override the operation.
You misund
On 4/20/20 8:06 AM, Benjamin Peterson wrote:
I'm eudaemonic to announce the immediate availability of Python 2.7.18. [...]
Over all those years, CPython's core developers and contributors sedulously
applied bug fixes to the 2.7 branch, no small task as the Python 2 and 3
branches diverged.
Gosh how time flies. 3.5 is nearing the end of its security maintenance
period, and as such the patches have slowed down. But we got a couple
recently--all having to do with web technologies--so it's probably time
to make another release. I propose to release rc1 in two weeks, and
final tw
Oh, good point! I forgot about that and was, uh, looking in the wrong
place. Yes, the next version will be 3.5.10.
//arry/
On 6/14/20 2:30 PM, John Thorvald Wodder II wrote:
3.5.9 was already released back in November. Yes, it's (almost) the same code
as 3.5.8, but its version number (
601 - 700 of 882 matches
Mail list logo