PyObject *tmp;
Py_identifier(update);
As I understand it, the macro expands to both the ID variable
declaration and the init-at-first-call code, right?
No. The variable will only get static initialization with the
char*. The initialization on first call (of the PyObject*) happens
in the
Le 14/10/2011 07:44, Georg Brandl a écrit :
Am 14.10.2011 00:30, schrieb Victor Stinner:
Le jeudi 13 octobre 2011 03:34:00, Victor Stinner a écrit :
We would need a new format for Py_BuildValue, e.g. 'a' for ASCII string.
Later we can add new functions like _PyDict_GetASCII().
The main
Am 13.10.11 20:38, schrieb Barry Warsaw:
On Oct 13, 2011, at 08:08 PM, Martin v. Löwis wrote:
Py_CONST_STRING or Py_IDENTIFIER would be fine with me. Given that
everything else uses Id in their name, Py_IDENTIFIER is probably better?
I agree that either is fine, with a slight preference for
On Oct 14, 2011, at 04:08 PM, Martin v. Löwis wrote:
It actually is _Py_IDENTIFIER (and was _Py_identifier).
Yep, I saw your commit to make the change. Thanks!
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Instead of an explicit prefix, how about a macro, such as
Py_ID(__string__)?
That wouldn't be instead, but in addition - you need the
variable name, anyway. Not sure whether there is actually
a gain in readability - people not familiar with this would
assume that it's a function call of some
Martin v. Löwis wrote:
That wouldn't be instead, but in addition - you need the
variable name, anyway.
But the details of exactly how the name is constructed
could be kept as an implementation detail.
Not sure whether there is actually
a gain in readability - people not familiar with this
Am 15.10.2011 01:32, schrieb Greg Ewing:
Martin v. Löwis wrote:
That wouldn't be instead, but in addition - you need the
variable name, anyway.
But the details of exactly how the name is constructed
could be kept as an implementation detail.
Is there a use case for keeping that detail
I like this better too because of the all-caps macro name. Something about
seeing Py_identifier look like a function call and having it add the magical
PyId_update local bugs me. It just looks wrong, whereas the all-caps is more
of a cultural clue that something else is going on.
If people
An alternative I am fond of is to to avoid introducing a new type, and
simply initialize a PyObject * and register its address.
-1 on that, because of the lack of error checking.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
On Thu, 13 Oct 2011 14:00:38 +0200
Martin v. Löwis mar...@v.loewis.de wrote:
I like this better too because of the all-caps macro name. Something about
seeing Py_identifier look like a function call and having it add the
magical
PyId_update local bugs me. It just looks wrong, whereas
On Oct 13, 2011, at 03:23 PM, Antoine Pitrou wrote:
Py_CONST_STRING or Py_IDENTIFIER would be fine with me. Given that
everything else uses Id in their name, Py_IDENTIFIER is probably better?
I agree that either is fine, with a slight preference for Py_IDENTIFIER for
the same reasons.
Py_CONST_STRING or Py_IDENTIFIER would be fine with me. Given that
everything else uses Id in their name, Py_IDENTIFIER is probably better?
I agree that either is fine, with a slight preference for Py_IDENTIFIER for
the same reasons.
Ok, so it's Py_IDENTIFIER.
So I think it needs a prefix.
Martin v. Löwis wrote:
So I think it needs a prefix. If you don't like PyId_, let me know
what the prefix should be instead.
Instead of an explicit prefix, how about a macro, such as
Py_ID(__string__)?
--
Greg
___
Python-Dev mailing list
Le jeudi 13 octobre 2011 03:34:00, Victor Stinner a écrit :
We would need a new format for Py_BuildValue, e.g. 'a' for ASCII string.
Later we can add new functions like _PyDict_GetASCII().
The main difference between my new const ASCII string idea and
PyIdentifier is the lifetime of
Am 14.10.2011 00:30, schrieb Victor Stinner:
Le jeudi 13 octobre 2011 03:34:00, Victor Stinner a écrit :
We would need a new format for Py_BuildValue, e.g. 'a' for ASCII string.
Later we can add new functions like _PyDict_GetASCII().
The main difference between my new const ASCII string
Le samedi 8 octobre 2011 16:54:06, Martin v. Löwis a écrit :
In benchmarking PEP 393, I noticed that many UTF-8 decode
calls originate from C code with static strings, in particular
PyObject_CallMethod. Many of such calls already have been optimized
to cache a string object, however,
Le jeudi 13 octobre 2011 00:44:33, Victor Stinner a écrit :
Le samedi 8 octobre 2011 16:54:06, Martin v. Löwis a écrit :
In benchmarking PEP 393, I noticed that many UTF-8 decode
calls originate from C code with static strings, in particular
PyObject_CallMethod. Many of such calls already
On 10/08/2011 04:54 PM, Martin v. Löwis wrote:
tmp = PyObject_CallMethod(result, update, O, other);
would be replaced with
PyObject *tmp;
Py_identifier(update);
...
tmp = PyObject_CallMethodId(result,PyId_update, O, other);
An alternative I am fond of is to
2011/10/11 Hrvoje Niksic hrvoje.nik...@avl.com
An alternative I am fond of is to to avoid introducing a new type, and
simply initialize a PyObject * and register its address. For example:
PyObject *tmp;
static PyObject *s_update;// pick a naming convention
On Oct 11, 2011, at 02:36 PM, Hrvoje Niksic wrote:
On 10/08/2011 04:54 PM, Martin v. Löwis wrote:
tmp = PyObject_CallMethod(result, update, O, other);
would be replaced with
PyObject *tmp;
Py_identifier(update);
...
tmp =
On 10/11/2011 02:45 PM, Amaury Forgeot d'Arc wrote:
It should also check for errors; in this case the initialization is a
bit more verbose:
if (PY_IDENTIFIER_INIT(update) 0)
return NULL or return -1 or goto error;
Error checking is somewhat more controversial because behavior in case
of
On Tue, 11 Oct 2011 09:19:43 -0400
Barry Warsaw ba...@python.org wrote:
On Oct 11, 2011, at 02:36 PM, Hrvoje Niksic wrote:
On 10/08/2011 04:54 PM, Martin v. Löwis wrote:
tmp = PyObject_CallMethod(result, update, O, other);
would be replaced with
PyObject *tmp;
2011/10/11 Antoine Pitrou solip...@pitrou.net:
+1 for something more recognizable.
I think const string is more accurate than identifier as well.
It should only really be used for identifiers, though, because the
result is interned.
--
Regards,
Benjamin
Martin v. Löwis, 08.10.2011 16:54:
In benchmarking PEP 393, I noticed that many UTF-8 decode
calls originate from C code with static strings, in particular
PyObject_CallMethod. Many of such calls already have been optimized
to cache a string object, however, PyObject_CallMethod remains
In benchmarking PEP 393, I noticed that many UTF-8 decode
calls originate from C code with static strings, in particular
PyObject_CallMethod. Many of such calls already have been optimized
to cache a string object, however, PyObject_CallMethod remains
unoptimized since it requires a char*.
I
On Sat, 08 Oct 2011 16:54:06 +0200
Martin v. Löwis mar...@v.loewis.de wrote:
I find the ad-hoc approach of declaring and initializing variables
inadequate, in particular since it is difficult to clean up all
those string objects at interpreter shutdown.
I propose to add an explicit API to
Am 08.10.2011 17:43, schrieb Antoine Pitrou:
On Sat, 08 Oct 2011 16:54:06 +0200
Martin v. Löwis mar...@v.loewis.de wrote:
I find the ad-hoc approach of declaring and initializing variables
inadequate, in particular since it is difficult to clean up all
those string objects at interpreter
27 matches
Mail list logo
