>> 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
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
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 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
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
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
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
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 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
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
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.)
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
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"
13 matches
Mail list logo
