[issue16487] Allow ssl certificates to be specified from memory rather than files.
Brandon Craig Rhodes added the comment: Kristján, you are certainly correct that a single-argument that can be either a filename or a cert is inappropriate; we should not be peeking inside of strings to guess what they contain. And I think you also have a good point about Pythonic-ness when it comes to polymorphism; routines that are sensitive to object type have been going more and more out of style for the past twenty years, and for good reason. But, having ceded those points, I still think string-or-file-like-object is the correct approach here, simply because it is the overwhelming approach of the Standard Library; everyone is used to it, and will already know the ropes of that approach; and it prevents noisying up the interface with redundant arguments. Were we doing this over again, we would simply not allow a filename at all, and let the user open the file if they needed to. But since a filename is allowed, it feels like the Official Standard Library Approach to also allow a file-like object. Some examples: zipfile.ZipFile: Open a ZIP file, where file can be either a path to a file (a string) or a file-like object. http://docs.python.org/2/library/zipfile#zipfile.ZipFile binhex.hexbin: Decode a binhex file input. input may be a filename or a file-like object supporting read() and close() methods. http://docs.python.org/release/2.7.5/library/binhex.html#binhex.hexbin xml.dom.minidom.parse: filename_or_file may be either a file name, or a file-like object. http://docs.python.org/2/library/xml.dom.minidom.html#xml.dom.minidom.parse mailbox.Mailbox.add: Parameter message may be a Message instance, an email.message.Message instance, a string, or a file-like object (which should be open in text mode). http://docs.python.org/2/library/mailbox.html#mailbox.Mailbox.add pickletools.dis: pickle can be a string or a file-like object. http://docs.python.org/2/library/pickletools.html#pickletools.dis I suggest that these precedents, along with others that I believe we could find with a more exhaustive search of the Standard Library, are sufficient to suggest that in this case the least-surprise approach is a single argument that's either a filename or file-like object. I would suggest reviewing quickly the code for the above examples and following their example for how to distinguish most cleanly between a filename and file-like object; I wonder if they call any common code to get the contents out, or each do it completely by themselves? :) Thanks again for wanting to add this to the SSL module, it will be a *great* addition that solves an important use case! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16487 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Brandon Craig Rhodes added the comment: Kristján, your patch is a wonderful idea—I am about to commit production code that will have to create tens of thousands of temporary files during operation, one file each time SSL is started up on a socket, which could be avoided if something like this patch were applied. I had always assumed that it was simply a limitation of the underlying SSL library! An interface that takes a filename like this, instead of a live file-like object, seems so un-Pythonic that I assumed the only reason for it was a limitation in OpenSSL. Thank you very much for looking under the covers and discovering that this was not the case! I do, though, feel a slight twinge when we add Even More Parameters to a Standard Library routine but in such a way that it cannot be used with an existing parameter — as here in your patch, where we gain a parameter like `certdata` that cannot be (should not be?) used at the same time as `certfile`. It seems redundant to have two names for the same parameter to the underlying library, and makes it look like the routine needs more information than it really does. Since my own instinct was to think, ten minutes ago, Maybe I can pass a StringIO, since it says it wants a fine!, I am very much in support of the idea of keeping only the existing parameters, but making them accept both strings (which, for compatibility, would continue to be interpreted as filenames) and file-like objects as arguments. I think this would have a great deal of symmetry with how other parts of the Standard Library work, while keeping this patch's central value of making it possible for those of us with cert-heavy code to avoid the creation of thousands of files a minute. Again, thank you VERY much for discovering that OpenSSL can do this, and I will try to provide whatever encouragement I can as you try to shepherd this past the other committers. -- nosy: +brandon-rhodes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16487 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17855] Implement introspection of logger hierarchy
Brandon Craig Rhodes added the comment: Adding an entirely separate API for introspection strikes me as counter-productive — instead of merely having to maintain the logging API that you already maintain, you will additionally now have an entirely separate and second API that also has to be maintained forever. Reading back over the current logging documentation, it looks like the problem is that the documentation only includes verbs — the methods that can be invoked — but not adjectives: the attributes that are attached to each logger, handler, and filter. This is contrary to modern Python APIs, which typically document their attributes and offer direct access to them; within the Standard Library, cf the threading.Thread object for one that has done a good job of moving into the modern world with directly-accessible attributes. So my guess would be that you should discard the idea of a separate introspection API, and simply document that attributes of each logger, handler, and filter that today are already perfectly introspectable. Check out the logging_tree code if you want to make sure that you are “promoting” into document-hood all of the attributes that I needed in order to do my introspecting there. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17855 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13477] tarfile module should have a command line
Brandon Craig Rhodes added the comment: Larry Hastings rep...@bugs.python.org writes: Huh. tar *can* infer it from the data itself. On the other hand, it chooses explicitly not to. I guess tar knows explicit is better than implicit too ;-) I am told that the refusal of tar to introspect the data is because: (a) Tar runs gunzip -c (for example) as an external program; it does not actually compile against libz. (b) Streams in UNIX cannot be rewound. Tar cannot look at the first block of an input pipe and then put the block back so that the same input can be fed directly to gunzip as its input. (c) Given (a) and (b), tar could only support data introspection of input from a pipe if it were willing to be a pass-through that, after reading and introspecting the first block, then fired up gunzip and sent ALL of the blocks through. Which would require multiprocessing, threading, or async I/O so that tar could both read and write, which would make tar more complicated. (d) Therefore, tar refuses to even look. Since Python does bundle compression in its standard library, it can quite trivially step forward and actually do the data introspection that tar insists on not doing; the first few bytes of a tar archive are quite demonstrably different from the first bytes of a gzip stream, if I recall. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13477 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17370] PEP should not if it has been superseded
New submission from Brandon Craig Rhodes: A friend (@theomn on Twitter) was just working off of PEP-333 when I mentioned to him that PEP-, and he had never heard of it, and he expressed the wish that PEPs would have a banner or something at the top if there is a more recent version of them. I think his idea is great, and is like the feature of PyPI where if Google lands you on an old version of a package then it is careful to tell you up at the top that a more recent version is available. This could extend to all sorts of cross-references that we should maintain: some PEPs have been superseded; others have more recent supplements that people should read as well (think of the relationship between packaging PEPs); PEPs that did not wind up being implemented have cousins who were; and so forth. Is this something that needs to wait until the New Python Web Site appears, and that would be meta-markup somehow maintained along with the PEP texts themselves? Or should there be a “Related PEPs” paragraph that we open at the top of each relevant PEP and just include the cross-links as raw updates to the PEP's own restructured text? I'm open to a simple implementation here, so long as we can provide more “community context” when people land on a PEP. -- assignee: docs@python components: Documentation messages: 183625 nosy: brandon-rhodes, docs@python priority: normal severity: normal status: open title: PEP should not if it has been superseded ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17370] PEP should note if it has been superseded
Brandon Craig Rhodes added the comment: (Corrected not to note in the title and went with enhancement) -- title: PEP should not if it has been superseded - PEP should note if it has been superseded type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17370] PEP should note if it has been superseded
Brandon Craig Rhodes added the comment: The original inspiration: https://twitter.com/theomn/status/309468740611891200 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13477] tarfile module should have a command line
New submission from Brandon Craig Rhodes bran...@rhodesmill.org: The tarfile module should have a simple command line that allows it to be executed with -m — even if its only ability was to take a filename and extract it to the current directory, it could be a lifesaver on Windows machines where Python has been installed but nothing else. Would such a patch be welcome if I could write one up? -- messages: 148300 nosy: brandon-rhodes priority: normal severity: normal status: open title: tarfile module should have a command line ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13477 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1947] Exception exceptions.AttributeError '_shutdown' in module 'threading'
Brandon Craig Rhodes bran...@rhodesmill.org added the comment: In case Google brings anyone else to this bug: this error typically indicates that a `threading.py` which is not actually the Standard Library's `threading` module has somehow wound up on an earlier path in `sys.path` and is therefore shadowing the Standard Library module. This upsets the Python exit logic, which tries to run `threading._shutdown()` if `threading` exists in `sys.modules`. I just helped someone on Stack Overflow with a situation like this, which in that case resulted from an error in how `pylint` works. -- nosy: +brandon-rhodes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11561] coverage of Python regrtest cannot see initial import of libs
Brandon Craig Rhodes bran...@rhodesmill.org added the comment: Brett, yes, you are welcome to close this issue — Ned quite handily convinced me that coverage code belongs in the coverage distribution, not languishing about in the CPython source tree. That solution also quite beautifully solves the copyright problem. So I happily withdraw my request for this feature. Nick, Brett is working on exactly the sort of devguide improvement that you suggest — not least because the devguide will now need to instruct people in how to build coverage so that its C-accelerated tracer is available, which Ned's own patch to coverage to cover stdlib tracing uses instead of the Python tracer that I cut-and-pasted into this patch. Finally, it would be wonderful to have a more formal mechanism for boot-time interventions. I have mentioned before my wish that Python's first action be to open() the executable, check its tail to see if it's a valid zipfile, and if so to try loading and running startup.py from that zipfile. Among other things, that would allow single-file distribution of pure-Python applications without the py2exe/py2app mess that prevails in the projects I work with today. But since the whole issue of grabbing control at boot time raises hackles (why would you want to do that!?), and I needed something working immediately during the PyCon sprint, I elected to simply adopt encodings.py as my way in. It works great, and coverage can evolve to an even better mechanism as soon as one becomes available, should anyone want to take the bootup option and run with it. One final thought: should PyPy etc also implement the same boot protocol, should one be invented, so that all mainline interpreters can be instrumented the same way? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11572] bring Lib/copy.py to 100% coverage
Brandon Craig Rhodes bran...@rhodesmill.org added the comment: Ezio and Sandro, thank you very much for your attention to this issue, and for helping me split it into manageable chunks! To answer the question about why coverage does not show as high a total as it ought: it's because coverage normally can't see the outer, global scope execution of modules that are already imported by the time coverage itself can take control and install a tracer. I have another patch outstanding that fixes this — we are still working on it, but the code works fine — if you want to run coverage and see a more accurate number: http://bugs.python.org/issue11561 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11572 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11572] bring Lib/copy.py to 100% coverage
Brandon Craig Rhodes bran...@rhodesmill.org added the comment: Éric, I think your points are good ones. (And, as I return to this patch after three months, I should thank the PSF for sponsoring the CPython sprint here at PyOhio, and creating this opportunity for me to continue trying to land this patch!) I am attaching a fourth version of the patch. It incorporates your two suggestions, Éric. It also applies cleanly once against today's trunk; besides the usual line number changes as code has come and gone, I am happy to see that my change of an assertTrue for an assertIs in the test suite has already taken place thanks to another patch in the meantime. -- Added file: http://bugs.python.org/file22822/test_copy4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11572 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11561] coverage of Python regrtest cannot see initial import of libs
Brandon Craig Rhodes bran...@rhodesmill.org added the comment: Éric, I think your suggestions are all good ones, and I have incorporated them into the file. (But do note that the departures we are now making from Ned's own copy of the tracer code — removing the commented-out debugging statement, and the long comment, and the inheritance from object — might make it harder to bring in changes from his own copy if he should ever further improve it.) I have tried to write the comments to be more informative, while also addressing your own ideas; let me know if you like the result! Oh: and, I am continuing to use this new file in my own work on the Python core, and it has been working fine — so no problems with the actual code have developed over these first 3+ months of use. -- Added file: http://bugs.python.org/file22823/fullcoverage2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12056] … (HORIZONTAL ELLIPSIS) should be an alternative syntax for ... (FULL STOP FULL STOP FULL STOP)
Brandon Craig Rhodes bran...@rhodesmill.org added the comment: But if we allow for ellipsis, then would we not also have to start allowing characters like ≥ and ≤ in Python? And the problem with any of these (admittedly very attractive) substitutions is that they seem to abandon the principle of there being One Obvious Way of typing any given expression. Instead there would now be several alternate ways, with different styles in different codebases and, I think, something of a visual and symbolic mess resulting. I like each symbol to have exactly one possible representation. -- nosy: +brandon-rhodes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12056 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11572] bring Lib/copy.py to 100% coverage
Brandon Craig Rhodes bran...@rhodesmill.org added the comment: Nick Coghlan rep...@bugs.python.org writes: Regarding __reduce__, other readers will have the same question Éric did, so that point should definitely go in a comment after the __reduce_ex__ check. I just sat down to review this issue, and, looking at test_copy3.patch, isn't there already a comment next to each __reduce_ex__ check that reminds the reader that object.__reduce_ex__ will itself call __reduce__? Does the comment just need to be more elaborate or something? Finally, Éric wants me to replace this: self.assertTrue(issubclass(copy.Error, Exception)) with self.assertIsInstance(). But surely the question is not whether copy.Error is an *instance* of Exception? They are both instances of *type*, right? What I would need is something like assertIsSubclass or assertInheritsFrom, neither of which exists. So I think that test_copy3.patch already includes all of the valid improvements on the table; if I'm missing one, just point it out and I'll fix it! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11572 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11572] bring Lib/copy.py to 100% coverage
Brandon Craig Rhodes bran...@rhodesmill.org added the comment: Nick Coghlan rep...@bugs.python.org writes: Nick Coghlan ncogh...@gmail.com added the comment: Regarding __reduce__, other readers will have the same question Éric did, so that point should definitely go in a comment after the __reduce_ex__ check. I had initially wanted to make a comment, but feared the objection that a comment would eventually fall out of sync with the implementation of object.__reduce_ex__ over the years (just as copy.py currently has all sorts of cruft that is no longer applicable). But I think that you are right that a comment that's at least true today is better than no comment at all; so I will add one on Monday. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11572 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11572] bring Lib/copy.py to 100% coverage
Brandon Craig Rhodes bran...@rhodesmill.org added the comment: Éric, after checking line 112 of the two patches and then of the new file, I figured out that you meant line 112 of the old file — and, yes, that test can go away too since in python3 complex always exists and unicode never exists. A further improved patch (#3) is attached. -- Added file: http://bugs.python.org/file21276/test_copy3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11572 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11572] bring Lib/copy.py to 100% coverage
Brandon Craig Rhodes bran...@rhodesmill.org added the comment: Éric, the Makefile in Python trunk seems to include Objects/complexobject.o in the build unilaterally without any way to turn it off. What is leading you to believe that Python 3 can conditionally turn the complex type off during a build? I do not understand your question about Unicode — could you reference the line number in the patch file that is worrying you? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11572 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11572] bring Lib/copy.py to 100% coverage
Brandon Craig Rhodes bran...@rhodesmill.org added the comment: Antoine, neither this issue, nor either version of my patch, was intended to assert that 100% test coverage indicates that a test of tests are complete. If you will point out where in the text this is implied, I will correct it. Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11572 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11572] bring Lib/copy.py to 100% coverage
New submission from Brandon Craig Rhodes bran...@rhodesmill.org: The attached patch will bring Lib/copy.py to 100% test coverage. A bug in coverage results in its only reporting 99% at the moment; see coverage issue #122 on bitbucket: https://bitbucket.org/ned/coveragepy/issue/122/for-else-always-reports-missing-branch This patch makes several minor improvements to copy: when doing getattr lookups with a default of None, it now uses an is comparison against None which is both faster and more correct; several special cases have been removed since Python 3 always has CodeType available; and an ancient obsolete test suite that had been appended to copy.py in ancient times has been removed. -- files: test_copy.patch keywords: patch messages: 131135 nosy: brandon-rhodes priority: normal severity: normal status: open title: bring Lib/copy.py to 100% coverage versions: Python 3.3 Added file: http://bugs.python.org/file21244/test_copy.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11572 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue502085] pickle problems (with Boost.Python)
Brandon Craig Rhodes bran...@rhodesmill.org added the comment: Benjamin, I would like some way to know when our tests achieve 100% coverage because otherwise I will keep coming back to this module to add more tests and have to re-discover code that is not CPython relevant. But for now I have removed the pragmas. The attached patch also changes assertIs() and assertIsNot(), and uses self.fail() instead of the exception inside of support. Thanks for those pointers! -- keywords: +patch nosy: +brandon-rhodes Added file: http://bugs.python.org/file21245/test_copy2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue502085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue502085] pickle problems (with Boost.Python)
Changes by Brandon Craig Rhodes bran...@rhodesmill.org: Removed file: http://bugs.python.org/file21245/test_copy2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue502085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11572] bring Lib/copy.py to 100% coverage
Brandon Craig Rhodes bran...@rhodesmill.org added the comment: Benjamin, thanks for the pointers! The attached patch now uses assertIs() and assertIsNot(), and calls self.fail() instead of using the exception from support. In the future I would like some way to determine when test coverage is fully achieved, so that I do not come back to this module every few months and have to re-discover why it is not 100%. But for the moment I have indeed removed the pragmas, pending a better approach! -- Added file: http://bugs.python.org/file21246/test_copy2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11572 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11561] coverage of Python regrtest cannot see initial import of libs
New submission from Brandon Craig Rhodes bran...@rhodesmill.org: When running the Python regression tests in coverage, the initial outer level of interpreted code in several standard library modules shows as not having been covered by the tests, because they were imported during the Python boot process and were already loaded when the coverage command got control. -- messages: 131051 nosy: brandon-rhodes priority: normal severity: normal status: open title: coverage of Python regrtest cannot see initial import of libs ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11561] coverage of Python regrtest cannot see initial import of libs
Brandon Craig Rhodes bran...@rhodesmill.org added the comment: Here is a module that solves this problem if the tests are run with the fullcoverage directory at the front of the PYTHONPATH, like this: PYTHONPATH=Tools/fullcoverage ./python -m coverage run --pylib Lib/test/regrtest.py test_copy -- keywords: +patch Added file: http://bugs.python.org/file21232/fullcoverage.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10979] setUpClass exception causes explosion with -b
New submission from Brandon Craig Rhodes bran...@rhodesmill.org: Normally, unittest cleanly reports an exception in a setUpClass method. But if I place the attached test in a directory by itself and then run python -m unittest discover -b from inside of the same directory, then instead of being shown the setUpClass exception I am instead shown a long traceback because unittest seems to think that it has put a stringIO in place of sys.stdout but a file is there instead. -- components: Library (Lib) files: test_example.py messages: 126816 nosy: brandon-rhodes priority: normal severity: normal status: open title: setUpClass exception causes explosion with -b type: crash versions: Python 2.7 Added file: http://bugs.python.org/file20484/test_example.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10979 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10901] Python 3 MIME generator dies if not given boundary
New submission from Brandon Craig Rhodes bran...@rhodesmill.org:
If you try doing msg.as_string() to a MIMEMultipart message that has not been
given a boundary, then it dies with this exception:
Traceback (most recent call last):
File mime_gen_alt.py, line 40, in module
print(msg.as_string())
File /home/brandon/python3.2b2/lib/python3.2/email/message.py, line 164, in
as_string
g.flatten(self, unixfrom=unixfrom)
File /home/brandon/python3.2b2/lib/python3.2/email/generator.py, line 88,
in flatten
self._write(msg)
File /home/brandon/python3.2b2/lib/python3.2/email/generator.py, line 134,
in _write
self._dispatch(msg)
File /home/brandon/python3.2b2/lib/python3.2/email/generator.py, line 160,
in _dispatch
meth(msg)
File /home/brandon/python3.2b2/lib/python3.2/email/generator.py, line 234,
in _handle_multipart
self.write('--' + boundary + self._NL)
TypeError: Can't convert 'NoneType' object to str implicitly
--
components: Library (Lib)
messages: 126187
nosy: brandon-rhodes
priority: normal
severity: normal
status: open
title: Python 3 MIME generator dies if not given boundary
type: crash
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10901
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10901] Python 3 MIME generator dies if not given boundary
Brandon Craig Rhodes bran...@rhodesmill.org added the comment: Here is a patch that fixes the problem. The problem probably only occurs if the MIMEMultipart is actually given several MIME parts to use in its interior. -- keywords: +patch Added file: http://bugs.python.org/file20391/email-boundary.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10901 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9723] pipes.quote() needs to be documented
New submission from Brandon Craig Rhodes bran...@rhodesmill.org: The only way to safely build shell command lines from inside of Python — which is necessary when sending commands across SSH, since that behaves like os.system() rather than like subprocess.call() — is to use the wonderful pipes.call() method to turn possibly-dangerous arguments, like filenames that might have spaces, special characters, and embedded rm -r calls, into perfectly quoted strings for an sh-like shell (say, bash or zsh). This call is already recommended on mailing lists, blog posts, and Stack Overflow — and since it doesn't start with a _, I think its public use is fair game. But the pipes documentation itself doesn't officially mention or support it. I think it should be added to the Standard Library documentation for pipes. So. Yeah. -- assignee: d...@python components: Documentation messages: 115263 nosy: brandon-rhodes, d...@python priority: normal severity: normal status: open title: pipes.quote() needs to be documented 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/issue9723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8713] multiprocessing needs option to eschew fork() under Linux
New submission from Brandon Craig Rhodes bran...@rhodesmill.org: The multiprocessing module uses a bare fork() to create child processes under Linux, so the children get a copy of the entire state of the parent process. But under Windows, child processes are freshly spun-up Python interpreters with none of the data structures or open connections of the parent process available. This means that code that tests fine under Linux, because it is depending on residual parent state in a way that the programmer has not noticed, can fail spectacularly under Windows. Therefore, the multiprocessing module should offer an option under Linux that ignores the advantage of being able to do a bare fork() and instead spins up a new interpreter instance just like Windows does. Some developers will just use this for testing under Linux, so their test results are valid for Windows too; and some developers might even use this in production, preferring to give up a bit of efficiency under Linux in return for an application that will show the same behavior on both platforms. Either way, an option that lets the developer subvert the simple sys.platform != 'win32' check in forking.py would go a long way towards helping us write platform-agnostic Python programs. -- components: Library (Lib) messages: 105719 nosy: brandon-rhodes priority: normal severity: normal status: open title: multiprocessing needs option to eschew fork() under Linux type: feature request versions: 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/issue8713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8713] multiprocessing needs option to eschew fork() under Linux
Brandon Craig Rhodes bran...@rhodesmill.org added the comment: Jesse, it's great to learn it's on your wish list too! Should I design the patch so that (a) there is some global in the module that needs tweaking to choose the child creation technique, or (b) that an argument to the Process() constructor forces a full interpreter exec to make all platforms match, or (c) that a process object once created has an attribute (like .daemon) that you set before starting it off? Or (d) should there be a subclass of Process that, if specifically used, has the fork/exec behavior instead of just doing the fork? My vote would probably be for (b), but you have a much better feel for the library and its style than I do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8517] Apple Style Guide link is broken in the Documenting Python chapter
New submission from Brandon Craig Rhodes bran...@rhodesmill.org: On this page, the Style Guide for people who want to try contributing to the Python documentation: docs.python.org/documenting/style.html there is a broken link to the Apple Style Guide. The 2008 edition now seems gone and people are now apparently supposed to visit: http://developer.apple.com/Mac/library/documentation/UserExperience/Conceptual/APStyleGuide/APSG_2009.pdf -- assignee: georg.brandl components: Documentation messages: 104077 nosy: brandon-rhodes, georg.brandl severity: normal status: open title: Apple Style Guide link is broken in the Documenting Python chapter versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
