[issue31742] Default to emitting FutureWarning for provisional APIs

[Nick Coghlan]

Nick Coghlan  added the comment:

I think if someone is going to be put off by a FutureWarning, then that 
indicates they're not yet familiar with just what the provisional API status 
means, and those are exactly the folks we *want* to scare away from provisional 
APIs (or features in third party libraries and frameworks that depend on them).

After all, if "Set 'use_provisional_ = True' in __main__" is more of an 
inconvenience than someone is prepared to tolerate to enable warning-free 
access to a still evolving feature, imagine how upset they'd be if we actually 
*did* make a breaking change to that API.

I did realise my draft warning was missing a bit though, which was to explain 
how to turn it off:

import __main__
_feature_flag = f"use_provisional_{__name__}"
if not getattr(__main__, _feature_flag):
import warnings
_provisional_msg = f"The {__name__} module is currently a provisional 
API - see documentation for details. Set '__main__.{_feature_flag} = True' to 
disable this warning."
warnings.warn(FutureWarning, _provisional_msg)

I also revised the draft message to account for Guido's observation about even 
"provisional" APIs being mostly stable by directing folks to the module 
documentation for details. That way the maintainers of the provisional API 
don't need to duplicate their explanation of how provisional the module 
actually is (e.g. the typing docs make it clear that feature additions and API 
changes are currently in scope for maintenance releases, but outright removal 
isn't listed as a possible outcome).

Folks that want to always opt-in to various features in their REPL sessions can 
then set them via PYTHONSTARTUP.

I'll also note here why I'm proposing this as a per-process flag rather than a 
per-module one:

- checking a feature flag in __main__ is easy, checking a flag in the 
"importing module" is hard
- module caching means only the first import would actually run the code to 
emit the warning any way
- we know from experience that having to set per-module __future__ flags to 
access backwards incompatible syntax changes genuinely *is* annoying (to the 
point where we'll implement clever tricks like those Yury came up with for 
native coroutines to avoid needing them)

--

___
Python tracker 

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

[issue31741] backports import path can not be overridden in Windows (Linux works fine)

[Paul Moore]

Paul Moore  added the comment:

The "backports" module you refer to as being in site-packages is not shipped 
with the standard library, it's a 3rd party addon that presumably you installed 
yourself. You'll need to let us know what you did to install it.

You say you manipulate sys.path manually in your code. Please provide:

1. the value of sys.path before you change it.
2. The value of sys.modules.get('backports') before you change sys.path.
3. the value of sys.path after you change it.
4. The value of sys.modules.get('backports') after you change sys.path.

--

___
Python tracker 

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

[issue31735] Documentation incorrectly states how descriptors are invoked

[Henk-Jaap Wagenaar]

Henk-Jaap Wagenaar  added the comment:

"We know this doesn't happen because nothing is printed to stdout."

Try running Obj().d, you will get output.

Obj.d does not work because it is on a *class*, and so it runs, per the docs:

'Obj.__dict__['d'].__get__(None, Obj)'

whereas you consider running it on an instance to get:

b = Obj()
b.d
# equivalent to
type(b).__dict__['d'].__get__(b, type(b))

and you will get output twice.

[Note, on python2 you will get an error, I think this is because your class 
does not inherit from object.]

--

___
Python tracker 

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

[issue31735] Documentation incorrectly states how descriptors are invoked

[Henk-Jaap Wagenaar]

Henk-Jaap Wagenaar  added the comment:

I do think though that

"If d defines the method __get__(), then d.__get__(obj) is invoked according to 
the precedence rules listed below."

seems to contain a mistake in that it should have

d.__get__(obj, type(obj)) instead of d.__get__(obj)

--

___
Python tracker 

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

[issue31415] Add -X option to show import time

[STINNER Victor]

STINNER Victor  added the comment:


New changeset a997c7b434631f51e00191acea2ba6097691e859 by Victor Stinner in 
branch 'master':
bpo-31415: Add _PyTime_GetPerfCounter() and use it for -X importtime (#3936)
https://github.com/python/cpython/commit/a997c7b434631f51e00191acea2ba6097691e859


--

___
Python tracker 

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

[issue31743] Proportional Width Font on Generated Python Docs PDFs

[Ante Perić]

New submission from Ante Perić :

Fonts in the generated documentation PDFs, for all Python versions, are 
proportional width in code blocks, unlike in HTML version, where they are 
fixed-width.

Example https://docs.python.org/2.7/archives/python-2.7.14-docs-pdf-a4.zip

--
assignee: docs@python
components: Documentation
files: Screenshot 2017-10-10 12.41.34.png
messages: 304024
nosy: docs@python, synthmeat
priority: normal
severity: normal
status: open
title: Proportional Width Font on Generated Python Docs PDFs
type: enhancement
versions: Python 2.7
Added file: https://bugs.python.org/file47203/Screenshot 2017-10-10 12.41.34.png

___
Python tracker 

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

[issue31744] Python 2.7.14 Fails to compile on CentOS/RHEL7

[Brian Sidebotham]

New submission from Brian Sidebotham :

I am getting the following error when trying to compile Python 2.7.14 (and 
previous 2.7 versions) on CentOS and RHEL7.

The main problem is that CONFIG_ARGS does not exist. I've included the build. 
This RPATH is correct - it has to go through the RPM SPEC file so needs 
escaping like this to work.

Python 3.6.2 builds find like this, but Python 2.7 is failing to build. Have I 
missed something?

LDFLAGS='-Wl,-rpath=$\\$$ORIGIN/../lib' \
./configure --prefix=/opt/wsl \
--enable-shared \
--with-system-ffi \
--with-ensurepip=yes \
--enable-optimizations

...

ranlib libpython2.7.a
Modules/posixmodule.o: In function `posix_tmpnam':
/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14/./Modules/posixmodule.c:7642:
 warning: the use of `tmpnam_r' is dangerous, better use `mkstemp'
Modules/posixmodule.o: In function `posix_tempnam':
/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14/./Modules/posixmodule.c:7589:
 warning: the use of `tempnam' is dangerous, better use `mkstemp'
gcc -pthread -Wl,-rpath=RIGIN/../lib -fprofile-generate  -Xlinker 
-export-dynamic -o python \
Modules/python.o \
-L. -lpython2.7 -lpthread -ldl  -lutil   -lm  
LD_LIBRARY_PATH=/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14
 ./python -E -S -m sysconfig --generate-posix-vars ;\
if test $? -ne 0 ; then \
echo "generate-posix-vars failed" ; \
rm -f ./pybuilddir.txt ; \
exit 1 ; \
fi
Traceback (most recent call last):
  File "./setup.py", line 33, in 
COMPILED_WITH_PYDEBUG = ('--with-pydebug' in 
sysconfig.get_config_var("CONFIG_ARGS"))
TypeError: argument of type 'NoneType' is not iterable
make[2]: *** [sharedmods] Error 1
make[2]: Leaving directory 
`/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14'
make[1]: *** [build_all_generate_profile] Error 2
make[1]: Leaving directory 
`/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14'
make: *** [profile-opt] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.sFvDid (%build)





-bash-4.2# cd build/lib.linux-x86_64-2.7/
-bash-4.2# ls
_sysconfigdata.py  _sysconfigdata.pyc
-bash-4.2# cat _sysconfigdata.py
# system configuration generated and used by the sysconfig module
build_time_vars = {'AC_APPLE_UNIVERSAL_BUILD': 0,
 'AIX_GENUINE_CPLUSPLUS': 0,
 'AR': 'ar',
 'ARFLAGS': 'rc',
 'ATHEOS_THREADS': 0,
 'BASECFLAGS': '-fno-strict-aliasing',
 'BASEMODLIBS': '',
 'BEOS_THREADS': 0,
 'BINDIR': '/opt/wsl/bin',
 'BINLIBDEST': '/opt/wsl/lib/python2.7',
 'BLDLIBRARY': '-L. -lpython2.7',
 'BLDSHARED': 'gcc -pthread -shared -Wl,-rpath=RIGIN/../lib -fprofile-generate',
 'BUILDEXE': '',
 'BUILDPYTHON': 'python',
 'CC': 'gcc -pthread',
 'CCSHARED': '-fPIC',
 'CFLAGS': '-fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall 
-Wstrict-prototypes',
 'CFLAGSFORSHARED': '-fPIC',
 'CONFIGFILES': 'configure configure.ac acconfig.h pyconfig.h.in 
Makefile.pre.in',
 'CONFINCLUDEDIR': '/opt/wsl/include',
 'CONFINCLUDEPY': '/opt/wsl/include/python2.7',
 'COREPYTHONPATH': ':plat-linux2:lib-tk:lib-old',
 'COVERAGE_INFO': 
'/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14/coverage.info',
 'COVERAGE_REPORT': 
'/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14/lcov-report',
 'COVERAGE_REPORT_OPTIONS': '--no-branch-coverage --title "CPython lcov 
report"',
 'CPPFLAGS': '-I. -IInclude -I./Include',
 'CXX': 'g++ -pthread',
 'C_THREADS': 0,
 'DESTDIRS': '/opt/wsl /opt/wsl/lib /opt/wsl/lib/python2.7 
/opt/wsl/lib/python2.7/lib-dynload',
 'DESTLIB': '/opt/wsl/lib/python2.7',
 'DESTPATH': '',
 'DESTSHARED': '/opt/wsl/lib/python2.7/lib-dynload',
 'DIRMODE': 755,
 'DIST': 'README ChangeLog configure configure.ac acconfig.h pyconfig.h.in 
Makefile.pre.in Include Lib Misc Demo Ext-dummy',
 'DISTDIRS': 'Include Lib Misc Demo Ext-dummy',
 'DISTFILES': 'README ChangeLog configure configure.ac acconfig.h pyconfig.h.in 
Makefile.pre.in',
 'DLINCLDIR': '.',
 'DLLLIBRARY': '',
 'DOUBLE_IS_ARM_MIXED_ENDIAN_IEEE754': 0,
 'DOUBLE_IS_BIG_ENDIAN_IEEE754': 0,
 'DOUBLE_IS_LITTLE_ENDIAN_IEEE754': 1,
 'DYNLOADFILE': 'dynload_shlib.o',
 'ENABLE_IPV6': 1,
 'ENSUREPIP': 'upgrade',
 'EXE': '',
 'EXEMODE': 755,
 'EXTRAMACHDEPPATH': '',
 'EXTRAPLATDIR': '',
 'EXTRATESTOPTS': '',
 'EXTRA_CFLAGS': '',
 'FILEMODE': 644,
 'FLOCK_NEEDS_LIBBSD': 0,
 'GETPGRP_HAVE_ARG': 0,
 'GETTIMEOFDAY_NO_TZ': 0,
 'GITBRANCH': '',
 'GITTAG': '',
 'GITVERSION': '',
 'GLHACK': '-Dclear=__GLclear',
 'GNULD': 'yes',
 'HAVE_ACOSH': 1,
 'HAVE_ADDRINFO': 1,
 'HAVE_ALARM': 1,
 'HAVE_ALLOCA_H': 1,
 'HAVE_ALTZONE': 0,
 'HAVE_ASINH': 1,
 'HAVE_ASM_TYPES_H': 1,
 'HAVE_ATANH': 1,
 'HAVE_ATTRIBUTE_FORMAT_PARSETUPLE': 0,
 'HAVE_BIND_TEXTDOMAIN_CODESET': 1,
 'HAVE_BLUETOOTH_BLUETOOTH_H': 0,
 'HAVE_BLUETOOTH_H': 0,
 'HAVE_BROKEN_NICE': 0,
 'HAVE_BROKEN_PIPE_BUF': 0,
 'HAVE_BROKEN_POLL': 0,
 'HAVE_BROKEN_POSIX_SE

[issue31415] Add -X option to show import time

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +3914

___
Python tracker 

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

[issue30008] OpenSSL 1.1.0 deprecated functions

[Mark Wright]

Change by Mark Wright :


--
pull_requests: +3915

___
Python tracker 

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

Re: [issue31744] Python 2.7.14 Fails to compile on CentOS/RHEL7

[M.-A. Lemburg]

I'm not sure whether this is related, but your quoting for --rpath
doesn't appear to work:

On 10.10.2017 14:17, Brian Sidebotham wrote:
> LDFLAGS='-Wl,-rpath=$\\$$ORIGIN/../lib' \
> ...
> gcc -pthread -Wl,-rpath=RIGIN/../lib -fprofile-generate  -Xlinker 
> -export-dynamic -o python \
>   Modules/python.o \
>   -L. -lpython2.7 -lpthread -ldl  -lutil   -lm  

The CONFIG_ARGS variable should always be set, so I assume that
your _sysconfigdata.py was generated in a previous broken build.

-- 
Marc-Andre Lemburg
eGenix.com

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

[issue30008] OpenSSL 1.1.0 deprecated functions

[Mark Wright]

Mark Wright  added the comment:

Thanks, I opened
https://github.com/python/cpython/pull/3943
for the rest of the changes (on top of your changes in
https://github.com/python/cpython/pull/3934)
to allow it to compile with OpenSSL 1.1.0f compiled with
disable-deprecated.

--

___
Python tracker 

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[R. David Murray]

R. David Murray  added the comment:

I think there needs to be an easy way to turn off the warnings while running 
tests, as well.  I don't want to be bothered by those messages when testing 
parts of my package that are consciously using the provisional features.

But really, I agree with Guido: if this were opt in, and set on by default in 
test harnesses like unittest, that would make sense to me.  Otherwise I think 
we'll be revisiting some of the pain that caused us to make deprecation 
warnings silent by default.

If you don't have tests for your code you should be expecting it to break 
eventually anyway :)

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[Amber Brown]

Amber Brown  added the comment:

What is the point of an opt-in warning, when the entire point of the proposed 
warning is letting people know that they may be using something they are not 
fully educated or informed about the ramifications of using? If you know to 
turn on the warning, you know to check the list of provisional modules, or know 
that provisional modules exist in the first place.

--

___
Python tracker 

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[R. David Murray]

R. David Murray  added the comment:

That's why I said set on by default by the test harnesses. The opt in would be 
done by the standard testing tools, not directly by the programmer.  That's how 
deprecation warnings work now.

--

___
Python tracker 

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I don't think that a special way for silencing FutureWarning is needed. You can 
use an existing mechanism.

import warnings
warnings.filterwarnings('ignore', '', FutureWarning, 'typing')

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[Amber Brown]

Amber Brown  added the comment:

So you're proposing a coordinated effort across the half dozen, possibly more, 
test runners to enable some flags, so CPython doesn't log a single message, 
possibly two, that you're using unsupported experimental software with no 
backwards compatibility guarantee?

I think the warnings control setting there could be a good solution for your "I 
don't care, don't show the warning" use case, but I also think explicit 
disabling per module is a better solution to recommend to users (since we might 
know that we're using typing, and we say "we are okay with using typing", but 
might not realise that we're silencing a new provisional module used by an 
updated library sometime in the future).

--

___
Python tracker 

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[Nick Coghlan]

Nick Coghlan  added the comment:

Deprecation warnings were different: we turned those off by default because 
currently working applications could start emitting console warnings simply 
because an end user ran them on a newer version of Python.

With future warnings, we're instead trying to detect cases where:

* a user has heard about a cool new Python standard library API, starts trying 
it out, but has no idea yet that it isn't covered by our regular backwards 
compatibility assurances. If they're a beginner or a corporation, this is 
setting them up for potential problems without any clear indication they might 
be doing something they may want to reconsider
* you upgraded a dependency and it started relying on a provisional API, and 
you'd prefer to stick with the old version rather than risking relying on the 
provisional interface

Neither of those situations can be encountered simply by running an existing 
*application* on a newer version of Python (assuming the application bundles 
all of its dependencies other than the runtime itself).

Neither of them is helped by an opt-in flag either, since the scenarios we're 
trying to detect include the affected user either:

1. Not knowing about provisional APIs at all;
2. Not knowing that *that particular* API is provisional; or
3. Not knowing that a dependency on that particular API has been introduced

Since the warning would be emitted through the regular warnings machinery, all 
those options would be available to turn it off, but there'd also be the even 
more convenient option of just setting "use_provisional_typing = True" in 
__main__ and leaving the warnings settings alone.

It's clear to me from both Guido's and David's confusion that this idea is 
going to need to go through the PEP process though, which is probably a 
reasonable thing to do anyway (since one of the outcomes would be an amendment 
to PEP 411 to include the programmatic warning mechanism).

--

___
Python tracker 

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[R. David Murray]

R. David Murray  added the comment:

I imagine we could make it controlled by the same setting that controls 
deprecation warnings, with some way to differentiate them if you really need 
to.  I forget exactly how that warning control works, so maybe that would be 
awkward, but I wouldn't be surprised if it was relatively easy.  That way test 
runners would automatically be enabling the warning without having to do 
anything.  (If a test runner isn't already automatically enabling deprecation 
warnings, then I doubt it will want to automatically enable future warnings).

--

___
Python tracker 

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

[issue31705] test_sha256 from test_socket fails on ppc64le arch

[STINNER Victor]

STINNER Victor  added the comment:

Charalampos Stratakis: "Attaching the strace output."

Oh thanks! I guess tha the interesting syscalls are:

socket(AF_ALG, SOCK_SEQPACKET|SOCK_CLOEXEC, 0) = 3
bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
accept4(3, NULL, NULL, SOCK_CLOEXEC)= 4
send(4, "abc", 3, 0)= -1 ENOKEY (Required key not available)
close(4)= 0

test_socket calls bind() with typ='hash', name='sha256', but in the strace, I 
only see 'hash'.

strace is maybe outdated and fails to display the full bind() address, or 
Python doesn't serialize correctly the address.

--

On my Fedora 26, I see sha256 in the bind call:

socket(AF_ALG, SOCK_SEQPACKET|SOCK_CLOEXEC, 0) = 3
bind(3, {sa_family=AF_ALG, 
sa_data="hash\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0sha256\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"},
 88) = 0
accept4(3, NULL, NULL, SOCK_CLOEXEC)= 4
sendto(4, "abc", 3, 0, NULL, 0) = 3
recvfrom(4, 
"\272x\26\277\217\1\317\352AA@\336]\256\"#\260\3a\243\226\27z\234\264\20\377a\362\0\25\255",
 512, 0, NULL, NULL) = 32
close(4)= 0
accept4(3, NULL, NULL, SOCK_CLOEXEC)= 4
sendto(4, "a", 1, MSG_MORE, NULL, 0)= 1
sendto(4, "b", 1, MSG_MORE, NULL, 0)= 1
sendto(4, "c", 1, MSG_MORE, NULL, 0)= 1
sendto(4, "", 0, 0, NULL, 0)= 0
recvfrom(4, 
"\272x\26\277\217\1\317\352AA@\336]\256\"#\260\3a\243\226\27z\234\264\20\377a\362\0\25\255",
 512, 0, NULL, NULL) = 32
close(4)= 0
close(3)= 0

--

___
Python tracker 

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

[issue31705] test_sha256 from test_socket fails on ppc64le arch

[STINNER Victor]

STINNER Victor  added the comment:

> strace is maybe outdated and fails to display the full bind() address,

I vote for this option since I see addrlen=88 in both examples.

--

___
Python tracker 

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

[issue31719] [2.7] test_regrtest.test_crashed() fails on s390x

[STINNER Victor]

STINNER Victor  added the comment:

> Why not use just abort() or Py_FatalError()?

I try to test how a real program crash, like a real invalid memory read. Maybe 
it doesn't matter much here.

--

___
Python tracker 

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

[issue26546] Provide translated french translation on docs.python.org

[STINNER Victor]

STINNER Victor  added the comment:

Since you closed the issue, Julien, I changed the status of the PEP 545 to 
Final:
https://github.com/python/peps/commit/14092e51dea5c5c6391458da4a2ad92adad227b9

--

___
Python tracker 

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[R. David Murray]

R. David Murray  added the comment:

Nick says: "Neither of those situations can be encountered simply by running an 
existing *application* on a newer version of Python". 

I fail to see the operational difference between running an application on a 
newer version of Python and doing a pip --upgrade or yum update and then 
running the application.  So that argument boils down to "this warning should 
be on by default", which is what we are discussing :)

I'm happy to leave this to the PEP process.

--

___
Python tracker 

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[Nick Coghlan]

Nick Coghlan  added the comment:

A note regarding *only* using the warnings module to turn things off:

The problem I have with that is that the UX is relatively clumsy, and hence 
runs into the concern Guido mentions above: "having this warning pop up every 
time you import a provisional module while developing code feels like 
harassment of the very users we'd like to try out the provisional APIs."

By contrast, "To rely on this provisional feature without getting a runtime 
FutureWarning, set this application level feature flag in your __main__ module" 
feels like exactly the right level of affirmative agreement to me - the 
equivalent of clicking through a confirmation dialog, or ticking an "I agree" 
check box on a form.

Libraries registering that agreement on behalf of their users would then always 
be inappropriate, while whether or not it was appropriate for a framework to do 
it would depend on the framework and the feature.

--

___
Python tracker 

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[Nick Coghlan]

Nick Coghlan  added the comment:

The deprecation warnings weren't turned off due to Python developers running 
things in virtual environments - they were turned off due to Linux distros 
upgrading their system Python runtimes, and Linux ISVs getting an influx of new 
bug reports from their users.

So the cases of relevance were ones where all the app dependencies were bundled 
*except* the runtime itself.

By contrast, one of the things we *want* to warn about in this case is folks 
acquiring transitive dependencies on provisional APIs that they may not want to 
depend on.

--

___
Python tracker 

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

[issue31744] Python 2.7.14 Fails to compile on CentOS/RHEL7

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

Which CentOS/RHEL version do you have?

Could you provide the output of 'cat /etc/redhat-release' ?

--
nosy: +cstratak

___
Python tracker 

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

[issue31705] test_sha256 from test_socket fails on ppc64le arch

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

Indeed the version of strace is 'strace-4.12-4.el7'.

I will try to provide output from the latest one.

--

___
Python tracker 

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

[issue31745] Overloading "Py_GetPath" does not work

[Kay Hayen]

New submission from Kay Hayen :

Hello,

for my Python compiler Nuitka, I want to make sure that compiled binaries in 
standalone mode do not access the original installation, but solely the 
distribution folder created.

I am using the new API Py_SetPath on Python3 and it works fine. The Python2.7 
documentation of the C-API however says: 

The embedding application can steer the search by calling 
Py_SetProgramName(file) before calling Py_Initialize(). Note that PYTHONHOME 
still overrides this and PYTHONPATH is still inserted in front of the standard 
path. An application that requires total control has to provide its own 
implementation of Py_GetPath(), Py_GetPrefix(), Py_GetExecPrefix(), and 
Py_GetProgramFullPath() (all defined in Modules/getpath.c).

My attempts at overloading this have badly failed, because of conflicting 
"declspec" (dllimport vs dllexport). And when defining Py_GetPath away before 
making the include, so the conflict is not seen by the MSVC compiler, the 
result is that the function is not called. 
Is this known to work? Can you point me to a working example, because my 
searches didn't reveal anything. Not normal web search, nor global code search 
for Py_GetPath code.

I did not try on Linux yet. I am assuming it might work, I just wanted to tap 
on knowledge on your side. Is it feasible. For Linux? For Windows?

Thanks,
Kay Hayen

--
components: Build
messages: 304045
nosy: kayhayen
priority: normal
severity: normal
status: open
title: Overloading "Py_GetPath" does not work
type: behavior
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

[issue31744] Python 2.7.14 Fails to compile on CentOS/RHEL7

[Iryna Shcherbina]

Change by Iryna Shcherbina :


--
nosy: +ishcherb

___
Python tracker 

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

[issue31744] Python 2.7.14 Fails to compile on CentOS/RHEL7

[Ned Deily]

Ned Deily  added the comment:

Do you already have an existing version of Python 2.7 installed at the prefix 
location /opt/ws1?  Because you are attempting to build with --enable-shared, 
the build may be picking up the already installed shared library.  Try building 
without --enable-shared or with a unique prefix location and see if it works 
then.

--
nosy: +ned.deily -ishcherb

___
Python tracker 

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

[issue31744] Python 2.7.14 Fails to compile on CentOS/RHEL7

[Ned Deily]

Change by Ned Deily :


--
nosy: +ishcherb

___
Python tracker 

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

[issue31740] refleaks when calling sqlite3.Connection.__init__() more than once

[Oren Milman]

Change by Oren Milman :


--
keywords: +patch
pull_requests: +3917
stage:  -> patch review

___
Python tracker 

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

[issue31746] crashes in sqlite3.Connection in case it is uninitialized or partially initialized

[Oren Milman]

New submission from Oren Milman :

The following code causes a crash:
import sqlite3
connection = sqlite3.Connection.__new__(sqlite3.Connection)
connection.isolation_level

This is because pysqlite_connection_get_isolation_level() doesn't check whether
the Connection object is initialized.
pysqlite_connection_close() also doesn't check that, so we would get a crash
also if we replaced `connection.isolation_level` with `connection.close()`.

pysqlite_connection_set_isolation_level() doesn't crash in case of an
uninitialized Connection object, but it also doesn't raise an error, and IMHO
it should.


The following code causes a crash, too:
import sqlite3
try:
connection = sqlite3.Connection.__new__(sqlite3.Connection)
connection.__init__('', isolation_level='invalid isolation level')
except ValueError:
pass

connection.cursor()

This is because `self->initialized` is set to 1 in the beginning of
pysqlite_connection_init(), so after it fails, we are left with a partially
initialized Connection object whose `self->initialized` is 1. Thus,
pysqlite_connection_cursor() thinks that the Connection object is initialized.
Eventually pysqlite_connection_register_cursor() is called, and it crashes
while trying to append to `connection->cursors`, which is NULL.

--
components: Extension Modules
messages: 304047
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: crashes in sqlite3.Connection in case it is uninitialized or partially 
initialized
type: crash
versions: Python 3.7

___
Python tracker 

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

[issue31740] refleaks when calling sqlite3.Connection.__init__() more than once

[Oren Milman]

Oren Milman  added the comment:

(opened bpo-31746 for the crashes i mentioned)

--

___
Python tracker 

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

[issue6135] subprocess seems to use local encoding and give no choice

[Andrew Clegg]

Andrew Clegg  added the comment:

The commit for this bug (720f0cf580e2) introduces encoding and errors arguments 
but doesn't actually document what the values of these should be. In the case 
of the encoding it could be reasonably guessed, but the only way to determine 
what the value of 'errors' should be is to make the logical leap and look at 
the TextIOWrapper doc page.

And in reply to message #274510, there certainly should be a 'text=True' 
argument added. There are countless use cases where text rather than bytes is 
the expected behaviour, and currently this has to be triggered by using a more 
obscure option. In any case, it could be argued that text should be returned 
when shell=True since this mimics the behaviour of any shell program. 

(Sorry if adding a comment to a closed bug is poor etiquette; it seemed like 
the best place to put this comment)

--
nosy: +andrewclegg

___
Python tracker 

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

[issue31747] fatal error LNK1120 in PCbuild\python3dll.vcxproj

[Denis Osipov]

New submission from Denis Osipov :

Since today (2017-10-10) I have compile error on Windows 10:

$ PCbuild/build.bat -e -d -p x64
Using py -3.6 (found with py.exe)
Fetching external libraries...
bzip2-1.0.6 already exists, skipping.
sqlite-3.14.2.0 already exists, skipping.
xz-5.2.2 already exists, skipping.
zlib-1.2.11 already exists, skipping.
Fetching external binaries...
openssl-bin-1.1.0f already exists, skipping.
tcltk-8.6.6.0 already exists, skipping.
Finished.
Using "C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\\MSBuild\15.0\Bin\msbuild.exe" (found in the Visual 
Studio 2017 registry)

D:\repos\cpython>"C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\\MSBuild\15.0\Bin\msbuild.exe" 
"D:\repos\cpython\PCbuild\pcbuild.proj" /t:Build /m /nologo /v:m 
/p:Configuration=Debug /p:Platform=x64 /p:IncludeExternals=true 
/p:IncludeSSL=true /p:IncludeTkinter=true /p:UseTestMarker= /p:GIT="C:\Program 
Files\Git\mingw64\bin\git.exe"
  Killing any running python_d.exe instances...
  Getting build info from "C:\Program Files\Git\mingw64\bin\git.exe"
  Building heads/master:a997c7b434 master
  pythoncore.vcxproj -> D:\repos\cpython\PCbuild\amd64\python37_d.dll
  pythoncore.vcxproj -> D:\repos\cpython\PCbuild\amd64\python37_d.pdb (Full PDB)
  _ctypes_test.vcxproj -> D:\repos\cpython\PCbuild\amd64\_ctypes_test_d.pyd
  _ctypes_test.vcxproj -> D:\repos\cpython\PCbuild\amd64\_ctypes_test_d.pdb 
(Full PDB)
  _testbuffer.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testbuffer_d.pyd
  _testbuffer.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testbuffer_d.pdb (Full 
PDB)
  _testcapi.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testcapi_d.pyd
  _testcapi.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testcapi_d.pdb (Full PDB)
  _testembed.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testembed_d.exe
  _testembed.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testembed_d.pdb (Full 
PDB)
  _testimportmultiple.vcxproj -> 
D:\repos\cpython\PCbuild\amd64\_testimportmultiple_d.pyd
  _testimportmultiple.vcxproj -> 
D:\repos\cpython\PCbuild\amd64\_testimportmultiple_d.pdb (Full PDB)
  _testmultiphase.vcxproj -> 
D:\repos\cpython\PCbuild\amd64\_testmultiphase_d.pyd
  _testmultiphase.vcxproj -> 
D:\repos\cpython\PCbuild\amd64\_testmultiphase_d.pdb (Full PDB)
  _testconsole.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testconsole_d.pyd
  _testconsole.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testconsole_d.pdb 
(Full PDB)
  pylauncher.vcxproj -> D:\repos\cpython\PCbuild\amd64\py_d.exe
  pylauncher.vcxproj -> D:\repos\cpython\PCbuild\amd64\py_d.pdb (Full PDB)
  pywlauncher.vcxproj -> D:\repos\cpython\PCbuild\amd64\pyw_d.exe
  pywlauncher.vcxproj -> D:\repos\cpython\PCbuild\amd64\pyw_d.pdb (Full PDB)
  pyshellext.vcxproj -> D:\repos\cpython\PCbuild\amd64\pyshellext_d.dll
  pyshellext.vcxproj -> D:\repos\cpython\PCbuild\amd64\pyshellext_d.pdb (Full 
PDB)
 Создается библиотека D:\repos\cpython\PCbuild\amd64\python3_dstub.lib и 
объект D:\repos\cpython\PCbuild\amd64\python3_dstub.exp
  _asyncio.vcxproj -> D:\repos\cpython\PCbuild\amd64\_asyncio_d.pyd
  _asyncio.vcxproj -> D:\repos\cpython\PCbuild\amd64\_asyncio_d.pdb (Full PDB)
  _ctypes.vcxproj -> D:\repos\cpython\PCbuild\amd64\_ctypes_d.pyd
  _ctypes.vcxproj -> D:\repos\cpython\PCbuild\amd64\_ctypes_d.pdb (Full PDB)
  _decimal.vcxproj -> D:\repos\cpython\PCbuild\amd64\_decimal_d.pyd
  _decimal.vcxproj -> D:\repos\cpython\PCbuild\amd64\_decimal_d.pdb (Full PDB)
  LINK : не найден или не выполнена сборка 
D:\repos\cpython\PCbuild\amd64\python3_d.dll при последней инкрементной 
компоновке; выполняется полная компоновка
  _elementtree.vcxproj -> D:\repos\cpython\PCbuild\amd64\_elementtree_d.pyd
  _elementtree.vcxproj -> D:\repos\cpython\PCbuild\amd64\_elementtree_d.pdb 
(Full PDB)
python3_d.def : error LNK2001: неразрешенный внешний символ 
"PyThread_tss_alloc" [D:\repos\cpython\PCbuild\python3dll.vcxproj]
python3_d.def : error LNK2001: неразрешенный внешний символ 
"PyThread_tss_create" [D:\repos\cpython\PCbuild\python3dll.vcxproj]
python3_d.def : error LNK2001: неразрешенный внешний символ 
"PyThread_tss_delete" [D:\repos\cpython\PCbuild\python3dll.vcxproj]
python3_d.def : error LNK2001: неразрешенный внешний символ "PyThread_tss_free" 
[D:\repos\cpython\PCbuild\python3dll.vcxproj]
python3_d.def : error LNK2001: неразрешенный внешний символ "PyThread_tss_get" 
[D:\repos\cpython\PCbuild\python3dll.vcxproj]
python3_d.def : error LNK2001: неразрешенный внешний символ 
"PyThread_tss_is_created" [D:\repos\cpython\PCbuild\python3dll.vcxproj]
python3_d.def : error LNK2001: неразрешенный внешний символ "PyThread_tss_set" 
[D:\repos\cpython\PCbuild\python3dll.vcxproj]
D:\repos\cpython\PCbuild\amd64\python3_d.lib : fatal error LNK1120: 
неразрешенных внешних элементов: 7 [D:\repos\cpython\PCbuild\python3dll.vcxproj]
  _multiprocessing.vcxproj -> 
D:\repos\cpython\PCbuild\amd64\_multiprocessing_d.pyd
  _multiprocessing.vcxproj -> 
D:\repos\cpython\PCbuild\amd64\_multiprocessing_d.pd

[issue31705] test_sha256 from test_socket fails on ppc64le arch

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

Attaching the output of:

strace -s 128 -e trace=%network -o trace ./python3 -m test -v test_socket -m 
test_sha256

using the latest version of strace (4.19).

--
Added file: https://bugs.python.org/file47204/trace2

___
Python tracker 

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

[issue31672] string.Template should use re.ASCII flag

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

On Oct 6, 2017, at 15:04, Serhiy Storchaka  wrote:
> Serhiy Storchaka  added the comment:
> 
> Another solution (works in 3.6 too): set idpattern to 
> r'(?-i:[_a-zA-Z][_a-zA-Z0-9]*)'.
> 
> This looks pretty weird, setting the re.IGNORECASE flag and then unsetting 
> it. But it works, and don't break the user code that changes idpattern 
> without changing flags.

Oh, I think I like that :)

--

___
Python tracker 

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

[issue31672] string.Template should use re.ASCII flag

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

With some comments to clarify of course.

--

___
Python tracker 

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

[issue31314] email throws exception with oversized header input

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

PR 3938 fixes this issue, but I'm wondering why self._split() returns an empty 
list only for long header names.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue14369] make __closure__ writable

[Devin Bayer]

Change by Devin Bayer :


--
nosy: +akvadrako

___
Python tracker 

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[Guido van Rossum]

Guido van Rossum  added the comment:

I have no bandwidth for this discussion, but so far I am not convinced. What 
happened to "consenting adults"?

> [...] the entire point of the proposed warning letting people know that they 
> may be using something they are not fully educated or informed about the 
> ramifications of using

That describes most of the Python experience. :-)

