Re: [Python-ideas] Is there any idea about dictionary destructing?

On Tue, Apr 10, 2018 at 03:29:08PM +0800, Thautwarm Zhao wrote: > I'm focused on the consistency of the language itself. Consistency is good, but it is not the only factor to consider. We must guard against *foolish* consistency: adding features just for the sake of matching some other, often

Re: [Python-ideas] Is there any idea about dictionary destructing?

I must say I can't really see the point either. If you say like: > {'a': a, 'b': b, **c} = {'a': 1, **{'b': 2}} Do you basically mean: c = {'a': 1, **{'b': 2}} a = c.pop("a") b = c.pop("b") # ? That's the only thing I could think of. I think most of these problems could be solved with pop

Re: [Python-ideas] Start argument for itertools.accumulate() [Was: Proposal: A Reduce-Map Comprehension and a "last" builtin]

On Mon, Apr 9, 2018 at 11:35 PM, Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Tim Peters writes: > > > "Sum reduction" and "running-sum accumulation" are primitives in > > many peoples' brains. > > I wonder what Kahneman would say about that. He goes to some length > to

Re: [Python-ideas] Is there any idea about dictionary destructing?

Here's one argument why sequence unpacking is more important than dict unpacking. Without sequence unpacking, you have a long sequence, to get at a specific item you'd need to use indexing, where you often end up having to remember the indices for each type of information. Say you have points of

[Python-ideas] Add more information in the header of pyc files

The format of the header of pyc files was stable for long time and changed only few times. First time it was changed in 3.3: added the size of the corresponding source mod 2**32. [1] Second time it was changed in 3.7: added the 32-bit flags field and support of hash-based pyc files (PEP 552).

Re: [Python-ideas] Move optional data out of pyc files

On Wed, Apr 11, 2018 at 2:14 AM, Serhiy Storchaka wrote: > Currently pyc files contain data that is useful mostly for developing and is > not needed in most normal cases in stable program. There is even an option > that allows to exclude a part of this information from pyc

[Python-ideas] Move optional data out of pyc files

