On Sun, 2009-08-02 at 14:14 +, Albert van der Horst wrote:
> >This is actually quite thoroughly untrue. In python, *indentation*
> is
> >significant. Whitespace (internal to a line) is not. You can even
> call
> >methods like this if you want:
>
> You totally don't get it. You describe how
In article ,
J. Cliff Dyer wrote:
>On Fri, 2009-07-17 at 20:53 +, Albert van der Horst wrote:
>> Because unlike in algol 68 in python whitespace is relevant,
>> we could get by with requiring whitespace:
>> x= -q # okay
>> a> 8 ** -2
Maybe the IDE is the best place to warn you of something like that.
You could have an IDE where you specify which language you're more
familiar with and then have it display warnings likely to be relevant
to you. People could collaborate to add support for gradually more
niche languages.
Python
J. Cliff Dyer wrote:
On Fri, 2009-07-17 at 20:53 +, Albert van der Horst wrote:
Because unlike in algol 68 in python whitespace is relevant,
we could get by with requiring whitespace:
x= -q # okay
a
This is actually quite thoroughly untrue. In python,
On Fri, 2009-07-17 at 20:53 +, Albert van der Horst wrote:
> Because unlike in algol 68 in python whitespace is relevant,
> we could get by with requiring whitespace:
> x= -q # okay
> a 8 ** -2 # okay
This is actually quite thor
In article ,
Gabriel Genellina wrote:
>En Mon, 06 Jul 2009 00:28:43 -0300, Steven D'Aprano
> escribi?:
>> On Mon, 06 Jul 2009 14:32:46 +1200, Lawrence D'Oliveiro wrote:
>>
>>> I wonder how many people have been tripped up by the fact that
>>>
>>> ++n
>>>
>>> and
>>>
>>> --n
>>>
>>> fail si
On Jul 7, 2:00 pm, Steven D'Aprano wrote:
> On Mon, 06 Jul 2009 22:18:20 -0700, Chris Rebert wrote:
> >> Not so rare. Decimal uses unary plus. Don't assume +x is a no-op.
> [...]
> > Well, yes, but when would you apply it twice in a row?
>
> My point was that unary + isn't a no-op, and therefore n
In message , MRAB
wrote:
> I wonder whether the problem with assignment in conditionals in C is due
> to the assignment operator being "=". If it was ":=", would the error
> still occur?
One of the original C designers, Kernighan or Ritchie, admitted that he made
the assignment operator "=" ins
In message <4a538a71$0$30236$9b4e6...@newsspool1.arcor-online.net>, Stefan
Behnel wrote:
> Lawrence D'Oliveiro wrote:
>>
>> I wonder how many people have been tripped up by the fact that
>>
>> ++n
>>
>> and
>>
>> --n
>>
>> fail silently for numeric-valued n.
>
> I doubt that there ar
>> But this academic discussion is honestly a little pointless. The OP
>> was referring to a expectation, coming from C, that is not fulfilled
>> in python. What's wrong with mentioning it somewhere for the sake of
>> helping C programmers?
>>
> And where does one stop? After all, my primary
-Original Message-
From: Dennis Lee Bieber [mailto:wlfr...@ix.netcom.com]
Sent: Tuesday, 7 July 2009 4:45 p.m.
To: python-list@python.org
Subject: Re: A Bug By Any Other Name ...
On Mon, 6 Jul 2009 19:48:39 -0700, Daniel Fetchinson
declaimed the following in
gmane.comp.python.general
Lawrence D'Oliveiro wrote:
> I wonder how many people have been tripped up by the fact that
>
> ++n
>
> and
>
> --n
>
> fail silently for numeric-valued n.
I doubt that there are many. Plus, you misspelled them from the more obvious
n++
and
n--
which *do* fail with
Daniel Fetchinson wrote:
and my point is that users
are most of time correct when they assume that something will work the
same way as in C.
Oh, really ? They would surely be wrong if they'd expect the for loop to
have any similarity with a C for loop, or - a *very* common error - if
they'd expe
>> and my point is that users
>> are most of time correct when they assume that something will work the
>> same way as in C.
>
> Oh, really ? They would surely be wrong if they'd expect the for loop to
> have any similarity with a C for loop, or - a *very* common error - if
> they'd expect assignme
Yes, there are plenty of languages other than Java and C, but the
influence of C is admittedly huge in Python. Why do you think loops
are called "for", conditionals "if" or "while", functions return via
"return", loops terminate via "break" and keep going via "continue"
and
> (snip)
>> and my point is that users
>> are most of time correct when they assume that something will work the
>> same way as in C.
>
> Oh, really ? They would surely be wrong if they'd expect the for loop to
> have any similarity with a C for loop, or - a *very* common error - if
> they'd expect
Duncan Booth wrote:
Dennis Lee Bieber wrote:
for, if, and return were common keywords in FORTRAN.
Really? What does 'for' do in FORTRAN?
P.S. Does FORTRAN actually have keywords these days? Back when I learned it
there was no such thing as a reserved word though for all I know they
Dennis Lee Bieber wrote:
On Mon, 6 Jul 2009 19:48:39 -0700, Daniel Fetchinson
declaimed the following in
gmane.comp.python.general:
Yes, there are plenty of languages other than Java and C, but the
influence of C is admittedly huge in Python. Why do you think loops
are called "for", conditiona
On Mon, 06 Jul 2009 22:18:20 -0700, Chris Rebert wrote:
>> Not so rare. Decimal uses unary plus. Don't assume +x is a no-op.
[...]
> Well, yes, but when would you apply it twice in a row?
My point was that unary + isn't a no-op, and therefore neither is ++. For
Decimal, I can't think why you'd w
Daniel Fetchinson a écrit :
Yes, there are plenty of languages other than Java and C, but the
influence of C is admittedly huge in Python. Why do you think loops
are called "for", conditionals "if" or "while", functions return via
"return", loops terminate via "break" and keep going via "continue
Daniel Fetchinson a écrit :
(snip)
and my point is that users
are most of time correct when they assume that something will work the
same way as in C.
Oh, really ? They would surely be wrong if they'd expect the for loop to
have any similarity with a C for loop, or - a *very* common error - if
Dennis Lee Bieber wrote:
> for, if, and return were common keywords in FORTRAN.
Really? What does 'for' do in FORTRAN?
P.S. Does FORTRAN actually have keywords these days? Back when I learned it
there was no such thing as a reserved word though for all I know they may
have since added them.
On Mon, Jul 6, 2009 at 10:13 PM, Steven
D'Aprano wrote:
> On Tue, 07 Jul 2009 04:51:51 +, Lie Ryan wrote:
>
>> Chris Rebert wrote:
>>> On Mon, Jul 6, 2009 at 1:29 AM, Lawrence
>>> D'Oliveiro wrote:
In message , Tim
Golden wrote:
> The difficulty here is knowing where to put s
>> Yes, there are plenty of languages other than Java and C, but the
>> influence of C is admittedly huge in Python. Why do you think loops
>> are called "for", conditionals "if" or "while", functions return via
>> "return", loops terminate via "break" and keep going via "continue"
>> and why is co
On Tue, 07 Jul 2009 04:51:51 +, Lie Ryan wrote:
> Chris Rebert wrote:
>> On Mon, Jul 6, 2009 at 1:29 AM, Lawrence
>> D'Oliveiro wrote:
>>> In message , Tim
>>> Golden wrote:
>>>
The difficulty here is knowing where to put such a warning. You
obviously can't put it against the "++" op
Chris Rebert wrote:
> On Mon, Jul 6, 2009 at 1:29 AM, Lawrence
> D'Oliveiro wrote:
>> In message , Tim Golden
>> wrote:
>>
>>> The difficulty here is knowing where to put such a warning.
>>> You obviously can't put it against the "++" operator as such
>>> because... there isn't one.
>> This bug is
I wonder how many people have been tripped up by the fact that
++n
and
--n
fail silently for numeric-valued n.
>>>
>>> What do you mean, "fail silently"? They do exactly what you should
>>> expect:
>> ++5 # positive of a positive number is p
In message , Terry
Reedy wrote:
> ... it is C, not Python, that is out of step with standard usage in math
> and most languages ...
And it is C that introduced "==" for equality, versus "=" for assignment,
which Python slavishly followed instead of keeping "=" with its mathematical
meaning and
On Mon, 06 Jul 2009 17:54:35 +0100, Dave Angel wrote:
Rhodri James wrote:
Indeed, arguably it's a bug for C compilers to fail to find the valid
parsing of "++5" as "+(+5)". All I can say is that I've never even
accidentally typed that in twenty years of C programming.
But the C language spec
Mark Dickinson wrote:
On Jul 6, 3:32 am, Lawrence D'Oliveiro wrote:
I wonder how many people have been tripped up by the fact that
++n
and
--n
fail silently for numeric-valued n.
Rather few, it seems.
Recent python-ideas discussion on this subject:
http://mail.python.org/piperm
On Mon, Jul 6, 2009 at 07:12, Hendrik van Rooyen wrote:
> "Terry Reedy" wrote:
>
>> Gabriel Genellina wrote:
>> >
>> > In this case, a note in the documentation warning about the potential
>> > confusion would be fine.
>>
>> How would that help someone who does not read the doc?
>
> It obviously w
Rhodri James wrote:
On Mon,
06 Jul 2009 10:58:21 +0100, Steven D'Aprano
wrote:
On Mon, 06 Jul 2009 02:19:51 -0300, Gabriel Genellina wrote:
En Mon, 06 Jul 2009 00:28:43 -0300, Steven D'Aprano
escribió:
On Mon, 06 Jul 2009 14:32:46 +1200, Lawrence D'Oliveiro wrote:
I wonder how many peo
On Mon, 06 Jul 2009 10:58:21 +0100, Steven D'Aprano
wrote:
On Mon, 06 Jul 2009 02:19:51 -0300, Gabriel Genellina wrote:
En Mon, 06 Jul 2009 00:28:43 -0300, Steven D'Aprano
escribió:
On Mon, 06 Jul 2009 14:32:46 +1200, Lawrence D'Oliveiro wrote:
I wonder how many people have been tripped
On Jul 6, 3:32 am, Lawrence D'Oliveiro wrote:
> I wonder how many people have been tripped up by the fact that
>
> ++n
>
> and
>
> --n
>
> fail silently for numeric-valued n.
Recent python-ideas discussion on this subject:
http://mail.python.org/pipermail/python-ideas/2009-March/003741.h
On Jul 6, 1:12 pm, "Hendrik van Rooyen" wrote:
> "Terry Reedy" wrote:
> > Gabriel Genellina wrote:
>
> > > In this case, a note in the documentation warning about the potential
> > > confusion would be fine.
>
> > How would that help someone who does not read the doc?
>
> It obviously won't.
>
>
"Terry Reedy" wrote:
> Gabriel Genellina wrote:
> >
> > In this case, a note in the documentation warning about the potential
> > confusion would be fine.
>
> How would that help someone who does not read the doc?
It obviously won't.
All it will do, is that it will enable people on this group
On Mon, 06 Jul 2009 02:19:51 -0300, Gabriel Genellina wrote:
> En Mon, 06 Jul 2009 00:28:43 -0300, Steven D'Aprano
> escribió:
>> On Mon, 06 Jul 2009 14:32:46 +1200, Lawrence D'Oliveiro wrote:
>>
>>> I wonder how many people have been tripped up by the fact that
>>>
>>> ++n
>>>
>>> and
>>>
>>
Gabriel Genellina wrote:
In this case, a note in the documentation warning about the potential
confusion would be fine.
How would that help someone who does not read the doc?
--
http://mail.python.org/mailman/listinfo/python-list
On Jul 6, 12:32 pm, Lawrence D'Oliveiro wrote:
> I wonder how many people have been tripped up by the fact that
>
> ++n
>
> and
>
> --n
>
> fail silently for numeric-valued n.
What fail? In Python, ++n and --n are fatuous expressions which
SUCCEED silently except for rare circiumstances e
On Jul 6, 5:56 pm, Tim Golden wrote:
> Gabriel Genellina wrote:
> > In this case, a note in the documentation warning about the potential
> > confusion would be fine.
>
> The difficulty here is knowing where to put such a warning.
> You obviously can't put it against the "++" operator as such
> be
On Mon, Jul 6, 2009 at 1:29 AM, Lawrence
D'Oliveiro wrote:
> In message , Tim Golden
> wrote:
>
>> The difficulty here is knowing where to put such a warning.
>> You obviously can't put it against the "++" operator as such
>> because... there isn't one.
>
> This bug is an epiphenomenon. :)
Well, l
In message , Tim Golden
wrote:
> The difficulty here is knowing where to put such a warning.
> You obviously can't put it against the "++" operator as such
> because... there isn't one.
This bug is an epiphenomenon. :)
--
http://mail.python.org/mailman/listinfo/python-list
Gabriel Genellina wrote:
[... re confusion over ++n etc ...]
In this case, a note in the documentation warning about the potential
confusion would be fine.
The difficulty here is knowing where to put such a warning.
You obviously can't put it against the "++" operator as such
because... there
En Mon, 06 Jul 2009 03:33:36 -0300, Gary Herron
escribió:
Gabriel Genellina wrote:
En Mon, 06 Jul 2009 00:28:43 -0300, Steven D'Aprano
escribió:
On Mon, 06 Jul 2009 14:32:46 +1200, Lawrence D'Oliveiro wrote:
I wonder how many people have been tripped up by the fact that
++n
and
Gabriel Genellina wrote:
En Mon, 06 Jul 2009 00:28:43 -0300, Steven D'Aprano
escribió:
On Mon, 06 Jul 2009 14:32:46 +1200, Lawrence D'Oliveiro wrote:
I wonder how many people have been tripped up by the fact that
++n
and
--n
fail silently for numeric-valued n.
What do you mean,
En Mon, 06 Jul 2009 00:28:43 -0300, Steven D'Aprano
escribió:
On Mon, 06 Jul 2009 14:32:46 +1200, Lawrence D'Oliveiro wrote:
I wonder how many people have been tripped up by the fact that
++n
and
--n
fail silently for numeric-valued n.
What do you mean, "fail silently"? They do
On Mon, 06 Jul 2009 14:32:46 +1200, Lawrence D'Oliveiro wrote:
> I wonder how many people have been tripped up by the fact that
>
> ++n
>
> and
>
> --n
>
> fail silently for numeric-valued n.
What do you mean, "fail silently"? They do exactly what you should expect:
>>> ++5 # posit
On Sun, Jul 5, 2009 at 7:32 PM, Lawrence
D'Oliveiro wrote:
> I wonder how many people have been tripped up by the fact that
>
> ++n
>
> and
>
> --n
>
> fail silently for numeric-valued n.
Given that C-style for-loops are relatively infrequent in Python and
are usually written using range() w
48 matches
Mail list logo
