date:20170517


Changes by Terry J. Reedy :


--
pull_requests: +1736

___
Python tracker 

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

Re: How to install Python package from source on Windows

On 18/05/2017 01:19, Steve D'Aprano wrote:

On Thu, 18 May 2017 07:47 am, Ian Kelly wrote:

Because, as has already been stated, there's no way to make such a simple
process cross-platform.

Please understand that Bart's understanding of cross-platform and the Python
community's understanding of cross-platform are different.

Bart's understanding of cross-platform is:

"I have a Windows box, or maybe two of them, and a Linux VM, and so long as
my code will compile and run a few simple scripts on each of them with no
obvious bugs, I'm going to assume we're done!"

The Python community's understanding is:

"We have to support literally tens of thousands of different combinations
and permutations of hardware, operating system version, variations in how
the OS and user's environment are configured, and variations in C compilers
and how they are configured; we have to support hundreds of different
flavours of Linux alone, plus FreeBSD, OpenBSD, NetBSD, and other Unixes,
plus multiple versions of Windows and MacOS, and possibly a few others; we
have to support machines with different floating point capabilities, and as
much as possible abstract those differences away so that they're not
visible to the end user; and importantly, we want to halt the build process
with a comprehensible[1] error message if some essential feature is lacking
on your platform."

I've been looking at the CPython sources, and it shows.

When I first started using Python in version 1.5, among the many Unixes
supported were:

- VAX;
- VMS;
- Sun OS/Solaris (technically a Unix);
- HP UX (also technically a Unix);
- Windows 95/98;
- Windows NT;
- Windows CE;
- OS/2;
- classic Mac OS ("system 6", I think, or possibly 7).

My memory is a little fuzzy on the following, so don't quote me, but I think
the following were also officially supported:

- IBM AS/400 ("System i" or "iSeries");
- BeOS;
- MS DOS;
- Z/OS (OS 390);
- Acorn RISC;

You seem surprised. A portable C application should run anywhere there 
is a C compiler.

So tell us Bart, what do you think are the chances that your Q compiler will
*just work* with no modifications at all if somebody tried to build it on
an IBM AS/400, or under BeOS?

Maybe somebody can try it:

https://github.com/bartg/langs/blob/master/qlang/qcc64.c
https://github.com/bartg/langs/blob/master/qlang/pcc64.c

The first is a compiler, the second an interpreter. They need to be 
built for a system with 64-bit pointers (as these aren't original 
sources but intermediate code targetted at 64-bit C).

>Or for something a little more current, how
> about Android?

If Android has a terminal window, then why not?

--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Referring to a module by a string without using eval()

2017-05-17 Thread jeanbigboute

Thanks to all for the prompt replies.  I look forward to trying both 
approaches.  

I wasn't aware that subpackages such as numpy.random and such could be imported 
after numpy was imported at the top level.  For some reason I thought it would 
cause confusion.  

The functools.reduce and class approaches also look very powerful beyond my 
immediate need.

--- JBB
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to install Python package from source on Windows


On 17/05/2017 23:32, Chris Angelico wrote:

On Thu, May 18, 2017 at 8:21 AM, bartc  wrote:

My own approach with the standard library is that I just use what is
provided by the OS (so msvcrt.dll or libc.so.6).

I expect Tiny C does the same as it doesn't appear to come with any
libraries of its own.


Well, msvcrt.dll isn't the whole thing. You need the compilation end
of that too (header files and static libraries). Where are you going
to get those from? Oh right. The dev version of msvcrt.dll is in
Visual Studio.


No. On Windows, C compilers provide their own headers.

(I build mine from looking at the C standard, from online docs such as 
msdn, and peeking at existing headers, but you can't use them directly 
as they tend to be compiler-specific.)


Library files (I assume you mean .a/.lib) are not needed as it is 
possible to link directly to shared libraries, such as msvcrt.dll.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

[issue28618] Decorate hot functions using attribute((hot)) to optimize Python

2017-05-17 Thread Jesús Cea Avión


Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

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

Re: How to install Python package from source on Windows

2017-05-17 Thread Steve D'Aprano

On Thu, 18 May 2017 01:37 am, bartc wrote:

> No, not like that. I mean genuinely simple. Your example:
> 
> (1) Doesn't work on Windows
> (2) Usually seems to involve executing 20,000 to to 30,000 lines of
> complete gobbledygook in that configuration script.
> 
> That can't possibly be justified.

Dammit, Bart just worked it out!

You're right Bart, the whole thing is a scam. The Python compiler is
actually a ten line C program[1], the rest of the files and build-scripts
and all the other stuff you see in the source directory are just there to
give the impression that it is harder than it really is. They actually have
no purpose, and the core devs have spent tens of thousands of person-hours
writing and maintaining those files as part of an elaborate Get Rich Slow
scam:

(1) Write Python.
(2) Bulk it up to make it look more impressive.
(4) Profit!

[1] Excluding comments.

-- 
Steve
Emoji: a small, fuzzy, indistinct picture used to replace a clear and
perfectly comprehensible word.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to install Python package from source on Windows

2017-05-17 Thread Steve D'Aprano

On Thu, 18 May 2017 06:05 am, breamore...@gmail.com wrote:

> 
> What is the problem with the documentation given here
> https://docs.python.org/devguide ?
> 
> Specifically:-
> 
> "and on Windows use:
> 
> PCbuild\build.bat -e -d"
> 
> 
> That is 24 key strokes, including ENTER, to do the build on Windows.  What
> is so difficult about this?

Well, for starters, I don't have Windows, so I can't use it!

*wink*

Thanks Mark for pointing this out. Twice.

Hey Bart, if you're reading this, how about answering the question: what is
so hard for Windows users about running the build.bat script that is
prepared for you?

Does it not work? If not, that's a bug.

Does it have undocumented dependencies? That's a bug.

Does it have documented but unreasonable dependencies? Well, that depends on
what is "reasonable", but that might be a good reason for a feature
request.

E.g. "support the Tiny-C compiler" might be a reasonable feature request, if
Tiny-C supports all the features used by Python.

"Don't require any C compiler at all" would be unreasonable.

-- 
Steve
Emoji: a small, fuzzy, indistinct picture used to replace a clear and
perfectly comprehensible word.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to install Python package from source on Windows

2017-05-17 Thread Steve D'Aprano

On Thu, 18 May 2017 07:47 am, Ian Kelly wrote:

> Because, as has already been stated, there's no way to make such a simple
> process cross-platform.

Please understand that Bart's understanding of cross-platform and the Python
community's understanding of cross-platform are different.

Bart's understanding of cross-platform is:

"I have a Windows box, or maybe two of them, and a Linux VM, and so long as
my code will compile and run a few simple scripts on each of them with no
obvious bugs, I'm going to assume we're done!"

The Python community's understanding is:

"We have to support literally tens of thousands of different combinations
and permutations of hardware, operating system version, variations in how
the OS and user's environment are configured, and variations in C compilers
and how they are configured; we have to support hundreds of different
flavours of Linux alone, plus FreeBSD, OpenBSD, NetBSD, and other Unixes,
plus multiple versions of Windows and MacOS, and possibly a few others; we
have to support machines with different floating point capabilities, and as
much as possible abstract those differences away so that they're not
visible to the end user; and importantly, we want to halt the build process
with a comprehensible[1] error message if some essential feature is lacking
on your platform."

When I first started using Python in version 1.5, among the many Unixes
supported were:

- VAX;
- VMS;
- Sun OS/Solaris (technically a Unix);
- HP UX (also technically a Unix);
- Windows 95/98;
- Windows NT;
- Windows CE;
- OS/2;
- classic Mac OS ("system 6", I think, or possibly 7).

My memory is a little fuzzy on the following, so don't quote me, but I think
the following were also officially supported:

- IBM AS/400 ("System i" or "iSeries");
- BeOS;
- MS DOS;
- Z/OS (OS 390);
- Acorn RISC;

although some of them may not have been official ports. (Most of these are
still available through third-parties.)

Support for a lot of those have been dropped, but it still leaves its traces
in the build system. The most important of which is the use of configure
and make in the first place: even if every Linux and Windows system in the
world today uses exactly the same configuration (which they don't), make
still tests for each of those features because you never know when you
might be running on some exotic mainframe or embedded device with radically
different features.

So tell us Bart, what do you think are the chances that your Q compiler will
*just work* with no modifications at all if somebody tried to build it on
an IBM AS/400, or under BeOS? Or for something a little more current, how
about Android?

[1] Comprehensible to the core devs, not necessarily the end user.

-- 
Steve
Emoji: a small, fuzzy, indistinct picture used to replace a clear and
perfectly comprehensible word.

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30395] deadlocked child process after forking on pystate.c's head_mutex

2017-05-17 Thread Pádraig Brady


Changes by Pádraig Brady :


--
nosy: +pixelbeat

___
Python tracker 

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

[issue30395] deadlocked child process after forking on pystate.c's head_mutex


Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue30395] deadlocked child process after forking on pystate.c's head_mutex

2017-05-17 Thread Louis Brandy


New submission from Louis Brandy:

A forked process (via os.fork) can inherit a locked `head_mutex` from its 
parent process and will promptly deadlock in this stack (on my linux box):

Child Process (deadlocked):

