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
Fo
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 chec
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.
>>
>
>
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
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 <
[email protected]> wrote:
> Hello,
>
> Currently it is hard to as
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 :) .
`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 m
On 4/24/2019 12:50 PM, João Matos wrote:
The objective of the proposal is to increase readability.
Relational expressions are powerful and flexible and yes, people find
them hard to read until they really learn the sublanguage. The solution
is to isolate application-specific regexes in funct
On 2019-04-24 18:48, Brett Cannon wrote:
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
(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:
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 part
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
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 ver
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.
Sin
14 matches
Mail list logo
