On Nov 19, 2019, at 18:53, Oscar Benjamin wrote:
>
> On Wed, 20 Nov 2019 at 02:36, Richard Damon wrote:
>>
>> If I understand it right, an eager context manager (like open currently
>> is) allows itself to be used somewhat optionally, and not need to be in
>> a with statement. A lazy context m
On Wed, 20 Nov 2019 at 02:36, Richard Damon wrote:
>
> On 11/19/19 8:57 PM, Oscar Benjamin wrote:
> > On Tue, 19 Nov 2019 at 12:03, Paul Moore wrote:
> >> On Tue, 19 Nov 2019 at 11:34, Oscar Benjamin
> >> wrote:
> >>
> >>> If I was to propose anything here it would not be to disallow anything
>
On Nov 19, 2019, at 17:57, Oscar Benjamin wrote:
>
>
> Perhaps a less emotive way of distinguishing these classes of context
> managers would be as "eager" vs "lazy". An eager context manager jumps
> the gun and does whatever needs undoing or following up before its
> __enter__ method is called.
On 11/19/19 8:57 PM, Oscar Benjamin wrote:
> On Tue, 19 Nov 2019 at 12:03, Paul Moore wrote:
>> On Tue, 19 Nov 2019 at 11:34, Oscar Benjamin
>> wrote:
>>
>>> If I was to propose anything here it would not be to disallow anything
>>> that you can currently do with context managers. Rather the sug
On Tue, 19 Nov 2019 at 12:03, Paul Moore wrote:
>
> On Tue, 19 Nov 2019 at 11:34, Oscar Benjamin
> wrote:
>
> > If I was to propose anything here it would not be to disallow anything
> > that you can currently do with context managers. Rather the suggestion
> > would be to:
> > 1. Clearly define
On Nov 19, 2019, at 15:45, Greg Ewing wrote:
>
> On 20/11/19 12:14 pm, Andrew Barnert wrote:
>> Off the top of my head, there’s Smalltalk, which I suspect is where
>> Guido got the idea, and ObjC, which got it from Smalltalk, and Swift,
>> which got it from ObjC,
>
> I don't think Smalltalk/Obj
On 20/11/19 12:14 pm, Andrew Barnert wrote:
Off the top of my head, there’s Smalltalk, which I suspect is where
Guido got the idea, and ObjC, which got it from Smalltalk, and Swift,
which got it from ObjC,
I don't think Smalltalk/ObjC do quite the same thing. Sometimes you
see a pattern like
On Nov 19, 2019, at 14:30, Greg Ewing wrote:
>
> On 20/11/19 6:51 am, Andrew Barnert via Python-ideas wrote:
>> A class can bind attributes in __new__ and return a fully initialized
>> object. If that’s perfectly ok, why doesn’t every class do everything
>> in __new__, in which case there’s no r
On 20/11/19 6:51 am, Andrew Barnert via Python-ideas wrote:
A class can bind attributes in __new__ and return a fully initialized
object. If that’s perfectly ok, why doesn’t every class do everything
in __new__, in which case there’s no reason for __init__ to exist at
all?
If Python had been de
On 20/11/19 6:50 am, Soni L. wrote:
I still feel like opening the file but delaying the exception would be
more beneficial
That would break anything that tests for the existence of a file
by attempting to open it.
--
Greg
___
Python-ideas mailing lis
On Tuesday, November 19, 2019 at 3:06:26 PM UTC-5, Paul Moore wrote:
>
> On Tue, 19 Nov 2019 at 19:03, Random832 > wrote:
> >
> > On Tue, Nov 19, 2019, at 11:26, Paul Moore wrote:
> > > Because you don't have to create the context manager directly in the
> > > with statement
> >
> > ...wha
On Tue, 19 Nov 2019 at 19:03, Random832 wrote:
>
> On Tue, Nov 19, 2019, at 11:26, Paul Moore wrote:
> > Because you don't have to create the context manager directly in the
> > with statement
>
> ...what? that's *my* argument. that's *precisely* why I consider open to be
> 'misbehaving'. Because
On 19/11/2019 17:57, Andrew Barnert wrote:
On Nov 19, 2019, at 09:40, Rhodri James wrote:
How about using Paths as file context managers? Just an idle thought.
Then how do you open a Path for writing, or in binary mode, etc.?
With additional parameters and/or methods, obviously.
Adding
On Tue, Nov 19, 2019, at 11:26, Paul Moore wrote:
> Because you don't have to create the context manager directly in the
> with statement
...what? that's *my* argument. that's *precisely* why I consider open to be
'misbehaving'. Because you *should* be able to create a context manager outside
th
On 19/11/2019 17:50, Soni L. wrote:
On 2019-11-19 3:37 p.m., Rhodri James wrote:
On 19/11/2019 17:12, Brian Skinn wrote:
@jayvdb on GitHub and I are working on a new version of one of my
packages, stdio-mgr (https://github.com/bskinn/stdio-mgr), with a
dramatically expanded API and capabilit
On 20/10/2019 03:56:22, Steve Jorgensen wrote:
When using a custom classdict to implement a DSL or use in the body of a class
definition, from what I can tell by experiment, the classdict takes priority,
and the surrounding context is only referenced if trying to get an item from
the classdi
On Nov 19, 2019, at 09:51, Soni L. wrote:
>
> I still feel like opening the file but delaying the exception would be more
> beneficial and have better semantics. It allows cd, mv, rm, etc to happen
> without any surprising semantics, and fits the model you want it to fit.
Well, without any sur
On Nov 19, 2019, at 09:40, Rhodri James wrote:
>
>
> How about using Paths as file context managers? Just an idle thought.
Then how do you open a Path for writing, or in binary mode, etc.?
Adding a Path.opening method that returns an file-on-enter context manager
instead of a file would prob
> On Nov 19, 2019, at 08:04, Random832 wrote:
> On Tue, Nov 19, 2019, at 07:03, Paul Moore wrote:
>> That sounds reasonable, with one proviso. I would *strongly* object to
>> calling context managers that conform to the new expectations "well
>> behaved", and by contrast implying that those that
On 2019-11-19 3:37 p.m., Rhodri James wrote:
On 19/11/2019 17:12, Brian Skinn wrote:
@jayvdb on GitHub and I are working on a new version of one of my
packages, stdio-mgr (https://github.com/bskinn/stdio-mgr), with a
dramatically expanded API and capabilities.
Context managers feature heavi
On 19/11/2019 17:12, Brian Skinn wrote:
@jayvdb on GitHub and I are working on a new version of one of my packages,
stdio-mgr (https://github.com/bskinn/stdio-mgr), with a dramatically expanded
API and capabilities.
Context managers feature heavily in the planned design; part of the design pla
@jayvdb on GitHub and I are working on a new version of one of my packages,
stdio-mgr (https://github.com/bskinn/stdio-mgr), with a dramatically expanded
API and capabilities.
Context managers feature heavily in the planned design; part of the design plan
is to allow instantiation of a StdioMan
On Tue, 19 Nov 2019 at 16:05, Random832 wrote:
>
> On Tue, Nov 19, 2019, at 07:03, Paul Moore wrote:
> > That sounds reasonable, with one proviso. I would *strongly* object to
> > calling context managers that conform to the new expectations "well
> > behaved", and by contrast implying that those
On Tue, Nov 19, 2019, at 07:03, Paul Moore wrote:
> That sounds reasonable, with one proviso. I would *strongly* object to
> calling context managers that conform to the new expectations "well
> behaved", and by contrast implying that those that don't are somehow
> "misbehaving". File objects have
On Tue, 19 Nov 2019 at 11:34, Oscar Benjamin wrote:
> If I was to propose anything here it would not be to disallow anything
> that you can currently do with context managers. Rather the suggestion
> would be to:
> 1. Clearly define what a well-behaved context manager is.
> 2. Add convenient util
Whoops I sent too soon. I'll try again...
On Tue, 19 Nov 2019 at 11:01, Oscar Benjamin wrote:
>
> On Tue, 19 Nov 2019 at 08:21, Paul Moore wrote:
> >
> > On Mon, 18 Nov 2019 at 23:42, Oscar Benjamin
> > wrote:
> >
> > > Context managers and the
> > > with statement are all about assigning resp
On Tue, 19 Nov 2019 at 08:21, Paul Moore wrote:
>
> On Mon, 18 Nov 2019 at 23:42, Oscar Benjamin
> wrote:
>
> > Context managers and the
> > with statement are all about assigning responsibility so there needs
> > to be an understanding of what has responsibility for what at any
> > given time.
On 19/11/19 3:32 pm, Random832 wrote:
For one thing, it'd have to *truly never* fail.
Even if open() itself truly never failed, there would still be
room to get yourself into trouble. E.g.
with (open(get_filename_1()), open(get_filename_2())) as (f1, f2):
...
If get_filename_2()
On Mon, 18 Nov 2019 at 23:42, Oscar Benjamin wrote:
> > The definition is clearly and precisely implied by the PEP and the
> > semantics of the with statement. A CM is anything that has __enter__
> > and __exit__. See
> > https://www.python.org/dev/peps/pep-0343/#standard-terminology.
>
> That def
29 matches
Mail list logo
