Keep MISSING.
On Dec 28, 2017 8:44 AM, "Yury Selivanov" wrote:
> On Thu, Dec 28, 2017 at 4:51 AM, Victor Stinner
> wrote:
> > Hi,
> >
> > I like the new version of the PEP using "read only mapping" and
> > copy_context(). It's easier to understand.
>
> Thanks, Victor!
>
> >
> > I'm ok with seei
I don't think the language definition should be judgmental here. The
semantics are unambiguous.
On Dec 28, 2017 11:38 AM, "Serhiy Storchaka" wrote:
> 28.12.17 16:38, Guido van Rossum пише:
>
>> Looks to me the prohibition was to prevent a crash. It makes more sen
y the category killer on PyPI. So we
are IMO taking the best course possible given that we want something in the
stdlib but not exactly attrs.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.
But you always inherit __repr__, from object. The base class might also
itself be a dataclass. I think it should only skip when the decorated class
itself defines __repr__.
On Dec 29, 2017 3:47 AM, "Antoine Pitrou" wrote:
> On Fri, 29 Dec 2017 02:23:56 -0800
> Ethan Smith wrote:
> >
> > In a fe
I still think it should overrides anything that's just inherited but
nothing that's defined in the class being decorated.
On Dec 29, 2017 5:43 PM, "Nathaniel Smith" wrote:
> On Fri, Dec 29, 2017 at 12:30 PM, Ethan Furman wrote:
> > Good point. So auto-generate a new __repr__ if:
> >
> > - one
M, "Ethan Smith" wrote:
>
>
> On Fri, 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.
>>
>>
> Could y
This being a security issue I think it's okay to break 3.6. might even
backport to 3.5 if it's easy?
On Dec 29, 2017 1:59 PM, "Christian Heimes" wrote:
> Hi,
>
> tl;dr
> This mail is about internationalized domain names and TLS/SSL. It
> doesn't concern you if you live in ASCII-land. Me and a co
I was wondering is if the child will know about all the fields in the
> parent -- so it could make a full __repr__.
>
Yes, there's a class variable (__dataclass_fields__) that identifies the
parent fields. The PEP doesn't mention this or the fact that special
methods (like
by var.get(), when get() is called without the
> default parameter."
>
> Victor
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/m
ntext", there is only a "current context data" in
>> the current Python thread. There is no need for a concrete context instance
>> to store variable variables values. It's also hard to understand that in
>> the PEP.
>>
>>
>
On Tue, Jan 2, 2018 at 4:45 PM, Victor Stinner
wrote:
> Le 2 janv. 2018 18:57, "Guido van Rossum" a écrit :
>
> Oh, the "Specification" section in the PEP is too brief on several of
> these subjects. It doesn't really specify what var.get() does if the
t manager that sets and restores a context
variable (like in `with decimal.localcontext()`). Handling double resets is
about as useful as specifying what happens if __exit__ is called twice.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailin
_
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
>> yselivanov.ml%40gmail.com
>>
>
--
--Guido van Rossum
the *first* example in the doc. But here contextvars is different
> since there is no API to get the current API. The lack of API to access
> directly the current contextvars context is the main difference with
> decimal context, and I'm fine with that.
>
> It's easy to see a parallel since decimal context can be copied using
> Context.copy(), it has also multiple (builtin) "variables", it's just that
> the API is different (decimal context variables are modified as
> attributes), and it's possible to set a context using
> decimal.setcontext().
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Wed, Jan 3, 2018 at 12:32 PM, Glenn Linderman
wrote:
> On 1/3/2018 11:16 AM, Guido van Rossum wrote:
>
> Maybe I should clarify again what run() does. Here's how I think of it in
> pseudo code:
>
> def run(self, func, *args, **kwds):
> old = _get_current_cont
> Neil
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
--
--Guido van Ros
t (in the thread state). I don't have time right now to respond in
more detail, sorry for shedding darkness. :-( Hopefully I'll have time
Friday.
On Wed, Jan 3, 2018 at 4:25 PM, Victor Stinner
wrote:
> 2018-01-03 23:01 GMT+01:00 Guido van Rossum :
> > Heh, you're right, I fo
assertNotIn(name, context)
>
> def func2():
> assert name.get() == 'yury'
> assert context[name] == 'yury'
>
> context = contextvars.copy_context()
>
> assert name.get() == 'name'
> assertNotIn(name, context)
>
> context.run(func1)
>
On Thu, Jan 4, 2018 at 3:25 AM, Paul Moore wrote:
> On 4 January 2018 at 00:17, Greg Ewing
> wrote:
> > Guido van Rossum wrote:
> >>
> >> contextvars.copy_context().run(func, )
> >
> > If contexts are immutable, why is there something
> > called c
that I didn't say anything about HAMTs here, because that's
> orthogonal implementation detail. It would make perfect sense to have
> Context be an opaque wrapper around a regular dict; it would just give
> different performance trade-offs.)
>
Agreed, that's how the PEP pseud
On Thu, Jan 4, 2018 at 9:27 AM, Paul Moore wrote:
> On 4 January 2018 at 15:56, Guido van Rossum wrote:
> > It was get_context() in an earlier version of PEP 567. We changed it to
> > copy_context() believing that that would clarify that you get a clone
> that
> > is
On Thu, Jan 4, 2018 at 4:56 PM, Greg Ewing
wrote:
> Guido van Rossum wrote:
>
>> It was get_context() in an earlier version of PEP 567. We changed it to
>> copy_context() believing that that would clarify that you get a clone that
>> is unaffected by subsequent ContextVar
18 PM, Nathaniel Smith wrote:
> On Thu, Jan 4, 2018 at 8:30 AM, Guido van Rossum wrote:
> > On Wed, Jan 3, 2018 at 6:35 PM, Nathaniel Smith wrote:
> >> - Context is a mutable object representing a mapping
> >> - BUT it doesn't allow mutation through the MutableMap
We should interview you for the paper we may be writing for HOPL.
On Wed, Jan 3, 2018 at 6:05 PM, Neil Schemenauer
wrote:
> On 2018-01-03, Guido van Rossum wrote:
> > I'm sorry, I don't think more research can convince me either way.
> > I want all three of return/brea
that I suspect answers to questions like this will be obvious.
>
In the other thread I think we've clarified what the (im)mutability status
of Context is. I don't think we need Victor's implementation either and I
agree with Paul that the PEP just needs a better specification /
d
do for asyncio.Task --
constructing the task calls copy_context() _step() is always wrapped in a
run() call for that context.
(This was a good question because it teases out more of the semantics of
Context.run().)
--
--Guido van Rossum (python.org/~guido)
___
tasks. But I don't see
a use case for mutating a Context object that's not the current context,
and when it is the current context, ContextVar.set() is more direct. I also
don't see use cases for other MutableMapping methods like pop() or
update(). (And clear()
On Thu, Jan 4, 2018 at 7:58 PM, Nathaniel Smith wrote:
> On Thu, Jan 4, 2018 at 6:09 PM, Guido van Rossum wrote:
> > However you've not convinced me that it would be better to make Context
> > implement the full MutableMapping interface (with `__delitem__` always
> &g
r on the tracker). It was never implemented and I think it
shouldn't be. So we might as well update the PEP. It wouldn't be
particularly useful, since (by definition) the function that declares the
nonlocal variable is not its owner, and hence it's unlikely to make sense
to initia
On Fri, Jan 5, 2018 at 5:08 AM, Eric V. Smith wrote:
> On 1/2/2018 12:01 AM, Guido van Rossum wrote:
>
>> Yes, there's a class variable (__dataclass_fields__) that identifies the
>> parent fields. The PEP doesn't mention this or the fact that special
>> method
() is inherited from Mapping.get(); if
you want it to raise use Context.__getitem__() (i.e. ctx[var]). Lots of
classes define get() methods with various behaviors. Context.get() and
ContextVar.get() are just different -- ContextVar is not a Mapping.
--
--Gui
On Fri, Jan 5, 2018 at 2:41 AM, Paul Moore wrote:
> On 4 January 2018 at 23:58, Guido van Rossum wrote:
> > Do you have a specific proposal for a wording change? PEP 567 describes
> > Context as "a read-only mapping, implemented using an immutable
> dictionary."
>
... you need to use the
> ContextVar.set() method from Context.run()" would be OK, although I
> don't want the summary to get too long.
>
(Sorry, I wrote my previous response before seeing this part of the
exchange.)
Maybe "... you need to use the ContextVar.set() method, which
d Tries (HAMT). They allow for O(log N)
> > ``set`` operation, and for O(1) ``copy_context()`` function, where
> > *N* is the number of items in the dictionary. For a detailed
> > analysis of HAMT performance please refer to :pep:`550` [1]_.
>
> Would it be
ede I have no use case so I'll drop it.
On Fri, Jan 5, 2018 at 8:43 AM, Eric V. Smith wrote:
> On 1/5/2018 11:24 AM, Guido van Rossum wrote:
>
>> On Fri, Jan 5, 2018 at 5:08 AM, Eric V. Smith > <mailto:e...@trueblade.com>> wrote:
>>
>> On 1/2/2018
5, 2018, at 10:47, Guido van Rossum wrote:
> > I don't recall (though someone with more time might find the discussion
> in
> > the archives or on the tracker). It was never implemented and I think it
> > shouldn't be. So we might as well update the PEP. It wouldn't
I'm normally no big fan of things that take either a class or an instance,
but since fields() does this, I think is_dataclass() should to. And that's
the name I'd choose. OK on the pseudo-fields.
On Fri, Jan 5, 2018 at 11:06 AM, Eric V. Smith wrote:
> On 1/5/2018 12:58 PM
ri, Jan 5, 2018 at 7:47 AM, Guido van Rossum wrote:
> > I don't recall (though someone with more time might find the discussion
> in
> > the archives or on the tracker). It was never implemented and I think it
> > shouldn't be. So we might as well update the
On Fri, Jan 5, 2018 at 2:43 PM, Chris Jerdonek
wrote:
> On Fri, Jan 5, 2018 at 8:29 AM, Guido van Rossum wrote:
> > On Fri, Jan 5, 2018 at 2:05 AM, Victor Stinner >
> > wrote:
> >>
> >> Currently, Context.get(var) returns None when "var in cont
ython.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org
:^) tis...@stackless.com
> Software Consulting : http://www.stackless.com/
> Karl-Liebknecht-Str. 121 : https://github.com/PySide
> 14482 Potsdam: GPG key -> 0xFB7BEE0E
> phone +49 173 24 18 776 fax +49 (30) 700143-0023
>
>
> ___
> P
te_shell=True?)
> to match the normal user expectations without using the shell?
>
That feels like a terrible idea to me. How do you define "normal user
expectations" here? If people want shell builtins they should just use
shell=True
e
are cases where a user did write an explicit __ne__ that needs to be
overridden) I would recommend the following rule:
- If there's an __eq__, don't do anything (regardless of whether there's an
__ne__)
- If there no __eq__ but there is an __ne__, generate __eq__ but
rst one being 'a b' and the second one 'c'.
At this point I can understand that Christian recommends against shell=True
-- it's totally messed up! But the fix should really be to fix this, not
inventing a new feature.
--
--Guido van Rossum (python.org/~guido)
27;m +1 for this one.
>
>
> 5. PEP language.
>
> I agree that PEP is vague about some details and is incorrect in some
> places (like calling Context objects immutable, which is not really
> true, because .run() can modify them). I'll fix the language in v3
> once I'm
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
_
sn't create a variable, only "x = None".
>>
>> It's not possible to define a thread local variable without specifying
>> a "default" value neither.
>>
>> Victor
>>
>
> _______
> Py
lier
>> discussions). However, at this point, I'd probably need a lot of help to
>> make that happen for 3.7.
>>
>> -- Koos
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/yselivano
>> v.ml%40gmail.com
>>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
t; —Koos
>
>
> On Wed, Jan 10, 2018 at 6:21 PM, Guido van Rossum
> wrote:
>
>> The current status of PEP 555 is "Withdrawn". I have no interest in
>> considering it any more, so if you'd rather see a decision from me I'll be
>> happy to change it
uot;variable" or "name", the
> current design makes sense (at least to me).
>
> Paul
> _______
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https:/
r reset() I wouldn't know what
the use case for idempotency would be.)
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
;s like the
old RPC transparency problem, which was never solved IIRC. There are just
too many things you need to be aware of before you can successfully offload
something to a different process.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev m
ant) version -- it makes it clear to the human reader of the
code which variable is being reset. And it's not like it's going to be used
that much -- it'll be likely hidden inside a context manager.
--
--Guido van Rossum (python.org/~guido)
_
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>
--
--Guido van Rossum (python.org/~guido)
_
Perhaps you can update the PEP with a summary of the rejected ideas from
this thread?
On Jan 17, 2018 7:23 AM, "Yury Selivanov" wrote:
> On Wed, Jan 17, 2018 at 6:03 AM, Antoine Pitrou
> wrote:
> > On Tue, 16 Jan 2018 17:18:06 -0800
> > Nathaniel Smith wrote:
> >> On Tue, Jan 16, 2018 at 5:06
ked before
then. Please don't rehash issues that have already been debated -- we're
unlikely to reach a different conclusion upon revisiting the same issue
(read the Rejected Ideas section first).
--
--Guido van Rossum (python.org/~guido)
___
Pyt
v mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Not so fast. I think a PEP is still needed. This change has more
repercussions than argument clinic, e.g. it affects 3rd party tooling and
bytecode.
On Jan 19, 2018 17:00, "Terry Reedy" wrote:
> On 1/19/2018 4:49 PM, Mario Corchero wrote:
>
>> I am happy to put some work into this (and Pablo Gal
ctions in the curses module) don't
inspire a lot of copy-cat APIs.
OTOH the more plain positional-only arguments are a pretty common need --
for example, for methods that are conventionally used that way, and
overridden with disregard for argument names.
(IOW I agree with you here. ;-)
--
-
On Sat, Jan 20, 2018 at 1:25 AM, Mario Corchero wrote:
> OK, if no one has anything against, Pablo and I can start a PEP just for
> the ‘/‘ simple syntax (without the argument group part).
>
Go for it!
Note that your target will be Python 3.8.
--
--Guido van Rossum (python.o
t; Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Yury,
I am hereby *accepting* the latest version of PEP 567[1]. Congrats!
--Guido
[1]
https://github.com/python/peps/commit/a459539920b9b8c8394ef61058e88a076ef8b133#diff-9d0ccdec754459da5f665cc6c6b2cc06
On Fri, Jan 19, 2018 at 9:30 AM, Guido van Rossum wrote:
> There has been useful
inferred trivially.
>
>
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/jell
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
>
> Mark Lawrence
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/
https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>>
> ___
> python-committers mailing list
> python-committ...@python.org
> https://mail.python
Cool trick! Works on Sierra too. I guess it's all part of Apple's drive to
merge iOS and OS X...
On Sat, Jan 27, 2018 at 2:12 PM, Barry Warsaw wrote:
> On Jan 27, 2018, at 17:04, Guido van Rossum wrote:
>
>
> Hardly a surprising choice! Congrats, Łukasz. (And never forg
Dalke from usenet posts.
>
> Read on, this is pretty fascinating: https://twitter.com/dabeaz/status/
> 934590421984075776
>
> - Ł
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.p
the
> wild (on PyPI or some such), it behooves us to think through all the
> usability issues. To me at least, the tri-state hashability was entirely
> unexpected and hard to debug -- I had to do a close reading of the source
> to figure-out what was happening.
>
>
> Raymond
&g
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
_
I was going to argue, but it's not worth it. What you propose is fine.
On Sun, Jan 28, 2018 at 10:03 PM, Nick Coghlan wrote:
> On 29 January 2018 at 14:43, Guido van Rossum wrote:
> > So why can't you just run "make test" if that's faster?
>
> I can (and
nt, setting hash=False or hash=True is much quicker than trying
to understand the rules. But the rules *are* deterministic and reasonable.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
> 40python.org
>
--
--Guido van Rossum (python.org/~guid
.com/scan.php?page=news_item&px=Fedora-
> 28-libxcrypt-Plans
> [3] https://github.com/besser82/libxcrypt
> [4] https://bugs.python.org/issue32635
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/ma
ython-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
what your desired outcome is anyway?
On Sat, Feb 3, 2018 at 4:07 AM, Christian Heimes
wrote:
> On 2018-02-02 17:18, Guido van Rossum wrote:
> > I'm all for nudging people in the direction of xcrypt. I assume we can't
> > just switch the C-level crypt with xcrypt and
e *not* equivalent (consider a tuple containing a list) I'm
not at all convinced that any API in the core language should "reflect"
this misconception, depending on how you meant that.
--
--Guido van Rossum (python.org/~guido)
___
P
b 4, 2018 at 5:54 PM, Nick Coghlan wrote:
> On 5 February 2018 at 08:31, Guido van Rossum wrote:
> > On Sun, Feb 4, 2018 at 11:59 AM, Chris Barker - NOAA Federal
> > wrote:
> >>
> >> I think the folks that are concerned about this issue are quite right
> >
n from
StackOverflow anyway. The docs can point to frozen=True and explain the
danger.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://
I'm sorry, but a solution that requires __class__ assignment is way too
fragile for my taste.
On Mon, Feb 5, 2018 at 6:28 AM, Nick Coghlan wrote:
> On 5 February 2018 at 15:49, Guido van Rossum wrote:
> > My point is that once you have one of those patterns in place, changing
&
If there's going to be an API for it, it should be in the class, not
something that mutates the class afterwards.
On Mon, Feb 5, 2018 at 1:59 AM, Kirill Balunov
wrote:
> On Sun, Feb 4, 2018, 9:50 PM Guido van Rossum <https://mail.python.org/mailman/listinfo/python-dev>> wrote:
Yes, that's what I meant -- "afterwards" meaning after the @dataclass
decorator is applied.
On Mon, Feb 5, 2018 at 11:09 AM, Kirill Balunov
wrote:
>
> 2018-02-05 20:47 GMT+03:00 Guido van Rossum :
>
>> If there's going to be an API for it, it should be
an burden all uses of the hash
> parameter, good and bad, with the unsafe label.
>
>
> --
> Steve
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://ma
). It will also disregard fields declared using
field(compare=False, hash=False|None).
On Tue, Feb 6, 2018 at 10:11 AM, Ethan Furman wrote:
> On 02/06/2018 09:38 AM, Guido van Rossum wrote:
>
> Where do you get the impression that one would have to explicitly request
>> __hash__
Honestly, the name I would most want for the keyword argument is '_hash'.
> That carries the semantics I desire.
>
> On Feb 6, 2018 10:13 AM, "Ethan Furman" wrote:
>
>> On 02/06/2018 09:38 AM, Guido van Rossum wrote:
>>
>> Where do you get the impre
s(frozen=True)) -- nothing we can do about the
*field* will change this.
Of course if you use @dataclass(frozen=True, unsafe_hash=True) you may
still get a safe hash. :-)
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python
quest. Let's wait whether it's
actually needed a lot before designing it.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail
(None).
>
> --
> Eric
>
> On Feb 5, 2018, at 12:49 AM, Guido van Rossum wrote:
>
> Looks like this is turning into a major flamewar regardless of what I say.
> :-(
>
> I really don't want to lose the ability to add a hash function to a
> mutable dataclass by f
I'm not a fan, sorry.
On Tue, Feb 6, 2018 at 7:33 PM, Ethan Furman wrote:
> On 02/06/2018 06:48 PM, Guido van Rossum wrote:
>
> That seems a rare case (though I hadn't thought of it). I had thought of
>> the use case where you want a frozen type
>> without
?
Also, a small example that demonstrates your need would do wonders to help
us understand your use case better.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Why can'y you make `name` on `NamedObjectItem` a property that returns `
self.obj.name`? Why store a duplicate copy of the name?
PS. I have to ponder why frozen dataclasses don't use `__new__`.
On Fri, Feb 16, 2018 at 11:43 PM, Ben Lewis wrote:
> On Sat, Feb 17, 2018 at 6:40
fields['j'] = database.lookup('j')
>
> I personally see two problems with this idea:
> 1. This isn't as ergonomic as __post_init__ is as its modifing a
> dictionary instead of its instance.
> 2. To implement this, it would require a metaclass.
>
wrote:
> On 18 February 2018 at 14:10, Guido van Rossum wrote:
> > Agreed the __pre_init__ idea is no improvement. I think we're back where
> you
> > started -- just use `object.__setattr__` to set the attribute in
> > `__post_init__`. That's what the PEP says is
then wanting it hashable.
>
> Which pointed to the idea of a “ freeze this from now on” method.
>
> This seems another use case — maybe it would be helpful to be able to
> freeze an instance after creation for multiple use-cases?
>
> -CHB
>
--
On Mon, Feb 19, 2018 at 8:16 PM, Glenn Linderman
wrote:
> On 2/19/2018 7:02 PM, Guido van Rossum wrote:
>
> But how?
>
> On Mon, Feb 19, 2018 at 5:06 PM, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
>
>> ... maybe it would be helpful to be ab
solutions now that people can implement as
separate class decorators and distribute via PyPI (or copy into their own
codebase) so I don't think now's the time to consider adding this to
dataclasses. Maybe for Python 3.8.
--
--Guido van Rossum (python.org/~guido)
_
On Tue, Feb 20, 2018 at 1:37 PM, Eric V. Smith wrote:
> On 2/17/2018 2:35 PM, Guido van Rossum wrote:
>
>> PS. I have to ponder why frozen dataclasses don't use `__new__`.
>>
>
> As I'm sure everyone is now aware after the rest of this discussion: it's
>
ido said "no" to this from the outset.
>
I'm willing to reconsider if there's a good enough tool. Ditto for C code
(or do we already do it for C?).
FWIW I'm personally hugely happy with the new workflow -- my only regret is
that we're not using GitHub for issue tra
volunteer steps up we might consider it (a PEP would
have to be written).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.or
ion
>
> chris.bar...@noaa.gov
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>
n't respond to this thread.
--Guido
On Wed, Feb 21, 2018 at 7:03 PM, Dan Stromberg wrote:
> On Wed, Feb 21, 2018 at 2:19 PM, Barry Warsaw wrote:
> > On Feb 21, 2018, at 13:22, Guido van Rossum wrote:
> >>
> >> I'm willing to reconsider if there's a
501 - 600 of 6462 matches
Mail list logo
