If you build python (at least 2.6.5, but probably other versions as
well) in a universal setup using the following command (or similar)
while the machine currently has 10.6 installed:
./configure --with-universal-archs=doesn't matter
--enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk/
then the
On Thu, 07 Oct 2010 03:31:34 +0900, Stephen J. Turnbull step...@xemacs.org
wrote:
R. David Murray writes:
5. Return the content, with non-ASCII bytes replaced with ?
characters.
That hadn't occurred to me (and it makes me sick to contemplate it).
That said, this is probably
Soliciting opinions on issue 2142 (http://bugs.python.org/issue2142).
There are patched available so this isn't vapour. :)
The issue is this (I'll discuss only unified_diff(), but the same
applies to context_diff()):
from difflib import *
gen = unified_diff(one\ntwo\nthree.splitlines(1),
...
Stephen J. Turnbull stephen at xemacs.org writes:
R. David Murray writes:
We're (in the current patch) not punting on handling non-conforming
email, we're punting on handling non-conforming bytes *if the headers
that contain them need to be modified*. The headers can still be
On 6 Oct, 2010, at 22:26, Arnaud Bergeron wrote:
If you build python (at least 2.6.5, but probably other versions as
well) in a universal setup using the following command (or similar)
while the machine currently has 10.6 installed:
./configure --with-universal-archs=doesn't matter
Greetings Python developers,
We, Montréal-Python, are the coordinators of the Python track at
ConFoo 2011 and we are very proud to announce our call for speakers.
PHP-Québec, Montréal-Python, Montreal.rb, W3Qc, and OWASP Montréal are
organizing the first edition of the ConFoo conference, which
Hi!
I'm running newspipe-1.1.9, an RSS reader
(http://newspipe.sourceforge.net/), on NetBSD-5.99.11/amd64 using
Python-2.6.6.
Sometimes, it core dumps with particular feeds in the configuration (I
guess depending on the feed, because when I comment out the offending
feed in the opml file, it
On Wed, 06 Oct 2010 15:53:59 -0700, Trent Mick tre...@gmail.com wrote:
Soliciting opinions on issue 2142 (http://bugs.python.org/issue2142).
There are patched available so this isn't vapour. :)
[...]
Possiblities:
1. Change `difflib.unified_diff` to emit:
['--- \n', '+++ \n', '@@
On Thu, Oct 7, 2010 at 00:53, Trent Mick tre...@gmail.com wrote:
1. Change `difflib.unified_diff` to emit:
['--- \n', '+++ \n', '@@ -1,3 +1,3 @@\n', ' one\n', ' two\n',
'-three\n', '\ No newline at end of file', '+trois\n', '\ No newline
at end of file']
instead of:
['--- \n',
On Thu, 07 Oct 2010 15:00:04 +0900, Stephen J. Turnbull step...@xemacs.org
wrote:
R. David Murray writes:
But that's not interesting; you did that with Python 3. We want to
Of course I did it with Python3. It's the Python3 email codebase
I'm working with (and have to work
Hi,
A PYTHONFSENCODING environment variable was added to Python 3.2: issue #8622.
This variable introduces an inconstency because the filesystem and the locale
encodings can now be different.
There are (at least) four issues related to this problem. We have 2 choices to
fix these issues:
Stephen J. Turnbull wrote (giving me an opening to jump in here):
R. David Murray writes:
In other words, my proposed patch only makes email5 1/8 to 1/4
broken, instead of half broken as it is now. But not un-broken
enough for Mailman, it sounds like.
IMO, not in the long run. But
Victor Stinner wrote:
Hi,
A PYTHONFSENCODING environment variable was added to Python 3.2: issue #8622.
This variable introduces an inconstency because the filesystem and the locale
encodings can now be different.
There are (at least) four issues related to this problem. We have 2
On Thu, Oct 07, 2010 at 06:35:09PM +0200, M.-A. Lemburg wrote:
It is well possible that the two are different. Mac OS X is
just one example. Another common example is having a Unix
account using the C locale (=ASCII) while working on a UTF-8
file system.
My filesystems are always koi8-r,
On Thu, 07 Oct 2010 16:03:18 -, l...@rmi.net wrote:
I'm forwarding a link to the code of these clients to David by
private email in case they might be useful as a test case (O'Reilly
has already posted them ahead of the book, but they may be a bit too
heavy for use in formal testing).
It's best to report issues at bugs.python.org.
On Thu, Oct 7, 2010 at 05:17, Thomas Klausner t...@giga.or.at wrote:
Hi!
I'm running newspipe-1.1.9, an RSS reader
(http://newspipe.sourceforge.net/), on NetBSD-5.99.11/amd64 using
Python-2.6.6.
Sometimes, it core dumps with particular feeds
On Oct 07, 2010, at 04:40 AM, Stephen J. Turnbull wrote:
And the email API currently promises not to raise during parsing,
which is a contract my patch does not change.
Which is a contract that has historically been broken frequently.
Unhandled UnicodeErrors have been one of the most common
Le jeudi 07 octobre 2010 18:44:19, Oleg Broytman a écrit :
On Thu, Oct 07, 2010 at 06:35:09PM +0200, M.-A. Lemburg wrote:
It is well possible that the two are different. Mac OS X is
just one example. Another common example is having a Unix
account using the C locale (=ASCII) while working
Le jeudi 07 octobre 2010 18:35:09, M.-A. Lemburg a écrit :
Victor Stinner wrote:
Hi,
A PYTHONFSENCODING environment variable was added to Python 3.2: issue
#8622. This variable introduces an inconstency because the filesystem
and the locale encodings can now be different.
There
On Thu, Oct 07, 2010 at 09:12:13PM +0200, Victor Stinner wrote:
Le jeudi 07 octobre 2010 18:44:19, Oleg Broytman a ?crit :
My filesystems are always koi8-r, but sometimes I work with programs in
utf-8 locale. Just an example...
Are programs able to display correctly non-ascii filenames
Am 04.10.2010 03:56, schrieb Daniel Stutzbach:
On Sat, Oct 2, 2010 at 3:55 PM, Martin v. Löwis mar...@v.loewis.de
mailto:mar...@v.loewis.de wrote:
I'll have to come up with a better way to determine the branch
which a patch was created on.
That would also be helpful for those of
On Thu, 07 Oct 2010 23:04:54 +0200
Martin v. Löwis mar...@v.loewis.de wrote:
However, if I get something like
diff -r e981b6cc56b0 Include/longintrepr.h
--- a/Include/longintrepr.h Thu Oct 07 03:12:19 2010 +0200
+++ b/Include/longintrepr.h Thu Oct 07 13:53:41 2010 +0200
I have no
As I said, most patches are supposed to be produced against py3k HEAD,
so you could try just that as the primary heuristic.
I think this is impractical. There are tons of patches (the majority)
which are in the tracker and *not* against py3k head. So this heuristics
will only cover a small
Le jeudi 07 octobre 2010 à 23:17 +0200, Martin v. Löwis a écrit :
As I said, most patches are supposed to be produced against py3k HEAD,
so you could try just that as the primary heuristic.
I think this is impractical. There are tons of patches (the majority)
which are in the tracker and
Seems like python.org has gone down and come back up a couple of times
in the last few minutes, is this intentional?
Geremy Condra
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Am 08.10.2010 00:00, schrieb geremy condra:
Seems like python.org has gone down and come back up a couple of times
in the last few minutes, is this intentional?
Nothing on python.org suggests that this has actually happened. Could
it be that the issue is on your end?
Regards,
Martin
On Thu, Oct 07, 2010 at 11:15:27AM -0700, Brett Cannon wrote:
It's best to report issues at bugs.python.org.
Are different people reading it there?
Following your suggestion, I've created
http://bugs.python.org/issue10047
Please let me know what kind of further details you need.
I still have
On Thu, Oct 7, 2010 at 3:52 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Am 08.10.2010 00:00, schrieb geremy condra:
Seems like python.org has gone down and come back up a couple of times
in the last few minutes, is this intentional?
Nothing on python.org suggests that this has actually
On Thu, Oct 7, 2010 at 15:53, Thomas Klausner t...@giga.or.at wrote:
On Thu, Oct 07, 2010 at 11:15:27AM -0700, Brett Cannon wrote:
It's best to report issues at bugs.python.org.
Are different people reading it there?
Yes, but we also just don't accept bug reports here as they just get
lost in
Nothing on python.org suggests that this has actually happened. Could
it be that the issue is on your end?
It's possible, but I was first notified that it was happening by
someone literally 3000 miles away. It seems unlikely that we would
both have had the same problem at the same time
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/07/2010 07:17 PM, Martin v. Löwis wrote:
Nothing on python.org suggests that this has actually happened. Could
it be that the issue is on your end?
It's possible, but I was first notified that it was happening by
someone literally 3000
FWIW, PyPI was inaccessible for some longish period of time this morning.
That I can confirm (assuming you are talking about the UTC night).
However, it stopped around 5:00 UTC, so it's clearly unrelated to
anything that happened reportedly 2 hours ago.
Regards,
Martin
On Thu, Oct 7, 2010 at 4:17 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Nothing on python.org suggests that this has actually happened. Could
it be that the issue is on your end?
It's possible, but I was first notified that it was happening by
someone literally 3000 miles away. It seems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/07/2010 07:42 PM, Martin v. Löwis wrote:
FWIW, PyPI was inaccessible for some longish period of time this morning.
That I can confirm (assuming you are talking about the UTC night).
However, it stopped around 5:00 UTC, so it's clearly
R. David Murray writes:
The MIME-charset = UNKNOWN dodge might be a better way of handling
this.
That is a very interesting idea. It is the *right* thing to do, since it
would mean that a message parsed as bytes could be generated via Generator
and passed to, say, smtplib without
l...@rmi.net writes:
To put that more strongly, the Python user base is much larger than
this list's readership.
Agreed. Nevertheless, this is the channel (not channel) that the
developers listen on, and substantial effort is made to let Python
users know that. I think they do know it,
36 matches
Mail list logo