[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

2021-01-04 Thread Paul Moore 
On Sun, 3 Jan 2021 at 23:38, Nick Coghlan  wrote:
>
> The instance attribute syntax arose from trying to deal with two problems 
> from class patterns in PEP 634:
>
> * "ATTR=TARGET" using "=" to bind to the right instead of to the left
> * no subsequent path to ever offering a syntax for *retrieving* multiple 
> attributes in ordinary expressions outside pattern matching
>
> The minimal fix for the first point would have been just "case object(host=as 
> host, port=as port}:", but that couldn't ever be used to retrieve multiple 
> attributes, as "object(host, port)" is already a function call.

OK, so there's our dispute. Neither of those seem to me to be problems
with PEP 634.

1. I view ATTR=PLACEHOLDER as *equality* with a placeholder that gets
filled in, not a binding that goes left to right. (And no, I don't
have a problem with the rule that the placeholder must be on the
right).
2. I don't see any immediate reason to assume we want to "retrieve
multiple attributes in ordinary expressions". We can easily add a
"match let" statement that did match-style destructuring, why do we
need it to be built in to ordinary assignment (which is what I assume
you mean)?

So IMO you're producing a weird syntax to solve problems I don't
believe exist in the first place. Whereas PEP 634 offers a feature
that I think I would find useful, using a syntax that I find perfectly
comfortable in the context in which it's defined.

Paul
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/X3C46TCWHDLL6AZG3RYEAUCPM3AA4GRU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Where is the SQLite module maintainer

2021-01-04 Thread Steve Dower 

On 12/28/2020 11:32 AM, Erlend Aasland wrote:
On 27 Dec 2020, at 22:38, Christian Heimes > wrote:

How about you put your name in the expert index instead of him? :)


Thanks for your confidence, but I'm far from an expert :)


Neither is anyone else :)

I'm not looking to start any mentoring right now, but if someone else is 
and you're interested, it should be easy to get you connected. I am more 
than happy to endorse you as a good candidate for becoming our SQLite 
expert.


Cheers,
Steve
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/AM7AVQH6L4AQVTB5UFOBYXICDPXYZBKQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Enhancement request for PyUnicode proxies

2021-01-04 Thread Steve Dower 

On 12/29/2020 5:23 PM, Antoine Pitrou wrote:

The third option is to add a distinct "string view" protocol.  There
are peculiarities (such as the fact that different objects may have
different internal representations - some utf8, some utf16...) that
make the buffer protocol suboptimal for this.

Also, we probably don't want unicode-like objects to start being usable
in contexts where a buffer-like object is required (such as writing to
a binary file, or zlib-compressing a bunch of bytes).


I've had to deal with this problem in the past as well (WinRT HSTRINGs), 
and this is the approach that would seem to make the most sense to me.


Basically, reintroduce PyString_* APIs as an _abstract_ interface to 
str-like objects.


So the first line of every single one can be PyUnicode_Check() followed 
by calling the _concrete_ PyUnicode_* implementation. And then we 
develop additional type slots or whatever is necessary for someone to 
build an equivalent native object.


Most "is this a str" checks can become PyString_Check, provided all the 
APIs used against the object are abstract (PyObject_* or PyString_*). 
Those that are going to mess with internals will have to get special 
treatment.


I don't want to make it all sound too easy, because it probably won't 
be. But it should be possible to add a viable proxy layer as a set of 
abstract C APIs to use instead of the concrete ones.


Cheers,
Steve
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/TC3BZJX4DGC2WV32AHIX7A57HQNJ2EMO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Enhancement request for PyUnicode proxies

2021-01-04 Thread Guido van Rossum 
Do you want to be a champion for this development? Or does anyone else want
to volunteer?

On Mon, Jan 4, 2021 at 8:54 AM Steve Dower  wrote:

