[issue36371] FancyGetopt.generate_help crashes with TypeError
New submission from Maxim :
Hi!
FancyGetopt.generate_help crashes if help text in option_table is None:
instance = FancyGetopt([('long', 'l', None)])
help_text = instance.generate_help()
TypeError Traceback (most recent call last)
in
> 1 a.generate_help()
/usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/fancy_getopt.py
in generate_help(self, header)
352 (max_opt, opt_names, text[0]))
353 else:
--> 354 lines.append(" --%-*s" % opt_names)
355
356 for l in text[1:]:
TypeError: * wants int
This code is in master branch too.
And if help_text is empty string code behavior is like a help_text is actually
pass and added 2 whitespaces.
--
components: Library (Lib)
messages: 338401
nosy: crztssr
priority: normal
severity: normal
status: open
title: FancyGetopt.generate_help crashes with TypeError
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue36371>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36371] FancyGetopt.generate_help crashes with TypeError
Change by Maxim : -- keywords: +patch pull_requests: +12400 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36371> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13148] simple bug in mmap size check
New submission from Maxim Yanchenko :
The condition contradicts the exception text:
if (offset >= st.st_size) {
PyErr_SetString(PyExc_ValueError,
"mmap offset is greater than file size");
return NULL;
}
The condition should be changed to (offset > st.st_size), similar to the later
condition which is correct:
} else if (offset + (size_t)map_size > st.st_size) {
PyErr_SetString(PyExc_ValueError,
"mmap length is greater than file size");
return NULL;
}
The patch is attached.
--
components: Library (Lib)
files: mmap-greater.patch
keywords: patch
messages: 145319
nosy: jazzer
priority: normal
severity: normal
status: open
title: simple bug in mmap size check
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23372/mmap-greater.patch
___
Python tracker
<http://bugs.python.org/issue13148>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13148] simple bug in mmap size check
Maxim Yanchenko added the comment:
First of all, it doesn't fail (at least on Linux), I tested it before posting.
And the latest, it's not like I'm just stalking around and reading Python
sources for fun. It's a real and pretty valid case, I hit it while upgrading
our production code to python 2.7.
I'm using NumPy (linear algebra module) that uses Python's core mmap module
under the hood.
In NumPy, it's pretty valid to have arrays of size 0.
I have a file with a fixed-size header that holds size of the array and some
other meta-data. I mmap this file as a NumPy array using the offset equal to
header size. Of course, if there is no data in the array then the file will be
just header, and the offset will be equal to the size of the file - here is
where this bug hits us as I can't load this file with Python 2.7.2 anymore
(while I was able to with Python 2.5).
This patch fixes this and everything works as expected, giving an array with
zero dimensions ('shape' in terms of NumPy):
>>> x.shape
(0,)
>>> x.size
0
Please kindly consider applying the patch.
--
resolution: invalid ->
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue13148>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13148] simple bug in mmap size check
Maxim Yanchenko added the comment:
Well, "n+1" is clearly outside the file, wile "n" is within and therefore valid.
Also, if your position is to forbid zero-size mmapping completely, then the
checks inside "if (map_size == 0) {" don't make any sense, especially as they
may or may fail.
>From the existing code, zero-size mmapping is OK as long as offset is OK, so
>the question is whether we consider offset pointing to the end of the file OK.
>To me, it's fine and valid, and there are valid cases like NumPy's zero-size
>arrays, hence the proposed patch.
Removing the check completely is a viable option too, it was already requested
for special files:
http://bugs.python.org/issue12556
I believe users should have an ability to enjoy whatever their OS provides, and
"deal with the consequences" as you said.
--
___
Python tracker
<http://bugs.python.org/issue13148>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13148] simple bug in mmap size check
Maxim Yanchenko added the comment: tried on newer Linux - crashes with my patch. So I'll be thinking about a workaround, probably a fix for NumPy to avoid using mmap in such cases but still provide uniform interface to avoid making special conditional handling in all my scripts. Therefore, I'm no longer pushing for this change, I will need another workaround anyway. -- ___ Python tracker <http://bugs.python.org/issue13148> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13148] simple bug in mmap size check
Maxim Yanchenko added the comment: > You got lucky, since the offset must be a multiple of the page size. That's why our header is exactly the page size :) > Here's what POSIX says Then it's just another discrepancy between POSIX and Linux, as I received ENOMEM instead of EINVAL (RHEL6 on 2.6.32). Regarding the contradiction, it's probably still worth changing the exception message to "mmap offset is greater than _or equal to_ file size", to match the condition. Just 'greater than' means the '>' check, not the '>=' check from the code, mathematically. -- resolution: rejected -> ___ Python tracker <http://bugs.python.org/issue13148> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8639] Allow callable objects in inspect.getfullargspec
Maxim Bublis added the comment: I've ran into the same problem with getfullargspec not supporting callables, so I've written patch with docs and tests, that adds support for any Python callable. As a result of getfullargspec's implementation change, getargspec function also supports callables. -- keywords: +patch nosy: +maxbublis Added file: http://bugs.python.org/file22825/inspect.patch ___ Python tracker <http://bugs.python.org/issue8639> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8639] Allow callable objects in inspect.getfullargspec
Maxim Bublis added the comment: Agree, support for __new__ or __init__ methods would add some ambiquity, so i've decided to drop __init__ support from patch. Patch has been reuploaded. -- Added file: http://bugs.python.org/file22826/inspect2.patch ___ Python tracker <http://bugs.python.org/issue8639> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8639] Allow callable objects in inspect.getfullargspec
Changes by Maxim Bublis : Removed file: http://bugs.python.org/file22825/inspect.patch ___ Python tracker <http://bugs.python.org/issue8639> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12758] time.time() returns local time instead of UTC
New submission from Maxim Koltsov : Python docs (http://docs.python.org/library/time.html#time.time) say that time.time() function should return UTC timestamp, but actually i get local one: >>> time.mktime(time.gmtime()), time.time(), time.mktime(time.localtime()) (1313466499.0, 1313480899.384221, 1313480899.0) As you can see, the result of second statement is equal to result of the third, while it must be equal to result of the first. Checked on 2.7 and 3.1. My OS is Gentoo/Linux, timezone-info is the latest version (2011h). -- messages: 142167 nosy: maksbotan priority: normal severity: normal status: open title: time.time() returns local time instead of UTC versions: Python 2.7, Python 3.1 ___ Python tracker <http://bugs.python.org/issue12758> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12758] time.time() returns local time instead of UTC
Maxim Koltsov added the comment: Then docs must be fixed. By the way, help(time.time) correctly says about localtime. -- ___ Python tracker <http://bugs.python.org/issue12758> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12758] time.time() returns local time instead of UTC
Maxim Koltsov added the comment: Maybe add some words about local timezone? -- ___ Python tracker <http://bugs.python.org/issue12758> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12758] time.time() returns local time instead of UTC
Maxim Koltsov added the comment: Seems OK to me. -- ___ Python tracker <http://bugs.python.org/issue12758> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44380] glob.glob handling of * (asterisk) wildcard is broken
New submission from Maxim Egorushkin :
Problem:
`glob.glob` documentation states that "pathname ... can contain shell-style
wildcards."
However, it stops short of saying that shell-style wildcards are handled the
same way as in a POSIX-compliant/friendly shell.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_02
POSIX requires that "`*` (asterisk) is a pattern that shall match any string,
including the null string."
However, `glob.glob` pattern `*` (asterisk) doesn't match an empty/null string.
Reproduction:
$ ls *.bash_profile
.bash_profile
$ python3 -c 'import glob; print(glob.glob("*.bash_profile"))'
[]
$ python3 -c 'import glob; print(glob.glob(".bash_profile"))'
['.bash_profile']
--
components: Library (Lib)
messages: 395545
nosy: max0x7ba
priority: normal
severity: normal
status: open
title: glob.glob handling of * (asterisk) wildcard is broken
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue44380>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44380] glob.glob handling of * (asterisk) wildcard is broken
Change by Maxim Egorushkin : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue44380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44380] glob.glob handling of * (asterisk) wildcard is broken
Maxim Egorushkin added the comment:
I may be naive, but why then:
$ python3 -c 'from pathlib import Path;
print(list(Path(".").glob("*.bash_profile")))'
Outputs:
[PosixPath('.bash_profile')]
?
--
___
Python tracker
<https://bugs.python.org/issue44380>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44380] glob.glob handling of * (asterisk) wildcard is broken
Maxim Egorushkin added the comment: > glob.glob does not provide something equivalent to a DOTALL flag I see now, said a blind man. -- ___ Python tracker <https://bugs.python.org/issue44380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23706] pathlib.Path.write_text should include a newline argument
Change by Maxim Burov : -- keywords: +patch nosy: +maksvenberv nosy_count: 5.0 -> 6.0 pull_requests: +21458 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/22420 ___ Python tracker <https://bugs.python.org/issue23706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23706] pathlib.Path.write_text should include a newline argument
Maxim Burov added the comment: For the newline parameter, what is the expected behaviour? To work as newline from io.open() which supports only so called "legal" newlines which are: None, '', '\n', '\r', and '\r\n', or to allow users use any sequence as newline hence do replacing before passing text to io.open()? -- ___ Python tracker <https://bugs.python.org/issue23706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23706] pathlib.Path.write_text should include a newline argument
Maxim Burov added the comment: CLA signed now and PR is ready :) -- ___ Python tracker <https://bugs.python.org/issue23706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8108] test_ftplib fails with OpenSSL 0.9.8m
Maxim Yegorushkin added the comment:
I am still having this issue with Python-2.7.2 (which includes the patch) and
openssl-devel-1.0.0e-1.fc14.x86_64:
File "./download.py", line 195, in download_file
ftp.retrbinary("retr " + filename, lambda data: file.write(data))
File "/usr/local/ots/python/lib/python2.7/ftplib.py", line 691, in retrbinary
conn.unwrap()
File "/usr/local/ots/python/lib/python2.7/ssl.py", line 275, in unwrap
s = self._sslobj.shutdown()
socket.error: [Errno 0] Error
--
nosy: +max0x7ba
___
Python tracker
<http://bugs.python.org/issue8108>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32634] Message parsing fails where it has incompele headers
New submission from Maxim Barabanov : If email message dont have a content-transfer-encoding or content-type header, function write in generator.py crashes -- components: email messages: 310485 nosy: barry, r.david.murray, reb00ter priority: normal severity: normal status: open title: Message parsing fails where it has incompele headers type: crash versions: Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.org/issue32634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32634] Message parsing fails where it has incompele headers
Change by Maxim Barabanov : -- keywords: +patch pull_requests: +5125 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available
Change by Maxim Barabanov : -- pull_requests: +5126 ___ Python tracker <https://bugs.python.org/issue3264> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33170] New type based on int() created with typing.NewType is not consistent
New submission from Maxim Avanov :
>From my understanding of the docs section on new types,
>https://docs.python.org/3/library/typing.html#newtype the new type based on
int() should just pass the value into the base constructor. However,
```
PercentDiscount = NewType('PercentDiscount', int)
>>> PercentDiscount(50) == int(50)
True
>>> int('50') == int(50)
True
>>> PercentDiscount('50') == PercentDiscount(50)
False
```
--
components: Library (Lib)
messages: 314598
nosy: avanov
priority: normal
severity: normal
status: open
title: New type based on int() created with typing.NewType is not consistent
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue33170>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33170] New type based on int() created with typing.NewType is not consistent
Maxim Avanov added the comment:
Logically, I would expect it to behave similarly to
```
>>> class PercentDiscount(int): pass
>>> PercentDiscount('50') == PercentDiscount(50)
True
```
--
___
Python tracker
<https://bugs.python.org/issue33170>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33170] New type based on int() created with typing.NewType is not consistent
Maxim Avanov added the comment: Ok, after further reading, I see that NewType creates an identity stub. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33170> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8617] Better document user site-packages in site module doc
Maxim Doucet added the comment: Shouldn't there be an update of the 2.6 documentation too? After your patch, the 2.7 reflects the existence of the "--user" option (see http://docs.python.org/release/2.7.3/install/index.html#alternate-installation-the-user-scheme) but not the 2.6 documentation (http://docs.python.org/release/2.6.8/install/index.html#alternate-installation). In my personal experience, I used the "--home" option with python 2.6 to mimic what "--user" does and it took me 2 weeks to, by chance, stumble upon http://www.python.org/dev/peps/pep-0370/ which informed me that the "--user" option was originally available for python 2.6. If it had been on the 2.6 documentation, it would have been easier and more coherent IMHO. -- nosy: +maximd ___ Python tracker <http://bugs.python.org/issue8617> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8617] Better document user site-packages in site module doc
Maxim Doucet added the comment: Fair enough, thank you for the information. As a side note, my original question was in fact more suited for issue10745 -- ___ Python tracker <http://bugs.python.org/issue8617> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27503] support RUSAGE_THREAD as a constant in the resource module
New submission from Maxim Sobolev: This is duplicate of the #10440, which has been added in 2010 into 3.x but never merged. -- files: patch-Modules_resource.c messages: 270275 nosy: Maxim Sobolev priority: normal severity: normal status: open title: support RUSAGE_THREAD as a constant in the resource module type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file43700/patch-Modules_resource.c ___ Python tracker <http://bugs.python.org/issue27503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7352] pythonx.y-config --ldflags out of /usr and missing -L
Maxim Egorushkin added the comment:
I encountered this issue when compiling gdb against my own build of Python 2.7
in a non-standard location. gdb could not locate libpython2.7.so.
The solution is to configure Python with LINKFORSHARED variable which contains
additional linker flags required to link against libpython2.7.so. Here are the
relevant bits (in Makefile syntax):
prefix := /opt/toolchain
python_version := 2.7.10
PREFIX := ${prefix}/python-${python_version}
CPPFLAGS := -fmessage-length=0
LINKFORSHARED := -L${PREFIX}/lib64 -Wl,-rpath=${PREFIX}/lib64
./configure --prefix=${PREFIX} --libdir=${PREFIX}/lib64 --enable-shared
--enable-unicode=ucs4 CPPFLAGS="${cppflags}" LDFLAGS="${LDFLAGS}"
LINKFORSHARED="${LINKFORSHARED}"
After Python is built and installed verify the flags:
$ /opt/toolchain/python-2.7.10/bin/python-config --ldflags
-lpython2.7 -lpthread -ldl -lutil -lm
-L/opt/toolchain/python-2.7.10/lib64
-Wl,-rpath=/opt/toolchain/python-2.7.10/lib64
--
nosy: +max0x7ba
___
Python tracker
<http://bugs.python.org/issue7352>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23711] ConfigParser module blames on section less ini file
New submission from Maxim Kot: Wikipedia (http://en.wikipedia.org/wiki/INI_file#Sections) says: >Keys may (but need not) be grouped into arbitrarily named sections But when it's trying to parse file without section header - "MissingSectionHeaderError: File contains no section headers" raised. Can such check be made optional and switched on for default for example? -- components: Library (Lib) messages: 238537 nosy: Maxim Kot, lukasz.langa priority: normal severity: normal status: open title: ConfigParser module blames on section less ini file type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue23711> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
