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

[Chris Angelico]

On Tue, Apr 17, 2018 at 1:54 PM, Ethan Furman  wrote:
> On 04/10/2018 10:32 PM, Chris Angelico wrote:
>
>> PEP: 572
>> Title: Assignment Expressions
>> Author: Chris Angelico 
>
>
> Chris, I think you've gotten all the feedback you need.  Pick a symbol (I'd
> say either ":=" or "as"), and slap this puppy over onto python-dev.
>

Yep, sounds about right. I'm actually still toying with a couple of
points of grammar to see if I can smooth out some of the annoying
bits, and then I think the proposal is done with -ideas.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

On Mon, Apr 16, 2018 at 8:09 PM, Thautwarm Zhao 
wrote:
>
>  > 3) "target ? expr" (where ? is some other word/character -  IIRC
>  >  "target from expr" was proposed once)
>
> A more popular convention is to mark `?` as handling boolean variables, so
> `target ? expr` could mean `expr if target else target`. Other proposal for
> null/boolean checking might need `?`, let's preserve `?` character for
> further development.
>

The only acceptable use of ? is formulated in PEP 505.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ethan Furman]

On 04/10/2018 10:32 PM, Chris Angelico wrote:


PEP: 572
Title: Assignment Expressions
Author: Chris Angelico 


Chris, I think you've gotten all the feedback you need.  Pick a symbol (I'd say either ":=" or "as"), and slap this 
puppy over onto python-dev.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Thautwarm Zhao]

 > We have ways of cheating a bit if we want to reinterpret the semantics
> of something that nevertheless parses cleanly - while the parser is
> limited to single token lookahead, it's straightforward for the
> subsequent code generation stage to look a single level down in the
> parse tree and see that the code that parsed as "with expr" is
> actually "with subexpr as target".

It does work, however I think it does sound like a patch, and definitely it
will block us to make other extensions in the future.

 > 3) "target ? expr" (where ? is some other word/character -  IIRC
 >  "target from expr" was proposed once)

A more popular convention is to mark `?` as handling boolean variables, so
`target ? expr` could mean `expr if target else target`. Other proposal for
null/boolean checking might need `?`, let's preserve `?` character for
further development.


> How about "name being expression" - this avoids the already used "as"
> while being searchable, reasonably short and gives a reasonably clear,
> (at least to English speakers), indication of what is going on. It can
> also be typed on an ASCII keyboard without having to have a helper
> program or memorising Unicode codes and can be displayed or printed
> without having to install specialised fonts.

It makes sense, if we don't have a long history in Python programming...
A new keyword would be something very dangerous, because it just causes the
crash of some existed library using the keyword as identifier.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Gregory P. Smith]

On Mon, Apr 16, 2018 at 11:11 AM Ned Batchelder 
wrote:

> On 4/16/18 1:42 PM, Chris Angelico wrote:
> > 3) "expr -> name" ==> The information went data way.
> >
> > So either you take a parallel from elsewhere in Python syntax, or you
> > take a hopefully-intuitive dataflow mnemonic symbol. Take your pick.
>
> My problem with the "->" option is that function annotations already use
> "->" to indicate the return type of a function.  This is an unfortunate
> parallel from elsewhere in Python syntax, since the meaning is
> completely different.
>
> ":=" is at least new syntax.
>
> "as" is nice in that it's already used for assignment, but seems to be
> causing too much difficulty in parsing, whether by compilers or people.
>
>
FWIW - We used "as" in our Python C++ binding interface description
language in CLIF to denote renaming from the original C++ name to a new
name in Python - effectively an assignment syntax.
   https://github.com/google/clif/blob/master/clif/python/primer.md

I currently have a "-0" opinion on the entire PEP 572 as I don't buy that
assignments within expressions are even a good thing to have in the
language.  #complexity - Think of people learning the language.

-gps
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] collections.Counter should implement __mul__, __rmul__

[Tim Peters]

[Tim]
>> I also have no problem with inplace operators.  Or with adding
>> `Counter /= scalar", for that matter.

[Raymond]
> But surely __rdiv__() would be over the top, harmonic means be damned ;-)

Agreed - itertools.Counter is the poster child for "practicality beats
purity" :-)

In context, the

c *= 1 / c.total

example would clearly be useful at times.  But it's a strained way to spell

c /= c.total

and, for float values, the former also introduces a needless rounding
error (to compute the reciprocal).

BTW, if _`Counter * scalar` is added, we should think more about
oddball cases.  While everyone knows what _they_ mean by "scalar",
Python doesn't.  The obvious implementation (Peter already gave it)
would lead to things like `Counter * Counter`, where both
multiplicands have integer values, yielding a Counter whose values are
also Counters.

That is, if

c = Counter(a=1, b=2)
d = Counter(a=3, b=4)

then c*d would yield a Counter mapping 'a` to 1 * d == d, and 'b' to 2
* d == Counter(a=6, b=8).

That's "bad", because the next suggestion will be that c*d return
Counter(a=3, b=8) instead.  That is, map a shared key to the product
of the values associated with that key.  For example, `c` is a Counter
tabulating category counts, and `d` a Counter giving category weights.

I don't suggest doing that now, but it would be nice to dream up a way
to stop "things like" Counter * Counter at the start so that backward
compatibility doesn't preclude adding sensible meanings later.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Danilo J. S. Bellini]

On 16 April 2018 at 10:49, Peter O'Connor 
wrote:

> Are you able to show how you'd implement the moving average example with
> your package?
>

Sure! The single pole IIR filter you've shown is implemented here:
https://github.com/danilobellini/pyscanprev/blob/master/examples/iir-filter.rst

I tried:
>
> @enable_scan("average")
> def exponential_moving_average_pyscan(signal, decay, initial=0):
> yield from ((1-decay)*(average or initial) + decay*x for x in
> signal)
>
>
> smooth_signal_9 = list(exponential_moving_average_pyscan(signal,
> decay=decay))[1:]
>
> Which almost gave the right result, but seemed to get the initial
> conditions wrong.
>

