[Python-Dev] Not-a-Number (was PyObject_RichCompareBool identity shortcut)

Related to the discussion on "Not a Number" can I point out a few things that have not be explicitly addressed so far. The IEEE standard is about hardware and bit patterns, rather than types and values so may not be entirely appropriate for high-level language like Python. NaN is *not* a numb

Re: [Python-Dev] Not-a-Number (was PyObject_RichCompareBool identity shortcut)

Steven D'Aprano wrote: Mark Shannon wrote: Related to the discussion on "Not a Number" can I point out a few things that have not be explicitly addressed so far. The IEEE standard is about hardware and bit patterns, rather than types and values so may not be entirely appro

Re: [Python-Dev] Proposal for a common benchmark suite

Maciej Fijalkowski wrote: On Thu, Apr 28, 2011 at 11:10 PM, Stefan Behnel wrote: M.-A. Lemburg, 28.04.2011 22:23: Stefan Behnel wrote: DasIch, 28.04.2011 20:55: the CPython benchmarks have an extensive set of microbenchmarks in the pybench package Try not to care too much about pybench. The

Re: [Python-Dev] What if replacing items in a dictionary returns the new dictionary?

Roy Hyunjin Han wrote: It would be convenient if replacing items in a dictionary returns the new dictionary, in a manner analogous to str.replace(). What do you think? :: # Current behavior x = {'key1': 1} x.update(key1=3) == None x == {'key1': 3} # Original variable has change

[Python-Dev] Borrowed and Stolen References in API

Hi, The online documentation specifies which API function borrow and/or steal references (as opposed to the default behaviour). Yet, I cannot find this information anywhere in the source. Any clues as to where I should look? Cheers, Mark ___ Python-

Re: [Python-Dev] Borrowed and Stolen References in API

s...@pobox.com wrote: Georg> Let's remove the cruft, and only keep interesting info. This Georg> will also make the file much more manageable. If I was to do this from scratch I'd think hard about annotating the source code. No matter how hard you try, if you keep this information sepa

Re: [Python-Dev] Borrowed and Stolen References in API

Antoine Pitrou wrote: On Fri, 06 May 2011 13:28:11 +1200 Greg Ewing wrote: Amaury Forgeot d'Arc wrote [concerning the Doc/data/refcounts.dat file]: This is not always true, for example when the item is already present in the dict. It's not important to know what the function does to the obje

Re: [Python-Dev] Linus on garbage collection

Neal Becker wrote: http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html Being famous does not necessarily make you right. OS kernels are pretty atypical software, even if Linus is right about Linux, it doesn't apply to Python. I have empirical evidence, not opinion, that PyPy and my own HotPy ar

Re: [Python-Dev] Linus on garbage collection

s...@pobox.com wrote: Antoine> Since we're sharing links, here's Matt Mackall's take: Antoine> http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html From that note: 1: You can't have meaningful destructors, because when destruction happens is undefined. And go

Re: [Python-Dev] Linus on garbage collection

Michael Foord wrote: On 06/05/2011 18:26, Mark Shannon wrote: Michael Foord wrote: On 06/05/2011 17:51, Stefan Behnel wrote: Mark Shannon, 06.05.2011 18:33: s...@pobox.com wrote: Antoine> Since we're sharing links, here's Matt Mackall's take: Antoine> http://www.

Re: [Python-Dev] Linus on garbage collection

Stefan Behnel wrote: Michael Foord, 06.05.2011 19:06: On 06/05/2011 17:51, Stefan Behnel wrote: Mark Shannon, 06.05.2011 18:33: s...@pobox.com wrote: Antoine> Since we're sharing links, here's Matt Mackall's take: Antoine> http://www.selenic.com/pipermail/mercurial-devel

Re: [Python-Dev] Python 3 optimizations continued...

