On 10/04/2018 18:54, 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 misunderstanding, that
On Wed, Apr 11, 2018 at 3:54 PM, Ethan Furman wrote:
> 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 case
I think Guido has given a direct answer why dict unpacking is not supported
in syntax level,
I can take it and I think it's better to implement a function for dict
unpacking in standard library, just like
from dict_unpack import dict_unpack, pattern as pat
some_dict = {'a': {'b': {'c': 1},
On Wed, Apr 11, 2018 at 02:21:17PM +1000, Chris Angelico wrote:
[...]
> > Yes, it will double the number of files. Actually quadruple it, if the
> > annotations and line numbers are in separate files too. But if most of
> > those extra files never need to be opened, then there's no cost to them.
>
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 th
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 c
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 one hand, we have a f
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 goog
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
> readable:
>
> dict(d1
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
>> in how long it takes to
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
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 m
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
Those people who say "x = x + 1
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 argued that writing
> *functi
[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 a list comprehension in
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 complic
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 meas
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
___
Pytho
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 auto-generated help, so we need to
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 use annotations at r
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 help(), and unless I'm
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 option
> > that allows
>> 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
___
Pyt
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 pyc
> files. It is expe
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 function didn't
provide all
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 too,
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 library. I don't think people want to lose t
>
> 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.
In
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,
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 t
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 misunderstanding, that requir
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 this will mean twice
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 files. It is
> expected
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
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 changing the
> bytecode.
[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: w
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 correct but compatible byte
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 pyc
> files. It is expe
>
> 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, where
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 t
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' launcher
> and third-p
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).
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 t
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 e
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 a
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 b
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 [(1-deca
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 lan
48 matches
Mail list logo
