Re: [Python-Dev] 3to2 0.1 alpha 1 released

On Thu, Aug 27, 2009 at 6:48 PM, Brett Cannon wrote: > On Thu, Aug 27, 2009 at 14:47, Benjamin Peterson > wrote: > > 2009/8/27 Brett Cannon : > >> What are the plans to merge this into Python's repository so we can > >> all help out on this? > > > > None at the moment. I think the community needs

Re: [Python-Dev] 3to2 0.1 alpha 1 released

On Thu, Aug 27, 2009 at 4:08 PM, Benjamin Peterson wrote: > 2009/8/26 Joe Amenta : > > Hello all, > > > > I have released the first alpha version of 3to2 after finishing it for my > > Google Summer of Code 2009(tm) project. You can get the tarball for this > > release at > > http://bitbucket.org/

Re: [Python-Dev] quick PEP 387 comments

On 12:49 am, benja...@python.org wrote: I should probably mark that PEP as abandoned or deferred, since for various reasons, it seems like this is not what Python-dev feels is needed [1]. Re-reading that thread, I see some good discussion about how to improve the PEP, a little bit of misunders

Re: [Python-Dev] 3to2 0.1 alpha 1 released

On Thu, Aug 27, 2009 at 7:43 PM, "Martin v. Löwis" wrote: >>> None at the moment. I think the community needs to show its interest >>> in it and Joe his willingness to maintain it in the future in order >>> for it to qualify for addition to the stdlib. >> >> Is that how 2to3 got in? If I remember c

Re: [Python-Dev] quick PEP 387 comments

I should probably mark that PEP as abandoned or deferred, since for various reasons, it seems like this is not what Python-dev feels is needed [1]. [1] http://mail.python.org/pipermail/python-dev/2009-June/090121.html 2009/8/27 Brett Cannon : > Is the PEP considering all non-private APIs public e

Re: [Python-Dev] 3to2 0.1 alpha 1 released

