I just noticed a failure on a recent Windows build:
http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/11620/steps/test/logs/stdio
"urllib.error.URLError: "
So I guess that the change is to restrict the unit test on parsing the
robot failed and not test the SSL module.
Am I righ
2016-09-12 13:50 GMT+02:00 Antoine Pitrou :
> Besides, I don't think it has been proven that the compact-and-ordered
> dict implementation is actually *faster* than the legacy one.
Python 3.6 dict is slower than Python 3.5 dict, at least for a simple lookup:
http://bugs.python.org/issue27350#msg27
2016-09-12 18:35 GMT+02:00 Guido van Rossum :
> Couldn't we use the order in the actual hash table (which IIUC now
> contains just indexes into the ordered vector of key/value/hash
> structs)? That would probably simulate the pre-3.6 order quite
> effectively.
>From what I understood, Python 3.6 d
Ok, it's start listing regressions/major issues :-)
* Bug in _PyDict_Pop() on a splitted table:
http://bugs.python.org/issue28120 -- bug in the new compact dict
implementation
Victor
2016-09-13 1:35 GMT+02:00 Ned Deily :
> On behalf of the Python development community and the Python 3.6 release
2016-09-15 8:31 GMT+02:00 Serhiy Storchaka :
> Note that this is made at the expense of the 20% slowing down an iteration.
>
> $ ./python -m timeit -s "d = dict.fromkeys(range(10**6))" -- "list(d)"
> Python 3.5: 66.1 msec per loop
> Python 3.6: 82.5 msec per loop
>
> Fortunately the cost of the loo
2016-09-15 10:02 GMT+02:00 INADA Naoki :
> In my environ:
>
> ~/local/python-master/bin/python3 -m timeit -s "d =
> dict.fromkeys(range(10**6))" 'list(d)'
Stop! Please stop using timeit, it's lying!
* You must not use the minimum but average or median
* You must run a microbenchmark in multip
2016-09-15 11:29 GMT+02:00 Antoine Pitrou :
> That sounds irrelevant. LTO+PGO improves performance, it does
> nothing for benchmarking per se.
In the past, I had bad surprised when running benchmarks without PGO:
https://haypo.github.io/journey-to-stable-benchmark-deadcode.html
I don't recall if
The discussion on benchmarking is no more related to compact dict, so
I start a new thread.
2016-09-15 13:27 GMT+02:00 Paul Moore :
> Just as a side point, perf provided essentially identical results but
> took 2 minutes as opposed to 8 seconds for timeit to do so. I
> understand why perf is bett
2016-09-15 21:33 GMT+02:00 Victor Stinner :
> perf takes ~60 seconds by default. If you don't care of the accuracy,
> use --fast and it now only takes 20 seconds ;-)
Oops, I'm wrong. By default, a "single dot" (one worker process) takes
less 1 second, so 20 dots (d
2016-09-13 18:36 GMT+02:00 Victor Stinner :
> Ok, it's start listing regressions/major issues :-)
>
> * Bug in _PyDict_Pop() on a splitted table:
> http://bugs.python.org/issue28120 -- bug in the new compact dict
> implementation
A new one: a crash in os.execve() an
I see that the old macro is now an alias to va_copy(). A similar change was
done for Py_MEMCPY(). Would it make sense to put these old macros in a new
backward_compat.h header, so maybe one day we can remove them? :-)
Maybe we need at least a comment mentionning when (python version) the
macro bec
2016-09-20 21:01 GMT+02:00 Maciej Fijalkowski :
> How about we just make timeit show average and not disable the GC then
> (two of the complaints that will not change the execution time)?
Thanks for the reminder.
The first part of my plan was to write a new module to experiment
changes. This part
2016-09-22 8:02 GMT+02:00 Benjamin Peterson :
> Just dump the compat macros in Python 4.0 I think.
Please don't. Python 3 was so painful because we decided to make
millions of tiny backward incompatible changes. To have a smooth
Python 4.0 release, we should only remove things which were already
d
2016-09-23 8:47 GMT+02:00 Benjamin Peterson :
> I'm being flippant here because of the triviality of the change. Anyone
> using Py_VA_COPY or Py_MEMCPY can fix their code in a backwards and
> forwards compatible manner in 7 seconds with a sed command.
Python 3 had the same argument with 2to3: run
2016-09-23 9:03 GMT+02:00 Chris Angelico :
> In fact, this kind of thing would be perfect for Python 4.0 - it's
> technically backward incompatible (thus justifying the 4.0 number),
> but removes only things that have been deprecated for some time, and
> have simple and direct translations.
Sorry,
Hi,
My question is simple: do we officially support Solaris and/or OpenIndiana?
Jesus Cea runs an OpenIndiana buildbot slave:
http://buildbot.python.org/all/buildslaves/cea-indiana-x86
"Open Indiana 32 bits"
The platform module of Python says "Solaris-2.11", I don't know the
exact OpenIndiana ve
Hi,
Can someone please review the patch attached to:
http://bugs.python.org/issue26617
The patch seems safe and well defined, but it would be nice to have
more reviews on it.
It's a crash (assertion error) in Python >= 3.4 which occurs
"sometimes" in asyncio.
Victor
2016-10-03 15:37 GMT+02:00 Skip Montanaro :
> While starting to port the Python Sybase module to Python 3, among other
> hurdles, I noticed that RO is no longer defined. Looking in structmember.h,
RO was an alias to READONLY. READONLY still exists in Python 3, just
use this name.
You might create
2016-10-12 11:34 GMT+02:00 INADA Naoki :
> I see. My proposal should be another PEP (if PEP is required).
I don't think that adding a single method deserves its own method.
I like the idea with Serhiy's API (as Python 2 buffer constructor):
bytes.frombuf(buffer, [offset, size])
bytearray.frombu
2016-10-12 10:01 GMT+02:00 Nathaniel Smith :
> It's more complicated than that -- the right algorithm is the one that
> Antoine implemented in 3.4.
> (...)
> My point is that
> forcing everyone who writes network code in Python to do that is
> silly, especially given that CPython's apparently been
Oops, right, I wanted to write "I don't think that adding a single
method deserves its own PEP."
Victor
2016-10-12 18:37 GMT+02:00 Stephen J. Turnbull
:
> Victor Stinner writes:
> > 2016-10-12 11:34 GMT+02:00 INADA Naoki :
>
> > > I see. My proposal shoul
Hi,
Last months, I worked a lot on benchmarks. I ran benchmarks, analyzed
results in depth (up to the hardware and kernel drivers!), I wrote new
tools and enhanced existing tools.
* I wrote a new perf module which runs benchmarks in a reliable way
and contains a LOT of features: collect metadata,
Are you on the 2.7 branch or the default branch?
You might try to cleanup your checkout:
hg up -C -r 2.7
make distclean
hg purge # WARNING! it removes *all* files not tracked by Mercurial
./configure && make
You should also paste the full error message.
Victor
2016-10-20 13:47 GMT+02:00 Skip M
Hi,
I removed all old benchmarks results and I started to run manually
benchmarks. The timeline view is interesting to investigate
performance regression:
https://speed.python.org/timeline/#/?exe=3&ben=grid&env=1&revs=50&equid=off&quarts=on&extr=on
For example, it seems like call_method became sl
Hi,
2016-11-01 22:56 GMT+01:00 Rasmus Villemoes :
> I'm using (and contributing to) an application which spends a
> significant part of its startup time calling copy.deepcopy, so I thought
> I'd try to write a C extension to speed this up.
Maybe you should consider another option: using copy.dpee
(Re-post without the two attached files of 100 KB each.)
Hi,
You may know that I'm working on benchmarks. I regenerated all
benchmark results of speed.python.org using performance 0.3.2
(benchmark suite). I started to analyze results.
All results are available online on the website:
https://
ner/status/794525289623719937
Victor
2016-11-04 13:53 GMT+01:00 Victor Stinner :
> (Re-post without the two attached files of 100 KB each.)
>
> Hi,
>
> You may know that I'm working on benchmarks. I regenerated all
> benchmark results of speed.python.org using performance 0.3.2
2016-11-04 20:18 GMT+01:00 Miquel Torres :
> Nice! For the record, I'll be giving a talk in PyCon Ireland about
> Codespeed. Would you mind me citing those tweets and screenshots, to
> highlight usage on speed.python.org?
Sure. Keep me in touch in you publish your slides later.
> You mentioned n
2016-11-07 20:20 GMT+01:00 Guido van Rossum :
> Re:
> https://speed.python.org/timeline/#/?exe=4&ben=python_startup&env=1&revs=50&equid=off&quarts=on&extr=on
>
> That's suspiciously close to the core sprint. Since the -S time stayed
> roughly the same I suspect that either a new module was added to
Hi,
Antoine Pitrou asked me to compare Python 3.6 to Python 3.5. Here are
results on the speed-python server using LTO compilation (but not
PGO):
$ python3 -m perf compare_to 2016-11-03_15-37-3.5-89f7386104e2.json
2016-11-03_15-38-3.6-c4319c0d0131.json -G --min-speed=5
Slower (17):
- call_method_
You are looking for the bug fix http://bugs.python.org/issue4180:
"warnings.simplefilter("always") does not make warnings always show up"
Python 2.7 has a bug, Python 3.4.3+ behaves correctly.
It is surprising that Python 3.4.0 and Python 3.4.3 behaves
differently :-) (Ubuntu 14.04 uses Python 3
Hi,
2016-11-22 8:24 GMT+01:00 Ned Deily :
> OK, all of the release engineering for 3.6.0b4 is complete. The 3.6 branch
> in the cpython repo is now available again but, as noted, *only* for reviewed
> release critical fixes appropriate for the 3.6.0 final and for final 3.6.0
> doc updates!
So
It's not bug but a feature :-) Python doesn't protect yourself against
mistakes :-)
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-
Ok, thank you Raymond for checking.
Victor
Le 23 nov. 2016 05:25, "Raymond Hettinger" a
écrit :
>
> > On Nov 22, 2016, at 6:57 AM, Victor Stinner
> wrote:
> >
> > Should I revert these changes?
>
> I don't think reverting any of these would i
Hi,
I proposed a patch to drop the CALL_PROFILE special build to simplify
Python/ceval.c:
http://bugs.python.org/issue28799
I modified ceval.c for fast calls in Python 3.6, and I'm not sure that
the feature still works correctly. The feature is not well documented
and not tested at all.
For fast
> On Sat, Nov 26, 2016 at 3:34 AM Raymond Hettinger
> wrote:
>>
>>
>> > On Nov 25, 2016, at 1:28 AM, Victor Stinner
>> > wrote:
>> >
>> > I would like to completely remove the feature to be able to implement
>> > further opti
2016-11-30 10:01 GMT+01:00 Serhiy Storchaka :
>> Uniformize argument names of "call" functions
>>
>> * Callable object: callable, o, callable_object => func
>> * Object for method calls: o => obj
>> * Method name: name or nameid => method
>
> This change looks wrong to me. "callable" and "callabl
I reverted my change and reposted the change as a patch:
http://bugs.python.org/issue28838
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/
Hi,
Can someone please review my patch for the following issue?
"Change in behavior when overriding warnings.showwarning and with
catch_warnings(record=True)"
http://bugs.python.org/issue28835
It would be nice to fix a known regression which has a patch :-)
I added warnings._showwarnmsg() to Pyt
Hi,
The PyObject_CallFunction() function has a special case when the
format string is "O", to pass exactly one Python object:
* If the argument is a tuple, the tuple is unpacked: it behaves like func(*arg)
* Otherwise, it behaves like func(arg)
This case is not documented in the C API !
https://
2016-12-09 18:46 GMT+01:00 Victor Stinner :
> Last days, I patched functions of PyObject_CallFunction() family to
> use internally fast calls.
> (...)
> http://bugs.python.org/issue28915
Oh, I forgot to mention the performance results of these changes.
Python slots are now a littl
Hi,
2016-12-10 7:43 GMT+01:00 Serhiy Storchaka :
> It is documented for Py_BuildValue(), and the documentation of
> PyObject_CallFunction() refers to Py_BuildValue().
You're right, but even if I read the documentation of Py_BuildValue()
every week, I never noticed that PyObject_CallFunction() beh
2016-12-15 10:46 GMT+01:00 Serhiy Storchaka :
> https://docs.python.org/3/c-api/object.html#c.PyObject_CallMethod
>
> Seems online documentation is not updated.
"Last updated on Dec 08, 2016."
Oh, right. No idea what/who compiles the documentation. I expected at
least one build per day?
Someone
2016-12-15 10:54 GMT+01:00 Victor Stinner :
> Oh, right. No idea what/who compiles the documentation. I expected at
> least one build per day?
I am told that it can be related to
https://github.com/python/docsbuild-scripts/pull/7
Victor
___
Pyth
Hi,
I made multiple changes to the Include/abstract.h header file, because
it was inconsistent in different manners:
* Parameter names of functions of the PyObject_Call family were
inconsistent: "func" versus "callable" for a Python callable object
for example (sometimes, .c and .h files were inc
x test_gdb, I convinced Ned to
also cherry-pick:
---
changeset: 105342:752863f96fb8
user:Victor Stinner
date:Tue Nov 22 22:53:18 2016 +0100
files: Lib/test/test_gdb.py Tools/gdb/libpython.py
description:
Issue #28770: Update python-gdb.py for fastcalls
Frame.is_other_python_frame(
2016-12-16 11:24 GMT+01:00 Antoine Pitrou :
> Since you are cleaning up, you could remove the whole "PROPOSAL: A
> Generic Python Object Interface for Python C Modules" introduction,
> which isn't very interesting to read today.
Ah right, I noticed this huge comment but I didn't understand the
pur
2016-12-18 9:31 GMT+01:00 Serhiy Storchaka :
> Originally C API didn't use the const qualifier. Over few last years the
> const qualifier was added to C API if that preserved backward compatibility.
> For example input "char *" parameters were changed to "const char *". This
> makes C API compatibl
2016-12-16 11:24 GMT+01:00 Antoine Pitrou :
> Since you are cleaning up, you could remove the whole "PROPOSAL: A
> Generic Python Object Interface for Python C Modules" introduction,
> which isn't very interesting to read today.
Done: hg.python.org/cpython/rev/3ab0a6692e25
Victor
2016-12-21 2:52 GMT+01:00 Steve Dower :
> _PyBytes_DecodeEscape
> _PyDebug_PrintTotalRefs
> _PyThreadState_Current
> _PyTrash_thread_deposit_object
> _PyTrash_thread_destroy_chain
> _PyUnicode_DecodeUnicodeEscape
> _Py_AddToAllObjects
> _Py_ForgetReference
> _Py_GetRefTotal
> _Py_HashSecret_Initial
2016-12-21 14:06 GMT+01:00 Serhiy Storchaka :
>> These functions are private. Would it be possible to not export them?
>
> Private functions used in public macros (like _Py_NewReference) should be
> exported.
Ah, _Py_NewReference is used in the PyObject_INIT(op, typeobj) *macro*, right.
IMO it's
2016-12-21 17:21 GMT+01:00 Nathaniel Smith :
> It sounds like the opt-out approach isn't working very well, and maybe an
> opt-in approach should be considered instead? I recognize that the way C
> headers work makes this difficult, but it seems like something needs to
> change.
I proposed somethi
Hi,
tl;dr Python 3.7 is going to be faster without breaking backward
compatibility, say hello to the new "tp_fastcall" slot!
=> http://bugs.python.org/issue29259
Python 3.6 got a new "FASTCALL" calling convention which allows to
avoid the creation a temporary tuple to pass positional arguments a
Oh, I found another recent bug fixed because of the "O" weird behaviour:
http://bugs.python.org/issue26478
"dict views don't implement subtraction correctly"
Victor
2016-12-09 18:46 GMT+01:00 Victor Stinner :
> Hi,
>
> The PyObject_CallFunction() function ha
2017-01-18 1:59 GMT+01:00 INADA Naoki :
> I think mixing two forms is OK only if new form is used only at bottom.
> (like keyword arguments are allowed after all positional arguments in
> Python function calling)
>
> Complete rewriting makes diff huge. And there is PyVarObject_HEAD_INIT
> already
2017-01-18 3:28 GMT+01:00 Guido van Rossum :
> I recommend being reluctant to add new fields -- the number of type objects
> is larger than you'd think and these are static bytes which I consider a
> relatively expensive resource.
>
> There's also an ABI issue with new fields -- new fields can only
2017-01-18 12:33 GMT+01:00 Antoine Pitrou :
> I don't think I thought about that idea at the time. tp_finalize
> doesn't benefit many extension types, so it's not a huge burden to add
> a FLAGS value for the few cases where you want to use it.
It isn't obvious to me that I have to define explicit
2017-01-20 11:49 GMT+01:00 INADA Naoki :
> Report is here
> https://gist.github.com/methane/ce723adb9a4d32d32dc7525b738d3c31
Very interesting report, thanks!
> My thoughts are:
>
> * Interning (None,) seems worth enough.
I guess that (None,) comes from constants of code objects:
>>> def f(): pa
Larry Hastings' Gilectomy also moved the reference counter into a
separated memory block, no? (grouping all refcounts into large memory
blocks if I understood correctly.)
https://github.com/larryhastings/gilectomy
Victor
2017-01-20 13:40 GMT+01:00 Christian Heimes :
> On 2017-01-20 13:15, INADA
There is @support.reap_thread which can help.
Victor
Le dim. 22 janv. 2017 à 21:04, Ethan Furman a écrit :
> Question: I need to add a threaded test to the enum test module [1] -- is
> there anything extra I
>
> need to worry about besides the test itself? Setting or resetting or
> using a to
2017-01-23 12:25 GMT+01:00 INADA Naoki :
> I gave advice to use 'List[User]' instead of List[User] to the team of
> the project,
> if the team think RAM usage or boot speed is important.
I would prefer a Python option (ex: "-o noannotation" command line
option) to opt-out annotations rather than h
2017-01-24 15:00 GMT+01:00 INADA Naoki :
> And here are top 3 tracebacks from tracemalloc:
>
> 15109615 (/180598)
> File "", line 488
> File "", line 780
> File "", line 675
> File "", line 655
FYI at Python startup, usually the largest memory block comes from the
dictionary used to intern
Hi,
I noticed a strange issue with Roundup Robot on the issue #29318.
I closed http://bugs.python.org/issue29318 as rejected:
resolution: -> rejected
status: open -> closed
Roundup Robot made a first change:
stage: -> resolved
But then it made a second change:
resolution: rejec
2017-02-01 20:42 GMT+01:00 Lukasz Langa :
> However, this benchmark is incomplete in the sense that it only checks the
> compatibility mode of `regex`, whereas it's the new mode that lends the
> biggest performance gains. So, providing checks for the other engine would
> show us the full picture.
Oh, I noticed another strange thing:
The Roundup Robot closed the issue http://bugs.python.org/issue29368
but I don't see any explicit "Close issue #xxx" or "Close #xxx" in the
commit message of the two commits.
Is it deliberate to close an issue after any commit?
Victor
2017-01-31 19:18 GMT+01
2017-02-01 18:32 GMT+01:00 Victor Stinner :
> To finish with an empty change:
Information on IRC:
Known issue: http://psf.upfronthosting.co.za/roundup/meta/issue611
"Maciej is working on it"
Good & thanks!
Victor
___
Python-Dev ma
2017-02-02 22:24 GMT+01:00 Maciej Szulik :
> Ezio confirmed pushing all the changes to bugs.python.org already.
> I'm very sorry for all the inconvenience caused by previous mistakes. If
> your
> issues was closed make sure to verify it was closed properly and re-open if
> needed.
Don't worry. Bre
(Oops, I wrote privately to Brett, so he replied me in private. So
here is a copy of our emails.)
Brett Cannon via gmail.com
On Tue, 7 Feb 2017 at 13:42 Victor Stinner wrote:
>
> If I push a patch file written by someone else, should I try to use the
> author full name + email?
I&#
2017-02-08 8:35 GMT+01:00 Victor Stinner :
> I'm sure the patch author would appreciate it, but I don't think we
> need to require it as we have gone this long without it.
I know that different people have different expectation on GitHub. I
would like to take the opportunity of
Hi,
Is there anything new about Solaris or OpenIndiana since September?
Right now, it seems like the cea-indiana-x86 buildbot slave is offline
since longer than 54 days.
Oracle decided to stop Solaris 12 development:
https://arstechnica.com/information-technology/2017/01/oracle-sort-of-confirms-d
2017-02-08 21:32 GMT+01:00 Terry Reedy :
> Many patches have multiple authors. Does the 'author' field allow that?
> Often, the committer adds missing chunks or rewrites the work with various
> degrees of editing. Sometimes a read a patch for the idea and then start
> fresh with the actual code.
2017-02-08 23:42 GMT+01:00 Brett Cannon :
> Don't forget we are doing squash merges,
Ah, I didn't know. Why not using merges?
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
2017-02-13 21:08 GMT+01:00 Brett Cannon :
> We now have two sets of labels for representing cherry-picking statuses:
> "backport to N.M" and "cherry-pick for N.M". The former are to help keep
> track of what branches a PR should be cherry-picked to and can be removed
> once the PR for a cherry-pick
2017-02-14 18:43 GMT+01:00 Zachary Ware :
> To propose another color for the bikeshed, what about having labels
> for each branch along with "needs backport" and "cherry-pick" labels?
Oh right, labels have colors. I propose pink for "needs backport" and
yellow for "cherry-pick"!
Just kidding, sor
Hi,
I'm a member of the french #python-fr IRC channel on Freenode: it's
common to meet people who don't speak english and so are unable to
read the Python official documentation. Python wants to be widely
available, for all users, in any language: that's also why Python 3
now allows any non-ASCII
Hi,
As an user, I like Misc/NEWS changelog. I like reading
https://docs.python.org/dev/whatsnew/changelog.html#changelog after a
minor Python release to see all bugfixes.
As a developer, I deeply hate this file :-) It's very painful to:
* find the latest Python version in this giant file
* find
2017-02-22 16:40 GMT+01:00 Antoine Pitrou :
> As long as you are asking for "moral" support and not actually
> vouching for the accuracy of third-party translations, then +1 from me.
The main complain about these translations is the accuracy.
My bet is that making these translations "official" an
2017-02-22 17:42 GMT+01:00 Barry Warsaw :
> Our release notes have different sections:
>
> * Core and Builtins
> * Extension Modules
> * Library
> * Windows
> * C API
> * Documentation
> * Build
> * Tools/Demos
> * Tests
> (others?)
While we are talking about changing things... I would propose to
2017-02-22 19:04 GMT+01:00 Serhiy Storchaka :
> What percent of lines is changed between bugfix releases? Feature releases?
>
> My largest apprehension is that the documentation can be outdated and
> quickly become degraded if main contributors left it.
If the original text (english) changes, untr
Hi,
I created a tool to generate a report on Python vulnerabilities:
http://python-security.readthedocs.io/vulnerabilities.html
I collected data of 41 vulnerabilities since 2007 (first Python CVE:
CVE-2007-4965).
If you would like to add data of a new vulnerability, enhance the
report, ... :
2017-02-22 23:53 GMT+01:00 Serhiy Storchaka :
> Some changes can be related to a couple of modules.
I suggest to repeat either repeat the change in each module section,
or put the change in a general section.
The tool should support a list of modules.
Victor
_
2017-02-24 11:06 GMT+01:00 Nick Coghlan :
> The main idea that comes to mind is finding a way to add a "Fixed In" column
> to the summary table to get a quick overview of which versions were
> affected.
I had this column, just I just removed it before my email to
python-dev because the table was t
This change has zero impact on docs.python.org, it only help teams
working on translation, so go ahead.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mai
Hi,
Recently, I wrote reports of my CPython contributions since 1 year
1/2. Some people on this list might be interested, so here is the
list.
I was also asked for more documentation about my work on FASTCALL and
its effect on performance. You can expect more article on FASTCALL
later, especially
2017-02-25 19:19 GMT+01:00 Brett Cannon :
> It's getting a little hard to tease out what exactly is being asked at this
> point. Perhaps it's time to move the discussion over to a translation SIG
> (which probably needs to be created unless the old
> https://mail.python.org/mailman/listinfo/i18n-si
2017-02-24 13:20 GMT+01:00 Berker Peksağ :
>> If the original text (english) changes, untranslated text is
>> displayed, not outdated text.
>
> I think that's much worse than showing the outdated text. I don't see
> any point on showing half English and half French text if the reader
> can't unders
2017-02-24 16:10 GMT+01:00 Steven D'Aprano :
>> …And then you need another one to
>> check what was written. These are practical problems. There are
>> extant services to support this, they are expensive in either money or
>> time, and the docs produced usually lag behind English quite a bit.
>
>
I suggest to remove them. I didn't use them since python-gdb.py exist.
Does someone still need gdbinit macros for gdb without python binding?
Victor
Le 28 févr. 2017 1:27 AM, "Alexander Belopolsky" <
alexander.belopol...@gmail.com> a écrit :
> I have opened an issue on b.p.o., [1] but I wonder
2017-02-28 3:00 GMT+01:00 Skip Montanaro :
> Alexander> I find them useful. I've never had success with python-gdb.py.
Alexander, Skip: Oh, which kind of issues do you have with
python-gdb.py? It doesn't work? You are unable to dump some data?
python-gdb.py doesn't run code to analyze memory, it
Ok, it seems like very few people know how to use python-gdb.py :-/
Sorry, I expect that everybody was using it!
python-gdb.py was written by Dave Malcolm, it includes:
* a pretty printer for many builtin Python types: str, tuple, list,
dict, frame, etc. It means that a regular gdb "print obj" co
2017-02-28 20:38 GMT+01:00 Alexander Belopolsky
:
> First, I had to rename python-gdb.py to python3.6-gdb.py to make it load.
There is nothing specific to Python here, the file command of gdb (or
gdb file) tries to load "file-gdb.py". So if your program is called
python3.6, gdb looks for python3.6
Please don't put code using asyncio in Python stdlib yet. The Python
language is still changing rapidly to get new async features
(async/await keywords, async generators, etc.), and asyncio also
evolved quickly.
I suggest to create 3rd party modules on PyPI. It became easy to pull
dependencies usi
Hi,
Your document doesn't explain how you configured the host to run
benchmarks. Maybe you didn't tune Linux or anything else? Be careful
with modern hardware which can make funny (or not) surprises. See my
recent talk at FOSDEM (last month):
"How to run a stable benchmark"
https://fosdem.org/201
2017-03-03 8:27 GMT+01:00 Nick Coghlan :
> Victor, do you know if you or anyone else has compared the RHEL/CentOS 7.x
> binaries (Python 2.7.5 + patches, built with GCC 4.8.x) with the Fedora 25
> binaries (Python 2.7.13 + patches, built with GCC 6.3.x)?
I didn't and I'm not aware of anyone who di
2017-03-03 12:18 GMT+01:00 Charalampos Stratakis :
> PGO is not enabled in RHEL and Fedora.
>
> I did some initial testing for Fedora, however it increased the compilation
> time of the RPM by approximately two hours, so for the time being I left it
> out.
Two hours in a *single* build server is
> Out of curiosity, I ran the set of benchmarks in two LXC containers running
> centos7 (2.7.5 + gcc 4.8.5) and Fedora 25 (2.7.13 + gcc 6.3.x). The benchmarks
> do run faster in 18 benchmarks, slower on 12 and insignificant for the rest
> (~33
> from memory).
"faster" or "slower" is relative: I w
Le 5 mars 2017 19:14, "Senthil Kumaran" a écrit :
On Fri, Feb 24, 2017 at 3:50 PM, Victor Stinner
wrote:
> Recently, I wrote reports of my CPython contributions since 1 year
> 1/2. Some people on this list might be interested, so here is the
> list.
They are prolific!
Thank
2017-03-10 0:35 GMT+01:00 Ned Deily :
> I don't know exactly what you mean by an "official GO" but I don't think
> there has been any agreement yet since there hasn't been a specific proposal
> yet to review. I think what *was* agreed is that, in principle, translation
> *sounds* like a good id
gt; and other in dictobject.c (still not fixed). If prefer using concrete type
> macros this would unlikely happen.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Un
2017-03-10 1:03 GMT+01:00 Victor Stinner :
> FYI we are already working on a PEP with Julien Palard (FR) and INADA
> Naoki (JP). We will post it when it will be ready ;-)
Ok, Julien wrote the PEP with the help of Naoki and myself. He posted
it on python-ideas for a first review:
1601 - 1700 of 3215 matches
Mail list logo
