Mailman 3 September 2011 - Python-ideas

Re: [Python-ideas] IP addressing library, aka reviving PEP 3144 (Re: Add from __experimental__ import bla)
by Nick Coghlan 02 Sep '11

02 Sep '11

On Fri, Sep 2, 2011 at 8:03 AM, Peter Moody <pmoody(a)google.com> wrote: > I'll make an implementation with these changes this weekend. Great to hear! > It sounds like it's going to be clunky, but that's definitely with a grain or two of bias. Hopefully it won't be too inconvenient - in theory, it just means that when you derive the network details from a host address and masking information you can't throw the original host address information away any more (since IPNetwork own't be keeping it around). > Documentation isn't my strong suit, but assuming the implementation is > palatable to all involved, that can be forthcoming as well. Splitting the API up a little should actually make the documentation task itself easier. For folks that are already familiar with networking concepts, it isn't that hard to mentally map the "IPNetwork" name as meaning "either an actual IP network or else an arbitrary host/netmask pair". We might grumble about it (*cough*), but we wouldn't be confused once we made the connection. However, once ipaddr goes into the standard library, its module documentation is going to be the first introduction many future Python programmers will have to the details of how IP addressing actually works. We'll refer them off to other resources, of course, but having clean semantics in the API itself is important in helping people that are *not* already networking experts use the module correctly. That means having the class model map cleanly to the real world entities it represents, and while IP networks and specific interfaces on those networks are both represented accurately by the combination of an IP address with masking information, they're *not* the same kind of thing. It's the difference between using Pair(a, b) for both 2-D coordinates and rational numbers vs using separate Point(x, y) and Rational(n, d) classes. Yes, the information stored in both cases is the same, but the semantics assigned to that information changes. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

Re: [Python-ideas] Create a StringBuilder class and use it everywhere
by k_bx 02 Sep '11

02 Sep '11

> This doesn't seem nicer to read and write to me than the list form. I > also do not see any reason to believe it will stop people from doing > it the quadratic way if the ubiquitous make-a-list-then-join idiom > does not. The whole point is that people don't write u''.join idiom just because they don't know it is slow. And when they see StringBuilder -- they can ask themselves "why is he using that". I don't mind using u''.join, but it just doesn't make people think about speed at all. The most popular (as from what I can see) thing right now where people start seeing that += is slow is when they try to do that on PyPy (which doesn't have hack like CPython, who is still slow) and ask "why my pypy code is sooooo slow". With StringBuilder used widely that would not be the case.

14 19

Add from __experimental__ import bla [was: Should we move to replace re with regex?]
by Dj Gilcrease 01 Sep '11

01 Sep '11

In the thread about replacing re with regex someone mentioned adding to __future__ which isnt a great idea as future APIs are already solidified, they just live there to give developer time to adapt their code. The idea of a __experimental__ area is good for any pep's or stliib additions that are somewhat controversial (API isnt agreed on, code may take a while to integrate properly, developer wants some time to hash out any edge case bugs or API clarifications that may come up in large scale testing, etc). __experimental__ should emit a warning on import that says anything in here may change or be removed at any time and should not be used in stable code. __experimental__ features should behave the same as __future__ in that they can add new keywords or semantics to the existing language __experimental__ features can move directly to the stlib or builtins if they do not add new keywords and/or are backwards compatible with the feature they are replacing. Otherwise they move into __future__ for how ever many releases are deemed reasonable time for developers to adapt their code.

20 52

Re: [Python-ideas] aliasing
by Christopher King 01 Sep '11

01 Sep '11

Wrong list again On Thu, Sep 1, 2011 at 4:10 PM, Christopher King <g.nius.ck(a)gmail.com>wrote: > ------------------------ >> >>> list = [3,] >> >>> a = list >> >>> list[0] = 6 >> >>> a[0] >> 3 >> ------------------------- >> > Slight error in my code. It should be. > ------------------------ > >>> list = [3,] > >>> a = list > >>> list[0] = 6 > >>> a[0] > 6 > ------------------------- >

1 0