Re: [Python-ideas] OT: slowing rotation [was: High Precision datetime]

2018-05-18 Thread Greg Ewing
Ethan Furman wrote: How long before the earth stops rotating? Apparently about 1.9 trillion years. > When it does, will we be > tide-locked with the sun, or will an earth day become an earth year? Wikipedia says the main cause of the slowing is tidal effects from the moon, so probably it wou

Re: [Python-ideas] OT: slowing rotation [was: High Precision datetime]

2018-05-18 Thread Stefan Behnel
Greg Ewing schrieb am 18.05.2018 um 10:05: > Ethan Furman wrote: >> How long before the earth stops rotating?Β  > > Apparently about 1.9 trillion years. So, does that mean we now need to hold our breath for 1.9 british trillion years or 1.9 american trillion years? Assuming you were referring to

Re: [Python-ideas] Verbatim names (allowing keywords as names)

2018-05-18 Thread Greg Ewing
Steven D'Aprano wrote: It's Python 3.8, and I learn that in 4.0 "spam" is going to become a keyword. I simply take my code and change all the references spam to \spam, and I've future-proofed the code for 4.0 while still keeping compatibility with 3.8 and 3.9. Okay, maybe it helps a little bi

Re: [Python-ideas] OT: slowing rotation [was: High Precision datetime]

2018-05-18 Thread Chris Angelico
On Fri, May 18, 2018 at 6:27 PM, Stefan Behnel wrote: > Greg Ewing schrieb am 18.05.2018 um 10:05: >> Ethan Furman wrote: >>> How long before the earth stops rotating? >> >> Apparently about 1.9 trillion years. > > So, does that mean we now need to hold our breath for 1.9 british trillion > years

Re: [Python-ideas] Verbatim names (allowing keywords as names)

2018-05-18 Thread Stephan Houben
2018-05-18 8:05 GMT+02:00 Greg Ewing : > Steven D'Aprano wrote: > >> It's Python 3.8, and I learn that in 4.0 "spam" is going to become a >> keyword. I simply take my code and change all the references spam to \spam, >> and I've future-proofed the code for 4.0 while still keeping compatibility >>

Re: [Python-ideas] OT: slowing rotation [was: High Precision datetime]

2018-05-18 Thread Greg Ewing
Stefan Behnel wrote: So, does that mean we now need to hold our breath for 1.9 british trillion years or 1.9 american trillion years? Seeing as the time-to-red-giant is only about 5e9 years, I don't think it matters much either way. -- Greg ___ Pytho

Re: [Python-ideas] OT: slowing rotation [was: High Precision datetime]

2018-05-18 Thread Greg Ewing
Chris Angelico wrote: I'm not sure. How long will it take for people to agree on a meaning for "trillion"? About a trillion years, I estimate. :-) -- Greg ___ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/

[Python-ideas] Make keywords KEYwords only in places they would have syntactical meaning

2018-05-18 Thread Ken Hilton
Hi all, Yes, this is another idea for avoiding breaking existing code when introducing new keywords. I'm not sure if this is too similar to Guido's previous "allow keywords in certain places" idea, but here goes: Only treat keywords as having any special meaning when they are in places with synta

Re: [Python-ideas] Make keywords KEYwords only in places they would have syntactical meaning

2018-05-18 Thread Rhodri James
On 18/05/18 12:22, Ken Hilton wrote: My idea is to only treat keywords as having special meaning when they're in the right place. So the following would all be legal: >>> from operator import and >>> var = and(True, False) >>> var False >>> var = True and False >>>

Re: [Python-ideas] Verbatim names (allowing keywords as names)

2018-05-18 Thread Steven D'Aprano
On Fri, May 18, 2018 at 06:05:05PM +1200, Greg Ewing wrote: > Steven D'Aprano wrote: > >It's Python 3.8, and I learn that in 4.0 "spam" is going to become a > >keyword. I simply take my code and change all the references spam to > >\spam, and I've future-proofed the code for 4.0 while still keepi

Re: [Python-ideas] Verbatim names (allowing keywords as names)

2018-05-18 Thread Steven D'Aprano
On Fri, May 18, 2018 at 11:17:13AM +0200, Stephan Houben wrote: > And the alternative is to replace all occurrences of > spam with 𝐬𝐩𝐚𝐦 , which has the same effect and also is > backward-compatible with 3.x for x < 8. > > So there is already a kind of solution available, albeit an ugly one. You

Re: [Python-ideas] Make keywords KEYwords only in places they would have syntactical meaning

2018-05-18 Thread Steven D'Aprano
On Fri, May 18, 2018 at 07:22:13PM +0800, Ken Hilton wrote: [...] > Only treat keywords as having any special meaning when they are in places > with syntactical significance. [...] > My idea is to only treat keywords as having special meaning when they're in > the right place. Chris discussed his

