On Mon, Mar 19, 2012 at 2:50 PM, Ethan Furman wrote:
> [1] I'm assuming that 'iter(some_list)' is a quick operation.
This seems to be the case so I've just gone ahead and renamed
collapse_address_list to collapse_addresses and added 'return
iter(...)' to the end.
The rest of the list-returning
Greg Ewing wrote:
Guido van Rossum wrote:
I personally like having 'iter' in the name (e.g. iterkeys() -- note
that we dropped this in Py3k because it's no longer an iterator, it's
a dict view now. But I don't want to promote that style for ipaddr.py.
+1 from me too on having all methods that
Guido van Rossum wrote:
I personally like having 'iter' in the name (e.g. iterkeys() -- note
that we dropped this in Py3k because it's no longer an iterator, it's
a dict view now. But I don't want to promote that style for ipaddr.py.
+1 from me too on having all methods that return iterators
c
On Mon, Mar 19, 2012 at 02:50:22PM -0700, Ethan Furman wrote:
> Guido van Rossum wrote:
[...]
> >And remember that consistency is good in moderation, but if it becomes
> >a goal in itself you may have a problem.
>
> While I agree that consistency as a goal in and of itself is not good, I
> consi
On Tue, Mar 20, 2012 at 10:43 AM, Stephen J. Turnbull
wrote:
> But according to Nick's post, there's some sort of uniquification that
> is done, and the algorithm currently used computes the whole list anyway.
>
> I suppose that one could do the uniquification lazily, or find some other
> way to a
On Tue, Mar 20, 2012 at 8:34 AM, Guido van Rossum wrote:
> Anyway, I also tried to imply that it matters if the number of list
> items would ever be huge. It seems that is indeed possible (even if
> not likely) so I think iterators are useful.
But according to Nick's post, there's some sort of u
On Mon, Mar 19, 2012 at 3:44 PM, Terry Reedy wrote:
> I am not sure which way you are pointing, but the general default in 3.x is
> to return iterators: range, zip, enumerate, map, filter, reversed, open
> (file objects), as well at the dict methods.
Actually as I tried to say, the dict methods (
On 3/19/2012 6:04 PM, Guido van Rossum wrote:
On Mon, Mar 19, 2012 at 2:58 PM, Peter Moody wrote:
On Mon, Mar 19, 2012 at 12:55 PM, Guido van Rossum wrote:
On Mon, Mar 19, 2012 at 12:37 PM, Ethan Furman wrote:
Nick Coghlan wrote:
Collapsing the address list has to build the result list an
Guido van Rossum wrote:
On Mon, Mar 19, 2012 at 1:13 PM, Ethan Furman wrote:
Nothing wrong in and of itself. It just seems to me that if we have several
functions that deal with ip addresses/networks/etc, and all but one return
iterators, that one is going to be a pain... 'Which one returns a l
On Mon, Mar 19, 2012 at 2:58 PM, Peter Moody wrote:
> On Mon, Mar 19, 2012 at 12:55 PM, Guido van Rossum wrote:
>> On Mon, Mar 19, 2012 at 12:37 PM, Ethan Furman wrote:
>>> Nick Coghlan wrote:
Collapsing the address list has to build the result list anyway to
actually handle the d
On Mon, Mar 19, 2012 at 12:55 PM, Guido van Rossum wrote:
> On Mon, Mar 19, 2012 at 12:37 PM, Ethan Furman wrote:
>> Nick Coghlan wrote:
>>>
>>> Collapsing the address list has to build the result list anyway to
>>> actually handle the deduplication part of its job, so returning a
>>> concrete li
On Mon, Mar 19, 2012 at 1:13 PM, Ethan Furman wrote:
> Guido van Rossum wrote:
>>
>> On Mon, Mar 19, 2012 at 12:37 PM, Ethan Furman wrote:
>>>
>>> Nick Coghlan wrote:
Collapsing the address list has to build the result list anyway to
actually handle the deduplication part of its jo
Guido van Rossum wrote:
On Mon, Mar 19, 2012 at 12:37 PM, Ethan Furman wrote:
Nick Coghlan wrote:
Collapsing the address list has to build the result list anyway to
actually handle the deduplication part of its job, so returning a
concrete list makes sense in that case.
Having only one funct
On Mon, Mar 19, 2012 at 12:37 PM, Ethan Furman wrote:
> Nick Coghlan wrote:
>>
>> Collapsing the address list has to build the result list anyway to
>> actually handle the deduplication part of its job, so returning a
>> concrete list makes sense in that case.
>
>
> Having only one function return
Nick Coghlan wrote:
Collapsing the address list has to build the result list anyway to
actually handle the deduplication part of its job, so returning a
concrete list makes sense in that case.
Having only one function return a list instead of an iterator seems
questionable.
Depending on the
On Mon, Mar 19, 2012 at 12:44 PM, Peter Moody wrote:
> On Mon, Mar 12, 2012 at 9:15 AM, Peter Moody wrote:
>
- iterable APIs should consistently produce iterators (leaving users
free to wrap list() around the calls if they want the concrete
realisation)
>
> I might've missed earlie
On Mon, Mar 12, 2012 at 9:15 AM, Peter Moody wrote:
>>> - iterable APIs should consistently produce iterators (leaving users
>>> free to wrap list() around the calls if they want the concrete
>>> realisation)
I might've missed earlier discussion somewhere, but can someone point
me at an example
On Wed, Feb 29, 2012 at 9:13 PM, Peter Moody wrote:
> Just checking in:
>
> On Mon, Feb 20, 2012 at 5:48 PM, Nick Coghlan wrote:
>> At the very least:
>> - the IP Interface API needs to move to a point where it more clearly
>> *is* an IP Address and *has* an associated IP Network (rather than
>>
On Thu, Mar 1, 2012 at 3:13 PM, Peter Moody wrote:
> Just checking in:
>
> On Mon, Feb 20, 2012 at 5:48 PM, Nick Coghlan wrote:
>> At the very least:
>> - the IP Interface API needs to move to a point where it more clearly
>> *is* an IP Address and *has* an associated IP Network (rather than
>> b
Just checking in:
On Mon, Feb 20, 2012 at 5:48 PM, Nick Coghlan wrote:
> At the very least:
> - the IP Interface API needs to move to a point where it more clearly
> *is* an IP Address and *has* an associated IP Network (rather than
> being the other way around)
This is done [1]. There's cleanup
On 2/21/12 4:52 AM, Guido van Rossum wrote:
On Mon, Feb 20, 2012 at 4:53 PM, Stephen J. Turnbull wrote:
Steven D'Aprano writes:
> Also, "Czar" is commonly used in US politics as an informal term for the
top
> official responsible for an area.
I think here the most important connotation
On 2/20/2012 11:52 PM, Guido van Rossum wrote:
On Mon, Feb 20, 2012 at 4:53 PM, Stephen J. Turnbull wrote:
Steven D'Aprano writes:
> Also, "Czar" is commonly used in US politics as an informal term for the
top
> official responsible for an area.
I think here the most important connotat
On Mon, Feb 20, 2012 at 4:53 PM, Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
>
> > Also, "Czar" is commonly used in US politics as an informal term for the
> top
> > official responsible for an area.
>
> I think here the most important connotation is that in US parlance a
> "czar" does
On Tue, Feb 21, 2012 at 7:09 AM, Guido van Rossum wrote:
> Approved. Nick is PEP czar for PEP 3144. Thanks Nick!
In that case the addition of the "ipaddress" module is approved for
3.3, with a provisional caveat on the API details. I'm doing it that
way because I think those remaining details can
Steven D'Aprano writes:
> Also, "Czar" is commonly used in US politics as an informal term for the top
> official responsible for an area.
I think here the most important connotation is that in US parlance a
"czar" does not report to a committee, and with the exception of a
case where Sybil is
Nick Coghlan wrote:
On Mon, Feb 20, 2012 at 11:55 PM, Antoine Pitrou wrote:
On Mon, 20 Feb 2012 23:23:13 +1000
Nick Coghlan wrote:
Does anyone object to me naming myself PEP czar for PEP 3144?
“Tsar is a title used to designate certain European Slavic monarchs or
supreme rulers.”
Is this ou
Approved. Nick is PEP czar for PEP 3144. Thanks Nick!
On Mon, Feb 20, 2012 at 11:13 AM, Terry Reedy wrote:
> On 2/20/2012 8:23 AM, Nick Coghlan wrote:
>>
>> Does anyone object to me naming myself PEP czar for PEP 3144?
>
>
> I think it great that you volunteer to be the PEP czar and hope Guido
>
On 2/20/2012 8:23 AM, Nick Coghlan wrote:
Does anyone object to me naming myself PEP czar for PEP 3144?
I think it great that you volunteer to be the PEP czar and hope Guido
appoints you -- especially after your response to Antoine. Since this is
a Python 3 module, let us start off with a mod
On Mon, Feb 20, 2012 at 11:27 PM, Antoine Pitrou wrote:
> IMHO, nesting without a good, consistent, systematic categorization
> leads to very unpleasant results (e.g. "from urllib.request import
> urlopen").
>
> Historically, our stdlib has been flat and I think it should stay so,
> short of redoi
On Mon, Feb 20, 2012 at 16:27, Antoine Pitrou wrote:
>> Should it be net.ipaddress instead of just ipaddress?
>>
>> Somewhat nested is better than fully flat.
>
> IMHO, nesting without a good, consistent, systematic categorization
> leads to very unpleasant results (e.g. "from urllib.request impor
I like 'PEP czar'
On Mon, Feb 20, 2012 at 6:50 PM, Mark Lawrence wrote:
> On 20/02/2012 16:28, Senthil Kumaran wrote:
>>
>> On Tue, Feb 21, 2012 at 12:07 AM, wrote:
>>>
>>> "supreme ruler" sounds good to me. I could go for "inquisitor" instead
>>> of "czar" as well...
>>
>>
>> But that would be
On 20/02/2012 16:28, Senthil Kumaran wrote:
On Tue, Feb 21, 2012 at 12:07 AM, wrote:
"supreme ruler" sounds good to me. I could go for "inquisitor" instead
of "czar" as well...
But that would be bad for developers from Spain as nobody would expect
a spanish inquisition.
:-)
How about Big
On Tue, Feb 21, 2012 at 12:07 AM, wrote:
> "supreme ruler" sounds good to me. I could go for "inquisitor" instead
> of "czar" as well...
But that would be bad for developers from Spain as nobody would expect
a spanish inquisition.
:-)
--
Senthil
___
Does anyone object to me naming myself PEP czar for PEP 3144?
“Tsar is a title used to designate certain European Slavic monarchs or
supreme rulers.”
Is this our official word?
"supreme ruler" sounds good to me. I could go for "inquisitor" instead
of "czar" as well...
Regards,
Martin
___
On Mon, 20 Feb 2012 16:20:15 +0100
Dirkjan Ochtman wrote:
> On Mon, Feb 20, 2012 at 14:23, Nick Coghlan wrote:
> > I don't personally think the module API needs the provisional
> > disclaimer as the core functionality has been tested for years in
> > ipaddr and the API changes in ipaddress are ju
On Mon, Feb 20, 2012 at 14:23, Nick Coghlan wrote:
> I don't personally think the module API needs the provisional
> disclaimer as the core functionality has been tested for years in
> ipaddr and the API changes in ipaddress are just cosmetic ones either
> for PEP 8 conformance, or to make the API
On Mon, Feb 20, 2012 at 11:55 PM, Antoine Pitrou wrote:
> On Mon, 20 Feb 2012 23:23:13 +1000
> Nick Coghlan wrote:
>> Does anyone object to me naming myself PEP czar for PEP 3144?
>
> “Tsar is a title used to designate certain European Slavic monarchs or
> supreme rulers.”
>
> Is this our officia
On Mon, 20 Feb 2012 23:23:13 +1000
Nick Coghlan wrote:
> Does anyone object to me naming myself PEP czar for PEP 3144?
“Tsar is a title used to designate certain European Slavic monarchs or
supreme rulers.”
Is this our official word?
> There's also basic-but-usable module documentation availabl
Does anyone object to me naming myself PEP czar for PEP 3144?
I've collated the objections to the original proposal on a few
different occasions throughout the (long!) PEP review process, and as
noted in the Background section, the latest version of the PEP [1] has
addressed the key concerns that
39 matches
Mail list logo
