[issue27089] I think this is a small bug in urlparse.py

[Feng A]

New submission from Feng A:

=
BUG:

run : urlparse.urlparse('http://google.com]')
then: raise ValueError("Invalid IPv6 URL")

=
SOURCE:

if url[:2] == '//':

netloc, url = _splitnetloc(url, 2)

if (('[' in netloc and ']' not in netloc) or

(']' in netloc and '[' not in netloc)):

raise ValueError("Invalid IPv6 URL")

=
SOLUTION:

I THINK IT IS BETTER TO JUST REMOVE THE LAST 3 LINES ABOVE

--
components: Library (Lib)
messages: 266125
nosy: Feng A
priority: normal
severity: normal
status: open
title: I think this is a small bug in urlparse.py
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

[issue27089] I think this is a small bug in urlparse.py

[Xiang Zhang]

Xiang Zhang added the comment:

Why? I think this is the right behaviour. According to the rfc[1], square 
brackets are used and only used to refer IPv6 address in URI. Square brackets 
are reserved characters and the URI you give is not correct.

1. http://tools.ietf.org/html/rfc3986#section-3

--
nosy: +xiang.zhang

___
Python tracker 

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

[issue27089] I think this is a small bug in urlparse.py

[Feng A]

Feng A added the comment:

I wish you could think twice if you hadn't use urlparse.py in practical 
project.  

1. Do you like the module to raise an exception?
2. The href in webpage is always standard format?
3. Should the parse module verify the ipv6 url format? If so, did the module 
really make it?

4. Personally, Given a wrong formated url, It is the responsibility of the 
module to correct it ?

--

___
Python tracker 

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

[issue27089] I think this is a small bug in urlparse.py

[Xiang Zhang]

Xiang Zhang added the comment:

As a general purpose library for url parsing, I think conforming to the 
existing standard is a good choice.

'http://google.com]' is a malformed URI according to the standard and then I 
think raising an exception is quite suitable. Of course there are always 
malformed links in webpages but how to correct them is quite objective. I think 
catch the exception in application and correct them in your own logic is what 
you should do.

--

___
Python tracker 

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

[issue27089] I think this is a small bug in urlparse.py

[Xiang Zhang]

Xiang Zhang added the comment:

Ohh, not objective, but subjective. Sorry.

--

___
Python tracker 

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

[issue27089] I think this is a small bug in urlparse.py

[Antti Haapala]

Antti Haapala added the comment:

This behaviour exists exactly because the return value also contains the 
`.hostname`, which for the IPv6 addresses is *without* brackets:

>>> urlparse('http://[::1]:80/').hostname
'::1'

There is no way to get a proper parsing result from such a broken URI.

--
nosy: +ztane

___
Python tracker 

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

[issue27089] I think this is a small bug in urlparse.py

[Berker Peksag]

Berker Peksag added the comment:

> 4. Personally, Given a wrong formated url, It is the responsibility of the 
> module to correct it ?

It's not the responsibility of the library to correct (or make a guess on) user 
input.

--
nosy: +berker.peksag
resolution:  -> not a bug
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

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

[aixtools]

aixtools added the comment:

See below between points.

On 12-May-16 17:45, Martin Panter wrote:
> Martin Panter added the comment:
>
> Thanks for trying to move the directory in the new patch, but it does not 
> seem to have been picked up by Rietveld. I have only seen patches generated 
> with Mercurial and Git work, but I don’t exactly know _why_ they work :)
>
> Here is a summary of what I would be comfortable adding to Python:
>
> 1. Add ctypes.RTLD_MEMBER constant (new API, so 3.6+ only)
Understood. Should also add RTLD_NOW as it is referenced in comments, 
and used in the _global.c (imho).
> 2. Basic ctypes.util.find_library("crypto") implementation for AIX. But cases 
> like find_library("libintl.so") should fail. I think your earlier patches 
> were closer to this implementation than the later ones.
>
> I am a bit hesitant about the automatic behaviour of 
> CDLL("libcrypto.a(libcrypto.so.1.0.0)") using RTLD_MEMBER. IMO it may be 
> better to let the caller specify RTLD_MEMBER explicitly. If a shared library 
> file literally called “/usr/lib/libcrypto.a(libcrypto.so.1.0.0)” existed, 
> i.e. not inside an archive, would dlopen("libcrypto.a(libcrypto.so.1.0.0)", 
> RTLD_NOW) succeed? I admit this is an unlikely scenario, but it seems bad to 
> reduce the domain of a low-level API.
>
> I understand it would be good to have the return value of find_library() 
> consistent with the name accepted by CDLL(). Perhaps a new parameter format 
> would help, such as a tuple (archive, member).
I would expect a new tuple would be seen as new API (like 
_ctypes.RTLD_MEMBER), so it would never help in Python-2.7, which is 
still where I see most people asking for support with AIX.
My guidance was: find_library("m") is legal, as is 
find_library("libm.so"), as is CDLL("libcrypt.so").

These are all dependencies, at a low-level of how the system is 
configured, i.e., it is not uncommon for a GNU/Linux installation to 
have many symbolic links to resolve multiple names, and programmers use 
one, or more of those conventions. The find_library() and CDLL() calls 
work because of these conventions.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu May 19 02:53:48 2016 from xxx.yyy.zzz.net 

root@x066:~# python -m ctypes.util
libm.so.6
libc.so.6
libbz2.so.1.0


libcrypt.so.1

Looking at filesystem level:
root@x066:~# cd /lib64
root@x066:/lib64# ls -l libcrypt.*
lrwxrwxrwx 1 root root 16 Feb 22  2015 libcrypt.so.1 -> libcrypt-2.13.so 

root@x066:/lib64# cd /usr/lib64
root@x066:/usr/lib64# ls -l libcrypt.*
-rw-r--r-- 1 root root 62108 Feb 22  2015 libcrypt.a
lrwxrwxrwx 1 root root20 Feb 22  2015 libcrypt.so -> 
/lib64/libcrypt.so.1

So, CDLL.dlopen() finds /usr/lib64/libcrypt.so that is a symbolic link 
to /lib64/libcrypt.so.1 that is a symbolic link to 
/lib64/libcrypt-2.13.so . I see libcrypt.so as 
a "shorthand" for whatever is installed. As a porgrammer/user of 
CDLL.dlopen() I do not care what it finally resolves to.

