Hi. Just to respond to some peoples’ points… Bernardo asked 'This would be "constant" as in Java constants right? Referential constants, so that if an object were mutable you would still be able to change its internal state.’ Um, I’m not entirely sure what you mean, since I’ve never used Java. But if it means what I think it means, I would be INCLINED to say no. If, for example, I saw code like this:
x = [9, 5, 7, 1] let y = x y[0] = 42 print(y) … I would expect that code to raise an error, not print “[42, 5, 7, 1]”, since you’re trying to modify the “constant” y in place, which… well, would kind of go against the idea of y being a constant, I thought (unless I’m misunderstanding what you meant by “object", since everything in Python’s an object). However, I might change my opinion if I heard a good reason why Java-like constants would be better. Serhiy asked, in relation to constants, “To do what? What problem do you need to solve?”. No problem in particular, to be honest. I just thought they’d be nice since they’d increase confidence that my variables-intended-to-be-constants wouldn’t get reassigned, and just to increase readability/explicitness to other programmers. > On 21 Nov 2017, at 20:08, python-ideas-requ...@python.org wrote: > > Send Python-ideas mailing list submissions to > python-ideas@python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/python-ideas > or, via email, send a message with subject or body 'help' to > python-ideas-requ...@python.org > > You can reach the person managing the list at > python-ideas-ow...@python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-ideas digest..." > > > Today's Topics: > > 1. Re: Should Python have user-defined constants? (Steven D'Aprano) > 2. Re: Should Python have user-defined constants? (St?fane Fermigier) > 3. Re: Should Python have user-defined constants? (Bernardo Sulzbach) > 4. Star assignment in iterator way? (Kirill Balunov) > 5. Re: Star assignment in iterator way? (Serhiy Storchaka) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Nov 2017 19:13:42 +1100 > From: Steven D'Aprano <st...@pearwood.info> > To: python-ideas@python.org > Subject: Re: [Python-ideas] Should Python have user-defined constants? > Message-ID: <20171121081342.gk19...@ando.pearwood.info> > Content-Type: text/plain; charset=us-ascii > > On Tue, Nov 21, 2017 at 02:38:45AM -0500, Joseph Jevnik wrote: > >> How is that different from "pi = 3.14"? > > pi = 3.14 > pi = 5 > print(pi) > # prints 5 > > let pi = 3.14 > pi = 5 > # raises an exception > > > > -- > Steve > > > ------------------------------ > > Message: 2 > Date: Tue, 21 Nov 2017 09:26:17 +0100 > From: St?fane Fermigier <s...@fermigier.com> > To: Python-Ideas <python-ideas@python.org> > Subject: Re: [Python-ideas] Should Python have user-defined constants? > Message-ID: > <cabujjj5-zhuwtbns8rm8jvwpaogq08mm+x0ryqp1z7ogqfs...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Javascript (ES6) has 'let' and 'const' for mutable and constant variables, > respectively. > > When programming in JS, I find myself aggressively aiming for as little > 'let' and as much 'const' as reasonably possible, since reasoning about > constants is much easier than about variables. In this context, 'const' is > used as a marker, a runtime checker, and, with proper tooling (IDE or > linter), a coding-time reminder to differentiate between these two > fundamental behaviours. > > I'm not +1 on introducing this idea to Python yet, but not -1 either - this > deserves some discussion, if this has not been discussed already. > > Cheers, > > S. > > On Tue, Nov 21, 2017 at 9:13 AM, Steven D'Aprano <st...@pearwood.info> > wrote: > >> On Tue, Nov 21, 2017 at 02:38:45AM -0500, Joseph Jevnik wrote: >> >>> How is that different from "pi = 3.14"? >> >> pi = 3.14 >> pi = 5 >> print(pi) >> # prints 5 >> >> let pi = 3.14 >> pi = 5 >> # raises an exception >> >> >> >> -- >> 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/ >> > > > > -- > Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - > http://linkedin.com/in/sfermigier > Founder & CEO, Abilian - Enterprise Social Software - > http://www.abilian.com/ > Chairman, Free&OSS Group / Systematic Cluster - > http://www.gt-logiciel-libre.org/ > Co-Chairman, National Council for Free & Open Source Software (CNLL) - > http://cnll.fr/ > Founder & Organiser, PyData Paris - http://pydata.fr/ > --- > ?You never change things by ?ghting the existing reality. To change > something, build a new model that makes the existing model obsolete.? ? R. > Buckminster Fuller > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mail.python.org/pipermail/python-ideas/attachments/20171121/b26ce033/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Tue, 21 Nov 2017 06:36:47 -0200 > From: Bernardo Sulzbach <mafagafogiga...@gmail.com> > To: python-ideas@python.org > Subject: Re: [Python-ideas] Should Python have user-defined constants? > Message-ID: <0028cb32-78e6-783e-e5d1-fc266e24e...@gmail.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > This could also be useful if one eventually wanted to implement constant > optimizations in the interpreter as it would be possible to detect > constants when they are declared without any code analysis. > > This would be "constant" as in Java constants right? Referential > constants, so that if an object were mutable you would still be able to > change its internal state. > > -- > Bernardo Sulzbach > http://www.mafagafogigante.org/ > mafagafogiga...@gmail.com > > > ------------------------------ > > Message: 4 > Date: Tue, 21 Nov 2017 11:54:37 +0300 > From: Kirill Balunov <kirillbalu...@gmail.com> > To: python-ideas@python.org > Subject: [Python-ideas] Star assignment in iterator way? > Message-ID: > <cabwcvqcodpaqkvr6dgvod+dop-ymuyqdmkxsc2nug2ypgn2...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello. Currently during star assignement the new list is created. > What was the idea to produce new list instead of returning an iterator? > It seems to me that returning an iterator more suited to the spirit of > Python 3. > There are three cases: > > 1. a,b,c,*d = something_iterable > 2. *a,b,c,d = something_iterable > 3. a,*b,c,d = something_iterable > > The first one is obvious. For the rest two we always need to iterate > through > entire iterable to achieve values for b,c,d (or c,d) binding. But this can > be done > more memory effiecient than currently (may be I'm wrong). And we can > iterate in > space of last three (or two) variables. Some rough (simplified) Python code: > > from itertools import islice, chain > from collections import deque > > def good_star_exp(signature, seq): > > if signature.count('*') > 1: > raise SyntaxError('two starred expressions in assignment') > > vrs = signature.split(',') > idx_max = len(vrs) - 1 > star_pos, = (i for i,v in enumerate(vrs) if '*' in v) > > #First case > if star_pos == idx_max: > head = islice(seq, idx_max) > tail = islice(seq, idx_max, None) > return chain(head, (tail,)) > > #Second case > elif star_pos == 0: > tail = deque(maxlen=idx_max) > for seq_idx_max, v in enumerate(seq): > tail.append(v) > head = islice(seq, 0, seq_idx_max-(idx_max-1)) > return chain([head], tail) > > #Third case > else: > head = islice(seq, star_pos) > tail = deque(maxlen=(idx_max-star_pos)) > for seq_idx_max, v in enumerate(seq): > tail.append(v) > mid = islice(seq, star_pos, seq_idx_max-(idx_max-2)) > return chain(head, [mid], tail) > > ls = range(100000) > a,b,c,d = good_star_exp('a,b,c,*d', ls) > a,b,c,d = good_star_exp('*a,b,c,d', ls) > a,b,c,d = good_star_exp('a,*b,c,d', ls) > > Of course this version has drawbacks (the first that come to mind): > 1. Will *b see change if rhs is some muttable sequence? > 2. Will *b one way iterator or somethong like range? > > But still it seems to me that the "iterator way" has more useful > applications. > > With best regards, -gdg > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mail.python.org/pipermail/python-ideas/attachments/20171121/f2819697/attachment-0001.html> > > ------------------------------ > > Message: 5 > Date: Tue, 21 Nov 2017 11:07:58 +0200 > From: Serhiy Storchaka <storch...@gmail.com> > To: python-ideas@python.org > Subject: Re: [Python-ideas] Star assignment in iterator way? > Message-ID: <ov0qd6$v12$1...@blaine.gmane.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > 21.11.17 10:54, Kirill Balunov ????: >> Of course this version has drawbacks (the first that come to mind): >> 1. Will *b see change if rhs is some muttable sequence? >> 2. Will *b one way iterator or somethong like range? >> >> But still it seems to me that the "iterator way" has more useful >> applications. > > Your implementation iterates seq multiple times. But iterable unpacking > syntax works with an arbitrary iterable, and iterates it only once. > > Changing the result of iterable unpacking will break existing code that > depends on the result been a list. > > And you already have mentioned a question about mutable sequence. > > If these conditions and restrictions suit you, you can use your > good_star_exp() in your code or share it with others. But the semantic > of iterable unpacking can't be changed. > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > > > ------------------------------ > > End of Python-ideas Digest, Vol 132, Issue 112 > **********************************************
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
