Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #51874 > unrolled thread

Where to suggest improvements in the official Python documentation?

Back to article view | Back to comp.lang.python

Contents

  Where to suggest improvements in the official Python documentation? Aseem Bansal <asmbansal2@gmail.com> - 2013-08-03 10:53 -0700
    Re: Where to suggest improvements in the official Python documentation? Joel Goldstick <joel.goldstick@gmail.com> - 2013-08-03 14:23 -0400
    Re: Where to suggest improvements in the official Python documentation? Terry Reedy <tjreedy@udel.edu> - 2013-08-03 16:43 -0400
      Re: Where to suggest improvements in the official Python documentation? Aseem Bansal <asmbansal2@gmail.com> - 2013-08-04 09:30 -0700
        Re: Where to suggest improvements in the official Python documentation? Joel Goldstick <joel.goldstick@gmail.com> - 2013-08-04 14:34 -0400
          Re: Where to suggest improvements in the official Python documentation? Aseem Bansal <asmbansal2@gmail.com> - 2013-08-20 07:22 -0700
            Re: Where to suggest improvements in the official Python documentation? Joel Goldstick <joel.goldstick@gmail.com> - 2013-08-20 10:57 -0400
        Functional Programming and python rusi <rustompmody@gmail.com> - 2013-09-22 19:21 -0700
          Re: Functional Programming and python Vito De Tullio <vito.detullio@gmail.com> - 2013-09-23 20:24 +0200
            Re: Functional Programming and python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-09-24 10:06 +0300
            Re: Functional Programming and python rusi <rustompmody@gmail.com> - 2013-09-24 00:08 -0700
              Re: Functional Programming and python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-09-24 10:42 +0300
                Re: Functional Programming and python rusi <rustompmody@gmail.com> - 2013-09-24 05:14 -0700
                  Re: Functional Programming and python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-09-24 17:51 +0300
                    Re: Functional Programming and python rusi <rustompmody@gmail.com> - 2013-09-24 08:07 -0700
                      Re: Functional Programming and python Chris Angelico <rosuav@gmail.com> - 2013-09-25 01:26 +1000
                        Re: Functional Programming and python rusi <rustompmody@gmail.com> - 2013-09-24 10:25 -0700
          Re: Functional Programming and python Franck Ditter <nobody@nowhere.org> - 2013-09-30 19:04 +0200
            Re: Functional Programming and python Chris Angelico <rosuav@gmail.com> - 2013-10-01 03:17 +1000
            Re: Functional Programming and python Neil Cerutti <neilc@norwich.edu> - 2013-09-30 18:36 +0000
              Re: Functional Programming and python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-01 00:14 +0000
                Re: Functional Programming and python Neil Cerutti <neilc@norwich.edu> - 2013-10-01 13:59 +0000
            Re: Functional Programming and python Piet van Oostrum <piet@vanoostrum.org> - 2013-09-30 14:55 -0400
              Re: Functional Programming and python Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-30 22:37 +0200
                Re: Functional Programming and python Piet van Oostrum <piet@vanoostrum.org> - 2013-10-01 13:31 -0400
            Re: Functional Programming and python Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-30 20:29 +0200
            Re: Functional Programming and python Tim Chase <python.list@tim.thechases.com> - 2013-09-30 16:02 -0500
            Re: Functional Programming and python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-01 00:41 +0000
            Re: Functional Programming and python alex23 <wuwei23@gmail.com> - 2013-10-01 11:03 +1000
            Re: Functional Programming and python Terry Reedy <tjreedy@udel.edu> - 2013-09-30 21:03 -0400
              Re: Functional Programming and python rusi <rustompmody@gmail.com> - 2013-09-30 18:36 -0700
                Re: Functional Programming and python Chris Angelico <rosuav@gmail.com> - 2013-10-01 17:28 +1000

Page 2 of 2 — ← Prev page 1 [2]

#55147 — Re: Functional Programming and python

On Mon, 30 Sep 2013 18:36:28 +0000, Neil Cerutti quoted:

>     Why can’t lambda forms contain statements?

