[Python-ideas] Re: "except;" - semicolon after except, to get rid of indentation when doing error recovery

[Chris Angelico]

On Wed, Jun 16, 2021 at 11:45 AM Steven D'Aprano  wrote:
>
> On Wed, Jun 16, 2021 at 10:56:12AM +1000, Chris Angelico wrote:
>
> > Dangerous idea - my first interpretation of that syntax was that it
> > would be equivalent to "except ValueError: pass", which would be very
> > confusing (it's subtly different in your example with return, and
> > drastically different in other cases).
>
> Aside from the difference in chained exceptions (the exception cause or
> context, I forget which is which, will be different) surely it is the
> same as `except ValueError: pass`?
>
> TBH I thought that difference was so minor that it wasn't even worth
> mentioning.

That's the subtle difference. The drastic difference is that, if you
ever change one of the cases (deliberately or accidentally) so it
doesn't have the return, it'll daisychain - but only when that one
gets hit.

But logically, there is a significant difference between putting code
inside the except block, and having "except X: pass" and then putting
code after. Code should be written the way it's meant to be, not the
way that happens to work.

ChrisA
___
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/UEJXTOQF5DPQLBGDTQM7ZE6XXCEVOBTQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: "except;" - semicolon after except, to get rid of indentation when doing error recovery

[Steven D'Aprano]

On Wed, Jun 16, 2021 at 10:56:12AM +1000, Chris Angelico wrote:

> Dangerous idea - my first interpretation of that syntax was that it
> would be equivalent to "except ValueError: pass", which would be very
> confusing (it's subtly different in your example with return, and
> drastically different in other cases).

Aside from the difference in chained exceptions (the exception cause or 
context, I forget which is which, will be different) surely it is the 
same as `except ValueError: pass`?

TBH I thought that difference was so minor that it wasn't even worth 
mentioning.

-- 
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/45ISBH6X4JUH3WGHP6XQ27TG2DTOZIPL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: "except;" - semicolon after except, to get rid of indentation when doing error recovery

[Steven D'Aprano]

On Tue, Jun 15, 2021 at 09:48:48PM -0300, Soni L. wrote:

> def foo():
>   try: return thing()
>   except ValueError:
>     try: return otherthing()
>     except ValueError:
>   try: return yetotherthing()
>   except ValueError:
>     if shouldraise(): raise
> 
> Look at all that unnecessary indentation! Would be nice to get rid of it.

It would be nice to use better looking four-space indents with indented 
blocks:

def foo():
try:
return thing()
except ValueError:
    try:
return otherthing()
    except ValueError:
    try:
return yetotherthing()
    except ValueError:
    if shouldraise():
raise


That makes the block structure of the code more clear, it reflects the 
semantics of the code better, it is much easier to modify (if we add an 
extra line between one of the try keywords and the returns, we don't 
need to change any existing lines, we just insert a new one: smaller 
diffs and better diffs). And it makes it more obvious that there is no 
final return (perhaps we forgot to add it?) and that the interpreter will 
automatically return None when we fall off the end of the function.

But if none of those arguments convince you that ideomatic Python code 
is better Python code, that's okay too. You can remove almost all the 
indentation:

def foo():
try: return thing()
except ValueError: pass
    try: return otherthing()
    except ValueError: pass
    try: return yetotherthing()
    except ValueError:
    if shouldraise(): raise


-- 
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/O5VGFNADFNTQ5CDGZTUK347JBPD3FGWR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: "except;" - semicolon after except, to get rid of indentation when doing error recovery

[Soni L.]

On 2021-06-15 10:13 p.m., Joao S. O. Bueno wrote:
> Sorry - personally I think this is absolutely ugly :-)  So I will
> bikeshed.
>
> If this thread even go ahead - since the idea is not that bad, maybe
> allowing `try` on the same line?
> Then it would be inline with `elif` - but still structured "English like" 
>
> try:
>    statement
> except ValueError try:
>    statement2
> except TypeError:
>    ...
>
> I had sometimes needed 2 and maybe up to 3 levels of this, nothing
> 'blocker', but maybe,
> just maybe, it would not be bad. 
> However, in real life, usually one wants to put more
> statements on the `except` clause than a bare nested try block.
> (logging, etc...)

For sure. The point is to turn the "rest of the function" into the
except block. Note that the try block would have to end with a return,
and no finally block would be allowed.

>
>
>
>
> On Tue, 15 Jun 2021 at 21:58, Chris Angelico  > wrote:
>
> On Wed, Jun 16, 2021 at 10:51 AM Soni L.  > wrote:
> >
> > Sometimes it would be useful to be able to write:
> >
> > def foo():
> >   try: return thing()
> >   except ValueError;
> >   try: return otherthing()
> >   except ValueError;
> >   try: return yetotherthing()
> >   except ValueError;
> >   if shouldraise(): raise
> >
> > But currently this needs to be written like so:
> >
> > def foo():
> >   try: return thing()
> >   except ValueError:
> >     try: return otherthing()
> >     except ValueError:
> >       try: return yetotherthing()
> >       except ValueError:
> >         if shouldraise(): raise
> >
> > Look at all that unnecessary indentation! Would be nice to get
> rid of it.
>
> Dangerous idea - my first interpretation of that syntax was that it
> would be equivalent to "except ValueError: pass", which would be very
> confusing (it's subtly different in your example with return, and
> drastically different in other cases).
>
> Are you doing this sort of thing a lot? And if you are, do you
> actually need/want the exception chaining that comes from burying more
> and more code into the except clauses? I know this is just a trivial
> example, but I'd be looking to see if it can be done with a loop
> instead.
>
> def foo():
>     for func in (thing, otherthing, yetotherthing):
>         try: return func()
>         except ValueError: pass
>
> or something like that.
>
> ChrisA
> ___
> 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/CJCSPO4N3RBGMXDFPT7HHIFROM4BZLN6/
> 
> 
> 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/ISYQKXGEVJOA3SY3SKJ7EZ4TUIS2ZGBC/
> 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/NVHMGSSJ6CG4EXEFUI34CHUUFLBTLXBV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: "except;" - semicolon after except, to get rid of indentation when doing error recovery

[Joao S. O. Bueno]

Sorry - personally I think this is absolutely ugly :-)  So I will bikeshed.

