Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Theodore Ts'o]

On Sun, Jun 12, 2016 at 06:53:54PM -0700, Nathaniel Smith wrote:
> 
> Speaking of full-stack perspectives, would it affect your decision if
> Debian Stretch were made robust against blocking /dev/urandom on
> AWS/GCE? Because I think we could find lots of people who would be
> overjoyed to fix Stretch before the next merge window even opens
> (AFAICT the quick fix is literally a 1 line patch), if that allowed
> the blocking /dev/urandom patches to go in upstream...

Alas, it's not just Debian.  Apparently it breaks the boot on Openwrt
as well as Ubuntu Quantal:

https://lkml.org/lkml/2016/6/13/48
https://lkml.org/lkml/2016/5/31/599

(Yay for an automated test infrastructure that fires off as soon as
you push to an externally visible git repository.  :-)

I haven't investigated to see exactly *why* it's blowing up on these
userspace setups, but it's a great reminder for why changing an
established interface is something that has to be done very carefully
indeed.

   - Ted
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 468

[Franklin? Lee]

I am. I was just wondering if there was an in-progress effort I should be
looking at, because I am interested in extensions to it.

P.S.: If anyone is missing the relevance, Raymond Hettinger's compact dicts
are inherently ordered until a delitem happens.[1] That could be "good
enough" for many purposes, including kwargs and class definition. If
CPython implements efficient compact dicts, it would be easier to propose
order-preserving (or initially-order-preserving) dicts in some places in
the standard.

[1] Whether delitem preserves order depends on whether you want to allow
gaps in your compact entry table. PyPy implemented compact dicts and
chose(?) to make dicts ordered.

On Saturday, June 11, 2016, Eric Snow  wrote:

> On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee
> > wrote:
> > Eric, have you any work in progress on compact dicts?
>
> Nope.  I presume you are talking the proposal Raymond made a while back.
>
> -eric
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 468

[Ethan Furman]

On 06/10/2016 02:13 PM, Franklin? Lee wrote:


P.S.: If anyone is missing the relevance, Raymond Hettinger's compact
dicts are inherently ordered until a delitem happens.[1] That could be
"good enough" for many purposes, including kwargs and class definition.


It would be great for kwargs, but not for class definition: del's can 
happen there, so we need PEP 520 with OrderedDict so the definition 
order is not lost when an item is deleted during class creation.


--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace (round 3)

[Berker Peksağ]

On Sun, Jun 12, 2016 at 5:37 AM, Eric Snow  wrote:
> The following code demonstrates roughly equivalent semantics for the
> default behavior::
>
>class Meta(type):
>def __prepare__(cls, *args, **kwargs):

Shouldn't this be wrapped with a classmethod decorator?

+1 from me.

--Berker
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 468

[Franklin? Lee]

I am. I was just wondering if there was an in-progress effort I should be
looking at, because I am interested in extensions to it.

P.S.: If anyone is missing the relevance, Raymond Hettinger's compact dicts
are inherently ordered until a delitem happens.[1] That could be "good
enough" for many purposes, including kwargs and class definition. If
CPython implements efficient compact dicts, it would be easier to propose
order-preserving (or initially-order-preserving) dicts in some places in
the standard.

[1] Whether delitem preserves order depends on whether you want to allow
gaps in your compact entry table. PyPy implemented compact dicts and
chose(?) to make dicts ordered.

On Saturday, June 11, 2016, Eric Snow  wrote:

> On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee
> > wrote:
> > Eric, have you any work in progress on compact dicts?
>
> Nope.  I presume you are talking the proposal Raymond made a while back.
>
> -eric
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 468

[Franklin? Lee]

I am. I was just wondering if there was an in-progress effort I should be
looking at, because I am interested in extensions to it.

P.S.: If anyone is missing the relevance, Raymond Hettinger's compact dicts
are inherently ordered until a delitem happens.[1] That could be "good
enough" for many purposes, including kwargs and class definition. If
CPython implements efficient compact dicts, it would be easier to propose
order-preserving (or initially-order-preserving) dicts in some places in
the standard.

[1] Whether delitem preserves order depends on whether you want to allow
gaps in your compact entry table. PyPy implemented compact dicts and
chose(?) to make dicts ordered.

