Re: [Python-Dev] socket.create_connection slow
Right, there is no way to try to simultaneously connect using ipv4 and ipv6, apparently. Also, the problem with setting the registry TcpConnectMaxRetries registry entry is that it also affects retries wen no ACK is received. This is probably something one doesn't want to mess with. Okay, so do we want to bug MS about this? Clearly it is a performance problem when implementing dual stack clients. K -Original Message- From: "Martin v. Löwis" [mailto:mar...@v.loewis.de] Sent: 15. janúar 2009 00:07 To: Kristján Valur Jónsson Cc: python-dev@python.org Subject: Re: [Python-Dev] socket.create_connection slow > And Microsoft, realizing their problem , came up with this: > http://msdn.microsoft.com/en-us/library/bb513665(VS.85).aspx Dual-stacked sockets are a useful thing to have (so useful that Linux made them the default, despite that the RFC says that the default should be IPV6_V6ONLY). The Python library should make all server sockets dual-stacked if possible. Unfortunately: - the socket option is not available on all systems, in particular, it is not available on Windows XP (you need Vista) - you'll see the 1s delay on the client side if the server is not dual-stacked, so if the server "misbehaves", the client has to suffer. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for the Haiku OS
-On [20090115 01:11], Guido van Rossum (gu...@python.org) wrote: >I'm with Martin. In these days of distributed version control systems, >I would think that the effort for the Haiku folks to maintain a branch >of Python in their own version control would be minimal. It is likely >that for each new Python version that comes out, initially it is >broken on Haiku, and then they have to go in and fix it. Last time I looked at Haiku and dabbled with it there were some people actively working on POSIX compliance. My only guess right now is that this work is largely complete. In effect that would mean that Python would work out of the box, more or less. So the cost of adding and maintaining it in the main repository should not be a big overhaul or anything. Just as a FYI. :) -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Earth to earth, ashes to ashes, dust to dust... ___ Python-Dev mailing list Python-Dev@python.org 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-checkins] r68547 - in python/trunk/Lib/test: test_datetime.py test_os.py
Ok, in r 68610 I fixed some of this. The strftime test is now just an excercise, since clearly some platforms accept the %e without hesitation. Also, there were errors in two test_os cases. However, these: == ERROR: test_ftruncate (test.test_os.TestInvalidFD) -- Traceback (most recent call last): File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/test/test_os.py", line 570, in test_ftruncate self.assertRaises(OSError, os.ftruncate, 10, 0) File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/unittest.py", line 345, in failUnlessRaises callableObj(*args, **kwargs) IOError: [Errno 9] Bad file descriptor == FAIL: test_close (test.test_os.TestInvalidFD) -- Traceback (most recent call last): File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/test/test_os.py", line 542, in helper self.assertRaises(OSError, getattr(os, f), 10) AssertionError: OSError not raised Seem bogus. For ftruncate, an invalid filedescriptor really should return OSError, and close(10) should raise an OSError as well. However, these are just being mapped up from whatever the OS returns, so I suppose I should make the tests more lenient? K -Original Message- From: python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Jean-Paul Calderone Sent: 14. janúar 2009 20:20 To: python-dev@python.org Subject: Re: [Python-Dev] [Python-checkins] r68547 - in python/trunk/Lib/test: test_datetime.py test_os.py On Mon, 12 Jan 2009 19:09:28 +0100 (CET), "kristjan.jonsson" wrote: >Author: kristjan.jonsson >Date: Mon Jan 12 19:09:27 2009 >New Revision: 68547 > >Log: >Add tests for invalid format specifiers in strftime, and for handling of >invalid file descriptors in the os module. > >Modified: > python/trunk/Lib/test/test_datetime.py > python/trunk/Lib/test/test_os.py Several of the tests added to test_os.py are invalid and fail. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Help
First of all,I'm so sorry for that my english is so poor that I can't use it freely. Can you tell me how can I install the Python3.0 on my computer with the Red Hat Enterprise 5? Thank you! cuizhiyong 2009-1-15 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Help
>> Can you tell me how can I install the Python3.0 on my computer with >> the Red Hat Enterprise 5? You should ask this question on one of these three mailing lists: python-l...@python.org h...@python.org tu...@python.org This mailing list discusses Python development not how to use Python. -- Skip Montanaro - s...@pobox.com - http://smontanaro.dyndns.org/ ___ Python-Dev mailing list Python-Dev@python.org 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-checkins] r68547 - in python/t runk/Lib/test: test_datetime.pytest_os.py
Kristján Valur Jónsson ccpgames.com> writes: > Seem bogus. > For ftruncate, an invalid filedescriptor really should return OSError, and close(10) should raise an > OSError as well. It seems wrong to assume that 10 is an invalid file descriptor at the time of running the test. IMO you should first open a file descriptor, remember its value and then close it, that way you are reasonably sure that it will be invalid just after. (I'm not saying this is why the tests are failing, but at least it would make them more robust) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] imap bodystructure parser - email.message.Message extension
Hello, I wrote an extension to the imaplib library that implements a "BODYSTRUCTURE" parser. For this I wrote an extension to email.message.Message that allows a message structure to be loaded from imap, the message can be used like a normal email.message.Message but the actual payload is only loaded on the fly. This makes it much quicker for imap applications. The code is here if anyone fancies a try: http://voyageonline.co.uk/blog/article/python-imaplibx I though it might be useful as imaplib is very low level. Regards, -- Stephane Konstantaropoulos signature.asc Description: This is a digitally signed message part. ___ Python-Dev mailing list Python-Dev@python.org 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-checkins] r68547 - in python/trunk/Lib/test: test_datetime.py test_os.py
On Thu, Jan 15, 2009 at 9:13 AM, Kristján Valur Jónsson wrote: > However, these: > > == > ERROR: test_ftruncate (test.test_os.TestInvalidFD) > -- > Traceback (most recent call last): > File > "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/test/test_os.py", > line 570, in test_ftruncate >self.assertRaises(OSError, os.ftruncate, 10, 0) > File > "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/unittest.py", line > 345, in failUnlessRaises >callableObj(*args, **kwargs) > IOError: [Errno 9] Bad file descriptor At the risk of stating the obvious, shouldn't you be checking for IOError rather than OSError in assertRaises? Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for the Haiku OS
On Thu, Jan 15, 2009 at 1:00 AM, Jeroen Ruigrok van der Werven wrote: > -On [20090115 01:11], Guido van Rossum (gu...@python.org) wrote: >>I'm with Martin. In these days of distributed version control systems, >>I would think that the effort for the Haiku folks to maintain a branch >>of Python in their own version control would be minimal. It is likely >>that for each new Python version that comes out, initially it is >>broken on Haiku, and then they have to go in and fix it. > > Last time I looked at Haiku and dabbled with it there were some people > actively working on POSIX compliance. My only guess right now is that this > work is largely complete. In effect that would mean that Python would work > out of the box, more or less. So the cost of adding and maintaining it in > the main repository should not be a big overhaul or anything. > > Just as a FYI. :) Did you look at the patch they submitted? http://bugs.python.org/issue4933 -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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-checkins] r68547 - in python/trunk/Lib/test: test_datetime.py test_os.py
Well, all the other functions raise OSError when the file descriptor is invalid. IOError usually means that the IO itself failed. I wonder if it is platform specific? Does it raise IOError on all platforms? I can also change the test to test for IOError or OSError. K -Original Message- From: Mark Dickinson [mailto:dicki...@gmail.com] Sent: 15. janúar 2009 15:44 To: Kristján Valur Jónsson Cc: Jean-Paul Calderone; python-dev@python.org Subject: Re: [Python-Dev] [Python-checkins] r68547 - in python/trunk/Lib/test: test_datetime.py test_os.py On Thu, Jan 15, 2009 at 9:13 AM, Kristján Valur Jónsson wrote: > However, these: > > == > ERROR: test_ftruncate (test.test_os.TestInvalidFD) > -- > Traceback (most recent call last): > File > "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/test/test_os.py", > line 570, in test_ftruncate >self.assertRaises(OSError, os.ftruncate, 10, 0) > File > "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/unittest.py", line > 345, in failUnlessRaises >callableObj(*args, **kwargs) > IOError: [Errno 9] Bad file descriptor At the risk of stating the obvious, shouldn't you be checking for IOError rather than OSError in assertRaises? Mark ___ Python-Dev mailing list Python-Dev@python.org 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-checkins] r68547 - in python/trunk/Lib/test: test_datetime.py test_os.py
On Thu, Jan 15, 2009 at 4:19 PM, Kristján Valur Jónsson
wrote:
> Well, all the other functions raise OSError when the file descriptor is
> invalid. IOError usually means that the IO itself failed.
> I wonder if it is platform specific? Does it raise IOError on all platforms?
It certainly looks like it: here are lines 6632--6638 of
posixmodule.c, in posix_ftruncate:
Py_BEGIN_ALLOW_THREADS
res = ftruncate(fd, length);
Py_END_ALLOW_THREADS
if (res < 0) {
PyErr_SetFromErrno(PyExc_IOError);
return NULL;
}
Mark
___
Python-Dev mailing list
Python-Dev@python.org
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-checkins] r68547 - in python/trunk/Lib/test: test_datetime.py test_os.py
Interesting.
Looks like a bug, really. It's the only function that sets IOError. All
others use posix_error which raises an OSError.
Maybe tests are a good thing, then?
Kristján
-Original Message-
From: Mark Dickinson [mailto:dicki...@gmail.com]
Sent: 15. janúar 2009 17:01
To: Kristján Valur Jónsson
Cc: Jean-Paul Calderone; python-dev@python.org
Subject: Re: [Python-Dev] [Python-checkins] r68547 - in python/trunk/Lib/test:
test_datetime.py test_os.py
On Thu, Jan 15, 2009 at 4:19 PM, Kristján Valur Jónsson
wrote:
> Well, all the other functions raise OSError when the file descriptor is
> invalid. IOError usually means that the IO itself failed.
> I wonder if it is platform specific? Does it raise IOError on all platforms?
It certainly looks like it: here are lines 6632--6638 of
posixmodule.c, in posix_ftruncate:
Py_BEGIN_ALLOW_THREADS
res = ftruncate(fd, length);
Py_END_ALLOW_THREADS
if (res < 0) {
PyErr_SetFromErrno(PyExc_IOError);
return NULL;
}
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for the Haiku OS
Jeroen Ruigrok van der Werven wrote: > actively working on POSIX compliance. My only guess right now is that this > work is largely complete. In effect that would mean that Python would work > out of the box, more or less. So the cost of adding and maintaining it in This is very interesting to know. If Py 2.x and Py 3K gets supported and perhaps come built-in with next Haiku release, it would be definitely be a win-win situation for both Python and Haiku. -- Senthil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for the Haiku OS
-On [20090115 16:53], Guido van Rossum (gu...@python.org) wrote: >Did you look at the patch they submitted? http://bugs.python.org/issue4933 I did now (python-2.5.4-haiku-2.diff). I am not sure what you are implying though, Guido. It doesn't look like a huge change and most of it is close to 'one time only'. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Earth to earth, ashes to ashes, dust to dust... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for the Haiku OS
On Thu, Jan 15, 2009 at 9:23 AM, Jeroen Ruigrok van der Werven wrote: > -On [20090115 16:53], Guido van Rossum (gu...@python.org) wrote: >>Did you look at the patch they submitted? http://bugs.python.org/issue4933 > > I did now (python-2.5.4-haiku-2.diff). I am not sure what you are implying > though, Guido. It doesn't look like a huge change and most of it is close to > 'one time only'. That's the naive idea. That's what I used to thing too, but it just isn't so. We have quite a bit of experience with these kinds of "one time only" platform-specific changes, and they are never once-only -- they invariably get out of date with each new version released, since nobody except the users of that platform ever tests new versions on that platform. (Also the platform typically evolves faster than Python.) The effort to get a new version QA'ed on such a minority platform *before* it is released never gets made, so the expected and promised compatibility is disappointing for all -- and then the core developers get blamed. It can work only if there are core developers who care enough about such a minority platform to try new versions (both of the trunk and of maintenance branches!) on their platform, *and* submit necessary fixes right away. I don't see such a commitment in this case, but if a believable one comes up I'm sure Martin would happily revert his position. Note that a buildbot would have to be part of the deal. However a buildbot is not enough -- if nobody fixes the build for that platform it will just be ignored by release managers. And only the users of the platform can fix the issues. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] socket.create_connection slow
> Right, there is no way to try to simultaneously connect using ipv4 > and ipv6, apparently. Ah, I see what you meant. No, this cannot work - what if you get positive ACKs on both protocols? > Also, the problem with setting the registry TcpConnectMaxRetries > registry entry is that it also affects retries wen no ACK is > received. This is probably something one doesn't want to mess with. Indeed. They were wrong to overload this setting. > Okay, so do we want to bug MS about this? If you think it helps, go ahead! This has been in the system for so long that they are unlikely to change it. Yet, as IPv6 deployment progresses, this case will occur more and more often (until eventually all services are dual-stacked - in which case the only effect will be that you wait 2 seconds if the service is really not available; 1s delay per protocol). If the default retry counter can't be changed, I'd suggest that they provide a socket option. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] imap bodystructure parser - email.message.Message extension
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 15, 2009, at 7:58 AM, Stéphane Konstantaropoulos wrote: I wrote an extension to the imaplib library that implements a "BODYSTRUCTURE" parser. For this I wrote an extension to email.message.Message that allows a message structure to be loaded from imap, the message can be used like a normal email.message.Message but the actual payload is only loaded on the fly. This makes it much quicker for imap applications. The code is here if anyone fancies a try: http://voyageonline.co.uk/blog/article/python-imaplibx I though it might be useful as imaplib is very low level. This sounds very interesting. One of the things I'd hoped to do for the next version of the email package is actually design an API for remotely loading and saving the payloads. Yours is one of the use cases I've thought of, but also being able to store the payload in a disk cache so as not to chew up memory for say, lots of big image attachments. Unfortunately I don't have time right now to work on this, but I'll keep your message. You should think about joining the email-sig and bringing this up there, if you want to discuss such a generic API. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSW+AknEjvBPtnXfVAQIuKgP/SQcqJ+mdV7P9Euphb4kYPlqHKn6iUYTE uMSNIUvf49Z3pMoup8fJmnOjbela7hCW0g1ZIERaMSrttIq0RNACsoA9GSulfi2M upXp+IE0bGpnxrd0TNNs0DiRHSlerH7okqsix07CdOK2KR3iKBLPypmqWz5T4BpK PJbOEdUWSwo= =q0R0 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support for the Haiku OS
> I don't see such a commitment in this case, but if a > believable one comes up I'm sure Martin would happily revert his > position. Indeed. I have myself added support for AtheOS, even though I had never used the system. The AtheOS maintainer ran away, the code rotted, and eventually get ripped out. The same happened for a lot of other systems whose code was recently removed. Unless a core committer actively works on the port, I see little change that it remains in a usable shape over time. In case you wonder why it might break: configure gets rewritten to have new features (like --enable-shared), and then people contributing such a change can only contribute it for the systems they can test it on. New variables get introduced, which don't get set for Haiku, and the Makefile breaks - perhaps in a trivial way, but nonetheless useless for the end user who wants to build Haiku. In addition, I expect that a *true* Haiku port would have many additional modules that provide access to API specific to the system (such as support for GUI applications). The true Haiku port will have to provide all these things, but they won't be in the core. So people using Python on Haiku will have to get it from elsewhere, anyway. So I think adding the patch to Python has little advantage to Haiku users, and (if the patch is small) maintaining it outside of python.org should be little effort to the authors of the patch. (e.g. compared to writing all these other modules) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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-checkins] r68547 - in python/trunk/Lib/test: test_datetime.py test_os.py
On Thu, Jan 15, 2009 at 5:06 PM, Kristján Valur Jónsson wrote: > Interesting. > Looks like a bug, really. It's the only function that sets IOError. All > others use posix_error which raises an OSError. Maybe. But changing it risks breaking existing code, so would certainly require (at least) a tracker discussion. In the meantime, please could you either revert or fix the r68547 checkin? It looks as though *all* of the (non-Windows) trunk buildbots are failing on test_os, and if any of the release managers notices we'll all be in trouble. :-) Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] report on building of python 2.5.2 under msys under wine on linux.
no, the above subject-line is not a joke: i really _have_ successfully built python2.5.2 by installing wine on linux, then msys under wine, and then mingw32 compiler - no, not the linux mingw32-cross-compiler, the _native_ mingw32 compiler that runs under msys, and then hacking things into submission until it worked. issue-report: http://bugs.python.org/issue4954 source code: http://github.com/lkcl/pythonwine/tree/python_2.5.2_wine related issue-report: http://bugs.python.org/issue3871 related issue-report: http://bugs.python.org/issue1597850 i'm going to _try_ to merge in #3871 but it's... the prospect of sitting waiting for configure to take THREE hours to complete, due to /bin/sh.exe instances taking TWO SECONDS _each_ to start up does not really fill me with deep joy. consequently i did a major hatchet-job on configure.in with repeated applications of "if test $win32build = no; then" ... cue several hundred lines of configure.in tests blatantly ignored "fi # $win32build=no! " and thus cut the configure time down from three hours to a mere 15 minutes. the only reason why this was possible at all was because PC/config.h already exists and has been pre-set-up with lots of lovely #defines. also, there is another significant difference between #3871 and #4954 - i chose to build in to libpython2.5.dll exactly as many modules as are in the proprietary win32 build. this turned out to be a good practical decision, due to /bin/sh.exe messing around and stopping python.exe from running! (under cmd.exe it's fine. i have to do a bit more investigation: my guess is that the msys "remounter" is getting in the way, somehow. compiling python to have a prefix of /python25 results in files being installed in /python25 which maps to c:/msys/python25/ but actually that doesn't get communicated correctly to the compiled python.exe it's all a bit odd - it still feels like things are being cross-compiled... but they're not... it's just that setup.py has paths that don't _quite_ match up with the msys environment... needs work, there. the regression testing is _great_ fun! some of the failures are really quite spectacular, but surprisingly there are less than anticipated. file "sharing violation" isn't a big surprise (under wine); the ctypes structure failures are going to be a bitch to hunt down; the test_str %f failure _was_ a big surpise; the builtin file \r\n <-> \n thing wasn't in the _least_ bit of a surprise :) overall, this has been... interesting. and the key thing is that thanks to #3871 and #4954 and #1597850, python will soon happily compile for win32 _without_ the dependence on _any_ proprietary software or operating systems. that's a pretty significant milestone. l. p.s. if anyone would like to try out this build, on a windows box, to see if it fares any better on the regression tests please say so and i will make the binaries available. ___ Python-Dev mailing list Python-Dev@python.org 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-checkins] r68547 - in python/trunk/Lib/test: test_datetime.py test_os.py
Right. I've fixed the remainder, things should quiet down now. K -Original Message- From: Mark Dickinson [mailto:dicki...@gmail.com] Sent: 15. janúar 2009 20:40 To: Kristján Valur Jónsson Cc: Jean-Paul Calderone; python-dev@python.org Subject: Re: [Python-Dev] [Python-checkins] r68547 - in python/trunk/Lib/test: test_datetime.py test_os.py On Thu, Jan 15, 2009 at 5:06 PM, Kristján Valur Jónsson wrote: > Interesting. > Looks like a bug, really. It's the only function that sets IOError. All > others use posix_error which raises an OSError. Maybe. But changing it risks breaking existing code, so would certainly require (at least) a tracker discussion. In the meantime, please could you either revert or fix the r68547 checkin? It looks as though *all* of the (non-Windows) trunk buildbots are failing on test_os, and if any of the release managers notices we'll all be in trouble. :-) Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Lib/email/header.py ecre regular expression
Hello.
Welcome message to this mail list said that it's
good to tell a few words about myself.
So, my name is Jan Malakhovski aka OXIj,
I'm living in St. Petersburg, Russia,
student of ITMO University, 4th year of education.
I have dedicated mail server at home
and it holds about 1G of mail.
Most of mail is in non UTF-8 codepage, so today
I wrote little script that should recode
all letters to UTF. But I found that
email.header.decode_header parses some headers wrong.
For example, header
Content-Type: application/x-msword; name="2008 =?windows-1251?B?wu7v8O7x+w==?=
2 =?windows-1251?B?4+7kIDgwONUwMC5kb2M=?="
parsed as
[('application/x-msword; name="2008', None), ('\xc2\xee\xef\xf0\xee\xf1\xfb',
'windows-1251'), ('2 =?windows-1251?B?4+7kIDgwONUwMC5kb2M=?="', None)]
that is obviously wrong.
Now I'm playing with email/header.py file in
python 2.5 debian package
(but it's same in 2.6.1 version except that all <> changed to !=).
If it's patched with
==BEGIN CUT==
--- oldheader.py2009-01-16 01:47:32.553130030 +0300
+++ header.py 2009-01-16 01:47:16.783119846 +0300
@@ -39,7 +39,6 @@
\?# literal ?
(?P.*?) # non-greedy up to the next ?= is the encoded string
\?= # literal ?=
- (?=[ \t]|$) # whitespace or the end of the string
''', re.VERBOSE | re.IGNORECASE | re.MULTILINE)
# Field name regexp, including trailing colon, but not separating whitespace,
==END CUT==
it works fine.
So I wonder if this
(?=[ \t]|$) # whitespace or the end of the string
really needed, after all if there is only
whitespaces after encoded word, its just
appended to the list by
parts = ecre.split(line)
--
Jan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] report on building of python 2.5.2 under msys under wine on linux.
On Thu, Jan 15, 2009, Luke Kenneth Casson Leighton wrote: > > p.s. if anyone would like to try out this build, on a windows box, to > see if it fares any better on the regression tests please say so and i > will make the binaries available. Don't bother on my account, but please publicize the URL if you end up doing it; I may try it on my Mac with Windows under Fusion... -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian W. Kernighan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] report on building of python 2.5.2 under msys under wine on linux.
> practical decision, due to /bin/sh.exe messing around and stopping > python.exe from running! (under cmd.exe it's fine. i have to do a > bit more investigation: http://bugs.python.org/issue4956 found it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Lib/email/header.py ecre regular expression
On Fri, Jan 16, 2009, Jan Malakhovski wrote: > > I have dedicated mail server at home and it holds about 1G of mail. > Most of mail is in non UTF-8 codepage, so today I wrote little > script that should recode all letters to UTF. But I found that > email.header.decode_header parses some headers wrong. Please post this to http://bugs.python.org/ -- regardless of whether this is a real bug, using the tracker ensures that we won't lose it. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian W. Kernighan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [patch] moving file load to AFTER Py_Initialize performed
http://bugs.python.org/issue4956 uhn... weird bug, totally left-field scenario (using python under msys under wine under linux) but this rather strange scenario has a situation where loading the filename from the command line cannot be done until _after_ PyInitialize is called. prior to PyInitialize() being called, file handling including stderr is _so_ screwed that it's impossible to even use sprintf(stderr, "help help there's something wrong!\n") to diagnose the problem. i wanted to ask people: does this patch (in #4956) look... reasonable? there's no global variables or subtle interaction that "steals" argv or argc (as part of PyInitialize()) is there, that would, once it's finished, disrupt the loading of the file? if so, it would be necessary to split up the code that "gets" the filename (filename = argv[_PyOS_optind]) and leave that _bfore_ PyInitialize(), from the code that _loads_ the file (into fp). following the deployment of this fix, the build of python under msys+wine+linux proceeds _from_ msys, rather than having to be irritatingly interrupted and continued from "wineconsole cmd". l. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] multiprocessing vs. distributed processing
I've noticed over the past few weeks lots of questions asked about multi-processing (including myself). For those of you new to multi-processing, perhaps this thread may help you. Some things I want to start off with to point out are: "multiprocessing will not always help you get things done faster." "be aware of I/O bound applications vs. CPU bound" "multiple CPUs (cores) can compute multiple concurrent expressions - not read 2 files concurrently" "in some cases, you may be after distributed processing rather than multi or parallel processing" cheers James -- -- "Problems are solved by method" ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
