Raymond Hettinger wrote:
> It's a PITA because it precludes all of the use cases whether the
> inputs ARE intentionally of different length (like when one argument
> supplys an infinite iterator):
>
>for lineno, ts, line in zip(count(1), timestamp(), sys.stdin):
>print 'Line %d, Time %
On 9/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
In this particular case I don't care what's simpler to implement, butwhat's most likely to do what the user expects. If on a particular boxmost files are encoded in encoding X, and the user did whatever isnecessary to tell the tools that that's
On 9/5/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> On 9/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > In this particular case I don't care what's simpler to implement, but
> > what's most likely to do what the user expects.
Good.
> But now Europeans are just as likely to use UTF-8 as a
On 9/5/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> Beyond all of that: It just seems wrong to me that I could send someone a
> bunch of files and a Python program and their results processing them would
> be different from mine, despite the fact that we run the same version of
> Python on the sam
Giovanni Bajo wrote:
> Raymond Hettinger wrote:
>
>> It's a PITA because it precludes all of the use cases whether the
>> inputs ARE intentionally of different length (like when one argument
>> supplys an infinite iterator):
>>
>>for lineno, ts, line in zip(count(1), timestamp(), sys.stdin):
>
Guido van Rossum wrote:
> And it seems just as wrong if Python doesn't do what the user expects.
> If I were a beginning Python user, I'd hate it if I had prepared a
> simple data file in vi or notepad and my Python program wouldn't read
> it right because Python's idea of encoding differs from my
On 9/5/06, Brian Quinlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > And it seems just as wrong if Python doesn't do what the user expects.
> > If I were a beginning Python user, I'd hate it if I had prepared a
> > simple data file in vi or notepad and my Python program wouldn't read
>
On 9/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 9/5/06, Paul Prescod <[EMAIL PROTECTED]> wrote:> Beyond all of that: It just seems wrong to me that I could send someone a> bunch of files and a Python program and their results processing them would
> be different from mine, despite the fac
On 9/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> So, for me and users> like me, Python is going to silently misinterpret my data.Not to any greater extent than Notepad or whatever other tool you are using.Yes. Unicode was invented in large part because people got sick of crappy tools that s
I have no desire to continue this discussion in every detail. I
believe we've both made our point, eloquently enough. The designers of
the I/O library will have to come up with the specific rules for
deciding on the default encoding. The only thing I'm saying is that
hardcoding the default encoding
[EMAIL PROTECTED] wrote:
> Here is a quick status of the int_unification branch,
> summarizing what I did at the Google sprint in NYC.
>
> - the int type has been dropped; the builtins int and long
> now both refer to long type
> - all PyInt_* API is forwarded to the PyLong_* API. Little
> cha
On 9/5/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> What impact is this long/int unification going to have on C-based
> sub-types of the old int-type? Will you be able to sub-class the
> integer-type in C without carrying around all the extra backage of the
> Python long?
This seems unlikely
On 9/5/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > On 9/5/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> >
> >> What impact is this long/int unification going to have on C-based
> >> sub-types of the old int-type? Will you be able to sub-class the
> >> integer-
Guido van Rossum wrote:
> On 9/5/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>> What impact is this long/int unification going to have on C-based
>> sub-types of the old int-type? Will you be able to sub-class the
>> integer-type in C without carrying around all the extra backage of the
>> P
Guido van Rossum wrote:
> On 9/5/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
>
>> Beyond all of that: It just seems wrong to me that I could send someone a
>> bunch of files and a Python program and their results processing them
>> would be different from mine, despite the fact that we run the sam
David Hopwood wrote:
> I don't know about vi, but notepad will open and save files that are not in
> the system ("ANSI") encoding just fine. On opening it checks for a BOM and
> auto-detects UTF-8 and UTF-16; on saving it will write a BOM if you choose
> "Unicode" (UTF-16LE), "Unicode big-endian" (
On 9/5/06, David Hopwood <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 9/5/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> >
> >> Beyond all of that: It just seems wrong to me that I could send someone a
> >> bunch of files and a Python program and their results processing them
> >> wou
Guido van Rossum wrote:
> On 9/5/06, Brian Quinlan <[EMAIL PROTECTED]> wrote:
> [...]
>
> That would not be doing what the user wants. We have extensive
> experience with defaulting to ASCII in Python 2.x and it's mostly bad.
> There should definitely be a way to force ASCII as the default
> encod
On 9/4/06, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 03, 2006 at 01:45:28PM -0700, Aahz wrote:
> > On Sun, Sep 03, 2006, Marcin 'Qrczak' Kowalczyk wrote:
> > > "tomer filiba" <[EMAIL PROTECTED]> writes:
> > >>
> > >> file("foo", "w+") ?
> > >
> > > What is a rationale of this operatio
Guido van Rossum wrote:
> On 9/5/06, David Hopwood <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > On 9/5/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
>> >
>> >> Beyond all of that: It just seems wrong to me that I could send
>> >> someone a bunch of files and a Python program and their r
On 9/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 9/5/06, David Hopwood <[EMAIL PROTECTED]> wrote:> Guido van Rossum wrote:> > On 9/5/06, Paul Prescod <
[EMAIL PROTECTED]> wrote:> >> >> Beyond all of that: It just seems wrong to me that I could send someone a> >> bunch of files and a Python
On 9/5/06, David Hopwood <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:> On 9/5/06, Brian Quinlan <[EMAIL PROTECTED]> wrote:> [...]>> That would not be doing what the user wants. We have extensive
> experience with defaulting to ASCII in Python 2.x and it's mostly bad.> There should definitely
Paul Prescod wrote:
> On 9/5/06, David Hopwood <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > On 9/5/06, Brian Quinlan <[EMAIL PROTECTED]> wrote:
>> > [...]
>> >
>> > That would not be doing what the user wants. We have extensive
>> > experience with defaulting to ASCII in Python 2.x an
David Hopwood <[EMAIL PROTECTED]> writes:
> The whole idea of a default encoding is flawed. Ideally there would be
> no default; programmers should be forced to think about the issue
> on a case-by-case basis. In some cases they might choose to open a file
> with the system encoding, but that shou
24 matches
Mail list logo
