Re: [Python-Dev] Inconsistent script/console behaviour

2011-09-24 Thread Georg Brandl 
Am 24.09.2011 01:32, schrieb Guido van Rossum:
> On Fri, Sep 23, 2011 at 4:25 PM, anatoly techtonik  
> wrote:
>> Currently if you work in console and define a function and then
>> immediately call it - it will fail with SyntaxError.
>> For example, copy paste this completely valid Python script into console:
>>
>> def some():
>>  print "XXX"
>> some()
>>
>> There is an issue for that that was just closed by Eric. However, I'd
>> like to know if there are people here that agree that if you paste a
>> valid Python script into console - it should work without changes.
> 
> You can't fix this without completely changing the way the interactive
> console treats blank lines. None that it's not just that a blank line
> is required after a function definition -- you also *can't* have a
> blank line *inside* a function definition.

While the former could be changed (I think), the latter certainly cannot.
So it's probably not worth changing established behavior.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Inconsistent script/console behaviour

2011-09-24 Thread Yuval Greenfield 
Could you elaborate on what would be wrong if function definitions ended
only after an explicitly less indented line? The only problem that comes to
mind is global scope "if" statements that wouldn't execute when expected (we
actually might need to terminate them with a dedented "pass").
On Sep 24, 2011 4:26 AM, "Georg Brandl"  wrote:
> Am 24.09.2011 01:32, schrieb Guido van Rossum:
>> On Fri, Sep 23, 2011 at 4:25 PM, anatoly techtonik 
wrote:
>>> Currently if you work in console and define a function and then
>>> immediately call it - it will fail with SyntaxError.
>>> For example, copy paste this completely valid Python script into
console:
>>>
>>> def some():
>>> print "XXX"
>>> some()
>>>
>>> There is an issue for that that was just closed by Eric. However, I'd
>>> like to know if there are people here that agree that if you paste a
>>> valid Python script into console - it should work without changes.
>>
>> You can't fix this without completely changing the way the interactive
>> console treats blank lines. None that it's not just that a blank line
>> is required after a function definition -- you also *can't* have a
>> blank line *inside* a function definition.
>
> While the former could be changed (I think), the latter certainly cannot.
> So it's probably not worth changing established behavior.
>
> Georg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ubershmekel%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Inconsistent script/console behaviour

2011-09-24 Thread Georg Brandl 
You're right that in principle for function definitions there is no ambiguity.
But you also presented the downfall of that proposal: all multi-clause
statements will still need an explicit way of termination, and of course the
"pass" would be exceedingly ugly, not to mention much more confusing than the
current way.

Georg

Am 24.09.2011 11:53, schrieb Yuval Greenfield:
> Could you elaborate on what would be wrong if function definitions ended only
> after an explicitly less indented line? The only problem that comes to mind is
> global scope "if" statements that wouldn't execute when expected (we actually
> might need to terminate them with a dedented "pass").
> 
> On Sep 24, 2011 4:26 AM, "Georg Brandl"  > wrote:
>> Am 24.09.2011 01:32, schrieb Guido van Rossum:
>>> On Fri, Sep 23, 2011 at 4:25 PM, anatoly techtonik  > wrote:
 Currently if you work in console and define a function and then
 immediately call it - it will fail with SyntaxError.
 For example, copy paste this completely valid Python script into console:

 def some():
 print "XXX"
 some()

 There is an issue for that that was just closed by Eric. However, I'd
 like to know if there are people here that agree that if you paste a
 valid Python script into console - it should work without changes.
>>>
>>> You can't fix this without completely changing the way the interactive
>>> console treats blank lines. None that it's not just that a blank line
>>> is required after a function definition -- you also *can't* have a
>>> blank line *inside* a function definition.
>>
>> While the former could be changed (I think), the latter certainly cannot.
>> So it's probably not worth changing established behavior.




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Inconsistent script/console behaviour

2011-09-24 Thread Guido van Rossum 
I see a lot of flawed "proposals". This is clearly a python-ideas
discussion. (Anatoly, take note -- please post your new gripe there.)

In the mean time, there's a reasonable work-around if you have to
copy/paste a large block of formatted code:

>>> exec('''
   .
   .
   .

   .
   .
   .
''')
>>>

The only thing that you can't put in there is a triple-quoted string
using single quotes.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] range objects in 3.x

2011-09-24 Thread Guido van Rossum 
On Fri, Sep 23, 2011 at 11:55 PM, Georg Brandl  wrote:
> Am 24.09.2011 04:40, schrieb Guido van Rossum:
>> On Fri, Sep 23, 2011 at 7:13 PM, Steven D'Aprano  wrote:
> http://code.activestate.com/recipes/577068-floating-point-range/

 I notice that your examples carefully skirt around the rounding issues.
