date:20200630

[issue896330] pyconfig.h is not placed in --includedir

2020-06-30 Thread Mario Gonzalez



Mario Gonzalez  added the comment:

hey u, send mi a mail, u need my help
and i need u 
mario the last one
mario.cro...@gmail.com

--
nosy: +Mario Gonzalez

___
Python tracker 

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

[issue19335] codeop misclassifies incomplete code with 'nonlocal'

2020-06-30 Thread Terry J. Reedy



Terry J. Reedy  added the comment:

I reread Nick's comment "the C level loop simply blocks on stdin, waiting until 
the parser spits out a complete AST."  I interpret that now as meaning that the 
REPL compiles user code only once per statement, which IDLE and 
code.InteractiveInterpreter compile a statement once per line, which codeop 
expands to 3 compiles in an attempt to determine whether more is needed.  This 
can all be considered to be a hack, so adding 1 more does not bother me now.

(Side note: if the first compile succeeds in producing a code object, it is 
unconditionally returned after the additional compiles, so they seem like a 
waste.)

I looked at a git blame listing for codeop.  It was extracted from code by 
Guido in 1998 so that Jython (JPython) could replace compile_command.  It was 
not revised after the addition of nonlocal broke it.

I traced the flow of calls from when a user hits  in the entry area to 
the call of compile, and of the returns back.  The attached 
idle-shell-compile.txt records what I found.  Of particular interest to me:

1. IDLE strips trailing ' 's, '\t's, and 1 '\n' from user input before sending 
it to be compiled. (This goes back to the original IDLE commit in 2000.) So 
there is a trailing '\n' only when the user has hit '' twice to complete 
a compound statement.  It would solve this issue *for IDLE* to only print the 
nonlocal error message when there is a trailing '\n'.  I am willing to give up 
the special casing needed to get 'def a():\n  nonlocal c' (no double , 
no trailing '\n') to raise immediately.

Nothing in code says that it expects source to be stripped as IDLE does.  The 
reason for the latter might just be to get rid of the 'smart indent' that will 
precede the first Enter, and possibly anything the user adds before the second. 
 

2. compile is passed the undocumented flag PyCF_DONT_IMPLY_DEDENT = 0x200.  Can 
anyone explain the full intent?  I found this difference.

>>> compile("def f():\n  nonlocal c", '', 'single')
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2
SyntaxError: no binding for nonlocal 'c' found

# Same code, flag added, different message.
>>> compile("def f():\n  nonlocal c", '', 'single', 0x200)
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2
nonlocal c
 ^
SyntaxError: unexpected EOF while parsing

# Add '\n' and message is same as without flag.
>>> compile("def f():\n  nonlocal c\n", '', 'single', 0x200)
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2
SyntaxError: no binding for nonlocal 'c' found

To use the message difference, the first compile-with-flag message would have 
to be saved for comparison, and the difference would only appear if source had 
no trailing '\n'.  We could make that be true, or we could wait until another 
user of codeop complains.

--
Added file: https://bugs.python.org/file49282/idle-shell-compile.txt

___
Python tracker 

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

[issue41179] find_library on macOS Big Sur

2020-06-30 Thread Roundup Robot



Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +20400
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21250

___
Python tracker 

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

[issue41179] find_library on macOS Big Sur

2020-06-30 Thread Sumanth Ratna


New submission from Sumanth Ratna :

The following all return None on macOS Big Sur, but return a valid path (str) 
on macOS Catalina:

python3.6 -c "from ctypes import util; print(util.find_library('objc'))"
python3.7 -c "from ctypes import util; print(util.find_library('objc'))"
python3.8 -c "from ctypes import util; print(util.find_library('objc'))"

The solution I'm thinking of is using platform.mac_ver() in 
ctypes.util.find_library to see if the macOS version is either 10.16 or 11.0; 
if so, use an alternative method to locate the path of the library 
somehow—else, use the current functionality. I'm hoping that looking in 
/System/Library/Frameworks/ is enough. 

>From the macOS Big Sur release notes 
>(https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-beta-release-notes):

