[issue10419] distutils command build_scripts fails with UnicodeDecodeError
Changes by Michał Górny mgo...@gentoo.org: -- nosy: +mgorny ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10419 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10422] pstats.py : error when loading multiple stats files
New submission from Stephane Ruchet sruc...@parkeon.com: When using pstats constructor with multiple files, the add_callers method fails. Actually, add_callers need to add values of tuples, but it uses the + operator, that appends tuples. I submit the fix (pstats.py.fix file) and the old one (pstats.py.bug.2.5) -- components: Library (Lib) files: pstats.zip messages: 121216 nosy: sruchet priority: normal severity: normal status: open title: pstats.py : error when loading multiple stats files type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file19611/pstats.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10422 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10422] pstats.py : error when loading multiple stats files
Ezio Melotti ezio.melo...@gmail.com added the comment: This bug should already be fixed in Python 2.6 and 2.7 (see #7372) and 2.5 now accepts only security fixes. I suggest you to upgrade to a newer version of Python. (BTW, thanks for the report and the patch, but it's usually better to avoid zip files and prefer plain diff files) -- nosy: +ezio.melotti resolution: - out of date stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10422 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10350] errno is read too late
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Terry J. Reedy writes: There is one relocation of memory freeing Modules/timemodule.c does '#if,if(..errno..)' after PyMem_Free(outbuf), which can overwrite the desired errno. Instead of reading errno into a temporary, I moved the free into both branches taken by the #if,if(). and the additions of +if (res = 0) +break; which I cannot evaluate. errno is only needed after an error., so I moved 'res 0' out of the 'while'. if (res == MP_EXCEPTION_HAS_BEEN_SET) break; } while (res 0 errno == EINTR !PyErr_CheckSignals()); -- if (res == MP_EXCEPTION_HAS_BEEN_SET) break; if (! (res 0)) break; } while (errno == EINTR !PyErr_CheckSignals()); -- if (res = 0) break; err = errno; if (res == MP_EXCEPTION_HAS_BEEN_SET) break; } while (err == EINTR !PyErr_CheckSignals()); -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10350 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10423] s/args/options in arpgarse Upgrading optparse code
New submission from Steven Bethard steven.beth...@gmail.com: From a personal email: -- I'm not signed up for all the Python issue tracking stuff, but thought I'd let you know about a problem with the argparse doc page: http://docs.python.org/library/argparse.html It says at the end: Replace options, args = parser.parse_args() with args = parser.parse_args() and add additional ArgumentParser.add_argument() calls for the positional arguments. But I think it should be options = parser.parse_args(), not args. -- They're not options, so I don't like encouraging people to continue to call them options, but the docs should at least make clear that the namespace object that used to be called options is now called args. -- assignee: d...@python components: Documentation messages: 121219 nosy: bethard, d...@python priority: normal severity: normal stage: needs patch status: open title: s/args/options in arpgarse Upgrading optparse code versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10424] better error message from argparse when positionals missing
New submission from Steven Bethard steven.beth...@gmail.com:
From a private email in respect to the following class of error messages:
parser = argparse.ArgumentParser(prog='PROG')
parser.add_argument('--foo')
parser.add_argument('--bar')
parser.add_argument('ham')
parser.add_argument('spam', nargs='+')
parser.parse_args(['HAM'])
usage: PROG [-h] [--foo FOO] [--bar BAR] ham spam [spam ...]
PROG: error: too few arguments
--
One suggestion would be that when it displays the error too few arguments, it
would nice if it said something about the argument(s) that are missing.
I modified argparse's error message when there are too few arguments. I didn't
examine the code a lot, so there might be cases where this doesn't work, but
here's what I did:
if positionals:
self.error(_('too few arguments: %s is required' % positionals[0].dest))
--
This would be a nice feature - I haven't checked if the suggested approach
works in general though.
--
components: Library (Lib)
messages: 121220
nosy: bethard
priority: normal
severity: normal
stage: needs patch
status: open
title: better error message from argparse when positionals missing
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10424
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1326113] Letting build_ext --libraries take more than one lib
Palm Kevin kevin.p...@labsolution.lu added the comment: This one is really annoying. Could you please consider fixing this one for the next release? (=lightweight change) -- nosy: +palm.kevin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1326113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1520831] urrlib2 max_redirections=0 disables redirects
Senthil Kumaran orsent...@gmail.com added the comment: John, I was trying to find out what does rfc say on Client Ignoring the 30X REDIRECT headers. There is no point made on Client's trying to ignore it, instead it said that it should follow the Redirect and must not endlessly loop. Setting max_redirect to 0 is similar to ignoring the redirect request , which I found to be a bad idea under any case. Also, if one has to just see redirect urls coming from http server, it can be done by subclassing the HTTPRedirectHandler and logging the redirects. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1520831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1326113] Letting build_ext --libraries take more than one lib
Tarek Ziadé ziade.ta...@gmail.com added the comment: Distutils is frozen and we fix only bugs. This case is a little bit at the edge. Can you show us an example of a call you are trying to make, and the gcc command line output that fails ? I want to see if we can find a workaround. If so, this will be changed only in Distutils2. If not I'll change this to a bug and we'll fix it in distutils too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1326113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10425] xmlrpclib support for None isn't compliant with XMLRPC
New submission from Adam Bielański abg...@gmail.com: XMLRPC standard doesn't support None/nil/null values. Element `nil/` was added as an extension to original protocol. Currently sending None object through xmlrpclib produces `valuenil//value` string. This causes parsing errors in more sophisticated XMLRPC parsers (like org.apache.xmlrpc for Java) which require `nil/` element to be declared in namespace for extensions: xmlns:ex='http://ws.apache.org/xmlrpc/namespaces/extensions' Attached patch makes xmlrpclib use that namespace for sending None values both in method calls and responses, so None value might be passed both ways. It isn't bound to use fixed prefix for extensions namespace and it also parses XML produced by original xmlrpclib (without any namespace at all), so it is backward compatible. It does its job communicating with org.apache.xmlrpc library now, using default parser on the Python side which is an improvement to original version, so I'd like to see it included in the next Python 2.x release, if possible. -- components: Library (Lib), XML files: xmlrpclib.diff keywords: patch messages: 121224 nosy: Adam.Bielański priority: normal severity: normal status: open title: xmlrpclib support for None isn't compliant with XMLRPC type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file19612/xmlrpclib.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10425 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1326113] Letting build_ext --libraries take more than one lib
Palm Kevin kevin.p...@labsolution.lu added the comment: I applied the patch proposed by slanger. This one is working. Now, I'm executing this instruction to build my extension: %pythonRoot%\python.exe setup.py build_ext --include-dirs C:\MyApp\include --library-dir C:\MyApp\lib --libraries myLib1 myLib2 If I don't use the patch, then the error I get is 'unresolved external symbol _xxx referenced in function _abc'. Which is quite normal since I can only point to one library... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1326113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10425] xmlrpclib support for None isn't compliant with XMLRPC
Changes by Senthil Kumaran orsent...@gmail.com: -- assignee: - orsenthil nosy: +orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10425 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6941] Socket error when launching IDLE
Joshua Purcell spamail.08jpurcellser...@gmail.com added the comment: Sorry I've not replied to anyones thoughts until now but nothing seems to fix it -- components: +Windows -IDLE resolution: works for me - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6941 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10426] The whole thing is NOT good
New submission from Joshua Purcell spamail.08jpurcellser...@gmail.com: There is a complete FAIL in this versionand all other versions like 3.* THEY ALL FREEZE UP MY SYSTEM (Windows) HELP -- components: Windows messages: 121227 nosy: 08jpurcell priority: normal severity: normal status: open title: The whole thing is NOT good type: crash versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10426 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10426] The whole thing is NOT good
Changes by Georg Brandl ge...@python.org: -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10426 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10426] The whole thing is NOT good
Ezio Melotti ezio.melo...@gmail.com added the comment: I'm closing this until you can provide more details about the problem you have. What version of Python have you used? (The one you selected (3.3) doesn't exist yet.) Are you sure that the problem is related to Python and not to Windows? If it is, how did you determine it? Is Python or Windows giving you any specific error? -- nosy: +ezio.melotti stage: - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10426 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7186] Document specialness of __doc__, and possibly other special attributes
R. David Murray rdmur...@bitdance.com added the comment: No, because that patch doesn't document the special inheritance rules for __doc__ (which are uniquely special even among special methods). Now, exactly where one would want to document those rules, I'm not sure. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7186 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10427] 24:00 Hour in DateTime
New submission from ingo janssen ingoo...@gmail.com: Short: make the DateTime class and related also accept 24 for the hour instead of stopping at 23:59:59. from the python doc: class datetime.datetime(year, month, day[, hour[, minute[, second[, microsecond[, tzinfo]) The year, month and day arguments are required. tzinfo may be None, or an instance of a tzinfo subclass. The remaining arguments may be ints or longs, in the following ranges: [...] 0 = hour 24 [...] If an argument outside those ranges is given, ValueError is raised. from http://en.wikipedia.org/wiki/ISO_8601 : ISO 8601 uses the 24-hour clock system. The basic format is [hh][mm][ss] and the extended format is [hh]:[mm]:[ss]. * [hh] refers to a zero-padded hour between 00 and 24 (where 24 is only used to notate midnight at the end of a calendar day). [...] Midnight is a special case and can be referred to as both 00:00 and 24:00. The notation 00:00 is used at the beginning of a calendar day and is the more frequently used. At the end of a day use 24:00. Note that 2007-04-05T24:00 is the same instant as 2007-04-06T00:00 (see Combined date and time representations below). The use of 24:00 is very comfortable when using hourly datasets, the first set of a day is saved under 1:00, the fifth (4:00 to 5:00) under 5:00 and the last (23:00 - 24:00) under 24:00. No need to suddenly use 23:59:59 or 0:00 the next day. Actually in another part of Python SQLlite's date and time functions accept and outputs the 24:00. Adding some Python to an existing database made me aware of the problem. -- messages: 121230 nosy: ingo.janssen priority: normal severity: normal status: open title: 24:00 Hour in DateTime type: feature request versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10427 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10260] Add a threading.Condition.wait_for() method
Antoine Pitrou pit...@free.fr added the comment: Good point, Antoine. I'm always trying to keep those timeouts low, however, to avoid having the testsuite duration grow too much with every test :) Well, better to have slower tests than intermittently failing ones, I say. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10260 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10427] 24:00 Hour in DateTime
Changes by Ezio Melotti ezio.melo...@gmail.com: -- components: +Library (Lib) nosy: +belopolsky, ezio.melotti versions: -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10427 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10070] 2to3 wishes for already-2to3'ed files
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Martin v. Löwis writes: As this code is in a Python 2.x block: why does this change cause problems to you? You are supposed to run the 2to3 result in Python 3, and this conversion result will run correctly in Python 3. As I've explained, and as the if-statement and the associated comment expresses, that piece of code is intended to work with both Python 2 and 3. 2to3 turns it into code which would break on Python 2. I've explained why I'd run 2to3 on such code, and thus why it'd be convenient if I could ask 2to3 to leave such code alone. So I requested this feature. I don't know exactly how I'm supposed to use 2to3. If you are its inventor, you do. Otherwise it may also be supposed to suit other workflows than yours. Ok, I can propose two different spellings of this without any macro processor: (...) Both your examples fit my request perfectly. Pieces of code which I presume are correct for both Python 2 and 3, and 2to3 break them for both Python versions. With my feature, the code would keep working with both. However, it is true that there are other cases where I'd like to shut up 2to3 but where my suggested solution would not be convenient to use. I am after all requesting a mere convenience feature, and aimed for something I hoped would be a simple matter to implement. I never imagined that merely explaining it would grow into such a discussion. Bobby, thanks for the sa2to3 reference. Doesn't quite do what I wanted, but looks useful and might also be a good starting point for what I did ask for. Hopefully I won't need to understand too much 2to3 code first... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7186] Document specialness of __doc__, and possibly other special attributes
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7186 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10070] 2to3 wishes for already-2to3'ed files
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Hallvard B Furuseth writes: Martin v. Löwis writes: Ok, I can propose two different spellings of this without any macro processor: (...) Both your examples fit my request perfectly. Pieces of code which I presume are correct for both Python 2 and 3, (...) Sorry, ignore that. I saw you doing what I would be doing, not what you were doing... Not example A. And Example B looks (to me) like it is intended to work unmodified for both Python 2 and 3, but doesn't. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10427] 24:00 Hour in DateTime
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: +1 Note that in Python, semi-open intervals are favored, but specifying the last hour of the day is awkward when using datetime (as OP mentioned) and impossible using just time. Using closed intervals is not a good work-around in many cases because it requires the user to be explicit about precision: is the last hour [23:00-23:59], [23:00:00-23:59:00], or [23:00:00.99-23:59:00.99]? I offer to write the patch for the C implementation if someone comes up with a patch for datetime.py including tests. -- assignee: - belopolsky components: +Extension Modules stage: - unit test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10427 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10070] 2to3 wishes for already-2to3'ed files
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Éric Araujo writes: I think 2to3 is designed to take 2.x code and turn it into 3.x code. Codebases using tricks and hacks to support both 2.x and 3.x (like the example you linked to) cannot be handled by 2to3. That's fair enough. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1326113] Letting build_ext --libraries take more than one lib
Antoine Pitrou pit...@free.fr added the comment: Since --libraries is plural, and since the help text says: --libraries (-l) external C libraries to link with it should IMO be considered a bug. (Standard UNIX linkers have a different convention: you can specify -l several times in order to link against several libraries; however, distutils seems to ignore all but the last -l option) -- nosy: +eric.araujo, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1326113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Ron Adam ron_a...@users.sourceforge.net added the comment: This should be done or very close to done. The -g option, gui(), and serve() functions are deprecated. The new features are browse(port, *, open_browser=True), and a '-b' option. The '-p port' option does browse(port=port, open_browser=False), so _startserver() does not need to be part of the API. If anyone wants to access the server directly, then we can discuss making it it's own module, or a submodule in a package. Because we deprecated the gui() function, I figured we need to make browse() public. The only reason it would need to be private is if we want a different name or signature. (Any thoughts?) I left Lib/urllib/parse.py, Lib/test/test_pyclbr.py, and Lib/test/test_urlparse.py alone. I presumed you fixed bugs in them that needed to be fixed anyway. -- Added file: http://bugs.python.org/file19613/issue2001_b.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Changes by Ron Adam ron_a...@users.sourceforge.net: Removed file: http://bugs.python.org/file19604/issue2001_a.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Changes by Ron Adam ron_a...@users.sourceforge.net: Removed file: http://bugs.python.org/file19476/pydoc_r86133.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1553375] Add traceback.print_full_exception()
Pascal Chambon chambon.pas...@gmail.com added the comment: I dont understand, if we use traceback.print_stack(), it's the stack at the exception handling point which will be displayed. In my view, the interesting think was not the stack trace at the point where the exception is being handled, but where the unwinding stopped (i.e, a snapshot of the stack at the moment the exception was caught). I agree that most of the time these stacks are quite close, but if you happen to move the traceback object all around, in misc. treatment functions (or even, if it has been returned by functions to their caller - let's be fool), it can be handy to still be able to output a full exception stack, like if the exception had flowed up to the root of the program. At least that's what'd interest me for debugging. try: myfunction() #- that's the point of which I'd likle a stack trace except Exception, e: handle_my_exception(e) #- not of that point, some recursion levels deeper Am I the only one viewing it as this ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error
Changes by David Fraser dav...@sjsoft.com: -- nosy: +davidfraser ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1553375] Add traceback.print_full_exception()
R. David Murray rdmur...@bitdance.com added the comment: I agree with you, Pascal, but I think Nick is saying that that information is not actually available. I don't fully understand why, but he knows vastly more about Python internals than I do so I'll take his word for it. It might be interesting to try saving the traceback and printing out the allframes traceback elsewhere, since that should prove to you and I that it doesn't work :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10428] IDLE Trouble shooting
New submission from Eli eliandka...@acsalaska.net: I am having trouble with python. I use python 2.5.1, and have windows 7. I used to be able to use IDLE, but now it says its opening and it never does. I also could use recovery to fix it. but that does not work now. Any Ideas? -- components: Windows messages: 121240 nosy: creat0r priority: normal severity: normal status: open title: IDLE Trouble shooting versions: Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10428 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1520831] urrlib2 max_redirections=0 disables redirects
John J Lee jj...@users.sourceforge.net added the comment: That's silly. A justification of the need for a new feature isn't needed, because this is already-implemented feature that simply does the wrong thing at the edge case. It's not high priority, but it is a bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1520831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Roumen Petrov bugtr...@roumenpetrov.info added the comment: But different build system make new plaform ! Roumen -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10319] SocketServer.TCPServer truncates responses on close (in some situations)
Changes by Ralf Schmitt sch...@gmail.com: -- nosy: +schmir ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10319 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10428] IDLE Trouble shooting
R. David Murray rdmur...@bitdance.com added the comment: I would recommend posting to the python mailing list (see mail.python.org for a list of the mailing lists and subscribe to python-list). The bug tracker isn't a place to get help, but you might also try searching for windows idle bugs, since as I recall there are closed bugs that have some debugging suggestions in them. -- nosy: +r.david.murray resolution: - works for me stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10428 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: But different build system make new plaform! Maybe, but not a new sys.platform. VC6 and VS9.0 don't share any project file for the compilation; but they both build a sys.platform=='win32'. Distutils has to use another way to make the difference and choose the right compiler (in distutils.mscvcompiler.get_build_version()) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment:
I disagree;
i would say that you're entitled to disagree, but i have to point
out that unless you've actually been through the process of trying
to port python to mingw32 you're not really in a position of ...
how can i put this best... you're entitled to say i disagree
but that doesn't actually carry any weight.
if you said i've tried compiling this patch, and i looked at
it and i disagreed with the decision to create a new platform,
so i removed that code, here's an updated patch, i found it to
work absolutely fine THEN i would say that you are in a position
of authority to disagree.
so - question: have you actually _tried_ compiling python with
mingw32, with the latest patch?
programs compiled with mingw32 run on Windows, and use the MSVC
runtime.
they do indeed. this however has absolutely no relevance.
It's the same platform as the current win32 build.
It's even possible to use mingw32 to compile extensions
for the VS9.0 based python.exe.
it is indeed. the patch that i did allowed you to specify
a gcc spec file which did exactly that: i added options to
compile not only extensions but also the entire python.exe
to use a different MSVCRT runtime.
_and_ it did assemblies, too.
A different compiler does not make a new platform.
ok.
unfortunately, as the work that i did was well over a year ago,
i'm going from memory - but basically, i'm very very sorry to
have to point out that you don't know what you're talking about,
here.
let me try and go through it.
look at the platform detection code: it parses the gcc version
string. it goes if compiler has string gcc but also has win32
then it must be cygwin platform.
otherwise it goes this must be MSVC win32 platform.
this _simply_ doesn't work, hence the need to do further
detection, hence the need to have a separate compiler type.
... but it doesn't end there: there are subtle differences
between MSVC win32 and MINGW32 win32 (differences in the
build .lib files that specify what functions are available
in the DLLs. mingw32 is a reverse-engineering project,
remember?)
to be honest i can't remember if i actually set sys.platform to
mingw32 - but the more time i spent getting more and more modules
to compile, the more blindingly obvious it was that a new platform
type was needed.
i encountered dozens of assumptions that if sys.platform == 'win32'
then you MUST be building using visual studio: f*** off with your
attempt to compile this module using gcc.
over the eight to ten week period in which i focussed on this
non-stop for about 13 hours a day, the list just went on and on
of discrepancies that had to be solved, and if i _hadn't_ set a
new platform type, it would have been necessary to add extra
tests instead:
if sys.platform == 'win32' and not {something to detect mingw32}:
mingw32 _really_ does fall between both worlds: not just the
compiler type is different, but there are even features and
functions _missing_ from mingw32 that are present in MSVC.
i had to work with roumen to get patches to mingw32 upstream
in some cases!
so please _do_ stop putting road-blocks in the way. this is
a complex enough project, having to fit half way between
two disparate worlds, without it being stymied by disagreement
when you haven't _actually_ tried compiling this code (if you
have, i apologise).
btw if you'd like to try compiling it, but are adamant about
staying away from proprietary operating systems, i _did_
manage to get python 2.5 and 2.6 cross-compiled to run under wine.
ironically there were long-standing bugs in wine that ended up
getting fixed as a result of running the 25,000 python unit tests,
but that's another story... :)
l.
p.s. msys runs under wine as well, but the configure stage takes
well over an hour. the patch i created cut out most of configure
and replaced it with a pcconfig.h just like win32, which i had
to create by hand. this was quicker than waiting for configure
to run.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3871
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton l...@lkcl.net added the comment: perhaps, amaury, you might like to, instead of saying i disagree, you might like instead to say something like this: that sounds... interesting, and a little scary - creating an entirely new platform! are you absolutely sure it's necessary?? could you please perhaps elaborate and give a good justification behind why that decision was taken? you see how radically different that is? on the one hand you're telling three volunteers who have spent considerable time and resources - unpaid - on improving python's reach that they are, to put it bluntly, complete ignorant f*g morons, and on the other you're engaging with them, encouraging them, and generally trusting them. i'm really sorry: i really don't like having to be the one to point these kinds of things out, but... you see what i'm saying? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Roumen Petrov bugtr...@roumenpetrov.info added the comment: No it is win32 for the resulting binaries. Idea is following (issue3754) . Travial patch - move method get_platform global _get_platform and variable host_platform is initialized to its return value. Then replace all calls of sys.platform and get_platform() to use host_platform. In the patch for this issue _get_platform is modiffed to return mingw32 if so host_platform will be 'minwg32'. Including compiler and etc. don't work well in cross-compilation environment as the build script is run with python from build system. Roumen -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9807] deriving configuration information for different builds with the same prefix
Barry A. Warsaw ba...@python.org added the comment: Matthias, you mean $prefix/lib/python3.2 and $prefix/lib/python3.2$abiflags, right? The latter has just a config directory, and you'd rather see that become $prefix/lib/python3.2/config-$abiflags, right? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9807] deriving configuration information for different builds with the same prefix
Barry A. Warsaw ba...@python.org added the comment: Matthias, When you say the python.pc change should change includedir instead of Cflags, that seems weird. includedir does not currently include the 'pythonX.Y' subdirectory so there's no place to put the abiflags. Or are you suggesting that we move the pythonX.Yabiflags subdir to includedir and remove it from Cflags? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10262] Add --disable-abi-flags option to `configure`
Changes by Barry A. Warsaw ba...@python.org: -- assignee: - barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10262 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Luke, Please please! Don't make me say what I did not say. I just said I disagree, without any bad word. This may have been a bit terse, but I don't consider the issue tracker as a place to express one's feelings; hey, other core developers could have written -1 instead. I'm not trying to block this development, on the contrary, I'm getting interested in it so that we can merge it into CPython development tree. I'm here to help. Really. I did try to port python to the mingw32 compiler some years ago, and in the proposed patch I retrieve some of the changes I did at the time. IIRC I gave up because there were issues with the localtime function, and because of differences in the sprintf format. I'm glad that you found how to solve them. FYI, I'm also the maintainer of pypy on Windows, and we support both MSVC (8, 9, 10) and mingw32. i encountered dozens of assumptions that if sys.platform == 'win32' then you MUST be building using visual studio: f*** off with your attempt to compile this module using gcc. There are not so many of them in distutils. Did you see them in third-party packages? Code like this is wrong and should be changed, just like #ifdef MS_WINDOWS (=the platform) is not equivalent to #ifdef _MSC_VER (=the compiler) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10262] Add --disable-abi-flags option to `configure`
Matthias Klose d...@debian.org added the comment: I think this is not a good idea, because then you have different names for extension modules, which will be recognized by one configuration but not the other. This configure option should not change the sonames. If this option is to keep pathes like /usr/local/include/python3.2 (instead of /usr/local/include/python3.2mu) or /usr/local/lib/python3.2/config (instead of /usr/local/lib/python3.2mu/config), then fine with me. Although in this case we should make sure that these pathes are available in the sysconfig module. -- nosy: +doko ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10262 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9807] deriving configuration information for different builds with the same prefix
Matthias Klose d...@debian.org added the comment: On 15.11.2010 23:57, Barry A. Warsaw wrote: you mean $prefix/lib/python3.2 and $prefix/lib/python3.2$abiflags, right? The latter has just a config directory, and you'd rather see that become $prefix/lib/python3.2/config-$abiflags, right? yes. -- title: deriving configuration information for different builds with the same prefix - deriving configuration information for different builds with the same prefix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9807] deriving configuration information for different builds with the same prefix
Matthias Klose d...@debian.org added the comment: On 16.11.2010 00:01, Barry A. Warsaw wrote: When you say the python.pc change should change includedir instead of Cflags, that seems weird. includedir does not currently include the 'pythonX.Y' subdirectory so there's no place to put the abiflags. Or are you suggesting that we move the pythonX.Yabiflags subdir to includedir and remove it from Cflags? sorry, I'm wrong. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10429] bug in test_imaplib
New submission from Antoine Pitrou pit...@free.fr:
The following warning suggests the test is wrong:
c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_imaplib.py:231:
BytesWarning: Comparison between bytes and string
self.assertFalse('LOGINDISABLED' in self.server.capabilities)
--
assignee: pitrou
components: Library (Lib), Tests
messages: 121255
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: bug in test_imaplib
type: behavior
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10429
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10134] test_email failures on Windows: end of line issue?
Brian Curtin cur...@acm.org added the comment: Still not sure why they were not showing up on the buildbots. Victor was working from an svn checkout and I from the binary installer, so it's not just a difference in the svn eol handling. I too had only been seeing this in my checkout, but now that I setup a build slave I brought the bad luck there. http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%203.x/builds/0 (nothing new, same failures as haypo uploaded). -- nosy: +brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10134 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2244] urllib and urllib2 decode userinfo multiple times
Jessica McKellar jesst...@mit.edu added the comment: I can confirm that the combination of urllib_issue_updated.diff and urllib_ftptests_doubleencode.patch apply cleanly against py3k, that the added tests exercise the described bug, and that the full test suite passes after applying the patches. The patches look clean and conforming to PEP 8. -- nosy: +jesstess ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue716634] build_ext libraries subcommand not s
Changes by Éric Araujo mer...@netwok.org: -- resolution: wont fix - duplicate superseder: - Letting build_ext --libraries take more than one lib ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue716634 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9116] test_capi.test_no_FatalError_infinite_loop crash on Windows
Brian Curtin cur...@acm.org added the comment: The patch works for me. Unfortunately my knowledge on this particular area is very low so I can't really evaluate the patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9312] Fix usage of :option: markup in stdlib ReST docs
Éric Araujo mer...@netwok.org added the comment: Can I commit doc patches like this one despite the branch freeze? -- assignee: d...@python - eric.araujo resolution: - accepted status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1326113] Letting build_ext --libraries take more than one lib
Éric Araujo mer...@netwok.org added the comment:
I agree this is a bug: it’s a broken feature, not a new one, even if it can be
argued that fixing a long-standing behavior enables new usages, and is thus
comparable to a new feature.
I found no mention of --libraries in the docs, so I looked at the file history,
and it’s clear that the intent of the code does not match its behavior. The
fix is simple:
-if isinstance(self.libraries, str):
-self.libraries = [self.libraries]
+self.ensure_string_list('libraries')
I guess Greg forgot to change that line of code when he invented the ensure_*
methods. No test is broken by this change. Do we need a regression test for
this? It’s not strictly required IMO.
FTR, in distutils2, I want to make the types and formats clear for everything.
For example, build_ext.swig_opts is defined as “a list” in the current docs,
this time with an example that shows it’s space-separated
(“--swig-opts=-modern -I../include”). The code does not use
ensure_string_list, and hence does not support comma-separated. IMO, any value
described as list should accept space-separated and comma-separated. This is
probably out of scope for distutils, but something I definitely want to improve
in distutils2. Supporting multiple options (-lm -lfoo) is IMO feasible too.
--
assignee: tarek - eric.araujo
components: +Distutils2
stage: - unit test needed
type: feature request - behavior
versions: +3rd party, Python 2.7, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1326113
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10427] 24:00 Hour in DateTime
Changes by Éric Araujo mer...@netwok.org: -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10427 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10425] xmlrpclib support for None isn't compliant with XMLRPC
Éric Araujo mer...@netwok.org added the comment:
Thanks for the report and patch. You may find the following guidelines useful
for your future contributions: http://www.python.org/dev/patches/
I have two questions about the proposed fix. First, this line caught my eye:
if tag.split(':')[1] == 'nil':
It seems wrong to handle a nil element from any namespace the same way. I
think namespaces should be supported properly or not at all.
Second point, can you point us to documentation about nil? The Wikipedia
article about XML-RPC and http://ontosys.com/xml-rpc/extensions.php agree that
nil should not be a child of value, but say nothing about a namespace. If it’s
a band-aid for one specific server, I don’t think it’s acceptable.
--
nosy: +eric.araujo, loewis
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10425
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1326113] Letting build_ext --libraries take more than one lib
Éric Araujo mer...@netwok.org added the comment: I’ve reviewed other modules for the same error and found two candidates: config.libraries, the same thing as build_ext.libraries, and install.extra_path, for which I’m not sure. (More distutils2 thoughts: A number of options are split on os.pathsep, a new ensure_dirs_list method looks in order. Regarding the type system, an angry comment in build_py confirmed the need :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1326113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10417] unittest triggers UnicodeEncodeError with non-ASCII character in the docstring of the test function
Jeffrey Finkelstein jeffrey.finkelst...@gmail.com added the comment: I am not having this problem on Ubuntu 10.10 with the most recent Python 2.7: terminal interaction $ ./python unicodetest.py --verbose test_unicode_docstring (__main__.UnicodeTest) täst - docstring with unicode character ... ok -- Ran 1 test in 0.000s OK $ ./python unicodetest.py test_unicode_docstring (__main__.UnicodeTest) täst - docstring with unicode character ... ok -- Ran 1 test in 0.000s OK /terminal interaction -- nosy: +jfinkels ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10417 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10417] unittest triggers UnicodeEncodeError with non-ASCII character in the docstring of the test function
Éric Araujo mer...@netwok.org added the comment: Great, thank you for the update! Closing. -- resolution: - out of date stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10417 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8254] write a configure command
Éric Araujo mer...@netwok.org added the comment: I have turned my branch into a clean patch for default: https://bitbucket.org/Merwok/distutils2/changeset/076b15559290 Notes: - You can diff configure.py against build.py and install_dist.py from an earlier revision to see what code has been moved where. - Two tests for install_dist still fail, but this could be only the tip of the iceberg. We need more tests there. Installation paths is a tricky business, and we have to make sure configure does not break anything. - I have changed install to install_dist in the code, tests and docs, but only in the part of the docs I added for configure. The rest of the file is inaccurate, but that’s outside the scope of this patch. - Some to-do features: distribute the configure.cache file in the dist-info directory (requires adding a hook system to install_distinfo); add info about the compiler type; probably more. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8254 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8254] write a configure command
Changes by Éric Araujo mer...@netwok.org: -- keywords: +needs review, patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8254 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7900] posix.getgroups() failure on Mac OS X
R. David Murray rdmur...@bitdance.com added the comment: Ronald, on a normal unix system if you add a user to a group, any existing process/terminal session that runs 'id -G' will return the *old* group list. Only a new process/terminal session will see the new group. On OSX, 'id -G' returns the new group when run in an existing process/terminal session, according to what you wrote. You can't just remove the 'id -G' from that test, because the test is using 'id -G' to get an independent verification of the list of group numbers as a check against what getgroups returns. On a normal unix system, these two would match. On OSX, they don't. At the moment I don't see any alternative to skipping the test on OSX with a message that 'id -G' and 'getgroups' do not return the same group list on OSX. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10430] _sha.sha().digest() method is endian-sensitive. and hexdigest()
New submission from Kristján Valur Jónsson krist...@ccpgames.com: in shamodule.c, the digest() method just creates a simple bytes string of the digest. The digest is stored as an array of 32 bit integers in the native representation. Therefore, the digest will be different on big- and little-endian machines. The specification (http://en.wikipedia.org/wiki/SHA-1) suggest that the digest should actually be big endian, so the standard implementation on most home machines is actually wrong Actually, looking at the code, hexdigest() has the same problem! -- components: Extension Modules messages: 121268 nosy: krisvale priority: normal severity: normal status: open title: _sha.sha().digest() method is endian-sensitive. and hexdigest() type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10430 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7900] posix.getgroups() failure on Mac OS X
Stephen Hansen me+pyt...@ixokai.io added the comment: The test is clearly verifying a *wrong* assumption: that id -G will match posix.getgroups() which simply does not hold on OSX. I can reproduce this reliably on a completely clean, brand new installation of 10.5: from there the only things that have been done to the box is updating to 10.5.8, and then downloading the latest XCode tools that run on Leopard. From here, launch Terminal: leave the console open. Run id -G; then run python and look at posix.getgroups(). Now, go into System Preferences and add a new user. Don't do anything else. Don't change anything with existing user. In the console that was already open, do id -G again. Now run python again, and do posix.getgroups() -- those no longer match. Clearly IMHO the assumption that the test is declaring to be an expected result simply is not true in a OSX-Unix environment. Yes, if I go and *edit the actual slave user* then surely I can expect failures until I restarted the buildslave. But, if by merely adding a user causes a change to the buildslaves user by no action of my own, and that causes this test to be invalid... the test itself seems to be founded on assumptions which simply are not reliably true. I understand disabling the test means os.getgroups() will no longer be tested on OSX: and yet, the current situation is a specific behavior of os.getgroups() is tested which is *not* actually the guaranteed behavior of that operation. There is at least one very easy to reproduce situation in which id -G and posix.getgroups() do not match: I don't know if there are more. But for the test to assert the truth that its only correct when they match seems to be a mistake. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
