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

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

buggy python interpretter or am I missing something here?

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

Contents

  buggy python interpretter or am I missing something here? me <noone@all.net> - 2014-01-27 03:42 +0000
    buggy python interpretter or am I missing something here? - "TCdaemon.py"  yEnc me <noone@all.net> - 2014-01-27 03:42 +0000
    Re: buggy python interpretter or am I missing something here? Gary Herron <gary.herron@islandtraining.com> - 2014-01-26 21:04 -0800
      Re: buggy python interpretter or am I missing something here? me <noone@all.net> - 2014-01-27 06:17 +0000
        Re: buggy python interpretter or am I missing something here? Gary Herron <gary.herron@islandtraining.com> - 2014-01-26 23:03 -0800
          Re: buggy python interpretter or am I missing something here? me <noone@all.net> - 2014-01-27 07:20 +0000
    Re:buggy python interpretter or am I missing something here? Dave Angel <davea@davea.name> - 2014-01-27 00:36 -0500
      Re:buggy python interpretter or am I missing something here? me <noone@all.net> - 2014-01-27 06:02 +0000
        Re: buggy python interpretter or am I missing something here? Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-01-27 00:47 -0600
          Re: buggy python interpretter or am I missing something here? me <noone@all.net> - 2014-01-27 07:17 +0000
            Re: buggy python interpretter or am I missing something here? Alister <alister.ware@ntlworld.com> - 2014-01-27 12:19 +0000
            Re: buggy python interpretter or am I missing something here? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-27 13:48 +0000
            Re: buggy python interpretter or am I missing something here? Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-01-27 10:23 -0600
              Re: buggy python interpretter or am I missing something here? Dan Sommers <dan@tombstonezero.net> - 2014-01-27 16:38 +0000
            Re: buggy python interpretter or am I missing something here? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-27 16:45 +0000
    Re: buggy python interpretter or am I missing something here? Terry Reedy <tjreedy@udel.edu> - 2014-01-27 01:21 -0500
      Re: buggy python interpretter or am I missing something here? me <noone@all.net> - 2014-01-27 06:42 +0000
        Re: buggy python interpretter or am I missing something here? Ethan Furman <ethan@stoneleaf.us> - 2014-01-26 23:08 -0800
    Re: buggy python interpretter or am I missing something here? me <noone@all.net> - 2014-01-27 06:46 +0000
      Re: buggy python interpretter or am I missing something here? Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-01-27 00:55 -0600
      Re: buggy python interpretter or am I missing something here? Gary Herron <gary.herron@islandtraining.com> - 2014-01-26 23:12 -0800
        Re: buggy python interpretter or am I missing something here? me <noone@all.net> - 2014-01-27 07:30 +0000
          Re: buggy python interpretter or am I missing something here? Peter Otten <__peter__@web.de> - 2014-01-27 09:45 +0100
      Re: buggy python interpretter or am I missing something here? Ethan Furman <ethan@stoneleaf.us> - 2014-01-26 23:17 -0800
        Re: buggy python interpretter or am I missing something here? me <noone@all.net> - 2014-01-27 07:44 +0000
          Re: buggy python interpretter or am I missing something here? Chris Angelico <rosuav@gmail.com> - 2014-01-27 20:01 +1100
            Re: buggy python interpretter or am I missing something here? me <noone@all.net> - 2014-01-27 09:32 +0000
              Re: buggy python interpretter or am I missing something here? Neil Cerutti <neilc@norwich.edu> - 2014-01-27 12:56 +0000
              Re: buggy python interpretter or am I missing something here? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-27 13:56 +0000
              Re: buggy python interpretter or am I missing something here? Rick Johnson <rantingrickjohnson@gmail.com> - 2014-01-27 07:33 -0800
                Re: buggy python interpretter or am I missing something here? Chris Angelico <rosuav@gmail.com> - 2014-01-28 02:53 +1100
                  Re: buggy python interpretter or am I missing something here? Rick Johnson <rantingrickjohnson@gmail.com> - 2014-01-27 12:22 -0800
                    Re: buggy python interpretter or am I missing something here? Chris Angelico <rosuav@gmail.com> - 2014-01-28 07:29 +1100
                    Re: buggy python interpretter or am I missing something here? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-27 22:25 +0000
                      Re: buggy python interpretter or am I missing something here? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-01-30 18:13 +1300
                        Re: buggy python interpretter or am I missing something here? Terry Reedy <tjreedy@udel.edu> - 2014-01-30 04:44 -0500
                        Re: buggy python interpretter or am I missing something here? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-31 04:06 +0000
                          Re: buggy python interpretter or am I missing something here? Kushal Kumaran <kushal.kumaran@gmail.com> - 2014-01-31 10:37 +0530
                          Re: buggy python interpretter or am I missing something here? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-01-31 19:59 +1300
                Re: buggy python interpretter or am I missing something here? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-27 16:22 +0000
              Re: buggy python interpretter or am I missing something here? Michael Torrie <torriem@gmail.com> - 2014-01-27 10:52 -0700

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