Re: [Python-ideas] Make keywords KEYwords only in places they would have syntactical meaning

2018-05-18 Thread Chris Angelico
On Fri, May 18, 2018 at 9:59 PM, Steven D'Aprano wrote: > That's even assuming such a context-sensitive grammar would be possible > within the requirement that Python's parser is LL(1). I'm sure it could be done, but it may impact existing Python grammar. So backward compatibility might mean maki

Re: [Python-ideas] Verbatim names (allowing keywords as names)

2018-05-18 Thread Neil Girdhar
On Fri, May 18, 2018 at 2:48 AM Steven D'Aprano wrote: > On Thu, May 17, 2018 at 11:02:23PM -0400, Neil Girdhar wrote: > > > However, the difference between the backslash syntax and comprehensions > and > > generator functions is that comprehensions and generator functions make > the > > language

Re: [Python-ideas] Verbatim names (allowing keywords as names)

2018-05-18 Thread Clint Hepner
> On 2018 May 18 , at 7:37 a, Steven D'Aprano wrote: > > On Fri, May 18, 2018 at 11:17:13AM +0200, Stephan Houben wrote: > >> And the alternative is to replace all occurrences of >> spam with 𝐬𝐩𝐚𝐦 , which has the same effect and also is >> backward-compatible with 3.x for x < 8. >> >> So there

Re: [Python-ideas] Verbatim names (allowing keywords as names)

2018-05-18 Thread Stephan Houben
2018-05-18 13:37 GMT+02:00 Steven D'Aprano : > On Fri, May 18, 2018 at 11:17:13AM +0200, Stephan Houben wrote: > > > And the alternative is to replace all occurrences of > > spam with 𝐬𝐩𝐚𝐦 , which has the same effect and also is > > backward-compatible with 3.x for x < 8. > > > > So there is alrea

Re: [Python-ideas] Verbatim names (allowing keywords as names)

2018-05-18 Thread Steven D'Aprano
On Fri, May 18, 2018 at 03:09:57PM +0200, Stephan Houben wrote: > 2018-05-18 13:37 GMT+02:00 Steven D'Aprano : > > > On Fri, May 18, 2018 at 11:17:13AM +0200, Stephan Houben wrote: > > > > > And the alternative is to replace all occurrences of > > > spam with 𝐬𝐩𝐚𝐦 , which has the same effect and a

Re: [Python-ideas] Verbatim names (allowing keywords as names)

2018-05-18 Thread Stephan Houben
2018-05-18 15:37 GMT+02:00 Steven D'Aprano : > > Earlier you described this suggestion as "a silly joke". > > https://mail.python.org/pipermail/python-ideas/2018-May/050861.html The joke proposal was to write all keywords in Python using bold font variation, as a reaction to a similar joke prop

Re: [Python-ideas] Verbatim names (allowing keywords as names)

2018-05-18 Thread Steven D'Aprano
On Fri, May 18, 2018 at 08:31:36AM -0400, Neil Girdhar wrote: [...] > > > I don't like multiple ways of doing the same thing. > > > > Ah, like when people want to use "class" as an identifier, and since > > they can't, they write: > > > > klass cls Class [...] > > Remind me again what the "one

Re: [Python-ideas] Verbatim names (allowing keywords as names)

2018-05-18 Thread Richard Damon
On 5/18/18 10:31 AM, Stephan Houben wrote: > > NFKC normalization is restricted to identifiers. > Keywords "must be spelled exactly as written here." > Β  > > > > > It is guaranteed to work by PEP-3131: > > https://www.python.org/dev/peps/pep-3131 >

Re: [Python-ideas] String and bytes bitwise operations

2018-05-18 Thread Chris Barker via Python-ideas
On Thu, May 17, 2018 at 11:07 PM, Greg Ewing wrote: > Steven D'Aprano wrote: > >> But XORing bytes seems perfectly reasonable. Bytes are numbers, even if >> we display them as ASCII characters. > > actually, bytes are, well, bytes ;-) -- that is, 8 bits. But the point is that "bitwise" operations

Re: [Python-ideas] String and bytes bitwise operations

2018-05-18 Thread Facundo Batista
2018-05-18 13:32 GMT-03:00 Chris Barker via Python-ideas : > or would it operate on the whole sequence as a single collection of bits? Once you think as the whole sequence of bytes as a sequence of bits (eight times longer, of course), all questions are easly answered, see below... > Would it b

Re: [Python-ideas] String and bytes bitwise operations

2018-05-18 Thread Richard Damon
On 5/18/18 12:32 PM, Chris Barker via Python-ideas wrote: > actually, bytes are, well, bytes ;-) -- that is, 8 bits. But the point > is that "bitwise" operations make all the sense in the world for > bytes, but not for unicode text -- did anyone have a use case for > bitwise operation on unicode st

