[issue28698] Python 3.x ctypes c_wchar_p return is different from official documentation example

[Louie Lu]

Changes by Louie Lu :


--
pull_requests: +1289

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30079] Explain why it is recommended to pass args as a string rather than as a sequence If shell is True

[Eryk Sun]

Eryk Sun added the comment:

In Unix, passing an args list with shell=True makes the first element the -c 
command. The remaining elements are arguments for the shell itself, which makes 
them $N variables. For example:

>>> subprocess.call(['echo $0, $1', 'spam', 'eggs'], shell=True)
spam, eggs

In Windows, subprocess.list2cmdline assumes VC++ rules for creating a command 
line from a list. cmd's parsing rules are very different -- e.g. '^' is the 
escape character, and double quotes also escape special characters, except not 
'%'. (Shockingly there is no way to escape '%' on the cmd.exe command line -- 
only in batch files by doubling it. If you think '^' escapes it, you're wrong. 
cmd looks for an environment variable containing the '^' character. By luck 
it's usually not found.) cmd's parsing is convoluted, to say the least. Now 
combine that with having to pass command lines for external programs in way 
that they survive cmd's parsing without also breaking how the external program 
parses its command line. This problem is intractable. Just use a string. For 
anything complicated you may have to experiment a few times to figure out some 
permutation that works. The best option is to not use the shell at all.

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19184] dis module has incorrect docs for RAISE_VARARGS

[Louie Lu]

Changes by Louie Lu :


--
pull_requests: +1288

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30079] Explain why it is recommended to pass args as a string rather than as a sequence If shell is True

[R. David Murray]

R. David Murray added the comment:

Because passing a sequence to shell=True won't work on unix.  It only works 
more-or-less by accident on windows, even though the current docs kind of 
encourage it.  Yes, I think it would be good if these sentences were clarified.

See also issue 7839.

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30079] Explain why it is recommended to pass args as a string rather than as a sequence If shell is True

[Philip Lee]

New submission from Philip Lee:

The doc here 
https://docs.python.org/3/library/subprocess.html#subprocess.Popen
says :
"If shell is True, it is recommended to pass args as a string rather than as a 
sequence."
but without explain why ? Please add the explanation !
while in
https://docs.python.org/3/library/subprocess.html#frequently-used-arguments
says:
"args is required for all calls and should be a string, or a sequence of 
program arguments. Providing a sequence of arguments is generally preferred, as 
it allows the module to take care of any required escaping and quoting of 
arguments (e.g. to permit spaces in file names). If passing a single string, 
either shell must be True (see below) or else the string must simply name the 
program to be executed without specifying any arguments."

In the case of shell =True ,  I found providing a sequence of arguments  rather 
than  a string argument can take the advantage of auto escaping and quoting of 
arguments (e.g. to permit spaces in file names) , so what is the advantage of 
pass args as a string rather than as a sequence as says in the doc when shell 
is True?

--
assignee: docs@python
components: Documentation
messages: 291733
nosy: docs@python, iMath
priority: normal
severity: normal
status: open
title: Explain why it is recommended to pass args as a string rather than as a 
sequence If shell is True
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30075] Printing ANSI Escape Sequences on Windows 10

[Eryk Sun]

Eryk Sun added the comment:

cmd.exe enables virtual terminal mode, but only for itself. It disables VT mode 
before starting other programs, and also at shutdown. It appears you've found a 
bug in the case of "cmd.exe /c ...". You can get the same result via 
os.system(''). It's failing to disable VT mode after it exits.

Enabling VT mode by default is potentially a problem because a console  
buffer's mode is shared, inherited state. Adding a set_console_mode method on 
console files would be a useful convenience to manage this state. There could 
also be a couple IntFlag enums for the available input and output mode values. 

Here's some code to enable VT mode in Windows 10 -- assuming you're not using 
the legacy console. If you're using an older version of Windows, or the legacy 
console in Windows 10, then enabling VT mode will fail as an invalid parameter. 
This is handled by raising NotImplementedError. On success, it returns the 
previous console mode, which can be restored by calling set_conout_mode(mode). 
Depending on your needs, that could done in an atexit function.

import os
import msvcrt
import ctypes

from ctypes import wintypes

kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

ERROR_INVALID_PARAMETER = 0x0057
ENABLE_VIRTUAL_TERMINAL_PROCESSING = 0x0004