> On 12/29/2020 5:23 PM, Antoine Pitrou wrote:
> > The third option is to add a distinct "string view" protocol.  There
> > are peculiarities (such as the fact that different objects may have
> > different internal representations - some utf8, some utf16...) that
> > make the buffer protocol suboptimal for this.
> >
> > Also, we probably don't want unicode-like objects to start being usable
> > in contexts where a buffer-like object is required (such as writing to
> > a binary file, or zlib-compressing a bunch of bytes).
>
> I've had to deal with this problem in the past as well (WinRT HSTRINGs),
> and this is the approach that would seem to make the most sense to me.
>
> Basically, reintroduce PyString_* APIs as an _abstract_ interface to
> str-like objects.
>
> So the first line of every single one can be PyUnicode_Check() followed
> by calling the _concrete_ PyUnicode_* implementation. And then we
> develop additional type slots or whatever is necessary for someone to
> build an equivalent native object.
>
> Most "is this a str" checks can become PyString_Check, provided all the
> APIs used against the object are abstract (PyObject_* or PyString_*).
> Those that are going to mess with internals will have to get special
> treatment.
>
> I don't want to make it all sound too easy, because it probably won't
> be. But it should be possible to add a viable proxy layer as a set of
> abstract C APIs to use instead of the concrete ones.
>
> Cheers,
> Steve
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/TC3BZJX4DGC2WV32AHIX7A57HQNJ2EMO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/BXTRBOA5NHZFZWCSTTQM265AHM6V6WJJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Where is the SQLite module maintainer

2021-01-04 Thread Guido van Rossum 
OTOH if you just want to have the PR merged I can do that -- it seems
unobjectionable.

On Mon, Jan 4, 2021 at 8:41 AM Steve Dower  wrote:

> On 12/28/2020 11:32 AM, Erlend Aasland wrote:
> >> On 27 Dec 2020, at 22:38, Christian Heimes  >> > wrote:
> >> How about you put your name in the expert index instead of him? :)
> >
> > Thanks for your confidence, but I'm far from an expert :)
>
> Neither is anyone else :)
>
> I'm not looking to start any mentoring right now, but if someone else is
> and you're interested, it should be easy to get you connected. I am more
> than happy to endorse you as a good candidate for becoming our SQLite
> expert.
>
> Cheers,
> Steve
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/AM7AVQH6L4AQVTB5UFOBYXICDPXYZBKQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/O62IZ2P42T5RKSB6GKMU5DYDTZIKNN7U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Python-ideas] Re: Add venv activate command to the venv modules

2021-01-04 Thread Paul Sokolovsky 
Hello,

On Mon, 4 Jan 2021 21:07:23 +0400
Abdur-Rahmaan Janhangeer  wrote:

> @Christopher Barker 
> 
> You nailed it! I've used the conda activate command many times.
> It should in theory be possible in Python
> 
> @Chris Angelico 
> 
> Yes mere shell commands passing via Py does not work,
> maybe  a file way with results in current shell as @M.-A. Lemburg
> 
> points out, venv already generates the files. On windows it has an
> activate.bat

Knowing that, you're a step away from creating a "subshell" solution
for *yourself*. For POSIX systems, that would be:

venv-shell.sh:

. $1/bin/activate
/bins/sh


Voila!

If you want to add "--shell" switch to "python3 -m venv" with that
functionality, to benefit the whole mankind, not just yourself, I'm +1.
I'd say, you can start writing a patch for that. But I'd warn you that
it likely will be rejected, as it will require a bunch of sustained user
support (i.e. it won't work as expected on various OSes and various
shells).


-- 
Best regards,
 Paul  mailto:[email protected]
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/75KT2J6ESWXZSTC2TEO2YNUX2FG3S4CR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Enhancement request for PyUnicode proxies

2021-01-04 Thread Nelson, Karl E. via Python-Dev 
I would like to second Steve's suggestion.

The requirements for JPype for this to work are pretty minimal.   If there were 
a bit flag for string like that was checked by PyString_Check and then a call 
to the PyObject_Str() which would be guaranteed to return a concrete Unicode 
which is then used  throughout the function call.  This would not require any 
additional slots.   Unfortunately, this doesn't match the other patterns in 
Python as if it passes PyString_Check then why would one need to call a casting 
object to get the actual string.  It could be as simple as making a macro 
PyString_ToUnicode() that calls PyUnicode_Check and if it passes creates a new 
reference else returns PyObject_Str().  It is then just a small matter for 
JString, ObjCStr, WinHTString, etc to set this bit flag when the type is 
created.  The downside of this is that we end up with an extra 
reference/dereference in string using functions, but given ownership concerns 
of a Buffer like protocol this is really the minimum required.

This does not deal with ObjC requirement through as unlike Java, ObjC has 
mutable strings.   There are number of parts of the Python API where the string 
is consumed immediately were immutable and mutable strings do not matter.  But 
others like the hash or dictionary keys require immutable.  So perhaps there 
needs to also be PyString_IsImmutable() so that we can prevent accidentally 
usage of a mutable string.