Re: [Python-ideas] Make keywords KEYwords only in places they would have syntactical meaning

2018-05-18 Thread MRAB
On 2018-05-18 12:22, Ken Hilton wrote: Hi all, Yes, this is another idea for avoiding breaking existing code when introducing new keywords. I'm not sure if this is too similar to Guido's previous "allow keywords in certain places" idea, but here goes: Only treat keywords as having any specia

Re: [Python-ideas] String and bytes bitwise operations

2018-05-18 Thread Chris Angelico
On Sat, May 19, 2018 at 2:32 AM, Chris Barker via Python-ideas wrote: > On Thu, May 17, 2018 at 11:07 PM, Greg Ewing > wrote: >> >> Steven D'Aprano wrote: >>> >>> But XORing bytes seems perfectly reasonable. Bytes are numbers, even if >>> we display them as ASCII characters. > > > actually, bytes

Re: [Python-ideas] Make keywords KEYwords only in places they would have syntactical meaning

2018-05-18 Thread Chris Angelico
On Sat, May 19, 2018 at 2:56 AM, MRAB wrote: > On 2018-05-18 12:22, Ken Hilton wrote: >> >> Hi all, >> >> Yes, this is another idea for avoiding breaking existing code when >> introducing new keywords. I'm not sure if this is too similar to Guido's >> previous "allow keywords in certain places" id

Re: [Python-ideas] Verbatim names (allowing keywords as names)

2018-05-18 Thread Neil Girdhar
On Fri, May 18, 2018 at 10:49 AM Steven D'Aprano wrote: > On Fri, May 18, 2018 at 08:31:36AM -0400, Neil Girdhar wrote: > [...] > > > > I don't like multiple ways of doing the same thing. > > > > > > Ah, like when people want to use "class" as an identifier, and since > > > they can't, they write

Re: [Python-ideas] Async Lambda syntax

2018-05-18 Thread Noah Simon
Hello all, I was developing a script using an asyncio-based API, when I came across the need to define an asynchronous lambda. I found this syntax does not currently exist. Obviously I could have (and did) just write a regular coroutine, but for simple one-line functions and such, I think an asy

Re: [Python-ideas] Async Lambda syntax

2018-05-18 Thread Terry Reedy
On 5/18/2018 4:53 PM, Noah Simon wrote: Hello all, I was developing a script using an asyncio-based API, when I came across the need to define an asynchronous lambda. Not really. I found this syntax does not currently exist. Obviously I could have (and did) just write a regular coroutine, b

Re: [Python-ideas] String and bytes bitwise operations

2018-05-18 Thread Chris Barker - NOAA Federal via Python-ideas
>> actually, bytes are, well, bytes ;-) -- that is, 8 bits. > > Grammatically, you appear to be disagreeing with the assertion that > bytes are numbers. Is that the case? Um, yes. Though I think for the rest of the conversation, it’s a distinction that doesn’t matter. > If you want to be extremel

Re: [Python-ideas] String and bytes bitwise operations

2018-05-18 Thread Chris Angelico
On Sat, May 19, 2018 at 8:25 AM, Chris Barker - NOAA Federal wrote: >> I suppose you could argue that a "byte" is a patch of >> storage capable of holding a number from 0 to 255, as opposed to being >> the number itself, but that's getting rather existential :) > > No, I’m making the distinction t

[Python-ideas] Modern language design survey for "assign and compare" statements

2018-05-18 Thread Mike Miller
Background: While the previous discussions about assignment-expressions (PEPΒ 572) (abbreviated AE below) have been raging one thing that was noticeable is that folks have been looking back to C for a solution. But how are newer languages solving the problem today? Believe Ryan brought this up f

Re: [Python-ideas] Modern language design survey for "assign and compare" statements

2018-05-18 Thread Chris Angelico
On Sat, May 19, 2018 at 10:54 AM, Mike Miller wrote: > In short, extend the "if/elif", "while", and comprehension to: > > if pattern.search(data) as match: > … > > while read_next_item() as value: > … > > May be best to disallow multiple assignment/conditions for now, but u

Re: [Python-ideas] Modern language design survey for "assign and compare" statements

2018-05-18 Thread Juancarlo AΓ±ez
Conclusions > > > It appears assignment expressions are no longer the favored solution for > the > "assign and compare" use case. Not one of these five newer languages > supports > them fully, as the language generations from C to C# did. > > Of those that have recognized the use case

Re: [Python-ideas] Async Lambda syntax

2018-05-18 Thread Nathaniel Smith
On Fri, May 18, 2018 at 1:53 PM, Noah Simon wrote: > Hello all, > I was developing a script using an asyncio-based API, when I came across the > need to define an asynchronous lambda. I found this syntax does not > currently exist. Obviously I could have (and did) just write a regular > coroutine,

