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 3 of 3 — ← Prev page 1 2 [3]

#77550

On 04/09/2014 14:37, Steven D'Aprano wrote:
>
> 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.
>

I've given up completely with print for debugging.  I start with the 
logging module and change one line to effectively switch it off. 
Admittedly that's easy for me as I'm only writing code for my own use, 
I'm fairly sure that some of the bigger applications simply couldn't 
take the performance hit.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#77551

On Thu, Sep 4, 2014 at 11:37 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> 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*.

This is an unfair comparison, though. There's a vast difference
between library and application code. You also don't find library code
that changes the current directory, but on the flip side, *every* job
control system needs that facility. (With sysvinit, job control is
shell scripts. With upstart and systemd, there are directives to set
the working directory. Etcetera.) It's bad form for a library to
produce console output, because it doesn't own the console; but the
application does. The logger module will, by default, produce stderr
output, because it's assuming the application owns it. Otherwise, it's
generally up to the application to print stuff out.

So a fairer comparison is: How many applications produce non-debug
output on stderr or stdout? And that would be a much larger
percentage. Even GUI programs will, in some cases - for instance, try
firing up your favorite GUI text editor with no X server active, or
with invalid .Xauthority. You'll get some sort of error message - on
the console. Which means that somewhere in the GUI library, there's
fall-back code that produces console output. That's why I say it's the
most basic of all forms of that fundamental of programming, producing
output that a human can read. It's the simple one that you teach
first; everything else is built on that.

ChrisA

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

#77568

On Thursday, September 4, 2014 7:38:40 PM UTC+5:30, Chris Angelico wrote:

> So a fairer comparison is: How many applications produce non-debug
> output on stderr or stdout? And that would be a much larger
> percentage. Even GUI programs will, in some cases - for instance, try
> firing up your favorite GUI text editor with no X server active, or
> with invalid .Xauthority. You'll get some sort of error message - on
> the console. Which means that somewhere in the GUI library, there's
> fall-back code that produces console output. That's why I say it's the
> most basic of all forms of that fundamental of programming, producing
> output that a human can read. It's the simple one that you teach
> first; everything else is built on that.

Seeing the unix-centricity of this -- What's .Xauthority?? --
reminds me of this story/joke (apocryphal) that floats around the net.
----------------------------------------------------------------
Word Perfect helpline story: Customer support officer was sacked
because of the following conversation

Customer Support: Ridge Hall computer assistant; may I help you?
Caller: Yes, well, I'm having trouble with WordPerfect.
CS: What sort of trouble?
C: Well, I was just typing along, and all of a sudden the words went away.
CS: Went away?
C: They disappeared.
CS: Hmm. So what does your screen look like now?
C: Nothing.
CS: Nothing?
C: It's blank; it won't accept anything when I type.
CS: Are you still in WordPerfect, or did you get out?
C: How do I tell?
CS: Can you see the C: prompt on the screen?
C: What's a sea-prompt?
CS: Never mind. Can you move the cursor around on the screen?
C: There isn't any cursor, I told you, it won't accept anything I type.
CS: Does your monitor have a power indicator?
C: What's a monitor?
CS: It's the thing with the screen on it that looks like a TV. Does
it have a little light that tells you when it's on?
C: I don't know.
CS: Well, then look on the back of the monitor and find where the
power cord goes into it. Can you see that?
C: Yes, I think so.
CS: Great. Follow the cord to the plug, and tell me if it's plugged
into the wall.
C: .......Yes, it is.
CS: When you were behind the monitor, did you notice that there were
two cables plugged into the back of it, not just one?
C: No.
CS: Well, there are. I need you to look back there again and find the
other cable.
C: .......Okay, here it is.
CS: Follow it for me, and tell me if it's plugged securely into the
back of your computer.
C: I can't reach.
CS: Uh huh. Well, can you see if it is?
C: No.
CS: Even if you maybe put your knee on something and lean way over?
C: Oh, it's not because I don't have the right angle - it's because it's dark.
CS: Dark?
C: Yes - the office light is off, and the only light I have is coming
in from the window.
CS: Well, turn on the office light then.
C: I can't.
CS: No? Why not?
C: Because there's a power outage.
CS: A power... A power outage? Ah, Okay, we've got it licked now. Do
you still have the boxes and manuals and packing stuff your computer
came in?
C: Well, yes, I keep them in the closet.
CS: Good. Go get them, and unplug your system and pack it up just
like it was when you got it. Then take it back to the store you bought
it from.
C: Really? Is it that bad?
CS: Yes, I'm afraid it is.
C: Well, all right then, I suppose. What do I tell them?
CS: Tell them you're too stupid to own a computer.
--------------------------------------------------------------------

