Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

2018-08-03 Thread Benedikt Werner
The proposal is for new operators.  The operators would be "bNOT", "bAND", "bOR", and "bXOR".  They would be completely independent of the existing "not", "and", and "or" operators, operating purely on boolean values.  It would be possible to overload these operators. I see, I misunderstood

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

2018-08-03 Thread Todd
On Fri, Aug 3, 2018 at 5:38 PM, Chris Barker wrote: > On Fri, Aug 3, 2018 at 1:02 PM, Nicholas Chammas < > nicholas.cham...@gmail.com> wrote: > >> The project overloaded the bitwise operators &, |, and ~ since they >> could not >> > override the boolean operators and, or, and not. >> >> I

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

2018-08-03 Thread Todd
On Fri, Aug 3, 2018 at 6:05 PM, Benedikt Werner <1benediktwer...@gmail.com> wrote: > There was a proposal to allow overloading boolean operators in Pep-335 >> [2], but that PEP was rejected for a variety of very good reasons. I think >> none of those reasons (besides the conversation fizzling

Re: [Python-ideas] PEP 505: None-aware operators: operators ?= and ?? and OR

2018-08-03 Thread Eric Fahlgren
On Fri, Aug 3, 2018 at 6:19 PM Steven D'Aprano wrote: > It needs some work. Something like "Here's an example in the standard > library. On converting it to none-aware version, we realised the std lib > version is buggy, because ...". A couple of sentences. > Yup, that's what I was getting

Re: [Python-ideas] With expressions

2018-08-03 Thread Steven D'Aprano
On Sat, Aug 04, 2018 at 12:28:40AM +0200, Robert Vanden Eynde wrote: > As the code I showed, being just that: > > filename = ... > lines = ... > parsed_data = ... > > With implementation details? The highest value is there, the alg is clear., > one fetches the filename, one preprocess the

Re: [Python-ideas] PEP 505: None-aware operators: operators ?= and ?? and OR

2018-08-03 Thread Steven D'Aprano
On Fri, Aug 03, 2018 at 06:30:25AM -0700, Eric Fahlgren wrote: > After looking at the code a bit more, I agree, we've uncovered a bug in the > stdlib and the null coalescing version actually fixes it. [...] > But! We are not here to talk about bugs in the email package, this > discussion is

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

2018-08-03 Thread MRAB
On 2018-08-03 23:05, Benedikt Werner wrote: There was a proposal to allow overloading boolean operators in Pep-335 [2], but that PEP was rejected for a variety of very good reasons.  I think none of those reasons (besides the conversation fizzling out) apply to my proposal. Maybe I am missing

Re: [Python-ideas] With expressions

2018-08-03 Thread Steven D'Aprano
On Fri, Aug 03, 2018 at 12:49:24PM +0200, Robert Vanden Eynde wrote: > Le ven. 3 août 2018 à 03:07, Steven D'Aprano a écrit : > > > On Thu, Aug 02, 2018 at 03:13:25PM +0200, Robert Vanden Eynde wrote: > > > > > This brings the discussion of variable assignement in Expression. > > Functional > >

Re: [Python-ideas] With expressions

2018-08-03 Thread Eric Fahlgren
On Fri, Aug 3, 2018 at 5:26 PM Abe Dillon wrote: > 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: > > except (Exception[-list])[ as e]): > You're reinventing PEP 463:

Re: [Python-ideas] With expressions

2018-08-03 Thread Abe Dillon
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: except (Exception[-list])[ as e]): it could be: (Exception[-list])[ as e])! So: y = x[0] IndexError! default instead of y = x[0] except

Re: [Python-ideas] With expressions