#64839

On 01/26/2014 10:46 PM, me wrote:
> In any case, thanks for the answers guys.  I'm satisfied that the except:
> syntax yields undefined behavior, and in my mind it shouldn't be
> syntactically allowed then.
>
> Updating to Exception,e or Exception as e fixes the problem.
>

That's an irksome habit you have there,  this jumping to (incorrect) 
conclusions so quickly.   We'd like to get to the bottom of this. (And 
correct your mis-interpretations while we're at it :-)    But we need to 
see your test *and* the results.

Gary Herron

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

#64842

On Sun, 26 Jan 2014 23:12:18 -0800, Gary Herron wrote:

> On 01/26/2014 10:46 PM, me wrote:
>> In any case, thanks for the answers guys.  I'm satisfied that the
>> except:
>> syntax yields undefined behavior, and in my mind it shouldn't be
>> syntactically allowed then.
>>
>> Updating to Exception,e or Exception as e fixes the problem.
>>
>>
> That's an irksome habit you have there,  this jumping to (incorrect)
> conclusions so quickly.   We'd like to get to the bottom of this. (And
> correct your mis-interpretations while we're at it :-)    But we need to
> see your test *and* the results.
> 
> Gary Herron


Problem solved.  I understand what was happening now with the "raise" 
following the bare except:

Since this code is for a personal research project I'm not as concerned 
about code quality as I would be if I was getting paid to write 
production code...and if it was production code I'd only prototype a 
proof-of-concept in python and then rewrite in c++.

The project is to take advantage of all 16 CPU cores to process A LOT of 
GPS data for a 3d map-making and visualization project.  Now my 
bottleneck may end up being the python global lock when doing concurrent 
processing...but we'll see.

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

#64850

me wrote:

Not me, you ;)

> Since this code is for a personal research project I'm not as concerned
> about code quality as I would be if I was getting paid to write
> production code...and if it was production code I'd only prototype a
> proof-of-concept in python and then rewrite in c++.

Another way to improve code quality is to write less code yourself and 
instead to rely on well-tested libraries:

import argparse

parser = argparse.ArgumentParser()
parser.add_argument("-d", "--basedir", default="/process")
parser.add_argument("-i", "--inpipe", default="/tmp/TCdaemonIN")
parser.add_argument("-#", "--maxjobs", type=int, default=8)
parser.add_argument("-o", "--outpipe", default="/tmp/TCdaemonOUT")

print parser.parse_args()

Seriously, code quality doesn't magically improve by a switch of language. 
You may make fewer newbie errors in C++, but once you get over the 
instinctive

"Ducktype and unit tests? I'll do it with these three undebuggable templates 
and get type checks for free from the compiler."

the simpler and often more concise Python solutions will start to pay off.

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

#64845

