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

2018-05-17 Thread Neil Girdhar
On Thu, May 17, 2018 at 9:35 PM Steven D'Aprano wrote: > On Thu, May 17, 2018 at 11:41:33AM -0700, Neil Girdhar wrote: > > My preference is to do nothing. If you end up making "where" a keyword > in > > Python 3.8, numpy will probably: > > This is only incidently about

Re: [Python-ideas] Runtime assertion with no overhead when not active

2018-05-17 Thread Eloi Gaudry
On Thu, 2018-05-17 at 03:09 +1000, Steven D'Aprano wrote: > On Wed, May 16, 2018 at 01:27:50PM +, Eloi Gaudry wrote: > > On Wed, 2018-05-16 at 21:15 +1000, Steven D'Aprano wrote: > > > On Wed, May 16, 2018 at 08:29:00AM +, Eloi Gaudry wrote: > > > > Is there some interest in the proposal

Re: [Python-ideas] Keyword declarations

2018-05-17 Thread Adam Bartoš
On Wed May 16 20:53:46 EDT 2018, Steven D'Aprano wrote: > On Wed, May 16, 2018 at 07:24:19PM +0200, Adam Bartoš wrote: >> Hello, >> >> I have yet another idea regarding the the clashes between new keywords and >> already used names. How about introducing two new keywords *wink* that >> would serve

Re: [Python-ideas] Specifying Python version

2018-05-17 Thread Brice Parent
It's in the same spirit as what I proposed in my answer to Guido's crazy idea, but set at a different level (in code instead of in setup.py in my proposal). I think it belongs to the same discussion, so I'm copying it here (sorry for the inconvenience if you already read it there): Le

Re: [Python-ideas] Runtime assertion with no overhead when not active

2018-05-17 Thread Chris Angelico
On Thu, May 17, 2018 at 5:46 PM, Eloi Gaudry wrote: >> But the most important reason is that I'm not really interested in >> adding a new keyword for this. I would much prefer to explore ways >> to >> allow ordinary functions to receive arguments and be able to delay >>

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