#0  0x7f1a4da82e3c in futex_abstimed_wait_cancelable (private=0, 
abstime=0x0, expected=0, futex_word=0x7f1a4c2964e0) at 
../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  0x7f1a4da82e3c in do_futex_wait (sem=sem@entry=0x7f1a4c2964e0, 
abstime=0x0) at sem_waitcommon.c:111
#2  0x7f1a4da82efc in __new_sem_wait_slow (sem=0x7f1a4c2964e0, abstime=0x0) 
at sem_waitcommon.c:181
#3  0x7f1a4da82fb9 in __new_sem_wait (sem=) at sem_wait.c:29
#4  0x7f1a4de4c605 in PyThread_acquire_lock_timed (lock=0x7f1a4c2964e0, 
microseconds=-1, intr_flag=0) at Python/thread_pthread.h:352
#5  0x7f1a4de4c4b4 in PyThread_acquire_lock (lock=, 
waitflag=waitflag@entry=1) at Python/thread_pthread.h:556
#6  0x7f1a4dd59e08 in _PyThreadState_DeleteExcept (tstate=0x7f19f2301800) 
at Python/pystate.c:483
#7  0x7f1a4dd46af4 in PyEval_ReInitThreads () at Python/ceval.c:326
#8  0x7f1a4dd78b0b in PyOS_AfterFork () at ./Modules/signalmodule.c:1608


The parent process has a race between one thread calling `os.fork` (and holding 
the GIL) and another (in our case C++) thread trying to use PyGILState_Ensure. 
PyGILState_Ensure will grab the head_mutex before it tries to get the GIL. So 
if a fork happens in this critical section, the child process will get the 
locked head_mutex. 

The path from PyGILState_Ensure -> head_mutex looks like this:

#0  new_threadstate (interp=0x7fb5fd483d80, init=init@entry=1) at 
Python/pystate.c:183
#1  0x7fb5ff149027 in PyThreadState_New (interp=) at 
Python/pystate.c:250
#2  0x7fb5ff006ac7 in PyGILState_Ensure () at Python/pystate.c:838




Possible fix?

A simple fix would be to, inside PyOS_AfterFork, reset/unlock pystate.c's 
head_mutex if it's already locked.

Unclear if this is related to: https://bugs.python.org/issue28812

--
components: Interpreter Core
messages: 293906
nosy: Louis Brandy
priority: normal
severity: normal
status: open
title: deadlocked child process after forking on pystate.c's head_mutex
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

[issue23749] asyncio missing wrap_socket (starttls)

2017-05-17 Thread Barry A. Warsaw


Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue30394] smtplib leaves open sockets around if SMTPConnectError is raised in init

2017-05-17 Thread Joel Hillacre


Changes by Joel Hillacre :


Added file: http://bugs.python.org/file46875/test_client.py

___
Python tracker 

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

[issue30039] Resuming a 'yield from' stack is broken if a signal arrives in the middle


Changes by Yury Selivanov :


--
pull_requests: +1735

___
Python tracker 

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

[issue30394] smtplib leaves open sockets around if SMTPConnectError is raised in init

2017-05-17 Thread Joel Hillacre


Changes by Joel Hillacre :


Added file: http://bugs.python.org/file46874/test_server.py

___
Python tracker 

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

[issue30394] smtplib leaves open sockets around if SMTPConnectError is raised in init

2017-05-17 Thread Joel Hillacre


New submission from Joel Hillacre:

I am encountering a ResourceWarning about an unclosed socket when getting a non 
220 response during connect() in __init__() of smtplib.SMTP. Attached are a 
client script causing this warning for me, a server script to cause the client 
to the warning and a patch that fixes the warning for me. My python version is 
Python 3.6.1 (default, Apr  7 2017, 09:32:32) [GCC 4.8.5 20150623 (Red Hat 
4.8.5-11)] on linux. I had found previous related issue with similar symptom 
and remedy in issue #21641.


$ python3.6 test_server.py
connected by ('127.0.0.1', 53630)
$ 


$ python3.6 test_client.py
Traceback (most recent call last):
  File "test_client.py", line 2, in 
smtp = smtplib.SMTP('127.0.0.1', 8025)
  File "/usr/lib64/python3.6/smtplib.py", line 253, in __init__
raise SMTPConnectError(code, msg)
smtplib.SMTPConnectError: (554, b'Nope.')
/usr/lib64/python3.6/socket.py:657: ResourceWarning: unclosed 
$ 


RFC 2821 states that servers responding with non 220 greetings must not close 
the connection. It is this behaviour that test_server.py is using to trigger 
the warning in test_client.py.

RFC 2821 Section 3.1 Paragraph 3
https://tools.ietf.org/html/rfc2821#section-3.1
   '... a 554 response MAY be given in the initial connection opening message
   instead of the 220.  A server taking this approach MUST still wait
   for the client to send a QUIT (see section 4.1.1.10) before closing
   the connection and SHOULD respond to any intervening commands with
   "503 bad sequence of commands".'

The ResourceWarning is no longer caused for me after applying this change.

--
components: Library (Lib)
files: smtplib.patch
keywords: patch
messages: 293905
nosy: jhillacre
priority: normal
severity: normal
status: open
title: smtplib leaves open sockets around if SMTPConnectError is raised in 
__init__
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file46873/smtplib.patch

___
Python tracker 

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

[issue30339] test_multiprocessing_main_handling: "RuntimeError: Timed out waiting for results" on x86 Windows7 3.x

2017-05-17 Thread Jeremy Kloth


Changes by Jeremy Kloth :


--
nosy: +jkloth

___
Python tracker 

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

[issue30339] test_multiprocessing_main_handling: "RuntimeError: Timed out waiting for results" on x86 Windows7 3.x


STINNER Victor added the comment:

Another failure on AMD64 Windows7 SP1 3.5:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.5/builds/145/steps/test/logs/stdio

==
FAIL: test_directory (test.test_multiprocessing_main_handling.SpawnCmdLineTest)
--
Traceback (most recent call last):
  File 
"C:\buildbot.python.org\3.5.kloth-win64\build\lib\test\test_multiprocessing_main_handling.py",
 line 197, in test_directory
self._check_script(script_dir)
  File 
"C:\buildbot.python.org\3.5.kloth-win64\build\lib\test\test_multiprocessing_main_handling.py",
 line 155, in _check_script
rc, out, err = assert_python_ok(*run_args, __isolated=False)
  File 
"C:\buildbot.python.org\3.5.kloth-win64\build\lib\test\support\script_helper.py",
 line 150, in assert_python_ok
return _assert_python(True, *args, **env_vars)
  File 
"C:\buildbot.python.org\3.5.kloth-win64\build\lib\test\support\script_helper.py",
 line 136, in _assert_python
err))
AssertionError: Process return code is 1
command line: 
['C:\\buildbot.python.org\\3.5.kloth-win64\\build\\PCbuild\\amd64\\python_d.exe',
 '-X', 'faulthandler', '-E', 
'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmpld1_lj4t', 'spawn']

stdout:
---

---

stderr:
---
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.5.kloth-win64\build\lib\runpy.py", line 193, 
in _run_module_as_main
"__main__", mod_spec)
  File "C:\buildbot.python.org\3.5.kloth-win64\build\lib\runpy.py", line 85, in 
_run_code
exec(code, run_globals)
  File "C:\Users\Buildbot\AppData\Local\Temp\tmpld1_lj4t\__main__.py", line 23, 
in 
raise RuntimeError("Timed out waiting for results")
RuntimeError: Timed out waiting for results
---

--
versions: +Python 3.5, Python 3.6

___
Python tracker 

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

[issue30039] Resuming a 'yield from' stack is broken if a signal arrives in the middle


Yury Selivanov added the comment:

Yes, I'll do the backport.

--

___
Python tracker 

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

[issue30039] Resuming a 'yield from' stack is broken if a signal arrives in the middle


STINNER Victor added the comment:

The change should be backported to 3.5 and 3.6, right? The change seems very 
short and safe. IMHO it's ok to backport.

--
nosy: +haypo

___
Python tracker 

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

Re: How to install Python package from source on Windows

On 05/17/2017 04:21 PM, Chris Angelico wrote:
> One of the complaints that bartc raised against clang was that it's
> not self-contained - that it depends on some other stdlib. Yet he
> espouses a tiny C compiler that obviously has the same limitation. On
> my Linux boxes, I can grab GNU libc; but on Windows, where are you
> going to get the header files and link-time libraries from? Oh right.
> MSVC.

No so. Tcc has a full suite of header files for msvcrt and also support
for the win32 API.  MingW GCC has had its own set of headers for many
years, and they could probably be freely used.

So in some sense, TCC and MingW are both self-contained. Neither depends
on MSVC, though both depend on a version of the MSVCRT which can be
installed as its own redistributable package.  In fact Python 3.6 ships
with the latest version of the MSVCRT universal runtime.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to install Python package from source on Windows

On 05/17/2017 04:32 PM, Chris Angelico wrote:
> On Thu, May 18, 2017 at 8:21 AM, bartc  wrote:
>> My own approach with the standard library is that I just use what is
>> provided by the OS (so msvcrt.dll or libc.so.6).
>>
>> I expect Tiny C does the same as it doesn't appear to come with any
>> libraries of its own.
> 
> Well, msvcrt.dll isn't the whole thing. You need the compilation end
> of that too (header files and static libraries). Where are you going
> to get those from? Oh right. The dev version of msvcrt.dll is in
> Visual Studio.

Looks like TCC comes with a full set of headers for msvcrt as well as
win32.

So if you can build Cpython with mingw gcc, you should be able to just
tell configure to use tcc in the msys environment and see what happens.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30387] warning of threading_cleanup in test_threading


STINNER Victor added the comment:

Ok, the warning should now be fixed. Thanks for the report Xiang. I don't know 
how I missed it ;-)

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

___
Python tracker 

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

[issue29137] Fix fpectl-induced ABI breakage

2017-05-17 Thread Nathaniel Smith


Nathaniel Smith added the comment:

