Re: [Python-Dev] PEP XXX: Compact ordered dict

On Tue, Jun 21, 2016 at 12:17 PM, Oleg Broytman wrote: > Hi! > > On Tue, Jun 21, 2016 at 11:14:39AM +0900, INADA Naoki > wrote: >> Here is my draft, but I haven't >> posted it yet since >> my English is much worse than C. >> https://www.dropbox.com/s/s85n9b2309k03cq/pep-compact-dict.txt?dl=0 > >

Re: [Python-Dev] PEP XXX: Compact ordered dict

Hi! On Tue, Jun 21, 2016 at 11:14:39AM +0900, INADA Naoki wrote: > Here is my draft, but I haven't > posted it yet since > my English is much worse than C. > https://www.dropbox.com/s/s85n9b2309k03cq/pep-compact-dict.txt?dl=0 It's good enough for a start (if a PEP is needed at all). If you p

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

Donald Stufft writes: > I guess one question would be, what does the secrets module do if > it’s on a Linux that is too old to have getrandom(0), off the top > of my head I can think of: > > * Silently fall back to reading os.urandom and hope that it’s been > seeded. > * Fall back to os.

Re: [Python-Dev] PEP 487: Simpler customization of class creation

> On Jun 20, 2016, at 5:41 PM, Tim Delaney wrote: > > Although not a Jython developer, I've looked into the code a few times. > > The major stumbling block as I understand it will be that Jython uses a > ConcurrentHashMap as the underlying structure for a dictionary. This would > need to chan

[Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 4)

I've updated PEP 520 to reflect a clearer focus on the definition order and less emphasis on OrderedDict. -eric === PEP: 520 Title: Preserving Class Attribute Definition Order Version: $Revision$ Last-Modified: $Date$ Author: Eric Snow Status: Draft Type: St

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

>> >> Finally, it seems someone is working on making all dicts ordered. Does that >> mean this will soon be obsolete? > > Nope. Having an ordered definition namespace by default does not give > us __definition_order__ for free. Furthermore, the compact dict under > consideration isn't strictly or

Re: [Python-Dev] Review of PEP 520: Ordered Class Definition Namespace

On Mon, Jun 20, 2016 at 10:32 AM, Guido van Rossum wrote: > - I don't like the exception for dunder names. I can see that __module__, > __name__ etc. that occur in every class are distractions, but since you're > adding methods, you should also add methods with dunder names like > __init__ or __g

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On Mon, Jun 20, 2016 at 9:49 AM, Guido van Rossum wrote: > I agree it's better to define the order as computed at runtime. I don't > think there's much of a point to mandate that all builtin/extension types > reveal their order too -- I doubt there will be many uses for that -- but I > don't want

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On Fri, Jun 17, 2016 at 7:32 PM, Nick Coghlan wrote: > The discussion in the PEP 487 thread made me realise that I'd like to > see a discussion in PEP 520 regarding whether or not to define > __definition_order__ for builtin types initialised via PyType_Ready or > created via PyType_FromSpec in ad

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On 21 June 2016 at 06:12, Guido van Rossum wrote: > OK, basically you're arguing that knowing the definition order of class > attributes is often useful when (ab)using Python for things like schema or > form definitions. There are a few ways to go about it: > > 1. A hack using a global creation c

Re: [Python-Dev] New security-sig mailling list

