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

[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.


Since then we've introduced other new syntax (in particular PEP 526) so 
we could indeed try adding something better for Callable.


I think we should probably at least have parentheses around the 
arguments, so you'd write


f: (int) -> str
g: (int, str) -> float

That looks elegant.

But we should also try to support optional arguments and keyword arguments.

Also, some groups of people would like to see a more concise notation 
for lambdas, and maybe they'd want to write


x = (a, b) -> a + b

as sugar for

x = lambda a, b: a + b

We probably can't have both, so we should at least decide which is more 
important.


Too bad we can't use Unicode arrows. :-)


Some languages use ->; some others use =>.

As Python already uses -> for the return type, it could use => for lambdas.

On Wed, Apr 24, 2019 at 2:30 PM Vaibhav Karve > wrote:


(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:

Currently we write:
     f: Callable[[int, Dict[str, int]], str]  # declaring the type
of some fake function

This would be much cleaner if we could write:
     f: int -> Dict[str, int] -> str   # One of the possibilities

or even:
     f: int, Dict[str, int] -> str      # Another possibility

I have no idea how this will affect the existing syntax (and if this
will have any bad repercussions/notational misuse). I just thought
it would be nicer to:
a) Not have to spell out Callable
b) Not have to use all those square brackets
c) Have the same notation work for both the function annotation as
well as for declaring the type.

This is my first time posting an idea to python-ideas. So apologies
if i am not following some conventions that i might not be aware of.

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 version doesn't work, as list_reverseiterator objects don't 
have an index method. You're not the only person to make that error, I 
too often forget that reverse() returns an iterator, not a list.

The second is easy to get wrong, because it returns the wrong index:

  # Get the item following the last instance of spam.
  index = x[::-1].index(spam)
  print(x[index+1])

In your example, the correct index is 7 but the returned value is 2.


> Notice how with lists you can easily reverse them and still get at the
> value since you are searching per index. 

"Easily" hides a lot of copying behind the scenes. If the list is a 
non-trivial size, that can be very wasteful, especially if you're doing 
it in a loop, or hidden in a function. Don't think about the case of a 
ten element list, think of a ten-billion element list.

Personally, I don't think I've every used list.index, let alone needed 
rindex. But I think we underestimate the difficulty and cost of faking 
an rindex method from index for those who need it (if anyone does).


> But with strings, you searching by
> a subslice that can be greater than 1 in which case you can't use a similar
> approach.

Of course you can: you "just" need to reverse the substring as well.

The conversions will be even more fiddly and error-prone:

py> s = "abc spam def spam ghi"
py> s.rindex('spam') == len(s) - s[::-1].index('spam'[::-1]) - len('spam')
True

but it can be done.



-- 
Steven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 course it's a "real need", but the question is whether it is common 
enough for somebody to do the work if it doesn't affect them personally.

Can you share an example of one of these algorithms?



-- 
Steven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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:

Currently we write:
f: Callable[[int, Dict[str, int]], str]  # declaring the type of some
fake function

This would be much cleaner if we could write:
f: int -> Dict[str, int] -> str   # One of the possibilities

or even:
f: int, Dict[str, int] -> str  # Another possibility

I have no idea how this will affect the existing syntax (and if this will
have any bad repercussions/notational misuse). I just thought it would be
nicer to:
a) Not have to spell out Callable
b) Not have to use all those square brackets
c) Have the same notation work for both the function annotation as well as
for declaring the type.

This is my first time posting an idea to python-ideas. So apologies if i am
not following some conventions that i might not be aware of.
Vaibhav Karve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] CPython Bytecode Assembler

[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 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 :) .
>
> On Wed, Apr 24, 2019 at 10:36 AM Batuhan Osman Taşkaya <
> batuhanosmantask...@gmail.com> wrote:
>
>> 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
>> objects will may be handy.
>>
>> It would help if you are doing;
>> - Runtime patching
>> - Specific optimizations at bytecode level
>>
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] CPython Bytecode Assembler

[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 :) .

On Wed, Apr 24, 2019 at 10:36 AM Batuhan Osman Taşkaya <
batuhanosmantask...@gmail.com> wrote:

> 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
> objects will may be handy.
>
> It would help if you are doing;
> - Runtime patching
> - Specific optimizations at bytecode level
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] CPython Bytecode Assembler

[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 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
> objects will may be handy.
>
> It would help if you are doing;
> - Runtime patching
> - Specific optimizations at bytecode level
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


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

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] CPython Bytecode Assembler

[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 objects will may
be handy.

It would help if you are doing;
- Runtime patching
- Specific optimizations at bytecode level
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] contains_any_in and contains_all_in

[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.search('|'.join(map(re.escape, ['string1', 'string2', 'string3'])), 
> master_string)
>
> For those who might find it non trivial.
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] contains_any_in and contains_all_in

[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 check if a string contains any/all of several other 
> > strings we have to use several or/and conditions or any/all.
> > 
> > For any:
> > |if ('string1' in master_string or 'string2' in master_string
> >  or 'string3' in master_string):
> > or
> > ifany(item inmaster_string foritem in['string1','string2','string3']):
>
> Trivial with re module, which will answer the question in one pass.
>
>
> > For all:
> > |
> > ||if ('string1' in master_string and 'string2' in master_string
> >  and'string3' in master_string):
> > or
> > ||ifall(item inmaster_string foritem in['string1','string2','string3']):
>
> Tougher.
> Are the strings guaranteed to not be prefixes of each other?
> Do you want to allow overlaps?
> Can do in one pass by compiling a new re every time an item is found.
> If overlaps not wanted, re.iterfind will find all occurrence of any, so 
> feed to set and see if all found.
>
> -- 
> Terry Jan Reedy
>
>
> ___
> Python-ideas mailing list
> python...@python.org 
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] contains_any_in and contains_all_in

[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

For any:
if master_string contains_any_in ['string1', 'string2', 'string3']:

For all:
if master_string contains_all_in ['string1', 'string2', 'string3]:


They sound more like string methods to me, by analogy with startswith() 
and endswith():


  if master_string.contains_any('string1', 'string2', 'string3'):

etc.  The only question is whether this is a common enough requirement 
to justify their existence.  I don't remember our recent discussion on 
suffices coming to much of a conclusion about that.  Anyone?


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/