Change by Steve Dower :
--
keywords: +patch, patch
pull_requests: +11664, 11665
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Steve Dower :
--
keywords: +patch, patch, patch
pull_requests: +11664, 11665, 11666
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Steve Dower added the comment:
So with the fix for multiprocessing, we currently rely on __PYVENV_LAUNCHER__
remaining set throughout the process.
However, it may be better to add a "sys.base_executable" property instead and
clear the __PYVENV_LAUNCHER__ variable once we've r
Steve Dower added the comment:
You can't actually nest virtual environments, at least with venv - it ought to
be configuring it all against the original environment.
What is in your pyvenv.cfg files here?
--
___
Python tracker
&
Steve Dower added the comment:
Is there any reason to not resolve the base executable on creation and make it
relative to that? So the second pyvenv.cfg would have the same home directory
as the first?
My proposed fix for issue35873 (PR soon) is going to make this trivial.
--
nosy
Steve Dower added the comment:
My PR fixes both issues properly, but adds a minor "feature" to distutils by
making distutils.sysconfig.get_python_inc() potentially return a set of include
paths (with os.path.pathsep separators).
This is fully internal, so right now we know it
Change by Steve Dower :
--
keywords: +patch, patch
pull_requests: +11667, 11668
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Steve Dower :
--
keywords: +patch
pull_requests: +11670
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35873>
___
___
Py
Change by Steve Dower :
--
keywords: +patch
pull_requests: +11667
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35872>
___
___
Py
Change by Steve Dower :
--
keywords: +patch, patch, patch
pull_requests: +11667, 11668, 11669
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Steve Dower :
--
keywords: +patch, patch
pull_requests: +11670, 11671
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Steve Dower :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Steve Dower :
--
nosy: -steve.dower
___
Python tracker
<https://bugs.python.org/issue35841>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Steve Dower :
--
keywords: +patch, patch
pull_requests: +11672, 11673
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Steve Dower :
--
assignee: -> steve.dower
___
Python tracker
<https://bugs.python.org/issue35692>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Steve Dower :
--
keywords: +patch, patch, patch
pull_requests: +11672, 11673, 11674
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Steve Dower :
--
keywords: +patch
pull_requests: +11672
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Steve Dower :
--
versions: -Python 3.5, Python 3.6
___
Python tracker
<https://bugs.python.org/issue35642>
___
___
Python-bugs-list mailing list
Unsub
Change by Steve Dower :
--
assignee: -> steve.dower
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python
Steve Dower added the comment:
New changeset 8ebc6451f36fa213130c316199dbec5ad8a02163 by Steve Dower (Minmin
Gong) in branch 'master':
bpo-35890 : Fix some API calling consistency (GH-11742)
https://github.com/python/cpython/commit/8ebc6451f36fa213130c316199dbec
Steve Dower added the comment:
Thanks for the contribution!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Steve Dower added the comment:
> I don't know why we add argv0_path to sys.path.
My guess is that the idea was to be able to load the .pyd files we used to put
alongside it, though we found out they weren't being loaded anyway.
One potential side effect is that manually creat
Steve Dower added the comment:
New changeset 2f6fae6e510dba653391cb510a2aca8322eec03b by Steve Dower in branch
'master':
bpo-35692: pathlib no longer raises when checking file and directory existence
on drives that are not ready (GH-11746)
https://github.com/python/cpyt
Steve Dower added the comment:
New changeset a8474d025cab794257d2fd0bea67840779b9351f by Steve Dower in branch
'master':
bpo-35872 and bpo-35873: Clears __PYVENV_LAUNCHER__ variable (GH-11745)
https://github.com/python/cpython/commit/a8474d025cab794257d2fd0bea6784
Steve Dower added the comment:
New changeset a8474d025cab794257d2fd0bea67840779b9351f by Steve Dower in branch
'master':
bpo-35872 and bpo-35873: Clears __PYVENV_LAUNCHER__ variable (GH-11745)
https://github.com/python/cpython/commit/a8474d025cab794257d2fd0bea6784
Change by Steve Dower :
--
pull_requests: +11689
___
Python tracker
<https://bugs.python.org/issue35872>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Steve Dower :
--
pull_requests: +11689, 11690
___
Python tracker
<https://bugs.python.org/issue35872>
___
___
Python-bugs-list mailing list
Unsub
Change by Steve Dower :
--
pull_requests: +11689, 11690, 11691
___
Python tracker
<https://bugs.python.org/issue35872>
___
___
Python-bugs-list mailing list
Unsub
Change by Steve Dower :
--
pull_requests: +11692
___
Python tracker
<https://bugs.python.org/issue35873>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
Py_Initialize() is not supposed to set it up. If you are embedding Python, you
have to be responsible for configuring the paths that it uses - pyvenv.cfg is
configuration for Python interactive, not the shared lib (using Windows
terminology, it's configur
Change by Steve Dower :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Steve Dower added the comment:
New changeset 44467e8ea4cea390b0718702291b4cfe8ddd67ed by Steve Dower in branch
'3.7':
bpo-35872 and bpo-35873: Clears __PYVENV_LAUNCHER__ variable (GH-11745)
https://github.com/python/cpython/commit/44467e8ea4cea390b0718702291b4c
Steve Dower added the comment:
New changeset 44467e8ea4cea390b0718702291b4cfe8ddd67ed by Steve Dower in branch
'3.7':
bpo-35872 and bpo-35873: Clears __PYVENV_LAUNCHER__ variable (GH-11745)
https://github.com/python/cpython/commit/44467e8ea4cea390b0718702291b4c
Change by Steve Dower :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Steve Dower :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Steve Dower added the comment:
> The idea is that python, in the embedding application, should work as in the
> python executable.
I disagree that this is the idea. Python in the embedding application should
work as in the embedding application, not the standalone one. The emb
Steve Dower added the comment:
Agreed that it should go to setuptools in order to support third-party packages.
In general, those of us who ever touch distutils these days (basically just
me?) are only really maintaining those parts necessary to build Python and its
own modules. Since this
Steve Dower added the comment:
New changeset 85e102a2b090dd693d0801ae2edb9660cfa0f281 by Steve Dower in branch
'master':
bpo-35299: Fixed sysconfig and distutils during PGO profiling (GH-11744)
https://github.com/python/cpython/commit/85e102a2b090dd693d0801ae2edb96
Change by Steve Dower :
--
assignee: -> steve.dower
___
Python tracker
<https://bugs.python.org/issue35299>
___
___
Python-bugs-list mailing list
Unsubscrib
Steve Dower added the comment:
This is intentional. The "platform" here represents the Python platform (for
figuring out whether native modules are compatible), and since it's the 32-bit
build of Python it should specify the 32-bit platform.
To find out information about the
Steve Dower added the comment:
The installer hasn't changed since 3.7, so this seems unlikely to be a new
issue.
I see this line in your log file:
MSI (s) (A8:D0) [13:09:39:028]: Ignoring disallowed property TARGETDIR
Perhaps your IT department has configured some restrictio
Steve Dower added the comment:
> sys.platform is defined by code path taken while compiling. it is hardcoded
> and really represents the os abi used of a *supported* platform
Correct, though the examples I'd give are Win32 vs. WinRT vs. Cygwin, which are
fundamentally different A
Steve Dower added the comment:
> This includes _getdiskusage, _getfinalpathname, _getfullpathname,
> _getvolumepathname, _isdir, and startfile. They have no place in a POSIX
> module.
Except for startfile, I disagree. They are all there to help implement POSIX
compatibility, and a
Steve Dower added the comment:
Victor may be thinking about it from time to time (or perhaps it's time to make
the rest of the configuration changes plans concrete so we can all help out?),
but I'd like to see this as either:
* a helper function to fill out the core config struct
New submission from Steve Dower :
As posted at
https://mail.python.org/pipermail/python-dev/2019-February/156229.html, add
support for the Windows ARM32 platform.
This is related to issue33125, but we are doing ARM32 first before considering
ARM64.
Paul Monson (Paul.Monson at microsoft.com
Steve Dower added the comment:
I think the caching that MSVC does naturally handles this well enough -
certainly rebuilds normally just build those files that have not changed.
Besides not rebuilding .o[bj] files where the sources have not changed, what
else do these tools do
Steve Dower added the comment:
Posted a review. I suggest a few changes for the sake of tidying up, but I
agree that I'd like to see more tests added.
--
___
Python tracker
<https://bugs.python.org/is
Steve Dower added the comment:
I'm not sure it's quite as simple as calling sys.exit, but it would be a great
project to bring universal cancellation support to all (regularly) blocking
functions. Asyncio has suffered from this as well.
Part of the problem is that POSIX APIs o
Steve Dower added the comment:
That looks like an incomplete log. Do you have the log file without
"000_core_JustForMe" at the end of the name?
--
___
Python tracker
<https://bugs.python.o
Steve Dower added the comment:
It seems to think the install has been deleted between extracting/verifying it
and launching the installer.
Do you have any antivirus running that you could disable? Those can sometimes
interfere like this
Steve Dower added the comment:
This is complete.
Right now it's a straight merge from the libffi repo, as we want to be on their
latest to help resolve any remaining bugs. Once they make a stable release, we
can snap to that.
--
assignee: -> steve.dower
resolution: ->
Steve Dower added the comment:
We should switch to _wsetlocale, or else come up with a more sensible mapping
that makes sense between platforms (like we have for encodings already).
I suspect the latter requires proper design and discussion, so it's worth doing
the first part immedi
New submission from Steve Dower :
Just updating the title to reflect what the patch actually does in isolation -
you probably should update the PR and NEWS items to match.
It's fine (probably preferred) to mention in the issue and PR text that it's
been split out from another PR. B
Steve Dower added the comment:
That's not a "see also" - it's just a duplicate :) I'll close this one as the
other one has been around longer.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Make pyvenv
Steve Dower added the comment:
I just closed 35706 as a duplicate of this one (the titles are basically
identical, which feels like a good hint ;) )
It seems that the disagreement about the design is fundamentally a disagreement
between a "quick, painful but complete fix" and &quo
Steve Dower added the comment:
Thanks, Victor, that's great information.
> Memory allocator, context, different structures for configuration... it's
> really not an easy topic :-( There are so many constraints put into a single
> API!
This is why I'm keen to des
Steve Dower added the comment:
Issue35976 was broken out for the more mechanical changes.
--
___
Python tracker
<https://bugs.python.org/issue35920>
___
___
Steve Dower added the comment:
New changeset 8a1657b93469580ef345c7c91738587f3d76e87d by Steve Dower (Paul
Monson) in branch 'master':
bpo-35976: Enable Windows projects to build with platform ARM32 (GH-11825)
https://github.com/python/cpython/commit/8a1657b93469580ef345c7c9173858
Steve Dower added the comment:
Thanks, Paul! Hopefully when you rebase the main change on top of this it will
be easier to see the actual impact.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Pytho
Steve Dower added the comment:
> So is that a no for a regular .zip release here?
> https://www.python.org/downloads/windows/
Correct, it's a no.
The main reason is because people use it wrong and get into trouble, and we
don't want to support that. (More after the docs l
Steve Dower added the comment:
The whole point of a venv is to give you a separate directory with a "stand
alone" Python. As that's what you just installed with nuget, there's no point
in creating a venv - just pip install directly into it.
Alternatively, you can pip in
Steve Dower added the comment:
There certainly used to be a problem where venv was totally reliant on Python
being in the registry to work properly. I'm not sure if that's still the case -
possibly with the new redirector in 3.7.2+
Steve Dower added the comment:
It would be a great help if you could copy the ensurepip and venv directories
from a regular install into an extracted Nuget package and let us know whether
your scenario works. As you can see from the discussion, there were problems
originally that may have
Steve Dower added the comment:
Yeah, I'm okay with it for 3.7.3 and future releases. The only change should
need to be for the nuget preset in PC/layout/support/options.py
--
___
Python tracker
<https://bugs.python.org/is
Change by Steve Dower :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.o
Steve Dower added the comment:
Would it make sense to add a parameter to _getfinalpathname that specifies the
type of the path? For same[open]file(), we can probably just go to the most
unreadable but broadly supported type, whereas the other functions that are
actually going to return the
Steve Dower added the comment:
We don't support older versions of MSVC at this point, so the version check
seems unnecessary.
If we need to alias these within the CPython sources for non-MSVC compilers,
then we should do it in source files. In general, we never want to pollute the
u
Steve Dower added the comment:
The most I'd be okay with doing here is filtering for "://" in the
webbrowser module, and not limiting "scheme" at all except that it must be a
valid scheme.
Windows allows apps and programs to extend protocol handling in
HKEY_CLASS
Steve Dower added the comment:
Eh, just needs to change the local variable to Py_ssize_t. This applies to all
platforms.
Might be worth asserting that it is no bigger than the largest number of child
tokens a node may have, but only if we have an arbitrary limit for that
somewhere (I
Steve Dower added the comment:
The PR requires PEP 7 to be applied thoroughly, but I think the concept is
sound enough.
--
nosy: +nr
___
Python tracker
<https://bugs.python.org/issue35
Steve Dower added the comment:
Thanks.
This is a well-known and long-standing issue between OpenSSL and Windows, and
the best workaround right now is to use the Mozilla certs directly.
One day when OpenSSL is no longer part of the CPython public API, then we can
consider switching to an
Steve Dower added the comment:
> Maybe webbrowser must be changed to become *very strict*.
This is the only acceptable suggestion I've seen (since my suggestion ;) )
I'd propose making it very strict by *requiring* a browser to be detected. So
remove the os.startfile defau
Steve Dower added the comment:
Start by just deleting the definitions in pyerrors.h, and see where the build
fails. Then either switch those to use PyOS_snprintf (best), or add the #ifndef
checks in the source files (not header files) that need them.
Be aware that we shouldn't backpor
Steve Dower added the comment:
> reveals an expectation that Py_END_ALLOW_THREADS won't change the results of
> GetLastError()
Fantastic work, Jeff! That's almost certainly the major problem there -
Py_END_ALLOW_THREADS can totally change the error code, and we haven
Steve Dower added the comment:
> I assume you meant #35662
Yes indeed. I am apparently massively dyslexic when it comes to copying issue
numbers into the bpo comment field :)
Meanwhile, over on #35662, Jeff has a fix for at least one of the regressions.
--
versions: +Python
Change by Steve Dower :
--
nosy: +steve.dower
___
Python tracker
<https://bugs.python.org/issue33944>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
The regular test suite ought to be enough - see devguide.python.org for the
info. It was definitely failing in multiprocessing last time I tried this.
You could also just push changes and start a PR, as that will run the tests
automatically
New submission from Steve Dower :
So the fundamental problem is that the default DLL search path on Windows
changes in various contexts, and the only consistent approach is the most
difficult to support with current packaging tools. The result is .pyd files
that need to resolve .dll
Steve Dower added the comment:
I nosied both Windows and import experts, and I'm about to go ping relevant
numpy/scipy people on https://github.com/numpy/numpy/pull/13019
Personally, I would prefer option #1, despite the pain it would cause. It is
the better long-term supported option
Steve Dower added the comment:
I took a look at the docs PR, and honestly I don't even get what the "intended"
uses of executable code are supposed to be.
The examples are "load 3rd-party import hooks, adjust PATH variable", but the
only cases I can think of where
Steve Dower added the comment:
I'm very against doing magic to extract the names from the DLL, but maybe we
could have a search path in the parent package? Then add/remove it around
importing the module.
I think you're right that we just need to update the LoadLibrary flags, but
Changes by Steve Dower :
--
pull_requests: +374
___
Python tracker
<http://bugs.python.org/issue27593>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Steve Dower :
--
pull_requests: +375
___
Python tracker
<http://bugs.python.org/issue27593>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Steve Dower :
--
pull_requests: +376
___
Python tracker
<http://bugs.python.org/issue27593>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Steve Dower :
--
pull_requests: +377
___
Python tracker
<http://bugs.python.org/issue27593>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
Here's some sample output with the change:
C:\build\cpython36>PCbuild\win32\python_d.exe
Python 3.6.0+ (3.6:95c50e5aed9e5683676e18349dd94b11901a66b3, Mar 4 2017,
06:08:54) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright"
Steve Dower added the comment:
copyright==>version string (sys.version)
Also, that part is clearly not release blocking. My PR for 2.7 is waiting for
Travis to catch up, so once that's done and Ned has finished his backports (or
Larry and Ben have backported to their versions?) we c
Steve Dower added the comment:
GitHub trims to the first 7 characters. I see no harm in doing that for
sys.version (but not tonight)
--
___
Python tracker
<http://bugs.python.org/issue27
Steve Dower added the comment:
I just did my build for 3.6.1rc1 and it looks like `git name-rev --name-only
--tags HEAD` returns "3.6.1rc1^0" for some reason.
Perhaps "git describe" is the better command to use here? From what I've seen
of that, it should do "
Steve Dower added the comment:
Eric - that sounds like the same issue. Can you test with 3.6.1rc1 to see if it
is fixed for you?
--
___
Python tracker
<http://bugs.python.org/issue29
Steve Dower added the comment:
We don't use MFC in Python, so we are not affected.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pyth
Steve Dower added the comment:
Oh, well that's by design. Neither the current working directory nor the
directory of the initial script are in sys.path by default - they need to be
added explicitly.
The intent of this distro is that you know exactly where relative to the
executable
Steve Dower added the comment:
There will be no changes to the CRT in the update. It's been released as a
major upgrade package rather than a patch, which is why it contains all the
files, but the last version field typically (and in this case definitely)
indicates no change to the A
Steve Dower added the comment:
It's actually "adding" the current directory by not replacing the empty string
that's normally there, presumably because it's already been resolved into a
path at this stage. The behavior on Windows is correct, so I expect it's
Steve Dower added the comment:
> C:\Temp doesn't belong in sys.path in this case
Hang on, why not? If I were running a module.py then it would be, so why is a
package\__main__.py different (and not able to import itself or its siblings)?
The package is the "script" being run
Steve Dower added the comment:
That will work fine. Thanks for checking
The process for pulling someone's PR into your own repo is roughly branch then
pull from the repo sending the PR. Github should show instructions for this
under m hidden behind a "merge manually" button (
Steve Dower added the comment:
I thought we'd documented that if you set the path when embedding you should
also set the program name, but perhaps not (didn't check just now). If not, we
should do that.
We shouldn't be loading python3.dll anywhere. Are you sure that's in C
Steve Dower added the comment:
Noted.
Did this bite you somehow? Is there something else that should be added/changed?
--
___
Python tracker
<http://bugs.python.org/issue23
Steve Dower added the comment:
Ah, I see. We force load it in PC/getpathp.c to ensure that it's ours and not
another version's python3.dll.
We should probably refactor the GetModuleFileNameW call into its own function
so we can call it from anywhe
Changes by Steve Dower :
--
stage: -> needs patch
type: -> behavior
versions: +Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/i
3101 - 3200 of 5794 matches
Mail list logo
