[issue23605] Use the new os.scandir() function in os.walk()
Scott Dial added the comment: I cloned https://github.com/benhoyt/scandir @ 494f34d784 and ran benchmark.py on a couple systems that are Linux backed by a couple different NFS servers of various quality. First, a Linux VM backed by a Mac OS X NFS server backed by a SSD: $ python benchmark.py Using slower ctypes version of scandir Comparing against builtin version of os.walk() Priming the system's cache... Benchmarking walks on benchtree, repeat 1/3... Benchmarking walks on benchtree, repeat 2/3... Benchmarking walks on benchtree, repeat 3/3... os.walk took 0.088s, scandir.walk took 0.084s -- 1.1x as fast $ python benchmark.py -s Using slower ctypes version of scandir Comparing against builtin version of os.walk() Priming the system's cache... Benchmarking walks on benchtree, repeat 1/3... Benchmarking walks on benchtree, repeat 2/3... Benchmarking walks on benchtree, repeat 3/3... os.walk size 23400, scandir.walk size 23400 -- equal os.walk took 0.142s, scandir.walk took 0.145s -- 1.0x as fast Second, a Linux VM backed by a Linux NFS server backed by a NAS with big, slow drives: $ python benchmark.py Using slower ctypes version of scandir Comparing against builtin version of os.walk() Priming the system's cache... Benchmarking walks on benchtree, repeat 1/3... Benchmarking walks on benchtree, repeat 2/3... Benchmarking walks on benchtree, repeat 3/3... os.walk took 0.071s, scandir.walk took 0.063s -- 1.1x as fast $ python benchmark.py -s Using slower ctypes version of scandir Comparing against builtin version of os.walk() Priming the system's cache... Benchmarking walks on benchtree, repeat 1/3... Benchmarking walks on benchtree, repeat 2/3... Benchmarking walks on benchtree, repeat 3/3... os.walk size 23400, scandir.walk size 23400 -- equal os.walk took 0.118s, scandir.walk took 0.141s -- 0.8x as fast Finally, a linux VM backed by a Linux NFS server backed by a NAS with small, fast SAS drives: $ python benchmark.py Using slower ctypes version of scandir Comparing against builtin version of os.walk() Priming the system's cache... Benchmarking walks on benchtree, repeat 1/3... Benchmarking walks on benchtree, repeat 2/3... Benchmarking walks on benchtree, repeat 3/3... os.walk took 0.159s, scandir.walk took 0.119s -- 1.3x as fast $ python benchmark.py -s Using slower ctypes version of scandir Comparing against builtin version of os.walk() Priming the system's cache... Benchmarking walks on benchtree, repeat 1/3... Benchmarking walks on benchtree, repeat 2/3... Benchmarking walks on benchtree, repeat 3/3... os.walk size 23400, scandir.walk size 23400 -- equal os.walk took 0.229s, scandir.walk took 0.232s -- 1.0x as fast A major factor that is not addressed above is that the performance is dramatically different if the metadata cache for the NFS mount is disabled, which is not the default. In the above data, the first system is normally configured in such a manner in order to ensure that the filesystem is coherent. The results of that test is much more dramatic: $ python benchmark.py Using slower ctypes version of scandir Comparing against builtin version of os.walk() Priming the system's cache... Benchmarking walks on benchtree, repeat 1/3... Benchmarking walks on benchtree, repeat 2/3... Benchmarking walks on benchtree, repeat 3/3... os.walk took 4.835s, scandir.walk took 0.097s -- 49.9x as fast $ python benchmark.py -s Using slower ctypes version of scandir Comparing against builtin version of os.walk() Priming the system's cache... Benchmarking walks on benchtree, repeat 1/3... Benchmarking walks on benchtree, repeat 2/3... Benchmarking walks on benchtree, repeat 3/3... os.walk size 23400, scandir.walk size 23400 -- equal os.walk took 9.945s, scandir.walk took 5.373s -- 1.9x as fast -- nosy: +scott.dial ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23605 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2975] VS8 include dirs grow without bound
Scott Dial sc...@scottdial.com added the comment: I was looking through old issues I had commented on and saw that my patch was never applied. The current tip of the codebase still has the redundant removeDuplicates function. Not a big deal, just a little extra noise in the code. Probably not worth opening a new ticket for it, but I'd thought I'd ping the nosies (Amaury). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2975 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10639] reindent.py should not convert newlines
Scott Dial sc...@scottdial.com added the comment: I haven't seen anyone use a side-effect-less statement (a string) as a comment before, but I doubt that is an approved style for the CPython codebase. Please change the string preceeding the spec_line definition into a proper comment. -- nosy: +scott.dial ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
Scott Dial sc...@scottdial.com added the comment: Antoine Pitrou wrote: It would be nice if it were enabled by default for fatal errors (and asserts perhaps?). I feel like a broken record. This code hardcodes fd=2 as a write target on crash, which is not safe thing to do at all. You can argue that adopters of Python 3.3 should have to deal with that fact, but it's obscure and there is no way to warn anyone about it except by putting a NEWS item, and if the PyCapsule discussion on python-dev have taught us anything: even well meaning programmers miss these things all the time. I have stated this repeatedly on the other issues for this same discussion. I think creating a completely new issue for this same topic has segmented the discussion unfortunately. I wrote a much longer and more thoughtful explanation of why faulthandler writes to the wrong thing here: http://bugs.python.org/msg124381 AFAICT, Victor has addressed my issue by giving programmers yet another interface to configure (that they may or may not be aware of). So, the only way this acceptable to me is if it's off by default and a programmer who wants this functionality opts-in and has taken care to make sure it does the right thing. My suggestion that faulthandler needs to find a way to be coupled to sys.stderr still stands. -- nosy: +scott.dial ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11450] Py_GetBuildInfo() truncates when there are many hg tags
New submission from Scott Dial sc...@scottdial.com: I'm not sure if it's intended to be a supported workflow, but I personally have come to like using mq for projects where I am an outsider submitting small changes as patches. However, this appears to be a broken workflow due to way getbuildinfo module choose to limit the buildinfo string to 50 characters: $ hg qnew dummy-patch $ echo /* dummy change */ Modules/getbuildinfo.c $ ./python -c 'import sys; print(sys.version)' 3.3a0 (dummy-patch qbase qtip tip:191f047a07b4+, Mar 9 ) [GCC 4.4.5] This breaks the platform module and therefore breaks the regrtest code, which makes it a show-stopper for using mq to manage your workflow. Is there any reason that length of buildinfo can't be chosen at compile-time based on the sizeof(HGTAG)? -- components: Build messages: 130432 nosy: scott.dial priority: normal severity: normal status: open title: Py_GetBuildInfo() truncates when there are many hg tags type: feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11450 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Scott Dial sc...@scottdial.com added the comment: I'm well aware of the limited use of Py_UniversalNewlineFgets() in py3k, but it remains the case that it is a public API that fails to work correctly under the conditions specified by the reporter, and Alexander confirmed the original patch fixed the issue. AFAICT, there no longer are any test cases (beyond the indirect testing of the dependent code) for Py_UniversalNewlineFgets(). One of the issues with applying the patch to tip was due to commenting out some code in it: /* if ( c == EOF skipnextlf ) newlinetypes |= NEWLINE_CR; */ For issue8914, which really should've just deleted those two lines, but there was not such an extensive review of that change. The unittests have there own merit. The file object API is supposed to behave in the manner that the tests exercise them. There are currently no tests that would inform us if any change broke this documented behavior. If you want to split the patch in two to treat them as independent items, then fine. Otherwise, close the issue as WONTFIX due to obsolescence. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Scott Dial sc...@scottdial.com added the comment: I've updated the patch to apply to the current tip. (This patch was an opportunity for me to update to an Hg workflow.) Alexander, I disagree with you about the tests. The unittests use the exact same pattern/model that testIteration uses. I find your complaint that a unittest, which does test the feature under question, is not good enough, despite the prevailing unittests being designed in the same manner, to be absurd. Practicality beats purity -- a test that works is better than no test at all. By rejecting unittests on the merits of its coding style, you are creating a double-standard for people like me (outside of the core committers), which eventually wears out my interest in helping you get this improvement into your project. I have been chased around this obstacle course before. For example, issue5949, when I was asked to provide unittests for a module that had *none*, for a 3-line patch that nobody disagreed it being correct. I had a vested interest in jumping through the obstacles of getting that patch in, but here I am again being blocked from making a 3-line patch, except this time, purely for stylistic reasons. -- Added file: http://bugs.python.org/file21060/issue1706039-py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10899] No function type annotations in the standard library
Scott Dial sc...@scottdial.com added the comment: Raymond Hettinger wrote: I think those annotations should be replaced with comments. In your revisions, you didn't do anything but blow away the annotations despite what you said here, which is an unfortunate loss of information for implementers and users of those interfaces. -- nosy: +scott.dial ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10899 ___ ___ 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
Scott Dial sc...@scottdial.com added the comment: On 12/22/2010 8:52 PM, STINNER Victor wrote: Amaury asked for a sys.setsegfaultenabled() option: I think that the command line option and the environment variable are enough. I really think you should think of it as a choice the developer of an application makes instead of a choice an application user makes. A setsegfaultenabled() could just be another step of initializing the application akin to setting up the logging module, for instance. In that situation, a function call has a much lower barrier for use than a CLI option or environment variable where you'd have to create a wrapper script. -- title: Display Python backtrace on SIGSEGV, SIGFPE and fatal error - Display Python backtrace on SIGSEGV, SIGFPE and fatal error ___ 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
[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error
Scott Dial sc...@scottdial.com added the comment: On 12/22/2010 10:35 PM, STINNER Victor wrote: Why do you think so? Can you give me an use case of sys.setsegfaultenabled()? To feed back your own argument on python-dev: How do you know that you application will crash? The idea is to give informations to the user when an application crashs: the user can use the backtrace or send it to the developer. Segmentation faults are usually not (easilly) reproductible :-( So even if you enable the fault handler, you may not be able to replay the crash. Or even worse, the fault may not occurs at all when you enable the fault handler... (Heisenbugs!) After the discussion on python-dev, I don't think that the fault handler should be enabled by default, but only for a single run. I agree that it should be disabled by default because of the potential do bad things if the application was not wrote with it in mind. But an application developer would be in a much better position to decide what the default should be for their application if they believe they will be able to get more useful bug reports from their users by enabling it. I thought that was your position, but if you no longer believe that, then I will not push for it. -- title: Display Python backtrace on SIGSEGV, SIGFPE and fatal error - Display Python backtrace on SIGSEGV, SIGFPE and fatal error ___ 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
[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error
Scott Dial sc...@scottdial.com added the comment: On 12/20/2010 8:30 AM, STINNER Victor wrote: Write into a closed file descriptor just does nothing. Closed file descriptors are not a problem. My issue not with a closed file descriptor, it is with an open file descriptor that is not what you think it is. For all you know, fd=2 currently is a network socket that you will be throwing gibberish at, or worse it could be a block device that you are writing gibberish on. The GNU libc has also a fault handler (source code: debug/segfault.c). It uses the file descriptor 2, except if SEGFAULT_OUTPUT_NAME environment variable is set (value stored in fname variable): open the specified file. The GNU libc segfault handler is *opt-in* via the SEGFAULT_SIGNALS environment variable. I do not know of a system where SEGFAULT_SIGNALS is a part of the default environment. I suspect the only time anyone uses that variable and code is if they are using the catchsegv tool, which comes with glibc. In any case, that developer should be aware of the implication of closing fd 2. The FILE* type cannot be used because fprintf(), fputs(), ... are not signal- safe. My point was that in C++, they have an object that an application developer more readily associates with stderr than fd 2. That writing to stderr leads to a write to fd 2 is incidental, because it's possible that stderr does *not* lead to a write to fd 2 and that writing to fd 2 would be a bad thing to do blindly. For instance, you can call freopen(path, mode, stderr) and fd 2 will end up closed and another fd will be the target of stderr. I don't believe POSIX guarantees that open() will not re-use fd 2. The problem is to detect that stderr file descriptor changes (eg. closed, duplicated, reopened, etc.). I don't think that it's possible to detect such changes (with a portable function). When I said that, I hadn't fully investigated the intricacies of the io types. I was unaware that you could assign to sys.stderr.buffer.raw and change out the target fd. I assumed a BufferedWriter could not have the target stream changed out from beneath it. So, I don't have a solution to the problem of knowing the correct (if any) file descriptor to write to. If the argument is made that fd 2 is the right place for most Python applications, then there needs to be a programmatic way to disable this feature and/or tell it where to write, so that programs that daemonize can do the right thing. -- title: Display Python backtrace on SIGSEGV, SIGFPE and fatal error - Display Python backtrace on SIGSEGV, SIGFPE and fatal error ___ 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
[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error
Scott Dial sc...@scottdial.com added the comment: FYI, in v10, +#define NFAULT_SIGNALS (sizeof(fault_signals) / sizeof(fault_signals[0])) +static fault_handler_t fault_handlers[4]; , should use NFAULT_SIGNALS instead of 4. However, this bit of code bothers me a lot: +const int fd = 2; /* should be fileno(stderr) */ To assume that fd=2 is the write place to be writing bytes is assuming quite a bit about the state of the application. It is not unusual at all to close 0,1,2 when writing daemons, which frees them up to be assigned to *anything*. For all you know, fd=2 currently is a network socket that you will be throwing gibberish at, or worse it could be a block device that you are writing gibberish on. The closest discussion I could find on this subject was on the libstdc++ mailing-list with regard to their verbose termination code: http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02388.html AFAICT, their conclusion was that the only reasonable solution was to write to the stderr FILE since it was the only thing that is guaranteed to make sense always (even though it may fail). Their situation is different in that they are handling a C++ exception, so they don't have to stick to async-safe functions, but absent that extra difficulty, I believe the reasoning is the same. The analogous situation exists in Python, in that sys.stderr(*) represents where the application programmer expects stderr writing to go. I think you need to arrange to know what the fd number for that object is or this patch is unacceptable in the vein of wrote garbage to my harddrive and destroyed my data sort. I'm not sure there is a safe way to know what the fileno for sys.stderr is because it can be anything, including an object whose fileno changes over time. However, I think it would be fair to support only built-in io types that are obviously safe, since you could cache the fileno() value at assignment to use in your fault handler. (*) Or perhaps __stderr__ if stderr is None or an unsupported type? -- nosy: +scott.dial ___ 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
[issue1706039] Added clearerr() to clear EOF state
Scott Dial sc...@scottdial.com added the comment: The patch includes unittests; the issue is that the tests pass without the changes. That is an entirely different state to be in. The tests should be committed unless somebody wants to object to the behavior that they are testing (although I believe this behavior is already codified in documentation). If the tests start failing on someone's platform, then you have a patch already waiting to be applied. Nevertheless, I don't see the harm in the patch as-is, because it is a quite innocuous change to Py_UniversalNewlineFgets(), unless (again) you want to argue about the correctness of that change despite no test failing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ 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()
Scott Dial sc...@scottdial.com added the comment: Got a test case that demonstrates a failure? Looks like it works to me... $ uname -ip sparc SUNW,Sun-Fire-280R $ python -c 'import sys; print sys.byteorder' big $ python -c 'import sha; print sha.new(open(test, rb).read()).hexdigest()' 851faf3199d27200abf2750c14ae6451696216a9 $ sha1sum -b test 851faf3199d27200abf2750c14ae6451696216a9 *test # uname -ip AMD Sempron(tm) Processor 2800+ AuthenticAMD # python -c 'import sys; print sys.byteorder' little # python -c 'import sha; print sha.new(open(test, rb).read()).hexdigest()' 851faf3199d27200abf2750c14ae6451696216a9 # sha1sum -b /tmp/test 851faf3199d27200abf2750c14ae6451696216a9 *test I think your code analysis is wrong. Perhaps you missed the call to longReverse(), which does endianness byte-swapping, at the beginning of the sha_transform() that specifically is commented: When run on a little-endian CPU we need to perform byte reversal on an array of longwords. -- nosy: +scott.dial ___ 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
[issue10432] concurrent.futures.as_completed() spins waiting for futures to complete
Scott Dial sc...@scottdial.com added the comment: Good catch. I suppose it was inevitable when I transferred my changes into a SVN checkout that I missed something. Nevertheless, your changeset in r86491 matches my own. Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10432 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10432] concurrent.futures.as_completed() spins waiting for futures to complete
New submission from Scott Dial sc...@scottdial.com: The code in as_completed() waits on a FIRST_COMPLETED event, which means that after the first future completes, it will no longer wait at all. The proposed patch adds a _AsCompletedWaiter and uses a lock to swap out the finished list and reset the event. This is a difficult problem to create a test case for without adding intrusive code to as_completed() to count how many times it loops or create a mock Event object that counts it, so I have not proposed a test. -- components: Library (Lib) files: futures-r86476.patch keywords: patch messages: 121280 nosy: scott.dial priority: normal severity: normal status: open title: concurrent.futures.as_completed() spins waiting for futures to complete type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file19615/futures-r86476.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10432 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6507] Enhance dis.dis to autocompile codestrings
Scott Dial sc...@scottdial.com added the comment: disassemble_str should be private with an underscore. disassemble_string should've been private as well, while we are editing this module. -- nosy: +scott.dial ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6507 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8636] enumerate() test cases do not cover optional start argument
New submission from Scott Dial sc...@scottdial.com: The issue2831 patch test cases are not actually being run by test_enumerate and they were broken tests anyways. This patch fixes the brokenness. -- components: Interpreter Core, Tests files: test_enumerate.patch keywords: patch messages: 105147 nosy: scott.dial priority: normal severity: normal status: open title: enumerate() test cases do not cover optional start argument type: behavior versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file17237/test_enumerate.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2831] Adding start to enumerate()
Scott Dial sc...@scottdial.com added the comment: Created issue8636 for the broken test cases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Scott Dial sc...@scottdial.com added the comment: I've attached a patch that applies cleanly against py3k. I do not have an in-depth understanding of the new io module, but at a cursory glance, it seems to not use FILE streams, and would not be subject to this bug. However, Py_UniversalNewlineFgets() still remains, and I have patched it accordingly. Additionally, I have added the test to test_fileio. py3k doesn't fail any of these tests for me, but the original issue was only exposed on OS X. -- Added file: http://bugs.python.org/file15516/issue1706039-py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Changes by Scott Dial sc...@scottdial.com: Added file: http://bugs.python.org/file15517/issue1706039-py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Changes by Scott Dial sc...@scottdial.com: Removed file: http://bugs.python.org/file15516/issue1706039-py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Changes by Scott Dial sc...@scottdial.com: Added file: http://bugs.python.org/file15508/test_imaplib_issue5949-py26.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Changes by Scott Dial sc...@scottdial.com: Added file: http://bugs.python.org/file15509/test_imaplib_issue5949-py26.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Changes by Scott Dial sc...@scottdial.com: Removed file: http://bugs.python.org/file15508/test_imaplib_issue5949-py26.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Changes by Scott Dial sc...@scottdial.com: Removed file: http://bugs.python.org/file15509/test_imaplib_issue5949-py26.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Scott Dial sc...@scottdial.com added the comment: I tracked the necessary change to r73638 and issue6267. However, I am not sure it is in scope to backport all of that. The only changed actually needed from this set to make SocketServer behave correctly with a SSLSocket is: def close_request(self, request): Called to clean up an individual request. +#explicitly shutdown. socket.close() merely releases +#the socket and waits for GC to perform the actual close. +request.shutdown(socket.SHUT_WR) request.close() Hence in my py26 patch, I have made a call to shutdown() within the handler. I would call this a bug, but nobody seems to have noticed but me, so I defer to you about the best solution. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Scott Dial sc...@scottdial.com added the comment: I've revised my opinion. If you extract out only the changes to SocketServer and ignore the others, then I would consider it a good backport (fixes bugs only). I have attached such a patch. BTW, with this patch, you can remove the shutdown() call in the test_imaplib patch. -- Added file: http://bugs.python.org/file15511/socketserver_issue_6267.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Scott Dial sc...@scottdial.com added the comment:
It seems that on the py3k branch, the EOF situation is handled roughly
in the same manner (the broken line is returned) and ultimately the
IMAP4.abort exception is raised because b'* ' is an invalid response
(the 'OK' having been dropped). IOW, it passes the EOF test only because
trimming broke the welcome message format. If it got an EOF in the
middle of a more complicated response, it would go undetected or cause a
broken response.
I propose adding the following test case:
@reap_threads
def test_line_termination(self):
class BadNewlineHandler(SimpleIMAPHandler):
def cmd_CAPABILITY(self, tag, args):
self._send(b'* CAPABILITY IMAP4rev1 AUTH\n')
self._send('{} OK CAPABILITY
completed\r\n'.format(tag).encode('ASCII'))
with self.reaped_server(BadNewlineHandler) as server:
self.assertRaises(imaplib.IMAP4.abort,
self.imap_class, *server.server_address)
Which silently misreads the CAPABILITY response as including AUT and
not AUTH. It would be a perversely broken server, but I think this
test case demonstrates why an explicit check and exception should be
thrown always.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5949
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Scott Dial sc...@scottdial.com added the comment: The design of your patch makes a lot of sense. I found that your patch uncovered a problem with using the ThreadingMixin (which is ultimately not necessary as long as the whole SocketServer is in its own thread). I rewrote the SimpleIMAPHandler to timeout in a timely manner and for the reap_server() to actually ensure that all threads have been shutdown. I ended up rewriting my patch in steps towards yours before I uncovered why I was getting threads alive at shutdown. In that vein, the patch I am attaching uses the with reaped_server(hdlr) as server: technique, but it could be converted to use an attribute instead. I find using with easier to read and less error prone (failing shutdown the server and thread because human error or an uncaught exception). -- Added file: http://bugs.python.org/file15472/test_imaplib_issue5949-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Scott Dial sc...@scottdial.com added the comment: I actually thought I was complying with PEP8.. yikes. I guess my personal rules are slightly different. I think the latest attached patch is PEP8 compliant now. And, I moved the import_module() to the top as you suggested. -- Added file: http://bugs.python.org/file15474/test_imaplib_issue5949-3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Changes by Scott Dial sc...@scottdial.com: Removed file: http://bugs.python.org/file15460/test_imaplib-r76683.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Changes by Scott Dial sc...@scottdial.com: Removed file: http://bugs.python.org/file15466/test_imaplib-r76683-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Changes by Scott Dial sc...@scottdial.com: Removed file: http://bugs.python.org/file15472/test_imaplib_issue5949-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Changes by Scott Dial sc...@scottdial.com: Removed file: http://bugs.python.org/file15457/imaplib-eof-test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Scott Dial sc...@scottdial.com added the comment: The test requires regrtest.py be run with network support and the python instance be built with threads. $ ./python Lib/test/regrtest.py -u network test_imaplib Without network support, it just skips those test (which is the same way test_ssl). That seemed a bit fishy to me, but I was just emulating what I saw. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Scott Dial sc...@scottdial.com added the comment: Thanks for giving it a try. I believe the issue is that I am raising an exception in the middle of run_server, which was not a pattern tested in the other modules I looked at. Thus, the threads for those do not get reaped correctly. I have rewrote the test to ensure all of the spawned threads and servers are shutdown correctly. -- Added file: http://bugs.python.org/file15466/test_imaplib-r76683-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Scott Dial sc...@scottdial.com added the comment: Alright, I am attaching a new patch to correct the brain-fart inefficiency of slicing versus endswith(). I don't understand why this is so difficult to review. I don't think Janssen is the right person to have been assigned to this. While it is related to SSL, I don't think the IMAP module is even on his radar. Whereas, I use this module everyday, every 10 minutes every day to fetch my email (via getmail), and can assure you that the 110 character change is correct. -- Added file: http://bugs.python.org/file15456/imaplib-r76683.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Changes by Scott Dial sc...@scottdial.com: Removed file: http://bugs.python.org/file15013/imaplib-r75166.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Scott Dial sc...@scottdial.com added the comment: Ben, I understand that we are all volunteers here. My frustration in the lack of a de facto owner of the imaplib module and not with you personally or any other committer for that matter. As it is, there is no unittests for the imaplib module, and I am not in a position to provide a complete implementation of an IMAP server. However, I have attached a simple script demonstrating the issue. An unpatched trunk will infinite loop, consuming memory, and a patched version will throw a Traceback immediately. -- Added file: http://bugs.python.org/file15457/imaplib-eof-test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Scott Dial sc...@scottdial.com added the comment: I found myself in the mood to code, so in the spirit of every step counts, I have attached a patch that updates test_imaplib accordingly. The construction of the test framework is based loosely on test_ssl and test_socketserver. If someone felt so moved to add more test cases, then one would could simply extend SimpleIMAPHandler to handle more IMAP commands. FYI, as previously noted, on an unpatch trunk test_issue5949() is an infinite loop. -- Added file: http://bugs.python.org/file15458/test_imaplib-r76683.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Changes by Scott Dial sc...@scottdial.com: Added file: http://bugs.python.org/file15459/test_imaplib-r76683.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Changes by Scott Dial sc...@scottdial.com: Removed file: http://bugs.python.org/file15458/test_imaplib-r76683.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Changes by Scott Dial sc...@scottdial.com: Added file: http://bugs.python.org/file15460/test_imaplib-r76683.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Changes by Scott Dial sc...@scottdial.com: Removed file: http://bugs.python.org/file15459/test_imaplib-r76683.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7084] printing a list releases the GIL carelessly
Scott Dial sc...@scottdial.com added the comment: I've attached a patch that fixes this issue by grabbing a reference to the item to be printed just before releasing the GIL. -- keywords: +patch nosy: +scott.dial Added file: http://bugs.python.org/file15099/list_print-r75317.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7084 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Scott Dial sc...@scottdial.com added the comment: It would seem the logical patch would be to return the line when the empty string is returned. This would fall in line with the behavior of other objects with a readline() in python. In following with that, the patch I have attached returns a truncated line. Therein, the _get_line() implementation needs to actually check for the correct termination of the line (it's arguably a bug as it is, just chucking away the last two characters blindly). -- keywords: +patch nosy: +scott.dial Added file: http://bugs.python.org/file15012/imaplib-r75166.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Changes by Scott Dial sc...@scottdial.com: Removed file: http://bugs.python.org/file15012/imaplib-r75166.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
Changes by Scott Dial sc...@scottdial.com: Added file: http://bugs.python.org/file15013/imaplib-r75166.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Scott Dial sc...@scottdial.com added the comment: They differ because in Py_UniversalNewlineFgets() there is a call to FLOCKFILE(), and it seemed appropriate to ensure that clearerr() was called after locking the FILE stream. I certainly pondered over whether it made a difference to do it before or after, and it would seem to me that if we are bothering to lock the FILE stream then we would care to ensure that the first GETC() after locking reaps the benefit of having called clearerr(). In the cases that we fall into fread and fgets, we may actually need to be doing: FLOCKFILE(stream) clearerr(stream); result = fgets(buf, n, stream); FUNLOCKFILE(stream); return result; One nitpick is that the testcase was appended to the StdoutTests class instead of OtherFileTests class, which would seem more appropriate. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Scott Dial sc...@scottdial.com added the comment: I believe the original patch is overreaching. I believe the changes to fileobject.c should've been much simpler, just as the title describes (adding clearerr() just before performing reads on the FILE handles). I've attached a much simpler patch that I believe corrects the issue, but I don't have an OS X platform to try it on. -- nosy: +scottdial Added file: http://bugs.python.org/file12425/fileobject.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4711] Wide literals in the table of contents overflow in documentation
New submission from Scott Dial sc...@scottdial.com: There is a problem with the table contents with respect to literals that cannot be word-wrapped. I see this issue here: http://docs.python.org/dev/2.6/library/multiprocessing.html The line in the table of contents that reads The multiprocessing.dummy module is broken in that the literal multiprocessing.sharedctypes overflows into the right-hand side. It also ends up underneath the contents on the right, which makes it extra hard to know what that entry was about. This instance may be browser specific, but I think it brings up a more general question of what should be done with such long literals and how overflow should be handled. And perhaps even whether it is wise to have set the width of that div to such a narrow and specific value (230px). I've attached a screenshot from Firefox 2.0.0.20/Win32 in case it is not as reproducible as I would expect. -- assignee: georg.brandl components: Documentation files: multiprocessing.png messages: 78151 nosy: georg.brandl, scottdial severity: normal status: open title: Wide literals in the table of contents overflow in documentation type: behavior Added file: http://bugs.python.org/file12416/multiprocessing.png ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4711 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2975] VS8 include dirs grow without bound
Scott Dial [EMAIL PROTECTED] added the comment: This patch shouldn't have been applied as it is. The definition of removeDuplicates is both poorly-named, not exactly correct, and redundant (as there is already a normalize_and_reduce_paths) for performing this fix on PATH. Jim, you acknowledged already that: The normalize_and_reduce_paths() function needs to be performed on INCLUDE and LIBPATH in addition to the exec path. i.e. os.environ['lib'] and os.environ['include']. So, I don't understand how that got missed. I've attached a patch that removes the extra code. Added file: http://bugs.python.org/file11351/msvc9compiler_path.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2975 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2975] VS8 include dirs grow without bound
Scott Dial [EMAIL PROTECTED] added the comment: The path gets changed everytime a MSVCCompiler is instantiated. I've seen the same problem with PATH before with PyPy. I agree this is a bug, but I don't see how it can be fixed. The problem exists inside of vcvarsall.bat if I understand this correctly. Furthermore, I don't understand how an exception could actually be thrown; the vc_env values are sourced from the environment after running vcvarsall.bat, so how could they be too long? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2975 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2975] VS8 include dirs grow without bound
Scott Dial [EMAIL PROTECTED] added the comment: I don't believe this is a valid bug. Can you provide a case where it does in fact grow? This issue has previously been addressed in #1685563, and was carried over to the new code as well. Some lines after the path is appended to, there is a call to normalize_and_reduce_paths(...), which removes duplicates almost exactly like you wrote it. -- nosy: +scottdial ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2975 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1775025] zipfile: Allow reading duplicate filenames
Scott Dial [EMAIL PROTECTED] added the comment: In the patch you commented why is 'filepos' computed next? It's never referenced. The answer is that back at r54152 (#1121142) the method was rewrote removing any reference to 'filepos', but the patch author failed to remove that line. Please remove it. -- nosy: +scottdial _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1775025 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2831] Adding start to enumerate()
Scott Dial [EMAIL PROTECTED] added the comment: As it stands, enumerate() already takes a sequence keyword as an alternative to the first positional argument (although this seems to be completely undocumented). So, as you say, METH_O is a no go. I agree with you in that my original complaint with the positional argument was that enumerate(iterable, start) was backwards. My other argument was that a large number of these iterator utility functions are foo(*iterable) and upon seeing enumerate(foo, bar), a reader might be inclined to assume it was equivalent to enumerate(chain(foo, bar)). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2831 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2831] Adding start to enumerate()
New submission from Scott Dial [EMAIL PROTECTED]: Georg Brandel suggested enumerate() should have the ability to start on an arbitrary number (instead of always starting at 0). I suggest such a parameter should be keyword-only. Attached is a patch to add such a feature along with added test cases. Documentation still needs to be updated, but I wasn't sure how best to handle that anyways. I wasn't sure how best to handle a keyword-only argument, so I'd be interested to know if there is a better way. -- components: Interpreter Core files: enumerate.diff keywords: patch messages: 66705 nosy: scottdial severity: normal status: open title: Adding start to enumerate() type: feature request versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10299/enumerate.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2831 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2831] Adding start to enumerate()
Changes by Scott Dial [EMAIL PROTECTED]: Added file: http://bugs.python.org/file10300/enumerate.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2831 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2831] Adding start to enumerate()
Changes by Scott Dial [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10299/enumerate.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2831 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2831] Adding start to enumerate()
Changes by Scott Dial [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10300/enumerate.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2831 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2831] Adding start to enumerate()
Changes by Scott Dial [EMAIL PROTECTED]: Added file: http://bugs.python.org/file10301/enumerate.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2831 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1826] operator.attrgetter() should accept dotted attribute paths
Scott Dial added the comment: Mea culpa, the original patch I attached here has an obvious duplication of code in test_operator.py. I've attached an updated patch to make life easier on the commiter. Added file: http://bugs.python.org/file9175/getattrchaser.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1826 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1826] operator.attrgetter() should accept dotted attribute paths
Scott Dial added the comment: I want to clarify that the proposed change would break: operator.attrgetter(foo)(bar) == getattr(bar, foo) Which is the documented intent of the operator module: This module exports a set of functions implemented in C corresponding to the intrinsic operators of Python. Unless, you are proposing getattr grow this functionality as well. IOW, should PyObject_GetAttr* perform this recursion? If so, should PyObject_HasAttr*, PyObject_DelAttr*, PyObject_SetAttr* do this as well? At the moment, it is possible to have foo's (as in above) that contain dots despite the inability to spell that in python's dereferencing syntax. However, I don't know that anybody does that. -- nosy: +scottdial __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1826 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1826] operator.attrgetter() should accept dotted attribute paths
Scott Dial added the comment: The attached patch provides for the functionality requested. I've updated the docstring of attrgetter related to this new feature and have updated test_operator accordingly. Added file: http://bugs.python.org/file9169/getattrchaser.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1826 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Instances of BaseException and family don't provide __module__?
I have started working on a new project using ZSI and perhaps one can
argue this is a bug in ZSI, but I found it odd. The ZSI dispatcher
needs to catch all exceptions and pass that over to the client; in
doing so, it passes along the name of the exception that occurred so
that the client can know more than just it failed. Anyways, I am
getting off the point, the mechanics of this code in ZSI goes more or
less like this:
try:
doSomething()
except Exception, ex:
sendFault(':'.join([ex.__module__, ex.__class__.__name__]))
This works just fine for user-defined exceptions like:
class UserException(Exception):
pass
uex = UserException()
print ':'.join([uex.__module__, uex.__class__.__name__]) #
__main__.UserException
But falls on its face with built-in exceptions:
ex = Exception()
print ':'.join([ex.__module__, ex.__class__.__name__]) # AttributeError!
, because the built-in exception instances don't have the __module__
attribute (as of 2.5). The only way this works in 2.4 as well as 2.5
is to do:
print ':'.join([ex.__class__.__module__, ex.__class__.__name__]) #
exceptions:Exception
print ':'.join([uex.__class__.__module__, uex.__class__.__name__]) #
__main__:NewException
But this is a bit obscure and I don't understand why user-defined
exception instances should have a different set of attributes than the
built-in exception instances. As well as this is a change from 2.4-
2.5 that breaks existing code for no apparent reason. This smells
like it was an overlooked mistake and not a feature. I am tempted to
open a bug against python for it, but I didn't know if someone could
give a rational reason why that attribute is missing?
Thanks,
-Scott
--
http://mail.python.org/mailman/listinfo/python-list