def _check_bool(result, func, args):
if not result:
raise ctypes.WinError(ctypes.get_last_error())
return args

LPDWORD = ctypes.POINTER(wintypes.DWORD)
kernel32.GetConsoleMode.errcheck = _check_bool
kernel32.GetConsoleMode.argtypes = (wintypes.HANDLE, LPDWORD)
kernel32.SetConsoleMode.errcheck = _check_bool
kernel32.SetConsoleMode.argtypes = (wintypes.HANDLE, wintypes.DWORD)

def set_conout_mode(new_mode, mask=0x):
# don't assume StandardOutput is a console.
# open CONOUT$ instead
fdout = os.open('CONOUT$', os.O_RDWR)
try:
hout = msvcrt.get_osfhandle(fdout)
old_mode = wintypes.DWORD()
kernel32.GetConsoleMode(hout, ctypes.byref(old_mode))
mode = (new_mode & mask) | (old_mode.value & ~mask)
kernel32.SetConsoleMode(hout, mode)
return old_mode.value
finally:
os.close(fdout)

def enable_vt_mode():
mode = mask = ENABLE_VIRTUAL_TERMINAL_PROCESSING
try:
return set_conout_mode(mode, mask)
except WindowsError as e:
if e.winerror == ERROR_INVALID_PARAMETER:
raise NotImplementedError
raise

Please don't use the code in issue 29059. It's simpler, but there are several 
problems with it. (1) There's no error handling. (2) It passes handles 
incorrectly as 32-bit int values, for which ctypes in 64-bit Python 2 may 
corrupt the high DWORD (if it works, it's only by accident; ctypes doesn't zero 
the stack in ffi_prep_args). (3) It assumes the StandardOutput handle is a 
console output buffer, but maybe it's a pipe or file, and the program has 
manually opened CONOUT$ to write debug text in color. (4) It uses windll, which 
causes problems when multiple libraries contend for the same functions (e.g. 
some library may have set incompatible argtypes, restype, or errcheck values on 
windll.kernel32.GetConsoleMode).

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30075] Printing ANSI Escape Sequences on Windows 10

[Martin Panter]

Martin Panter added the comment:

Maybe this is related to Issue 29059. If so, there seems to be resistance to 
enabling the feature by default, and preference to use existing APIs rather 
than adding a new API that enables it.

--
components: +Windows
nosy: +martin.panter, paul.moore, steve.dower, tim.golden, zach.ware
superseder:  -> Windows: Python not using ANSI compatible console

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30078] "-m unittest --help" says nothing about direct script exection

[R. David Murray]

R. David Murray added the comment:

Agreed that it looks like another example line should be added to the help for 
this case.

--
nosy: +r.david.murray
stage:  -> needs patch
versions: +Python 3.7 -Python 3.3, Python 3.4, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30078] "-m unittest --help" says nothing about direct script exection

[Ilya Kazakevich]

New submission from Ilya Kazakevich:

In Py3 it is possible to run test filelike 
"python -m unittest tests/test_something.py" (it is *not* possible in Py2!)
Here is doc: https://docs.python.org/3/library/unittest.html

But "--help" seems to be simply copied from Py2 because it does not have 
information nor examples about such execution. 

Please add it to "examples" section at least because this type of usage is very 
useful.

--
assignee: docs@python
components: Documentation
messages: 291729
nosy: Ilya Kazakevich, docs@python
priority: normal
severity: normal
status: open
title: "-m unittest --help" says nothing about direct script exection
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30071] Duck-typing inspect.isfunction()

[Terry J. Reedy]

Terry J. Reedy added the comment:

inspect.getargspec is deprecated in favor of .getfullargspec and .signature and 
is implemented in with .getfullargspec.  This, in turn, calls 
._signature_from_callable which ultimately looks for (perhaps after recursive 
unwrap calls) obj.__signature__.  So I expect that the case you 'care most 
about' already works.  True?

It appears that .signature is intended to work for cython functions via the 
following helper function. Its code is somewhat awkward and tests that the 
object has needed attributes with needed types.

def _signature_is_functionlike(obj):
"""Private helper to test if `obj` is a duck type of FunctionType.
A good example of such objects are functions compiled with
Cython, which have all attributes that a pure Python function
would have, but have their code statically compiled.
"""