> New in macOS Big Sur 11 beta, the system ships with a built-in dynamic linker 
> cache of all system-provided libraries. As part of this change, copies of 
> dynamic libraries are no longer present on the filesystem. Code that attempts 
> to check for dynamic library presence by looking for a file at a path or 
> enumerating a directory will fail. Instead, check for library presence by 
> attempting to `dlopen()` the path, which will correctly check for the library 
> in the cache. (62986286)

Related links:
- https://bugs.python.org/issue41116 (this is a build issue, but is related I 
think)
- 
https://stackoverflow.com/questions/62587131/macos-big-sur-python-ctypes-find-library-does-not-find-libraries-ssl-corefou
- 
https://www.reddit.com/r/MacOSBeta/comments/hfknpa/is_corefoundation_missing_for_everyone_on_big_sur/
- https://github.com/vispy/vispy/issues/1885
- https://github.com/napari/napari/issues/1393
- https://github.com/espressif/esptool/issues/540


This is my first issue in Python; sorry in advance if I've made a mistake 
anywhere.

--
components: ctypes
messages: 372728
nosy: Sumanth Ratna
priority: normal
severity: normal
status: open
title: find_library on macOS Big Sur
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue41100] Build failure on macOS 11 (beta)

2020-06-30 Thread Lawrence D'Anna



Change by Lawrence D'Anna :


--
pull_requests: +20399
pull_request: https://github.com/python/cpython/pull/21249

___
Python tracker 

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

[issue41170] Use strnlen instead of strlen when the size i known.

2020-06-30 Thread Eric V. Smith



New submission from Eric V. Smith :

Is strnlen() supported by all of the compilers we care about?

--
nosy: +eric.smith

___
Python tracker 

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

[issue41178] Registry writes on Windows Store - workaround

2020-06-30 Thread DataGhost



New submission from DataGhost :

I just installed the Windows Store version of Python (v3.8.3:6f8c832) on 
Windows 10.0.18362.900 (1903, old VM) and quickly ran into the issue that 
registry writes aren't visible system-wide. I later found a remark about this 
in the Known Issues section of the Using Python on Windows page. Real-world 
scenario: running "python -m pip install --user pipx" and subsequently "python 
-m pipx ensurepath" says it changed the PATH variable, but it does not take 
effect even after a reboot. I'd say this is one of the cases where a user might 
not know about what's going on and why it fails, even after reading the known 
issues, and the developer might not have thought of the existence or 
incompatibility of the Windows Store version of Python at all.

I have found a workaround to do this, though, and I figured the best place to 
do that is in the actual winreg module so that users and developers don't need 
to worry about this. Calling reg.exe allows registry variables to be written in 
the "normal" registry, and these changes are system-wide rather than in the 
private copy Store apps use. Some functions could be changed to use the reg.exe 
binary instead of the system calls on Windows Store builds. Other functions, 
such as for querying, don't need any changes.

I realise this is an ugly workaround so I'm just suggesting it in hopes of 
improving compatibility, so that users and developers don't need to worry about 
these issues anymore. I did some basic tests on this, by executing reg.exe 
through the subprocess module, and testing for a Windows Store instance by 
checking sys.base_exec_prefix. There are probably better ways but at least this 
shows that it should be possible in just Python.

--
components: Windows
messages: 372726
nosy: DataGhost, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Registry writes on Windows Store - workaround
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue41169] socket.inet_pton raised when pass an IPv6 address like "[::]" to it

2020-06-30 Thread Wator Sead



Wator Sead  added the comment:

I did not build it, just download the Windows pre-built releases.

Can make a consistent behave via constraints it? socket.socket accepted it, but 
socket.inet_pton did not.

--

___
Python tracker 

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

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

2020-06-30 Thread Roundup Robot



Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +20398
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21248

___
Python tracker 

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

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

2020-06-30 Thread Brett Hannigan



New submission from Brett Hannigan :

The logging.config module uses three internal data structures to hold items 
that may need to be converted to a handler or other object: ConvertingList, 
ConvertingTuple, and ConvertingDict.

These three objects provide interfaces to get converted items using the 
__getitem__ methods. However, if a user tries to iterate over items in the 
container, they will get the un-converted entries.

