[Python-ideas] Providing a public API for creating and parsing HTTP messages
Hello all, If this is not the appropriate place for this type of proposal please let me know. The modules http.client and http.server both do a wonderful job when implementing HTTP clients and servers, respectively. However, occasionally there may be a need to create and parse HTTP messages themselves without needing to implement a client or server. While http.client and http.server clearly have solved this problem for its own uses, there is little to no public API exposed to a user wishing to do the same. For instance, the documentation for http.client.HTTPMessage [1] simply states that it extends from email.message.Message in order to parse the messages. [1]: https://docs.python.org/3/library/http.client.html#httpmessage-objects While this need may admittedly be a niche one, it is a shame that one cannot simply use the functionality already implemented for http.client and http.server for this purpose. Therefore, I am proposing this module be improved such that the creation and parsing of HTTP messages be "pulled out of" the existing code into HTTPRequest and HTTPResponse classes with a public API for this purpose. The exact API is subject to change of course, but it could work like: >>> r = http.client.HTTPRequest("POST", "/foo", "Hello world!") >>> r.method 'POST' >>> r.body 'Hello world!' >>> print(r) POST /foo HTTP/1.1 Content-Length: 12 Hello world! If this idea is not completely a bad one, I am very interested in discussing in further detail how I (or perhaps someone else) could begin to implement these changes. Thank you for reading. ___ 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)
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)
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)
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)
> 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)
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] >> 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
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)
On Tue, Apr 17, 2018 at 5:42 AM, Mikhail V wrote: > On Mon, Apr 16, 2018 at 8:42 PM, Chris Angelico wrote: >> On Mon, Apr 16, 2018 at 11:05 PM, Mikhail V 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. > > > As I initially said, I just don't find this choice list fair. > and it should be: > > 1) "target = expr" (which would be first intuitive idea from user's PoV, > and if can't be made then explained to Python people why not) That one is dealt with in the PEP. It is not an option. > 2) "target := expr" (as probably best close alternative) Yep, got that one. > 3) "target ? expr" (where ? is some other word/character - IIRC > "target from expr" was proposed once) ... which isn't specific enough to be a front-runner option. > That's it. > But well, if I compare to your choice list - there is ":=" option you > have as well :) Yes. I'm not sure what's unfair about the options I've given there. 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)
On Mon, Apr 16, 2018 at 8:42 PM, Chris Angelico wrote: > On Mon, Apr 16, 2018 at 11:05 PM, Mikhail V 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. As I initially said, I just don't find this choice list fair. and it should be: 1) "target = expr" (which would be first intuitive idea from user's PoV, and if can't be made then explained to Python people why not) 2) "target := expr" (as probably best close alternative) 3) "target ? expr" (where ? is some other word/character - IIRC "target from expr" was proposed once) That's it. But well, if I compare to your choice list - there is ":=" option you have as well :) ___ 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)
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)
> 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/ > 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). -- 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/
Re: [Python-ideas] Idea: Importing from arbitrary filenames
On Mon, Apr 16, 2018 at 10:23 AM, Brett Cannon wrote: > > > 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) > Thanks, Brett, I'll read through that and see where I get. Those corners /are/ pretty dark. The backstory is that I'm doing the final port from Py2 to Py3 (it's been a long time coming, mostly years of waiting for extension modules to get ported, notably wxPython and VTK). In Py2, all warnings were enabled and disallowed, so big surprise on first run, hundreds of lines of the aforementioned one and "ImportWarning: __package__ != __spec__.parent". We have manually defined "__package__" all over the place, for reasons lost in the fog of time, which I believe to be the culprit for the latter warning. Eric ___ 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)
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)
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)
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] Spelling of Assignment Expressions PEP 572 (was post #4)
On Tue, Apr 17, 2018 at 1:54 AM, Steven D'Aprano wrote: > 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. Thanks so much for the aggressively-trimmed quote. For once, though, TOO aggressive. What you're focusing on is the *unrolled* version of a two-line loop. Look at the actual loop, please, and respond to the actual question. :| >> 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. 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? 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
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
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
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
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)
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
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] collections.Counter should implement __mul__, __rmul__
[Steve Barnes ] > 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? We already have all that: a counter's values can be anything at all: >>> a = Counter(a=Fraction(2, 3)) >>> a + a Counter({'a': Fraction(4, 3)}) It's four specific binary "multiset" _operations_ that purge values <= 0 from their results: >>> a = Counter(a=Fraction(-2, 3)) >>> a Counter({'a': Fraction(-2, 3)}) >>> a['a'] < 0 True >>> a + a Counter() >>> a - a Counter() >>> a | a Counter() >>> a & a Counter() OK, also unary prefix "+" and "-". Other methods do not: >>> a = Counter(a=Fraction(-2, 3)) >>> a.subtract(Counter(a=1)) # like inplace "-" but <= 0 not special >>> a Counter({'a': Fraction(-5, 3)}) >>> a.update(Counter(a=1)) # like inplace "+" but <= 0 not special >>> a Counter({'a': Fraction(-2, 3)}) >>> a['a'] -= 100 >>> a Counter({'a': Fraction(-302, 3)}) > ... > 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. As above, results are a property not of the counter objects, but of the specific operations performed. some_counter / scalar would most obviously work like:the current: >>> c = Counter(a=1, b=-2) >>> c Counter({'a': 1, 'b': -2}) >>> scalar = 5 >>> Counter({key: value / scalar for key, value in c.items()}) Counter({'a': 0.2, 'b': -0.4}) ___ 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)
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
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
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)
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
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)
[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 have an assignment expression? ( depends on the previous ) 3. Does it make sense to make it valid only i
Re: [Python-ideas] Rewriting file - pythonic way
В Понедельник, 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
В Воскресенье, 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
В Воскресенье, 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
В Воскресенье, 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
В Воскресенье, 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)
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
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__
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
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
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/