Linux has it's conventions: one important one I observe when porting OSS 
packages is that "installation" and updates of libraries (or API's) 
provide "shortnames" in the form of libFOO.so  that are symbolic names 
to the final object. Unfortunately, there are exceptions - especially 
look at "libc.so"

root@x066:/usr/lib64# ls -l libc.so*
-rw-r--r-- 1 root root 243 Feb 22  2015 libc.so

root@x066:/usr/lib64# cd /lib64
root@x066:/lib64# ls -l libc.so*
lrwxrwxrwx 1 root root 12 Feb 22  2015 libc.so.6 -> libc-2.13.so
root@x066:/lib64# ls -l libc-2.13.so
-rwxr-xr-x 1 root root 1758016 Feb 22  2015 libc-2.13.so

Obviously, using shorthand for libc.so on Debian is not returning 
anything equivalent to libc.so.6 (look at the different sizes). So, a 
program that looks specifically for libc.so.6 will succeed on Debian, 
and fail on AIX (as it does not exist in that form) - and my expectation 
is that existing programs that code libc.so.6 will fail on AIX. However, 
I have extreme doubts that anyone actually codes the test - as (at least 
on AIX) libc is already loaded.

AIX:
root@x071:[/root]ldd /opt/bin/python
/opt/bin/python needs:
  /usr/lib/libc.a(shr.o)
  /usr/lib/libpthreads.a(shr_xpg5.o)
  /usr/lib/libpthreads.a(shr_comm.o)
  /usr/lib/libdl.a(shr.o)
  /unix
  /usr/lib/libcrypt.a(shr.o)

And, it seems, libc is also already loaded on Debian:
root@x066:/lib64# ldd /usr/bin/python
 linux-vdso32.so.1 =>  (0x0010)
 libpthread.so.0 => /lib/powerpc-linux-gnu/libpthread.so.0 
(0x0ffc5000)
 libdl.so.2 => /lib/powerpc-linux-gnu/libdl.so.2 (0x0ffa1000)
 libutil.so.1 => /lib/powerpc-linux-gnu/libutil.so.1 (0x0ff7e000)
 libz.so.1 => /lib/powerpc-linux-gnu/libz.so.1 (0x0ff47000)
 libm.so.6 => /lib/powerpc-linux-gnu/libm.so.6 (0x0fe79000)
 libc

[issue27090] Python 3 import error after installation

[Richard Penman]

New submission from Richard Penman:

I installed latest release 
(https://www.python.org/downloads/release/python-351/) on OSX and get this 
error:

$ python3
...
ImportError: This package should not be accessible on Python 3. Either you are 
trying to run from the python-future src folder or your installation of 
python-future is corrupted.

Also tried installing via brew and got same error.

--
components: Installation, Macintosh
messages: 266133
nosy: Richard Penman, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python 3 import error after installation
type: crash
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

[issue27090] Python 3 import error after installation

[Richard Penman]

Richard Penman added the comment:

The full error log:

$ python3
Failed to import the site module
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/site-packages/site.py", line 75, in 
__boot()
  File "/usr/local/lib/python2.7/site-packages/site.py", line 23, in __boot
loader.load_module('site')
  File 
"/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site.py", line 
563, in 
main()
  File 
"/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site.py", line 
549, in main
known_paths = addusersitepackages(known_paths)
  File 
"/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site.py", line 
281, in addusersitepackages
user_site = getusersitepackages()
  File 
"/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site.py", line 
257, in getusersitepackages
user_base = getuserbase() # this will also set USER_BASE
  File 
"/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site.py", line 
247, in getuserbase
USER_BASE = get_config_var('userbase')
  File 
"/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/sysconfig.py", 
line 582, in get_config_var
return get_config_vars().get(name)
  File 
"/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/sysconfig.py", 
line 561, in get_config_vars
import _osx_support
  File 
"/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/_osx_support.py",
 line 4, in 
import re
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/re.py", 
line 335, in 
import copyreg
  File "/usr/local/lib/python2.7/site-packages/copyreg/__init__.py", line 7, in 

raise ImportError('This package should not be accessible on Python 3. '
ImportError: This package should not be accessible on Python 3. Either you are 
trying to run from the python-future src folder or your installation of 
python-future is corrupted.

What needs to be changed to avoid importing Python 2 modules?

--

___
Python tracker 

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

[issue16353] add function to os module for getting path to default shell

[Xavier de Gaye]

Xavier de Gaye added the comment:

Following Serhiy suggestion at msg224477, this tentative patch adds the 
is_android attribute to the posix module and the default_shell attribute to the 
os module. No documentation for the moment. No test case is needed I think, as 
the changes in issue 16255 will test any solution found here.

An alternative to posix.is_android is sys.platform set to 'linux-android' on 
Android. These are the locations in the standard library that do not test for 
"if sys.platform.startswith('linux')":

Lib/distutils/tests/test_dist.py|386 col 16| if sys.platform in ('linux', 
'darwin'):
Lib/test/test_logging.py|527 col 12| if sys.platform in ('linux', 'darwin'):
Lib/test/test_resource.py|135 col 26| @unittest.skipUnless(sys.platform == 
'linux', 'test requires Linux')
Lib/test/test_socket.py|898 col 16| or sys.platform in ('linux', 'darwin')):
Lib/test/test_socket.py|2256 col 23| @skipWithClientIf(sys.platform not in 
{"linux"},
Lib/test/test_socket.py|4508 col 22| @unittest.skipUnless(sys.platform == 
'linux', 'Linux specific test')
Lib/test/test_sysconfig.py|388 col 26| @unittest.skipUnless(sys.platform == 
'linux', 'Linux-specific test')

--
nosy: +xdegaye
Added file: http://bugs.python.org/file42953/default_shell.patch

___
Python tracker 

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

[issue27090] Python 3 import error after installation

[Richard Penman]

Richard Penman added the comment:

Apparently "The PYTHONPATH variable is used by all versions of Python 2 and 
Python 3, so you should not permanently configure this variable unless it only 
includes code that is compatible with all of your installed Python versions."

That seems crazy...

--

___
Python tracker 

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

[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update

[Clement Rouault]

Changes by Clement Rouault :


--
nosy: +hakril

___
Python tracker 

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

[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update

[Clement Rouault]

Clement Rouault added the comment:

I also stumbled on this issue when playing with the winreg module.
I will try to make the discussion go forward by submitting a new patch.
I added a test and tried everything (test included on 3.5) on my own computer 
(windows 8.1 64b)
There are two points that might be 'sensitive' and I would like to have 
someone's opinion:
* I am using `DWORD64` as an unsigned 64bit value as `QWORD` is not defined 
in 
* I changed one line of the previous implementation for REG_DWORD:
* `PyLong_FromUnsignedLong(*(int *)retDataBuf);` became 
`PyLong_FromUnsignedLong(*(DWORD *)retDataBuf);`
* I don't think it is a problem, but better ask than break something

--
versions: +Python 3.5 -Python 3.4
Added file: http://bugs.python.org/file42954/winreg_qword_patch_with_test.patch

___
Python tracker 

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

[issue27091] Python IDLE doesn't like 💙

[Christian Kleineidam]

New submission from Christian Kleineidam:

When I past 💙 into the Python IDLE it closes automatically. 
I would be fine with the IDLE not being able to display the character. 
Automatically closing seems however excessive.

--
components: IDLE
messages: 266138
nosy: Christian.Kleineidam
priority: normal
severity: normal
status: open
title: Python IDLE doesn't like 💙
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

[issue26927] test_mmap does not handle ValueError when no large file support

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> When OverflowError is raised? Shouldn't it be replaced with ValueError?

At least Python implementation of io.FileIO can raise OverflowError (from 
os.lseek()). Thus OverflowError should be kept.

--
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

[issue27091] Python IDLE doesn't like 💙

[STINNER Victor]

STINNER Victor added the comment:

What is your OS? Windows?

What is the full Python version (see the IDLE window title)?

Note: I cannot reproduce the issue on Linux with Python 3.4.3: pasting a string 
which contains 💙 do nothing, whereas pasting pure ASCII string works well.

I recall the TCL doesn't have a full support of Unicode, usually it only 
supports BMP (U+-U+).

💙 is a non-BMP character: U+1f499.

--
nosy: +haypo

___
Python tracker 

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

[issue27090] Python 3 import error after installation

[Steven D'Aprano]

Steven D'Aprano added the comment:

It looks like your Python 3 is somehow using your Python 2 site directory. What 
does your PYTHONPATH contain?

Try running this:

python3 -E -S -c "import sys; print(sys.path)"

and see what it says.

--
nosy: +steven.daprano
type: crash -> behavior

___
Python tracker 

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

[issue27092] ord() raises TypeError in string input

[Christoph Wruck]

New submission from Christoph Wruck:

Hi,
is there any reason why ord() raises a TypeError instead of ValueError on 
string/bytes input with wrong length?

The chr() function will raise a ValueError on negative integers such as chr(-1).

Required behaviour:

try:
n = ord(input_string)
except ValueError as e:
# it's a string/bytes-string, process potential escape sequence and
# get an ordinal number of decoded escape sequence, otherwise raise
...

with kind regards,
Chris

--
components: Unicode
messages: 266142
nosy: cwr, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: ord() raises TypeError in string input
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

[issue27092] ord() raises TypeError in string input

[Christoph Wruck]

Changes by Christoph Wruck :


--
type:  -> enhancement

___
Python tracker 

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

[issue27092] ord() raises TypeError in string input

[Christoph Wruck]

Changes by Christoph Wruck :


--
type: enhancement -> behavior

___
Python tracker 

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

[issue17866] TestCase.assertItemsEqual exists in 2.7, not in 3.3

[R. David Murray]

R. David Murray added the comment:

At the time I wanted it to be named assertCountsEqual, which is better (IMO) 
than either assertItemsEqual or assertCountEqual.  I lost that naming contest, 
though :(.  On the third hand, I don't think there exists a good two word name 
for what the function does.

--
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

[issue27092] ord() raises TypeError in string input

[Xiang Zhang]

Xiang Zhang added the comment:

Once I also mentioned about this in another thread, issue27008, I created and 
Serhiy gave me a response. You can have a look at that.

--
nosy: +xiang.zhang

___
Python tracker 

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

[issue27091] Python IDLE doesn't like 💙

[Martin Panter]

Martin Panter added the comment:

Is this the same as Issue 13153?

--
nosy: +martin.panter

___
Python tracker 

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

[issue27092] ord() raises TypeError in string input

[Xiang Zhang]

Changes by Xiang Zhang :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Vincent Michel]

Vincent Michel added the comment:

I agree with Yury's ideas about the implementation of this feature. However, it 
is a bit confusing to have `asyncio.get_event_loop` defined as:

def get_event_loop():
policy = get_event_loop_policy()
return policy.get_running_loop() or policy.get_event_loop()

One would expect `asyncio.get_event_loop` to simply work as a shortcut for:

get_event_loop_policy().get_event_loop()

The root of the problem is that we're trying to define 3 concepts with only 2 
wordings. I think it is possible to solve this issue quite easily by renaming 
`AbstractLoopPolicy.get_event_loop` with `AbstractLoopPolicy.get_default_loop`. 
We'd end up with the following definitions:

- default_loop: current default loop as defined in the policy
- running_loop: current running loop (thread-wise) if any 
- event_loop: running loop if any, default_loop otherwise

Changing the API is always annoying, but in this case it would only affect the 
event loop policies. This is a pretty specific use case, and they'll have to be 
updated anyway in order to implement `set_running_loop`. asyncio.set_event_loop 
might be affected too, although it could be kept or deprecated.

Do you think it's worth the trouble?

--
nosy: +vxgmichel

___
Python tracker 

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

[issue27092] ord() raises TypeError on string/bytes input

[Christoph Wruck]

Christoph Wruck added the comment:

closed as redundant to:

http://bugs.python.org/issue27008

--
resolution:  -> not a bug
status: open -> closed
title: ord() raises TypeError in string input -> ord() raises TypeError on 
string/bytes input

___
Python tracker 

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

[issue27093] Silence warning in cjkcodecs.h

[Demur Rumed]

New submission from Demur Rumed:

gcc6 now warns about indentation of code. find_paireencmap raised such 
warnings. This patch silences that warning while updating the code to be more 
PEP7 friendly wrt curlies

--
files: cjkcodecs.patch
keywords: patch
messages: 266148
nosy: Demur Rumed
priority: normal
severity: normal
status: open
title: Silence warning in cjkcodecs.h
type: compile error
versions: Python 3.6
Added file: http://bugs.python.org/file42955/cjkcodecs.patch

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ionel Cristian Mărieș]

Ionel Cristian Mărieș added the comment:

On Mon, Apr 20, 2015 at 5:08 PM, Eric Snow  wrote:

> FYI, I'll re-iterate something I said before, there is a different
> approach you can take here if this is just an issue of proxying.  Use two
> different proxy types depending on if the proxied object is callable or not:
>
>
> class Proxy:
> # all the proxy stuff...
>
>
> class CallableProxy(Proxy):
> def __call__(self, *args, **kwargs):
> ...
>
>
> def proxy(obj):
> if callable(obj):
> return CallableProxy(obj)
> else:
> return Proxy(obj)
>
>
> If that isn't a viable alternative then please explain your use case in
> more detail.  I'm sure we can find a solution that works for you.
>

​This does not work if I need to resolve the `obj` at a later time (way
later than the time I create the Proxy object). Unfortunately, I need
exactly that. Not sure how that wasn't clear from all the examples I posted
...​

--

___
Python tracker 

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

[issue27032] Remove deprecated html.parser.HTMLParser.unescape()

[Jim Jewett]

Jim Jewett added the comment:

Looks Good To Me

--
nosy: +Jim.Jewett

___
Python tracker 

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

[issue26915] Test identity first in membership operation of ItemsView, ValuesView and Sequence in collections.abc

[Xiang Zhang]

Xiang Zhang added the comment:

Reopen this since the solution is not complete pointed out by Serhiy and the 
new patch has already been attached(s2).

--
status: closed -> open

___
Python tracker 

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

[issue27038] Make os.DirEntry exist

[Jim Jewett]

Changes by Jim Jewett :


--
stage:  -> needs patch

___
Python tracker 

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

[issue26632] __all__ decorator

[Franklin? Lee]

Franklin? Lee added the comment:

>I don't know, but what practical effect will this have?  I.e. under what
>conditions would you @public wrap a @functools.wraps function and want it to
>show up in __all__?  Do you have a specific use case?

I sometimes wrap functions that return iterators to make functions that return 
lists, because I work on the interpreter a lot. From there, it's not much of a 
stretch to imagine functions which are implemented as decorated versions of 
other functions.

If @public were only to be used as a decorator, it would not be possible to 
have `public` called on a function outside of its definition. But someone might 
call `public(some_decorator(some_function))`.

(@public is really a macro, if you think about it.)

>It would be possible.

(I meant, is it possible for someone to have a non-list __all__?)

If the `.append` fails, I think there should be a meaningful error. Perhaps 
"'__all__' is not a list."

>Sure, we could probably add some heuristics, but I still don't see the need
>for the extra complexity.  The error will be far from the declaration, but the
>exception should make it relatively obvious what's going on.  I also really
>don't think folks would naturally be inclined to put @public on anything but a
>top-level definition.  You wouldn't ever put such a thing in your __all__ so
>why would you decorate it with @public?

I'm thinking of the people who don't read docs and are coming from other 
languages. They'd put `@public` over their method, and one day they'd `import 
*` from that file (whereas they used to only import explicitly), getting an 
error about a name not being defined in their module. "But why would that name 
need to be defined? It's a method."

Or worse, the name of the method just happens to be the same as something in 
some other file, so they'll focus on why that NAME is being expected in THIS 
file.

>Also, I know that I have several cases where constants are actually
>instances.  They could be marker objects like::
>
>MARKER = object()

(Here's food for thought: A MARKER could be a one-element enum, both 
conceptually and by implementation. Just like how the "bool enum" is 
{True,False} and the "None enum" is {None}.)

--

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[R. David Murray]

R. David Murray added the comment:

Personally I don't see any difference between assertCountsEqual and 
assertFrequencyCountsEqual.  The logic for assertCountsEqual is that it is 
asserting that some counts are equal in this sequence.  What could we be 
counting?  The only obvious thing is the length of the collections of equal 
elements.  'Count' was chosen because it references itertools.count, which it 
can be defined in terms of, as indicated in the docs.  The presence of absence 
of the s doesn't affect that rationale for the name.

The flaw in assertItems(Elements)Equal is that it implies that each pair of 
element is equal, implying that the *orders* are the same, which is exactly the 
opposite of the intent.

This is the kind of bikeshed that can go on for weeks on a mailing list.  I say 
leave well enough alone unless someone comes up with a simply brilliant better 
name.

--
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

[issue27085] Make it possible to select return type for os.listdir

[R. David Murray]

R. David Murray added the comment:

The API for selecting the output type is to pass in the corresponding input 
type.  This is true for many functions in the python3 standard library.

--
nosy: +r.david.murray
resolution:  -> rejected
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

[issue27086] Add closefd argument to os.listdir

[R. David Murray]

R. David Murray added the comment:

This proposal doesn't feel to me like it matches the general APIs we have in 
the standard library.  I would think the python style for this would be to use 
a context manager when opening the fd.  So, I'm -1 on this proposal.

--
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

[issue27021] It is not documented that os.writev() suffer from SC_IOV_MAX

[Jim Jewett]

Changes by Jim Jewett :


--
stage:  -> needs patch

___
Python tracker 

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

[issue27066] SystemError if custom opener returns -1

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


Added file: http://bugs.python.org/file42956/27066-2.patch

___
Python tracker 

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

[issue27085] Make it possible to select return type for os.listdir

[Evgeny Kapun]

Evgeny Kapun added the comment:

Unfortunately, this doesn't work if I pass a file descriptor.

--
resolution: rejected -> 
status: closed -> open

___
Python tracker 

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

[issue27085] Make it possible to select return type for os.listdir

[STINNER Victor]

STINNER Victor added the comment:

> Unfortunately, this doesn't work if I pass a file descriptor.

I strongly suggest you to handle filenames as Unicode ;-) It helps a lot on 
Windows, it's more convenient, etc.

--
nosy: +haypo

___
Python tracker 

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

[issue27085] Make it possible to select return type for os.listdir

[Evgeny Kapun]

Evgeny Kapun added the comment:

Unfortunately, on Linux, handling names as Unicode can cause some problems. For 
example, merely print()-ing such a name can cause UnicodeEncodeError.

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ionel Cristian Mărieș]

Changes by Ionel Cristian Mărieș :


Added file: http://bugs.python.org/file42957/callable2.diff

___
Python tracker 

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

[issue26632] __all__ decorator

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On May 23, 2016, at 02:43 PM, Franklin? Lee wrote:

>I sometimes wrap functions that return iterators to make functions that
>return lists, because I work on the interpreter a lot. From there, it's not
>much of a stretch to imagine functions which are implemented as decorated
>versions of other functions.
>
>If @public were only to be used as a decorator, it would not be possible to
>have `public` called on a function outside of its definition. But someone
>might call `public(some_decorator(some_function))`.

Do you mean, they'd call this is some module other than the one some_function
was defined in?  I don't know that this is a use case we even want to support.

>(@public is really a macro, if you think about it.)

That's true in a sense.  It doesn't change the decorated thing at all.  I
think it's important to keep in mind that @public isn't the only way to add to
__all__.

>
>>It would be possible.  
>
>(I meant, is it possible for someone to have a non-list __all__?)

Yes.  I've seen existing code where __all__ is assigned to a tuple.

>If the `.append` fails, I think there should be a meaningful error. Perhaps
>"'__all__' is not a list."

You should get something like:

AttributeError: 'tuple' object has no attribute 'append'

which seems pretty obvious.

>I'm thinking of the people who don't read docs and are coming from other
>languages. They'd put `@public` over their method, and one day they'd `import
>*` from that file (whereas they used to only import explicitly), getting an
>error about a name not being defined in their module. "But why would that
>name need to be defined? It's a method."
>
>Or worse, the name of the method just happens to be the same as something in
>some other file, so they'll focus on why that NAME is being expected in THIS
>file.

Well, consenting adults and all.  I'm not sure we need to protect ourselves so
strictly against people who don't read the docs and don't understand Python
(i.e. random cargo-culters).

>>Also, I know that I have several cases where constants are actually
>>instances.  They could be marker objects like::
>>
>>MARKER = object()  
>
>(Here's food for thought: A MARKER could be a one-element enum, both
>conceptually and by implementation. Just like how the "bool enum" is
>{True,False} and the "None enum" is {None}.)

Sure.  I don't think that changes anything here though.  Down the line, it
might be an interesting idiom to experiment with (you can probably start with
the standalone enum34 module).

--

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Michael Foord]

Michael Foord added the comment:

I agree with David, I don't like the name but it is at least accurate (if you 
already understand what it does). assertItemsEqual was better but misleading. 
In the absence of a *dramatically* better name leave it alone.

--

___
Python tracker 

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

[issue27090] Python 3 import error after installation

[Zachary Ware]

Zachary Ware added the comment:

> That seems crazy...

What's crazy about it?  There are very very few legitimate situations where you 
need to permanently set any PYTHON* variable, particularly PYTHONPATH and 
PYTHONHOME.  Adding site-packages to sys.path via PYTHONPATH is completely 
unnecessary anyway since site.py will do that for you in a much safer manner.

This looks like a local configuration issue; closing.

--
nosy: +zach.ware
resolution:  -> not a bug
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

[issue27090] Python 3 import error after installation

[Ned Deily]

Ned Deily added the comment:

To add to Zach's comment, there have been extended discussions in the past 
about whether there should be a separate set of environment variables for 
Python 3 vs Python 2 interpreters; see, for instance, Issue2375 and 
http://comments.gmane.org/gmane.comp.python.devel/109797.  In the latter, Guido 
pronounced on the matter: no separate values for PYTHONPATH since PYTHONPATH is 
not intended to be used on permanent basis.  Either install distribution 
packages normally (to site-packages) or use a virtual environment.

--

___
Python tracker 

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

[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update

[Steve Dower]

Steve Dower added the comment:

Looks good to me. (In case someone else applies the patch, there are a few 
mixed tab/spaces that should be fixed.)

I'm personally okay with adding this to 3.5, but technically I think it's a new 
feature and should be in 3.6 only. Anyone else have an opinion here?

--
nosy: +paul.moore
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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

Gentlemen, the point is that the name of a function should be all that is 
necessary to unambiguously understand what this method does without having to 
know that it's implemented in terms of collections.Counter or any other 
internal detail like that. That's not a good strategy for picking names in 
computer programming. The name of a function should certainly not be tied to an 
internal implementation detail (use Counter to implement, so let's name it 
"Count"?). Something that asserts the equality of two collections of elements 
is not rocket science and does not deserve an ambiguous name. "Count" is simply 
too ambiguous in this case.

--

___
Python tracker 

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

[issue27085] Make it possible to select return type for os.listdir

[R. David Murray]

R. David Murray added the comment:

The issue of passing an fd is a fair point.

However, converting the filenames to bytes isn't going to help you print them, 
you'll just get decoding errors when converting them to strings instead of 
encoding errors.  You could use the surrogateescape error handler on stdout via 
PYTHONIONENCODING if you want to get the bytes out, but in that case you don't 
need to encode them to bytes yourself, your program can just handle them as 
strings and let the python IO machinery deal with the bytes.

If you really want bytes filenames from listdir with an fd, you can just apply 
os.fsencode to the results:  map(os.fsencode, listdir(fd))

So, I'm still -1 on this proposal.

(Note: there is an existing open issue about surrogateescape and subprocess 
binary streams, so that is a known problem we haven't solved yet, and 
represents a more general problem than this issue.)

--

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[R. David Murray]

R. David Murray added the comment:

Vitaly: if you can come up with a name we agree is more descriptive than the 
current one by a non-trivial margin, we will be happy to listen.  
assertFrequencyCountsEqual is not sufficiently better.  (Personally, I would 
not know what that function did by reading the name.)

--

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

My first expectation for this function was assertUnorderedEqual, but I want to 
avoid problems with renaming (and coexisting of three names of for the same 
function), and I vote for status quo.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update

[Paul Moore]

Paul Moore added the comment:

My instinct is that this should only go into 3.6. It's a remote possibility, 
but someone could otherwise write code that uses REG_DWORD64 and say that it 
"works on 3.5" because they tested on 3.5.x, only to have it fail on 3.5.1.

But if someone with a better feel for the implications wants to say it's OK, I 
wouldn't object.

--

___
Python tracker 

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

[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update

[Mark Grandi]

Mark Grandi added the comment:

why do you say that QWORD is not present in windows.h? 

I found it here: 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx

typedef unsigned __int64 QWORD;

--

___
Python tracker 

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

[issue26779] pdb continue followed by an exception in the same frame shows incorrect frame linenumber

[Sriram Rajagopalan]

Sriram Rajagopalan added the comment:

ping.

Gentle reminder to review the patch

--

___
Python tracker 

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

[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update

[Clement Rouault]

Clement Rouault added the comment:

Because `QWORD` is not defined in any file included by CPython. The main file 
for basic sized type definition in Windows is:

basetsd.h: Type definitions for the basic sized types.

which contains the definition of `DWORD64`: `typedef unsigned __int64 DWORD64, 
*PDWORD64;`
but no reference to `QWORD`. Furthemore the code did not compile with the use 
of `QWORD`.
So, I am pretty sure it is not defined by the standard includes

Other people complain in your link:

> "Apparently, QWORD isn't defined in any of the windows header files for 
MSVC 2010."

Finally, the only files where I could find a typedef for `QWORD` are:

* Include\shared\Sspi.h (Security Support Provider Interface. Prototypes 
and structure definitions)
* Include\um\WinDNS.h (Domain Name System (DNS). DNS definitions and DNS 
API.)
* Include\um\wmcodecdsp.h (COM interface -> generated code)
* Include\um\wmnetsourcecreator.h (COM interface -> generated code)
* Include\um\wmnetsourcecreator.idl (MIDL Interface Definition File)
* Include\um\wmsdkidl.h (COM interface -> generated code)
* Include\um\wmsdkidl.idl (MIDL Interface Definition File)
* Include\um\mfobjects.h (COM interface -> generated code)
* Include\um\Mfobjects.idl (MIDL Interface Definition File)


It seems to be in pretty obscure files that should not be included by CPython 
(In my opinion)

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ethan Furman]

Ethan Furman added the comment:

To change this behavior at this point will require a PEP.  The PEP should be 
something along the lines of "Add proxy support to builtins" and should address 
such things as callable, issubclass, and whatever else is is appropriate.

As for working around your problem now I see a few options:

- write your own `is_proxy_callable` function
- add a `.callable` method to your proxy class
- a `resolve_proxy` function/method which can change the proxy class
  type to whatever is needed to mirror the actual object

--

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

By leaps and bounds, I like assertUnorderedEqual versus assertCountEqual, which 
is terribly misleading. The first, and simplest, thing that comes to my mind 
from the word Count by itself is the count of all elements in a sequence (i.e., 
its length), certainly not frequency count.

I am also happy with the status quo of assertItemsEqual, but I have to agree 
that assertUnorderedEqual removes any ambiguity that assertItemsEqual 
purportedly suffers from. Thank you for suggesting assertUnorderedEqual.

--

___
Python tracker 

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

[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update

[Steve Dower]

Steve Dower added the comment:

IIRC, the preferred typedef is ULONGLONG, but it's not really a big deal. 
Avoiding new header files is a good enough reason.

I think Paul's right about 3.6 only. We shouldn't encourage code that won't 
work downlevel within the same version, and there is a ctypes workaround 
available.

--
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

[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update

[Mark Grandi]

Mark Grandi added the comment:

@hakril: ok, that makes sense, I'm not a windows/win32 programmer by any means 
so I was mostly going on the microsoft web docs

also the patch by hakril includes the documentation from my patch, so that 
patch should be the one considered (as a FYI)

--
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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +georg.brandl, gregory.p.smith, rhettinger

___
Python tracker 

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

[issue27066] SystemError if custom opener returns -1

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

In general LGTM, but I left style comment on Rietveld. And you can use 
assertRaisesRegex in tests if you prefers.

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ionel Cristian Mărieș]

Ionel Cristian Mărieș added the comment:

On Mon, May 23, 2016 at 9:34 PM, Ethan Furman 
wrote:

> "Add proxy support to builtins" and should address such things as
> callable, issubclass, and whatever else is is appropriate.

​As previously stated this builtin is the only one not doing the right
thing. If you think otherwise, please provide proof. I provided plenty of
supporting examples.

Your "working around" is basically saying "don't use​ callable or don't
solve your problem". Not an option.

Let me restate the problem: I want to implement a "proxy that resolves the
target at a later time". That means I can't juggle classes ahead of time
(no `resolve_proxy` or whatever) and I can't tell users "don't use
callable" (what's the point of having a proxy then?).

--

___
Python tracker 

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

[issue27029] Remove support of deprecated mode 'U' in zipfile

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Updated patch addresses Jim's comments.

--
Added file: http://bugs.python.org/file42958/zipfile_remove_deprecated2.patch

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ethan Furman]

Ethan Furman added the comment:

`issubclass` doesn't "do the right thing", as evidenced by another dev.

Continued complaining to this issue is not going to get you what you want, but 
writing a PEP to address the issue might.

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ionel Cristian Mărieș]

Ionel Cristian Mărieș added the comment:

On Mon, May 23, 2016 at 11:04 PM, Ethan Furman 
wrote:

> `issubclass` doesn't "do the right thing", as evidenced by another dev.
>

Hmmm. Technically, in that case, the problem is in
collections.abc.Iterable, not issubclass. I can extent the patch to fix
that too.

Continued complaining to this issue is not going to get you what you want,
> but writing a PEP to address the issue might.
>

Not sure what you're going at here. Are you hinting that you'd support
these changes if there would be a PEP?​

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ethan Furman]

Ethan Furman added the comment:

I'm not against them, but there are many diverse opinions.

A PEP will:

- broaden discussion, so all (or at least most) pros and cons can be
  considered

- highlight any other pieces of Python that would need to change to
  properly support proxies

- get a pronouncement by the BDFL (or a delegate)

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ionel Cristian Mărieș]

