[Python-ideas] Re: Create a @deprecated decorator (annotation)

[Cameron Simpson]

On 29Jul2021 15:58, Paul Moore  wrote:
>On Thu, 29 Jul 2021 at 15:39, Leonardo Freua
> wrote:
>> Would it be interesting to create a @deprecated decorator to avoid 
>> adding warnings.warn("deprecation message", DeprecationWarning, 
>> stacklevel=2) in methods body?
>
>I don't see the value personally.

I do. Like various others here I wrote myself such a decorator long ago.  
It was named @OBSOLETE and was by no means as complete as, say, the 
Deprecated PyPI module. But the use case was the same:

@OBSOLETE
def old_func():

A decorator is concise and right up front in the code. As others have 
mentioned, it becomes easy for tooling to see or use. (Not mine, it is a 
miracle of crudity, just issuing warning() calls when the function is 
first called from some place - it does at least say where the call was 
made from.)

[...]
>Why would it be "interesting"? I don't see any practical advantage,
>and as soon as you need any form of logic you have to rewrite, so why
>bother?

That's the case for any presupplied convenience. But it covers off a lot 
of the common cases to my mind.

The idea's a definite +1 from me.

Cheers,
Cameron Simpson 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YG2VHW6RJNHGD6ITJNAQNWHS6LAR7GWR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP idea

[Guido van Rossum]

That's proposed in PEP 645 (https://www.python.org/dev/peps/pep-0645/).
Personally I think it's not necessary, we should just write MyType | None.
(Yes, this is directly from TypeScript.)

On Sun, Aug 15, 2021 at 6:10 AM Will Bradley 
wrote:

> Hi all,
>
> As of 3.10 (PEP 604) we've gotten syntactical support for a common type
> operation— namely, typing.Union[Type1, Type2] can now be written as Type1 |
> Type2 . This is achieved via overriding the __or__ method.
>
> I propose the ? symbol as sugar for typing.Optional, so that
> typing.Optional[MyType] can be written as MyType? . (Yes, this is lifted
> directly from C#.)
>
> Thoughts? Is it unnecessary now that we can write MyType | None as of 3.10?
>
> Thanks,
> Will
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/VYZOMTCNSSAJNAYHRE5A5BJUMACY57SF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


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

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VOEC3A6GMSLMIXU2WBUKKXCWVH673BCT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Notation for subscripts.

[Guido van Rossum]

Have you seen PEP 637? IIRC it has discussions on a[] and a[*x]. Note that
it was rejected, but the idea of a[*x] is being resurrected for PEP 646.

On Fri, Aug 13, 2021 at 5:43 AM Matsuoka Takuo 
wrote:

> Dear Developers,
>
> Given a subscriptable object s, the intended rule for the notation for
> getting an item of s seems that, for any expression {e}, such as
> "x, ",
>   s[{e}]
> (i.e., s[x, ] if {e} is "x, ") means the same as
>   s[({e})]
> (i.e., s[(x, )] in the considered case), namely, should be evaluated
> as s.__getitem__(({e})) (or s.__class_getitem__(({e})) when that
> applies). If this is the rule, then it looks simple and hence
> friendly to the user. However, there are at least two exceptions:
>
> (1) The case where {e} is the empty expression "":
> The expression
>   s[]
> raises SyntaxError instead of being evaluated in the same way as
> s[()] is.
>
> (2) The case where {e} contains "*" for unpacking:
> An expression containing the unpacking notation, such as
>   s[*iterable, ]
> raises SyntaxError instead of being evaluated in the same way as
> s[(*iterable, )] in this example, is.
>
> Are these (and other if any) exceptions justified? If not, I propose
> having the described rule to have full effect if that would simplify
> the syntax. This would affect currently working codes which rely on
> SyntaxError raised in either of the described ways (through eval, exec
> or import??). I wonder if reliance on SyntaxError in these cases
> should be supported in all future versions of Python.
>
> Best regards,
> Takuo Matsuoka
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/V2WFMNVJLUBXVQFPNHH4TJNRYNPK2BKJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


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

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/L6CXI6OWIXS7ADXWHE4K2FJUMQSAOAYI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Create a @deprecated decorator (annotation)

[Marco Sulla]

@Deprecated is used in Java and I find it very easy to use. Remember
you can also use parameters in decorators.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OBTRKWOMEE3TUF2MZKWVZSAAV4OFQQ47/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: copy-paste code snippets to the python console

[Marco Sulla]

You can use the Jupiter console: https://jupyter.org/

On Fri, 11 Jun 2021 at 15:13, Raymond Bisdorff  wrote:
>
> Dear Python developers,
>
> It would be helpful, if the following issue with copy-pasting python
> code-snippets into the standard shell console, could be investigated and
> corrected.
>
> https://stackoverflow.com/questions/2501208/copying-and-pasting-code-into-the-python-interpreter
>
> In particular, copying and pasting from sphinx python and pycon
> code-blocks with copy button (only >>> and ... lines), is at present not
> generally working due to the  "the shell-s de-indent cmd" need for empty
> lines.
>
> See https://digraph3.readthedocs.io/en/latest/index.html
>
> Thank you in advance for you attention,
>
> Best Regards,
>
> Raymond Bisdorff
>
> --
> Raymond Bisdorff
> Emeritus Professor of Computer Science and Applied Mathematics
> University of Luxembourg
> http://rbisdorff.github.io/
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/6X6G52BYEDQYTZPX2FV5JJ4P4JH4VIL3/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JXG3ETPULMYJUT4RQA6JUFUJMGENIZO7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP idea

[Thomas Grainger]

You can use `T | None`
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/G6UWX2W7SQ7VUYOPDKDTULLWOIIWD7RS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP idea

[Thomas Grainger]

Any has the same number of characters as All
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/O23FEL4BWZKQF6C7Y5WEOH33FYJISMKB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP idea

[James Oldfield]

Surely there already is a built in for that, not quite as short as “All” but 
shorter than “typing.Any”: “object”. Avoids keyword pollution, already has 
clear meaning. And it works with isinstance! :-) 

 

