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
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
> 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 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
> 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
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
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
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
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
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
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 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
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
(
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
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
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
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
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
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
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
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 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
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 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"
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
25 matches
Mail list logo
