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

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

seek operation in python

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

Contents

  seek operation in python siva sankari R <buddingrose11@gmail.com> - 2015-04-29 11:08 -0700
    Re: seek operation in python Joel Goldstick <joel.goldstick@gmail.com> - 2015-04-29 14:17 -0400
      Re: seek operation in python siva sankari R <buddingrose11@gmail.com> - 2015-04-29 11:26 -0700
        Re: seek operation in python Billy Earney <billy.earney@gmail.com> - 2015-04-29 13:42 -0500
        Re: seek operation in python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-29 21:53 +0100
          Re: seek operation in python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-30 10:19 +1000
    Re: seek operation in python MRAB <python@mrabarnett.plus.com> - 2015-04-29 19:50 +0100
    Re: seek operation in python John Gordon <gordon@panix.com> - 2015-04-29 18:53 +0000
    Re: seek operation in python Chris Angelico <rosuav@gmail.com> - 2015-04-30 10:33 +1000
      Re: seek operation in python Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 08:27 +0200
        Re: seek operation in python Chris Angelico <rosuav@gmail.com> - 2015-04-30 17:33 +1000
          Re: seek operation in python Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 10:06 +0200
            Re: seek operation in python Dave Angel <davea@davea.name> - 2015-04-30 04:31 -0400
              Re: seek operation in python Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 11:06 +0200
                Re: seek operation in python Chris Angelico <rosuav@gmail.com> - 2015-04-30 19:39 +1000
            Re: seek operation in python Larry Hudson <orgnut@yahoo.com> - 2015-04-30 12:38 -0700
              Re: seek operation in python Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 22:50 +0200
                Re: seek operation in python Larry Hudson <orgnut@yahoo.com> - 2015-04-30 19:42 -0700
    Re: seek operation in python Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 14:31 +0200

#89561 — seek operation in python

file=open("input","r")
line=file.seek(7)
print line

The above code is supposed to print a line but it prints "none". I don't know where the mistake is. Help.!

[toc] | [next] | [standalone]

#89563

On Wed, Apr 29, 2015 at 2:08 PM, siva sankari R <buddingrose11@gmail.com> wrote:
> file=open("input","r")
> line=file.seek(7)
> print line
>
> The above code is supposed to print a line but it prints "none". I don't know where the mistake is. Help.!
> --
> https://mail.python.org/mailman/listinfo/python-list

What is in the file you are printing?

-- 
Joel Goldstick
http://joelgoldstick.com

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

#89564

There is a file named "input.cpp"(c++ file) that contains some 80 lines of code. 

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

#89566

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

if your filename is input.cpp, you first line of code should be:

file=open("input*.cpp*","r")

On Wed, Apr 29, 2015 at 1:26 PM, siva sankari R <buddingrose11@gmail.com>
wrote:

> There is a file named "input.cpp"(c++ file) that contains some 80 lines of
> code.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

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

#89576

The only good top poster is a dead top poster, except for...

On 29/04/2015 19:42, Billy Earney wrote:
> if your filename is input.cpp, you first line of code should be:
>
> file=open("input*.cpp*","r")
>
> On Wed, Apr 29, 2015 at 1:26 PM, siva sankari R <buddingrose11@gmail.com>
> wrote:
>
>> There is a file named "input.cpp"(c++ file) that contains some 80 lines of
>> code.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>

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

#89589

On Thu, 30 Apr 2015 06:53 am, Mark Lawrence wrote:

> The only good top poster is a dead top poster, except for...

Since you just top posted, at least you're being honest.

Mark, I'm fairly sure you were trying to be funny, but I think you just
crossed a line from "funny and mean" to "just mean but not funny". 


-- 
Steven

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

#89567

On 2015-04-29 19:08, siva sankari R wrote:
> file=open("input","r")
> line=file.seek(7)
> print line
>
> The above code is supposed to print a line but it prints "none". I don't know where the mistake is. Help.!
>
'seek' will seek to position 7 in the file. It doesn't read. That's
what 'read' is for! :-)

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

#89568

