Steven D'Aprano writes:
> On Monday 28 March 2016 23:18, BartC wrote:
>
> > (There are also docstrings, but until yesterday I didn't even know
> > they were also expressions. Wikipedia says this:
> >
> > "Python docstrings appear as a string literal (not an expression) as
> > the first statement
On Monday 28 March 2016 23:18, BartC wrote:
> On 28/03/2016 02:24, Steven D'Aprano wrote:
>> Don't think about floats and ints and strings. Think of complex objects
>> with operator overloading. You're probably thinking of `x + y`. Instead,
>> think of things like:
>>
>> graph + node
>> database
On 3/27/2016 9:26 PM, Steven D'Aprano wrote:
On Mon, 28 Mar 2016 03:39 am, Terry Reedy wrote:
So Bart is proposing
whether 'actually' or 'hypothetically'
I don't think Bart is intending this as an actual proposal to change Python
so much as just a hypothetical to discuss.
I don't remembe
On 28/03/2016 02:24, Steven D'Aprano wrote:
On Sun, 27 Mar 2016 10:31 pm, BartC wrote:
Whether there are side-effects is not quite as important as picking up
things that are likely to be errors:
f() # Probably OK
g() # Probably OK
f()+g() # Probably not OK
Yo
BartC :
> So no matter how many potentially useful counter-examples you can dig
> up, non-function-call expressions are still going to be highly
> unusual. And suspect.
>
> That's why it's not going to be much loss to disallow them /in that
> form/.
Note that operators are front ends for dunder m
On Mon, Mar 28, 2016 at 1:59 PM, Tim Chase
wrote:
> On 2016-03-28 12:38, Chris Angelico wrote:
>> I would still look askance at code that adds two things and drops
>> the result, though. The compiler can't discard it, but if a linter
>> complains, I'd support that. A DSL that requires you to do th
On 2016-03-28 12:38, Chris Angelico wrote:
> I would still look askance at code that adds two things and drops
> the result, though. The compiler can't discard it, but if a linter
> complains, I'd support that. A DSL that requires you to do this is,
> imo, poorly designed.
Is it only the "*add* tw
On Mon, Mar 28, 2016 at 12:24 PM, Steven D'Aprano wrote:
>>
>>f() # Probably OK
>>g() # Probably OK
>>f()+g() # Probably not OK
>
> You don't and can't know what's "probably not" okay unless you know what
> type of object both f and g return.
>
> Don't think about f
