[Python-Dev] Re: Restrict the type of __slots__

> I propose to restrict the type of __slots__. -1 for adding a restriction. This breaks code for no good reason. This API has been around for a very long time. I've seen lists, tuples, dicts, single strings, and occasionally something more exotic. Why wreck stable code? Also, the inspect

[Python-Dev] Re: Optimizing literal comparisons and contains

For the benefit of the audience on python-dev, you should also mention that this proposal and associated PR has been twice discussed and rejected on the tracker: https://bugs.python.org/issue45907 https://bugs.python.org/issue45843 The response just given by Skip pretty much matches the

[Python-Dev] Re: PEP 467 feedback from the Steering Council

> 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

[Python-Dev] Re: PEP 467 feedback from the Steering Council

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

[Python-Dev] Re: Announcing the CPython Docs Workgroup

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

[Python-Dev] Re: Announcing the CPython Docs Workgroup

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

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

> 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

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

> 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. >

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

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

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

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

[Python-Dev] Re: Changing Python's string search algorithms

> 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

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

> On Jun 29, 2020, at 5:46 PM, Victor Stinner wrote: > > You missed the point of the PEP: "It becomes possible to experiment > with more advanced optimizations in CPython than just > micro-optimizations, like tagged pointers." > > IMHO it's time to stop wasting our limited developer resources

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

> On Jun 22, 2020, at 5:10 AM, Victor Stinner wrote: > > Introduce C API incompatible changes to hide implementation details. How much of the existing C extension ecosystem do you expect to break as a result of these incompatible changes? > It will be way easier to add new features. This

[Python-Dev] Re: The Anti-PEP

> it is hard to make a decision between the pros and cons, > when the pros are in a single formal document and the > cons are scattered across the internet. Mark, I support your idea. It is natural for PEP authors to not fully articulate the voices of opposition or counter-proposals. The

[Python-Dev] Re: Latest PEP 554 updates.

> On May 4, 2020, at 10:30 AM, Eric Snow wrote: > > Further feedback is welcome, though I feel like the PR is ready (or > very close to ready) for pronouncement. Thanks again to all. Congratulations. Regardless of the outcome, you've certainly earned top marks for vision, tenacity, team

[Python-Dev] Re: Adding a "call_once" decorator to functools

> On Apr 30, 2020, at 10:44 AM, Carl Meyer wrote: > > On Wed, Apr 29, 2020 at 9:36 PM Raymond Hettinger > wrote: >> Do you have some concrete examples we could look at? I'm having trouble >> visualizing any real use cases and none have been presented so far.

[Python-Dev] Re: Adding a "call_once" decorator to functools

Would either of the existing solutions work for you? class X: def __init__(self, name): self.name = name @cached_property def title(self): print("compute title once") return self.name.title() @property @lru_cache def upper(self): print("compute

[Python-Dev] Re: Adding a "call_once" decorator to functools

> On Apr 30, 2020, at 6:32 AM, Joao S. O. Bueno wrote: > > Of course this is meant to be something simple - so there are no "real > world use cases" that are "wow, it could not have > been done without it". The proposed implementation does something risky, it hold holds a non-reentrant lock

[Python-Dev] Re: Adding a "call_once" decorator to functools

> On Apr 29, 2020, at 4:20 PM, Antoine Pitrou wrote: > > On Wed, 29 Apr 2020 12:01:24 -0700 > Raymond Hettinger wrote: >> >> The call_once() decorator would need different logic: >> >> 1) if the function has already been called and result is known, r

[Python-Dev] Re: Adding a "call_once" decorator to functools

> On Apr 29, 2020, at 12:55 AM, Tom Forbes wrote: > > Hey Raymond, > Thanks for your input here! A new method wouldn’t be worth adding purely for > performance reasons then, but there is still an issue around semantics and > locking. Right. > it doesn’t actually ensure the function is

[Python-Dev] Re: Adding a "call_once" decorator to functools

> t...@tomforb.es wrote: > > I would like to suggest adding a simple “once” method to functools. As the > name suggests, this would be a decorator that would call the decorated > function, cache the result and return it with subsequent calls. It seems like you would get just about everything

[Python-Dev] Re: Accepting PEP 617: New PEG parser for CPython

This will be a nice improvement. Raymond ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at

[Python-Dev] Re: PEP 616 "String methods to remove prefixes and suffixes" accepted

Please consider adding underscores to the names: remove_prefix() and remove_suffix(). The latter method causes a mental hiccup when first read as removes-uffix, forcing mental backtracking to get to remove-suffix. We had a similar problem with addinfourl initially being read as add-in-four-l

