Change by Ronald Oussoren :
--
keywords: +patch
pull_requests: +21727
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22764
___
Python tracker
<https://bugs.python.org/issu
Ronald Oussoren added the comment:
Given this plist:
http://www.apple.com/DTDs/PropertyList-1.0.dtd;>
hex
0x010c
oct
0123
``plutil -convert json`` prints:
{"hex":[1677722
Ronald Oussoren added the comment:
This file is still present on the latest version of macOS 11 beta on ARM64,
with this integer value. Furthermore plutil will happily read this file.
I'm in favour of changing plistlib to parse files like
Ronald Oussoren added the comment:
It is far from clear what's going on here. In particular, it not clear to my
why check_output(['xdg-settings', ...]) would ever raise NotADirectoryError.
- What packages do you have installed through homebrew?
- Is there an xdg-settings command installed
Ronald Oussoren added the comment:
The installers on Python.org no longer use the system version of libsqlite,
sidestepping that issue.
That doesn't fix the issue with _scproxy, but that's something we cannot easily
fix in Python itself.
--
resolution: -> wont fix
st
Ronald Oussoren added the comment:
Also: What's meant by "crash OSX 10.14.6"?
Could this be a duplicate of #37833?
--
___
Python tracker
<https://bugs.python.o
Ronald Oussoren added the comment:
I've tested the same settings with Safari, and that browser ignores excludes
with an invalid prefix length.
I've created a PR that does the same for urllib.request.
--
___
Python tracker
<ht
Change by Ronald Oussoren :
--
keywords: +patch
pull_requests: +21726
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/22762
___
Python tracker
<https://bugs.python.org/issu
Ronald Oussoren added the comment:
The error is due to invalid proxy settings on the system.
I can reproduce the error by enabling a HTTP proxy in system settings, while
adding "172.19.0.0/40" to the proxy exclude list in the HTTP proxy settings.
--
stage: -> needs p
Ronald Oussoren added the comment:
I'm closing this issue because it is a duplicate of #41100, the patches needed
to build on Apple Silicon are more involved than just a configure check.
--
resolution: -> duplicate
stage: patch review -> resolved
status: open -> closed
s
Ronald Oussoren added the comment:
The PR is fairly simple: Just reject files with entity declarations as invalid
files. Adding an option to accept entity declarations should not be necessary
as Apple tools won't accept these declarations
Change by Ronald Oussoren :
--
keywords: +patch
pull_requests: +21725
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22760
___
Python tracker
<https://bugs.python.org/issu
Ronald Oussoren added the comment:
I'm working on a PR.
--
___
Python tracker
<https://bugs.python.org/issue42051>
___
___
Python-bugs-list mailing list
Unsub
Ronald Oussoren added the comment:
I'm not sure what you are trying to accomplish. It is already possible to
replace the Tcl/Tk libraries by replacing the relevant files in
Python.framework. However: these aren't meant to be user serviceable parts, the
copy of Tcl/Tk that we include
Ronald Oussoren added the comment:
One option is to copy what defusedxml does to forbid a number of unsafe
operations, see
https://github.com/tiran/defusedxml/blob/eb38a2d710b67df48614cb5098ddb8472289ce6d/defusedxml/ElementTree.py#L68
Defusedxml uses an XMLParser subclass that optionally
Ronald Oussoren added the comment:
I have a PR that implements support for Apple Silicon:
https://github.com/python/cpython/pull/21564
Sadly this is not yet complete. I hope to make progress again during the core
sprint next week.
--
nosy: +ronaldoussoren
Ronald Oussoren added the comment:
Is there something we could do in plistlib to avoid those problems?
Plist XML files are not arbitrary XML. In particular disabling entity
definitions would avoid the problems mentioned as plist files should not
contain those. That said, a quick glance
Ronald Oussoren added the comment:
This is a language change that has been discussed on the python-ideas list a
number of times.
In my opinion adding this would not necessarily be an improvement, especially
when names and expressions get longer. You'd also not win a lot compared to
your
Ronald Oussoren added the comment:
I agree. Without further information it is impossible to move forward.
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Ronald Oussoren :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ronald Oussoren added the comment:
You can already do this with the walrus operator:
# ---
def test():
for i in range(10):
yield (square := i * i)
yield square + 1
# ---
This adds some parenthesis to your second alternative.
--
nosy: +ronaldoussoren
Ronald Oussoren added the comment:
os.access is a think wrapper around C APIs (access(2), faccessat(2)).
I don't think this is a bug in Python, a shell command like "test -r /opt/xray"
will almost certainly give the same result.
--
nosy: +rona
Ronald Oussoren added the comment:
This is intentional behaviour, the factory can only be passed as a positional
argument.
The documentation[1] mentions this, although its probably possible to write
this a bit clearer.
[1] https://docs.python.org/3.8/library/collections.html
Ronald Oussoren added the comment:
in 3.6 t == '*', in 3.7 and later it is '**'.
To be honest I don't like the 3.7 behaviour, it is very surprising even if it
is technically correct (the first '*' is from a match from the entire string,
the second one is from an empty match at the end
Ronald Oussoren added the comment:
But does VS Code use the installation of 3.8 your expecting (the one in
/Library/Frameworks/Python.framework)?
I'm closing the issue because this appears to be a problem with 3th-party code
(VS Code), not with the Python.org installer
Ronald Oussoren added the comment:
Adding new functions that are extreme similar to existing functions requires a
better rationale than your giving.
In particular, both are similar to the builtin function "round"
(https://docs.python.org/3/library/functions.html#round>).
--
Ronald Oussoren added the comment:
Weird. Maybe VS Code uses a different Python installation? You can add "import
sys; print(sys.prefix)" to your script to check.
--
___
Python tracker
<https://bugs.python.o
Ronald Oussoren added the comment:
the version of Tk in /System is not relevant, as I wrote the Tkinter in the
Python.org installer uses a copy of Tcl/Tk that's installed by the Python.org
installer (somewhere in /Library/Frameworks/Python.framework).
This can be checked using the otool(1
Ronald Oussoren added the comment:
How did you install Python? Did you use the installer on Python.org or some
other method?
A script that demonstrates the problem would be useful as well, I've tried to
reproduce the problem in an interactive session in the terminal:
>>> fro
Ronald Oussoren added the comment:
I'm fairly sure this is intended behaviour, see
<https://docs.python.org/3.8/library/os.path.html#os.path.join>.
The second arguments is "{:3", the colon means this is interpreted as the the
relative path "3" on drive "}:&qu
Ronald Oussoren added the comment:
As mentioned before I haven't studied the ctypes code base, but I am a bit
worried about the use of MAX_STRUCT_SIZE, an array definition in a structure is
always part of the struct itself and is never a pointer.
I agree with Vinay that there needs
Ronald Oussoren added the comment:
Note that recent commits to the trunk and 3.8 and 3.9 branches have added a
_uuid module using libuuid (and the comparable Windows API). I'd expect that
this extension will also be used on macOS.
I'd advise to check if this issue is still present when
Ronald Oussoren added the comment:
Please add more information on how to reproduce the problem. The current
description is not complete enough to be able to determine if there is a bug
and if so where that bug is.
--
nosy: +ronaldoussoren
Ronald Oussoren added the comment:
A workaround in the implementation of multiprocessing.SharedMemory is IMHO
acceptable, tweaking os.ftruncate less so.
Note that a Python script can already cause problems on systems by using APIs
as intended (such as using shutil.rmtree on the user's home
Ronald Oussoren added the comment:
I expect that this is more a problem with how memory management works on macOS,
the freeze and crash is likely an indication of eager allocation of memory by
the system.
It is far from sure if implementing a workaround is feasible, the upper limit
Change by Ronald Oussoren :
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<https://bugs.python.org/issue41
Ronald Oussoren added the comment:
There's multiple options:
1. Escape '%' in environment variables (%%not_existing%%) to avoid the exception
2. Switch to configparser.ExtendedInterpolation for the interpolation, which
uses a different syntax that doesn't conflict with env. variables
Ronald Oussoren added the comment:
The exception is due to the interpolation feature of ConfigParser, which
expects a different syntax. The default interpolation syntax is "%(key)s".
Interpolation can be turned off by passing "interpolation=None" when creating
the Confi
Ronald Oussoren added the comment:
That doesn't answer my question, synthetic.conf should still make it possible
to have the mountpoint in /, and that's even used as an example in the manpage.
--
___
Python tracker
<https://bugs.python.
Ronald Oussoren added the comment:
> For some background, our network location /mathworks is usually mounted at
> root, but due to the restrictions on macOS Catalina, it mounts at
> /System/Volumes/Data and we then add a symlink to the root directory so
> "/mathworks ->
Ronald Oussoren added the comment:
> As a reminder when implementing:
The whole configure machinery needs work :-(.
Disabling looking in /usr/local should IMHO be an explicit choice when
building, not something inferred from the presence of "-isysroot" in the
compiler
Change by Ronald Oussoren :
--
resolution: -> not a bug
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue41456>
___
___
Python-bugs-
Ronald Oussoren added the comment:
mach_absolute_time returns time in ticks, there's a separate API that returns
the resolution of this clock (which is already used).
The manpage explicitly says that mach_absolute_time and CLOCK_UPTIME_RAW are
the same clock:
CLOCK_UPTIME_RAW clock
Ronald Oussoren added the comment:
Please also report this at apple using the feedback assistent.
--
___
Python tracker
<https://bugs.python.org/issue41
Ronald Oussoren added the comment:
This is expected behaviour. Run_in_executor uses a
concurrent.futures.ThreadPoolExecutor to manage the worker threads. Those
threads will get reused when more work is scheduled, and will exit when the
runloop is shut down.
--
nosy: +ronaldoussoren
Ronald Oussoren added the comment:
On macOS CLOCK_UPTIME_RAW is the same as mach_absolute_time (according to the
manpage).
--
___
Python tracker
<https://bugs.python.org/issue41
Ronald Oussoren added the comment:
@Nathaniel: I hadn't noticed that CLOCK_MONOTONIC on macOS behaves different
from that clock on Linux. Sigh.
That means there's little reason to switch to CLOCK_MONOTONIC on macOS, that
would just result in different behaviour between Linux and macOS
Ronald Oussoren added the comment:
Relevant libffi documentation:
https://github.com/libffi/libffi/blob/4661ba7928b49588aec9e6976673208c8cbf0295/doc/libffi.texi#L505
--
___
Python tracker
<https://bugs.python.org/issue38
Ronald Oussoren added the comment:
This is expected behaviour. the assessment to retProduct[productKey] is not a
copy. If those variants have the same parent and a different color you'll end
up with a baseProduct where 'variants' refers to the same variant dict (and the
second color seen
Ronald Oussoren added the comment:
As I mentioned earlier the code in sgtdict.c seems dodgy, the libffi
representation for an array in a dict should be the same regardless of the size
of the dictionary.
That said, I haven't studied the ctypes code yet and am not sure if my analysis
Ronald Oussoren added the comment:
I don't quite understand what the issue is.
* What proxy settings do you have?
* Is the problem reproducible without using pip?
- By using the requests API to fetch a web page
- By using the stdlib http.client API to do the same
Change by Ronald Oussoren :
--
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
___
Python tracker
<https://bugs.python.org/issue38628>
___
___
Python-bug
Ronald Oussoren added the comment:
Thanks for the code reference.
I'm not a ctypes expert, but do maintain another project using libffi. The
comment in stgdict.c is correct, and that code is used for all platforms.
However, code to embed arrays into a struct (as described int the comment
Ronald Oussoren added the comment:
David, is the issue you mention in your message at 2020-02-05 reproducible with
valid usage of ctypes (that is, by calling a C function with the correct
signature)?
What do you mean with "this is documented in Python ctypes"?
-
Ronald Oussoren added the comment:
PureWindowsPath does not know about POSIX paths, it supports the two styles of
directory separator that are valid on Windows: '/' and '\'.
PurePosixPath only supports the single stile of directory separator valid on
POSIX systems: '/'.
On a Posix system
Ronald Oussoren added the comment:
I'm not sure what you try to report.
PurePath(...) returns a PureWindowsPath on Windows and an PurePosixPath on
other (unix-y) platforms. This explains the difference in behaviour you're
seeing for as_posix
Ronald Oussoren added the comment:
That's this issue.
FWIW: I'm slowly working on a patch to build on macOS 11 and deploy to macOS
10.9 or later, the current rough and untested PR is at
https://github.com/python/cpython/pull/21583.
This needs testing and cleanup before it can
Ronald Oussoren added the comment:
macOS 10.12 also has clock_gettime(), which would allow using the generic code
path (although the current path must be kept for older versions of macOS).
--
___
Python tracker
<https://bugs.python.org/issue41
Ronald Oussoren added the comment:
I agree that the current implementation is wonky.
The implementation should use linkat(2) whenever it is available, that's the
only portable way to honour the follow_symlinks flag as POSIX says that the
behaviour for link(2) with symbolic links
Ronald Oussoren added the comment:
I don't know if this limitation is intentional, but not that you can use an
assignment expression when you enclose the expression with parenthesis:
>>> assert (a:=1)
>>> a
1
>>>
-
Ronald Oussoren added the comment:
PR21564 is my attempt to merge all changes needed to support macOS 11 and
arm64. To be honest I had lost track of what's needed.
With this the patch the tests pass on my DTK system.
TODO:
- Verify builds on older macOS versions
- Maybe: support building
Ronald Oussoren added the comment:
We're tracking macOS 11 and arm64 support in #41100
--
resolution: -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder: -> Build failure on macOS 11 (beta)
___
Python tra
Ronald Oussoren added the comment:
I can somewhat reproduce the problem with both IDLE and tkinter.Tk() in 3.9b3
and an external monitor.
What I did:
- Start IDLE (or a shell running tkinter.Tk()
- Maximize window without changing monitor settings: OK
- Revert to regular window
- Rotate
Ronald Oussoren added the comment:
The compiler cannot know if "false" is an existing name when compiling.
One example is that the name might refer to the name of a builtin.
--
nosy: +ronaldoussoren
resolution: -> not a bug
stage: -> resolved
status: open -> c
Change by Ronald Oussoren :
--
pull_requests: +20724
pull_request: https://github.com/python/cpython/pull/21583
___
Python tracker
<https://bugs.python.org/issue41
New submission from Ronald Oussoren :
The code for os.link() seems to ignore follow_symlinks when the linkat(2)
function is not available on the platform, which results in unexpected
behaviour when "follow_symlinks" is false.
--
components: Extension Modules
messages: 3
Change by Ronald Oussoren :
--
pull_requests: +20709
pull_request: https://github.com/python/cpython/pull/21564
___
Python tracker
<https://bugs.python.org/issue41
Change by Ronald Oussoren :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ronald Oussoren added the comment:
I'm closing this as "later" as the consensus is that this might be a useful
binding to have, but io_uring is evolving too fast at the moment.
It is better to develop these bindings on PyPI, which also makes it easier to
iterate on
Ronald Oussoren added the comment:
modulegraph already knows where the import is done, and users of the library
can use that information to make decisions.
There's no need to make changes to either heapq.py or modulegraph.
For py2app I've made the choice to no be smart about inclusions
Ronald Oussoren added the comment:
I have no opinion on the proposed change.
The "disruption" alex c talks about is that this imports gets seen by
modulegraph (and hence pyinstaller and py2app), which will then include doctest
and all its dependencies in standalone bundles e
Ronald Oussoren added the comment:
This appears to be a bug in the APFS filesystem implementation.
On my machine:
- main disk (SSD, APFS): race condition happens
- r/w disk image with APFS: race condition happens
- r/w disk image with HFS+: no race condition
Ronald Oussoren added the comment:
How stable is the io_uring API?
The stdlib evolves slowly, I'm not sure if the io_uring interface has matured
enough to make it acceptable that updates to the stdlib bindings for that API
are only done in new major releases of CPython (about every 18
Ronald Oussoren added the comment:
I've attached a variation on test-conc-read.py that uses os.open and low-level
APIs instead of the Python IO stack (open/io.open). This fails in the same way.
os.open/os.read/os.write/os.close are very thin wrappers around the
corresponding C APIs
Ronald Oussoren added the comment:
If it is reproducable in C this is likely a bug in macOS, and should be
reported to them.
I get the same behaviour as you with the test script, even if I add calls to
fhandle.flush and os.fsync to force the content to stable storage.
Interestingly enough
Change by Ronald Oussoren :
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue41188>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
I agree, this is a "feature" of the SQLite headers as shipped by Apple.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
type: enhancement -> compile error
___
Ronald Oussoren added the comment:
That's the problem with any change to distutils, the API is unclear and that
causes any change to be potentially breaking for existing users. That's why
distutils has been mostly stagnant for years.
I have no particular wish w.r.t. changing behaviour, I've
Ronald Oussoren added the comment:
The deprecation warnings are a specific "feature" of the copy of Tcl/Tk shipped
by Apple, and do not reflect the status of this API upstream.
The correct fix is to either ignore these warnings when building, or better to
use a different install
Ronald Oussoren added the comment:
An unfortunate side effect of this change is that changes the build order even
if the source list order is relevant.
In particular, I sort the source list by age when working on larger extensions,
this makes sure that the source files I edited last get
Ronald Oussoren added the comment:
As I mentioned in my review on the PR I'd prefer to keep using Macintosh where
it is used to denote to MacOS 9 and earlier. Both out of nostalgia and because
that older OS was substantially different from the current OS
Ronald Oussoren added the comment:
We're tracking macOS 11 changes in Issue41100. That issue has a PRs from Apple
for, amongst others, this issue.
--
components: +macOS
nosy: +ned.deily, ronaldoussoren
superseder: -> Build failure on macOS 11 (beta)
versions: +Python 3.10, Pyt
Ronald Oussoren added the comment:
A first testrun on the arm-mac resulted in test failures in test_distutils (in
particular test_deployment_target_default in the distutils test). That's
something I have to investigate further.
--
___
Python
Ronald Oussoren added the comment:
FYI I have as of a couple of minutes ago received a developer transition kit
and can, and will, test on the new hardware.
--
___
Python tracker
<https://bugs.python.org/issue41
Ronald Oussoren added the comment:
I see, and (as expected) get the same output when I build like that.
I agree that we should teach _osx_support about this. I guess we should add a
function that returns the SDK root, which can then be used in distutils (and
setuptools, ...) instead
Ronald Oussoren added the comment:
These build for me (master branch), because the support for .tbd files in the
macOS SDK still works.
The ones that don't build for me:
- Bits not found: _gdbm, _hashlib, _ssl, ossaudiodev, spwd
- Failed to build: _ctypes, _decimal, _lzma
Ronald Oussoren added the comment:
New changeset d518ed0baaa31ca25cd88ac8996c7a7d563b2a1f by Miss Islington (bot)
in branch '3.9':
bpo-41005: Fixed perrmission error (GH-20936) (GH-21051)
https://github.com/python/cpython/commit/d518ed0baaa31ca25cd88ac8996c7a7d563b2a1f
Ronald Oussoren added the comment:
New changeset adf8708c44945bfa68db8b02c6a1f560f05a5151 by Miss Islington (bot)
in branch '3.8':
bpo-41005: Fixed perrmission error (GH-20936) (GH-21052)
https://github.com/python/cpython/commit/adf8708c44945bfa68db8b02c6a1f560f05a5151
Change by Ronald Oussoren :
--
pull_requests: +20278
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21115
___
Python tracker
<https://bugs.python.org/issu
Change by Ronald Oussoren :
--
title: Support for "Apple Silicon" -> Support for "Universal 2" binary builds
versions: +Python 3.8
___
Python tracker
<https://
Change by Ronald Oussoren :
--
keywords: +patch
pull_requests: +20277
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21114
___
Python tracker
<https://bugs.python.org/issu
New submission from Ronald Oussoren :
Apple introduced a new CPU architecture for macOS at WWDC, which is arm64.
Mac/Tools/pythonw.c launches the real python interpreter in a framework build
is and is careful to launch that using the same architecture as it is running
(to make it possible
Change by Ronald Oussoren :
--
keywords: +patch
pull_requests: +20276
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21113
___
Python tracker
<https://bugs.python.org/issu
New submission from Ronald Oussoren :
macOS 11 is darwin 20.0.0. This confuses the configure script, resulting in
defining _POSIX_C_SOURCE and friends.
--
assignee: ronaldoussoren
components: Build, macOS
messages: 372245
nosy: ned.deily, ronaldoussoren
priority: normal
severity
Ronald Oussoren added the comment:
I only know what's on Apple website. There will be documentation, and there is
developer hardware. I do have a VM running the new macOS with a version of
Xcode that can compile for the new hardware, but that's where it ends for me
New submission from Ronald Oussoren :
The attached patch implements "universal2" as an option for
"--with-univeral-archs" to enable building "Universal 2" binaries on macOS
(with x86_64 and arm64 code).
This is an extension of the already existing support for o
Ronald Oussoren added the comment:
Year 0 does exist in ISO 8601 though, but that wouldn't help us here as year 0
in that standard is year 1 BCE which is not representable in Python's datetime
module.
I'm not sure what we can do about this. The best we could do with plistlib is
probably
Ronald Oussoren added the comment:
New changeset 9e27bc0c1efc7478872f98729f87886e9333548f by Krishna Chivukula in
branch 'master':
bpo-41005: Fixed perrmission error (GH-20936)
https://github.com/python/cpython/commit/9e27bc0c1efc7478872f98729f87886e9333548f
Ronald Oussoren added the comment:
I've commented on the attached PR.
IMHO a correct fix is to catch and ignore PermissionError when calling
xdg-settings (on all platforms). An xdg-settings executable that cannot be
started due to permission problems is similar to that executable not being
New submission from Ronald Oussoren :
What's your question or bug report?
The log just shows that a number of extensions could not be build because their
dependencies are not installed.
https://devguide.python.org/setup/#macos-and-os-x shows how to install
dependencies (but I noticed
401 - 500 of 2417 matches
Mail list logo
