On 12/13/2017 10:56 PM, Victor Stinner wrote:
> I looked at your scripts to build Android but I failed to use them.
You failed because you did not read the README and tried to improvise. I will change the documentation and the build process to make it simpler for those that do not have the time t
On Thu, 14 Dec 2017 17:00:10 +1000
Nick Coghlan wrote:
> On 14 Dec. 2017 9:19 am, "Antoine Pitrou" wrote:
>
>
> Hello,
>
> After debugging a crash on AppVeyor for a submitter's PR
> (see https://github.com/python/cpython/pull/4611 ), I came to the
> following diagnosis: converting the "atexit"
Hello,
After noticing that many issues were opened for it and it was lacking
maintenance, I contacted the sqlite3 module's historical author and
maintainer, Gerhard Häring (for the record, Gerhard didn't make any
changes to the sqlite3 module since 2011... and the Python 2-only,
third-party "pysq
On 12/14/2017 12:00 PM, Antoine Pitrou wrote:
On Thu, 14 Dec 2017 17:00:10 +1000
Nick Coghlan wrote:
On 14 Dec. 2017 9:19 am, "Antoine Pitrou" wrote:
Hello,
After debugging a crash on AppVeyor for a submitter's PR
(see https://github.com/python/cpython/pull/4611 ), I came to the
following d
2017-12-14 10:26 GMT+01:00 Xavier de Gaye :
> The 'Mac' build system has its own subdirectory in the source tree and it
> makes sense as it is the reference build system for this platform. I do not
> see why this should be different for Android.
Hum, Mac/ is mostly the recipe to build the installe
On Thu, 14 Dec 2017 15:05:02 +0100
Petr Viktorin wrote:
>
> PEP 489 gives you good defaults, if you use it and avoid global state
> (roughly: C-level mutable static variables), then you should get
> multi-interpreter support for free in simple cases.
> It's also possible to use PyModule_GetStat
Hi,
Serhiy Storchaka seems to be worried by the high numbers of commits in
https://bugs.python.org/issue32030 "PEP 432: Rewrite Py_Main()", so
let me explain the context of this work :-)
To prepare CPython to implement my UTF-8 Mode PEP (PEP 540), I worked
on the implementation of Nick Coghlan's
Currently, we have the following configuration options:
typedef struct {
int ignore_environment; /* -E */
int use_hash_seed; /* PYTHONHASHSEED=x */
unsigned long hash_seed;
int _disable_importlib; /* Needed by freeze_importlib */
const char *allocator; /* Memory allocator
SGTM. It's one of my favorite stdlib modules wrapping an external library
-- I use it for a variety of tasks to which it is well-suited. Go Berker!
On Thu, Dec 14, 2017 at 4:42 AM, Antoine Pitrou wrote:
>
> Hello,
>
> After noticing that many issues were opened for it and it was lacking
> mainte
On 12/14/2017 10:16 AM, Victor Stinner wrote:
Hi,
Serhiy Storchaka seems to be worried by the high numbers of commits in
https://bugs.python.org/issue32030 "PEP 432: Rewrite Py_Main()", so
let me explain the context of this work :-)
You could have (and still could) made that a master issue wit
2017-12-14 22:54 GMT+01:00 Terry Reedy :
> You could have (and still could) made that a master issue with multiple
> dependencies. Last summer, I merged at least 20 patches for one idlelib
> file. I split them up among 1 master issue and about 6 dependency issues.
> That was essential because mos
Ivan, Guido,
Would it be possible to add a slot so that types defined in C can
implement __class_getitem__?
static PyClassMethodDef class_methods = {
foo_class_getitem /* cm_class_getitem */
}
static PyTypeObject Foo = {
.tp_class_methods = class_methods
}
Yury
On Mon, Dec 4, 2017
A slot is pretty expensive, as *every* class in existence will be another 8
bytes larger (and possibly more due to malloc rounding). So unless we find
that there's a significant performance benefit I think we should hold back
on this. IIRC Ivan has already measured an order of magnitude's speedup
(
On Thu, Dec 14, 2017 at 7:03 PM, Guido van Rossum wrote:
> A slot is pretty expensive, as *every* class in existence will be another 8
> bytes larger (and possibly more due to malloc rounding). So unless we find
> that there's a significant performance benefit I think we should hold back
> on this
On Thu, 14 Dec 2017 16:03:48 -0800
Guido van Rossum wrote:
> A slot is pretty expensive, as *every* class in existence will be another 8
> bytes larger (and possibly more due to malloc rounding).
I'm always surprised by the discussions about class object size.
Even imagining you have 1 classe
On Thu, Dec 14, 2017 at 4:29 PM Yury Selivanov
wrote:
> On Thu, Dec 14, 2017 at 7:03 PM, Guido van Rossum
> wrote:
> My motivation to add the slot wasn't the performance: it's just not
> possible to have a class-level __getitem__ on types defined in C. The
> only way is to define a base class in
In the light of Antoine's and Stephan's feedback I think this can be
reconsidered -- while I want to take a cautious stance about resource
consumption I don't want to stand in the way of progress.
On Thu, Dec 14, 2017 at 4:36 PM, Stephan Hoyer wrote:
> On Thu, Dec 14, 2017 at 4:29 PM Yury Seliva
Hi, folks.
TLDR, was the final decision made already?
If "dict keeps insertion order" is not language spec and we
continue to recommend people to use OrderedDict to keep
order, I want to optimize OrderedDict for creation/iteration
and memory usage. (See https://bugs.python.org/issue31265#msg3019
I'm in favor of stating that dict keeps order as part of the language spec.
However re-reading
https://mail.python.org/pipermail/python-dev/2017-November/150381.html
there's still a point of debate: should it be allowed if dict reorders
after deletion (presumably as a result of a rehash)? I'm in f
Oh, I just found
https://mail.python.org/pipermail/python-dev/2017-November/150323.html so I
already know what you think: we should go with "dicts preserve insertion
order" rather than "dicts preserve insertion order until the first
deletion". I guess we should wait for Serhiy to confirm that he's
> On Dec 14, 2017, at 6:03 PM, INADA Naoki wrote:
>
> If "dict keeps insertion order" is not language spec and we
> continue to recommend people to use OrderedDict to keep
> order, I want to optimize OrderedDict for creation/iteration
> and memory usage. (See https://bugs.python.org/issue31265
On Dec 14, 2017 21:30, "Raymond Hettinger"
wrote:
> On Dec 14, 2017, at 6:03 PM, INADA Naoki wrote:
>
> If "dict keeps insertion order" is not language spec and we
> continue to recommend people to use OrderedDict to keep
> order, I want to optimize OrderedDict for creation/iteration
> and mem
> I support having regular dicts maintain insertion order but am opposed to
> Inada changing the implementation of collections.OrderedDict We can have
> the first without having the second.
>
> It seems like the two quoted paragraphs are in vociferous agreement.
The referenced tracker entry
On Thu, Dec 14, 2017 at 9:00 PM, Guido van Rossum wrote:
> In the light of Antoine's and Stephan's feedback I think this can be
> reconsidered -- while I want to take a cautious stance about resource
> consumption I don't want to stand in the way of progress.
I've created an issue to discuss this
15.12.17 02:25, Yury Selivanov пише:
My motivation to add the slot wasn't the performance: it's just not
possible to have a class-level __getitem__ on types defined in C. The
only way is to define a base class in C and then extend it in
pure-Python. This isn't too hard usually, though.
What ar
25 matches
Mail list logo