Re: [Python-ideas] Modern language design survey for "assign and compare" statements

2018-05-18 Thread Greg Ewing
Chris Angelico wrote: The 'as' syntax has been hammered out in great detail and is no longer recommended due to its negative interactions with existing constructs. Allowing it in arbitrary expressions has been ruled out on the grounds that the difference between "with x as y:" and "with (x as y

Re: [Python-ideas] Modern language design survey for "assign and compare" statements

2018-05-18 Thread Chris Angelico
On Sat, May 19, 2018 at 12:11 PM, Greg Ewing wrote: > Chris Angelico wrote: >> >> The 'as' syntax has been hammered out in great detail and is no longer >> recommended due to its negative interactions with existing constructs. > > > Allowing it in arbitrary expressions has been ruled out on > the

Re: [Python-ideas] Verbatim names (allowing keywords as names)

2018-05-18 Thread Carl Smith
I was asked earlier to summarise the the proposal I've been advocating for, but have already gone over the central points a few times. I'll try and find time to write a clear explanation soon. -- Carl Smith [email protected] On 18 May 2018 at 19:54, Neil Girdhar wrote: > > > On Fri, May 18,

Re: [Python-ideas] Modern language design survey for "assign and compare" statements

2018-05-18 Thread Brendan Barnwell
On 2018-05-18 17:54, Mike Miller wrote: > Background: > > While the previous discussions about assignment-expressions (PEP 572) > (abbreviated AE below) have been raging one thing that was noticeable is that > folks have been looking back to C for a solution. > > But how are newer languages solv

Re: [Python-ideas] String and bytes bitwise operations

2018-05-18 Thread Ken Hilton
On Fri, 18 May 2018 13:49:58 -0300, Facundo Batista wrote: > Once you think as the whole sequence of bytes as a sequence of bits (eight times longer, of course), all questions are easly answered, see below... I had never considered this before, but it seems very interesting. Essentially that would

Re: [Python-ideas] Make keywords KEYwords only in places they would have syntactical meaning

2018-05-18 Thread Nick Coghlan
On 19 May 2018 at 04:34, Chris Angelico wrote: > "yield" would have to be a keyword in any context where an expression > is valid. Which, in turn, makes it utterly useless as a function name, > or any other identifier. > Right, I spent a fair bit of time thinking about this in the context of usi

Re: [Python-ideas] String and bytes bitwise operations

2018-05-18 Thread Steve Barnes
On 18/05/2018 07:07, Greg Ewing wrote: > Steven D'Aprano wrote: >> But XORing bytes seems perfectly reasonable. Bytes are numbers, even >> if we display them as ASCII characters. > > Yep. Implement it for bytes, then the user can decode/encode > as appropriate for the application. > Personall

Re: [Python-ideas] Modern language design survey for "assign and compare" statements

2018-05-18 Thread Nick Coghlan
On 19 May 2018 at 10:54, Mike Miller wrote: > Background: > > While the previous discussions about assignment-expressions (PEP 572) > (abbreviated AE below) have been raging one thing that was noticeable is > that > folks have been looking back to C for a solution. > > But how are newer languages

Re: [Python-ideas] Escaped braces in format specifiers

2018-05-18 Thread Ken Kundert
On Tue, May 15, 2018 at 04:23:26PM -0400, Eric V. Smith wrote: > I'm busy at the sprints, so I don't have a lot of time to think about this. > > However, let me just say that recursive format specs are supported, > to a depth of 1. > > >>> width=10 > >>> f'{"test":{width}}' > 'test ' > > So

Re: [Python-ideas] Modern language design survey for "assign and compare" statements

2018-05-18 Thread Paul Svensson
On Sat, 19 May 2018, Greg Ewing wrote: Chris Angelico wrote: The 'as' syntax has been hammered out in great detail and is no longer recommended due to its negative interactions with existing constructs. Allowing it in arbitrary expressions has been ruled out on the grounds that the difference

Re: [Python-ideas] Modern language design survey for "assign and compare" statements

2018-05-18 Thread Greg Ewing
Paul Svensson wrote: I don't quite get what's so subtle about it, am I missing something? The "with" keyword calls "__enter__", and "as" gives it a name. Just like "-x + y" is different from "-(x + y)", I think the difference is that mentally one already tends to think of "with x as y" being

Re: [Python-ideas] Modern language design survey for "assign and compare" statements

2018-05-18 Thread Chris Angelico
On Sat, May 19, 2018 at 4:12 PM, Greg Ewing wrote: > Paul Svensson wrote: > >> I don't quite get what's so subtle about it, am I missing something? >> >> The "with" keyword calls "__enter__", and "as" gives it a name. >> >> Just like "-x + y" is different from "-(x + y)", > > > I think the differe