[issue27141] Fix collections.UserList shallow copy

[Raymond Hettinger]

Raymond Hettinger added the comment:

Please add a test case.

--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue27137] functools.partial: Inconsistency between Python and C implementations

[Raymond Hettinger]

Raymond Hettinger added the comment:

-1 I prefer to keep the current clean, easy-to-understand, easy-to-get-right 
code which complies with the documented API.  I see no real benefit in twisting 
the code around to match non-guaranteed implementation details.

--

___
Python tracker 

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

[issue27142] Default int value with xmlrpclib / xmlrpc.client

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

XML-RPC Specification: http://xmlrpc.scripting.com/spec.html .

--
nosy: +loewis, serhiy.storchaka

___
Python tracker 

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

[issue26149] Suggest PyCharm Community as an editor for Unix platforms

[Ketan Bhatt]

Ketan Bhatt added the comment:

I would want to work on this, for 2 days. 
This is going to be my first contribution to python, please bear with me if i 
make some silly mistake.

Looking forward to your support. Thank you

--
nosy: +Ketan Bhatt

___
Python tracker 

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

[issue27043] Describe what ‘inspect.cleandoc’ does to synopsis line.

[Ben Finney]

Ben Finney added the comment:

On 27-May-2016, Nathan Harold wrote:
> 
> Split version (cleandoc2.patch):
> 
>Clean up indentation from docstrings that are indented to line up
>with blocks of code.
>
>All leading whitespace is removed from the first line. Any
>leading whitespace that can be uniformly removed from the second
>line onwards is removed. Empty lines at the beginning and end are
>subsequently removed. Also, all tabs are expanded to spaces.

That looks good to me.

--

___
Python tracker 

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

[issue27137] functools.partial: Inconsistency between Python and C implementations

[Emanuel Barry]

Emanuel Barry added the comment:

Attached patch turns the Python implementation of functools.partial into a 
class. The implementation is as close to the C version as possible, except 
__repr__ where I went for a different, more Pythonic approach (output is 
identical).

I haven't yet added tests for this, and I had to fix something (because some 
errors occur if _functools is not present and that's the only way I know to 
make the tests run against the Python implementation). One test fails with the 
patch (and sys.modules["_functools"] = None):

...E

==
ERROR: test_pickle (test.test_functools.TestPartialC)
--
Traceback (most recent call last):
  File "E:\GitHub\cpython\lib\test\test_functools.py", line 224, in test_pickle
f_copy = pickle.loads(pickle.dumps(f, proto))
_pickle.PicklingError: Can't pickle : it's not the sa
me object as functools.partial

--
Ran 148 tests in 0.216s

FAILED (errors=1)

I'll try to see what kind of tests I can add to this to reliably test both 
'partial' implementations. I'll also see what I can do about that one failing 
test. Oddly enough, there seems to be a test for subclassing 
'_functools.partial', which I might extend.

Raymond, what do you think?

--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file43035/functools_partial_1.patch

___
Python tracker 

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

[issue26553] Write HTTP in uppercase

[Martin Panter]

Martin Panter added the comment:

Thankyou Nathan, and also Anish & Aatish.

For the record, it is normally enough to do a patch against the latest (3.6), 
and any minor conflicts can be sorted out when applying it to 3.5. In this case 
the 3.5 and 3.6 patches were basically the same. But the separate patch for 2.7 
was very helpful, because there are so many differences between 2 and 3.

--
resolution:  -> fixed
stage: patch review -> 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

[issue26553] Write HTTP in uppercase

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4275181c4229 by Martin Panter in branch '3.5':
Issue #26553: Capitalization of HTTP, HTTPS, FTP, and URL
https://hg.python.org/cpython/rev/4275181c4229

New changeset 8c92ebcca83f by Martin Panter in branch 'default':
Issue #26553: Merge capitalization from 3.5
https://hg.python.org/cpython/rev/8c92ebcca83f

New changeset d914d681b7f3 by Martin Panter in branch '2.7':
Issue #26553: Capitalization of HTTP, HTTPS, FTP, and URL
https://hg.python.org/cpython/rev/d914d681b7f3

--
nosy: +python-dev

___
Python tracker 

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

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

[Martin Panter]

Martin Panter added the comment:

Strictly speaking, Python 2.7 never had special support for RTLD_MEMBER or 
find_library(). That is why I am unsure about many of these changes being done 
in 2.7. They seem more like new features than bug fixes. Especially once you 
start talking about a smart CDLL() that tests for a file and then falls back to 
RTLD_MEMBER.

Whether you represent an archive member as an (archive, member) tuple, or as an 
"archive(member)" string, or something else, it is still an extension of the 
API of CDLL(), and arguably also of find_library().

I think I have already tried to explain that on Linux, find_library("libm.so") 
is far from normal usage (although may be technically legal if there was a 
library called liblibm.so.so).

Also, on Linux I wouldn’t recommend CDLL("libcrypt.so"), which relies on a file 
only intended for build time. On Debian, the glibc library 
 has separate packages for 
shared libraries (libc6) and development libraries (libc6-dev). It should be 
possible to run programs with libc6 installed, but without libc6-dev. Looking 
at the file lists for “i386” architecture, libc6-dev includes:

/usr/lib/i386-linux-gnu/libcrypt.a
/usr/lib/i386-linux-gnu/libcrypt.so

It symbolically links to /lib/i386-linux-gnu/libcrypt.so.1, which is provided 
by libc6:

/lib/i386-linux-gnu/libcrypt-2.19.so
/lib/i386-linux-gnu/libcrypt.so.1

So on Debian (and with Linux in general), CDLL("libcrypt.so") may work in some 
cases, but you should normally use CDLL("libcrypt.so.1") instead.

Usually people just upload a new version of the original patch (original 
changes, plus new changes, in one file). I think it would be too confusing 
looking at differences between two patches.

--

___
Python tracker 

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

[issue26083] ValueError: insecure string pickle in subprocess.Popen on Python 2

[Alok Singhal]

Alok Singhal added the comment:

