Le jeudi 07 septembre 2006 à 16:33 -0700, Guido van Rossum a écrit :
> Why not use tell() and seek() instead of get_pointer() and
> set_pointer()? Seek should also support several special cases:
> f.seek(0) seeks to the start of the file no matter what type is
> otherwise used for pointers ("seek c
Le jeudi 07 septembre 2006 à 15:41 -0700, Paul Prescod a écrit :
> Are you plugged into the Mandriva community?
Not much. I only participe in bug reports ;)
> Is there any debate about the continued use of iso8859-15?
I think there has been some for years. Some people in the community push
for
On 08/09/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
Perhaps it would be good to drop those magic numbers (0, 1, 2) forseek() ? They don't really help readibility except perhaps for peoplewho still do a lot of C ;)+1If we can't don't want to eliminate the "magic numbers" entirely, perhaps we coul
> Why not use tell() and seek() instead of get_pointer() and
> set_pointer()?
because, at least the way i see it, seek and tell are byte-oriented,
while the upper layers of the stack may be objects-oriented
(including, for instance, characters, struct records, or pickled objects),
so pointers woul
"tomer filiba" <[EMAIL PROTECTED]> writes:
> yes, this was discussed some time ago. we concluded that the new
> position property should behave similar to negative indexes:
>
> f.position = 5 -- absolute seek, from the beginning of the stream
> f.position += 3 -- relative seek (*)
> f.position
[Guido]
>> Why not use tell() and seek() instead of get_pointer() and
>> set_pointer()?
[tomer]
> because, at least the way i see it, seek and tell are byte-oriented,
> while the upper layers of the stack may be objects-oriented
> (including, for instance, characters, struct records, or pickled ob
On Fri, 8 Sep 2006 00:26:55 -0700, Hasan Diwan <[EMAIL PROTECTED]> wrote:
>On 08/09/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>>
>>Perhaps it would be good to drop those magic numbers (0, 1, 2) for
>>seek() ? They don't really help readibility except perhaps for people
>>who still do a lot of C
On Friday, September 08, 2006, at 02:30PM, Jean-Paul Calderone <[EMAIL
PROTECTED]> wrote:
>On Fri, 8 Sep 2006 00:26:55 -0700, Hasan Diwan <[EMAIL PROTECTED]> wrote:
>>On 08/09/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>>>
>>>Perhaps it would be good to drop those magic numbers (0, 1, 2) for
On Fri, 08 Sep 2006 15:37:00 +0200, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
>
>On Friday, September 08, 2006, at 02:30PM, Jean-Paul Calderone <[EMAIL
>PROTECTED]> wrote:
>>
>>Note that Python is _worse_ than C here. C has named constants for these,
>>Python does not expose them.
>
>What about
On Friday, September 08, 2006, at 03:41PM, Jean-Paul Calderone <[EMAIL
PROTECTED]> wrote:
>On Fri, 08 Sep 2006 15:37:00 +0200, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
>>
>>On Friday, September 08, 2006, at 02:30PM, Jean-Paul Calderone <[EMAIL
>>PROTECTED]> wrote:
>>>
>>>Note that Python is
On 9/8/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Le jeudi 07 septembre 2006 à 16:33 -0700, Guido van Rossum a écrit :
> > Why not use tell() and seek() instead of get_pointer() and
> > set_pointer()? Seek should also support several special cases:
> > f.seek(0) seeks to the start of the file
Marcin Kowalczyk writes:
> In my language the traceback is materialized from the stack only
> if needed [...] The stack is not
> physically unwound until an exception handler completes successfully,
> so the data is available until then.
Jim Jewett writes:
> Even today, if a StopIteration() partic
Guido van Rossum wrote:
> Maybe (since I fall in that category it doesn't bother me :-), but we
> shouldn't replace them with symbolic constants. Having to import
> another module to import names like SEEK_CUR and SEEK_END is not
> Pythonic. Perhaps the seek() method can grow keyword arguments to
>
Nick Coghlan wrote:
> Guido van Rossum wrote:
>> Maybe (since I fall in that category it doesn't bother me :-), but we
>> shouldn't replace them with symbolic constants. Having to import
>> another module to import names like SEEK_CUR and SEEK_END is not
>> Pythonic. Perhaps the seek() method can g
On Fri, Sep 08, 2006, Michael Chermside wrote:
>
>def logError(msg):
>try:
>errorChannel.write(msg)
>except IOError:
>pass
>
>try:
>callSomeCode()
>except SomeException as err:
>msg = str(msg)
>logError(msg)
>raise
On Friday 08 September 2006 13:00, Nick Coghlan wrote:
> As I mentioned in a different part of the thread, I believe seek(),
> seekby() and rseek() would work as names for the 3 different method
> approach.
+1, for the reasons discussed.
-Fred
--
Fred L. Drake, Jr.
-1 on those particular cryptic names. Which one of seekby() and
rseek() is the relative seek? Where's the seek relative to EOF?
On 9/8/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Friday 08 September 2006 13:00, Nick Coghlan wrote:
> > As I mentioned in a different part of the thread, I
Le vendredi 08 septembre 2006 à 11:06 -0700, Guido van Rossum a écrit :
> -1 on those particular cryptic names. Which one of seekby() and
> rseek() is the relative seek? Where's the seek relative to EOF?
What about seek(), seek_relative() and seek_reverse() ?
"rseek" also looks like "relative see
On 9/8/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Le vendredi 08 septembre 2006 à 11:06 -0700, Guido van Rossum a écrit :
> > -1 on those particular cryptic names. Which one of seekby() and
> > rseek() is the relative seek? Where's the seek relative to EOF?
> What about seek(), seek_relative(
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> -1 on those particular cryptic names. Which one of seekby() and
> rseek() is the relative seek? Where's the seek relative to EOF?
I propose seek, seek_by, seek_end.
I suppose in 99% of cases seek_end is used to seek to the very end,
rather than so
On Friday 08 September 2006 14:06, Guido van Rossum wrote:
> -1 on those particular cryptic names. Which one of seekby() and
> rseek() is the relative seek? Where's the seek relative to EOF?
My reading was seekby() as relative, and rseek() was relative to the end. It
could be something like se
Le vendredi 08 septembre 2006 à 15:04 -0400, Jim Jewett a écrit :
> > What about seek(), seek_relative() and seek_reverse() ?
>
> Why not just borrow the standard symbolic names of cur and end?
>
> seek(pos=0)
> seek_cur(pos=0)
> seek_end(pos=0)
You are right, it's clear and shorter
On Sat, Sep 09, 2006 at 12:24:10AM +0200, Antoine Pitrou wrote:
> Le vendredi 08 septembre 2006 ? 15:04 -0400, Jim Jewett a ?crit :
> > > What about seek(), seek_relative() and seek_reverse() ?
> >
> > Why not just borrow the standard symbolic names of cur and end?
> >
> > seek(pos=0)
> >
On 9/7/06, David Hopwood <[EMAIL PROTECTED]> wrote:
> Yes. However, this is not a good idea for precisely the reason described
> on that page (false detection of Unicode), and so any Unicode detection
> algorithm in Python should only be based on detecting a BOM, IMHO.
Right, except BOMs break ton
On 9/7/06, Jeff Wilcox <[EMAIL PROTECTED]> wrote:
> > From: "Paul Prescod" <[EMAIL PROTECTED]>
> > 1. On US English Windows, Notepad defaults to an encoding called "ANSI".
> > "ANSI" is not a real encoding at all (and certainly not one from the
> On Japanese Windows 2000, Notepad defaults to ANSI a
Jim Jewett wrote:
> On 9/8/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>> Le vendredi 08 septembre 2006 à 11:06 -0700, Guido van Rossum a écrit :
>>> -1 on those particular cryptic names. Which one of seekby() and
>>> rseek() is the relative seek? Where's the seek relative to EOF?
>
>> What abou
26 matches
Mail list logo
