On May 10, 2014, at 2:54 PM, Antoine Pitrou wrote:
> It's not about being bright or not, it's about being
> *willing* to eat walls of text. However pleasant it may be for some
> people to *write* documentation, for most readers (and especially
> non-native English readers, who read more slowly a
On May 10, 2014, at 4:15 PM, Stefan Behnel wrote:
> Total +1 on keeping these little bits around.
Since all of you want a warning, I'll add one back
but with improved wording.
I'm not all at comfortable with the wording of the second sentence.
I was the author of the SystemRandom() class and I
If there is anyone here with an interest in web-spiders,
it would be nice if someone else could take a look at
http://bugs.python.org/issue21469
which addresses the risk of false positives with the robots.txt parser.
Raymond
___
Python-Dev maili
On May 11, 2014, at 6:57 AM, Steve Dower wrote:
> Thanks.
>
> For those who missed the earlier discussions, Martin v. Löwis has handed over
> responsibility for the Windows installers. It sounds like Brett Cannon and I
> are both in a position to build 2.7 right now, and I hope to simplify th
and 90755 by Raymond Hettinger 8 hours
> ago. From earliest to lastest:
>
> c67a19e11a71
> 7c5f1b200a24
> 35ea333f43bd
> 31211947387b
> 854fd62f
>
> If there was any notice on the Committer's list about not making commits, I
> did not get it. In fact, I do
On May 27, 2014, at 1:58 AM, Serhiy Storchaka wrote:
> Perhaps it is worth to add simple comment explaining why this is not
> equivalent to just list(zip(it, range(n))). Otherwise it can be
> unintentionally "optimized" in future.
FWIW, that is covered by the test cases.
If you substitute lis
On May 30, 2014, at 8:32 PM, Terry Reedy wrote:
> B. Lets assuming that turtle.py is, at least to some degree, fair game for
> fixes and enhancements. PSF Python PyLadies (Jessica Keller, Lynn Root) are
> participating in the 2014 GNOME Outreach Program for Women (OPW)
> https://wiki.python.o
On Jun 1, 2014, at 9:17 AM, Antoine Pitrou wrote:
> Le 01/06/2014 10:11, Steven D'Aprano a écrit :
>>
>> My feeling is that the CPython standard library should be written for
>> CPython, that is, it should stick to the current naive implementation of
>> median, and if PyPy wants to speed the fu
On Jun 7, 2014, at 6:25 AM, R. David Murray wrote:
>> I guess I could duck-type it based on the _fields attribute but that
>> feels implicit and fragile.
>>
>> What do you guys suggest?
>
> I seem to remember a previous discussion that concluded that duck typing
> based on _fields was the way
On Jun 8, 2014, at 6:42 PM, Nick Coghlan wrote:
> >> I seem to remember a previous discussion that concluded that duck typing
> >> based on _fields was the way to go. (It's a public API, despite the _,
> >> due to name-tuple's attribute namespacing issues.)
> >
> >
> > Yes. That is the recomme
On Jun 9, 2014, at 4:40 AM, Antoine Pitrou wrote:
> Instead of an ABC, why not a simple is_namedtuple() function?
That would work.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubsc
On Jun 20, 2014, at 10:30 AM, Ezio Melotti wrote:
> I added a new "stats" page to the bug tracker:
> http://bugs.python.org/issue?@template=stats
> The page can be reached from the sidebar of the bug tracker: Summaries ->
> Stats
> The data are updated once a week, together with the Summary of
> On Jul 25, 2018, at 8:23 PM, INADA Naoki wrote:
>
> On Thu, Jul 26, 2018 at 12:04 PM Zhao Lee wrote:
>>
>>
>> Since Python 3.7，dicts remember the order that items were inserted, so any
>> plans to combine collections.OrderedDict with dict?
>> https://docs.python.org/3/library/collections.
> On Jul 26, 2018, at 10:23 AM, Terry Reedy wrote:
>
> On python-idea, Miro Hrončok asked today whether we can change the
> OrderedDict repr from, for instance,
>
> OrderedDict([('a', '1'), ('b', '2')]) # to
> OrderedDict({'a': '1', 'b': '2'})
>
> I am not sure what our repr change policy is
> On Jul 29, 2018, at 4:53 AM, Serhiy Storchaka wrote:
>
> The benefit is that it will be easier to run all C API tests at once, and
> only them, and it will be clearer what C API is covered by tests. The
> disadvantage is that you will need to run several files for testing marshal
> for ex
> On Jul 30, 2018, at 12:06 AM, Serhiy Storchaka wrote:
>
> 30.07.18 09:46, Raymond Hettinger пише:
>> I prefer the current organization that keeps the various tests together with
>> the category being tested. I almost never need to run the C API tests all
>> at
> On Sep 22, 2018, at 1:38 PM, Yury Selivanov wrote:
>
> On Sat, Sep 22, 2018 at 3:11 PM Guido van Rossum wrote:
> [..]
>> Still, I wonder if there's a tweak possible of the globals and locals used
>> when exec()'ing the function definitions in dataclasses.py, so that
>> get_type_hints() ge
Overall, I support the efforts to improve the C API, but over the last few
weeks have become worried. I don't want to hold up progress with fear,
uncertainty, and doubt. Yet, I would like to be more comfortable that we're
all aware of what is occurring and what are the potential benefits and r
> On Jan 19, 2019, at 2:12 AM, Serhiy Storchaka wrote:
>
> I have virtually completely lost the sight of my right eye (and the loss is
> quickly progresses) and the sight of my left eye is weak.
I hope this only temporary. Best wishes.
Raymond
_
Now that regular dicts are ordered and compact, it makes more sense for the
_asdict() method to create a regular dict (as it did in its early days) rather
than an OrderedDict. The regular dict is much smaller, much faster, and has a
much cleaner looking repr. It would also help namedtuple() st
> On Jan 30, 2019, at 6:00 PM, David Mertz wrote:
>
> Ditto +1 option 4
>
> On Wed, Jan 30, 2019, 5:56 PM Paul Moore On Wed, 30 Jan 2019 at 22:35, Raymond Hettinger
> wrote:
> > My recommendation is Option 4 as being less disruptive and more beneficial
> > t
> On Jan 30, 2019, at 9:11 PM, Tim Delaney wrote:
>
> Alternatively, would it be viable to make OrderedDict work in a way that so
> long as you don't use any reordering operations it's essentially just a very
> thin layer on top of a dict,
There's all kinds of tricks we could do but none of
> On Jan 31, 2019, at 3:06 AM, Steve Holden wrote:
>
> And I see that such a patch is now merged. Thanks, Raymond!
And thank you for getting ordering into csv.DictReader. That was a significant
improvement in usability :-)
Raymond
___
Python-De
> On Feb 3, 2019, at 1:03 PM, Antoine Pitrou wrote:
>
> I'd like to ask for the reversion of the changes done in
> https://github.com/python/cpython/pull/11664
Please work *with* Davin on this one.
It was only recently that you edited his name out of the list of maintainers
for multiprocess
> On Feb 3, 2019, at 5:40 PM, Terry Reedy wrote:
>
> On 2/3/2019 7:55 PM, Guido van Rossum wrote:
>> Also, did anyone ask Davin directly to roll it back?
>
> Antoine posted on the issue, along with Robert O. Robert reviewed and make
> several suggestions.
I think the PR sat in a stable stat
> On Feb 4, 2019, at 2:36 AM, Łukasz Langa wrote:
>
> @Raymond, would you be willing to work with Davin on finishing this work in
> time for alpha2?
I would be happy to help, but this is beyond my technical ability. The people
who are qualified to work on this have already chimed in on the d
> On Feb 5, 2019, at 9:52 AM, Giampaolo Rodola' wrote:
>
> The main problem I have with this PR is that it seems to introduce 8 brand
> new APIs, but since there is no doc, docstrings or tests it's unclear which
> ones are supposed to be used, how or whether they are supposed to supersede
>
On Feb 21, 2019, at 6:53 AM, Stephane Wirtel wrote:
>
> What do you think if we suggest a "template" for the new bugs?
99% of the time the template would be not applicable. Historically, we asked
for more information when needed and that wasn't very often.
I think that anything that raises th
I'll been running benchmarks that have been stable for a while. But between
today and yesterday, there has been an almost across the board performance
regression.
It's possible that this is a measurement error or something unique to my system
(my Mac installed the 10.14.3 release today), so
> On Feb 24, 2019, at 10:06 PM, Eric Snow wrote:
>
> I'll look into it in more depth tomorrow. FWIW, I have a few commits
> in the range you described, so I want to make sure I didn't slow
> things down for us. :)
Thanks for looking into it.
FWIW, I can consistently reproduce the results sev
> On Feb 25, 2019, at 2:54 AM, Antoine Pitrou wrote:
>
> Have you tried bisecting to find out the offending changeset, if there
> any?
I got it down to two checkins before running out of time:
Between
git checkout 463572c8beb59fd9d6850440af48a5c5f4c0c0c9
And:
git checkout 3b0abb019
> On Feb 26, 2019, at 3:30 AM, INADA Naoki wrote:
>
> I'm working on compact and ordered set implementation.
> It has internal data structure similar to new dict from Python 3.6.
>
> On Feb 26, 2019, at 3:30 AM, INADA Naoki wrote:
>
> I'm working on compact and ordered set implementation.
Quick summary of what I found when I last ran experiments with this idea:
* To get the same lookup performance, the density of index table would need to
go down to around 25%. Otherwise, there's no way to make up for the extra
indirection and the loss of cache locality.
* There was a small win
On Feb 25, 2019, at 8:23 PM, Eric Snow wrote:
>
> So it looks like commit ef4ac967 is not responsible for a performance
> regression.
I did narrow it down to that commit and I can consistently reproduce the timing
differences.
That said, I'm only observing the effect when building with the M
On Feb 26, 2019, at 2:28 PM, Neil Schemenauer wrote:
>
> Are you compiling with --enable-optimizations (i.e. PGO)? In my
> experience, that is needed to get meaningful results.
I'm not and I would worry that PGO would give less stable comparisons because
it is highly sensitive to changes its t
n
standard library modules guarantee cross-release bytewise identical output for
XML. That is really the core issue here. Had we had an explicit notice one way
or the other, there wouldn't be an issue now.
Any thoughts?
Raymond Hettinger
P.S. Stefan Behnel is planning to remove
> On Mar 18, 2019, at 4:15 PM, Nathaniel Smith wrote:
>
> I noticed that your list doesn't include "add a DOM equality operator". That
> seems potentially simpler to implement than canonical XML serialization, and
> like a useful thing to have in any case. Would it make sense as an option?
T
I'm working on ways to make improve help() by giving docstrings to member
objects.
One way to do it is to wait until after the class definition and then make
individual, direct assignments to __doc__ attributes.This way widely the
separates docstrings from their initial __slots__ definition.
> On Mar 19, 2019, at 1:52 PM, MRAB wrote:
>
> Thinking ahead, could there ever be anything else that you might want also to
> attach to member objects?
Our experience with property object suggests that once docstrings are
supported, there don't seem to be any other needs. But then, you n
> On Mar 20, 2019, at 3:30 PM, Gregory P. Smith wrote:
>
> I like the idea of documenting attributes, but we shouldn't force the user to
> use __slots__ as that has significant side effects and is rarely something
> people should bother to use.
Member objects are like property objects in tha
> On Mar 20, 2019, at 3:47 PM, Ivan Pozdeev via Python-Dev
> wrote:
>
>> NormalDist.mu.__doc__ = 'Arithmetic mean'
>> NormalDist.sigma.__doc__ = 'Standard deviation'
>
> IMO this is another manifestation of the problem that things in the class
> definition have no access to the class object.
> On Mar 20, 2019, at 3:59 PM, Ethan Furman wrote:
>
> Hmm. Said somewhat less snarkily, is there a more general solution to the
> problem of absent docstrings or do we have to attack this problem
> piece-by-piece?
I think this is the last piece. The pydoc help() utility already knows how
> On Mar 19, 2019, at 4:53 AM, Ned Batchelder wrote:
>
> None of this is impossible, but please try not to preach to us maintainers
> that we are doing it wrong, that it will be easy to fix, etc
There's no preaching and no judgment. We can't have a conversation though if
we can't state the
> On Mar 20, 2019, at 5:22 PM, Victor Stinner wrote:
>
> I don't understand why such simple solution has been rejected.
It hasn't been rejected. That is above my pay grade. Stefan and I recommended
against going down this path. However, since you're in disagreement and have
marked this as a
> On Mar 20, 2019, at 6:07 PM, Victor Stinner wrote:
>
> what's the rationale of this backward incompatible change?
Please refrain from abusive mischaracterizations. It is only backwards
incompatible if there was a guaranteed behavior. Whether there was or not is
what this thread is about.
> On Jul 13, 2019, at 1:56 PM, Serhiy Storchaka wrote:
>
> Could we strictly define what is considered a public module interface in
> Python?
The RealDefinition™ is that whatever we include in the docs is public,
otherwise not.
Beyond that, there is a question of how users can deduce what is
FWIW, the bisect_left and bisect_right functions have different argument order
so that they can both use __lt__, making them consistent with sorting and with
the heapq functions.
Raymond
___
Python-Dev mailing list -- python-dev@python.org
To unsubscri
We should revisit what we want to do (if anything) about invalid escape
sequences.
For Python 3.8, the DeprecationWarning was converted to a SyntaxWarning which
is visible by default. The intention is to make it a SyntaxError in Python 3.9.
This once seemed like a reasonable and innocuous idea
Thanks for looking at other languages do. It gives some hope that this won't
end-up being a usability fiasco.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailm
> I broadly agree that the warning is very annoying, particularly
> when it comes from third-party packages (I see it from some
> of pip's vendored dependencies all the time),
The same here as well.
The other annoyance is that it pops up during live demos, student teaching
sessions, and during
End-user experience isn't something that can just be argued away. Steve and I
are reporting a recurring annoyance. The point of a beta release is to elicit
these kinds of reports so they can be addressed before it is too late. ISTM
you are choosing not to believe the early feedback and don't
For me, these warnings are continuing to arise almost daily. See two recent
examples below. In both cases, the code previously had always worked without
complaint.
- Example from yesterday's class
''' How old-style formatting works with positional placeholders
print('The answer is %
This isn't about me. As a heavy user of the 3.8 beta, I'm just the canary in
the coal mine.
After many encounters with these warnings, I'm starting to believe that
Python's long-standing behavior was convenient for users. Effectively, "\-"
wasn't an error, it was just a way of writing "\-". F
> On Oct 17, 2020, at 2:40 PM, Tim Peters wrote:
>
> Still waiting for someone who thinks string search speed is critical
> in their real app to give it a try. In the absence of that, I endorse
> merging this.
Be bold. Merge it. :-)
Raymond
__
I vote against removal.
We have no compelling need to disrupt an entire community and ecosystem even
though it it is small.
To anyone chiming in to say, yes drop the support, ask whether you've consulted
any of the users — they should have a say in the matter. It is better for them
to be a b
Here are a couple comments on the Twitter thread that warrant your attention.
Apparently, this is being used by the European Space Agency on their space
craft.
-- https://twitter.com/nikolaivk/status/1322094167980466178
"To be clear I will put some money where my mouth is. If we need to invest
> On Oct 30, 2020, at 4:51 PM, Gregory P. Smith wrote:
>
> On Fri, Oct 30, 2020 at 1:14 PM Raymond Hettinger
> wrote:
> FWIW, when the tracker issue landed with a PR, I became concerned that it
> would be applied without further discussion and without consulting users.
>
> On Nov 7, 2020, at 9:51 AM, Riccardo Polignieri via Python-Dev
> wrote:
>
> My concern here is that if you start removing or simplifying some
> "too-difficult-for-a-tutorial" bits of information on an occasional basis,
> and without too much scrutiny or editorial guidance, you will end up
Please add me to the list of members for the initial workgroup.
Thank you,
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
That seems exclusionary. Right now, anyone can contribute to documentation,
anyone can comment on proposals, and any core dev can accept their patches.
In the interest of transparency, can you explain why the other initial members
did not need to go through an application process? ISTM the in
I recommend removing the "discouragement" from writing "bytes(10)". That is
merely stylistic. As long as we support the API, it is valid Python. In the
contexts where it is currently used, it tends to be clear about what it is
doing: buffer = bytearray(bufsize). That doesn't need to be disco
> I would rather keep `bchr` and lose the `.fromint()` methods.
For me, "bchr" isn't a readable name. If I expand mentally expand it to
"byte_character", it becomes an oxymoron that opposes what we try teach about
bytes and characters being different things.
Can you show examples in existing
On Mar 20, 2013, at 12:38 PM, Barry Warsaw wrote:
> Right. Ultimately, I think IDLE should be a separate project entirely, but I
> guess there's push back against that too.
The most important feature of IDLE is that it ships with the standard library.
Everyone who clicks on the Windows MSI on
On Mar 25, 2013, at 2:16 PM, Victor Stinner wrote:
> Hi,
>
> I just realized that the Python peephole optimizer removes useless
> instructions like numbers and strings between other instructions,
> without raising an error nor emiting an error. Example:
>
> $ python -Wd -c 'print "Hello"; "Wor
On Apr 6, 2013, at 2:02 PM, Benjamin Peterson wrote:
> we need to talk about how many more 2.7 releases there are
> going to be. At the release of 2.7.0, I thought we promised 5 years of
> bugfix maintenance, but my memory may be fuddled.
I don't we need to make any "promises" beyond 5 years,
After the long design effort for the enum module,
I'm sure there will be a forthcoming effort to apply
them pervasively throughout the standard library.
I would like to ask for a little restraint and for there to
be individual cost/benefit evaluations for each case.
On the plus-side, the new int
On May 12, 2013, at 8:26 PM, Eli Bendersky wrote:
> Thanks for the insights, Raymond. I don't think anyone is planning on rushing
> anything. We still have to get the enum module itself committed and a serious
> review process has just started for that, so it will take time.
>
> There's no ge
On May 15, 2013, at 4:32 AM, Christian Tismer wrote:
> What is the current status of this discussion?
> I'd like to know whether it is a considered alternative implementation.
As far as I can tell, I'm the only one working on it (and a bit slowly at that).
My plan is to implement it for frozens
On May 14, 2013, at 9:39 AM, Gregory P. Smith wrote:
> Bad: doctests.
I'm hoping that core developers don't get caught-up in the "doctests are bad
meme".
Instead, we should be clear about their primary purpose which is to test
the examples given in docstrings. In many cases, there is a gre
Does anyone know what we would need to do to get Python in the Apple
application store as a free App?
The default security settings on OS X 10.8 block the installation of the DMG
(or any software downloaded outside the app store). A number of my students
are having difficulty getting around i
On Jun 18, 2013, at 12:00 AM, Gregory P. Smith wrote:
> Why did you do this in the 2.7 branch?
>
> It hasn't been done in 3.3 or default
I worked on the 2.7 branch first because that was the one I had loaded
and the one where I did timings and code disassembly. I intended to
post it to 3.3 an
On Jun 23, 2013, at 6:52 PM, Scott Dial wrote:
> Nowadays, cache lines are still 64 bytes but pointers are 8 bytes, and
> we still allocating on 16 byte alignment, so you have a 25% chance of a
> cache miss now.
Honestly, I'm not sure what you're arguing for or against.
The struct should to be
On Jun 24, 2013, at 4:07 AM, Victor Stinner wrote:
> Out of curiosity, do you know (remember) how was the number 62 chosen?
> Is it a compromise between memory usage and performances? 62 is
> surprising because it is not a power of two :-)
>
> Is it to just have 64 (2+62) pointers in the struct
On Jun 24, 2013, at 10:12 PM, Benjamin Peterson wrote:
> Raymond, go ahead and reapply your change.
If you don't mind, I think you should be the one to undo your own reversions.
Thank you,
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
On Jul 4, 2013, at 2:34 AM, Brett Cannon wrote:
> The loss of the ability to figure out the class from an unbound method seems
> quite an annoying step back from an introspection point of view.
>
> It's only annoying if you take the perspective that methods are somehow
> special compared to f
On Jul 14, 2013, at 6:32 AM, David Beazley wrote:
> I honestly don't have any particular thoughts about PLY vs. other parser
> generators and the merits of their inclusion (or not) in the standard
> library.
I would love to have PLY in the standard library.
It would open up a whole new world
Our current Mac OS X builds use GCC-4.2.
On Python2.7, I ran a comparison of gcc-4.2.1 builds
versus gcc-4.8.1 and found that the latter makes a much
faster Python. PyBench2.0 shows the total running time
dropping from 5653ms to 4571ms. The code is uniformly
better in just about every category.
On Jul 21, 2013, at 5:32 PM, Ned Deily wrote:
> In article <252c50d8-c23d-438d-bae1-b22e0d65a...@gmail.com>,
> Raymond Hettinger wrote:
>> Our current Mac OS X builds use GCC-4.2.
>>
>> On Python2.7, I ran a comparison of gcc-4.2.1 builds
>> versus gcc-4.8
On Aug 2, 2013, at 8:47 PM, Eli Bendersky wrote:
> I was looking around the Objects directory and noticed that we have
> enumobject.h/c with the enumobject structure for "enumerate" and "reversed".
> This is somewhat confusing now with Lib/enum.py and will be doubly confusing
> if we ever dec
> The most reasonable thing to do would probably be to share the same
> dummy object between setobject.c and dictobject.c, then.
> Raymond, it would be nice if you could take a look!
Thanks, I will look at it shortly.
Raymond
On Sun, Aug 18, 2013 at 11:46 AM, Antoine Pitrou wrote:
> On Sun,
On Sep 10, 2013, at 4:28 AM, Antoine Pitrou wrote:
> In http://bugs.python.org/issue18986 I proposed adding a new mapping
> type to the collections module.
I would *really* like for this to start outside the standard library.
It needs to mature with user feedback before being dumped
in the coll
I was exercising the alpha two release of 3.4 and noticed that
it is still being built under GCC 4.2.1.
Is there any reason we have to use an old compiler?
I would like to see it built under the latest version of Clang
(like the other tools on the Mac) or under GCC 4.8.1.
I've better using the
On Sep 14, 2013, at 1:32 PM, Ned Deily wrote:
> The
> most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have
> a mature clang but do not provide a 10.6 SDK. Even with using an SDK,
> it's still possible to end up inadvertently linking with the wrong
> versions of system li
On Sep 23, 2013, at 7:15 AM, Nick Coghlan wrote:
> With the last round of updates, I believe PEP 453 is ready for
> Martin's pronouncement.
Personally, I'm very excited and happy that this or something like it
is coming close to fruition.
My experiences in userland suggest that this will be
On Sep 22, 2013, at 6:16 PM, Ethan Furman wrote:
> Are we close to asking for pronouncement?
When you're ready, let me know.
In the meantime, I conducting usability tests on students in Python classes
and researching how well it substitutes for existing solutions for
case insensitive diction
On Oct 4, 2013, at 2:06 PM, Victor Stinner wrote:
> I'm not convinced by your usability test.
You're not the one who needs to be convinced ;-)
Please do conduct your own API tests and report back.
This is necessary for a new class like TransformDict
that was constructed from scratch and pro
On Oct 4, 2013, at 2:14 PM, Antoine Pitrou wrote:
> I think "usability tests" should be conducted on people who actually
> have a need for the API. Otherwise they simply don't make sense: if you
> don't need an API, then you don't have to learn / understand it either.
You're right. Students do
On Oct 5, 2013, at 12:42 PM, Serhiy Storchaka wrote:
> Please remember me, what was common decision about CPython-only optimizations
> which change computation complexity?
IIRC, it is okay optimize C code for just about anything, but we don't
want to alter the pure python code after from idiom
On Oct 12, 2013, at 1:41 PM, Ethan Furman wrote:
> . break_on reads just fine to me, although leave_on is probably better.
Sorry, these are both really bad.
I've user tested ignore() and had good results.
It makes the intention of the code very clear.
When you ask someone to describe what
"t
On Oct 12, 2013, at 4:30 PM, Ethan Furman wrote:
>>
>> When you ask someone to describe what
>> "try: f() except SomeException: pass" does,
>> they will say that it ignores the exception.
>
> And they would be right in that case.
>
>
>> FWIW, I presented this to 2500+ people in the keynote
>
On Oct 15, 2013, at 5:55 AM, Larry Hastings wrote:
> I'd like to propose much the same thing for Argument Clinic: check it in now,
> before 3.4a4, and let it bake in trunk a little before feature freeze at beta
> 1 while I run around and finish the documentation.
This is a good plan.
"Lettin
On Oct 15, 2013, at 4:24 PM, Nick Coghlan wrote:
> this thread still epitomises everything that sucks about soul destroying,
> energy draining bikeshed painting that makes me wonder why I ever bother
> trying to make anything better.
>
FWIW, here's a little history:
* Last year, one of my
> On Jun 7, 2016, at 10:51 AM, Eric Snow wrote:
>
> This PEP changes the default class definition namespace to ``OrderedDict``.
I think this would be a nice improvement.
> Furthermore, the order in which the attributes are defined in each class
> body will now be preserved in ``type.__definiti
> On Jun 7, 2016, at 4:12 PM, Nick Coghlan wrote:
>
> By the time decorators run, the original execution namespace is no
> longer available - the contents have been copied into the class dict,
> which will still be a plain dict (and there's a lot of code that calls
> PyDict_* APIs on tp_dict, so
> On Jun 18, 2016, at 9:57 AM, Franklin Lee wrote:
>
> In the original discussion, I think they decided to reimplement set before
> dict.
I ended-up going in a different direction with sets (using linear probes to
reduce the cost of collisions). Also, after the original discussion, PyPy
imp
> On Jun 18, 2016, at 2:04 PM, Obiesie ike-nwosu via Python-Dev
> wrote:
>
> Hi,
>
> Could some one give a hand with explaining to me why we have a JUMP_ABSOLUTE
> followed by a JUMP_FORWARD op code when this function is disassembled.
> < snipped>
> From my understanding, once JUMP_ABSOLUTE
ort
and without much of a performance hit. IIRC, it involved using a
ConcurrentHashMap augmented by an auxiliary 2-by-n-row array of indices (one
for forward links and the other for backward links). There was also need to
add a reentrant lock around the mutating methods.
Raymond Hettinger
> On Jun 21, 2016, at 10:18 AM, Guido van Rossum wrote:
>
> Judging from Inada's message there seems to be some confusion about how well
> the compact dict preserves order (personally I think if it doesn't guarantee
> order after deletions it's pretty useless).
Inada should follow PyPy's impl
> 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 involved in those sort of decisions.
Raymond
> On Sep 11, 2016, at 12:45 AM, Elliot Gorokhovsky
> wrote:
>
> I am interested in making a non-trivial improvement to list.sort(), but
> before I put in the work, I want to test the waters and see if this is
> something the community would accept. Basically, I want to implement radix
> sort
101 - 200 of 1487 matches
Mail list logo
