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 helpe
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 deta
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 wou
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 kin
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
Python-Dev@p
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 fo
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 differ
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 ASCI
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 o
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
Python-Dev@p
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 Py_IDENTIFIER for
>> the same
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
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.
>> Or
On Thu, 13 Oct 2011 14:00:38 +0200
"Martin v. Löwis" 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 the all-c
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
http:/
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 t
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 alr
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, PyObje
"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
unoptimi
2011/10/11 Antoine Pitrou :
> +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
___
Pyth
On Tue, 11 Oct 2011 09:19:43 -0400
Barry Warsaw 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;
>
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)
;
Error checking is somewhat more controversial because behavior in case
of error differs between situations and codin
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 = PyObject_Ca
2011/10/11 Hrvoje Niksic
> 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
>
> PY_IDENTIFIER_INIT(update);
> tmp = PyO
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 o
Am 08.10.2011 17:43, schrieb Antoine Pitrou:
> On Sat, 08 Oct 2011 16:54:06 +0200
> "Martin v. Löwis" 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.
On Sat, 08 Oct 2011 16:54:06 +0200
"Martin v. Löwis" 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 deal with s
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 find
28 matches
Mail list logo
