[issue13828] Further improve casefold documentation
Thorsten added the comment: German example in casefolding is plain incorrect. #Casefolding is similar to lowercasing but more aggressive because it is #intended to remove all case distinctions in a string. For example, the #German lowercase letter 'ß' is equivalent to "ss". Since it is already #lowercase, lower() would do nothing to 'ß'; casefold() converts it to #"ss". It is not true that "ß" is equivalent to "ss" and has not been since an orthography reform in 1996. These are to be used in distinct use cases. "ß" after a diphthong or a long/open vowel. "ss" after a short/closed vowel. The documentation correctly describes (in this case) how Python handles the .casefold() for this letter, although the behavior itself is incorrect. As mentioned before, in 2017 an official upper-case version of "ß" has been introduced into German orthography: "ẞ". The German example should be stated as current incorrect behavior in the documentation. +1 to adding previously mentioned sentence: In addition to lowercasing, this function also expands ligatures, for example, "fi" becomes "fi". -- nosy: +MrSupertash ___ Python tracker <https://bugs.python.org/issue13828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13828] Further improve casefold documentation
Thorsten added the comment: I see. I found the documents. That's an issue. That usage is incorrect. It is still valid to upper case "ß" to SS since "ẞ" is fairly new as an official German character, but the other way around is not valid. As such the current sentence in documentation also just does not make sense. >"Since it is already lowercase, lower() would do nothing to 'ß'" Exactly. Why would it? It is nonsensical to change an already lowercase character with a lowercase function. Suggest to update to: "For example, the Unicode standard for German lower case letter 'ß' prescribes full casefolding to 'ss'. Since it is already lowercase, lower() would do nothing to 'ß'; casefold() converts it to 'ss'. In addition to full lowercasing, this function also expands ligatures, for example, 'fi' becomes 'fi'." -- ___ Python tracker <https://bugs.python.org/issue13828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13471] setting access time beyond Jan. 2038 on remote share failes on Win7 x64
New submission from Thorsten Simons :
Using Python '3.2.2 (default, Sep 4 2011, 09:07:29) [MSC v.1500 64 bit
(AMD64)]' on Windows 7 Professional SP1:
If you set an access time for a file beyond Jan. 2038 on a file stored in a
local NTFS filesystem, all's well:
>>> os.utime('c:\\temp_target\\ulp', (3433232323, 3433232323))
>>> os.stat('c:\\temp_target\\ulp')
nt.stat_result(st_mode=33206, st_ino=2251799813820060, st_dev=0, st_nlink=1,
st_uid=0, st_gid=0, st_size=0, st_atime=3433232323, st_mtime=3433232323,
st_ctime=1322133855)
>>> time.ctime(3433232323)
'Mon Oct 17 13:38:43 2078'
If you try to do this on a remote share (mounted as y:), provided by a Linux
x64 box running Samba x64, things are different:
>>> os.utime('y:\\temp_target2\\ulp', (3433232323, 3433232323))
>>> os.stat('y:\\temp_target2\\ulp')
nt.stat_result(st_mode=33206, st_ino=67150103, st_dev=0, st_nlink=1, st_uid=0,
st_gid=0, st_size=0, st_atime=910692730085, st_mtime=910692730085,
st_ctime=1322133629)
>>> time.ctime(910692730085)
Traceback (most recent call last):
File "", line 1, in
time.ctime(910692730085)
ValueError: unconvertible time
So, setting of access/modification time does not work - assumeably, we run into
a 32-bit boundary somewhere...
Interestingly, if you set the respective access time from a Linux x64 box, you
can see the right access time within Windows 7 via Explorer/Properties...
--
components: Windows
messages: 148248
nosy: Thorsten.Simons
priority: normal
severity: normal
status: open
title: setting access time beyond Jan. 2038 on remote share failes on Win7 x64
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue13471>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13471] setting access time beyond Jan. 2038 on remote share failes on Win7 x64
Thorsten Simons added the comment: Gentlemen, thank you for your contribution - the information about the Samba fix solved the problem! -- resolution: -> works for me status: open -> closed ___ Python tracker <http://bugs.python.org/issue13471> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12193] Argparse does not work together with gettext and non-ASCII help text
New submission from Thorsten Kampe : Error with argparse and UTF-8 non-ASCII help text on Linux (works on Windows and on Linux with optparse): % LANG=de_De ./script.py --help Traceback (most recent call last): File "./script.py", line 26, in args = cmdlineparser.parse_args() File "/usr/lib/python2.7/argparse.py", line 1678, in parse_args args, argv = self.parse_known_args(args, namespace) File "/usr/lib/python2.7/argparse.py", line 1710, in parse_known_args namespace, args = self._parse_known_args(args, namespace) File "/usr/lib/python2.7/argparse.py", line 1916, in _parse_known_args start_index = consume_optional(start_index) File "/usr/lib/python2.7/argparse.py", line 1856, in consume_optional take_action(action, args, option_string) File "/usr/lib/python2.7/argparse.py", line 1784, in take_action action(self, namespace, argument_values, option_string) File "/usr/lib/python2.7/argparse.py", line 993, in __call__ parser.print_help() File "/usr/lib/python2.7/argparse.py", line 2303, in print_help self._print_message(self.format_help(), file) File "/usr/lib/python2.7/argparse.py", line 2317, in _print_message file.write(message) UnicodeEncodeError: 'ascii' codec can't encode character u'\xdc' in position 91: ordinal not in range(128) -- components: Unicode files: script.py messages: 137013 nosy: thorsten priority: normal severity: normal status: open title: Argparse does not work together with gettext and non-ASCII help text versions: Python 2.7 Added file: http://bugs.python.org/file22138/script.py ___ Python tracker <http://bugs.python.org/issue12193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12193] Argparse does not work together with gettext and non-ASCII help text
Changes by Thorsten Kampe : -- type: -> crash ___ Python tracker <http://bugs.python.org/issue12193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12193] Argparse does not work together with gettext and non-ASCII help text
Changes by Thorsten Kampe : Added file: http://bugs.python.org/file22139/script.de.po ___ Python tracker <http://bugs.python.org/issue12193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12193] Argparse does not work together with gettext and non-ASCII help text
Changes by Thorsten Kampe : Added file: http://bugs.python.org/file22140/script.mo ___ Python tracker <http://bugs.python.org/issue12193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12193] Argparse does not work together with gettext and non-ASCII help text
Thorsten Kampe added the comment: "LANG=de_De" - should've been "LANG=de_DE". Sorry for wasting someone's time. I shouldn't write bug reports in the middle of the night. Sorry and thanks, Thorsten -- resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue12193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7511] msvc9compiler.py: ValueError: [u'path']
Thorsten Behrens added the comment: I can test this for 3.1, as all I have is the Express version of VC++. If you could point me towards a library that will work with 3.1 and has C components, that'll make the testing a lot easier. pycrypto and setuptools, the two libs mentioned in this issue, do not support Python 3.x. -- nosy: +sbehr...@gmx.li ___ Python tracker <http://bugs.python.org/issue7511> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7511] msvc9compiler.py: ValueError: [u'path']
Thorsten Behrens added the comment: You are right, this is not a bug in Python. The diff provides a workaround for a limitation in VC++ 2008 Express. This diff is a piece of user service. An equally as workable workaround is for the user to copy VC\bin\vcvars64.bat into VC\bin\amd64\vcvarsamd64.bat. Once that is done, distutils works without the workaround provided in this diff. Whether to provide a workaround within Python for an issue in VC++ 2008 Express can certainly be debated. I for one suggest to err on the side of being friendly, rather than insisting on purity. Consider that users of Python do include hobbyists and students. For them, VC++ Pro may be out of reach. And there are plenty of reasons for building 64-bit binaries, among them learning exercises. -- ___ Python tracker <http://bugs.python.org/issue7511> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9709] test_distutils warning: initfunc exported twice on Windows
Thorsten Behrens added the comment: Thank you for that patch, Stefan. I am currently tinkering with bringing pycrypto to 3.x and ran into this issue. initfunc2.patch resolves the issue on Win7-64, python31-64. I don't feel comfortable releasing code that requires the user to manually patch Python to build. What are my options here? Go back to void instead of PyMODINIT_FUNC? Is there aught else I can do to make sure pycrypto will build well "in the wild"? -- nosy: +thorsten.behrens ___ Python tracker <http://bugs.python.org/issue9709> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10773] "Building C and C++ Extensions on Windows" documentation shows 2.x way of initializing module
New submission from Thorsten Behrens : The documentation titled "Building C and C++ Extensions on Windows" at http://docs.python.org/py3k/extending/windows.html shows a Python 2.x way of handling static type object initializers, to whit: >> If your module creates a new type, you may have trouble with this line: PyVarObject_HEAD_INIT(&PyType_Type, 0) Static type object initializers in extension modules may cause compiles to fail with an error message like “initializer not a constant”. This shows up when building DLL under MSVC. Change it to: PyVarObject_HEAD_INIT(NULL, 0) and add the following to the module initialization function: MyObject_Type.ob_type = &PyType_Type; >> That last line will not function in Python 3.x. However, PyType_Ready will fill in the ob_type field if it is empty, if I understand PyType_Ready correctly. Therefore, the last few lines of this documentation snippet can become: >> and add the following to the module initialization function: if (PyType_Ready(&MyObject_Type) < 0) return NULL; >> -- assignee: d...@python components: Documentation messages: 124667 nosy: d...@python, thorsten.behrens priority: normal severity: normal status: open title: "Building C and C++ Extensions on Windows" documentation shows 2.x way of initializing module versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue10773> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7511] msvc9compiler.py: ValueError: [u'path']
Thorsten Behrens added the comment: Confirmed that this issue exists on Python 3.1 and 3.2b2. The exception thrown presents as: ValueError: ['path', 'include', 'lib'] -- ___ Python tracker <http://bugs.python.org/issue7511> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10793] hashlib.hash.digest() documentation incorrect re return type
New submission from Thorsten Behrens : The documentation for hashlib.hash.digest() states that digest() will "[r]eturn the digest of the data passed to the update() method so far. This is a bytes array of size digest_size[...]". The returned object is of class 'bytes', not 'bytearray'. Documentation should reflect this. -- assignee: d...@python components: Documentation messages: 124892 nosy: d...@python, thorsten.behrens priority: normal severity: normal status: open title: hashlib.hash.digest() documentation incorrect re return type versions: Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue10793> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10932] distutils.core.setup - data_files missbehaviour ?
New submission from Thorsten Simons : Hi ! when specifying additional files to be distributed by distutils.core.setup, documentation says that: "Each file name in files is interpreted relative to the setup.py script at the top of the package source distribution. No directory information from files is used to determine the final location of the installed file; only the name of the file is used" (http://docs.python.org/py3k/distutils/setupscript.html#distutils-additional-files) Well, this seems to be incorrect - I tried to specify a file from a higher level directory, which get's copies to a target based on the whole path I specified, not just the name... Pls. see attached file for details -- assignee: tarek components: Distutils files: issue.txt messages: 126459 nosy: Thorsten.Simons, eric.araujo, tarek priority: normal severity: normal status: open title: distutils.core.setup - data_files missbehaviour ? type: behavior versions: Python 3.1 Added file: http://bugs.python.org/file20435/issue.txt ___ Python tracker <http://bugs.python.org/issue10932> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10932] distutils.core.setup - data_files misbehaviour ?
Thorsten Simons added the comment: Hi Éric, All, thank you for the directions you gave me! It's all about a call of os.path.basename() missing in sdist.py. Pls. see attached diff. Regards, Thorsten -- keywords: +patch Added file: http://bugs.python.org/file20546/fix-sdist.py.diff ___ Python tracker <http://bugs.python.org/issue10932> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20136] Logging: StreamHandler does not use OS line separator.
Thorsten Weimann added the comment: Please re-open. The IO system only takes care of line separators, if no encoding is given. -- nosy: +Thorsten.W ___ Python tracker <http://bugs.python.org/issue20136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16606] hashlib memory leak
New submission from Thorsten Simons:
hashlib seems to leak memory when used on a Linux box (whereas the same works
fine when run under Windows 7) (tested w/ Python 3.2.1 and 3.2.3)
import hashlib
#file = 'B:\\video\\TEST\\01_file_10G'
file = '/video/TEST/01_file_10G'
myhash = hashlib.sha256()
with open(file, "rb") as f:
for buffer in f:
myhash.update(buffer)
print('hash =', myhash.hexdigest())
On Windows, 'python3 mem.py' occupies roundabout 7 MB memory,
on Linux (OpenSuse 12.2), it quickly acquires all available memory, then all
swap, than get's killed.
--
components: Library (Lib)
messages: 176907
nosy: Thorsten.Simons
priority: normal
severity: normal
status: open
title: hashlib memory leak
type: resource usage
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue16606>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16606] hashlib memory leak
Thorsten Simons added the comment: forgot to say that this is about huge files (tested w/ a 10GB file) -- ___ Python tracker <http://bugs.python.org/issue16606> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16606] hashlib memory leak
Thorsten Simons added the comment: Antoine, this was of great help - no memory leaking anymore... So, I asume that somewhere in the iteration the read file is buffered? Does that make sense or - was it the developers intention? Thank you, Regards, Thorsten -- resolution: -> works for me ___ Python tracker <http://bugs.python.org/issue16606> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16606] hashlib memory leak
Thorsten Simons added the comment: OK, learned something again - should have known this :-( Thank you! Thorsten -- ___ Python tracker <http://bugs.python.org/issue16606> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16786] argparse doesn't offer localization interface for "version" action
New submission from Thorsten Kampe: The - deprecated - "version" keyword for argparse.ArgumentParser allowed for localization of the "show program's version number and exit" help text for -v/--version (output of "-h"/"--help") The new version action for add_argument does not allow this - resulting in a partially translated output for the -v/--version option. -- components: Library (Lib) messages: 178209 nosy: thorsten priority: normal severity: normal status: open title: argparse doesn't offer localization interface for "version" action type: behavior versions: Python 2.7, Python 3.3 ___ Python tracker <http://bugs.python.org/issue16786> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