I'm not sure what you were expecting. A sentinel as the first "average"
value?

Before the loop begins, this scan-generator just echoes the first input,
like itertools.accumulate.
That is, the first value this generator yields is the first "signal" value,
which is then the first "average" value.

To put an initial memory state, you should do something like this (I've
removed the floating point trailing noise):

>>> from pyscanprev import enable_scan, prepend
>>>
>>> @enable_scan("y")
>>> def iir_filter(signal, decay, memory=0):
... return ((1 - decay) * y + decay * x for x in prepend(memory,
signal))
...
>>> list(iir_filter([1, 2, 3, 2, 1, -1, -2], decay=.1, memory=5))
[5, 4.6, 4.34, 4.206, 3.9854, 3.68686, 3.218174, 2.6963566]

In that example, "y" is the "previous result" (a.k.a. accumulator, or what
had been called "average" here).

--
Danilo J. S. Bellini
---
"*It is not our business to set up prohibitions, but to arrive at
conventions.*" (R. Carnap)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

On Tue, Apr 17, 2018 at 5:11 AM, Steve Barnes  wrote:
>
>> Here are the three most popular syntax options, and how each would be 
>> explained:
>>
>> 1) "target := expr" ==> It's exactly the same as other forms of
>> assignment, only now it's an expression.
>> 2) "expr as name" ==> It's exactly the same as other uses of "as",
>> only now it's just grabbing the preceding expression, not actually
>> doing anything with it
>> 3) "expr -> name" ==> The information went data way.
>>
>> So either you take a parallel from elsewhere in Python syntax, or you
>> take a hopefully-intuitive dataflow mnemonic symbol. Take your pick.
>
> How about "name being expression" - this avoids the already used "as"
> while being searchable, reasonably short and gives a reasonably clear,
> (at least to English speakers), indication of what is going on. It can
> also be typed on an ASCII keyboard without having to have a helper
> program or memorising Unicode codes and can be displayed or printed
> without having to install specialised fonts.
>
> If a postfix notation is considered desirable, either instead or as well
> as "being", then possibly another synonym would suit such as "expression
> stored_as name" or "expression storedas name" (not apologies for the
> awkward name as I personally find it an awkward construction just like
> Reverse Polish).

IMO searchability isn't enough of an advantage to justify creating a
new keyword, which could potentially break people's code. (I don't
think it'll break the stdlib, but it'll almost certainly break at
least some code out there.) New keywords have an extremely high bar to
reach.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ned Batchelder]

On 4/16/18 1:42 PM, Chris Angelico wrote:

3) "expr -> name" ==> The information went data way.

So either you take a parallel from elsewhere in Python syntax, or you
take a hopefully-intuitive dataflow mnemonic symbol. Take your pick.


My problem with the "->" option is that function annotations already use 
"->" to indicate the return type of a function.  This is an unfortunate 
parallel from elsewhere in Python syntax, since the meaning is 
completely different.


":=" is at least new syntax.

"as" is nice in that it's already used for assignment, but seems to be 
causing too much difficulty in parsing, whether by compilers or people.


--Ned.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ethan Furman]

On 04/16/2018 10:36 AM, Chris Angelico wrote:


Not after it got trimmed, no. Here's what I actually said in my original post:

while (read_next_item() -> items[i + 1 -> i]) is not None:
 print("%d/%d..." % (i, len(items)), end="\r")

Now, if THAT is your assignment target, are you still as happy as you
had been, or are you assuming that the target is a simple name?


I'm okay with it, although I'd still prefer "as".  But, really, as long as we 
get it* I'll be happy.

--
~Ethan~


* "it" being, of course, assignment-expressions.  :)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

On Mon, Apr 16, 2018 at 11:05 PM, Mikhail V  wrote:
> Lets just return to some of proposed examples
> (I use "=" in both examples to be less biased here):
>
> 1.
> if  ( match = re.match("foo", S) ) == True:
> print("match:", match)
>
> 2.
> if  ( re.match("foo", S) = match ) == True:
> print("match:", match)
>
>
> Now seriously, you may argue around those "pronounce"
> theoretical bla bla, like "take the result and save it in a token".
> But the variant 1. is just better, because _it is what it is in Python_.

You start by attempting to be less biased, but you're using existing
Python syntax and then justifying one of the two options because it's
existing Python syntax. I'm not sure that that's a strong argument :)

> So it is better not because it is better looking or whatever,
> it is same sh** turned around. So just don't turn it around!

Obviously if the chosen token is ":=", it's going to be target first.

> When I read code I don't have all those things
> you describe in a millisecond :
> - look at the pointy end of operator
> - think, oh this shows to the right
> - seems like I save the value there
> - yep, that's the way I imply things to work
> - stroking the belly
> 
>
> Instead I just parse visually some smaller parts
> of code and it's just better if the assignment is in the same
> order as everywhere.
> Yes, in some single case one order can look better,
> but in this case it's just not good to mix those.

Here are the three most popular syntax options, and how each would be explained:

1) "target := expr" ==> It's exactly the same as other forms of
assignment, only now it's an expression.
2) "expr as name" ==> It's exactly the same as other uses of "as",
only now it's just grabbing the preceding expression, not actually
doing anything with it
3) "expr -> name" ==> The information went data way.

So either you take a parallel from elsewhere in Python syntax, or you
take a hopefully-intuitive dataflow mnemonic symbol. Take your pick.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

On Sat, 14 Apr 2018 at 17:01 Neil Schemenauer 
wrote:

> On 2018-04-12, M.-A. Lemburg wrote:
> > This leaves the proposal to restructure pyc files into a sectioned
> > file and possibly indexed file to make access to (lazily) loaded
> > parts faster.
>
> I would like to see a format can hold one or more modules in a
> single file.  Something like the zip format but optimized for fast
> interpreter startup time.  It should support lazy loading of module
> parts (e.g. maybe my lazy bytecode execution idea[1]).  Obviously a
> lot of details to work out.
>

