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

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

open() and EOFError

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

Contents

  open() and EOFError Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-07 03:20 +0000
    Re: open() and EOFError Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-07-07 17:04 +1200
      Re: open() and EOFError Steven D'Aprano <steve@pearwood.info> - 2014-07-07 08:00 +0000
        Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-07 18:09 +1000
        Re: open() and EOFError Dave Angel <davea@davea.name> - 2014-07-07 08:14 -0400
        Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-07 22:19 +1000
          Re: open() and EOFError Roy Smith <roy@panix.com> - 2014-07-07 08:46 -0400
            Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-07 22:58 +1000
              Re: open() and EOFError Roy Smith <roy@panix.com> - 2014-07-07 20:26 -0400
            Re: open() and EOFError Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-07-08 09:50 +1200
          Re: open() and EOFError Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-07 15:45 +0000
            Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-08 01:53 +1000
            Re: open() and EOFError Marko Rauhamaa <marko@pacujo.net> - 2014-07-07 19:08 +0300
              Re: open() and EOFError Marko Rauhamaa <marko@pacujo.net> - 2014-07-07 19:12 +0300
        Re: open() and EOFError Roy Smith <roy@panix.com> - 2014-07-07 08:39 -0400
          Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-07 22:55 +1000
            Re: open() and EOFError Roy Smith <roy@panix.com> - 2014-07-07 20:28 -0400
          Re: open() and EOFError Terry Reedy <tjreedy@udel.edu> - 2014-07-07 14:49 -0400
            Re: open() and EOFError Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-07-08 10:04 +1200
              Re: open() and EOFError Grant Edwards <invalid@invalid.invalid> - 2014-07-08 14:19 +0000
                Re: open() and EOFError Terry Reedy <tjreedy@udel.edu> - 2014-07-08 11:08 -0400
                Re: open() and EOFError Tim Chase <python.list@tim.thechases.com> - 2014-07-08 10:20 -0500
                Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-09 01:24 +1000
                Re: open() and EOFError Tim Chase <python.list@tim.thechases.com> - 2014-07-08 10:46 -0500
                  Re: open() and EOFError Roy Smith <roy@panix.com> - 2014-07-08 21:05 -0400
                    Re: open() and EOFError Anssi Saari <as@sci.fi> - 2014-07-10 22:40 +0300
                Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-09 01:49 +1000
                Re: ^D vs ^Z as EOF and DOS dinosaurs talking (was: open() and EOFError) Tim Chase <python.list@tim.thechases.com> - 2014-07-08 10:57 -0500
                  Re: ^D vs ^Z as EOF and DOS dinosaurs talking (was: open() and EOFError) Jan van den Broek <balglaas@xs4all.nl> - 2014-07-08 16:38 +0000
                Re: ^D vs ^Z as EOF and DOS dinosaurs talking (was: open() and EOFError) Chris Angelico <rosuav@gmail.com> - 2014-07-09 02:20 +1000
                Re: open() and EOFError Tim Chase <python.list@tim.thechases.com> - 2014-07-08 11:40 -0500
                Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-09 02:50 +1000
            Re: open() and EOFError Steven D'Aprano <steve@pearwood.info> - 2014-07-08 09:03 +0000
              Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-08 20:29 +1000
        Re: open() and EOFError Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-07 14:06 +0100
        Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-07 23:27 +1000
        Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-07 23:29 +1000
        Re: open() and EOFError Dan Stromberg <drsalists@gmail.com> - 2014-07-07 09:07 -0700
        Re: open() and EOFError Ian Kelly <ian.g.kelly@gmail.com> - 2014-07-07 11:25 -0600
          Re: open() and EOFError Marko Rauhamaa <marko@pacujo.net> - 2014-07-07 20:31 +0300
            Re: open() and EOFError Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-07 18:07 +0000
              Re: open() and EOFError Marko Rauhamaa <marko@pacujo.net> - 2014-07-07 21:42 +0300
              Re: open() and EOFError Roy Smith <roy@panix.com> - 2014-07-07 20:22 -0400
            Re: open() and EOFError Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-07-08 10:09 +1200
              Re: open() and EOFError Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-08 00:10 +0100
              Re: open() and EOFError "Neil D. Cerutti" <neilc@norwich.edu> - 2014-07-08 10:29 -0400
        Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-08 03:29 +1000
          Re: open() and EOFError Marko Rauhamaa <marko@pacujo.net> - 2014-07-07 20:40 +0300
            Re: open() and EOFError Chris Angelico <rosuav@gmail.com> - 2014-07-08 10:55 +1000
        Re: open() and EOFError Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-07-07 18:54 -0400

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