I think you all should lighten up. It really sounds like a classic case of 
someone who was bitten badly by some obscure aspect of an API and then 
overreacts.

If the warning in the docs does not grab enough attention, change the text or 
formatting of that warning.

--

___
Python tracker 

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

[issue14369] make __closure__ writable

[Devin Bayer]

Devin Bayer  added the comment:

Any updates on this? I'm trying to implement hot module reloading using code 
from IPython, which tries to modify __closure__ in place. It fails silently and 
doesn't work, but indeed would be nice to have.

--

___
Python tracker 

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[Donald Stufft]

Donald Stufft  added the comment:

> What happened to "consenting adults"?

Making sure they're actually consenting when getting into something that might 
potentially bite them in the ass seems like a sane and thoughtful thing to do 
to me.

--

___
Python tracker 

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

[issue31733] [2.7] Add PYTHONSHOWREFCOUNT environment variable to Python 2.7

[Charalampos Stratakis]

Change by Charalampos Stratakis :


--
nosy: +cstratak

___
Python tracker 

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

[issue1927] Change input() to always prompt to stderr

[Carvell Scott]

Change by Carvell Scott :


--
nosy: +Carvell Scott

___
Python tracker 

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

[issue31747] fatal error LNK1120 in PCbuild\python3dll.vcxproj