If this thread even go ahead - since the idea is not that bad, maybe
allowing `try` on the same line?
Then it would be inline with `elif` - but still structured "English like"

try:
   statement
except ValueError try:
   statement2
except TypeError:
   ...

I had sometimes needed 2 and maybe up to 3 levels of this, nothing
'blocker', but maybe,
just maybe, it would not be bad.
However, in real life, usually one wants to put more
statements on the `except` clause than a bare nested try block. (logging,
etc...)




On Tue, 15 Jun 2021 at 21:58, Chris Angelico  wrote:

> On Wed, Jun 16, 2021 at 10:51 AM Soni L.  wrote:
> >
> > Sometimes it would be useful to be able to write:
> >
> > def foo():
> >   try: return thing()
> >   except ValueError;
> >   try: return otherthing()
> >   except ValueError;
> >   try: return yetotherthing()
> >   except ValueError;
> >   if shouldraise(): raise
> >
> > But currently this needs to be written like so:
> >
> > def foo():
> >   try: return thing()
> >   except ValueError:
> > try: return otherthing()
> > except ValueError:
> >   try: return yetotherthing()
> >   except ValueError:
> > if shouldraise(): raise
> >
> > Look at all that unnecessary indentation! Would be nice to get rid of it.
>
> Dangerous idea - my first interpretation of that syntax was that it
> would be equivalent to "except ValueError: pass", which would be very
> confusing (it's subtly different in your example with return, and
> drastically different in other cases).
>
> Are you doing this sort of thing a lot? And if you are, do you
> actually need/want the exception chaining that comes from burying more
> and more code into the except clauses? I know this is just a trivial
> example, but I'd be looking to see if it can be done with a loop
> instead.
>
> def foo():
> for func in (thing, otherthing, yetotherthing):
> try: return func()
> except ValueError: pass
>
> or something like that.
>
> ChrisA
> ___
> 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/CJCSPO4N3RBGMXDFPT7HHIFROM4BZLN6/
> 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/ISYQKXGEVJOA3SY3SKJ7EZ4TUIS2ZGBC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: "except;" - semicolon after except, to get rid of indentation when doing error recovery

[Chris Angelico]

On Wed, Jun 16, 2021 at 10:51 AM Soni L.  wrote:
>
> Sometimes it would be useful to be able to write:
>
> def foo():
>   try: return thing()
>   except ValueError;
>   try: return otherthing()
>   except ValueError;
>   try: return yetotherthing()
>   except ValueError;
>   if shouldraise(): raise
>
> But currently this needs to be written like so:
>
> def foo():
>   try: return thing()
>   except ValueError:
> try: return otherthing()
> except ValueError:
>   try: return yetotherthing()
>   except ValueError:
> if shouldraise(): raise
>
> Look at all that unnecessary indentation! Would be nice to get rid of it.

Dangerous idea - my first interpretation of that syntax was that it
would be equivalent to "except ValueError: pass", which would be very
confusing (it's subtly different in your example with return, and
drastically different in other cases).