@Dima:
> @njs: to point out that usefulness of this module is not just wishful 
> thinking. I just used it to locate, up to the line in a Python extension 
> module written in C, a bug in Sagemath (that has perhaps 20 FPU-using 
> extensions, some of them as large as numpy).  (Without using it we were 
> pulling out our hair for weeks over this)

That's pretty cool :-). But from skimming your link, it sounds like it would 
have been sufficient in your case to add a call to "fesetmask(FP_X_INV)" using 
C or Cython or ctypes (or directly in gdb), and then running the program under 
gdb to get a backtrace where the SIGFPE was delivered? Is that correct? Or did 
your debugging depend on the specific fpectl machinery for responding to that 
signal?

> PS. I would volunteer to fix it and maintain it, assuming I have some modest 
> funding to support such an activity.

I'm not personally aware of any funding sources for this, if that's the 
question.

--

___
Python tracker 

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

Re: How to install Python package from source on Windows

On 05/17/2017 03:56 PM, bartc wrote:
> It sounds more like CPython is written in assembly code rather than C. 
> Why don't the C language, C compilers and their optimisers take care of 
> these concerns?

No endianness definitely is something you as a programmer have to be
aware of in any language that allows direct manipulation of memory.  At
least if you're going to do any bit twiddling.  CPython is mostly C, but
probably there's the odd bit of assembly to grab some specific feature
they need.

> (And what does the build system do with all this information, or is this 
> just routinely gathered anyway whether the application needs it or not?)

Sometimes the information is routinely gathered, because as we said
before configure is a compiled program, built from standardized macros.
Whether Python does anything with all that information I don't know.
But since configure can be built to specific needs, I suspect that
CPython's internals do need to know about endianness, as well as some
special CPU-specific instructions.  There may well be the occasional
drop down into inline assembly for some very few specific things.  For
example interpreters often rely on devices like trampolines and jump
tables to get a bit of speedup.  Might occasionally need a bit of ASM
code (guarded by #ifdefs of course to make it platform independent).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to install Python package from source on Windows

On 05/17/2017 04:32 PM, Chris Angelico wrote:
> On Thu, May 18, 2017 at 8:21 AM, bartc  wrote:
>> My own approach with the standard library is that I just use what is
>> provided by the OS (so msvcrt.dll or libc.so.6).
>>
>> I expect Tiny C does the same as it doesn't appear to come with any
>> libraries of its own.
> 
> Well, msvcrt.dll isn't the whole thing. You need the compilation end
> of that too (header files and static libraries). Where are you going
> to get those from? Oh right. The dev version of msvcrt.dll is in
> Visual Studio.

Last I looked tcc did provide some basic headers for msvcrt, just like
MingW does.  I'm not sure the status of the win32 header files, though,
which would certainly be required to compile Python on Windows.

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue18617] AIA chasing for missing intermediate certificates on TLS connections

2017-05-17 Thread Alex Gaynor


Alex Gaynor added the comment:

Just discussed with Christian, and we're both in favor of adding AIA chasing 
support to the stdlib ssl.

--
nosy: +alex, janssen

___
Python tracker 

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

Re: Survey: improving the Python std lib docs

On Thu, May 18, 2017 at 8:11 AM, Michael Torrie  wrote:
> On 05/17/2017 02:31 PM, Ned Batchelder wrote:
>> Can you give an example of such a method? Often, that signature is used
>> because there is no pre-conception of what the arguments might be.
>
> I'm not sure if this afflicts the standard library, but in my own code,
> since Python doesn't support constructors with different signatures, you
> pretty much have to rely on kwargs with __init__() to handle different
> permutations of construction arguments.  Not that we don't know what the
> arguments might be, we just don't know which of them we'll have to deal
> with.  Maybe the standard library is better designed than my own code,
> but I find I have to implement __init__(self, **kwargs) all the time.

Also worth noting is that decorators sometimes have to go *a,**kw on
their functions. Until a couple of versions ago, help() would always
just show *a,**kw, but now there's a protocol between
functools.wraps() and help() that carries the original signature
through. Depending on exactly where you're viewing the info, eg
whether it uses inspect.getsignature or not, you might see the carried
original, or you might see *a,**kw.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29102] Add an id field to PyInterpreterState.


STINNER Victor added the comment:

What the status of this issue Eric? Do you still need interpreter ID?

--

___
Python tracker 

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

Re: How to install Python package from source on Windows

On Thu, May 18, 2017 at 8:21 AM, bartc  wrote:
> My own approach with the standard library is that I just use what is
> provided by the OS (so msvcrt.dll or libc.so.6).
>
> I expect Tiny C does the same as it doesn't appear to come with any
> libraries of its own.

Well, msvcrt.dll isn't the whole thing. You need the compilation end
of that too (header files and static libraries). Where are you going
to get those from? Oh right. The dev version of msvcrt.dll is in
Visual Studio.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to install Python package from source on Windows


On 17/05/2017 21:49, Chris Angelico wrote:


Before you can build CPython with Tiny C, you need to be sure that Tiny C can:

1) malloc and free arbitrary blocks of memory
2) open and close files and do other file system operations


It would be a bit limiting if it couldn't! Tiny C isn't a toy (I did 
think so once before I tried it). It's just very small and very fast.


With building, you just have to try compiling and linking (given the 
right file information) and see what errors arise.



3) perform trignometric calculations (sin/cos/tan and friends)
4) start threads and subprocesses
5) ascertain the time of day and any other clocks available
6) acquire and release semaphores
etc, etc, etc.

These features are provided generally by the C standard library. Does
Tiny C support all of those? If so, how? Do you include a full
standard library, or link against someone else's?


I'm not the author of Tiny C, so I wouldn't know.

My own approach with the standard library is that I just use what is 
provided by the OS (so msvcrt.dll or libc.so.6).


I expect Tiny C does the same as it doesn't appear to come with any 
libraries of its own.



--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: How to install Python package from source on Windows

On Thu, May 18, 2017 at 8:06 AM, Christian Gollwitzer  wrote:
> Am 16.05.17 um 09:53 schrieb Chris Angelico:
>>
>> On Tue, May 16, 2017 at 5:14 PM, Christian Gollwitzer 
>> wrote:
>>>
>>> More likely would be the option to ship a C compiler with Python written
>>> in
>>> C. For C++ this is way too big, but a pure C compiler can be as small as
>>> 1MB. tcc has a liberal license, supports many platforms and gives
>>> reasonable
>>> (unoptimized) code.
>>
>>
>> To do that, Python would itself have to be compiled with tcc, or else
>> all memory de/allocation would have to be funneled through a
>> Python-provided API. And that's going to kill performance, I suspect.
>
>
> I don't understand this remark. Why would that be needed?
> The C ABI is well defined on the usual systems, and tcc is compatible with
> the respective compilers. You can link together objects from tcc, gcc and
> icc on Linux /OSX or tcc, MSVC and gcc on Windows without problems.
> tcc is *only* the compiler, not a library, so it will call out into the C
> library that Python is using.
>
> tcc even has a "JIT-mode" of operation (libtcc). For Tcl, there exists an
> extension which compiles C code to memory and executes directly from there.
> The same thing could be done for Python, too.

One of the complaints that bartc raised against clang was that it's
not self-contained - that it depends on some other stdlib. Yet he
espouses a tiny C compiler that obviously has the same limitation. On
my Linux boxes, I can grab GNU libc; but on Windows, where are you
going to get the header files and link-time libraries from? Oh right.
MSVC.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Survey: improving the Python std lib docs

On 05/17/2017 02:31 PM, Ned Batchelder wrote:
> Can you give an example of such a method? Often, that signature is used
> because there is no pre-conception of what the arguments might be.

I'm not sure if this afflicts the standard library, but in my own code,
since Python doesn't support constructors with different signatures, you
pretty much have to rely on kwargs with __init__() to handle different
permutations of construction arguments.  Not that we don't know what the
arguments might be, we just don't know which of them we'll have to deal
with.  Maybe the standard library is better designed than my own code,
but I find I have to implement __init__(self, **kwargs) all the time.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to install Python package from source on Windows

2017-05-17 Thread Christian Gollwitzer


Am 16.05.17 um 09:53 schrieb Chris Angelico:

On Tue, May 16, 2017 at 5:14 PM, Christian Gollwitzer  wrote:

More likely would be the option to ship a C compiler with Python written in
C. For C++ this is way too big, but a pure C compiler can be as small as
1MB. tcc has a liberal license, supports many platforms and gives reasonable
(unoptimized) code.


To do that, Python would itself have to be compiled with tcc, or else
all memory de/allocation would have to be funneled through a
Python-provided API. And that's going to kill performance, I suspect.


I don't understand this remark. Why would that be needed?
The C ABI is well defined on the usual systems, and tcc is compatible 
with the respective compilers. You can link together objects from tcc, 
gcc and icc on Linux /OSX or tcc, MSVC and gcc on Windows without problems.
tcc is *only* the compiler, not a library, so it will call out into the 
C library that Python is using.


tcc even has a "JIT-mode" of operation (libtcc). For Tcl, there exists 
an extension which compiles C code to memory and executes directly from 
there. The same thing could be done for Python, too.


Christian
--
https://mail.python.org/mailman/listinfo/python-list

[issue30303] IDLE: Add _utest to textview and add textview tests


Terry J. Reedy added the comment:

I am adding a couple of exception tests to complete coverage.

--

___
Python tracker 

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

[issue30303] IDLE: Add _utest to textview and add textview tests


Changes by Terry J. Reedy :


--
title: IDLE: Add _utest to textview -> IDLE: Add _utest to textview and add 
textview tests

___
Python tracker 

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

[issue30303] IDLE: Add _utest to textview


Changes by Terry J. Reedy :


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

[issue30357] test_thread should clean threads after each test


