One last thing:
Since expressions tend to have pretty limited space, it might be worth it
to consider more concise options like maybe instead of:
<expression1> except (Exception[-list])[ as e]): <expression2>
it could be:
<expression1> (Exception[-list])[ as e])! <expression2>
So:
y = x[0] IndexError! default
instead of
y = x[0] except IndexError: default
or:
y = spam.ham[0] (AttributeError, IndexError) as e! foo(e)
instead of
y = spam.ham[0] except (AttributeError, IndexError) as e: foo(e)
Or something to that effect. (thought I think it might be best to err on
the side of 'except' because it's more clear what it does and it only adds
7 characters).
On Fri, Aug 3, 2018 at 6:57 PM, Abe Dillon <abedil...@gmail.com> wrote:
> [Benedikt Werner]
>
>> As the with-expression mimics the with-statement I would say this is
>> similar to:
>> with supress(AttributeError):
>> tmp = person.name[0]
>> initial = tmp # Error on assignment wouldn't get suppressed. Not relevant
>> for this case but still.
>
>
> Ah, yes. That makes much more sense now. I would say the error on
> assignment IS relevant for that case and it's not clear to me how you would
> present that error to the user without causing a lot of confusion.
>
> If it were implemented as:
>
> tmp = None
> with suppress(AttributeError):
> tmp = person.name[0]
> initial = tmp
>
> Then it would solve many of the common use cases for the None-aware
> operators proposed in PEP 505, especially if we made it easy to filter out
> None-specific errors:
>
> class NoneError(BaseException):
> pass
>
> class NoneAttributeError(AttributeError, NoneError):
> pass
>
> ... code to make erroneous attribute access on NoneType objects throw
> NoneAttributeErrors ...
> ... shouldn't break much code other than maybe some doc-string tests ...
>
> initial = person.name[0] with suppress(NoneError)
>
> [Robert Vanden Eynde]
>
>> With implementation details? The highest value is there, the alg is
>> clear., one fetches the filename, one preprocess the lines, then parse the
>> data.
>
>
> Yes. Sorry for using confusing language. I was trying to say that I like
> your proposed syntax (for both with and except) because it follows the same
> principal. At the same time, I was trying to demonstrate part of the value
> of expression-ized statements to everyone else. Since Python is strictly
> evaluated statement by statement, there is no notion of looking ahead and
> re-ordering code. You can't use a variable in one statement then define
> that variable later on (like you do in comprehensions). Expressions, on the
> other hand; are parsed in a more complex way, so you can do things like put
> the relevant logic up front and move all the book-keeping to the end.
>
> [Robert Vanden Eynde]
>
>> About if elif elif else, ternary if does have that:
>> y = (x+1 if x < 0 else
>> x-1 if x > 0 else
>> 0)
>
>
> True, and your except syntax could chain in a similar manner. In-fact it
> might be possible to make a separate "finally" operator that executes the
> left side then executes the right side no matter what:
>
> y = ((x[0] except InxexError: x.default) except AttributeError: None)
> finally print("hello!")
>
> [Robert Vanden Eynde]
>
>> Limiting the scope is interesting, for "with" the only limitation in that
>> the body must have exactly one assignment, like in the ternary if case?
>> a = ([l.strip() for l in f.readlines()] with open ('name') as f)
>> By cutting the edge cases, "with something():" is not possible, only
>> "with ... as" being possible?
>
>
> I think it's better to forget what I said about limiting the scope of the
> operator. It was a half-baked thought.
>
> As for assignment expressions, they're already on their way thanks to PEP
> 572. I like the "where" version you proposed because it places the logic
> first, but unfortunately PEP 572 (4th alternate spelling
> <https://www.python.org/dev/peps/pep-0572/#alternative-spellings>) states
> that they had considered that version and rejected it because "where" is a
> pretty common variable name. From the PEP:
>
> SQLAlchemy and numpy have where methods, as does tkinter.dnd.Icon in the
>> standard library
>
>
> So adding a new "where" keyword would break backwards compatibility in a
> major way.
>
> On Fri, Aug 3, 2018 at 5:40 PM, Benedikt Werner <1benediktwer...@gmail.com
> > wrote:
>
>> For instance, what would the following do?
>>
>> initial = person.name[0] with suppress(AttributeError) # Hangover from
>> PEP 505 discussion...
>>
>> As the with-expression mimics the with-statement I would say this is
>> similar to:
>>
>> with supress(AttributeError):
>> tmp = person.name[0]
>> initial = tmp # Error on assignment wouldn't get
>> suppressed. Not relevant for this case but still.
>>
>> I don't understand where this is ambigous?
>>
>> So maybe it only makes sense to use expression assignment (PEP 572):
>>
>> data = (d := file.read() with open(...) as file)
>>
>> To which I say, "Eww..."
>>
>> I definitely agree that this looks a bit bad but I don't get why you
>> would consider using an expression assignment there.
>>
>> data = file.read with open(...) as file
>>
>> works perfectly fine so why would you want to additonaly assign it to
>> another variable "d"?
>>
>>
>> Overall I like the idea of the with-expression as it allows you to make
>> some common use cases like the open/read example more readable. It's clear
>> at first sight that what is actually done is reading the file. While it's
>> true that it's usually easy to write a simple function to do the job that
>> still isn't as simple to understand and in most cases when reading the code
>> you then have to look at the function to see if anything else is done
>> there. Also what if you then do readlines somewhere? Then you need another
>> function.
>>
>> _______________________________________________
>> 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/
