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

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

python file API

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

Contents

  python file API zipher <dreamingforward@gmail.com> - 2012-09-24 14:35 -0700
    Re: python file API Dave Angel <d@davea.name> - 2012-09-24 17:49 -0400
      Re: python file API Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-09-25 08:22 +0200
        Re: python file API Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-25 04:19 -0400
          Re: python file API Grant Edwards <invalid@invalid.invalid> - 2012-09-25 14:07 +0000
        Re: python file API Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-25 12:07 -0400
        Re: python file API Chris Angelico <rosuav@gmail.com> - 2012-09-26 02:12 +1000
    Re: python file API Chris Kaynor <ckaynor@zindagigames.com> - 2012-09-24 14:58 -0700
    Re: python file API Chris Angelico <rosuav@gmail.com> - 2012-09-25 08:14 +1000
      Re: python file API zipher <dreamingforward@gmail.com> - 2012-09-24 15:36 -0700
        Re: python file API Mark Adam <dreamingforward@gmail.com> - 2012-09-24 21:32 -0500
        Re: python file API Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-25 08:27 +0100
        Re: python file API Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-25 11:51 +0100
      Re: python file API zipher <dreamingforward@gmail.com> - 2012-09-24 15:36 -0700
        Re: python file API Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-25 02:28 +0000
          Re: python file API Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-09-25 07:25 +0200
            Re: python file API Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-25 07:28 +0000
              Re: python file API Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-09-25 21:40 +0200
      Re: python file API Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-25 01:33 +0000
    Re: python file API Dave Angel <d@davea.name> - 2012-09-24 18:36 -0400
    Re: python file API Ian Kelly <ian.g.kelly@gmail.com> - 2012-09-24 16:37 -0600
      Re: python file API Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-09-25 07:32 +0200
        Re: python file API Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-25 04:13 -0400
          Re: python file API Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-09-25 11:53 +0200
        Re: python file API Ian Kelly <ian.g.kelly@gmail.com> - 2012-09-25 03:32 -0600
    Re: python file API Chris Angelico <rosuav@gmail.com> - 2012-09-25 08:57 +1000
    Re: python file API Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-25 00:12 +0100
    Re: python file API Chris Kaynor <ckaynor@zindagigames.com> - 2012-09-24 16:14 -0700
    Re: python file API Ramchandra Apte <maniandram01@gmail.com> - 2012-09-30 05:50 -0700

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

#29948

On Mon, Sep 24, 2012 at 4:14 PM, Chris Angelico <rosuav@gmail.com> wrote:
> file.pos = 42 # Okay, you're at position 42
> file.pos -= 10 # That should put you at position 32
> foo = file.pos # Presumably foo is the integer 32
> file.pos -= 100 # What should this do?

Since ints are immutable, the language specifies that it should be the
equivalent of "file.pos = file.pos - 100", so it should set the file
pointer to 68 bytes before EOF.

> foo -= 100 # But this sets foo to the integer -68
> file.pos = foo # And this would set the file pointer 68 bytes from end-of-file.

Which is the same result.

> I don't see it making sense for "file.pos -= 100" to suddenly put you
> near the end of the file; it should either cap and put you at position
> 0, or do what file.seek(-100,1) would do and throw an exception.

I agree, but the language doesn't allow those semantics.

Also, what about the use of `f.seek(0, os.SEEK_END)` to seek to EOF?
I'm not certain what the use cases are, but a quick google reveals
that this does happen in real code.  If a pos of 0 means BOF, and a
pos of -1 means 1 byte before EOF, then how do you seek to EOF without
knowing the file length?

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

#30024

Am 25.09.2012 00:37 schrieb Ian Kelly:
> On Mon, Sep 24, 2012 at 4:14 PM, Chris Angelico<rosuav@gmail.com>  wrote:
>> file.pos = 42 # Okay, you're at position 42
>> file.pos -= 10 # That should put you at position 32
>> foo = file.pos # Presumably foo is the integer 32
>> file.pos -= 100 # What should this do?
>
> Since ints are immutable, the language specifies that it should be the
> equivalent of "file.pos = file.pos - 100", so it should set the file
> pointer to 68 bytes before EOF.

But this is not a "real int", it has a special use. So I don't think it 
is absolutely required to behave like an int.

This reminds me of some special purpose registers in embedded 
programming, where bits can only be set by hardware and are cleared by 
the application by writing 1 to them.

Or some bit setting registers, like on ATxmega: OUT = 0x10 sets bit 7 
and clears all others, OUTSET = 0x10 only sets bit 7, OUTTGL = 0x10 
toggles it and OUTCLR = 0x10 clears it.

If this behaviour is documented properly enough, it is quite OK, IMHO.


Thomas

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

#30042

On Tue, 25 Sep 2012 07:32:31 +0200, Thomas Rachel
<nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de>
declaimed the following in gmane.comp.python.general:

> Or some bit setting registers, like on ATxmega: OUT = 0x10 sets bit 7 
> and clears all others, OUTSET = 0x10 only sets bit 7, OUTTGL = 0x10 
> toggles it and OUTCLR = 0x10 clears it.
> 
> If this behaviour is documented properly enough, it is quite OK, IMHO.
>
	I don't think I'd want to work with any device where 0x10 (00010000
binary) modifies bit SEVEN. 0x40, OTOH, would fit my mental impression
of bit 7.

	It doesn't even fit my mind if the value is suppose to be the /bit