On 01/26/2014 10:46 PM, me wrote:
>
> [...]  I'm satisfied that the except: syntax yields
> undefined behavior, and in my mind it shouldn't be
>  syntactically allowed then.

Two points:

   1) Python is not C++

   2) You asked for help; you received it.  Coming back
      with an attitude of "Python must be broken, I'll
      work around it" is going to quickly lose you the
      support of those willing to help again.

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

#64846

On Sun, 26 Jan 2014 23:17:29 -0800, Ethan Furman wrote:

> On 01/26/2014 10:46 PM, me wrote:
>>
>> [...]  I'm satisfied that the except: syntax yields undefined behavior,
>> and in my mind it shouldn't be
>>  syntactically allowed then.
> 
> Two points:
> 
>    1) Python is not C++
> 
>    2) You asked for help; you received it.  Coming back
>       with an attitude of "Python must be broken, I'll work around it"
>       is going to quickly lose you the support of those willing to help
>       again.


Whatever...lighten up dude!

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

#64852

On Mon, Jan 27, 2014 at 6:44 PM, me <noone@all.net> wrote:
> On Sun, 26 Jan 2014 23:17:29 -0800, Ethan Furman wrote:
>
>> On 01/26/2014 10:46 PM, me wrote:
>>>
>>> [...]  I'm satisfied that the except: syntax yields undefined behavior,
>>> and in my mind it shouldn't be
>>>  syntactically allowed then.
>>
>> Two points:
>>
>>    1) Python is not C++
>>
>>    2) You asked for help; you received it.  Coming back
>>       with an attitude of "Python must be broken, I'll work around it"
>>       is going to quickly lose you the support of those willing to help
>>       again.
>
>
> Whatever...lighten up dude!

When you use a language, you should be working with it, not fighting
against it. It doesn't do to complain that REXX ought to have IEEE
floating-point semantics, or that 8086 assembly language really would
benefit from a native hashtable type. Python works a certain way, and
part of that is its use of exceptions - which are integral to the
language, rather than being (as in C++) somewhat tacked-on. Assuming
that anything that isn't the way you expect it is inherently broken,
and saying so on a mailing list, is a good way to alienate those who
are offering you help for no reimbursement... and "lighten up dude"
doesn't help.

ChrisA

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

#64853

On Mon, 27 Jan 2014 20:01:33 +1100, Chris Angelico wrote:

> On Mon, Jan 27, 2014 at 6:44 PM, me <noone@all.net> wrote:
>> On Sun, 26 Jan 2014 23:17:29 -0800, Ethan Furman wrote:
>>
>>> On 01/26/2014 10:46 PM, me wrote:
>>>>
>>>> [...]  I'm satisfied that the except: syntax yields undefined
>>>> behavior,
>>>> and in my mind it shouldn't be
>>>>  syntactically allowed then.
>>>
>>> Two points:
>>>
>>>    1) Python is not C++
>>>
>>>    2) You asked for help; you received it.  Coming back
>>>       with an attitude of "Python must be broken, I'll work around it"
>>>       is going to quickly lose you the support of those willing to
>>>       help again.
>>
>>
>> Whatever...lighten up dude!
> 
> When you use a language, you should be working with it, not fighting
> against it. It doesn't do to complain that REXX ought to have IEEE
> floating-point semantics, or that 8086 assembly language really would
> benefit from a native hashtable type. Python works a certain way, and
> part of that is its use of exceptions - which are integral to the
> language, rather than being (as in C++) somewhat tacked-on. Assuming
> that anything that isn't the way you expect it is inherently broken, and
> saying so on a mailing list, is a good way to alienate those who are
> offering you help for no reimbursement... and "lighten up dude" doesn't
> help.
> 
> ChrisA

You feel better now that you too have vented?  I had a productive 
discussion with a couple of top level posters who helped me solve my 
problem and they receive appropriate kuddos.  Now it seems that some 
lonely individuals who maybe just want some attention are coming out of 
the woodwork.