Yeah its funny... But it tells a serious story in the context of this thread.
We make a large number of assumptions which may seem obvious to some and not
to others -- "Machine is powered on" is of course an extreme.



One can think of more such. eg for running a python ..

1. We need a machine. What is "machine"? Washing machine? No computer!
   Will IBM 360 do? EDSAC?
   *&*(&^%$# I mean a reasonably modern computer!
   The most modern and widespread computing devices are smartphones. Will that do?
   
   Ok so lets assume that the not exactly trivial question "What is an
   appropriate machine for running python?" has been settled (And its
   powered on!)  Is that enough?
2. I am playing around with the "rm" command. So I rm /lib/x86_64-linux-gnu/libc.so.6
   <choose your response>
3. Ok so I have a 'running' system. And its asking me for something
   called a login and password
   etc ...
4. Running system. Python script not running. Is python installed?

All of which is to say that for meaningfully discussing python we make
a fairly large number of assumptions.

You assume that this thing called bash/cmd is a given.

What is bash? An OS-level REPL.
[Linux-kernel programmers cant assume such]

If we can assume all the above, how much extra is it to
assume one more level of REPL called 'python'?

And what are the pedagogic advantages to this assumption?

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

#77569

On Fri, Sep 5, 2014 at 12:24 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Thursday, September 4, 2014 7:38:40 PM UTC+5:30, Chris Angelico wrote:
>
>> So a fairer comparison is: How many applications produce non-debug
>> output on stderr or stdout? And that would be a much larger
>> percentage. Even GUI programs will, in some cases - for instance, try
>> firing up your favorite GUI text editor with no X server active, or
>> with invalid .Xauthority. You'll get some sort of error message - on
>> the console. Which means that somewhere in the GUI library, there's
>> fall-back code that produces console output. That's why I say it's the
>> most basic of all forms of that fundamental of programming, producing
>> output that a human can read. It's the simple one that you teach
>> first; everything else is built on that.
>
> Seeing the unix-centricity of this -- What's .Xauthority?? --

That's one particular example that's from Unix. I've seen (and
written) Windows GUI programs that use consoles, too. And OS/2 ones.
Can't speak for Mac OS Classic as I've never used it, but I'd be
surprised if it's not possible.

So I still stand by my statement that console output is a fundamental,
and it's not a bad thing to teach it.

ChrisA

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

#77570

In article <mailman.13780.1409884245.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Fri, Sep 5, 2014 at 12:24 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> > On Thursday, September 4, 2014 7:38:40 PM UTC+5:30, Chris Angelico wrote:
> >
> >> So a fairer comparison is: How many applications produce non-debug
> >> output on stderr or stdout? And that would be a much larger
> >> percentage. Even GUI programs will, in some cases - for instance, try
> >> firing up your favorite GUI text editor with no X server active, or
> >> with invalid .Xauthority. You'll get some sort of error message - on
> >> the console. Which means that somewhere in the GUI library, there's
> >> fall-back code that produces console output. That's why I say it's the
> >> most basic of all forms of that fundamental of programming, producing
> >> output that a human can read. It's the simple one that you teach
> >> first; everything else is built on that.
> >
> > Seeing the unix-centricity of this -- What's .Xauthority?? --
> 
> That's one particular example that's from Unix. I've seen (and
> written) Windows GUI programs that use consoles, too. And OS/2 ones.
> Can't speak for Mac OS Classic as I've never used it, but I'd be
> surprised if it's not possible.
> 
> So I still stand by my statement that console output is a fundamental,
> and it's not a bad thing to teach it.
> 
> ChrisA

      write(6, 11)