I think there is a small problem with the fix in changeset 268d13c7e939 
(msg258029).  It copies the string from the return value of _eintr_retry_call() 
twice.  I am attaching a trivial fix.

--
keywords: +patch
nosy: +AlokSinghal
Added file: http://bugs.python.org/file43034/subprocess.patch

___
Python tracker 

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

[issue20699] Document that binary IO classes work with bytes-likes objects

[Roundup Robot]

Roundup Robot added the comment:

New changeset bd41151a7429 by Martin Panter in branch '3.5':
Issue #20699: Document that “io” methods accept bytes-like objects
https://hg.python.org/cpython/rev/bd41151a7429

New changeset c1b40a29dc7a by Martin Panter in branch 'default':
Issue #20699: Merge io bytes-like fixes from 3.5
https://hg.python.org/cpython/rev/c1b40a29dc7a

--
nosy: +python-dev

___
Python tracker 

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

[issue27143] python 3.5 conflict with Mailman, ebtables and firewalld

[Rubén Rivero Capriles]

Rubén Rivero Capriles added the comment:

# whereis python
python: /usr/bin/python 
/usr/bin/python2.7 
/usr/bin/python2.7-config 
/usr/lib/python2.7 
/usr/lib64/python2.7 
/etc/python 
/usr/local/bin/python3.5-config 
/usr/local/bin/python3.5m-config 
/usr/local/bin/python3.5m 
/usr/local/bin/python3.5 
/usr/local/lib/python3.5 
/usr/include/python2.7 
/usr/share/man/man1/python.1.gz

--

___
Python tracker 

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

[issue20699] Document that binary IO classes work with bytes-likes objects

[Martin Panter]

Martin Panter added the comment:

Porting this to Python 2 uncovered a few flaws that I am unsure how to best 
handle. In this patch I have added workarounds, but perhaps we can find better 
fixes.

1. The io.BytesIO.write() C implementation does not accept array.array() 
objects. I suspect it only accepts objects implementing the “new” memoryview() 
buffer protocol, and array() only implements the “old” buffer() protocol.

In Python 2, is array.array() considered a bytes-like object? If so, the 
proposed update to the write() documentation is not consistent. Perhaps it is a 
real bug to fix in the BytesIO implementation. Or is test_array_writes() just 
going too far for Python 2?

I added code to skip the relevant test in test_array_writes(). Maybe it would 
be simplest to document that in general, BufferedIOBase.write() only has to 
accept “new” memoryview()-able objects.

2. The _pyio.BufferedIOBase.readinto() native Python implementation cannot 
assign into arbitrary bytes-like objects. Python 2 does not have 
memoryview.cast("B"), buffer() objects seem to be read-only, and I can’t think 
of any other easy way.

I reverted back to only testing native Python readinto() methods with 
bytearray(). But perhaps it would be best to document that for Python 2, only 
memoryview()-able arrays of bytes are acceptable, which should be practical to  
handle in native Python code.

3. The _pyio.BytesIO.write() and BufferedWriter.write() native Python 
implementations did not handle obscure bytes-like objects well. I added 
buffer() calls to the code. But I am not sure this is a good idea, because it 
will raise warnings with “python -3”. An alternative might be to again only 
require write() to accept memoryview()-able arrays of bytes.

Perhaps the Python 2 definition of “bytes-like object” should be restricted to 
the “new” memoryview() buffer protocol, and to 1-D arrays of bytes. I.e. 
memoryview(byteslike).ndim == 1 and memoryview(byteslike).format == "B".

--
Added file: http://bugs.python.org/file43033/bytes-like-param.py2.patch

___
Python tracker 

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

[issue27143] python 3.5 conflict with Mailman, ebtables and firewalld

[Rubén Rivero Capriles]

New submission from Rubén Rivero Capriles:

My current python version is 3.5 which I installed yesterday. How can I get rid 
of 2,7. Python 3.5 should be the one running.

While: Installing mailman.
An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
  File 
"/root/Python-3.5.0/venv/lib/python2.7/site-packages/zc/buildout/buildout.py", 
line 1992, in main
getattr(buildout, command)(args)
  File 
"/root/Python-3.5.0/venv/lib/python2.7/site-packages/zc/buildout/buildout.py", 
line 666, in install
installed_files = self[part]._call(recipe.install)
  File 
"/root/Python-3.5.0/venv/lib/python2.7/site-packages/zc/buildout/buildout.py", 
line 1407, in _call
return f()
  File 
"/root/mailman-bundler/eggs/collective.recipe.cmd-0.11-py2.7.egg/collective/recipe/cmd/__init__.py",
 line 56, in install
self.execute()
  File 
"/root/mailman-bundler/eggs/collective.recipe.cmd-0.11-py2.7.egg/collective/recipe/cmd/__init__.py",
 line 69, in execute
run_commands(cmds, self.shell)
  File 
"/root/mailman-bundler/eggs/collective.recipe.cmd-0.11-py2.7.egg/collective/recipe/cmd/__init__.py",
 line 39, in run_commands
check_call('%s %s' % (shell, tmpfile), shell=True)
  File "/usr/lib64/python2.7/subprocess.py", line 542, in check_call
raise CalledProcessError(retcode, cmd)
CalledProcessError: Command 'sh /tmp/tmpnI0SlP/run' returned non-zero exit 
status 127
(venv)[root@mlp mailman-bundler]# groupadd mailman
groupadd: group 'mailman' already exists

I had many firewalld conflicts today with the pythos 3.5 I installed yesterday. 
Iptables didn't work either. So I uninstalled both of them and downloaded from 
source firewalld-0.4.1.2.tar.bz2 but can't install it either due to a bug in 
gobject.stp.in', needed by 'gobject.stp

sudo firewall-cmd --permanent --add-service=ssh
Error: Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/dbus/service.py", line 707, in 
message_cb
retval = candidate_method(self, args, *keywords)
File "/usr/lib/python2.7/site-packages/slip/dbus/service.py", line 148, in 
wrapped_method
reply_handler=reply_handler, error_handler=error_handler)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 270, in 
IsSystemBusNameAu thorizedAsync
reply_handler, error_handler, challenge, details)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 256, in 
IsSystemBusNameAu thorizedAsync
timeout=method_call_no_timeout)
File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 137, in __call_
**keywords)
File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 584, in 
call_async
message.append(signature=signature, *args)
ValueError: Unable to guess signature from an empty dict

