Am 01.09.2010 23:43, schrieb Nick Coghlan:
> On Thu, Sep 2, 2010 at 7:25 AM, Georg Brandl wrote:
>> That title isn't better though, since it doesn't cover the "using/cmdline"
>> document which deals with command line options, environment variables
>> and the like.
>>
>> I agree that "Using Python"
Hi Victor,
1. This function and PyUnicode_strcat are missing documentation.
2. Are you sure they need to be public APIs? What are they going to
be used for? (I'm not sure myself, but I think we usually have a
short notice here when new C APIs are added.)
Georg
Am 02.09.2010 01:43, schri
Georg Brandl wrote:
> Hi Victor,
>
> 1. This function and PyUnicode_strcat are missing documentation.
>
> 2. Are you sure they need to be public APIs? What are they going to
>be used for? (I'm not sure myself, but I think we usually have a
>short notice here when new C APIs are added.)
Hello all,
In issue #5506, I originally proposed that io.BytesIO objects support
the buffer protocol, to make it possible to access the internal buffer
without intermediate copies.
Then it came to me then perhaps it would be too automatic. So I'm
currently floating between:
- add implicit buffer
On Thu, Sep 2, 2010 at 6:51 PM, Georg Brandl wrote:
> Hi Victor,
>
> 1. This function and PyUnicode_strcat are missing documentation.
>
> 2. Are you sure they need to be public APIs? What are they going to
> be used for? (I'm not sure myself, but I think we usually have a
> short notice here
On Fri, Sep 3, 2010 at 6:35 AM, Antoine Pitrou wrote:
>
> Hello all,
>
> In issue #5506, I originally proposed that io.BytesIO objects support
> the buffer protocol, to make it possible to access the internal buffer
> without intermediate copies.
>
> Then it came to me then perhaps it would be too
On Wed, Sep 1, 2010 at 10:54 PM, Antoine Pitrou wrote:
> Please consider this: even without relying on PEP 384, using FILE*
> is /already/ dangerous; because you might compile an extension with a
> different compiler version than Python was compiled with. So, if we were
> following you, we should
Hi,
Le jeudi 02 septembre 2010 11:13:22, vous avez écrit :
> > 1. This function and PyUnicode_strcat are missing documentation.
It's Py_UNICODE_strcat(), not PyUnicode_strcat(). But yes, Py_UNICODE_strcat()
is not documented. But I didn't found any doc for other Py_UNICODE_str*()
functions in D
Le jeudi 02 septembre 2010 23:19:04, Nick Coghlan a écrit :
> On Thu, Sep 2, 2010 at 6:51 PM, Georg Brandl wrote:
> > Hi Victor,
> >
> > 1. This function and PyUnicode_strcat are missing documentation.
> >
> > 2. Are you sure they need to be public APIs? What are they going to
> > be used for
On 02/09/10 09:04, Nick Coghlan wrote:
I think it would be better if everything dealing with FILE* was a
macro rather than a function, yes.
How would that help?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
On Apr 30, 2010, at 12:51 PM, Martin v. Löwis wrote:
> Without a BDFL, I think we need a committee to make decisions, e.g. by
> majority vote amongst committers.
I like Guido's idea. Just appoint have one of the experienced developers
who is independent of the proposal and have them be the final
On Thu, Sep 2, 2010 at 9:08 PM, Raymond Hettinger
wrote:
>
> On Apr 30, 2010, at 12:51 PM, Martin v. Löwis wrote:
>> Without a BDFL, I think we need a committee to make decisions, e.g. by
>> majority vote amongst committers.
>
> I like Guido's idea. Just appoint have one of the experienced develo
>> Without a BDFL, I think we need a committee to make decisions, e.g. by
>> majority vote amongst committers.
>
> It is better to have one experienced developer decide than to have
> a committee.
I feel that the concept of a BDFM (benevolent dictator for the moment)
has the advantage of a clear v
13 matches
Mail list logo
