New submission from Martin von Gagern:
https://docs.python.org/3/library/zipfile.html#zipfile.ZipFile.write writes:
“Note: There is no official file name encoding for ZIP files. If you have
unicode file names, you must convert them to byte strings in your desired
encoding before passing them
Martin von Gagern martin.vgag...@gmx.net added the comment:
I'm attaching a patch to better explain what I'm suggesting. As you can see,
this patch doesn't change the signature of discover, nor does it change the
semantics for any code that doesn't pass pattern, or that passes some pattern
Martin von Gagern martin.vgag...@gmx.net added the comment:
Michael wrote: […] the real pattern being passed in.
I wonder, what would be the real pattern? In the code I originally pasted,
the load_tests function would be invoked by loadTestsFromModule (for module
__main__). There is nothing
Martin von Gagern martin.vgag...@gmx.net added the comment:
Rik, I don't follow your argument on not changing discover. Currently, if code
calls discover with pattern=None, there will be an exception. So there cannot
be any working code out there which passes pattern=None. Therefore, it should
Martin von Gagern martin.vgag...@gmx.net added the comment:
As people keep stating how easy the change from sys.platform == 'linux2' to
sys.platform.startswith('linux') is, e.g. msg142385, please also keep in mind
cases like someDict.get(sys.platform) where the comparison is implicit
Martin von Gagern martin.vgag...@gmx.net added the comment:
Marc-Andre Lemburg wrote:
Both Python and the application will make certain assumptions about
the platform depending on the compile time environment.
Can you give examples for this?
So you need both the compile and the runtime
New submission from Martin von Gagern martin.vgag...@gmx.net:
The attached C extension provides a way to manually set an element in the dict
of an extension type. As the test case exposes, this can result in a
discrepancy between cls.__dict__['key'] and cls.key.
Please tell me up front if my
Changes by Martin von Gagern martin.vgag...@gmx.net:
--
nosy: +gagern
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12326
___
___
Python-bugs-list
New submission from Martin von Gagern martin.vgag...@gmx.net:
suprocess.Popen on POSIX (using _posixsubprocess Module) has a good chance of
repeatedly closing the same file descriptor if the descriptor for stdin is also
used for stdout and/or stderr. Only stdout and stderr are checked
Martin von Gagern martin.vgag...@gmx.net added the comment:
Sorry, this is a duplicate of issue #11432. Failed to find that, and also
failed to realize that python is now using hg and my svn checkout might be
outdated. Sorry there.
--
resolution: - duplicate
status: open - closed
New submission from Martin von Gagern martin.vgag...@gmx.net:
I'd like to be able to run pydoc -b in whatever directory I'm currently in.
Most of the time that would be the root of my home directory, which is an
ext4fs mount. So it has a subdirectory called lost+found for which I don't
have
Martin von Gagern martin.vgag...@gmx.net added the comment:
The server continues all right. It's the browser window which displays the
error message. Not much better in my opinion, though.
To be completely accurate: currently the -b option doens't work as it should
due to issue #11432
Changes by Martin von Gagern martin.vgag...@gmx.net:
--
nosy: +gagern
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4934
___
___
Python-bugs-list
New submission from Martin von Gagern martin.vgag...@gmx.net:
If I follow the documentation at
http://docs.python.org/library/unittest.html#unittest.main by putting the
following two snippets of code in my module file:
def load_tests(loader, standard_tests, pattern='test*.py'):
# top
Martin von Gagern martin.vgag...@gmx.net added the comment:
I've added a unit test for this nested mutex scenario. The attached patch
includes the original fix as well, as for some reason the patch by loewis
wouldn't apply to my tree automatically.
--
nosy: +gagern
Added file: http
Martin von Gagern martin.vgag...@gmx.net added the comment:
Maybe I'm missing something here, but r84229 looks to me like aliasing
'macintosh' to itself, instead of to 'mac_roman'. 'csmacintosh' and 'mac' are
not included at all, without any comment as to why they have been omitted.
Makes me
Martin von Gagern martin.vgag...@gmx.net added the comment:
Wrong issue number again, or did you deliberately try to catch me in an
infinite see-also loop? ;-)
I've tried to work out what issue you meant, but failed so far.
--
___
Python tracker rep
Martin von Gagern martin.vgag...@gmx.net added the comment:
Here is the corresponding path for python3 (py3k branch). It's mostly the same,
except for one additional test which ensures header preservation even if the
maxheaderlen argument to Message.as_string is greater than 0. It's called
Martin von Gagern martin.vgag...@gmx.net added the comment:
You missed a digit in the test comment:
s/See issue 96843/See issue 968430/
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1670765
Martin von Gagern martin.vgag...@gmx.net added the comment:
Let's get some traction here, please!
Attached is a test case which will demonstrate the issue. It includes the
content of test5.eml as a string so that it won't require additional files. It
produces both human-readable output
Martin von Gagern martin.vgag...@gmx.net added the comment:
OK, here is a patch providing both two test cases and the fix for current
trunk. Will probably hack something for python 3 as well, although there the
Message.as_string approach works due to the new headerlength argument
defaulting
Martin von Gagern martin.vgag...@gmx.net added the comment:
Find attached (issue843590_rfc.patch) an implementation of the macintosh
encoding as the RFC defines it. I don't suggest its inclusion; I would prefer
the alias of this implementation, but either one is better than no 'macintosh
Martin von Gagern martin.vgag...@gmx.net added the comment:
And this patch (issue84359_alias.patch) is the alternative, 'macintosh' as an
alias to 'mac_roman' as originally requested, along with a bunch of aliases
registered with IANA. I'd prefer this approach over the preceding one, and hope
Changes by Martin von Gagern martin.vgag...@gmx.net:
--
nosy: +gagern
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1974
___
___
Python-bugs-list
Martin von Gagern martin.vgag...@gmx.net added the comment:
I did some further investigations here. Apple doesn't seem likely to
offer any authoritative reference for the macintosh encoding, because
all they ever seem to talk about is Roman. The only source for
macintosh I could find is this RFC
Martin von Gagern martin.vgag...@gmx.net added the comment:
Any progress with the review?
By the way, what branch are we aiming for? I'm using 2.5 here, so I
reported this issue against that version, and wrote the patch against
that branch. I guess it should work for trunk as well
Martin von Gagern martin.vgag...@gmx.net added the comment:
I had my first indication to rather use macintosh instead of
mac_roman from Wikipedia http://en.wikipedia.org/wiki/Mac_OS_Roman
which states that the charset part of a MIME content-type specification
should be maciontosh. I'm
Martin von Gagern martin.vgag...@gmx.net added the comment:
Not being a regular Python programmer myself, I've never even heard of a
context manager before, but this latest patch should fit the bill.
As for tests, I believe that a few two-second sleeps (as FAT has only
two second resolution
Martin von Gagern martin.vgag...@gmx.net added the comment:
Like this? Should the magic number be checked as well, and if so,
against what value? I couldn't find that constant in any structure
accessible from python, and jumping through hoops seems too much, as
updating the python version should
Martin von Gagern martin.vgag...@gmx.net added the comment:
Next iteration. With magic number, and now also closing the file again.
I changed from unpack and number comparison to pack and string
comparison, makes things a bit easier, as there is only one comparison,
and as underflow
New submission from Martin von Gagern martin.vgag...@gmx.net:
When trying to decide whether or not a given file needs to be
recompiled, the inode creation time should be taken into account along
with the file modification time.
Scenario: Suppose you have three times, A B C D. At time A, you
Changes by Martin von Gagern martin.vgag...@gmx.net:
--
keywords: +patch
Added file: http://bugs.python.org/file12917/compileall-ctime.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5128
Martin von Gagern added the comment:
Looks like I missed your comments on this patch.
What kind of tests do you have in mind?
Tests demonstrating where current implementation fails and my patch will
help? Or rather tests checking that this patch won't break anything
else? The former would
Martin von Gagern added the comment:
Take the attached test5.eml. Run it through the following python script:
import email
print (email.message_from_file(open(test5.eml)).as_string(False))
The result will have both instances of the X-Long-Line header rewrapped.
As the second instance
34 matches
Mail list logo