Ionel Cristian Mărieș added the comment:

Okay ... is anyone interested in helping with this (reviewing drafts)? Who 
would be the BDFL?

--

___
Python tracker 

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

[issue27094] Floating Point Printing Error with 2+.8553 or 3+.8553

[Seth Norton]

New submission from Seth Norton:

In a basic command line interpreter, adding 2 or 3 to .8553 will cause the 
result to be displayed as if a rounding error occurred. The number is so small 
that I expect it is not a mathematical error but rather in how the number is 
printed.

The displayed answer is 2.85529997.

This also occurs in python 2.7.4. I am running Ubuntu 14.04 (64-bit).

--
components: Interpreter Core
messages: 266183
nosy: Seth Norton
priority: normal
severity: normal
status: open
title: Floating Point Printing Error with 2+.8553 or 3+.8553
type: behavior
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

[issue27094] Floating Point Printing Error with 2+.8553 or 3+.8553

[Seth Norton]

Changes by Seth Norton :


--
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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Gregory P. Smith]

Gregory P. Smith added the comment:

I'm not against adding a new name if it makes glorious sense, but we should not 
remove the old names from unittest as that causes unnecessary pain (based on 
past experience).

assertCountEqual does make sense in terms of the "equivalent to" context from 
the docs.  Thought I agree with you, its meaning is generally not obvious and 
must be looked up to be understood. 
https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertCountEqual

assertUnorderedEqual is a reasonable name, but I don't find significantly 
better than assertCountEqual from a "never read the docs, just reading the 
code" understandability point of view.  It makes me wonder "unordered what?"

that's a vote of -0 for the status quo.

--

___
Python tracker 

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

[issue27094] Floating Point Printing Error with 2+.8553 or 3+.8553

[R. David Murray]

R. David Murray added the comment:

https://docs.python.org/3/tutorial/floatingpoint.html

--
nosy: +r.david.murray
resolution:  -> not a bug
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

[issue27095] Simplify MAKE_FUNCTION

[Demur Rumed]

New submission from Demur Rumed:

Implemented as per 
https://mail.python.org/pipermail/python-dev/2016-April/144135.html

--
files: mkfu.patch
keywords: patch
messages: 266187
nosy: Demur Rumed
priority: normal
severity: normal
status: open
title: Simplify MAKE_FUNCTION
type: performance
Added file: http://bugs.python.org/file42959/mkfu.patch

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

When I read "Unordered", it makes me think of collections, including sequences 
and sets.

--

___
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

[Demur Rumed]

Changes by Demur Rumed :


--
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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[R. David Murray]

R. David Murray added the comment:

Heh.  We could call it 'assertQuotientSetEqual', but most people would have to 
look that up (I did, to find it). 'assertEquivalenceClassesEqual' is a bit 
better, but probably still not clear without looking it up (or being a 
mathematician).