[Denis Osipov]

Denis Osipov  added the comment:

Oops... I've tried to rebuild, it didn't help. But after deleting folder 
cpython\PCbuild\amd64 everything works well again.

Sorry for false alarm.

--
resolution:  -> works for me
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

[issue31748] Modules/posixmodule.c: skip compiling jka4NaPmmQ37 and posix_fildes_fd

[Дилян Палаузов]

New submission from Дилян Палаузов :

These are needed only sometimes.

diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -1466,6 +1466,7 @@ path_error2(path_t *path, path_t *path2)
 
 /* POSIX generic methods */
 
+#if defined(HAVE_FSYNC) || defined(HAVE_FDATASYNC) || defined(HAVE_FCHDIR)
 static int
 fildes_converter(PyObject *o, void *p)
 {
@@ -1495,6 +1496,7 @@ posix_fildes_fd(int fd, int (*func)(int))
 return (!async_err) ? posix_error() : NULL;
 Py_RETURN_NONE;
 }
+#endif
 
 
 #ifdef MS_WINDOWS

--
components: Build
messages: 304059
nosy: dilyan.palauzov
priority: normal
severity: normal
status: open
title: Modules/posixmodule.c: skip compiling jka4NaPmmQ37 and posix_fildes_fd
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue6135] subprocess seems to use local encoding and give no choice