STINNER Victor added the comment:


New changeset f5633e02433a81a6d0f14fc1c3294e752f4ac1a3 by Victor Stinner in 
branch '3.5':
bpo-30387: Fix warning in test_threading (#1634) (#1637)
https://github.com/python/cpython/commit/f5633e02433a81a6d0f14fc1c3294e752f4ac1a3


--

___
Python tracker 

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

[issue18617] AIA chasing for missing intermediate certificates on TLS connections

2017-05-17 Thread April King


April King added the comment:

Err, sorry, I may have been a bit unclear.  AIA chasing is not *universal* 
amongst browsers.  IE, Edge, Chrome, and Safari perform AIA chasing.  Firefox 
maintains a cache of intermediate certificate authorities.  I noted that a bit 
further underneath, but my apologies if it was confusing.

That said, every browser has a some chosen some underlying method to ameliorate 
this common TLS error.  It would be amazing if Python could similarly resolve 
this issue for developers.

--

___
Python tracker 

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

[issue29063] Fixed timemodule compile warnings (gmtoff).


STINNER Victor added the comment:

I backported the fix to 3.6. So all warnings on timemodule.c should now be 
fixed. Thanks for the bug report and the patch Decorater! 

commit 69f3a5ac28041fac86897e0c90d98ad9fd6fa3f7
Author: Victor Stinner 
Date:   Wed May 17 14:45:45 2017 -0700

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

___
Python tracker 

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

Re: How to install Python package from source on Windows


On 17/05/2017 22:40, Chris Angelico wrote:

On Thu, May 18, 2017 at 6:52 AM, bartc  wrote:

determines whether your system has the required
compilers and libraries, figures out what source files should be
compiled, and calculates the order in which to build the source files.



Yes! That's what I need!

But either this information is highly classified, or nobody here actually
knows how to extract it from the output of configure or the makefile or
wherever it ends up.



Have you looked in config.log?


Don't have to run it first?


configure:3651: checking for gcc
configure:3667: found /usr/bin/gcc
configure:3678: result: gcc

Or the less verbose form that you see on the console while it's
actually running?


That sounds like the answer is yes!

OK, so maybe I can get an idea of what's involved if I run it on another 
computer that has Linux. But I expect that the output will then be 
slanted at that system rather than mine.



and some architecture-specific things:

checking whether C doubles are little-endian IEEE 754 binary64... yes
checking whether C doubles are big-endian IEEE 754 binary64... no
checking whether C doubles are ARM mixed-endian IEEE 754 binary64... no
checking whether we can use gcc inline assembler to get and set x87
control word... yes
checking whether we can use gcc inline assembler to get and set
mc68881 fpcr... no


It sounds more like CPython is written in assembly code rather than C. 
Why don't the C language, C compilers and their optimisers take care of 
these concerns?


(And what does the build system do with all this information, or is this 
just routinely gathered anyway whether the application needs it or not?)


--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

[issue30357] test_thread should clean threads after each test


STINNER Victor added the comment:


New changeset 44944b602af23712d7119801183cdc6e202e4f76 by Victor Stinner in 
branch '3.6':
bpo-30387: Fix warning in test_threading (#1634) (#1636)
https://github.com/python/cpython/commit/44944b602af23712d7119801183cdc6e202e4f76


--

___
Python tracker 

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

Re: How to install Python package from source on Windows

2017-05-17 Thread Ian Kelly

On Wed, May 17, 2017 at 2:52 PM, bartc  wrote:
>
> On 17/05/2017 21:17, Michael Torrie wrote:
>>
>> On 05/17/2017 01:32 PM, bartc wrote:
>>>
>>> Sometimes, if there's a problem. But usually the code is doing something
>>> sensible. The stuff in configure is complete gobbledygook (if anyone
>>> doesn't believe me, just have look).
>>
>>
>> Well trying to edit an executable in a disassembler would look like
>> gobligook as well.
>
>
> The content of configure is high-level human readable source code. But it
is meaningless.

configure is generated code. If you want to understand what it's doing then
you should really be looking at configure.ac. But that's a whole language
of its own.

>> What a wonderful simplification!  But yes, you're essentially correct.
>> All this gobbligook figures out how to best configure the features and
>> options you require,
>
>
> Well, while we're here, why don't /you/ run configure and tell me what
the output is. Preferably in a form I can understand.
>
> Here's the input data:
>
>  OS:Windows 7
>  Processor: Intel 64-bit
>
> Um, that's it I guess. I only need enough info to build, say, python.exe;
just something to get to first base. (I don't know what the other binary
files are or where they live.)

The input data isn't just a description of your system. It's your actual
system, including the particulars of your exact compiler and libc version
as well as optional libraries you may have installed. Generally speaking,
the way configure checks for features is by writing a short program that
uses the feature and trying to compile it.

>> determines whether your system has the required
>> compilers and libraries, figures out what source files should be
>> compiled, and calculates the order in which to build the source files.
>
>
> Yes! That's what I need!
>
> But either this information is highly classified, or nobody here actually
knows how to extract it from the output of configure or the makefile or
wherever it ends up.

configure has two primary outputs: Makefile and pyconfig.h. The latter is
actually the more important one. You can probably figure out *what* to
build and in what order just by reading Makefile.pre.in which is
essentially a template for the actual Makefile. But you're not going to get
very far without the huge number of #defines in pyconfig.h which determine
things like "is pthread.h available on this system" or "how many bytes is
the double typle on this system".

> Or, more importantly, how this list of files could be determined manually.

You're funny. :-)

> Yes. The end-result of all this might be something like:
>
>   gcc -c file1.c
>   gcc -c file2.c
>   ...
>   gcc file1.o file2.o ... -opython.exe
>
> Someone please explain why I can't just do that

Because, as has already been stated, there's no way to make such a simple
process cross-platform.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to install Python package from source on Windows

On 05/17/2017 02:52 PM, bartc wrote:
> On 17/05/2017 21:17, Michael Torrie wrote:
>> On 05/17/2017 01:32 PM, bartc wrote:
>>> Sometimes, if there's a problem. But usually the code is doing something
>>> sensible. The stuff in configure is complete gobbledygook (if anyone
>>> doesn't believe me, just have look).
>>
>> Well trying to edit an executable in a disassembler would look like
>> gobligook as well.
> 
> The content of configure is high-level human readable source code. But 
> it is meaningless.

No, I assure you, it's compiled code.  Happens to be readable to those
who know how to read it, but it was never written by a human.

> 

> Yes. The end-result of all this might be something like:
> 
>gcc -c file1.c
>gcc -c file2.c
>...
>gcc file1.o file2.o ... -opython.exe
> 
> Someone please explain why I can't just do that

You sure could if you were sure of the right order given dependencies
(.h files).  But it would be tedious if you had thousands of source code
files.  And what if you had a common header file depended on by hundreds
of other files?  You'd have to either manually identify each affected
file and recompile it, or recompile the whole works again.  For a large
project, or even a medium-sized one, that's just not sustainable.  Sure
you could put more in a file, as you already do, and that works for
small projects such as your compilers and also sqlite.  Wouldn't work at
all for the Linux kernel, of course.

That said, there are huge benefits to keeping your source files short,
modular, and as abstract as possible. And huge benefits to using a build
manager program like scons, qmake, or even Visual Studio solutions, even
to small programs.

I tend to do the same as you for small, one-off programs. I just compile
and link them with gcc manually.  Since that fits your needs you can
keep doing it.  Eventually you may encounter the limitations of that,
and then you can think about investigating a tool like scons.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to install Python package from source on Windows


On 17/05/2017 21:39, Chris Angelico wrote:

On Thu, May 18, 2017 at 5:32 AM, bartc  wrote:



It is impossible that all this is needed just to figure out what source
files need to be compiled. (If it generated CPython sources fractal-style,
then I might be impressed, but doesn't.)


I love how absolutely certain you are that this is *impossible*. Ahh,
that naivety again. Though in this case, you do happen to be correct:
it's doing more than merely figuring out which files to compile. It's
figuring out what libraries are available, what features are available
in those libraries, how the compiler produces object files, whether
the build environment is sane, and in some cases, enumerating all
available compilers so you can pick and choose. Imagine if your
compiler could detect whether nasm, tasm, masm, or gas is installed,
and emit appropriate assembly code for any of them. That's what you
need a configure script for.


Please tell me you don't seriously think it takes 18,000 lines of script 
just to do that.


And if you don't, what are the other 17,000 lines doing, or don't you care?

(Actually I've seen a 20,000-line configure just trying to compile the 
GMP library.)



(BTW I've gone down the route of installing MSYS etc many times, something
always went wrong. Why is it that people can't appreciate that complicated
thing are more likely to go wrong?)


Why would bash not exist? Or do you mean that it exists, but isn't installed?


Because it (and all the utilities the script intends to use) exist on a 
different OS?



I've put some comments here: https://pastebin.XXX/hSCjNsA2 as it's getting
way off-topic.


Not interested in clicking on a pastebin with all its ads.


OK, 30 minutes of effort down the drain. (I've deleted the link now.)

If you don't want to believe that my compilers are capable of competing 
with gcc, then don't. It doesn't change the facts.


gcc can do astonishing things with small, tight, benchmarks or when 
directed at specific bottlenecks. But its optimisations have less 
dramatic effects on some real applications such as mine.


(And take another look at the figures I posted yesterday comparing gcc 
with Tiny C, with an extra line:


 Tiny C 6.7 seconds
 gcc -O33.6 seconds
 My comp:   1.2 seconds with ASM help

Yes, that last figure is three times the speed of gcc. If you won't 
believe 30% slower, then I doubt you will 200% faster! Yes, one module 
is ASM, but the others are HLL, and no C compiler is involved.)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: How to install Python package from source on Windows

On Thu, May 18, 2017 at 6:52 AM, bartc  wrote:
>> determines whether your system has the required
>> compilers and libraries, figures out what source files should be
>> compiled, and calculates the order in which to build the source files.
>
>
> Yes! That's what I need!
>
> But either this information is highly classified, or nobody here actually
> knows how to extract it from the output of configure or the makefile or
> wherever it ends up.
>

Have you looked in config.log?

configure:3651: checking for gcc
configure:3667: found /usr/bin/gcc
configure:3678: result: gcc

Or the less verbose form that you see on the console while it's
actually running?

checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E

And of course, there's all the headers that Python looks for:

checking spawn.h usability... yes
checking spawn.h presence... yes
checking for spawn.h... yes
checking util.h usability... no
checking util.h presence... no
checking for util.h... no
checking alloca.h usability... yes
checking alloca.h presence... yes
checking for alloca.h... yes
checking endian.h usability... yes
checking endian.h presence... yes
checking for endian.h... yes

and the standard library functions:

checking for kill... yes
checking for killpg... yes
checking for lchmod... no
checking for lchown... yes
checking for linkat... yes
checking for lstat... yes
checking for lutimes... yes
checking for mmap... yes

and some architecture-specific things:

checking whether C doubles are little-endian IEEE 754 binary64... yes
checking whether C doubles are big-endian IEEE 754 binary64... no
checking whether C doubles are ARM mixed-endian IEEE 754 binary64... no
checking whether we can use gcc inline assembler to get and set x87
control word... yes
checking whether we can use gcc inline assembler to get and set
mc68881 fpcr... no
checking for x87-style double rounding... no

For "highly classified" information, this is being very well hidden in
plain sight.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30303] IDLE: Add _utest to textview


Terry J. Reedy added the comment:


New changeset ba365da9cee8901fad08ab0b61c7489c110e5c97 by terryjreedy (Louie 
Lu) in branch 'master':
bpo-30303: IDLE: Add _utest argument to textview (#1499)
https://github.com/python/cpython/commit/ba365da9cee8901fad08ab0b61c7489c110e5c97


--

___
Python tracker 

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

[issue18617] AIA chasing for missing intermediate certificates on TLS connections

2017-05-17 Thread April King

April King added the comment:

Browsers universally support AIA chasing/fetching, as do a number of underlying
OS libraries, such as Secure Transport (macOS) and schannel (Windows).

As a result, it is becoming increasingly common for server operators to fail to
include the entire certificate chain in their handshake. By some measures,
anywhere from 10 to over 30% of all TLS errors(1) are caused by missing
intermediate certificates.

There are a handful of ways that scanners and other tools have worked around
this issue. Some, like SSL Labs, do their own AIA chasing. Others make
subprocess to other tools linked to OS libraries which invisibly perform AIA
chasing, such as curl on macOS. Others, like Firefox, maintain a cache of
intermediate certificates.

In any case, all of these solutions are concession to the reality that TLS is
really hard and that it is largely impossible to solve this particular
misconfiguration issue.

I myself write a popular tool(2) that does scanning of sites for missing
security configurations. Although it's not explicitly focused on TLS, some of
the underlying tests rely on a verified TLS connection. For example, the HTTP
Strict Transport Security (HSTS) header can only be set on valid TLS
connections. I use requests (which uses httplib underneath), but I'm unable to
tell if a given certificate error is because of either:

a) the certificate validation actually failed (for example, due to being
expired), or
b) there was a missing intermediate certificate and that things would have
worked if AIA chasing was available

As a result, I have to tell people that their HSTS header can't be set. This is
often incorrect, because browsers that do AIA chasing consider the connection
perfectly secure for the purposes of HSTS.

It would be really nice if Python's httplib could be updated to do transparent
AIA chasing, with the optional ability to turn it off. In an ideal world, the
underlying TLS libraries (such as OpenSSL) would do this for us, but
unfortunately as things stand now OpenSSL leaves it up to the applications
themselves to perform chasing. According to Mozilla research (3), if
implemented, it would reduce TLS errors by approximately 6% were AIA chasing
always performed and successful.

Thanks!

1.
https://docs.google.com/document/d/1ryqFMSHHRDERg1jm3LeVt7VMfxtXXrI8p49gmtniNP0/edit?pli=1
2. https://observatory.mozilla.org/
3. https://bugzilla.mozilla.org/show_bug.cgi?id=399324#c80

--
nosy: +april
title: TLS and Intermediate Certificates -> AIA chasing for missing
intermediate certificates on TLS connections

___
Python tracker

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

[issue30387] warning of threading_cleanup in test_threading


STINNER Victor added the comment:


New changeset f5633e02433a81a6d0f14fc1c3294e752f4ac1a3 by Victor Stinner in 
branch '3.5':
bpo-30387: Fix warning in test_threading (#1634) (#1637)
https://github.com/python/cpython/commit/f5633e02433a81a6d0f14fc1c3294e752f4ac1a3


--

___
Python tracker 

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

[issue30387] warning of threading_cleanup in test_threading


STINNER Victor added the comment:


New changeset 44944b602af23712d7119801183cdc6e202e4f76 by Victor Stinner in 
branch '3.6':
bpo-30387: Fix warning in test_threading (#1634) (#1636)
https://github.com/python/cpython/commit/44944b602af23712d7119801183cdc6e202e4f76


--

___
Python tracker 

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

[issue30393] test_readline hangs

2017-05-17 Thread wmayner


New submission from wmayner:

I'm trying to build Python 3.6.1 from source with the `--enable-optimizations` 
configuration option. As I understand it, this entails running and profiling 
all the tests for PGO. When `test_readline` is run, it hangs.

OS: Debian 3.16.43-2 (2017-04-30) x86_64 GNU/Linux

Please let me know what other information I should provide.

--
components: Tests
messages: 293888
nosy: wmayner
priority: normal
severity: normal
status: open
title: test_readline hangs
type: behavior
versions: Python 3.6

___
Python tracker 

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

[issue17560] problem using multiprocessing with really big objects?

2017-05-17 Thread Igor


Changes by Igor :


--
nosy: +i3v

___
Python tracker 

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

[issue29102] Add an id field to PyInterpreterState.

2017-05-17 Thread Eric Snow


Changes by Eric Snow :


--
pull_requests: +1734

___
Python tracker 

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

[issue28411] Eliminate PyInterpreterState.modules.

2017-05-17 Thread Eric Snow


Changes by Eric Snow :


--
pull_requests: +1732

___
Python tracker 

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

Re: How to install Python package from source on Windows


On 17/05/2017 21:17, Michael Torrie wrote:

On 05/17/2017 01:32 PM, bartc wrote:

Sometimes, if there's a problem. But usually the code is doing something
sensible. The stuff in configure is complete gobbledygook (if anyone
doesn't believe me, just have look).


Well trying to edit an executable in a disassembler would look like
gobligook as well.


The content of configure is high-level human readable source code. But 
it is meaningless.



What a wonderful simplification!  But yes, you're essentially correct.
All this gobbligook figures out how to best configure the features and
options you require,


Well, while we're here, why don't /you/ run configure and tell me what 
the output is. Preferably in a form I can understand.


Here's the input data:

 OS:Windows 7
 Processor: Intel 64-bit

Um, that's it I guess. I only need enough info to build, say, 
python.exe; just something to get to first base. (I don't know what the 
other binary files are or where they live.)


(I have visions of you now feeding a punched card into a computer called 
Multivac occupying a cubic mile of vacuum tubes and relays... That's 
about the same degree of overkill!)



determines whether your system has the required
compilers and libraries, figures out what source files should be
compiled, and calculates the order in which to build the source files.


Yes! That's what I need!

But either this information is highly classified, or nobody here 
actually knows how to extract it from the output of configure or the 
makefile or wherever it ends up.


Or, more importantly, how this list of files could be determined manually.


All of things things are very important. I'd rather have this and keep
my build times down to seconds and minutes than have to recompile all
million lines of code for just one change.


Once again, this is not for development. It's a one-off build of a fresh 
download, so everything will need compiling anyway.



I admit autoconf is hard to wrap my head around, hard to use as a
programmer, and even harder to extend to handle new libraries and new
compilers.


Has someone thought about replacing it then? I would be nervous about 
running 2 lines of AI-generated code that manipulates my file system.



are very nice and simple, and cross-platform.  But all of these generate
Makefiles, which would likely be considered unnecessary gobbligook to
you, I suspect.


Yes. The end-result of all this might be something like:

  gcc -c file1.c
  gcc -c file2.c
  ...
  gcc file1.o file2.o ... -opython.exe

Someone please explain why I can't just do that

--
bartc



--
https://mail.python.org/mailman/listinfo/python-list

Re: New to python and programming

2017-05-17 Thread Ray Cote

On Wed, May 17, 2017 at 4:43 PM, justin walters 
wrote:

> On Wed, May 17, 2017 at 12:59 PM, BT  wrote:
>
> > Hi guys,
> > I am fairly new to programming. I was just trying to understand how this
> > group works. Am i allowed to ask any questions that I may have when i get
> > stuck? I mean is this group for new programmers as well..?
> > Thanks
>
> You might want to check out the Python Tutors list:
   https://mail.python.org/mailman/listinfo/tutor

It is friendly towards beginner questions.
—Ray
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to python and programming

2017-05-17 Thread Ben Bacarisse

BT  writes:

> I am fairly new to programming. I was just trying to understand how
> this group works. Am i allowed to ask any questions that I may have
> when i get stuck? I mean is this group for new programmers as well..?

Welcome.  Yes, it's for pretty much any questions about Python
programming.

Some questions turn out to be about something else (graphics algorithms,
SQL statements) that comes up in the course of Python programming and in
those cases people will suggest you ask elsewhere.

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to python and programming

On Thu, May 18, 2017 at 5:59 AM, BT  wrote:
> I am fairly new to programming. I was just trying to understand how this 
> group works. Am i allowed to ask any questions that I may have when i get 
> stuck? I mean is this group for new programmers as well..?
>

Hi! Yes, it is, but if you're really REALLY new, you may want to try
the python-tutor mailing list:

https://mail.python.org/mailman/listinfo/tutor

This list tends to wander off into tangential topics a bit, and will
also tend to go into some fairly detailed minutiae, so the tutor list
is probably more useful if you're looking for just the basics. But
you're most welcome to hop back and forth between the two, lurk on
both of them, and learn everything you can.

Welcome to the community. :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to install Python package from source on Windows

On Thu, May 18, 2017 at 6:27 AM, bartc  wrote:
> I'll repeat what I said before: I don't want to build CPython with VS2015. I
> wanted to build it with Tiny C.
>
> The purpose of doing the latter was to evaluate what the performance might
> be, if for example Tiny C became the bundled C compiler so as to quickly get
> a source distribution going. Bundling VS2015 with CPython sources is not
> going to happen.
>
> (Although I wouldn't really be surprised if someone tried it. People here
> don't seem to see anything wrong with cracking a small nut with a
> particularly massive sledgehammer.)

Before you can build CPython with Tiny C, you need to be sure that Tiny C can:

1) malloc and free arbitrary blocks of memory
2) open and close files and do other file system operations
3) perform trignometric calculations (sin/cos/tan and friends)
4) start threads and subprocesses
5) ascertain the time of day and any other clocks available
6) acquire and release semaphores
etc, etc, etc.

These features are provided generally by the C standard library. Does
Tiny C support all of those? If so, how? Do you include a full
standard library, or link against someone else's?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29104] Left bracket remains in format string result when '\' preceeds it

2017-05-17 Thread Mariatta Wijaya


Changes by Mariatta Wijaya :


--
stage:  -> patch review

___
Python tracker 

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

[issue29660] Document that print/format_exception ignore etype

2017-05-17 Thread Mariatta Wijaya


Changes by Mariatta Wijaya :


--
stage:  -> patch review

___
Python tracker 

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

Re: New to python and programming

2017-05-17 Thread justin walters

On Wed, May 17, 2017 at 12:59 PM, BT  wrote:

> Hi guys,
> I am fairly new to programming. I was just trying to understand how this
> group works. Am i allowed to ask any questions that I may have when i get
> stuck? I mean is this group for new programmers as well..?
> Thanks
> --
> https://mail.python.org/mailman/listinfo/python-list
>

The mailing list info page doesn't mention anything specific about asking
for help: https://mail.python.org/mailman/listinfo/python-list

People do routinely ask for help here though. I think I can speak for
everyone when I say
that you should make sure that you try to find the answer using your search
engine
of choice before bringing the question here. Your question may be a very
common one
and you might be able to find the answer more quickly on, say, stack
overflow.

All that said, welcome to the list! Some of the conversation can get a
little fiery,
but it's entertaining at the least.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to install Python package from source on Windows

On Thu, May 18, 2017 at 5:32 AM, bartc  wrote:
> On 17/05/2017 17:23, Chris Angelico wrote:
>>
>> On Thu, May 18, 2017 at 1:37 AM, bartc  wrote:
>>>
>>> On 17/05/2017 15:13, Chris Angelico wrote:
>
>
>> [1] Does work on Windows. Install bash for Windows, or (on a
>> recent-enough Windows) just use the subsystem that Microsoft provides.
>
>
> So the answer is, switch to Linux. In other words, a cop-out.

No, I said "install bash". Since when does bash imply Linux? You can
get bash for any of the major platforms in use today. It's the default
user login shell on most Mac OS and Linux systems, as well as a good
smattering of other OSes.

>> [2] So? You don't have to read it, just run it. Or do you read every
>> line of code that any of your programs executes?
>
>
> Sometimes, if there's a problem. But usually the code is doing something
> sensible. The stuff in configure is complete gobbledygook (if anyone doesn't
> believe me, just have look).

That's because "configure" isn't source code. It's like someone
looking at your nasm files and moaning that they're unreadable. You
don't directly read or edit the configure script.

> It is impossible that all this is needed just to figure out what source
> files need to be compiled. (If it generated CPython sources fractal-style,
> then I might be impressed, but doesn't.)

I love how absolutely certain you are that this is *impossible*. Ahh,
that naivety again. Though in this case, you do happen to be correct:
it's doing more than merely figuring out which files to compile. It's
figuring out what libraries are available, what features are available
in those libraries, how the compiler produces object files, whether
the build environment is sane, and in some cases, enumerating all
available compilers so you can pick and choose. Imagine if your
compiler could detect whether nasm, tasm, masm, or gas is installed,
and emit appropriate assembly code for any of them. That's what you
need a configure script for.

>> How about if I put you on a different CPU than you're used to? Can you
>> use your tiny C compiler? I doubt it, because it's emitting Intel byte
>> code.
>
> I'm used to it. I used to start off with machines with no software in them
> at all. (Actually, I often needed to wire up the boards first.)
>
> The point I'm making is that these things should still work when reduced to
> the basics.

Define "basics". You seem to assume an Intel x86 CPU and nothing else,
or your program won't be any use. What's the point in reducing below
an OS if you're still depending on a specific line of CPUs? Are you
expecting to compile your own OS kernel? Type one in at the console?

> What it does show is that it is practical to reduce a substantial
> application to a single file, and trivially build it pretty much everywhere,
> as C compilers are ubiquitous. And that it will run with little trouble. The
> same source can run on ARM32, x86 and x64; Linux or Windows. Probably
> elsewhere but that is the extent of my tests.)

"substantial". Exactly how much code are you talking about? And how
portable does it need to be?

>> You're asking me to bootstrap Python. I would start by looking for the
>> nearest similar platform and trying to build a hybrid. I haven't done
>> this with Python itself, but a while ago, I wanted to port a
>> similarly-sized language to OS/2, and the process went like this:
>>
>> 1) Attempt to run the configure script, using bash and gcc (which
>> already existed for OS/2)
>
> I said bash didn't exist.
>
> (BTW I've gone down the route of installing MSYS etc many times, something
> always went wrong. Why is it that people can't appreciate that complicated
> thing are more likely to go wrong?)