--

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[R. David Murray]

R. David Murray added the comment:

And it suffers the same problem as 'unordered', or even more so, as it implies 
sets, but we aren't dealing with python sets.

See why this is so tough? :)

--

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

Why do you say that "we aren't dealing with python sets"? Try:

import unittest as u
class Test(u.TestCase):
def test_equal_count_of_same_elements(self):
self.assertItemsEqual(set([1,2,3]), set([1,2,3]))


def test_equal_count_of_different_elements(self):
self.assertItemsEqual(set([1,2,3]), set([1,2,4]))


def test_different_count(self):
self.assertItemsEqual(set([1,2,3]), set([1,2,3,4]))
u.main()

--

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

$ python assert_items_equal_test.py 
FF.
==
FAIL: test_different_count (__main__.Test)
--
Traceback (most recent call last):
  File "assert_items_equal_test.py", line 12, in test_different_count
self.assertItemsEqual(set([1,2,3]), set([1,2,3,4]))
AssertionError: Element counts were not equal:
First has 0, Second has 1:  4

==
FAIL: test_equal_count_of_different_elements (__main__.Test)
--
Traceback (most recent call last):
  File "assert_items_equal_test.py", line 8, in 
test_equal_count_of_different_elements
self.assertItemsEqual(set([1,2,3]), set([1,2,4]))
AssertionError: Element counts were not equal:
First has 1, Second has 0:  3
First has 0, Second has 1:  4