Is there something I’m missing? I never saw the point of typing.Any.

 

From: Abdulla Al Kathiri  
Sent: 15 August 2021 19:29
To: Joren Hammudoglu 
Cc: python-ideas@python.org
Subject: [Python-ideas] Re: PEP idea

 

+1 I like it, anything to get rid of Optional[type] is good.

If we can replace Callable[[type1], type2] with (type1) -> type2 and typing.Any 
with just soft keyword “All”, type annotations will be fun! 

Sent from my iPhone





On 15 Aug 2021, at 8:41 PM, Joren Hammudoglu mailto:jhammudo...@gmail.com> > wrote:



See https://www.python.org/dev/peps/pep-0645/

___
Python-ideas mailing list -- python-ideas@python.org 
 
To unsubscribe send an email to python-ideas-le...@python.org 
 
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UYSUJOZOWOYQ26CI5EXLZNAXUU3AUYON/
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KWBJIEZ3TKGWBYCR2W2P6FVD5ZVI7O35/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP idea

[Abdulla Al Kathiri]

+1 I like it, anything to get rid of Optional[type] is good.
If we can replace Callable[[type1], type2] with (type1) -> type2 and typing.Any 
with just soft keyword “All”, type annotations will be fun! 

Sent from my iPhone

> On 15 Aug 2021, at 8:41 PM, Joren Hammudoglu  wrote:
> 
> 
> See https://www.python.org/dev/peps/pep-0645/
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/UYSUJOZOWOYQ26CI5EXLZNAXUU3AUYON/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VGKRB4ACAT52B2CZWBHZ3HCXZH6ZQIPZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pattern matching in python function headers

[Abdulla Al Kathiri]

You have a point, but the mathematical approach of Haskell of different 
function cases is quite readable and straight forward. I only coded a little in 
Haskell and I know how to read it. I am not sure if you would consider Rust a 
functional language but they have pattern matching for function parameters but 
only you’re allowed to use one function signature unlike Haskell.

Sent from my iPhone

