On 30/07/18 21:15, Rudy Matela wrote:
> Hello,
>
> Do you think it would be nice to allow with statements inside genexps or
> list comprehensions? The functions __enter__ and __exit__ would be
> automatically called as iterables are traversed. I am thinking of
> drafting a PEP about this. Examp
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 07/08/18 22:57, Victor Porton wrote:
This is an idea of a new PEP.
I propose to create a portable file format which will list command line
options to run Python scripts with dual purpose:
You are going about this the wrong way. If you want IDE-makers to use
your putative file format, you
Hi Victor
Thank you for your contribution, regarding standards for Python tools.
Here is my two cents worth.
You wrote:
> We need a standard to make PyCharm and others to conform to it.
Things don't quite work that way, in the Python community. True, we
have a Benevolent Dictator For Life (BDFL)
On 08/08/18 12:25, Barry Scott wrote:
On Tuesday, 7 August 2018 22:57:51 BST Victor Porton wrote:
This is an idea of a new PEP.
I propose to create a portable file format which will list command line
options to run Python scripts with dual purpose:
At the moment I solve this problem with vario
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:
>>
On Tuesday, 7 August 2018 22:57:51 BST Victor Porton wrote:
> This is an idea of a new PEP.
>
> I propose to create a portable file format which will list command line
> options to run Python scripts with dual purpose:
At the moment I solve this problem with various solutions, depending on
requi
On Wed, 8 Aug 2018 at 00:35, Victor Porton wrote:
>
> > But I see no reason why this has anything to do with the Python standard
> > library. Can you explain why you want to distribute an experimental
> > file format in the Python std lib?
>
> As I pointed out, I want this format to become common
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
22 matches
Mail list logo