--

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

The preceding results are via Python 2.7.10

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ethan Furman]

Ethan Furman added the comment:

The BDFL would be the BDFL  (Guido van Rossum ;) or whomever he asks to do the 
job.

Don't worry too much about drafts.  Pick one of the existing PEPs (409 is 
fairly short), and follow the same type of layouts.  Make your arguments for 
what should be changed and why, then post it to Python-Ideas for initial 
discussion.  As points come up either for or against it you'll add those to 
your draft PEP.  If -Ideas doesn't kill it you can then post your most 
up-to-date draft to Python-Dev for the next round of discussion.

Make sure to have examples of the desired behavior, and decent arguments to 
refute the objections already raised in this issue.

--

___
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]

Changes by Serhiy Storchaka :


--
components: +Interpreter Core
dependencies: +ceval: use Wordcode, 16-bit bytecode
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue27066] SystemError if custom opener returns -1

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

BTW, I may wait to commit this until after we've moved to GitHub. :)

--

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

Same results on Python.org's Python 3.5.1 shell:
>>> class Test(u.TestCase):
... def test_equal_count_of_same_elements(self):
... self.assertCountEqual(set([1,2,3]), set([1,2,3]))
... def test_equal_count_of_different_elements(self):
... self.assertCountEqual(set([1,2,3]), set([1,2,4]))
... def test_different_count(self):
... self.assertCountEqual(set([1,2,3]), set([1,2,3,4]))
... 
>>> u.main()
FF.
==
FAIL: test_different_count (__main__.Test)
--
Traceback (most recent call last):
  File "", line 7, in test_different_count