[Python-Dev] Re: Improvement to SimpleNamespace

[Serhiy] > As a workaround you can use > > object_hook=lambda x: SimpleNamespace(**x) That doesn't suffice because some valid JSON keys are not valid identifiers. You still need a way to get past those when they arise: catalog.books.fiction['Paradise Lost'].isbn Also, it still leaves you

[Python-Dev] Re: Improvement to SimpleNamespace

[GvR] > We should not try to import JavaScript's object model into Python. Yes, I get that. Just want to point-out that working with heavily nested dictionaries (typical for JSON) is no fun with square brackets and quotation marks. Raymond ___

[Python-Dev] Improvement to SimpleNamespace

SimpleNamespace() is really good at giving attribute style-access. I would like to make that functionality available to the JSON module (or just about anything else that accepts a custom dict) by adding the magic methods for mappings so that this works: catalog = json.load(f,

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

I forget to mention that list.index() also uses PyObject_RichCompareBool(). Given a non-empty list *s*: s[0] = x assert s.index(x) == 0 # We want this to always work or: s = [x] assert s.index(x) == 0# Should not raise a ValueError If those two assertions aren't

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

> We propose to revert 5 changes: > > • Removed tostring/fromstring methods in array.array and base64 modules > • Removed collections aliases to ABC classes > • Removed fractions.gcd() function (which is similar to math.gcd()) > • Remove "U" mode of open(): having to use

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

> PyObject_RichCompareBool(x, y, op) has a (valuable!) shortcut: if x and y are > the same object, then equality comparison returns True and inequality False. > No attempt is made to execute __eq__ or __ne__ methods in those cases. > > This has visible consequences all over the place, but they

[Python-Dev] Re: Should set objects maintain insertion order too?

> 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 they? I don't think they should. Several

[Python-Dev] Re: [python-committers] PEP 581/588 RFC: Collecting feedback about GitHub Issues

> On Aug 27, 2019, at 10:44 AM, Mariatta wrote: > > (cross posting to python-committers, python-dev, core-workflow) > > PEP 581: Using GitHub Issues has been accepted by the steering council, but > PEP 588: GitHub Issues Migration plan is still in progress. > > I'd like to hear from core

[Python-Dev] Re: [python-committers] PEP 581/588 RFC: Collecting feedback about GitHub Issues

> On Aug 27, 2019, at 10:44 AM, Mariatta wrote: > > (cross posting to python-committers, python-dev, core-workflow) > > PEP 581: Using GitHub Issues has been accepted by the steering council, but > PEP 588: GitHub Issues Migration plan is still in progress. > > I'd like to hear from core

[Python-Dev] Re: Announcing the new Python triage team on GitHub

Thanks for doing this. I hope it encourages more participation. The capabilities of a triager mostly look good except for "closing PRs and issues". This is a superpower that has traditionally been reserved for more senior developers because it grants the ability to shut-down the work of

[Python-Dev] Re: What to do about invalid escape sequences

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 "\-".

[Python-Dev] Re: What to do about invalid escape sequences

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

[Python-Dev] Re: What to do about invalid escape sequences

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

[Python-Dev] Re: What to do about invalid escape sequences

> 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

[Python-Dev] Re: What to do about invalid escape sequences

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

[Python-Dev] What to do about invalid escape sequences

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

[Python-Dev] Re: The order of operands in the comparison

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

[Python-Dev] Re: What is a public API?

> 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

Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

> 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

Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

> 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

Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

> 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

Re: [Python-Dev] Best way to specify docstrings for member objects

> 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

Re: [Python-Dev] Best way to specify docstrings for member objects

> 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

Re: [Python-Dev] Best way to specify docstrings for member objects

> 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

Re: [Python-Dev] Best way to specify docstrings for member objects

> 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

[Python-Dev] Best way to specify docstrings for member objects

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.

Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

> 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?

[Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

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 attribute sorting from lxml. On the bug tracker, he has clearly

Re: [Python-Dev] Possible performance regression

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

Re: [Python-Dev] Possible performance regression

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

Re: [Python-Dev] Compact ordered set

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

Re: [Python-Dev] Compact ordered set

> 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.

Re: [Python-Dev] Possible performance regression

> 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

Re: [Python-Dev] Possible performance regression

> 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

[Python-Dev] Possible performance regression

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

Re: [Python-Dev] Add minimal information with a new issue?

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

Re: [Python-Dev] Asking for reversion

> 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

Re: [Python-Dev] Asking for reversion

> 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

Re: [Python-Dev] Asking for reversion

> 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

Re: [Python-Dev] Asking for reversion

> 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

Re: [Python-Dev] Fwd: How about updating OrderedDict in csv and configparser to regular dict?

> 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 ___

Re: [Python-Dev] How to update namedtuple asdict() to use dict instead of OrderedDict

> 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

Re: [Python-Dev] How to update namedtuple asdict() to use dict instead of OrderedDict

> 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 &g

[Python-Dev] How to update namedtuple asdict() to use dict instead of OrderedDict

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()

Re: [Python-Dev] Lost sight

> 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

[Python-Dev] General concerns about C API changes

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

Re: [Python-Dev] Postponed annotations break inspection of dataclasses

> 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()

Re: [Python-Dev] Testing C API

> 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

Re: [Python-Dev] Testing C API

> 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

Re: [Python-Dev] [issue34221] Any plans to combine collections.OrderedDict with dict

> 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

Re: [Python-Dev] [issue34221] Any plans to combine collections.OrderedDict with dict

> 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? >>

Re: [Python-Dev] Add __reversed__ methods for dict

> On May 26, 2018, at 7:20 AM, INADA Naoki wrote: > > Because doubly linked list is very memory inefficient, every implementation > would be forced to implement dict like PyPy (and CPython) for efficiency. > But I don't know much about current MicroPython and other

Re: [Python-Dev] PEP 574 (pickle 5) implementation and backport available

> On May 24, 2018, at 10:57 AM, Antoine Pitrou wrote: > > While PEP 574 (pickle protocol 5 with out-of-band data) is still in > draft status, I've made available an implementation in branch "pickle5" > in my GitHub fork of CPython: >

Re: [Python-Dev] Add __reversed__ methods for dict

> On May 25, 2018, at 9:32 AM, Antoine Pitrou wrote: > > It's worth nothing that OrderedDict already supports reversed(). > The argument could go both ways: > > 1. dict is similar to OrderedDict nowadays, so it should support > reversed() too; > > 2. you can use

Re: [Python-Dev] Hashes in Python3.5 for tuples and frozensets

> On May 16, 2018, at 5:48 PM, Anthony Flury via Python-Dev > wrote: > > However the frozen set hash, the same in both cases, as is the hash of the > tuples - suggesting that the vulnerability resolved in Python 3.3 wasn't > resolved across all potentially hashable

Re: [Python-Dev] PEP 572: Usage of assignment expressions in C

> On Apr 28, 2018, at 8:45 AM, Antoine Pitrou wrote: > >> I personally haven't written a lot of C, so have no personal experience, >> but if this is at all a common approach among experienced C developers, it >> tells us a lot. > > I think it's a matter of taste and

Re: [Python-Dev] PEP 572: A backward step in readability

> On Apr 30, 2018, at 9:37 AM, Steven D'Aprano wrote: > > On Mon, Apr 30, 2018 at 08:09:35AM +0100, Paddy McCarthy wrote: > [...] >> A PEP that can detract from readability; *readability*, a central >> tenet of Python, should >> be rejected, (on principle!), when such

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

> On Apr 26, 2018, at 12:40 AM, Tim Peters <tim.pet...@gmail.com> wrote: > > [Raymond Hettinger <raymond.hettin...@gmail.com>] >> After re-reading all the proposed code samples, I believe that >> adopting the PEP will make the language harder to teach to peopl

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

> On Apr 25, 2018, at 8:11 PM, Yury Selivanov wrote: > > FWIW I started my thread for allowing '=' in expressions to make sure that > we fully explore that path. I don't like ':=' and I thought that using '=' > can make the idea more appealing to myself and others. It

Re: [Python-Dev] PEP 575: Unifying function/method classes

> On Apr 15, 2018, at 5:50 AM, Jeroen Demeyer wrote: > > On 2018-04-14 23:14, Guido van Rossum wrote: >> That actually sounds like a pretty big problem. I'm sure there is lots >> of code that doesn't *just* duck-type nor calls inspect but uses >> isinstance() to decide how

Re: [Python-Dev] PEP 575: Unifying function/method classes

> On Apr 12, 2018, at 9:12 AM, Jeroen Demeyer wrote: > > I would like to request a review of PEP 575, which is about changing the > classes used for built-in functions and Python functions and methods. The > text of the PEP can be found at > >

Re: [Python-Dev] Soliciting comments on the future of the cmd module (bpo-33233)

> On Apr 6, 2018, at 3:02 PM, Ned Deily wrote: > > We could be even bolder and officially deprecate "cmd" and consider closing > open enhancement issues for it on b.p.o." FWIW, the pdb module depends on the cmd module. Also, I still teach people how to use cmd and I think

Re: [Python-Dev] Replacing self.__dict__ in __init__

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

Re: [Python-Dev] Replacing self.__dict__ in __init__

> On Mar 24, 2018, at 7:18 AM, Tin Tvrtković wrote: > > it's faster to do this: > > self.__dict__ = {'a': a, 'b': b, 'c': c} > > i.e. to replace the instance dictionary altogether. On PyPy, their core devs > inform me this is a bad idea because the instance

Re: [Python-Dev] Symmetry arguments for API expansion

ees). Raymond > > On Tue, Mar 13, 2018 at 11:39 AM, Raymond Hettinger > <raymond.hettin...@gmail.com> wrote: > > > > On Mar 13, 2018, at 10:43 AM, Guido van Rossum <gu...@python.org> wrote: > > > > So let's make as_integer_ratio() the standard protocol f

Re: [Python-Dev] Symmetry arguments for API expansion

> On Mar 13, 2018, at 10:43 AM, Guido van Rossum wrote: > > So let's make as_integer_ratio() the standard protocol for "how to make a > Fraction out of a number that doesn't implement numbers.Rational". We already > have two examples of this (float and Decimal) and perhaps

Re: [Python-Dev] Symmetry arguments for API expansion

> On Mar 12, 2018, at 12:15 PM, Guido van Rossum wrote: > > There's a reason why adding this to int feels right to me. In mypy we treat > int as a sub*type* of float, even though technically it isn't a sub*class*. > The absence of an is_integer() method on int means that

[Python-Dev] Symmetry arguments for API expansion

There is a feature request and patch to propagate the float.is_integer() API through rest of the numeric types ( https://bugs.python.org/issue26680 ). While I don't think it is a good idea, the OP has been persistent and wants his patch to go forward. It may be worthwhile to discuss on this

[Python-Dev] Should the dataclass frozen property apply to subclasses?

When working on the docs for dataclasses, something unexpected came up. If a dataclass is specified to be frozen, that characteristic is inherited by subclasses which prevents them from assigning additional attributes: >>> @dataclass(frozen=True) class D: x: int = 10

Re: [Python-Dev] Dataclasses, frozen and __post_init__

> On Feb 20, 2018, at 2:38 PM, Guido van Rossum wrote: > > But then the class would also inherit a bunch of misfeatures from tuple (like > being indexable and having a length). It would be nicer if it used __slots__ > instead. FWIW, George Sakkis made a tool like this

Re: [Python-Dev] Is static typing still optional?

> On Jan 28, 2018, at 11:52 PM, Eric V. Smith wrote: > > I think it would be a bad design to have to opt-in to hashability if using > frozen=True. I respect that you see it that way, but it doesn't make sense to me. You can have either one without the other. It seems

Re: [Python-Dev] Is static typing still optional?

>>> 2) Change the default value for "hash" from "None" to "False". This might >>> take a little effort because there is currently an oddity where setting >>> hash=False causes it to be hashable. I'm pretty sure this wasn't intended >>> ;-) >> I haven't looked at this yet. > > I think the