Why would bash not exist? Or do you mean that it exists, but isn't installed?

>> Yes. Yes, it is. For starters, GCC actually can compile to machine
>> code, instead of depending on nasm.
>
>
> I don't think it does. gcc AFAIK generates assembly code (via pipes or
> equivalent so usually you don't see it), then invokes an assembler called
> 'as' to convert into object code.
>
> I believe that the base gcc compiler is separate from the bin-utils such as
> 'as' and 'ld' (the linker).

Check that. I think you'll find that you measured the size of the
compiler with the assembler.

> Downloading gcc tdm for Windows, these are separate download bundles. On
> Linux, this stuff is pre-installed so it's easy to think it's all the same
> thing.

No, it isn't pre-installed. Have you ever actually used Linux, or do
you just express assumptions as facts?

> When /my/ compiler does it properly, then it will be truly self-contained.
> And still be one executable.

Sure. Now tell me. What's your standard library? Let's suppose you
want to sort an array of numbers, for instance. Do you have a stdlib
function available to do that? And if so, do you include a complete
copy of your entire stdlib in every one of your output executables?

>> Then do it. Make

Re: Survey: improving the Python std lib docs

2017-05-17 Thread Ned Batchelder

On Wednesday, May 17, 2017 at 5:48:30 AM UTC-4, Cem Karan wrote:
> On May 16, 2017, at 12:36 PM, rzed  wrote:
> 
> > On Friday, May 12, 2017 at 6:02:58 AM UTC-4, Steve D'Aprano wrote:
> >> One of the more controversial aspects of the Python ecosystem is the Python
> >> docs. Some people love them, and some people hate them and describe them as
> >> horrible.
> >> 
> > [...]
> > 
> > One thing I would love to see in any function or class docs is a few 
> > example invocations, preferably non-trivial. If I need to see more, I can 
> > read the entire doc, but most times I just want a refresher on how the 
> > function is called. Does it use keywords? Are there required nameless 
> > parameters? In what order? A line or two would immediately clarify that 
> > most of the time. 
> > 
> > Apart from that, links to docs for uncommon functions (or to the docs of 
> > the module, if there are many) would be at least somewhat useful.
> 
> I'd like to see complete signatures in the docstrings, so when I use help() 
> on something that has *args or **kwargs I can see what the arguments actually 
> are.