[root@mlp config]# sudo firewall-cmd --permanent --add-service=http
Error: Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/dbus/service.py", line 707, in 
message_cb
retval = candidate_method(self, args, *keywords)
File "/usr/lib/python2.7/site-packages/slip/dbus/service.py", line 148, in 
wrapped_method
reply_handler=reply_handler, error_handler=error_handler)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 270, in 
IsSystemBusNameAu thorizedAsync
reply_handler, error_handler, challenge, details)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 256, in 
IsSystemBusNameAu thorizedAsync
timeout=method_call_no_timeout)
File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 137, in __call_
**keywords)
File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 584, in 
call_async
message.append(signature=signature, *args)
ValueError: Unable to guess signature from an empty dict

[root@mlp config]# sudo firewall-cmd --permanent --add-service=https
Error: Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/dbus/service.py", line 707, in 
message_cb
retval = candidate_method(self, args, *keywords)
File "/usr/lib/python2.7/site-packages/slip/dbus/service.py", line 148, in 
wrapped_method
reply_handler=reply_handler, error_handler=error_handler)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 270, in 
IsSystemBusNameAu thorizedAsync
reply_handler, error_handler, challenge, details)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 256, in 
IsSystemBusNameAu thorizedAsync
timeout=method_call_no_timeout)
File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 137, in __call_
**keywords)
File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 584, in 
call_async
message.append(signature=signature, *args)
ValueError: Unable to guess signature from an empty dict

[root@mlp config]# sudo firewall-cmd --permanent --add-service=smtp
Error: Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/dbus/service.py", line 707, in 
message_cb
retval = candidate_method(self, args, *keywords)
File 

[issue5784] raw deflate format and zlib module

[Martin Panter]

Martin Panter added the comment:

> v = tuple(map(int, zlib.ZLIB_RUNTIME_VERSION.split(".")))
> supports_wbits_0 = v >= (1, 2, 3, 5)

That was basically my first thought. But I didn’t want to presume that every 
element of the version is an integer. For instance, the current string in the 
“develop” branch of zlib has "1.2.8.1-motley".

--

___
Python tracker 

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

[issue27136] sock_connect fails for bluetooth (and probably others)

[Yury Selivanov]

Yury Selivanov added the comment:

>> Maybe the form requirements for Bluetooth addresses are different than for 
>> IP or ipv6? I guess the validation should be protocol-specific.
> 
> Right, I've just looked at the code [1].  We should return from _ipaddr_info 
> if family is not an AF_UNSPEC, AF_INET or AF_INET6.

Actually, we should probably return in case of AF_UNSPEC too.

--

___
Python tracker 

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

[issue27136] sock_connect fails for bluetooth (and probably others)

[Yury Selivanov]

Yury Selivanov added the comment:

> Maybe the form requirements for Bluetooth addresses are different than for IP 
> or ipv6? I guess the validation should be protocol-specific.

Right, I've just looked at the code [1].  We should return from _ipaddr_info if 
family is not an AF_UNSPEC, AF_INET or AF_INET6.

[1] https://github.com/python/asyncio/blob/master/asyncio/base_events.py#L90

--

___
Python tracker 

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

[issue27136] sock_connect fails for bluetooth (and probably others)

[Guido van Rossum]

Guido van Rossum added the comment:

Maybe the form requirements for Bluetooth addresses are different than for IP 
or ipv6? I guess the validation should be protocol-specific.

--

___
Python tracker 

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

[issue27142] Default int value with xmlrpclib / xmlrpc.client

[Julien]

New submission from Julien:

I tried to execute the following code, but `xmlrpclib` is raising an exception:

>>> import xmlrpclib
>>> data = """ 
... 
... test_method
... 
... 
... 
... 
... 
... 
... 
... """
>>> xmlrpclib.loads(data)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1141, in loads
p.feed(data)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 558, in feed
self._parser.Parse(data, 0)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 829, in end
return f(self, join(self._data, ""))
  File "/usr/lib64/python2.7/xmlrpclib.py", line 864, in end_int
self.append(int(data))
ValueError: invalid literal for int() with base 10: ''

The behaviour is the same with ``, and in python 3.4 with 
xmlrpc.client .
However, I tried to parse the same data with PHP, and it works without any 
trouble.

php > $data = 'test_method';
php > print_r(xmlrpc_decode($data));
Array
(
[0] => 0
)

The .NET documentation of XML-RPC also suggests that `` is interpreted as 
0 (although I couldn't try it myself):
> If an XML-RPC struct member is missing its corresponding .NET struct member 
> will be set to null instead of the default value for the type if a 
> non-nullable type had been used, for example null instead of zero for an 
> integer.

Is it a feature in .NET and PHP implementations of XML-RPC, or a bug in the 
python implementation? I didn't find any documentation about the XML-RPC 
protocol itself on this topic.

--
components: Library (Lib), XML
messages: 266517
nosy: julienc
priority: normal
severity: normal
status: open
title: Default int value with xmlrpclib / xmlrpc.client
type: behavior
versions: Python 2.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

[issue27136] sock_connect fails for bluetooth (and probably others)

[Yury Selivanov]

Yury Selivanov added the comment:

pyptr2, can you reproduce this with latest asyncio (from 
github.com/python/asyncio)?

--

___
Python tracker 

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

[issue27141] Fix collections.UserList shallow copy

[Bar Harel]

New submission from Bar Harel:

I have encountered a weird behavior in collections.UserList.
Using copy.copy() on an instance results in a new instance of UserList but with 
the same underlying list. Seems like self.copy() works great but __copy__ was 
not overridden to allow copy.copy to work too.
The patch just assigns __copy__ to self.copy triggering the correct behavior.

--
components: Library (Lib)
files: UserList.patch
keywords: patch
messages: 266515
nosy: bar.harel
priority: normal
severity: normal
status: open
title: Fix collections.UserList shallow copy
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43032/UserList.patch

___
Python tracker 

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

[issue27136] sock_connect fails for bluetooth (and probably others)

[pyptr2]

pyptr2 added the comment:

The test program should try to connect to a bluetooth device, using asyncio.
The bluetooth address is obviously made up, so it would likely fail to do so, 
but it should not raise an exception before even trying:

$ python3.5 test_async_btsock.py 
Traceback (most recent call last):
  File "test_async_btsock.py", line 9, in 
loop.run_until_complete(coro)
  File "/usr/lib/python3.5/asyncio/base_events.py", line 373, in 
run_until_complete
return future.result()
  File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result
raise self._exception
  File "/usr/lib/python3.5/asyncio/selector_events.py", line 400, in 
sock_connect
base_events._check_resolved_address(sock, address)
  File "/usr/lib/python3.5/asyncio/base_events.py", line 151, in 
_check_resolved_address
" got host %r" % host)
ValueError: address must be resolved (IP address), got host '00:01:02:03:04:05'

