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

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

Python is going to be hard

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

Contents

  Python is going to be hard Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-09-03 14:10 -0400
    Re: Python is going to be hard John Gordon <gordon@panix.com> - 2014-09-03 18:17 +0000
      Re: Python is going to be hard Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-09-03 14:52 -0400
        Re: Python is going to be hard mm0fmf <none@mailinator.com> - 2014-09-03 22:37 +0100
    Re: Python is going to be hard Rock Neurotiko <miguelglafuente@gmail.com> - 2014-09-03 20:16 +0200
    Re: Python is going to be hard Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-09-03 11:19 -0700
      Re: Python is going to be hard Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-09-03 14:50 -0400
    Re: Python is going to be hard MRAB <python@mrabarnett.plus.com> - 2014-09-03 19:24 +0100
    Re: Python is going to be hard Skip Montanaro <skip@pobox.com> - 2014-09-03 13:28 -0500
      Re: Python is going to be hard Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-09-03 14:52 -0400
    Re: Python is going to be hard Ethan Furman <ethan@stoneleaf.us> - 2014-09-03 11:33 -0700
      Re: Python is going to be hard Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-09-03 14:41 -0400
        Re: Python is going to be hard Ethan Furman <ethan@stoneleaf.us> - 2014-09-03 12:49 -0700
    Re: Python is going to be hard Juan Christian <juan0christian@gmail.com> - 2014-09-03 15:44 -0300
      Re: Python is going to be hard Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-09-03 14:56 -0400
    Re: Python is going to be hard Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-09-03 14:49 -0400
      Re: Python is going to be hard Ethan Furman <ethan@stoneleaf.us> - 2014-09-03 11:55 -0700
        Re: Python is going to be hard Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-09-03 12:01 -0700
      Re: Python is going to be hard Ian Kelly <ian.g.kelly@gmail.com> - 2014-09-03 13:11 -0600
        Re: Python is going to be hard Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-09-03 15:22 -0400
      Re: Python is going to be hard Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-09-04 12:11 +1000
    Re: Python is going to be hard Denis McMahon <denismfmcmahon@gmail.com> - 2014-09-03 20:55 +0000
    Re: Python is going to be hard Rustom Mody <rustompmody@gmail.com> - 2014-09-03 18:48 -0700
      Re: Python is going to be hard Chris Angelico <rosuav@gmail.com> - 2014-09-04 11:56 +1000
        Re: Python is going to be hard Rustom Mody <rustompmody@gmail.com> - 2014-09-03 19:10 -0700
          Re: Python is going to be hard Chris Angelico <rosuav@gmail.com> - 2014-09-04 12:25 +1000
            Re: Python is going to be hard Rustom Mody <rustompmody@gmail.com> - 2014-09-03 19:33 -0700
              Re: Python is going to be hard alister <alister.nospam.ware@ntlworld.com> - 2014-09-04 10:29 +0000
                Re: Python is going to be hard Rustom Mody <rustompmody@gmail.com> - 2014-09-04 06:08 -0700
            Re: Python is going to be hard Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-09-04 23:25 +1000
              Re: Python is going to be hard Chris Angelico <rosuav@gmail.com> - 2014-09-04 23:55 +1000
        Re: Python is going to be hard Rustom Mody <rustompmody@gmail.com> - 2014-09-03 20:22 -0700
          Re: Python is going to be hard Chris Angelico <rosuav@gmail.com> - 2014-09-04 13:49 +1000
            Re: Python is going to be hard Rustom Mody <rustompmody@gmail.com> - 2014-09-03 21:11 -0700
              Re: Python is going to be hard Chris Angelico <rosuav@gmail.com> - 2014-09-04 15:02 +1000
                Re: Python is going to be hard Rustom Mody <rustompmody@gmail.com> - 2014-09-03 23:23 -0700
                  Re: Python is going to be hard Chris Angelico <rosuav@gmail.com> - 2014-09-04 16:39 +1000
                    Re: Python is going to be hard Rustom Mody <rustompmody@gmail.com> - 2014-09-04 06:15 -0700
                      Re: Python is going to be hard Chris Angelico <rosuav@gmail.com> - 2014-09-04 23:30 +1000
                    Re: Python is going to be hard Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-09-04 23:37 +1000
                      Re: Python is going to be hard Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-09-04 15:04 +0100
                      Re: Python is going to be hard Chris Angelico <rosuav@gmail.com> - 2014-09-05 00:08 +1000
                        Re: Python is going to be hard Rustom Mody <rustompmody@gmail.com> - 2014-09-04 19:24 -0700
                          Re: Python is going to be hard Chris Angelico <rosuav@gmail.com> - 2014-09-05 12:30 +1000
                            Re: Python is going to be hard Roy Smith <roy@panix.com> - 2014-09-04 22:51 -0400
                            Re: Python is going to be hard Rustom Mody <rustompmody@gmail.com> - 2014-09-04 19:56 -0700
                              Re: Python is going to be hard Chris Angelico <rosuav@gmail.com> - 2014-09-05 13:08 +1000
          Re: Python is going to be hard Ethan Furman <ethan@stoneleaf.us> - 2014-09-03 21:06 -0700
            Re: Python is going to be hard Rustom Mody <rustompmody@gmail.com> - 2014-09-03 21:15 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#77521