The thread is done so lets give it a rest.  The condescending attitude 
about proper USENET tech help is just as annoying as perhaps my 
"opinions" seem.  If someone is so sensitive as to not be able to discuss 
a technical matter without making it personal or seeing it as an attack 
against their religion then I neither want nor need their input.  There 
are plenty of technical resources in the world that don't require idol 
worship.

Regards

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

#64856

On 2014-01-27, me <noone@all.net> wrote:
> The thread is done so lets give it a rest.  The condescending
> attitude about proper USENET tech help is just as annoying as
> perhaps my "opinions" seem.  If someone is so sensitive as to
> not be able to discuss a technical matter without making it
> personal or seeing it as an attack against their religion then
> I neither want nor need their input.  There are plenty of
> technical resources in the world that don't require idol
> worship.

Oh, it's all right. I'm sure that we can handle this situation
maturely, just like the responsible adults that we are. Isn't
that right, Mr... Poopy-Pants?

-- 
Neil Cerutti

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

#64862

On Mon, 27 Jan 2014 09:32:43 +0000, some guy who calls himself "me" wrote:

> On Mon, 27 Jan 2014 20:01:33 +1100, Chris Angelico wrote:
> 
>> On Mon, Jan 27, 2014 at 6:44 PM, me <noone@all.net> wrote:
>>> On Sun, 26 Jan 2014 23:17:29 -0800, Ethan Furman wrote:
>>>
>>>> On 01/26/2014 10:46 PM, me wrote:
>>>>>
>>>>> [...]  I'm satisfied that the except: syntax yields undefined
>>>>> behavior,
>>>>> and in my mind it shouldn't be
>>>>>  syntactically allowed then.
>>>>
>>>> Two points:
>>>>
>>>>    1) Python is not C++
>>>>
>>>>    2) You asked for help; you received it.  Coming back
>>>>       with an attitude of "Python must be broken, I'll work around
>>>>       it" is going to quickly lose you the support of those willing
>>>>       to help again.
>>>
>>>
>>> Whatever...lighten up dude!
>> 
>> When you use a language, you should be working with it, not fighting
>> against it. It doesn't do to complain that REXX ought to have IEEE
>> floating-point semantics, or that 8086 assembly language really would
>> benefit from a native hashtable type. Python works a certain way, and
>> part of that is its use of exceptions - which are integral to the
>> language, rather than being (as in C++) somewhat tacked-on. Assuming
>> that anything that isn't the way you expect it is inherently broken,
>> and saying so on a mailing list, is a good way to alienate those who
>> are offering you help for no reimbursement... and "lighten up dude"
>> doesn't help.
>> 
>> ChrisA
> 
> You feel better now that you too have vented?  I had a productive
> discussion with a couple of top level posters who helped me solve my
> problem and they receive appropriate kuddos.  Now it seems that some
> lonely individuals who maybe just want some attention are coming out of
> the woodwork.

A word to the wise: Chris is one of the most frequent and helpful posters 
here. So is Ethan. Both of them know what they're talking about, so when 
they give you advice, you could do a lot worse than to listen.

Some examples of "a lot worse": you could arrogantly dismiss them by 
saying "whatever". Or you could make assumptions about their personal 
lives ("lonely individuals"). 

