Re: [Python-Dev] Benchmarking Python and micro-optimizations

Hi Victor Despite the fact that I was not able to find time to run your stuff yet, thanks for all the awesome work! On Thu, Oct 20, 2016 at 12:56 PM, Victor Stinner wrote: > Hi, > > Last months, I worked a lot on benchmarks. I ran benchmarks, analyzed > results in

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Thu, Sep 15, 2016 at 1:27 PM, Paul Moore wrote: > On 15 September 2016 at 10:43, Raymond Hettinger > wrote: >> Something like this will reveal the true and massive improvement in >> iteration speed: >> >> $ ./python.exe -m timeit -s

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Fri, Sep 9, 2016 at 10:55 AM, Antoine Pitrou wrote: > On Thu, 8 Sep 2016 14:20:53 -0700 > Victor Stinner wrote: >> 2016-09-08 13:36 GMT-07:00 Guido van Rossum : >> > IIUC there's one small thing we might still want to change

Re: [Python-Dev] What do we do about bad slicing and possible crashes (issue 27867)

On Tue, Aug 30, 2016 at 2:31 PM, Dima Tisnek wrote: > On 30 August 2016 at 14:13, Serhiy Storchaka wrote: >>> 1. Detect length change and raise. >> >> >> It would be simpler solution. But I afraid that this can break third-party >> code that "just works"

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Tue, Aug 30, 2016 at 3:00 AM, Brett Cannon wrote: > > > On Mon, Aug 29, 2016, 17:06 Terry Reedy wrote: >> >> On 8/29/2016 5:38 PM, Brett Cannon wrote: >> >> > who objected to the new field did either for memory ("it adds another >> > pointer to the struct

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

Hi Brett For what is worth, vmprof and similar tools would love such field (there is an open question how can you use vmprof *and* another tool, but later) On Mon, Aug 29, 2016 at 11:38 PM, Brett Cannon wrote: > For quick background for those that don't remember, part of PEP

Re: [Python-Dev] Review request: issue 27350, compact ordered dict

On Mon, Aug 15, 2016 at 6:02 AM, Xavier Combelle <xavier.combe...@gmail.com> wrote: > > > On 10/08/2016 17:06, Maciej Fijalkowski wrote: >> * there are nice speedups >> > in this blog post > https://morepypy.blogspot.fr/2015/01/faster-more-memory-efficient-an

Re: [Python-Dev] Review request: issue 27350, compact ordered dict

Hello everyone. I did do only a cursory look on that one, but I would like to reiterate that this gives huge benefits in general and we measured nice speedups on pypy (where all the dicts are ordered forever): * you can essentially kill OrderedDict or make it almost OrderedDict = dict (in pypy

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 1:14 PM, Jon Ribbens wrote: > On Tue, Apr 12, 2016 at 06:21:04AM -0400, Isaac Morland wrote: >> On Tue, 12 Apr 2016, Jon Ribbens wrote: >> >>This is still a massive game of whack-a-mole. >> > >> >No, it still isn't. If the names blacklist

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

I'm with Victor here. In fact I tried (and failed) to convince Victor that the approach is entirely unworkable when he was starting, don't be the next one :-) On Sat, Apr 9, 2016 at 3:43 PM, Victor Stinner wrote: > Please don't loose time trying yet another sandbox

Re: [Python-Dev] Hash randomization for which types?

Note that hashing in python 2.7 and prior to 3.4 is simply broken and the randomization does not do nearly enough, see https://bugs.python.org/issue14621 On Wed, Feb 17, 2016 at 4:45 AM, Shell Xu wrote: > I thought you are right. Here is the source code in python 2.7.11: >

Re: [Python-Dev] Wordcode v2

On Mon, Feb 15, 2016 at 4:05 AM, Guido van Rossum wrote: > I think it's probably too soon to discuss on python-dev, but I do > think that something like this could be attempted in 3.6 or (more > likely) 3.7, if it really is faster. > > An unfortunate issue however is that many

Re: [Python-Dev] PEP 509: Add a private version to dict

The easiest version is to have global numbering (as opposed to local). Anyway, I would strongly suggest getting some benchmarks done and showing performance benefits first, because you don't want PEPs to be final when you don't exactly know the details. On Wed, Jan 20, 2016 at 7:02 PM, Yury

Re: [Python-Dev] PEP 509: Add a private version to dict

On Wed, Jan 20, 2016 at 7:22 PM, Brett Cannon wrote: > > > On Wed, 20 Jan 2016 at 10:11 Yury Selivanov wrote: >> >> On 2016-01-18 5:43 PM, Victor Stinner wrote: >> > Is someone opposed to this PEP 509? >> > >> > The main complain was the change on the

Re: [Python-Dev] PEP 509: Add a private version to dict

On Wed, Jan 20, 2016 at 8:00 PM, Yury Selivanov <yselivanov...@gmail.com> wrote: > > > On 2016-01-20 1:36 PM, Maciej Fijalkowski wrote: >> >> On Wed, Jan 20, 2016 at 7:22 PM, Brett Cannon <br...@python.org> wrote: >>> >>> >>> On Wed,

Re: [Python-Dev] PEP 509: Add a private version to dict

there is also the problem that you don't want it on all dicts. So having two extra words is more to pay than having extra objects (also, comparison is cheaper for guards) On Wed, Jan 20, 2016 at 8:23 PM, Yury Selivanov <yselivanov...@gmail.com> wrote: > > > On 2016-01-20

Re: [Python-Dev] PEP 509: Add a private version to dict

On Wed, Jan 20, 2016 at 8:08 PM, Yury Selivanov <yselivanov...@gmail.com> wrote: > > On 2016-01-20 2:02 PM, Maciej Fijalkowski wrote: >> >> On Wed, Jan 20, 2016 at 8:00 PM, Yury Selivanov <yselivanov...@gmail.com> >> wrote: >> > [..] >>>

Re: [Python-Dev] _PyThreadState_Current

seems to work thanks. That said, I would love to have PyThreadState_Get equivalent that would let me handle the NULL. On Mon, Jan 18, 2016 at 9:31 PM, Maciej Fijalkowski <fij...@gmail.com> wrote: > Good point > > On Mon, Jan 18, 2016 at 9:25 PM, Victor Stinner > <victor.sti

Re: [Python-Dev] _PyThreadState_Current

Good point On Mon, Jan 18, 2016 at 9:25 PM, Victor Stinner <victor.stin...@gmail.com> wrote: > Hum, you can try to lie and define Py_BUILD_CORE? > > Victor > > 2016-01-18 21:18 GMT+01:00 Maciej Fijalkowski <fij...@gmail.com>: >> Hi >> >&

Re: [Python-Dev] PEP 509: Add a private version to dict

Hi Victor. You know that pypy does this stuff without changing and exposing python semantics right? We have a version dict that does not leak abstractions to the user. In general, doing stuff like that where there is a public API that leaks details of certain optimizations makes it harder and

Re: [Python-Dev] PEP 509: Add a private version to dict

On Mon, Jan 11, 2016 at 9:56 PM, Victor Stinner <victor.stin...@gmail.com> wrote: > Le 11 janv. 2016 8:09 PM, "Maciej Fijalkowski" <fij...@gmail.com> a écrit : >> Hi Victor. >> >> You know that pypy does this stuff without changing and exposing >&g

Re: [Python-Dev] Idea: Dictionary references

You can very easily implement this with version tags on the globals dictionaries - means that the dictionaries have versions and the guard checking if everything is ok just checks the version tag on globals. Generally speaking, such optimizations have been done in the past (even in places like

Re: [Python-Dev] Avoiding CPython performance regressions

Hi David. Any reason you run a tiny tiny subset of benchmarks? On Tue, Dec 1, 2015 at 5:26 PM, Stewart, David C wrote: > > > From: Fabio Zadrozny > > Date: Tuesday, December 1, 2015 at 1:36 AM > To: David Stewart >

Re: [Python-Dev] Avoiding CPython performance regressions

On Tue, Dec 1, 2015 at 9:04 PM, Stewart, David C <david.c.stew...@intel.com> wrote: > On 12/1/15, 10:56 AM, "Maciej Fijalkowski" <fij...@gmail.com> wrote: > > > >>Hi David. >> >>Any reason you run a tiny tiny subset of benchmarks? > > W

Re: [Python-Dev] Avoiding CPython performance regressions

Hi Thanks for doing the work! I'm on of the pypy devs and I'm very interested in seeing this getting somewhere. I must say I struggle to read the graph - is red good or is red bad for example? I'm keen to help you getting anything you want to run it repeatedly. PS. The intel stuff runs one

Re: [Python-Dev] Avoiding CPython performance regressions

On Tue, Dec 1, 2015 at 11:49 AM, Fabio Zadrozny <fabi...@gmail.com> wrote: > > On Tue, Dec 1, 2015 at 6:36 AM, Maciej Fijalkowski <fij...@gmail.com> wrote: >> >> Hi >> >> Thanks for doing the work! I'm on of the pypy devs and I'm very >> intereste

Re: [Python-Dev] Benchmark results across all major Python implementations

Hi Brett Any thoughts on improving the benchmark set (I think all of {cpython,pypy,pyston} introduced new benchmarks to the set). "speed.python.org" becoming a thing is generally stopped on "noone cares enough to set it up". Cheers, fijal On Mon, Nov 16, 2015 at 9:18 PM, Brett Cannon

Re: [Python-Dev] Second milestone of FAT Python

How do you check that someone did not e.g. bind something different to "len"? On Wed, Nov 4, 2015 at 8:50 AM, Victor Stinner wrote: > Hi, > > I'm writing a new "FAT Python" project to try to implement optimizations in > CPython (inlining, constant folding, move

Re: [Python-Dev] Second milestone of FAT Python

Uh, sorry, misread your full mail, scratch that On Wed, Nov 4, 2015 at 9:07 AM, Maciej Fijalkowski <fij...@gmail.com> wrote: > How do you check that someone did not e.g. bind something different to "len"? > > On Wed, Nov 4, 2015 at 8:50 AM, Victor Stinner <victor

Re: [Python-Dev] compatibility for C-accelerated types

For what is worth, that level of differences already exists on pypy and it's really hard to get the *exact* same semantics if things are implemented in python vs C or the other way around. Example list of differences (which I think OrderedDict already breaks if moved to C): * do methods like

[Python-Dev] An example of Python 3 promotion attitude

There was a discussion a while ago about python 3 and the attitude on social media and there was a lack of examples. Here is one example: https://www.reddit.com/r/Python/comments/3nl5ut/ninite_the_popular_website_to_install_essential/ According to some people, it is everybodys job to promote

Re: [Python-Dev] Issue #25256: Add sys.debug_build?

Speaking of other python implementations - why would you even care? (the pypy debug build has very different properties and does very different stuff for example). I would be very happy to have this clearly marked as implementation-dependent and that's why it would be cool to not be in sys (there

Re: [Python-Dev] semantics of subclassing things from itertools

Hettinger <raymond.hettin...@gmail.com> wrote: > >> On Sep 13, 2015, at 3:09 PM, Maciej Fijalkowski <fij...@gmail.com> wrote: >> >> Well, fair enough, but the semantics of "whatever happens to happen >> because we decided subclassing is a cool id

Re: [Python-Dev] semantics of subclassing things from itertools

On Fri, Sep 11, 2015 at 1:48 AM, Raymond Hettinger <raymond.hettin...@gmail.com> wrote: > >> On Sep 10, 2015, at 3:23 AM, Maciej Fijalkowski <fij...@gmail.com> wrote: >> >> I would like to know what are the semantics if you subclass something >> from iterto

Re: [Python-Dev] semantics of subclassing things from itertools

On Sun, Sep 13, 2015 at 5:46 PM, Raymond Hettinger <raymond.hettin...@gmail.com> wrote: > >> On Sep 13, 2015, at 3:49 AM, Maciej Fijalkowski <fij...@gmail.com> wrote: >> >>> The intended semantics are that the itertools are classes (not functions >>

[Python-Dev] semantics of subclassing things from itertools

Hi I would like to know what are the semantics if you subclass something from itertools (e.g. islice). Right now it's allowed and people do it, which is why the documentation is incorrect. It states "equivalent to: a function-or a generator", but you can't subclass whatever it is equivalent to,

Re: [Python-Dev] semantics of subclassing things from itertools

On Thu, Sep 10, 2015 at 10:26 AM, Serhiy Storchaka <storch...@gmail.com> wrote: > On 10.09.15 10:23, Maciej Fijalkowski wrote: >> >> I would like to know what are the semantics if you subclass something >> from itertools (e.g. islice). >> >> Right now it's

Re: [Python-Dev] tp_finalize vs tp_del sematics

On Thu, Sep 3, 2015 at 9:23 AM, Valentine Sinitsyn wrote: > Hi Armin, > > On 25.08.2015 13:00, Armin Rigo wrote: >> >> Hi Valentine, >> >> On 25 August 2015 at 09:56, Valentine Sinitsyn >> wrote: Yes, I think so. There is a

Re: [Python-Dev] Profile Guided Optimization active by-default

Interesting. So pypy (with it's profiling JIT) would be in a similar boat, potentially. PGO and what pypy does have pretty much nothing to do with each other. I'm not sure what do you mean by similar boat ___ Python-Dev mailing list

Re: [Python-Dev] Branch Prediction And The Performance Of Interpreters - Don't Trust Folklore

On Mon, Aug 10, 2015 at 4:44 PM, Larry Hastings la...@hastings.org wrote: This just went by this morning on reddit's /r/programming. It's a paper that analyzed Python--among a handful of other languages--to answer the question are branch predictors still that bad at the big switch statement

Re: [Python-Dev] Python automatic optimization

As far as I can tell, the feedback directed optimizations don't give much speedup on Python. There is a variety of tools for help: cython, numba, pypy, numpy etc. if you care about performance of mathematical operations. On Thu, Jul 23, 2015 at 9:04 PM, Andrew Steinberg via Python-Dev

Re: [Python-Dev] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

I must say I completely fail to understand the procedures under which python is developed. If the change (unreviewed, just randomly applied) causes crashes, then surely it should be reverted first and continued on bug tracker instead of lingering (and the complain sitting on bug tracker)? On Tue,

Re: [Python-Dev] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

On Tue, Jul 7, 2015 at 2:14 PM, Guido van Rossum gu...@python.org wrote: FYI, do we have any indication that Raymond even read the comment? IIRC he doesn't regularly read python-dev. I also don't think code review comments ought to go to python-dev; the commiters list would seem more

Re: [Python-Dev] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

On Tue, Jul 7, 2015 at 3:08 PM, Serhiy Storchaka storch...@gmail.com wrote: On 07.07.15 15:32, Maciej Fijalkowski wrote: I kind of thought that python does pre-commit reviews (at least seems to apply to most people), so in case someone is completely exempt from that, maybe he should read

Re: [Python-Dev] speed.python.org (was: 2.7 is here until 2020, please don't call it a waste.)

, Maciej Fijalkowski wrote: On Wed, Jun 3, 2015 at 3:49 PM, R. David Murray I think we should look into getting speed.python.org up and running for both Python 2 and 3 branches: https://speed.python.org/ What would it take to make that happen ? I guess ideal would be some

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

On Wed, Jun 3, 2015 at 11:38 AM, M.-A. Lemburg m...@egenix.com wrote: On 02.06.2015 21:07, Maciej Fijalkowski wrote: Hi There was a PSF-sponsored effort to improve the situation with the https://bitbucket.org/pypy/codespeed2/src being written (thank you PSF). It's not better enough than

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

On Wed, Jun 3, 2015 at 3:49 PM, R. David Murray rdmur...@bitdance.com wrote: On Wed, 03 Jun 2015 12:04:10 +0200, Maciej Fijalkowski fij...@gmail.com wrote: On Wed, Jun 3, 2015 at 11:38 AM, M.-A. Lemburg m...@egenix.com wrote: On 02.06.2015 21:07, Maciej Fijalkowski wrote: Hi

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

Hi There was a PSF-sponsored effort to improve the situation with the https://bitbucket.org/pypy/codespeed2/src being written (thank you PSF). It's not better enough than codespeed that I would like, but gives some opportunities. That said, we have a benchmark machine for benchmarking cpython

Re: [Python-Dev] Computed Goto dispatch for Python 2

I'm -1 on the idea because: * Performance improvements are not bug fixes * The patch doesn't make the migration process from Python 2 to Python 3 easier And this is why people have been porting Python applications to Go. Maybe addressing Python performance and making Python (2 or 3) a

Re: [Python-Dev] ctypes module

I presume the reason was that noone wants to maintain code for the case where there are no buildbots available and there is no development time available. You are free to put back in the files and see if they work (they might not), but such things are usually removed if they're a maintenance

Re: [Python-Dev] ctypes module

for the record libffi supports itanium officially (but as usual I'm very skeptical how well it works on less used platforms) https://sourceware.org/libffi/ On Wed, Apr 8, 2015 at 1:32 PM, Nick Coghlan ncogh...@gmail.com wrote: On 8 April 2015 at 20:36, Maciej Fijalkowski fij...@gmail.com wrote

Re: [Python-Dev] libffi embedded in CPython

On Tue, Mar 24, 2015 at 11:31 PM, Paul Moore p.f.mo...@gmail.com wrote: On 12 March 2015 at 17:44, Paul Moore p.f.mo...@gmail.com wrote: On 12 March 2015 at 17:26, Brett Cannon br...@python.org wrote: I'm all for ditching our 'libffi_msvc' in favor of adding libffi as another 'external' for

Re: [Python-Dev] libffi embedded in CPython

On Thu, Mar 12, 2015 at 8:35 PM, Ned Deily n...@acm.org wrote: In article CAP1=2w7cx5jpqv_pr61rqs1ubusjf5f6kg0cd-qcwr2+9ij...@mail.gmail.com, For UNIX OSs we could probably rely on the system libffi then. What's the situation on OS X? Anyone know if it has libffi, or would be need to be

Re: [Python-Dev] (ctypes example) libffi embedded in CPython

On Wed, Mar 11, 2015 at 8:17 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 11 Mar 2015 19:05:57 +0100 Antoine Pitrou solip...@pitrou.net wrote: But they are not ctypes. For example, cffi wouldn't be obvious to use for interfacing with non-C code, since it requires you to write

Re: [Python-Dev] libffi embedded in CPython

On Wed, Mar 11, 2015 at 11:34 PM, Victor Stinner victor.stin...@gmail.com wrote: Le 11 mars 2015 18:29, Brett Cannon br...@python.org a écrit : I'm going to propose a somewhat controversial idea: let's deprecate the ctypes module. In the past I tried to deprecate many functions or modules

Re: [Python-Dev] libffi embedded in CPython

On Wed, Mar 11, 2015 at 8:31 PM, Wes Turner wes.tur...@gmail.com wrote: On Mar 11, 2015 12:55 PM, Maciej Fijalkowski fij...@gmail.com wrote: On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 11 Mar 2015 17:27:58 + Brett Cannon br...@python.org wrote

Re: [Python-Dev] libffi embedded in CPython

On Wed, Mar 11, 2015 at 8:05 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 11 Mar 2015 19:54:58 +0200 Maciej Fijalkowski fij...@gmail.com wrote: Depends what you call dangerous. C code doesn't rot quicker than pure Python code :-) Also, libffi really offers a wrapper around

Re: [Python-Dev] libffi embedded in CPython

On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 11 Mar 2015 17:27:58 + Brett Cannon br...@python.org wrote: Did anyone ever step forward to do this? I'm a bit worried about the long-term viability of ctypes if we don't have a maintainer or at least

Re: [Python-Dev] libffi embedded in CPython

On Thu, Mar 12, 2015 at 12:20 AM, Brett Cannon br...@python.org wrote: On Wed, Mar 11, 2015 at 6:03 PM Paul Moore p.f.mo...@gmail.com wrote: On 11 March 2015 at 21:45, Maciej Fijalkowski fij...@gmail.com wrote: Is it possible to use cffi without a C compiler/headers as easily than ctypes

Re: [Python-Dev] libffi embedded in CPython

On Thu, Mar 12, 2015 at 12:31 AM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 11 Mar 2015 23:10:14 +0200 Maciej Fijalkowski fij...@gmail.com wrote: Well, sure. The point is, such bugs are unlikely to appear at a fast rate... Also, I don't understand why libffi issues would affect

Re: [Python-Dev] boxing and unboxing data types

Not all your examples are good. * float(x) calls __float__ (not __int__) * re.group requires __eq__ (and __hash__) * I'm unsure about OSError * the % thing at the very least works on pypy On Mon, Mar 9, 2015 at 8:07 AM, Serhiy Storchaka storch...@gmail.com wrote: On 09.03.15 06:33, Ethan

Re: [Python-Dev] Encoding of PyFrameObject members

that as a hint that I want someone else to get extremely creative!) -gps On Sat Feb 07 2015 at 1:34:26 PM Greg Ewing greg.ew...@canterbury.ac.nz wrote: Maciej Fijalkowski wrote: However, you can't access thread locals from signal handlers (since in some cases it mallocs, thread locals

Re: [Python-Dev] Encoding of PyFrameObject members

Giraldeau francis.girald...@gmail.com wrote: 2015-02-08 4:01 GMT-05:00 Maciej Fijalkowski fij...@gmail.com: I'm working on vmprof (github.com/vmprof/vmprof-python) which works for both cpython and pypy (pypy has special support, cpython is patched on-the fly) This looks interesting. I'm

Re: [Python-Dev] Encoding of PyFrameObject members

On Sat, Feb 7, 2015 at 12:48 AM, Francis Giraldeau francis.girald...@gmail.com wrote: 2015-02-06 6:04 GMT-05:00 Armin Rigo ar...@tunes.org: Hi, On 6 February 2015 at 08:24, Maciej Fijalkowski fij...@gmail.com wrote: I don't think it's safe to assume f_code is properly filled by the time

Re: [Python-Dev] Encoding of PyFrameObject members

Hi Francis I don't think it's safe to assume f_code is properly filled by the time you might read it, depending a bit where you find the frame object. Are you sure it's not full of garbage? Besides, are you writing a profiler, or what exactly are you doing? On Fri, Feb 6, 2015 at 1:27 AM,

Re: [Python-Dev] PEP 468 (Ordered kwargs)

, Maciej Fijalkowski fij...@gmail.com wrote: On Sat, Jan 24, 2015 at 12:50 PM, Maciej Fijalkowski fij...@gmail.com wrote: Hi I would like to point out that we implemented rhettingers idea in PyPy that makes all the dicts ordered by default and we don't have any adverse performance effects

Re: [Python-Dev] PEP 468 (Ordered kwargs)

On Sat, Jan 24, 2015 at 12:50 PM, Maciej Fijalkowski fij...@gmail.com wrote: Hi I would like to point out that we implemented rhettingers idea in PyPy that makes all the dicts ordered by default and we don't have any adverse performance effects (in fact, there is quite significant memory

[Python-Dev] PEP 468 (Ordered kwargs)

Hi I would like to point out that we implemented rhettingers idea in PyPy that makes all the dicts ordered by default and we don't have any adverse performance effects (in fact, there is quite significant memory saving coming from it). The measurments on CPython could be different, but in

Re: [Python-Dev] More compact dictionaries with faster iteration

On Wed, Dec 31, 2014 at 3:12 PM, Serhiy Storchaka storch...@gmail.com wrote: On 10.12.12 03:44, Raymond Hettinger wrote: The current memory layout for dictionaries is unnecessarily inefficient. It has a sparse table of 24-byte entries containing the hash value, key pointer, and value

Re: [Python-Dev] libffi embedded in CPython

On Thu, Dec 18, 2014 at 10:36 PM, Jim J. Jewett jimjjew...@gmail.com wrote: On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote: ... http://bugs.python.org/issue23085 ... is there any reason any more for libffi being included in CPython? [And why a fork, instead of just treating

[Python-Dev] libffi embedded in CPython

After reading this http://bugs.python.org/issue23085 and remembering struggling having our own patches into cpython's libffi (but not into libffi itself), I wonder, is there any reason any more for libffi being included in CPython? Cheers, fijal ___

Re: [Python-Dev] libffi embedded in CPython

On Thu, Dec 18, 2014 at 9:17 PM, Steve Dower steve.do...@microsoft.com wrote: Maciej Fijalkowski wrote: After reading this http://bugs.python.org/issue23085 and remembering struggling having our own patches into cpython's libffi (but not into libffi itself), I wonder, is there any reason any

Re: [Python-Dev] libffi embedded in CPython

to debug On Thu, Dec 18, 2014 at 9:30 PM, Benjamin Peterson benja...@python.org wrote: On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote: After reading this http://bugs.python.org/issue23085 and remembering struggling having our own patches into cpython's libffi (but not into libffi itself

Re: [Python-Dev] Should standard library modules optimize for CPython?

On Mon, Jun 2, 2014 at 10:43 AM, Victor Stinner victor.stin...@gmail.com wrote: 2014-06-01 10:11 GMT+02:00 Steven D'Aprano st...@pearwood.info: My feeling is that the CPython standard library should be written for CPython, Right. PyPy, Jython and IronPython already have their own standard

Re: [Python-Dev] Language Summit notes

On Fri, Apr 11, 2014 at 2:22 PM, Paul Moore p.f.mo...@gmail.com wrote: On 11 April 2014 10:36, Armin Rigo ar...@tunes.org wrote: This would be superficial, but change the perception of CFFI to be a preprocessor that produces C extension modules. Thanks, that clarification helps a lot. Does

Re: [Python-Dev] collections.sortedtree

On Thu, Mar 27, 2014 at 10:11 AM, Stephen J. Turnbull step...@xemacs.org wrote: Nick Coghlan writes: On 27 Mar 2014 07:02, Guido van Rossum gu...@python.org wrote: Actually, the first step is publish it on PyPI, the second is to get a fair number of happy users there. The bar for

Re: [Python-Dev] collections.sortedtree

On Thu, Mar 27, 2014 at 11:07 AM, Paul Moore p.f.mo...@gmail.com wrote: On 27 March 2014 08:16, Maciej Fijalkowski fij...@gmail.com wrote: And random pieces of C included in the standard library can be shuffled under the carpet under the disguise of upgrade or what are you suggesting

Re: [Python-Dev] Intricacies of calling __eq__

On Wed, Mar 19, 2014 at 11:43 PM, Nick Coghlan ncogh...@gmail.com wrote: On 20 Mar 2014 07:38, Nick Coghlan ncogh...@gmail.com wrote: Correct, but I think this discussion has established that how many times dict lookup calls __eq__ on the key is one such thing. In CPython, it already varies

Re: [Python-Dev] Intricacies of calling __eq__

On Tue, Mar 18, 2014 at 11:19 PM, Paul Moore p.f.mo...@gmail.com wrote: On 18 March 2014 19:46, Maciej Fijalkowski fij...@gmail.com wrote: A question: how far away will this optimization apply? if x in d: do_this() do_that() do_something_else() spam = d

Re: [Python-Dev] Intricacies of calling __eq__

On Wed, Mar 19, 2014 at 2:42 PM, Antoine Pitrou solip...@pitrou.net wrote: On Tue, 18 Mar 2014 09:52:05 +0200 Maciej Fijalkowski fij...@gmail.com wrote: We're thinking about doing an optimization where say: if x in d: return d[x] where d is a dict would result in only one dict lookup

Re: [Python-Dev] Intricacies of calling __eq__

On Wed, Mar 19, 2014 at 3:17 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 19 Mar 2014 15:09:04 +0200 Maciej Fijalkowski fij...@gmail.com wrote: I would like to point out that instructing people does not really work. Besides, other examples like this: if d[x] = 3: d[x] += 1

Re: [Python-Dev] Intricacies of calling __eq__

On Wed, Mar 19, 2014 at 3:26 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 19 Mar 2014 15:21:16 +0200 Maciej Fijalkowski fij...@gmail.com wrote: On Wed, Mar 19, 2014 at 3:17 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 19 Mar 2014 15:09:04 +0200 Maciej Fijalkowski fij

Re: [Python-Dev] Intricacies of calling __eq__

On Wed, Mar 19, 2014 at 8:38 AM, Kevin Modzelewski k...@dropbox.com wrote: Sorry, I definitely didn't mean to imply that this kind of optimization is valid on arbitrary subscript expressions; I thought we had restricted ourselves to talking about builtin dicts. If we do, I think this becomes a

[Python-Dev] Intricacies of calling __eq__

Hi I have a question about calling __eq__ in some cases. We're thinking about doing an optimization where say: if x in d: return d[x] where d is a dict would result in only one dict lookup (the second one being constant folded away). The question is whether it's ok to do it, despite the

Re: [Python-Dev] Intricacies of calling __eq__

On Tue, Mar 18, 2014 at 11:35 AM, Nick Coghlan ncogh...@gmail.com wrote: On 18 March 2014 17:52, Maciej Fijalkowski fij...@gmail.com wrote: Hi I have a question about calling __eq__ in some cases. We're thinking about doing an optimization where say: if x in d: return d[x] where d

Re: [Python-Dev] Intricacies of calling __eq__

On Tue, Mar 18, 2014 at 1:18 PM, Steven D'Aprano st...@pearwood.info wrote: On Tue, Mar 18, 2014 at 05:05:56AM -0400, Terry Reedy wrote: On 3/18/2014 3:52 AM, Maciej Fijalkowski wrote: Hi I have a question about calling __eq__ in some cases. We're thinking about doing an optimization

Re: [Python-Dev] Intricacies of calling __eq__

On Tue, Mar 18, 2014 at 4:21 PM, Steven D'Aprano st...@pearwood.info wrote: On Tue, Mar 18, 2014 at 01:21:05PM +0200, Maciej Fijalkowski wrote: note that this is specifically about dicts, where __eq__ will be called undecided number of times anyway (depending on collisions in hash/buckets

Re: [Python-Dev] What is the precise problem? [was: Reference cycles in Exception.__traceback__]

On Mon, Mar 10, 2014 at 12:10 PM, Victor Stinner victor.stin...@gmail.com wrote: 2014-03-08 16:30 GMT+01:00 Maciej Fijalkowski fij...@gmail.com: How about fixing cyclic gc to deal with __del__ instead? That sounds like an awful change to the semantics. Hum? That's the purpose of the PEP 442

Re: [Python-Dev] What is the precise problem? [was: Reference cycles in Exception.__traceback__]

On Mon, Mar 10, 2014 at 3:23 PM, Victor Stinner victor.stin...@gmail.com wrote: 2014-03-10 13:11 GMT+01:00 Maciej Fijalkowski fij...@gmail.com: It was agreed long time ago that the immediate finalization is an implementation specific detail and it's not guaranteed. You should not rely

Re: [Python-Dev] What is the precise problem? [was: Reference cycles in Exception.__traceback__]

On Mon, Mar 10, 2014 at 7:35 PM, Guido van Rossum gu...@python.org wrote: On Mon, Mar 10, 2014 at 10:30 AM, Maciej Fijalkowski fij...@gmail.com wrote: On Mon, Mar 10, 2014 at 3:23 PM, Victor Stinner victor.stin...@gmail.com wrote: 2014-03-10 13:11 GMT+01:00 Maciej Fijalkowski fij

Re: [Python-Dev] What is the precise problem? [was: Reference cycles in Exception.__traceback__]

On Mon, Mar 10, 2014 at 7:49 PM, Guido van Rossum gu...@python.org wrote: On Mon, Mar 10, 2014 at 10:39 AM, Maciej Fijalkowski fij...@gmail.com wrote: On Mon, Mar 10, 2014 at 7:35 PM, Guido van Rossum gu...@python.org wrote: On Mon, Mar 10, 2014 at 10:30 AM, Maciej Fijalkowski fij

Re: [Python-Dev] What is the precise problem? [was: Reference cycles in Exception.__traceback__]

On Sat, Mar 8, 2014 at 5:14 PM, Victor Stinner victor.stin...@gmail.com wrote: 2014-03-08 14:33 GMT+01:00 Antoine Pitrou solip...@pitrou.net: Ok, it's actually quite trivial. The whole chain is kept alive by the fut global variable. If you arrange for it to be disposed of: fut =

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

On Tue, Feb 25, 2014 at 11:13 AM, Victor Stinner victor.stin...@gmail.com wrote: Hi, 2014-02-25 8:53 GMT+01:00 Nick Coghlan ncogh...@gmail.com: I've checked these, and noted the relevant hg.python.org links on the tracker issue at http://bugs.python.org/issue20246 Would it be possible to

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

On Tue, Feb 25, 2014 at 3:01 PM, Donald Stufft don...@stufft.io wrote: On Feb 25, 2014, at 7:59 AM, Maciej Fijalkowski fij...@gmail.com wrote: On Tue, Feb 25, 2014 at 11:13 AM, Victor Stinner victor.stin...@gmail.com wrote: Hi, 2014-02-25 8:53 GMT+01:00 Nick Coghlan ncogh...@gmail.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

On Tue, Feb 25, 2014 at 3:06 PM, Chris Angelico ros...@gmail.com wrote: On Tue, Feb 25, 2014 at 11:59 PM, Maciej Fijalkowski fij...@gmail.com wrote: Last issues: - hash DoS is this fixed? Yes, hash randomization was added as an option in 2.7.3 or 2.7.4 or thereabouts, and is on by default

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

On Tue, Feb 25, 2014 at 5:22 PM, Barry Warsaw ba...@python.org wrote: On Feb 25, 2014, at 03:03 PM, Maciej Fijalkowski wrote: Oh, I thought security fixes go to all python releases. Well, not the EOL'd ones of course. yes of course sorry. Where's the analysis on backporting SIPHash

Re: [Python-Dev] cffi in stdlib

On Thu, Dec 19, 2013 at 3:17 AM, Gregory P. Smith g...@krypto.org wrote: On Tue, Dec 17, 2013 at 8:43 AM, Stefan Krah ste...@bytereef.org wrote: Maciej Fijalkowski fij...@gmail.com wrote: I would like to discuss on the language summit a potential inclusion of cffi[1] into stdlib

Re: [Python-Dev] cffi in stdlib

quite pushed to commitment. =) we're still working on resolving discussed issues before officially proposing it for inclusion. On Tue, Dec 17, 2013 at 11:43 AM, Stefan Krah ste...@bytereef.org wrote: Maciej Fijalkowski fij...@gmail.com wrote: I would like to discuss on the language summit

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

On Sun, Nov 17, 2013 at 9:02 PM, Barry Warsaw ba...@python.org wrote: On Nov 17, 2013, at 05:14 PM, Victor Stinner wrote: 2013/11/16 Maciej Fijalkowski fij...@gmail.com: Can I see some writeup how -OO benefit embedded devices? You get smaller .pyc files. In an embedded device, the whole OS may

Re: [Python-Dev] The pysandbox project is broken

On Sat, Nov 16, 2013 at 12:12 PM, Nick Coghlan ncogh...@gmail.com wrote: On 16 Nov 2013 11:35, Christian Tismer tis...@stackless.com wrote: IOW: Do we really need a full abstraction, embedded in a virtual OS, or is there already a compromise that suits 98 percent of the common needs? I think

  1   2   3   4   >