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
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
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
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
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
>>
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
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
>
> 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
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) ^
>
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
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
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
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
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
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
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
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
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 '
>
>
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
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
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
> 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
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
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
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
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
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
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
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
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
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
[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
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)
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
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]
> 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
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
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
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 |
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
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.
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
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
[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
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)
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
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
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
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
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
>
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
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
52 matches
Mail list logo