Georg Brandl wrote:
>> Right. At least, not with changing structmember.[ch].
>
> Did you mean "without"?
Oops, right.
> Can I submit a patch?
I personally don't mind having more types added to structmember,
so I'm +0 on adding Py_ssize_t to the list of types supported.
I wonder what the specif
[Neal]
>> Looking in stringobject.c, I don't see how %zu (or %lu) can be used
>> with String_FromFormatV.
[Martin]
> Right. It currently cannot be used. So if it is desired, it needs to
> be added first, and then should be used.
I added it: %u, %lu, and %zu can be used now in PyString_FromFormat
Neal Norwitz wrote:
>> That's a bug. It should print it signed. If unsigned printing of size_t
>> is desired, %zu should be used.
>
> Looking in stringobject.c, I don't see how %zu (or %lu) can be used
> with String_FromFormatV.
Right. It currently cannot be used. So if it is desired, it needs to
On 5/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> > '%zd' won't work since my value can be negative, and the 'z' modifier
> > converts the argument to size_t.
>
> That's a bug. It should print it signed. If unsigned printing of size_t
> is desired, %zu should be used.
Looking in stringo
Martin v. Löwis wrote:
> Georg Brandl wrote:
>> Similary, there's no way for a structmember to be of type Py_ssize_t...
>
> Right. At least, not with changing structmember.[ch].
Did you mean "without"? Can I submit a patch?
Georg
___
Python-Dev mailin
Somebody has contributed an edited version of the current icons,
at
https://sourceforge.net/tracker/index.php?func=detail&aid=1481304&group_id=5470&atid=305470
He claims that his version is prettier in small sizes; I'm
uncertain whether this is the case.
What do you think?
Regards,
Martin
_
Georg Brandl wrote:
> Similary, there's no way for a structmember to be of type Py_ssize_t...
Right. At least, not with changing structmember.[ch].
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
Martin v. Löwis wrote:
> Georg Brandl wrote:
>> which formatting code should be used for a Py_ssize_t value in e.g.
>> PyString_FromFormat?
>
> %zd
>
>> '%zd' won't work since my value can be negative, and the 'z' modifier
>> converts the argument to size_t.
>
> That's a bug. It should print it
Georg Brandl wrote:
> which formatting code should be used for a Py_ssize_t value in e.g.
> PyString_FromFormat?
%zd
> '%zd' won't work since my value can be negative, and the 'z' modifier
> converts the argument to size_t.
That's a bug. It should print it signed. If unsigned printing of size_t
Hi,
which formatting code should be used for a Py_ssize_t value in e.g.
PyString_FromFormat?
'%zd' won't work since my value can be negative, and the 'z' modifier
converts the argument to size_t.
Georg
___
Python-Dev mailing list
Python-Dev@python.org
M.-A. Lemburg wrote:
> I was leaving those out already - only the codes named 'ERROR_*'
> get included (see attached parser and generator).
Right. One might debate whether DNS_INFO_AXFR_COMPLETE (9751L)
or WSAEACCES (10013L) should be included as well.
I got a smaller source file as I included on
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> What do you think ?
>
> I think the size could be further reduced by restricting the set of
> error codes. For example, if the COM error codes are left out, I only
> get a Python file with 60k source size (although the bytecode size
> is then 130k).
12 matches
Mail list logo