That does leave cases like the inspect.getfile code you quoted.  It could be 
fixed with some fiddly code, but there would still be .getclosurevariables and 
a couple of other uses of isfunction to review.

I reviewed the function and code attributes listed in
https://docs.python.org/3/library/inspect.html#types-and-members
and I think the necessary differences a function compiled by CPython and 
anything else are limited to the code object.

Proposal: for a cleaner solution, define a 'mincode' base class that lacks, for 
instance, co_code, co_consts, co_flags, co_lnotab, and co_stacksize.  Make code 
a subclass of this.  Define 'minfunction' as a function whose __code__ is a 
mincode.  Make function a subclass of this.  Define 'isminfunction' and replace 
'isfunction' where a mincode is sufficient.  This might allow, for instance, 
_signature_is_functionlike to be removed.

Details should perhaps be specified in a relatively short PEP.  Discussion 
could maybe continue on python-ideas.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30077] Support Apple AIFF-C pseudo compression in aifc.py

[Toby Thurston]

Changes by Toby Thurston :


--
pull_requests: +1287

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30077] Support Apple AIFF-C pseudo compression in aifc.py

[Toby Thurston]

New submission from Toby Thurston:

aifc.py fails to open AIFF files containing the compression type "sowt" in the 
COMM chunk with an "unsupported compression type" error.

This compression type is an Apple specific extension that signals that the data 
is not actually compressed but is stored uncompressed in little Endian order.  

Supporting it would require a trivial change to allow the compression type as a 
byte-string and to add a do-nothing _convert routine. 

This would allow aifc.py to be used with AIFF files on Apple macOS.

--
components: Extension Modules
messages: 291727
nosy: thruston
priority: normal
severity: normal
status: open
title: Support Apple AIFF-C pseudo compression in aifc.py
type: enhancement
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29021] Custom functions in sqlite receive None on invalid UTF-8

[Aviv Palivoda]

Aviv Palivoda added the comment:

In my patch I use sqlite3_create_function_v2 which was added in sqlite 3.7.3 
(2010-10-08). There were a few problems after adding sqlite3_stmt_readonly in 
284676cf2ac8 as can be seen in issue #29355. sqlite3_stmt_readonly was added in 
3.7.4 (2010-12-07) so I guess using sqlite3_create_function_v2 will cause the 
same problems.

Do you think I should find another way to fix this issue? I can follow all the 
user functions and free on my own but that will make the code more complex. On 
the other hand I can add this fix in ifdef and the behavior will be different 
when using sqlite in versions smaller then 3.7.3.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30076] Opcode names BUILD_MAP_UNPACK_WITH_CALL and BUILD_TUPLE_UNPACK_WITH_CALL are too long

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Two new opcodes BUILD_MAP_UNPACK_WITH_CALL and BUILD_TUPLE_UNPACK_WITH_CALL 
(added in 3.5 and 3.6) have too long names (26 and 28 characters). This exceeds 
the width of the opcode names in the dis module (20 characters). Increasing the 
width of the column will make opcode arguments too distant from opcode names, 
that will decrease readability. The better solution would be renaming these two 
opcodes.

They are used for merging iterables and mappings of positional and keyword 
arguments when used var-positional (*args) and var-keyword (**kwargs) 
arguments. Maybe new names should reflect this.

>>> dis.dis('f(a, b, *args, x=x, y=y, **kw)')
  1   0 LOAD_NAME0 (f)
  2 LOAD_NAME1 (a)
  4 LOAD_NAME2 (b)
  6 BUILD_TUPLE  2
  8 LOAD_NAME3 (args)
 10 BUILD_TUPLE_UNPACK_WITH_CALL 2
 12 LOAD_NAME4 (x)
 14 LOAD_NAME5 (y)
 16 LOAD_CONST   0 (('x', 'y'))
 18 BUILD_CONST_KEY_MAP  2
 20 LOAD_NAME6 (kw)
 22 BUILD_MAP_UNPACK_WITH_CALL 2
 24 CALL_FUNCTION_EX 1
 26 RETURN_VALUE

--
messages: 291725
nosy: ncoghlan, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Opcode names BUILD_MAP_UNPACK_WITH_CALL and BUILD_TUPLE_UNPACK_WITH_CALL 
are too long
type: enhancement
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30071] Duck-typing inspect.isfunction()

