Am 19.11.2010 03:23, schrieb Benjamin Peterson:
> 2010/11/18 Jesus Cea :
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 18/11/10 18:32, "Martin v. Löwis" wrote:
>>> In general, I'm *also* concerned about the lack of volunteers that
>>> are interested in working on the infrastructure.
2010/11/18 Jesus Cea :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 18/11/10 18:32, "Martin v. Löwis" wrote:
>> In general, I'm *also* concerned about the lack of volunteers that
>> are interested in working on the infrastructure. I wish some of the
>> people who stated that they can't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18/11/10 18:32, "Martin v. Löwis" wrote:
> In general, I'm *also* concerned about the lack of volunteers that
> are interested in working on the infrastructure. I wish some of the
> people who stated that they can't wait for the migration to happen
>> Therefore, I'm concerned that I will have to work out all the details
>> on my own, just so that I can produce the b2 binaries (says); this is
>> not something I look forward to.
>
> How much does the binary build process really depend on version control?
> I.e., what would be stopping you from
Am 18.11.2010 18:32, schrieb "Martin v. Löwis":
>>> Alternatively, b1 should be postponed until after the Mercurial
>>> migration is done.
>>
>> I think this "new feature" is not so shocking that it can be used as
>> an argument to hold up the migration. If you have another reason to
>> stop the m
>> Alternatively, b1 should be postponed until after the Mercurial
>> migration is done.
>
> I think this "new feature" is not so shocking that it can be used as
> an argument to hold up the migration. If you have another reason to
> stop the migration please say so; personally I can't wait for it
Am 18.11.2010 17:25, schrieb "Martin v. Löwis":
> Am 17.11.2010 08:18, schrieb Georg Brandl:
>> 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
On Thu, Nov 18, 2010 at 8:25 AM, "Martin v. Löwis" wrote:
> Am 17.11.2010 08:18, schrieb Georg Brandl:
>> 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 conta
On Thu, Nov 18, 2010 at 4:16 AM, Nick Coghlan wrote:
> On Thu, Nov 18, 2010 at 7:22 AM, Georg Brandl wrote:
>> So it comes down again to what we'd like __all__ to mean foremost:
>> public API, or just a list for "import *"?
>
> It's the list for star imports. This intended use case is borne out b
Am 17.11.2010 08:18, schrieb Georg Brandl:
> 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 th
On Thu, Nov 18, 2010 at 11:18 PM, Antoine Pitrou wrote:
>> Log:
>> Fix Issue 9991: xmlrpc client ssl check faulty
>>
> [...]
>>
>> + def test_ssl_presence(self):
>> + #Check for ssl support
>> + have_ssl = False
>> + if hasattr(socket, 'ssl'):
>> + have_ssl = Tru
On Thu, 18 Nov 2010 16:00:53 +0100 (CET)
senthil.kumaran wrote:
> Author: senthil.kumaran
> Date: Thu Nov 18 16:00:53 2010
> New Revision: 86514
>
> Log:
> Fix Issue 9991: xmlrpc client ssl check faulty
>
[...]
>
> +def test_ssl_presence(self):
> +#Check for ssl support
> +
On Thu, Nov 18, 2010 at 6:41 AM, Michael Foord
wrote:
> Along with the others +1
I agree with keeping these distinct and orthogonal as well.
> What is more important is that we have a clearly stated policy for new
> modules and adding names to existing modules so that we don't have to repeat
> t
Am 18.11.2010 13:48, schrieb Michael Foord:
On 18/11/2010 12:37, Georg Brandl wrote:
Am 18.11.2010 11:47, schrieb Michael Foord:
On 17/11/2010 21:16, Éric Araujo wrote:
Excluding a builtin name from __all__ sounds like a perfectly
sensible
idea, so even if it wasn't deliberate, I'd say it qua
On 18/11/2010 12:37, Georg Brandl wrote:
Am 18.11.2010 11:47, schrieb Michael Foord:
On 17/11/2010 21:16, Éric Araujo wrote:
Excluding a builtin name from __all__ sounds like a perfectly sensible
idea, so even if it wasn't deliberate, I'd say it qualifies as
fortuitous :)
But then, a tool that
Am 18.11.2010 11:47, schrieb Michael Foord:
> On 17/11/2010 21:16, Éric Araujo wrote:
>>> Excluding a builtin name from __all__ sounds like a perfectly sensible
>>> idea, so even if it wasn't deliberate, I'd say it qualifies as
>>> fortuitous :)
>> But then, a tool that looks into __all__ to find f
On Thu, Nov 18, 2010 at 7:22 AM, Georg Brandl wrote:
> Am 17.11.2010 22:16, schrieb Éric Araujo:
>>> Excluding a builtin name from __all__ sounds like a perfectly sensible
>>> idea, so even if it wasn't deliberate, I'd say it qualifies as
>>> fortuitous :)
>>
>> But then, a tool that looks into __
On 17/11/2010 21:57, Steven D'Aprano wrote:
Nick Coghlan wrote:
The policy we're aiming to clarify here is what we should do when we
come across standard library APIs that land in the grey area, with
there being two appropriate ways to deal with them:
1. Document them and make them officially p
On 17/11/2010 21:22, Georg Brandl wrote:
Am 17.11.2010 22:16, schrieb Éric Araujo:
Excluding a builtin name from __all__ sounds like a perfectly sensible
idea, so even if it wasn't deliberate, I'd say it qualifies as
fortuitous :)
But then, a tool that looks into __all__ to find for example wha
On 17/11/2010 21:16, Éric Araujo wrote:
Excluding a builtin name from __all__ sounds like a perfectly sensible
idea, so even if it wasn't deliberate, I'd say it qualifies as
fortuitous :)
But then, a tool that looks into __all__ to find for example what
objects to document will miss open. I’d p
20 matches
Mail list logo
