On 19/11/19 4:54 am, Paul Moore wrote:
"should only manage one
resource" is not actually correct - the whole *point* of something
like nested() would be to manage multiple resources
I think a better way to say it would be that the __enter__
method should be atomic -- it should either acquire al
Jonathan Fine writes:
> I'm an amateur (unpaid) research mathematician. I find the syntax
> >>> A in B < C
> clear.
When I first saw it I read it "A in B is less than C," ie, "A in B and
A < C".
___
Python-ideas mailing list -- python-ideas@python.or
> On Nov 18, 2019, at 19:34, Brendan Barnwell wrote:
>
>
> I would say this is a poor design. Just write "wait" so that you always
> have to call it, and you just pass no arguments if you want the default.
> So instead of this:
>
> # default delay
> @wait
> def foo():
>
> # custom delay
> @w
On 2019-11-18 18:09, Samuel Muldoon wrote:
At present, multi-argument function decorators are a little bit
tricky to implement.
As an example (somewhat contrived), suppose that `wait` is a function
decorator which haults program execution for a few seconds before
calling the wrapped function.
On 2019-11-18 10:59 p.m., Andrew Barnert wrote:
On Nov 18, 2019, at 16:35, Soni L. wrote:
>
>
>> On 2019-11-18 5:22 p.m., Soni L. wrote:
>>
>>
>>> On 2019-11-18 5:13 p.m., Andrew Barnert via Python-ideas wrote:
On Nov 18, 2019, at 10:51, Random832 wrote:
>>> > > On Mon, Nov 18, 201
On 18Nov2019 19:09, Samuel Muldoon wrote:
At present, multi-argument function decorators are a little bit tricky to
implement.
Aye, but one can write a decorator for decorators which makes it easy.
No extra syntax required.
I've one of my own called @decorator, available on PyPI from the
On Mon, Nov 18, 2019, at 19:32, Soni L. wrote:
> let me ask again: can we make it so open() never fails, instead
> returning a file that can be either "open", "closed" or "errored"?
For one thing, it'd have to *truly never* fail. Not just on I/O errors but on
things like passing bad function arg
At present, multi-argument function decorators are a little bit tricky to
implement.
As an example (somewhat contrived), suppose that `wait` is a function
decorator which haults program execution for a few seconds before calling
the wrapped function.
If you do not pass a float value into *delay*
On Tue, 19 Nov 2019 at 00:35, Soni L. wrote:
>
> On 2019-11-18 5:22 p.m., Soni L. wrote:
> >
> > could we tweak open() so it doesn't raise immediately? this would make
> > it play nicer with __enter__ but would probably break some things.
> > this would make open() itself "never" fail.
>
> let me
On Nov 18, 2019, at 16:35, Soni L. wrote:
>
>
>> On 2019-11-18 5:22 p.m., Soni L. wrote:
>>
>>
>>> On 2019-11-18 5:13 p.m., Andrew Barnert via Python-ideas wrote:
On Nov 18, 2019, at 10:51, Random832 wrote:
>>> > > On Mon, Nov 18, 2019, at 12:46, Paul Moore wrote:
>>> >> But open() isn'
On 2019-11-18 5:22 p.m., Soni L. wrote:
On 2019-11-18 5:13 p.m., Andrew Barnert via Python-ideas wrote:
On Nov 18, 2019, at 10:51, Random832 wrote:
> > On Mon, Nov 18, 2019, at 12:46, Paul Moore wrote:
>> But open() isn't designed *just* to be used in a with statement. It
>> can be used in
On 2019-11-18 11:24, Brendan Barnwell wrote:
I agree. I think this discussion wouldn't be necessary if there were a
context manager that was like open() but opened the file in __enter__ and closed
it in __exit__. I would go so far as to say I think it would be a good idea to
add such a
On Mon, 18 Nov 2019 at 22:00, Paul Moore wrote:
>
> On Mon, 18 Nov 2019 at 18:34, Oscar Benjamin
> wrote:
> >
> > On Mon, 18 Nov 2019 at 17:46, Paul Moore wrote:
>
> > I think that nested was fine but in combination with open it was prone
> > to misuse. By the time with/contextlib etc had shipp
On Nov 18, 2019, at 12:34, Barry wrote:
>
> Esoteric? I work with files that are open beyond the scope of a single block
> of code all the time. Clearly I need to arrange to close the file eventually.
> Why would I want the uglyness of __exit__ rather then close()?
> I use with all the time if th
On 11/18/19 4:53 PM, Andrew Barnert via Python-ideas wrote:
> On Nov 18, 2019, at 13:14, Chris Angelico wrote:
>> I wasn't aiming that at you, so much as pointing out how incredibly
>> tricky it is to pin down all these definitions. So tricky, in fact,
>> that it's almost completely not worth t
On Nov 18, 2019, at 13:14, Chris Angelico wrote:
>
> I wasn't aiming that at you, so much as pointing out how incredibly
> tricky it is to pin down all these definitions. So tricky, in fact,
> that it's almost completely not worth trying to define at all (in my
> opinion).
90% of the time it’s o
On Nov 18, 2019, at 13:14, Random832 wrote:
>
> On Mon, Nov 18, 2019, at 13:35, Serhiy Storchaka wrote:
>> 18.11.19 04:39, Daniel Zeng пише:
>>> Syntax for tuple comprehension, something like:
>>> (i, for i in range(10))
>>
>>(**(i for i in range(10)))
>
> It'd be (*(i for i in range(10)),
On Mon, 18 Nov 2019 at 18:34, Oscar Benjamin wrote:
>
> On Mon, 18 Nov 2019 at 17:46, Paul Moore wrote:
> > What about
> >
> > f = open(filename)
> > header = f.readline()
> > with f:
> > # use f
>
> I would naturally rewrite that as
>
> with open(filename) as f:
> header
On 18.11.2019 21:13, Barry wrote:
>
>
>> On 18 Nov 2019, at 19:27, Brendan Barnwell wrote:
>>
>> On 2019-11-18 10:49, Random832 wrote:
>>> I would say open() is arguably a wart. Had context managers existed
>>> in the language all along, it should not be possible to do anything
>>> that creates
On Tue, Nov 19, 2019 at 8:04 AM Random832 wrote:
>
> On Mon, Nov 18, 2019, at 14:04, Chris Angelico wrote:
> > If by "constant" you mean that they are immutable, then maybe; there
> > aren't very many mutable callables (by comparison to the huge number
> > of functions). But you can't assume that
On Mon, Nov 18, 2019, at 13:35, Serhiy Storchaka wrote:
> 18.11.19 04:39, Daniel Zeng пише:
> > Syntax for tuple comprehension, something like:
> > (i, for i in range(10))
>
> (**(i for i in range(10)))
It'd be (*(i for i in range(10)),) but point taken. In fact, after thinking
about it some
On Mon, Nov 18, 2019, at 14:04, Chris Angelico wrote:
> If by "constant" you mean that they are immutable, then maybe; there
> aren't very many mutable callables (by comparison to the huge number
> of functions). But you can't assume that a function is as constant as
> a string literal.
I meant a
> On 18 Nov 2019, at 19:27, Brendan Barnwell wrote:
>
> On 2019-11-18 10:49, Random832 wrote:
>> I would say open() is arguably a wart. Had context managers existed
>> in the language all along, it should not be possible to do anything
>> that creates an open-ended future requirement to do som
On Tue, Nov 19, 2019 at 6:31 AM wrote:
>
> OMG people, no one said its a replacement for +
> Its an addition. that does nothing but combining data.
Except that you're asking it to do something extremely similar to what
the + operator already does.
> It does not perform any mathematical operation
Hi all,
moderator here. Saw this. No need to respond.
thanks,
--titus
On Mon, Nov 18, 2019 at 07:30:05PM -, tonycst...@gmail.com wrote:
> OMG people, no one said its a replacement for +
> Its an addition. that does nothing but combining data.
> It does not perform any mathematical operations
On Tue, Nov 19, 2019 at 6:15 AM Andrew Barnert wrote:
>
> On Nov 18, 2019, at 11:07, Chris Angelico wrote:
> >
> > If by "constant" you mean that they are immutable, then maybe; there
> > aren't very many mutable callables (by comparison to the huge number
> > of functions).
>
> Functions are mut
OMG people, no one said its a replacement for +
Its an addition. that does nothing but combining data.
It does not perform any mathematical operations whats so ever. It simply puts
things together regardless of their data type.
(1.1 & 5 & "word") results in 1.15word
That fact that you say "will be
On 2019-11-18 5:13 p.m., Andrew Barnert via Python-ideas wrote:
On Nov 18, 2019, at 10:51, Random832 wrote:
>
> On Mon, Nov 18, 2019, at 12:46, Paul Moore wrote:
>> But open() isn't designed *just* to be used in a with statement. It
>> can be used independently as well. What about
>>
>>
On 2019-11-18 10:49, Random832 wrote:
I would say open() is arguably a wart. Had context managers existed
in the language all along, it should not be possible to do anything
that creates an open-ended future requirement to do something (i.e.
"require that the returned object gets closed at some s
On Nov 18, 2019, at 11:07, Chris Angelico wrote:
>
> If by "constant" you mean that they are immutable, then maybe; there
> aren't very many mutable callables (by comparison to the huge number
> of functions).
Functions are mutable. You can edit their __defaults__, or even replace their
__code_
On Tue, Nov 19, 2019 at 5:47 AM Andrew Barnert via Python-ideas
wrote:
> Unless there’s some case where you don’t want to close f at all, I don’t see
> why you don’t want a context manager. For example, your return early case:
>
> with open(filename) as f:
> header = f.readline()
>
On Nov 18, 2019, at 10:51, Random832 wrote:
>
> On Mon, Nov 18, 2019, at 12:46, Paul Moore wrote:
>> But open() isn't designed *just* to be used in a with statement. It
>> can be used independently as well. What about
>>
>>f = open(filename)
>>header = f.readline()
>>with f:
>>
On Nov 18, 2019, at 10:27, Random832 wrote:
>
> On Mon, Nov 18, 2019, at 13:00, Andrew Barnert via Python-ideas wrote:
>>def f(a, b): return a**(b+1)
>>g = partial(f, b==2)
>>h = lambda x: f(x, 2)
>>
>> Python can’t tell the difference between f, g, and h; they’re all
>> variables.
On Tue, Nov 19, 2019 at 5:26 AM Random832 wrote:
>
> On Mon, Nov 18, 2019, at 13:00, Andrew Barnert via Python-ideas wrote:
> > def f(a, b): return a**(b+1)
> > g = partial(f, b==2)
> > h = lambda x: f(x, 2)
> >
> > Python can’t tell the difference between f, g, and h; they’re all
> >
On Mon, Nov 18, 2019, at 12:46, Paul Moore wrote:
> But open() isn't designed *just* to be used in a with statement. It
> can be used independently as well. What about
>
> f = open(filename)
> header = f.readline()
> with f:
> # use f
>
> The open doesn't "create a future need
On Nov 18, 2019, at 09:47, Paul Moore wrote:
>
> But open() isn't designed *just* to be used in a with statement. It
> can be used independently as well. What about
>
>f = open(filename)
>header = f.readline()
>with f:
># use f
>
> The open doesn't "create a future need to c
18.11.19 04:39, Daniel Zeng пише:
Syntax for tuple comprehension, something like:
(i, for i in range(10))
(**(i for i in range(10)))
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.
On Mon, 18 Nov 2019 at 17:46, Paul Moore wrote:
>
> On Mon, 18 Nov 2019 at 17:17, Oscar Benjamin
> wrote:
> > The problem with a misbehaving context manager is that it creates a
> > future need to call __exit__ before it has been passed to a with
> > statement or any other construct that can gua
On Mon, Nov 18, 2019, at 12:59, Paul Moore wrote:
> On Mon, 18 Nov 2019 at 17:55, Random832 wrote:
> > This particular chain of discussion is regarding a proposal to solve the
> > problem posed in the original topic by using a parenthesized tuple display,
> > i.e. code that looks like the follow
On Mon, Nov 18, 2019, at 13:00, Andrew Barnert via Python-ideas wrote:
> def f(a, b): return a**(b+1)
> g = partial(f, b==2)
> h = lambda x: f(x, 2)
>
> Python can’t tell the difference between f, g, and h; they’re all
> variables. An IDE could keep track of the fact that f was bound
On Nov 18, 2019, at 06:02, tonycst...@gmail.com wrote:
>
> x = 5
> y = 5
> print (x+y) #prints 10
> This is easy because everyone knows that + sign adds 2 values together.
>
> print(str(x)+str(y)) #prints 55
> I understand that there are more then one way to do this but, the bottom line
> is, t
On Nov 18, 2019, at 06:05, tonycst...@gmail.com wrote:
>
> Inability to visually identify a variable without looking at where its
> placed and/or how its used is sometimes brain damaging task when it comes to
> understanding code someone else wrote.
What’s the difference between a variable and
On Mon, 18 Nov 2019 at 17:55, Random832 wrote:
> This particular chain of discussion is regarding a proposal to solve the
> problem posed in the original topic by using a parenthesized tuple display,
> i.e. code that looks like the following:
>
> with (open(filename1), open(filename2)) as (file1
On Tue, Nov 19, 2019 at 4:41 AM Andrew Barnert via Python-ideas
wrote:
>
> On Nov 18, 2019, at 04:32, Ned Batchelder wrote:
>
> There are uses for comprehension syntax for making tuples, but they occur far
> far less frequently than the comprehensions we have. To me, the existing way
> to do i
On Mon, Nov 18, 2019, at 03:42, Paul Moore wrote:
> The context here has been lost - I've searched the thread and I can't
> find a proper explanation of how open() "misbehaves" in any way that
> seems to relate to this statement (I don't actually see any real
> explanation of any problem with open(
On Mon, 18 Nov 2019 at 17:17, Oscar Benjamin wrote:
> The problem with a misbehaving context manager is that it creates a
> future need to call __exit__ before it has been passed to a with
> statement or any other construct that can guarantee to do that.
You seem to be focusing purely on the usag
On Nov 18, 2019, at 04:32, Ned Batchelder wrote:
>
> There are uses for comprehension syntax for making tuples, but they occur far
> far less frequently than the comprehensions we have. To me, the existing way
> to do it makes perfect sense, and exactly expresses what needs to happen:
>
>
On Mon, 18 Nov 2019 at 15:54, Paul Moore wrote:
>
> On Mon, 18 Nov 2019 at 11:12, Oscar Benjamin
> wrote:
>
> > I am proposing the root of the problem here is the fact that open
> > acquires its resource (the opened file descriptor) before __enter__ is
> > called. This is what I mean by a contex
This is way too late to change now. I agree that plus isn't great but & is also
quite bad since it means bitwise and. A totally separate operator for
concatenation would have been preferable but this is as I said way too late to
change now.
> On 18 Nov 2019, at 15:02, tonycst...@gmail.com wrot
On Mon, 18 Nov 2019 at 11:12, Oscar Benjamin wrote:
> I am proposing the root of the problem here is the fact that open
> acquires its resource (the opened file descriptor) before __enter__ is
> called. This is what I mean by a context manager that "misbehaves". If
> there was a requirement on co
On Mon, 18 Nov 2019 at 14:07, Soni L. wrote:
> On 2019-11-18 11:32 a.m., Oscar Benjamin wrote:
> > On Mon, 18 Nov 2019 at 13:12, Soni L. wrote:
> > >
> > > On 2019-11-18 9:10 a.m., Oscar Benjamin wrote:
> > > >
> > > > with nested(open(filename) for filename in filenames) as files:
> > > > .
Imo `&` is not a suitable replacement for `+`.
Semantically when I read "Tony & Maria" it looks closer to behaving like a
Set.union ala`{"Tony"}.union({"Maria"})`
where comparatively the addition (+) infix operator is there to facilitate
concatenation, which is a very common operation and does no
On 2019-11-18 11:32 a.m., Oscar Benjamin wrote:
On Mon, 18 Nov 2019 at 13:12, Soni L. wrote:
>
> On 2019-11-18 9:10 a.m., Oscar Benjamin wrote:
> > [snip]
> >
> > To me that seems clumsy and awkward compared to nested though:
> >
> > with nested(*map(open, filenames)) as files:
> > ...
>
Inability to visually identify a variable without looking at where its placed
and/or how its used is sometimes brain damaging task when it comes to
understanding code someone else wrote.
In fact, i dont know any IDE that can identify python or any language variable
and color them as good as Auto
x = 5
y = 5
print (x+y) #prints 10
This is easy because everyone knows that + sign adds 2 values together.
print(str(x)+str(y)) #prints 55
I understand that there are more then one way to do this but, the bottom line
is, this is not logical.
Tony+Maria
is what we used to write when we were little
On Mon, 18 Nov 2019 at 13:12, Soni L. wrote:
>
> On 2019-11-18 9:10 a.m., Oscar Benjamin wrote:
> > [snip]
> >
> > To me that seems clumsy and awkward compared to nested though:
> >
> > with nested(*map(open, filenames)) as files:
> > ...
> >
> > Ideally I would design nested to take an itera
On 2019-11-18 9:10 a.m., Oscar Benjamin wrote:
[snip]
To me that seems clumsy and awkward compared to nested though:
with nested(*map(open, filenames)) as files:
...
Ideally I would design nested to take an iterable rather than *args
and then it would be fine to do e.g.
with nested(ope
On 11/17/19 9:39 PM, Daniel Zeng wrote:
Syntax for tuple comprehension, something like:
(i, for i in range(10))
This shouldn't result in ambiguity, since generators need to be in
parentheses anyway:
(i, for i in range(10)) vs (1, (i for i in range(10)))
The existing comprehensions support
To me, however, that would look like a one-element genexp tuple, and would be
too easily confused with something like ((i for i in range(10),)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@pyt
On Mon, 18 Nov 2019 at 08:42, Paul Moore wrote:
>
> On Sun, 17 Nov 2019 at 19:18, Oscar Benjamin
> wrote:
> >
> > Ultimately the problem is that the requirements on a context manager
> > are not clearly spelled out. The with statement gives context manager
> > authors a strong guarantee that if
On Mon, 18 Nov 2019 at 03:57, Daniel Zeng wrote:
>
> Syntax for tuple comprehension, something like:
> (i, for i in range(10))
>
> This shouldn't result in ambiguity, since generators need to be in
> parentheses anyway:
> (i, for i in range(10)) vs (1, (i for i in range(10)))
I'm going to ignore
On Sun, 17 Nov 2019 at 19:18, Oscar Benjamin wrote:
> That might be useful but it doesn't solve the problem from the
> perspective of someone writing context manager utilities like nested
> because it still leaves a trap for anyone who uses open with those
> utilities.
>
> Also I don't know of any
62 matches
Mail list logo