Currently pyc files contain data that is useful mostly for developing and is not needed in most normal cases in stable program. There is even an option that allows to exclude a part of this information from pyc files. It is expected that this saves memory, startup time, and disk space (or the

Re: [Python-ideas] Start argument for itertools.accumulate() [Was: Proposal: A Reduce-Map Comprehension and a "last" builtin]

[Tim] > Woo hoo! Another coincidence. I just happened to be playing with > this problem today: > > You have a large list - xs - of N numbers. It's necessary to compute slice > sums > > sum(xs[i:j]) > > for a great many slices, 0 <= i <= j <= N. Which brought to mind a different problem:

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Tue, Apr 10, 2018 at 12:18:27PM -0400, Peter O'Connor wrote: [...] > I added your coroutine to the freak show: Peter, I realise that you're a fan of functional programming idioms, and I'm very sympathetic to that. I'm a fan of judicious use of FP too, and while I'm not keen on your specific

Re: [Python-ideas] Move optional data out of pyc files

On Tue, 10 Apr 2018 19:14:58 +0300 Serhiy Storchaka wrote: > Currently pyc files contain data that is useful mostly for developing > and is not needed in most normal cases in stable program. There is even > an option that allows to exclude a part of this information from

Re: [Python-ideas] Add more information in the header of pyc files

On Tue, 10 Apr 2018 18:49:36 +0300 Serhiy Storchaka wrote: > > 1. More stable file signature. Currently the magic number is changed in > every feature release. Only the third and the forth bytes are stable > (b'\r\n'), the first bytes are changed non-predicable. The 'py'

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

> > First, why a class would be a bad thing ? It's clear, easy to > understand, debug and extend. - Lots of reduntand-looking "frameworky" lines of code: "self._param_1 = param_1" - Potential for opaque state changes: Caller doesn't know if "y=my_object.do_something(x)" has any side-effect,

Re: [Python-ideas] Add more information in the header of pyc files

On Tue, 10 Apr 2018 19:29:18 +0300 Serhiy Storchaka wrote: > > A bugfix release can fix bugs in bytecode generation. See for example > issue27286. [1] The part of issue33041 backported to 3.7 and 3.6 is an > other example. [2] There were other examples of compatible

Re: [Python-ideas] Move optional data out of pyc files

On Tue, Apr 10, 2018 at 12:38 PM, Chris Angelico 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 > docstrings. So

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

> > But even I find your use of dysphemisms like "freak show" for non-FP > solutions quite off-putting. Ah, I'm sorry, "freak show" was not mean to be disparaging to the authors or even the code itself, but to describe the variety of strange solutions (my own included) to this simple problem.

Re: [Python-ideas] Move optional data out of pyc files

On Tue, 10 Apr 2018 11:13:01 -0700 Ethan Furman wrote: > On 04/10/2018 10:54 AM, Zachary Ware wrote: > > On Tue, Apr 10, 2018 at 12:38 PM, Chris Angelico wrote: > >> A deployed Python distribution generally has .pyc files for all of the > >> standard

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 10/04/18 18:32, Steven D'Aprano wrote: On Tue, Apr 10, 2018 at 12:18:27PM -0400, Peter O'Connor wrote: [...] I added your coroutine to the freak show: Peter, I realise that you're a fan of functional programming idioms, and I'm very sympathetic to that. I'm a fan of judicious use of FP

Re: [Python-ideas] Move optional data out of pyc files

>> 3. Annotations. They are used mainly by third party tools that >> statically analyze sources. They are rarely used at runtime. > > Even less used than docstrings probably. typing.NamedTuple and dataclasses use annotations at runtime. Eric ___

Re: [Python-ideas] Move optional data out of pyc files

There are libraries out there like this: https://docopt.readthedocs.io/en/0.2.0/ which use docstrings for runtime info. Today we already have -OO which allows us to create docstring-less bytecode files in case we have, after careful consideration, established that it is safe to do so. I think

Re: [Python-ideas] Move optional data out of pyc files

I'm not sure I understand the benefit of this, perhaps you can clarify. What I see is two scenarios Scenario A) External files are present In this case, the data is loaded from the pyc and then from external file, so there are no savings in memory, startup time, disk space, or network load time,

Re: [Python-ideas] Move optional data out of pyc files

On Tue, 10 Apr 2018 19:14:58 +0300 Serhiy Storchaka wrote: > Currently pyc files contain data that is useful mostly for developing > and is not needed in most normal cases in stable program. There is even > an option that allows to exclude a part of this information from

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 10 April 2018 at 19:25, Peter O'Connor wrote: > Kyle Lahnakoski made a pretty good case for not using itertools.accumulate() > earlier in this thread I wouldn't call it a "pretty good case". He argued that writing *functions* was a bad thing, because the name of a

Re: [Python-ideas] Move optional data out of pyc files

On 04/10/2018 10:54 AM, Zachary Ware wrote: On Tue, Apr 10, 2018 at 12:38 PM, Chris Angelico 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

Re: [Python-ideas] Add more information in the header of pyc files

10.04.18 18:58, Antoine Pitrou пише: On Tue, 10 Apr 2018 18:49:36 +0300 Serhiy Storchaka wrote: 3. The number of compatible subversion. Currently the interpreter supports only a single magic number. If the updated version of the compiler produces more optimal or more

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

Le 10/04/2018 à 00:54, Peter O'Connor a écrit : > Kyle, you sounded so reasonable when you were trashing > itertools.accumulate (which I now agree is horrible).  But then you go > and support Serhiy's madness:  "smooth_signal = [average for average in > [0] for x in signal for average in

Re: [Python-ideas] Accepting multiple mappings as positional arguments to create dicts

On Wed, Apr 11, 2018 at 02:22:08PM +1000, Chris Angelico wrote: > > dict(d1, d2, d3) > > That's more readable than {**d1, **d2, **d3} ? Doesn't look materially > different to me. It does to me. On the one hand, we have a function call (okay, technically a type...) "dict()" that can be

Re: [Python-ideas] Accepting multiple mappings as positional arguments to create dicts

On Wed, Apr 11, 2018 at 2:44 PM, Steven D'Aprano wrote: > On Wed, Apr 11, 2018 at 02:22:08PM +1000, Chris Angelico wrote: > >> > dict(d1, d2, d3) >> >> That's more readable than {**d1, **d2, **d3} ? Doesn't look materially >> different to me. > > It does to me. > > On the

[Python-ideas] PEP 572: Assignment Expressions (post #4)

Wholesale changes since the previous version. Statement-local name bindings have been dropped (I'm still keeping the idea in the back of my head; this PEP wasn't the first time I'd raised the concept), and we're now focusing primarily on assignment expressions, but also with consequent changes to

Re: [Python-ideas] PEP 572: Assignment Expressions (post #4)

On 04/10/2018 10:32 PM, Chris Angelico wrote: Migration path == The semantic changes to list/set/dict comprehensions, and more so to generator expressions, may potentially require migration of code. In many cases, the changes simply make legal what used to raise an exception, but

Re: [Python-ideas] Is there any idea about dictionary destructing?

Your library seems difficult to extract values from nested dictionary, and when the key is not an identifier it's also embarrassed. For sure we can have a library using graphql syntax to extract data from the dict of any schema, but that's not my point. I'm focused on the consistency of the

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

Greg Ewing writes: > Kyle Lahnakoski wrote: > > > Consider Serhiy Storchaka's elegant solution, which I reformatted for > > readability > > > >>smooth_signal = [ > >> average > >>for average in [0] > >>for x in signal > >> for average in [(1-decay)*average + decay*x] >

Re: [Python-ideas] Start argument for itertools.accumulate() [Was: Proposal: A Reduce-Map Comprehension and a "last" builtin]

Tim Peters writes: > "Sum reduction" and "running-sum accumulation" are primitives in > many peoples' brains. I wonder what Kahneman would say about that. He goes to some length to explain that people are quite good (as human abilities go) at perceiving averages over sets but terrible at

Re: [Python-ideas] Move optional data out of pyc files

On Tue, Apr 10, 2018 at 5:03 PM, Steven D'Aprano wrote: > > __pycache__/spam.cpython-38.pyc > __pycache__/spam.cpython-38-doc.pyc > __pycache__/spam.cpython-38-lno.pyc > __pycache__/spam.cpython-38-ann.pyc > ​Our product uses the doc strings for

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

If anyone is interested I came across this same subject on a blog post and discussion on HN today: - https://www.hillelwayne.com/post/equals-as-assignment/ - https://news.ycombinator.com/item?id=16803874 On 2018-04-02 15:03, Guido van Rossum wrote: IIRC Algol-68 (the lesser-known, more

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

[Jacco van Dorp ] > I've sometimes thought that exhaust(iterator) or iterator.exhaust() would be > a good thing to have - I've often wrote code doing basically "call this > function > for every element in this container, and idc about return values", but find > myself using

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Tue, Apr 10, 2018 at 08:12:14PM +0100, Paul Moore wrote: > On 10 April 2018 at 19:25, Peter O'Connor wrote: > > Kyle Lahnakoski made a pretty good case for not using > > itertools.accumulate() earlier in this thread > > I wouldn't call it a "pretty good case". He

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Wed, Apr 11, 2018 at 1:15 PM, Mike Miller wrote: > If anyone is interested I came across this same subject on a blog post and > discussion on HN today: > > - https://www.hillelwayne.com/post/equals-as-assignment/ > - https://news.ycombinator.com/item?id=16803874

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 2018-04-08 10:41, Kyle Lahnakoski wrote: For example before I read the docs on itertools.accumulate(list_of_length_N, func), here are the unknowns I see: It sounds like you're saying you don't like using functions because you have to read documentation. That may be so, but I don't have

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

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

Re: [Python-ideas] Move optional data out of pyc files

On Wed, Apr 11, 2018 at 1:02 PM, Steven D'Aprano wrote: > On Wed, Apr 11, 2018 at 10:08:58AM +1000, Chris Angelico wrote: > >> File system limits aren't usually an issue; as you say, even FAT32 can >> store a metric ton of files in a single directory. I'm more interested >>

Re: [Python-ideas] Accepting multiple mappings as positional arguments to create dicts

On Wed, Apr 11, 2018 at 11:19 AM, Mike Miller wrote: > > On 2018-04-09 04:23, Daniel Moisset wrote: >> >> In which way would this be different to {**mapping1, **mapping2, >> **mapping3} ? > > > That's possible now, but believe the form mentioned previously would be more

Re: [Python-ideas] Move optional data out of pyc files

On Tue, Apr 10, 2018 at 12:51 PM Eric V. Smith wrote: > > >> 3. Annotations. They are used mainly by third party tools that > >> statically analyze sources. They are rarely used at runtime. > > > > Even less used than docstrings probably. > > typing.NamedTuple and dataclasses

Re: [Python-ideas] Accepting multiple mappings as positional arguments to create dicts

On 2018-04-09 04:23, Daniel Moisset wrote: In which way would this be different to {**mapping1, **mapping2, **mapping3} ? That's possible now, but believe the form mentioned previously would be more readable: dict(d1, d2, d3) -Mike ___

Re: [Python-ideas] Move optional data out of pyc files

On Wed, Apr 11, 2018 at 03:38:08AM +1000, Chris Angelico wrote: > On Wed, Apr 11, 2018 at 2:14 AM, Serhiy Storchaka wrote: > > Currently pyc files contain data that is useful mostly for developing and is > > not needed in most normal cases in stable program. There is even an

Re: [Python-ideas] Move optional data out of pyc files

On Wed, Apr 11, 2018 at 10:03 AM, Steven D'Aprano wrote: > On Wed, Apr 11, 2018 at 03:38:08AM +1000, Chris Angelico 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

Re: [Python-ideas] Move optional data out of pyc files

On Wed, Apr 11, 2018 at 10:08:58AM +1000, Chris Angelico wrote: > File system limits aren't usually an issue; as you say, even FAT32 can > store a metric ton of files in a single directory. I'm more interested > in how long it takes to open a file, and whether doubling that time > will have a