Am 16.11.2010 19:38, schrieb Jesus Cea:
> Is there any updated mercurial schedule?.
>
> Any impact related with the new 3.2 schedule (three weeks offset)?
I've been trying to contact Dirkjan and ask; generally, I don't
see much connection to the 3.2 schedule (with the exception that
the final mig
On Nov 16, 2010, at 4:49 PM, Guido van Rossum wrote:
>> PEP 8 isn't nearly visible enough, either. Whatever the rule is, it needs
>> to be presented with the information itself. If the rule is that things not
>> documented in the library manual have no compatibility guarantees, then all
>> of t
I created http://bugs.python.org/issue10435 to follow up on unicode C
API issues.
On Tue, Nov 16, 2010 at 10:38 AM, M.-A. Lemburg wrote:
> Alexander Belopolsky wrote:
>> What this thread has shown is that there is no consensus on what
>> public names are and what rules should be followed when cha
On Tue, Nov 16, 2010 at 4:31 PM, Ben Finney wrote:
..
> I don't know about Guido, but I'd be -1 on suggestions to add more
> normative information to PEP 7, PEP 8, PEP 257, or any other established
> style guide PEP. I certainly don't want to have to keep going back to
> the same documents frequen
On Tue, Nov 16, 2010 at 8:34 AM, wrote:
> On 03:48 pm, gu...@python.org wrote:
>>
>> On Tue, Nov 16, 2010 at 7:16 AM, Alexander Belopolsky
>> wrote:
>>>
>>> What this thread has shown is that there is no consensus on what
>>> public names are and what rules should be followed when changing names
On Tue, Nov 16, 2010 at 4:31 PM, Ben Finney wrote:
> I don't know about Guido, but I'd be -1 on suggestions to add more
> normative information to PEP 7, PEP 8, PEP 257, or any other established
> style guide PEP. I certainly don't want to have to keep going back to
> the same documents frequently
exar...@twistedmatrix.com writes:
> On 03:48 pm, gu...@python.org wrote:
> >Hm. Apart from the specific semantics assigned by the language to
> >single and double leading (and trailing) underscores, I still think
> >this belongs in a style guide, not in the library manual.
>
> I don't think it bel
Am 16.11.2010 21:15, schrieb Rodrigo Bernardo Pimentel:
> On 26 October 2010 18:04, Georg Brandl wrote:
>> Am 26.10.2010 19:53, schrieb Brett Cannon:
>>> Can whomever has edit access to the Python Google Calendar add this?
>>
>> Done.
>
> The Bug Weekend is still up, right? I don't see mention of
On Tue, Nov 16, 2010 at 3:06 PM, M.-A. Lemburg wrote:
..
> len(chr(0x10))
>> 2
>>
>> (on a USC2 build.)
>
> Yes, it's a documentation bug. I guess someone forgot to update
> the comment in unicodeobject.h after the change to have chr()/unichr()
> return a 2-char string instead of a 1-char
On 26 October 2010 18:04, Georg Brandl wrote:
> Am 26.10.2010 19:53, schrieb Brett Cannon:
>> Can whomever has edit access to the Python Google Calendar add this?
>
> Done.
The Bug Weekend is still up, right? I don't see mention of it at
http://wiki.python.org/moin/PythonBugDay (and when I tried
Alexander Belopolsky wrote:
> On Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg wrote:
>> Alexander Belopolsky wrote:
>>> On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg wrote:
>>> ..
Now, we can't use a macro for [PyUnicode_GetMax()], since the information
has
to be available as call
On Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg wrote:
> Alexander Belopolsky wrote:
>> On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg wrote:
>> ..
>>> Now, we can't use a macro for [PyUnicode_GetMax()], since the information
>>> has
>>> to be available as callable in order to applications or ext
Alexander Belopolsky wrote:
> On Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg wrote:
> ..
>>> Note that we can have both a macro and a function
>>> version. This is fairly standard practice in Python C-API.
>>
>> Sure, but what for ?
>>
>
> Mostly just for consistency with the other macros:
>
>
On 11/16/2010 10:16 AM, Alexander Belopolsky wrote:
What this thread has shown is that there is no consensus on what
public names are and what rules should be followed when changing names
that can be imported from a module.
Nor is their any consensus on the use of __all__ in the stdlib, with
o
On Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg wrote:
..
>> Note that we can have both a macro and a function
>> version. This is fairly standard practice in Python C-API.
>
> Sure, but what for ?
>
Mostly just for consistency with the other macros:
http://docs.python.org/dev/py3k/c-api/unicode
Alexander Belopolsky wrote:
> On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg wrote:
> ..
>> Now, we can't use a macro for [PyUnicode_GetMax()], since the information has
>> to be available as callable in order to applications or extensions
>> to use it (without recompile).
>>
>
> .. but it *is* a
On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg wrote:
..
> BTW: I'm not really happy about the Py_UNICODE_ prefix for functions
> in unicodeobject.h, but I guess it's too late to change those.
> It would be better to stick to one prefix for Unicode related
> APIs, i.e. "PyUnicode_".
I don't have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there any updated mercurial schedule?.
Any impact related with the new 3.2 schedule (three weeks offset)?
- --
Jesus Cea Avion _/_/ _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_
On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg wrote:
..
> Now, we can't use a macro for [PyUnicode_GetMax()], since the information has
> to be available as callable in order to applications or extensions
> to use it (without recompile).
>
.. but it *is* a macro resolving to either PyUnicodeUCS2
Am 16.11.2010 18:06, schrieb Antoine Pitrou:
> On Tue, 16 Nov 2010 16:34:54 -
> exar...@twistedmatrix.com wrote:
>>
>> Imagine trying to use a dictionary without knowing about alphabetical
>> ordering.
>
> You mean an ordered dictionary, right?
That one's a sorted dictionary, though.
Georg
Alexander Belopolsky wrote:
> On Tue, Nov 16, 2010 at 10:38 AM, M.-A. Lemburg wrote:
> ..
>> One API I'm not sure about is PyUnicode_AppendAndDel(). It's somewhat
>> obscure and given that we already have PyUnicode_Concat(), I think
>> it should be made private and eventually dropped.
>>
>
> What
On 05:21 pm, fuzzy...@voidspace.org.uk wrote:
On 16/11/2010 17:16, 1ukasz Langa wrote:
Am 16.11.2010 18:06, schrieb Antoine Pitrou:
On Tue, 16 Nov 2010 16:34:54 -
exar...@twistedmatrix.com wrote:
Imagine trying to use a dictionary without knowing about
alphabetical
ordering.
You mean an
On 16/11/2010 17:16, Łukasz Langa wrote:
Am 16.11.2010 18:06, schrieb Antoine Pitrou:
On Tue, 16 Nov 2010 16:34:54 -
exar...@twistedmatrix.com wrote:
Imagine trying to use a dictionary without knowing about alphabetical
ordering.
You mean an ordered dictionary, right?
He meant the ones w
Am 16.11.2010 18:06, schrieb Antoine Pitrou:
On Tue, 16 Nov 2010 16:34:54 -
exar...@twistedmatrix.com wrote:
Imagine trying to use a dictionary without knowing about alphabetical
ordering.
You mean an ordered dictionary, right?
He meant the ones with actual paper pages.
__
On Tue, Nov 16, 2010 at 10:38 AM, M.-A. Lemburg wrote:
..
> One API I'm not sure about is PyUnicode_AppendAndDel(). It's somewhat
> obscure and given that we already have PyUnicode_Concat(), I think
> it should be made private and eventually dropped.
>
What about PyUnicode_GetMax()? Isn't that s
On Tue, 16 Nov 2010 16:34:54 -
exar...@twistedmatrix.com wrote:
>
> Imagine trying to use a dictionary without knowing about alphabetical
> ordering.
You mean an ordered dictionary, right?
___
Python-Dev mailing list
Python-Dev@python.org
http:/
On Nov 16, 2010, at 7:05 AM, Paul Moore wrote:
>
> PEP 3148 (Futures) is noted in the PEP as going into 3.2, It also
> seems to be in the release.
>
> Should it not be added to the "What's new in 3.2" document and the
> release announcements? It's a fairly significant feature.
I'll update the w
On Nov 16, 2010, at 7:05 AM, Paul Moore wrote:
>
> PEP 3148 (Futures) is noted in the PEP as going into 3.2, It also
> seems to be in the release.
>
> Should it not be added to the "What's new in 3.2" document and the
> release announcements? It's a fairly significant feature.
I'll update the w
On 03:48 pm, gu...@python.org wrote:
On Tue, Nov 16, 2010 at 7:16 AM, Alexander Belopolsky
wrote:
What this thread has shown is that there is no consensus on what
public names are and what rules should be followed when changing names
that can be imported from a module. �I have opened an issue a
Ned Deily wrote:
> In article <30929.1289879...@parc.com>, Bill Janssen
> wrote:
>
> > Both the Tiger buildbots are suddenly failing 3.x on test_cmd_line.
> > Looking at the changes since the last success, I can't see anything
> > which would obviously affect that... Any suspects?
>
> It app
On Tue, Nov 16, 2010 at 7:16 AM, Alexander Belopolsky
wrote:
> What this thread has shown is that there is no consensus on what
> public names are and what rules should be followed when changing names
> that can be imported from a module. I have opened an issue at
> http://bugs.python.org/issue10
Alexander Belopolsky wrote:
> What this thread has shown is that there is no consensus on what
> public names are and what rules should be followed when changing names
> that can be imported from a module. I have opened an issue at
> http://bugs.python.org/issue10434 to address this. My vote is t
On 16/11/2010 15:16, Alexander Belopolsky wrote:
What this thread has shown is that there is no consensus on what
public names are and what rules should be followed when changing names
that can be imported from a module. I have opened an issue at
http://bugs.python.org/issue10434 to address this
What this thread has shown is that there is no consensus on what
public names are and what rules should be followed when changing names
that can be imported from a module. I have opened an issue at
http://bugs.python.org/issue10434 to address this. My vote is to
adopt the definition spelled out i
(Copying to the list, sorry Georg for the duplicate)
On 16 November 2010 14:05, Georg Brandl wrote:
> On behalf of the Python development team, I'm happy to announce the
> fourth and (this time really) final alpha preview release of Python 3.2.
PEP 3148 (Futures) is noted in the PEP as going int
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Python development team, I'm happy to announce the
fourth and (this time really) final alpha preview release of Python 3.2.
Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line. Since the final rel
In article <30929.1289879...@parc.com>, Bill Janssen
wrote:
> Both the Tiger buildbots are suddenly failing 3.x on test_cmd_line.
> Looking at the changes since the last success, I can't see anything
> which would obviously affect that... Any suspects?
It appears to be a duplicate of Issue8458
37 matches
Mail list logo
