On 2021-12-08 23:12, Chris Angelico wrote:
On Thu, Dec 9, 2021 at 5:52 PM Brendan Barnwell wrote:
To try stating this in yet another way, currently if I have:
def f(a=)
must be something that evaluates to a first-class
object, and the "argument default" IS that first-class ob
On 2021-12-08 23:22, Chris Angelico wrote:
On Thu, Dec 9, 2021 at 5:54 PM Brendan Barnwell wrote:
On 2021-12-08 20:36, Chris Angelico wrote:
> Remember, though: The comparison should be to a function that looks like this:
>
> def f(a=[], b=_SENTINEL1, c=_SENTINEL2, d=_SENTINEL3):
> if b i
On 09/12/2021 08:38, Brendan Barnwell wrote:
Your definition is somewhat circular, because you say that a
default is "anything that provides a default". But that says "default"
again. So what is a default?
This seems somewhat disingenuous. A "default" is anything that provides
a value
On Wed, 8 Dec 2021 at 23:40, Chris Angelico wrote:
>
> I have attempted to explain the syntax. What is confusing?
>
> def f(x=spam): ...
>
> def f(x=>spam): ...
Are we using the term "confusing" in different ways? I'm saying that
it's easy to confuse the two forms = and =>, as they look very
simi
On Thu, 9 Dec 2021 at 06:49, Christopher Barker wrote:
>
> (I started writing this this morning, and there’s been quite a bit more
> discussion since, but I don’t think it’s completely too late)
Your email client is doing "white on white" again. You should try to
get that fixed :-(
I agree, wit
We seem to be arguing in circles and talking past each other here about
nomenclature:
f(arg=>dflt)
What does it matter if we call it "a default" or "just behaviour in the
function" or "a Jabberwocky" or ""?
The RELEVANT question should be "Is it useful"?
Best wishes
Rob Cliffe
On 09/12/20
On Thu, Dec 9, 2021 at 7:07 PM Brendan Barnwell wrote:
>
> On 2021-12-08 23:12, Chris Angelico wrote:
> > On Thu, Dec 9, 2021 at 5:52 PM Brendan Barnwell
> > wrote:
> >> To try stating this in yet another way, currently if I have:
> >>
> >> def f(a=)
> >>
> >> must be something
On Thu, Dec 9, 2021 at 8:45 PM Paul Moore wrote:
>
> On Wed, 8 Dec 2021 at 23:40, Chris Angelico wrote:
> >
> > I have attempted to explain the syntax. What is confusing?
> >
> > def f(x=spam): ...
> >
> > def f(x=>spam): ...
>
> Are we using the term "confusing" in different ways? I'm saying tha
On Thu, 9 Dec 2021 at 11:51, Chris Angelico wrote:
>
> Are = and := confusing? They are also very similar, and they have some
> subtle distinctions. Is it a problem for two different operators to
> look similar when they do very similar things?
Maybe. I don't use assignment expressions - I don't
On Thu, Dec 9, 2021 at 12:12 AM Paul Bryan wrote:
> On Thu, 2021-12-09 at 12:32 +1100, Steven D'Aprano wrote:
>
> On Wed, Dec 08, 2021 at 09:45:35AM -0800, Paul Bryan wrote:
>
> I propose there is already a viable option in typing.Annotated.
> Example:
>
> @dataclass
> class InventoryItem:
>
Hi all,
the PEP-671 thread is starting to accumulate an awful lot of heat. I’ve placed
the list into emergency moderation for the day to give everyone a chance to
take a step back and (re)consider their next e-mails. Thank you!
best,
—titus
(list moderator)
___
I'm using docstrings bellow the attributes (analogous to functions and
classes), I think it works well.
It helps with distinguishing the class docstring from the arguments.
On 2021-12-08 13:25:55, Ricky Teachey wrote:
> On Wed, Dec 8, 2021 at 1:20 PM Paul Bryan wrote:
> > I believe a Annotated[..
On Thu, Dec 9, 2021 at 11:08 AM Simão Afonso <
[email protected]> wrote:
> Shouldn't typing be encouraged on dataclasses, at least?
Typing shouldn’t be encouraged for any particular class, nor the language
itself. Typing policy is a matter for the project/organization to decide.
On Thu, Dec 9, 2021 at 3:08 PM Christopher Barker
wrote:
> On Thu, Dec 9, 2021 at 11:08 AM Simão Afonso <
> [email protected]> wrote:
>
>> Shouldn't typing be encouraged on dataclasses, at least?
>
>
> Typing shouldn’t be encouraged for any particular class, nor the language
> itse
Hi, I would like to hear the opinion of Python's community on enforcing
types in the future for the language. I've been using Python as my main
language for everything for around 10 years, until I started moving to Rust
2 years ago; one of the main factors was types.
Just before moving to Rust I s
On Thu, 2021-12-09 at 19:01 +, Simão Afonso wrote:
> I'm using docstrings bellow the attributes (analogous to functions
> and
> classes), I think it works well.
> It helps with distinguishing the class docstring from the arguments.
I think you'll find on close inspection that those strings don
Please, no, No, NO!
It has always been the policy that typing is, and will remain, optional.
On 09/12/2021 20:32, deavid wrote:
Hi, I would like to hear the opinion of Python's community on
enforcing types in the future for the language. I've been using Python
as my main language for everything
On Thu, Dec 9, 2021 at 3:23 PM Ricky Teachey wrote:
> On Thu, Dec 9, 2021 at 3:08 PM Christopher Barker
> wrote:
>
>> On Thu, Dec 9, 2021 at 11:08 AM Simão Afonso <
>> [email protected]> wrote:
>>
>>> Shouldn't typing be encouraged on dataclasses, at least?
>>
>>
>> Typing shouldn
Oops sorry accidentally sent mid typing:
```
class Array:
def __class_getitem__(cls, size):
# I know this usage is discouraged
if hasattr(cls, 'size'):
raise TypeError('cannot resive type')
return type(cls)(f'Array[{size}]', (), {'size': size})
def __ne
On Thu, 9 Dec 2021 at 20:55, deavid wrote:
>
> So well, my question here is: why is this not a thing? Has anyone proposed
> something like this before? I feel I must have missed something important.
IMO, making types mandatory would severely penalise the use of Python
for scripting, exploratory
Title: Python standard library TOML module
Hello everyone,
ITT I propose the idea of a TOML module in the standard library for general
TOML operations.
The main motivator of this is the growing adoption of PEP 517. Recently I've
been following its developments and I've noticed some situations
"Should Python enforce Type-checking in the future?"
Python already enforces type-checking. It is *runtime* time checking.
https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
As far as *static* type checking goes, the answer is No.
(Obviously all of the following is my opinion, not
First off I love types. They, as you point out, are a great tool for
finding bugs. However, there are reasons why requiring types would either
require the use of meaningless types e.g. marking everything as the Any
type or require python to solve the halting problem.
Consider the following code e
23 matches
Mail list logo
