On Sun, 06 Oct 2013 00:02:14 +0300
Serhiy Storchaka wrote:
> 05.10.13 23:11, Georg Brandl написав(ла):
> > Am 05.10.2013 21:42, schrieb Serhiy Storchaka:
> >> Please remember me, what was common decision about CPython-only
> >> optimizations which change computation complexity? I.g. constant
> >>
On Sat, 5 Oct 2013 15:35:30 -0700
Raymond Hettinger wrote:
>
> Making bytearray's efficiently pop from the left side is dubious.
> This isn't a common idiom, nor should it be. Even if all the
> other implementations could model this behavior, it wouldn't
> be a good idea to have bytearrays have
On Sun, 6 Oct 2013 09:32:30 +1000
Nick Coghlan wrote:
> On 6 Oct 2013 08:59, "Antoine Pitrou" wrote:
> >
> > On Sat, 5 Oct 2013 15:35:30 -0700
> > Raymond Hettinger wrote:
> > >
> > > Making bytearray's efficiently pop from the left side i
Hi,
On Sun, 6 Oct 2013 17:32:37 +0200
Victor Stinner wrote:
>
> Slowly, I'm trying to see if it would be possible to reduce the memory
> footprint of Python using the tracemalloc module.
>
> First, I noticed that linecache can allocate more than 2 MB. What do
> you think of adding a registry o
On Sun, 06 Oct 2013 22:27:52 +0200
mar...@v.loewis.de wrote:
>
> Quoting Benjamin Peterson :
>
> >> If you know that your application uses a lot of memory, it is
> >> interesting to sometimes (when the application is idle) try to release
> >> some bytes to not use all the system memory. On embedd
On Sun, 06 Oct 2013 22:47:27 +0200
mar...@v.loewis.de wrote:
>
> Quoting Antoine Pitrou :
>
> > The linecache module is used implicitly by the traceback and warnings
> > module, so perhaps quite a bit more than one would imagine :-)
> >
> > I think limiting the l
On Tue, 8 Oct 2013 08:31:46 +1000
Nick Coghlan wrote:
>
> That said, with the current plan to lower the barrier to entry for PyPI
> dependencies (I should have the 3.4 only ensurepip proposal written up some
> time this week), I think it makes sense to let this one bake on PyPI for a
> while.
"t
Le Tue, 8 Oct 2013 08:21:43 +0200,
Antoine Pitrou a écrit :
>
> > I think there *is* a potentially worthwhile generalisation here,
> > but I'm far from sure "is-a-dict" is the right data model - for
> > composability reasons, it feels like a "has-a"
For the record, if you want to reduce memory footprint of Python on a
x86-64 bit, you can use the "x32" ABI for which Debian/Ubuntu provide
some support.
(install the required base packages and use CFLAGS=-mx32 LDFLAGS=-mx32)
Regards
Antoine.
Le Sun, 6 Oct 2013 17:32:37 +0200,
Victor Stinner
Le Tue, 8 Oct 2013 22:12:02 +1000,
Nick Coghlan a écrit :
>
> It's OK if the key transforming API has to constrain the behaviour of
> the underlying mapping or require an appropriately designed transform
> function to handle more esoteric containers. Either would still be
> better than categorica
Le Tue, 8 Oct 2013 22:49:28 +1000,
Nick Coghlan a écrit :
> > Well, you could ask the same question about OrderedDict,
> > defaultdict or Weak*Dictionary since neither of them use
> > composition :-)
>
> We *did* ask the same question about those (except the Weak* variants,
> simply due to age).
On Tue, 8 Oct 2013 23:36:05 +0400
Yuriy Taraday wrote:
> On Tue, Oct 8, 2013 at 10:17 PM, MRAB wrote:
>
> > If you don't need the original key, then you might as well just use a
> > transform function with a dict.
>
> As I understood, storing original keys is not the purpose of TransformDict,
>
On Wed, 09 Oct 2013 01:33:26 +0200
Larry Hastings wrote:
>
> I've contributed a new PEP to humanity. I include the RST for your
> reading pleasure below, but you can also read it online here:
>
> http://www.python.org/dev/peps/pep-0457/
Only skimmed through the PEP, but -1 on the whole id
Le Tue, 8 Oct 2013 15:43:40 -0400,
Benjamin Peterson a écrit :
> 2013/10/8 R. David Murray :
> > In this context, if we'd been *really* smart-lazy in CPython
> > development, we'd have kept the memory and startup-time and...well,
> > we probably do pretty well on CPU actually...smaller, so that w
Le Wed, 09 Oct 2013 11:01:01 +1300,
Greg Ewing a écrit :
> R. David Murray wrote:
> > I can give you one data point: a mobile platform that (currently)
> > uses Python3, and does not use linecache because of how much memory
> > it consumes.
>
> Wouldn't a sensible approach be to discard the linec
Hello,
Just noticed the following quirk:
>>> type.__subclasses__()
Traceback (most recent call last):
File "", line 1, in
TypeError: descriptor '__subclasses__' of 'type' object needs an argument
Yet it would be nice to know about the subclasses of type.
Regards
Antoine.
Le Wed, 9 Oct 2013 10:29:30 +0200,
Antoine Pitrou a écrit :
> Le Tue, 8 Oct 2013 15:43:40 -0400,
> Benjamin Peterson a écrit :
>
> > 2013/10/8 R. David Murray :
> > > In this context, if we'd been *really* smart-lazy in CPython
> > > development, we&#
Le Wed, 9 Oct 2013 08:39:40 -0400,
Benjamin Peterson a écrit :
> 2013/10/9 Antoine Pitrou :
> > Le Wed, 9 Oct 2013 10:29:30 +0200,
> > Antoine Pitrou a écrit :
> >> Le Tue, 8 Oct 2013 15:43:40 -0400,
> >> Benjamin Peterson a écrit :
> >>
> >
Le Wed, 09 Oct 2013 15:32:10 +0200,
Larry Hastings a écrit :
> On 10/09/2013 02:38 PM, Benjamin Peterson wrote:
> > Why does a syntax need to be reserved? Documentation conventions and
> > the syntax of internal tools like argument clinic may be changed any
> > time we like.
>
> If Argument Clini
Le Wed, 9 Oct 2013 15:40:08 +0100,
Paul Moore a écrit :
> On 9 October 2013 15:30, Larry Hastings wrote:
> > Only if I can stop writing other PEPs and replying to their
> > discussion threads!
>
> So once again, why is this new PEP needed? :-)
Procrastination perhaps ;-)
> Paul
__
On Wed, 09 Oct 2013 20:38:55 +0200
Georg Brandl wrote:
> Am 07.10.2013 20:41, schrieb antoine.pitrou:
> > http://hg.python.org/cpython/rev/2aee9c41bb79
> > changeset: 86140:2aee9c41bb79
> > branch: 3.3
> > parent: 86136:b4444d16e333
> > user
Le Thu, 10 Oct 2013 14:36:26 +0200,
Dirkjan Ochtman a écrit :
> On Thu, Oct 10, 2013 at 2:25 PM, Christian Heimes
> wrote:
> > Benchmark of 1000 times "python -c ''"
> >
> > Python 3.4dev with all my experimental patches:
> >
> > Avg: 0.705161 -> 0.443613: 1.59x faster
> >
> > 2.7 -> 3.4dev:
>
Le Thu, 10 Oct 2013 10:26:25 -0400,
Benjamin Peterson a écrit :
> 2013/10/9 Antoine Pitrou :
> > Le Wed, 9 Oct 2013 10:29:30 +0200,
> > Antoine Pitrou a écrit :
> >> Le Tue, 8 Oct 2013 15:43:40 -0400,
> >> Benjamin Peterson a écrit :
> >>
> >
Hello,
On Fri, 11 Oct 2013 07:39:48 +0200 (CEST)
raymond.hettinger wrote:
> http://hg.python.org/cpython/rev/f014b5f0773f
> changeset: 86209:f014b5f0773f
> user:Raymond Hettinger
> date:Thu Oct 10 22:39:39 2013 -0700
> summary:
> Rename contextlib.ignored() to contextlib.ign
Let me answer here to Nick's argument on the tracker (made last year,
before the patch was committed):
> As with many context managers, a key benefit here is in the priming
> effect for readers. In this code:
>
> try:
># Whatever
> except (A, B, C):
>pass
>
> the reader
Le Fri, 11 Oct 2013 14:24:29 +0200,
Stefan Krah a écrit :
> Hi,
>
> recently there has been some talk about reducing import times. It
> seems that the current import strategy for C extensions (i.e.
> importing the extension at the bottom of the .py file) is quite slow:
>
>
> ===
Le Fri, 11 Oct 2013 13:51:24 +0100,
Mark Lawrence a écrit :
> On 11/10/2013 11:33, Eric V. Smith wrote:
> >
> > And Antoine has again taught me a new word:
> > polysemic: having more than one meaning; having multiple meanings
> >
>
> IMHO a poor word to use. I'm a middle aged Brit who's never he
Le Fri, 11 Oct 2013 17:01:35 +0200,
Stefan Krah a écrit :
>
> I'm getting about the same values as above. I may be misunderstanding
> something, but I wanted to reduce the difference between the 2.21 msec
> and the 112 usec.
So you aren't complaining about C extension import time, but Python
cod
On Sat, 12 Oct 2013 14:04:48 +1000
Nick Coghlan wrote:
> On 12 Oct 2013 11:15, "Victor Stinner" wrote:
> >
> > 2013/10/12 Ethan Furman :
> > >> What do you propose in cases like this? Should the keyword always refer
> > >> to the same PEP it did in the past, even when that PEP is no longer as
> >
Opened issue at http://psf.upfronthosting.co.za/roundup/meta/issue528
Regards
Antoine.
Le samedi 12 octobre 2013 à 14:40 +0200, Victor Stinner a écrit :
> Hi,
>
> The DNS server of python.org announce the IP address 2a01:4f8:131:2480::3:
>
> $ host -t bugs.python.org
> bugs.python.org
On Sat, 12 Oct 2013 18:55:42 +0200
Christian Heimes wrote:
> Am 12.10.2013 17:37, schrieb Nick Coghlan:
> > I think the default recommendation in PEP 399 still makes sense - 2
> > modules are easy to manage than three and the idiom allows for easy
> > partial replacement.
>
> We could ues yet ano
On Sat, 12 Oct 2013 19:19:44 +0200
Christian Heimes wrote:
> Hi,
>
> I have written a interface to OpenSSL's PKCS5_PBKDF2_HMAC() function. It
> implements PKCS#5's password based key derivation function 2 with HMAC
> as pseudo-random function. It supports any digest that is supported by
> OpenSSL
On Sat, 12 Oct 2013 21:19:16 +0200
Georg Brandl wrote:
> Am 12.10.2013 20:20, schrieb Serhiy Storchaka:
> > 12.10.13 21:04, Georg Brandl написав(ла):
> >> in light of the recent thread about PEPs not forming part of the docs,
> >> I've just pushed a change that allows to document C API elements
>
On Sat, 12 Oct 2013 22:04:57 +0200
Georg Brandl wrote:
> Am 12.10.2013 21:56, schrieb Antoine Pitrou:
> > On Sat, 12 Oct 2013 21:19:16 +0200
> > Georg Brandl wrote:
> >> Am 12.10.2013 20:20, schrieb Serhiy Storchaka:
> >> > 12.10.13 21:04, Georg Brandl написав
On Sat, 12 Oct 2013 22:25:36 +0200
Georg Brandl wrote:
> >> > ("limited API" is really a bad synonym for "stable ABI" IMO)
> >>
> >> It's not a synonym: to get a stable ABI, you use the limited API.
> >
> > I still don't like that name, because it doesn't convey any interesting
> > information.
On Sat, 12 Oct 2013 23:35:23 +0200
Christian Heimes wrote:
> Am 12.10.2013 19:02, schrieb Antoine Pitrou:
> > If you grow sys.path, imports get slower.
> > (IMHO it also makes the source tree more cumbersome to navigate)
>
> It shouldn't slow down successful imports.
On Sun, 13 Oct 2013 16:57:09 +1000
Nick Coghlan wrote:
>
> For the record, this thread did prompt me to consider the new construct
> anew, but on reflection, I still consider it a reasonable addition to
> contextlib.
>
> It substantially improves the simple cases it is intended to help with,
> a
On Sun, 13 Oct 2013 22:50:07 +1000
Nick Coghlan wrote:
> That's the way this works (unless you think this is such a disastrous
> addition that you want to appeal to Guido to strip me of my
> responsibilities as contextlib maintainer and go hunting for a new
> one).
Wow... I don't think challengin
On Sun, 13 Oct 2013 16:05:40 +0200
Antoine Pitrou wrote:
> On Sun, 13 Oct 2013 22:50:07 +1000
> Nick Coghlan wrote:
> > That's the way this works (unless you think this is such a disastrous
> > addition that you want to appeal to Guido to strip me of my
> > r
On Mon, 14 Oct 2013 01:20:30 +1000
Nick Coghlan wrote:
>
> Then, yes, I think challenging people to try to get me booted as
> module maintainer for contextlib is a *precisely* proportionate
> response.
Because I don't agree with you on one instance doesn't mean I usually
*distrust* your judgemen
Le Mon, 14 Oct 2013 12:47:03 +0300,
Serhiy Storchaka a écrit :
> 13.10.13 13:39, Christian Heimes написав(ла):
> > Am 13.10.2013 08:32, schrieb Nick Coghlan:
> >> +1 to hashlib from me (especially since we used that as the best
> >> available home for compare_digest).
> >
> > I'm afraid your memor
Le Mon, 14 Oct 2013 13:49:34 +0200,
Maciej Fijalkowski a écrit :
> HI
>
> I'm working on an incremental GC for PyPy. How do I measure GC pauses
> in CPython? (that is, the circular reference searching stuff)
timeit gc.collect()?
___
Python-Dev mailin
Le Mon, 14 Oct 2013 14:25:18 +0200,
Maciej Fijalkowski a écrit :
> On Mon, Oct 14, 2013 at 2:11 PM, "Martin v. Löwis"
> wrote:
> > Am 14.10.13 13:49, schrieb Maciej Fijalkowski:
> >> I'm working on an incremental GC for PyPy. How do I measure GC
> >> pauses in CPython? (that is, the circular refe
Le Mon, 14 Oct 2013 14:38:44 +0200,
Maciej Fijalkowski a écrit :
> On Mon, Oct 14, 2013 at 2:34 PM, Antoine Pitrou
> wrote:
> > Le Mon, 14 Oct 2013 14:25:18 +0200,
> > Maciej Fijalkowski a écrit :
> >> On Mon, Oct 14, 2013 at 2:11 PM, "Martin v. Löwis"
Hello,
On Tue, 15 Oct 2013 00:55:05 +0400
Sergey Dorofeev wrote:
> Hello,
>
> I'd like to submit patch to support zip archives created on systems that
> use non-US codepage (e.g. russian CP866).
> Codepage would be specified in additional parameter of ZipFile
> constructor, named "codepage".
Le Tue, 15 Oct 2013 22:05:41 +1000,
Nick Coghlan a écrit :
> On 15 October 2013 13:12, Glenn Linderman
> wrote:
> > Of course, if the name were changed to be accurate, or the feature
> > made less prone to misuse, then maybe it would terminate.
>
> I've come to the conclusion it makes sense to
Le Tue, 15 Oct 2013 13:55:47 +0100,
Larry Hastings a écrit :
>
> You can review the existing code here:
>
> https://bitbucket.org/larry/python-clinic/
You didn't create it as a (Bitbucket) fork of CPython, and you didn't
put your changes in a separate branch, so this repo is a bit useless t
On Tue, 15 Oct 2013 15:20:34 +0100
Larry Hastings wrote:
> If you want to struggle through it by hand, read clinic.py (obviously),
> and then search for the string "clinic" in these files:
>
> Modules/_cursesmodule.c
> Modules/_datetimemodule.c
> Modules/_dbmmodule.c
> Modules/po
Le Wed, 16 Oct 2013 00:07:16 -0700,
Raymond Hettinger a écrit :
>
> As Nick said, this thread was just awful. I found it painful to read
> each day. Shoot from the hip comments were given greater weight than
> months of development. Neither Nick nor I were given an ounce of
> respect for the th
Le Wed, 16 Oct 2013 13:42:34 +0200,
Victor Stinner a écrit :
> I might agree with idea of contextlib.ignore() (I'm still opposed to
> the idea), but I don't understand the purpose of adding a new syntax
> doing exactly the same than try/except:
>
> > with trap(OSError) as cm:
> > os.u
Le Wed, 16 Oct 2013 14:01:37 +0200,
Victor Stinner a écrit :
> 2013/10/16 Antoine Pitrou :
> >> By the way, what are the performances of contextlib.ignore()?
> >> Exceptions can be slow in some cases. Adding something even slower
> >> would not be a good idea.
> &
Le Wed, 16 Oct 2013 14:09:16 +0200,
Antoine Pitrou a écrit :
> Le Wed, 16 Oct 2013 14:01:37 +0200,
> Victor Stinner a écrit :
> > 2013/10/16 Antoine Pitrou :
> > >> By the way, what are the performances of contextlib.ignore()?
> > >> Exceptions can be slow
Le Wed, 16 Oct 2013 08:31:44 -0600,
Eric Snow a écrit :
>
> You make several good points, Victor. However, in this case the
> change is a new function and a small, innocuous one at that. That is
> not enough justification alone, as Antoine pointed out, but the
> module's maintainer made a decis
On Wed, 16 Oct 2013 21:30:52 -0400
Terry Reedy wrote:
> On 10/16/2013 5:01 PM, Peter Portante wrote:
> > Hello,
> >
> > Is there a reason why the stdlib socket module _fileobject.flush()
> > method is using ._rbufsize instead of ._wbufsize at line 297 (Python
> > 2.7.3), where it determines the b
On Thu, 17 Oct 2013 15:22:03 +0200 (CEST)
nick.coghlan wrote:
>
> +.. c:function:: int Py_SetStandardStreamEncoding(char *encoding, char
> *errors)
> +
> + .. index::
> + single: Py_Initialize()
> + single: main()
> + triple: stdin; stdout; sdterr
> +
> + This function should
On Thu, 17 Oct 2013 15:33:02 +0200 (CEST)
richard.oudkerk wrote:
> http://hg.python.org/cpython/rev/9558e9360afc
> changeset: 86401:9558e9360afc
> parent: 86399:9cd88b39ef62
> user:Richard Oudkerk
> date:Thu Oct 17 14:24:06 2013 +0100
> summary:
> Try doing a raw test of
On Thu, 17 Oct 2013 08:52:42 -0700
Ethan Furman wrote:
> On 10/17/2013 08:29 AM, Benjamin Peterson wrote:
> > 2013/10/17 Ethan Furman :
> >> Good day!
> >>
> >> What is the effect of assigning a bug tracker issue to docs@python?
> >
> > The assignee field is set to d...@python.org.
> >
> > In othe
Le Fri, 18 Oct 2013 20:16:03 +1000,
Nick Coghlan a écrit :
> >
> > Also, shouldn't it be excluded from the stable/limited API?
>
> Since it didn't expose any struct layouts, I just followed the
> precedent set by the other PySet_* APIs on that front. Moving it
> would be fine, too, though, since
Is anyone looking into those leaks?
I suspect they might have to do with Serhiy's latest re changes in
add40e9f7cbe.
(just a barely educated guess, though)
Regards
Antoine.
On Fri, 18 Oct 2013 09:31:49 +0200
solip...@pitrou.net wrote:
> results for 30f33e6a04c1 on branch "default"
> -
On Sun, 28 Aug 2016 22:40:11 +0200
Christian Heimes wrote:
>
> Here is the deal for 2.7 to 3.5:
>
> 1) All versions older than 0.9.8 are completely out-of-scope and no
> longer supported.
>
> 2) 0.9.8 is semi-support. Python will still compile and work with 0.9.8.
> However we do NOT promise th
On Mon, 29 Aug 2016 21:38:19 +
Brett Cannon wrote:
> For quick background for those that don't remember, part of PEP 523
> proposed adding a co_extra field to code objects along with making the
> frame evaluation function pluggable (
> https://www.python.org/dev/peps/pep-0523/#expanding-pycode
On Tue, 30 Aug 2016 17:14:31 +
Brett Cannon wrote:
>
> Depends on what vmprof chooses to do. Since the data is designed to be
> disposable it could decide it should always take precedence and overwrite
> the data if someone beat it to using the field. Basically I don't think we
> want co_extr
On Tue, 30 Aug 2016 17:35:35 +
Brett Cannon wrote:
> >
> > Perhaps a list would work indeed. Realistically, if there are at most
> > 2-3 users of the field at any given time (and most probably only one or
> > zero), a simple type check (by pointer equality) on each list item may
> > be suffic
On Tue, 30 Aug 2016 18:12:01 +
Brett Cannon wrote:
> > Why not make it always a list? List objects are reasonably cheap in
> > memory and access time... (unlike dicts)
>
> Because I would prefer to avoid any form of unnecessary performance
> overhead for the common case.
But the performance
On Wed, 31 Aug 2016 10:31:12 +0200
"M.-A. Lemburg" wrote:
>
> I am thinking of Python users out there who are running on LTS
> OS releases simply because their IT doesn't let them run anything
> else.
There is a solution nowadays, which is to use Anaconda (or Miniconda).
Regards
Antoine.
___
Le 31/08/2016 à 11:33, M.-A. Lemburg a écrit :
> On 31.08.2016 10:43, Antoine Pitrou wrote:
>> On Wed, 31 Aug 2016 10:31:12 +0200
>> "M.-A. Lemburg" wrote:
>>>
>>> I am thinking of Python users out there who are running on LTS
>>> OS releases s
On Wed, 7 Sep 2016 11:53:14 -0700
Guido van Rossum wrote:
> W00t! I will have to rewrite my brain. :-)
... Is your brain coded in C89?
>
> On Wed, Sep 7, 2016 at 11:07 AM, Victor Stinner
> wrote:
> > 2016-09-07 10:56 GMT-07:00 Benjamin Peterson :
> >> To conclude our discussion about using
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 somewhere
> > after 3.6b1 but before 3.6rc1: the order is not preserved when you
> > delete some keys and then add some other keys.
On Fri, 9 Sep 2016 14:01:08 -0500
David Mertz wrote:
> It seems unlikely, but not inconceivable, that someday in the future
> someone will implement a dictionary that is faster than current versions
> but at the cost of losing inherent ordering.
I agree with this. Since ordering is a constraint,
On Sat, 10 Sep 2016 16:22:57 +0200
Christian Heimes wrote:
>
> For 3.6 I like to make the SSL more sane and more secure by default.
> Yes, I'm a bit late but all my proposals are implemented, documented,
> partly tested and existing tests are passing.
I don't have time nor motivation to review
On Sun, 11 Sep 2016 04:37:58 -0400
Victor Stinner wrote:
>
> For Python 3.7, I propose that we move all these private functions in
> separated header files, maybe Include/private/ or Include/core/, and
> not export them as part of the "regular API".
-1 from me. There are reasons to rely on priv
On Sat, 10 Sep 2016 20:23:13 +0200
Christian Heimes wrote:
>
> It's a bit too clever and tricky for my taste. I prefer 'explicit is
> better than implicit' for trust anchors. My main concern are secure
> default settings. A SSLContext should be secure w/o further settings in
> order to prevent de
On Thu, 15 Sep 2016 10:57:07 +0200
Victor Stinner wrote:
>
> > Both Python is built without neither `--with-optimizations` or `make
> > profile-opt`.
>
> That's bad :-) For most reliable benchmarks, it's better to use
> LTO+PGO compilation.
That sounds irrelevant. LTO+PGO improves performance
On Thu, 15 Sep 2016 07:08:50 -0600
Eric Snow wrote:
> On Sep 15, 2016 06:06, "Serhiy Storchaka" wrote:
> > Python 3.5: 10 loops, best of 3: 33.5 msec per loop
> > Python 3.6: 10 loops, best of 3: 37.5 msec per loop
> >
> > These results look surprisingly and inexplicably to me. I expected that
On Thu, 15 Sep 2016 08:02:10 -0700
Raymond Hettinger wrote:
>
> Eric is correct on this one. The consecutive hashes make a huge difference
> for Python 3.5. While there is a table full table scan, the check for NULL
> entries becomes a predictable branch when all the keys are in consecutive
On Thu, 15 Sep 2016 18:13:54 +0200
Antoine Pitrou wrote:
>
> This also shows that a micro-benchmark that merely looks ok can actually
> be a terrible proxy of actual performance.
... unless all your dicts have their key objects nicely arranged
sequentially in heap memory, of course.
On Wed, 12 Oct 2016 14:14:48 -0700
Nathaniel Smith wrote:
>
> The proposal is that it should be documented as being part of the
> language spec starting in 3.4 (or whatever). So applications that
> support Python 2.7 can't rely on it, sure. But if I have an
> application that requires, say, 3.5+
Hi Victor,
On Fri, 4 Nov 2016 13:53:10 +0100
Victor Stinner wrote:
>
> Raw results of Python 3.6 compared to Python 2.7:
That's interesting, but I would be personally more interested in
a performance comparison of 3.5 and 3.6, to know if anything
interesting (or worrying :-)) has happened ther
On Tue, 22 Nov 2016 12:52:59 +0100
Stefan Scherfke wrote:
> Hi all,
>
> I am trying to build a custom Conda installer for Python 3.6.0b4.
>
> I could successfully build an run Python. However, when I run
> the generated Conda installer, it dies with a "Bus error".
>
> It happens when Conda's m
On Tue, 29 Nov 2016 23:07:14 -0800
Benjamin Peterson wrote:
> Okay, now that we're heard from the other side, and I lacking a concrete
> reason to delay the release, I'm putting 2.7.13 back at the original
> dates.
Serhiy may be thinking about https://bugs.python.org/issue28427
Regards
Antoine.
On Wed, 30 Nov 2016 22:58:01 -0800
Benjamin Peterson wrote:
> On Wed, Nov 30, 2016, at 10:19, Antoine Pitrou wrote:
> > On Tue, 29 Nov 2016 23:07:14 -0800
> > Benjamin Peterson wrote:
> > > Okay, now that we're heard from the other side, and I lacking a concr
On Thu, 15 Dec 2016 11:22:10 +0100
Victor Stinner wrote:
>
> Before:
> https://hg.python.org/cpython/file/f692dafe6797/Include/abstract.h
>
> Now:
> https://hg.python.org/cpython/file/c4bcca326c0a/Include/abstract.h
Since you are cleaning up, you could remove the whole "PROPOSAL: A
Generic Pyth
On Thu, 5 Jan 2017 20:28:26 -0500
Yury Selivanov wrote:
> On 2017-01-05 7:11 PM, INADA Naoki wrote:
> >> bytes.frombuffer(x) is bytes(memoryview(x)) or memoryview(x).tobytes().
> >>
> > There is pitfall: memoryview should be closed.
> > So b = bytes.frombuffer(x) is:
> >
> > with memoryview(x) a
On Wed, 18 Jan 2017 08:44:29 +0100
Victor Stinner wrote:
>
> My patch adds Py_TPFLAGS_HAVE_FINALIZE and Py_TPFLAGS_HAVE_FASTCALL to
> Py_TPFLAGS_DEFAULT. So all modules compiled with Python 3.7 will
> announce that they have tp_finalize and tp_fastcall fields, even if
> they are NULL. I don't kno
On Fri, 20 Jan 2017 19:49:01 +0900
INADA Naoki wrote:
>
> Report is here
> https://gist.github.com/methane/ce723adb9a4d32d32dc7525b738d3c31
"this script counts static memory usage. It doesn’t care about dynamic
memory usage of processing real request"
You may be trying to optimize something whi
On Fri, 20 Jan 2017 13:40:14 +0100
Christian Heimes wrote:
>
> IIRC Thomas Wouters (?) has been working on a patch to move the ref
> counter out of the PyObject struct and into a dedicated memory area. He
> proposed the idea to improve cache affinity, reduce cache evictions and
> to make CoW more
On Fri, 20 Jan 2017 22:30:16 +0900
INADA Naoki wrote:
> >
> > Moving the refcount out of the PyObject will probably make increfs /
> > decrefs more costly, and there are a lot of them. We'd have to see
> > actual measurements if a patch is written, but my intuition is that the
> > net result won'
On Tue, 24 Jan 2017 10:21:45 -0800
Nathaniel Smith wrote:
>
> The thing I found most surprising about that blog post was that contrary to
> common wisdom, refcnt updates per se had essentially no effect on the
> amount of memory shared between CoW processes, and the problems were all
> due to the
On Wed, 25 Jan 2017 20:54:02 +0900
INADA Naoki wrote:
>
> ## Stripped annotation + without pydebug
Does this mean the other measurements were done with pydebug enabled?
pydebug is not meant to be used on production systems so, without
wanting to disparage the effort this went into these measurem
On Sat, 28 Jan 2017 12:07:05 -0500
Barry Warsaw wrote:
> On Jan 28, 2017, at 03:43 PM, Nick Coghlan wrote:
>
> >I still think it could be a good candidate for a first "bundled"
> >module, where we don't migrate it fully into the CPython development
> >process, but *do* officially bless it and pro
On Sun, 29 Jan 2017 20:30:38 +
Steve Holden wrote:
> Why not declare re deprecated and remove it in Python 4?
Why deprecate and remove a library that's perfectly usable and
satisfactory for the vast majority of regular expression usage? It's
not like regex presents a radically different API.
On Wed, 1 Feb 2017 03:23:02 -0500
Philippe Proulx wrote:
>
> It feels like `bread` is never deleted in the module initialization
> situation, but I don't know why: the only reference to the Bread Python
> object is this `bread` name in the module... what could prevent this
> object's __del__() me
On Fri, 10 Feb 2017 16:15:46 -0500
Terry Reedy wrote:
> Today I have been getting the following for about 1/3 of access
> attempts (with Firefox).
> '''
> Secure Connection Failed
>
> An error occurred during a connection to bugs.python.org. A PKCS #11
> module returned CKR_DEVICE_ERROR, indi
Hi Victor,
On Wed, 22 Feb 2017 13:10:17 +0100
Victor Stinner wrote:
>
> IMHO a reference in this domain is PHP: PHP documentation is
> translated to at least 10 languages. See for example the "Change
> language: [...]" list at:
>
>http://php.net/echo
>
> I'm not asking you to take any tec
On Thu, 23 Feb 2017 23:51:45 -0800
Benjamin Peterson wrote:
>
> Like all CPython developers, the Python security team are all
> volunteers. That combined with the fact that dealing with security
> issues is one of the least fun programming tasks means issues are
> sometimes dropped.
>
> Perhaps
On Fri, 24 Feb 2017 19:55:20 +1000
Nick Coghlan wrote:
>
> On the procedural front, the main open question is whether or not Guido
> wants to review and approve this PEP himself, or if he'd prefer to delegate
> that task.
>
> Assuming the latter case, I think it may make sense for Christian to h
On Wed, 1 Mar 2017 12:28:24 -0500
Barry Warsaw wrote:
>
> Louis (Cc'd here) has done a ton of work to measure and analyze the problem,
> but we've more or less hit a roadblock, so we're taking the issue public to
> see if anybody on this mailing list has further ideas. A detailed analysis is
> a
On Wed, 1 Mar 2017 19:58:14 +0100
Matthias Klose wrote:
> On 01.03.2017 18:51, Antoine Pitrou wrote:
> > As for the high level: what if the training set used for PGO in Xenial
> > has become skewed or inadequate?
>
> running the testsuite
I did some tests a year or two
On Wed, 1 Mar 2017 20:24:03 +0100
Louis Bouchard wrote:
>
> Indeed, this is something that is in the history of the LP bug so here is the
> URL where those comparison can be found :
>
> https://docs.google.com/spreadsheets/d/1MyNBPVZlBeic1OLqVKe_bcPk2deO_pQs9trIfOFefM0/edit#gid=2034603487
Some
On Mon, 20 Mar 2017 13:26:34 +0200
Serhiy Storchaka wrote:
> What is the preferable way of getting the size of tuple, list, bytes,
> bytearray: Py_SIZE or PyTuple_GET_SIZE, PyList_GET_SIZE,
> PyBytes_GET_SIZE, PyByteArray_GET_SIZE? Are macros for concrete types
> more preferable or they are out
1701 - 1800 of 4909 matches
Mail list logo
