Would it be possible to have trove classifiers added to PyPI specifically
for PyPy and possibly also Jython and IronPython?
Regards,
David Moss
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
2009/9/28 Peter Moody
> [cc += david moss]
>
> On Mon, Sep 28, 2009 at 9:39 AM, Guido van Rossum
> wrote:
> > On Sun, Sep 27, 2009 at 5:32 PM, Antoine Pitrou
> wrote:
> >> Peter Moody hda3.com> writes:
> >>>
> >>> I've never said otherwise. In fact, from an email last night, "If what
> >>> the
2009/9/26 Daniel Stutzbach
> On Sat, Sep 26, 2009 at 2:07 PM, DrKJam wrote:
>
>> The current version of the PEP and reference implementation do not mention
>> or deal with IPv4 classful addressing (A, B, C, D and E). It would be good
>> to know if any of this (admi
Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/drkjam%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
t to discard these bits (or at least
Cisco does when adding routes). For configuring a network interface you
would most certainly want to keep them!
> Cheers,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
> ---
> ___
> Python-Dev mailing lis
Please can we have the following RFCs added to the references section that
cover many of the aspects covered by this PEP?
RFC 791 - Internet Protocol
RFC 1918 - Address Allocation for Private Internets
RFC 3330 - Special-Use IPv4 Addresses
RFC 4291 - IPv6 Addressing Architecture
RFC 4632 - Classle
I've posted several of issues to the ipaddr bug tracker for consideration.
They shouldn't be major discussion topics so I'll leave them off the list.
The following are a few feature requests that might possibly require further
discussion here. If they are no-brainers that don't require any further
2009/8/25 Peter Moody
> On Mon, Aug 24, 2009 at 3:24 PM, DrKJam wrote:
>
[SNIP]
> As it was left in early June, a pep and design modifications were
> requested before ipaddr would be considered for inclusion, but if this
> is going to start *another* drawn out ipaddr/netaddr
I've started a very basic (work in progress) entry on the netaddr wiki to
track various aspects of this discussion that might not be in a format
suitable for publishing to the list or are too lengthy. It will also allow
my ascii art diagrams to render correctly ;-)
http://code.google.com/p/netaddr
Good evening fellow Pythonistas,
Considering a PEP is now available I'd like to join this discussion and
raise several points with regard to both the PEP and the ipaddr reference
implementation put forward with it.
1) Firstly, an offering of code.
I'd like to bring to your attention an example i
I've just subscribed to python-dev again after being pointed towards this
thread (thanks Raymond).
I'd be the first to accept failings and oddities in the interface of my own
library. Since its release netaddr has taken its own interesting set of
twists and turns. However, all along I have tried t
2009/1/14 DrKJam
> Are there any current plans for 2.7/3.1 to have inet_pton() and inet_ntop()
> made available via the socket module?
>
> Not sure how feasible or difficult doing this would be across all support
> Python platforms but it would certainly be useful, especially now
Are there any current plans for 2.7/3.1 to have inet_pton() and inet_ntop()
made available via the socket module?
Not sure how feasible or difficult doing this would be across all support
Python platforms but it would certainly be useful, especially now there is
talk about adding IPv4/IPv6 address
A merger sounds like a good way forward.
It shouldn't be as painful as it might sound initially and there should be
lots of room for some early big wins.
Contentious Issues
--
*** Separate IP and CIDR classes
The IP and CIDR object split in netaddr is going to require some furth
14 matches
Mail list logo