On Saturday, June 11, 2016, Eric Snow  wrote:

> On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee
> > wrote:
> > Eric, have you any work in progress on compact dicts?
>
> Nope.  I presume you are talking the proposal Raymond made a while back.
>
> -eric
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 468

[Franklin? Lee]

I am. I was just wondering if there was an in-progress effort I should be
looking at, because I am interested in extensions to it.

P.S.: If anyone is missing the relevance, Raymond Hettinger's compact dicts
are inherently ordered until a delitem happens.[1] That could be "good
enough" for many purposes, including kwargs and class definition. If
CPython implements efficient compact dicts, it would be easier to propose
order-preserving (or initially-order-preserving) dicts in some places in
the standard.

[1] Whether delitem preserves order depends on whether you want to allow
gaps in your compact entry table. PyPy implemented compact dicts and
chose(?) to make dicts ordered.

On Saturday, June 11, 2016, Eric Snow  wrote:

> On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee
> > wrote:
> > Eric, have you any work in progress on compact dicts?
>
> Nope.  I presume you are talking the proposal Raymond made a while back.
>
> -eric
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 468

[Guido van Rossum]

Can someone block Franklin until his mailer stops resending this message?

--Guido (mobile)
On Jun 13, 2016 2:26 PM, "Franklin? Lee" 
wrote:

> I am. I was just wondering if there was an in-progress effort I should be
> looking at, because I am interested in extensions to it.
>
> P.S.: If anyone is missing the relevance, Raymond Hettinger's compact
> dicts are inherently ordered until a delitem happens.[1] That could be
> "good enough" for many purposes, including kwargs and class definition. If
> CPython implements efficient compact dicts, it would be easier to propose
> order-preserving (or initially-order-preserving) dicts in some places in
> the standard.
>
> [1] Whether delitem preserves order depends on whether you want to allow
> gaps in your compact entry table. PyPy implemented compact dicts and
> chose(?) to make dicts ordered.
>
> On Saturday, June 11, 2016, Eric Snow  wrote:
>
>> On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee
>>  wrote:
>> > Eric, have you any work in progress on compact dicts?
>>
>> Nope.  I presume you are talking the proposal Raymond made a while back.
>>
>> -eric
>>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 468

[Tim Golden]

I've set him to moderation for now. Beyond that we'd have to unsubscribe 
him altogether and ask him to resubscribe later.


TJG

On 13/06/2016 22:34, Guido van Rossum wrote:

Can someone block Franklin until his mailer stops resending this message?

--Guido (mobile)

On Jun 13, 2016 2:26 PM, "Franklin? Lee" mailto:leewangzhong%2bpyt...@gmail.com>> wrote:

I am. I was just wondering if there was an in-progress effort I
should be looking at, because I am interested in extensions to it.

P.S.: If anyone is missing the relevance, Raymond
Hettinger's compact dicts are inherently ordered until a
delitem happens.[1] That could be "good enough" for many purposes,
including kwargs and class definition. If CPython implements
efficient compact dicts, it would be easier to propose
order-preserving (or initially-order-preserving) dicts in some
places in the standard.

[1] Whether delitem preserves order depends on whether you want to
allow gaps in your compact entry table. PyPy implemented compact
dicts and chose(?) to make dicts ordered.

On Saturday, June 11, 2016, Eric Snow mailto:ericsnowcurren...@gmail.com>> wrote:

On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee
 wrote:
> Eric, have you any work in progress on compact dicts?

Nope.  I presume you are talking the proposal Raymond made a
while back.

-eric


___
Python-Dev mailing list
Python-Dev@python.org 
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/guido%40python.org



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/mail%40timgolden.me.uk



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 468

[MRAB]

On 2016-06-13 17:34, Ethan Furman wrote:

On 06/10/2016 02:13 PM, Franklin? Lee wrote:


P.S.: If anyone is missing the relevance, Raymond Hettinger's compact
dicts are inherently ordered until a delitem happens.[1] That could be
"good enough" for many purposes, including kwargs and class definition.


It would be great for kwargs, but not for class definition: del's can
happen there, so we need PEP 520 with OrderedDict so the definition
order is not lost when an item is deleted during class creation.

The order can be lost when an item is deleted because it moves the last 
item into the 'hole' left by the deleted item.


