On 2015-05-07 1:42 PM, Guido van Rossum wrote:
On Tue, May 5, 2015 at 3:36 PM, Rajiv Kumar wrote:
I wrote a little example[1] that has a bare-bones implementation of Go
style channels via a custom event loop. I used it to translate the prime
sieve example from Go[2] almost directly to Python
arent: 95953:a983d63e3321
user: Yury Selivanov
date:Mon May 11 14:48:38 2015 -0400
summary:
asyncio: async() function is deprecated in favour of ensure_future().
files:
Lib/asyncio/base_events.py | 2 +-
Lib/asyncio/tasks.py
:ee31277386cb
user:Yury Selivanov
date:Wed May 13 17:18:41 2015 -0400
summary:
inspect: Add __slots__ to BoundArguments.
Note that adding __slots__ breaks pickleability.
___
Python-Dev mailing list
Python-Dev@python.org
https
:07 +0300
Serhiy Storchaka wrote:
On 14.05.15 00:38, yury.selivanov wrote:
https://hg.python.org/cpython/rev/ee31277386cb
changeset: 96038:ee31277386cb
user:Yury Selivanov
date:Wed May 13 17:18:41 2015 -0400
summary:
inspect: Add __slots__ to BoundArguments.
Note that adding
Chris,
Could you please add a link to the email where the PEP was accepted?
Thanks,
Yury
On 2015-05-16 10:12 PM, chris.angelico wrote:
https://hg.python.org/peps/rev/f876276ce076
changeset: 5854:f876276ce076
user:Chris Angelico
date:Sun May 17 12:12:19 2015 +1000
summary:
On Wed, Sep 13, 2017 at 11:56 PM, Nick Coghlan wrote:
[..]
>>send(obj):
>>
>>Send the object to the receiving end of the channel. Wait until
>>the object is received. If the channel does not support the
>>object then TypeError is raised. Currently only bytes are
>>
Hi,
It looks like the discussion about the execution context became
extremely hard to follow. There are many opinions on how the spec for
generators should look like. What seems to be "natural"
behaviour/example to one, seems to be completely unreasonable to other
people. Recent emails from Gui
On Mon, Oct 16, 2017 at 11:49 AM, Guido van Rossum wrote:
> On Sun, Oct 15, 2017 at 10:26 PM, Nathaniel Smith wrote:
>>
>> On Sun, Oct 15, 2017 at 10:10 PM, Guido van Rossum
>> wrote:
>> > Yes, that's what I meant by "ignoring generators". And I'd like there to
>> > be
>> > a "current context" t
On Mon, Oct 16, 2017 at 7:44 AM, Nick Coghlan wrote:
[..]
> So going down this path would lock in the *default* semantics for the
> interaction between context variables and generators as being the same as
> the interaction between thread locals and generators, but would still leave
> the door ope
On Tue, Oct 17, 2017 at 1:02 AM, Nick Coghlan wrote:
> On 17 October 2017 at 14:31, Guido van Rossum wrote:
>>
>> No, that version just defers to magic in ContextVar.get/set, whereas what
>> I'd like to see is that the latter are just implemented in terms of
>> manipulating the mapping directly.
On Tue, Oct 17, 2017 at 2:25 PM, Guido van Rossum wrote:
> On Tue, Oct 17, 2017 at 8:54 AM, Yury Selivanov
[..]
>> My way of thinking about this: "get_execution_context()" returns you a
>> shallow copy of the current EC (at least conceptually). So making any
>> m
On Wed, Oct 18, 2017 at 1:06 PM, Guido van Rossum wrote:
> On Tue, Oct 17, 2017 at 9:40 PM, Nick Coghlan wrote:
[..]
>> By contrast, "contextvars.set_ctx" would need various wrappers to handle
>> correctly reverting the context change, and would hence be prone to "changed
>> the active context wi
On Wed, Oct 18, 2017 at 2:10 PM, Ethan Furman wrote:
[..]
> Unless it's extremely difficult to not seg-fault in such a situation I don't
> think this is a valid argument.
Well, you don't think so, but I do, after writing a few
implementations of this PEP family. It would complicate the design,
b
On Wed, Oct 18, 2017 at 2:21 PM, Guido van Rossum wrote:
> On Wed, Oct 18, 2017 at 10:50 AM, Yury Selivanov
> wrote:
>>
>> The main reason why I don't like 'set_ctx()' is because it would make
>> it harder for us to adopt PEP 550-like design later in the f
On Fri, Nov 3, 2017 at 11:30 PM, Nick Coghlan wrote:
> On 4 November 2017 at 09:52, Jelle Zijlstra wrote:
>>
>> 2017-11-03 16:44 GMT-07:00 Joao S. O. Bueno :
>>>
>>> This just popped up in Brython's issue tracker discussion:
>>>
>>> """
>>> Pierre Quentel
>>>
>>> 04:57 (16 hours ago)
>>> to bryt
Big +1 from me. The whole point of DeprecationWarnings is to be
visible so that they are resolved faster. The current behaviour
allows them to go unnoticed for the majority of Python users.
Yury
On Sun, Nov 5, 2017 at 9:05 PM, Nick Coghlan wrote:
> On the 12-weeks-to-3.7-feature-freeze thread,
On Tue, Nov 7, 2017 at 9:32 AM, Antoine Pitrou wrote:
> On Wed, 8 Nov 2017 00:01:04 +1000
> Nick Coghlan wrote:
>
>> On 7 November 2017 at 23:48, Stefan Krah wrote:
>> >
>> >
>> > This is just a reminder that the current dict is not an "OrderedDict":
>> >
>> from collections import OrderedD
On Thu, Nov 16, 2017 at 7:56 AM, Victor Stinner
wrote:
> 2017-11-16 13:43 GMT+01:00 Antoine Pitrou :
>>> About asyncio debug mode, if it's too expensive to be used to develop
>>> an application, maybe there is an issue with additional checks? Should
>>> we remove some of them to be able to use asy
On Wed, Nov 22, 2017 at 10:10 AM, Ivan Levkivskyi wrote:
> On 22 November 2017 at 15:47, Paul Moore wrote:
>>
>> I generally don't understand "await" in any context, so I deferred
>> judgement on that :-) Based on your comment that they are equally
>> tricky, I'd suggest we prohibit them both ;-)
On Wed, Nov 22, 2017 at 11:11 AM, Paul Moore wrote:
[..]
> But by the logic you just described, await isn't (or shouldn't be)
> allowed, surely?
No, that's a stretch. People can understand and actually use 'yield
(await foo())', but they usually can't figure what 'yield (yield
foo())' actually d
On Wed, Nov 22, 2017 at 2:08 PM, Ivan Levkivskyi wrote:
> On 22 November 2017 at 19:54, Jelle Zijlstra
> wrote:
>>
>>
>> One proposal is to make it so `g` gets assigned a list, and the `yield`
>> happens in the enclosing scope (so the enclosing function would have to be a
>> generator). This was
On Wed, Nov 22, 2017 at 2:37 PM, Ivan Levkivskyi wrote:
> On 22 November 2017 at 20:33, Guido van Rossum wrote:
>>
>> On Wed, Nov 22, 2017 at 11:12 AM, Ivan Levkivskyi
>> wrote:
>>>
>>> On 22 November 2017 at 20:05, Guido van Rossum wrote:
On Wed, Nov 22, 2017 at 10:54 AM, Jelle Zijls
On Wed, Nov 22, 2017 at 6:46 PM, Ivan Levkivskyi wrote:
[..]
> Just found another example of intuitive behaviour:
>
async def f():
> ... for i in range(3):
> ... yield i
> ...
async def g():
> ... return [(yield i) async for i in f()]
> ...
g().send(None)
> Traceback
On Fri, Nov 24, 2017 at 7:22 PM, Guido van Rossum wrote:
> The more I hear about this topic, the more I think that `await`, `yield` and
> `yield from` should all be banned from occurring in all comprehensions and
> generator expressions. That's not much different from disallowing `return`
> or `br
So we are keeping asynchronous generator expressions as long as they are
defined in an 'async def' coroutine?
Yury
On Sat, Nov 25, 2017 at 12:17 PM Brett Cannon wrote:
>
>
> On Fri, Nov 24, 2017, 19:32 Guido van Rossum, wrote:
>
>> On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum
>> wrote:
>
On Sat, Nov 25, 2017 at 3:27 PM, Guido van Rossum wrote:
> On Sat, Nov 25, 2017 at 9:21 AM, Yury Selivanov
> wrote:
>>
>> So we are keeping asynchronous generator expressions as long as they are
>> defined in an 'async def' coroutine?
>
>
> I would
On Sun, Nov 26, 2017 at 6:51 PM, Guido van Rossum wrote:
> On Sun, Nov 26, 2017 at 12:29 PM, Nathaniel Smith wrote:
[..]
>> - async/await has associated thread-global state like
>> sys.set_coroutine_wrapper and sys.set_asyncgen_hooks. Generally async
>> libraries assume that they own these, and a
On Sun, Nov 26, 2017 at 11:23 PM, Caleb Hattingh
wrote:
[..]
> I'd be very grateful if anyone can point out if my understanding of the
> above is incorrect. Private email is fine if you prefer not to post to the
> list.
It is correct. While 'yield from coro()', where 'coro()' is an 'async
def'
On Mon, Nov 27, 2017 at 12:05 PM, Larry Hastings wrote:
[..]
> The PEP for
> inspect.signature (PEP 362) says that when comparing two signatures for
> equality, their positional and positional-or-keyword parameters must be in
> the same order. It makes a point of *not* requiring that the two func
On Wed, Nov 29, 2017 at 1:47 PM, Ryan Gonzalez wrote:
> Doesn't Git make this rather easy, though?
+1.
PEP-like process for removing/renaming files is too much, in my opinion.
Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.
es to the interpreter or to the behaviour of generator or
coroutine objects.
PEP: 567
Title: Context Variables
Version: $Revision$
Last-Modified: $Date$
Author: Yury Selivanov
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 12-Dec-2017
Python-Version: 3.7
Post-History: 12-Dec
Hi Victor,
On Tue, Dec 12, 2017 at 6:49 PM, Victor Stinner
wrote:
> Hi Yury,
>
> I like the overall idea and I prefer this PEP over PEP 550 since it's
> shorter and easier to read :-)
>
> Question: Is there an API to list all context variables?
Context implements abc.Mapping, so 'get_context().k
On Tue, Dec 12, 2017 at 9:07 PM, Chris Angelico wrote:
> Redirecting comments from the PR to the ML. Everything that was
> tightly bound to the PR has been dropped.
>
> On Wed, Dec 13, 2017 at 12:15 PM, Yury Selivanov
> wrote:
>> Most of your questions should be asked on py
On Tue, Dec 12, 2017 at 9:55 PM, Guido van Rossum wrote:
> On Tue, Dec 12, 2017 at 5:35 PM, Yury Selivanov
> wrote:
>>
>> On Tue, Dec 12, 2017 at 6:49 PM, Victor Stinner
>> wrote:
>> > I like the overall idea and I prefer this PEP over PEP 550 since it&
On Tue, Dec 12, 2017 at 10:36 PM, Guido van Rossum wrote:
> Some more feedback:
>
>> This proposal builds directly upon concepts originally introduced
>> in :pep:`550`.
>
> The phrase "builds upon" typically implies that the other resource must be
> read and understood first. I don't think that we
eric
>
> On Tue, Dec 12, 2017 at 10:33 AM, Yury Selivanov
> wrote:
>> This is a new proposal to implement context storage in Python.
>
> +1
>
> This is something I've had on my back burner for years. Getting this
> right is non-trivial, so having a stdlib impleme
Ivan, Guido,
Would it be possible to add a slot so that types defined in C can
implement __class_getitem__?
static PyClassMethodDef class_methods = {
foo_class_getitem /* cm_class_getitem */
}
static PyTypeObject Foo = {
.tp_class_methods = class_methods
}
Yury
On Mon, Dec 4, 2017
On Thu, Dec 14, 2017 at 7:03 PM, Guido van Rossum wrote:
> A slot is pretty expensive, as *every* class in existence will be another 8
> bytes larger (and possibly more due to malloc rounding). So unless we find
> that there's a significant performance benefit I think we should hold back
> on this
On Thu, Dec 14, 2017 at 9:00 PM, Guido van Rossum wrote:
> In the light of Antoine's and Stephan's feedback I think this can be
> reconsidered -- while I want to take a cautious stance about resource
> consumption I don't want to stand in the way of progress.
I've created an issue to discuss this
> I don't see any problems with implementing this on types defined in C. This
> isn't harder than implementing __sizeof__ or pickling support, and NumPy
> classes already have implemented both. Maybe Yury forgot about METH_STATIC
> and METH_CLASS?
I just tested __class_getitem__ defined via MET
Shouldn't we optimize the usability for pure-Python first, and then for C API?
Right now we have the '__new__' magic method, which isn't a
@classmethod. Making '__class_getitem__' a @classmethod will confuse
regular Python users. For example:
class Foo:
def __new__(cls, ...): pass
On Fri, Dec 15, 2017 at 12:45 PM, Serhiy Storchaka wrote:
> 15.12.17 18:47, Yury Selivanov пише:
>>
>> Shouldn't we optimize the usability for pure-Python first, and then for C
>> API?
>>
>> Right now we have the '__new__' magic method, which isn&#x
Hi Ben,
On Sun, Dec 17, 2017 at 10:38 AM, Ben Darnell wrote:
> On Tue, Dec 12, 2017 at 12:34 PM Yury Selivanov
> wrote:
>>
>> Hi,
>>
>> This is a new proposal to implement context storage in Python.
>>
>> It's a successor of PEP 550 and builds
> 3. The connection pool has a queue, and creates a task for each connection to
> serve requests from that queue. Naively, each task could inherit the context
> of the request that caused it to be created, but the task would outlive the
> request and go on to serve other requests. The connection
On Mon, Dec 18, 2017 at 6:00 PM, Ivan Levkivskyi wrote:
> On 13 December 2017 at 22:35, Yury Selivanov
> wrote:
>>
>> [..]
>> >> A new standard library module ``contextvars`` is added
>> >
>> > Why not add this to contextlib instead of adding a ne
really doing.
4. Few clarifications/edits here and there to address earlier feedback.
Yury
PEP: 567
Title: Context Variables
Version: $Revision$
Last-Modified: $Date$
Author: Yury Selivanov
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 12-Dec-2017
Python-Version: 3.7
On Thu, Dec 28, 2017 at 5:28 AM, Chris Jerdonek
wrote:
> I have a couple basic questions around how this API could be used in
> practice. Both of my questions are for the Python API as applied to Tasks in
> asyncio.
>
> 1) Would this API support looking up the value of a context variable for
> **a
On Thu, Dec 28, 2017 at 4:51 AM, Victor Stinner
wrote:
> Hi,
>
> I like the new version of the PEP using "read only mapping" and
> copy_context(). It's easier to understand.
Thanks, Victor!
>
> I'm ok with seeing a context as a mapping, but I am confused about a context
> variable considered as
On Wed, Jan 3, 2018 at 2:36 AM Victor Stinner
wrote:
> > I would really like to invite more people to review this PEP! I expect
> I'll be accepting it in the next two weeks, but it needs to go through more
> rigorous review.
>
> I read again the PEP and I am still very confused by Context.run().
On Wed, Jan 3, 2018 at 3:04 AM Victor Stinner
wrote:
> What is the behaviour of ContextVar.reset(token) if the token was created
> from a different variable? Raise an exception?
>
> token = var1.set("value")
> var2.reset(token)
>
> The PEP states that Token.var only exists for debug or introspect
I don't want to expose a SetContext operation because of, again, potential
incompatibility with PEP 550, where generators expect to fully control
push/pop context operation.
Second, Context.run is 100% enough for *any* async framework to add support
for PEP 567. And because the PEP is focused just
> On Jan 3, 2018, at 12:26 PM, Victor Stinner wrote:
>
> Le 3 janv. 2018 06:05, "Yury Selivanov" a écrit :
> tuples in Python are immutable, but you can have a tuple with a dict as its
> single element. The tuple is immutable, the dict is mutable.
>
> At th
I think we can expose the default property. If it's not set we can return
MISSING.
Yury
Sent from my iPhone
> On Jan 3, 2018, at 1:04 PM, Victor Stinner wrote:
>
> Le 3 janv. 2018 06:38, "Guido van Rossum" a écrit :
> But is there a common use case? For var.get() I'd rather just pass the
>
Hi,
Thanks to everybody participating in the PEP 567 discussion! I want
to summarize a few topics to make sure that we are all on the same
page (and maybe provoke more discussion).
1. Proposal: ContextVar has default set to None.
>From the typing point of view that would mean that if a context
> On Jan 9, 2018, at 11:18 AM, Nathaniel Smith wrote:
>
>> On Thu, Jan 4, 2018 at 9:42 PM, Guido van Rossum wrote:
>>> On Thu, Jan 4, 2018 at 7:58 PM, Nathaniel Smith wrote:
>>> This does make me think that I should write up a short PEP for
>>> extending PEP 567 to add context lookup, PEP 550
On Tue, Jan 9, 2018 at 11:02 AM, Nathaniel Smith wrote:
> On Mon, Jan 8, 2018 at 11:34 AM, Yury Selivanov
> wrote:
>> 1. Proposal: ContextVar has default set to None.
>>
>> From the typing point of view that would mean that if a context
>> variable is declared wi
09 12:41 GMT+01:00 Yury Selivanov :
> > But I'd be -1 on making all ContextVars have a None default
> > (effectively have a "ContextVar.get(default=None)" signature. This
> > would be a very loose semantics in my opinion.
>
> Why do you think that it'
Wasn't PEP 555 rejected by Guido? What's the point of this post?
Yury
On Wed, Jan 10, 2018 at 4:08 AM Koos Zevenhoven wrote:
> Hi all,
>
> I feel like I should write some thoughts regarding the "context"
> discussion, related to the various PEPs.
>
> I like PEP 567 (+ 567 ?) better than PEP 550
On Thu, Jan 11, 2018 at 4:44 AM, Nathaniel Smith wrote:
[..]
> It may have gotten lost in that email, but my actual favorite approach
> is that we make the signatures:
>
> ContextVar(name, *, initial_value) # or even (*, name, initial_value)
> ContextVar.get()
> ContextVar.set(value)
>
> so that
On Thu, Jan 11, 2018 at 10:39 AM, Ethan Furman wrote:
> On 01/10/2018 10:23 PM, Yury Selivanov wrote:
[..]
>> Therefore I'm still in favour of keeping the current PEP 567
>> behaviour.
>
>
> To be clear: We'll now be able to specify a default when we create the
On Thu, Jan 11, 2018 at 10:35 AM, Chris Jerdonek
wrote:
> On Mon, Jan 8, 2018 at 11:02 PM, Nathaniel Smith wrote:
>> Right now, the set of valid states for a ContextVar are: it can hold
>> any Python object, or it can be undefined. However, the only way it
>> can be in the "undefined" state is in
uthor: Yury Selivanov
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 12-Dec-2017
Python-Version: 3.7
Post-History: 12-Dec-2017, 28-Dec-2017, 16-Jan-2018
Abstract
This PEP proposes a new ``contextvars`` module and a set of new
CPython C APIs to support context vari
On Tue, Jan 16, 2018 at 6:53 PM, Guido van Rossum wrote:
> On Tue, Jan 16, 2018 at 3:26 PM, Victor Stinner
[..]
>> I don't think that it's worth it to prevent misuage of reset(). IMHO
>> it's fine if calling reset() twice reverts the variable state twice.
>
>
> Maybe the effect of calling it twic
Thanks, Victor!
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Tue, Jan 16, 2018 at 7:45 PM, Guido van Rossum wrote:
> On Tue, Jan 16, 2018 at 4:37 PM, Antoine Pitrou wrote:
>>
>> On Tue, 16 Jan 2018 17:44:14 -0500
>> Yury Selivanov wrote:
>>
>> > Offloading execution to other threads
>> > -
On Tue, Jan 16, 2018 at 8:27 PM, Nathaniel Smith wrote:
[..]
> token = cvar.set(...)
> token.reset()
I see the point, but I think that having the 'reset' method defined on
the ContextVar class is easier to grasp. It also feels natural that a
pair of set/reset methods is defined on the same class
On Wed, Jan 17, 2018 at 6:03 AM, Antoine Pitrou wrote:
> On Tue, 16 Jan 2018 17:18:06 -0800
> Nathaniel Smith wrote:
>> On Tue, Jan 16, 2018 at 5:06 PM, Yury Selivanov
>> wrote:
>> >
>> > I think it would be a very fragile thing In practice: if you have e
On Wed, Jan 17, 2018 at 2:24 PM, Guido van Rossum wrote:
> Perhaps you can update the PEP with a summary of the rejected ideas from
> this thread?
The Rejected Ideas section of the PEP is now updated with the below:
Token.reset() instead of ContextVar.reset()
On Wed, Jan 17, 2018 at 8:53 PM, Yury Selivanov wrote:
> On Wed, Jan 17, 2018 at 2:24 PM, Guido van Rossum
> wrote:
>> Perhaps you can update the PEP with a summary of the rejected ideas from
>> this thread?
>
> The Rejected Ideas section of the PEP is now updated wit
Yay! Thank you, Guido!
Yury
On Mon, Jan 22, 2018 at 6:52 PM, Guido van Rossum wrote:
> Yury,
>
> I am hereby *accepting* the latest version of PEP 567[1]. Congrats!
>
> --Guido
>
> [1]
> https://github.com/python/peps/commit/a459539920b9b8c8394ef61058e88a076ef8b133#diff-9d0ccdec754459da5f665cc6c
I looked at the PR and I think the code is fine.
Yury
On Thu, Jan 25, 2018 at 4:39 PM, Victor Stinner
wrote:
> Hi,
>
> If nobody is available to review your PR, I suggest to push it anyway,
> to get it merged before the feature freeze. The code can be reviewed
> later. Merging it sooner gives mo
On Mon, Jan 29, 2018 at 1:36 AM Nick Coghlan wrote:
> [...]
> Currently the answers are:
>
> - A: not hashable
> - B: hashable (by identity) # Wat?
> - C: hashable (by field hash)
> - D: hashable (by identity) # Wat?
> - E: hashable (by field hash)
> - F: hashable (by field hash)
> - G: hashable
On Fri, Feb 2, 2018 at 10:51 AM, Paul Moore wrote:
[..]
> To put it another way, using your words above, "The moment you want to
> use a dataclass a a dict key, or put it in a set, you need it to be
> *immutable*" (not hashable, unless you really know what you're doing).
Can someone clarify what
FWIW I'm extremely happy with the current workflow. The recent
improvements to @miss-islington (kudos to Mariatta!) allowing her to
auto-backport PRs and commit them is a big time saver.
I can only suggest a couple improvements:
1. Make our bots check the code style—fully enforce PEP 8, lint the
On Wed, Feb 21, 2018 at 10:27 PM, Guido van Rossum wrote:
[..]
> I honestly expect that running either with close-to-default flags on stdlib
> code would be a nightmare, and I wouldn't want *any* directives for either
> one to appear in stdlib code, ever.
It would be great to enable the linter on
Hi Chris,
Thank you for working on this PEP! Inline assignments is a long
requested feature and this seems to be the first serious attempt
at adding it.
That said I'm very -1 on the idea.
1. I switch between Python / JavaScript / C frequently (although
I code in Python 70% of my time.) C and
I propose to use the following syntax for assignment expressions:
( NAME = expr )
I know that it was proposed before and this idea was rejected, because
accidentally using '=' in place of '==' is a pain point in
C/C++/JavaScript.
That said, I believe we can still use this syntax as long as w
On Tue, Apr 24, 2018 at 9:46 AM, Nick Coghlan wrote:
> On 24 April 2018 at 23:38, Yury Selivanov wrote:
>> I propose to use the following syntax for assignment expressions:
>>
>> ( NAME = expr )
>>
>> I know that it was proposed before and this idea was
On Tue, Apr 24, 2018 at 10:07 AM, Nick Coghlan wrote:
>> "=" is always an assignment.
>> "==" is always an equality check.
>
> That's not the distinction I meant, I meant the difficulty of
> explaining the discrepancies in this list:
>
> a = 1 # Assignment
> (a = 1) # Also assignment
>
> a, b = 1
On Tue, Apr 24, 2018 at 10:56 AM, Chris Angelico wrote:
[..]
>> A lot of other questions arise though. PEP 572 proposes:
>>
>> a = 1 # assignment
>> a := 1 # also assignment
>> (a := 1) # also assignment
>> (a = 1) # error, why?
>
> Your third example is just the same as the second, with pare
On Tue, Apr 24, 2018 at 10:49 AM, Paul Moore wrote:
[..]
>>> 3. Most importantly: it is *not* allowed to mask names in the current
>>> local scope.
>>
>> While I agree this would be unambiguous to a computer, I think for
>> most humans it would be experienced as a confusing set of arcane and
>> ar
On Tue, Apr 24, 2018 at 10:54 AM, Anthony Flury via Python-Dev
wrote:
[..]
> As discussed previously by others on this exact proposals, you now have the
> issue of confusion when using keyword arguments : *my_func(a = b)* :
> clearly that is a call to `my_func' where argument a has the value of b
On Tue, Apr 24, 2018 at 11:07 AM, Chris Angelico wrote:
[..]
> x = 1
> if (x = 2): ...
>
> This, according to your proposal, raises SyntaxError - not because a
> comparison was wanted and an assignment was made, but because the name
> already had a value. And, even worse, this is NOT an error:
Y
On Tue, Apr 24, 2018 at 11:15 AM, Steven D'Aprano wrote:
[..]
>> >> 3. Most importantly: it is *not* allowed to mask names in the current
>> >> local scope.
>
> That means you can't rebind existing variables. That means you can't
> rebind to the same variable in a loop.
No, it doesn't. The check
On Tue, Apr 24, 2018 at 11:31 AM, Nick Coghlan wrote:
> On 25 April 2018 at 00:54, Eric Snow wrote:
>> Regardless, your 3 rules would benefit either syntax. Nick may have a
>> point that the rules might be an excessive burden, but I don't think
>> it's too big a deal since the restrictions are f
On Tue, Apr 24, 2018 at 11:27 AM, Steven D'Aprano wrote:
> On Tue, Apr 24, 2018 at 11:03:35AM -0400, Yury Selivanov wrote:
>
>> My point was that when you see lots of '=' and ':=' used at the
>> statement level, one might try to write "if x =
On Tue, Apr 24, 2018 at 11:28 AM, Chris Angelico wrote:
> On re-thinking this, I think the distinction IS possible, but (a) only
> in function/class scope, not at global; and (b) would be defined in
> terms of lexical position, not run-time. For instance:
>
> def f():
> (a = 1) # Legal; 'a' h
On Tue, Apr 24, 2018 at 11:34 AM, Steven D'Aprano wrote:
> On Tue, Apr 24, 2018 at 11:05:57AM -0400, Yury Selivanov wrote:
>
>> Well, `my_func(a=(b:=foo))` or `my_func(b:=foo)` are also barely
>> readable to my eye.
>
> There's no advantage to using binding-expre
On Tue, Apr 24, 2018 at 11:51 AM, Ethan Furman wrote:
>> When I compare to variables from outer scopes they *usually* are on
>> the *right* side of '=='.
>
>
> You mean something like
>
> if 2 == x:
>
> ? I never write code like that, and I haven't seen it, either.
Hm. I mean this:
const
On Tue, Apr 24, 2018 at 11:58 AM, Chris Angelico wrote:
> On Wed, Apr 25, 2018 at 1:49 AM, Yury Selivanov
> wrote:
>> On Tue, Apr 24, 2018 at 11:34 AM, Steven D'Aprano
>> wrote:
[..]
>>> There's no advantage to using binding-expressions unless you
On Tue, Apr 24, 2018 at 12:03 PM, Ethan Furman wrote:
[..]
> But I do write this:
>
> def wrapper(func, some_value):
> value_I_want = process(some_value)
> def wrapped(*args, **kwds):
> if value_I_want == 42:
> ...
But this pattern is more rare than comparing local variab
On Wed, Apr 25, 2018 at 5:58 PM Guido van Rossum wrote:
[..]
> It was meant dismissive. With Chris, I am tired of every core dev
starting their own thread about how PEP 572 threatens readability or
doesn't reach the bar for new syntax (etc.). These arguments are entirely
emotional and subjective.
On Wed, Apr 25, 2018 at 8:22 PM Chris Angelico wrote:
[..]
> > my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf))
> >
> > To my eye this is an anti-pattern. One line of code was saved, but the
> > other line becomes less readable. The fact that 'buf' can be used after
> > t
Reviewed. This seems to be an omission that needs to fixed, thanks for the
PR! Almost good to go in 3.8. As for 3.7, this isn't a bug fix it's up to
Ned if he wants to accept it.
Yury
On Sun, Apr 29, 2018 at 8:02 AM Anthony Flury via Python-Dev <
python-dev@python.org> wrote:
> All,
> Can someon
On Mon, Apr 30, 2018 at 11:32 AM Chris Angelico wrote:
> On Tue, May 1, 2018 at 12:30 AM, Mark Shannon wrote:
> > List comprehensions
> > ---
> > The PEP uses the term "simplifying" when it really means "shortening".
> > One example is
> > stuff = [[y := f(x), x/y] for x in range
On Mon, Apr 30, 2018 at 1:03 PM Chris Angelico wrote:
> > That's a weird argument, Chris :-)
> >
> > If `f(x)` has no meaningful name, then *what* is the result of the
> > comprehension? Perhaps some meaningless data? ;)
> f(x) might have side effects. Can you give a meaningful name to the
> tri
On Fri, May 18, 2018 at 4:15 PM Steve Dower wrote:
[..]
> The asyncio instability is apparently really hard to fix. There were 2-3
people looking into it yesterday on one of the other systems, but
apparently we haven’t solved it yet (my guess is lingering state from a
previous test). The multissl
On Tue, May 22, 2018 at 8:52 AM Victor Stinner wrote:
> Usually, I don't open a new bug to fix or enhance a test. So I
> wouldn't say that it's mandatory. It's really on a case by case basis.
> It seems like test_asyncio failures are a hot topic these days :-)
> It's one of the reasons why Pytho
> It is currently a general convention in asyncio to only catch Exception, not
> BaseException. I consider this a flaw and we should fix it, but it's
> unfortunately not so easy -- the tests will fail if you replace all
> occurrences of Exception with BaseException, and it is not always clear
>
On Mon, Jun 4, 2018 at 12:50 PM Chris Angelico wrote:
>
> On Tue, Jun 5, 2018 at 2:11 AM, Victor Stinner wrote:
[..]
> > For me, it's fine to catch any exception using "except:" if the block
> > contains "raise", typical pattern to cleanup a resource in case of
> > error. Otherwise, there is a ri
101 - 200 of 592 matches
Mail list logo
