Re: [Python-Dev] [Email-SIG] Dropping bytes "support" in json
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 end of the name to get the bytes version (i.e. os.environb). That aligns nicely with the b"" prefix for bytes literals, and isn't much of a typing or reading burden when dealing with the bytes API instead of the text one. A similar naming scheme (i.e. msg.headers and msg.headersb) would probably work for email as well. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping bytes "support" in json
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? Besides, the fact that many values in a typical JSON object will be strings, and must be encoded from/decoded to unicode objects in py3k, suggests that accepting/outputting unicode as default is the laziest (i.e. the best) choice performance-wise. But you don't have to trust me: look at the quick numbers I've posted. The py3k version (in the str-only incarnation I've proposed) is sometimes actually faster than the trunk version: http://mail.python.org/pipermail/python-dev/2009-April/088498.html Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping bytes "support" in json
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, yes, but all too often in a nondeterministic way. That's precisely the problem that the spec is trying to avert. People often schlep "text" around as if that were well-defined, forcing receivers to guess what is meant. Having a spec isn't going to stop them, but at least you can lash them with a wet noodle. The specification of at least the abstract character repertoire and coded character set also allows implementers like Python to proceed confidently with their usual internal encoding. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] How do I update http://www.python.org/dev/faq?
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.html ...still ends up at the 2.5.2 docs. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Test failures on Python 2.7 (trunk)
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 channel
('socket.error'>:[Errno 9] Bad file descriptor
[/Users/chris/py2k/Lib/asyncore.py|readwrite|107]
[/Users/chris/py2k/Lib/asyncore.py|handle_expt_event|441]
[|getsockopt|1] [/Users/chris/py2k/Lib/socket.py|_dummy|165])
...(lots of repeats of the above)
**
test_asyncore
test test_asyncore failed -- Traceback (most recent call last):
File "/Users/chris/py2k/Lib/test/test_asyncore.py", line 144, in
test_readwrite
self.assertEqual(tobj.read, True)
AssertionError: False != True
...
test test_macostools failed -- Traceback (most recent call last):
File "/Users/chris/py2k/Lib/test/test_macostools.py", line 90, in
test_mkalias_relative
macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix)
File "/Users/chris/py2k/Lib/plat-mac/macostools.py", line 40, in mkalias
relativefsr = File.FSRef(relative)
Error: (-35, 'no such volume')
Should I expect these? If so, why?
cheers,
Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Test failure on Py3k branch
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 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
> > > 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 wiki page mentioned in the proposal, along with the use case? Following that, I'll see if I can do anything about it to make it a reality. Cheers, M. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failure on Py3k branch
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 Are you on OS X? This looks like http://bugs.python.org/issue4388 Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failure on Py3k branch
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: 1 != 0 Are you on OS X? This looks like http://bugs.python.org/issue4388 Yup, that looks like it. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] issue5578 - explanation
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. Oh? I don't follow... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures on Python 2.7 (trunk)
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: uncaptured python exception, closing channel > ( 'socket.error'>:[Errno 9] Bad file descriptor > [/Users/chris/py2k/Lib/asyncore.py|readwrite|107] > [/Users/chris/py2k/Lib/asyncore.py|handle_expt_event|441] > [|getsockopt|1] [/Users/chris/py2k/Lib/socket.py|_dummy|165]) > ...(lots of repeats of the above) > ** > test_asyncore > test test_asyncore failed -- Traceback (most recent call last): > File "/Users/chris/py2k/Lib/test/test_asyncore.py", line 144, in > test_readwrite > self.assertEqual(tobj.read, True) > AssertionError: False != True I'm getting the asyncore failure on Linux as well (no unexpected output though - just the final exception). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] issue5578 - explanation
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 ;-) "practicality beats purity" Benjamin? +0 OK, well, I'll use it as my first "test commit" when I get a chance :-) Actually, this was gone on the py3k branch already. I've committed the fix to trunk, is there anything else I need to do? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.2 final
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. There's a fix posted to the issue tracker, but it's not entirely trivial and I think the risk of accidental breakage outweighs the niceness of seeing 'all tests passed' on Solaris. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] email header encoding
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'))
Which you now must *parse* and guess the encoding to determine how to
RFC-2047-encode the binary mush. I think the encoding parameter is
necessary here.
Indeed.
> But it would be far easier to do all the encoding at once in an
> output() or serialize() method. Do different headers need different
> encodings?
You can have multiple encodings within a single header (and a naïve
"can" and "should" are two very different things.
When is it even a good idea to have more than one encoding in a single
header?
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] headers api for email package
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 you have some bytes. You need to end up with bytes in the
ASCII range and you'd like to leave the header value unencoded if so.
But in both cases, you might have bytes or characters outside that
range, so you need an explicit encoding, defaulting to utf-8 probably.
>>> Message.set_header('Subject', 'Some text', encoding='utf-8')
>>> Message.set_header('Subject', b'Some bytes')
Where you just want "a damned valid email and stop making my life hard!":
Message['Subject']='Some text'
Where you care about what encoding is used:
Message['Subject']=Header('Some text',encoding='utf-8')
If you have bytes, for whatever reason:
Message['Subject']=b'some bytes'.decode('utf-8')
...because only you know what encoding those bytes use!
One of those maps to
>>> message['Subject'] = ???
...should only accept text or a Header object.
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Email-SIG] Dropping bytes "support" in json
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' onto the end of the name to get the bytes version (i.e. os.environb). That aligns nicely with the b"" prefix for bytes literals, and isn't much of a typing or reading burden when dealing with the bytes API instead of the text one. A similar naming scheme (i.e. msg.headers and msg.headersb) would probably work for email as well. That just feels nasty though :-( Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping bytes "support" in json
[email protected] 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 headers and bytes_headers? I think bytes headers are evil. If you don't know the encoding when you have one, who does or ever will? message.headers['Subject'] = Header(bytes=b'Some Bytes', encoding='utf-8') Explicit is better than implicit, right? Indeed, and the case for the above would be to keep indempotence of incoming messages in applications like mailman... ...otherwise we could just decode them and be done with it. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do I update http://www.python.org/dev/faq?
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 [email protected] and then send in your SSH key to request commit access to the website. Otherwise, please send your suggested updates to pydotorg. -- Aahz ([email protected]) <*> http://www.pythoncraft.com/ Why is this newsgroup different from all other newsgroups? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test failures on Python 2.7 (trunk)
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: ** error: uncaptured python exception, closing channel (:[Errno 9] Bad file descriptor [/Users/chris/py2k/Lib/asyncore.py|readwrite|107] [/Users/chris/py2k/Lib/asyncore.py|handle_expt_event|441] [|getsockopt|1] [/Users/chris/py2k/Lib/socket.py|_dummy|165]) ...(lots of repeats of the above) ** test_asyncore test test_asyncore failed -- Traceback (most recent call last): File "/Users/chris/py2k/Lib/test/test_asyncore.py", line 144, in test_readwrite self.assertEqual(tobj.read, True) AssertionError: False != True I'm getting the asyncore failure on Linux as well (no unexpected output though - just the final exception). Ditto. I looked at that asyncore traceback yesterday. The way that the flags argument to the readwrite call are propagated to the object was changed, but the tests were not updated to match. I haven't yet gotten as far as figuring out why the changes were made, but svn blames josiah.carlson for the changes (or at least the most recent ones). --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] issue5578 - explanation
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] email header encoding
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyCFunction_* Missing
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 should be for internal use only? I don't think so. PyCFunctions are mentioned in the C API reference, so it seems that these functions simply fall into the regrettably quite large category of public API functions that aren't documented yet. Please open a tracker item and assign it to me, so that I don't forget this. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
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 happy camper. -> > -> Jack, how about you write that idea down on the wiki page mentioned in the -> proposal, along with the use case? Following that, I'll see if I can do -> anything about it to make it a reality. We had a GSoC student two years back who worked on something like this; his name is Michal Kwiatkowski. He probably has the code working somewhere. It's a nontrivial problem if you want to do it properly with VMs etc. cheers, --titus -- C. Titus Brown, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
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. -> -> I don't think these are good "core" projects. Even if the students come -> up with a complete solution, it shouldn't be integrated with the -> standard library right away. Instead, it should have a life outside the -> standard library, and be considered for inclusion only if the user -> community wants it. Tarek has said he can put it into distutils on a trial basis, although I'm sure that'll depend on what the student comes up with. 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 well into "core" territory IMO. -> I'm also skeptical that this is a good SoC project in the first place. -> 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 past attempts at unifying APIs have demonstrated -> that creating them is difficult, and might require writing a PEP -> (whose acceptance then might not happen within a summer). Well, that's a more unassailable argument and one I agree with ;). cheers, --titus -- C. Titus Brown, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
> -> 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 past attempts at unifying APIs have demonstrated > -> that creating them is difficult, and might require writing a PEP > -> (whose acceptance then might not happen within a summer). > > Well, that's a more unassailable argument and one I agree with ;). For this case, the student work is not a "dumb" work consisting of writing code on an already-thaught PEP... Part of the work will consist of working on a PEP-like document, and on building APIs for various keychains and see if we can have an unified one. I doubt the PEP-like document can be written before writing prototypes APIs for various keychains has been done. At the end of the summer, if we come up with a nice unified API, I'd like to include it to Distutils for the "register" command, and maybe write a PEP to have it as part of the standard library because it makes sense to have this kind of feature imho. Tarek ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
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 having to store it in *clear text* in the .pypirc file anymore. 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. " Regards Tarek ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
> 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 well into "core" territory IMO. I understand why Tarek wants it, and I can sympathise with that: to protect PyPI passwords better (they are currently stored on disk in plain). Putting it into distutils might not make it "official API", but then, I think it ought to be official API, since PyPI would be just one (minor) application of it; Python also features a netrc module (which probably nobody uses). So I think it would be good to have a discussion upfront whether this should be added to the library after the summer is over (assuming it actually works by then). Decision to accept it or not as a SoC project is independent, but if accepted, the student should well understand the outcome of this discussion. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
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 the IDLE proposal). I liked the outcome of last year's "memory profiling" project: the student added sys.getsizeof (with much of mentoring on my side), and created a profiling library and application that wasn't added to the core. The latter part is a biased outcome (as I originally hoped to get something that becomes part of the standard library - but gave up on this quickly as way too much design went into that library); the useful core contribution (getsizeof) took considerable amount of learning, and still had a few tricky design issues to resolve. In short, there must be a realistic chance that the code gets actually used. Chances for a from-scratch library to be used are nearly zero, so from-scratch libraries are not good projects. In case you wonder why I give it nearly zero chance: I keep telling long-term contributors that libraries have to be field-tested before being considered for inclusion, and sometimes, even field-testing is not enough (think setuptools). If SoC students get to short-cut the process, that would send a wrong message to contributors and users. > Part of the work will consist of working on a PEP-like document, and on > building APIs for various keychains and see if we can have an unified one. > I doubt the PEP-like document can be written before writing prototypes APIs > for various keychains has been done. That's certainly true. That's why I think it is a much larger project: - write different wrappers - come up with a unifying API - field-test it for actual applications - write a PEP This could easily take a few years to get right (unless the actual authors of the various keychain implementations get together, define a common C API, which then a Python module just needs to wrap). > At the end of the summer, if we come up with a nice unified API, I'd > like to include > it to Distutils for the "register" command, and maybe write a PEP to have it > as part of the standard library because it makes sense to have this kind > of feature imho. I completely agree that this is a useful functionality to have, and I also agree it *eventually* belongs into the standard library. I just don't like the idea of bypassing the proper process by making it part of distutils. This model (I need it, so I add it) made both distutils and setuptools so unmaintainable. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
> 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, people will start using the distutils implementation as if it were official API). Also, if you want it pluggable, you likely come up with *another* ad-hoc plugin system. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Email-SIG] Dropping bytes "support" in json
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. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Email-SIG] Dropping bytes "support" in json
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 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 end of the name to get the bytes version (i.e. >> os.environb). >> >> That aligns nicely with the b"" prefix for bytes literals, and isn't >> much of a typing or reading burden when dealing with the bytes API >> instead of the text one. >> >> A similar naming scheme (i.e. msg.headers and msg.headersb) would >> probably work for email as well. >> > > That just feels nasty though :-( > > Chris > > -- > Simplistix - Content Management, Zope & Python Consulting > - http://www.simplistix.co.uk > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brian.curtin%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping bytes "support" in json
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 optimization the root of all evil? Besides, the fact that many values in a typical JSON object will be strings, and must be encoded from/decoded to unicode objects in py3k, suggests that accepting/outputting unicode as default is the laziest (i.e. the best) choice performance-wise. I don't see it as premature optimization, but rather trying to ensure the interface/api best suits the actual use cases. But you don't have to trust me: look at the quick numbers I've posted. The py3k version (in the str-only incarnation I've proposed) is sometimes actually faster than the trunk version: http://mail.python.org/pipermail/python-dev/2009-April/088498.html But if all *actual* use-cases involve moving to and from utf8 encoded bytes, I'm not sure that little example is particularly useful. In those use-cases, I'd be surprised if there wasn't significant time and space benefits in not asking apps to use an 'intermediate' string object before getting the bytes they need, particularly when the payload may be a significant size. Assuming the above is all true, I'd see choosing bytes less as a premature optimization and more a design choice which best supports actual use. So to my mind the only real question is whether the above *is* true, or if there are common use-cases which don't involve utf8-off/on-the-wire... Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google Summer of Code/core Python projects - RFC
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 a family vacation, returning online the week of 20 Apr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