--
components: Library (Lib)
messages: 372724
nosy: Brett Hannigan
priority: normal
severity: normal
status: open
title: ConvertingList and ConvertingTuple lack iterators and ConvertingDict 
lacks items()
type: enhancement
versions: Python 3.7

___
Python tracker 

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

[issue41169] socket.inet_pton raised when pass an IPv6 address like "[::]" to it

2020-06-30 Thread Christian Heimes



Christian Heimes  added the comment:

I can reproduce the problem with 3.6 and even Python versions as old as 3.4:

Python 3.4.10rc1+ (default, Jun 30 2020, 23:15:25) 
[GCC 10.1.1 20200507 (Red Hat 10.1.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.inet_pton(socket.AF_INET6,'[::]')
Traceback (most recent call last):
  File "", line 1, in 
OSError: illegal IP address string passed to inet_pton

Python is just mapping inet_pton(3) return value 0 to an exception. It might be 
possible that your libc has changed behavior.

--
nosy: +christian.heimes

___
Python tracker 

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

[issue38782] Convert importlib.abc to use typing.Protocol

2020-06-30 Thread Zackery Spytz



Change by Zackery Spytz :


--
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 3.0 -> 4.0
pull_requests: +20397
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21245

___
Python tracker 

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

[issue41176] revise Tkinter mainloop dispatching flag behavior

2020-06-30 Thread Richard Sheridan

New submission from Richard Sheridan :

This could also be considered a "behavior" type issue.

`TkappObject` has a member `dispatching` that could usefully be exposed by a
very simple read-only method for users to determine at runtime if the tkinter
mainloop is running. Matplotlib and I'm sure other packages rely on fragile
hacks
(https://github.com/matplotlib/matplotlib/blob/a68562aa230e5895136120f5073dd01f124d728d/lib/matplotlib/cbook/__init__.py#L65-L71)
to determine this state. I ran into this in
https://github.com/matplotlib/matplotlib/pull/17802. All these projects would
be more reliable with a new "dispatching()" method on the TkappObject,
tkinter.Misc objects, and possibly the tkinter module itself.

Internally, `dispatching` is used to, yes, determine if the mainloop is
running. However, this determination is always done within the
`WaitForMainloop` function
(https://github.com/python/cpython/blob/bd4a3f21454a6012f4353e2255837561fc9f0e6a/Modules/_tkinter.c#L363-L380),
which waits up to 1 second for the mainloop to come up. Apparently, this
function allows a thread to implicitly wait for the loop to come up by calling
any `TkappObject` method. This is a bad design choice in my opinion, because if
client code wants to start immediately and the loop is not started by mistake,
there will be a meaningless, hard-to-diagnose delay of one second before
crashing. Instead, if some client code in a thread needs to wait for the
mainloop to run, it should explicitly poll `dispatching()` on its own. This
waiting behavior should be deprecated and, after a deprecation cycle perhaps,
all `WaitForMainloop()` statements should be converted to inline
`self->dispatching`.

The correctness of the `dispatching` flag is dampened by the currently
existing, undocumented `willdispatch` method which simply arbitrarily sets the
`dispatching` to 1. It seems `willdispatch` was added 18 years ago to
circumvent a bug building pydoc caused by `WaitForMainloop` not waiting long
enough, as it tricks `WaitForMainloop` into... not waiting for the mainloop.
This was in my opinion a bad choice in comparison to adding a dispatching flag:
again, if some thread needs to wait for the mainloop, it should poll
`dispatching()`, and avoid adding spurious 1 second waits. `willdispatch`
currently has no references in CPython and most GitHub references are to
Pycharm stubs for the CPython method. It should be deprecated and removed to
preserve the correctness of `dispatching`.

Happy to make a PR about this, except I don't understand clinic at all, nor the
specifics of deprecation cycles in CPython.

--
components: Tkinter
messages: 372722
nosy: Richard Sheridan
priority: normal
severity: normal
status: open
title: revise Tkinter mainloop dispatching flag behavior
type: enhancement
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python
3.9

1 2 >

100 matches

Mail list logo