Can you give an example of such a method? Often, that signature is used
because there is no pre-conception of what the arguments might be.

--Ned.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29723] 3.6.1rc1 adds the current directory to sys.path when running a subdirectory's main.py; previous versions did not

2017-05-17 Thread Eric Snow


Changes by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue30039] Resuming a 'yield from' stack is broken if a signal arrives in the middle


Yury Selivanov added the comment:


New changeset ab4413a7e9bda95b6fcd517073e2a51dafaa1624 by Yury Selivanov 
(Nathaniel J. Smith) in branch 'master':
bpo-30039: Don't run signal handlers while resuming a yield from stack (#1081)
https://github.com/python/cpython/commit/ab4413a7e9bda95b6fcd517073e2a51dafaa1624


--

___
Python tracker 

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

[issue30318] test_distutils is too verbose on Windows


STINNER Victor added the comment:

> The problem here I think is that distutils itself should only dump 
> stdout/stderr on failure, ...

Hum, I would like to see warnings even if the compilation succeed. So I would 
prefer to only modify test_distutils.

--

___
Python tracker 

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

Re: How to install Python package from source on Windows


On 17/05/2017 21:05, breamore...@gmail.com wrote:

On Wednesday, May 17, 2017 at 8:32:40 PM UTC+1, bartc wrote:

