On Fri, May 8, 2015 at 8:47 PM, Albert van der Horst
wrote:
> In article ,
> Chris Angelico wrote:
>>On Tue, May 5, 2015 at 3:32 AM, Irmen de Jong wrote:
>>> That is a broad question, but one thing that comes to mind is the
>>current (python 3)
>>> behavior of integer division. It gives the exa
In article ,
Chris Angelico wrote:
>On Tue, May 5, 2015 at 3:32 AM, Irmen de Jong wrote:
>> That is a broad question, but one thing that comes to mind is the
>current (python 3)
>> behavior of integer division. It gives the exact result and doesn't
>truncate to integers:
>>
>>
> 5/4
>> 1.25
On 06/05/2015 17:03, Steven D'Aprano wrote:
On Wed, 6 May 2015 10:40 pm, BartC wrote:
But I had in mind not implementing ++ and --, but detecting them and
issuing a warning,
That's a job for a linter, not the compiler. The compiler should be as
flexible as possible in what it accepts:
a ,
On Wed, 6 May 2015 10:40 pm, BartC wrote:
> But I had in mind not implementing ++ and --, but detecting them and
> issuing a warning,
That's a job for a linter, not the compiler. The compiler should be as
flexible as possible in what it accepts:
a ,b=12+3 * 4,"hello"
On Wed, May 6, 2015 at 11:11 PM, wrote:
> On Mon, May 4, 2015, at 18:02, BartC wrote:
>> (I think I would have picked up "++" and "--" as special tokens even if
>> increment/decrement ops weren't supported. Just because they would
>> likely cause errors through misunderstanding.)
>
> There's prec
On Mon, May 4, 2015, at 18:02, BartC wrote:
> (I think I would have picked up "++" and "--" as special tokens even if
> increment/decrement ops weren't supported. Just because they would
> likely cause errors through misunderstanding.)
There's precedent for not doing this in C itself - even thou
On Wednesday, May 6, 2015 at 6:09:08 PM UTC+5:30, Antoon Pardon wrote:
> Op 05-05-15 om 18:24 schreef Rustom Mody:
>
> > Yeah I happen to me in that minuscule minority that regards '= denotes
> > assignment' a bigger mistake than ++
>
> Nice to know I'm not alone. I Especially think it is a mist
On 06/05/2015 12:19, Gregory Ewing wrote:
BartC wrote:
So why pretend that ++ and -- don't exist?
Probably because Python would gain very little from
having them.
Main uses of ++ in C are things like integer for
loops:
for (i = 0; i < 10; i++) {...
and stepping through arrays:
a[i
Op 05-05-15 om 18:24 schreef Rustom Mody:
> Yeah I happen to me in that minuscule minority that regards '= denotes
> assignment' a bigger mistake than ++
Nice to know I'm not alone. I Especially think it is a mistake, because
it is then used as a reason for not allowing something like
if a =
BartC wrote:
So why pretend that ++ and -- don't exist?
Probably because Python would gain very little from
having them.
Main uses of ++ in C are things like integer for
loops:
for (i = 0; i < 10; i++) {...
and stepping through arrays:
a[i++] = b[j++];
Python code usually operates a
Steven D'Aprano wrote:
The first one just does a name lookup and then throws the result away. The
second one looks up names a and b, then adds them together, throwing away
the result.
Actually, it's worse than that. :-) It's possible for a to
have an __add__ method with a side effect, althoug
On Tuesday, May 5, 2015 at 6:50:29 PM UTC+5:30, BartC wrote:
> On 05/05/2015 09:19, Steven D'Aprano wrote:
> > On Tuesday 05 May 2015 08:02, BartC wrote:
>
> >> (I think I would have picked up "++" and "--" as special tokens even if
> >> increment/decrement ops weren't supported. Just because they
On 05/05/2015 09:19, Steven D'Aprano wrote:
On Tuesday 05 May 2015 08:02, BartC wrote:
(I think I would have picked up "++" and "--" as special tokens even if
increment/decrement ops weren't supported. Just because they would
likely cause errors through misunderstanding.)
Just because C made
On Tuesday 05 May 2015 08:02, BartC wrote:
> On 04/05/2015 16:20, Cecil Westerhof wrote:
>> Potential dangerous bug introduced by programming in Python as if it
>> was C/Java. :-(
>> I used:
>> ++tries
>> that has to be:
>> tries += 1
>
> I think I've come across that. It doesn't mind +
On 05/04/2015 04:28 PM, Cecil Westerhof wrote:
Op Monday 4 May 2015 21:39 CEST schreef Ian Kelly:
On Mon, May 4, 2015 at 11:59 AM, Mark Lawrence wrote:
On 04/05/2015 16:20, Cecil Westerhof wrote:
Potential dangerous bug introduced by programming in Python as if
it was C/Java. :-( I used: ++
On 2015-05-04 21:57, Andrew Cooper wrote:
> On 04/05/2015 18:43, Ian Kelly wrote:
> >
> > Some other gotchas that aren't necessarily related to C/Java but
> > can be surprising nonetheless:
> >
> > *() is a zero-element tuple, and (a, b) is a two-element
> > tuple, but (a) is not a one-elemen
On 04/05/2015 16:20, Cecil Westerhof wrote:
Potential dangerous bug introduced by programming in Python as if it
was C/Java. :-(
I used:
++tries
that has to be:
tries += 1
I think I've come across that. It doesn't mind ++ so people are likely
to be assume that increment works as in o
On Mon, May 4, 2015, at 16:57, Andrew Cooper wrote:
> * {} is an empty set(), not dict().
You've got it backwards.
> Particularly subtle when combined with **kwargs
The function in your example below _always_ returns a set, and kwargs is
always a dict. There's no subtlety outside of the repr out
On 04/05/2015 18:43, Ian Kelly wrote:
>
> Some other gotchas that aren't necessarily related to C/Java but can
> be surprising nonetheless:
>
> *() is a zero-element tuple, and (a, b) is a two-element tuple,
> but (a) is not a one-element tuple. Tuples are created by commas, not
> parentheses
Op Monday 4 May 2015 21:39 CEST schreef Ian Kelly:
> On Mon, May 4, 2015 at 11:59 AM, Mark Lawrence
> wrote:
>> On 04/05/2015 16:20, Cecil Westerhof wrote:
>>>
>>> Potential dangerous bug introduced by programming in Python as if
>>> it was C/Java. :-( I used: ++tries that has to be: tries += 1
On 5/4/2015 1:43 PM, Ian Kelly wrote:
*() is a zero-element tuple, and (a, b) is a two-element tuple,
but (a) is not a one-element tuple. Tuples are created by commas, not
parentheses, so use (a,) instead.
Which means that a, and a,b (or a,b,) are 1 and 2 element tuples
respectively. Exce
On Mon, May 4, 2015 at 11:59 AM, Mark Lawrence wrote:
> On 04/05/2015 16:20, Cecil Westerhof wrote:
>>
>> Potential dangerous bug introduced by programming in Python as if it
>> was C/Java. :-(
>> I used:
>> ++tries
>> that has to be:
>> tries += 1
>>
>> Are there other things I have to
On 04/05/2015 16:20, Cecil Westerhof wrote:
Potential dangerous bug introduced by programming in Python as if it
was C/Java. :-(
I used:
++tries
that has to be:
tries += 1
Are there other things I have to be careful on? That does not work as
in C/Java, but is correct syntax.
Not dan
On Mon, May 4, 2015 at 9:20 AM, Cecil Westerhof wrote:
> Potential dangerous bug introduced by programming in Python as if it
> was C/Java. :-(
> I used:
> ++tries
> that has to be:
> tries += 1
>
> Are there other things I have to be careful on? That does not work as
> in C/Java, but is c
On Tue, May 5, 2015 at 3:32 AM, Irmen de Jong wrote:
> That is a broad question, but one thing that comes to mind is the current
> (python 3)
> behavior of integer division. It gives the exact result and doesn't truncate
> to integers:
>
>
5/4
> 1.25
Using the word "exact" around non-integ
On 4-5-2015 17:20, Cecil Westerhof wrote:
> Potential dangerous bug introduced by programming in Python as if it
> was C/Java. :-(
> I used:
> ++tries
> that has to be:
> tries += 1
>
> Are there other things I have to be careful on? That does not work as
> in C/Java, but is correct syntax
On 05/04/2015 08:20 AM, Cecil Westerhof wrote:
Potential dangerous bug introduced by programming in Python as if it
was C/Java. :-(
I used:
++tries
that has to be:
tries += 1
Are there other things I have to be careful on? That does not work as
in C/Java, but is correct syntax.
One
Potential dangerous bug introduced by programming in Python as if it
was C/Java. :-(
I used:
++tries
that has to be:
tries += 1
Are there other things I have to be careful on? That does not work as
in C/Java, but is correct syntax.
--
Cecil Westerhof
Senior Software Engineer
LinkedIn: ht
28 matches
Mail list logo