Seymore4Head wrote:

> Ok, I understand now that x is actually the first item in the list.
> What I want is a loop that goes from 1 to the total number of items in
> the list steve.

99% of the time, you don't want that at all. Trust me, iterating over the
values in the list is *nearly* always the right solution.

But for those times you actually do want 1...N, use the range() function.
Remember that in Python, ranges are "half open": the start value is
*included*, but the end value is *excluded*. Also, the start value defaults
to 0. So for example, if you wanted the numbers 1...5:

range(5) --> range(0, 5) --> [0, 1, 2, 3, 4]

range(1, 5+1) --> range(1, 6) --> [1, 2, 3, 4, 5]

So to iterate over 1 to the number of items in list `steve`:

for i in range(1, len(steve)+1):
    print(i)


But if you are ever tempted to write something like this:

for i in range(1, len(steve)+1):
    x = steve[i-i]  # adjust the index from 1-based to 0-based
    print(i, x)


we will take you out and slap you with a rather large hallibut
https://www.youtube.com/watch?v=IhJQp-q1Y1s

*wink*

The right way to do that is:

for i, x in enumerate(steve, 1):
    print(i, x)


-- 
Steven

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

#77507

On Wed, 03 Sep 2014 14:10:42 -0400, Seymore4Head wrote:

> import math import random import sys b=[]
> steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
> for x in steve:
>     print (steve[x])
> 
> Traceback (most recent call last):
>   File "C:\Functions\blank.py", line 7, in <module>
>     print (steve[x])
> IndexError: list index out of range

x is the value, not the index

Try:

steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
for x in steve:
    print (x)

or if you want to use the index:

for x in range(len(steve)):
    print (steve[x])


-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#77515

On Wednesday, September 3, 2014 11:41:27 PM UTC+5:30, Seymore4Head wrote:
> import math
> import random
> import sys
> b=[]
> steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
> for x in steve:
>     print (steve[x])

> Traceback (most recent call last):
>     print (steve[x])
> IndexError: list index out of range