[Steve Dower]

Steve Dower  added the comment:

> The commit for this bug (720f0cf580e2) introduces encoding and errors 
> arguments but doesn't actually document what the values of these should be

Do you mean it doesn't document that they take the normal encoding/errors 
arguments that all the other functions that do character encoding take? Or they 
don't specify which encoding you should use? The latter is not feasible, and if 
you mean the former then feel free to open a new issue for documentation.

Having a single "text" parameter is essentially what we had before - a magic 
option that modifies your data without giving you any ability to do it 
correctly. This change brought Popen in line with all the other places where we 
translate OS-level bytes into Python str, and it's done it in exactly the same 
way.

Also see msg274562 where Nick withdraws his own suggestion of a "text" 
parameter.

--

___
Python tracker 

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

[issue31749] Request: Human readable byte amounts in the standard library

[Rich]

New submission from Rich :

This problem is an _extremely_ common one, a problem that almost any Python 
project of a reasonable size will encounter.

Given a number of bytes, say 123901842, format this as '123.9MB'.

The reason I strongly think that this should be included in the standard 
library is that if you look for how to do this through a Google search, there 
are an incredible amount of different solutions on StackOverflow, blog posts, 
forum posts, and various different libraries which provide this functionality - 
with varying levels of functionality and safety. You can also find different 
implementations of solutions to this problem inside of pretty much every major 
Python project (Django, etc.). In fact, I don't think I can think of any other 
function that gets copy-pasted into a project's 'util.py' file more commonly.