--

___
Python tracker 

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

[issue27135] nested list produced with multiplication is linked to the same list

[Emanuel Barry]

Emanuel Barry added the comment:

You do raise a valid point, sequence repetition (*) on lists of mutable objects 
serves very little purpose. However, as I stated, it is a side-effect of the 
data model and changing it would be yet another special case, which aren't 
special enough to break the rules, and this applies here.

Keep in mind that, currently, this is only confusing to newbies. Your idea 
would make this confusing for long-time Python programmers.

If you still wish to propose such a change, I recommend to take this to the 
Python-ideas mailing list (point to this issue in your email). Be warned though 
that most core developers (and most non-core devs such as myself) will probably 
prefer the statu quo, again because the change would be yet another special 
case, and probably view this as an attractive nuisance ("Why does [[x] * y] * n 
create separate lists but x = y = [] refer to the same list?").

--

___
Python tracker 

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

[issue27095] Simplify MAKE_FUNCTION

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

In general the patch LGTM, besides few minor comments.

But new implementation uses longer bytecode for annotations. Current code packs 
argument names in one constant tuple:

$ ./python -m dis
def f(x: int, y: str, z: float): pass
  1   0 LOAD_NAME0 (int)
  2 LOAD_NAME1 (str)
  4 LOAD_NAME2 (float)
  6 LOAD_CONST   0 (('x', 'y', 'z'))
  8 LOAD_CONST   1 (", line 1>)
 10 LOAD_CONST   2 ('f')
 12 EXTENDED_ARG 4
 14 EXTENDED_ARG  1024
 16 MAKE_FUNCTION262144
 18 STORE_NAME   3 (f)
 20 LOAD_CONST   3 (None)
 22 RETURN_VALUE

New code uses LOAD_CONST for every name:

$ ./python -m dis
def f(x: int, y: str, z: float): pass
  1   0 LOAD_CONST   0 ('x')
  2 LOAD_NAME0 (int)
  4 LOAD_CONST   1 ('y')
  6 LOAD_NAME1 (str)
  8 LOAD_CONST   2 ('z')
 10 LOAD_NAME2 (float)
 12 BUILD_MAP3
 14 LOAD_CONST   3 (", line 1>)
 16 LOAD_CONST   4 ('f')
 18 MAKE_FUNCTION4
 20 STORE_NAME   3 (f)
 22 LOAD_CONST   5 (None)
 24 RETURN_VALUE

With new opcode that creates a dict from values and a tuple of keys 
(issue27140) new code would be only one instruction longer.

--
stage:  -> patch review

___
Python tracker 

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

[issue27140] Opcode for creating dict with constant keys

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue27140] Opcode for creating dict with constant keys

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

BUILD_MAP, BUILD_MAP_UNPACK and BUILD_MAP_UNPACK_WITH_CALL need pushing 
key-value pairs on the stack. If keys and values are not constant, this is 
correct order of evaluating them. But if keys are constant (very common case), 
the order of pushing them doesn't affect semantic. We can pack them in constant 
tuple and push on the stack by one instruction.

I think there would be a benefit from adding new opcodes that take a sequence 
of values and a tuple of keys instead of a sequence of key-value pairs.

New MAKE_FUNCTION (issue27095) and new CALL_FUNCTION (issue yet not opened) 
could have a benefit.

--
components: Interpreter Core
messages: 266511
nosy: Demur Rumed, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Opcode for creating dict with constant keys
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

[issue27135] nested list produced with multiplication is linked to the same list

[Matthew Tanous]

Matthew Tanous added the comment:

It makes sense, except for this case is not true when "x" is an immutable data 
type - it appears as though something like [5] * n creates a list of totally 
separate elements (even if they start as the same thing).

It is difficult to see a case where I would not want separate elements from a 
mutable type as well. It would seem to me that having the "*" operator function 
as the list comprehension does now would be more logical and straightforward.

This would change the default list in a way that is mostly unseen: [5] * 3 
would still result in [5, 5, 5] while treating mutable nesting in a way that I 
believe would be more understandable from the apparent intent of the syntax in 
question.

This would also resolve the problem of being unable to use the list 
multiplication to create a list of mutable objects. If I have a mutable object 
Foo and wish to create a list of different instances of them, I cannot use the 
straightforward syntax [Foo()] * n at present to do this, as there will only be 
one actual Foo instance in that list. I think that this is confusing to 
developers who would generally expect that this shortcut (and this is the only 
purpose of the operator for lists) would create a list of different instances.

> On May 27, 2016, at 6:30 AM, Emanuel Barry  wrote:
> 
> 
> Emanuel Barry added the comment:
> 
> The reason why Python behaves like that in this case is a side-effect of the 
> way the data model is implemented. Lists are a mutable data type, which means 
> that referencing the same list - which is what you are doing - as opposed to 
> creating a new one each time, does exactly what is expected of the data 
> model, which is to keep a reference to the original list. Consider:
> 
> x = ??
> y = x
> 
> The object bound to `y` refers to the same object as the one bound to `x`, 
> such that `x is y`, for every possible value of `x`. As `=` is the assignment 
> operator (and not the copy operator, is such a thing existed), `y` merely has 
> a reference to `x`.
> 
> There are very valid use cases where you will want to get a reference to the 
> original list to modify it, for example in a function that is meant to alter 
> the original. If you want a copy, use `l[:]` (or `l.copy()` in more recent 
> versions).
> 
> In Python, every object and operation is evaluated once, when the interpreter 
> comes across it (in a for or while loop, it will come over the same point 
> multiple times, so it will evaluate it multiple times). By doing:
> 
> [[x] * y] * n
> 
> You are essentially doing this:
> 
> l_1 = [x] # one-element list
> l_2 = l_1 * y # list with `y` times `x` in it (references to `x`, not copies)
> l_3 = [l_2] # a new list with one element, `l_2`
> l_4 = l_3 * n # list with `n` times `l_3` in it (references to `l_3`, not 
> copies)
> 
> As you can see, it makes no sense to have multiple different lists by doing 
> that. Doing a list comprehension, such as:
> 
> [[None] * n for _ in range(N)]
> 
> Will evaluate a new list each time the interpreter comes across it, which 
> will be N times for this case. Thus, you get a different list everytime.
> 
> In other words, the reason that "That's just how it works" is because this 
> behaviour is a side-effect, not something that's out of the way. Creating a 
> new special case for this particular case seems like a very big stretch. 
> Remember, "Special cases aren't special enough to break the rules."
> 
> This change that is "seemingly trivial" to you is actually asking to break 
> the Python semantics in some weird and convoluted way, for no gain since we 
> have list comprehensions (that you seem to already be acquainted with).
> 
> Did that seem like a sufficient answer? ;-)
> 
> --
> nosy: +ebarry
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue5784] raw deflate format and zlib module

