Ronald Oussoren added the comment:
Given a quick scan of RFC 3986[1] I'd say that the behaviour of Ruby seems to
be the most correct. That said, I'd also check what the major browsers do in
this case (FWIW both FF and Safari use 'benign.com' as the hostname in this
case).
[1] https
Ronald Oussoren added the comment:
A discussion on the use of enum and deprecation warnings might be useful,
although there is a significant risk on bike shedding.
I agree that formally deprecating READONLY can lead to uglier code in extension
that use the value and need to support anything
Ronald Oussoren added the comment:
Switches from #define's to an enum would allow explictly deprecating the old
name (at least with clang and probably with GCC as well):
clang -c -Wall t.c
t.c:12:10: warning: 'READONLY' is deprecated: use PY_READONLY
[-Wdeprecated-declarations]
int
Ronald Oussoren added the comment:
One thing to keep in mind: HAVE_UNICODE_WCHAR_CACHE == 1 and
HAVE_UNICODE_WCHAR_CACHE == 0 have a different ABI due to a different struct
layout. This should probably affect the ABI tag for extension modules.
--
nosy: +ronaldoussoren
Change by Ronald Oussoren :
--
versions: +Python 2.7, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue36259>
___
___
Python-bugs-list m
Ronald Oussoren added the comment:
I guess it depends on what the information is used for. From a quick glance at
the code I'd say that the current usage is correct, and that
GetNativeSystemInfo could be used when reporting about the currently running
system (for example by functions
Ronald Oussoren added the comment:
What is your use case for this? Is that something that can use the buffer API
instead of these low-level APIs?
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue36
Ronald Oussoren added the comment:
In Python 3.7.2:
>>> open(2, 'a')
<_io.TextIOWrapper name=2 mode='a' encoding='UTF-8'>
>>> m = _
>>> m.name
2
>>> type(_)
That is, when opening a file descriptor the name is set to the value of that
file descript
Ronald Oussoren added the comment:
I don't know a good reason for including $PWD in sys.path for "python -m", I
expect only scripts that run other scripts (such as coverage.py) might want the
current behaviour and those can adjust to new behaviour.
For "python -c CMD" t
Ronald Oussoren added the comment:
This issue can be closed. Status quo wins due to backward compatibility
concerns.
BTW. The primary reason for proposing "macosx" as the return value for
platform.system() is that the platform name as used in egg files (at the time,
now wheels)
Ronald Oussoren added the comment:
On which Python versions do you see this problem? Both tests pass on my system
(macOS 10.4.3) with Python 3.7.2, 3.6.3 and 3.5.5.
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue35
Ronald Oussoren added the comment:
I can live without this API, I mostly filed this issue because there's an
obvious hole in the API when you look at API description: SetItem,
SetItemString, DelItem, DelItemString, GetItem, GetItemString,
GetItemWithError, <>.
Thanks for the explan
Ronald Oussoren added the comment:
There are more reasons to implement in C than just speed ;-). In my code I have
two usecases for using PyDict_GetItemString, both not in performance critical
code
1) Look up a hardcoded name in a dictionary. These could be switched to the Id
API
Ronald Oussoren added the comment:
Adding PyDict_GetItemStringWithError makes is possible to migrate existing code
to a design that does not ignore errors. I have a significant number of calls
to PyDict_GetItemString that cannot be switch toed PyDict_GetItem without
increasing the number
Ronald Oussoren added the comment:
Could you expand on why instancemethod is amazing, other than that's it is
apparently fast at something.
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue35
Ronald Oussoren added the comment:
@Neil: On what version of macOS did you test?
On 10.14.3 with Xcode 10.1 shm_open is in libSystem (that's named libc on most
other unixy systems) and there is no library named librt.
--
nosy: +ronaldoussoren
Change by Ronald Oussoren :
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<https://bugs.python.org/issue35
Ronald Oussoren added the comment:
The bug is the stdlib, and I've checked that setuptools just calls the code in
distutils in this case.
IMHO it would be better to fix this in the stdlib.
(Unselecting python 3.6 because that's in security-only mode by now)
--
versions: -Python
Ronald Oussoren added the comment:
@Paul, modulegraph2 uses flit, but I do use setuptools to build extensions in
the test suite. The problematic setup.py file is in testsuite/nodebuilder-tree.
I do have a workaround in that setup.py:
# START
def get_export_symbols(self, ext):
parts
Ronald Oussoren added the comment:
Please also address my review comments.
--
___
Python tracker
<https://bugs.python.org/issue35813>
___
___
Python-bugs-list m
Ronald Oussoren added the comment:
David,
I don't agree with merging at this point.
The lack of documentation makes it hard to ask for more feedback and broader
testing, because people won't know how to use the library and provide
constructive feedback (that's why my review comments
Ronald Oussoren added the comment:
FWIW the project in question is modulegraph2
<https://bitbucket.org/ronaldoussoren/modulegraph2/src/default/>, which almost
works on Windows, except for this issue and some incorrect code on my side that
assumes virtualenv on Windows behaves th
New submission from Ronald Oussoren :
Python supports having a C extension for the the __init__ of a package (instead
of having __init__.py). This works fine on Linux, but on Windows distutils
fails to build the C extension because it assumes the entry point is named
PyInit___init__ while
Ronald Oussoren added the comment:
FWIW I agree with reverting this pull request, the work is clearly not finished
yet.
--
___
Python tracker
<https://bugs.python.org/issue35
Ronald Oussoren added the comment:
Was this merged too soon? This is new functionality without any docs and tests.
I've also left review comments on the pull request.
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.
Ronald Oussoren added the comment:
The all_proxy setting is used by other software as well, see for example the
manpage for curl and this feature request for requests
<https://github.com/requests/requests/issues/3183>.
Adding support for all_proxy to urllib sounds like a useful f
Ronald Oussoren added the comment:
See also #35673.
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue35843>
___
___
Python-bugs-list m
Change by Ronald Oussoren :
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue10915>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
Note that I will have to special case namespaces like typing.re anyway in my
code, being a namespace that does not correspond to a "real" module whose code
I can analyse.
#35791 was mostly about 3th-party code like apipkg that are &quo
Ronald Oussoren added the comment:
BTW. I hadn't noticed _close_open_fds_safe, that should be safe when using
vfork().
Finally: I have no strong opinion on this patch, your explanation looks fine
and I'm not up-to-speed w.r.t. implementation details of vfork and the like to
feel
Ronald Oussoren added the comment:
Issue #34663 contains some earlier discussion about vfork, in the context of
supporting a specific posix_spawn flag on Linux.
W.r.t. closing all file descriptors > 2: posix_spawn_file_actions_addclose can
do this when using posix_spawn. That would h
Ronald Oussoren added the comment:
In response to my previous message: "Messing" with sys.modules appears to be
good enough work around for me, at least in the limited testing I've done so
far. The new version of modulegraph hasn't seen any testing beyond a largish
set of unit te
Ronald Oussoren added the comment:
The reason I filed #35791 is that I'm rewriting modulegraph[1] using importlib
and run into some problems due to importlib.util.find_spec() failing for names
that are already imported.
Working around that in general probably will require reimplementing
Ronald Oussoren added the comment:
I expected as much.
I've filed an issue with apipkg for this:
https://github.com/pytest-dev/apipkg/issues/13.
My next challenge is to find a way to work around this issue in my code.
BTW. Typing.io is a namespace added to sys.modules by the typing
Ronald Oussoren added the comment:
> In other words: if we can only use __float__ and __int__, how do we know
> which one to use?
I guess __index__. I've read the definition of object.__index__ in the data
model documentation, and using __index__ for this conversion is fine.
Ronald Oussoren added the comment:
Using __index__ here doesn't feel right, although I can't explain why yet.
--
___
Python tracker
<https://bugs.python.org/issue35
Ronald Oussoren added the comment:
As a late response to msg333416 and msg333547, I don't agree with looking at
__index__ in _PyTime_FromObject.
The __index__ method is used when an object can be used as the index for a
sequence, but should not silently convert to int or float. See
Ronald Oussoren added the comment:
This might be a bug in "py", which uses a vendored version of apipkg that
replaces sys.modules["py"] with a lazy loading object. That copy of apipkg does
not copy __spec__ into the lazy loading object.
If this is indeed consider to be a
New submission from Ronald Oussoren :
Using Python 3.7.2 on macOS 10.14 I get an unexpected exception when calling
"importlib.util.find_spec('py')" after importing "py". find_spec works as
expected before I import 'py'.
See the repl session below:
Python 3.7.2 (v3.7.
Change by Ronald Oussoren :
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue32146>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
Victor, the binaries are build on the macOS version mentioned in the download.
That is, the modern 64-bit installers are build on macOS 10.9 with the 10.9
SDK, the older 32/64-bit intel installers are build on macOS 10.6 with the 10.6
SDK.
With some work
Ronald Oussoren added the comment:
This is intentional, see
<https://docs.python.org/3/reference/lexical_analysis.html#floating-point-literals>.
In floating point literals the underscores must always be between two digits.
--
nosy: +ronaldoussoren
resolution: -> not a b
Ronald Oussoren added the comment:
(changed the type from "security" because this is not a security incident).
Both ISO C and C++ define "reserved identifiers" that are reserved for the
implementation and where use in programs is undefined behaviour. However, these
defi
Ronald Oussoren added the comment:
The background for all of this: I'm currently rewriting modulegraph
(https://pypi.org/project/modulegraph/) to use importlib instead of its own
implementation of the import mechanism.
I currently detect PEP420 style namespace packages, but I'm not sure
Ronald Oussoren added the comment:
See:
<https://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier>
Basically all names starting with double underscores are reserved for the
implementation in C++. Likewise for all names st
Ronald Oussoren added the comment:
@barry: I agree on both.
Do you know why the namespace package loader lies about the source and code?
Both .get_source() and .get_code() return a value that isn't None.
And likewise: Why is the namespace package loader a private class, other
loaders
New submission from Ronald Oussoren :
The documentation for import lib.machinery.ModuleSpec says that the attribute
"loader" should be None for namespace packages (see
<https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec>)
In reality the load
Ronald Oussoren added the comment:
#include in the macOS 10.14 SDK says:
/*
* RFC 3542 define the following socket options in a manner incompatible
* with RFC 2292:
* IPV6_PKTINFO
* IPV6_HOPLIMIT
* IPV6_NEXTHOP
* IPV6_HOPOPTS
* IPV6_DSTOPTS
* IPV6_RTHDR
*
* To use
Ronald Oussoren added the comment:
A better workaround is IMHO to force the socket to be IPV6 only:
sd = socket.socket(socket.AF_INET6, socket.SOCK_STREAM, 0)
sd.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_V6ONLY, 1)
That avoids the ordering problem as well as having to try all possible
Ronald Oussoren added the comment:
The patch does not use the version information passed in to calculate the
marketing version. That's a problem when passing in low-level information from
a system running a different version of macOS (for example passing in the
low-level version information
Ronald Oussoren added the comment:
> IMHO platform.architecture() should return 32bit when running "arch -i386
> /usr/local/bin/python3" to be consistent with struct.calcsize("P") == 4 and
> sys.maxsize == 2147483647. Otherwise, how would you notice that you a
Ronald Oussoren added the comment:
> What result of platform.architecture() do you expect for an universal binary?
I honestly don't know. What is the purpose of this functionality in the first
place? I have never had a problem where using this function was the right
solution.
To be hon
Ronald Oussoren added the comment:
BTW. A related problem with platform.architecture() is that it doesn't know how
to deal with fat binaries (such as those found on macOS).
As an example:
$ file /usr/bin/python
/usr/bin/python: Mach-O universal binary with 2 architectures: [i386:Mach-O
Ronald Oussoren added the comment:
>>My gut feeling is that this is some issue with your system or environment.
> I Doubt it, happens with another MacBook air which is literally out of the
> box, no mods.
But on the other hand most other users (including myself and Ned
Ronald Oussoren added the comment:
I'm in favour of removing macpath.
I was against removing the module in the past because parts of the macOS API
still used (on probably still use) classic MacOS style paths. Most if not all
APIs are by this time deprecated, which makes it less and less
New submission from Ronald Oussoren :
PyDict_GetItemWithError is a variant of PyDict_GetItem that doesn't swallow
unrelated exceptions. While converting a project to use this API I noticed
that there is similar variant of PyDict_GetItemString.
It would be nice to have
Ronald Oussoren added the comment:
This issue does not have enough information to determine what is wrong. It is
however fairly clear that it is not related to "scutil --get HostName"
mentioning that there is no hostname set as that is the normal state of
systems, and I have
Ronald Oussoren added the comment:
AFAIK there is nothing you can do between after calling fork(2) to
"reinitialise" the ObjC runtime. And I don't think that's the issue anyway: I
suspect that the actual problem is that Apple's system frameworks use
multithreading (in particular l
Ronald Oussoren added the comment:
I should have been clearer in my previous post. I’m not against changing this,
but would like an implementation that returns consistent information: either
return “macOS” and the macOS version, or “Darwin” and the kernel version.
IIRC there is, or used
Ronald Oussoren added the comment:
Why do you want to change this?
The current behavior is consistent with the platform name (Darwin). I’ve filed
an issue in the past to change the platform name to “macosx”, but there were
good arguments to not change the behavior at the time. The existence
Ronald Oussoren added the comment:
I don’t understand this either. For some reason the patch works when using the
function and not when using the macro.
I haven’t looked into this yet, and am currently traveling. I should have time
to look into this starting December 5th when I’m back home
Ronald Oussoren added the comment:
I agree with Ned. The code fragment works for me as well on 10.14.1 and I've
used simular code in the past on different versions of macOS as well.
@ssbarnea:
- What is the hostname as shown in the "Sharing" preference pane? Does the name
inclu
Ronald Oussoren added the comment:
I'm not convinced that any change is needed, this is completely expected
behaviour (and not special to modules).
The following code also raises RecursionError:
class VerboseObject:
def __setattr__(self, nm, value):
print(f"Settin
Ronald Oussoren added the comment:
IMHO implementing "__index__" for UUID would not the correct solution. That
method is meant be used by integer-like objects. One of the side effects of
implementing "__index__" is that indexing lists with UUID instances would start
to
Ronald Oussoren added the comment:
FWIW I don't see the problem either, VM running 10.14.1 (beta) with Python
3.7.0.
--
___
Python tracker
<https://bugs.python.org/issue35
Ronald Oussoren added the comment:
The error is printed by libc, there's nothing we can do about that.
--
___
Python tracker
<https://bugs.python.org/issue5
Ronald Oussoren added the comment:
My latter points makes it possible to define custom windowing functions in
Python, similar to how it is already possible to define other SQLite functions
in Python.
--
___
Python tracker
<ht
Ronald Oussoren added the comment:
To completely do this requires two things:
1) Upgrade SQLite included in a number of binary distributions
2) Update the sqlite extension to allow creating custom window functions in
Python
The latter is definitely something that cannot be done
Ronald Oussoren added the comment:
@pahskazan: It is correct that '\r\n' is not found in those strings, Python
source code is always parsed after conversion to "Unix" line endings with "\n"
between lines. This is basicly the same as the "universal newlines"
Ronald Oussoren added the comment:
I suspect that there may also be confusion about the line ending in multiline
strings. Is there any documentation on the fact that this is always "\n" and
not "\r\n" (even on Windows)?
The closest I've found is the Lexical Analysis
Ronald Oussoren added the comment:
What do you think the problem is? The output of the script is what I'd expect
it to be.
Note that str.find() returns -1 when the needle is not present (and the first
offset where the needle is found when it is present).
--
nosy: +ronaldoussoren
Ronald Oussoren added the comment:
This is not a bug. You are searching for the character range from "+" to "*",
which is an invalid range because "+" > "*".
--
nosy: +ronaldoussoren
resolution: -> not a bug
stage: -> resolv
Ronald Oussoren added the comment:
Do you have a $PYTHONPATH in your environment?
For some reason the 3.7 install is looking in the site-packages directory for
the 2.7 install. This is probably configuration on your system.
--
___
Python tracker
Ronald Oussoren added the comment:
I had the some problem when using mypy. What does reproduce the issue is the
following:
* Create *two* venv environments
* Install mypy in one of them
* Activate the other
* Run the subprocess call in the activated venv
I then get a message about not being
Ronald Oussoren added the comment:
I've added back port labels for 3.6 and 3.7.
AFAIK 3.5 is closed for bugfixes at this point (except for security fixes).
--
___
Python tracker
<https://bugs.python.org/issue22
Ronald Oussoren added the comment:
To use the framework build you either have to install, use or set
"DYLD_FRAMEWORK_PATH" in the environment (See the definition of RUNFORSHARED in
Makefile for the value to use).
To properly test the this issue you have to install (or trick
Ronald Oussoren added the comment:
I've added PR 9516 that just clears __PYVENV_LAUNCHER__ from the environment as
soon as it is no longer needed.
A more involved change would be to change both the interpreter and the stub
executable to avoid the need to use an environment variable
Change by Ronald Oussoren :
--
pull_requests: +8922
___
Python tracker
<https://bugs.python.org/issue22490>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
The pull request is wrong, the use of __PYVENV_LAUNCHER__ in pythonw.c is
correct and should not be removed. Where the current code goes wrong is that it
doesn't clear the environment as soon as possible.
This patch should basically do the trick
Ronald Oussoren added the comment:
Same here, even if I learned more about the implementation of posix_spawn than
I should have to know ;-)
--
___
Python tracker
<https://bugs.python.org/issue34
Ronald Oussoren added the comment:
Note that the POSIX_SPAWN_USEVFORK may not do anything at this point (see the
link in my previous message, if I read the code correctly POSIX_SPAWN_USEVFORK
is no longer used in the implementation of posix_spawn(3)).
Even if it did do something the user
Ronald Oussoren added the comment:
I did some more research:
* <https://sourceware.org/bugzilla/show_bug.cgi?id=10354> seems to indicate
that glibc switched to a different implementation of posix_spawn that uses
clone(2) instead of fork()/vfork() to avoid some problems with
Ronald Oussoren added the comment:
I get the impression that go uses vfork on Linux, not posix_spawn, because go
doesn't use libc (based on reading the referenced issue, not on deep knowledge
of go and its implementation).
I do wonder why glibc's implementation of posix_spawn doesn't use
Ronald Oussoren added the comment:
@Zorg: you don't need to sell the usefulness of this functionality. Its just
that the python developers are volunteers and hence have limited time to work
on python.
--
___
Python tracker
<ht
Ronald Oussoren added the comment:
vfork() is more dangerous than fork() because the parent and child processes
share memory (not copy-on-write, but really the same memory). Whether or not
this affects posix_spawn depends on its implementation (to give a very vague
statement).
Glibc
Ronald Oussoren added the comment:
Good question. A comment on
<https://stackoverflow.com/questions/2731531/faster-forking-of-large-processes-on-linux>
says that glibc already uses vfork where appropriate, explicitly using the
flag may not be necessary.
Note that I haven't ve
Ronald Oussoren added the comment:
@vstinner: another option is to ignore "use_vfork" on platforms that don't have
POSIX_SPAWN_USEVFORK. Using vfork or not is primarily a optimisation, ignoring
the flag should not result in different behaviour (other than speed).
-
Ronald Oussoren added the comment:
IMHO there doesn't need to be a new API unless the semantics change w.r.t
Py_TYPE (for example by adding an API that returns an owned reference instead
of a borrowed reference). Py_TYPE can work with an opaque version of PyObject
by turning
Ronald Oussoren added the comment:
Linking with newer SDKs is needed to get access to some newer features and
APIs. That's less relevant for Python itself, but can be relevant for the
embedding application. You can still compile Python itself on an older
machine, then link
Ronald Oussoren added the comment:
Yes it should, the same problem has been present from the start.
--
___
Python tracker
<https://bugs.python.org/issue31
Ronald Oussoren added the comment:
There's not enough information in the issue to be sure, but I'm inclined to say
this is a 3th-party problem. To be sure someone will have to reproduce the
problem in a debugger, or provide a stack trace of the crash.
The initial message says there's
Ronald Oussoren added the comment:
Binaries currently work on the system you compiled on and any later release of
macOS. That's the only "promise" there currently is.
Anything better requires work, and hence someone willing to do that work.
I'd love to be able to build on the la
Ronald Oussoren added the comment:
I get the same error, also with python3.7. Both for homebrew and a python.org
installer.
--
components: +macOS
nosy: +ned.deily, ronaldoussoren
versions: +Python 3.7
___
Python tracker
<https://bugs.python.
Ronald Oussoren added the comment:
The primary Python.org installer supports 10.9 and later by way of being
compiled on 10.9, and there is also an installer that supports 10.6.
There currently is no promise that building on 10.13 results in code that works
on earlier versions of macOS
Ronald Oussoren added the comment:
I'm not to happy about the crash, the interpreter shouldn't crash like this.
This may well be Tk related though.
--
resolution: -> not a bug
stage: -> resolved
status: open -> pending
type: -> crash
__
Ronald Oussoren added the comment:
@DeKrain: I agree
--
components: +Extension Modules -Library (Lib)
___
Python tracker
<https://bugs.python.org/issue34
Ronald Oussoren added the comment:
It's not as easy as that, the SystemError in the original report is caused by
invalid use of a C-API due to partial initialisation of an _struct.Struct
instance.
The solution is likely two-fold:
1) Ensure that __new__ fully initialises the fields in de C
Ronald Oussoren added the comment:
IMHO SystemError is the wrong exception, that exception is primarily used to
signal implementation errors.
BTW. I can reproduce crashes in a couple of runs of your scriptlet:
Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 26 2018, 23:26:24)
[Clang 6.0 (clang
Change by Ronald Oussoren :
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue34543>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
win32com is part of pywin32, which is a 3th-party extension. Please check with
that project first (if there is bug it is probably on that side).
--
components: +Windows
nosy: +paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
resolution
601 - 700 of 2417 matches
Mail list logo