I would be happy to help with this effort, but I am in the unfortunate position 
that the legal department at my employer (DOE/LLNL) has objected to some clause 
in the PSF Contributor Agreement thus prohibiting me from signing it.   We also 
have a policy that prohibits open source contributions to projects that require 
signing agreements without laboratory legal sign off so I am in a bind until 
such time as I deal with their concerns.

--Karl

-Original Message-
From: Steve Dower  
Sent: Monday, January 4, 2021 8:54 AM
To: [email protected]
Subject: [Python-Dev] Re: Enhancement request for PyUnicode proxies

On 12/29/2020 5:23 PM, Antoine Pitrou wrote:
> The third option is to add a distinct "string view" protocol.  There 
> are peculiarities (such as the fact that different objects may have 
> different internal representations - some utf8, some utf16...) that 
> make the buffer protocol suboptimal for this.
> 
> Also, we probably don't want unicode-like objects to start being 
> usable in contexts where a buffer-like object is required (such as 
> writing to a binary file, or zlib-compressing a bunch of bytes).

I've had to deal with this problem in the past as well (WinRT HSTRINGs), and 
this is the approach that would seem to make the most sense to me.

Basically, reintroduce PyString_* APIs as an _abstract_ interface to str-like 
objects.

So the first line of every single one can be PyUnicode_Check() followed by 
calling the _concrete_ PyUnicode_* implementation. And then we develop 
additional type slots or whatever is necessary for someone to build an 
equivalent native object.

Most "is this a str" checks can become PyString_Check, provided all the APIs 
used against the object are abstract (PyObject_* or PyString_*). 
Those that are going to mess with internals will have to get special treatment.

I don't want to make it all sound too easy, because it probably won't be. But 
it should be possible to add a viable proxy layer as a set of abstract C APIs 
to use instead of the concrete ones.

Cheers,
Steve
___
Python-Dev mailing list -- [email protected] To unsubscribe send an email 
to [email protected] 
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/TC3BZJX4DGC2WV32AHIX7A57HQNJ2EMO/
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/NQSXIJB4GGDYZ6BVEA2IZ4MCAQGCMRFW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.10.0a4 is now available

2021-01-04 Thread Pablo Galindo Salgado 
Happy new year to all of you. I hope you all have a great start of the
year! And how to best celebrate that we have left 2020 behind that with a
new Python alpha release? :)  Go get it here:

https://www.python.org/downloads/release/python-3100a4/


*Major new features of the 3.10 series, compared to 3.9*
Python 3.10 is still in development. This releasee, 3.10.0a4 is the second
of six planned alpha releases.
Alpha releases are intended to make it easier to test the current state of
new features and bug fixes and to test the release process.
During the alpha phase, features may be added up until the start of the
beta phase (2021-05-03) and, if necessary, may be modified or deleted up
until the release candidate phase (2021-10-04). Please keep in mind that
this is a preview release and its use is not recommended for production
environments.

Many new features for Python 3.10 are still being planned and written.
Among the new major
new features and changes so far:

* PEP 623 – Remove wstr from Unicode
* PEP 604 – Allow writing union types as X | Y
* PEP 612 – Parameter Specification Variables
* PEP 626 – Precise line numbers for debugging and other tools.
* bpo-38605: from __future__ import annotations (PEP 563) is now the
default.
* PEP 618 – Add Optional Length-Checking To zip.

(Hey, fellow core developer, if a feature you find important is missing
from this list, let me know.)
The next pre-release of Python 3.10 will be 3.10.0a5, currently scheduled
for 2021-02-01.


*And now for something completely different*
The Majumdar–Papapetrou spacetime

is
one surprising solution of the coupled Einstein-Maxwell equations that
describe a cluster of static charged black holes with the gravitational and
the electrostatic forces cancelling each other out. Each one of these many
black holes of the multi-black holes system has a spherical topology and
follows the Reissner–Nordström metric
.
Unsurprisingly, the movement of a test particle in such spacetime is not
only a very chaotic system but also has some fractals
 hiding the complexity of its movement.

Regards from cold London,
Pablo Galindo Salgado
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/HPZ7Z62WGFZKSFT2Z2G4ZGWGONWFJ6B7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Where is the SQLite module maintainer

2021-01-04 Thread Erlend Aasland 


> On 4 Jan 2021, at 18:24, Guido van Rossum  wrote:
> 
> OTOH if you just want to have the PR merged I can do that -- it seems 
> unobjectionable.

I'm eager to get it merged, so I'll appreciate it if you could help with that.


