On Wed, Dec 4, 2019 at 5:22 PM Kyle Stanley wrote:
>
> > BTW, I think 2to3 can help to move from 2&3 code to 3-only code.
>
> > Instead, we can do:
>
> > * Don't recommend u-prefix except in Python 2&3 code.
> > * Provide a tool to remove the u-prefix.
>
> +1, this seems like the smoothest way of
> BTW, I think 2to3 can help to move from 2&3 code to 3-only code.
> Instead, we can do:
> * Don't recommend u-prefix except in Python 2&3 code.
> * Provide a tool to remove the u-prefix.
+1, this seems like the smoothest way of handling it and has very minimal
impact on users. In 5+ years from
On Wed, Dec 4, 2019 at 3:16 PM Steven D'Aprano wrote:
>
> On Wed, Dec 04, 2019 at 01:47:53PM +1100, Chris Angelico wrote:
>
> > Integer sizes are a classic example of this. Is it acceptable to limit
> > your integers to 2^16? 2^32? 2^64? Python made the choice to NOT limit
> > its integers, and I
On Wed, Dec 4, 2019 at 11:49 AM Ned Batchelder wrote:
>
> On 12/3/19 8:13 PM, Inada Naoki wrote:
> > I think it is too early to determine when to remove it.
> > Even only talking about it causes blaming war.
>
> Has anyone yet given a reason to remove it?
Note that "never" is included in ”when".
On Tue, Dec 3, 2019 at 8:20 AM Mark Shannon wrote:
> The Python language does not specify limits for many of its features.
> Not having any limit to these values seems to enhance programmer freedom,
> at least superficially, but in practice the CPython VM and other Python
> virtual
> machines have
On Wed, Dec 04, 2019 at 01:47:53PM +1100, Chris Angelico wrote:
> Integer sizes are a classic example of this. Is it acceptable to limit
> your integers to 2^16? 2^32? 2^64? Python made the choice to NOT limit
> its integers, and I haven't heard of any non-toy examples where an
> attacker causes y
My random Googling turned up a new hash function tonight:
"HighwayHash". It's a keyed hash function like the SipHash we now use
for hashing strings / bytes / etc for our lovely dicts.
Key points:
* Apache 2 license
* Can use SIMD
* "5x faster than SipHash"
I think they mean 5x faster th
On Wed, Dec 4, 2019 at 1:31 PM Gregory P. Smith wrote:
> Overall I like the idea of limits... But... in my experience, limits like
> this tend to impact generated source code or generated bytecode, and thus any
> program that transitively uses those.
>
Overall, I *dislike* the idea of limits, b
On 12/3/19 8:13 PM, Inada Naoki wrote:
I think it is too early to determine when to remove it.
Even only talking about it causes blaming war.
Has anyone yet given a reason to remove it? It will change working code
into broken code. Why do that?
--Ned.
BTW, I think 2to3 can help to move fr
On Tue, Dec 3, 2019 at 8:21 AM Mark Shannon wrote:
> Hi Everyone,
>
> I am proposing a new PEP, still in draft form, to impose a limit of one
> million on various aspects of Python programs, such as the lines of code
> per module.
>
> Any thoughts or feedback?
>
> The PEP:
> https://github.com/ma
> The number of live coroutines in a running interpreter.
Could you further elaborate on what is meant by "live coroutines"? My
guesses (roughly from most likely to least likely) would be:
1) All known coroutine objects in a state of either CORO_RUNNING or
CORO_SUSPENDED, but *not* CORO_CREATED
I think it is too early to determine when to remove it.
Even only talking about it causes blaming war.
BTW, I think 2to3 can help to move from 2&3 code to 3-only code.
* "future" fixer can be remove legacy futures. But it seems to remove
all futures,
including "annotations". It should be kept
I'm going to second Chris' comment about efficiency. The purposes of
this PEP (as I read it) are:
(1) Security (less chance of code intentionally or accidentally
exceeding low-level machine limits that allow a security exploit);
(2) Improved memory use;
(3) And such improved memory use will le
- Original Message -
> From: "Pablo Galindo Salgado"
> To: "Python Dev"
> Sent: Tuesday, December 3, 2019 10:14:01 PM
> Subject: [Python-Dev] Multiple reference leaks in master
>
> Hi,
>
> Me (and Victor) have not been able to attend the buildbots for a while
> unfortunately and toda
> Maybe you or Victor can update the devguide with this information? This
is not the first time that we've been asked to pay attention to the
refleaks buildbots, and it's frustrating that they are so hard to find.
Good point! I will make a PR to the dev guide improving the existing
documentation a
At the Steering Council’s November 12th meeting, we unanimously agreed to
reject PEPs 606 and 608:
* 606 - Python Compatibility Version
* 608 - Coordinated Python Release
It was our opinion that neither PEP will effectively improve compatibility as
proposed. Additionally, PEP 606 had the probl
Maybe you or Victor can update the devguide with this information? This is
not the first time that we've been asked to pay attention to the refleaks
buildbots, and it's frustrating that they are so hard to find.
On Tue, Dec 3, 2019 at 2:17 PM Pablo Galindo Salgado
wrote:
> > How do I find the re
On 4/12/19 8:41 am, Christian Heimes wrote:
I'm strongly against removing it from Python 3 or even
raising a deprecation warning.
I agree. I know there is a maintenance cost to keeping
things like this around, but in this case it's pretty
minor. We've probably already spent more time discussing
I have a few minor copy-editing comments, but I'll submit those as a PR to the
PEPs repo (it's nothing substantial, just a few wording clarifications, and
making sure the list of added methods is complete).
Thanks to you and everyone else for the work on this!
___
On Tue, Dec 3, 2019, at 12:22, Steve Dower wrote:
> > * The number of constants in a code object.
>
> SGTM.
Two things...
First, for this one in particular, the number of constants in a code object is
hard to predict. For example, recently (I want to say 3.7), the number of
constants generated
> How do I find the refleak buildbots?
In this page:
https://buildbot.python.org/all/#/builders
all the buildbots that have "Refleaks" in the name. You can click on the
tags to filter only the "stable" and the ones in master "3.x".
On Tue, 3 Dec 2019 at 22:11, Guido van Rossum wrote:
> How do
How do I find the refleak buildbots? I went to the devguide and searched
for "buildbot", which pointed to https://www.python.org/dev/buildbot/ --
but searching there for "refleak" finds nothing.
On Tue, Dec 3, 2019 at 1:16 PM Pablo Galindo Salgado
wrote:
> Hi,
>
> Me (and Victor) have not been a
On 12/3/19 12:16 PM, Serhiy Storchaka wrote:
The 'u" string literal prefix was removed in 3.0 and reintroduced in
3.3 to help writing the code compatible with Python 2 and 3 [1]. After
the dead of Python 2.7 we will remove some deprecated features kept
for compatibility with 2.7. When we are go
On 12/3/19 2:41 PM, Christian Heimes wrote:
On 03/12/2019 19.09, Barry Warsaw wrote:
On Dec 3, 2019, at 09:16, Serhiy Storchaka
wrote:
The 'u" string literal prefix was removed in 3.0 and reintroduced
in 3.3 to help writing the code compatible with Python 2 and 3
[1]. After the dead of Python
Hi,
Me (and Victor) have not been able to attend the buildbots for a while
unfortunately and today
I was checking them out after some fixes to the SSL tests and sadly the
refleaks buildbots have many
independent issues. At least these tests are failing due to reference
leaks:
test__xxsubinter
On 12/3/2019 3:35 PM, Christian Heimes wrote:
On 03/12/2019 21.04, Ethan Furman wrote:
On 12/03/2019 09:31 AM, Guido van Rossum wrote:
I think it’s too soon to worry about this. I don’t see a reason to
harass people who maintain code based that were just recently migrated.
I'm happy to go wit
On Tue, 3 Dec 2019 09:31:22 -0800
Guido van Rossum wrote:
> I think it’s too soon to worry about this. I don’t see a reason to harass
> people who maintain code based that were just recently migrated.
Agreed with Guido. Let's wait a couple more years and rethink it.
Regards
Antoine.
_
Guido> I think it’s too soon to worry about this.
Simon> +100
Ditto. Besides, isn't support for u"..." just a variable and a couple
tests in the earliest phase of compilation? If things are going to get
deprecated/removed, I'd prefer the focus be placed on those bits which
present a significant su
On 03/12/2019 21.04, Ethan Furman wrote:
> On 12/03/2019 09:31 AM, Guido van Rossum wrote:
>
>> I think it’s too soon to worry about this. I don’t see a reason to
>> harass people who maintain code based that were just recently migrated.
>
> I'm happy to go with this, since my libraries still do
On Tue, Dec 3, 2019 at 7:42 PM Guido van Rossum wrote:
> I think it’s too soon to worry about this. I don’t see a reason to harass
> people who maintain code based that were just recently migrated.
>
+100
___
Python-Dev mailing list -- python-dev@pytho
On 12/03/2019 09:31 AM, Guido van Rossum wrote:
I think it’s too soon to worry about this. I don’t see a reason to harass
people who maintain code based that were just recently migrated.
I'm happy to go with this, since my libraries still do the 2/3 straddle.
Do we want to set a date/version
On 03/12/2019 19.09, Barry Warsaw wrote:
> On Dec 3, 2019, at 09:16, Serhiy Storchaka
> wrote:
>>
>> The 'u" string literal prefix was removed in 3.0 and reintroduced
>> in 3.3 to help writing the code compatible with Python 2 and 3
>> [1]. After the dead of Python 2.7 we will remove some deprecat
On 12/3/19 6:31 PM, Guido van Rossum wrote:
> I think it’s too soon to worry about this. I don’t see a reason to harass
> people who maintain code based that were just recently migrated.
+1 ... or code that will be migrated in the (near) future ;-) ...
Regards,
francismb
___
On 12/03/2019 09:16 AM, Serhiy Storchaka wrote:
The 'u" string literal prefix was removed in 3.0 and reintroduced in 3.3 to help writing
the code compatible with Python 2 and 3 [1]. After the dead of Python 2.7 we will remove some
deprecated features kept for compatibility with 2.7. When we ar
On Dec 3, 2019, at 09:16, Serhiy Storchaka wrote:
>
> The 'u" string literal prefix was removed in 3.0 and reintroduced in 3.3 to
> help writing the code compatible with Python 2 and 3 [1]. After the dead of
> Python 2.7 we will remove some deprecated features kept for compatibility
> with 2.7
On 03/12/2019 16:15, Mark Shannon wrote:
Hi Everyone,
I am proposing a new PEP, still in draft form, to impose a limit of one
million on various aspects of Python programs, such as the lines of code
per module.
Any thoughts or feedback?
The PEP:
https://github.com/markshannon/peps/blob/one-
On 03/12/2019 17:16, Serhiy Storchaka wrote:
The 'u" string literal prefix was removed in 3.0 and reintroduced in 3.3
to help writing the code compatible with Python 2 and 3 [1]. After the
dead of Python 2.7 we will remove some deprecated features kept for
compatibility with 2.7. When we are go
I think it’s too soon to worry about this. I don’t see a reason to harass
people who maintain code based that were just recently migrated.
On Tue, Dec 3, 2019 at 09:21 Serhiy Storchaka wrote:
> The 'u" string literal prefix was removed in 3.0 and reintroduced in 3.3
> to help writing the code co
On 03Dec2019 0815, Mark Shannon wrote:
Hi Everyone,
I am proposing a new PEP, still in draft form, to impose a limit of one
million on various aspects of Python programs, such as the lines of code
per module.
I assume you're aiming for acceptance in just under four months? :)
Any thoughts
The 'u" string literal prefix was removed in 3.0 and reintroduced in 3.3
to help writing the code compatible with Python 2 and 3 [1]. After the
dead of Python 2.7 we will remove some deprecated features kept for
compatibility with 2.7. When we are going to deprecate and remove the
"u" prefix?
On Wed, Dec 4, 2019 at 3:20 AM Mark Shannon wrote:
>
> Hi Everyone,
>
> I am proposing a new PEP, still in draft form, to impose a limit of one
> million on various aspects of Python programs, such as the lines of code
> per module.
>
> Any thoughts or feedback?
>
The main justification for these
I would not have such a small limit.
I can envisage generating code from a log then evaluating that code. 1
million lines could be small, given the speed of the interpreter on modern
machines.
One might want to generate data as a Python file rather than a pile and
load that as a module. There might
Hi Everyone,
I am proposing a new PEP, still in draft form, to impose a limit of one
million on various aspects of Python programs, such as the lines of code
per module.
Any thoughts or feedback?
The PEP:
https://github.com/markshannon/peps/blob/one-million/pep-100.rst
Cheers,
Mark.
F
Hi,
Le lun. 2 déc. 2019 à 08:18, Larry Hastings a écrit :
> My random Googling turned up a new hash function tonight: "HighwayHash".
> It's a keyed hash function like the SipHash we now use for hashing strings /
> bytes / etc for our lovely dicts.
>
> Key points:
>
> Apache 2 license
> Can use
44 matches
Mail list logo