On 17/05/2017 17:23, Chris Angelico wrote:

On Thu, May 18, 2017 at 1:37 AM, bartc  wrote:

On 17/05/2017 15:13, Chris Angelico wrote:



[1] Does work on Windows. Install bash for Windows, or (on a
recent-enough Windows) just use the subsystem that Microsoft provides.


So the answer is, switch to Linux. In other words, a cop-out.

--
bartc


Poor old Chris seems to be getting a little frustrated so I'll just repeat what 
I said previously.


What is the problem with the documentation given here 
https://docs.python.org/devguide ?

Specifically:-

"and on Windows use:

PCbuild\build.bat -e -d"


That is 24 key strokes, including ENTER, to do the build on Windows.  What is 
so difficult about this?


I'll repeat what I said before: I don't want to build CPython with 
VS2015. I wanted to build it with Tiny C.


The purpose of doing the latter was to evaluate what the performance 
might be, if for example Tiny C became the bundled C compiler so as to 
quickly get a source distribution going. Bundling VS2015 with CPython 
sources is not going to happen.


(Although I wouldn't really be surprised if someone tried it. People 
here don't seem to see anything wrong with cracking a small nut with a 
particularly massive sledgehammer.)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: How to install Python package from source on Windows

On 05/17/2017 01:32 PM, bartc wrote:
> Sometimes, if there's a problem. But usually the code is doing something 
> sensible. The stuff in configure is complete gobbledygook (if anyone 
> doesn't believe me, just have look).

Well trying to edit an executable in a disassembler would look like
gobligook as well.  configure is a generated script from a compiler
called autoconf.  It is compiled from some high-level macros that are
somewhat easier to understand.  The system is convenient because we can
abstract away differences in target OS platforms more easily.

> It is impossible that all this is needed just to figure out what
> source files need to be compiled. (If it generated CPython sources
> fractal-style, then I might be impressed, but doesn't.)

What a wonderful simplification!  But yes, you're essentially correct.
All this gobbligook figures out how to best configure the features and
options you require, determines whether your system has the required
compilers and libraries, figures out what source files should be
compiled, and calculates the order in which to build the source files.
All of things things are very important. I'd rather have this and keep
my build times down to seconds and minutes than have to recompile all
million lines of code for just one change.

I admit autoconf is hard to wrap my head around, hard to use as a
programmer, and even harder to extend to handle new libraries and new
compilers.

You'd probably find scons more to your liking, and Qt's QMake facilities
are very nice and simple, and cross-platform.  But all of these generate
Makefiles, which would likely be considered unnecessary gobbligook to
you, I suspect.

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30318] test_distutils is too verbose on Windows

2017-05-17 Thread Steve Dower


Steve Dower added the comment:

The problem here I think is that distutils itself should only dump 
stdout/stderr on failure, but because of how it spawns processes it never 
actually captures the output from external tools.

We really need to update distutils's spawn() function to use subprocess. That 
would also resolve a handful of other issues.

--

___
Python tracker 

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

[issue30390] Document how to make classes in the C API.

2017-05-17 Thread Serhiy Storchaka


Serhiy Storchaka added the comment:

The title of this issue is "Document how to make classes in the C API." This 
already is documented.

For documenting the PyClassMethod* names open a new issue.

--
status: open -> closed

___
Python tracker 

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

New to python and programming

2017-05-17 Thread BT

Hi guys,
I am fairly new to programming. I was just trying to understand how this group 
works. Am i allowed to ask any questions that I may have when i get stuck? I 
mean is this group for new programmers as well..?
Thanks
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29619] st_ino (unsigned long long) is casted to long long in posixmodule.c:_pystat_fromstructstat

2017-05-17 Thread Xavier de Gaye


Xavier de Gaye added the comment:

> What is the type of st_ino? It's not off_t?

The type of st_ino is unsigned long long as defined in sys/stat.h for x86 and 
off_t is defined in sys/types.h this way;, quoting:

/* This historical accident means that we had a 32-bit off_t on 32-bit 
architectures. */
typedef __kernel_off_t off_t;

There is also a related section in the bionic github repo [1] quoted here:

=
This probably belongs in the NDK documentation rather than here, but these are 
the known ABI bugs in the 32-bit ABI:

time_t is 32-bit. http://b/5819737. In the 64-bit ABI, time_t is 64-bit.

off_t is 32-bit. There is off64_t, and in newer releases there is 
almost-complete support for _FILE_OFFSET_BITS. Unfortunately our stdio 
implementation uses 32-bit offsets and -- worse -- function pointers to 
functions that use 32-bit offsets, so there's no good way to implement the last 
few pieces http://b/24807045. In the 64-bit ABI, off_t is off64_t.

sigset_t is too small on ARM and x86 (but correct on MIPS), so support for 
real-time signals is broken. http://b/5828899 In the 64-bit ABI, sigset_t is 
the correct size for every architecture.
=

I will test your patch on x86 and x86_64 on Android and propose a patch if it 
works.

[1] https://android.googlesource.com/platform/bionic.git/#32_bit-ABI-bugs

--

___
Python tracker 

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

[issue30392] default webbrowser fails on macOS Sierra 10.12.5


Changes by Andrew Jaffe :


--
title: default webbrowser not used on macOS Sierra 10.12.5 -> default 
webbrowser fails on macOS Sierra 10.12.5

___
Python tracker 

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

[issue30392] default webbrowser not used on macOS Sierra 10.12.5


Andrew Jaffe added the comment:

A few more details:

 - I believe this worked correctly under previous macOS versions (but I don't 
currently have access to any such machines). 
 - This behaviour is identical under 3.6.1 and 2.7.13 (untested elsewhere)
 - Behaviour first noticed under Jupyter notebook -- see 
https://github.com/jupyter/notebook/issues/2438

--

___
Python tracker 

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

[issue30392] default webbrowser not used on macOS Sierra 10.12.5


New submission from Andrew Jaffe:

On the newly-released macOS Sierra 10.12.5, the default web browser which is 
meant to returned by webbrowser.get() gives an error. Specifically:

>>> import webbrowser
>>> br = webbrowser.get()
>>> br.open("http://python.org;)
0:33: execution error: "http://python.org; doesn’t understand the “open 
location” message. (-1708)
False

>>> ### but this works
>>> br = webbrowser.get("safari")
>>> br.open("http://python.org;)
True

--

___
Python tracker 

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

[issue30392] default webbrowser not used on macOS Sierra 10.12.5


Changes by Andrew Jaffe :


--
title: default webbrowser macOS Sierra 10.12.5 -> default webbrowser not used 
on macOS Sierra 10.12.5

___
Python tracker 

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

[issue30392] default webbrowser macOS Sierra 10.12.5


Changes by Andrew Jaffe :


--
components: Library (Lib), macOS
nosy: Andrew.Jaffe, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: default webbrowser macOS Sierra 10.12.5
type: behavior
versions: Python 2.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

Re: How to install Python package from source on Windows


On 17/05/2017 17:23, Chris Angelico wrote:

On Thu, May 18, 2017 at 1:37 AM, bartc  wrote:

On 17/05/2017 15:13, Chris Angelico wrote:



[1] Does work on Windows. Install bash for Windows, or (on a
recent-enough Windows) just use the subsystem that Microsoft provides.


So the answer is, switch to Linux. In other words, a cop-out.


[2] So? You don't have to read it, just run it. Or do you read every
line of code that any of your programs executes?


Sometimes, if there's a problem. But usually the code is doing something 
sensible. The stuff in configure is complete gobbledygook (if anyone 
doesn't believe me, just have look).


It is impossible that all this is needed just to figure out what source 
files need to be compiled. (If it generated CPython sources 
fractal-style, then I might be impressed, but doesn't.)



I didn't even have an editor the first time I had that situation. And
it worked, because I was using the same C compiler that I was
accustomed to - it existed for that platform. I was specifically NOT
helpless because I am used to using good tools.

How about if I put you on a different CPU than you're used to? Can you
use your tiny C compiler? I doubt it, because it's emitting Intel byte
code.


I'm used to it. I used to start off with machines with no software in 
them at all. (Actually, I often needed to wire up the boards first.)


The point I'm making is that these things should still work when reduced 
to the basics.


(As it happens, I'm done this on an original raspberry pi machine. It 
will need an existing C compiler to get started, after which my 
programs, interpreters and compilers, run fine.


But it's funny waiting for gcc to compile my mcc64.c file (taking 30 to 
120 seconds depending on optimisation), and then it compiles itself in 
0.7 seconds. Of course that would be targetting x64 so the output is not

much use.

What it does show is that it is practical to reduce a substantial 
application to a single file, and trivially build it pretty much 
everywhere, as C compilers are ubiquitous. And that it will run with 
little trouble. The same source can run on ARM32, x86 and x64; Linux or 
Windows. Probably elsewhere but that is the extent of my tests.)




You're asking me to bootstrap Python. I would start by looking for the
nearest similar platform and trying to build a hybrid. I haven't done
this with Python itself, but a while ago, I wanted to port a
similarly-sized language to OS/2, and the process went like this:

1) Attempt to run the configure script, using bash and gcc (which
already existed for OS/2)


I said bash didn't exist.

(BTW I've gone down the route of installing MSYS etc many times, 
something always went wrong. Why is it that people can't appreciate that 
complicated thing are more likely to go wrong?)


You need hard information in the form of what exactly needs to be done 
with the .c and .h files provided. If it's necessary that another 
language is needed to generate some of those, then sources for that 
program are needed too.


However, that would also suggest that the application (CPython etc) is 
not a pure C application at all.



Yes. Yes, it is. For starters, GCC actually can compile to machine
code, instead of depending on nasm.


I don't think it does. gcc AFAIK generates assembly code (via pipes or 
equivalent so usually you don't see it), then invokes an assembler 
called 'as' to convert into object code.


I believe that the base gcc compiler is separate from the bin-utils such 
as 'as' and 'ld' (the linker).


Downloading gcc tdm for Windows, these are separate download bundles. On 
Linux, this stuff is pre-installed so it's easy to think it's all the 
same thing.


When /my/ compiler does it properly, then it will be truly 
self-contained. And still be one executable.



Then do it. Make your compiler able to target all of the above. See
how much ifdef mess you need.


My language doesn't have ifdef. There are other ways of managing this 
switch. (Actually my current compiler for that language is interpreted. 
It supports two targets.)



Plus, git shouldn't be considered an onerous requirement for a
developer. Go get it. Start using it.


I'm doing this for fun. It's not a job to be taken seriously. And doing 
battle with other people's temperamental multi-GB applications is not my 
idea of fun.


(I mean, even if I did so, what can I contribute? Nothing.)


And I can only conclude from your comments, that CPython is also incomplete
because it won't work without a bunch of other tools, all chosen to be the
biggest and most elaborate there are.


Exactly. The core devs reject small solutions, even if they're
perfect, in order to pick up a much larger and more elaborate one.
That's how they make technology decisions.


You're being sarcastic, but you may have a hit upon the truth.

I mean, is there any bigger development system they could have chosen 
than VS 2015? (And someone mentioned that VS 2017 needed 25GB or

RE: Survey: improving the Python std lib docs

2017-05-17 Thread Deborah Swanson

Cem Karan wrote, on Wednesday, May 17, 2017 2:48 AM
> 
> On May 16, 2017, at 12:36 PM, rzed  wrote:
> 
> > On Friday, May 12, 2017 at 6:02:58 AM UTC-4, Steve D'Aprano wrote:
> >> One of the more controversial aspects of the Python 
> ecosystem is the 
> >> Python docs. Some people love them, and some people hate them and 
> >> describe them as horrible.
> >> 
> > [...]
> > 
> > One thing I would love to see in any function or class docs is a few

> > example invocations, preferably non-trivial. If I need to 
> see more, I can read the entire doc, but most times I just 
> want a refresher on how the function is called. Does it use 
> keywords? Are there required nameless parameters? In what 
> order? A line or two would immediately clarify that most of the time.
> > 
> > Apart from that, links to docs for uncommon functions (or 
> to the docs 
> > of the module, if there are many) would be at least somewhat useful.
> 
> I'd like to see complete signatures in the docstrings, so 
> when I use help() on something that has *args or **kwargs I 
> can see what the arguments actually are.
> 
> Thanks,
> Cem Karan

I'd also like to see all of the above, especially what the possible
*args or **kwargs are.

Sure hope someone who might do these things is reading this.

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue28240] Enhance the timeit module: display average +- std dev instead of minimum

2017-05-17 Thread Jesús Cea Avión


Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

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

[issue30390] Document how to make classes in the C API.

2017-05-17 Thread Decorater


Changes by Decorater :


--
status: closed -> open

___
Python tracker 

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

[issue30390] Document how to make classes in the C API.

2017-05-17 Thread Decorater


Decorater added the comment:

Still it does look the functions lited in the second comment are undocumented.

https://docs.python.org/3/search.html?q=PyClassMethodDescr_Type
https://docs.python.org/3/search.html?q=PyClassMethod_New_keywords=yes=default

However on the last function I did find 1 thing However it was not what I was 
looking for. What I actually was looking for was the args for the 3 functions 
and description on what it does and all that similar to how this function is 
documented:

```
PyObject* PyObject_CallObject(PyObject *callable_object, PyObject *args)
Return value: New reference.
Call a callable Python object callable_object, with arguments given by the 
tuple args. If no arguments are needed, then args may be NULL. Returns the 
result of the call on success, or NULL on failure. This is the equivalent of 
the Python expression callable_object(*args).

```

This is actually the reason why the issue was opened as the functions was not 
documented like this.

--

___
Python tracker 

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

[issue29063] Fixed timemodule compile warnings (gmtoff).


Changes by STINNER Victor :


--
pull_requests: +1731

___
Python tracker 

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

[issue29063] Fixed timemodule compile warnings (gmtoff).


Changes by STINNER Victor :


--
title: Fixed timemodule compile warnings. -> Fixed timemodule compile warnings 
(gmtoff).

___
Python tracker 

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

[issue30391] test_socketserver killed after 15 min on AMD64 FreeBSD 10.x Shared 3.6


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.x%20Shared%203.6/builds/142/steps/test/logs/stdio

...
0:10:10 [396/405] test_pulldom passed -- running: test_socketserver (487 sec)
0:10:11 [397/405] test_dictcomps passed -- running: test_socketserver (488 sec)
0:10:11 [398/405] test_support passed -- running: test_socketserver (488 sec)
0:10:22 [399/405] test_email passed -- running: test_socketserver (499 sec)
0:10:44 [400/405] test_buffer passed -- running: test_socketserver (521 sec), 
test_concurrent_futures (40 sec), test_datetime (49 sec)
0:10:53 [401/405] test_ftplib passed -- running: test_socketserver (530 sec), 
test_concurrent_futures (49 sec), test_datetime (58 sec)
0:10:55 [402/405] test_ucn passed -- running: test_socketserver (532 sec), 
test_concurrent_futures (51 sec), test_datetime (60 sec)
fetching http://www.pythontest.net/unicode/9.0.0/NamedSequences.txt ...
0:11:09 [403/405] test_concurrent_futures passed (65 sec) -- running: 
test_socketserver (546 sec), test_datetime (74 sec)
0:11:16 [404/405] test_datetime passed (81 sec) -- running: test_socketserver 
(553 sec)
running: test_socketserver (583 sec)
running: test_socketserver (613 sec)
running: test_socketserver (643 sec)
running: test_socketserver (673 sec)
running: test_socketserver (703 sec)
running: test_socketserver (733 sec)
running: test_socketserver (763 sec)
running: test_socketserver (793 sec)
running: test_socketserver (823 sec)
running: test_socketserver (853 sec)
running: test_socketserver (883 sec)
0:17:04 [405/405] test_socketserver crashed
Timeout (0:15:00)!
Thread 0x000802006400 (most recent call first):
  File "/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/threading.py", 
line 295 in wait
  File "/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/threading.py", 
line 551 in wait
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/test/test_socketserver.py",
 line 369 in wait_done
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/test/test_socketserver.py",
 line 341 in __init__
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/test/test_socketserver.py",
 line 362 in __init__
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/test/test_socketserver.py",
 line 307 in test_threading_handled
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/unittest/case.py", 
line 601 in run
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/unittest/case.py", 
line 649 in __call__
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/unittest/suite.py", 
line 122 in run
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/unittest/suite.py", 
line 84 in __call__
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/unittest/suite.py", 
line 122 in run
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/unittest/suite.py", 
line 84 in __call__
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/unittest/suite.py", 
line 122 in run
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/unittest/suite.py", 
line 84 in __call__
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/unittest/runner.py", 
line 176 in run
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/test/support/__init__.py",
 line 1889 in _run_suite
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/test/support/__init__.py",
 line 1923 in run_unittest
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py",
 line 164 in test_runner
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py",
 line 165 in runtest_inner
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py",
 line 119 in runtest
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/test/libregrtest/runtest_mp.py",
 line 71 in run_tests_slave
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/test/libregrtest/main.py",
 line 475 in _main
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/test/libregrtest/main.py",
 line 468 in main
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/test/libregrtest/main.py",
 line 532 in main
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/test/regrtest.py", 
line 46 in _main
  File 
"/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/test/regrtest.py", 
line 50 in 
  File "/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/runpy.py", line 
85 in _run_code
  File "/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/runpy.py", line 
193 in _run_module_as_main
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/runpy.py", line 
193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/home/buildbot/python/3.6.koobs-freebsd10/build/Lib/runpy.py", line 
85, in

[issue30387] warning of threading_cleanup in test_threading


STINNER Victor added the comment:

Oh, strange, the test in Python 2.7 doesn't have the bug: see commit 
30a5445b30bb627a64b2d30788f6db58f6db3ae1. Compare it to the code in Python 3: 
commit 9939cc89a4ee54ab50719a597a8b8a0795a691f6.

The warning is already fixed in master. I created backports for 3.5 and 3.6.

--
versions: +Python 3.5, 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

[issue30357] test_thread should clean threads after each test


Changes by STINNER Victor :


--
pull_requests: +1730

___
Python tracker 

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

[issue30387] warning of threading_cleanup in test_threading


Changes by STINNER Victor :


--
pull_requests: +1729

___
Python tracker 

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

[issue30149] inspect.signature() doesn't support partialmethod without explicit self parameter


Yury Selivanov added the comment:


New changeset 378d70642aa1c8de2a53ecb811927faf0388db2d by Yury Selivanov 
(Dong-hee Na) in branch 'master':
bpo-30149: Fix partialmethod without explicit self parameter (#1308)
https://github.com/python/cpython/commit/378d70642aa1c8de2a53ecb811927faf0388db2d


--

___
Python tracker 

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

[issue30387] warning of threading_cleanup in test_threading


Changes by STINNER Victor :


--
pull_requests: +1727

___
Python tracker 

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

[issue30357] test_thread should clean threads after each test