I think this should functionality should be provided in the standard math 
package, with arguments which allow to specific SI/NIST formatting and the 
number of significant digits to display. Implementing this would strongly cut 
down on the amount of cargo-cult Python programming in the world.

I'm willing to implement this if there's a consensus that it should be included.

Thanks!,
Rich Jones

--
messages: 304061
nosy: miserlou2
priority: normal
severity: normal
status: open
title: Request: Human readable byte amounts in the standard library
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue31750] expose PyCell_Type in types module

[Devin Bayer]

New submission from Devin Bayer :

The type of PyCell_Type is not available in the types module or anywhere else. 
Since this type is exposed to users it seems like it's a rather odd omission.

Related issues:
- https://bugs.python.org/issue2408
- https://bugs.python.org/issue1605

--
components: Library (Lib)
messages: 304062
nosy: akvadrako
priority: normal
severity: normal
status: open
title: expose PyCell_Type in types module
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

[issue31750] expose PyCell_Type in types module

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

According to discussions in the issues referred by you, this omission is 
intentional. Do you have any new arguments for adding the cell type in the 
types module?

--
nosy: +serhiy.storchaka
versions: +Python 3.7 -Python 3.6

___
Python tracker 

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

[issue13601] sys.stderr should be line-buffered when stderr is not a TTY

[Torsten Landschoff]

Torsten Landschoff  added the comment:

> Looking at 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/stdin.html (which 
> also covers stdout and stderr), it specifically says about stderr: "When 
> opened, the standard error stream is not fully buffered;".

I was of the impression that this is defined in ISO C already. Unfortunately, I 
only have ISO C 99 at hand, but this clearly states in section 7.19.3 (Files), 
enumeration item 7:

> As initially opened,  the  standard  error  stream  is  not  fully  buffered; 
>  the  standard  input  and  standard output streams are fully buffered if and 
> only if the stream can be determined not to refer
to an interactive device.

I am quite sure this is just as as it was in the original ANSI C standard.

--
nosy: +torsten

___
Python tracker 

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

[issue31749] Request: Human readable byte amounts in the standard library

[Michael DePalatis]

Michael DePalatis  added the comment:

This would be a useful feature, but I don't think it quite fits in the math 
package. It might make more sense to use this with string formatting, for 
example:

{:h}.format(filesize)

where I use h as the format specifier since it doesn't appear to be taken yet 
and would be in line with "human-readable" options in tools like ls.

--
nosy: +mivade

___
Python tracker 

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

[issue31738] Lib/site.py: method `abs_paths` is not documented

[Liel Fridman]

Liel Fridman  added the comment:

No, I've just tried to find something to work on as a first contribution.

--

___
Python tracker 

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

[issue31750] expose PyCell_Type in types module

[Devin Bayer]

Devin Bayer  added the comment:

I have just reread those discussions and I don't see any reasoning behind 
omitting the cell type. It is barely mentioned.

Basically, I need this type and it isn't exposed anywhere. I don't care where 
it is, but the only way to get it right now is a hack, for example:

a = [1]
def f(): return a
return type(f.__closure__[0])

--

___
Python tracker 

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

[issue31751] Support for C++ 11 and/or C++ 14 in python.org installer

[steven Michalske]

New submission from steven Michalske :

We are using some compiled cython modules with c++ 11 features.
This prohibits us from instructing users to install python from the python.org 
download.

Please consider using clang with support for C++ 11 and higher.
This would move the minimum OS X version away from 10.6 but as 10.6 is 8 years 
old and phased out 6 years ago it should be rare that non technical users would 
be using this OS version.

--
components: Build, Installation, macOS
messages: 304068
nosy: hardkrash, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Support for C++ 11 and/or C++ 14 in python.org installer
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue31722] _io.IncrementalNewlineDecoder doesn't inherit codecs.IncrementalDecoder

[Oren Milman]

Change by Oren Milman :


--
keywords: +patch
pull_requests: +3918
stage:  -> patch review

___
Python tracker 

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

