Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

significant changes in What's > New, and also removed insignificant entries, reorganized entries, > fixed errors, improved wording and formatting. Many thanks to Martin > Panter, Elvis Pranskevichus, Yury Selivanov, R. David Murray, Nick > Coghlan, Antoine Pitrou, Victor Stinner and othe

Re: [Python-Dev] Dataclasses and correct hashability

> Because it's not the default, it will be documented as being an > advanced use case, and it's useful in rare instances. > > And as I've said a number of times, both here and in other > discussions, I'm not arguing strenuously for this. I just think that, > given that it's not the default and

Re: [Python-Dev] Dataclasses and correct hashability

On Friday, February 2, 2018 10:51:11 AM EST Eric V. Smith wrote: > I was specifically talking about the case of a non-frozen, hashable > class. If you want to make a class frozen and hashable, then: > > @dataclass(frozen=True) > > will do just that. > > The case you brought up initially is the

Re: [Python-Dev] Dataclasses and correct hashability

On Friday, February 2, 2018 10:08:43 AM EST Eric V. Smith wrote: > However, I don't feel very strongly about this. As I've said, I expect > the use cases for hash=True to be very, very rare. Why do you think that the requirement to make a dataclass hashable is a "very, very rare" requirement?

Re: [Python-Dev] Dataclasses and correct hashability

On Friday, February 2, 2018 12:33:04 AM EST Nick Coghlan wrote: > For 3.7, I think we should seriously considered just straight up > disallowing the "hash=True, frozen=False" combination, and instead > require folks to provide their own hash function in that case. > "Accidentally hashable"

Re: [Python-Dev] Dataclasses and correct hashability

On Thursday, February 1, 2018 8:37:41 PM EST Eric V. Smith wrote: > > hash=None and compare=True leads to the same result, which, I > > think is even worse. > > Have you actually tried that? I meant this: @dataclasses.dataclass(hash=True) class A: foo: int = dataclasses.field(compare=True)

Re: [Python-Dev] Dataclasses and correct hashability

On Thursday, February 1, 2018 8:21:03 PM EST Eric V. Smith wrote: > I should add: This is why you shouldn't override the default > (hash=None) unless you know what the consequences are. Can I ask > why you want to specify hash=True? hash=None and compare=True leads to the same result, which, I

[Python-Dev] Dataclasses and correct hashability

There appears to be a critical omission from the current dataclass implementation: it does not make hash=True fields immutable. Per Python spec: "the implementation of hashable collections requires that a key’s hash value is immutable (if the object’s hash value changes, it will be in the

Re: [Python-Dev] [python-committers] Welcome the 3.8 and 3.9 Release Manager - Łukasz Langa!

And on Linux (X11) there's a compose key [1] Compose + / + L = Ł You have to map Compose first, as it's not a physical button on modern keyboards: setxkbmap -option compose:ralt [1] https://wiki.archlinux.org/index.php/Keyboard_configuration_in_Xorg#Configuring_compose_key

Re: [Python-Dev] PEP 567 v2

On Friday, January 5, 2018 5:43:24 PM EST Chris Jerdonek wrote: > Is there a reason ContextVar needs to be exposed publicly at all? For > example, the API could use string keys like contextvars.get(name) or > Context.get(name) (class method). There could be separate functions > to initialize keys

Re: [Python-Dev] iso8601 parsing

On Tuesday, October 24, 2017 5:53:58 PM EDT Alexander Belopolsky wrote: > No, but the last time I suggested that that datetime types should > satisfy the same invariants as numbers, namely > T(repr(x)) == x, the idea was met will silence. I, on the other hand, > am not very enthusiastic about

Re: [Python-Dev] PEP 550 v4

On Thursday, September 7, 2017 10:06:14 AM EDT Ethan Furman wrote: > I might be, and I wouldn't be surprised. :) On the other hand, one > can look at isolation as being a resource. > > threading.local(), the isolation mechanism, is *implicit*. > > I don't think so. You don't get

Re: [Python-Dev] PEP 550 v4

On Thursday, September 7, 2017 6:37:58 AM EDT Greg Ewing wrote: > 2) You ignore it and always use a context manager, in > which case it's not strictly necessary for the implicit > context push to occur, since the relevant context managers > can take care of it. > > So there doesn't seem to be any

Re: [Python-Dev] PEP 550 v4

On Thursday, September 7, 2017 9:05:58 AM EDT Ethan Furman wrote: > The disagreement seems to be whether a LogicalContext should be > created implicitly vs explicitly (or opt-out vs opt-in). As a user > trying to track down a decimal context change not propagating, I > would not suspect the above

Re: [Python-Dev] PEP 550 v4

On Thursday, September 7, 2017 3:54:15 AM EDT Greg Ewing wrote: > This problem would also not arise if context vars > simply had names instead of being magic key objects: > > def foo(): >contextvars.set("mymodule.myvar", 1) > > That's another thing I think would be an improvement, >

Re: [Python-Dev] PEP 550 v4

On Wednesday, September 6, 2017 8:06:36 PM EDT Greg Ewing wrote: > Nathaniel Smith wrote: > > The implementation strategy changed radically between v1 > > and v2 because of considerations around generator (not coroutine) > > semantics. I'm not sure what more it can do to dispel these > > feelings>

Re: [Python-Dev] Pep 550 module

On Tuesday, August 29, 2017 9:14:53 AM EDT Yury Selivanov wrote: > On Tue, Aug 29, 2017 at 6:53 AM, Nick Coghlan wrote: > > On 28 August 2017 at 01:51, Jim J. Jewett wrote: > >> I think there is general consensus that this should go in a module > >>

Re: [Python-Dev] PEP 550 v4

On Saturday, August 26, 2017 2:34:29 AM EDT Nathaniel Smith wrote: > On Fri, Aug 25, 2017 at 3:32 PM, Yury Selivanov wrote: > > Coroutines and Asynchronous Tasks > > - > > > > In coroutines, like in generators, context variable changes

Re: [Python-Dev] Help requested with Python 2.7 performance regression

After much testing I found what is causing the regression in 16.04 and later. There are several distinct causes which are attributed to the choices made in debian/rules and the changes in GCC. Cause #1: the decision to compile `Modules/_math.c` with `-fPIC` *and* link it statically into the

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Friday, September 9, 2016 2:01:08 PM EDT David Mertz wrote: > It feels best to me only to promise order in specific cases like kwargs, > but say nothing (even in 3.6 or 3.7) about the requirement for how dict > itself is implemented. On Saturday, September 10, 2016 6:39:27 AM EDT Barry Warsaw

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Friday, September 9, 2016 4:52:21 PM EDT Brett Cannon wrote: > On Fri, 9 Sep 2016 at 01:58 Antoine Pitrou wrote: > > On Thu, 8 Sep 2016 14:20:53 -0700 > > > > Victor Stinner wrote: > > > 2016-09-08 13:36 GMT-07:00 Guido van Rossum

Re: [Python-Dev] Issues with PEP 482

Hi Mark, Mark Shannon wrote: Hi, I still think that there are several issues that need addressing with PEP 492. This time, one issue at a time :) async The Rationale and Goals of PEP 492 states that PEP 380 has 3 shortcomings. The second of which is: It is not possible to

Re: [Python-Dev] svn.python.org ?

Joseph Armbruster wrote: Is svn.python.org ok? I am unable to perform an update at the moment. Joseph Armbruster Looks like the httpd on svn.python.org is down: telnet svn.python.org 80 Trying 82.94.237.220... telnet: connect to address 82.94.237.220: Connection refused SSH is up,