On Fri, Apr 13, 2018 at 4:27 PM, Ethan Furman wrote:
> On 04/12/2018 09:52 PM, Chris Angelico wrote:
>
>> foo := a > b # does this capture 'a', or 'a > b'?
>> bar := c + d # 'c' or 'c + d'?
>>
>> I'm open to argument here, but my thinking is that these should
>> capture 'a' and 'c + d'.
>
>
>
On 04/12/2018 09:52 PM, Chris Angelico wrote:
foo := a > b # does this capture 'a', or 'a > b'?
bar := c + d # 'c' or 'c + d'?
I'm open to argument here, but my thinking is that these should
capture 'a' and 'c + d'.
I think := should act the same as = or there will be plenty of confusion.
12.04.18 22:42, Andrés Delfino пише:
I think the update method can (and personally, should) stay unchanged:
spam.update(dict(x, y))
seems succinct and elegant enough, with the proposed constructor syntax.
Sorry my ignorance, do (Mutable)Mapping ABC say anything about
constructors?
Mapping a
On Fri, Apr 13, 2018 at 2:37 PM, Guido van Rossum wrote:
> Clearly the PEP should spell out the precedence of :=. I'm sure Chris
> intended to give := the lowest possible precedence: the analogy with = (both
> in Python and in other languages), and the original design of the PEP, where
> the synta
[David Mertz ]
> Yes, I have not read all the iterations of the PEP, and none of them
> extremely closely. I had thought it "obvious" that ':=' should have a very
> high operator precedence.
But you don't really believe that ;-) That's the rub. In your specific
None if var:= function() is N
On Fri, Apr 13, 2018 at 2:14 PM, David Mertz wrote:
> Yes, I have not read all the iterations of the PEP, and none of them
> extremely closely. I had thought it "obvious" that ':=' should have a very
> high operator precedence. But of course if it doesn't then expressions like
> the one I proposed
On Fri, Apr 13, 2018 at 1:55 PM, Tim Peters wrote:
> [David Mertz ]
>> Yes, I should have added ternary expressions to if statements. I can
>> definitely see the use there.
>>
>> However, your example is not null checking. You'd have to modify it slightly
>> to get that:
>>
>> None if var:= functi
Clearly the PEP should spell out the precedence of :=. I'm sure Chris
intended to give := the lowest possible precedence: the analogy with =
(both in Python and in other languages), and the original design of the
PEP, where the syntax was ( as ), with mandatory parentheses.
(Probably his implementa
>
> On the third hand, requiring parentheses all the time would also feel
> strained:
>
> while m := someregexp.match(somestring):
>
> is already impossible to misread.
>
> Annoying ;-)
While adding parens to that would be superfluous for the reader of the
module, as a tradeoff for requiri
On Fri, Apr 13, 2018 at 1:00 PM, Thautwarm Zhao wrote:
> I do support this feature, but now I'm worried about the meaning of ':=', it
> seems to be a lazy assignment in some degree. I'm not sure using ':=' is
> proper here.
What do you mean by "lazy"? The assignment happens at the exact point
tha
Yes, I have not read all the iterations of the PEP, and none of them
extremely closely. I had thought it "obvious" that ':=' should have a very
high operator precedence. But of course if it doesn't then expressions like
the one I proposed could mean something quite different.
I find the third hand
[David Mertz ]
> Yes, I should have added ternary expressions to if statements. I can
> definitely see the use there.
>
> However, your example is not null checking. You'd have to modify it slightly
> to get that:
>
> None if var:= function() is None else var.method()
>
> Still not bad looking.
I
> None if var:= function() is None else var.method()
Make sense.
In some specific scenes(maybe general, I'm not sure),
var.method() if var:=function() else var
looks cool although it's not really null checking. It works for Python,
just like use `if lst` to check if the list `lst` is empty.
On Thu, Apr 12, 2018 at 8:22 PM, David Mertz wrote:
> Yes, I should have added ternary expressions to if statements. I can
> definitely see the use there.
>
> However, your example is not null checking. You'd have to modify it
> slightly to get that:
>
> None if var:= function() is None else var.
Yes, I should have added ternary expressions to if statements. I can
definitely see the use there.
However, your example is not null checking. You'd have to modify it
slightly to get that:
None if var:= function() is None else var.method()
Still not bad looking.
On Thu, Apr 12, 2018, 11:01 PM T
> You're looking at a very early commit there. I suggest looking at the
> most recent commits on one of two branches:
https://github.com/Rosuav/cpython/blob/statement-local-
variables/Grammar/Grammar
https://github.com/Rosuav/cpython/blob/assignment-
expressions/Grammar/Grammar
> Those are the tw
It's a slippery slope indeed. While having to change update() alone
wouldn't worry me, the subclass constructors do seem like they are going to
want changing too, and that's indeed a bit much. So let's back off a bit.
Not every three lines of code need a built-in shorthand.
On Thu, Apr 12, 2018 at
On Fri, 13 Apr 2018 at 03:47, M.-A. Lemburg wrote:
> I think moving data out of pyc files is going in a wrong direction:
> more stat calls means slower import and slower startup time.
>
> Trying to make pycs smaller also isn't really worth it (they
> compress quite well).
>
> Saving memory could
Fair enough. I wouldn't actually do what I suggested either. But then, I
also wouldn't ever write:
x1, x2 = (-b + sqrt(D)))/2, (-b - sqrt(D))/2 [with/where/whatever D=...]
If your goal is simply to have symmetry in the plus-or-minus clauses, I was
simply pointing out you can have that with the ':
On Wed, Apr 11, 2018 at 1:41 PM, Steven D'Aprano wrote:
> Personally, I still think the best approach here is a combination of
> itertools.accumulate, and the proposed name-binding as an expression
> feature:
>
> total = 0
> running_totals = [(total := total + x) for x in values]
> # a
I think moving data out of pyc files is going in a wrong direction:
more stat calls means slower import and slower startup time.
Trying to make pycs smaller also isn't really worth it (they
compress quite well).
Saving memory could be done by disabling reading objects lazily
from the file - witho
* correction to example:
moving_average_gen = (average:= moving_average_step(average, x,
decay=decay) for
x in signal from average=initial)
On Thu, Apr 12, 2018 at 3:37 PM, Peter O'Connor
wrote:
> On Wed, Apr 11, 2018 at 10:50 AM, Paul Moore wrote:
>
>> In particular, I'm happiest with the nam
I think the update method can (and personally, should) stay unchanged:
spam.update(dict(x, y))
seems succinct and elegant enough, with the proposed constructor syntax.
Sorry my ignorance, do (Mutable)Mapping ABC say anything about
constructors?
On Thu, Apr 12, 2018 at 12:45 PM, Serhiy Storchak
There's a long thread about the subject:
https://mail.python.org/pipermail/python-ideas/2015-February/031748.html
I suggest to avoid the matter altogether :)
On Thu, Apr 12, 2018 at 4:15 PM, Mike Miller
wrote:
> While we're on the subject, I've tried to add dicts a few times over the
> years to
On Wed, Apr 11, 2018 at 10:50 AM, Paul Moore wrote:
> In particular, I'm happiest with the named moving_average() function,
> which may reflect to some extent my lack of familiarity with the
> subject area. I don't *care* how it's implemented internally - an
> explicit loop is fine with me, but i
While we're on the subject, I've tried to add dicts a few times over the years
to get a new one but it doesn't work:
d3 = d1 + d2 # TypeError
Thinking a bit, set union is probably a better analogue, but it doesn't work
either:
d3 = d1 | d2 # TypeError
Where the last value of any du
I've been playing a bit with this trying to collect some data and measure
how useful this would be. You can take a look at the script I'm using at:
https://github.com/dmoisset/pycstats
What I'm measuring is:
1. Number of objects in the pyc, and how many of those are:
* docstrings (I'm using a h
On Fri, Apr 13, 2018 at 4:01 AM, Thautwarm Zhao wrote:
>> > Makes sense. However, couldn't you prevent that by giving with
>> priority over the binding ? As in "(with simple_cm) as value", where
>> > we consider the "as" as binding operator instead of part of the with
>> > statement ? Sure, you co
> > Makes sense. However, couldn't you prevent that by giving with
> priority over the binding ? As in "(with simple_cm) as value", where
> > we consider the "as" as binding operator instead of part of the with
> > statement ? Sure, you could commit suicide by parenthesis, but by
> > default it'd
> Makes sense. However, couldn't you prevent that by giving with
> priority over the binding ? As in "(with simple_cm) as value", where
> we consider the "as" as binding operator instead of part of the with
> statement ? Sure, you could commit suicide by parenthesis, but by
> default it'd do exact
12.04.18 18:12, Guido van Rossum пише:
I hear where you're coming from but I really don't think we should do
this. If you don't have the right expectation already it's hard to guess
what it means. I would much rather spend effort on a proper matching
statement.
There are few applications of t
09.04.18 00:18, Andrés Delfino пише:
I thought that maybe dict could accept several mappings as positional
arguments, like this:
class Dict4(dict):
def __init__(self, *args, **kwargs):
if len(args) > 1:
if not all([isinstance(arg, dict) for arg in args
12.04.18 17:34, Ed Kellett пише:
It allows for creating a flattened dict from an iterable of dicts, too,
which I've occasionally wanted:
configs = {'a': 'yes'}, {'b': 'no'}, {'c': 3}
dict(*configs)
{'a': 'yes', 'b': 'no', 'c': 3}
versus:
dict(chain.from_iterable(c.items() for c in configs))
I hear where you're coming from but I really don't think we should do this.
If you don't have the right expectation already it's hard to guess what it
means. I would much rather spend effort on a proper matching statement.
On Thu, Apr 12, 2018 at 2:54 AM, Serhiy Storchaka
wrote:
> Yet one crazy
On Thu, Apr 12, 2018 at 7:34 AM, Ed Kellett
wrote:
> On 2018-04-12 14:46, Andrés Delfino wrote:
> > Extending the original idea, IMHO it would make sense for the dict
> > constructor to create a new dictionary not only from several mappings,
> but
> > mixing mappings and iterables too.
> >
> > Co
On 2018-04-12 14:57, Serhiy Storchaka wrote:
> If noddy_name is a Python function, noddy.name() will call
> noddy_name(noddy), but if it is a C function, noddy.name() will call
> noddy_name().
>
> The same is true for classes and custom callables.
FWIW, you could (almost) do this in py2:
>>> cla
On 2018-04-12 14:46, Andrés Delfino wrote:
> Extending the original idea, IMHO it would make sense for the dict
> constructor to create a new dictionary not only from several mappings, but
> mixing mappings and iterables too.
>
> Consider this example:
>
> x = [(1, 'one')]
> y = {2: 'two'}
>
> N
On 2018-04-12 15:57, Serhiy Storchaka wrote:
There is a difference between functions implemented in Python and C.
Functions implemented in Python are descriptors. They can be used for
defining methods in Python classes. Functions implemented in C are not
descriptors. When set a class attribute to
One implementation difficulty specifically related to annotations, is that
they are quite hard to find/extract from the code objects. Both docstrings
and lnotab are within specific fields of the code object for their
function/class/module; annotations are spread as individual constants
(assuming PE
There is a difference between functions implemented in Python and C.
Functions implemented in Python are descriptors. They can be used for
defining methods in Python classes. Functions implemented in C are not
descriptors. When set a class attribute to a functions implemented in C,
it will not
On Thu, Apr 12, 2018 at 11:19 PM, Nick Coghlan wrote:
> On 12 April 2018 at 07:28, Chris Angelico wrote:
>> On Thu, Apr 12, 2018 at 1:22 AM, Nick Coghlan wrote:
Frequently Raised Objections
>>>
>>> There needs to be a subsection here regarding the need to c
Extending the original idea, IMHO it would make sense for the dict
constructor to create a new dictionary not only from several mappings, but
mixing mappings and iterables too.
Consider this example:
x = [(1, 'one')]
y = {2: 'two'}
Now: {**dict(x), **y}
Proposed: dict(x, y)
I think this extensi
On Thu, Apr 12, 2018 at 11:31 PM, Jacco van Dorp wrote:
> 2018-04-12 15:02 GMT+02:00 Nick Coghlan :
>> On 12 April 2018 at 22:22, Jacco van Dorp wrote:
>>> I've looked through PEP 343, contextlib docs (
>>> https://docs.python.org/3/library/contextlib.html ), and I couldn't
>>> find a single case
2018-04-12 15:02 GMT+02:00 Nick Coghlan :
> On 12 April 2018 at 22:22, Jacco van Dorp wrote:
>> I've looked through PEP 343, contextlib docs (
>> https://docs.python.org/3/library/contextlib.html ), and I couldn't
>> find a single case where "with (y := f(x))" would be invalid.
>
> Consider this c
On 12 April 2018 at 07:28, Chris Angelico wrote:
> On Thu, Apr 12, 2018 at 1:22 AM, Nick Coghlan wrote:
>>> Frequently Raised Objections
>>>
>>
>> There needs to be a subsection here regarding the need to call `del`
>> at class and module scope, just as there is for l
On Thu, Apr 12, 2018 at 7:21 PM, Kirill Balunov wrote:
>
> I gain readability! I don't see any reason to use it in other contexts...
> Because it makes the code unreadable and difficult to perceive while giving
> not so much benefit. I may be wrong, but so far I have not seen a single
> example t
On Thu, Apr 12, 2018 at 9:09 PM, Paul Moore wrote:
> On 11 April 2018 at 22:28, Chris Angelico wrote:
>> On Thu, Apr 12, 2018 at 1:22 AM, Nick Coghlan wrote:
>>> This argument will be strengthened by making the examples used in the
>>> PEP itself more attractive, as well as proposing suitable ad
On 12 April 2018 at 22:22, Jacco van Dorp wrote:
> I've looked through PEP 343, contextlib docs (
> https://docs.python.org/3/library/contextlib.html ), and I couldn't
> find a single case where "with (y := f(x))" would be invalid.
Consider this custom context manager:
@contextmanager
de
> On 2018 Apr 12 , at 5:54 a, Serhiy Storchaka wrote:
>
> Yet one crazy idea. What if allow default values for targets in multi-target
> assignment?
>
>>>> (a, b=0) = (1, 2)
>>>> a, b
>(1, 2)
>>>> (a, b=0) = (1,)
>>>> a, b
>(1, 0)
>>>> (a, b=0) = ()
>Traceback (
2018-04-12 13:28 GMT+02:00 Kirill Balunov :
>
>
> 2018-04-12 12:48 GMT+03:00 Jacco van Dorp :
>>
>> Wouldn't these local name bindings make the current "as" clause of
>> "with f(x) as y" completely obsolete ?
>>
>> It's probably good to know my background, and my background is that I
>> know comple
2018-04-12 12:48 GMT+03:00 Jacco van Dorp :
> Wouldn't these local name bindings make the current "as" clause of
> "with f(x) as y" completely obsolete ?
>
> It's probably good to know my background, and my background is that I
> know completely nothing of the implementation, im only junior softwa
On 11 April 2018 at 22:28, Chris Angelico wrote:
> On Thu, Apr 12, 2018 at 1:22 AM, Nick Coghlan wrote:
>> This argument will be strengthened by making the examples used in the
>> PEP itself more attractive, as well as proposing suitable additions to
>> PEP 8, such as:
>>
>> 1. If either assignme
> Finally, loading docstrings and other optional components can be made lazy.
> This was not in my original idea, and this will significantly complicate the
> implementation, but in principle it is possible. This will require larger
> changes in the marshal format and bytecode.
I'm +1 on this idea
10.04.18 19:24, Antoine Pitrou пише:
2. Line numbers (lnotab). They are helpful for formatting tracebacks,
for tracing, and debugging with the debugger. Sources are helpful in
such cases too. If the program doesn't contain errors ;-) and is sipped
without sources, they could be removed.
What is
10.04.18 20:38, Chris Angelico пише:
On Wed, Apr 11, 2018 at 2:14 AM, Serhiy Storchaka wrote:
A deployed Python distribution generally has .pyc files for all of the
standard library. I don't think people want to lose the ability to
call help(), and unless I'm misunderstanding, that requires
docs
Yet one crazy idea. What if allow default values for targets in
multi-target assignment?
>>> (a, b=0) = (1, 2)
>>> a, b
(1, 2)
>>> (a, b=0) = (1,)
>>> a, b
(1, 0)
>>> (a, b=0) = ()
Traceback (most recent call last):
File "", line 1, in
ValueError: not e
Wouldn't these local name bindings make the current "as" clause of
"with f(x) as y" completely obsolete ?
It's probably good to know my background, and my background is that I
know completely nothing of the implementation, im only junior software
engineer, and python was my first programming exper
2018-04-12 1:43 GMT+03:00 Chris Angelico :
> On Thu, Apr 12, 2018 at 5:24 AM, Kirill Balunov
> wrote:
> > I find that I wrote very vague, so I'll try in response to my answer to
> add
> > some specifics. In general, I find this idea missed in the language and
> > thank you for trying to fix this!
On 11 April 2018 at 23:09, Brendan Barnwell wrote:
> On 2018-04-11 11:05, David Mertz wrote:
>
>> How about this, Brendan?
>>
>> _, x1, x2 = (D := b**2 - 4*a*c), (-b + sqrt(D))/2, (-b - sqrt(D))/2
>>
>> I'm not sure I love this, but I don't hate it.
>>
>
> That's clever, but why bother?
59 matches
Mail list logo