>>>
>>> I also carefully *didn't* claim that it made rounding issues disappear
>>> completely. I'll add a note clarifying that rounding still occurs and as a
>>> consequence results can be unexpected.
>>
>> I believe this API is fundamentally wrong for float ranges, even if
>> it's great for int ranges, and I will fight against adding it to the
>> stdlib in that form.
>>
>> Maybe we can come up with a better API, and e.g. specify begin and end
>> points and the number of subdivisions? E.g. frange(0.0, 2.1, 3) would
>> generate [0.0, 0.7, 1.4].
>
> This is what numpy calls linspace:
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.linspace.html
>
> numpy also has an "arange" that works with floats, but:
> """When using a non-integer step, such as 0.1, the results will often not be
> consistent. It is better to use linspace for these cases."""

Aha, I like linspace(). I started a G+ thread
(https://plus.google.com/u/0/115212051037621986145/posts/ZnrWDiHHiaW)
but it mostly served to demonstrate that few people understand
floating point, and that those that do don't understand how hard it is
for the others. Jeffrey Yaskin's analysis (starting with "To anyone
who thinks they can recover inside frange():") is the best of the
bunch. But I still believe that it's best *not* to have frange(), and
to warn about the flaws in the existing implementations floating
around (like Steven's), referring them to linspace() instead.

It looks easy enough to implement a basic linspace() that doesn't have
the problems of frange(), and having a recipe handy (for those who
don't want or need NumPy) would be a great start.

I expect that to implement a version worthy of the stdlib math module,
i.e. that computes values that are correct within 0.5ULP under all
circumstances (e.g. lots of steps, or an end point close to the end of
the floating point range) we'd need a numerical wizard like Mark
Dickinson or Tim Peters (retired). Or maybe we could just borrow
numpy's code.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] range objects in 3.x

2011-09-24 Thread Terry Reedy 

On 9/23/2011 10:40 PM, Guido van Rossum wrote:

On Fri, Sep 23, 2011 at 7:13 PM, Steven D'Aprano  wrote:



I also carefully *didn't* claim that it made rounding issues disappear
completely. I'll add a note clarifying that rounding still occurs and as a
consequence results can be unexpected.


To avoid inclusion/exclusion errors, you should be testing values 
against a stop value that is (except for rounding errors) half a step 
above the last value you want to yield. In other words, subtract or add 
step/2.0 to the stop value according to whether or not you want it 
excluded or included.



I believe this API is fundamentally wrong for float ranges, even if
it's great for int ranges, and I will fight against adding it to the
stdlib in that form.


I completely agree. For range(n), n is both the stop value and number of 
ints generated. It is otherwise stop-start, which is to say, stop = 
start + n, which is why there is no need for an n-based api (all this is 
by design).



Maybe we can come up with a better API, and e.g. specify begin and end
points and the number of subdivisions? E.g. frange(0.0, 2.1, 3) would
generate [0.0, 0.7, 1.4]. Or maybe it would even be better to use
inclusive end points? OTOH if you consider extending the API to
complex numbers, it might be better to specify an initial value, a
step, and a count. So frange(0.0, 0.7, 3) to generate [0.0, 0.7, 1.4].
Probably it shouldn't be called frange then.


In float use cases I can think of, one wants either both or neither end 
point. If neither, one probably wants points at .5*step, 1.5*step, etc., 
where step calculated as (right-left)/n.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] range objects in 3.x

2011-09-24 Thread Steven D'Aprano 

Guido van Rossum wrote:

On Fri, Sep 23, 2011 at 7:13 PM, Steven D'Aprano  wrote:

http://code.activestate.com/recipes/577068-floating-point-range/

I notice that your examples carefully skirt around the rounding issues.

I also carefully *didn't* claim that it made rounding issues disappear
completely. I'll add a note clarifying that rounding still occurs and as a
consequence results can be unexpected.


I believe this API is fundamentally wrong for float ranges, even if
it's great for int ranges, and I will fight against adding it to the
stdlib in that form.


I wasn't proposing it to be in the standard lib, it was just an idle 
comment triggered by the OP's question. But I'm gratified it has started 
an interesting discussion.


Whether the most float-friendly or not, the start/stop/step API is the 
most obvious and user-friendly for at least one use-case: graphing of 
functions.


It is natural to say something like "draw a graph starting at 0, 
sampling every 0.1 unit, and stop when you get past 3". My HP-48 
graphing calculator does exactly that: you must specify the start and 
stop coordinates, and an optional step size. By default, the step size 
is calculated for you assuming you want one point plotted per pixel. 
Given that the calculator display is both low-resolution and fixed size, 
that makes sense as the default, but you can set the step size manually 
if desired.


start/stop/step is also familiar for users of Excel and other 
spreadsheets' Fill>Series command.


Numeric integration is an interesting case, because generally you want 
multiple iterations, interpolating between the points previously seen 
until you reach some desired level of accuracy. E.g.:


#1:  0.0, 0.5, 1.0
#2:  0.25, 0.75
#3:  0.125, 0.375, 0.625, 0.875

For integration, I would probably want both APIs.



Maybe we can come up with a better API, and e.g. specify begin and end
points and the number of subdivisions? 


Thanks to Mark Dickinson for suggesting using Fraction, I have this:

http://code.activestate.com/recipes/577878-generate-equally-spaced-floats/



--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com