Re: [Python-ideas] Using rightarrow "->" for typing annotation of functions

2019-04-24 Thread MRAB
On 2019-04-24 22:42, Guido van Rossum wrote: Thanks for posting. I agree that Callable is ugly (even hideous :-), but when we introduced type annotations in PEP 484, we didn't want to introduce new syntax. The existing syntax (using -> in function headings) was supported since Python 3.0.

Re: [Python-ideas] What are the strong use cases for str.rindex()?

2019-04-24 Thread Steven D'Aprano
On Tue, Apr 23, 2019 at 10:28:29AM -0700, Brett Cannon wrote: > Given "abcdefabcdefabcdef", what is the last result of "abc"? > x.rindex("abc") will tell you. > > Given [1, 2, 3, 4, 5, 1, 2, 3, 4, 5] where is the last result of 3? > reversed(x).index(3) will tell you (or x[::-1]). That first

Re: [Python-ideas] What are the strong use cases for str.rindex()?

2019-04-24 Thread Steven D'Aprano
On Wed, Apr 24, 2019 at 08:59:18AM +0800, 林自均 wrote: > Hi all, > > Thanks for the explanation. Now I agree that the need for list.rindex() is > not as common as str.rindex(). In fact, I only need list.rindex() when > doing some algorithm problems. I guess that doesn't count as real need here. Of

[Python-ideas] Using rightarrow "->" for typing annotation of functions

2019-04-24 Thread Vaibhav Karve
(Note: This idea is about a particular static typecheking (typing?) annotation syntax). The idea is that currently the use of the "->" (right arrow) is restricted to only function definition annotation. Can we extent it to declaration of type for functions even outside their definitions? Example:

Re: [Python-ideas] CPython Bytecode Assembler

2019-04-24 Thread Batuhan Osman Taşkaya
`dis` module was my only reference for this proposal. If majority doesn't want a new implementation-specific module, it is best to withdraw this proposal. Brett Cannon , 24 Nis 2019 Çar, 20:49 tarihinde şunu yazdı: > Since bytecode is a CPython-specific implementaiton detail I don't know if > it

Re: [Python-ideas] CPython Bytecode Assembler

2019-04-24 Thread Brett Cannon
Since bytecode is a CPython-specific implementaiton detail I don't know if it makes sense to enshrine an assembler for it in the stdlib (if you were to ask me today if I thought the dis module belonged in the stdlib I would probably say "no", but I also know not everyone agrees with that view :) .

Re: [Python-ideas] CPython Bytecode Assembler

2019-04-24 Thread Guido van Rossum
It is intentionally not included -- bytecode is a detail of the implementation and changes with each feature release, without concern for backwards compatibility. On Wed, Apr 24, 2019 at 10:33 AM Batuhan Osman Taşkaya < batuhanosmantask...@gmail.com> wrote: > Hello, > > Currently it is hard to

[Python-ideas] CPython Bytecode Assembler

2019-04-24 Thread Batuhan Osman Taşkaya
Hello, Currently it is hard to assemble cpython bytecode without help of 3rd party libraries (like: vstinner/bytecode). I'm proposing an assembler to standard library and an API to cpython's peephole optimizer. Also an interface like `ast.NodeVisitor` and `ast.NodeTransformer` for bytecode

Re: [Python-ideas] contains_any_in and contains_all_in

2019-04-24 Thread João Matos
The objective of the proposal is to increase readability. IMO using re is even more unreadable than the and/or or any/all I mentioned. quarta-feira, 24 de Abril de 2019 às 05:47:04 UTC+1, Robert Vanden Eynde escreveu: > > Trivial with re module, which will answer thequestion in one pass. >> > >

Re: [Python-ideas] contains_any_in and contains_all_in

2019-04-24 Thread João Matos
The objective of the proposal is to increase readability. IMO your options are even more unreadable than the and/or or any/all I mentioned. quarta-feira, 24 de Abril de 2019 às 05:33:12 UTC+1, Terry Reedy escreveu: > > On 4/23/2019 4:39 PM, João Matos wrote: > > Hello, > > > > If we want to

Re: [Python-ideas] contains_any_in and contains_all_in

2019-04-24 Thread Rhodri James
On 23/04/2019 21:39, João Matos wrote: If we want to check if a string contains any/all of several other strings we have to use several or/and conditions or any/all. [snip] I suggest adding some "sugar" to make it more readable by adding contains_any_in and contains_all_in to look like this