On Wed, Aug 8, 2018 at 12:28 PM Paul Moore wrote:
>
> On Wed, 8 Aug 2018 at 16:58, Oscar Benjamin
> wrote:
> > Thinking about this some more: closing() can ensure finalisation but
> > it is still generally bad to yield from a with block. Some context
> > managers are designed to temporarily alte
On Wed, 8 Aug 2018 at 16:58, Oscar Benjamin wrote:
> Thinking about this some more: closing() can ensure finalisation but
> it is still generally bad to yield from a with block. Some context
> managers are designed to temporarily alter global state between
> __enter__ and __exit__ - this can be ve
On 08/08/18 16:55, Oscar Benjamin wrote:
Thinking about this some more: closing() can ensure finalisation but
it is still generally bad to yield from a with block. Some context
managers are designed to temporarily alter global state between
__enter__ and __exit__ - this can be very confusing if y
Ronald Oussoren via Python-ideas wrote:
> It is also possible to fix the particular issue by using another with
> statement, that is use:
>
> with contextlib.closing(read_multiple(…)) as chunks:
>for contents in chunks:
>…
>
> Automatically closing the generator at the end of the for
On 8 August 2018 at 15:37, Oscar Benjamin wrote:
> On 8 August 2018 at 15:22, Ronald Oussoren via Python-ideas
> wrote:
>>
>> It is also possible to fix the particular issue by using another with
>> statement, that is use:
>>
>> with contextlib.closing(read_multiple(…)) as chunks:
>>for cont
On 8 August 2018 at 15:22, Ronald Oussoren via Python-ideas
wrote:
>>
>> On 08/08/18 07:14, Ken Hilton wrote:
>>> Now, let's take a look at the following scenario:
>>> def read_multiple(*filenames):
>>> for filename in filenames:
>>> with open(filename) as f:
>>>
On Wed, Aug 8, 2018 at 10:32 PM, Oscar Benjamin
wrote:
> Without the context manager you could write:
>
> def read_multiple(*filenames):
> for filename in filenames:
> f = open(filename)
> yield f.read()
> f.close()
>
> Which also only leaks one file
On Tue, Aug 07, 2018 at 11:31:35PM -0700, Elazar wrote:
> Instead of disallowing code, this is a case for allowing with expressions:
Only if you accept Ken's conclusion, that yielding inside a with
statement is harmful (I don't). And if you do accept Ken's conclusion,
then with-expressions don'
> On 8 Aug 2018, at 14:35, Rhodri James wrote:
>
> On 08/08/18 07:14, Ken Hilton wrote:
>> Now, let's take a look at the following scenario:
>> def read_multiple(*filenames):
>> for filename in filenames:
>> with open(filename) as f:
>> yield f.read()
>>
On 08/08/18 07:14, Ken Hilton wrote:
Now, let's take a look at the following scenario:
def read_multiple(*filenames):
for filename in filenames:
with open(filename) as f:
yield f.read()
Can you spot the problem? The "with open(filename)" statement is
On 8 August 2018 at 07:32, Chris Angelico wrote:
> On Wed, Aug 8, 2018 at 4:14 PM, Ken Hilton wrote:
>>
>> Now, let's take a look at the following scenario:
>>
>> def read_multiple(*filenames):
>> for filename in filenames:
>> with open(filename) as f:
>> y
On 8 August 2018 at 08:48, Nathaniel Smith wrote:
> On Tue, Aug 7, 2018 at 11:14 PM, Ken Hilton wrote:
>>
>> Now, let's take a look at the following scenario:
>>
>> def read_multiple(*filenames):
>> for filename in filenames:
>> with open(filename) as f:
>>
Ken Hilton writes:
> Can you spot the problem? The "with open(filename)" statement is supposed
> to ensure that the file object is disposed of properly. However, the "yield
> f.read()" statement suspends execution within the with block, so if this
> happened:
>
> for contents in read_mu
On Tue, Aug 7, 2018 at 11:14 PM, Ken Hilton wrote:
> This mostly springs off of a comment I saw in some thread.
>
> The point of a with statement is that it ensures that some resource will be
> disposed of, yes? For example, this:
>
> with open(filename) as f:
> contents = f.read()
>
>
On Wed, Aug 8, 2018 at 5:05 PM, Barry Scott wrote:
> But so long as you do not leak the generator the file will be closed
> immediately after the loop as the ref count of the generater hits 0.
Technically that's not guaranteed (since refcounts aren't a language
feature), but if you're using this
On Wednesday, 8 August 2018 07:14:47 BST Ken Hilton wrote:
> Now, let's take a look at the following scenario:
>
> def read_multiple(*filenames):
> for filename in filenames:
> with open(filename) as f:
> yield f.read()
In this particular case you can fix t
I don't think this is a major problem. In this case, the file will be
closed when the generator is garbage collected. So you'd also have to
leak the generator to actually get this problem. And if leaking
generators won't harm your application, neither will leaking the
occasional file handle.
Also,
On Wed, Aug 8, 2018 at 4:14 PM, Ken Hilton wrote:
> This mostly springs off of a comment I saw in some thread.
>
> The point of a with statement is that it ensures that some resource will be
> disposed of, yes? For example, this:
>
> with open(filename) as f:
> contents = f.read()
>
>
On Tue, Aug 7, 2018 at 11:16 PM Ken Hilton wrote:
> ...
> Now, let's take a look at the following scenario:
>
> def read_multiple(*filenames):
> for filename in filenames:
> with open(filename) as f:
> yield f.read()
>
> Can you spot the problem? The "with
i think a SyntaxError won't be appropriate as it is valid syntax as the
lexer finds nothing wrong
it falls more i think like out of index errors and the like, a
ContextManagerError ?
else, a request to add headings like
EXAMPLES
=
in your discussion
yours,
--
Abdur-Rahmaan Janhangeer
This mostly springs off of a comment I saw in some thread.
The point of a with statement is that it ensures that some resource will be
disposed of, yes? For example, this:
with open(filename) as f:
contents = f.read()
is better than this:
contents = open(filename).read()
becaus
21 matches
Mail list logo