Erlend
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/EIZNTM5ZH5H6DTYG63SC4MVRAJH7HBJC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Descriptors in dataclasses fields

2021-01-04 Thread Joao S. O. Bueno 
I think you are complicating things just because there is no easy way to
tell mypy
that although you are assigning a descriptor to a class variable
in the class body, it will be used as a normal instance attribute
afterwards - and
it is the type used in the instance attribute that mypy should care for,

And then
maybe, the specs of static type checking could get a feature to allow
assigning one thing at class declaration and another thing at instance
working
(otherwise, not only dataclasses, but anything using custom descriptors
would not work with static type checking).

As a workaround, you could just "cast" our descriptor instance to the
type the attribute will actually hold - mypy should not complain:
```
@dataclass
class Item:
price: Decimal = typing.cast(Decimal, MyDescriptor())

```

On Sun, 3 Jan 2021 at 22:48, Josue Balandrano Coronel 
wrote:

> I've been exploring dataclasses for a few months now and they've proven to
> be very useful.
>
> The only downside is that there's not a simple way to use descriptors.
>
> Descriptors only work on class attributes (as per the docs:
> https://docs.python.org/3/howto/descriptor.html#closing-thoughts). This
> means that to use a descriptor in a data class we have to use
> typing.ClassVar like this
>
> @dataclass
> class Item:
> name: str
> price: typing.ClassVar[Decimal] = PriceValidator()
>
> Which is totally fine because of how descriptors work the previous syntax
> is a feature in dataclasses, IMHO.
>
> But, there's not a straight forward way to pass a value to the descriptor
> on init. Because ClassVars are not used by @dataclass to do its thing (as
> per the docs:
> https://docs.python.org/3/library/dataclasses.html#class-variables)
>
> This means that in the example above `price` is not going to be a
> parameter of the class Item's __init__ method. So the only way to do this
> is to either create an InitVar field or a regular field and then pass the
> value to the descriptor in __post_init__
>
> @dataclass
> class Item:
> name: str
> price_val: InitVar[Decimal]
> price: typing.ClassVar[Decimal] = PriceValidator()
>
> def __post_init__(self, price_val: Decimal) -> None:
> self.price = price_val
>
> When using a regular field we can double the field's purpose by making it
> the field the descriptor is going to use:
>
> @dataclass
> class Item:
> name: str
> _price: Decimal
> price: typing.ClassVar[Decimal] = PriceValidator()
>
> def __post_init__(self) -> None:
> self.price = self._price
>
> And then in the descriptor implement __set_name__ like so:
>
> def __set_name(self, owner, name):
> self.name = f"_{name}"
>
>
> Personally, I don't like either option because it adds noice to the data
> class definition. Using an InitVar is the better option because that
> variable is clearly defined as init only and it's not present in an
> instance. Using a regular field adds unnecessary noice to the data class.
>
> Also, I think it clashes with the intent of descriptors since they're
> supposed to manage their data in any way they want.
>
> My questions are:
>
> - Are my assumptions correct?
> - Is this the intended behavior? Or what's the preferred way of using a
> descriptor in a dataclass field?
> - If this is not intended, could it be possible to add a `descriptor`
> parameter to the `field` method and treat the field accordingly?
>
> I couldn't find any information on the docs or the PEP. I could"ve missed
> something, sorry if this is the case :)
>
> Thanks!
>
> --
> Josue
> https://www.rmcomplexity.com
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/UOMBDIVNRG3DS6UHWSOF4JTLIPXEENCT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/HRIDJO4VX4F4MNOHODMZJNAOV7NP2VL7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Where is the SQLite module maintainer

2021-01-04 Thread Erlend Aasland 


> On 4 Jan 2021, at 17:34, Steve Dower  wrote:
> On 12/28/2020 11:32 AM, Erlend Aasland wrote:
>>> On 27 Dec 2020, at 22:38, Christian Heimes >> > wrote:
>>> How about you put your name in the expert index instead of him? :)
>> Thanks for your confidence, but I'm far from an expert :)
> Neither is anyone else :)
> 
> I'm not looking to start any mentoring right now, but if someone else is and 
> you're interested, it should be easy to get you connected. I am more than 
> happy to endorse you as a good candidate for becoming our SQLite expert.
> 

Thanks, I really appreciate that. I'm willing to invest the time needed if 
someone's interested in mentoring me.


Erlend
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/PRMT36E5WJUREBJVKYHMZQVTKZDQ4QYF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Descriptors in dataclasses fields

