[issue30937] csv module examples miss newline='' when opening files
New submission from Pavel:
At the very beginning the csv module documentation
(https://docs.python.org/3.7/library/csv.html) advises to open files passing
newline='' parameter though three examples don't include it:
Here are the examples:
1:
>>> import csv
>>> with open('names.csv') as csvfile:
... reader = csv.DictReader(csvfile)
... for row in reader:
... print(row['first_name'], row['last_name'])
...
Eric Idle
John Cleese
>>> print(row)
OrderedDict([('first_name', 'John'), ('last_name', 'Cleese')])
2:
import csv
with open('names.csv', 'w') as csvfile:
fieldnames = ['first_name', 'last_name']
writer = csv.DictWriter(csvfile, fieldnames=fieldnames)
writer.writeheader()
writer.writerow({'first_name': 'Baked', 'last_name': 'Beans'})
writer.writerow({'first_name': 'Lovely', 'last_name': 'Spam'})
writer.writerow({'first_name': 'Wonderful', 'last_name': 'Spam'})
3:
with open('example.csv') as csvfile:
dialect = csv.Sniffer().sniff(csvfile.read(1024))
csvfile.seek(0)
reader = csv.reader(csvfile, dialect)
# ... process CSV file contents here ...
--
assignee: docs@python
components: Documentation
messages: 298397
nosy: Pavel, docs@python
priority: normal
severity: normal
status: open
title: csv module examples miss newline='' when opening files
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue30937>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25517] regex howto example in "Lookahead Assertions"
New submission from Pavel:
The example advises ".*[.](?!bat$).*$" expression "to match filenames where the
extension is not bat". But here is an example which passes such check:
>>> re.match("(.*)[.](?!bat$).*$", "test.a.bat")
<_sre.SRE_Match object at 0x7ff221996f30>
To my mind use of negative lookbehind expressions (not covered so far in the
HOWTO) is better:
>>> re.match("(.*)[.].*(?>>
------
assignee: docs@python
components: Documentation
messages: 253725
nosy: Pavel, docs@python
priority: normal
severity: normal
status: open
title: regex howto example in "Lookahead Assertions"
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue25517>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12945] ctypes works incorrectly with _swappedbytes_ = 1
Pavel Boldin added the comment: We have raw data packages from some tools. These packages contains bitfields, arrays, simple data and so on. We want to parse them into Python objects (structures) for analysis and storage. I tried to use ctypes, but now I wrote myself implementation of raw parser based on bitarray and struct. I wonder if ctypes can do this. -- ___ Python tracker <http://bugs.python.org/issue12945> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Changes by Pavel Labushev : -- nosy: +Arach ___ Python tracker <http://bugs.python.org/issue13703> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12176] Compiling Python 2.7.1 on Ubuntu 11.04 (Natty Narwhale)
New submission from Pavel Bogdanovic : Compiling of Python does end with an error. It has to do with changes in Ubuntu: https://wiki.ubuntu.com/MultiarchSpec I added one line after python's setup.py after line 351 add_dir_to_list(self.compiler.library_dirs, '/usr/lib/i386-linux-gnu') and it compiled. It might be archeticture-dependent. Perhaps it should account (/lib/i386-linux-gnu /lib/x86_64-linux-gnu /usr/lib/i386-linux-gnu /usr/lib/x86_64-linux-gnu) -- components: Build files: patch_setup.py messages: 136862 nosy: Pavel.Bogdanovic priority: normal severity: normal status: open title: Compiling Python 2.7.1 on Ubuntu 11.04 (Natty Narwhale) type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file22111/patch_setup.py ___ Python tracker <http://bugs.python.org/issue12176> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12176] Compiling Python 2.7.1 on Ubuntu 11.04 (Natty Narwhale)
Pavel Bogdanovic added the comment: yes, the patch mentioned in issue 11715 works. Sorry for crossposting the issue. -- ___ Python tracker <http://bugs.python.org/issue12176> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12945] ctypes works incorrectly with _swappedbytes_ = 1
New submission from Pavel Boldin :
ctypes seems to work incorrectly with _swappedbytes_ specified.
I.e. it misses some values from buffer:
class X(ctypes.Structure):
_swappedbytes_ = 1
_pack_ = 1
_fields_ = [
('a', ctypes.c_ubyte, 4),
('b', ctypes.c_ubyte, 4),
('c', ctypes.c_ushort, 8),
('d', ctypes.c_ushort, 8),
]
buf = '\x12\x34\x56\x78'
x = X.from_buffer_copy(buf)
print x.a == 1
print x.b == 2
print x.c == 3
print x.d == 4
This prints
True
True
False
False
Where as four 'True' are expected.
--
components: ctypes
files: test_ctypes.py
messages: 143761
nosy: Pavel.Boldin
priority: normal
severity: normal
status: open
title: ctypes works incorrectly with _swappedbytes_ = 1
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file23122/test_ctypes.py
___
Python tracker
<http://bugs.python.org/issue12945>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12945] ctypes works incorrectly with _swappedbytes_ = 1
Pavel Boldin added the comment:
Yes. Thanks. But here is another error:
import ctypes
class X(ctypes.Structure):
_pack_ = 1
_fields_ = [
('a', ctypes.c_ubyte, 4),
('b', ctypes.c_ubyte, 4),
('c', ctypes.c_ushort, 4),
('d', ctypes.c_ushort, 12),
]
buf = '\x12\x34\x56\x78'
x = X.from_buffer_copy(buf)
print X.a
print X.b
print X.c
print X.d
print x.a == 2
print x.b == 1
print x.c == 4
print x.d == 0x563
Prints (python 2.7.1):
True
True
True
False
Can you reproduce this?
--
___
Python tracker
<http://bugs.python.org/issue12945>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12945] ctypes works incorrectly with _swappedbytes_ = 1
Pavel Boldin added the comment: OK. So, it seems just like ctypes work, but don't for my needs. Thing that bothers me anyway is the strange code, where size contains either size (when bitsize==0) or bitsize in upper 16 bits and bitoffset in lower 16 bits. -- ___ Python tracker <http://bugs.python.org/issue12945> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11048] "import ctypes" causes segfault on read-only filesystem
New submission from Pavel Labushev : "import ctypes" causes segfault on read-only filesystem This regression was introduced in python-2.6.6 and exists in all the later versions. To reproduce run python -c "import ctypes" on read-only filesystem: (gdb) file python3.2 Reading symbols from /usr/bin/python3.2...done. (gdb) run -c "import ctypes" Starting program: /usr/bin/python3.2 -c "import ctypes" [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0xb7af605c in CThunkObject_dealloc (_self=0xb7b35344) at /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/callbacks.c:18 18 /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/callbacks.c: No such file or directory. in /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/callbacks.c (gdb) bt #0 0xb7af605c in CThunkObject_dealloc (_self=0xb7b35344) at /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/callbacks.c:18 #1 0xb7af63b4 in _ctypes_alloc_callback (callable=0xb7b10bec, converters=0xb7c4e02c, restype=0xb810c544, flags=257) at /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/callbacks.c:439 #2 0xb7af1f57 in PyCFuncPtr_new (type=0xb810b0bc, args=0xb7b3618c, kwds=0x0) at /var/tmp/portage/dev-lang/python-3.2_pre20110123/work/python-3.2_pre20110123/Modules/_ctypes/_ctypes.c:3339 #3 0xb7ea2355 in type_call (type=0xb810b0bc, args=0xb7b3618c, kwds=0x0) at Objects/typeobject.c:676 #4 0xb7e4f34e in PyObject_Call (func=0xb810b0bc, arg=0xb7b3618c, kw=0x0) at Objects/abstract.c:2149 #5 0xb7eedee3 in do_call (f=0xb80fdb44, throwflag=0) at Python/ceval.c:4095 #6 call_function (f=0xb80fdb44, throwflag=0) at Python/ceval.c:3898 #7 PyEval_EvalFrameEx (f=0xb80fdb44, throwflag=0) at Python/ceval.c:2673 #8 0xb7ef0639 in PyEval_EvalCodeEx (_co=0xb7b159d0, globals=0xb7bf40b4, locals=0xb7bf40b4, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3311 #9 0xb7ef08b6 in PyEval_EvalCode (co=0xb7b159d0, globals=0xb7bf40b4, locals=0xb7bf40b4) at Python/ceval.c:761 #10 0xb7f0121c in PyImport_ExecCodeModuleWithPathnames (name=0xbfffd9fb "ctypes", co=0xb7b159d0, pathname=0xbfffa89b "/usr/lib/python3.2/ctypes/__pycache__/__init__.cpython-32.pyc", cpathname=0xbfffa89b "/usr/lib/python3.2/ctypes/__pycache__/__init__.cpython-32.pyc") at Python/import.c:809 #11 0xb7f03ce8 in load_source_module (name=, pathname=, fp=0xb8020b28) at Python/import.c:1339 #12 0xb7f044f8 in load_package (name=, pathname=) at Python/import.c:1435 #13 0xb7f04da7 in import_submodule (mod=, subname=, fullname=0xbfffd9fb "ctypes") at Python/import.c:2894 #14 0xb7f050b4 in load_next (mod=, altmod=, p_name=0xbfffd9ec, buf=0xbfffd9fb "ctypes", p_buflen=0xbfffd9f4) at Python/import.c:2706 #15 0xb7f05774 in import_module_level (name=0x0, globals=, locals=0xb7c2035c, fromlist=0xb7f98ca0, level=0) at Python/import.c:2422 #16 0xb7f05d14 in PyImport_ImportModuleLevel (name=0xb7c0f8e8 "ctypes", globals=0xb7c2035c, locals=0xb7c2035c, fromlist=0xb7f98ca0, level=0) at Python/import.c:2474 #17 0xb7ee73c1 in builtin___import__ (self=0xb7c6726c, args=0xb7c7b9bc, kwds=0x0) at Python/bltinmodule.c:168 #18 0xb7e907fe in PyCFunction_Call (func=0xb7c6730c, arg=0xb7c7b9bc, kw=0xb7b35344) at Objects/methodobject.c:84 #19 0xb7e4f34e in PyObject_Call (func=0xb7c6730c, arg=0xb7c7b9bc, kw=0x0) at Objects/abstract.c:2149 #20 0xb7ee802f in PyEval_CallObjectWithKeywords (func=0xb7c6730c, arg=0xb7c7b9bc, kw=0x0) at Python/ceval.c:3755 #21 0xb7eec962 in PyEval_EvalFrameEx (f=0xb8072564, throwflag=0) at Python/ceval.c:2332 #22 0xb7ef0639 in PyEval_EvalCodeEx (_co=0xb7bdb7f0, globals=0xb7c2035c, locals=0xb7c2035c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3311 #23 0xb7ef08b6 in PyEval_EvalCode (co=0xb7bdb7f0, globals=0xb7c2035c, locals=0xb7c2035c) at Python/ceval.c:761 #24 0xb7f0eabc in run_mod (mod=, filename=, globals=0xb7c2035c, locals=0xb7c2035c, flags=0xbfffefa8, arena=0xb8071030) at Python/pythonrun.c:1760 #25 0xb7f0edf9 in PyRun_StringFlags (str=0xb7bf5330 "import ctypes\n", start=257, globals=0xb7c2035c, locals=0xb7c2035c, flags=0xbfffefa8) at Python/pythonrun.c:1694 #26 0xb7f11006 in PyRun_SimpleStringFlags (command=0xb7bf5330 "import ctypes\n", flags=0xbfffefa8) at Python/pythonrun.c:1267 #27 0xb7f2477c in run_command (argc=3, argv=0xb8001018) at Modules/main.c:258 #28 Py_Main (argc=3, argv=0xb8001018) at Modules/main.c:647 #29 0xb7fffc4f in main (argc=3, argv=0xb0d4) at ./Modules/python.c:82 (gdb) quit -- assignee: theller componen
[issue11048] "import ctypes" causes segfault on read-only filesystem
Pavel Labushev added the comment:
How to reproduce:
# mkdir /mnt/readonly
# mount --bind / /mnt/readonly
# mount -o remount,ro /mnt/readonly
# mount -t proc proc /mnt/readonly/proc
# chroot /mnt/readonly python3.2 -c "import ctypes"
Segmentation fault
If your python build expected to have this bug, you'll see something like this
(the -1 EROFS lines):
# chroot /mnt/readonly strace -f -e trace=open python3.2 -c "import ctypes"
2>&1 | grep ffi
open("/usr/lib/libffi.so.5", O_RDONLY) = 5
open("/tmp/.private/root/ffiicoh8G", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 ENOENT
(No such file or directory)
open("/tmp/ffiFjqUa9", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EROFS (Read-only file
system)
open("/var/tmp/ffidTdydB", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EROFS (Read-only
file system)
open("/dev/shm/ffiemIcg3", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EROFS (Read-only
file system)
open("/root/ffiXfWRiv", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EROFS (Read-only file
system)
--
___
Python tracker
<http://bugs.python.org/issue11048>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3195] invalid conversion xml.etree.ElementTree.Element object to boolean
New submission from Pavel Strashkin <[EMAIL PROTECTED]>:
Python 2.5.2 (r252:60911, May 7 2008, 15:19:09)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.ElementTree import Element
>>> e = Element('Test', {'attr' : 'value'})
>>> b = not e
>>> print b
True
Why i'm getting True here instead of False?
Because of this i can not do:
if not e:
# here some logic
pass
--
components: XML
messages: 68720
nosy: xaka
severity: normal
status: open
title: invalid conversion xml.etree.ElementTree.Element object to boolean
versions: Python 2.5
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3195>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3442] wsgiref.validate.InputWrapper.readline does not accept optional "length" argument
New submission from Pavel Strashkin <[EMAIL PROTECTED]>:
All file/stream-like objects in Python have "readline" method with
optional "length" argument, but wsgiref.validate.InputWrapper doest not
have. Some 3rd party modules/packages use this argument. As result there
is exception:
: readline() takes exactly 1 argument (2 given)
I think wsgiref.validate.InputWrapper.readline must be implemented same
to wsgiref.validate.InputWrapper.read:
def readline(self, *args, **kwargs):
v = self.input.readline(*args, **kwargs)
assert_(type(v) is type(""))
return v
--
components: Library (Lib)
messages: 70248
nosy: xaka
severity: normal
status: open
title: wsgiref.validate.InputWrapper.readline does not accept optional "length"
argument
versions: Python 2.5
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3442>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1949] test_ntpath.py converted to unittest
Pavel Vinogradov added the comment: This patch also looks good for me. It convert all test cases and run successfully on latest python trunk (on Linux). -- nosy: +pavel.vinogradov __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1949> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] platform.dist() has unpredictable result under Linux
Pavel Vinogradov added the comment: I'm work on this issue in GHOP(http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=216&can=1&colspec=ID%20Status%20ClaimedBy%20Due%20NeedsReview%20Summary) I'm attach updated patch for python trunk. This patch fixes issue and add additional test for some other Linux distributions. -- nosy: +pavel.vinogradov Added file: http://bugs.python.org/file9504/test_platform_py26.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1322> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] platform.dist() has unpredictable result under Linux
Pavel Vinogradov added the comment: You can see confirmation from Georg on thread in GHOP: http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=216&can=1&colspec=ID%20Status%20ClaimedBy%20Due%20NeedsReview%20Summary#c20 I can update patch for 3.0 (it don't applies now) if you are ready to commit them. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1322> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2176] Undocumented lastrowid attribute i sqlite3 cursor class
Pavel Vinogradov added the comment: This patch include brief lastrowid description based on my experience and Python DB API 2.0 PEP. -- keywords: +patch nosy: +pavel.vinogradov Added file: http://bugs.python.org/file9582/lastrowid_rst_desctiption.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2176> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2675] Curses terminal resize problems when Python is in interactive mode
New submission from Pavel Bazant <[EMAIL PROTECTED]>:
When python is in interactive mode, curses does not react to resize
events properly.
test.py:
import curses
def run():
stdscr=curses.initscr()
key=0
while(key!=ord('q')):
key=stdscr.getch()
stdscr.addstr(0,0,str(stdscr.getmaxyx())+' '+str(key))
stdscr.refresh()
curses.endwin()
run()
When this is run directly, everything is ok. When it is called via
execfile() from the interactive prompt, it shows the right screen size
after the first keypress, but behaves oddly after the resize.
IMHO, the following happens:
For some reason, env. variables LINES and COLUMNS are set but they are
not reflected in the os.environ structure nor they respond to screen
size changes. If these variables are set then the ncurses library (see
man pages) uses their values instead of getting the term size via
ioctl.
The ncurses library receives a SIGWINCH and sees that LINES
and COLUMNS are set. However, their values are same as the
screen dimensions before the resize, so it is perplexed why there is
a SIGWINCH if the screen did not change and it just ungetchs an ERR
and ncurses internal structures are not changed appropriately.
>From the resizeterm man page:
"If the environment variables LINES or COLUMNS are set, this overrides
the library's use of the window size obtained from the operating
system. Thus, even if a SIGWINCH is received, no screen size change may
be recorded. In that case, no KEY_RESIZE is queued for the next call to
getch; an ERR will be returned instead."
Executing
import os
os.environ['LINES']="blah"
del os.environ['LINES']
os.environ['COLUMNS']="blah"
del os.environ['COLUMNS']
solves the problem for me.
Perhaps the problem has sth to do with python using readline
in interactive mode???
PB
--
components: None
messages: 65700
nosy: pbazant
severity: normal
status: open
title: Curses terminal resize problems when Python is in interactive mode
type: behavior
versions: Python 2.4
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2675>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2827] IDLE 3.0a5 cannot handle UTF-8
Pavel Kosina added the comment: the following very simple example might be the the same issue: x="ěščřžýáíé" print (x) It reliably puts down IDLE entirely without any error message. It is saved in UTF-8. python +idle 3.0, wxp sp3 -- nosy: +geon ___ Python tracker <http://bugs.python.org/issue2827> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2827] IDLE 3.0a5 cannot handle UTF-8
Pavel Kosina added the comment: Thank you. Not sure, what to do now, cause the putting down of IDLE is fixed, but still within IDLE I get wrong output: x="ěščřžýáíé" print (x) >>> ěščřžýáĂĂ© when running this script under python command line form another editor, I get the output readable as expected. Shall I open another issue? Added file: http://bugs.python.org/file12547/q.py ___ Python tracker <http://bugs.python.org/issue2827> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2827] IDLE 3.0a5 cannot handle UTF-8
Pavel Kosina added the comment: Moreover: do you think its good idea to change the file encoding at opened and then saved file without any question when there is no encoding declaration? :-( Users do not edit just python programs, they can edit also config files, text files, etc It could be that at first saving we are asked to use *utf8 *used one. ___ Python tracker <http://bugs.python.org/issue2827> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4815] idle 3.1a1 utf8
New submission from Pavel Kosina : When you open file without encoding declaration, make changes and save, then IDLE changes without any question encodings to utf8. You can try it on attached file that is cp1250 now. It could be that at first saving we are asked to use *utf8 *current one. -- components: IDLE files: cp1250.py messages: 78932 nosy: geon severity: normal status: open title: idle 3.1a1 utf8 versions: Python 3.1 Added file: http://bugs.python.org/file12559/cp1250.py ___ Python tracker <http://bugs.python.org/issue4815> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4008] IDLE: checksyntax() doesn't support Unicode?
Pavel Kosina added the comment:
I vote for fixing this too. This might be simplified/another example of
above mentioned issues:
# -*- coding: utf-8 -*-
print ("ěščřžýáíé")
in IDLE prints this:
>>>
ěščřžýáĂĂ©
When running this script under python command line from another editor,
I get the output readable as expected.
--
nosy: +geon
___
Python tracker
<http://bugs.python.org/issue4008>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4815] idle 3.1a1 utf8
Pavel Kosina added the comment: You can open script made in python 2.x and it stops immediately working after saving, if it is coding-aware. You can have bigger project and use idle for editing config and text files from this project too. It is "unfair" to change without notification the encodings. Or do you consider IDLE just for beginners for learning? ___ Python tracker <http://bugs.python.org/issue4815> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4815] idle 3.1a1 utf8
Pavel Kosina added the comment: I forgot about "Perhaps IDLE should offer to convert it on opening." That would be nice, too. ___ Python tracker <http://bugs.python.org/issue4815> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4815] idle 3.1a1 utf8
Pavel Kosina added the comment: Sorry, where is the patch? ___ Python tracker <http://bugs.python.org/issue4815> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4815] idle 3.1a1 utf8
Pavel Kosina added the comment: OK, I got it. In my opinion it would nice if user can either convert file to utf8 or to do nothing and add new encodings declaration or cancel. Current "Cancel" gives an Decoding error. If you give an encodings that doesn't exist, it shouldn't destroy IDLE. Hoping its not my mistake, cause I do not have all files from 3.1a - just those from idlelib. ___ Python tracker <http://bugs.python.org/issue4815> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4815] idle 3.1a1 utf8
Pavel Kosina added the comment: seems to be working. Seems to me now I get it. The file encoding is ruled by the encoding declaration. When I stated # -*- coding: cp1250 -*- then the file would be saved in cp1250. Now hoping that I would keep this issue, cause it comes with this patches: when I open file *with* say # -*- coding: cp1250 -*-, I am asked to change to utf8. This behaviour was not before and is probably unwanted. ___ Python tracker <http://bugs.python.org/issue4815> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4815] idle 3.1a1 utf8
Pavel Kosina added the comment: Well, thanks a lot. (aware this is really off this issue): Now I even get the system of patches - issue 4008 solved the inconvenience in print Unicode signs inside IDLE. Still not sure how works patches for Python versions. I vote for including this a that patch about IDLE even in some 3.0.1, not only in branch 3.1. In non-English speaking countries troubles with encodings are more common, more beginners-frustrating than you can believe. HNY 2009 Pavel Kosina ___ Python tracker <http://bugs.python.org/issue4815> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4823] idle height and place
New submission from Pavel Kosina : Nearly always (after opening) is IDLE window outside visible area. Mainly the status bar is hidden under bottom windows menu bar. Same situation happens when choosing Window-Zoom Height from IDLE menu. xpsp3, 1024x768, py2.x-3.x -- components: IDLE messages: 78983 nosy: geon severity: normal status: open title: idle height and place type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue4823> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4823] idle height and place
Pavel Kosina added the comment: sorry it is duplicate to issue 3286 pls close ___ Python tracker <http://bugs.python.org/issue4823> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3286] IDLE opens window too low on Windows
Pavel Kosina added the comment: +1 -- nosy: +geon versions: +Python 3.1 ___ Python tracker <http://bugs.python.org/issue3286> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4815] idle 3.1a1 utf8
Pavel Kosina added the comment:
I might have another problem with this patch and maybe also that one in
issue 4008. Having a file with
print ("ěščřžýáíé")
# saved in cp1250
Open - confirm converting to utf8 - F5 - error: see attached file
idleunicode1.jpg
Added file: http://bugs.python.org/file12576/idleunicode1.jpg
___
Python tracker
<http://bugs.python.org/issue4815>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4815] idle 3.1a1 utf8
Pavel Kosina added the comment: Martin v. Löwis napsal(a), dne 3.1.2009 22:24: > I can't reproduce the problem. Can you please attach the > exact file that failed to work? > You can use that one that is already here: cp1250.py. It is the same error with me. ___ Python tracker <http://bugs.python.org/issue4815> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4815] idle 3.1a1 utf8
Pavel Kosina added the comment: Microsoft Windows XP [Verze 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\prg\Python30\Lib\idlelib>svn update# from http://svn.python.org/projects/python/branches/py3k/Lib/idlelib Restored 'AutoCompleteWindow.py' Restored 'ToolTip.py' Restored 'UndoDelegator.py' Restored 'Bindings.py' Restored '__init__.py' Restored 'AutoComplete.py' Restored 'configHandler.py' Restored 'HyperParser.py' Restored 'ColorDelegator.py' Restored 'Delegator.py' Restored 'ObjectBrowser.py' Restored 'testcode.py' Restored 'configSectionNameDialog.py' Restored 'ZoomHeight.py' Restored 'PyShell.py' Restored 'ParenMatch.py' Restored 'config-keys.def' Restored 'Debugger.py' Restored 'CREDITS.txt' Restored 'configDialog.py' Restored 'StackViewer.py' Restored 'HISTORY.txt' Restored 'SearchEngine.py' Restored 'ReplaceDialog.py' Restored 'ScriptBinding.py' Restored 'ChangeLog' Restored 'tabbedpages.py' Restored 'keybindingDialog.py' Restored 'configHelpSourceEdit.py' Restored 'WidgetRedirector.py' Restored 'GrepDialog.py' Restored 'FormatParagraph.py' Restored 'EditorWindow.py' Restored 'help.txt' Restored 'config-highlight.def' Restored 'PyParse.py' Restored 'README.txt' Restored 'rpc.py' Restored 'OutputWindow.py' Restored 'aboutDialog.py' Restored 'idle.bat' Restored 'TODO.txt' Restored 'config-main.def' Restored 'IdleHistory.py' Restored 'PathBrowser.py' Restored 'IOBinding.py' Restored 'WindowList.py' Restored 'ScrolledList.py' Restored 'ClassBrowser.py' Restored 'FileList.py' Restored 'CallTips.py' Restored 'idle.py' Restored 'CodeContext.py' Restored 'textView.py' Restored 'SearchDialogBase.py' Restored 'CallTipWindow.py' Restored 'SearchDialog.py' Restored 'RemoteObjectBrowser.py' Restored 'idlever.py' Restored 'RemoteDebugger.py' Restored 'TreeWidget.py' Restored 'NEWS.txt' Restored 'idle.pyw' Restored 'run.py' Restored 'config-extensions.def' Restored 'AutoExpand.py' Restored 'Percolator.py' Restored 'dynOptionMenuWidget.py' Restored 'extend.txt' Restored 'MultiStatusBar.py' Restored 'MultiCall.py' Restored 'macosxSupport.py' At revision 68230. C:\prg\Python30\Lib\idlelib>patch < conv.diff patching file IOBinding.py C:\prg\Python30\Lib\idlelib>patch < idle_encoding_4.patch patching file ScriptBinding.py patching file IOBinding.py - Run IDLE - Open cp1250.py - confirm converting to utf8 - F5 (immediately, no change in code!) - error: see attached file idleunicode1.jpg All the other python code base is clean 3.0. xpsp3 ___ Python tracker <http://bugs.python.org/issue4815> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4815] idle 3.1a1 utf8
Pavel Kosina added the comment: Yes. God job. ;-) ___ Python tracker <http://bugs.python.org/issue4815> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3087] Clean up Demos and Tools
Pavel Kosina added the comment: +1 In Tkinter there is still import Tkinter and not import tkinter. -- nosy: +geon ___ Python tracker <http://bugs.python.org/issue3087> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4815] idle 3.1a1 utf8
Pavel Kosina added the comment: Martin v. Löwis napsal(a), dne 4.1.2009 14:39: > Why that? This file is already encoded in utf-8 just fine. It is, > simultaneously, also encoded in ASCII, cp1250, cp1252, and nearly > any other encoding in use (as long as it is ASCII-based). > Well I am not much experienced but this file is not real utf8. It is encoded in ascii, cp1250, cp1252, and many other but not in utf8. utf8 has a special flag, special bytes inside - as a special mark for editors. That is what this file doesnt have. Even after making change in it in IDLE, it does not became real utf8. I always check it in another editor, that can work with encoding very well - PSPad. ___ Python tracker <http://bugs.python.org/issue4815> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4832] idle filename extension
New submission from Pavel Kosina : There should not be necessity to write filename *with extension* at the saving dialog. It should be enough, at least on Windows, to put there just "hello" and get "hello.py". It is really complication especially for beginners. If they, as they are used to from another programs, put there just "hello", it is saved without extension ".py" what have 2 result: they cannot see any icons at that file and they are not able to run in, cause python.exe is bind with ".py". Hoping its not duplicate I haven't found anything like this here. -- components: IDLE messages: 79062 nosy: geon severity: normal status: open title: idle filename extension type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue4832> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4815] idle 3.1a1 utf8
Pavel Kosina added the comment: With this file - hello.py (attached) - I should be also asked for converting to utf8. When I open it, nothing changes, after making changes and saving then the encodings is my windows standard cp1250 Added file: http://bugs.python.org/file12582/hello.py ___ Python tracker <http://bugs.python.org/issue4815> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44528] Move IP version resolving to http.server's API
New submission from pavel-lexyr : Python's native HTTP server (http.server module) has special code to allow it to detect and bind to IPv6 addresses when called as a CLI tool. As of right now, the code is in private functions. Those are not intended to be called by library users - only the CLI command. People want to create HTTP/WSGI servers programmatically - then they run into similar problems. Since the relevant code is not open for library use, they copy it to their own projects instead. That's code duplication. Exhibit A: https://github.com/prometheus/client_python/pull/657 This doesn't look like a good way to do things. To avoid such problems, it can be useful to have the CLI tool's protocol version resolver added to the library. This relates to bpo-20215, which has related aspirations - but a broader scope. -- components: Library (Lib) messages: 396655 nosy: jaraco, pavel-lexyr priority: normal severity: normal status: open title: Move IP version resolving to http.server's API type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue44528> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44571] itertools: takedowhile()
New submission from pavel-lexyr : As described in the documentation, itertools.takewhile() returns all the elements until the first one that does not match the provided criterion. In case of a destructive iterator, or one with side effects, not yielding an element downstream may render takewhile() unsuitable for use. Proposed is itertools.takedowhile() - an alternate function that yields the first false element as well, and returns after. The behaviour is identical otherwise. -- messages: 397025 nosy: pavel-lexyr, rhettinger priority: normal severity: normal status: open title: itertools: takedowhile() type: enhancement ___ Python tracker <https://bugs.python.org/issue44571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44571] itertools: takedowhile()
pavel-lexyr added the comment: I see. If the syntax allows for better ways to do it now, perhaps a move towards deprecation would be a better idea then? This would agree with the Zen. Also, please elaborate more on the generator-based solutions you have in mind. The suggestion stems from a very real use case - and the lambda function we ended up using looks like a poor hack. -- ___ Python tracker <https://bugs.python.org/issue44571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44571] itertools: takedowhile()
pavel-lexyr added the comment: There is a core part of the `takedowhile` proposal's use case that I am having trouble envisioning via the alternative `before_and_after` proposal. If the `after` part of the iterator the user does not engage with, the transitional elements will be stuck indefinitely. What would a correct usage be, in case one wants the following two conditions to hold true: 1. the amount of elements after the first falsifying one is minimal, i.e. 0 2. all the yielded elements are processed no matter what? -- ___ Python tracker <https://bugs.python.org/issue44571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44571] itertools: takedowhile()
pavel-lexyr added the comment: Thank you - that answers the questions. The use case where we would want to know if the last element is transitional or not completely slipped my mind for some reason. -- ___ Python tracker <https://bugs.python.org/issue44571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44634] Version is duplicated in name of app in list of installed apps
New submission from Pavel Moiseenko : The version of the app is duplicated in the name of the app in the list of installed apps in "Settings - Apps - Apps & features" and "Control Panel - Programs - Programs and Features" in the version for Windows. Please remove the version number from the app name, as the version number is displayed next to the name in a separate field. -- components: Windows files: 2021-07-14 13-49-41 Settings.png messages: 397474 nosy: paul.moore, rakleed, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Version is duplicated in name of app in list of installed apps type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file50147/2021-07-14 13-49-41 Settings.png ___ Python tracker <https://bugs.python.org/issue44634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44634] Version is duplicated in name of app in list of installed apps
Change by Pavel Moiseenko : Added file: https://bugs.python.org/file50148/2021-07-14 13-50-19 Programs and Features.png ___ Python tracker <https://bugs.python.org/issue44634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44634] Version is duplicated in name of app in list of installed apps
Pavel Moiseenko added the comment: This does not cause any problems in the operation of the app, but visually it looks strange. Most other apps don't indicate the version of the app in the name of the app, but just indicate it in a specially made field for this. Therefore, it would be nice if your app followed this behavior. Perhaps these links will also be helpful: https://docs.microsoft.com/en-us/windows/win32/msi/uninstall-registry-key, https://stackoverflow.com/questions/26156405/how-to-change-add-remove-program-name-using-wix-installer And can you tell me where the WiX config file is? -- ___ Python tracker <https://bugs.python.org/issue44634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44634] Version is duplicated in name of app in list of installed apps
Pavel Moiseenko added the comment: @paul.moore, but you don't need to open additional menus in the control panel to see the version of the app. -- ___ Python tracker <https://bugs.python.org/issue44634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44768] dataclasses.dataclass and collections.namedtuple do the same thing
New submission from pavel-lexyr : PEP 20 states: > There should be one-- and preferably only one --obvious way to do it. As of right now, two very similar constructions for making a lightweight dataclass exist in Python. collections.namedtuple is one of them. dataclasses.dataclass is the other*. The behaviour they provide is very similar. And with the functions .astuple() and the `frozen` constructor argument of the dataclass, one could consider it to be almost a direct superset of the namedtuple. Having two different classes with very similar behaviour is not considered a good practice. I propose merging the two classes' features into one and to deprecate the other, to prevent unnecessary ambiguity. * To get deeper into semantics, we might consider types.SimpleNamespace to be the third. This is out of this issue's scope - the reader is welcome to follow up in another one. -- components: Library (Lib) messages: 398421 nosy: eric.smith, pavel-lexyr, rhettinger priority: normal severity: normal status: open title: dataclasses.dataclass and collections.namedtuple do the same thing type: enhancement versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44765] Misspelled Word In Docs
Change by pavel-lexyr : -- keywords: +patch nosy: +pavel-lexyr nosy_count: 3.0 -> 4.0 pull_requests: +25959 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/27430 ___ Python tracker <https://bugs.python.org/issue44765> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44768] dataclasses.dataclass and collections.namedtuple do the same thing
pavel-lexyr added the comment: Most of the differences are direct upgrades added in the dataclass module. Deprecating dataclass in favour of nametuple would be counterproductive, I agree - what about vice versa? -- ___ Python tracker <https://bugs.python.org/issue44768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44768] dataclasses.dataclass and collections.namedtuple do the same thing
pavel-lexyr added the comment: Touche. Another advantage a namedtuple has is that it can expand out of the box - i.e., can write something like > for x, y, z in namedtuple_list: without any list comprehensions. Can we bring those advantages into the dataclass while also preserving the interface? Maybe a special version of the implementation behind the scenes, something similar to what C++ does with bool vectors. -- versions: +Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44768] dataclasses.dataclass and collections.namedtuple do the same thing
Change by pavel-lexyr : -- versions: -Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44768] dataclasses.dataclass and collections.namedtuple do the same thing
Change by pavel-lexyr : -- resolution: -> rejected ___ Python tracker <https://bugs.python.org/issue44768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44768] dataclasses.dataclass and collections.namedtuple do the same thing
pavel-lexyr added the comment: Thank you all for your input! Migrating the discussion to https://mail.python.org/archives/list/python-id...@python.org/thread/UQRCDWMFNC5NRLLQCTYPOEGWJOIV7BGJ/ for now, if anyone wants to continue. -- resolution: rejected -> ___ Python tracker <https://bugs.python.org/issue44768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45872] Turtle documentation, write()
New submission from Pavel V : There are no parentheses for 'font' argument in turtle.write() documentation https://docs.python.org/3.10/library/turtle.html#turtle.write -- assignee: docs@python components: Documentation messages: 406795 nosy: docs@python, willyns priority: normal severity: normal status: open title: Turtle documentation, write() versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45872> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42875] argparse incorrectly shows help string on a new line in case of long command string
New submission from Pavel Ditenbir : Steps to reproduce. Run the attached script: $ python3 argparse-indent-sample.py --help The output is: usage: argparse-indent-sample.py [-h] CMD ... optional arguments: -h, --help show this help message and exit service: CMD command to use addadd something remove remove something a-very-long-command command that does something Expected output is: usage: argparse-indent-sample.py [-h] CMD ... optional arguments: -h, --help show this help message and exit service: CMDcommand to use add add something remove remove something a-very-long-command command that does something -- components: Library (Lib) files: argparse-indent-sample.py messages: 384728 nosy: DiPaolo priority: normal severity: normal status: open title: argparse incorrectly shows help string on a new line in case of long command string type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file49730/argparse-indent-sample.py ___ Python tracker <https://bugs.python.org/issue42875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42875] argparse incorrectly shows help string on a new line in case of long command string
Change by Pavel Ditenbir : -- keywords: +patch pull_requests: +23003 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24177 ___ Python tracker <https://bugs.python.org/issue42875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42875] argparse incorrectly shows help string on a new line in case of long command string
Change by Pavel Ditenbir : -- versions: +Python 3.10, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue42875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42875] argparse incorrectly shows help string on a new line in case of long command string
Change by Pavel Ditenbir : -- versions: -Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue42875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41293] fix confusing example in hashlib docs
New submission from Pavel Trukhanov : The documentation found in https://docs.python.org/3/library/hashlib.html#hash-algorithms give us the following two examples: ``` For example, to obtain the digest of the byte string b'Nobody inspects the spammish repetition': >>> >>> import hashlib >>> m = hashlib.sha256() >>> m.update(b"Nobody inspects") >>> m.update(b" the spammish repetition") >>> m.digest() b'\x03\x1e\xdd}Ae\x15\x93\xc5\xfe\\\x00o\xa5u+7\xfd\xdf\xf7\xbcN\x84:\xa6\xaf\x0c\x95\x0fK\x94\x06' >>> m.digest_size 32 >>> m.block_size 64 More condensed: >>> hashlib.sha224(b"Nobody inspects the spammish repetition").hexdigest() 'a4337bc45a8fc544c03f52dc550cd6e1e87021bc896588bd79e901e2' hashlib ``` It's confusing because two examples use different algo - sha256 and sha224, respectfully. Also the first one gets `.digest()` while the other - `.hexdigest()`, which are incomparable. -- assignee: docs@python components: Documentation messages: 373619 nosy: Pavel Trukhanov, docs@python priority: normal severity: normal status: open title: fix confusing example in hashlib docs ___ Python tracker <https://bugs.python.org/issue41293> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41293] fix confusing example in hashlib docs
Change by Pavel Trukhanov : -- type: -> enhancement versions: +Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41293> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34374] Shouldn't shutil.copyfile replace link in dst with follow_symlinks set?
Pavel Raiskup added the comment: Check out this default behavior of /bin/cp though: $ mkdir a b $ echo content > a/file $ ln -s non-existing b/file $ cp a/file b cp: not writing through dangling symlink 'b/file' Shouldn't shutil.copy*() refuse to write trough a dangling symlink to non-existent file? (ATM it seems it just silently creates the file, or fails if it can not be created). -- nosy: +Pavel Raiskup ___ Python tracker <https://bugs.python.org/issue34374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.
Pavel Kostyuchenko added the comment:
I was able to reproduce the error with version
f13c5c8b9401a9dc19e95d8b420ee100ac022208 on FreeBSD 12.0 VM. The error seems to
be caused not by those changes, but by lack of synchronization in the
multiprocessing.managers.Server.
The failure happens when running the
"test_shared_memory_SharedMemoryManager_basics" with high CPU load and frequent
interrupts e.g. moving some window during test. Mostly I used the "python -m
test --fail-env-changed test_multiprocessing_spawn -m 'WithProcessesTestS[hu]*'
-F" command to reproduce the crash.
By analyzing core dumps I deduced that the crash happens during this call from
the parent test process:
class BaseManager(object):
def _finalize_manager(process, address, authkey, state, _Client):
...
try:
conn = _Client(address, authkey=authkey)
try:
dispatch(conn, None, 'shutdown')
finally:
conn.close()
except Exception:
pass
Main thread in the multiprocessing child:
class Server(object):
def serve_forever(self):
...
try:
accepter = threading.Thread(target=self.accepter)
accepter.daemon = True
accepter.start()
try:
while not self.stop_event.is_set():
self.stop_event.wait(1)
except (KeyboardInterrupt, SystemExit):
pass
finally:
...
sys.exit(0) << main thread have finished and destroyed the
interpreter
Worker thread in the multiprocessing child.
Locals:
File "/usr/home/user/cpython/Lib/multiprocessing/managers.py", line 214, in
handle_request
c.send(msg)
self =
funcname = 'shutdown'
result = None
request = (None, 'shutdown', (), {})
ignore = None
args = ()
kwds = {}
msg = ('#RETURN', None)
Listing:
class Server(object):
def handle_request(self, c):
...
try:
result = func(c, *args, **kwds) << calls Server.shutdown method
except Exception:
msg = ('#TRACEBACK', format_exc())
else:
msg = ('#RETURN', result)
try:
c.send(msg) << crashes with SIGBUS in _send_bytes -> write ->
take_gil -> SET_GIL_DROP_REQUEST(tstate->interp)
except Exception as e:
try:
c.send(('#TRACEBACK', format_exc()))
except Exception:
pass
...
def shutdown(self, c):
...
try:
util.debug('manager received shutdown message')
c.send(('#RETURN', None))
except:
import traceback
traceback.print_exc()
finally:
self.stop_event.set()
Worker thread is daemonic and is not terminated during the interpreter
finalization, thus it might still be running and is terminated silently when
the process exits. The connection (c) has different implementations on several
platforms, so we cannot be sure whether the connection is closed during
shutdown or not, whether the last "c.send(msg)" blocks until the end of the
process, returns instantly, or fails inconsistently.
The error was there for a long time, but for two reasons it didn't cause much
trouble:
- the race condition is hard to trigger;
- SET_GIL_DROP_REQUEST used to ignore the errorneous state of interpreter, but
introduction of tstate->interp argument by Eric manifested SIGBUS on FreeBSD.
I haven't managed to find a nice clean test to reproduce the bug automatically.
I suggest the changes for the multiprocessing/managers.py in the attachment.
--
nosy: +shprotx
Added file: https://bugs.python.org/file48333/managers.patch
___
Python tracker
<https://bugs.python.org/issue33608>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.
Pavel Kostyuchenko added the comment: Also it might be viable to add some assertion to verify the take_gil is not called with uninitialized interpreter. I used the changes in the attachment (take_gil.assert.patch), but it produced errors during test_tracemalloc with f13c5c8b9401a9dc19e95d8b420ee100ac022208 . It happens because, during startup with invalid arguments, the interpreter is finalized with pymain_main->pymain_free->_PyRuntime_Finalize before the error is printed. However, the problem seems to be fixed for me in the last revisions of master branch, so I upload the diff against it. -- Added file: https://bugs.python.org/file48334/take_gil.assert.patch ___ Python tracker <https://bugs.python.org/issue33608> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36919] Exception from 'compile' reports a newline char not present in input
Pavel Koneski added the comment: If "equivalent input" is acceptable, then it looks like case B: other implementations possibly having different forms of equivalent input. I am going to post this question on python-dev. -- versions: +Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.org/issue36919> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36919] Exception from 'compile' reports a newline char not present in input
Change by Pavel Koneski : -- versions: -Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.org/issue36919> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36919] Exception from 'compile' reports a newline char not present in input
Pavel Koneski added the comment: > I'm assuming the real issue is wanting to make IronPython pass as much of the > CPython test suite as possible. This is indeed the case. The CPython test suite is invaluable in guiding IronPython development. Most of the time, the tests are pretty good to gloss over implementation artifacts (usually error messages), so that they work for IronPython as well, despite some differences between CPython and IronPython. There are a few cases, however, when the tests expect behavior that is implementation-specific and difficult to match in IronPython, or is proper Python but impossible to match for IronPython. For all such cases I would like to submit patches to the CPython repo, but I am new to this process. Should such case first be reported on bpo, python-dev, or just straight a github PR? Sometimes, by writing additional tests for IronPython we discover what seems as possible bugs in CPython. I was planning to submit reports for them on bpo, assuming this is the proper place to discuss them, but perhaps python-dev is a better place. > So fixing the tests to allow it either way sounds good. A github PR is on its way. -- ___ Python tracker <https://bugs.python.org/issue36919> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36919] Exception from 'compile' reports a newline char not present in input
Change by Pavel Koneski : -- keywords: +patch pull_requests: +13535 stage: -> patch review pull_request: https://github.com/python/cpython/pull/13639 ___ Python tracker <https://bugs.python.org/issue36919> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37416] If threading is not imported from the main thread it sees the wrong thread as the main thread.
Change by Pavel Minaev : -- nosy: +int19h ___ Python tracker <https://bugs.python.org/issue37416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37416] If threading is not imported from the main thread it sees the wrong thread as the main thread.
Pavel Minaev added the comment: This is a bit tricky to explain... There's no easy way to achieve this effect "normally". It manifests due to the way some Python debuggers (specifically, pydevd and ptvsd - as used by PyCharm, PyDev, and VSCode) implement non-cooperative attaching to a running Python process by PID. A TL;DR take is that those debuggers have to inject a new thread into a running process from the outside, and then run some Python code on that thread. There are OS APIs for such thread injection - e.g. CreateRemoteThread on Windows. There are various tricks that they then have to use to safely acquire GIL and invoke PyEval_InitThreads, but ultimately it comes down to running Python code. That is the point where this can manifest. Basically, as soon as that injected code (i.e. the actual debugger) imports threading, things break. And advanced debuggers do need background threads for some functionality... Here are the technical details - i.e. how thread injection happens exactly, and what kind of code it might run - if you're interested. https://github.com/microsoft/ptvsd/issues/1542 I think that a similar problem can also occur in an embedded Python scenario with multithreading. Consider what happens if the hosted interpreter is initialized from the main thread of the host app - but some Python code is then run from the background thread, and that code happens to be the first in the process to import threading. Then that background thread becomes the "main thread" for threading, with the same results as described above. The high-level problem, I think, is that there's an inconsistency between what Python itself considers "main thread" (i.e. main_thread in ceval.c, as set by PyEval_InitThreads), and what threading module considers "main thread" (i.e. _main_thread in threading.py). Logically, these should be in sync. If PyEval_InitThreads is the source of truth, then the existing thread injection technique will "just work" as implemented already in all the aforementioned debuggers. It makes sure to invoke PyEval_InitThreads via Py_AddPendingCall, rather than directly from the background thread, precisely so that the interpreter doesn't get confused. Furthermore, on 3.7+, PyEval_InitThreads is already automatically invoked by Py_Initialize, and hence when used by python.exe, will mark the actual first thread in the process as the main thread. So, using it a the source of truth would guarantee that attach by thread injection works correctly in all non-embedded Python scenarios. Apps hosting Python would still need to ensure that they always call Py_Initialize on what they want to be the main thread, as they already have to do; but they wouldn't need to worry about "import threading" anymore. -- ___ Python tracker <https://bugs.python.org/issue37416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37416] If threading is not imported from the main thread it sees the wrong thread as the main thread.
Pavel Minaev added the comment: It's also possible to hit if using some native code that starts a background thread without going via threading, and runs Python code on that background thread. In that case, if that Python code then does "import threading", and threading hasn't been imported yet, then you have this same problem. Here's a pure Python repro using ctypes on Win32: #-- import sys, time from ctypes import * ThreadProc = WINFUNCTYPE(c_uint32, c_void_p) @ThreadProc def thread_proc(_): import threading print(threading.current_thread() is threading.main_thread()) return 0 assert "threading" not in sys.modules #import threading # uncomment to fix windll.kernel32.CreateThread(None, c_size_t(0), thread_proc, None, c_uint32(0), None) time.sleep(1) assert "threading" in sys.modules import threading print(threading.current_thread() is threading.main_thread()) #-- Here's the output: >py -3 main.py True False Exception ignored in: Traceback (most recent call last): File "C:\Python\3.7-64\lib\threading.py", line 1276, in _shutdown assert tlock.locked() AssertionError: -- ___ Python tracker <https://bugs.python.org/issue37416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37416] If threading is not imported from the main thread it sees the wrong thread as the main thread.
Pavel Minaev added the comment: Debuggers will have to work around this in past Python versions that they support (which still includes Python 2 for pretty much all of them), so this is solely about resolving the inconsistency for the future. No point rushing it for 3.8 specifically. (The most likely immediate workaround will be that, instead of invoking PyEval_InitThreads on the main thread via Py_AddPendingCall, we will simply use the same facility to exec "import threading" on the main thread.) -- ___ Python tracker <https://bugs.python.org/issue37416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35447] Redundant try-except block in urllib
New submission from Shishmarev Pavel : https://github.com/python/cpython/blob/master/Lib/urllib/parse.py#L875 It's redundant to raise and then catch exception. -- components: Library (Lib) messages: 331436 nosy: PashaWNN priority: normal severity: normal status: open title: Redundant try-except block in urllib type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35447> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35447] Redundant try-except block in urllib
Change by Shishmarev Pavel : -- keywords: +patch pull_requests: +10287 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35447> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35447] Redundant try-except block in urllib
Change by Shishmarev Pavel : -- pull_requests: +10288 ___ Python tracker <https://bugs.python.org/issue35447> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35447] Redundant try-except block in urllib
Shishmarev Pavel added the comment:
https://github.com/python/cpython/blob/master/Lib/urllib/parse.py#L875
It's redundant to raise and then catch exception.
I mean:
if len(query) and not isinstance(query[0], tuple):
ty, va, tb = sys.exc_info()
raise TypeError("not a valid non-string sequence "
"or mapping object").with_traceback(tb)
Would be more clean.
--
___
Python tracker
<https://bugs.python.org/issue35447>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36919] Exception form 'compile' reports a newline char not present in input
New submission from Pavel Koneski :
Since Python 3.2, input in 'exec' mode of 'compile' does not have to end in a
newline anymore. However, it creates a surprising behavior when a 'SyntaxError'
is reported:
>>> try: compile('try', '', 'exec')
... except SyntaxError as ex: print(repr(ex))
...
SyntaxError('invalid syntax', ('', 1, 4, 'try\n'))
The 'text' field of the exception thrown contains an additional newline
character that was not present in the input. Is it:
a. Proper Python language behavior?
b. CPython implementation artifact?
c. A bug?
In case of:
a. I will submit a patch to IronPython, which does not add an extra newline at
the moment.
b. I can submit a patch to CPython to make StdLib tests implementation
independent.
c. This inquiry can serve as a bug report.
--
components: Interpreter Core
messages: 342515
nosy: BCSharp
priority: normal
severity: normal
status: open
title: Exception form 'compile' reports a newline char not present in input
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue36919>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32919] csv.reader() to support QUOTE_ALL
New submission from Pavel Shpilev : It appears that in current implementation csv.QUOTE_ALL has no effect on csv. reader(), it only affects csv.writer(). I know that csv is a poorly defined format and all, but I think this might be useful to distinguish None and '' values for the sources that use such quoting. Example: "1","Noneval",,"9" "2","Emptystr","","10" "3","somethingelse","","8" Reader converts all values in the third column to empty strings. The suggestion is to adjust reader's behaviour so when quoting=csv.QUOTE_ALL that would instruct reader to convert empty values (like the one in the first row) to None instead. -- components: Extension Modules messages: 312617 nosy: Pavel Shpilev priority: normal severity: normal status: open title: csv.reader() to support QUOTE_ALL type: enhancement versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue32919> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32919] csv.reader() to support QUOTE_ALL
Pavel Shpilev added the comment: I know that CSV specification says empty field and empty string are the same, however, I still believe there is practical use for unconventional processing of such fields. In our specific case we parse CSVs produced by Amazon Athena (based on Presto) in which NULL and empty string values represented as above. Following CSV specs dogmatically, there's no way to distinguish between the two, but pragmatically you can tell them apart by simply looking at values. Brief search shows we aren't the only ones facing the issue. After giving it some more thought, I'd agree that csv.QUOTE_ALL doesn't make much sense here, but may be an extra argument to csv.reader() will do the trick? Something like csv.reader(detect_none_values=False/True), with False being default, and emphasis in the documentation that True goes against CSV specification. -- ___ Python tracker <https://bugs.python.org/issue32919> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14102] argparse: add ability to create a man page
Change by Pavel Raiskup : -- nosy: +Pavel Raiskup ___ Python tracker <https://bugs.python.org/issue14102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14102] argparse: add ability to create a man page
Pavel Raiskup added the comment: On Friday, June 15, 2018 1:52:41 AM CEST Ben Finney wrote: > On Thu, 2018-06-14 23:46 +, Aaron Meurer wrote: > > Couldn't such a tool exist outside the standard library. > > I've tried writing such a tool. It would ideally re-use as much as feasible of > the functionality that assembles the usage message. FWIW, I followed you and andialbrecht's solution, and did some changes to the code (now the code is in PyPi as argparse-manpage). Feel free to take what's considered useful. > So this bug report asks for that work to be done in the ‘argparse’ library. Agreed. > > Installing the manpage is a separate concern. > > Yes, I agree. That is not part of this bug report. I think installation is valid concern; so it should be tracked somewhere. -- ___ Python tracker <https://bugs.python.org/issue14102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14102] argparse: add ability to create a man page
Pavel Raiskup added the comment: On Friday, June 15, 2018 11:54:04 AM CEST Daniel Walsh wrote: > Correct, the reason I would want this is to add something to a Makefile > ... > manpages: foo.py > ./python foo.py --manpage > foo.1 The /bin/argparse-manpage could help temporarily (if you don't mind the additional build-dep). -- ___ Python tracker <https://bugs.python.org/issue14102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34129] CGITB does not mangle variables names
New submission from Pavel Jurkas : CGITB does not mangle private variables names. So they are displayed as undefined even though they are defined. Example: self.__core undefined -- messages: 321757 nosy: pjurkas priority: normal severity: normal status: open title: CGITB does not mangle variables names ___ Python tracker <https://bugs.python.org/issue34129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34129] CGITB does not mangle variables names
Change by Pavel Jurkas : -- keywords: +patch pull_requests: +7835 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34129] CGITB does not mangle variables names
Pavel Jurkas added the comment: https://github.com/python/cpython/pull/8301 -- ___ Python tracker <https://bugs.python.org/issue34129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34129] CGITB does not mangle variables names
Change by Pavel Jurkas : -- pull_requests: +7836 ___ Python tracker <https://bugs.python.org/issue34129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34129] CGITB does not mangle variables names
Pavel Jurkas added the comment: https://github.com/python/cpython/pull/8302 -- ___ Python tracker <https://bugs.python.org/issue34129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34129] CGITB does not mangle variables names
Pavel Jurkas added the comment: https://github.com/python/cpython/pull/8304 -- ___ Python tracker <https://bugs.python.org/issue34129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34129] CGITB does not mangle variables names
Change by Pavel Jurkas : -- pull_requests: +7838 ___ Python tracker <https://bugs.python.org/issue34129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14710] pkgutil.get_loader is broken
New submission from Pavel Aslanov :
if module was marked as not existing by setting sys.modules [fullname] to None,
then pkgutil.get_loader (fullname) will throw AttributeError.
Example:
#! /usr/bin/evn python
import unittest
import pkgutil
def main ():
pkgutil.get_loader ('unittest.functools')
if __name__ == '__main__':
main ()
Patch is attached
--
components: Library (Lib)
files: python_pkgutil_bug.patch
keywords: patch
messages: 159848
nosy: Pavel.Aslanov
priority: normal
severity: normal
status: open
title: pkgutil.get_loader is broken
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file25442/python_pkgutil_bug.patch
___
Python tracker
<http://bugs.python.org/issue14710>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14710] pkgutil.get_loader is broken
Pavel Aslanov added the comment: Main use case of pkgutil.get_loader is to determine if its possible to load module and either return loader or None. But it throws exception more over it is AttributeErrror exception. -- ___ Python tracker <http://bugs.python.org/issue14710> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15073] commands.getoutput() is broken
New submission from Pavel Fedin :
commands.getoutput() is broken on Windows. The issue has been detected in
v2.7.2, but still persists in v2.7.3:
--- cut ---
Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import commands;
>>> print commands.getoutput("dir");
'{' is not recognized as an internal or external command,
operable program or batch file.
>>>
--- cut ---
The error message comes from cmd.exe. Looks like Python tries to feed native
Windows shell with UNIX-style commands sequence in {...}.
I believe this is very simple to fix, please take a look at it. Some our
internal software croaks because of this.
--
components: Windows
messages: 162844
nosy: p.fedin
priority: normal
severity: normal
status: open
title: commands.getoutput() is broken
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue15073>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15073] commands.getoutput() does not work on windows
Pavel Fedin added the comment: I see it's deprecated and dropped, but anyway, why not to fix it to work on Windows? From 10197 i see the fix is quite simple, and there is lots of legacy code i believe. -- ___ Python tracker <http://bugs.python.org/issue15073> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16050] ctypes: callback from C++ to Python fails with Illegal Instruction call
New submission from Pavel Maltsev: ppc_405, Linux 2.4, GCC 3.3.1 Python crashes on attempt to pass python callback function to custom C++ library under PowerPC 405. This happens because some versions of GCC (I guess below 4.1) doesn't raise __NO_FPRS__ flag if hard-floats is not supported, instead they use _SOFT_FLOAT. So we need to change #ifndef __NO_FPRS__ to #if (!defined(__NO_FPRS__) && !defined(_SOFT_FLOAT)) -- components: ctypes files: soft_float.patch keywords: patch messages: 171325 nosy: Opilki_Inside priority: normal severity: normal status: open title: ctypes: callback from C++ to Python fails with Illegal Instruction call type: crash versions: Python 2.7 Added file: http://bugs.python.org/file27309/soft_float.patch ___ Python tracker <http://bugs.python.org/issue16050> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14710] pkgutil.get_loader is broken
Pavel Aslanov added the comment:
This function is broken again in version 3.4
The way it should look is:
Python 2.7.6 (default, Feb 26 2014, 12:07:17)
[GCC 4.8.2 20140206 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkgutil
>>> pkgutil.get_loader('no_such_module') # returns None
>>>
How it really looks:
Python 3.4.0 (default, Apr 27 2014, 23:33:09)
[GCC 4.8.2 20140206 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkgutil
>>> pkgutil.get_loader('no_such_module')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.4/pkgutil.py", line 467, in get_loader
return find_loader(fullname)
File "/usr/lib/python3.4/pkgutil.py", line 488, in find_loader
return spec.loader
AttributeError: 'NoneType' object has no attribute 'loader'
>>>
find_loader is at fault (change "return spec.loader" -> "return spec and
spec.loader"). Thanks.
--
___
Python tracker
<http://bugs.python.org/issue14710>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5575] Add env vars for controlling building sqlite, hashlib and ssl
Pavel Machyniak added the comment: Unfortunately this patch will not work if there is other (system) openssl installed in the default locations (`/usr/include`, `/usr/lib`) because this patch only add another path at the end of the search list. Instead of this I will make a ticket for providing configuration option for controlling the `openssl` (`--with-ssl=PATH`) and I will propose the solution (patch for current `configure` and `setup.py`). This way the user can explicitly provide the path for `openssl` and there is no need to search for one. I think it is important to fix this because there is a lot of people having problem compiling `python` with custom `openssl`, eg.: [http://stackoverflow.com/questions/22409092/coredump-when-compiling-python-with-a-custom-openssl-version] -- nosy: +machyniak ___ Python tracker <http://bugs.python.org/issue5575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21541] Provide configure option --with-ssl for compilation with custom openssl
New submission from Pavel Machyniak: There is no easy way to build python with custom openssl build. This can lead to miscellaneous problems (like segmentation faults) in various situations/configurations (see eg. http://stackoverflow.com/questions/22409092/coredump-when-compiling-python-with-a-custom-openssl-version). The problems usually arise when different version of openssl headers and libs are used, or when different versions of openssl is required within one process (eg. using python within apache httpd process (mod_wsgi or mod_python) + some other module that uses explicitly updated/newer/incompatible version of openssl). The best way to workaround this problem would be to have the clear way how to build python with specific openssl version. The best way would by to use configure options --with-ssl=PATH optionally with --with-ssl-includes=PATH and --with-ssl-libs=PATH. In this case, setup.py shall not search for openssl but shall use the explicitly specified one. I will shortly provide the patch for the current version of configure and setup.py. See related issues: - http://bugs.python.org/issue5575 - http://bugs.python.org/issue16660 -- components: Build messages: 218844 nosy: machyniak priority: normal severity: normal status: open title: Provide configure option --with-ssl for compilation with custom openssl type: enhancement versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue21541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21541] Provide configure option --with-ssl for compilation with custom openssl
Pavel Machyniak added the comment: This is the proposed patch (compared 2 trees src & upd where src is latest release 3.4.1, upd is my working). Changes are in: configure, setup.py. Please review it and hopefully integrate to future releases. -- keywords: +patch versions: +Python 3.4 -Python 3.5 Added file: http://bugs.python.org/file35304/issue21541-patch.diff ___ Python tracker <http://bugs.python.org/issue21541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
