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, 28 Mar 2016 01:43 am, BartC wrote:
[... talk about function and procedures ...]
> Well, that could be done in Python (not so usefully because you can't
> take account of such info until a call is attempted), but that's not
> what I'm talking about, which is simply allowing:
>
>fn(...)
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
On Mon, 28 Mar 2016 03:39 am, Terry Reedy wrote:
> On 3/27/2016 11:48 AM, Ned Batchelder wrote:
>> On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:
>
>>> whether fn has an explicit return or not, and not allowing:
>>>
>>> fn # and other kinds of expression
>>>
>>> unless s
On Sun, 27 Mar 2016 10:31 pm, BartC wrote:
> On 27/03/2016 07:34, Paul Rubin wrote:
>> BartC writes:
>>> But my suggestion was to have required a keyword in front of
>>> such expressions.
>>
>> Should there be a keyword in front of a line containing "sqrt(x)" ?
>> What about "launch(missiles)"
10 matches
Mail list logo
