Re: [Python-Dev] Google Summer of Code/core Python projects - RFC

2009-04-11 Thread Ron DuPlain
On Fri, Apr 10, 2009 at 4:38 PM, C. Titus Brown wrote: > Unquestionably "core" by my criteria above: > > 3to2 tool -- 'nuff said. I worked on the 3to2 tool during the sprint last week at PyCon. I can chip in for GSoC in the event it does get picked up. -Ron PS - I'm out of town next week for

Re: [Python-Dev] Dropping bytes "support" in json

2009-04-11 Thread Mark Hammond
On 11/04/2009 6:12 PM, Antoine Pitrou wrote: Martin v. Löwis v.loewis.de> writes: Not sure whether it would be *significantly* faster, but yes, Bob wrote an accelerator for parsing out of a byte string to make it really fast; IIRC, he claims that it is faster than pickling. Isn't premature o

Re: [Python-Dev] [Email-SIG] Dropping bytes "support" in json

2009-04-11 Thread cur...@acm.org
FWIW, that is also the way things are done in the pickle/cPickle module. dump/dumps and load/loads to differentiate between the file object and string ways of using that functionality. On Sat, Apr 11, 2009 at 7:41 AM, Chris Withers wrote: > Nick Coghlan wrote: > >> Barry Warsaw wrote: >> >>> Of c

Re: [Python-Dev] [Email-SIG] Dropping bytes "support" in json