2018-08-03 Thread Abe Dillon
[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

Re: [Python-ideas] With expressions

2018-08-03 Thread Benedikt Werner
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 =

Re: [Python-ideas] With expressions

2018-08-03 Thread Robert Vanden Eynde
> > Expressionization may break the "one and only on obvious way" guideline, > but it can offer concise, readable code in a lot of instances where a > statement-based version would be clumsy and noisy, and there's already some > precedent for it: > > function declaration => lambda > for-loops =>

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

2018-08-03 Thread Benedikt Werner
There was a proposal to allow overloading boolean operators in Pep-335 [2], but that PEP was rejected for a variety of very good reasons.  I think none of those reasons (besides the conversation fizzling out) apply to my proposal. Maybe I am missing something, but I don't really see how this

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

2018-08-03 Thread Chris Barker via Python-ideas
On Fri, Aug 3, 2018 at 1:02 PM, Nicholas Chammas wrote: > The project overloaded the bitwise operators &, |, and ~ since they > could not > override the boolean operators and, or, and not. > > I actually think that is a good solution to this problem -- the fact is that for most data types

Re: [Python-ideas] With expressions

2018-08-03 Thread Abe Dillon
I like this idea in theory, but I'm not sold yet. I think there's a lot of draw to the concept of "expressionizing" statements because many statements require an unnatural ordering in-which the most important code, the logic, comes after some necessary but ultimately noisy (from the readers

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

2018-08-03 Thread Nicholas Chammas
On Fri, Aug 3, 2018 at 1:47 PM Todd toddr...@gmail.com wrote: The operators would be: > > bNOT - boolean "not" > bAND - boolean "and" > bOR - boolean "or" > bXOR - boolean "xor" > These look pretty ugly to me. But that could just be a matter of familiarity. For

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

2018-08-03 Thread Todd
On Fri, Aug 3, 2018 at 2:26 PM, Jonathan Fine wrote: > Hi Todd > > Thank you for your contribution! I've got a couple of comments. The > experts, I hope, will have more to say. > > Thanks for your reply, Jonathan. > You wrote: > > > As to why this is useful, the overall problem is that the

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

2018-08-03 Thread Jonathan Fine
Hi Todd Thank you for your contribution! I've got a couple of comments. The experts, I hope, will have more to say. You wrote: > As to why this is useful, the overall problem is that the current logical > operators, like and, or, and not, cannot be overloaded, which means projects > like numpy

Re: [Python-ideas] With expressions

2018-08-03 Thread Todd
On Thu, Aug 2, 2018 at 5:35 AM, Ken Hilton wrote: > Hi, I don't know if someone has already suggested this before, but here > goes: > > With expressions allow using the enter/exit semantics of the with > statement inside an expression context. Examples: > > contents = f.read() with

[Python-ideas] Revisiting dedicated overloadable boolean operators

2018-08-03 Thread Todd
Coming back to the previous discussion about a new set of overloadable boolean operators [1], I have an idea for overloadable boolean operators that I think might work. The idea would be to define four new operators that take two inputs and return a boolean result based on them. This behavior

Re: [Python-ideas] With expressions

2018-08-03 Thread Chris Barker via Python-ideas
On Fri, Aug 3, 2018 at 3:49 AM, Robert Vanden Eynde wrote: > > When I say "functional programming", I speak about the paradigm used in > language like Haskell. In language like those, all constructs are > "expression-based". > sure -- but Python is explicitly NOT a functional language in that

Re: [Python-ideas] PEP 505: None-aware operators: operators ?= and ?? and OR

2018-08-03 Thread Eric Fahlgren
On Thu, Aug 2, 2018 at 10:06 PM Alexandre Brault wrote: > I would make the opposite argument and claim that since when policy is > None mangle_from_ is initialised to True and not None, None is likely not a > potential value for policy.mangle_from_. Looking at > Lib/email/_policybase.py where

Re: [Python-ideas] With expressions

2018-08-03 Thread Robert Vanden Eynde
Thanks for answering each line. If someone wants "too long didn't read", just check my code at the paragraph "readlines is a toy example, but maybe the code would be more creative". Le ven. 3 août 2018 à 03:07, Steven D'Aprano a écrit : > On Thu, Aug 02, 2018 at 03:13:25PM +0200, Robert Vanden

Re: [Python-ideas] PEP 505: None-aware operators: operators ?= and ?? and OR

2018-08-03 Thread Jonathan Fine
Hi Alexandre Thank you for your post. In PEP 505 the context for the example being discussed is: > Some of these are shown below as examples before and after converting to use > the new operators. You wrote: > So yes, *strictly speaking* the two chunks of code are not exactly the same. I see