[Aside: you seem to be making a habit of jumping to wrong conclusions 
based on incorrect and illogical interpretations of minimal evidence. 
That's a poor habit to get into, and especially poor for a programmer.]


> The thread is done so lets give it a rest.  The condescending attitude
> about proper USENET tech help is just as annoying as perhaps my
> "opinions" seem.  If someone is so sensitive as to not be able to
> discuss a technical matter without making it personal or seeing it as an
> attack against their religion then I neither want nor need their input. 
> There are plenty of technical resources in the world that don't require
> idol worship.

What does idol worship have to do with anything? Oh wait, do you think 
Ethan and Chris are pissed off because you're not genuflecting at 
Python's awesomeness? That's another comically wrong conclusion.


-- 
Steven

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

#64871

On Monday, January 27, 2014 3:32:43 AM UTC-6, me wrote:
> On Mon, 27 Jan 2014 20:01:33 +1100, Chris Angelico wrote:
> 
> [snip chris reply]
> 
> You feel better now that you too have vented?  I had a
> productive discussion with a couple of top level posters
> who helped me solve my problem and they receive
> appropriate kuddos.  Now it seems that some lonely
> individuals who maybe just want some attention are coming
> out of the woodwork.

You can kindly ignore Chris, he is just one of our well
known *resident* "lonely individuals", seeking attention yet
again! And his constant blabbing about and idol worship of REXX is
more annoying than all of xah lee post combined, however, i
do just enjoy watching him "casually" weaving in those
examples as though he does not have an agenda to push.

@Chris: Two can play at this game!

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

#64874

On Tue, Jan 28, 2014 at 2:33 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> You can kindly ignore Chris, he is just one of our well
> known *resident* "lonely individuals", seeking attention yet
> again! And his constant blabbing about and idol worship of REXX is
> more annoying than all of xah lee post combined, however, i
> do just enjoy watching him "casually" weaving in those
> examples as though he does not have an agenda to push.
>
> @Chris: Two can play at this game!

Heh. If you'd said Pike instead of REXX, I might have believed you :)
I've said more about Pike than is perhaps appropriate, but of late,
I've actually not been the one to most often quote REXX code.
Actually, REXX as a language has been majorly left behind. Back in the
early 1990s it was blessed with support for non-English text in the
form of DBCS (at least, the OS/2 REXX implementation was - don't know
how standard that was), but then nobody ever went in and made it all
Unicode instead, so now we have a bytes-only language. Has its
coolnesses, but far too much of it is done with language magic (eg the
PARSE statement - there's no way to interact with that, no way to make
anything dynamic, so even though it is, in many ways, much cleaner
than C's sscanf or Perl's regular expressions, it's just plain
impossible to extend). Still, it was my first taste of
arbitrary-precision arithmetic, and for that (and plenty more) I am
well appreciative.

Frankly, I don't "idol worship" *any* language. There is not a single
language that I've ever used which has no flaws. And I can't think of
any language with which I have no fundamental disagreements on major
design points. (Note that there's a difference between those two.
Flaws are objective (and I'm not talking about bugs, I'm talking about
stuff where the author agrees that it's wrong but it's too late to
change now), design disagreements are personal. For instance, I
personally believe that disallowing assignment-as-expression cuts out
more value than it gains by preventing bugs (as we've seen lately,
people can just get it wrong the other way, comparing as a statement),
but I respect Guido's decision on that and don't see it as a problem
to be fought. A lot of Python's worst flaws were fixed in 3.x (input()
-> eval(), print as a statement, etc), but there are still a few
oddities that can't easily be fixed. They don't stop the language from
being useful and awesome.

ChrisA

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

#64884

On Monday, January 27, 2014 9:53:37 AM UTC-6, Chris Angelico wrote:
> Heh. If you'd said Pike instead of REXX, I might have
> believed you :) I've said more about Pike than is perhaps
> appropriate, but of late, I've actually not been the one
> to most often quote REXX code.

Yes in my haste to inject a jab at you i pulled the
trigger before fully retracting the gun from my holster...
OUCH!

It was indeed "Pike" that i meant. But, although you
*do* mention it quite a lot, i don't think mentioning any
language should be off topic because heck, someone could
learn something new.

> [snip]
> For instance, I personally believe that disallowing
> assignment-as-expression cuts out more value than it gains
> by preventing bugs (as we've seen lately, people can just
> get it wrong the other way, comparing as a statement),

I myself wish for such a Python feature -- but alas, we are but
slaves to whims of the dutch!