11    format(21H.XAUTHORITY NOT FOUND)

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

#77572

On Friday, September 5, 2014 8:01:00 AM UTC+5:30, Chris Angelico wrote:

> That's one particular example that's from Unix. I've seen (and
> written) Windows GUI programs that use consoles, too. And OS/2 ones.
> Can't speak for Mac OS Classic as I've never used it, but I'd be
> surprised if it's not possible.

> So I still stand by my statement that console output is a fundamental,
> and it's not a bad thing to teach it.

If what is fundamental is what should be taught (first) then we should
start with machine language because everything bottoms out into
that. Yes?

The most logical order and the optimal pedagogical order are not
usually the same and they may both differ from the factual historical
order.

In here Ive laid out the history of CS as it unfolded
blog.languager.org/2011/02/cs-education-is-fat-and-weak-1.html

And the consequent pedagogical confusions and logical inconsistencies
of choosing not to 'reconfigure' our history:
blog.languager.org/2011/02/cs-education-is-fat-and-weak-2.html

Including this that my teacher's teacher of programming was taught
assembly as the first programming language because it was easy and
Fortran (II??) only later because it was advanced and difficult.
This was right in 1960. Its wrong today.

Likewise here. In C we have no choice but to produce standalone
executables.  Imposing the same impoverishment onto a beginner by
teaching script-writing before the REPL is a miserable choice.

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

#77574

On Fri, Sep 5, 2014 at 12:56 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Friday, September 5, 2014 8:01:00 AM UTC+5:30, Chris Angelico wrote:
>
>> That's one particular example that's from Unix. I've seen (and
>> written) Windows GUI programs that use consoles, too. And OS/2 ones.
>> Can't speak for Mac OS Classic as I've never used it, but I'd be
>> surprised if it's not possible.
>
>> So I still stand by my statement that console output is a fundamental,
>> and it's not a bad thing to teach it.
>
> If what is fundamental is what should be taught (first) then we should
> start with machine language because everything bottoms out into
> that. Yes?

No, that's not what fundamental means. And if you try to say "teach
the lowest abstraction first", then you have to teach electrical
engineering... oh wait, that's just an abstraction over physics...
which is an abstraction over mathematics... which gets us right back
to the top of the stack.

The fundamental is the thing that's most basic in *usage*, not
implementation. Console output on a modern GUI system ends up becoming
GUI display, so if you go by the "most concrete wins" then you should
start by teaching a GUI. But the console has been implemented for you,
and in usage, it's the simplest and most basic form of output
available. It's also the most cross-platform - there's no form of
output more available than stdout.

> Likewise here. In C we have no choice but to produce standalone
> executables.

Technically wrong, I've seen interactive C interpreters :) Language
doesn't mandate usage structure.

> Imposing the same impoverishment onto a beginner by
> teaching script-writing before the REPL is a miserable choice.

Personally, I'd teach both very early. Whether you teach scripts first
or REPL first doesn't make much difference - just teach both. I'm not
sure what this has to do with print, though, nor how you propose to
make useful programs without side effects.

ChrisA

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

#77529

On 09/03/2014 08:22 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
>
>> 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

Lots of Python functions have side effects.

> | -- Variables are immutable, preventing unexpected changes to program data by other code

Lots of Python core data types are mutable.

> | -- Data can be freely aliased or copied without introducing unintended effects from mutation

Every mutable Python data type that is aliased can be affected by unintended mutational effects -- as well as 
intentional ones.

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

Ridiculous argument after ridiculous argument.  Please do not waste our time with nonsense.

--
~Ethan~

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

#77532

On Thursday, September 4, 2014 9:37:05 AM UTC+5:30, Ethan Furman wrote:
> Ridiculous argument after ridiculous argument.  Please do not waste our time with nonsense.

See my answer (3.) to Chris above.

[toc] | [prev] | [standalone]

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

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

csiph-web