Are you doing this sort of thing a lot? And if you are, do you
actually need/want the exception chaining that comes from burying more
and more code into the except clauses? I know this is just a trivial
example, but I'd be looking to see if it can be done with a loop
instead.

def foo():
for func in (thing, otherthing, yetotherthing):
try: return func()
except ValueError: pass

or something like that.

ChrisA
___
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/CJCSPO4N3RBGMXDFPT7HHIFROM4BZLN6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] "except;" - semicolon after except, to get rid of indentation when doing error recovery

[Soni L.]

Sometimes it would be useful to be able to write:

def foo():
  try: return thing()
  except ValueError;
  try: return otherthing()
  except ValueError;
  try: return yetotherthing()
  except ValueError;
  if shouldraise(): raise

But currently this needs to be written like so:

def foo():
  try: return thing()
  except ValueError:
    try: return otherthing()
    except ValueError:
  try: return yetotherthing()
  except ValueError:
    if shouldraise(): raise

Look at all that unnecessary indentation! Would be nice to get rid of it.
___
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/U4YH5O255RBMNXOM3VEUBCDDCHQDFES5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Receive filtered warnings

[kasium]

Hello all,

I recently opened a feature request for pytest 
(https://github.com/pytest-dev/pytest/issues/8768) to find out if a warnings 
filter capture anything.

Basic use-case: In big project with a lot of dependencies, the warnings filter 
list can grow a lot. Currently the only safe way to find out if a filter is 
still needed, is to remove it and then to run your code.
Therefore it would be nice to have a more automatic approach. 
Suggestion for the warnings module: A new method wich returns all filtered 
warnings as well as the filter which caused the filtering.
The "capturing" could even be placed inside a context generator to avoid a 
unnecessary collection and a global state.

Afterwards it would be possible for tools like pytest to take a look at all 
applied filters and then to report, which filters were not applied.
Additional benefits: A user can e.g. see if a previous general written filter 
(e.g. without a module) can be more specific.
___
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/FU26XQJKLKLTWFZJE2ZIQO3EZMKJ2CYD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Mo., 14. Juni 2021 um 01:25 Uhr schrieb Chris Angelico :

>
> I'd love to have some sort of generic interpolation construct, but the
> use-cases all seem really weak...
>
>
It depends on your daily work. If you create many small methods returning
small HTML fragments,
then it really helps if you can avoid some extra typing. But maybe it is
not about typing.
Maybe it is about reading. Passing variables via `foo=foo, bar=bar`
contains no value.
This means your eyes need to parse information which has little value. I
would like to
avoid that.

f-strings are great. Unfortunately they do too much.

Regards,
  Thomas
___
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/IXVIRB75RT6ISETC5GS7STULJ3DOXWYE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Mo., 14. Juni 2021 um 11:12 Uhr schrieb J. Pic :

> On Thu, Jun 10, 2021 at 8:34 AM Thomas Güttler 
> wrote:
>
>>
>> This solution has two drawbacks:
>>
>>1. It is too verbose. Typing "conditional_escape(...)" again and
>>again is cumbersome.
>>
>> from django import conditional_espace as esc
> f'''
> Hi {esc(name)}
> Your messages: {esc(messages)}
> '''
>
>>
>>1. If a conditional_escape() gets forgotten Cross-site scripting
>>attacks could be possible, since malicious users could inject HTML.
>>
>> This is specific to Django and other frameworks out there which accept
> anything as user input by default, that's an anti-pattern which OWASP
> recommends against because obviously it opens a wide range of attack
> vectors, absolutely no security audit would ever validate the default
> validation of a CharField or a TextField.
>
>
You are right. Validating user input is an important topic. But it is a
different topic, which should be discussed at a different time.



> Another problem I see with this proposal is how do you actually use safe
> HTML in variables?
>
> msgs = [f'{msg}' for msg in messages]
> f'''
> Hi {name}
> Your messages: {msgs}
> '''
>
> Will output:
>
> Hi Your name
> Your messages: liYour message/li
>
> Instead of what we would want in this situation:
>
> Hi Your name
> Your messages: Your message
>
> Otherwise good idea, it's an issue we have, even though the first
> immediate fix needed is Django's default input validation which is just
> openbar.
>

Thank you for your feedback James.

The "magic" is done in conditional_escape():
https://github.com/django/django/blob/824981b2dc61a76a59d0e470bed6e61626a44ccf/django/utils/html.py#L92

I updated the PEP so that it contains a hyperlink to the github repo.

Regards,
  Thomas
___
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/U5FB7XCLWD6FIZTW6WIDSZQWM4CZLESH/
Code of Conduct: http://python.org/psf/codeofconduct/