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
On Fri, Apr 10, 2009 at 9:58 PM, Harry (Thiago Leucz Astrizi)
thiagoha...@riseup.net wrote:
Hello everybody. My name is Thiago and currently I'm working as a
teacher in a high school in Brazil. I have plans to offer in the
school a programming course to the students, but I had some problems
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
Martin v. Löwis martin at 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?
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,
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:
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
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
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
On Sat, Apr 11, 2009 at 11:14 AM, Chris Withers ch...@simplistix.co.uk 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)
Mark Dickinson wrote:
On Sat, Apr 11, 2009 at 11:14 AM, Chris Withers ch...@simplistix.co.uk 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
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.
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
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 ;-)
On Fri, Apr 10, 2009 at 2:31 PM, Barry Warsaw ba...@python.org 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
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'))
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
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
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
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:
2009/4/11 Chris Withers ch...@simplistix.co.uk:
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
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
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
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
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
- 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
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
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
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
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,
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.
--
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 ch...@simplistix.co.ukwrote:
Nick Coghlan wrote:
Barry Warsaw
On 11/04/2009 6:12 PM, Antoine Pitrou wrote:
Martin v. Löwismartinat 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
On Fri, Apr 10, 2009 at 4:38 PM, C. Titus Brown c...@msu.edu 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
34 matches
Mail list logo
