n fixing actual problems.
--
*Q::Drone's Co-Founder and Co-CEO*
*Hervé "Kyle" MUTOMBO*
*Envoyé depuis le web.*
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.pyt
Brett Cannon wrote:
> I agree with Raymond that if the calendar module was following the leading
> underscore practice (which we should probably encourage all new modules to
> follow for
> consistency going forward) then I think the module should be updated to keep
> the practice
> going.
> -Bre
Serhiy Storchaka wrote:
> Either we establish the rule that all non-public names must be
> underscored, and do mass renaming through the whole stdlib. Or allow to
> use non-underscored names for internal things and leave the sources in
Personally, I would be the most in favor of doing a mass re
Serhiy Storchaka wrote:
> Thank you. The majority of the code uses needle on the right. There are
> just 6 places where it is on the left, and the half of them look
> copy-pasted, and in one place the C code differs from the corresponding
> Python implementation. There is an order more places wh
Brett Cannon wrote:
> Same would happen with a rename where people's code suddenly broke. We
> don't do renames on purpose without a proper deprecation cycle and doing that
> en-mass would be extremely disruptive.
Good point, this would probably have to be a gradual change if it did happen,
rathe
Upon further consideration and reading your response, I'm starting to think
that the proposal to perform a mass renaming across stdlib might have been a
bit too drastic, even if it was done over a longer period of time. Thanks for
the detailed explanation of the costs, that significantly improve
Barry Warsaw wrote:
> This leads to the second problem, which is that it’s too easy for the __all__
> to get
> out of sync with the module’s contents. Often a function or class is renamed,
> removed, or
> added without the __all__ being updated.
IMO, this seems to be the best part of the @publi
Steve Dower wrote:
> So I apologise for mentioning that people care about import performance.
> Let's ignore them/that issue for now and worry instead about making sure
> people (including us!) know what the canonical reference for
> public/internal is.
Good point, the discussion about __all__,
I find myself in agreement with Inada (https://bugs.python.org/issue12445), in
that comparing the values view between two dictionaries by itself would not be
particularly useful for enough people to warrant implementing the comparison.
In most situations when using the data structure, it is only
Serhiy Storchaka wrote:
> Is there any precedence of raising an exception in the equality comparison?
> Does 3 == "3" returning False make more sense to you?
Personally, I don't find ``3 == "3"`` to be an equivalent comparison to
``d0.values() == d1.values()``. Generally, it makes sense when comp
Eric V. Smith wrote:
>That makes things worse. Now the comparison is always true in a boolean
>context. And presumably you'd want __ne__ to also return >NotImplemented,
>so then both __eq__ and __ne__ would be true, since >bool(NotImplemented)
>is True.
Eric V Smith wrote:
7/25/2019 6:00 AM, Er
Brett Cannon wrote:
> You're correct that I misspoke, but I personally still think a doc change
> is the best solution.
I would agree that a doc change should occur if it is decided that the current
behavior is appropriate, but I would like to mention that in the current
[documentation for
`obj
Serhiy Storchaka wrote:
> Actually, the == operator cannot return NotImplemented.
Thanks for the clarification. What is the reason for this limitation and is it
only possible for the `==` operator to return one of `None`, `False`, or
`True`? It seems like it would be useful for it to be able to
Terry Reedy wrote:
> Given the absence of a consensus on when values() views should be
> considered equal, I strongly agree. I strongly oppose raising an exception.
I am with you regarding the strong opposition regarding the raising of an
exception. I don't think that the `==` operator should r
> I want a real-world application which requires it.
> Without a strong use case, I think the discussion is just wasting time.
I would have to agree. Initially I was in support of changing the behavior, but
upon reading the responses of several core developers and further
consideration, the most
> Essentially those "easy" issues aren't so easy,
> and we're starting over.
Is "easy" still going to be used for intermediate level issues or
will it be no longer used? Apologies if this was already discussed
in the initial thread, I don't have access to core-mentorship.
_
Not sure if this would be the right place to mention it,
but the side menu url/button "Easy issues" in bpo
should probably be renamed to "Newcomer friendly"
and the "dispname" property in the url could also be
similarly updated. This could be done by changing the
url from:
[current](https://bugs.
Clarification: The url change is only for updating the
"dispname" property, which is shown at the top of
the page. It would change the header from:
"List of issues - Easy issues"
=>
"List of issues - Newcomer friendly"
Also, I realized that I accidentally included the "nosy"
property at the end,
Stephen J. Turnbull wrote:
> In general, it's not obvious to me how much extra burden we want to
> put on triagers. This tag has basically the same problems that "easy"
> does, except that it deters experienced developers from snatching up
> easy issues. I think we should see how this works out i
+1 to remove support for Solaris going forward. 4 years is plenty of time
to wait for someone to volunteer to maintain it, IMO. So my preference
would be for option 3 to remove it now, but I wouldn't be opposed to option
2 either w/ deprecating support and waiting a couple versions to remove it.
I'
I can't speak for all of the members of the upcoming documentation WG, but
as someone that will be on it (based on our discussions at the recent core
dev sprint), my personal vote would be for keeping it as a comprehensive
guide for beginners of Python. Detailed enough that it covers the
fundamenta
On Sun, Nov 8, 2020 at 8:17 PM Inada Naoki wrote:
> OK. Since checking all mails in the long thread is tedious job, I will
> pick some up and leave a comment in the b.p.o.
>
Personally, I think that just linking to the python-dev thread in bpo
(and/or PR) is adequate for most cases, especially i
Rather than trying to specifically transform the existing tutorial into a
guide exclusively aimed at beginners, I think that we should use the
guideline of: "Is this useful information in 95% of real-world use cases or
does it have a strong niche purpose that will be useful at *some *point for
sig
On Sat, Nov 14, 2020 at 7:54 AM Nick Coghlan wrote:
> On Sat, 14 Nov 2020 at 09:51, Greg Ewing
> wrote:
> >
> > On 14/11/20 7:45 am, Brandt Bucher wrote:
> > > with (using your own syntactic flavor):
> > > ```
> > > case >first, *>middle, >last:
> > > rebuilt = first, *middle, last
> > > ca
On Sun, Nov 15, 2020 at 1:56 AM Chris Angelico wrote:
> On Sun, Nov 15, 2020 at 4:28 PM Kyle Stanley wrote:
> >
> > FWIW, I'd like to add my +1 to usage of "as" for spelling class capture
> patterns. This is by far the clearest and easiest to read form I'
Thanks for bringing attention to this, Victor, and to Ken Jin (GH:
Fidget-Spinner) for the PR. I've just completed reviewing and merging the
PR, so hopefully anyone affected will now have a more clear idea of how to
migrate their asyncio code to 3.10. Having the porting method explicitly
documented
On Jan 20, 2021 at 9:51 PM Chros Jerdonek wrote:
> Is there / would it make sense to have a section analogous to "Porting to
> Python X" that covers "Make All DeprecationWarnings Go Away in X"? If we
> had such a section, the "Porting to" section could be constructed by
> copying the relevant bit
have overcome past struggles*
.
--
--Kyle R. Stanley, Python Core Developer (what is a core dev?
<https://devguide.python.org/coredev/>)
*Pronouns: they/them **(why is my pronoun here?*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-ch
With Loving Regards,
--
--Kyle R. Stanley, Python Core Developer (what is a core dev?
<https://devguide.python.org/coredev/>)
*Pronouns: they/them **(why is my pronoun here?*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c
As someone who's had to make use of the pattern `_sentinel = object()` a
few times within stdlib code, I'd like to give a strong +1 for the proposal
to add a new `sentinel()` function. This is much more intuitive, easier to
look up, etc. From my experience, it's a common enough pattern to be well
On Sun, Jun 6, 2021 at 7:09 PM Dan Stromberg wrote:
> I've got a comparison of sort algorithms in both Cython and Pure Python
> (your choice) at:
> https://stromberg.dnsalias.org/~strombrg/sort-comparison/
> ...including a version of timsort that is in Cython or Pure Python.
>
Thanks for sharing
bsolute 100%
certainty that no regressions or future unexpected issues will occur as a
result of the change.
Also, for fun, here's a pythonized version of the quote:
“[Guido] said that I was the wisest of all the [pythonistas]. It is because
I alone, of all the [pythonistas], know that I know
s to (or be able to fix it).
Best Regards,
--
--Kyle R. Stanley, Python Core Developer (what is a core dev?
<https://devguide.python.org/coredev/>)
*Pronouns: they/them **(why is my pronoun here?*
<http://feministing.com/2015/02/03/how-us
I can agree with the general premise of what Antoine is saying, but to me
even as a non-participant, the following quote from the thread Brett linked
seems a clear CoC violation:
I repeat, even the worst AI will understand from the context what I meant.
> But let me do a very rude example:
>
> Wha
Thanks for the fix! This could have caused some serious issues, so glad we
were able to address it ahead of time.
On Mon, Sep 13, 2021 at 5:06 AM Victor Stinner wrote:
> Hi,
>
> A bug has been identified and *fixed* in the OAuth-based
> authentication code used on the Python bug tracker bugs.pyt
I'd suggest both: briefer, easier to read write up for average user in
docs, more details/semantics in informational PEP. Thanks for working on
this, Petr!
On Tue, Nov 2, 2021 at 2:07 PM David Mertz, Ph.D.
wrote:
> This is an amazing document, Petr. Really great work!
>
> I think I agree with Ma
0_o color me impressed, I did not think that would be legal syntax. Would
be interesting to include in a textbook, if for nothing else other than to
academically demonstrate that it is possible, as I suspect many are not
aware.
--
--Kyle R. Stanley, Python Core Developer (what is a core
t is great to see that the incumbents desire to have a wide pool of
applicants for the longevity of Python; rather than being on the SC
indefinitely.
Best Regards,
--
--Kyle R. Stanley, Python Core Developer (what is a core dev?
<https://devguide.python.org/coredev/>)
*Pronouns: they/them *
ate, rather than 2 versions for all. Module
removal certainly takes more effort to adjust in code vs simple function
name change with 1:1 replacement.
--
--Kyle R. Stanley, Python Core Developer (what is a core dev?
<https://devguide.python.org/coredev/>)
*Pronouns: they/them **(why is my pro
FWIW that seems like a reasonable approach, at least to me.
On Thu, Nov 18, 2021, 5:29 PM Guido van Rossum wrote:
> I know PEP 646 was one of these. In our defense, we *did* notify the SC
> that there was a pending issue (
> https://github.com/python/steering-council/issues/59#issuecomment-95172
Thanks for the update! Although possibly a minor inconvenience to some, I
am certainly of the belief that our choice in language has a subtle, yet
powerful effect on our perception of the world around us, so although some
may see it as needless, I think small changes such as "master" to "main"
are
May he rest in peace, I can't even fathom the impact PIL has had on Python
over the years.
On Fri, Dec 10, 2021 at 3:20 PM Guido van Rossum wrote:
> A former core dev who works at Google just passed the news that Fredrik
> Lundh (also known as Effbot) has died.
>
> Fredrik was an early Python co
Barry Warsaw wrote:
> The PEP doesn’t really go into the rationale for why a new exception is being
> defined,
> and in the issue I’ve argued that we should just raise SyntaxError in those
> cases. To me,
> “TargetScopeError” is pretty obscure and doesn’t give users an obvious clue
> as to what
Nick Coghlan wrote:
> It's not an unwritten rule, as it already has its own subsection in
> PEP 8:
> https://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces
> The main question in this thread is what to do about standard library
> modules that were written before those documented
Kyle Stanley wrote:
> It would also be appropriate to provide any user attempting to import
> a module that is going to be prepended with an underscore with
> warnings, and at least a couple of versions to update their code.
Clarification: When I mentioned prepending a module with an
u
Recently, on Discuss, I created a new topic:
https://discuss.python.org/t/should-news-entries-contain-documentation-links/2127
However, many may not have the time to read the full post or don’t regularly
check the core workflow category on Discuss, so I'll provide a shortened
version here.
Dur
eST features. But if that's also an
issue, a more explicit reST hyper link could be provided with: \`Link text <
http://target>\`_. However, direct links are probably the most likely to
become deprecated or lead to dead ends, so the other options would be more
preferable for less maintenanc
als are to
further improve the documentation and other resources for newer users of
the language.
Thanks,
Kyle Stanley
On Tue, Aug 13, 2019 at 3:58 AM Ned Deily wrote:
> On Aug 13, 2019, at 00:20, Kyle Stanley wrote:
> > On Tue, Aug 13, 2019 at 2:41 AM Mariatta
> wrote:
>
> There seems to be some sentiment that it's perfectly fine to exclusively
use plaintext in every news entry.
Oops, that third sentence was a typo, I didn't intend to repeat myself
there.
On Tue, Aug 13, 2019 at 6:31 PM Kyle Stanley wrote:
> > Note that there is an open
ew, so in general
they would end up being less time consuming anyways.
Also, thanks for the tips! I'll definitely look into helping with this.
Thanks,
Kyle Stanley
On Tue, Aug 13, 2019 at 7:30 PM Ned Deily wrote:
> On Aug 13, 2019, at 15:31, Kyle Stanley wrote:
> > > In
e
future as well.
Thanks,
Kyle Stanley
On Tue, Aug 13, 2019 at 11:30 PM Wes Turner wrote:
> Could a bot be written to suggest upgraded markup for Misc/NEWS entries as
> a PR?
>
> Most e.g. class, method, and function references probably need ReST markup
> AND a more specific fu
provide instructions on when it's
appropriate to utilize.
Thanks,
Kyle Stanley
On Wed, Aug 14, 2019 at 3:31 AM Terry Reedy wrote:
> On 8/13/2019 6:31 PM, Kyle Stanley wrote:
>
> > The primary purpose of me creating this topic was because there seems to
> > be some sentimen
ing/#what-s-new-and-news-entries
>
> On Thu, Aug 15, 2019 at 3:39 AM Kyle Stanley wrote:
>
>> > Also, for IDLE, news entries to idlelib/NEWS.txt
>> > where markup, as opposed to unicode, is noise.
>>
>> Interesting, I actually wasn't aware of the dist
ers.
Once I open the PR for it in the devguide, I'll be sure to send a message
in this topic which includes a link to it. It would greatly benefit from
review from those who are less familiar with documentation. That will help
to ensure the section is easy to understand for the intended
appreciate feedback from contributors and developers less
experienced with documentation to ensure that the section is easy to
understand for the intended target audience. Also, review from those who
are experienced with documentation and news entries is needed to ensure it
is as accurate as possible.
Tha
> the talk I gave last month at PyOhio (
https://www.pyohio.org/2019/presentations/137)
> Right now I have the slides up as a view-only share in my Google Drive (
bit.ly/bskinn-pyohio2019-intersphinx). Perhaps it would be useful to link
to them? Or, to host a PDF someplace more permanent, and link
eated here:
https://github.com/python/cpython/pull/14976. Even if it hadn't been
recreated, I think it would still be a good example as of a stale PR, since
it had changes requested for over a year with no response from the author
since then.
Regards,
Kyle Stanley
On Thu, Aug 22, 2019 at 2:2
Kyle Stanley wrote:
> as it has been awaiting changes since Feb 20, 2018
Clarification: The author addressed the suggested changes on Feb 19, 2017
but had made no response after Brett added the ``awaiting changes`` label.
As a related question, would it be okay for triagers to manually add
Mariatta wrote:
> It still requires earning trust from at least one core developer who will
approve their request, which I don't actually believe is an easy > thing to
do.
Agreed, it may be a low bar in comparison to the 66% approval required for
becoming a core developer, but it's definitely not
> That was Brett's bot for backfilling the "awaiting ..." label to PRs
created before we had any "awaiting .." label. A script was used to
> automatically determine the stage of the PR and apply appropriate label.
Ah, that makes sense. I wasn't aware that personal GitHub accounts were
previously u
> For instance, I don't think a triager should be able to edit other users'
comments or lock conversations, but I'm afraid GitHub
> doesn't provide that level of granularity (correct?).
You are correct in that GitHub does not allow customization of the
permissions, but those with the "Triage" per
Terry Jan Reedy wrote:
> "This installer also installs the multiversion py.exe launcher if doing
so would not be a downgrade. If you have admin access, we recommend
installing one py.exe for all users. See xxx for how to use py.exe.
[ ] Install py.exe for all users.
+1, Particularly on this pa
Benjamin, what are you thoughts on usage of the "needs backport to 2.7"
label? For most of the PRs I've reviewed I tend to avoid adding it myself,
but I've seen it used periodically. It seems to be used rather infrequently
(
https://github.com/python/cpython/pulls?q=is%3Apr+label%3A%22needs+backpor
> How easy would it be to search the sources and the docs for the ones
that are currently public but not documented?
Comparing the docs and .c files for functions that are not documented
would be fairly trivial, but it's very difficult to define something as
being
public if it's not documented, si
Recently, Brett updated the developer log in the devguide
(https://devguide.python.org/developers/) to fetch the names of each core
developer and the date they were given commit privileges from the private
python-committers repository.
I think it would also be quite useful to include GitHub userna
> But I will say that listing our GitHub usernames with our real names is
not required to tell who is a core developer. In GitHub's UI there are
multiple places it will tell you if a person is a member of the
repository/team
Within the GitHub UI if you're not a member of the organization, it tells
nt for a decent while before I started contributing to Python).
This would be a non-issue with a public listing of core developer real
names -> GitHub usernames that isn't dependent on bpo.
On Wed, Sep 25, 2019 at 7:12 AM Victor Stinner wrote:
> Le mer. 25 sept. 2019 à 08:24, Kyle Stanley
> Can you help with the "What's New" document?
After seeing this, I went through the whatsnew for 3.8 and found a couple
of typos and broken links (from Sphinx roles that were slightly off). I
opened a PR to fix as many as I was able to:
https://github.com/python/cpython/pull/16535. Raymond will b
> Recently, I started to experiment "./python -m test [options] -F
-j100" to attempt to reproduce some tricky race conditions: -j100
spawns 100 worker processes in parallel and -F stands for --forever
(run tests in loop and stop at the first failure).
Interesting, even as someone who has recently
> You don't need permission to support Python in a commercial IDE. It's
open source.
Adding to this, see
https://docs.python.org/3/license.html#terms-and-conditions-for-accessing-or-otherwise-using-python
for the complete licensing information on Python.
On a somewhat related note to the licensin
> Probably python-list/comp.lang.python mailing list/news group is the
best place
Since this involves a potential suggested change (adding a feature to
assign custom headers to http.server), python-ideas or the "Ideas" section
of https://discuss.python.org/ would also be appropriate.
On Sat, Oct
> This is all irrelevant if you haven't signed the CLA*.
IMO, this shouldn't be an argument against the proposed changes, as the CLA
is fairly straightforward and only takes 24-48 hours to process. Unless the
OP specifically is unable to or doesn't want to sign the CLA, it won't be a
significant c
> I agree with Nick, this is indeed big, but not impossible. If you are not
sure yet whether you will work on implementation, you can focus on
polishing the PEP text, and then if it is accepted and you will decide to
give implementation to someone else, we will find a volunteer.
Unless I'm misunde
> The number of live coroutines in a running interpreter.
Could you further elaborate on what is meant by "live coroutines"? My
guesses (roughly from most likely to least likely) would be:
1) All known coroutine objects in a state of either CORO_RUNNING or
CORO_SUSPENDED, but *not* CORO_CREATED
> BTW, I think 2to3 can help to move from 2&3 code to 3-only code.
> Instead, we can do:
> * Don't recommend u-prefix except in Python 2&3 code.
> * Provide a tool to remove the u-prefix.
+1, this seems like the smoothest way of handling it and has very minimal
impact on users. In 5+ years from
Steve Dower wrote:
> As a related aside, I've been getting GitHub Actions support together
> (which I started at the sprints).
Would adding support for GitHub Actions make it easier/faster to
temporarily disable and re-enable specific CI services when they're having
external issues? IIUC, that see
Victor Stinner wrote:
> Isn't it already the current unwritten deprecation process?
Personally, I don't think we should rely on an unwritten process for
something as important and potentially breaking as a deprecation process.
Regardless of the outcome of this discussion, I think we should try to
han closing+reopening the
PR. Restarting the checks is typically a last resort since intermittent
regression test failures are a concern, but it's highly useful when the
failure is occurring due to external factors (such as a recently merged PR
or issues with the CI service itself).
On Fri
> (b) Why limit coroutines? It's just another Python object and has no
operating resources associated with it. Perhaps your definition of
coroutine is different, and you are thinking of OS threads?
This was my primary concern with the proposed PEP. At the moment, it's
rather trivial to create one
, 2019 at 10:17 PM Khazhismel Kumykov wrote:
>
>
> On Mon, Dec 9, 2019, 18:48 Kyle Stanley wrote:
>
>> > (b) Why limit coroutines? It's just another Python object and has no
>> operating resources associated with it. Perhaps your definition of
>> coroutine i
> I also would suggest for PEP 611 that any limits are discoverable (maybe
in sys) so it can be used by other implementations like Jython.
I agree, I think that sys would likely be the most reasonable place to read
these limits from. Also, it seems like a good location for setting of the
limits, i
Chris Angelico wrote:
> We have people who believe that a bit
> mask will slow things down, others who claim that improved cache
> locality will speed things up, and Mark asks us to please justify our
> objections with numbers. But surely it's up to Mark to show numbers
> first?
+1. While it would
7;re not (reasonably) configurable by most users, I would
consider that to further reinforce my previous statement that we should
have some form of concrete evidence; to prove that imposing the limits will
provide tangible benefits to the vast majority of Python users.
On Tue, Dec 10, 2019 at 4:45 AM S
With the removal of the coroutine limit, I think that PEP 611 will be a lot
easier to consider. Personally, I've gone from -1 to +0. But, with the
class limit also being rather controversial, I think the PEP would benefit
significantly from backing that up with some form of analysis on memory
usage
ith each
FD, but I believe this can be limited through the FD option F_SETPIPE_SZ (
https://linux.die.net/man/2/fcntl).
Note: I was unable to find a credible source on the minimum memory usage
per additional FD, so clarification on that would be appreciated.
On Wed, Dec 11, 2019 at
ill worthwhile to write. I suspect that the topic of
"coroutine object limits" is likely to come up again in the future.
On Wed, Dec 11, 2019 at 4:46 PM Antoine Pitrou wrote:
> On Mon, 9 Dec 2019 21:42:36 -0500
> Kyle Stanley wrote:
>
> > > (b) Why limit corout
Victor Stinner wrote:
> What is the issue? Can someone please open a bug report at
https://bugs.python.org/ so I can try to investigate?
>From my understanding, it looks to be pyenv related and not something we
can fix on our end, at least based on the build logs:
https://travis-ci.org/python/cpyt
that keeps the breakage from landing on
> master?
>
> On Thu, Dec 12, 2019 at 5:46 PM Kyle Stanley wrote:
>
>> Victor Stinner wrote:
>> > What is the issue? Can someone please open a bug report at
>> https://bugs.python.org/ so I can try to investigate?
>>
>>
Serhiy Storchaka wrote:
> Forbids calling str() without object if encoding or errors are
> specified. It is very unlikely that this can break a real code, so I
> propose to make it an error without a deprecation period.
+1, I suspect that nobody would intentionally pass an argument to the
encoding
as UTF-8, assume the user meant
str(bytes_obj, encoding='utf-8')
Personally, I'm more in favor of (1) since it's much more explicit and
obvious, but I think (2) would at least be more useful than the current
behavior.
On Sun, Dec 15, 2019 at 8:13 PM Chris Angelico wrote:
> On Mon,
pect via string conversion.
Thanks for the insight.
On Mon, Dec 16, 2019 at 3:43 AM Eric V. Smith wrote:
> On 12/16/2019 3:05 AM, Kyle Stanley wrote:
>
> Chris Angelico wrote:
> > ANY object can be passed to str() in order to get some sort of valid
> > printable form. The awkw
haka wrote:
> You can get an error here if you run Python with -bb. This is a
> temporary option to catch common errors of porting from Python 2.
Huh, interesting.
On Mon, Dec 16, 2019 at 3:59 AM Serhiy Storchaka
wrote:
> 16.12.19 02:55, Kyle Stanley пише:
> > I'd much pref
Inada Naoki wrote:
> If we find it broke some software, we can step back to regular
> deprecation workflow.
> Python 3.9 is still far from beta yet. That's why I'm +1 on these
proposals.
IMO, since this would be changing a builtin function, we should at least
use a version+2 deprecation cycle (in
Kyle Stanley wrote:
> or making *object* a positional only argument.
Typo: I meant "positional only parameter", not "argument".
On Mon, Dec 16, 2019 at 4:39 AM Kyle Stanley wrote:
>
> Inada Naoki wrote:
> > If we find it broke some software, we can step back
Larry Hastings wrote:
> a hypothetical collections.OrderedSet would probably work just fine.
I'm also in agreement with adding a collections.OrderedSet. There certainly
seems to be a practical use case for a Set that preserves insertion order,
but with significant push back to modifying the existi
the "Add" ones. This
should provide a decent general idea though.
On Mon, Dec 23, 2019 at 8:12 PM Guido van Rossum wrote:
> To begin with, please compare performance of dict-with-None-values to that
> of a set, for operations that can be expressed by both (e.g. both have
> up
10.22558353268
Some more in-depth comparisons might be required for addition of single
items to the containers. I might experiment further with this at some point
in the next week or so, likely with implementing proper tests that omit the
time to initialize the container.
On Mon, De
Tim Peters wrote:
> Sorry! A previous attempt to reply got sent before I typed anything :-(
No worries, I only saw the link in the footer to the PSF CoC, and I was
mildly concerned for a moment. My first thought was "Oh no, what did I
do?". Thanks for clearing that up (:
> The collision resoluti
> The only `OrderedSet` use I have seen in the wild is
https://github.com/python-hyper/uritemplate/search?q=orderedset&unscoped_q=orderedset
.
A more generalized Python code search across GitHub of "orderedset" returns
~500k results: https://github.com/search?l=Python&q=orderedset&type=Code .
Of
On the attendance application, there is currently an incorrect link to the
informational page for the Language Summit: "
https://us.pycon.org/2020/events/language-summit/";.
Either the link could be changed to "
https://us.pycon.org/2020/events/languagesummit/"; or "
https://us.pycon.org/2020/even
1 - 100 of 138 matches
Mail list logo