[issue31722] _io.IncrementalNewlineDecoder doesn't inherit codecs.IncrementalDecoder

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests:  -3918

___
Python tracker 

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

[issue31750] expose PyCell_Type in types module

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

The reason is that nobody provided good enough arguments for exposing a cell 
type in the types module. The initial argument "types should expose all types 
used by the interpreter" was found to be bad. There are a lot of types (like 
"stderrprinter" or "list_reverseiterator") that shouldn't be exposed.

--
nosy: +benjamin.peterson, gvanrossum

___
Python tracker 

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

[issue31749] Request: Human readable byte amounts in the standard library

[Timothy Allen]

Timothy Allen  added the comment:

This would be a benefit to my team, for sure. I can't even tell you how many 
different solutions we currently use to make file sizes human readable - at 
least three.

--
nosy: +FlipperPA

___
Python tracker 

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

[issue31740] refleaks when calling sqlite3.Connection.__init__() more than once

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 93c5a5df8ea118f6e4a153a7c8cccd65a5ff8bff by Victor Stinner (Oren 
Milman) in branch 'master':
bpo-31740: Prevent refleaks when sqlite3.Connection.__init__() is called more 
than once (GH-3944)
https://github.com/python/cpython/commit/93c5a5df8ea118f6e4a153a7c8cccd65a5ff8bff


--
nosy: +haypo

___
Python tracker 

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

[issue31740] refleaks when calling sqlite3.Connection.__init__() more than once

[STINNER Victor]

STINNER Victor  added the comment:

Oren Milman: thanks for your contribution! I merged your PR.

I don't consider that such corner case requires to backport the change to 
Python 2.7 and 3.6.

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

[issue31748] Modules/posixmodule.c: skip compiling jka4NaPmmQ37 and posix_fildes_fd

[STINNER Victor]

STINNER Victor  added the comment:

Hi Дилян Палаузов,

> These are needed only sometimes.

Would you mind to elaborate, please?

Which platform doesn't have os.fchdir(), os.fsync() nor os.fdatasync()?

--
nosy: +haypo

___
Python tracker 

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

[issue31750] expose PyCell_Type in types module

[Devin Bayer]

Devin Bayer  added the comment:

Well that's true enough. My main argument is consistency. Cells and code 
objects together make up closures, so to manipulate closures you need both. 
Right now I am using a ctypes hack to modify the cells/closures, for what I 
consider a strategically important use-case. So I guess a type(cell) hack isn't 
out of place; the risk is it's fragile.

So, to really make hot reloading work with no hacks I need both this and the 
follow-up of https://bugs.python.org/issue14369 to be implemented. Or 
equivalently, a python interface to make closures mutable.

Honestly I don't know what your criteria are, so it's hard to make a point.

--

___
Python tracker 

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

[issue31748] Modules/posixmodule.c: skip compiling jka4NaPmmQ37 and posix_fildes_fd

[Дилян Палаузов]

Дилян Палаузов  added the comment:

Having 'CFLAGS="-pipe -Werror -Wall -Wextra -O3 -fno-fat-lto-objects -flto" 
CXXFLAGS="-pipe -Wall -Wextra -O3 -fno-fat-lto-objects -flto" 
LDFLAGS="-Wl,-O1,-s -flto=12" ' in config.site and running "./configure" with 
gcc8 prints:

checking for fchdir... no
checking for fsync... no
checking for fdatasync... no

and config.log has:

configure:11440: checking for fchdir
configure:11453: gcc -c -pipe -Werror -Wall -Wextra -O3 -fno-fat-lto-objects 
-flto  conftest.c >&5
conftest.c: In function 'main':
conftest.c:250:7: error: unused variable 'x' [-Werror=unused-variable]
 void *x=fchdir
   ^
cc1: all warnings being treated as errors
configure:11453: $? = 1
configure: failed program was:
| /* confdefs.h */
...
| #define HAVE_DIRFD 1
| /* end confdefs.h.  */
| #include 
| int
| main ()
| {
| void *x=fchdir
|   ;
|   return 0;
| }
configure:11460: result: no

--

___
Python tracker 

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

[issue31749] Request: Human readable byte amounts in the standard library

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Do you mean decimal or binary prefixes? 123901842 bytes can be formatted as 
"118.2 MiB". In different areas decimal and binary prefixes can be more common. 
For example the volume of hard disks usually is specified with decimal 
prefixes, but the volume of RAM -- with binary prefixes (32 GiB, not 34.4 GB). 
Sometimes even mixed prefixes can be used (1 MB = 1024000 bytes).

And when we talk about human-readability, we can't ignore localization. For 
many people "123,9 МБ" looks more human-readable than "123.9 MB".

This is a complex problem and needs a complex solution. You can start from 
writing a special purposed package and adding it on PyPI. Maybe there are 
existing packages that solve this problem.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue31748] Modules/posixmodule.c: skip compiling jka4NaPmmQ37 and posix_fildes_fd

[STINNER Victor]

STINNER Victor  added the comment:

Ok. My next question is: what is your operating system? What is your operating 
system version?

--

___
Python tracker 

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

[issue31750] expose PyCell_Type in types module

[Guido van Rossum]

Guido van Rossum  added the comment:

I think the cell type is pretty fundamental to Python's semantic model. IIRC 
there once was a time when cells were entirely hidden from the user, but that's 
no longer true. Third-party code that uses them might want to have type 
annotations and then it's a pain when there's no way to talk about them. And 
no, that doesn't mean it belongs in typing.py -- that's not a scalable model, 
and in general we only want to shadow things there that must be generic (but 
aren't in types.py), like `List` or `re.Pattern`.

--

___
Python tracker 

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

[issue31728] crashes in _elementtree due to unsafe decrefs of Element.text and Element.tail

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 39ecb9c71b6e55d8a61a710d0144231bd88f9ada by Serhiy Storchaka 
(Oren Milman) in branch 'master':
bpo-31728: Prevent crashes in _elementtree due to unsafe cleanup of 
Element.text and Element.tail (#3924)
https://github.com/python/cpython/commit/39ecb9c71b6e55d8a61a710d0144231bd88f9ada


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue31748] Modules/posixmodule.c: skip compiling jka4NaPmmQ37 and posix_fildes_fd

[Дилян Палаузов]

Дилян Палаузов  added the comment:

If I remove -Werror from CFLAGS ./configure prints:

  checking for fchdir... yes
  checking for fsync... yes
  checking for fdatasync... yes

so it is irrelevant what the OS is.

--

___
Python tracker 

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

[issue31728] crashes in _elementtree due to unsafe decrefs of Element.text and Element.tail

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +3919

___
Python tracker 

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

[issue31748] configure fails to detect fchdir() using CFLAGS="-Werror -Wall"

[STINNER Victor]

STINNER Victor  added the comment:

I can reproduce the issue on Fedora 26:

haypo@selma$ ./configure CFLAGS="-Werror -Wall" 2>&1|tee log
haypo@selma$ grep fchdir log
checking for fchdir... no

The problem is not posixmodule.c. The problem is configure which emits a 
compiler warning.

configure.ac contains:
---
AC_MSG_CHECKING(for fchdir)
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include ]], [[void 
*x=fchdir]])],
  [AC_DEFINE(HAVE_FCHDIR, 1, Define if you have the 'fchdir' function.)
   AC_MSG_RESULT(yes)],
  [AC_MSG_RESULT(no)
])
---

Extract of config.log, without the long confdefs.h part:
---
configure:11258: checking for fchdir
configure:11271: gcc -c -Werror -Wall -Wextra  conftest.c >&5
conftest.c: In function 'main':
conftest.c:256:7: error: unused variable 'x' [-Werror=unused-variable]
 void *x=fchdir
   ^
cc1: all warnings being treated as errors
configure:11271: $? = 1
configure: failed program was:
| /* confdefs.h */
| (...)
| /* end confdefs.h.  */
| #include 
| int
| main ()
| {
| void *x=fchdir
|   ;
|   return 0;
| }
configure:11278: result: no
---

--
title: Modules/posixmodule.c: skip compiling jka4NaPmmQ37 and posix_fildes_fd 
-> configure fails to detect fchdir() using CFLAGS="-Werror -Wall"

___
Python tracker 

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

[issue31748] configure fails to detect fchdir() using CFLAGS="-Werror -Wall"

[STINNER Victor]

STINNER Victor  added the comment:

Python 2.7 is also affected by the issue.

--
versions: +Python 2.7, Python 3.6, Python 3.7 -Python 3.8

___
Python tracker 

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

[issue31752] Assertion failure in timedelta() in case of bad __divmod__

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

The following code causes an assertion error in timedelta constructor.

from datetime import timedelta

class BadInt(int):
def __mul__(self, other):
return Prod()

class Prod:
def __radd__(self, other):
return Sum()