> On 10 Aug 2021, at 10:53 AM, Steven D'Aprano  wrote:
> 
> On Sun, Aug 08, 2021 at 11:30:20AM +0400, Abdulla Al Kathiri wrote:
> 
>> For me, it looks normal because I am used to seeing pattern matching 
>> for function parameters in functional programming languages.
> 
> Can you give us a few samples from other languages? The only one I know 
> is Haskell:
> 
>fib 0 = 0
>fib 1 = 1
>fib n = fib (n-1) + fib (n-2)
> 
> 
> I don't *hate* that in Haskell, because Haskell is meant to be read 
> almost as mathematical definitions. But Python functions are 
> declarative, and Python code consists of statements which are executed 
> in a defined order. I don't think that's a good match for Haskell-style 
> syntax.
> 
> What's wrong with the straight-forward application of a match statement 
> inside the function body? As you suggest:
> 
>> def fib(*args):
>>match args:
>>case 0, : return 0 
>>case 1, : return 1 
>>case int(n), : 
>>return fib(n-1) + fib(n-2) 
> 
> It costs one extra line (the match statement), but makes it explicit 
> what we're matching. And you save having to repeat the `def fib` for 
> every case.
> 
> Most importantly, it means that we only need one kind of pattern 
> matching syntax, instead of two.
> 
> -- 
> Steve
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/WCOU56EW37ZAC76GNICXR5NOWNNR6GRN/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AZIFHKRXO5LT2FVY4JE7KOFMEOJFNSWU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP idea

[Joren Hammudoglu]

See https://www.python.org/dev/peps/pep-0645/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UYSUJOZOWOYQ26CI5EXLZNAXUU3AUYON/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Notation for subscripts.

[Matsuoka Takuo]

Dear Steve,

Thank you for your thoughts.

To be precise, the sequence of letters "*(1,2)" is not actually a
"starred expression" in the sense of the Python Language, but e.g.,
"*(1,2), "
is. (A comma is trailing.) Please check the definitions here:

https://docs.python.org/3/reference/expressions.html#expression-lists

For instance, "(*(1,2) )" raises SyntaxError.

Now, is "1,2," more boxed up than "*(1,2)," is? The *current* rule
surely says the former is a tuple at some places and the latter
is not, but otherwise, I don't see any parenthesis nor bracket around
"1,2,". May more parentheses than brackets visible there? I see commas
in both, so that's not the difference. Is there no way "*(1,2)," could
equally be boxed up at exactly the same places where "1,2," can?

Importantly, what problem may be caused by this in practice, or from
what problem does SyntaxError currently raised there save us? For
instance, if someone writes "s[*(1,2),]" in fact wanting
"s[ [*(1,2),] ]" but forgets to box up "*(1,2),", then the same thing
can happen for "s[ [1,2,] ]" (i.e., it can be mistyped as "s[1,2,]"
but without SyntaxError this time). It would at least be consistent if
we got SyntaxError in both cases (namely, the syntax allowed only a
single Python expression here), but if we don't want SyntaxError in
the latter case, how may we want it in the former case?

By the way, please note I wish "*(1,2)," to be treated like "1,2,"
only where the current syntax expects an expression list. Elsewhere, I
don't
mind it if starred expressions remain treated as unboxed or whatever.

Best regards,
Takuo
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RKTLNFTKVRUPVEUIINGBO72EENX4MYH3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] PEP idea

[Will Bradley]

Hi all,

As of 3.10 (PEP 604) we've gotten syntactical support for a common type
operation— namely, typing.Union[Type1, Type2] can now be written as Type1 |
Type2 . This is achieved via overriding the __or__ method.

I propose the ? symbol as sugar for typing.Optional, so that
typing.Optional[MyType] can be written as MyType? . (Yes, this is lifted
directly from C#.)

Thoughts? Is it unnecessary now that we can write MyType | None as of 3.10?

Thanks,
Will
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VYZOMTCNSSAJNAYHRE5A5BJUMACY57SF/
Code of Conduct: http://python.org/psf/codeofconduct/