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
___
Pyth
On Thu, Dec 18, 2014 at 9:17 PM, Steve Dower 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 ther
re hard to debug
On Thu, Dec 18, 2014 at 9:30 PM, Benjamin Peterson 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
On Thu, Dec 18, 2014 at 10:36 PM, Jim J. Jewett 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
On Wed, Dec 31, 2014 at 3:12 PM, Serhiy Storchaka 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 pointer.
>>
>>
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 principl
On Sat, Jan 24, 2015 at 12:50 PM, Maciej Fijalkowski 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
&g
24, 2015 at 2:51 AM, Maciej Fijalkowski
> wrote:
>>
>> On Sat, Jan 24, 2015 at 12:50 PM, Maciej Fijalkowski
>> wrote:
>> > Hi
>> >
>> > I would like to point out that we implemented rhettingers idea in PyPy
>> > that makes all the dicts ordered
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, Franci
On Sat, Feb 7, 2015 at 12:48 AM, Francis Giraldeau
wrote:
> 2015-02-06 6:04 GMT-05:00 Armin Rigo :
>
>> Hi,
>>
>> On 6 February 2015 at 08:24, Maciej Fijalkowski wrote:
>> > I don't think it's safe to assume f_code is properly filled by the
>> &g
nals are so rare for most things... until they aren't.
>
> As a side note and encouragement: I wonder what PyPy could do for
> dynamically enabled and disabled low overhead CPU profiling. (take that as a
> hint that I want someone else to get extremely creative!)
>
> -gps
>
Giraldeau
wrote:
> 2015-02-08 4:01 GMT-05:00 Maciej Fijalkowski :
>>
>> 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 inter
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 wrote:
> On 09.03.15 06:33, Ethan Furman wrote:
>>
>> I
On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou wrote:
> On Wed, 11 Mar 2015 17:27:58 +
> Brett Cannon 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
>> someone making sure we are sta
On Wed, Mar 11, 2015 at 8:05 PM, Antoine Pitrou wrote:
> On Wed, 11 Mar 2015 19:54:58 +0200
> Maciej Fijalkowski wrote:
>> >
>> > Depends what you call "dangerous". C code doesn't rot quicker than pure
>> > Python code :-) Also, libffi really o
On Wed, Mar 11, 2015 at 8:31 PM, Wes Turner wrote:
>
> On Mar 11, 2015 12:55 PM, "Maciej Fijalkowski" wrote:
>>
>> On Wed, Mar 11, 2015 at 7:50 PM, Antoine Pitrou
>> wrote:
>> > On Wed, 11 Mar 2015 17:27:58 +
>> > Brett Cannon wrote:
>
On Wed, Mar 11, 2015 at 8:17 PM, Antoine Pitrou wrote:
> On Wed, 11 Mar 2015 19:05:57 +0100
> Antoine Pitrou 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 C-like
>> > > declarations
On Wed, Mar 11, 2015 at 11:34 PM, Victor Stinner
wrote:
>
> Le 11 mars 2015 18:29, "Brett Cannon" 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 because they are
> rarely or neve
On Thu, Mar 12, 2015 at 12:20 AM, Brett Cannon wrote:
>
>
> On Wed, Mar 11, 2015 at 6:03 PM Paul Moore wrote:
>>
>> On 11 March 2015 at 21:45, Maciej Fijalkowski wrote:
>> >> Is it possible to use cffi without a C compiler/headers as easily than
>> >
On Thu, Mar 12, 2015 at 12:31 AM, Antoine Pitrou wrote:
> On Wed, 11 Mar 2015 23:10:14 +0200
> Maciej Fijalkowski wrote:
>> >
>> > Well, sure. The point is, such bugs are unlikely to appear at a fast
>> > rate... Also, I don't understand why libffi issues w
On Thu, Mar 12, 2015 at 8:35 PM, Ned Deily wrote:
> In article
> ,
>> 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
>> pulled in to be used like on Windows?
>
> Ronald (in http://bugs.python.org/
On Tue, Mar 24, 2015 at 11:31 PM, Paul Moore wrote:
> On 12 March 2015 at 17:44, Paul Moore wrote:
>> On 12 March 2015 at 17:26, Brett Cannon wrote:
I'm all for ditching our 'libffi_msvc' in favor of adding libffi as
another 'external' for the Windows build. I have managed to get
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 burden
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 wrote:
> On 8 April 2015 at 20:36, Maciej Fijalkowski wrote:
>> I presume the r
> 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
b
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 and
On Wed, Jun 3, 2015 at 11:38 AM, M.-A. Lemburg 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
>>
On Wed, Jun 3, 2015 at 3:49 PM, R. David Murray wrote:
> On Wed, 03 Jun 2015 12:04:10 +0200, Maciej Fijalkowski
> wrote:
>> On Wed, Jun 3, 2015 at 11:38 AM, M.-A. Lemburg wrote:
>> > On 02.06.2015 21:07, Maciej Fijalkowski wrote:
>> >> Hi
>> >>
>
t; we could add some additional focus on performance regressions. Right now,
>> > we don't have any way of reliably and reproducibly testing Python
>> > performance.
>> >
>> > I'm very interested in speed.python.org and feel regret that the project is
>> &
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,
On Tue, Jul 7, 2015 at 2:14 PM, Guido van Rossum 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 appropriate?
> (Though i
On Tue, Jul 7, 2015 at 3:08 PM, Serhiy Storchaka 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 h
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
wrote:
> He
On Mon, Aug 10, 2015 at 4:44 PM, Larry Hastings 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
> approach to
>
> 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
Python-Dev
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 *highly obscure* corner case: __del__
will still be calle
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, w
On Thu, Sep 10, 2015 at 10:26 AM, Serhiy Storchaka 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 allowed and people do it
On Fri, Sep 11, 2015 at 1:48 AM, Raymond Hettinger
wrote:
>
>> On Sep 10, 2015, at 3:23 AM, Maciej Fijalkowski wrote:
>>
>> I would like to know what are the semantics if you subclass something
>> from itertools (e.g. islice).
>>
>> Right now it'
On Sun, Sep 13, 2015 at 5:46 PM, Raymond Hettinger
wrote:
>
>> On Sep 13, 2015, at 3:49 AM, Maciej Fijalkowski wrote:
>>
>>> The intended semantics are that the itertools are classes (not functions
>>> and not generators). They are intended to be sub-cla
M, Raymond Hettinger
wrote:
>
>> On Sep 13, 2015, at 3:09 PM, Maciej Fijalkowski wrote:
>>
>> Well, fair enough, but the semantics of "whatever happens to happen
>> because we decided subclassing is a cool idea" is possibly the worst
>> answer to th
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 a
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 pyth
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 item
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 invariants out of loops, etc.)
> us
Uh, sorry, misread your full mail, scratch that
On Wed, Nov 4, 2015 at 9:07 AM, Maciej Fijalkowski 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
> wrote:
>> Hi,
>>
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 wrote:
>
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 bench
On Tue, Dec 1, 2015 at 11:49 AM, Fabio Zadrozny wrote:
>
> On Tue, Dec 1, 2015 at 6:36 AM, Maciej Fijalkowski wrote:
>>
>> Hi
>>
>> Thanks for doing the work! I'm on of the pypy devs and I'm very
>> interested in seeing this getting somewhere. I mus
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 mailto:fabi...@gmail.com>>
> Date: Tuesday, December 1, 2015 at 1:36 AM
> To: David Stewart
> mailto:david.c.stew...@intel.com>>
> Cc: "R. David Murr
On Tue, Dec 1, 2015 at 9:04 PM, Stewart, David C
wrote:
> On 12/1/15, 10:56 AM, "Maciej Fijalkowski" wrote:
>
>
>
>>Hi David.
>>
>>Any reason you run a tiny tiny subset of benchmarks?
>
> We could always run more. There are so many in the full se
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 pyp
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 har
On Mon, Jan 11, 2016 at 9:56 PM, Victor Stinner
wrote:
> Le 11 janv. 2016 8:09 PM, "Maciej Fijalkowski" a écrit :
>> Hi Victor.
>>
>> You know that pypy does this stuff without changing and exposing
>> python semantics right? We have a version dict that does
Hi
change in between 3.5.0 and 3.5.1 (hiding _PyThreadState_Current and
pyatomic.h) broke vmprof. The problem is that as a profile, vmprof can
really encounter _PyThreadState_Current being null, while crashing an
interpreter is a bit not ideal in this case.
Any chance, a) _PyThreadState_Current c
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 wrote:
> Good point
>
> On Mon, Jan 18, 2016 at 9:25 PM, Victor Stinner
> wrote:
>> Hum, you can try
Good point
On Mon, Jan 18, 2016 at 9:25 PM, Victor Stinner
wrote:
> Hum, you can try to lie and define Py_BUILD_CORE?
>
> Victor
>
> 2016-01-18 21:18 GMT+01:00 Maciej Fijalkowski :
>> Hi
>>
>> change in between 3.5.0 and 3.5.1 (hiding _PyThreadState_Current and
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 Seliv
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 public Python API, but the PEP
>> > doesn't c
On Wed, Jan 20, 2016 at 8:00 PM, Yury Selivanov wrote:
>
>
> On 2016-01-20 1:36 PM, Maciej Fijalkowski wrote:
>>
>> On Wed, Jan 20, 2016 at 7:22 PM, Brett Cannon wrote:
>>>
>>>
>>> On Wed, 20 Jan 2016 at 10:11 Yury Selivanov
>>> wrote:
&g
On Wed, Jan 20, 2016 at 8:08 PM, Yury Selivanov wrote:
>
> On 2016-01-20 2:02 PM, Maciej Fijalkowski wrote:
>>
>> On Wed, Jan 20, 2016 at 8:00 PM, Yury Selivanov
>> wrote:
>>
> [..]
>>>>
>>>> Brett, you need two things - the ID of the dic
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 wrote:
>
>
> On 2016-01-20 2:09 PM, Maciej Fij
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 projects seem to mak
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:
>
> long
> PyObject_Hash(
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 inside CPython. It's just
> a w
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 had to keep being extended
>> >then
On Wed, Nov 13, 2013 at 2:11 AM, Steven D'Aprano wrote:
> On Wed, Nov 13, 2013 at 12:58:42AM +0100, Victor Stinner wrote:
>
>> I now gave up on sandboxing Python. I just would like to warn other
>> core developers that trying to put a sandbox in Python is not a good
>> idea :-)
>
> Do you mean CPy
On Sat, Nov 16, 2013 at 12:12 PM, Nick Coghlan wrote:
> On 16 Nov 2013 11:35, "Christian Tismer" 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 as a starter, categorizing t
On Fri, Nov 15, 2013 at 6:56 PM, Trent Nelson wrote:
> On Tue, Nov 12, 2013 at 01:16:55PM -0800, Victor Stinner wrote:
>> pysandbox cannot be used in practice
>>
>>
>> To protect the untrusted namespace, pysandbox installs a lot of
>> different protections. Bec
On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy wrote:
> http://bugs.python.org/issue19562
> propose to change the first assert in Lib/datetime.py
> assert 1 <= month <= 12, month
> to
> assert 1 <= month <= 12,'month must be in 1..12'
> to match the next two asserts out of the *53* in the file.
On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan wrote:
> On 16 November 2013 23:17, Maciej Fijalkowski wrote:
>> On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy wrote:
>>> If user input can trigger an assert, then the code should raise a normal
>>> exception that
On Sat, Nov 16, 2013 at 5:33 PM, Maciej Fijalkowski wrote:
> On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan wrote:
>> On 16 November 2013 23:17, Maciej Fijalkowski wrote:
>>> On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy wrote:
>>>> If user input can trigger an asse
On Sun, Nov 17, 2013 at 9:02 PM, Barry Warsaw wrote:
> On Nov 17, 2013, at 05:14 PM, Victor Stinner wrote:
>
>>2013/11/16 Maciej Fijalkowski :
>>> Can I see some writeup how -OO benefit embedded devices?
>>
>>You get smaller .pyc files. In an embedded device, t
never
> 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 wrote:
>>
>> Maciej Fijalkowski wrote:
>> > I would like to discuss on
On Thu, Dec 19, 2013 at 3:17 AM, Gregory P. Smith wrote:
>
>
>
> On Tue, Dec 17, 2013 at 8:43 AM, Stefan Krah wrote:
>>
>> Maciej Fijalkowski wrote:
>> > I would like to discuss on the language summit a potential inclusion
>> > of cffi[1] into std
On Tue, Feb 25, 2014 at 11:13 AM, Victor Stinner
wrote:
> Hi,
>
> 2014-02-25 8:53 GMT+01:00 Nick Coghlan :
>> 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 have a table with all known Python s
On Tue, Feb 25, 2014 at 3:01 PM, Donald Stufft wrote:
>
> On Feb 25, 2014, at 7:59 AM, Maciej Fijalkowski wrote:
>
>> On Tue, Feb 25, 2014 at 11:13 AM, Victor Stinner
>> wrote:
>>> Hi,
>>>
>>> 2014-02-25 8:53 GMT+01:00 Nick Coghlan :
>>>&
On Tue, Feb 25, 2014 at 3:06 PM, Chris Angelico wrote:
> On Tue, Feb 25, 2014 at 11:59 PM, Maciej Fijalkowski 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
> thereab
On Tue, Feb 25, 2014 at 5:22 PM, Barry Warsaw 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 b
On Sat, Mar 8, 2014 at 5:14 PM, Victor Stinner wrote:
> 2014-03-08 14:33 GMT+01:00 Antoine Pitrou :
>> 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 = asyncio.Future()
>> asyncio.Task(func(fut)
On Mon, Mar 10, 2014 at 12:10 PM, Victor Stinner
wrote:
> 2014-03-08 16:30 GMT+01:00 Maciej Fijalkowski :
>> 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 which is
On Mon, Mar 10, 2014 at 3:23 PM, Victor Stinner
wrote:
> 2014-03-10 13:11 GMT+01:00 Maciej Fijalkowski :
>> It was agreed long time ago that the immediate finalization is an
>> implementation specific detail and it's not guaranteed. You should not
>> rely on __del__s b
On Mon, Mar 10, 2014 at 7:35 PM, Guido van Rossum wrote:
> On Mon, Mar 10, 2014 at 10:30 AM, Maciej Fijalkowski
> wrote:
>>
>> On Mon, Mar 10, 2014 at 3:23 PM, Victor Stinner
>> wrote:
>> > 2014-03-10 13:11 GMT+01:00 Maciej Fijalkowski :
>> >> I
On Mon, Mar 10, 2014 at 7:49 PM, Guido van Rossum wrote:
> On Mon, Mar 10, 2014 at 10:39 AM, Maciej Fijalkowski
> wrote:
>>
>> On Mon, Mar 10, 2014 at 7:35 PM, Guido van Rossum
>> wrote:
>> > On Mon, Mar 10, 2014 at 10:30 AM, Maciej Fijalkowski
>> > wr
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 fact
On Tue, Mar 18, 2014 at 11:35 AM, Nick Coghlan wrote:
> On 18 March 2014 17:52, Maciej Fijalkowski wrote:
>> Hi
>>
>> I have a question about calling __eq__ in some cases.
>>
>> We're thinking about doing an optimization where say:
>>
>> if x in
On Tue, Mar 18, 2014 at 1:18 PM, Steven D'Aprano 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.
>> >
&g
On Tue, Mar 18, 2014 at 4:21 PM, Steven D'Aprano 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
&
On Tue, Mar 18, 2014 at 11:19 PM, Paul Moore wrote:
> On 18 March 2014 19:46, Maciej Fijalkowski wrote:
>>> A question: how far away will this optimization apply?
>>>
>>> if x in d:
>>> do_this()
>>> do_that()
>>>
On Wed, Mar 19, 2014 at 2:42 PM, Antoine Pitrou wrote:
> On Tue, 18 Mar 2014 09:52:05 +0200
> Maciej Fijalkowski wrote:
>>
>> We're thinking about doing an optimization where say:
>>
>> if x in d:
>>return d[x]
>>
>> where d is a dict
On Wed, Mar 19, 2014 at 3:17 PM, Antoine Pitrou wrote:
> On Wed, 19 Mar 2014 15:09:04 +0200
> Maciej Fijalkowski wrote:
>>
>> I would like to point out that instructing people does not really
>> work. Besides, other examples like this:
>>
>> if d[x] >
On Wed, Mar 19, 2014 at 3:26 PM, Antoine Pitrou wrote:
> On Wed, 19 Mar 2014 15:21:16 +0200
> Maciej Fijalkowski wrote:
>
>> On Wed, Mar 19, 2014 at 3:17 PM, Antoine Pitrou wrote:
>> > On Wed, 19 Mar 2014 15:09:04 +0200
>> > Maciej Fijalkowski wrote:
>>
On Wed, Mar 19, 2014 at 8:38 AM, Kevin Modzelewski 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
> discussion
On Wed, Mar 19, 2014 at 11:43 PM, Nick Coghlan wrote:
>
> On 20 Mar 2014 07:38, "Nick Coghlan" 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 based on:
>>
>> - dict
On Thu, Mar 27, 2014 at 10:11 AM, Stephen J. Turnbull
wrote:
> Nick Coghlan writes:
>
> > On 27 Mar 2014 07:02, "Guido van Rossum" 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 getting something
> >> incl
On Thu, Mar 27, 2014 at 11:07 AM, Paul Moore wrote:
> On 27 March 2014 08:16, Maciej Fijalkowski 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?
>
> The
On Fri, Apr 11, 2014 at 2:22 PM, Paul Moore wrote:
> On 11 April 2014 10:36, Armin Rigo 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 this mean that "API-mode"
>
On Mon, Jun 2, 2014 at 10:43 AM, Victor Stinner
wrote:
> 2014-06-01 10:11 GMT+02:00 Steven D'Aprano :
>> My feeling is that the CPython standard library should be written for
>> CPython,
>
> Right. PyPy, Jython and IronPython already have their "own" standard
> library when they need a different i
On Sat, Feb 16, 2013 at 10:03 AM, Stefan Behnel wrote:
> Nick Coghlan, 16.02.2013 08:49:
>> Yes, the PyPy team and scientific users of Python have a long history
>> of talking past each other (and abusing each other for the mutual lack
>> of understanding). However, that's no excuse for deliberate
On Wed, Feb 20, 2013 at 8:24 PM, Christian Heimes wrote:
> Am 20.02.2013 17:25, schrieb Benjamin Peterson:
>> Are these going to become patches for Python, too?
>
> I'm working on it. The patches need to be discussed as they break
> backward compatibility and AFAIK XML standards, too.
That's not
1 - 100 of 355 matches
Mail list logo