$ python
Python 2.7.8 (default, Aug 23 2014, 21:00:50) 
[GCC 4.9.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
>>> steve
[1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
>>> # You can see steve (strange name choice) without any printing

>>> [x for x in steve]
[1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
>>> # A bit long-winded but good to get used to; And NO PRINT

>>> [(x,y) for (x,y) in zip(steve, range(100))]
[(1, 0), (1, 1), (2, 2), (3, 3), (5, 4), (8, 5), (13, 6), (21, 7), (34, 8), (55, 9), (89, 10)]
>>> # NO PRINT; but whats that 100 there?

>>> [(x,y) for (x,y) in zip(steve, range(len(steve)))]
[(1, 0), (1, 1), (2, 2), (3, 3), (5, 4), (8, 5), (13, 6), (21, 7), (34, 8), (55, 9), (89, 10)]
>>> # NO PRINT; but sufficiently common that it needs a shortform


>>> [(x,y) for (x,y) in enumerate(steve)]
[(0, 1), (1, 1), (2, 2), (3, 3), (4, 5), (5, 8), (6, 13), (7, 21), (8, 34), (9, 55), (10, 89)]
>>> # NO PRINT but why not just the simple

>>> enumerate(steve)
<enumerate object at 0x7f0434de2780>
>>> # Hmm whats that??

>>> list(enumerate(steve))
[(0, 1), (1, 1), (2, 2), (3, 3), (4, 5), (5, 8), (6, 13), (7, 21), (8, 34), (9, 55), (10, 89)]
>>> NO PRINT

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

#77517

On Thu, Sep 4, 2014 at 11:48 AM, Rustom Mody <rustompmody@gmail.com> wrote:
>>>> NO PRINT

Yes, or the OP could work with actual saved .py files and the
reliability that comes from predictable execution environments... and
use print. Why are you so dead against print?

ChrisA

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

#77520

On Thursday, September 4, 2014 7:26:56 AM UTC+5:30, Chris Angelico wrote:
> On Thu, Sep 4, 2014 at 11:48 AM, Rustom Mody wrote:
> >>>> NO PRINT


> Why are you so dead against print?

Because it heralds a typical noob code-smell
[especially  when the OP admits that BASIC is his background]

> Yes, or the OP could work with actual saved .py files and the
> reliability that comes from predictable execution environments... and
> use print.

Dunno what you are talking about

The interpreter-REPL is less reliable than a script?

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

#77524

On Thu, Sep 4, 2014 at 12:10 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Thursday, September 4, 2014 7:26:56 AM UTC+5:30, Chris Angelico wrote:
>> On Thu, Sep 4, 2014 at 11:48 AM, Rustom Mody wrote:
>> >>>> NO PRINT
>
>
>> Why are you so dead against print?
>
> Because it heralds a typical noob code-smell
> [especially  when the OP admits that BASIC is his background]

And, of course, all those lovely Unix programs that produce output on
stdout, they're full of code smell too, right? I don't care what
someone's background is; console output is *not* code smell.

Anyway, all you're doing is relying on the magic of interactive mode
to call repr() and print() for you.

>> Yes, or the OP could work with actual saved .py files and the
>> reliability that comes from predictable execution environments... and
>> use print.
>
> Dunno what you are talking about
>
> The interpreter-REPL is less reliable than a script?

When you start a script, you have a consistent environment - an empty
one. When you write a series of commands in the interactive
interpreter, the environment for each one depends on all the preceding
commands. So when you have a problem, you might have to copy and paste
the entire interpreter session, rather than just the one command.

ChrisA

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

#77525

On Thursday, September 4, 2014 7:56:31 AM UTC+5:30, Chris Angelico wrote:
> On Thu, Sep 4, 2014 at 12:10 PM, Rustom Mody wrote:
> > On Thursday, September 4, 2014 7:26:56 AM UTC+5:30, Chris Angelico wrote:
> >> On Thu, Sep 4, 2014 at 11:48 AM, Rustom Mody wrote:
> >> >>>> NO PRINT
> >> Why are you so dead against print?
> > Because it heralds a typical noob code-smell
> > [especially  when the OP admits that BASIC is his background]

> And, of course, all those lovely Unix programs that produce output on
> stdout, they're full of code smell too, right? I don't care what
> someone's background is; console output is *not* code smell.

Tell me the same after having taught a few thousand students
If you are at the level of writing useful unix scripts, you are not
going to be asking these questions.

> Anyway, all you're doing is relying on the magic of interactive mode
> to call repr() and print() for you.

Yes its usually called DRY.
That P in the REPL is put in a neat and nifty place. Why repeat?

> >> Yes, or the OP could work with actual saved .py files and the
> >> reliability that comes from predictable execution environments... and
> >> use print.
> > Dunno what you are talking about
> > The interpreter-REPL is less reliable than a script?

> When you start a script, you have a consistent environment - an empty
> one. When you write a series of commands in the interactive
> interpreter, the environment for each one depends on all the preceding
> commands. So when you have a problem, you might have to copy and paste
> the entire interpreter session, rather than just the one command.

Agreed. Thats a downside.
Very minor compared to the mess induced by unstructured print-filled noob code.

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

#77539

On Wed, 03 Sep 2014 19:33:41 -0700, Rustom Mody wrote:

> On Thursday, September 4, 2014 7:56:31 AM UTC+5:30, Chris Angelico
> wrote:
>> On Thu, Sep 4, 2014 at 12:10 PM, Rustom Mody wrote:
>> > On Thursday, September 4, 2014 7:26:56 AM UTC+5:30, Chris Angelico
>> > wrote:
>> >> On Thu, Sep 4, 2014 at 11:48 AM, Rustom Mody wrote:
>> >> >>>> NO PRINT
>> >> Why are you so dead against print?
>> > Because it heralds a typical noob code-smell [especially  when the OP
>> > admits that BASIC is his background]
> 
>> And, of course, all those lovely Unix programs that produce output on
>> stdout, they're full of code smell too, right? I don't care what
>> someone's background is; console output is *not* code smell.
> 
> Tell me the same after having taught a few thousand students If you are
> at the level of writing useful unix scripts, you are not going to be
> asking these questions.
> 
>> Anyway, all you're doing is relying on the magic of interactive mode to
>> call repr() and print() for you.
> 
> Yes its usually called DRY.
> That P in the REPL is put in a neat and nifty place. Why repeat?
> 
>> >> Yes, or the OP could work with actual saved .py files and the
>> >> reliability that comes from predictable execution environments...
>> >> and use print.
>> > Dunno what you are talking about The interpreter-REPL is less
>> > reliable than a script?
> 
>> When you start a script, you have a consistent environment - an empty
>> one. When you write a series of commands in the interactive
>> interpreter, the environment for each one depends on all the preceding
>> commands. So when you have a problem, you might have to copy and paste
>> the entire interpreter session, rather than just the one command.
> 
> Agreed. Thats a downside.
> Very minor compared to the mess induced by unstructured print-filled
> noob code.

until the New programmer (I hate the word noob, it looks too derogatory 
even when that is not the intention) has learnt enough to be using a 
logging module i can see no alternative to using print for debugging 
purposes.

I would agree that in production code they are often the wrong option 
(although still valid for CLI applications.) 



-- 
You can't get there from here.

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

#77544

On Thursday, September 4, 2014 3:59:57 PM UTC+5:30, alister wrote:
> On Wed, 03 Sep 2014 19:33:41 -0700, Rustom Mody wrote:

> > On Thursday, September 4, 2014 7:56:31 AM UTC+5:30, Chris Angelico
> > wrote:
> >> When you start a script, you have a consistent environment - an empty
> >> one. When you write a series of commands in the interactive
> >> interpreter, the environment for each one depends on all the preceding
> >> commands. So when you have a problem, you might have to copy and paste
> >> the entire interpreter session, rather than just the one command.
> > Agreed. Thats a downside.
> > Very minor compared to the mess induced by unstructured print-filled
> > noob code.

> until the New programmer (I hate the word noob, it looks too derogatory 
> even when that is not the intention) has learnt enough to be using a 
> logging module i can see no alternative to using print for debugging 
> purposes.

Fully agree. If the one giving the instruction makes it clear that
this thing called a print statement (expression) is something -- a
probe -- you stick into the program to figure out whats happening,
thats fine.  If its presented as something that a program can have any
amount of then its not.

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

#77546

Chris Angelico wrote:

> On Thu, Sep 4, 2014 at 12:10 PM, Rustom Mody <rustompmody@gmail.com>
> wrote:
>> On Thursday, September 4, 2014 7:26:56 AM UTC+5:30, Chris Angelico wrote:
>>> On Thu, Sep 4, 2014 at 11:48 AM, Rustom Mody wrote:
>>> >>>> NO PRINT
>>
>>
>>> Why are you so dead against print?
>>
>> Because it heralds a typical noob code-smell
>> [especially  when the OP admits that BASIC is his background]
> 
> And, of course, all those lovely Unix programs that produce output on
> stdout, they're full of code smell too, right? I don't care what
> someone's background is; console output is *not* code smell.

I cautiously agree with Rustom on this one. Of course console output is
often useful, but it is slightly smelly:

- beginners have a tendency to use print when they should be using
  return, and consequently can't easily chain functions together;

- languages like shell scripting languages, which are designed to
  chain such printing functions together, suffer because of it:

  * they're less efficient, due to having to convert to and 
    from text repeatedly; 

  * as a programming language, they're rather impoverished,
    even if they have internal data types which aren't text,
    they can't pass output to other programs except as text;

    (very occasionally, they support a hybrid "text separated
    by NUL bytes" mode)

  * they tend to be rather less resilient since they cannot 
    easily separate presentation from calculation; any change
    to the presentation, or unexpected presentation, is likely
    to break your code silently.

Think of how many broken bash scripts there are out there which assume that
files names can never contain newlines. Or, for that matter, spaces.

Even in Python, consider how limiting something like dis.dis() is, seeing
how it prints its output instead of returning it.


> Anyway, all you're doing is relying on the magic of interactive mode
> to call repr() and print() for you.

Well, yes, but isn't that the point? Let your tools do most of the work.

[...]
>> The interpreter-REPL is less reliable than a script?
> 
> When you start a script, you have a consistent environment - an empty
> one. When you write a series of commands in the interactive
> interpreter, the environment for each one depends on all the preceding
> commands. So when you have a problem, you might have to copy and paste
> the entire interpreter session, rather than just the one command.

True, but the same applies to a script. If you have a problem with line 100,
you can't just post line 100, you may have to post the entire 100 lines
before it. Being able to isolate the problem to the minimal amount of code
needed to demonstrate it is an important skill for all developers.


-- 
Steven

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

#77549

On Thu, Sep 4, 2014 at 11:25 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Of course console output is
> often useful, but it is slightly smelly:
>
> - beginners have a tendency to use print when they should be using
>   return, and consequently can't easily chain functions together;
>
> - languages like shell scripting languages, which are designed to
>   chain such printing functions together, suffer because of it:
>
> Think of how many broken bash scripts there are out there which assume that
> files names can never contain newlines. Or, for that matter, spaces.

Focusing everything on output, yes that's a problem. (Look at the ob_*
functions in PHP - they are an abomination built to cope with other
abominations.)

> Even in Python, consider how limiting something like dis.dis() is, seeing
> how it prints its output instead of returning it.

I agree that it's limited - but how would you do it differently?
Python's repr for multiline text is pretty unreadable. The only way I
could imagine it being done is if it returns a custom object whose
repr is the text we usually see. If you want to send it somewhere
other than the console. dis.dis(file=...) works; and if you want to do
something other than simple output, you probably want one of the
lower-level functions (which I haven't personally dug into, but I'm
thinking get_instructions is probably more useful than dis for more
complicated jobs).

>> Anyway, all you're doing is relying on the magic of interactive mode
>> to call repr() and print() for you.
>
> Well, yes, but isn't that the point? Let your tools do most of the work.

Sure, but if you hate something enough to scream "NO PRINT" at us,
isn't it a bit odd to advocate something that does the exact same
thing only hidden? Why is it somehow okay to rely on the side effect
of intermediate expression results getting printed, while decrying
side effects anywhere else?

>>> The interpreter-REPL is less reliable than a script?
>>
>> When you start a script, you have a consistent environment - an empty
>> one. When you write a series of commands in the interactive
>> interpreter, the environment for each one depends on all the preceding
>> commands. So when you have a problem, you might have to copy and paste
>> the entire interpreter session, rather than just the one command.
>
> True, but the same applies to a script. If you have a problem with line 100,
> you can't just post line 100, you may have to post the entire 100 lines
> before it. Being able to isolate the problem to the minimal amount of code
> needed to demonstrate it is an important skill for all developers.

Yes, that's true. But a dozen-line script that's been through a dozen
iterations of editing is still a dozen lines of script, whereas it
might be sixty or seventy lines of interactive output. It's generally
easier to "isolate to the minimum" when you start with something
that's inherently shorter. It's also easier to isolate to the minimum
when you work with a consistent starting position, rather than have
each one build on the preceding ones.

Like I said in my most recent response to Rustom, we probably don't
disagree nearly as much as it seemed at the first couple of responses.

ChrisA

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

#77526

On Thursday, September 4, 2014 7:26:56 AM UTC+5:30, Chris Angelico wrote:
> On Thu, Sep 4, 2014 at 11:48 AM, Rustom Mody  wrote:
> >>>> NO PRINT

> Yes, or the OP could work with actual saved .py files and the
> reliability that comes from predictable execution environments... and
> use print. Why are you so dead against print?

Here is the most recent (2013) ACM/IEEE CS curriculum:
www.acm.org/education/CS2013-final-report.pdf

It is divided into tiers with core-tier1 being the bare minimum that
all CS graduate need to know.

One of (the many!) things there is this (pg 158)

| Functional Programming (3 Core-Tier1 hours)

| Effect-free programming
| -- Function calls have no side effects, facilitating compositional reasoning
| -- Variables are immutable, preventing unexpected changes to program data by other code
| -- Data can be freely aliased or copied without introducing unintended effects from mutation

So to answer your question: print statements are side-effecting and therefore obstruct
compositional reasoning.

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

#77527

On Thu, Sep 4, 2014 at 1:22 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> | Effect-free programming
> | -- Function calls have no side effects, facilitating compositional reasoning
> | -- Variables are immutable, preventing unexpected changes to program data by other code
> | -- Data can be freely aliased or copied without introducing unintended effects from mutation
>
> So to answer your question: print statements are side-effecting and therefore obstruct
> compositional reasoning.

Yeah, fine. One small problem: Computers aren't built to do nothing.
"Effect-free programming" is utterly valueless and purposeless. To
make a program actually useful, you need to have some effect
somewhere. So where do you do that? Where do you permit a function
with side effects?

If you force *everything* to be in the return value, you lose any
possibility of partial results - for instance, if it takes two weeks
to render a ray-traced animation, you actually spend the entire two
weeks building up a single, gigantic return value, which some outside
system (which is presumably allowed to have side effects) then saves
somewhere. In the meantime, you have absolutely no idea how far it's
progressed - no information that it's completed frame 6 and is working
on frame 7, nothing. Because telling the user anything is a side
effect.

And if my function f calls show_status_to_user() which has side
effects, then f has side effects too, and you can no longer reason
purely about f. The impurity that makes for practicality (hey, isn't
there something in the Zen of Python about that?) pollutes upwards
until all you'll have will be pockets of pure functional code that
execute quickly enough to not need any intermediate output. That
doesn't equate to "abolish print", that just means that you separate
the guts from the UI - which is good advice for any system, no matter
what its structure.

ChrisA

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

#77531

On Thursday, September 4, 2014 9:20:02 AM UTC+5:30, Chris Angelico wrote:
> On Thu, Sep 4, 2014 at 1:22 PM, Rustom Mody  wrote:
> > | Effect-free programming
> > | -- Function calls have no side effects, facilitating compositional reasoning
> > | -- Variables are immutable, preventing unexpected changes to program data by other code
> > | -- Data can be freely aliased or copied without introducing unintended effects from mutation
> > So to answer your question: print statements are side-effecting and therefore obstruct
> > compositional reasoning.

> Yeah, fine. One small problem: Computers aren't built to do nothing.
> "Effect-free programming" is utterly valueless and purposeless. To
> make a program actually useful, you need to have some effect
> somewhere. So where do you do that? Where do you permit a function
> with side effects?

> If you force *everything* to be in the return value, you lose any
> possibility of partial results - for instance, if it takes two weeks
> to render a ray-traced animation, you actually spend the entire two
> weeks building up a single, gigantic return value, which some outside
> system (which is presumably allowed to have side effects) then saves
> somewhere. In the meantime, you have absolutely no idea how far it's
> progressed - no information that it's completed frame 6 and is working
> on frame 7, nothing. Because telling the user anything is a side
> effect.

> And if my function f calls show_status_to_user() which has side
> effects, then f has side effects too, and you can no longer reason
> purely about f. The impurity that makes for practicality (hey, isn't
> there something in the Zen of Python about that?) pollutes upwards
> until all you'll have will be pockets of pure functional code that
> execute quickly enough to not need any intermediate output. That
> doesn't equate to "abolish print",

Is there some PEP filed called "Abolish print in python 4" ?
I dont remember filing any such...

Perhaps you should think of the relevance (rather than the
correctness) of your arguments Chris!  Are you arguing

1. With me?
2. With the OP?
3. With ACM/IEEE?

If 1 then yeah I know when to use prints and when not
If 2, are examples like ray-tracing animation remotely relevant (at this stage)?
If 3 Sure! Take it up with ACM&IEEE if you feel something in their
recommended curriculum is "valueless¹ and purposeless"



> that just means that you separate
> the guts from the UI - which is good advice for any system, no matter
> what its structure.

Yes thats the whole point -- computers do computing.
IO should be conceptualized separately.

--------------
¹ Strange choice of word considering that one principal agenda of functional
programming is to replace state-change thinking with value-oriented thinking

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

#77534

On Thu, Sep 4, 2014 at 2:11 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> Is there some PEP filed called "Abolish print in python 4" ?
> I dont remember filing any such...

You screamed "NO PRINT" at us in the voice of Edna Mode. (At least,
that's how I imagined it being said. YMMV.)

> Perhaps you should think of the relevance (rather than the
> correctness) of your arguments Chris!  Are you arguing
>
> 1. With me?
>
> If 1 then yeah I know when to use prints and when not

This. Then why are you advocating their non-use to new programmers?
Are you really saying print() is for experienced people only? Or, more
generally, that it should be possible for new programmers to do
absolutely all their coding at the REPL, never using any function with
side effects or mutating any state? (I was going to say "or using any
mutable objects", but since Python doesn't have tuple comprehensions,
you'd have to use lists. But if you never change what a list contains,
it comes to the same thing.)

Because that is what I'm arguing against. New programmers and
experienced programmers alike need their code to produce output, and
return values are just one form of that. Excluding all other forms is
unnecessary.

ChrisA

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

#77537

On Thursday, September 4, 2014 10:33:38 AM UTC+5:30, Chris Angelico wrote:
> On Thu, Sep 4, 2014 at 2:11 PM, Rustom Mody wrote:
> > Is there some PEP filed called "Abolish print in python 4" ?
> > I dont remember filing any such...

> You screamed "NO PRINT" at us in the voice of Edna Mode. (At least,
> that's how I imagined it being said. YMMV.)

> > Perhaps you should think of the relevance (rather than the
> > correctness) of your arguments Chris!  Are you arguing
> > 1. With me?
> > If 1 then yeah I know when to use prints and when not

> This. Then why are you advocating their non-use to new programmers?
> Are you really saying print() is for experienced people only? Or, more
> generally, that it should be possible for new programmers to do
> absolutely all their coding at the REPL, never using any function with
> side effects or mutating any state? (I was going to say "or using any
> mutable objects", but since Python doesn't have tuple comprehensions,
> you'd have to use lists. But if you never change what a list contains,
> it comes to the same thing.)

A patient goes to hospital. The first thing the nurses do (even before the
doctor arrives) is to stick all kinds of tubes into... eyes, nose, ears and
other unmentionable places.  The doctor arrives and orders a few more invasions.
Some of these are for helping eg a saline drip to a dehydrated patient, mostly
they are for 'debugging' the patient -- what things are there in the blood (etc)
that should not be or what is defcient that should be etc etc

Would you consider it acceptable that when the patient is declared cured,
he/she is sent home with these tubes hanging out?

Sure there are exceptions -- eg a patient needs a plaster/pacemaker etc.
As a rule he/she should be freed from all this.

You seem to think a print hanging out of a program to be ok, normal.
I consider it exceptional.

At the level of expertise of the OP -- this thread starts with
confusion about a for -- the foll. is totally irrelevant.  However
since you are bringing in heavy-duty examples like 'ray-tracing
animation' lets see a few examples:

1. Program is a gui -- There can be no meaningful prints, only
GUI-toolkit dialogs.
2. Program is a web-app -- It is painful and inefficient to generate
the html with prints. The correct approach is to use a templating engine
3. Program is a classic unix filter. If it is doing something entirely trivial
-- eg cat -- it matters little how its written.  If it is doing something significant
it is best structured into IO and computation separated
4. Programmer is a noob. You would start him on scripts.
I would start him in the REPL

> Because that is what I'm arguing against. New programmers and
> experienced programmers alike need their code to produce output, and
> return values are just one form of that. Excluding all other forms is
> unnecessary.

There is such a thing as law of primacy -- what is learnt first is remembered 
most. And there are many important things when learning programming/python.
One of them is debugging. print is excellent for that.

But there are more important things than that -- like structuring code and
using appropriate data structures. Putting print in the place of primacy
screws up that learning curve



> > Is there some PEP filed called "Abolish print in python 4" ?
> > I dont remember filing any such...

> You screamed "NO PRINT" at us in the voice of Edna Mode. (At least,
> that's how I imagined it being said. YMMV.) 

Dos and donts for adults and for children are different (at least in
my part of the world) ;-)

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

#77538

On Thu, Sep 4, 2014 at 4:23 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> A patient goes to hospital. The first thing the nurses do (even before the
> doctor arrives) is to stick all kinds of tubes into... eyes, nose, ears and
> other unmentionable places.  The doctor arrives and orders a few more invasions.
> Some of these are for helping eg a saline drip to a dehydrated patient, mostly
> they are for 'debugging' the patient -- what things are there in the blood (etc)
> that should not be or what is defcient that should be etc etc
>
> Would you consider it acceptable that when the patient is declared cured,
> he/she is sent home with these tubes hanging out?
>
> Sure there are exceptions -- eg a patient needs a plaster/pacemaker etc.
> As a rule he/she should be freed from all this.
>
> You seem to think a print hanging out of a program to be ok, normal.
> I consider it exceptional.

You keep saying that it's exceptional. You haven't really said why.
It's the simplest form of "program produces output for the human to
see", which all of your subsequent examples are more complicated
versions of:

> 1. Program is a gui -- There can be no meaningful prints, only
> GUI-toolkit dialogs.

(I actually disagree - several of my GUI programs have consoles for
debug output - but that's a separate point.) GUI toolkit dialogs are
inherently more complicated than simple print() calls, so they can be
learned later. "See, this is how you print to a console. Now, if you
do this, this, and this, you instead get a dialog."

> 2. Program is a web-app -- It is painful and inefficient to generate
> the html with prints. The correct approach is to use a templating engine

The templating engine is just another more complicated form of output.
Once again, learn the simple and fundamental first, and then add
complexity - starting with small levels of complexity like "You are
user %d of %d."%(user_num, concurrent_limit) and going up from there.

> 3. Program is a classic unix filter. If it is doing something entirely trivial
> -- eg cat -- it matters little how its written.  If it is doing something significant
> it is best structured into IO and computation separated

And how is the first of those going to be done? Somewhere, you need to
do I/O, and that's going to involve something very like print.

> 4. Programmer is a noob. You would start him on scripts.
> I would start him in the REPL

I would actually start on both. But if you're going to copy and paste
a bunch of stuff to python-list and say "here's what's going wrong,
can you help", it is MUCH easier if that's a script than an
interactive session that might have had almost anything preceding it.

> There is such a thing as law of primacy -- what is learnt first is remembered
> most. And there are many important things when learning programming/python.
> One of them is debugging. print is excellent for that.
>
> But there are more important things than that -- like structuring code and
> using appropriate data structures. Putting print in the place of primacy
> screws up that learning curve

Okay. Here's the thing I most want people to remember: Make the
program tell you stuff. Because that's more important as a debugging
help than *anything* in the world. No matter how beautiful your data
structure is, it's useless if you don't know how to get the program to
tell you about it.

You might like the idea of pure mathematical thinking, and that's fine
as a theory. If you want to teach programming on a blackboard, go
ahead, and use extremely functional style. Me, I've been tutoring
several Python students over the past few weeks, and I want to see
them get info back from the program. Using print() is perfect for
them, and it won't be a bad thing in the future. Maybe it's ugly and
messy and offends your theory-clean sensibilities, but it solves
real-world problems.

Practicality beats purity.
Especially when it actually solves real problems that people pay money
to get solved.

ChrisA

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

#77545

On Thursday, September 4, 2014 12:10:04 PM UTC+5:30, Chris Angelico wrote:

> Practicality beats purity.

Nice statement! Now where did I see it?? Let me see...
I see next to it some others:

- Beautiful is better than ugly.
- Explicit is better than implicit.
- Simple is better than complex.
- Complex is better than complicated.
 
- Readability counts.
  
- If the implementation is hard to explain, it's a bad idea.

How do each of these apply when comparing
a. A program that defaults to passing and returning data structures and
   uses print in a very controlled way

b. A program that randomly mixes call/return with input/print

??

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

#77547

On Thu, Sep 4, 2014 at 11:15 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> How do each of these apply when comparing
> a. A program that defaults to passing and returning data structures and
>    uses print in a very controlled way
>
> b. A program that randomly mixes call/return with input/print

Considering that I've never seen anything that *randomly* mixes them,
I can't really say. But you clearly don't dislike print nearly as much
as your earlier posts imply, because it can be used in a "controlled
way" as your potent comparison point. So how about you show me some
real example code, something real-world that you hate, and show me how
you'd rewrite it to not use print() calls "randomly mixed" with other
stuff, and then we can discuss. I think we'll find that our views
aren't as much different as it would seem; both of us believe in
separating guts from UI, both of us believe that side-effect-free
functions are easier to comprehend than those that unexpectedly change
state, and both of us want to make programs that can be read and
reasoned about. The only difference is that I see print as an
important tool as part of a balanced meal, and you see it as something
distasteful that you regrettably have to include. But we both use it.

ChrisA

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

#77548

Chris Angelico wrote:

> On Thu, Sep 4, 2014 at 4:23 PM, Rustom Mody <rustompmody@gmail.com> wrote:
>> You seem to think a print hanging out of a program to be ok, normal.
>> I consider it exceptional.
> 
> You keep saying that it's exceptional. You haven't really said why.
> It's the simplest form of "program produces output for the human to
> see", which all of your subsequent examples are more complicated
> versions of:

Out of the Python built-ins, how many functions (apart from print itself!)
print output instead of, or as well as, returning?

Out of the standard library, what percentage of functions and methods print
output instead of, or as well as, returning?

I haven't counted, but I'm guessing it will be well under 1%. There's a few
obvious examples: pprint.pprint, calendar.pr*, dis.dis, maybe a few more.
But I think they should be considered *exceptional*.

We often recommend using print as an easy and effective debugging tool. But
we don't (well, I don't) recommend leaving those print statements in the
code once the problem is debugged.


-- 
Steven

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web