Nick Coghlan wrote: On Tue, Aug 30, 2011 at 7:14 AM, Antoine Pitrou wrote: On Mon, 29 Aug 2011 11:33:14 -0700 stefan brunthaler wrote: * The optimized dispatch routine has a changed instruction format (word-sized instead of bytecodes) that allows for regular instruction decoding (without the

Re: [Python-Dev] Python 3 optimizations continued...

Martin v. Löwis wrote: So, the two big issues aside, is there any interest in incorporating these optimizations in Python 3? The question really is whether this is an all-or-nothing deal. If you could identify smaller parts that can be applied independently, interest would be higher. Also, I'd

Re: [Python-Dev] Python 3 optimizations continued...

Cesare Di Mauro wrote: 2011/9/1 Ned Batchelder > When the switchover to the new instruction format happens, what happens to sys.settrace() tracing? Will it report the same sequence of line numbers? For a small but important class of program execut

[Python-Dev] A new dict for Xmas?

Hi all, The current dict implementation is getting pretty old, isn't it time we had a new one (for xmas)? I have a new dict implementation which allows sharing of keys between objects of the same class. You can check it out here: http://bitbucket.org/markshannon/hotpy_new_dict Performance: F

Re: [Python-Dev] A new dict for Xmas?

Antoine Pitrou wrote: On Thu, 15 Dec 2011 22:18:18 + Mark Shannon wrote: For the gcbench benchmark (from unladen swallow), cpython with the new dict is about 9% faster and, more importantly, reduces memory use from 99 Mbytes to 61Mbytes (a 38% reduction). All tests were done on my ancient

Re: [Python-Dev] A new dict for Xmas?

Greg Ewing wrote: Mark Shannon wrote: I have a new dict implementation which allows sharing of keys between objects of the same class. We already have the __slots__ mechanism for memory savings. Have you done any comparisons with that? You can't make Python programmers use slots, ne

Re: [Python-Dev] A new dict for Xmas?

Jim Jewett wrote: Greg Ewing wrote: Mark Shannon wrote: I have a new dict implementation which allows sharing of keys between objects of the same class. We already have the __slots__ mechanism for memory savings. Have you done any comparisons with that? You can't make P

Re: [Python-Dev] A new dict for Xmas?

Terry Reedy wrote: On 12/16/2011 5:03 AM, Mark Shannon wrote: Of course using __slots__ saves more memory, but people don't use them much. Do you think the stdlib should be using __slots__ more? For some things yes, but where it's critical slots are already used. Take the ordered

Re: [Python-Dev] A new dict for Xmas?

Martin v. Löwis wrote: The current dict implementation is getting pretty old, isn't it time we had a new one (for xmas)? I like the approach, and I think something should be done indeed. If you don't contribute your approach, I'd like to drop at least ma_smalltable for 3.3. A number of things

Re: [Python-Dev] A new dict for Xmas?

Martin v. Löwis wrote: - it would be useful to have a specialized representation for all-keys-are-strings. In that case, me_hash could be dropped from the representation. You would get savings compared to the status quo even in the non-shared case. It might tricky switching key tables and

Re: [Python-Dev] A new dict for Xmas?

Martin v. Löwis wrote: If I'm wrong and its easy to implement then please do. Ok, so I take it that you are not interested in the idea. No problem. Its just that I don't think it would yield results commensurate with the effort. Also I think its worth keeping the initial version as simple as

Re: [Python-Dev] Hash collision security issue (now public)

Michael Foord wrote: Hello all, A paper (well, presentation) has been published highlighting security problems with the hashing algorithm (exploiting collisions) in many programming languages Python included: http://events.ccc.de/congress/2011/Fahrplan/attachments/2007_28C3_Effectiv

Re: [Python-Dev] Hash collision security issue (now public)

Raymond Hettinger wrote: FWIW, Uncle Timmy considers the non-randomized hashes to be a virtue. It is believed that they give us better-than-random results for commonly encountered datasets. A change to randomized hashes would have a negative performance impact on those cases. Tim Peter's analy

[Python-Dev] Testing the tests by modifying the ordering of dict items.

Hi, Python code should not depend upon the ordering of items in a dict. Unfortunately it seems that a number of tests in the standard library do just that. Changing PyDict_MINSIZE from 8 to either 4 or 16 causes the following tests to fail: test_dis test_email test_inspect test_nntplib tes

Re: [Python-Dev] Hash collision security issue (now public)

Serhiy Storchaka wrote: 06.01.12 02:10, Nick Coghlan написав(ла): Not a good idea - a lot of the 3rd party tests that depend on dict ordering are going to be using those modules anyway, so scattering our solution across half the standard library is needlessly creating additional work without rea

Re: [Python-Dev] Hash collision security issue (now public)

Hi, It seems to me that half the folk discussing this issue want a super-strong, resist-all-hypothetical-attacks hash with little regard to performance. The other half want no change or a change that will have no observable effect. (I may be exaggerating a little.) Can I propose the followi

Re: [Python-Dev] py3benchmark not working

Christian Heimes wrote: Hello, I tried to compare the py3k baseline with my randomhash branch but the benchmark suite is failing. I've follewed the instruction # hg clone http://hg.python.org/benchmarks/ py2benchmarks # mkdir py3benchmarks; # cd py3benchmarks # ../py2benchmarks/make_pe

[Python-Dev] Coroutines and PEP 380

Hi all. Lets start controversially: I don't like PEP 380, I think it's a kludge. I think that CPython should have proper coroutines, rather than add more bits and pieces to generators in an attempt to make them more like coroutines. I have mentioned this before, but this time I have done som

Re: [Python-Dev] Coroutines and PEP 380

Matt Joiner wrote: Just to clarify, this differs in functionality from enhanced generators by allowing you to yield from an arbitrary call depth rather than having to "yield from" through a chain of calling generators? Furthermore there's no syntactical change except to the bottommost frame doi

Re: [Python-Dev] Coroutines and PEP 380

Glyph wrote: On Jan 17, 2012, at 5:03 PM, Mark Shannon wrote: Lets start controversially: I don't like PEP 380, I think it's a kludge. Too late; it's already accepted. There's not much point in making controversial statements about it now. Why is it too late? Prese

[Python-Dev] Changing the order of iteration over a dictionary

Hi, One of the main sticking points over possible fixes for the hash-collision security issue seems to be a fear that changing the iteration order of a dictionary will break backwards compatibility. The order of iteration has never been specified. In fact not only is it arbitrary, it cannot

Re: [Python-Dev] [Python-ideas] Coroutines and PEP 380

Nick Coghlan wrote: (redirecting to python-ideas - coroutine proposals are nowhere near mature enough for python-dev) On Wed, Jan 25, 2012 at 5:35 PM, Matt Joiner wrote: If someone can explain what's stopping real coroutines being into Python (3.3), that would be great. The general issues wi

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

stefan brunthaler wrote: Hi, On Tue, Nov 8, 2011 at 10:36, Benjamin Peterson wrote: 2011/11/8 stefan brunthaler : How does that sound? I think I can hear real patches and benchmarks most clearly. I spent the better part of my -20% time on implementing the work as "suggested". Please find t

[Python-Dev] A new dictionary implementation

Hi, Now that issue 13703 has been largely settled, I want to propose my new dictionary implementation again. It is a little more polished than before. https://bitbucket.org/markshannon/hotpy_new_dict Object-oriented benchmarks use considerably less memory and are sometimes faster (by a small am

Re: [Python-Dev] A new dictionary implementation

Antoine Pitrou wrote: Hi, On Sun, 29 Jan 2012 10:31:48 + Mark Shannon wrote: Now that issue 13703 has been largely settled, I want to propose my new dictionary implementation again. It is a little more polished than before. https://bitbucket.org/markshannon/hotpy_new_dict I briefly

Re: [Python-Dev] A new dictionary implementation

Antoine Pitrou wrote: On Sun, 29 Jan 2012 09:56:11 -0500 Benjamin Peterson wrote: 2012/1/29 Mark Shannon : Hi, Now that issue 13703 has been largely settled, I want to propose my new dictionary implementation again. It is a little more polished than before. If you're serious about cha

Re: [Python-Dev] A new dictionary implementation

francis wrote: On 01/29/2012 11:31 AM, Mark Shannon wrote: It passes all the tests. (I had to change a couple that relied on dict repr() ordering) Hi Mark, I've cloned the repo, build it the I've tried with ./python -m test. I got some errors: First in general: 340 tests OK. 2 te

Re: [Python-Dev] A new dictionary implementation

Martin v. Löwis wrote: Now that issue 13703 has been largely settled, I want to propose my new dictionary implementation again. It is a little more polished than before. Please clarify the status of that code: are you actually proposing 6a21f3b35e20 for inclusion into Python as-is? If so, pleas

Re: [Python-Dev] A new dictionary implementation

Matt Joiner wrote: Mark, Good luck with getting this in, I'm also hopeful about coroutines, maybe after pushing your dict optimization your coroutine implementation will get more consideration. Shush, don't say the C word or you'll put people off ;) I'm actually not that fussed about the coro

Re: [Python-Dev] Store timestamps as decimal.Decimal objects

Alexander Belopolsky wrote: On Tue, Jan 31, 2012 at 7:13 AM, Antoine Pitrou wrote: On Tue, 31 Jan 2012 21:11:37 +1000 Nick Coghlan wrote: Having a low-level module like os needing to know about higher-level types like decimal.Decimal and datetime.datetime (or even timedelta) should be setting

Re: [Python-Dev] A new dictionary implementation

Just a quick update. I've been analysing and profile the behaviour of my new dict and messing about with various implementation options. I've settled on a new implementation. Its the same basic idea, but with better locality of reference for unshared keys. Guido asked: > Another question:

Re: [Python-Dev] A new dictionary implementation

Hi, Version 2 is now available. Version 2 makes as few changes to tunable constants as possible, and generally does not change iteration order (so repr() is unchanged). All tests pass (the only changes to tests are for sys.getsizeof() ). Repository: https://bitbucket.org/markshannon/cpython_n

[Python-Dev] Code review tool uses my old email address

Hi, I changed my email address (about a year ago) and updated my bug tracker settings to my new address (late last year). However, the code review tool still shows my old email address. How do I change it? Cheers, Mark. ___ Python-Dev mailing list Py

[Python-Dev] PEP for new dictionary implementation

Proposed PEP for new dictionary implementation, PEP 410? is attached. Cheers, Mark. PEP: XXX Title: Key-Sharing Dictionary Version: $Revision$ Last-Modified: $Date$ Author: Mark Shannon Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 08-Feb-2012 Python-Version: 3.3 or 3.4

Re: [Python-Dev] PEP for new dictionary implementation

Terry Reedy wrote: On 2/8/2012 2:18 PM, Mark Shannon wrote: A pretty clear draft PEP. Changes to repr() output and iteration order: For most cases, this will be unchanged. However for some split-table dictionaries the iteration order will change. Neither of these cons should be a problem

Re: [Python-Dev] A new dictionary implementation

francis wrote: Hi Mark, I've just cloned : Repository: https://bitbucket.org/markshannon/cpython_new_dict Do please try it on your machine(s). that's a: Linux random 3.1.0-1-amd64 #1 SMP Tue Jan 10 05:01:58 UTC 2012 x86_64 GNU/Linux and I'm getting: gcc -pthread -c -Wno-unused-resu

Re: [Python-Dev] A new dictionary implementation

francis wrote: Hi Mark, Bah... typo in assert statement. My fault for not testing the debug build (release build worked fine). Both builds working now. Yeah, now is working and passes all tests also on my machine. I've tried to run the test suite but I'm getting a SyntaxError: (may be you know

Re: [Python-Dev] PEP for new dictionary implementation

Antoine Pitrou wrote: Hello Mark, I think the PEP should explain what happens when a keys table needs resizing when setting an object's attribute. If the object is the only instance of a class, it remains split, otherwise the table is combined. Most OO code will set attributes in the __init__

Re: [Python-Dev] PEP for new dictionary implementation

Revised PEP for new dictionary implementation, PEP 412? is attached. Cheers, Mark. PEP: XXX Title: Key-Sharing Dictionary Version: $Revision$ Last-Modified: $Date$ Author: Mark Shannon Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 08-Feb-2012 Python-Version: 3.3 or 3.4

Re: [Python-Dev] A new dictionary implementation

Any opinions on my new dictionary implementation? I'm happy to take silence on the PEP as tacit approval, but the code definitely needs reviewing. Issue: http://bugs.python.org/issue13903 PEP: https://bitbucket.org/markshannon/cpython_new_dict/src/6c4d5d9dfc6d/pep-new-dict.txt Repository https

Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review

Antoine Pitrou wrote: On Wed, 15 Feb 2012 20:56:26 +0100 "Martin v. Löwis" wrote: With the quartz in Victor's machine, a single clock takes 0.3ns, so three of them make a nanosecond. As the quartz may not be entirely accurate (and also as the CPU frequency may change) you have to measure the cl

Re: [Python-Dev] PEP for new dictionary implementation

On 16/02/12 20:45, Antoine Pitrou wrote: On Wed, 08 Feb 2012 19:18:14 + Mark Shannon wrote: Proposed PEP for new dictionary implementation, PEP 410? is attached. So, I'm running a few benchmarks using Twisted's test suite (see https://bitbucket.org/pitrou/t3k/wiki/Home). At

Re: [Python-Dev] A new dictionary implementation

On 15/02/12 21:09, Yury Selivanov wrote: Hello Mark, First, I've back-ported your patch on python 3.2.2 (which was relatively easy). Almost all tests pass, and those that don't are always failing on my machine if I remember. The patch can be found here: http://goo.gl/nSzzY Then, I compared me

Re: [Python-Dev] PEP for new dictionary implementation

On 17 February 2012 at 17:42 Jim Jewett wrote: > On Fri, Feb 17, 2012 at 1:50 AM, "Martin v. Löwis" wrote: > >>> Good idea. However, how do you track per-dict how large the > >>> table is? > > [Or, rather, what is the highest index needed to store any values > that are actually set for this ins

[Python-Dev] Exceptions in LOAD_GLOBAL and LOAD_NAME

The code below causes different behaviour for LOAD_GLOBAL and LOAD_NAME. Which is correct? Should exceptions raised in the equality test be converted to a NameError or just propogated? Cheers, Mark. - import sys class S(str): pass def eq_except(self, o

Re: [Python-Dev] Exceptions in LOAD_GLOBAL and LOAD_NAME

Nick Coghlan wrote: On Thu, Feb 23, 2012 at 8:12 PM, Mark Shannon wrote: Should exceptions raised in the equality test be converted to a NameError or just propogated? Our general trend has been towards letting such exceptions escape the operation that caused them rather than implicitly

Re: [Python-Dev] Add a frozendict builtin type

Victor Stinner wrote: The blacklist implementation has a major issue: it is still possible to call write methods of the dict class (e.g. dict.set(my_frozendict, key, value)). It is also possible to use ctypes and violate even more invariants. For most purposes, this falls under "consenting adult

Re: [Python-Dev] Add a frozendict builtin type

Antoine Pitrou wrote: On Tue, 28 Feb 2012 12:45:54 +0100 Victor Stinner wrote: I think you need to elaborate on your use cases further, ... A frozendict can be used as a member of a set or as a key in a dictionary. For example, frozendict is indirectly needed when you want to use an object as

Re: [Python-Dev] Add a frozendict builtin type

Hi, I don't know if an implementation of the frozendict actually exists, but if anyone is planning on writing one then can I suggest that they take a look at my new dict implementation: http://bugs.python.org/issue13903 https://bitbucket.org/markshannon/cpython_new_dict/ Making dicts immutable (

Re: [Python-Dev] Add a frozendict builtin type

Victor Stinner wrote: * frozendict values must be immutable, as dict keys Why? That may be useful, but an immutable dict whose values might mutate is also useful; by forcing that choice, it starts to feel too specialized for a builtin. Hum, I realized that calling hash(my_frozendict) on a fr

[Python-Dev] Defending against stack overflow (was Sandboxing Python)

Having a look at the "crashers" in Lib/test/crashers it seems to me that they fall into four groups. 1. Unsafe gc functions like getreferrers() 2. Stack overflows. 3. "Normal" bugs that can be fixed on a case-by-case basis (like borrowed_ref_1.py and borrowed_ref_2.py) 4. Things that don't crash

Re: [Python-Dev] Sandboxing Python

Armin Rigo wrote: Hi all, On Sun, Mar 4, 2012 at 03:51, Guido van Rossum wrote: Could we put asserts in the places where segfaults may happen? No. I checked Lib/test/crashers/*.py and none of them would be safe with just a failing assert. If they were, we'd have written the assert long ago

[Python-Dev] Remove f_yieldfrom attribute from frameobject

Could we remove the f_yieldfrom attribute from frameobject (at the Python level) before it is too late and we are stuck with it. Issue (with patch) here: http://bugs.python.org/issue13970 Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org

[Python-Dev] Exceptions in comparison operators

Comparing two objects (of the same type for simplicity) involves a three stage lookup: The class has the operator C.__eq__ It can be applied to operator (descriptor protocol): C().__eq__ and it produces a result: C().__eq__(C()) Exceptions can be raised in all 3 phases, but an exception in the fi

[Python-Dev] Adding a builtins parameter to eval(), exec() and __import__().

I propose adding an optional (keyword-only?) 3rd parameter, "builtins" to exec(), eval(), __import__() and any other functions that take locals and globals as parameters. Currently, Python code is evaluated in a context of three name spaces; locals(), globals() and builtins. However, eval & exec

Re: [Python-Dev] problem with recursive "yield from" delegation

Stefan Behnel wrote: Hi, I found a problem in the current "yield from" implementation that I think is worth discussing: http://bugs.python.org/issue14220 [snip] I've been experimenting with the implementation of PEP 380, and I found a couple of interesting things. First of all, the semant

Re: [Python-Dev] Adding a builtins parameter to eval(), exec() and __import__().

Jim J. Jewett wrote: http://mail.python.org/pipermail/python-dev/2012-March/117395.html Brett Cannon posted: [in reply to Mark Shannon's suggestion of adding a builtins parameter to match locals and globals] It's a mess right now to try to grab the __import__() implementation and this would a

Re: [Python-Dev] Adding a builtins parameter to eval(), exec() and __import__().

Nick Coghlan wrote: On Thu, Mar 8, 2012 at 10:06 PM, Mark Shannon wrote: I don't think it cleans up import, but I'll defer to Brett on that. I've included __import__() along with exec and eval as it is a place where new namespaces can be introduced into an execution. There

Re: [Python-Dev] problem with recursive "yield from" delegation

Nick Coghlan wrote: On Thu, Mar 8, 2012 at 9:52 PM, Mark Shannon wrote: First of all, the semantics described in the PEP do not match the tests. If you substitute the supposedly semantically equivalent code based on normal yields for each yield from in the test code (Lib/test/test_pep380.py

[Python-Dev] Request for clarification of PEP 380

Hi, The scenario is this: A generator, G, has a non-generator sub-iterator, S, (ie G includes a "yield from S" experssion and S is not a generator) and either G.close() or G.throw(GeneratorExit) is called. In the current implementation, S.close() is called and, if that call raises an exception,

Re: [Python-Dev] Request for clarification of PEP 380

Nick Coghlan wrote: On Fri, Mar 9, 2012 at 12:06 AM, Mark Shannon wrote: The text of the PEP seems to implicitly assume that all sub-iterators will be generators, so it is not clear on the above points. On the contrary, this question is explicitly addressed in the PEP: http://www.python.org

Re: [Python-Dev] Adding a builtins parameter to eval(), exec() and __import__().

Guido van Rossum wrote: On Thu, Mar 8, 2012 at 4:33 PM, Nick Coghlan wrote: On Fri, Mar 9, 2012 at 3:31 AM, Guido van Rossum wrote: But the __builtins__ that are actually used by any particular piece of code is *not* taken by importing builtins. It is taken from what the globals store under t

Re: [Python-Dev] Adding a builtins parameter to eval(), exec() and __import__().

Nick Coghlan wrote: On Fri, Mar 9, 2012 at 6:19 PM, Mark Shannon wrote: The Python API would be changed, but in a backwards compatible way. exec, eval and __import__ would all gain an optional (keyword-only?) "builtins" parameter. No, some APIs effectively define *protocols*. For

Re: [Python-Dev] Adding a builtins parameter to eval(), exec() and __import__().

Victor Stinner wrote: The reason I am proposing this here rather than on python-ideas is that treating the triple of [locals, globals, builtins] as a single "execution context" can be implemented in a really nice way. Internally, the execution context of [locals, globals, builtins] can be treate

Re: [Python-Dev] Exceptions in comparison operators

= MyValue1(1) b = MyValue2(2) print(a + b) print(a < b) currently prints the following: add 3 gt True Cheers, Mark. On Mon, Mar 5, 2012 at 10:41 AM, Guido van Rossum wrote: On Mon, Mar 5, 2012 at 4:41 AM, Mark Shannon wrote: Comparing two objects (of the same type for simplicit

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

Stefan Krah wrote: Antoine Pitrou wrote: For instance I have several one line patches languishing, I can't imagine how disappointing it would be to have significantly larger patches ignored, but it happens. Can you give a pointer to these one-liners? Almost a one-liner, but vast knowledge re

[Python-Dev] Removing surplus fields from the frame object and not adding any new ones.

The frame object is a key object in CPython. It holds the state of a function invocation. Frame objects are allocated, initialised and deallocated at a rapid rate. Each extra field in the frame object requires extra work for each and every function invocation. Fewer fields in the frame object mean

Re: [Python-Dev] Removing surplus fields from the frame object and not adding any new ones.

a struct within the frame. The aim is clarity; locals, globals and builtins form a trio, so should be implemented as such. On Mon, Apr 9, 2012 at 11:56 AM, Mark Shannon wrote: The frame object is a key object in CPython. It holds the state of a function invocation. Frame objects are allocated

Re: [Python-Dev] Removing surplus fields from the frame object and not adding any new ones.

Guido van Rossum wrote: On Mon, Apr 9, 2012 at 3:51 AM, Mark Shannon wrote: f_namespaces would be part of the frame, replacing f_builtins, f_globals and f_locals. The indirection of an external object hurts performance, so it would have to be a struct within the frame. The aim is clarity

[Python-Dev] Meaning of the f_tstate field in the frame object

What is the purpose of the f_tstate field in the frame object? It holds a borrowed reference to the threadstate in which the frame was created. If PyThreadState_GET()->frame->f_state == PyThreadState_GET() then it is redundant. But what if PyThreadState_GET()->frame->f_state != PyThreadState_GET

[Python-Dev] PEP 412 Key-Sharing Dictionary

I would like to get the new shared-keys dictionary implementation committed, or rejected or further reviewed, if necessary. It seems to have got a bit stuck at the moment. As far as I am concerned it is ready to go in. Memory usage is reduced, speed is roughly unchanged, and it passes all the tes

[Python-Dev] What do PyAPI_FUNC & PyAPI_DATA mean?

Many (most?) of the function declarations in the CPython header files are annotated with the PyAPI_FUNC declaration. Similarly for data declarations and PyAPI_DATA What do they mean, exactly? From the name I would expect that they are a way of declaring a function or datum to be part of the API,

Re: [Python-Dev] Daily reference leaks (8dbcedfd13f8): sum=15528

Antoine Pitrou wrote: On Tue, 24 Apr 2012 05:36:41 +0200 solip...@pitrou.net wrote: results for 8dbcedfd13f8 on branch "default" test_itertools leaked [44, 44, 44] references, sum=132 test_robotparser leaked [103, 103, 103] references, sum=309 test_s

Re: [Python-Dev] [Python-checkins] cpython (3.2): don't use a slot wrapper from a different special method (closes #14658)

I'm not happy with this fix. Admittedly code like: class S(str): __getattr__ = str.__add__ s = S('a') print(S.b) is a little weird. But I think it should work (ie print 'ab') properly. This works without the patch. class S(str): __getattribute__ = str.__add__ s = S('a') print(S.b) (Pri

Re: [Python-Dev] [Python-checkins] cpython (3.2): don't use a slot wrapper from a different special method (closes #14658)

Benjamin Peterson wrote: 2012/4/24 Mark Shannon : I'm not happy with this fix. It's not perfect, but it's an improvement. Admittedly code like: class S(str): __getattr__ = str.__add__ s = S('a') print(S.b) My typo, should be: print(s.b) (Instance not class) T

Re: [Python-Dev] [Python-checkins] cpython (3.2): don't use a slot wrapper from a different special method (closes #14658)

Benjamin Peterson wrote: 2012/4/24 Mark Shannon : I'm not happy with this fix. It's not perfect, but it's an improvement. Actually, I think it is probably correct. I've been trying to break it by assigning various unusual objects to special attributes and it seems OK so

Re: [Python-Dev] [Python-checkins] Daily reference leaks (a2cf07135e4f): sum=6

solip...@pitrou.net wrote: results for a2cf07135e4f on branch "default" test_tempfile leaked [2, 2, 2] references, sum=6 These leaks are due to 6e5855854a2e: “Implement PEP 412: Key-sharing dictionaries (closes #13903)”. They both occur in tests f

Re: [Python-Dev] cpython: Implement PEP 412: Key-sharing dictionaries (closes #13903)

Kristján Valur Jónsson wrote: -Original Message- From: python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of mar...@v.loewis.de Sent: 24. apríl 2012 17:44 To: python-dev@python.org Subject: Re: [Python-Dev] cpython:

Re: [Python-Dev] Assigning copyright...

stefan brunthaler wrote: Hi, I only had little time to spend for my open sourcing efforts, which is why I could not get back to python-dev any time earlier... Yesterday I forward-ported my patches to revision 76549 (13c30fe3f427), which only took 25mins or so (primarly due to the small changes

Re: [Python-Dev] time.clock_info() field names

Benjamin Peterson wrote: 2012/4/29 Jim J. Jewett : In http://mail.python.org/pipermail/python-dev/2012-April/119134.html Benjamin Peterson wrote: I see PEP 418 gives time.clock_info() two boolean fields named "is_monotonic" and "is_adjusted". I think the "is_" is unnecessary and a bit ugly, a

Re: [Python-Dev] [RELEASED] Python 3.3.0 alpha 3

Georg Brandl wrote: On behalf of the Python development team, I'm happy to announce the third alpha release of Python 3.3.0. This is a preview release, and its use is not recommended in production settings. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting

Re: [Python-Dev] [RELEASED] Python 3.3.0 alpha 3

Nick Coghlan wrote: On Wed, May 2, 2012 at 7:55 PM, Mark Shannon wrote: Or maybe three parts? New features. Behavioural changes (i.e. bug fixes) Performance enhancements The release PEPs are mainly there for *our* benefit, not end users. For end users, it's the What's New doc

Re: [Python-Dev] [RELEASED] Python 3.3.0 alpha 3

Martin v. Löwis wrote: The What's New document also starts with a long list of PEPs. This seems to be the standard format as What's New for 3.2 follows the same layout. Perhaps adding an overview or highlights at the start would be a good idea. You seem to assume that Python users are not able

Re: [Python-Dev] Adding types.build_class for 3.3

Nick Coghlan wrote: On Wed, May 9, 2012 at 4:37 PM, Daniel Urban wrote: On Wed, May 9, 2012 at 3:10 AM, Nick Coghlan wrote: We need the explicitly declared metaclass as well as the bases in order to determine the correct metaclass. Note, that the current patch (at http://bugs.python.org/issu

Re: [Python-Dev] Adding types.build_class for 3.3

Nick Coghlan wrote: On Wed, May 9, 2012 at 5:57 PM, Mark Shannon wrote: As a consequence of this, making build_class either a class method or a static method will cause a direct call to type.build_class() to fail as neither class method nor static method are callable. We'll make su

Re: [Python-Dev] Adding types.build_class for 3.3

Nick Coghlan wrote: On Thu, May 10, 2012 at 10:03 AM, Greg Ewing wrote: Python is not Java -- we have modules. Something should only go in a class namespace if it somehow relates to that particular class, and other classes could might implement it differently. That's not the case with build_cla

Re: [Python-Dev] Adding types.build_class for 3.3

Nick Coghlan wrote: On Thu, May 10, 2012 at 6:11 PM, Mark Shannon wrote: Finally, could you remind me how the proposed type.define differs from builtins.__build_class__? I can't see any difference (apart from parameter ordering and the extra name parameter in builtins.__build_class__).

Re: [Python-Dev] Adding types.build_class for 3.3

Nick Coghlan wrote: On Fri, May 11, 2012 at 3:31 AM, Barry Warsaw wrote: On May 09, 2012, at 07:44 PM, R. David Murray wrote: (*) Actually, come to think of it, I probably refer to it as "constructing" the class, rather than creating or defining it. It's the type equivalent of constructing an

Re: [Python-Dev] C-level duck typing

Martin v. Löwis wrote: > And, we want this to somehow work with existing Python; we still > support users on Python 2.4. This makes the question out-of-scope for python-dev - we only discuss new versions of Python here. Old versions cannot be developed anymore (as they are released already).

<    1   2   3   4   5   >