Eric Snow, Barry Warsaw, and I chatted about a custom file format for
holding Python source (and data files). My notes on the chat can be found
at
https://notebooks.azure.com/Brett/libraries/design-ideas/html/Python%20source%20archive%20file%20format.ipynb
. (And since we aren't trying to rewrite bytecode we figured it wouldn't
break your proposal, Neil ;) .

-Brett


>
> The design should also take into account the widespread use of
> virtual environments.  So, it should be easy and space efficient to
> build virtual environments using this format (e.g. maybe allow
> overlays so that stdlib package is not copied into virtual
> environment, virtual packages would be overlaid on stdlib file).
> Also, should be easy to bundle all modules into a "uber" package and
> append it to the Python executable.  CPython should provide
> out-of-box support for single-file executables.
>
>
> 1. https://github.com/python/cpython/pull/6194
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Idea: Importing from arbitrary filenames

[Brett Cannon]

On Mon, 16 Apr 2018 at 09:58 Eric Fahlgren  wrote:

> The documentation is pretty opaque or non-existent on other aspects of
> importlib use, too.
>

Well, we are diving into the dark corners of import here. (Details can be
found in the language reference:
https://docs.python.org/3/reference/import.html).


>   If I enable warnings, I see this (and many more like it).  I've read PEP
> 302 a couple times, read the code in importlib that detects the warning and
> searched down several rabbit holes, only to come up empty...
>
> T:\Python36\lib\importlib\_bootstrap.py:219: ImportWarning: can't resolve
> package from __spec__ or __package__, falling back on __name__ and __path__
>
> My thoughts when I see it: "Ok.  So what does that mean?
>

It means that the mechanisms import typically uses to calculate the
importing module's name in order to resolve relative imports wasn't where
it should be, and so we fell back to the Python 2 way of doing it.


>   Is it bad?
>

Eh, it isn't ideal. ;)


>   It must be bad, otherwise I wouldn't get a warning.  How do I reconcile
> __spec__ and __package__?
>

You should be setting __spec__.parent, but we will fall back to __package__
if that doesn't exist (and raise a different warning). :)


>   Which one is missing and/or incorrect?"
>

Both are missing. :)

-Brett


