On Mon, Oct 6, 2014, at 19:13, Ned Deily wrote:
> In article
> ,
> Zachary Ware wrote:
> > On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote:
> > > 3. security: "fixing issues exploitable by attackers such as crashes,
> > > privilege escalation and, optionally, other issues such as denial of
> >
In article
,
Zachary Ware wrote:
> On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote:
> > 3. security: "fixing issues exploitable by attackers such as crashes,
> > privilege escalation and, optionally, other issues such as denial of
> > service attacks. Any other changes are not considered a sec
On 2014-10-06, 20:03 GMT, Victor Stinner wrote:
> I started a list of Python 2 bugs that will not be fixed:
> http://haypo-notes.readthedocs.org/python.html\
> #bugs-that-won-t-be-fixed-in-python-2-anymore
>
> It *is* possible to fix all bugs, but it requires a large amount of
> work, and we decide
On Mon, Oct 6, 2014, at 16:36, Brian Allen Vanderburg II wrote:
> I've got an idea for Python but don't know where to post it.
python-id...@python.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
U
I've got an idea for Python but don't know where to post it. It seems
like this may be the right place.
When developing Python libraries (and any other language for that
matter), items are separated into modules for organization and other
purpose. The following is an example fake framework to il
Hi,
2014-10-06 18:08 GMT+02:00 Ethan Furman :
> With the incredibly long life span of 2.7, which bugs should we *not* fix?
I started a list of Python 2 bugs that will not be fixed:
http://haypo-notes.readthedocs.org/python.html#bugs-that-won-t-be-fixed-in-python-2-anymore
It *is* possible to fix
On Mon, 06 Oct 2014 21:18:23 +0200, Christian Tismer
wrote:
> On 06.10.14 20:55, Zachary Ware wrote:
> > On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote:
> >> 3. security: "fixing issues exploitable by attackers such as crashes,
> >> privilege escalation and, optionally, other issues such as de
Eli,
Thanks for setting this up. People are evidently finding it quite useful
and are wondering if it could be more frequently run. We don't want you
to have to absorb the bandwidth costs yourself, though. Is the code you
use available somewhere? It shouldn't be hard to set up the cron job on
PSF i
On Mon, Oct 6, 2014 at 2:18 PM, Christian Tismer wrote:
> My impression is that no 3.X user ever would want to stick
> with any older version.
>
> Is that true, or am I totally wrong?
My impression is that you're mostly right, but only because those who
would still be on 3.1 are actually still on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 06.10.14 20:55, Zachary Ware wrote:
> On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote:
>> 3. security: "fixing issues exploitable by attackers such as crashes,
>> privilege escalation and, optionally, other issues such as denial of
>> service a
On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote:
> 3. security: "fixing issues exploitable by attackers such as crashes,
> privilege escalation and, optionally, other issues such as denial of
> service attacks. Any other changes are not considered a security risk
> and thus not backported to a se
On Tue, Oct 7, 2014 at 4:33 AM, Skip Montanaro wrote:
> On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote:
>> So 2.7.x is not "security only" and wouldn't reach that stage until 2020
>> under current policy.
>
> Apparently no other 2.x release qualifies as "security only" at this
> point? I would
In article
,
Skip Montanaro wrote:
> Apparently no other 2.x release qualifies as "security only" at this
> point? I would have expected at least 2.6 to fall into that category.
2.6 had its five-year run.
"Python 2.6.9 is the final security-only source-only maintenance
release of the Python 2
On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote:
> So 2.7.x is not "security only" and wouldn't reach that stage until 2020
> under current policy.
Apparently no other 2.x release qualifies as "security only" at this
point? I would have expected at least 2.6 to fall into that category.
Skip
___
In article <5432be77.40...@stoneleaf.us>,
Ethan Furman wrote:
> With the incredibly long life span of 2.7, which bugs should we *not* fix?
>
> For example, in http://bugs.python.org/issue22297 I mentioned one reason to
> not fix that bug was that the fix was not in
> 3.1-3.3, but 2.7 will outl
On Mon, 06 Oct 2014 09:08:23 -0700
Ethan Furman wrote:
> With the incredibly long life span of 2.7, which bugs should we *not* fix?*
Those that are not bugs but enhancement requests.
On that issue, you pointed out there was no regression and that enums
were never meant to be supported by the json
With the incredibly long life span of 2.7, which bugs should we *not* fix?
For example, in http://bugs.python.org/issue22297 I mentioned one reason to not fix that bug was that the fix was not in
3.1-3.3, but 2.7 will outlive all those plus a couple more.
So, what are the current guidelines on
On 06/10/14 10:33, Georg Brandl wrote:
> bytes-like object
Howdy,
two small comments:
1)
just as a quick check, I did a Python search for exactly
that phrase
https://docs.python.org/3/search.html?q=bytes-like+object&check_keywords=yes&area=default
with zero results.
Maybe it would be a good t
On 10/06/2014 06:34 AM, Nick Coghlan wrote:
> 3. "buffer" is a completely new term for most users, and one that
> refers to an implementation detail of memoryview, moreso than
> something developers actually need to care about. Using it directly in
> error messages and documentation is to make the
19 matches
Mail list logo