number/ unless the device considers "bit 7" to be the EIGHTH bit (that
is, the LSB is considered bit 1, not bit 0)
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#30068

Am 25.09.2012 10:13 schrieb Dennis Lee Bieber:
>> Or some bit setting registers, like on ATxmega: OUT = 0x10 sets bit 7
>> and clears all others, OUTSET = 0x10 only sets bit 7, OUTTGL = 0x10
>> toggles it and OUTCLR = 0x10 clears it.

Umpfzg. s/bit 7/bit 4/.

> 	I don't think I'd want to work with any device where 0x10 (00010000
> binary) modifies bit SEVEN. 0x40, OTOH, would fit my mental impression
> of bit 7.

Of course. My fault.

It can as well be a bit mask, with OUTTGL = 0x11 toggling bit 4 and bit 
0. Very handy sometimes.


Thomas

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

#30053

On Mon, Sep 24, 2012 at 11:32 PM, Thomas Rachel
<nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de>
wrote:
> Am 25.09.2012 00:37 schrieb Ian Kelly:
>> Since ints are immutable, the language specifies that it should be the
>> equivalent of "file.pos = file.pos - 100", so it should set the file
>> pointer to 68 bytes before EOF.
>
>
> But this is not a "real int", it has a special use. So I don't think it is
> absolutely required to behave like an int.

The point of the proposal was to simplify the API.  With that in mind,
if it's supposed to look like an int, then it should *be* an int.

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

#29951

On Tue, Sep 25, 2012 at 8:37 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Mon, Sep 24, 2012 at 4:14 PM, Chris Angelico <rosuav@gmail.com> wrote:
>> file.pos = 42 # Okay, you're at position 42
>> file.pos -= 10 # That should put you at position 32
>> foo = file.pos # Presumably foo is the integer 32
>> file.pos -= 100 # What should this do?
>
> Since ints are immutable, the language specifies that it should be the
> equivalent of "file.pos = file.pos - 100", so it should set the file
> pointer to 68 bytes before EOF.

Oh, I forgot that guaranteed equivalency. Well, at least it removes
the ambiguity. I don't like it though.

ChrisA

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

#29955

On 24/09/2012 22:35, zipher wrote:
> For some time now, I've wanted to suggest a better abstraction for the <file> type in Python.  It currently uses an antiquated C-style interface for moving around in a file, with methods like tell() and seek().  But after attributes were introduced to Python, it seems it should be re-addressed.
>
> Let file-type have an attribute .pos for position.   Now you can get rid of the seek() and tell() methods and manipulate the file pointer more easily with standard arithmetic operations.
>
>>>> file.pos = x0ae1      #move file pointer to an absolute address
>>>> file.pos +=1            #increment the file pointer one byte
>>>> curr_pos = file.pos  #read current file pointer
>
> You've now simplified the API by the removal of two obscure legacy methods and replaced them with a more basic one called "position".
>
> Thoughts?
>
> markj
>

This strikes me as being a case of if it ain't broke don't fix it.

-- 
Cheers.

Mark Lawrence.

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

#29957

On Mon, Sep 24, 2012 at 3:37 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Mon, Sep 24, 2012 at 4:14 PM, Chris Angelico <rosuav@gmail.com> wrote:
>> file.pos = 42 # Okay, you're at position 42
>> file.pos -= 10 # That should put you at position 32
>> foo = file.pos # Presumably foo is the integer 32
>> file.pos -= 100 # What should this do?
>
> Since ints are immutable, the language specifies that it should be the
> equivalent of "file.pos = file.pos - 100", so it should set the file
> pointer to 68 bytes before EOF.

There is no reason that it has to be an int object, however. It could
well return a "FilePosition" object which does not allow subtraction
to produce a negative result. Not saying its a good idea... Similarly,
it could be a more complex object with properties on it to determine
whether to seek from beginning or end.

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

#30550

On Tuesday, 25 September 2012 03:05:16 UTC+5:30, zipher  wrote:
> For some time now, I've wanted to suggest a better abstraction for the <file> type in Python.  It currently uses an antiquated C-style interface for moving around in a file, with methods like tell() and seek().  But after attributes were introduced to Python, it seems it should be re-addressed.
> 
> 
> 
> Let file-type have an attribute .pos for position.   Now you can get rid of the seek() and tell() methods and manipulate the file pointer more easily with standard arithmetic operations. 
> 
> 
> 
> >>> file.pos = x0ae1      #move file pointer to an absolute address 
> 
> >>> file.pos +=1            #increment the file pointer one byte
> 
> >>> curr_pos = file.pos  #read current file pointer
> 
> 
> 
> You've now simplified the API by the removal of two obscure legacy methods and replaced them with a more basic one called "position".
> 
> 
> 
> Thoughts?
> 
> 
> 
> markj

+1

[toc] | [prev] | [standalone]

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

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

csiph-web