[STINNER Victor]

STINNER Victor added the comment:

I agree Serhiy :-) i hesitated to propose exactly the same change.

--

___
Python tracker 

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

[issue27139] Increased test coverage for statistics.median_grouped

[Julio C Cardoza]

Changes by Julio C Cardoza <21ago7...@gmail.com>:


--
components: Tests
files: test_median_grouped.patch
keywords: patch
nosy: juliojr77
priority: normal
severity: normal
status: open
title: Increased test coverage for statistics.median_grouped
versions: Python 3.6
Added file: http://bugs.python.org/file43031/test_median_grouped.patch

___
Python tracker 

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

[issue27138] FileFinder.find_spec() docstring needs to be corrected.

[Eric Snow]

Changes by Eric Snow :


--
resolution:  -> fixed
stage: needs patch -> 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

[issue27138] FileFinder.find_spec() docstring needs to be corrected.

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4348fb8cae27 by Eric Snow in branch 'default':
Issue #27138: Fix the doc comment for FileFinder.find_spec().
https://hg.python.org/cpython/rev/4348fb8cae27

--

___
Python tracker 

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

[issue27138] FileFinder.find_spec() docstring needs to be corrected.

[Roundup Robot]

Roundup Robot added the comment:

New changeset ac9c1aeecfb4 by Eric Snow in branch '3.5':
Issue #27138: Fix the doc comment for FileFinder.find_spec().
https://hg.python.org/cpython/rev/ac9c1aeecfb4

--
nosy: +python-dev

___
Python tracker 

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

[issue27138] FileFinder.find_spec() docstring needs to be corrected.

[Eric Snow]

New submission from Eric Snow:

Looks like we weren't careful when we added find_spec(). :)  This issue is just 
to track the change.  I'll push the fix shortly.

--
assignee: eric.snow
messages: 266506
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: FileFinder.find_spec() docstring needs to be corrected.
versions: 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

[issue5784] raw deflate format and zlib module

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I would write the test as:

v = tuple(map(int, zlib.ZLIB_RUNTIME_VERSION.split(".")))
supports_wbits_0 = v >= (1, 2, 3, 5)

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue27137] functools.partial: Inconsistency between Python and C implementations

[Xiang Zhang]

Changes by Xiang Zhang :


--
nosy: +xiang.zhang

___
Python tracker 

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

[issue27136] sock_connect fails for bluetooth (and probably others)

[Guido van Rossum]

Guido van Rossum added the comment:

I cannot run your test program. Can you explain what it does and what you 
expected?

Also, watch your language.

--

___
Python tracker 

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

[issue27137] functools.partial: Inconsistency between Python and C implementations

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> rhettinger

___
Python tracker 

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

[issue27137] functools.partial: Inconsistency between Python and C implementations

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue27137] functools.partial: Inconsistency between Python and C implementations

[Emanuel Barry]

New submission from Emanuel Barry:

functools.partial is a class in C, but the Python implementation is a function. 
This doesn't matter for most use cases where you only want the end result of 
the call to partial.

A simple line in the REPL tells me enough (or so I thought) that I wouldn't 
need to check the implementation:

>>> functools.partial


Oh, it's a class, which means I can subclass it to add a custom repr for my 
needs.

Unsurprisingly, it works. It may not be the best idea to subclass something 
that is meant to be final, but I'm simply overriding a single method, what 
could possibly go wrong? Besides one of the implementations not actually being 
a class.

I'm suggesting to make the Python implementation also a class, for consistency 
and making sure that both the C and Python implementation match, in case 
someone else wants to do that too.