> but I respect Guido's decision on that and don't see it as
> a problem to be fought. A lot of Python's worst flaws were
> fixed in 3.x (input() -> eval(), print as a statement,
> etc),

I agree that those are flaws, but not enough of a flaw to
break code. "input" is only used by neophytes, so who cares
about breaking that one, but "print" is almost everywhere!

But let's go back to "input" for a bit...

Why do we even need an "input" function anyway if all
it is going to do is read from stdin? Would not $stdin.read
have been better choice? Or simply "read" if you're a global
namespace pollution fanboy!

Heck, if you're going to have a function for writing
strings to $stdout, and also, you're going to have a
function for reading strings from $stdin, then you need to
recognize the diametric relation between these functions,
and as such, your first design consideration should be to
maintain a consistency between them

    input (reads a string from stdin)
    print (writes a string to stdout)

It is my strong believe that defining an "input" method that
"magically" evals the input string is just plain evil. Why
you ask? Because doing so injects superfluous magic whist
simultaneously blinding the noob to the fact that strings
are the mutually inclusive love interest of both "Mrs.Input"
and "Mr.Output".

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

#64885

On Tue, Jan 28, 2014 at 7:22 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> maintain a consistency between them
>
>     input (reads a string from stdin)
>     print (writes a string to stdout)
>
> It is my strong believe that defining an "input" method that
> "magically" evals the input string is just plain evil.

Fortunately, as of Python 3, that parallel is maintained.

ChrisA

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

#64886

On Mon, 27 Jan 2014 12:22:22 -0800, Rick Johnson wrote:

> "input" is only used by neophytes, so who cares about breaking that one,
> but "print" is almost everywhere!

Heh heh heh, how very "Ranting Rick" to think that a function for 
listening to input is unimportant, while a function for spraying output 
all over the place is vital.


> But let's go back to "input" for a bit...
> 
> Why do we even need an "input" function anyway if all it is going to do
> is read from stdin? 

That's not all it does.

For example, it handles backspacing, so that typing H E L O O BACKSPACE 
BACKSPACE L O gives "HELLO" rather than "HELOO\x7f\x7fO".

Of course, somebody as awesome as Rick will have never made a mistake in 
his life, but for the rest of us mere mortals, that feature alone makes a 
dedicated input function worthwhile. But there's more!

On systems with readline, not only does input handle backspacing, but it 
handles all sorts of editing functionality, such as arrow keys and 
various editing commands. So typing A LEFT-ARROW B gives "BA" rather than 
"A\x1b[DB". input also provides visual feedback while you type, an 
optional prompt, handling of newlines, buffering, and possibly more.


-- 
Steven

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

#64965

Steven D'Aprano wrote:
> On Mon, 27 Jan 2014 12:22:22 -0800, Rick Johnson wrote:
> 
>>Why do we even need an "input" function anyway if all it is going to do
>>is read from stdin? 
> 
> That's not all it does.
> 
> For example, it handles backspacing, so that typing H E L O O BACKSPACE 
> BACKSPACE L O gives "HELLO" rather than "HELOO\x7f\x7fO".

No, it doesn't -- that's handled at a lower level.
Any other method of reading from stdin, as long
as it hasn't been redirected away from the console,
has the same behaviour.

I typed some backspaces in the input to each of the
following experiments, and they didn't end up in the
data:

 >>> import sys
 >>> x = sys.stdin.readline()
HELLO
 >>> x
'HELLO\n'
 >>> import os
 >>> f = os.fdopen(0)
 >>> y = f.readline()
adsxx
 >>> y
'adsxx\n'

So input() really is a pure convenience function.
(That doesn't mean it's not worth having, though!)

-- 
Greg

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

#64974

On 1/30/2014 12:13 AM, Gregory Ewing wrote:
> Steven D'Aprano wrote:
>> On Mon, 27 Jan 2014 12:22:22 -0800, Rick Johnson wrote:
>>
>>> Why do we even need an "input" function anyway if all it is going to do
>>> is read from stdin?
>>
>> That's not all it does.