AssertionError: Element counts were not equal:
First has 0, Second has 1:  4

==
FAIL: test_equal_count_of_different_elements (__main__.Test)
--
Traceback (most recent call last):
  File "", line 5, in test_equal_count_of_different_elements
AssertionError: Element counts were not equal:
First has 1, Second has 0:  3

--

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

With missing last line, this time:

==
FAIL: test_equal_count_of_different_elements (__main__.Test)
--
Traceback (most recent call last):
  File "", line 5, in test_equal_count_of_different_elements
AssertionError: Element counts were not equal:
First has 1, Second has 0:  3
First has 0, Second has 1:  4

--

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

I think that assertUnorderedEqual would contrast nicely with assertSequenceEqual

--

___
Python tracker 

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

[issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED

[Johannes Spangenberg]

Johannes Spangenberg added the comment:

I can confirm this issue. I did run it on Linux SuSE 13.1 (64 Bit). Unlike 
other components, which are installed in `lib/`, `lib-dynload` is installed in 
`lib64/python3.5/`. But `sys.path` still points to `lib/python3.5/lib-dynload`. 
It did run in on :

mkdir build
cd build
../configure --prefix="${HOME}/.opt"
nice -n 19 make -j 6
make install

--
nosy: +Johannes Spangenberg

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Graham Dumpleton]

Graham Dumpleton added the comment:

If someone is going to try and do anything in the area of better proxy object 
support, I hope you will also look at all the work I have done on that before 
for wrapt (https://github.com/GrahamDumpleton/wrapt).

Two related issue this has already found are http://bugs.python.org/issue19072 
and http://bugs.python.org/issue19070.

The wrapt package uses two separate proxy object types. A base ObjectProxy and 
a CallableObjectProxy because of the specific issue with how callable() works.

--

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Gregory P. Smith]