#74170

On 7/8/2014 10:19 AM, Grant Edwards wrote:
> On 2014-07-07, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote:
>> Terry Reedy wrote:
>>> Avoid EOFError. Much better, I think, is the somewhat customary
>>>
>>> s = input("Enter something, or hit <return> to exit")
>>> if not s: sys.exit()
>>> else: <process s>
>>
>> I beg to differ -- on Unix, Ctrl-D *is* the customary
>> way to exit from something that's reading from stdin.
>
> Indeed.  Ctrl-D is _the_ canonical way to tell a program that's
> reading stdin that your're done.

Not on Windows.

> I've never run across "hit <return> to exit".
>
>> In any case, you need to be able to handle EOF gracefully if the user
>> uses it.
>


-- 
Terry Jan Reedy

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

#74172

On 2014-07-08 11:08, Terry Reedy wrote:
> > Indeed.  Ctrl-D is _the_ canonical way to tell a program that's
> > reading stdin that your're done.  
> 
> Not on Windows.

Okay, EOF is the canonical way to tell a program reading stdin that
you're done.  It just happens that EOF ^D on *nix-likes and ^Z on
Win32. :-)

-tkc

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

#74174

On Wed, Jul 9, 2014 at 1:20 AM, Tim Chase <python.list@tim.thechases.com> wrote:
> On 2014-07-08 11:08, Terry Reedy wrote:
>> > Indeed.  Ctrl-D is _the_ canonical way to tell a program that's
>> > reading stdin that your're done.
>>
>> Not on Windows.
>
> Okay, EOF is the canonical way to tell a program reading stdin that
> you're done.  It just happens that EOF ^D on *nix-likes and ^Z on
> Win32. :-)
>
> -tkc

I can't think of any Windows-native programs that ask for EOF. Only
those which came from POSIX platforms do it. That said, though,
Windows doesn't tend to encourage interactive command-line programs at
all, so you may as well just follow the Unix convention.

ChrisA

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

#74177

On 2014-07-09 01:24, Chris Angelico wrote:
> On Wed, Jul 9, 2014 at 1:20 AM, Tim Chase
> > Okay, EOF is the canonical way to tell a program reading stdin
> > that you're done.  It just happens that EOF ^D on *nix-likes and
> > ^Z on Win32. :-)
> >
> > -tkc
> 
> I can't think of any Windows-native programs that ask for EOF. Only
> those which came from POSIX platforms do it. That said, though,
> Windows doesn't tend to encourage interactive command-line programs
> at all, so you may as well just follow the Unix convention.

There was a time in life where I used "copy con output.txt" on a
disturbingly frequent basis.  Control+Z ended my file for me.

-tkc

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

#74223

In article <mailman.11636.1404834458.18130.python-list@python.org>,
 Tim Chase <python.list@tim.thechases.com> wrote:

> On 2014-07-09 01:24, Chris Angelico wrote:
> > On Wed, Jul 9, 2014 at 1:20 AM, Tim Chase
> > > Okay, EOF is the canonical way to tell a program reading stdin
> > > that you're done.  It just happens that EOF ^D on *nix-likes and
> > > ^Z on Win32. :-)
> > >
> > > -tkc
> > 
> > I can't think of any Windows-native programs that ask for EOF. Only
> > those which came from POSIX platforms do it. That said, though,
> > Windows doesn't tend to encourage interactive command-line programs
> > at all, so you may as well just follow the Unix convention.
> 
> There was a time in life where I used "copy con output.txt" on a
> disturbingly frequent basis.  Control+Z ended my file for me.
> 
> -tkc

I once knew a guy who linked /dev/tty.c to /dev/tty, then he could do 
"cc /dev/tty.c" and type a C program in to the compiler from the 
terminal.

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

#74331

Roy Smith <roy@panix.com> writes:

> I once knew a guy who linked /dev/tty.c to /dev/tty, then he could do 
> "cc /dev/tty.c" and type a C program in to the compiler from the 
> terminal.

I thought some old C compilers took input from stdin without that kind
of trickery? Oh, looks like modern gcc does it too, as long as the
language is specified with -x.

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

#74178

