Guido van Rossum wrote:
On Fri, Jan 23, 2009 at 12:52 PM, Terry Reedy wrote:
While a strong argument can be made that the remaining 2.x versions should
not be changed, they do not apply to 3.x. New code and ported old code
should use 'with' wherever quick closing needs to be guaranteed. The
On Fri, Jan 23, 2009 at 12:52 PM, Terry Reedy wrote:
> Giovanni Bajo wrote:
>>
>>> You are so very wrong, my son. CPython's implementation strategy
>>> *will* evolve. Several groups are hard at work trying to make a faster
>>> Python interpreter, and when they succeed, everyone, including you,
>>>
Giovanni Bajo wrote:
You are so very wrong, my son. CPython's implementation strategy
*will* evolve. Several groups are hard at work trying to make a faster
Python interpreter, and when they succeed, everyone, including you,
will want to use their version (or their version may simply *be* the
n
Giovanni Bajo wrote:
> On 1/23/2009 4:27 PM, Guido van Rossum wrote:
>> On Fri, Jan 23, 2009 at 2:57 AM, Giovanni Bajo wrote:
>>> I miss to understand why many Python developers are so fierce in trying
>>> to push the idea of cross-python compatibility (which is something that
>>> does simply *not
Guido van Rossum python.org> writes:
>
> And, by the way, "for line in open(filename): ..." will continue to
> work. It may just not close the file right away. This is a forgivable
> sin in a small program that opens a few files only. It only becomes a
> program when this is itself inside a loop
On 1/23/2009 4:27 PM, Guido van Rossum wrote:
On Fri, Jan 23, 2009 at 2:57 AM, Giovanni Bajo wrote:
I miss to understand why many Python developers are so fierce in trying
to push the idea of cross-python compatibility (which is something that
does simply *not* exist in real world for applicati
On Fri, Jan 23, 2009 at 2:57 AM, Giovanni Bajo wrote:
> I miss to understand why many Python developers are so fierce in trying
> to push the idea of cross-python compatibility (which is something that
> does simply *not* exist in real world for applications) or to warn about
> rainy days in the f
On Fri, 23 Jan 2009 at 11:57, Giovanni Bajo wrote:
The fact that file objects are collected and closed immediately in all
reasonable use cases (and even in case of exceptions, that you mention,
things get even better with the new semantic of the except clause) is a
*good* property of Python. I re
> That would be break so much code that I doubt that, in practice, you can
> slip it through within a release. Besides, being able to write simpler
> code like "for L in open("foo.txt")" is per-se a good reason *not to*
> put file objects in cycles; so you will probably need more than one good
> re
Giovanni Bajo develer.com> writes:
>
> The fact that file objects are collected and closed immediately in all
> reasonable use cases (and even in case of exceptions, that you mention,
> things get even better with the new semantic of the except clause)
The new except clause removes any external
Giovanni Bajo wrote:
> On gio, 2009-01-22 at 18:42 -0800, Guido van Rossum wrote:
[...]
> I miss to understand why many Python developers are so fierce in trying
> to push the idea of cross-python compatibility (which is something that
> does simply *not* exist in real world for applications) or to
On gio, 2009-01-22 at 18:42 -0800, Guido van Rossum wrote:
> On Thu, Jan 22, 2009 at 5:22 PM, Giovanni Bajo wrote:
> > CPython will always use reference counting and thus have a simple and
> > clear GC criteria that can be exploited to simplify the code.
>
> Believe this at your own peril.
>
> O
On Thu, Jan 22, 2009 at 5:22 PM, Giovanni Bajo wrote:
> CPython will always use reference counting and thus have a simple and
> clear GC criteria that can be exploited to simplify the code.
Believe this at your own peril.
Once, CPython didn't have GC at all (apart from refcounting). Now it
does.
Giovanni Bajo wrote:
> On Mon, 19 Jan 2009 01:38:18 +, Gregory P. Smith wrote:
>
>> I regularly point out in code reviews that the very convenient and
>> common idiom of open(name, 'w').write(data) doesn't guarantee when the
>> file will be closed; its up to the GC implementation details.
>
On Thu, Jan 22, 2009 at 5:22 PM, Giovanni Bajo wrote:
> On Mon, 19 Jan 2009 01:38:18 +, Gregory P. Smith wrote:
>
>> I regularly point out in code reviews that the very convenient and
>> common idiom of open(name, 'w').write(data) doesn't guarantee when the
>> file will be closed; its up to th
On Mon, 19 Jan 2009 01:38:18 +, Gregory P. Smith wrote:
> I regularly point out in code reviews that the very convenient and
> common idiom of open(name, 'w').write(data) doesn't guarantee when the
> file will be closed; its up to the GC implementation details.
Which, to me, sounds like "ple
On Sun, Jan 18, 2009 at 11:49 PM, Adam Olsen wrote:
> On Sun, Jan 18, 2009 at 9:32 PM, Guido van Rossum wrote:
>> On Sun, Jan 18, 2009 at 5:38 PM, Gregory P. Smith wrote:
>>> +1 on getting rid of the IOBase __del__ in the C rewrite in favor of
>>> tp_dealloc.
>>>
>>> On Sun, Jan 18, 2009 at 11:5
On Sun, Jan 18, 2009 at 9:32 PM, Guido van Rossum wrote:
> On Sun, Jan 18, 2009 at 5:38 PM, Gregory P. Smith wrote:
>> +1 on getting rid of the IOBase __del__ in the C rewrite in favor of
>> tp_dealloc.
>>
>> On Sun, Jan 18, 2009 at 11:53 PM, Christian Heimes wrote:
>>>
>>> Brett Cannon schrieb:
On Sun, Jan 18, 2009 at 5:38 PM, Gregory P. Smith wrote:
> +1 on getting rid of the IOBase __del__ in the C rewrite in favor of
> tp_dealloc.
>
> On Sun, Jan 18, 2009 at 11:53 PM, Christian Heimes wrote:
>>
>> Brett Cannon schrieb:
>> > Fine by me. People should be using the context manager for g
+1 on getting rid of the IOBase __del__ in the C rewrite in favor of
tp_dealloc.
On Sun, Jan 18, 2009 at 11:53 PM, Christian Heimes wrote:
> Brett Cannon schrieb:
> > Fine by me. People should be using the context manager for guaranteed
> > file closure anyway IMO.
>
Yes they should. (how I re
Brett Cannon schrieb:
> Fine by me. People should be using the context manager for guaranteed
> file closure anyway IMO.
You make a very good point! Perhaps we should stop promising that files
get closed as soon as possible and encourage people in using the with
statement.
Christian
On Sun, Jan 18, 2009 at 15:03, Antoine Pitrou wrote:
> Dear python-dev,
>
> The Python implementation of IOBase, the base class for everything IO, has the
> (strange) idea to define a __del__ method. It is probably meant to avoid code
> duplication, so that users subclassing IOBase automatically g
Dear python-dev,
The Python implementation of IOBase, the base class for everything IO, has the
(strange) idea to define a __del__ method. It is probably meant to avoid code
duplication, so that users subclassing IOBase automatically get the
close-on-destruct behaviour.
(there is an even stranger
23 matches
Mail list logo
