On Sun, 2005-12-25 at 20:38 -0800, Aahz wrote:
> Guido sez in
> http://mail.python.org/pipermail/python-dev/2004-July/045921.html
> that it is not correct to recommend using ``file()`` instead of
> ``open()``. However, because ``open()`` currently *is* an alias to
> ``file()``, we end up with the
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>>> Here's a rough draft:
>>>
>>>def textopen(name, mode="r", encoding=None):
>>>if "U" not in mode:
>>>mode += "U"
>>
>> The "U" is not needed when opening files using codecs -
>> these always break lines using .splitlines() whi
M.-A. Lemburg wrote:
>>Here's a rough draft:
>>
>>def textopen(name, mode="r", encoding=None):
>>if "U" not in mode:
>>mode += "U"
>
>
> The "U" is not needed when opening files using codecs -
> these always break lines using .splitlines() which
> breaks lines according to
Phillip J. Eby wrote:
> At 04:20 PM 12/27/2005 +0100, M.-A. Lemburg wrote:
>> Phillip J. Eby wrote:
>> > At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote:
>> >> M.-A. Lemburg wrote:
>> >>
>> can we add a opentext factory for file/codecs.open while we're at
>> it ?
>> >>> Why a new factory fun
Phillip J. Eby wrote:
> >but that was made at a time when it wasn't clear if "open" or "file" would
> >be the preferred way to open a file. now that we've settled on the verb
> >form, I think "textopen" or "opentext" would be slightly more consistent.
>
> Sorry, I'm confused. Who settled on the
At 04:37 PM 12/27/2005 +0100, Fredrik Lundh wrote:
>but that was made at a time when it wasn't clear if "open" or "file" would
>be the preferred way to open a file. now that we've settled on the verb
>form, I think "textopen" or "opentext" would be slightly more consistent.
Sorry, I'm confused.
Phillip J. Eby wrote:
> >Here's a rough draft:
> >
> > def textopen(name, mode="r", encoding=None):
> > if "U" not in mode:
> > mode += "U"
> > if encoding:
> > return codecs.open(name, mode, encoding)
> > return file(name, mode)
>
> Nice. It sho
At 04:20 PM 12/27/2005 +0100, M.-A. Lemburg wrote:
>Phillip J. Eby wrote:
> > At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote:
> >> M.-A. Lemburg wrote:
> >>
> can we add a opentext factory for file/codecs.open while we're at it ?
> >>> Why a new factory function ? Can't we just redirect to
Phillip J. Eby wrote:
> At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote:
>> M.-A. Lemburg wrote:
>>
can we add a opentext factory for file/codecs.open while we're at it ?
>>> Why a new factory function ? Can't we just redirect to codecs.open()
>>> in case an encoding keyword argument is pass
At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote:
>M.-A. Lemburg wrote:
>
> >> can we add a opentext factory for file/codecs.open while we're at it ?
> >
> > Why a new factory function ? Can't we just redirect to codecs.open()
> > in case an encoding keyword argument is passed to open() ?!
>
>I th
Fredrik Lundh wrote:
> M.-A. Lemburg wrote:
>
>>> can we add a opentext factory for file/codecs.open while we're at it ?
>> Why a new factory function ? Can't we just redirect to codecs.open()
>> in case an encoding keyword argument is passed to open() ?!
>
> I think open is overloaded enough as
M.-A. Lemburg wrote:
>> can we add a opentext factory for file/codecs.open while we're at it ?
>
> Why a new factory function ? Can't we just redirect to codecs.open()
> in case an encoding keyword argument is passed to open() ?!
I think open is overloaded enough as it is. Using separate functio
Fredrik Lundh wrote:
> Aahz wrote:
>
>> class file(object)
>> | file(name[, mode[, buffering]]) -> file object
>> |
>> | Open a file. The mode can be 'r', 'w' or 'a' for reading (default),
>> [...]
>> | Note: open() is an alias for file().
>>
>> This is confusing. I suggest that we make ``op
Aahz wrote:
> class file(object)
> | file(name[, mode[, buffering]]) -> file object
> |
> | Open a file. The mode can be 'r', 'w' or 'a' for reading (default),
> [...]
> | Note: open() is an alias for file().
>
> This is confusing. I suggest that we make ``open()`` a factory function
> right
14 matches
Mail list logo