> How about moving it to a new repository on hg.python.org > ? Give it more of an "official" feel without the > burden of being in theb cpython tree? Unfortunately, this is not yet set up (i.e. you can't push to it). Regards, Martin _

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

> IPv6Address.is_ipv4_compat > IPv6Network.is_ipv4_compat > > Returns True if this address/network is IPv4-compatible IPv6 e.g. > ::192.0.2.0 or ::192.0.2.0/124 , False otherwise. -1. These addresses are deprecated. > IPv6Address.is_ipv4_mapped > IPv6Network.is_ipv4_mapped

Re: [Python-Dev] 3to2 0.1 alpha 1 released

How about moving it to a new repository on hg.python.org? Give it more of an "official" feel without the burden of being in theb cpython tree? On Thu, Aug 27, 2009 at 7:43 PM, "Martin v. Löwis" wrote: > > Ok, so then it should be easy to generate some real interest out of > it, right? E.g. a som

[Python-Dev] quick PEP 387 comments

Is the PEP considering all non-private APIs public even if they are not documented? If so we might want to be up front about that and say so to make sure we are all very careful about making all non-essential APIs private (assuming this PEP gets accepted). And we might want to say that all code in

Re: [Python-Dev] 3to2 0.1 alpha 1 released

>> None at the moment. I think the community needs to show its interest >> in it and Joe his willingness to maintain it in the future in order >> for it to qualify for addition to the stdlib. > > Is that how 2to3 got in? If I remember correctly, this was a huge > request from the language summit -

Re: [Python-Dev] 3to2 0.1 alpha 1 released

2009/8/27 Jesse Noller : > On Thu, Aug 27, 2009 at 5:47 PM, Benjamin Peterson wrote: >> 2009/8/27 Brett Cannon : >>> What are the plans to merge this into Python's repository so we can >>> all help out on this? >> >> None at the moment. I think the community needs to show its interest >> in it and

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

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

Re: [Python-Dev] 3to2 0.1 alpha 1 released

On Thu, Aug 27, 2009 at 14:47, Benjamin Peterson wrote: > 2009/8/27 Brett Cannon : >> What are the plans to merge this into Python's repository so we can >> all help out on this? > > None at the moment. I think the community needs to show its interest > in it and Joe his willingness to maintain it

Re: [Python-Dev] 3to2 0.1 alpha 1 released

On Thu, Aug 27, 2009 at 5:47 PM, Benjamin Peterson wrote: > 2009/8/27 Brett Cannon : >> What are the plans to merge this into Python's repository so we can >> all help out on this? > > None at the moment. I think the community needs to show its interest > in it and Joe his willingness to maintain i

[Python-Dev] deprecated methods on array objects

The python documentation says that the read() and write() methods on array objects have been deprecated since 1.5.1. I assume this is because their semantics are almost the exact opposite of read() and write() on a file-like object; array.read() reads data from a file into the array and array.writ

Re: [Python-Dev] 3to2 0.1 alpha 1 released

2009/8/27 Brett Cannon : > What are the plans to merge this into Python's repository so we can > all help out on this? None at the moment. I think the community needs to show its interest in it and Joe his willingness to maintain it in the future in order for it to qualify for addition to the stdl

Re: [Python-Dev] 3to2 0.1 alpha 1 released

What are the plans to merge this into Python's repository so we can all help out on this? On Thu, Aug 27, 2009 at 13:08, Benjamin Peterson wrote: > 2009/8/26 Joe Amenta : >> Hello all, >> >> I have released the first alpha version of 3to2 after finishing it for my >> Google Summer of Code 2009(tm)

Re: [Python-Dev] 3to2 0.1 alpha 1 released

2009/8/26 Joe Amenta : > Hello all, > > I have released the first alpha version of 3to2 after finishing it for my > Google Summer of Code 2009(tm) project.  You can get the tarball for this > release at > http://bitbucket.org/amentajo/lib3to2/downloads/3to2_0.1-alpha1.tar.gz. > This requires python

Re: [Python-Dev] 3to2 0.1 alpha 1 released

On Wed, Aug 26, 2009 at 3:29 PM, Joe Amenta wrote: > Hello all, > > I have released the first alpha version of 3to2 after finishing it for my > Google Summer of Code 2009(tm) project. Wow, congratulations! -Frank ___ Python-Dev mailing list Python-Dev@p

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

On Thu, Aug 27, 2009 at 10:37 AM, Peter Moody wrote: > On Thu, Aug 27, 2009 at 10:24 AM, David Moss wrote: >> Peter, >> >> I would like to apologise if I have caused you any offense. > > Thanks. Accepted. > >> Please can we >> put the animosity behind us and stick to pulling together the best IP >>

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

On Thu, Aug 27, 2009 at 10:24 AM, David Moss wrote: > Peter, > > I would like to apologise if I have caused you any offense. Thanks. Accepted. > Please can we > put the animosity behind us and stick to pulling together the best IP > library possible as part of this PEP? pep-3144 should hopefully

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

Peter, I would like to apologise if I have caused you any offense. Please can we put the animosity behind us and stick to pulling together the best IP library possible as part of this PEP? Regards, Dave M. ___ Python-Dev mailing list Python-Dev@p

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

2009/8/27 Barry Warsaw : > On Aug 27, 2009, at 9:08 AM, exar...@twistedmatrix.com wrote: > >> This is what I meant when I said what I said about correct code.  If you're >> happy to have encoding errors and corrupt data, then I guess you're happy to >> have a function like setdefaultencoding. > >

Re: [Python-Dev] 3to2 0.1 alpha 1 released

Congratulations and thank you - this is *great* news. Michael Joe Amenta wrote: Hello all, I have released the first alpha version of 3to2 after finishing it for my Google Summer of Code 2009(tm) project. You can get the tarball for this release at http://bitbucket.org/amentajo/lib3to2/dow

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

On Aug 27, 2009, at 9:08 AM, exar...@twistedmatrix.com wrote: This is what I meant when I said what I said about correct code. If you're happy to have encoding errors and corrupt data, then I guess you're happy to have a function like setdefaultencoding. Whatever happened to "we're all adu

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

On Wed, Aug 26, 2009 at 4:48 PM, DrKJam wrote: > 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

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

Howdy folks, the reference code has been updated per your comments; specifically, there's no more IP/IPv4/IPv6 factory functions, it's all IPAddress() and IPNetwork constructors. I've submitted a patch to the PEP with updated examples and a lengthy description of the class inheritance and the ben

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

DrKJam wrote: > Currently I'm ambivalent on whether an IP(vX)Network class constructor > should accept a numerical (i.e. integer) value at all *unless* you > explicit state somehow that you want the network aspect to be inferred > in some specific way. It isn't a case of just choosing /32 or /128 a

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

On 26 Aug, 11:51 pm, ch...@simplistix.co.uk wrote: exar...@twistedmatrix.com wrote: The ability to change the default encoding is a misfeature. There's essentially no way to write correct Python code in the presence of this feature. How so? If every single piece of text in your project is en

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

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 thread, perhaps >

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

Chris Withers writes: > > How can you be certain that any string is UTF-8 when doing any > > reasonable IO? > > Careful checking, and a knowledge for people working on the app's > development that anything else will result in severe pain, both physical > and mental ;-) If you're *that* c

Re: [Python-Dev] Excluding the current path from module search path?

Chris Withers wrote: > Nick Coghlan wrote: >> The details of the sys.path manipulation at program startup are >> documented here: >> http://docs.python.org/using/cmdline.html#command-line >> >> The directory prepended to sys.path is based on the code executed by the >> command line. > > It's more

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

s...@pobox.com wrote: > Martin> I think it's too early to tell. It may be that they have not yet > Martin> achieved their purpose - just let's wait fifty more years (and > Martin> I'm only half-joking). > > So what you're really saying is we only have to wait 25 years... :) Martin ha

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

Ben Finney wrote: > Antoine Pitrou writes: > >> DrKJam gmail.com> writes: >>> netaddr employs a simple variant of the GoF Strategy design pattern (with >> added Python sensibility). >> >> It would be nice if you could avoid employing this kind of acronyms >> without explaining them. Not everybod

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

Chris Withers wrote: > M.-A. Lemburg wrote: >> Let's look at this from another angle: sys.setdefaultencoding() >> is only made available for use in site.py. > > ...see this: > > http://mail.python.org/pipermail/python-dev/2009-August/091391.html > > I would like to use sitecustomize.py for all

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

> if hasattr(sys, "setdefaultencoding"): > +sys._setdefaultencoding = sys.setdefaultencoding > del sys.setdefaultencoding Ah, so you didn't want to rename the function. I agree that this would not break backwards compatibility. I guess the basic objection remains: making it

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

Ben Finney writes: > A pity, since the entire point of Design Patterns is to give us a > vocabulary of terms to use that enable these concepts to be communicated > *without* continually re-defining them. To that extent, then, they fail > their purpose. Of course not! There will always be chi

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

>> One specific problem is dictionaries will stop working correctly if you >> set the default encoding to anything but ASCII. > > ...except they haven't. In your application. Can you please agree that this a semantical problem that is completely unacceptable for language design? > Indeed, but t

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

Martin v. Löwis wrote: - If people were somehow relying on sys not having an attribute called _setdefaultencoding, or were relying on stuffing an attribute into sys called _setdefaultencoding then... well... that seems pretty unlikely ;-) If people were using the reload trickery, that would bre

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

Chris Withers wrote: > Martin v. Löwis wrote: In retrospect, it should have been called sys._setdefaultencoding(). That sends an extra signal that it's not meant for general use. >>> Crazy idea: how about mutating it into sys._setdefaultencoding rather >>> than deleting it? >> >> Please d

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

Martin v. Löwis wrote: The ability to change the default encoding is a misfeature. There's essentially no way to write correct Python code in the presence of this feature. How so? If every single piece of text in your project is encoded in a superset of ascii (such as utf-8), why would this be

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

Martin v. Löwis wrote: In retrospect, it should have been called sys._setdefaultencoding(). That sends an extra signal that it's not meant for general use. Crazy idea: how about mutating it into sys._setdefaultencoding rather than deleting it? Please don't post crazy ideas unless you really me