Re: [Python-Dev] Concerns about method overriding and subclassing with dataclasses

> On Dec 29, 2017, at 4:52 PM, Guido van Rossum wrote: > > I still think it should overrides anything that's just inherited but nothing > that's defined in the class being decorated. This has the virtue of being easy to explain, and it will help with debugging by honoring

Re: [Python-Dev] pep-0557 dataclasses top level module vs part of collections?

> On Dec 21, 2017, at 3:21 PM, Gregory P. Smith wrote: > > It seems a suggested use is "from dataclasses import dataclass" > > But people are already familiar with "from collections import namedtuple" > which suggests to me that "from collections import dataclass" would be a

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

> On Dec 15, 2017, at 1:47 PM, Guido van Rossum <gu...@python.org> wrote: > > On Fri, Dec 15, 2017 at 12:45 PM, Raymond Hettinger > <raymond.hettin...@gmail.com> wrote: > > > On Dec 15, 2017, at 7:53 AM, Guido van Rossum <gu...@python.org> wrote: &g

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

> On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote: > > Make it so. "Dict keeps insertion order" is the ruling. On Twitter, someone raised an interesting question. Is the guarantee just for 3.7 and later? Or will the blessing also cover 3.6 where it is already true.

Re: [Python-Dev] New crash in test_embed on macOS 10.12

> On Dec 15, 2017, at 11:55 AM, Barry Warsaw wrote: > > I haven’t bisected this yet, but with git head, built and tested on macOS > 10.12.6 and Xcode 9.2, I’m seeing this crash in test_embed: > > == > FAIL:

  1   2   3   4   5   6   7   8   9   10   >