> 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
> reason to change this. OK, not *you* because of your BDFL powers ;), but
> anyone else would surely have to face great opposition.note that this is about *writing* files, not reading. You would be surprised how much of the software have already taken care to be cross-platform (ie twisted, django, pylons, ...), not to rely on that and be able to run on any other python implementation. > > 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 regularly see people *happy* about it. > > 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 future when this would stop working in CPython. I > would strongly prefer that CPython would settle on (= document) using > reference counting and immediate destruction so that people can stop > making their everyday code more complex with no benefit. You will be > losing no more than an open door that nobody has entered in 20 years, > and people would only benefit from it. someone said at some point "noone will ever need more than 650k of RAM". see what has happened. Cheers, fijal _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