2009-04-11 Thread Greg Ewing
Chris Withers wrote: Nick Coghlan wrote: A similar naming scheme (i.e. msg.headers and msg.headersb) would probably work for email as well. That just feels nasty though :-( It does tend to look like a typo to me. Inserting an underscore (headers_b) would make it look less accidental. -- Gr

Re: [Python-Dev] Google Summer of Code/core Python projects - RFC

2009-04-11 Thread Martin v. Löwis
> The student will also provide some plugins for a maximum number of > existing keyring systems. > Some of these plugins might be included in Distutils, and some of them > in a third-party package. This is slightly better, but see my previous message (that is feature creep in distutils, and likely

Re: [Python-Dev] Google Summer of Code/core Python projects - RFC

2009-04-11 Thread Martin v. Löwis
Tarek Ziadé wrote: >> -> I'm also skeptical that this is a good SoC project in the first place. > > What is a good SoC project from your point of view ? As a core project - tricky. Implement some long-standing complex feature request, or fix a pile of outstanding bug reports for a module (like th

Re: [Python-Dev] Google Summer of Code/core Python projects - RFC

2009-04-11 Thread Martin v. Löwis
> I'm using "core projects" as a shorthand for projects that directly > address the core development environment, the stdlib, and priorities of > committers on python-dev. Tarek is a committer, and it sounded like > you, Jim, and Georg were all interested in this project, too -- that > pushes it w

Re: [Python-Dev] Google Summer of Code/core Python projects - RFC

2009-04-11 Thread Tarek Ziadé
Ok what about this then: I am changing the scope a little bit, and I think the students will be fine with this change since it's the same work. "The project will consist of creating a plugin system into Distutils to be able to store and retrieve the username/password used by some commands, without

Re: [Python-Dev] Google Summer of Code/core Python projects - RFC

2009-04-11 Thread Tarek Ziadé
> -> I'm also skeptical that this is a good SoC project in the first place. What is a good SoC project from your point of view ? > -> Coming up with a wrapper for, say, Apple Keychain, could be a good > -> project. Coming up with a unifying API for all keychains is out of > -> scope, IMO; various

Re: [Python-Dev] Google Summer of Code/core Python projects - RFC

2009-04-11 Thread C. Titus Brown
On Sat, Apr 11, 2009 at 08:13:35AM +0200, "Martin v. L?wis" wrote: -> > 2x "keyring package" -- see -> > http://tarekziade.wordpress.com/2009/03/27/pycon-hallway-session-1-a-keyring-library-for-python/. -> > The poorer one of these will probably be axed unless Tarek gives it -> > strong support. -

Re: [Python-Dev] Google Summer of Code/core Python projects - RFC

2009-04-11 Thread C. Titus Brown
On Sat, Apr 11, 2009 at 12:21:18PM +0200, Mario wrote: -> > He says vague things about patches too, but I'm not sure what. If he -> > wanted to make that into a 'patchbot' that just applied every patch in -> > isolation and ran 'make && make test' and posted results in the -> > tracker I'd be a ha

Re: [Python-Dev] PyCFunction_* Missing

2009-04-11 Thread Georg Brandl
Campbell Barton schrieb: > Hi, Just noticed the new Python 2.6.2 docs now dont have any reference to > * PyCFunction_New > * PyCFunction_NewEx > * PyCFunction_Check > * PyCFunction_Call > > Ofcourse these are still in the source code but Im wondering if this > is intentional that these functions s

Re: [Python-Dev] email header encoding

2009-04-11 Thread Stephen J. Turnbull
Chris Withers writes: > When is it even a good idea to have more than one encoding in a single > header? I'd be happy to discuss that on email-sig, but it's really OT for Python-Dev at this point. ___ Python-Dev mailing list Python-Dev@python.org htt

Re: [Python-Dev] issue5578 - explanation

2009-04-11 Thread Benjamin Peterson
2009/4/11 Chris Withers : > Actually, this was gone on the py3k branch already. > > I've committed the fix to trunk, is there anything else I need to do? Since it's not in py3k, I think not. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@

Re: [Python-Dev] Test failures on Python 2.7 (trunk)

2009-04-11 Thread R. David Murray
On Sat, 11 Apr 2009 at 21:10, Nick Coghlan wrote: Chris Withers wrote: Hi All, Got these when running from checkout on Mac OS: Could not find '/Users/chris/py2k/Lib/test' in sys.path to remove it ... test test_asynchat produced unexpected output: ***

Re: [Python-Dev] How do I update http://www.python.org/dev/faq?

2009-04-11 Thread Aahz
On Sat, Apr 11, 2009, Chris Withers wrote: > > How do I update the faq on the website? Brett Cannon has been the primary maintainer, but he's offline for a while; are you interested in picking up the task? If yes, please subscribe to pydot...@python.org and then send in your SSH key to request co

Re: [Python-Dev] Dropping bytes "support" in json

2009-04-11 Thread Chris Withers
gl...@divmod.com wrote: My preference would be that message.headers['Subject'] = b'Some Bytes' would simply raise an exception. If you've got some bytes, you should instead do message.bytes_headers['Subject'] = b'Some Bytes' Remind me again why you need to differentiate between hea

Re: [Python-Dev] [Email-SIG] Dropping bytes "support" in json

2009-04-11 Thread Chris Withers
Nick Coghlan wrote: Barry Warsaw wrote: Of course, one could use message.header and message.bythdr and they'd be the same length. I was trying to figure out what a 'thdr' was that we'd want to index 'by' it. :) In the discussions about os.environ, the suggested approach was to just tack a 'b

Re: [Python-Dev] headers api for email package

2009-04-11 Thread Chris Withers
Barry Warsaw wrote: >>> message['Subject'] The raw bytes or the decoded unicode? A header object. Okay, so you've picked one. Now how do you spell the other way? str(message['Subject']) bytes(message['Subject']) Now, setting headers. Sometimes you have some unicode thing and sometimes

Re: [Python-Dev] email header encoding

2009-04-11 Thread Chris Withers
Stephen J. Turnbull wrote: Robert Brewer writes: > Syntactically, there's no sense in providing: > > Message.set_header('Subject', 'Some text', encoding='utf-16') > > ...since you could more clearly write the same as: > > Message.set_header('Subject', 'Some text'.encode('utf-16

Re: [Python-Dev] Python 2.6.2 final

2009-04-11 Thread Mark Dickinson
On Fri, Apr 10, 2009 at 2:31 PM, Barry Warsaw wrote: > bugs.python.org is apparently down right now, but I set issue 5724 to > release blocker for 2.6.2.  This is waiting for input from Mark Dickinson, > and it relates to test_cmath failing on Solaris 10. I'd prefer to leave this alone for 2.6.2.

Re: [Python-Dev] issue5578 - explanation

2009-04-11 Thread Chris Withers
Chris Withers wrote: Benjamin Peterson wrote: Assuming it breaks no tests, would there be objection to me committing the above change to the Python 3 trunk? That's up to Benjamin. Personally, I live by "if it ain't broke, don't fix it." :-) Anything using an exec is broken by definition ;-)

Re: [Python-Dev] Test failures on Python 2.7 (trunk)

2009-04-11 Thread Nick Coghlan
Chris Withers wrote: > Hi All, > > Got these when running from checkout on Mac OS: > > Could not find '/Users/chris/py2k/Lib/test' in sys.path to remove it > ... > test test_asynchat produced unexpected output: > ** > error: unca

Re: [Python-Dev] issue5578 - explanation

2009-04-11 Thread Chris Withers
Steve Holden wrote: Anything using an exec that can be done in some other (more pythonic way) There's *always* another way ;-) is broken by definition ;-) Benjamin? We've just had a fairly clear demonstration that small semantic changes to the language can leave unexpected areas borked.

Re: [Python-Dev] Test failure on Py3k branch

2009-04-11 Thread Chris Withers
Mark Dickinson wrote: On Sat, Apr 11, 2009 at 11:14 AM, Chris Withers wrote: Also got the following failure from a py3k checkout: test test_cmd_line failed -- Traceback (most recent call last): File "/Users/chris/py3k/Lib/test/test_cmd_line.py", line 143, in test_run_code 0) AssertionError