>
>
> On Mon, Apr 16, 2018 at 9:36 AM, Paul Moore  wrote:
>
>> On 16 April 2018 at 17:22, Nick Coghlan  wrote:
>> > If we're not covering explicit __path__ manipulation anywhere, we
>> > should definitely mention that possibility.
>> > https://docs.python.org/3/library/pkgutil.html#pkgutil.extend_path
>> > does talk about it, but only in the context of scanning sys.path for
>> > matching names, not in the context of building a package from an
>> > arbitrary set of directory names.
>>
>> It's quite possible that we're not.
>>
>> > I'm not sure where we could put an explanation of some of the broader
>> > implications of that fact, though - while __path__ manipulation is
>> > usually fairly safe, we're always a little hesitant about encouraging
>> > too many dynamic modifications to the import system state, since it
>> > can sometimes have odd side effects based on whether imports happen
>> > before or after that state is adjusted..
>>
>> One of the problems with PEP 302 was that there was no really good
>> place in the documentation to put all the information that was present
>> (certainly not in the version of the docs that was around when we
>> wrote it). So a lot of the important details remained buried in PEP
>> 302. Since then, a lot of the details ended up in the docs, mostly in
>> the importlib sections, but I don't recall ever seeing anything about
>> __path__ (and particularly not the nice summary you gave, "packages
>> are ultimately just modules with a
>> __path__ attribute that works like sys.path".
>>
>> Paul
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Idea: Importing from arbitrary filenames

[Eric Fahlgren]

The documentation is pretty opaque or non-existent on other aspects of
importlib use, too.  If I enable warnings, I see this (and many more like
it).  I've read PEP 302 a couple times, read the code in importlib that
detects the warning and searched down several rabbit holes, only to come up
empty...

T:\Python36\lib\importlib\_bootstrap.py:219: ImportWarning: can't resolve
package from __spec__ or __package__, falling back on __name__ and __path__

My thoughts when I see it: "Ok.  So what does that mean?  Is it bad?  It
must be bad, otherwise I wouldn't get a warning.  How do I reconcile
__spec__ and __package__?  Which one is missing and/or incorrect?"


On Mon, Apr 16, 2018 at 9:36 AM, Paul Moore  wrote:

> On 16 April 2018 at 17:22, Nick Coghlan  wrote:
> > If we're not covering explicit __path__ manipulation anywhere, we
> > should definitely mention that possibility.
> > https://docs.python.org/3/library/pkgutil.html#pkgutil.extend_path
> > does talk about it, but only in the context of scanning sys.path for
> > matching names, not in the context of building a package from an
> > arbitrary set of directory names.
>
> It's quite possible that we're not.
>
> > I'm not sure where we could put an explanation of some of the broader
> > implications of that fact, though - while __path__ manipulation is
> > usually fairly safe, we're always a little hesitant about encouraging
> > too many dynamic modifications to the import system state, since it
> > can sometimes have odd side effects based on whether imports happen
> > before or after that state is adjusted..
>
> One of the problems with PEP 302 was that there was no really good
> place in the documentation to put all the information that was present
> (certainly not in the version of the docs that was around when we
> wrote it). So a lot of the important details remained buried in PEP
> 302. Since then, a lot of the details ended up in the docs, mostly in
> the importlib sections, but I don't recall ever seeing anything about
> __path__ (and particularly not the nice summary you gave, "packages
> are ultimately just modules with a
> __path__ attribute that works like sys.path".
>
> Paul
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Idea: Importing from arbitrary filenames

[Paul Moore]

On 16 April 2018 at 17:22, Nick Coghlan  wrote:
> If we're not covering explicit __path__ manipulation anywhere, we
> should definitely mention that possibility.
> https://docs.python.org/3/library/pkgutil.html#pkgutil.extend_path
> does talk about it, but only in the context of scanning sys.path for
> matching names, not in the context of building a package from an
> arbitrary set of directory names.

It's quite possible that we're not.

> I'm not sure where we could put an explanation of some of the broader
> implications of that fact, though - while __path__ manipulation is
> usually fairly safe, we're always a little hesitant about encouraging
> too many dynamic modifications to the import system state, since it
> can sometimes have odd side effects based on whether imports happen
> before or after that state is adjusted..

One of the problems with PEP 302 was that there was no really good
place in the documentation to put all the information that was present
(certainly not in the version of the docs that was around when we
wrote it). So a lot of the important details remained buried in PEP
302. Since then, a lot of the details ended up in the docs, mostly in
the importlib sections, but I don't recall ever seeing anything about
__path__ (and particularly not the nice summary you gave, "packages
are ultimately just modules with a
__path__ attribute that works like sys.path".

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Nick Coghlan]

On 16 April 2018 at 00:27, Thautwarm Zhao  wrote:
> Personally I prefer "as", but I think without a big change of python Grammar
> file, it's impossible to avoid parsing "with expr as name" into "with (expr
> as name)" because "expr as name" is actually an "expr".
> I have mentioned this in previous discussions and it seems it's better to
> warn you all again. I don't think people of Python-Dev are willing to
> implement a totally new Python compiler.

We have ways of cheating a bit if we want to reinterpret the semantics
of something that nevertheless parses cleanly - while the parser is
limited to single token lookahead, it's straightforward for the
subsequent code generation stage to look a single level down in the
parse tree and see that the code that parsed as "with expr" is
actually "with subexpr as target".

So the main concern around "with (name as expr)" is with human readers
getting confused, not the compiler, as we can tell the latter to
implement whichever semantics we decide we want, while humans are far
less tractable :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Idea: Importing from arbitrary filenames

[Nick Coghlan]

On 16 April 2018 at 03:45, Steve Barnes  wrote:
> On 15/04/2018 08:12, Nick Coghlan wrote:
>> The discoverability of these kinds of techniques could definitely
>> stand to be improved, but the benefit of adopting them is that they
>> work on all currently supported versions of Python (even
>> importlib.import_module exists in Python 2.7 as a convenience wrapper
>> around __import__), rather than needing to wait for new language level
>> syntax for them.
>
> As you say not too discoverable at the moment - I have just reread
> PEP328 & https://docs.python.org/3/library/importlib.html but did not
> find any mention of these mechanisms or even that setting an external
> __path__ variable existed as a possibility.

Yeah, the fact that "packages are ultimately just modules with a
__path__ attribute that works like sys.path" tends to get obscured by
the close association between package hierarchies and file system
layouts in the default filesystem importer.

The docs for that are all the way back in PEP 302:
https://www.python.org/dev/peps/pep-0302/#packages-and-the-role-of-path

> Maybe a documentation enhancement proposal would be in order?

If we're not covering explicit __path__ manipulation anywhere, we
should definitely mention that possibility.
https://docs.python.org/3/library/pkgutil.html#pkgutil.extend_path
does talk about it, but only in the context of scanning sys.path for
matching names, not in the context of building a package from an
arbitrary set of directory names.

I'm not sure where we could put an explanation of some of the broader
implications of that fact, though - while __path__ manipulation is
usually fairly safe, we're always a little hesitant about encouraging
too many dynamic modifications to the import system state, since it
can sometimes have odd side effects based on whether imports happen
before or after that state is adjusted..

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

On Mon, Apr 16, 2018 at 06:16:46AM +1000, Chris Angelico wrote:
[...]

> >> >>> items = [None] * 10
> >> >>> i = -1
> >> >>> items[i := i + 1] = input("> ")
> >> > asdf
> >> >>> items[i := i + 1] = input("> ")
> >> > qwer
> >> >>> items[i := i + 1] = input("> ")
> >> > zxcv
> >> >>>
> >> >>> items
> >> ['asdf', 'qwer', 'zxcv', None, None, None, None, None, None, None]
> >
> >
> > I don't know why you would write that instead of:
> >
> > items = [None]*10
> > for i in range(3):
> > items[i] = input("> ")
> >
> >
> > or even for that matter:
> >
> > items = [input("> ") for i in range(3)] + [None]*7
> >
> >
> > but whatever floats your boat. (Python isn't just not Java. It's also
> > not C *wink*)
> 
> You and Kirill have both fallen into the trap of taking the example
> too far. By completely rewriting it, you destroy its value as an
> example. Write me a better example of a complex target if you like,
> but the question is about how you feel about complex assignment
> targets, NOT how you go about creating a particular list in memory.
> That part is utterly irrelevant.

Chris, I must admit that I'm utterly perplexed at this. Your example is 
as far as from a complex assignment target as you can possibly get. It's 
a simple name! 

i := i + 1

The target is just "i", a name.

The point I was making is that your example is not a good showcase for 
this suggested functionality. Your code violates DRY, repeating the 
exact same line three times. It ought to be put in a loop, and once put 
in a loop, the justification for needing assignment-expression 
disappears.

But having said that, I did respond to your question and swapping the 
order around:

items[i + 1 -> i] = input("> ")

It's still not a "complex target", the target is still just a plain ol' 
name, but it is precisely equivalent to your example.

And then I went further and re-wrote your example to use a genuinely 
complex target, which I won't repeat here.

> >> Are you as happy with that sort of complex
> >> expression coming after 'as' or '->'?
> >
> > Sure. Ignoring the output of the calls to input():
> 
> The calls to input were in a while loop's header for a reason.
> Ignoring them is ignoring the point of assignment expressions.

What while loop? Your example has no while loop.

But regardless, we don't need to care about the *output* (i.e. your 
keypresses echoed to stdout) when looking at the code sample.


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Peter O'Connor]