Gah! Please fix your news client! (I see you're using slrn.) The \x92 
bytes found in your message are apostrophes (technically: right single 
quotation marks), encoded using the legacy Windows-1252 codec, but your 
news client is falsely advertising it as US-ASCII:

Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit


It's almost 2014, it is unspeakably poor form that an application is 
still making this mistake. Is there an updated version of slrn that fixes 
this? Can you manually force it to use UTF-8? Can you report this as a 
bug?

In case you aren't too clear on the concepts, here are two Must Read 
links:

http://www.joelonsoftware.com/articles/Unicode.html
http://nedbatchelder.com/text/unipain.html


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#55210 — Re: Functional Programming and python

On 2013-10-01, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> On Mon, 30 Sep 2013 18:36:28 +0000, Neil Cerutti quoted:
>
>>     Why can??t lambda forms contain statements?
>
> Gah! Please fix your news client! (I see you're using slrn.)
> The \x92 bytes found in your message are apostrophes
> (technically: right single quotation marks), encoded using the
> legacy Windows-1252 codec, but your news client is falsely
> advertising it as US-ASCII:
>
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 8bit
>
> It's almost 2014, it is unspeakably poor form that an
> application is still making this mistake. Is there an updated
> version of slrn that fixes this? Can you manually force it to
> use UTF-8? Can you report this as a bug?
>
> In case you aren't too clear on the concepts, here are two Must
> Read links:
>
> http://www.joelonsoftware.com/articles/Unicode.html
> http://nedbatchelder.com/text/unipain.html

Thanks, Steve. I'm aware my news setup is crap when it comes to
character set/unicode support. I haven't been motivated to fix
it, because everything else about it works great for me.

I'm afraid slrn is stagnated, but it might provide at least some
support and I need to find out what.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#55101 — Re: Functional Programming and python

Franck Ditter <nobody@nowhere.org> writes:

> Good approach of FP in Python, but two points make me crazy :
> 1. Tail recursion is not optimized. We are in 2013, why ? This is known technology (since 1960).
> And don't answer with "good programmers don't use recursion", this is bullshit.

Tail recursion optimization throws away valuable stack trace information in case of an error.

> 2. Lambda-expression body is limited to one expression. Why ?

Allowing general statements in a lambda body makes indentation more difficult, I think.
-- 
Piet van Oostrum <piet@vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]

[toc] | [prev] | [next] | [standalone]

#55113 — Re: Functional Programming and python

Op 30-09-13 20:55, Piet van Oostrum schreef:
> Franck Ditter <nobody@nowhere.org> writes:
>
>> Good approach of FP in Python, but two points make me crazy :
>> 1. Tail recursion is not optimized. We are in 2013, why ? This is known technology (since 1960).
>> And don't answer with "good programmers don't use recursion", this is bullshit.
>
> Tail recursion optimization throws away valuable stack trace information in case of an error.

This is hardly relevant. Because what are we told to use instead of
tail calls? We are told to use loops. But when you use a loop the
stack trace doesn't contain the values of previous runs through
the loop.

So how valuable is that stack frame information when the proposed
alternative doesn't produces it either.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#55230 — Re: Functional Programming and python

Antoon Pardon <antoon.pardon@rece.vub.ac.be> writes:

> Op 30-09-13 20:55, Piet van Oostrum schreef:
>> Franck Ditter <nobody@nowhere.org> writes:
>>
>>> Good approach of FP in Python, but two points make me crazy :
>>> 1. Tail recursion is not optimized. We are in 2013, why ? This is known technology (since 1960).
>>> And don't answer with "good programmers don't use recursion", this is bullshit.
>>
>> Tail recursion optimization throws away valuable stack trace information in case of an error.
>
> This is hardly relevant. Because what are we told to use instead of
> tail calls? We are told to use loops. But when you use a loop the
> stack trace doesn't contain the values of previous runs through
> the loop.
>
> So how valuable is that stack frame information when the proposed
> alternative doesn't produces it either.

This is incorrect. Loops are not always a replacement for tail recursion
optimization. Tail recursion optimization generally means that the last
function call before a return in a function reuses the current stack
frame instead of generating a new one. This is regardless of which
function is called, otherwise mutually recursive calls will not be
optimized. (Unless you do static analysis of all the functions calls
involved, which is very hard or even impossible in python.) A better
name for this process is therefore 'tail call optimization'. So any
function call that is last in its flow will be optimized. This gives a
lot of situations where stack trace information is thrown away, even in
those situations where a loop would not be an alternative and where
optimization would give little benefit. Anyway, deep recursion isn't
used very often in Python, which diminishes the value of tail call
optimization.
-- 
Piet van Oostrum <piet@vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]

[toc] | [prev] | [next] | [standalone]