The documentation ( 
https://docs.python.org/3/library/functools.html#functools.partial ) doesn't 
state that the Python and C implementations differ, but IMO this isn't a 
documentation bug.

I haven't written a patch yet, will probably be done by tomorrow.

Note: I haven't actually encountered this issue, but I suspect that it might 
arise if someone doesn't have access to _functools for whatever reason. And 
IMO, Python and C implementations of a feature should be fully equivalent 
(modulo implementation details à la OrderedDict.__root).

Thoughts?

--
components: Library (Lib)
messages: 266503
nosy: ebarry, ncoghlan, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: functools.partial: Inconsistency between Python and C implementations
type: behavior
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

[issue27043] Describe what ‘inspect.cleandoc’ does to synopsis line.

[Nathan Harold]

Nathan Harold added the comment:

Split version (cleandoc2.patch):

   Clean up indentation from docstrings that are indented to line up with blocks
   of code.
   
   All leading whitespace is removed from the first line.  Any leading 
whitespace
   that can be uniformly removed from the second line onwards is removed.  Empty
   lines at the beginning and end are subsequently removed.  Also, all tabs are
   expanded to spaces.

--
Added file: http://bugs.python.org/file43030/cleandoc2.patch

___
Python tracker 

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

[issue27126] Apple-supplied libsqlite3 on OS X is not fork safe; can cause crashes

[Evan Jones]

Evan Jones added the comment:

I have a crazy idea, but I'm not 100% sure how to implement it: If Python was 
able to detect and report this error in a friendly way, it would allow people 
to easily understand what is happening and to work around it. How can we do it?

First idea: In the implementation of os.fork(), detect if libdispatch has been 
used. If it has, throw an exception. I think this is probably possible using 
the libdispatch public APIs, but I'll need to figure out the details. In 
general, this could apply on Linux as well: throw an exception if the process 
has more than one thread running?

Second idea: On Mac OS X only, libdispatch is intentionally crashing the 
process. We could install a signal handler that attempts to detect *this 
specific crash* in order to throw a friendlier exception, or at worst crash 
with a useful message.

Third idea: Add documentation to the multiprocessing module and os.fork that 
they are very unsafe on Mac OS X?

Maybe there is a better way of making this crash "friendlier"?

--

___
Python tracker 

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

[issue18373] let code force str(bytes) to raise an exception

[Daniel Holth]

Daniel Holth added the comment:

Then you prefer the older three year old patch that adds to pystate.h ?
http://bugs.python.org/review/18373/#ps8545

I remember not being happy with how complicated it turned out, and
perhaps having problems with not wanting the "warn once" behavior? It
seems more Pythonic to store the flag in a dict.

--

___
Python tracker 

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

[issue26372] Popen.communicate not ignoring BrokenPipeError

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Ping.

--

___
Python tracker 

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

[issue5784] raw deflate format and zlib module

[STINNER Victor]

STINNER Victor added the comment:

> In Python 2 I removed the test, because Python 2 has no 
> zlib.ZLIB_RUNTIME_VERSION to check.

It makes sense. You didn't touch the C code of the module, only doc.

--

___
Python tracker 

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

[issue5784] raw deflate format and zlib module

[Martin Panter]

Martin Panter added the comment:

Apparently zlib only supports windowBits (wbits) = 0 since v1.2.3.5. I added a 
version check in the Python 3 tests, which seems to have solved the buildbot 
problems (OpenIndiana and OS X buildbots). In Python 2 I removed the test, 
because Python 2 has no zlib.ZLIB_RUNTIME_VERSION to check.

--
resolution:  -> fixed
stage: commit review -> 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

[issue5784] raw deflate format and zlib module

[Roundup Robot]

Roundup Robot added the comment:

New changeset 0df93ab07a8f by Martin Panter in branch '2.7':
Issue #5784: Cannot test wbits=0 unless we know we have zlib v1.2.3.5
https://hg.python.org/cpython/rev/0df93ab07a8f

--

___
Python tracker 

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

[issue18373] let code force str(bytes) to raise an exception

[Daniel Holth]

Daniel Holth added the comment:

My reasoning was that str(bytes) would normally be called so rarely that
who cares.

On Fri, May 27, 2016, at 09:02 AM, STINNER Victor wrote:
> 
> STINNER Victor added the comment:
> 
> strbytes.patch of #27134: adding calls to
> PyThreadState_GetDict()+PyDict_GetItemString() seems inefficient for a
> rare use case
> 
> I would prefer to modify the existing Py_BytesWarningFlag flag.
> 
> The flag is process-wide. If it's an issue, we can use a thread-local
> storage (TLS) for the flag in C.
> 
> FYI get_exec_path() uses the following code to temporarely ignore the
> warning:
> 
> # {b'PATH': ...}.get('PATH') and {'PATH': ...}.get(b'PATH') emit a
> # BytesWarning when using python -b or python -bb: ignore the warning
> with warnings.catch_warnings():
> warnings.simplefilter("ignore", BytesWarning)
> ...
> 
> --
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue18373] let code force str(bytes) to raise an exception

[STINNER Victor]

STINNER Victor added the comment:

strbytes.patch of #27134: adding calls to 
PyThreadState_GetDict()+PyDict_GetItemString() seems inefficient for a rare use 
case

I would prefer to modify the existing Py_BytesWarningFlag flag.

The flag is process-wide. If it's an issue, we can use a thread-local storage 
(TLS) for the flag in C.

FYI get_exec_path() uses the following code to temporarely ignore the warning:

# {b'PATH': ...}.get('PATH') and {'PATH': ...}.get(b'PATH') emit a
# BytesWarning when using python -b or python -bb: ignore the warning
with warnings.catch_warnings():
warnings.simplefilter("ignore", BytesWarning)
...

--

___
Python tracker 

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

[issue18373] let code force str(bytes) to raise an exception

[Daniel Holth]

Daniel Holth added the comment:

Better to continue discussion here.

Attached is my second, simpler version of the feature. A context manager is 
included:

with string.StrBytesRaises():
str(b'bytes')

# raises an exception

In a normal program, you might just set the flag to True, but in a library that 
has no hope of setting the -bb flag you might use it during serialization 
rather than checking isinstance() on all input.

--
title: implement sys.get/setbyteswarningflag() -> let code force str(bytes) to 
raise an exception
versions: +Python 3.6 -Python 3.5
Added file: http://bugs.python.org/file43029/strbytes.patch

___
Python tracker 

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

[issue27134] allow str(bytes) raises an exception to be controlled programmatically

[Daniel Holth]

Daniel Holth added the comment:

Continuing discussion in the older bug

--
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

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

[issue18373] implement sys.get/setbyteswarningflag()

[Daniel Holth]

Changes by Daniel Holth :