In any case, although I find the magic variable-injection stuff quite
strange, I like the decorator.

Something like

@scannable(average=0)  # Wrap function so that it has a "scan" method
which can be used to generate a stateful scan object
def exponential_moving_average(average, x, decay):
return (1-decay)*average + decay*x

stateful_func = exponential_moving_average.scan(average=initial)
smooth_signal = [stateful_func(x) for x in signal]

Seems appealing because it allows you to define the basic function without,
for instance, assuming that decay will be constant. If you wanted dynamic
decay, you could easily have it without changing the function:

stateful_func = exponential_moving_average.scan(average=initial)
smooth_signal = [stateful_func(x, decay=decay) for x, decay in
zip(signal, decay_schedule)]

And you pass around state explicitly.















On Mon, Apr 16, 2018 at 9:49 AM, Peter O'Connor 
wrote:

> Hi Danilo,
>
> The idea of decorating a function to show that the return variables could
> be fed back in in a scan form is interesting and could solve my problem in
> a nice way without new syntax.
>
> I looked at your code but got a bit confused as to how it works (there
> seems to be some magic where the decorator injects the scanned variable
> into the namespace).  Are you able to show how you'd implement the moving
> average example with your package?
>
> I tried:
>
> @enable_scan("average")
> def exponential_moving_average_pyscan(signal, decay, initial=0):
> yield from ((1-decay)*(average or initial) + decay*x for x in
> signal)
>
>
> smooth_signal_9 = list(exponential_moving_average_pyscan(signal,
> decay=decay))[1:]
>
> Which almost gave the right result, but seemed to get the initial
> conditions wrong.
>
> - Peter
>
>
>
> On Sat, Apr 14, 2018 at 3:57 PM, Danilo J. S. Bellini <
> danilo.bell...@gmail.com> wrote:
>
>> On 5 April 2018 at 13:52, Peter O'Connor 
>> wrote:
>>
>>> I was thinking it would be nice to be able to encapsulate this common
>>> type of operation into a more compact comprehension.
>>>
>>> I propose a new "Reduce-Map" comprehension that allows us to write:
>>>
>>> signal = [math.sin(i*0.01) + random.normalvariate(0, 0.1) for i in 
>>> range(1000)]
>>> smooth_signal = [average = (1-decay)*average + decay*x for x in signal from 
>>> average=0.]
>>>
>>> Instead of:
>>>
>>> def exponential_moving_average(signal: Iterable[float], decay: float, 
>>> initial_value: float=0.):
>>> average = initial_value
>>> for xt in signal:
>>> average = (1-decay)*average + decay*xt
>>> yield average
>>>
>>> signal = [math.sin(i*0.01) + random.normalvariate(0, 0.1) for i in 
>>> range(1000)]
>>> smooth_signal = list(exponential_moving_average(signal, decay=0.05))
>>>
>>> I wrote in this mail list the very same proposal some time ago. I was
>> trying to let the scan higher order function (itertools.accumulate with a
>> lambda, or what was done in the example above) fit into a simpler list
>> comprehension.
>>
>> As a result, I wrote this project, that adds the "scan" feature to Python
>> comprehensions using a decorator that performs bytecode manipulation (and
>> it had to fit in with a valid Python syntax):
>> https://github.com/danilobellini/pyscanprev
>>
>> In that GitHub page I've wrote several examples and a rationale on why
>> this would be useful.
>>
>> --
>> Danilo J. S. Bellini
>> ---
>> "*It is not our business to set up prohibitions, but to arrive at
>> conventions.*" (R. Carnap)
>>
>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Peter O'Connor]

Hi Danilo,

The idea of decorating a function to show that the return variables could
be fed back in in a scan form is interesting and could solve my problem in
a nice way without new syntax.

I looked at your code but got a bit confused as to how it works (there
seems to be some magic where the decorator injects the scanned variable
into the namespace).  Are you able to show how you'd implement the moving
average example with your package?

I tried:

@enable_scan("average")
def exponential_moving_average_pyscan(signal, decay, initial=0):
yield from ((1-decay)*(average or initial) + decay*x for x in
signal)


smooth_signal_9 = list(exponential_moving_average_pyscan(signal,
decay=decay))[1:]

Which almost gave the right result, but seemed to get the initial
conditions wrong.

- Peter



On Sat, Apr 14, 2018 at 3:57 PM, Danilo J. S. Bellini <
danilo.bell...@gmail.com> wrote:

> On 5 April 2018 at 13:52, Peter O'Connor 
> wrote:
>
>> I was thinking it would be nice to be able to encapsulate this common
>> type of operation into a more compact comprehension.
>>
>> I propose a new "Reduce-Map" comprehension that allows us to write:
>>
>> signal = [math.sin(i*0.01) + random.normalvariate(0, 0.1) for i in 
>> range(1000)]
>> smooth_signal = [average = (1-decay)*average + decay*x for x in signal from 
>> average=0.]
>>
>> Instead of:
>>
>> def exponential_moving_average(signal: Iterable[float], decay: float, 
>> initial_value: float=0.):
>> average = initial_value
>> for xt in signal:
>> average = (1-decay)*average + decay*xt
>> yield average
>>
>> signal = [math.sin(i*0.01) + random.normalvariate(0, 0.1) for i in 
>> range(1000)]
>> smooth_signal = list(exponential_moving_average(signal, decay=0.05))
>>
>> I wrote in this mail list the very same proposal some time ago. I was
> trying to let the scan higher order function (itertools.accumulate with a
> lambda, or what was done in the example above) fit into a simpler list
> comprehension.
>
> As a result, I wrote this project, that adds the "scan" feature to Python
> comprehensions using a decorator that performs bytecode manipulation (and
> it had to fit in with a valid Python syntax):
> https://github.com/danilobellini/pyscanprev
>
> In that GitHub page I've wrote several examples and a rationale on why
> this would be useful.
>
> --
> Danilo J. S. Bellini
> ---
> "*It is not our business to set up prohibitions, but to arrive at
> conventions.*" (R. Carnap)
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mikhail V]