#55103 — Re: Functional Programming and python

Op 30-09-13 19:04, Franck Ditter schreef:

>
> Good approach of FP in Python, but two points make me crazy :
> 1. Tail recursion is not optimized. We are in 2013, why ? This is known technology (since 1960).
> And don't answer with "good programmers don't use recursion", this is bullshit.

Guido doesn't like it.

> 2. Lambda-expression body is limited to one expression. Why ?
> Why the hell those limitations ? In this aspect, Javascript has a cooler approach.

Guido prefers it that way.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#55117 — Re: Functional Programming and python

On 2013-09-30 19:04, Franck Ditter wrote:
> two points make me crazy :
> 1. Tail recursion is not optimized. We are in 2013, why ? This is
> known technology (since 1960). And don't answer with "good
> programmers don't use recursion",

I seem to recall hearing that the primary reason it hadn't been
implemented is because of Python's super-dynamism (to make up a
word).  That a function could be a tail recursion in one call, but
the calling the same name could then become rebound.  I'm making up
the example, but I think it was something like this:

  def kablooie(*args):
    if not args:
      def kablooie(*args):
        woah()
    do_something(args)
    kablooie(args[1:])

where tail recursion optimization would do weird things.

-tkc

[toc] | [prev] | [next] | [standalone]

#55150 — Re: Functional Programming and python

On Mon, 30 Sep 2013 19:04:32 +0200, Franck Ditter wrote:

> Good approach of FP in Python, but two points make me crazy : 1. Tail
> recursion is not optimized. We are in 2013, why ? This is known
> technology (since 1960). And don't answer with "good programmers don't
> use recursion", this is bullshit.

Tail recursion optimization isn't really that useful. There is a HUGE 
universe of recursive problems which are not tail-recursive, and so 
cannot be optimized at all, or at least not automatically. Instead of 
encouraging people to rewrite such code using tail-recursion, which 
usually ends up obfuscating the code and introducing subtle bugs, it is 
better to encourage them to rewrite it to be iterative instead of 
recursive. Or just use recursion -- in many cases (although not all), if 
you have to recurse so many times that you pass the limit, your code is 
probably doing something wrong.

So tail-recursion optimization only helps in a tiny subset of recursive 
problems. Usually it doesn't help at all. And one cost is that you lose 
debugging information. Don't think of a single recursive function, where 
the traceback is extremely boring:

py> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in f
  File "<stdin>", line 2, in f
  [...]
  File "<stdin>", line 2, in f
  File "<stdin>", line 2, in f
  File "<stdin>", line 2, in f
RuntimeError: maximum recursion depth exceeded


Think of mutually recursive functions, where f calls g which calls h 
which sometimes calls f and sometimes calls g...

Personally, I'm not 100% convinced by these arguments. I think having a 
runtime option to enable or disable tail recursive optimizations would 
make Python a better language. Not by a lot, but by a tiny bit. But the 
people who would actually do the work don't care enough to do it, and the 
people who say they care don't bother doing the work.


> 2. Lambda-expression body is limited
> to one expression. Why ?

Nobody has come up with syntax that is unambiguous, would allow multiple 
statements in an expression, doesn't break backwards compatibility, and 
isn't ugly.

Since lambda is just a convenience, not a necessity -- it almost got 
dropped from Python 3 -- it is not worth compromising on those design 
requirements just for multiple-statement lambdas. It simply isn't 
important enough.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#55153 — Re: Functional Programming and python

On 1/10/2013 3:04 AM, Franck Ditter wrote:
> 1. Tail recursion is not optimized. We are in 2013, why ? This is known technology (since 1960).
> And don't answer with "good programmers don't use recursion", this is bullshit.

Here's an article Guido wrote explaining his reasoning:
http://neopythonic.blogspot.com.au/2009/04/tail-recursion-elimination.html

[toc] | [prev] | [next] | [standalone]

#55154 — Re: Functional Programming and python

On 9/30/2013 5:02 PM, Tim Chase wrote:
> On 2013-09-30 19:04, Franck Ditter wrote:
>> two points make me crazy :
>> 1. Tail recursion is not optimized. We are in 2013, why ? This is
>> known technology (since 1960). And don't answer with "good
>> programmers don't use recursion",
>
> I seem to recall hearing that the primary reason it hadn't been
> implemented is because of Python's super-dynamism (to make up a
> word).

