Re: [Python-Dev] Problems with unicode_literals
Index: Lib/optparse.py === --- Lib/optparse.py(revision 68465) +++ Lib/optparse.py(working copy) @@ -994,7 +994,7 @@ add_option(Option) add_option(opt_str, ..., kwarg=val, ...) -if type(args[0]) is types.StringType: +if type(args[0]) in types.StringTypes: option = self.option_class(*args, **kwargs) elif len(args) == 1 and not kwargs: option = args[0] Should this be fixed, or wait for 2.7? It would be a new feature. So if we apply a strict policy, it can't be added to 2.6. 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] Deprecate PyNumber_Long?
On Fri, Jan 16, 2009 at 10:42 PM, Brett Cannon br...@python.org wrote: Assuming we have been moving the C API usage to PyInt and not PyLong, then yes it makes sense. Hmm. I don't think there's been any such move. Maybe there should be. Benjamin wondered aloud about deprecating PyNumber_Long in the issue 4910 discussion; I suggested deprecating PyNumber_Int instead, but on reflection I think Benjamin's right: it seems neater to keep the PyNumber_Int - int() - nb_int naming connections than the PyNumber_Long - PyLong ones. At any rate, I think it would be good to deprecate one or the other; I don't really have a strong opinion about which one. 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] Deprecate PyNumber_Long?
Mark Dickinson dickinsm at gmail.com writes: Benjamin wondered aloud about deprecating PyNumber_Long in the issue 4910 discussion; I suggested deprecating PyNumber_Int instead, but on reflection I think Benjamin's right: it seems neater to keep the PyNumber_Int - int() - nb_int naming connections than the PyNumber_Long - PyLong ones. The C API uses the Long (rather than Int) wording, so it would be rather strange to have an outlier in PyNumber_Int. We should keep PyNumber_Long instead. ___ 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] Problems with unicode_literals
Le Saturday 17 January 2009 04:45:28 Barry Warsaw, vous avez écrit : The optparse one could easily be fixed for 2.6, if we agree it should be fixed. This untested patch should do it I think: Index: Lib/optparse.py === --- Lib/optparse.py (revision 68465) +++ Lib/optparse.py (working copy) @@ -994,7 +994,7 @@ add_option(Option) add_option(opt_str, ..., kwarg=val, ...) -if type(args[0]) is types.StringType: +if type(args[0]) in types.StringTypes: option = self.option_class(*args, **kwargs) elif len(args) == 1 and not kwargs: option = args[0] See also related issues: - http://bugs.python.org/issue2931: optparse: various problems with unicode and gettext - http://bugs.python.org/issue4319: optparse and non-ascii help strings -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ ___ 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] bundlebuilder broken in 2.6
It seems that the packaging of Mac Python 2.6 is missing at least one file that is critical to the operation of bundlebuilder.py. I've logged the issue as http://bugs.python.org/issue4937. Barry ___ 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] issue2233: ... extra slash before $(DESTDIR) ... cygwin install fail
Hi All,
May I ask for a vote how issue to be resolved.
The problem is command ... setup.py install ... --root=/$(DESTDIR) if
DESTDIR is specified:
error: could not create '//...': No such host or network path
Currently issue http://bugs.python.org/issue2233 propose three solutions:
1) replace slash before $(DESTDIR) with /./ . Lets call solution
hacky.
2) lets call second one shell script based:
INSTROOT=$(DESTDIR); test -z $$INSTROOT INSTROOT=/; ... setup.py
install ... --root=$$INSTROOT
3) the third shell parameter expansion:
... --root=$${DESTDIR-/}
The question for last one is: So, if a user executes make DESTDIR=
install, then the build will fail. Or, maybe we shouldn't worry about
that corner case.
Which solution is prefered ? What about other solutions ?
Roumen
___
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.
Luke Kenneth Casson Leighton wrote: [SNIP] 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. As from version 1.1.8 msys bash could be run in wine. May be wine issue 12046 is not enough to run a born shell in wine. The ash from pw32 projects (not updated in past 6 years :( ) work in wine but the problem is same - it is to slow, even more. [SNIP] 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... You could use CPPFLAGS and LDFLAGS to point other locations. Usually wine drive Z: is mapped to filesystem root and visible as /z in msys. [SNIP] the regression testing is _great_ fun! some of the failures are really quite spectacular, but surprisingly there are less than anticipated. About 5 test fail in emulated environment due bugs in emulator. May be some math tests fail. Python math tests are too strict for msvcrt 7.0/6.0 (default runtime). Simple work around is to use long double functions from mingwex library. Other work-around is to build whole python (including modules) with msvcrt 9.0 but I'm not sure that I will publish soon technical details about this build as DLL hell is replaces by Assembly hell (see python issues related to vista and MSVC build). [SNIP] Roumen ___ 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] Deprecate PyNumber_Long?
On 1/17/09, Antoine Pitrou solip...@pitrou.net wrote: Mark Dickinson dickinsm at gmail.com writes: Benjamin wondered aloud about deprecating PyNumber_Long in the issue 4910 discussion; I suggested deprecating PyNumber_Int instead, but on reflection I think Benjamin's right: it seems neater to keep the PyNumber_Int - int() - nb_int naming connections than the PyNumber_Long - PyLong ones. The C API uses the Long (rather than Int) wording, so it would be rather strange to have an outlier in PyNumber_Int. We should keep PyNumber_Long instead. I agree with Antoine here. Using nb_int instead of nb_long is rather unfortunate, but I think it's more important to keep the C-API function names consistent. -- Regards, Benjamin ___ 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.
hiya roumen, good to hear from you - i've been merging in the work that you did, on mingw native-and-cross compiles. got a couple of questions, will post them in the bugreport ok? On Sat, Jan 17, 2009 at 3:16 PM, Roumen Petrov bugtr...@roumenpetrov.info wrote: Luke Kenneth Casson Leighton wrote: [SNIP] 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. As from version 1.1.8 msys bash could be run in wine. ah, that might be worth trying. thank you! 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... You could use CPPFLAGS and LDFLAGS to point other locations. Usually wine drive Z: is mapped to filesystem root and visible as /z in msys. oh don't get me wrong - it all works, all compiles absolutely fine, modules and everything... it just... _feels_ like a cross-compile, because of msys. you're sort-of in unix-land, yet the resultant binary python.exe is most _definitely_ c:/ey. the regression testing is _great_ fun! some of the failures are really quite spectacular, but surprisingly there are less than anticipated. About 5 test fail in emulated environment due bugs in emulator. i have 12 that fail - but if i replace msvcrt builtin with msvcrt native, all but two or three disappear. the S8I one (which is due to gcc, you already found that i noticed); tmpfile() tries to write to z:/ which is of course / - the root filesystem; and os.environ['HELLO'] = 'World; os.popen(/bin/sh echo $HELLO).read() != 'World' but i'm not sure if that one _should_ succeed: the only reason it got run is because i _happened_ to have msys installed. May be some math tests fail. Python math tests are too strict for msvcrt 7.0/6.0 (default runtime). Simple work around is to use long double functions from mingwex library. oh i noticed in http://bugs.python.org/issue3871 that you replaced some of the math functions. Other work-around is to build whole python (including modules) with msvcrt 9.0 but I'm not sure that I will publish soon technical details about this build as DLL hell is replaces by Assembly hell (see python issues related to vista and MSVC build). ooo, scarey. oh! roumen, very important: martin says we have to be _really_ careful about releases of mingw-compiled python.exe and libpython2.N.dll - they _have_ to match up with the python-win32 build msvcrt otherwise it will cause absolute mayhem. i'm currently adding an msvcr80 specfile so i can build under wine - see http://bugs.python.org/msg79978 which requires that you customise wine to get it to drop something blah blah don't care in the least, i just want it all to work :) 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
Re: [Python-Dev] report on building of python 2.5.2 under msys under wine on linux.
About 5 test fail in emulated environment due bugs in emulator. oh - nearly forgot: several of the ctypes tests fail quite spectacularly :) ___ 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] Problems with unicode_literals
On Sat, Jan 17, 2009 at 12:25 AM, Martin v. Löwis mar...@v.loewis.de wrote: Index: Lib/optparse.py === --- Lib/optparse.py(revision 68465) +++ Lib/optparse.py(working copy) @@ -994,7 +994,7 @@ add_option(Option) add_option(opt_str, ..., kwarg=val, ...) -if type(args[0]) is types.StringType: +if type(args[0]) in types.StringTypes: option = self.option_class(*args, **kwargs) elif len(args) == 1 and not kwargs: option = args[0] Should this be fixed, or wait for 2.7? It would be a new feature. So if we apply a strict policy, it can't be added to 2.6. That seems a bit *too* strict to me, as long as the Unicode strings contain just ASCII. I'm fine with fixing both cases Barry mentioned, especially if it otherwise breaks from __future__ import unicode_literals. I expect though that as one tries more things one will find more things broken with that mode. -- --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] Problems with unicode_literals
That seems a bit *too* strict to me, as long as the Unicode strings contain just ASCII. I'm fine with fixing both cases Barry mentioned, especially if it otherwise breaks from __future__ import unicode_literals. I expect though that as one tries more things one will find more things broken with that mode. Of course, the proposed patch would widen it to arbitrary Unicode command options; nothing in the patch restricts it to pure ASCII. Even when only ASCII characters are used in the option name, we might still get encoding exceptions or warnings if a non-ASCII byte string (e.g. from the command line) happens to be compared with the option name (although I just now couldn't produce such a case). Regards, Martin P.S. optparse already defines a function isbasestring; it might be better to use that one instead. ___ 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] bundlebuilder broken in 2.6
In article 7043cb7c-18f4-4e16-ae0c-cda6ba311...@barrys-emacs.org, Barry Scott ba...@barrys-emacs.org wrote: It seems that the packaging of Mac Python 2.6 is missing at least one file that is critical to the operation of bundlebuilder.py. I've logged the issue as http://bugs.python.org/issue4937. I've noted a workaround in the tracker: just copy the file from an older version of Python. It's a simple xml plist and I don't think its contents are all that critical anyway. While the build should be fixed for 2.6+ (I'll send a patch), note that bundlebuilder is gone in 3.0. -- Ned Deily, n...@acm.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
[Python-Dev] off-by-one on ftell on wine, but no regression test to catch it
folks, hi, http://bugs.winehq.org/show_bug.cgi?id=16982 related to this: from array import array TESTFN = testfile.txt def fail(x): print x testlines = [ spam, spam and eggs\n, eggs, spam, ham and spam\n, saussages, spam, spam and eggs\n, spam, ham, spam and eggs\n, spam, spam, spam, spam, spam, ham, spam\n, wonderful spaam.\n ] try: # Prepare the testfile bag = open(TESTFN, w) bag.writelines(testlines) bag.close() f = open(TESTFN) testline = testlines.pop(0) line = f.readline() testline = testlines.pop(0) buf = array(c, \x00 * len(testline)) f.readinto(buf) testline = testlines.pop(0) print length of testline:, len(testline) line = f.read(len(testline)) if line != testline: fail(read() after next() with empty buffer failed. Got %r, expected %r % (line, testline)) lines = f.readlines() if lines != testlines: fail(readlines() after next() with empty buffer failed. Got %r, expected %r % (line, testline)) f.close() finally: os.unlink(TESTFN) which is a reduced version of Lib/test/test_file.py running under wine, ftell() has an off-by-one bug, where the file position accidentally doesn't include the fact that the CR of the CRLF has been skipped. but, now with the fgets() bug fixed, the regression tests pass, but there's still the off-by-one bug which _isn't_ caught. this really should be added as a windows test. actually, it should be added as a test for everything: it's not always reasonable to assume that OSes get their file positions right :) 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
Re: [Python-Dev] off-by-one on ftell on wine, but no re gression test to catch it
Luke Kenneth Casson Leighton lkcl at lkcl.net writes: running under wine, ftell() has an off-by-one bug, where the file position accidentally doesn't include the fact that the CR of the CRLF has been skipped. but, now with the fgets() bug fixed, the regression tests pass, but there's still the off-by-one bug which _isn't_ caught. I don't understand why we should have a test for this. The regression tests are meant to caught bugs in Python itself, not in the underlying OS libs... The only reason to care about this would be if the aforementioned OS bug managed to crash the interpreter. ___ 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] Python 3 for Mac OSX
Hi, Any idea when the Mac OSX disk image (.dmg file) for Python 3.x will be available? Are we talking about days? weeks? Or, should I start learning how to build Python from source? Any info would be appreciated. Thanks, Roger. ___ 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 3 for Mac OSX
Are we talking about days? weeks? Or, should I start learning how to build Python from source? Any info would be appreciated. The latter. Don't ever expect that others will help you. This is open source; you have to help yourself. 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 3 for Mac OSX
In article 655d2f11-818d-43e4-8234-1dd6c3b74...@qwest.net, Roger Vossler rvoss...@qwest.net wrote: Any idea when the Mac OSX disk image (.dmg file) for Python 3.x will be available? Are we talking about days? weeks? Or, should I start learning how to build Python from source? Any info would be appreciated. I don't know what other activity is going on but I am working on it right now. I expect to submit several patches in the next few days that should allow the production of at least a test installer image. -- Ned Deily, n...@acm.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
[Python-Dev] http://bugs.python.org/issue4977 - assumption that maxint64 fits into long on 32-bit systems
this was found as part of the regression tests, compiling python under wine under msys with mingw32. test_maxint64 failed. i tracked it down to the assumption that a long will fit into 32-bits, which obviously... it won't! the simplest case is to add a test for the length of the data string being 10 or more characters, on the basis that 9 or less is definitely going into an int; 11 or more is _definitely_ going into a long, and... well... bugger the 10 case, just stuff it in a long rather than waste time trying to find out how many chars it is. if anyone wants to do a more perfect version of this, simple patch, they're mooore than welcome. 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
Re: [Python-Dev] Problems with unicode_literals
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 16, 2009, at 10:52 PM, Benjamin Peterson wrote:
On Fri, Jan 16, 2009 at 9:45 PM, Barry Warsaw ba...@python.org
wrote:
The optparse one could easily be fixed for 2.6, if we agree it
should be
fixed. This untested patch should do it I think:
Index: Lib/optparse.py
===
- --- Lib/optparse.py (revision 68465)
+++ Lib/optparse.py (working copy)
@@ -994,7 +994,7 @@
add_option(Option)
add_option(opt_str, ..., kwarg=val, ...)
- -if type(args[0]) is types.StringType:
+if type(args[0]) in types.StringTypes:
option = self.option_class(*args, **kwargs)
elif len(args) == 1 and not kwargs:
option = args[0]
It'd probably be better to replace that whole line with
isinstance(args[0], basestring).
I thought about that, but clearly the style of that module is to use
the 'is' test. I'm assuming that's because of some required backward
compatibility reason, but honestly I didn't check, I just copied the
style of the file.
The fact that 'a' and 'b' are unicodes and not accepted as keyword
arguments
is probably the tougher problem. I haven't yet looked at what it
might take
to fix. Is it worth fixing in 2.6 or is this a wait-for-2.7 thing?
Actually, this looks like a one line fix, too:
--- Python/ceval.c (revision 68625)
+++ Python/ceval.c (working copy)
@@ -2932,7 +2932,8 @@
PyObject *keyword = kws[2*i];
PyObject *value = kws[2*i + 1];
int j;
- if (keyword == NULL || !
PyString_Check(keyword)) {
+ if (keyword == NULL || !
(PyString_Check(keyword) ||
+
PyUnicode_Check(keyword))) {
PyErr_Format(PyExc_TypeError,
%.200s() keywords must be
strings,
PyString_AsString(co-co_name));
That seems reasonable.
But I agree with Guido when he says this should be a 2.7 feature.
As does that.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSXJis3EjvBPtnXfVAQLnsAP+I7ZIa8vKwSJV+cGqlFyKYNdyYysxYW5w
QL36DMXMwfg+Gddb5GN16IGXZt54yTneFAp6fxNgq55Seql/LFmhSrYoq0dk0uXz
+sb92PRtYD7QjV6BkOUFlIGphmuOS7Vxv6+M2Xi1YoSyU6DHhno0AyYUFa3ysJiC
lfNP6TLgGL0=
=mp9M
-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] Problems with unicode_literals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 17, 2009, at 2:25 PM, Guido van Rossum wrote: On Sat, Jan 17, 2009 at 12:25 AM, Martin v. Löwis mar...@v.loewis.de wrote: Index: Lib/optparse.py === --- Lib/optparse.py(revision 68465) +++ Lib/optparse.py(working copy) @@ -994,7 +994,7 @@ add_option(Option) add_option(opt_str, ..., kwarg=val, ...) -if type(args[0]) is types.StringType: +if type(args[0]) in types.StringTypes: option = self.option_class(*args, **kwargs) elif len(args) == 1 and not kwargs: option = args[0] Should this be fixed, or wait for 2.7? It would be a new feature. So if we apply a strict policy, it can't be added to 2.6. That seems a bit *too* strict to me, as long as the Unicode strings contain just ASCII. I'm fine with fixing both cases Barry mentioned, especially if it otherwise breaks from __future__ import unicode_literals. I expect though that as one tries more things one will find more things broken with that mode. Maybe not though! I've finished converting the Mailman 3 code base and there were the only two problems that I could attribute to Python. Everything else were really attributed to my own sloppiness between bytes and strings. In fact, I started this experiment to fix a problem with the Storm ORM, which is much stricter about its column data types. I'm happy enough with the code that I'm going to keep it even with the Python nits. It sounds like you're amenable to fixing this in Python 2.6. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSXJjtXEjvBPtnXfVAQJ8pgP/WZptUyiYvMJnNGOQ/QF6fD7VpwN4GeDF h/idTycEFx9xD32qcdoO+1mZTbsUHyyIg+5hbJP4LP7Iy3yGfVNioih7dg6M287F 2QQ9LVimxyWGvJ+imT508EWDydLfszDkDi9zaqYxvCIU0fbJTs4ylWOFDQlnktNh HR/wU0n+7UQ= =5GII -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] Problems with unicode_literals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 17, 2009, at 8:03 AM, Victor Stinner wrote: Le Saturday 17 January 2009 04:45:28 Barry Warsaw, vous avez écrit : The optparse one could easily be fixed for 2.6, if we agree it should be fixed. This untested patch should do it I think: Index: Lib/optparse.py === --- Lib/optparse.py (revision 68465) +++ Lib/optparse.py (working copy) @@ -994,7 +994,7 @@ add_option(Option) add_option(opt_str, ..., kwarg=val, ...) -if type(args[0]) is types.StringType: +if type(args[0]) in types.StringTypes: option = self.option_class(*args, **kwargs) elif len(args) == 1 and not kwargs: option = args[0] See also related issues: - http://bugs.python.org/issue2931: optparse: various problems with unicode and gettext This one definitely covers the optparse problem I complained about. - http://bugs.python.org/issue4319: optparse and non-ascii help strings - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSXJnq3EjvBPtnXfVAQIy0QP/ZCveuE1fjdRFxd4KPnvOD9CEAOEb/bEs k6xpcCrOrrmhaseIMMgrfDvfFnio+3kbBoewfoD1tQpWAqNmKdqmIKcPxTNUf0cL 66Wv1212O5XrJACq+UnSO50rdkMbV/oD2RMOmsQRB4MJmNSafu9KUuyl56WzIa0S I7zBrqpcC/U= =uoVG -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
[Python-Dev] No email about buildbot failures for 3.1?
I just realized that I had not received any emails on python-checkins about the buildbot failures I accidentally caused. And then I noticed that I had not gotten any emails for py3k in a while. Did that get switched off on purpose? -Brett ___ 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
