On 6/20/10, Steven D'Aprano <st...@pearwood.info> wrote:
> On Mon, 21 Jun 2010 09:02:55 am Alex Hall wrote:
>> On 6/20/10, Neil Thorman <neil.thor...@gmail.com> wrote:
> [...]
>> >>>>inp = file("menu.txt", "r")
>> >
>> > *What is inp? What does it now contain?*
>>
>> It is now a reference to the location of the txt file.
>
> [pedantic]
> No, it's actually an abstract data structure that wraps the actual file
> itself. A reference to the *location* of the file would be:
>
> inp = "menu.txt"
>
> Locations are strings. File objects are file objects.
> [/pedantic]
>
> But in a practical sense, pay no attention to the man behind the curtain
> (the implementation details). inp is a file in every way which matters,
> just like after:
>
> n = 42
> x = 1.234
>
> n is an int and x a float in every way which matters.
>
>
>> Python calls
>> these file "objects", where an object is just something on which you
>> can call functions. If you had a dog object you might call a "bark"
>> method; here, we have a file object, so we can see what the file is.
>> inp is not the file itself, just as any object is not the full
>> object's info but rather a pointer to where that info is. If you were
>> to print inp, I think you would get a memory address.
>
> You would get a string printed to the console, like printing *anything*.
>
>>>> print inp
> <open file 'foo', mode 'w' at 0xb7d3a250>
Oh right, the object's toString method (or whatever Python calls this;
Java and Javascript call it toString, and it exists for all objects).
>
> That string happens to contain a hex number which looks like it could be
> a memory address, but that's an implementation detail because CPython
> doesn't sufficiently abstract its objects from the underlying C
> implementation.
>
> Python file objects aren't "files" only in the sense that they exist in
> memory rather than on disk in the file system, but other than that, I
> believe your explanation is at too low a level to be helpful. Neil said
> he's a beginner who hasn't done any programming since BASIC on an
> Acorn, and you're talking about low-level details like memory
> locations. Let me guess, you're also a C programmer?
Good point, and sorry for going into too much detail, much of which is
not on the mark anyway. :) No, I have hardly touched c++, but I am
starting my final year of a computer science degree in a few months so
I have had all the details of objects and how the computer actually
accesses them in several classes.
>
> As far as coding in Python is concerned, inp = file(pathname) creates a
> file object, which *is* a file in all practical sense. Everything else
> is just an implementation detail, which could change depending on the
> version of Python, the operating system, and the underlying hardware.
Very true.
>
>
> [...]
>> >>>>print inp.readlines()
>> >
>> > ['spam & eggs\n', 'spam & chips\n', 'spam & spam']
>> >
>> > but if I do it again I get:
>> >>>> print inp.readlines()
>> >
>> > []
>> >
>> > I'm baffled, why is inp now empty?
>>
>> I suspect you have hit the end of the file.
>
> Yes. readlines reads from the current file position, like all read
> operations. To read all the text again, you have to reset the file
> position with seek:
>
> inp.seek(0)
>
>
>
> --
> Steven D'Aprano
> _______________________________________________
> Tutor maillist - Tutor@python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor
>
--
Have a great day,
Alex (msg sent from GMail website)
mehg...@gmail.com; http://www.facebook.com/mehgcap
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