On Wed, Jul 9, 2014 at 1:46 AM, Tim Chase <python.list@tim.thechases.com> wrote:
> On 2014-07-09 01:24, Chris Angelico wrote:
>> On Wed, Jul 9, 2014 at 1:20 AM, Tim Chase
>> > Okay, EOF is the canonical way to tell a program reading stdin
>> > that you're done.  It just happens that EOF ^D on *nix-likes and
>> > ^Z on Win32. :-)
>> >
>> > -tkc
>>
>> I can't think of any Windows-native programs that ask for EOF. Only
>> those which came from POSIX platforms do it. That said, though,
>> Windows doesn't tend to encourage interactive command-line programs
>> at all, so you may as well just follow the Unix convention.
>
> There was a time in life where I used "copy con output.txt" on a
> disturbingly frequent basis.  Control+Z ended my file for me.
>

Yes, and I've done that with a few programs (sort comes to mind; also
Regina Rexx, because it lacked a true interactive interpreter), but
not interactive ones. Those programs are filters, so obviously EOF is
the way to signal, well, end of file.

(Have you ever used COPY CON to create a binary file?)

ChrisA

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

#74179 — Re: ^D vs ^Z as EOF and DOS dinosaurs talking (was: open() and EOFError)

On 2014-07-09 01:49, Chris Angelico wrote:
> Have you ever used COPY CON to create a binary file?

No, for that I used DEBUG.EXE (or DEBUG.COM on older versions of DOS)

-tkc

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

#74183 — Re: ^D vs ^Z as EOF and DOS dinosaurs talking (was: open() and EOFError)

On 2014-07-08, Tim Chase <python.list@tim.thechases.com> wrote:
> On 2014-07-09 01:49, Chris Angelico wrote:
>> Have you ever used COPY CON to create a binary file?
>
> No, for that I used DEBUG.EXE (or DEBUG.COM on older versions of DOS)

Both.
-- 
                                 Jan v/d Broek
                               balglaas@xs4all.nl

        "Geef je over, wy zyn Bassie en Adriaan, weerstand is nutteloos"

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

#74181 — Re: ^D vs ^Z as EOF and DOS dinosaurs talking (was: open() and EOFError)

On Wed, Jul 9, 2014 at 1:57 AM, Tim Chase <python.list@tim.thechases.com> wrote:
> On 2014-07-09 01:49, Chris Angelico wrote:
>> Have you ever used COPY CON to create a binary file?
>
> No, for that I used DEBUG.EXE (or DEBUG.COM on older versions of DOS)