Right. A tail call is a call immediately followed by a return (in the 
byte code or equivalent). A recursive tail call is a tail call to the 
function containing the tail call. In Python, the function to be called 
in a call is not determined until the call is made. This is because the 
function expression is evaluated to a function object at runtime, not 
when the function is compiled.

It would be trivial to detect and somewhat optimize all tail calls in 
CPython. But the result would be to delete traceback info with *all* 
tail calls, not just for recursive tail calls.

Some functions have multiple recursive calls, as with divide and conquer 
algorithms and graph traversal. The last recursive call might or might 
not be a tail call. When it is, having calls omitted from the traceback 
might be undesireable. It might be disconcerting, for instance, if the 
number of calls in the traceback for a balanced binary tree algorithm 
did *not* match the level where the error took place.

> That a function could be a tail recursion in one call, but
> the calling the same name could then become rebound.  I'm making up
> the example, but I think it was something like this:
>
>    def kablooie(*args):
>      if not args:
>        def kablooie(*args):
>          woah()
>      do_something(args)
>      kablooie(args[1:])
>
> where tail recursion optimization would do weird things.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#55157 — Re: Functional Programming and python

On Tuesday, October 1, 2013 6:11:18 AM UTC+5:30, Steven D'Aprano wrote:
> On Mon, 30 Sep 2013 19:04:32 +0200, Franck Ditter wrote:
> > 2. Lambda-expression body is limited to one expression. Why ?
> 
> Nobody has come up with syntax that is unambiguous, would allow multiple 
> statements in an expression, doesn't break backwards compatibility, and 
> isn't ugly.
> 
> Since lambda is just a convenience, not a necessity -- it almost got 
> dropped from Python 3 -- it is not worth compromising on those design 
> requirements just for multiple-statement lambdas. It simply isn't 
> important enough.

Agreed. λ-expressions are fundamental to functional programming theory; they are not strictly necessary to practical functional programming.

[Miranda one of the predecessors to haskell and a seminal FP language had no λ-expressions ] 

I find serious limitations in python from the pov of effectively doing FP; λ-expression limitations not the most crucial. eg
- scope leakage in comprehensions
- no comprehensions for tuples
- need to use assignments to simulate let
- mutable default parameters leak scope


On Monday, September 30, 2013 10:47:45 PM UTC+5:30, Chris Angelico wrote:
> On Tue, Oct 1, 2013 at 3:04 AM, Franck Ditter  wrote:
> 
> > 1. Tail recursion is not optimized. We are in 2013, why ? This is known technology (since 1960).
> > And don't answer with "good programmers don't use recursion", this is bullshit.
> 
> I've yet to see any value in having the compiler/interpreter optimize
> tail recursion that can't be achieved just as well, and usually more
> clearly, with simple iteration. Recursion's important; tail
> recursion's important; tail recursion optimization isn't.

Yeah -- since register allocation is isomorphic to graph-coloring[1] and graph-coloring is computationally hard[2], lets all go back to machine language!

[1] http://en.wikipedia.org/wiki/Register_allocation#Isomorphism_to_graph_colorability
[2] http://en.wikipedia.org/wiki/Graph_coloring#Algorithms

> (But I do sometimes yearn for a goto.)

Ha! In Scheme, a tail call IS a goto with parameter re-assignment

The real advantage to mandatory tail-call optimized language like scheme is pedagogical.

Students brought up on a scheme-like philosophy are liable to see recursion and iteration as synonymous [Certain common forms of recursion are more easily expressed as loops] and be more easy switching between them.

Recursion is just too central to the business of programming to afford having it pushed to one side in beginner's heads.

http://blog.languager.org/2012/05/recursion-pervasive-in-cs.html

The irony is that most non-FP programmers imagine that FP consists of using recursion for any and everything. See the progression and specially the last entry here http://www.willamette.edu/~fruehr/haskell/evolution.html

- no loops
- no recursion
- if possible no variables (the 'pointless' version)

[toc] | [prev] | [next] | [standalone]

#55167 — Re: Functional Programming and python

On Tue, Oct 1, 2013 at 11:36 AM, rusi <rustompmody@gmail.com> wrote:
>> (But I do sometimes yearn for a goto.)
>
> Ha! In Scheme, a tail call IS a goto with parameter re-assignment

Precisely. In fact, tail call optimization basically consists of that
exact rewrite. I'm absolutely fine with it being completely explicit.

ChrisA

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web