class Sum:
def __divmod__(self, other):
return (0, -1)

timedelta(hours=BadInt(1))


Result:

python: /home/serhiy/py/cpython/Modules/_datetimemodule.c:1573: 
microseconds_to_delta_ex: Assertion `0 <= temp && temp < 100' failed.
Aborted (core dumped)

--
components: Extension Modules
messages: 304083
nosy: Oren Milman, belopolsky, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Assertion failure in timedelta() in case of bad __divmod__
type: crash
versions: Python 2.7, Python 3.6, Python 3.7

___
Python tracker 

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

[issue31749] Request: Human readable byte amounts in the standard library

[Rich]

Rich  added the comment:

Yep, as I mentioned, it should be configurable to use either format. 
Localization is an excellent point as well, so, all in all, the optional 
arguments to the function are format, significant digits, and delimiter. That's 
not an unreasonable amount of configurability.

It's not a complex problem, the solutions are fairly simple, but there are many 
ways to shoot yourself in the foot when rolling your own. There are already 
many packages which attempt this, most of which aren't used by any serious 
projects, who instead use their own implementations. There are just as many 
snippets of partial solutions floating around the internet as well. There is no 
canonical way to solve this common problem.

This is exactly why this common functionality should be added to the standard 
library, so that this extremely common function doesn't have to be imported 
from some-random-jamook's-untrustworthy-project-on-PyPI or rewritten from 
scratch for every project.

--

___
Python tracker 

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

[issue31751] Support for C++ 11 and/or C++ 14 in python.org installer

[Ned Deily]

Ned Deily  added the comment:

Can you give a test case demonstrating what is not working?  The Python 
interpreters installed with python.org 10.6+ installers are built to work with 
all versions of macOS from 10.6 on and should be able to build extension 
modules with either gcc or clang as provided by the Xcode or Command Line Tools 
appropriate for the macOS version in use.  And, AFAIK, Python itself has no 
dependency on C++ at all so there should not be a c++ runtime library conflict 
due to Python itself.  Although the initial value of the configuration 
variables are CC=gcc-4.2 and GXX=g++-4.2, when the first compilation of an 
extension module is attempted, Distutils via Lib/_osx_support.py will do some 
work to figure out what compilers are available and modify CC and CXX 
accordingly.  So, for example, on say a macOS 10.13 system with the default 
Command Line Tools, it should use gcc and g++ which are both aliases for clang. 
 And, if necessary, you can always override the default compiler selection by 
explicitly 
 setting the CC and/or CXX environment variables when invoking python.  At 
least that's how it's supposed to work!

--

___
Python tracker 

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

[issue31746] crashes in sqlite3.Connection in case it is uninitialized or partially initialized

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
pull_requests: +3920
stage:  -> patch review

___
Python tracker 

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

[issue31752] Assertion failure in timedelta() in case of bad __divmod__

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +3922

___
Python tracker 

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

[issue31728] crashes in _elementtree due to unsafe decrefs of Element.text and Element.tail

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset a8ac71d15f2a4aef83a8954a678cc12545ce517c by Serhiy Storchaka 
(Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31728: Prevent crashes in _elementtree due to unsafe cleanup of 
Element.text and Element.tail (GH-3924) (#3945)
https://github.com/python/cpython/commit/a8ac71d15f2a4aef83a8954a678cc12545ce517c


--

___
Python tracker 

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

[issue31537] Bug in readline module documentation example

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:


New changeset eeb5ffd54e56dd89a99c74eb512c36d62649cfec by Mariatta (Brad Smith) 
in branch 'master':
bpo-31537: Update readline documentation example. (GH-3925)
https://github.com/python/cpython/commit/eeb5ffd54e56dd89a99c74eb512c36d62649cfec


--
nosy: +Mariatta

___
Python tracker 

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

[issue31537] Bug in readline module documentation example

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +3923

___
Python tracker 

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

[issue31753] Unnecessary closure in ast.literal_eval

[Aaron Hall]

New submission from Aaron Hall :

Removing the closure seems to make the function about 10% faster.

Original source code at: 
https://github.com/python/cpython/blob/3.6/Lib/ast.py#L40

Empirical evidence: astle.py

import timeit
from ast import literal_eval as orig_literal_eval
from ast import *

def new_literal_eval(node_or_string):
"""
Safely evaluate an expression node or a string containing a Python
expression.  The string or node provided may only consist of the following
Python literal structures: strings, bytes, numbers, tuples, lists, dicts,
sets, booleans, and None.
"""
if isinstance(node_or_string, str):
node_or_string = parse(node_or_string, mode='eval')
if isinstance(node_or_string, Expression):
node_or_string = node_or_string.body
node = node_or_string
if isinstance(node, Constant):
return node.value
elif isinstance(node, (Str, Bytes)):
return node.s
elif isinstance(node, Num):
return node.n
elif isinstance(node, Tuple):
return tuple(map(_convert, node.elts))
elif isinstance(node, List):
return list(map(_convert, node.elts))
elif isinstance(node, Set):
return set(map(_convert, node.elts))
elif isinstance(node, Dict):
return dict((_convert(k), _convert(v)) for k, v
in zip(node.keys, node.values))
elif isinstance(node, NameConstant):
return node.value
elif isinstance(node, UnaryOp) and isinstance(node.op, (UAdd, USub)):
operand = _convert(node.operand)
if isinstance(operand, _NUM_TYPES):
if isinstance(node.op, UAdd):
return + operand
else:
return - operand
elif isinstance(node, BinOp) and isinstance(node.op, (Add, Sub)):
left = _convert(node.left)
right = _convert(node.right)
if isinstance(left, _NUM_TYPES) and isinstance(right, _NUM_TYPES):
if isinstance(node.op, Add):
return left + right
else:
return left - right
raise ValueError('malformed node or string: ' + repr(node))



def main():
print('orig first, then new')
print("'1.01'")
print(min(timeit.repeat(lambda: orig_literal_eval('1.01'
print(min(timeit.repeat(lambda: new_literal_eval('1.01'
print("""'"1.01"'""")
print(min(timeit.repeat(lambda: orig_literal_eval('"1.01"'
print(min(timeit.repeat(lambda: new_literal_eval('"1.01"'
print("'1'")
print(min(timeit.repeat(lambda: orig_literal_eval('1'
print(min(timeit.repeat(lambda: new_literal_eval('1'


if __name__ == '__main__':
main()

Shell:

$ python -m astle
orig first, then new
'1.01'
3.518230145502848
3.274753015923377
'"1.01"'
3.189016693752965
2.906869704238048
'1'
3.40557457956146
3.157061471625788

--
components: Library (Lib)
messages: 304089
nosy: Aaron Hall
priority: normal
severity: normal
status: open
title: Unnecessary closure in ast.literal_eval
type: performance

___
Python tracker 

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

[issue31537] Bug in readline module documentation example

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:

Fixed. Thanks!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
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

[issue31537] Bug in readline module documentation example

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:


New changeset 10eb14e2c5fe08c4193668530eaef156e07c3674 by Mariatta (Miss 
Islington (bot)) in branch '3.6':
bpo-31537: Update readline documentation example. (GH-3925) (GH-3948)
https://github.com/python/cpython/commit/10eb14e2c5fe08c4193668530eaef156e07c3674


--

___
Python tracker 

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

[issue31753] Unnecessary closure in ast.literal_eval

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Test more complex examples including list and dict displays, binary operators.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue30457] Allow retrieve the number of waiters pending for most of the asyncio lock primitives

[Yury Selivanov]

Yury Selivanov  added the comment:

Isn't this code equivalent to yours:

async def get(process, key):
try:
return cache[key]
except KeyError:
if key in events:
await events[key].wait()
else:
events[key] = asyncio.Event()

# simulates some IO to get the Key
await asyncio.sleep(0.1)
cache[key] = "some random value"
event.set()

return cache[key]


?

--

___
Python tracker 

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

[issue31749] Request: Human readable byte amounts in the standard library

[Eric V. Smith]

Eric V. Smith  added the comment:

A library implementing this should definitely go on PyPI first to shake out 
design issues. Then we'd need a PEP.

As someone who has a simplistic version of this code around, and who's done a 
bit of string formatting, I can assure you that there are a lot of issues to be 
thought through.

- Should it be 0.5M, or 500K? Is there a cutoff to switch over? Is it 
configurable?
- What if I prefer 1000K to 1M? Or even 1,000.0K or 1.000,0K (localized)?
- How many decimals to display? Can you suppress trailing zeros? Should it be 
1.0M, or 1M?
- Space between the number and the units?
- As you mention, MiB vs. MB. And there are schemes where MB means 1000^2 and 
others where MB means 2^20. And as Serhiy says, schemes where 1 MB = 1024000 
bytes. How to handle all of these.
- Localization. Should this be specified as a locale, use the current locale, 
just ignored (see PEP 378 for an example), or have the delimiters passed in?

I'm sure there are other decisions to be made.

If you're serious about this (and I hope you are!), then I think finding 
current best practices both within and outside of the Python universe should be 
researched.

I do like the idea of the "h" format specifier, which would be an argument to 
move it in to the stdlib. That said, we never did come to agreement on 
something much simpler: engineering notation for floats (see issue 8060), 
because no one put the time into writing up a concrete proposal.

--
nosy: +eric.smith

___
Python tracker 

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

[issue31741] backports import path can not be overridden in Windows (Linux works fine)

[Chris Caron]

Change by Chris Caron :


Added file: https://bugs.python.org/file47205/Test.py

___
Python tracker 

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

[issue31741] backports import path can not be overridden in Windows (Linux works fine)

[Chris Caron]

Change by Chris Caron :


Added file: https://bugs.python.org/file47206/site-packages-Directory.png

___
Python tracker 

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

[issue31741] backports import path can not be overridden in Windows (Linux works fine)

[Chris Caron]

Change by Chris Caron :


Added file: https://bugs.python.org/file47207/Test.Directory.png

___
Python tracker 

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

[issue31741] backports import path can not be overridden in Windows (Linux works fine)

[Chris Caron]

Change by Chris Caron :


Added file: https://bugs.python.org/file47208/Test.Script.Backports.Dir.png

___
Python tracker 

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

[issue31741] backports import path can not be overridden in Windows (Linux works fine)

[Chris Caron]

Change by Chris Caron :


Added file: https://bugs.python.org/file47209/Test.Script.Output.png

___
Python tracker 

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

[issue31741] backports import path can not be overridden in Windows (Linux works fine)

[Chris Caron]

Change by Chris Caron :


Added file: https://bugs.python.org/file47210/Python.Test.zip

___
Python tracker 

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

[issue31741] backports import path can not be overridden in Windows (Linux works fine)

[Chris Caron]

Chris Caron  added the comment:

I'm not doing anything unusual.

Just to recap, I installed Python27 (in Windows 7 in my case- but this problem 
happens in Windows 10 too).

I did use `pip` to install packages as you'll see in the screenshot.  But even 
if i rename the `C:\Python27\Lib\site-packages\backports` to 
`ignoreme-backports`.  When i change the PYTHONPATH (from within 
sys.path.insert(0, 'new_path/that/has/a/backports/dir/in/it');

import backports
print backports.__path__
# always prints: C:\Python27\Lib\site-packages\backports

The problem arises because the following code won't work in my program:

from import import ssl_match_hostname

^^ That throws an exception that the package doesn't exist.  It's debugging it 
to the __path__ being incorrect that caused me to create this ticket.

--

___
Python tracker 

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

[issue31754] Documented type of parameter 'itemsize' to PyBuffer_FillContiguousStrides is incorrect.

[Robert Snoeberger]

New submission from Robert Snoeberger :

The signature for PyBuffer_FillContiguousStrides in the documentation shows 
that the type of parameter 'itemsize' is Py_ssize_t [1]. This is different from 
the signature in Include/abstract.h which shows that the type as int [2].


[1] https://docs.python.org/3/c-api/buffer.html#c.PyBuffer_FillContiguousStrides
[2] 
https://github.com/python/cpython/blob/49b2734bf12dc1cda80fd73d3ec8896ae3e362f2/Include/abstract.h#L559-L563

--
assignee: docs@python
components: Documentation
messages: 304096
nosy: docs@python, snoeberger
priority: normal
severity: normal
status: open
title: Documented type of parameter 'itemsize' to 
PyBuffer_FillContiguousStrides is incorrect.
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

[issue31742] Default to emitting FutureWarning for provisional APIs

[Amber Brown]

Amber Brown  added the comment:

> What happened to "consenting adults"?

Consent does not mean that by using Python, users fully consent to using 
modules that they may not be aware will, to paraphrase Donald, come back to 
bite them in the ass.

Consent requires multiple things:

- Acknowledgement of the benefits involved
- Acknowledgement of the risks involved
- Positive affirmation that these things are accepted.

The spate of PyCon talks on provisional modules (the half dozen asyncio at 
PyCon US last year, and the 2-3+ asyncio talks at every conference I've been to 
since 2014) very much has given the community the first item, and as people 
have expressed interest in the benefits, acknowledge them.

But, CPython does not like at all admitting clearly or explicitly the risks 
involved. From multiple discussions with Nick, an author of the provisional API 
PEP, it has come clear to me that the intended role of provisional software is 
to allow CPython to ship not-production-ready software for testing and API 
usability testing in an experimental capacity. How many people, from reading 
the single line in the docs (which, remember, is not the only path where people 
learned how to use asyncio in 3.4/3.5, and is absent from module 
documentation), did not know this?

Upon discussing this issue with others, a few people admitted that they had no 
idea that provisional APIs existed, that asyncio was one, that typing is one, 
and they had no idea where to look to see if they were using a provisional 
module in their code or their dependencies.

So, it appears that CPython is failing item #2 here, by not adequately 
informing users of the risks. Yes, the warning should be improved (and ought to 
be made bright red, not grey, and actually use the word "warning", not note), 
but we should also take a step to protect the users that may not learn about 
the module through official documentation, and in some cases, may never 
reference it.

Only then can we confidently say that the user is potentially a "consenting 
adult". (Which is maybe interesting language to use nowadays considering 
Python's growth areas contain a lot of school-age education...)

--

___
Python tracker 

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

[issue31751] Support for C++ 11 and/or C++ 14 in python.org installer

[steven Michalske]

steven Michalske  added the comment:

This might be a cython issue then, but I will dig into an example case.  Please 
be patient.

--

___
Python tracker 

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

[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

[Nick Coghlan]

Nick Coghlan  added the comment:

I've been thinking further about the write-through proxy idea, and I think I've 
come up with a design for one that shouldn't be too hard to implement, while 
also avoiding all of the problems that we want to avoid.

The core of the idea is that the proxy type would just be a wrapper around two 
dictionaries:

- the existing f_locals dictionary
- a new dictionary mapping cell & free variable names to their respective cells 
(note: this may not actually need to be a dict, as a direct reference from the 
proxy back to the frame may also suffice. However, I find it easier to think 
about the design by assuming this will be a lazily initialised dict in its own 
right)

Most operations on the proxy would just be passed through to f_locals, but for 
keys in both dictionaries, set and delete operations would *also* affect the 
cell in the cell dictionary. (Fortunately dict views don't expose any mutation 
methods, or intercepting all changes to the mapping would be a lot trickier)

Frames would gain a new lazily initialised "f_traceproxy" field that defaults 
to NULL/None.

For code objects that don't define or reference any cells, nothing would change 
relative to today.

For code objects that *do* define or reference cells though, tracing would 
change as follows:

* before calling the trace function:
  - f_locals would be updated from the fast locals array and current cell 
values as usual
  - f_locals on the frame would be swapped out for f_traceproxy (creating the 
latter if needed)
* after returning from the trace function:
  - f_locals on the frame would be reset back to bypassing the proxy (so writes 
to f_locals stop being written through to cells when the trace hook isn't 
running)
  - only the actual locals would be written from f_locals back to the fast 
locals array (cell updates are assumed to have already been handled via the 
proxy)

This preserves all current behaviour *except* the unwanted one of resetting 
cells back to their pre-tracehook value after returning from a trace hook:

* code outside trace hooks can't mutate the function level fast locals or cells 
via locals() or frame.f_locals (since their modifications will be overwritten 
immediately before the trace function runs), but *can* treat it as a regular 
namespace otherwise
* code inside trace hooks can mutate function level fast locals and cells just 
by modifying frame.f_locals
* all code can display the current value of function level fast locals and 
cells just by displaying locals() or frame.f_locals
* there's still only one f_locals dictionary per frame, it may just have a 
proxy object intercepting writes to cell variables when a trace hook is running

That way, we can avoid the problem with overwriting cells back to old values, 
*without* enabling arbitrary writes to function locals from outside trace 
functions, and without introducing any tricky new state synchronisation 
problems.

--

___
Python tracker 

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

[issue17960] Clarify the required behaviour of locals()

[Nick Coghlan]

Nick Coghlan  added the comment:

Nathaniel raised a valid concern about the draft PEP over in 
https://bugs.python.org/issue30744#msg302475, so I've been considering whether 
or not it would be possible to make the write-through proxy idea work without 
introducing other problems.

I think I have a workable design concept for that approach now: 
https://bugs.python.org/issue30744#msg304099

So the next step will be to see if that actually does work as well as I think 
it will, and if so, update the PEP accordingly.

--
nosy: +njs

___
Python tracker 

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