On Sun, Apr 15, 2018 at 6:58 PM, Steven D'Aprano  wrote:
> On Sun, Apr 15, 2018 at 10:21:02PM +1000, Chris Angelico wrote:
>
>> I don't think we're ever going to unify everyone on an arbitrary
>> question of "expression first" or "name first". But to all the
>> "expression first" people, a question: what if the target is not just
>> a simple name?
>>
>> while (read_next_item() -> items[i + 1 -> i]) is not None:
>> print("%d/%d..." % (i, len(items)), end="\r")
>
> I don't see why it would make a difference. It doesn't to me.
>
>
>> Does this make sense? With the target coming first, it perfectly
>> parallels the existing form of assignment:
>
> Yes, except this isn't ordinary assignment-as-a-statement.
>
> I've been mulling over the question why I think the expression needs to
> come first here, whereas I'm satisfied with the target coming first for
> assignment statements, and I think I've finally got the words to explain
> it. It is not just long familiarity with maths and languages that put
> the variable first (although that's also part of it). It has to do with
> what we're looking for when we read code, specifically what is the
> primary piece of information we're initially looking for.
>
> In assignment STATEMENTS the primary piece of information is the target.
> Yes, of course the value assigned to the target is important, but often
> we don't care what the value is, at least not at first. We're hunting
> for a known target, and only when we find it do we care about the value
> it gets.
>
... [SNIP] 

>
> It is appropriate for assignment statements and expressions to be
> written differently because they are used differently.
>


Wow. That feeling when you see someone giving  reasonable
arguments but in the end comes up with such doubtful conclusions.
So you agree that in general you may need to spot values
and in other case function calls or expressions.
And that's it, its just depends.
So if you swap the order and in some _single_ particular
case you may notice tiny advantage, you conclude that
the whole case with expression assignment needs this order.

Lets just return to some of proposed examples
(I use "=" in both examples to be less biased here):

1.
if  ( match = re.match("foo", S) ) == True:
print("match:", match)

2.
if  ( re.match("foo", S) = match ) == True:
print("match:", match)


Now seriously, you may argue around those "pronounce"
theoretical bla bla, like "take the result and save it in a token".
But the variant 1. is just better, because _it is what it is in Python_.

So it is better not because it is better looking or whatever,
it is same sh** turned around. So just don't turn it around!

Here the 1st variant can be unwrapped to:

match = re.match("foo", S)
if match == True:
print("match:", match)


Do you see what I mean?

When I read code I don't have all those things
you describe in a millisecond :
- look at the pointy end of operator
- think, oh this shows to the right
- seems like I save the value there
- yep, that's the way I imply things to work
- stroking the belly


Instead I just parse visually some smaller parts
of code and it's just better if the assignment is in the same
order as everywhere.
Yes, in some single case one order can look better,
but in this case it's just not good to mix those.



Mikhail
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Rewriting file - pythonic way

[Alexey Shrub]

https://pypi.python.org/pypi/in-place
> * Instead of hijacking sys.stdout, a new filehandle is returned for 
writing.
> * The filehandle supports all of the standard I/O methods, not just 
readline().


why fileinput did not support this things?

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Kirill Balunov]

 [Guido]
2018-04-15 20:19 GMT+03:00 Guido van Rossum :

> On Sun, Apr 15, 2018 at 4:05 AM, Kirill Balunov 
> wrote:
>
>> [...] For me personally, `: =` looks and feels just like normal
>> assignment statement which can be used interchangeable but in many more
>> places in the code. And if the main goal of the PEP was to offer this
>> `assignment expression` as a future replacement for `assignment statement`
>> the `:=` syntax form would be the very reasonable proposal (of course in
>> this case there will be a lot more other questions).
>>
>
> I haven't kept up with what's in the PEP (or much of this thread), but
> this is the key reason I strongly prefer := as inline assignment operator.
>
>
>> But somehow this PEP does not mean it! And with the current rationale of
>> this PEP it's a huge CON for me that `=` and `:=` feel and look the same.
>>
>
> Then maybe the PEP needs to be updated.
>

[Chris]
2018-04-15 23:28 GMT+03:00 Chris Angelico :

> On Mon, Apr 16, 2018 at 3:19 AM, Guido van Rossum 
> wrote:
> > On Sun, Apr 15, 2018 at 4:05 AM, Kirill Balunov  >
> > wrote:
> >> But somehow this PEP does not mean it! And with the current rationale of
> >> this PEP it's a huge CON for me that `=` and `:=` feel and look the
> same.
> >
> > Then maybe the PEP needs to be updated.
>
> I can never be sure what people are reading when they say "current"
> with PEPs like this. The text gets updated fairly frequently. As of
> time of posting, here's the rationale:
>
> -
> Naming the result of an expression is an important part of programming,
> allowing a descriptive name to be used in place of a longer expression,
> and permitting reuse.  Currently, this feature is available only in
> statement form, making it unavailable in list comprehensions and other
> expression contexts.  Merely introducing a way to assign as an expression
> would create bizarre edge cases around comprehensions, though, and to avoid
> the worst of the confusions, we change the definition of comprehensions,
> causing some edge cases to be interpreted differently, but maintaining the
> existing behaviour in the majority of situations.
> -
>
> Kirill, is this what you read, and if so, how does that make ':=' a
> negative? The rationale says "hey, see this really good thing you can
> do as a statement? Let's do it as an expression too", so the parallel
> should be a good thing.
>
>
Yes, this is what I read. I understand why you have such a question so I'll
try to explain my position in more detail. Also I want to add that I did
not fully understand about which part Guido said - "Then maybe the PEP
needs to be updated." Therefore, I allow myself to assume that he had in
mind the following - "The assignment expression should be semantically
equivalent to assignment statement and perceived as a theoretically
possible future replacement (usage) of assignment statement." If this is
really the case and I understood correctly - I will repeat that for me the
current state of the PEP does not fully imply this.