What else it does is print a prompt before reading and to strip off the 
trailing newline.

>> For example, it handles backspacing, so that typing H E L O O
>> BACKSPACE BACKSPACE L O gives "HELLO" rather than "HELOO\x7f\x7fO".
>
> No, it doesn't -- that's handled at a lower level.
> Any other method of reading from stdin, as long
> as it hasn't been redirected away from the console,
> has the same behaviour.
>
> I typed some backspaces in the input to each of the
> following experiments, and they didn't end up in the
> data:
>
>  >>> import sys
>  >>> x = sys.stdin.readline()
> HELLO
>  >>> x
> 'HELLO\n'
>  >>> import os
>  >>> f = os.fdopen(0)
>  >>> y = f.readline()
> adsxx
>  >>> y
> 'adsxx\n'
>
> So input() really is a pure convenience function.
> (That doesn't mean it's not worth having, though!)

It is equivalent to

def input(prompt):
   sys.stdout.write(prompt)
   return sys.stdin.read(<one line>)[:-1]

There was once an eval around the return, but that was determined to be 
a bad idea.

-- 
Terry Jan Reedy

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

#65085

On Thu, 30 Jan 2014 18:13:54 +1300, Gregory Ewing wrote:

> Steven D'Aprano wrote:
>> On Mon, 27 Jan 2014 12:22:22 -0800, Rick Johnson wrote:
>> 
>>>Why do we even need an "input" function anyway if all it is going to do
>>>is read from stdin?
>> 
>> That's not all it does.
>> 
>> For example, it handles backspacing, so that typing H E L O O BACKSPACE
>> BACKSPACE L O gives "HELLO" rather than "HELOO\x7f\x7fO".
> 
> No, it doesn't -- that's handled at a lower level. Any other method of
> reading from stdin, as long as it hasn't been redirected away from the
> console, has the same behaviour.
> 
> I typed some backspaces in the input to each of the following
> experiments, and they didn't end up in the data:
> 
>  >>> import sys
>  >>> x = sys.stdin.readline()
> HELLO
>  >>> x
> 'HELLO\n'
>  >>> import os
>  >>> f = os.fdopen(0)
>  >>> y = f.readline()
> adsxx
>  >>> y
> 'adsxx\n'


Very interesting. I admit I don't actually understand the way stdin 
works. Can you explain what's going on here then?

import sys, os
import tty, termios, fcntl

def getch():
    """Get a single character from standard input.

    Does not echo to the screen. This will block waiting for a keypress.
    """
    fd = sys.stdin.fileno()
    old_settings = termios.tcgetattr(fd)
    try:
        tty.setraw(fd)
        ch = sys.stdin.read(1)
    finally:
        termios.tcsetattr(fd, termios.TCSADRAIN, old_settings)
    return ch


And in use:

>>> [getch() for i in range(14)]
['H', 'e', 'l', 'l', 'l', '\x7f', 'o', ' ', 'W', 'o', 'r', 'l', 'd', '!']


where I type "Helll BACKSPACE o SPACE World!"


At what point do the arrow keys and other readline or readline-like 
features get handled?



-- 
Steven

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

#65091

