Greg Ewing wrote:
> The best you could do would be to return some kind
> of opaque object from tell() that could be passed
> back to seek().
that's how seek/tell works on text files in today's Python, of course.
if you're writing portable code, you can only seek to the beginning or
end of the f
tomer filiba wrote:
> my solution would be completely leaving seek() and tell() out of the
> 3rd layer -- it's a byte-level operation.
>
> anyone thinks differently? if so, what's your solution?
seek and tell are a poor mans sequence. I would have nothing by those
names.
I would have input s
> FileReader would be an InputStream,
> FileWriter would be an OutputStream
yes, this has been discussed, but that's too java-ish by nature.
besides, how would this model handle a simple operation, such as
file("foo", "w+") ?
opening TWO file descriptors for that purpose, one for reading and
anot
"tomer filiba" <[EMAIL PROTECTED]> writes:
>> FileReader would be an InputStream,
>> FileWriter would be an OutputStream
>
> yes, this has been discussed, but that's too java-ish by nature.
> besides, how would this model handle a simple operation, such as
> file("foo", "w+") ?
What is a rational
On Sun, Sep 03, 2006, Marcin 'Qrczak' Kowalczyk wrote:
> "tomer filiba" <[EMAIL PROTECTED]> writes:
>>
>> file("foo", "w+") ?
>
> What is a rationale of this operation for a text file?
You want to be able to read the file and write data to it. That argues
in favor of seek(0) and seek(-1) being t
tomer filiba wrote:
>> FileReader would be an InputStream,
>> FileWriter would be an OutputStream
>
> yes, this has been discussed, but that's too java-ish by nature.
> besides, how would this model handle a simple operation, such as
> file("foo", "w+") ?
You mean, with the intent of both re
Anders J. Munch wrote:
> Watch out! There's an essentiel difference between files and
> bidirectional communications channels that you need to take into
> account. For a TCP connection, input and output can be seen as
> isolated from one another, with each their own stream position, and
> each t
Brett Cannon wrote:
> Basically. Memory usage goes up if you do this as it stands now.
I'm not sure I follow that. The traceback gets created anyway,
so how is it going to use more memory if it's attached to a
throwaway exception instead of kept in a sys variable?
If you keep the exception arou
On 9/3/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> Basically. Memory usage goes up if you do this as it stands now.I'm not sure I follow that. The traceback gets created anyway,so how is it going to use more memory if it's attached to a
throwaway exception instead of kept in a s
On 9/1/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
> > today's Python supports "locale aware" 8-bit strings ...
> > to what extent should this be supported by Python 3000 ?
> Since all strings will be Unicode by then:
> >>> u"åäö".isalpha()
> True
Two followup questions,
Fredrik Lundh wrote:
> that's how seek/tell works on text files in today's Python, of course.
> if you're writing portable code, you can only seek to the beginning or
> end of the file, or to a position returned to you by tell.
True, but with arbitrary stacks of stream-transforming
objects the
On 9/3/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 9/3/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > The traceback gets created anyway, so how
> > is it going to use more memory if it's attached to a
> > throwaway exception instead of kept in a sys variable?
> > ... how often are exceptions
On 9/3/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
On 9/1/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:> Fredrik Lundh wrote:> > today's Python supports "locale aware" 8-bit strings ...> > to what extent should this be supported by Python 3000 ?
> Since all strings will be Unicode by then:> >>> u"åäö"
On 9/3/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 9/1/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > Fredrik Lundh wrote:
> > > today's Python supports "locale aware" 8-bit strings ...
> > > to what extent should this be supported by Python 3000 ?
>
> > Since all strings will be Unicode by the
On 9/3/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/3/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > (2) To what extent will strings have an opaque
> > (or at least on-demand) backing store, so that
> > decoding/encoding could be delayed?
> That seems to be a bit of a leading question.
15 matches
Mail list logo