[Jeroen Demeyer]

Jeroen Demeyer added the comment:

For the record: the __code__ attribute of a Cython function is a real "code" 
object (the same type as the __code__ attribute of a Python function). Of 
course not all fields are relevant, for example co_code is empty.

So I think it's clear that Cython tries really hard to be compatible with 
Python functions.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30074] compile warnings of _PySlice_Unpack in 2.7

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you for pointing on this and for your review Xiang!

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30074] compile warnings of _PySlice_Unpack in 2.7

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 5e79321742cb3af2184d22e2148c6756cade1864 by Serhiy Storchaka in 
branch '2.7':
bpo-30074: Fix compile warnings of _PySlice_Unpack and convert missed (#1154)
https://github.com/python/cpython/commit/5e79321742cb3af2184d22e2148c6756cade1864


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11822] Improve disassembly to show embedded code objects

[Nick Coghlan]

Nick Coghlan added the comment:

The problem I see is that we have conflicting requirements for the default 
behaviour:

- if we modify dis() instead of adding a new function, then the default 
behaviour needs to be non-recursive for backwards compatibility reasons
- if we allow the depth to be configurable, then we'd like the default 
behaviour to be to show everything

One potential resolution to that would be to define this as a new function, 
`distree`, rather than modifying `dis` and `disassemble` to natively support 
recursion. Then the new function could accept a `depth` argument (addressing my 
concerns), but have `depth=None` as the default (addressing your concerns).

If we wanted to allow even more control than that, then I think os.walk 
provides a useful precedent, where we'd add a new `dis.walk` helper that just 
looked at `co_consts` to find nested code objects without doing any of the 
other disassembly work.

The dis.walk() helper would produce an iterable of (depth, code, nested) 
3-tuples, where:

- the first item is the current depth in the compile tree
- the second is the code object itself
- the third is a list of nested code objects

Similar to os.walk(), editing the list of nested objects in place would let you 
control whether or not any further recursion took place.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11822] Improve disassembly to show embedded code objects

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The problem with the *depth* parameter is that it adds a burden of choosing the 
value for the end user. "Oh, there are more deeper code objects, I must 
increase the depth and rerun dis()!" I think in most cases when that parameter 
is specified it would be set to some large value like 999 because you don't 
want to set it too small. Compare for example with the usage of the attribute 
maxDiff in unittests.

The single depth parameter doesn't adds too much control. You can't enable 
disassembling functions and method bodies but disable disassembling 
comprehensions in functions. If you need more control, you  should use 
non-recursive dis() and manually walk the tree of code objects.

How much output adds unlimited recursion in comparison with the recursion 
limited by the first level?

As for supporting invalid bytecode, currently the dis module doesn't support it 
(see issue26694).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30075] Printing ANSI Escape Sequences on Windows 10

[Tithen Firion]

New submission from Tithen Firion:

Windows 10 supports ANSI Escape Sequences ( 
http://stackoverflow.com/a/38617204/2428152 
https://msdn.microsoft.com/en-us/library/windows/desktop/mt638032(v=vs.85).aspx 
) but Python just prints escape character. Adding `subprocess.call('', 
shell=True)` before printing solved the issue.

Test code:

import subprocess
print('\033[0;31mTEST\033[0m')
subprocess.call('', shell=True)
print('\033[0;31mTEST\033[0m')

output in attachment.

Haven't tested it on other Python versions but it probably occurs on them too.

--
components: IO
files: example.png
messages: 291719
nosy: Tithen Firion
priority: normal
severity: normal
status: open
title: Printing ANSI Escape Sequences on Windows 10
type: behavior
versions: Python 2.7, Python 3.6
Added file: http://bugs.python.org/file46805/example.png

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30011] HTMLParser class is not thread safe

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11822] Improve disassembly to show embedded code objects

[Nick Coghlan]

Nick Coghlan added the comment:

+1 for listing the nested code objects after the original one.

In reviewing Serhiy's patch, the core technical implementation looks OK to me, 
but I think we may want to go with a "depth" argument rather than a simple 
"recursive" flag.

My rationale for that relates to directly disassembling module and class source 
code:

- dis(module_source, depth=1) # Module, class bodies, function bodies
- dis(class_source, depth=1) # Class and method bodies

(with the default depth being 0, to disable recursive descent entirely)