On 06/20/2016 03:02 PM, Chris Jerdonek wrote: I would recommend clarifying the relationship of the SIG to the Python Security Response Team ( https://www.python.org/news/security ), or at least clarifying that the SIG is different from the PSRT (and that security reports should not be sent to th

Re: [Python-Dev] frame evaluation API PEP

On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon mailto:br...@python.org>> wrote: MRAB's response made me think of a possible approach: the co_extra field could be the very last field of the PyCodeObject struct and only present if a certain flag is set in co_flags. This is similar to a trick used

Re: [Python-Dev] Problem

General questions like this belong on python-list, not python-dev. To answer your question, though, you need to run that command from the Windows Command Prompt, not from the Python interpreter. ___ Python-Dev mailing list Python-Dev@python.org https://m

Re: [Python-Dev] frame evaluation API PEP

Couple uses of "it" here are ambiguous -- are you saying we don't need co_extra after all, or that we can safely insist it's a dict, or...? On Mon, Jun 20, 2016 at 1:20 PM, Dino Viehland via Python-Dev < python-dev@python.org> wrote: > Mark wrote: > > > Dino and I thought of two potential alterna

Re: [Python-Dev] Problem

Hello. We are sorry but we cannot help you. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/

Re: [Python-Dev] New security-sig mailling list

On Mon, Jun 20, 2016 at 12:24 PM, Ethan Furman wrote: > > has been created: > > https://mail.python.org/mailman/listinfo/security-sig > > The purpose of this list is to discuss security-related enhancements to > Python while having as little impact on backwards compatibility as possible. I wou

[Python-Dev] Problem

Hi: My daughter and I are trying to update to 8.1.2,but every time we try this happens >From the API To the Python window: Please advise ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/list

Re: [Python-Dev] frame evaluation API PEP

Mark wrote: > > Dino and I thought of two potential alternatives, neither of which we > > have taken the time to implement and benchmark. One is to simply have > > a hash table of memory addresses to JIT data that is kept on the JIT > > side of things. Obviously it would be nice to avoid the overhe

Re: [Python-Dev] frame evaluation API PEP

On Mon, 20 Jun 2016 at 13:43 Christian Heimes wrote: > On 2016-06-20 22:18, Guido van Rossum wrote: > > On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon > > wrote: > > > > MRAB's response made me think of a possible approach: the > > co_extra field could be

Re: [Python-Dev] frame evaluation API PEP

On 2016-06-20 22:18, Guido van Rossum wrote: > On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon > wrote: > > MRAB's response made me think of a possible approach: the > co_extra field could be the very last field of the PyCodeObject > struct and only

Re: [Python-Dev] frame evaluation API PEP

On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon wrote: > MRAB's response made me think of a possible approach: the co_extra field >> could be the very last field of the PyCodeObject struct and only present if >> a certain flag is set in co_flags. This is similar to a trick used by X11 >> (I know,

Re: [Python-Dev] PEP 487: Simpler customization of class creation

OK, basically you're arguing that knowing the definition order of class attributes is often useful when (ab)using Python for things like schema or form definitions. There are a few ways to go about it: 1. A hack using a global creation counter

Re: [Python-Dev] frame evaluation API PEP

On Sun, 19 Jun 2016 at 19:37 Guido van Rossum wrote: > On Sun, Jun 19, 2016 at 6:29 PM, Brett Cannon wrote: > >> >> >> On Sat, 18 Jun 2016 at 21:49 Guido van Rossum wrote: >> >>> Hi Brett, >>> >>> I've got a few questions about the specific design. Probably you know >>> the answers, it would be

Re: [Python-Dev] frame evaluation API PEP

On Sun, 19 Jun 2016 at 21:01 Mark Shannon wrote: > > > On 19/06/16 18:29, Brett Cannon wrote: > > > > > > On Sat, 18 Jun 2016 at 21:49 Guido van Rossum > > wrote: > > > > Hi Brett, > > > > I've got a few questions about the specific design. Probably you > > k

[Python-Dev] New security-sig mailling list

has been created: https://mail.python.org/mailman/listinfo/security-sig The purpose of this list is to discuss security-related enhancements to Python while having as little impact on backwards compatibility as possible. Once a proposal is ready it will be presented to Python Dev. (This te

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Mon, Jun 20, 2016 at 9:48 PM, Guido van Rossum wrote: > On Thu, Jun 16, 2016 at 3:24 PM, Nikita Nemkin wrote: >> >> I didin't know that PyPy has actually implemented packed ordered dicts! >> >> https://morepypy.blogspot.ru/2015/01/faster-more-memory-efficient-and-more.html >> https://mail.pyth

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Thu, Jun 16, 2016 at 3:24 PM, Nikita Nemkin wrote: > On Fri, Jun 17, 2016 at 2:36 AM, Nick Coghlan wrote: > > On 16 June 2016 at 14:17, Martin Teichmann > wrote: > > > An implementation like PyPy, with an inherently ordered standard dict > > implementation, can just rely on that rather than

[Python-Dev] Review of PEP 520: Ordered Class Definition Namespace

PEP 520 review notes. (From previous message; edited.) - I agree it's better to define the order as computed at runtime. - I don't think there's much of a point to mandate that all builtin/extension types reveal their order too -- I doubt there will be many uses for that -- but I don't want to d

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

I agree it's better to define the order as computed at runtime. I don't think there's much of a point to mandate that all builtin/extension types reveal their order too -- I doubt there will be many uses for that -- but I don't want to disallow it either. But we can allow types to define this, as l