1.  Part - "Then maybe the PEP needs to be updated."

If you really see it as a theoretical substitute for assignment statement
in future Python. I will update the rationale with  maybe the following (I
immediately warn you that I do not pretend to have a good English style):

-
Naming the result of an expression is an important part of programming,
allowing a descriptive name to be used in place of a longer expression,
and permitting reuse.  Currently, in Python this feature is available only
in
statement form, making it unavailable in list comprehensions and other
expression contexts.  This restriction, of making it as a statement, was
done
primarily to avoid the usual trap of `=` vs `==` in C/C++ language.  Despite
this, it is evident that the ability to assign a name within an expression
is convenient, allows to avoid redundant recalculations of the same
expression
and is a familiar feature from other programming languages.  Thus the main
aim
of this PEP is to provide a syntax which will allow to assign as an
expression
and be semantically and visually interchangeable with the assignment
statement.
...
-

In this case, I do not see any reason to discuss the alternative syntax -
there is really only one choice `:=`. And then for me the list of open
questions would look like (for example):
1. ...Is it worth accepting?
2. ...Should the other forms (+=, *=, basically all) that can not be
confused with `==` be changed to expressions?
...


2.  Part - How do I understand the current state of the PEP

I perceive the current rationale as "hey, see this really good thing you
can do as a statement? Let's do it as an expression too".  Which for me
means opportunities to discuss the following questions:
1.  Should assignment expression be viewed as a replacement of an
assignment statement or as a complement to it?
2.  Which spelling should 

Re: [Python-ideas] Rewriting file - pythonic way

[Alexey Shrub]

В Понедельник, 16 апр. 2018 в 2:48 , Alexey Shrub 
 написал:

https://pypi.python.org/pypi/in-place


I like in_place module
https://github.com/worldmind/scripts/blob/master/filerewrite/inplacetest.py
it fix some strange features of fileinput module.
Maybe in_place must be in standard library instead fileinput?

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Rewriting file - pythonic way

[Alexey Shrub]

В Воскресенье, 15 апр. 2018 в 10:47 , George Fischhof 
 написал:

https://docs.python.org/3/library/fileinput.html


https://pypi.python.org/pypi/in-place
looks not bad too
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Rewriting file - pythonic way

[Alexey Shrub]

В Воскресенье, 15 апр. 2018 в 1:12 , Serhiy Storchaka 
 написал:
Actually the reliable code should write into a separate file and 
replace

the original file by the new file only if writing is successful. Or
backup the old file and restore it if writing is failed. Or do both. 
And
handle hard and soft links if necessary. And use file locks if needed 
to
prevent race condition when read/write by different processes. 
Depending

on the specific of the application you may need different code. Your
three lines are enough for a one-time script if the risk of a powerful
blackout or disk space exhaustion is insignificant or if the data is 
not

critical.


I not sure that solving described problems is a task of this level, 
maybe it problem for higher level


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Rewriting file - pythonic way

[Alexey Shrub]

В Воскресенье, 15 апр. 2018 в 10:47 , George Fischhof 
 написал:

https://docs.python.org/3/library/fileinput.html


Thanks, it works
https://github.com/worldmind/scripts/blob/master/filerewrite/fileinputtest.py
but looks like that way only for line by line processing

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Rewriting file - pythonic way

[Alexey Shrub]

В Воскресенье, 15 апр. 2018 в 6:19 , Oleg Broytman 
 написал:

Can I recommend to catch exceptions in `backuper.backup()`,
cleanup backuper and unlock locker?


Yes, thanks, I move .backup() to try, about other exception I think 
that it must be catched outside, because this module don't know that to 
do with such problems


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Kirill Balunov]

2018-04-15 23:22 GMT+03:00 Chris Angelico :

>
> > 0.
> >
> > while (items[i := i+1] := read_next_item()) is not None:
> > print(r'%d/%d' % (i, len(items)), end='\r')
> >
> > 1.
> >
> > while (read_next_item() -> items[(i+1) -> i]) is not None:
> > print(r'%d/%d' % (i, len(items)), end='\r')
>
> These two are matching what I wrote, and are thus the two forms under
> consideration. I notice that you added parentheses to the second one;
> is there a clarity problem here and you're unsure whether "i + 1 -> i"
> would capture "i + 1" or "1"? If so, that's a downside to the
> proposal.
>
>
Yes parentheses were used only for clarity. I agree that I misunderstood
the purpose of your question. I have no problem if the right part is a
complex target, but maybe my perception is biased.

With kind regards,
-gdg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A cute Python implementation of itertools.tee

[Steven D'Aprano]

On Sun, Apr 15, 2018 at 08:35:51PM +0300, Serhiy Storchaka wrote:

> I have ideas about implementing zero-overhead try/except, but I have 
> doubts that it is worth. The benefit seems too small.

It is conventional wisdom that catching exceptions is expensive, and 
that in performance critical code it is better to "look before you leap" 
if possible, and avoid try...except.

Are you saying this advice is obsolete?

If not, then perhaps reducing the overhead of catching exceptions may be 
worthwhile.


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] collections.Counter should implement __mul__, __rmul__

[Steven D'Aprano]

On Mon, Apr 16, 2018 at 05:22:54AM +, Steve Barnes wrote:

> Wouldn't it make sense to have the current counter behaviour, (negative 
> counts not allowed), and also a counter that did allow negative values 
> (my bank doesn't seem to have a problem with my balance being able to go 
> below negative)

I wish my bank was as understanding, they keep telling me I'm 
overdrawn...