[Multipart message — attachments visible in raw view] — view raw

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> On Thu, 30 Jan 2014 18:13:54 +1300, Gregory Ewing wrote:
>
>> Steven D'Aprano wrote:
>>> On Mon, 27 Jan 2014 12:22:22 -0800, Rick Johnson wrote:
>>> 
>>>>Why do we even need an "input" function anyway if all it is going to do
>>>>is read from stdin?
>>> 
>>> That's not all it does.
>>> 
>>> For example, it handles backspacing, so that typing H E L O O BACKSPACE
>>> BACKSPACE L O gives "HELLO" rather than "HELOO\x7f\x7fO".
>> 
>> No, it doesn't -- that's handled at a lower level. Any other method of
>> reading from stdin, as long as it hasn't been redirected away from the
>> console, has the same behaviour.
>> 
>> I typed some backspaces in the input to each of the following
>> experiments, and they didn't end up in the data:
>> 
>>  >>> import sys
>>  >>> x = sys.stdin.readline()
>> HELLO
>>  >>> x
>> 'HELLO\n'
>>  >>> import os
>>  >>> f = os.fdopen(0)
>>  >>> y = f.readline()
>> adsxx
>>  >>> y
>> 'adsxx\n'
>
>
> Very interesting. I admit I don't actually understand the way stdin 
> works. Can you explain what's going on here then?
>
> import sys, os
> import tty, termios, fcntl
>
> def getch():
>     """Get a single character from standard input.
>
>     Does not echo to the screen. This will block waiting for a keypress.
>     """
>     fd = sys.stdin.fileno()
>     old_settings = termios.tcgetattr(fd)
>     try:
>         tty.setraw(fd)
>         ch = sys.stdin.read(1)
>     finally:
>         termios.tcsetattr(fd, termios.TCSADRAIN, old_settings)
>     return ch
>
>
> And in use:
>
>>>> [getch() for i in range(14)]
> ['H', 'e', 'l', 'l', 'l', '\x7f', 'o', ' ', 'W', 'o', 'r', 'l', 'd', '!']
>
>
> where I type "Helll BACKSPACE o SPACE World!"
>
>
> At what point do the arrow keys and other readline or readline-like 
> features get handled?
>

They can be handled by the in-kernel tty driver, when you're using a tty
set in "cooked" mode.  This driver can be configured by the termios
functions, which invoke various ioctls on the terminal devices.  Or you
can set the tty to "raw" mode, and the keystrokes are passed on to the
application, which can do all sorts of interpretation (for example if
you're using the readline library, or a curses app).

W. Richard Stevens covers this in much detail in APUE, but you can
preserve your sanity by being ignorant of the details of tty handling.

-- 
regards,
kushal

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

#65102

Steven D'Aprano wrote:
> Can you explain what's going on here then?
> 
> import sys, os
> import tty, termios, fcntl
> 
> def getch():
>     """Get a single character from standard input.
> 
>     Does not echo to the screen. This will block waiting for a keypress.
>     """
>     fd = sys.stdin.fileno()
>     old_settings = termios.tcgetattr(fd)
>     try:
>         tty.setraw(fd)
>         ch = sys.stdin.read(1)
>     finally:
>         termios.tcsetattr(fd, termios.TCSADRAIN, old_settings)
>     return ch

In Unix, normally line editing of terminal input is done
by the tty device driver in the kernel. (In the old days
it would have been talking to a real device connected by
a serial line; nowadays it's more likely to be a "pseudo
tty", which is a kind of funky pipe that looks like a
tty from one end.)

The tty driver can operate in a number of modes. In
"cooked" mode it buffers up a line of input, handles
backspacing and other editing, and a few other things
like turning ctrl-C into an interrupt signal. In "raw"
mode, it doesn't buffer anything and passes all characters
straight on to the user process.

The above code is temporarily putting the tty driver into
raw mode, reading one character, and then putting it back
the way it was.

I'm not sure exactly what happens when Python is configured
to use the readline library; probably something in the
file object detects when it's being attached to a tty
and interposes readline, which then puts the tty into raw
mode and does its own thing.

I have even less idea what happens on Windows. The console
there seems to have an API all of its own. (The Unix
philosophy is "everything is a file"; on Windows it
seems to be "only files are files, everything else is
some other weird thing of its own.")

-- 
Greg

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

#64875

On 27/01/2014 15:53, Chris Angelico wrote:
> Frankly, I don't "idol worship" *any* language.

I worship English because it's so easy to learn.  Ducks and runs :)

-- 
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]

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

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

csiph-web