Removed file: http://bugs.python.org/file30787/byteswarningflag.patch

___
Python tracker 

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

[issue27135] nested list produced with multiplication is linked to the same list

[Emanuel Barry]

Emanuel Barry added the comment:

The reason why Python behaves like that in this case is a side-effect of the 
way the data model is implemented. Lists are a mutable data type, which means 
that referencing the same list - which is what you are doing - as opposed to 
creating a new one each time, does exactly what is expected of the data model, 
which is to keep a reference to the original list. Consider:

x = ??
y = x

The object bound to `y` refers to the same object as the one bound to `x`, such 
that `x is y`, for every possible value of `x`. As `=` is the assignment 
operator (and not the copy operator, is such a thing existed), `y` merely has a 
reference to `x`.

There are very valid use cases where you will want to get a reference to the 
original list to modify it, for example in a function that is meant to alter 
the original. If you want a copy, use `l[:]` (or `l.copy()` in more recent 
versions).

In Python, every object and operation is evaluated once, when the interpreter 
comes across it (in a for or while loop, it will come over the same point 
multiple times, so it will evaluate it multiple times). By doing:

[[x] * y] * n

You are essentially doing this:

l_1 = [x] # one-element list
l_2 = l_1 * y # list with `y` times `x` in it (references to `x`, not copies)
l_3 = [l_2] # a new list with one element, `l_2`
l_4 = l_3 * n # list with `n` times `l_3` in it (references to `l_3`, not 
copies)

As you can see, it makes no sense to have multiple different lists by doing 
that. Doing a list comprehension, such as:

[[None] * n for _ in range(N)]

Will evaluate a new list each time the interpreter comes across it, which will 
be N times for this case. Thus, you get a different list everytime.

In other words, the reason that "That's just how it works" is because this 
behaviour is a side-effect, not something that's out of the way. Creating a new 
special case for this particular case seems like a very big stretch. Remember, 
"Special cases aren't special enough to break the rules."

This change that is "seemingly trivial" to you is actually asking to break the 
Python semantics in some weird and convoluted way, for no gain since we have 
list comprehensions (that you seem to already be acquainted with).

Did that seem like a sufficient answer? ;-)

--
nosy: +ebarry

___
Python tracker 

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

[issue27129] Wordcode, part 2

[STINNER Victor]

STINNER Victor added the comment:

> if the co_code object is remaining a bytes object then it seems intuitive to 
> keep f_lasti as a bytes offset

Right.

> In reality most of the results on github all seem to be copying a few 
> distinct uses. So maybe backwards compatibiltiy isn't so important

Backwards compatibiltiy is important.

--

___
Python tracker 

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

[issue27136] sock_connect fails for bluetooth (and probably others)

[pyptr2]

Changes by pyptr2 :


--
components: +Library (Lib)
versions: +Python 3.5

___
Python tracker 

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

[issue27136] sock_connect fails for bluetooth (and probably others)

[pyptr2]

Changes by pyptr2 :


Added file: http://bugs.python.org/file43028/test_async_btsock.py

___
Python tracker 

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

[issue27129] Wordcode, part 2

[Demur Rumed]

Demur Rumed added the comment:

https://github.com/search?q=f_lasti=Code

Popular use of f_lasti is checking it for -1, checking the instruction at the 
byte offset of f_lasti, checking the argument with code[f_lasti+1] (Some bad 
code checking f_lasti+3 which'll break with 3.6)

abarnert discussed how bytecode should be typed to Python code. Ideally it'd be 
typed as a "(instruction, arg)" tuple. He considered creating a "words" type 
similar to "bytes" but with 16 bit values. It's a bit niche to introduce a 
builtin for. So if the co_code object is remaining a bytes object then it seems 
intuitive to keep f_lasti as a bytes offset. Clashes with jump offsets no 
longer being a bytes offset even in Python code tho

In reality most of the results on github all seem to be copying a few distinct 
uses. So maybe backwards compatibiltiy isn't so important

Other search 
https://searchcode.com/?q=f_lasti=0=1=3=7=1=19 
doesn't produce many results either

--
nosy: +Demur Rumed

___
Python tracker 

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

[issue27136] sock_connect fails for bluetooth (and probably others)

[pyptr2]

pyptr2 added the comment:

s/prevents/causes/

--

___
Python tracker 

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

[issue5784] raw deflate format and zlib module

[Roundup Robot]

Roundup Robot added the comment:

New changeset ca49614989dd by Martin Panter in branch '3.5':
Issue #5784: wbits=0 apparently added in zlib v1.2.3.5
https://hg.python.org/cpython/rev/ca49614989dd

New changeset 1771f0ac9fc2 by Martin Panter in branch 'default':
Issue #5784: Merge zlib from 3.5
https://hg.python.org/cpython/rev/1771f0ac9fc2

--

___
Python tracker 

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

[issue27136] sock_connect fails for bluetooth (and probably others)

[pyptr2]

New submission from pyptr2:

Base{Selector,Proactor}EventLoop each have a sock_connect() method, both of 
which unconditionally "try" to run base_events' _check_resolved_address() which 
is apparently meant to raise an exception when called with an unresolved IP 
hostname. (because on some OSes it cannot be done asynchronously? WTF?)

Anyhow, the current implementation prevents ANY address family other than IP 
(and UNIX, which is special cased) to raise the exception, no matter if it's 
resolved or not.

So please, call _ipaddr_info() for IP only.

--
components: asyncio
files: check_resolved.patch
keywords: patch
messages: 266486
nosy: gvanrossum, haypo, pyptr2, yselivanov
priority: normal
severity: normal
status: open
title: sock_connect fails for bluetooth (and probably others)
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file43027/check_resolved.patch

___
Python tracker 

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

[issue5784] raw deflate format and zlib module

[STINNER Victor]

STINNER Victor added the comment:

Failure on Python 2.7:

http://buildbot.python.org/all/builders/x86%20OpenIndiana%202.7/builds/3348/steps/test/logs/stdio

==
ERROR: test_wbits (test.test_zlib.CompressObjectTestCase)
--
Traceback (most recent call last):
  File 
"/export/home/buildbot/32bits/2.7.cea-indiana-x86/build/Lib/test/test_zlib.py", 
line 534, in test_wbits
self.assertEqual(zlib.decompress(zlib15, 0), HAMLET_SCENE)
error: Error -2 while preparing to decompress data: inconsistent stream state

--
nosy: +haypo

___
Python tracker 

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

[issue5784] raw deflate format and zlib module

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4c88d6d18e85 by Martin Panter in branch '3.5':
Issue #5784: Expand documentation and tests for zlib wbits parameter
https://hg.python.org/cpython/rev/4c88d6d18e85

New changeset 4d4f27fc70d5 by Martin Panter in branch 'default':
Issue #5784: Merge zlib from 3.5
https://hg.python.org/cpython/rev/4d4f27fc70d5

New changeset e5fc74588cea by Martin Panter in branch '2.7':
Issue #5784: Expand documentation and tests for zlib wbits parameter
https://hg.python.org/cpython/rev/e5fc74588cea

--
nosy: +python-dev

___
Python tracker 

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

[issue27126] Apple-supplied libsqlite3 on OS X is not fork safe; can cause crashes

[Ronald Oussoren]

Ronald Oussoren added the comment:

There is a clear gap between two use cases for Python on OSX:

1) Integrate nicely with Apple stuff

