Re: [Python-ideas] A "local" pseudo-function
On Apr 27 2018, Tim Peters wrote: > Then `c` is 12, but `a` is still 1 and `b` is still 2. Same thing in the end: > > c = local(a=3, b=4, a*b) I think this can be done already with slighly different syntax: c = (lambda a=3, b=4: a*b)() The trailing () is a little ugly, but the semantics are much more obvious. So maybe go with a variation that makes function evaluation implicit? c = lambda! a=3, b=4: a*b (reads terrible, but maybe someone has a better idea). > if local(m = re.match(regexp, line)): > print(m.group(0)) Of course, that wouldn't (and shouldn't) work anymore. But that's a good thing, IMO :-). Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ 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 Apr 14 2018, Chris Angelico wrote: > On Fri, Apr 13, 2018 at 11:30 PM, Peter O'Connor > wrote: >> Well this may be crazy sounding, but we could allow left or right assignment >> with >> >> name := expr >> expr =: name >> >> Although it would seem to violate the "only one obvious way" maxim, at least >> it avoids this overloaded meaning with the "as" of "except" and "with" >> > > Hah. It took me multiple readings to even notice the change in the > operator there, so I think this would cause a lot of confusion. Well, if putting the expression first is generally considered better, the reasonable thing to do would be to allow *only* =:. -Best Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ 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: Statement-Local Name Bindings, take three!
On Mar 25 2018, Guido van Rossum wrote: > I gotta say I'm warming up to := in preference over 'as', *if* we're going > to do this at all (not a foregone conclusion at all). I'm surprised that no one has mentioned it yet, so as a quick datapoint: Go also uses := for assignment, so there's some precedent. Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ 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] Allow additional separator character in variables
On Nov 18 2017, Bruce Leban wrote:
> And because spaces between words is mostly not valid syntax currently, this
> change would be easier to introduce than breaking every single program out
> there by re-purposing hyphen-minus. But I'm not seriously proposing this
> because I think the modest benefits are outweighed by the many problems it
> would introduce.
Luckily, there is a compromise: use backticks to quote identifiers:
`test mode` = True
if `test mode`:
`display message`("just a test")
I'm not seriously suggesting that, but I still wonder what people think
about it.
I sort of like it, actually. The `(" part is pretty ugly (which is why I
included it in the example), but there's no syntax that can completely
avoid ugly corner cases. I think in most cases the context would also
make it easy to distinguish single quotes and backticks even when
they're typographically similar.
Cheers,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
___
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] π = math.pi
On Jun 01 2017, Victor Stinner wrote: > 2017-06-01 8:47 GMT+02:00 Serhiy Storchaka : >> What you are think about adding Unicode aliases for some mathematic names in >> the math module? ;-) >> >> math.π = math.pi > > How do you write π (pi) with a keyboard on Windows, Linux or macOS? Under Linux, you'd use the Compose facility. Take a look at eg. /usr/share/X11/locale/en_US.UTF-8/Compose for all the nice things it let's you enter: $ egrep '[πτΓ]' /usr/share/X11/locale/en_US.UTF-8/Compose : "Γ" U0393# GREEK CAPITAL LETTER GAMMA : "π" U03C0# GREEK SMALL LETTER PI : "τ" U03C4# GREEK SMALL LETTER TAU Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ 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] Technical possibilities for a syntax [was: Reverse assignment operators ...]
On Nov 18 2016, Ethan Furman wrote: > On 11/18/2016 11:19 AM, Mikhail V wrote: >> On 18 November 2016 at 01:26, Steven D'Aprano wrote: > > I'm not seeing D'Aprano's posts, except in Mikhail's replies FWIW, I can see them on Gmane. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ 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] Technical possibilities for a syntax [was: Reverse assignment operators ...]
On Nov 16 2016, Ryan Gonzalez wrote: > A = A + 1 ==> A += 1 > > > Similar problem: semantics change. If someone decided to be weird and have > __add__ and __iadd__ do two different things, this would completely break > that. Granted, that's a stupid idea to begin with, but it's still poor > justification for the code breakage. Aeh, that's used e.g. in numpy and most certaintly not weird. x = np.range(5) y = x**2 y_int = interpolate(x, y, copy=False) y = y+1 print(y_int(3)) If you replace 'y = y + 1' with 'y += 1', then instead of creating a new array and assigning it to y, you modify the existing array in place, which will change the result of y_int(3). That is a feature. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ 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] Technical possibilities for a syntax [was: Reverse assignment operators ...]
On Nov 16 2016, Mikhail V wrote: > On 16 November 2016 at 10:27, Paul Moore > wrote: >> On 16 November 2016 at 08:51, Mikhail V >> wrote: >>> What semantics it will fundamentally break or so hard to implement? >> >> I'm afraid I don't have time at the moment to fully review your email, >> but my first impression is that you are proposing that the name "self" >> be treated specially. It's going to be very difficult to convince >> people that this is a good idea. > > Oh Paul, come on, please. > I am making an **example**. Write a "poo" instead or a poo pile > character, ...and all of Paul's points still apply. > You think I am an idiot and don't know that there is "self" in OOP. No, that wouldn't be the reason. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ 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] Null coalescing operator
On Nov 02 2016, Zero Piraeus wrote: > On Wed, 2016-11-02 at 08:46 -0700, Guido van Rossum wrote: >> [...] we need to agree on what even the right definition of ?. is. It's >> been frighteningly difficult to explain this even on this list, even >> though I have a very clear view in my head, and PEP 505 also has the >> same semantics and explains well why those are the right semantics. > > I think the proposed semantics for ?. are confusing (and the operator > itself dangerous, but more on that later). > > If I write something like obj.attr, the failure mode I care about is that > obj has no attribute attr, rather than that obj is specifically None (or > one of a defined group of somewhat Nonelike objects). > > Clearly, in such a circumstance, obj is not what I expected it to be, > because I thought it was going to have an attribute attr, and it > doesn't. That means that you do not need null coalescing operators. They're not intended for your use-case, and you are not the target audience. Criticizing the proposal on this basis is like critizing it for not helping with asynchronous I/O. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ 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 better interactive prompt
On Oct 26 2016, Paul Moore wrote: > Thinking a little further about this, I think the reason I don't use > IPython more, is because my muscle memory types "python" (or more > often, "py") when I want an interactive prompt. And I do that for the > reason you mention - it's always there. > > The downside, of course, is that the default behaviour is inconsistent > - new users could attend a course where IPython was preinstalled, but > then struggle when back at the office because no-one told them how to > set it up. It also imposes a significant burden on scripting. I often have elements like this in shell scripts: output=$(python
Re: [Python-ideas] A better interactive prompt
On Oct 26 2016, Paul Moore wrote: > On 26 October 2016 at 18:25, Nick Coghlan > wrote: >> The built-in REPL serves two quite divergent use cases, and I think >> we're well past the point where we can't readily support both use >> cases with a single implementation: >> >> - a minimalist interactive environment, that is *always* present, even >> if parts of the interpreter (most notably the import system) aren't >> working or have been deliberately disabled >> - a day-to-day working environment for Python developers >> >> The prevalence of the latter use case then leads to it also being used >> as a tool for introducing new developers to Python. > > Thinking a little further about this, I think the reason I don't use > IPython more, is because my muscle memory types "python" (or more > often, "py") when I want an interactive prompt. And I do that for the > reason you mention - it's always there. > > So I think that it would be really useful to be able to plug in a new > REPL, when it's available. This has a number of benefits: > > 1. We don't need to worry about incorporating any complex REPL code > into Python. The default REPL can remain simple. > 2. Users can choose their preferred REPL, core Python doesn't have to > get involved in UI decisions. Uh, these are not advantages of plugging in a new REPL when available. This describes the current situation. At least in your email above you seem to be arguing that Python should change to better accomodate your muscle memory. I don't want to diminuish your importance, but doesn't that maybe go a little too far? :-). Best, -Niko -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ 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] real numbers with SI scale factors: next steps
On Aug 31 2016, Guido van Rossum wrote: > On Wed, Aug 31, 2016 at 5:21 AM, Nick Coghlan > wrote: >> On 31 August 2016 at 17:07, Chris Angelico >> wrote: >>> On Wed, Aug 31, 2016 at 2:08 PM, Ken Kundert >>> wrote: > What's the mnemonic here? Why "r" for scale factor? My thinking was that r stands for real like f stands for float. With the base 2 scale factors, b stands for binary. >>> >>> "Real" has historically often been a synonym for "float", and it >>> doesn't really say that it'll be shown in engineering notation. But >>> then, we currently have format codes 'e', 'f', and 'g', and I don't >>> think there's much logic there beyond "exponential", "floating-point", >>> and... "general format"? I think that's a back-formation, frankly, and >>> 'g' was used simply because it comes nicely after 'e' and 'f'. (C's >>> decision, not Python's, fwiw.) I'll stick with 'r' for now, but it >>> could just as easily become 'h' to avoid confusion with %r for repr. >> >> "h" would be a decent choice - it's not only a continuation of the >> e/f/g pattern, it's also very commonly used as a command line flag for >> "human-readable output" in system utilities that print numbers. > > I like it. So after all the drama we're just talking about adding an > 'h' format code that's like 'g' but uses SI scale factors instead of > exponents. I guess we need to debate what it should do if the value is > way out of range of the SI scale system -- what's it going to do when > I pass it 1e50? I propose that it should fall back to 'g' style then, > but use "engineering" style where exponents are always a multiple of > 3.) There's also the important nitpick if 32e7 is best rendered as 320 M or 0.32 G. There's valid applications for both. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ 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] real numbers with SI scale factors
On Aug 29 2016, Ken Kundert
wrote:
> Nikolaus,
> I have belatedly realized that this kind of hyperbole is counter
> productive.
> So let me back away from that statement and instead try to understand your
> reasons for not liking the proposal.
>
> Do you think there is no value to be able to naturally read and write numbers
> with SI scale factors from Python? Or is your issue with something about my
> proposal?
* I think there is no value gained by being able to write 32.3m instead
of 32.3e6. I think the second one is clear to everyone who uses SI
prefixes, while the first one just introduces a lot of
complexities. Most of them have been mentioned already:
- no deducible ordering if one doesn't know the prefixes
- potential for ambiguity with Exa
- question about base 2 vs base 10, e.g what do you expect to be
stored in *size* if you reed this:
"size = 10M # we need that many bytes"
- rather abitrary naming ("M" and "m" vs "T" and "p").
* I think having SI *Unit* support "32.3 kN" would be nice, but only if
there is a space between number and unit, and only if the unit
actually get's attached to the number. But your proposal would
result in 1km + 1µN == 2 being true.
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
___
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] real numbers with SI scale factors
On Aug 28 2016, Ken Kundert wrote: > So, in summary, you are suggesting that we tell the scientific and > engineering > communities that we refuse to provide native support for their preferred way > of > writing numbers because: I think you're making some incorrect assumptions here. Who, exactly, do you mean with "we" and "them"? I consider myself part of the scientific community and think your proposal is a bad idea, and Google finds some Python modules from you, but no prior CPython contributions... Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
