> 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 modu
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 c
> 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
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
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
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
> 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
> 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.
>
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
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
> 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
__
> 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
> 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 i
> 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 cu
> 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 pl
> 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.
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 u
> 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 a
> 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, retur
> 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 calle
> 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
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
https://mail.pyt
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 b
[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 wit
[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
___
Pytho
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, object_hook=S
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 r
> 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 io
> 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 d
> 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 tho
> 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 dev
> 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 deve
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
anoth
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
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 %
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
> 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
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
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
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
> 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
> 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 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 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 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 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: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 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
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 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
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 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
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
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 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.
> 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 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
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 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
> 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 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 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 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 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 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 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
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 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
_
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 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
> 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 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 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 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 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 Python
> implementation's
> pl
> 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:
> https://github.com/pitrou/cpython/tree/pickle5
>
> Also I've
> 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 OrderedDict to signal explic
> 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 values.
You are correct.
> 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 personal habit. Some peopl
> 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 objections are treated so
> On Apr 26, 2018, at 12:40 AM, Tim Peters wrote:
>
> [Raymond Hettinger ]
>> After re-reading all the proposed code samples, I believe that
>> adopting the PEP will make the language harder to teach to people
>> who are not already software engineers.
>
> C
> 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 didn't, sorry if
> it cau
> 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 to extract the desire
> 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
>
> https://www.python.org/dev/peps/pep-0575/
Thanks
> 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 it still serves a u
On Mar 25, 2018, at 8:08 AM, Tin Tvrtković wrote:
>
> That's reassuring, thanks.
I misspoke. The object size is the same but the underlying dictionary loses
key-sharing and doubles in size.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
> 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 dictionary is special
> there,
On Tue, Mar 13, 2018 at 11:39 AM, Raymond Hettinger
> wrote:
>
>
> > 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'
> 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 numpy or the
> som
> 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 this code has a bug
>
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 l
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
>>
> 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 about nine years ago.
> 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 to me that it is clear
>>> 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 has
> 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 the code proximate t
> 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 more
> natural s
> On Dec 15, 2017, at 1:47 PM, Guido van Rossum wrote:
>
> On Fri, Dec 15, 2017 at 12:45 PM, Raymond Hettinger
> wrote:
>
> > On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote:
> >
> > Make it so. "Dict keeps insertion order" is the ruling.
>
> 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.
The 3.6 guidance is
> 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: test_bpo20891 (tes
1 - 100 of 1487 matches
Mail list logo