In <8b2bd328-08a6-4211-85c4-8d117d1aae1e@googlegroups.com> siva sankari R <buddingrose11@gmail.com> writes:

> file=open("input","r")
> line=file.seek(7)
> print line

> The above code is supposed to print a line but it prints "none".
> I don't know where the mistake is. Help.!

The seek() function doesn't return any data; it just relocates the file
pointer.  You still have to do a read operation to get data from the
new location.

-- 
John Gordon         Imagine what it must be like for a real medical doctor to
gordon@panix.com    watch 'House', or a real serial killer to watch 'Dexter'.

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

#89591

On Thu, Apr 30, 2015 at 4:08 AM, siva sankari R <buddingrose11@gmail.com> wrote:
> file=open("input","r")
> line=file.seek(7)
> print line
>
> The above code is supposed to print a line but it prints "none". I don't know where the mistake is. Help.!

Going right back to the beginning... Are you aware that 'seek' works
with byte positions? On a text file, you can't even do this, and even
on a byte file, it won't give you the seventh line.

If, as you say, it's only some eighty lines of code, the best solution
is probably the simplest: read the whole file into memory.

with open("input.cpp") as f:
    lines = f.readlines()
print(lines[7])

That will print out the seventh line (counting from zero; take
lines[6] if you want to count from one), rather than seeking to byte
position 7 and printing out from there to the end of a line.

I've made a few other changes in the example, too:

1) Not that it's a big deal, but I used "f' rather than "file",
because the latter is a built-in name in Python 2, and it's safer not
to shadow.
2) A 'with' block ensures that the file is closed promptly.
3) Parentheses around your 'print' make it compatible with the
function form as well as the statement.

They're all small changes, but clean code is good code :)

ChrisA

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

#89606

Op Thursday 30 Apr 2015 02:33 CEST schreef Chris Angelico:

> On Thu, Apr 30, 2015 at 4:08 AM, siva sankari R <buddingrose11@gmail.com> wrote:
>> file=open("input","r")
>> line=file.seek(7)
>> print line
>>
>> The above code is supposed to print a line but it prints "none". I
>> don't know where the mistake is. Help.!
>
> Going right back to the beginning... Are you aware that 'seek' works
> with byte positions? On a text file, you can't even do this, and
> even on a byte file, it won't give you the seventh line.
>
> If, as you say, it's only some eighty lines of code, the best
> solution is probably the simplest: read the whole file into memory.
>
> with open("input.cpp") as f:
> lines = f.readlines()
> print(lines[7])

Is the following not better:
    print(open('input.cpp', 'r').readlines()[7])

Time is the same (about 25 seconds for 100.000 calls), but I find this
more clear.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

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

#89609

On Thu, Apr 30, 2015 at 4:27 PM, Cecil Westerhof <Cecil@decebal.nl> wrote:
>> with open("input.cpp") as f:
>> lines = f.readlines()
>> print(lines[7])
>
> Is the following not better:
>     print(open('input.cpp', 'r').readlines()[7])
>
> Time is the same (about 25 seconds for 100.000 calls), but I find this
> more clear.

The significant difference is that the 'with' block guarantees to
close the file promptly. With CPython it probably won't make a lot of
difference, and in a tiny script it won't do much either, but if you
do this on Jython or IronPython or MicroPython or some other
implementation, it may well make a gigantic difference - your loop
might actually fail because the file's still open.

ChrisA

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

#89612

Op Thursday 30 Apr 2015 09:33 CEST schreef Chris Angelico:

> On Thu, Apr 30, 2015 at 4:27 PM, Cecil Westerhof <Cecil@decebal.nl> wrote:
>>> with open("input.cpp") as f:
>>> lines = f.readlines()
>>> print(lines[7])
>>
>> Is the following not better:
>> print(open('input.cpp', 'r').readlines()[7])
>>
>> Time is the same (about 25 seconds for 100.000 calls), but I find
>> this more clear.
>
> The significant difference is that the 'with' block guarantees to
> close the file promptly. With CPython it probably won't make a lot
> of difference, and in a tiny script it won't do much either, but if
> you do this on Jython or IronPython or MicroPython or some other
> implementation, it may well make a gigantic difference - your loop
> might actually fail because the file's still open.