Gregory P. Smith added the comment:

assertUnorderedSequenceEqual would make more sense to me given the natural 
relation to assertSequenceEqual.

We aren't dealing with sets (though sets are valid sequences) as this method 
specifically does not require sequence items to be hashable.  Explicitly 
putting the word sequence in the name makes that more clear.

--

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[R. David Murray]

R. David Murray added the comment:

how about assertSequenceEqualUnordered

--

___
Python tracker 

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

[issue27096] Ability to get random bits from random.Random (as with os.urandom)

[Campbell Barton]

New submission from Campbell Barton:

Currently, getting random bits can be done with os.urandom,

However recently I was faced with having to make a test (with reproducible 
behavior), so I needed to replace os.urandom with a random generator that took 
a seed value.

It turns out there are 3 ways (at least) to handle this, but none are really 
that great.

- Create a list, fill with Random.randint(0, 255), then convert to bytes with 
bytes.join.
- Call Random.getrandbits(), then int.to_bytes.
- Override urandom at a system level (possible on Linux [0]).

While these work, they are either slow (creating a list), non trivial 
(OS-level) or limited - Random.getrandbits hits internal limits of an int, and 
accidentally using the int (running repr on it for example, locks up Python), 
currently CPython will fail to create values above 256mb since bits is limited 
to INT_MAX [1].

In short, to keep tests running fast, and without messing about and accounting 
for internal limits of CPython, there isn't a convenient way to get random bits 
in Python.

Since bits are a primitive type and since its already supported by os.urandom, 
I think its reasonable the random module could support returning random bits.

If this is accepted, I can provide a patch for this, I'm just checking to know 
if the functionality would be accepted.

Suggest to call random.randbits(n).



[0]: 
http://stackoverflow.com/questions/26053875/bypass-dev-urandomrandom-for-testing
[1]: http://bugs.python.org/issue27072

--
components: Library (Lib)
messages: 266202
nosy: ideasman42
priority: normal
severity: normal
status: open
title: Ability to get random bits from random.Random (as with os.urandom)
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

[issue27096] Ability to get random bits from random.Random (as with os.urandom)

[Campbell Barton]

Campbell Barton added the comment:

Correction, meant to write: random.randbytes(n).

--

___
Python tracker 

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

[issue27096] Ability to get random bytes from random.Random (as with os.urandom)

[R. David Murray]

R. David Murray added the comment:

It seems reasonable to me, but I'm not the one to sign off on something like 
this.  I've nosied someone who will have an opinion :)

Would doing:

mybytes = bytes(random.randint(0, 255) for i in range(size))

be faster enough to be workable?  I suppose that might build a list under the 
covers...maybe preallocating a bytearray and filling it with ints would work 
better.

--
nosy: +r.david.murray, rhettinger
title: Ability to get random bits from random.Random (as with os.urandom) -> 
Ability to get random bytes from random.Random (as with os.urandom)

___
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

[Demur Rumed]

Demur Rumed added the comment:

Attached are modifications to the patch based on feedback from Nikita. It 
produces a larger patch tho. The changes are to combine return branches in 
compiler_make_closure & to combine code between compiler_function & 
compiler_lambda into compiler_default_arguments

--
Added file: http://bugs.python.org/file42960/mkfu2.patch

___
Python tracker 

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

[issue27096] Ability to get random bytes from random.Random (as with os.urandom)

[Campbell Barton]

Campbell Barton added the comment:

@r.david.murray, yes, this avoids list creation, but is still quite slow.

To create 1mb of data, you can compare the following:

python -m timeit -s 'from os import urandom' 'print(len(urandom(100)))'

python -m timeit -s 'from random import randint' 
'print(len(bytes(randint(0, 255) for i in range(100'

On my system `os.urandom` is 0.04sec, using randint takes 2.24sec (approx 50x 
slower).

--

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Martin Panter]

Martin Panter added the comment:

assertMultisetEqual?

--
nosy: +martin.panter

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Gregory P. Smith]

Gregory P. Smith added the comment:

assertSequenceEqualUnordered also works R. David.  I was going to suggest that 
as well but edited it out to keep my suggestion simpler. :)

I don't like the assertMultisetEqual suggestion as this is most notably an api 
having nothing to do with sets.

#bikeshed

--

___
Python tracker 

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

[issue27097] ceval: Wordcode follow up, explicit unsigned short read

[Demur Rumed]

New submission from Demur Rumed:

Attached is a patch based off #26647 which converts ceval to read opcode/oparg 
by casting next_instr to an unsigned short. I don't believe we need to 
complicate the code with checking the pointer alignment of the instruction 
stream; some effort must be gone through to generate bytecode off alignment, & 
if the issue comes up it's because someone's using the C API on a CPU that 
doesn't support unaligned reads to generate their own custom bytecode. Anyways 
pybench went from 16.5 on wordcode to 16.0 for me

The change works through replacing NEXTOP/NEXTARG with a NEXTOPARG macro

--
components: Interpreter Core
files: ushort.patch
keywords: patch
messages: 266209
nosy: Demur Rumed
priority: normal
severity: normal
status: open
title: ceval: Wordcode follow up, explicit unsigned short read
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file42961/ushort.patch

___
Python tracker 

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

[issue27093] Silence warning in cjkcodecs.h

[Demur Rumed]

Changes by Demur Rumed :


--
components: +Extension Modules

___
Python tracker 

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

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Vitaly]

Vitaly added the comment:

assertSequenceEqualUnordered is not a good fit, because it doesn't follow the 
de facto naming convention, whereby "Equal" should be the suffix.

Also assertSequenceEqualUnordered would be considered an oxymoron, since the 
word "Sequence" implies ordered, while "Unordered" is the opposite. It's like 
saying "ordered unordered collection".

My vote (if I had one) is still with assertUnorderedEqual. I think that from 
the word "Unordered" it's a reasonable leap that it refers to an unordered 
collection of elements, and it would be easy to remember.

--

___
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)

[Michael Felt]

Michael Felt added the comment:

A bug was found, and has been corrected - but I am unclear on how to best 
submit the differences.

Editing the current "review" code is not a good idea, as there are many 
differences.

Please recommend correct course of action.

p.s. I will have also removed the imports for _ctypes and the use of LIBPATH

--

___
Python tracker 

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