2018-05-17 Thread Serhiy Storchaka
17.05.18 13:53, Ken Hilton пише: We all know the bitwise operators: & (and), | (or), ^ (xor), and ~ (not). We know how they work with numbers: 420 ^ 502 110100100 10110 == XOR == 001010010 = 82 But it might be useful in some cases to (let's say) xor a string (or bytestring): The

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

2018-05-17 Thread Steven D'Aprano
On Thu, May 17, 2018 at 03:49:02PM +0300, Serhiy Storchaka wrote: > 17.05.18 15:20, Steven D'Aprano пише: > >On Thu, May 17, 2018 at 02:14:10PM +0300, Serhiy Storchaka wrote: > >>17.05.18 13:53, Ken Hilton пише: > >>>But it might be useful in some cases to (let's say) xor a string (or >

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

2018-05-17 Thread Carl Smith
> The trouble with explicitly overriding keywords is that it still requires old code to > be changed whenever a new keyword is added... Nope. That's the exact thing my proposal avoids. I'm not sure it also does everything everyone else wants it to do, so it may be a bad idea, but you would not

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

2018-05-17 Thread Antoine Pitrou
Indeed, at this point Numpy sounds like the ideal solution for such use cases. Regards Antoine. On Thu, 17 May 2018 13:06:59 +0200 Stephan Houben wrote: > Seems you want numpy: > > >>> import numpy > >>> numpy.frombuffer(b"Hello", dtype=numpy.uint8) ^ >

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

2018-05-17 Thread Steven D'Aprano
On Thu, May 17, 2018 at 06:03:32PM +1200, Greg Ewing wrote: > Steven D'Aprano wrote: > >Let's say you're reading from a CSV file, creating an object from each > >row, and processing it: > > Okay, I can see it could be useful for situations like that. > > But this is still a completely different

[Python-ideas] String and bytes bitwise operations

2018-05-17 Thread Ken Hilton
Hi all, We all know the bitwise operators: & (and), | (or), ^ (xor), and ~ (not). We know how they work with numbers: 420 ^ 502 110100100 10110 == XOR == 001010010 = 82 But it might be useful in some cases to (let's say) xor a string (or bytestring): HELLO ^ world 01001000 01000101

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

2018-05-17 Thread Serhiy Storchaka
17.05.18 15:20, Steven D'Aprano пише: On Thu, May 17, 2018 at 02:14:10PM +0300, Serhiy Storchaka wrote: 17.05.18 13:53, Ken Hilton пише: But it might be useful in some cases to (let's say) xor a string (or bytestring): The question is how common a need of these operations? If it is not

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

2018-05-17 Thread Alexandre Brault
On 2018-05-17 2:03 AM, Greg Ewing wrote: Steven D'Aprano wrote: Let's say you're reading from a CSV file, creating an object from each row, and processing it: Okay, I can see it could be useful for situations like that. But this is still a completely different use case from the one that

Re: [Python-ideas] Inline assignments using "given" clauses

2018-05-17 Thread Nick Coghlan
On 15 May 2018 at 01:53, Tim Peters wrote: > [Nick] > > The question would then turn to "What if you just want to bind the target > > name, without considering the old value?". And then *that's* where "NAME > : = > > EXPR" would come in: as an augmented assignment operator

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

2018-05-17 Thread Stephan Houben
Seems you want numpy: >>> import numpy >>> numpy.frombuffer(b"Hello", dtype=numpy.uint8) ^ numpy.frombuffer(b"World", dtype=numpy.uint8) array([31, 10, 30, 0, 11], dtype=uint8) Stephan 2018-05-17 12:53 GMT+02:00 Ken Hilton : > Hi all, > > We all know the bitwise

Re: [Python-ideas] Runtime assertion with no overhead when not active

2018-05-17 Thread Steven D'Aprano
On Thu, May 17, 2018 at 07:46:41AM +, Eloi Gaudry wrote: > On Thu, 2018-05-17 at 03:09 +1000, Steven D'Aprano wrote: > I proposed to have several ways to set it (see previous answers) : one > would be extension based and the other would rely on having a builtin > value that one would be able

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

2018-05-17 Thread Steven D'Aprano
On Thu, May 17, 2018 at 02:14:10PM +0300, Serhiy Storchaka wrote: > 17.05.18 13:53, Ken Hilton пише: > >We all know the bitwise operators: & (and), | (or), ^ (xor), and ~ > >(not). We know how they work with numbers: > > > >420 ^ 502 > > > >110100100 > >10110 > >== XOR == > >001010010 > >= 82

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

2018-05-17 Thread Nick Coghlan
On 15 May 2018 at 16:23, 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 ' > >

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

2018-05-17 Thread Ken Hilton
On Thu, 17 May 2018 23:13:22 +1000, Steven D'Aprano wrote: > No, he didn't explain the meaning. He gave an example, but not a reason why it should do what he showed. > > Why should the *abstract character* 'H' XORed with the abstract character 'w' return the abstract character '?'? Why shouldn't

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

2018-05-17 Thread Terry Reedy
On 5/17/2018 6:53 AM, Ken Hilton wrote: Hi all, We all know the bitwise operators: & (and), | (or), ^ (xor), and ~ (not). We know how they work with numbers: 420 ^ 502 110100100 10110 == XOR == 001010010 = 82 But it might be useful in some cases to (let's say) xor a string (or

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

2018-05-17 Thread Antoine Pitrou
I agree with Steven. XORing unicode strings doesn't make sense, and is pointless anyway. The only interesting question is whether we want to add bytewise operations to the stdlib. Regards Antoine. On Thu, 17 May 2018 23:13:22 +1000 Steven D'Aprano wrote: > On Thu, May

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

2018-05-17 Thread Eric V. Smith
> On May 17, 2018, at 9:56 AM, Nick Coghlan wrote: > >> On 15 May 2018 at 16:23, 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

Re: [Python-ideas] High Precision datetime

2018-05-17 Thread Chris Barker via Python-ideas
On Thu, May 17, 2018 at 10:14 AM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > The other issue with leap-seconds is that python's datetime doesn't > support them :-) > > That's not entirely true. Since the implementation of PEP 495, it is > possible to represent the 23:59:60

Re: [Python-ideas] High Precision datetime

2018-05-17 Thread Chris Barker via Python-ideas
On Tue, May 15, 2018 at 11:21 AM, Rob Speer wrote: > > I'm sure that the issue of "what do you call the leap second itself" is > not the problem that Chris Barker is referring to. The problem with leap > seconds is that they create unpredictable differences between UTC and

Re: [Python-ideas] High Precision datetime

2018-05-17 Thread Alexander Belopolsky
On Thu, May 17, 2018 at 12:56 PM Chris Barker via Python-ideas < python-ideas@python.org> wrote: > The other issue with leap-seconds is that python's datetime doesn't support them :-) That's not entirely true. Since the implementation of PEP 495, it is possible to represent the 23:59:60 as

Re: [Python-ideas] __dir__ in which folder is this py file