*wink*

> and possibly at the same time a counter class that 
> allowed fractional counts?

I understand the idea of counting in fractions (1/3, 2/3, 1, 1+1/3, ...) 
but I don't understand what fractional frequencies would mean.

What's your use-case for fractional frequencies?




-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A cute Python implementation of itertools.tee

[Koos Zevenhoven]

On Sun, Apr 15, 2018 at 11:55 PM, Chris Angelico  wrote:

> On Mon, Apr 16, 2018 at 6:46 AM, Koos Zevenhoven 
> wrote:
> > Anyway, the whole linked list is unnecessary if the iterable can be
> iterated
> > over multiple times. But "tee" won't know when to do that. *That* is
> what I
> > call overhead (unless of course all the tee branches are consumed in an
> > interleaved manner).
>
> But if you have something you can iterate over multiple times, why
> bother with tee at all? Just take N iterators from the underlying
> iterable. The overhead is intrinsic to the value of the function.
>
> ​
Indeed. But if you have, say, an Iterable[int], you don't know if you need
the additional buffer or not.  It could be a range object or a set or a
generator (or iterator), who knows. Even your type checker doesn't know
what you need.

-- Koos


-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A cute Python implementation of itertools.tee

[Koos Zevenhoven]

On Mon, Apr 16, 2018 at 12:06 AM, Tim Peters  wrote:

> [Koos Zevenhoven ]
> > It's definitely possible to write the above in a more
> > readable way, and FWIW I don't think it involves "assignments as
> > expressions".
>
> Of course it is.  The point was brevity and speed, not readability.
> It was presented partly as a puzzle :-)
>
> >> What I find kind of hilarious is that it's no help at all as a
> >> prototype for a C implementation:  Python recycles stale `[next(it),
> >> None]` pairs all by itself, when their internal refcounts fall to 0.
> >> That's the hardest part.
>
> > Why can't the C implementation use Python refcounts? Are you talking
> about
> > standalone C code?
>
> Yes, expressing the algorithm in plain old C, not building on top of
> (say) the Python C API.
>
>
​There must have been a reason why pseudo code was "invented".​


> > Or perhaps you are thinking about overhead?
>
> Nope.
>
>
> > (In PEP 555 that was not a concern, though). Surely it would make sense
> > to reuse the refcounting code that's already there. There are no cycles
> > here, so it's not particulaly complicated -- just duplication.
> >
> > Anyway, the whole linked list is unnecessary if the iterable can be
> iterated
> > over multiple times.
>
> If the latter were how iterables always worked, there would be no need
> for tee() at all.  It's tee's _purpose_ to make it possible for
> multiple consumers to traverse an iterable's can't-restart-or-even
> -go-back result sequence each at their own pace.
>

​Yes. (I'm not sure which is easier, going back or starting from the
beginning)

-- Koos


-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] collections.Counter should implement __mul__, __rmul__

[Steve Barnes]

On 16/04/2018 06:07, Tim Peters wrote:
> [Peter Norvig]
>> For most types that implement __add__, `x + x` is equal to `2 * x`.
>>
>> That is true for all numbers, list, tuple, str, timedelta, etc. -- but not
>> for collections.Counter. I can add two Counters, but I can't multiply one
>> by a scalar. That seems like an oversight.
>>
>> ...
>> Here's an implementation:
>>
>> def __mul__(self, scalar):
>> "Multiply each entry by a scalar."
>> result = Counter()
>> for key in self:
>> result[key] = self[key] * scalar
>> return result
>>
>> def __rmul__(self, scalar):
>> "Multiply each entry by a scalar."
>> result = Counter()
>> for key in self:
>> result[key] = scalar * self[key]
>> return result
> 
> Adding Counter * integer doesn't bother me a bit, but the definition
> of what that should compute isn't obvious.  In particular, that
> implementation doesn't preserve that `x+x == 2*x` if x has any
> negative values:
> 
 x = Counter(a=-1)
 x
> Counter({'a': -1})
 x+x
> Counter()
> 
> It would be strange if x+x != 2*x, and if x*-1 != -x:
> 
 y = Counter(a=1)
 y
> Counter({'a': 1})
 -y
> Counter()
> 
> Etc.
> 
> Then again, it's already the case that, e.g., x-y isn't always the
> same as x + -y:
> 
 x = Counter(a=1)
 y = Counter(a=2)
 x - y
> Counter()
 x + -y
> Counter({'a': 1})
> 
> So screw obvious formal identities ;-)
> 
> I'm not clear on why "+" and "-" discard keys with values <= 0 to
> begin with.  For "-" it's natural enough viewing "-" as being multiset
> difference, but for "+"?  That's just made up ;-)
> 
> In any case, despite the oddities, I think your implementation would
> be least surprising overall (ignore the sign of the resulting values).
> At least for Counters that actually make sense as multisets (have no
> values <= 0), and for a positive integer multiplier `n > 0`, it does
> preserve that `x*n` = `x + x + ... + x` (with  `n` instances of `x`).
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
> 

Wouldn't it make sense to have the current counter behaviour, (negative 
counts not allowed), and also a counter that did allow negative values 
(my bank doesn't seem to have a problem with my balance being able to go 
below negative), and possibly at the same time a counter class that 
allowed fractional counts?

Then:
  x = Counter(a=1)
  y = Counter(a=2)
  x - y
 > Counter()
  x + -y
 > Counter({'a': 1})
BUT:
  x = Counter(a=1, allow_negative=True)
  y = Counter(a=2, allow_negative=True)
  x - y
 > Counter({'a': 1})
  x + -y
 > Counter({'a': 1})
Likewise for a Counter that was allowed to be fractional the result of 
some_counter / scalar would have (potentially) fractional results and 
one that did not would give floor results.

-- 
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect 
those of my employer.

---
This email has been checked for viruses by AVG.
http://www.avg.com

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/