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 or
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
>> evaluation of those argumen
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 16/05
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 010011
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 operators: & (and), | (or), ^ (
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 questi
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
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
common
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
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 start
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
> >>>bytestri
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 that used
> augmented
>
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 t
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) ^
> numpy.frombuffer(b"World", dtype=num
> 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
hav
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 '
>
> So first the string
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 t
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 17, 2018 at 03:49:02PM
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
bytestri
> 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 supported, to a
>> depth of 1.
>>
>> >>> width=1
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 real
> elapsed time.
>
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 option:
Any new keywords int
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 23:59
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 perspective, using /
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
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 your position is 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 bu
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 s
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 set.
Of
>> course, the
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 | 2017-01-01T00
[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
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 second.
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 rotation for brief peri
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)
bre
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 to python now is prett
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. That'
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 the question was about s
[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 in
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)
> 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 backwards
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 tha
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 change
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] http://docs.astropy.org/en/stable/ti
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 allo
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
> future") auto-download
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 referring to. The problem with leap
>> seconds is tha
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
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 and
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 "where". I'm hoping that t
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.
--
Greg
___
Python-i
On 2018-05-17 11:02 PM, Neil Girdhar wrote:
For that reason, I'd like to make a more modest proposal to *only* add
a verbatim versions of keywords as necessary, e.g., "\where" or
"\given". That way, there will be no temptation to use that syntax in
any other place. If a new version of Pytho
Carl Smith wrote:
> I wrote:
The trouble with explicitly overriding keywords is that it still requires old
code to
be changed whenever a new keyword is added...
>
For the purpose of this discussion, let's say that if any code implicitly
enables a new feature (by simply using it), all the cod
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 more expressive. The backslash is no more expressive than
> trailing
55 matches
Mail list logo