2) Be useful as a development platform for software that will be deployed on 
Linux machines.

Both use cases are valid, but have slightly different trade-offs. I have both 
use-cases, but tend not to do things that cause problems here.  In any case I 
tend to favour the first use case, it is easy enough to develop locally and 
test on Linux (VMs, docker, ...) for the second use case.

A particular problem is using os.fork, as Evan notes there are problems with 
using Apples frameworks in programs that use fork without exec-ing a new 
program. Libdispatch is one problem, but higher-level frameworks are also 
problematic (the _scproxy problem is not only caused the use of libdispatch).

Spawning off a small executable for the _scproxy case could be worthwhile, 
although I haven't fully thought about the implications of that. I wouldn't 
like removing the use of _scproxy, it uses the documented programmatic way to 
access system-wide proxy configuration. Using something like scutil(1) might 
work as well, but is hackish.

Changing the default mode for multiprocessing could also be useful, but could 
result in calls about code that works on Linux but doesn't on OSX due to 
differences in fork mode.

BTW. Using fork without exec is unsafe in any program using threads, people 
tend to run into this more on OSX because Apple's libraries use background 
threads while other Unix-y platforms don't tend to do that.

As to shipping the sqlite with the CPython source: that's not something we do 
in general. It would be better to document the issue in the build instructions 
for CPython, and/or tweak the CPython build process to issue a warning when it 
detects that is using the system version of sqlite on OSX.

BTW2. Another problematic issue on OSX is accessing the system trust store for 
SSL certificates.  AFAIK the current binaries still use Apple's build of 
OpenSSL that uses a private API to access the system trust store, using a 
standalone OpenSSL would require some way to make OpenSSL use the trust store; 
either by shipping a script to dump the trust store in a format that OpenSSL 
can use or by using Apple's APIs to access the trust store. IIRC there is an 
issue about that, but I cannot find it at the moment. Using the public APIs 
might result in similar problems as mentioned in this issue.

--

___
Python tracker 

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

[issue5784] raw deflate format and zlib module

[Martin Panter]

Changes by Martin Panter :


--
stage: patch review -> commit review
versions:  -Python 3.4

___
Python tracker 

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

[issue27135] nested list produced with multiplication is linked to the same list

[Matthew Tanous]

Matthew Tanous added the comment:

I'm aware that it's how Python works at present. My point was that this is 
awkward and counter-intuitive, with no purpose I can see worth serving.

"That's just how it works" seems to me a rather insufficient answer, especially 
for such a seemingly trivial change.

So, no, it's not technically a bug. But I think it's worth some discussion.

> On May 26, 2016, at 11:42 PM, Benjamin Peterson  
> wrote:
> 
> 
> Benjamin Peterson added the comment:
> 
> That's just how Python works. 
> https://docs.python.org/3/faq/programming.html#how-do-i-create-a-multidimensional-list
> 
> --
> nosy: +benjamin.peterson
> resolution:  -> not a bug
> status: open -> closed
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue7951] Should str.format allow negative indexes when used for __getitem__ access?

[Marco Buttu]

Marco Buttu added the comment:

The error message is misleading:

>>> s = '{names[-1]} loves {0[1]}'
>>> s.format(('C', 'Python'), names=('Dennis', 'Guido'))
Traceback (most recent call last):
...
TypeError: tuple indices must be integers or slices, not str

--
nosy: +marco.buttu

___
Python tracker 

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

[issue25926] problems with "times" keyword in itertools.repeat

[Nofar Schnider]

Nofar Schnider added the comment:

Attached a diff
All occurrences of "equivalent to" are switched to "roughly equivalent to"

--
hgrepos: +345
keywords: +patch
Added file: http://bugs.python.org/file43026/issue25926.diff

___
Python tracker 

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

[issue25926] problems with "times" keyword in itertools.repeat

[Nofar Schnider]

Changes by Nofar Schnider :


Removed file: http://bugs.python.org/file43025/itertools.rst

___
Python tracker 

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

[issue27120] xmllib unable to parse in UTF8 format

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage: test needed -> 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

[issue27120] xmllib unable to parse in UTF8 format

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

See also issue222587. Seems this was the reason why the xmllib module was 
deprecated.

Use the xml package for parsing XML (xml.etree.ElementTree, xml.dom.minidom, 
xml.sax, etc).

--
resolution:  -> wont fix

___
Python tracker 

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

[issue25926] problems with "times" keyword in itertools.repeat

[Nofar Schnider]

Nofar Schnider added the comment:

Issue #25926
Changed all "equivalent to" occurrences to "roughly equivalent to"

--
hgrepos: +344
nosy: +Nofar Schnider
Added file: http://bugs.python.org/file43025/itertools.rst

___
Python tracker 

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