I thought that in this case the file was also closed. But if that is
not the case I should think about this when I switch to another
version as CPython.

I wrote a module where I have:
    def get_indexed_message(message_filename, index):
        """
        Get index message from a file, where 0 gets the first message
        """

        return open(expanduser(message_filename), 'r').readlines()[index].rstrip()

But this can be used by others also and they could be using Jython or
another implementation. So should I rewrite this and other functions?
Or would it be OK because the open is in a function?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

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

#89613

On 04/30/2015 04:06 AM, Cecil Westerhof wrote:
> Op Thursday 30 Apr 2015 09:33 CEST schreef Chris Angelico:
>
>> On Thu, Apr 30, 2015 at 4:27 PM, Cecil Westerhof <Cecil@decebal.nl> wrote:
>>>> with open("input.cpp") as f:
>>>> lines = f.readlines()
>>>> print(lines[7])
>>>
>>> Is the following not better:
>>> print(open('input.cpp', 'r').readlines()[7])
>>>
>>> Time is the same (about 25 seconds for 100.000 calls), but I find
>>> this more clear.
>>
>> The significant difference is that the 'with' block guarantees to
>> close the file promptly. With CPython it probably won't make a lot
>> of difference, and in a tiny script it won't do much either, but if
>> you do this on Jython or IronPython or MicroPython or some other
>> implementation, it may well make a gigantic difference - your loop
>> might actually fail because the file's still open.
>
> I thought that in this case the file was also closed. But if that is
> not the case I should think about this when I switch to another
> version as CPython.
>
> I wrote a module where I have:
>      def get_indexed_message(message_filename, index):
>          """
>          Get index message from a file, where 0 gets the first message
>          """
>
>          return open(expanduser(message_filename), 'r').readlines()[index].rstrip()
>
> But this can be used by others also and they could be using Jython or
> another implementation. So should I rewrite this and other functions?
> Or would it be OK because the open is in a function?
>

No, it's not going to close the file just because the open is in a 
function.  The "with" construct was designed to help solve exactly this 
problem.  Please use it.



-- 
DaveA

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

#89615

Op Thursday 30 Apr 2015 10:31 CEST schreef Dave Angel:

> On 04/30/2015 04:06 AM, Cecil Westerhof wrote:
>> Op Thursday 30 Apr 2015 09:33 CEST schreef Chris Angelico:
>>
>>> On Thu, Apr 30, 2015 at 4:27 PM, Cecil Westerhof <Cecil@decebal.nl> wrote:
>>>>> with open("input.cpp") as f:
>>>>> lines = f.readlines()
>>>>> print(lines[7])
>>>>
>>>> Is the following not better:
>>>> print(open('input.cpp', 'r').readlines()[7])
>>>>
>>>> Time is the same (about 25 seconds for 100.000 calls), but I find
>>>> this more clear.
>>>
>>> The significant difference is that the 'with' block guarantees to
>>> close the file promptly. With CPython it probably won't make a lot
>>> of difference, and in a tiny script it won't do much either, but
>>> if you do this on Jython or IronPython or MicroPython or some
>>> other implementation, it may well make a gigantic difference -
>>> your loop might actually fail because the file's still open.
>>
>> I thought that in this case the file was also closed. But if that
>> is not the case I should think about this when I switch to another
>> version as CPython.
>>
>> I wrote a module where I have:
>> def get_indexed_message(message_filename, index):
>> """
>> Get index message from a file, where 0 gets the first message
>> """
>>
>> return open(expanduser(message_filename),
>> 'r').readlines()[index].rstrip()
>>
>> But this can be used by others also and they could be using Jython
>> or another implementation. So should I rewrite this and other
>> functions? Or would it be OK because the open is in a function?
>>
>
> No, it's not going to close the file just because the open is in a
> function. The "with" construct was designed to help solve exactly
> this problem. Please use it.