Only if you set a higher depth than 1 would you start seeing things like 
closures, comprehension bodies, and nested classes.

With a simple all-or-nothing flag, I think module level recursive disassembly 
would be too noisy to be useful.

The bounded depth approach would also avoid a problem with invalid bytecode 
manipulations that manage to create a loop between two bytecode objects. While 
the *compiler* won't do that, there's no guarantee that the disassembler is 
being fed valid bytecode, so we should avoid exposing ourselves to any infinite 
loops in the display code.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30011] HTMLParser class is not thread safe

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 50f948edda0e6465e194ecc50b85fa2646039b8d by Serhiy Storchaka in 
branch '2.7':
bpo-30011: Fixed race condition in HTMLParser.unescape(). (#1140)
https://github.com/python/cpython/commit/50f948edda0e6465e194ecc50b85fa2646039b8d


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30071] Duck-typing inspect.isfunction()

[Jeroen Demeyer]

Jeroen Demeyer added the comment:

> As indicated above, perfect emulation seems impossible for Cython or any 
> other external compiler that does not use the same bytecode.

True, Cython functions are not implemented using Python bytecode, so perfect 
emulation is impossible. The use case I care most about is getargspec(), which 
is fully supported by Cython functions.

> If it were possible for Cython to makes its CythonFunction class a subclass 
> of FunctionType, the issue would be 'solved', though the incompatibilities 
> would remain.

That's an interesting idea. Currently, that is simply impossible because

>>> from types import FunctionType
>>> class X(FunctionType): pass
Traceback (most recent call last):
  File "", line 1, in 
TypeError: type 'function' is not an acceptable base type

Still, one could argue to change the implementation of FunctionType. If you do 
that, it would be best to define a BaseFunctionType and then have Cython 
functions and Python functions inherit from that. Personally, I think that's an 
even better but much more involved solution (I guess it would require a PEP).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11822] Improve disassembly to show embedded code objects

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The issue was open 6 years ago. The feature could be added in 3.3. But it still 
not implemented.

Since there are problems with outputting the disassembly of internal code 
objects expanded in-line, proposed patch just outputs them after the 
disassembly of the main code object (similar to original Raymond's 
proposition). This is simpler and doesn't make the output too wide.

--
versions: +Python 3.7 -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11822] Improve disassembly to show embedded code objects

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +1286

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30034] csv reader chokes on bad quoting in large files

[Keith Erskine]

Keith Erskine added the comment:

OK Terry.  Thank you everybody for your thoughts and suggestions.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29070] Integration tests for pty.spawn on Linux and all other platforms

[Cornelius Diekmann]

Cornelius Diekmann added the comment:

Thank you Martin for your comments in the code review tool. I prepared a new 
patch for the code review tool.

The github changelog from patch v4 (Feb 2017) to my HEAD (currently patch v5, 
Apr 2017) is at:

https://github.com/python/cpython/compare/master...diekmann:wip-issue-29070?expand=1

I hope that having several micro commits instead of one huge patch is helpful. 
In the end, it will be squashed anyway. Do you prefer to continue with bpo 
patches or have a github pull request?

--
Added file: http://bugs.python.org/file46804/pty.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29378] Invalid example in documentation for PyErr_Fetch

[Kaeptm Blaubaer]

Kaeptm Blaubaer added the comment:

The error is fixed in Python 3.5.3 documentation.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27727] Update Tools/freeze to use .vcxproj files

[Kaeptm Blaubaer]

Changes by Kaeptm Blaubaer :


--
resolution:  -> duplicate

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29378] Invalid example in documentation for PyErr_Fetch

[Kaeptm Blaubaer]

Kaeptm Blaubaer added the comment:

Please don't close the bug until it is fixed in the python 3.5 documentation!

--
resolution: not a bug -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30074] compile warnings of _PySlice_Unpack in 2.7

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +1285

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22352] Ensure opcode names and args fit in disassembly output

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Proposed patch adjusts column widths of the output of dis.dis() for large line 
numbers and instruction offsets and adds tests for widths of opcode names.

Unfortunately this test is failed for two new opcodes: 
BUILD_MAP_UNPACK_WITH_CALL and BUILD_TUPLE_UNPACK_WITH_CALL (26 and 28 
characters respectively).