Re: [Python-Dev] Test failure on Py3k branch

2009-04-11 Thread Mark Dickinson
On Sat, Apr 11, 2009 at 11:14 AM, Chris Withers wrote: > Also got the following failure from a py3k checkout: > > test test_cmd_line failed -- Traceback (most recent call last): >  File "/Users/chris/py3k/Lib/test/test_cmd_line.py", line 143, in > test_run_code >    0) > AssertionError: 1 != 0 Ar

Re: [Python-Dev] Google Summer of Code/core Python projects - RFC

2009-04-11 Thread Mario
> > > He says vague things about patches too, but I'm not sure what. If he > wanted to make that into a 'patchbot' that just applied every patch in > isolation and ran 'make && make test' and posted results in the > tracker I'd be a happy camper. > > Jack, how about you write that idea down on the

[Python-Dev] Test failure on Py3k branch

2009-04-11 Thread Chris Withers
Hi All, Also got the following failure from a py3k checkout: test test_cmd_line failed -- Traceback (most recent call last): File "/Users/chris/py3k/Lib/test/test_cmd_line.py", line 143, in test_run_code 0) AssertionError: 1 != 0 Should I expect this or does someone owe beer? ;-) Chris

[Python-Dev] Test failures on Python 2.7 (trunk)

2009-04-11 Thread Chris Withers
Hi All, Got these when running from checkout on Mac OS: Could not find '/Users/chris/py2k/Lib/test' in sys.path to remove it ... test test_asynchat produced unexpected output: ** error: uncaptured python exception, closing chann

[Python-Dev] How do I update http://www.python.org/dev/faq?

2009-04-11 Thread Chris Withers
Hi All, How do I update the faq on the website? This section: http://python.org/dev/faq/#how-to-test-a-patch ...could do with fleshing out from this discussion: http://mail.python.org/pipermail/python-dev/2009-March/086771.html ...and the link to: http://www.python.org/doc/lib/module-test.h

Re: [Python-Dev] Dropping bytes "support" in json

2009-04-11 Thread Stephen J. Turnbull
Greg Ewing writes: > The reason you use a text format in the first place is that > you have some way of transmitting text, and you want to > send something that isn't text. In that situation, the > encoding is already determined by whatever means you're > using to send the text. Determined,

Re: [Python-Dev] Dropping bytes "support" in json

2009-04-11 Thread Antoine Pitrou
Martin v. Löwis v.loewis.de> writes: > > Not sure whether it would be *significantly* faster, but yes, Bob wrote > an accelerator for parsing out of a byte string to make it really fast; > IIRC, he claims that it is faster than pickling. Isn't premature optimization the root of all evil? Beside

Re: [Python-Dev] [Email-SIG] Dropping bytes "support" in json

2009-04-11 Thread Nick Coghlan
Barry Warsaw wrote: >> Of course, one could use message.header and message.bythdr and they'd >> be the same length. > > I was trying to figure out what a 'thdr' was that we'd want to index > 'by' it. :) In the discussions about os.environ, the suggested approach was to just tack a 'b' onto the e