This could be avoided by expanding the items to include the index of the 
'previous' and 'next' item, so that they could be handled like a 
doubly-linked list.


The disadvantage would be that it would use more memory.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 468

[Larry Hastings]

On 06/13/2016 05:05 PM, MRAB wrote:
This could be avoided by expanding the items to include the index of 
the 'previous' and 'next' item, so that they could be handled like a 
doubly-linked list.


The disadvantage would be that it would use more memory.


Another, easier technique: don't fill holes.  Same disadvantage 
(increased memory use), but easier to write and maintain.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 468

[MRAB]

On 2016-06-14 01:47, Larry Hastings wrote:

On 06/13/2016 05:05 PM, MRAB wrote:

This could be avoided by expanding the items to include the index of
the 'previous' and 'next' item, so that they could be handled like a
doubly-linked list.

The disadvantage would be that it would use more memory.


Another, easier technique: don't fill holes.  Same disadvantage
(increased memory use), but easier to write and maintain.

When iterating over the dict, you'd need to skip over the holes, so it 
would be a good idea to compact it a some point, when there are too many 
holes.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 468

[Nathaniel Smith]

On Jun 13, 2016 6:16 PM, "MRAB"  wrote:
>
> On 2016-06-14 01:47, Larry Hastings wrote:
>>
>> On 06/13/2016 05:05 PM, MRAB wrote:
>>>
>>> This could be avoided by expanding the items to include the index of
>>> the 'previous' and 'next' item, so that they could be handled like a
>>> doubly-linked list.
>>>
>>> The disadvantage would be that it would use more memory.
>>
>>
>> Another, easier technique: don't fill holes.  Same disadvantage
>> (increased memory use), but easier to write and maintain.
>>
> When iterating over the dict, you'd need to skip over the holes, so it
would be a good idea to compact it a some point, when there are too many
holes.

Right -- but if you wait for some ratio of holes to filled space before
compacting, you can amortize the cost down, and have a good big-O
complexity for both del and iteration simultaneously. Same basic principle
as using proportional overallocation when appending to a list, just in
reverse.

I believe this is what pypy's implementation actually does.

-n
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 468

[Ethan Furman]

On 06/13/2016 05:47 PM, Larry Hastings wrote:

On 06/13/2016 05:05 PM, MRAB wrote:



This could be avoided by expanding the items to include the index of
the 'previous' and 'next' item, so that they could be handled like a
doubly-linked list.

The disadvantage would be that it would use more memory.


Another, easier technique: don't fill holes.  Same disadvantage
(increased memory use), but easier to write and maintain.


I hope this is just an academic discussion: suddenly having Python's 
dicts grow continuously is going to have nasty consequences somewhere.


--
~Ethan~

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python 3.6.0a2 is now available

[Ned Deily]

On behalf of the Python development community and the Python 3.6 release
team, I'm happy to announce the availability of Python 3.6.0a2.
3.6.0a2 is the first of four planned alpha releases of Python 3.6,
the next major release of Python.  During the alpha phase, Python 3.6
remains under heavy development: additional features will be added
and existing features may be modified or deleted.  Please keep in mind
that this is a preview release and its use is not recommended for
production environments.

You can find Python 3.6.0a2 here:

https://www.python.org/downloads/release/python-360a2/ 

The next release of Python 3.6 will be 3.6.0a3, currently scheduled for
2016-07-11.

Enjoy!

--Ned

--
  Ned Deily
  n...@python.org -- []

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Current Python 3.2 status?

[Georg Brandl]

On 06/11/2016 07:41 PM, Chi Hsuan Yen wrote:
> 
> 
> On Sun, Jun 12, 2016 at 1:02 AM, Berker Peksağ  > wrote:
> 
> On Sat, Jun 11, 2016 at 8:59 AM, Chi Hsuan Yen  > wrote:
> > Hello all,
> >
> > Georg said in February that 3.2.7 is going to be released, and now it's
> > June. Will it ever be released?
> 
> Hi,
> 
> It was delayed because of a security issue. See Georg's email at
> https://mail.python.org/pipermail/python-dev/2016-February/143400.html
> 
> --Berker
> 
> 
> Thanks for that. I'm just curious what's happening on the 3.2 branch.

Patches being available now, I'll do the releases this weekend.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com