I already done it. I thought it not to much work. And it even makes
some code shorter:
-    marshal_file    = open(expanduser(marshal_filename), 'r')
-    not_list        = load(marshal_file)
-    marshal_file.close()
-    return not_list
+    with open(expanduser(marshal_filename), 'r') as f:
+        return load(f)

But here I did the close myself already, so that is not completely
honest of me. ;-)

I should spend some time to make my code more consistent.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

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

#89618

On Thu, Apr 30, 2015 at 7:06 PM, Cecil Westerhof <Cecil@decebal.nl> wrote:
> I already done it. I thought it not to much work. And it even makes
> some code shorter:
> -    marshal_file    = open(expanduser(marshal_filename), 'r')
> -    not_list        = load(marshal_file)
> -    marshal_file.close()
> -    return not_list
> +    with open(expanduser(marshal_filename), 'r') as f:
> +        return load(f)
>
> But here I did the close myself already, so that is not completely
> honest of me. ;-)

The context manager makes your code more concise AND more reliable -
an exception thrown by load() will skip the explicit close(), but the
'with' block unwinds correctly whether there's an exception or not.

ChrisA

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

#89664

On 04/30/2015 01:06 AM, Cecil Westerhof wrote:
[snip]

> I wrote a module where I have:
>      def get_indexed_message(message_filename, index):
>          """
>          Get index message from a file, where 0 gets the first message
>          """
>
>          return open(expanduser(message_filename), 'r').readlines()[index].rstrip()
>
Very minor nit unrelated to the file closing question:
This would be a good place to give index a default value...

def get_indexed_message(message_filename, index=0):
     ...

      -=- Larry -=-

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

#89675

Op Thursday 30 Apr 2015 21:38 CEST schreef Larry Hudson:

> On 04/30/2015 01:06 AM, Cecil Westerhof wrote:
> [snip]
>
>> I wrote a module where I have:
>> def get_indexed_message(message_filename, index):
>> """
>> Get index message from a file, where 0 gets the first message
>> """
>>
>> return open(expanduser(message_filename),
>> 'r').readlines()[index].rstrip()
>>
> Very minor nit unrelated to the file closing question:
> This would be a good place to give index a default value...
>
> def get_indexed_message(message_filename, index=0):

Why would you want this? I think the index should always be defined.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

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

#89688

On 04/30/2015 01:50 PM, Cecil Westerhof wrote:
> Op Thursday 30 Apr 2015 21:38 CEST schreef Larry Hudson:
>
>> On 04/30/2015 01:06 AM, Cecil Westerhof wrote:
>> [snip]
>>
>>> I wrote a module where I have:
>>> def get_indexed_message(message_filename, index):
>>> """
>>> Get index message from a file, where 0 gets the first message
>>> """
>>>
>>> return open(expanduser(message_filename),
>>> 'r').readlines()[index].rstrip()
>>>
>> Very minor nit unrelated to the file closing question:
>> This would be a good place to give index a default value...
>>
>> def get_indexed_message(message_filename, index=0):
>
> Why would you want this? I think the index should always be defined.
>
Matter of opinion, of course, but this allows calling the function without specifying the index 
and you still get a useful (and logical) result.  I find this convenient in most similar cases. 
  Using default parameters is quite Pythonic.  Note that this _permits_ using the function this 
way, it does not _require_ it.  Of course, it also should be suitably documented.  Naturally, YMMV.

      -=- Larry -=-

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

#89630

Op Wednesday 29 Apr 2015 20:08 CEST schreef siva sankari R.:

> file=open("input","r")
> line=file.seek(7)
> print line
>
> The above code is supposed to print a line but it prints "none". I
> don't know where the mistake is. Help.!

You could use my module:
    https://github.com/CecilWesterhof/PythonLibrary/blob/master/filebasedMessages.py

Then use:
    from filebasedMessages import get_indexed_message

    get_indexed_message('input.cpp', 7)

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [standalone]

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

csiph-web