I never used a DOS version so old it had DEBUG.COM, but I used
DEBUG.EXE extensively. It was, for years, the only means I had of
building assembly language programs - no C compiler, no proper
assembler, nothing. One of my greatest triumphs, at the time, was the
development of an absolutely insane (even at the time I knew it was
insane) system that let me build an assembly program with line labels
in it; it would pipe commands into DEBUG and pipe the output back out,
and drive DEBUG's mini-assembler. When it came to a label, it would
look at what the prompt said would be the next address, and save it.
When the label was used, it would patch in the actual address. And
forward references were handled, too - it'd put in a placeholder, and
then go and assemble over it afterward. (I'm not sure what happened if
the placeholder resulted in the wrong size of jump command being
assembled. It was a definite consideration, as conditional jumps had
to be relative, but unconditional jumps could be relative (two-byte
command) or absolute (three-byte command). Maybe it just always put in
a distant target, and patched in a NOP if it didn't need the third
byte, or something. I don't remember.)

Sadly, there was a period when all my programming was either in BASIC
or assembly, and even more sadly, I would write low-level code using
DEBUG, save it into the format needed by BLOAD, and then CALL ABSOLUTE
the routine from BASIC... in order to, for instance, access the mouse.
Life got ever so much better when I moved to OS/2, and started using
REXX for most of my work. (And then eventually got a C compiler,
albeit a Windows one. Was years and years before I actually got a
decent build system for OS/2.)

There was a time when, just for the fun of it, I started memorizing a
whole lot of 8086 opcodes in hex, just so I could COPY CON PROGRAM.COM
and make something actually work. I don't think there was ever any
purpose in it at all, but it was fun. I guess that's a purpose... some
people play Tetris, some people have girlfriends/boyfriends, and some
people learn to write machine code at COPY CON...

ChrisA

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

#74184

On 2014-07-09 01:24, Chris Angelico wrote:
> I can't think of any Windows-native programs that ask for EOF. Only
> those which came from POSIX platforms do it. That said, though,
> Windows doesn't tend to encourage interactive command-line programs
> at all, so you may as well just follow the Unix convention.

And within the last 10 minutes doing some work on a Win32 box, I
noticed that both the "wmic" console (standard since at least XP I
believe) and Python use EOF to quit (both provide alternate methods of
quitting, but EOF is fast & easy).

-tkc

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

#74185

On Wed, Jul 9, 2014 at 2:40 AM, Tim Chase <python.list@tim.thechases.com> wrote:
> On 2014-07-09 01:24, Chris Angelico wrote:
>> I can't think of any Windows-native programs that ask for EOF. Only
>> those which came from POSIX platforms do it. That said, though,
>> Windows doesn't tend to encourage interactive command-line programs
>> at all, so you may as well just follow the Unix convention.
>
> And within the last 10 minutes doing some work on a Win32 box, I
> noticed that both the "wmic" console (standard since at least XP I
> believe) and Python use EOF to quit (both provide alternate methods of
> quitting, but EOF is fast & easy).
>

Python doesn't count, as it's cross-platform; lots of programs work
the same way on all their platforms, and it doesn't say anything about
the expectations of native Windows apps. But wmic, that's a better
example. Counter-example: Command-line FTP on Windows doesn't react to
Ctrl-Z, which annoys me somewhat when I move from one to another. (Not
as much as it annoys me by not supporting passive mode, though. I
generally have to turn to a web browser to do basic FTP downloads
across a VM boundary, and for uploads, I either have to go fetch a
better FTP client (like FileZilla), or - as I've often done - whip up
a few lines of basic TCP socket file transfer, because I can do that
at an interactive interpreter faster than most people can move files
any other way.)

hrisA

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

#74155

On Mon, 07 Jul 2014 14:49:56 -0400, Terry Reedy wrote:

> Avoid EOFError. Much better, I think, is the somewhat customary
> 
> s = input("Enter something, or hit <return> to exit") if not s:
> sys.exit()
> else: <process s>

Under many circumstances, I would do exactly that. But sometimes an empty 
string is valid data, not a signal for special processing (whether 
exiting the application, or something else).


-- 
Steven

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

#74161

On Tue, Jul 8, 2014 at 7:03 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Mon, 07 Jul 2014 14:49:56 -0400, Terry Reedy wrote:
>
>> Avoid EOFError. Much better, I think, is the somewhat customary
>>
>> s = input("Enter something, or hit <return> to exit") if not s:
>> sys.exit()
>> else: <process s>
>
> Under many circumstances, I would do exactly that. But sometimes an empty
> string is valid data, not a signal for special processing (whether
> exiting the application, or something else).

Or you want to have two different signals: empty string means "use the
default", and something else means "exit the application now please".
Very common.

ChrisA

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

#74104

On 07/07/2014 09:09, Chris Angelico wrote:
> On Mon, Jul 7, 2014 at 6:00 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>> How do people feel about code like this?
>>
>> try:
>>      name = input("Enter file name, or Ctrl-D to exit")
>>      # On Windows, use Ctrl-Z [enter] instead.
>>      fp = open(name)
>> except EOFError:
>>      sys.exit()
>> except IOError:
>>      handle_bad_file(name)
>> else:
>>      handle_good_file(fp)
>
> It seems trivial in this example to break it into two try blocks:
>
> try:
>      name = input("Enter file name, or Ctrl-D to exit")
>      # On Windows, use Ctrl-Z [enter] instead.
> except EOFError:
>      sys.exit()
> try:
>      fp = open(name)
> except IOError:
>      handle_bad_file(name)
> else:
>      handle_good_file(fp)
>

All those extra lines to type, not on your life.  Surely it would be 
better written as a one liner?

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

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

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

#74105

On Mon, Jul 7, 2014 at 11:06 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 07/07/2014 09:09, Chris Angelico wrote:
>>
>> It seems trivial in this example to break it into two try blocks:
>>
>> try:
>>      name = input("Enter file name, or Ctrl-D to exit")
>>      # On Windows, use Ctrl-Z [enter] instead.
>> except EOFError:
>>      sys.exit()
>> try:
>>      fp = open(name)
>> except IOError:
>>      handle_bad_file(name)
>> else:
>>      handle_good_file(fp)
>>
>
> All those extra lines to type, not on your life.  Surely it would be better
> written as a one liner?

Challenge accepted! I shall wield the power of PEP 463, even though it
never got accepted, and pretend that it's a standard feature!

name = (input("Enter file name, or Ctrl-D to exit") except EOFError: sys.exit())
(handle_good_file(open(name)) except IOError: handle_bad_file(name))

Readers with a degree in higher mathematics will note that this is not
one, but two lines. It can be turned into one line, however the
forking out of the name requires some cheating. But since the last
part is now an expression, we have the option of lambda shenanigans...

(lambda n:(handle_good_file(open(n))except
IOError:handle_bad_file(n)))(input("Enter file name, or Ctrl-D to
exit")except EOFError:sys.exit())

Et voila! A single line, albeit 142 characters long, and that with
superfluous (ha!) internal spaces removed. As a side-effect of
expressionization (if that's a word), the code now catches IOError
from inside handle_good_file() by going to handle_bad_file, which is
almost certainly a bad idea (most likely, handle_good_file is going to
read from that file). But it's much more important that this be a
one-liner!

Alternatively, the nesting could be inverted. As long as
handle_bad_file() returns something which is not a file pointer (eg
None), and handle_good_file is carefully written to quietly do nothing
if given that, the original semantics could be retained:

(lambda n:(handle_good_file(open(n)except
IOError:handle_bad_file(n))))(input("Enter file name, or Ctrl-D to
exit")except EOFError:sys.exit())

Take your pick. And enjoy! :)

ChrisA

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

#74106

On Mon, Jul 7, 2014 at 11:06 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> try:
>>      name = input("Enter file name, or Ctrl-D to exit")
>>      # On Windows, use Ctrl-Z [enter] instead.
>> except EOFError:
>>      sys.exit()
>> try:
>>      fp = open(name)
>> except IOError:
>>      handle_bad_file(name)
>> else:
>>      handle_good_file(fp)
>>
>
> All those extra lines to type, not on your life.  Surely it would be better
> written as a one liner?

In all seriousness, though, if you're worried about the number of
lines, it's not that big a deal to squish up the small try blocks.

try: name = input("Enter file name, or Ctrl-D to exit")
except EOFError: sys.exit()

try: fp = open(name)
except IOError: handle_bad_file(name)
else: handle_good_file(fp)

Might violate some style guides, but IMO it's not a problem.

ChrisA

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

#74120

On 7/7/14, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 07/07/2014 09:09, Chris Angelico wrote:
>> On Mon, Jul 7, 2014 at 6:00 PM, Steven D'Aprano <steve@pearwood.info>
>> wrote:
>>> How do people feel about code like this?
>>>
>>> try:
>>>      name = input("Enter file name, or Ctrl-D to exit")
>>>      # On Windows, use Ctrl-Z [enter] instead.
>>>      fp = open(name)
>>> except EOFError:
>>>      sys.exit()
>>> except IOError:
>>>      handle_bad_file(name)
>>> else:
>>>      handle_good_file(fp)
>>
>> It seems trivial in this example to break it into two try blocks:
>>
>> try:
>>      name = input("Enter file name, or Ctrl-D to exit")
>>      # On Windows, use Ctrl-Z [enter] instead.
>> except EOFError:
>>      sys.exit()
>> try:
>>      fp = open(name)
>> except IOError:
>>      handle_bad_file(name)
>> else:
>>      handle_good_file(fp)
>>
>
> All those extra lines to type, not on your life.  Surely it would be
> better written as a one liner?

Don't be afraid of a few extra keystrokes.  Clarity is king.

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

#74127

On Mon, Jul 7, 2014 at 2:09 AM, Chris Angelico <rosuav@gmail.com> wrote:
> But if the code's more complicated and it's not so easy to split, then
> sure, doesn't seem a problem. It's like spam[foo//bar] and then
> catching either IndexError or ZeroDivisionError - there's no big
> confusion from having two distinct sources of two distinct errors
> handled by two distinct except blocks.

It's good practice to keep your try blocks as narrow as possible in
any case.  One wouldn't normally expect them, but a custom __getitem__
*could* cause a ZeroDivisionError, and a custom __floordiv__ *could*
cause an IndexError.

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

#74129

Ian Kelly <ian.g.kelly@gmail.com>:

> It's good practice to keep your try blocks as narrow as possible in
> any case.

True. Unfortunately, that leads to trouble with the handy "with"
construct:

    with open(path) as f:
        ...

If the open() call is guarded against exceptions (as it usually should),
one must revert to the classic syntax:

    try:
         f = open(path)
    except IOError:
         ...
    try:
         ...
    finally:
         f.close()


Marko

[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