I feel like you are actively undermining attempts to prevent exploitation
of known vulnerabilities because the software in question is currently too
slow.
For a 4-8% performance penalty, we could just add the CFLAGS to the build
now and not worry about it.
I give up.
On Friday, September 21, 201
There is much reason to believe it won't help, and you have given little
reason to believe that it will help, or that you even properly understand
how the flag mitigates Spectre in programs where it does help.
I am not undermining your attempts for the sake of performance. I am trying
to help you
On 19/09/2018 23.12, Ned Deily wrote:
> Update: not surprisingly, there have been a number of issues that have popped
> up during and since the sprint that we would like to ensure are addressed in
> 3.7.1 and 3.6.7. In order to do so, I've been holding off on starting the
> releases. I think we
On Sep 21, 2018, at 05:37, Christian Heimes wrote:
> On 19/09/2018 23.12, Ned Deily wrote:
>> Update: not surprisingly, there have been a number of issues that have
>> popped up during and since the sprint that we would like to ensure are
>> addressed in 3.7.1 and 3.6.7. In order to do so, I've
> What about the small integers cache?
I believe the small integers cache is only used to reduce the number of
objects -- I don't think there's any code (in CPython itself) that just
*assumes* that because an int is small it must be in the cache. So it
should be fine.
On Thu, Sep 20, 2018 at 11:2
On 21/09/2018 16.26, Guido van Rossum wrote:
>> What about the small integers cache?
>
> I believe the small integers cache is only used to reduce the number of
> objects -- I don't think there's any code (in CPython itself) that just
> *assumes* that because an int is small it must be in the cach
On Wed, Sep 19, 2018 at 4:26 PM Ned Deily wrote:
> On Sep 19, 2018, at 13:30, Yury Selivanov wrote:
[..]
> > Currently it's designed to expose "PyContext*" and "PyContextVar*"
> > pointers. I want to change that to "PyObject*" as using non-PyObject
> > pointers turned out to be a very bad idea (
> On Sep 21, 2018, at 06:53, Stefan Behnel wrote:
>
> Totally. This might actually be more relevant for Cython than for CPython
> in the end, because it wouldn't be limited to the stdlib and its core modules.
>
> It's a bit more difficult for us, because this probably won't work easily
> across
ACTIVITY SUMMARY (2018-09-14 - 2018-09-21)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open6795 (-24)
closed 39723 (+111)
total 46518 (+87)
Open issues w
On Fri, Sep 21, 2018 at 8:16 AM Christian Heimes
wrote:
> On 21/09/2018 16.26, Guido van Rossum wrote:
> >> What about the small integers cache?
> >
> > I believe the small integers cache is only used to reduce the number of
> > objects -- I don't think there's any code (in CPython itself) that j
Hi,
A humble proposal for a switch-like statement syntax for Python:
- - -
switch blah in (100, 2, 30, 'bumm'):
dosomething1()
x = 88
case blah in (44, 55):
otherstuff(9)
case blah in (8):
boo()
else:
wawa()
- - -
So, let's use, and allow only *tuples*.
As early as possible, build a ju
On Tue, Sep 18, 2018 at 3:00 PM, Neil Schemenauer
wrote:
> The users of Python are pretty diverse so it depends on who you ask.
> Some would like a giant executable that includes everything they
> need (so of like the Go approach). Other people want an executable
> that has just importlib inside
Guido van Rossum schrieb am 21.09.2018 um 19:35:
> Though now I start worrying about interned strings. That's a concept that's
> a little closer to being a feature.
True. While there's the general '"ab"+"cd" is (not) "abcd"' caveat, I'm
sure quite a bit of code out there assumes that parsed identi
First, this sounds like it belongs on python-ideas, not python-dev.
Second, when you do send a message to python-ideas, it'll help to
accompany it with a realistic example usage that motivates your
proposal.
On Fri, Sep 21, 2018 at 11:18 AM wrote:
>
> Hi,
>
> A humble proposal for a switch-like st
As Michael said, this belongs on python-ideas, but it's interesting. I'd
support it, though my input in that regard is worth approximately $0.00. ;)
It's the core devs and especially the eventual BDFL replacement whom you
would have to convince.
Without getting into an extended discussion here on
On Thu, Sep 20, 2018 at 11:20 PM, Stefan Behnel wrote:
> What about the small integers cache? The C serialisation generates several
> PyLong objects that would normally reside in the cache. Is this handled
> somewhere? I guess the cache could entirely be loaded from the data
> segment. And the sa
On 21/09/18 08:11, Wes Turner wrote:
I feel like you are actively undermining attempts to prevent
exploitation of known vulnerabilities because the software in question
is currently too slow.
Did you write "How to Win Friends And Influence People"?
--
My fellow Pythonistas, ask not what our
There's already a rejected PEP about a switch statement:
https://www.python.org/dev/peps/pep-3103/. There's no point bringing this
up again unless you have a new use case.
There have been several promising posts to python-ideas about the much more
powerful idea of a "match" statement. Please searc
> There have been several promising posts to python-ideas about the much
more powerful idea of a "match" statement
I actually even started working on a PEP about this (pattern matching), but
then decided to postpone it because it is unlikely that anything of this
size can be discussed/accepted in
Hi all,
I've got a pretty good sense of how signal handling works in the
runtime (i.e. via a dance with the eval loop), but still have some
questions:
1. Why do we restrict calls to signal.signal() to the main thread?
2. Why must signal handlers run in the main thread?
3. Why does signal handling
Le sam. 22 sept. 2018 à 01:05, Eric Snow a écrit :
> 3. Why does signal handling operate via the "pending calls" machinery
> and not distinctly?
Signals can be received anytime, between two instructions at the
machine code level. But the Python code base is rarely reentrant.
Moreover, you can get
On Friday, September 21, 2018, Mark Lawrence wrote:
> On 21/09/18 08:11, Wes Turner wrote:
>
>> I feel like you are actively undermining attempts to prevent exploitation
>> of known vulnerabilities because the software in question is currently too
>> slow.
>>
>>
> Did you write "How to Win Friend
22 matches
Mail list logo