2021-01-04 Thread Josue Balandrano Coronel 
Ah, very interesting.

Just tried this and it worked. That's awesome, thanks!

On Mon, Jan 4, 2021, at 15:45, Joao S. O. Bueno wrote:
> I think you are complicating things just because there is no easy way 
> to tell mypy
> that although you are assigning a descriptor to a class variable
> in the class body, it will be used as a normal instance attribute 
> afterwards - and
> it is the type used in the instance attribute that mypy should care for,
> 
> And then 
> maybe, the specs of static type checking could get a feature to allow
> assigning one thing at class declaration and another thing at instance working
> (otherwise, not only dataclasses, but anything using custom descriptors
> would not work with static type checking).
> 
> As a workaround, you could just "cast" our descriptor instance to the
> type the attribute will actually hold - mypy should not complain:
> ```
> @dataclass
> class Item:
> price: Decimal = typing.cast(Decimal, MyDescriptor())
> 
> ```
> 
> On Sun, 3 Jan 2021 at 22:48, Josue Balandrano Coronel 
>  wrote:
> > I've been exploring dataclasses for a few months now and they've proven to 
> > be very useful.
> > 
> > The only downside is that there's not a simple way to use descriptors.
> > 
> > Descriptors only work on class attributes (as per the docs: 
> > https://docs.python.org/3/howto/descriptor.html#closing-thoughts). This 
> > means that to use a descriptor in a data class we have to use 
> > typing.ClassVar like this
> > 
> > @dataclass
> > class Item:
> > name: str
> > price: typing.ClassVar[Decimal] = PriceValidator()
> > 
> > Which is totally fine because of how descriptors work the previous syntax 
> > is a feature in dataclasses, IMHO.
> > 
> > But, there's not a straight forward way to pass a value to the descriptor 
> > on init. Because ClassVars are not used by @dataclass to do its thing (as 
> > per the docs: 
> > https://docs.python.org/3/library/dataclasses.html#class-variables)
> > 
> > This means that in the example above `price` is not going to be a parameter 
> > of the class Item's __init__ method. So the only way to do this is to 
> > either create an InitVar field or a regular field and then pass the value 
> > to the descriptor in __post_init__
> > 
> > @dataclass
> > class Item:
> > name: str
> > price_val: InitVar[Decimal]
> > price: typing.ClassVar[Decimal] = PriceValidator()
> > 
> > def __post_init__(self, price_val: Decimal) -> None:
> > self.price = price_val
> > 
> > When using a regular field we can double the field's purpose by making it 
> > the field the descriptor is going to use:
> > 
> > @dataclass
> > class Item:
> > name: str
> > _price: Decimal
> > price: typing.ClassVar[Decimal] = PriceValidator()
> > 
> > def __post_init__(self) -> None:
> > self.price = self._price
> > 
> > And then in the descriptor implement __set_name__ like so:
> > 
> > def __set_name(self, owner, name):
> > self.name = f"_{name}"
> > 
> > 
> > Personally, I don't like either option because it adds noice to the data 
> > class definition. Using an InitVar is the better option because that 
> > variable is clearly defined as init only and it's not present in an 
> > instance. Using a regular field adds unnecessary noice to the data class.
> > 
> > Also, I think it clashes with the intent of descriptors since they're 
> > supposed to manage their data in any way they want.
> > 
> > My questions are:
> > 
> > - Are my assumptions correct?
> > - Is this the intended behavior? Or what's the preferred way of using a 
> > descriptor in a dataclass field?
> > - If this is not intended, could it be possible to add a `descriptor` 
> > parameter to the `field` method and treat the field accordingly?
> > 
> > I couldn't find any information on the docs or the PEP. I could"ve missed 
> > something, sorry if this is the case :)
> > 
> > Thanks!
> > 
> > --
> > Josue
> > https://www.rmcomplexity.com
> > ___
> > Python-Dev mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at 
> > https://mail.python.org/archives/list/[email protected]/message/UOMBDIVNRG3DS6UHWSOF4JTLIPXEENCT/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/HRIDJO4VX4F4MNOHODMZJNAOV7NP2VL7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

-- 
https://www.rmcomplexity.com
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://m

[Python-Dev] Re: Descriptors in dataclasses fields

2021-01-04 Thread Josue Balandrano Coronel 
Then this is more of an issue with type hints rather than dataclasses. 
Interesting.

On Mon, Jan 4, 2021, at 16:01, Josue Balandrano Coronel wrote:
> Ah, very interesting.
> 
> Just tried this and it worked. That's awesome, thanks!
> 
> On Mon, Jan 4, 2021, at 15:45, Joao S. O. Bueno wrote:
> > I think you are complicating things just because there is no easy way 
> > to tell mypy
> > that although you are assigning a descriptor to a class variable
> > in the class body, it will be used as a normal instance attribute 
> > afterwards - and
> > it is the type used in the instance attribute that mypy should care for,
> > 
> > And then 
> > maybe, the specs of static type checking could get a feature to allow
> > assigning one thing at class declaration and another thing at instance 
> > working
> > (otherwise, not only dataclasses, but anything using custom descriptors
> > would not work with static type checking).
> > 
> > As a workaround, you could just "cast" our descriptor instance to the
> > type the attribute will actually hold - mypy should not complain:
> > ```
> > @dataclass
> > class Item:
> > price: Decimal = typing.cast(Decimal, MyDescriptor())
> > 
> > ```
> > 
> > On Sun, 3 Jan 2021 at 22:48, Josue Balandrano Coronel 
> >  wrote:
> > > I've been exploring dataclasses for a few months now and they've proven 
> > > to be very useful.
> > > 
> > > The only downside is that there's not a simple way to use descriptors.
> > > 
> > > Descriptors only work on class attributes (as per the docs: 
> > > https://docs.python.org/3/howto/descriptor.html#closing-thoughts). This 
> > > means that to use a descriptor in a data class we have to use 
> > > typing.ClassVar like this
> > > 
> > > @dataclass
> > > class Item:
> > > name: str
> > > price: typing.ClassVar[Decimal] = PriceValidator()
> > > 
> > > Which is totally fine because of how descriptors work the previous syntax 
> > > is a feature in dataclasses, IMHO.
> > > 
> > > But, there's not a straight forward way to pass a value to the descriptor 
> > > on init. Because ClassVars are not used by @dataclass to do its thing (as 
> > > per the docs: 
> > > https://docs.python.org/3/library/dataclasses.html#class-variables)
> > > 
> > > This means that in the example above `price` is not going to be a 
> > > parameter of the class Item's __init__ method. So the only way to do this 
> > > is to either create an InitVar field or a regular field and then pass the 
> > > value to the descriptor in __post_init__
> > > 
> > > @dataclass
> > > class Item:
> > > name: str
> > > price_val: InitVar[Decimal]
> > > price: typing.ClassVar[Decimal] = PriceValidator()
> > > 
> > > def __post_init__(self, price_val: Decimal) -> None:
> > > self.price = price_val
> > > 
> > > When using a regular field we can double the field's purpose by making it 
> > > the field the descriptor is going to use:
> > > 
> > > @dataclass
> > > class Item:
> > > name: str
> > > _price: Decimal
> > > price: typing.ClassVar[Decimal] = PriceValidator()
> > > 
> > > def __post_init__(self) -> None:
> > > self.price = self._price
> > > 
> > > And then in the descriptor implement __set_name__ like so:
> > > 
> > > def __set_name(self, owner, name):
> > > self.name = f"_{name}"
> > > 
> > > 
> > > Personally, I don't like either option because it adds noice to the data 
> > > class definition. Using an InitVar is the better option because that 
> > > variable is clearly defined as init only and it's not present in an 
> > > instance. Using a regular field adds unnecessary noice to the data class.
> > > 
> > > Also, I think it clashes with the intent of descriptors since they're 
> > > supposed to manage their data in any way they want.
> > > 
> > > My questions are:
> > > 
> > > - Are my assumptions correct?
> > > - Is this the intended behavior? Or what's the preferred way of using a 
> > > descriptor in a dataclass field?
> > > - If this is not intended, could it be possible to add a `descriptor` 
> > > parameter to the `field` method and treat the field accordingly?
> > > 
> > > I couldn't find any information on the docs or the PEP. I could"ve missed 
> > > something, sorry if this is the case :)
> > > 
> > > Thanks!
> > > 
> > > --
> > > Josue
> > > https://www.rmcomplexity.com
> > > ___
> > > Python-Dev mailing list -- [email protected]
> > > To unsubscribe send an email to [email protected]
> > > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > > Message archived at 
> > > https://mail.python.org/archives/list/[email protected]/message/UOMBDIVNRG3DS6UHWSOF4JTLIPXEENCT/
> > > Code of Conduct: http://python.org/psf/codeofconduct/
> > ___
> > Python-Dev mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> > https://mail.python.org/mailman3/lists/python-dev.pytho