--
nosy: +serhiy.storchaka
stage:  -> patch review
type: behavior -> enhancement
versions: +Python 3.7 -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22352] Ensure opcode names and args fit in disassembly output

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +1284

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30011] HTMLParser class is not thread safe

[Alessandro Vesely]

Alessandro Vesely added the comment:

Serhiy's analysis is correct.  If anything more than a comment is going
to make its way to the code, I'd suggest to move dictionary building to
its own function, so that it can be called either on first use --like
now-- or before threading if the user is concerned.

I agree there is nothing wrong with multiple builds.  My point is just a
minor, bearable inefficiency.  It can be neglected.  Its most annoying
case is probably with test suites, which are more likely to shoot up a
bunch of new threads all at once.

Greetings
Ale

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30074] compile warnings of _PySlice_Unpack in 2.7

[Xiang Zhang]

New submission from Xiang Zhang:

Compile 2.7 now get many warning about _PySlice_Unpack, not in 3.x. See an 
example: 
http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%202.7/builds/109/steps/compile/logs/warnings%20%2822%29.

--
messages: 291708
nosy: serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
status: open
title: compile warnings of _PySlice_Unpack in 2.7
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19184] dis module has incorrect docs for RAISE_VARARGS

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage:  -> needs patch
versions: +Python 3.5, Python 3.6, Python 3.7 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25632] Document BUILD_*_UNPACK opcodes

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

They were documented in issue26213.

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Document BUILD_*_UNPACK opcodes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30011] HTMLParser class is not thread safe

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

There is nothing wrong with building entitydefs multiple times since the result 
is same. An alternative is using locking, but this is more cumbersome solution. 
And building entitydefs is much faster than importing the threading module.

$ ./python -m timeit -s 'from HTMLParser import HTMLParser; p = HTMLParser()' 
-- 'HTMLParser.entitydefs = None; p.unescape("")'
1000 loops, best of 3: 412 usec per loop

$ ./python -m timeit -s 'import sys; m = sys.modules.copy()' -- 'import 
threading; sys.modules.clear(); sys.modules.update(m)'
100 loops, best of 3: 5.43 msec per loop

Current solution is faster in single-thread case, correct likely fast enough in 
multi-thread case.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30071] Duck-typing inspect.isfunction()

[Terry J. Reedy]

Terry J. Reedy added the comment:

inspect.isfunction(object) is documented to
Return true if the object is a Python function, which includes functions 
created by a lambda expression.

This is currently implemented as "isinstance(object, types.FunctionType)".

The docs usually regard a 'Python function' as the result of a def statement or 
lambda expression.  The inspect doc says that a function includes a particular 
set of attributes.  One of them is a code object with its own fairly extensive 
set of attributes.  Some of them are derived from the Python code.  But others, 
in particular co_code, are specific to the current CPython bytecode version.  
(And co_code is intentionally writable.)

To me, the main purpose of checking that something is a function, as opposed to 
just being callable, is to know whether one can dependably access the 
attributes.  Given that some are inherently CPython specific, including objects 
compiled by third-party software seems dubious.  (There is also the issue of 
not being able to test with 3rd party objects.)

The referenced cython doc says
"""While it is quite possible to emulate the interface of functions in Cython’s 
own function type, and recent Cython releases have seen several improvements 
here,"""

To me, this implies to me that Cython function (compiled from Cython's extended 
def statements) do not yet perfectly emulate (fulfill) 'Python functions'.  As 
indicated above, perfect emulation seems impossible for Cython or any other 
external compiler that does not use the same bytecode.

"""the “inspect” module does not consider a Cython implemented function a 
“function”, because it tests the object type explicitly instead of comparing an 
abstract interface or an abstract base class. This has a negative impact on 
code that uses inspect to inspect function objects, but would require a change 
to Python itself."""

Where the current situation would be annoying is if working code uses 
isfunction and then Cython is used to speed up the code.  But Cython could 
supply, if it does not now, expanded functions along with the list of 
cyfunction attributes and an indication of which are compatible with CPython 
function attributes.

Cython is not the only 3rd party compiler, and not the only one that might ever 
be linkable to CPython.  So any change to CPython should not be limited to 
Cython.

If it were possible for Cython to makes its CythonFunction class a subclass of 
FunctionType, the issue would be 'solved', though the incompatibilities would 
remain.

--
nosy: +terry.reedy
stage:  -> test needed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com