2018-05-17 Thread Chris Barker via Python-ideas
On Mon, May 7, 2018 at 9:17 AM, Steven D'Aprano wrote: > I'm arguing that for some people, your preferred syntax *is* more > distracting and hard to comprehend than the more self-descriptive > version with named functions. then use Path.joinpath() if you want. > From that

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

2018-05-17 Thread Stephan Houben
OK, that was a silly joke, but did you realize that the following already WORKS TODAY: >>> class Foo: ... pass >>> f = Foo() >>> f.__dict__["if"] = 42 >>> f.퐢퐟 42 That's right, I can access a member whose name is a keyword by simply using Unicode bold. Because Python normalizes Unicode fonts

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

2018-05-17 Thread Stephan Houben
Fortunately we have Unicode bold characters nowadays 퐢퐟 if 퐢퐧 in: 퐫퐞퐭퐮퐫퐧 return Look ma! No syntactic ambiguity! Stephan 2018-05-17 19:10 GMT+02:00 Chris Barker via Python-ideas < python-ideas@python.org>: > On Wed, May 16, 2018 at 2:09 PM, Carl Smith wrote: > >> If

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

2018-05-17 Thread Chris Barker via Python-ideas
On Wed, May 16, 2018 at 2:09 PM, Carl Smith wrote: > If your position is that Guido shouldn't introduce keywords that are > currently used as names at all, > Exactly -- which is why I'm wondering my no one (that I've seen -- long thread) is presenting the backwards

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

2018-05-17 Thread Steven D'Aprano
On Thu, May 17, 2018 at 11:41:33AM -0700, Neil Girdhar wrote: > My preference is to do nothing. If you end up making "where" a keyword in > Python 3.8, numpy will probably: This is only incidently about "where". I'm hoping that the "where" (or "given") proposal is rejected. It is so verbose

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

2018-05-17 Thread Chris Angelico
On Fri, May 18, 2018 at 5:53 AM, Ethan Furman wrote: > On 05/17/2018 12:13 PM, Tim Peters wrote: > >> Other things can cause the Earth's rotation to speed up temporarily >> (like some major geological events), but they've only been able to >> overcome factors acting to slow

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

2018-05-17 Thread Eric V. Smith
[Resending due to Google Groups getting involved and giving me an error] On 5/17/2018 2:41 PM, Neil Girdhar wrote: My preference is to do nothing.  If you end up making "where" a keyword in Python 3.8, numpy will probably: * rename their where function to "where_" in 3.8 * add a where_ alias

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

2018-05-17 Thread Rob Cliffe via Python-ideas
On 16/05/2018 10:12, Stephan Houben wrote: Hi all, One problem already alluded to with the \identifier syntax is that it only works if the old Python version is sufficiently recent to understand \. What about using parentheses to allow a keyword to be used as an identifier: (where)(x, y)

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

2018-05-17 Thread Neil Girdhar
On Thursday, May 17, 2018 at 5:55:30 PM UTC-4, Carl Smith wrote: > > > I believe this is the first proposal that allows future-proofing of new > code while preserving > > complete backward compatibility. > > My proposal removes the need to future proof anything, and only requires > subtle

Re: [Python-ideas] High Precision datetime

2018-05-17 Thread Wes Turner
AstroPy solves for leap seconds [1][2] according to the IAU ERFA (SOFA) library [3] and the IERS-B and IERS-A tables [4]. IERS-B tables ship with AstroPy. The latest IERS-A tables ("from 1973 though one year into the future") auto-download on first use [5]. [1]

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

2018-05-17 Thread Carl Smith
> I believe this is the first proposal that allows future-proofing of new code while preserving > complete backward compatibility. My proposal removes the need to future proof anything, and only requires subtle changes to the syntax (nothing visually different). It also preserves perfect

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

2018-05-17 Thread Neil Girdhar
On Thursday, May 17, 2018 at 5:40:05 PM UTC-4, Carl Smith wrote: > > > My preference is to do nothing. If you end up making "where" a keyword > in Python 3.8, numpy will probably: > > * rename their where function to "where_" in 3.8 > > * add a where_ alias in Python < 3.8. > > This assumes

Re: [Python-ideas] High Precision datetime

2018-05-17 Thread Alexander Belopolsky
On Thu, May 17, 2018 at 1:33 PM Chris Barker wrote: > > On Thu, May 17, 2018 at 10:14 AM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: >> [...] Since the implementation of PEP 495, it is >> possible to represent the 23:59:60 as 23:59:59 with the "fold" bit

Re: [Python-ideas] High Precision datetime

2018-05-17 Thread Alexander Belopolsky
On Thu, May 17, 2018 at 2:51 PM Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > TAI | UTC > -+ > 2016-12-31T23:59:35 | 2016-12-31T23:59:59 > 2016-12-31T23:59:36 | 2016-12-31T23:59:60 > 2016-12-31T23:59:37 |

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

2018-05-17 Thread Ethan Furman
On 05/17/2018 12:13 PM, Tim Peters wrote: Other things can cause the Earth's rotation to speed up temporarily (like some major geological events), but they've only been able to overcome factors acting to slow rotation for brief periods, and never yet got near to overcoming them by a full

Re: [Python-ideas] High Precision datetime

2018-05-17 Thread Chris Barker via Python-ideas
now we really have gotten OT... But thanks! that was my question! -CHB Alexander covered the Python part of this, so I'll answer the possible > higher-level question: we haven't yet needed a "negative" leap > second, and it's considered unlikely (but not impossible) that we ever > will.

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

2018-05-17 Thread Neil Girdhar
My preference is to do nothing. If you end up making "where" a keyword in Python 3.8, numpy will probably: * rename their where function to "where_" in 3.8 * add a where_ alias in Python < 3.8. And then people will have to fix their code in 3.8 anyway. Only instead of learning a new verbatim

Re: [Python-ideas] High Precision datetime

2018-05-17 Thread Alexander Belopolsky
On Thu, May 17, 2018 at 3:13 PM Tim Peters wrote: > [Chris Barker] > > Does that support the other way -- or do we never lose a leap second > anyway? > > (showing ignorance here) > > Alexander covered the Python part of this, ... > No, I did not. I did not realize that

Re: [Python-ideas] High Precision datetime

2018-05-17 Thread Tim Peters
[Chris Barker] > Does that support the other way -- or do we never lose a leap second anyway? > (showing ignorance here) Alexander covered the Python part of this, so I'll answer the possible higher-level question: we haven't yet needed a "negative" leap second, and it's considered unlikely (but

[Python-ideas] Syntactic Sugar: Post-Conditions for Guard Clauses

2018-05-17 Thread Manuel Barkhau
Hello, has there been consideration for implementing the following new syntax: def my_fun(elements): results = [] for elem in elements: ... continue if not is_valid(elem) ... results.append(result)

Re: [Python-ideas] Syntactic Sugar: Post-Conditions for Guard Clauses

2018-05-17 Thread Chris Barker via Python-ideas
On Thu, May 17, 2018 at 12:55 PM, Manuel Barkhau wrote: > continue if not is_valid(elem) > ... > how is this better than: if not is_valid(elem): continue ? But even if it is, that might be a consideration for a new language, but adding it

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

2018-05-17 Thread Greg Ewing
Steven D'Aprano wrote: Let's say you're reading from a CSV file, creating an object from each row, and processing it: Okay, I can see it could be useful for situations like that. But this is still a completely different use case from the one that started this discussion, which was making it

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

2018-05-17 Thread MRAB
On 2018-05-17 22:38, Rob Cliffe via Python-ideas wrote: On 16/05/2018 10:12, Stephan Houben wrote: Hi all, One problem already alluded to with the \identifier syntax is that it only works if the old Python version is sufficiently recent to understand \. What about using parentheses to

Re: [Python-ideas] High Precision datetime

2018-05-17 Thread Wes Turner
https://en.wikipedia.org/wiki/Leap_second : > Insertion of each UTC leap second is usually decided about six months in advance by the International Earth Rotation and Reference Systems Service (IERS), when needed to ensure that the difference between the UTC and UT1 readings will never exceed 0.9

Re: [Python-ideas] High Precision datetime

2018-05-17 Thread Alexander Belopolsky
On Thu, May 17, 2018 at 7:12 PM Wes Turner wrote: > AstroPy solves for leap seconds [1][2] according to the IAU ERFA (SOFA) > library [3] and the IERS-B and IERS-A tables [4]. IERS-B tables ship with > AstroPy. The latest IERS-A tables ("from 1973 though one year into the >

Re: [Python-ideas] High Precision datetime

2018-05-17 Thread Nathaniel Smith
On Thu, May 17, 2018 at 9:49 AM, Chris Barker via Python-ideas wrote: > On Tue, May 15, 2018 at 11:21 AM, Rob Speer wrote: >> >> >> I'm sure that the issue of "what do you call the leap second itself" is >> not the problem that Chris Barker is

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

2018-05-17 Thread Steven D'Aprano
On Thu, May 17, 2018 at 10:54:25PM +0100, Carl Smith wrote: > My proposal removes the need to future proof anything, and only requires > subtle changes to the syntax (nothing visually different). It also preserves > perfect backwards compatibility. Just saying :) I must admit, I don't understand