Jurko Gospodnetić added the comment:
Hi Steve,
Thanks for a quick reply.
> Yeah, this whole issue is basically because Burn (our installer tool) won't do
> per-machine bundle registration even when it's only installing per-machine
> packages. So the install block that it w
Change by Jurko Gospodnetić :
--
versions: +Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue41
Change by Jurko Gospodnetić :
--
versions: -Python 3.10, Python 3.9
___
Python tracker
<https://bugs.python.org/issue41800>
___
___
Python-bugs-list mailin
Jurko Gospodnetić added the comment:
Some other potentially related issues:
- https://bugs.python.org/issue25164
- https://bugs.python.org/issue32966
- https://bugs.python.org/issue37756
And some other related links:
-
https://docs.microsoft.com/en-us/troubleshoot/windows-server/application
Jurko Gospodnetić added the comment:
This seems related to https://bugs.python.org/issue41800.
--
nosy: +Jurko.Gospodnetić
___
Python tracker
<https://bugs.python.org/issue29
Jurko Gospodnetić added the comment:
This also seems related to https://bugs.python.org/issue29033.
--
___
Python tracker
<https://bugs.python.org/issue41
New submission from Jurko Gospodnetić :
This issue seems to affect all Python 3 Windows installers.
Reproduced on:
- various Windows 10 systems
- one Windows 8 system
- one Windows 7 system
- all tested Python 3+ installers up to and including 3.8.5
Scenario:
1. there is already an existing
Jurko Gospodnetić added the comment:
encountered what I believe is the same problem, so here are some more details I
noticed, after checking what exactly that process name lookup does using
ProcessMonitor:
- when running my external process in a `venv` generated virtual environment,
POpen
Changes by Jurko Gospodnetić :
Removed file: http://bugs.python.org/file36823/218ef482e1e4.diff
___
Python tracker
<http://bugs.python.org/issue7511>
___
___
Python-bug
Changes by Jurko Gospodnetić :
Added file: http://bugs.python.org/file36823/218ef482e1e4.diff
___
Python tracker
<http://bugs.python.org/issue7511>
___
___
Python-bug
Jurko Gospodnetić added the comment:
Here's another patch fixing the Visual Studio Express edition issue
plus some minor related code-cleanup.
See the Hg repo at:
https://bitbucket.org/jurko/cpython
branch:
jurko/distutils_msvc_express_fix
direct link:
https://bitbucket.org/
Jurko Gospodnetić added the comment:
Might be related to the following issues:
http://bugs.python.org/issue9571
http://bugs.python.org/issue13922
--
___
Python tracker
<http://bugs.python.org/issue22
New submission from Jurko Gospodnetić:
If you have an optional nargs=argparse.REMAINDER argument defined
then, if specified, its value should contain all the remaining command-line
content. However, it seems that value does not include later '--' arguments.
For example, the followin
Jurko Gospodnetić added the comment:
Thanks for the detailed response! :-(
I should have tested more before reporting the issue.
Sorry for the noise. :-(
I saw the 'cls' argument and assumed it was a class
method. Having to explicitly specify cls did not
seem to be in contradiction
Changes by Jurko Gospodnetić :
--
keywords: +patch
Added file: http://bugs.python.org/file35130/81c5ba188805.diff
___
Python tracker
<http://bugs.python.org/issue21
New submission from Jurko Gospodnetić:
Doc/reference/datamodel.rst documentation states that
the __new__ method is a static method (in Python, not
in C!) when it is in fact a class method.
A patch has been prepared in the
https://bitbucket.org/jurko/cpython repository.
branch
Jurko Gospodnetić added the comment:
Thanks for looking into this Xavier.
Could someone reopen this issue so it can gets looked at again?
--
___
Python tracker
<http://bugs.python.org/issue21
Jurko Gospodnetić added the comment:
Just ran into this problem and it's so uncomfortable
researching dynamic structures at run-time using PDB
without this. :-(
As a workaround, you can use a trick similar to this one
to 'import' your locals into the list comprehension body:
New submission from Jurko Gospodnetić:
nturl2path.py module contains comments implying that it converts local paths to
URLs with ':' characters replaced with '|'. This has not been true since Python
2.6.
Commit at:
http://bitbucket.org/j
Jurko Gospodnetić added the comment:
Or, if you do not want to get into the specifics of how
to manually install setuptools/pip, it would probably be
better to just refer the user to the 'ensurepip' module
for the initial installation and tell him to upgrade
whatever is needed from the
Jurko Gospodnetić added the comment:
err... by Python 3.5 I meant Python 3.4.1 as well :-)
--
___
Python tracker
<http://bugs.python.org/issue19983>
___
___
Pytho
Jurko Gospodnetić added the comment:
Anyone have an eye on this item?
What are the chances of the suggested patch being applied for
Python 3.5?
Or the issue resolved in some other way?
Anything I can do to help?
P.S.
I'm not sure exactly how the regular development protocol
goes around
New submission from Jurko Gospodnetić:
In the Python documentation note:
http://docs.python.org/3.4/library/venv.html#venv-def
the paragraph:
> Common installation tools such as Distribute and pip work
> as expected with venvs - i.e. when a venv is active, they
> install Python
Jurko Gospodnetić added the comment:
Thanks Brett! :-)
--
___
Python tracker
<http://bugs.python.org/issue20884>
___
___
Python-bugs-list mailing list
Unsub
Jurko Gospodnetić added the comment:
Here are some more Windows Installer notes taken down
when originally researching this issue on my end.
Hopefully they can be of some use to anyone researching
the issue further:
- each installation gets a GUID key identifying it
- the installation GUID key
Jurko Gospodnetić added the comment:
This issue can confuse a regular user in the following
scenario:
1. User uses 'for current user only' Python installations.
2. User expects to be able to see all installed software
listed in the 'Add/Remove Programs' dialog and does
Jurko Gospodnetić added the comment:
Here is a possible 'workaround' for the issue, but it
will take someone more knowledgeable about the Windows
Installer infrastructure to say if the workaround can be
applied directly as a clean solution or if it could have
hidden consequences.
E
New submission from Jurko Gospodnetić:
When you install 32-bit CPython 'for the current user
only' on 64-bit Windows, the installation does not show
up in the Windows 'Add/Remove Programs' dialog (a.k.a.
'Programs and Features' dialog on Windows 7). It does
not show
New submission from Jurko Gospodnetić:
On Windows, when you repair your Python 3.4 installation, it
will not reinstall pip & setuptools. Here by 'repair' I mean
a 'Windows Installer' based repair installation.
Reproduced using:
* Windows 7 SP1 x64.
* Python 3.4.0 (3
Jurko Gospodnetić added the comment:
> Step 2: Jurko can you see if the uploaded patch fixes things for you?
Yup. That's exactly how we were working around the issue before
reporting it here. :-)
--
___
Python tracker
<http://bugs
Jurko Gospodnetić added the comment:
+1 for the clean solution :-)
--
___
Python tracker
<http://bugs.python.org/issue20884>
___
___
Python-bugs-list mailin
Jurko Gospodnetić added the comment:
This could possibly also have been caused by a resolution to issue 18088
(http://bugs.python.org/issue18088).
See commit e873f2e67353 (http://hg.python.org/cpython/rev/e873f2e67353).
--
___
Python tracker
<h
Jurko Gospodnetić added the comment:
That 'what's new' item seems relevant, except that the issue here
is related to the __file__ attribute instead of __path__. Could it
be that the same fix actually updated how the __file__ attribute is
defined as well?
The bug seems to be caus
Jurko Gospodnetić added the comment:
Ask per Nick's instructions I tweaked cx_Freeze to import a dummy
package as frozen. The dummy package has the following structure:
gugu/
__init__.py
and its __init__.py file contains only the 8 bytes '__file__'
(does not include the
Jurko Gospodnetić added the comment:
As mentioned by Anthony Tuininga at:
https://bitbucket.org/anthony_tuininga/cx_freeze/issue/61/python-340-nameerror-name-__file__-is-not#comment-9077661
The value of __file__ in the problematic importlib/__init__.py
module with Python 3.3. is '
Jurko Gospodnetić added the comment:
Here's a recipe I can use to reproduce the problem on my PC.
Environment:
* Windows 7 SP1 x64
* Python 3.4.0rc3
* cx_Freeze checkout from its current HEAD
* repository: https://bitbucket.org/anthony_tuininga/cx_freeze
* HEAD c
Jurko Gospodnetić added the comment:
> I cannot reproduce your issue
Meaning you do not have the environment set up for this or that you tried it
and it worked for you?
If it 'worked for you', I can send you more detailed environment information
when get back to my office
Jurko Gospodnetić added the comment:
Item possibly related to this. When packaging a simple HelloWorld-like
application like this:
print("Hello world")
import configparser
using cx_Freeze and Python 3.4, you get the following error on packaged
application startup:
Traceback (m
Jurko Gospodnetić added the comment:
I'll try to set up and post a reproducible use case tomorrow. Then you can
decide. It could turn out that the use case we ran into has an easy workaround.
--
___
Python tracker
<http://bugs.python.org/is
Jurko Gospodnetić added the comment:
> Nor was Martin suggesting it as far as I can tell
I'm sorry if I came across too strongly. I can assure you I meant no disrespect
nor have I at any point felt affronted by anything anyone else said in this
thre
Jurko Gospodnetić added the comment:
And as for simultaneous 64/32-bit Python installations on a single 64-bit
machine - as Paul said, whichever way Microsoft implemented its automatic
registry key redirection, it is up to Python to decide how its installer should
behave.
So the question is
Jurko Gospodnetić added the comment:
I'm against removing local user installation support because that is the only
way Python can be installed without write access to shared system locations
like the Windows system folder or the HKEY_LOCAL_MACHINE registry
Jurko Gospodnetić added the comment:
David: Nope, the issue does not exist with 3.3.
--
___
Python tracker
<http://bugs.python.org/issue20884>
___
___
Python-bug
New submission from Jurko Gospodnetić:
Python 3.4 introduced a change to Lib/importlib/__init__.py that added the
following code to it:
> else:
> # importlib._bootstrap is the built-in import, ensure we don't create
> # a second copy of the module.
> _b
Jurko Gospodnetić added the comment:
A possible solution would be to update installers and runners to use
HKEY_CURRENT_USER\Software\Wow6432Node registry entries for 32-bit 'for current
user only' installations on a 64-bit Windows OS.
To preserve backward compatibility, runners
New submission from Jurko Gospodnetić:
When running the Python Windows installer 'for all users', the 32-bit
installation and the 64-bit installation each gets a separate registration in
the Windows registry. E.g. under:
HKEY_LOCAL_MACHINE\Software\Python\PythonCor
Jurko Gospodnetić added the comment:
And another one:
'setttings'
should be spelled
'settings'
in:
http://hg.python.org/releasing/3.4/file/c1f9fbefb237/Doc/library/unittest.mock.rst#l1512
--
___
Python tracker
<http://bug
Jurko Gospodnetić added the comment:
Another related documentation 'bug' - the following wording:
> Mock doesn’t create these but instead of raises an
> AttributeError.
should be changed to something like:
> Mock doesn’t create these on demand and raises an AttributeError
New submission from Jurko Gospodnetić:
Python unittest.mock documentation has typo:
indvidually
instead of
individually
Can be seen in the documentation source file at:
http://hg.python.org/releasing/3.4/file/c1f9fbefb237/Doc/library/unittest.mock-examples.rst#l429
--
assignee
Jurko Gospodnetić added the comment:
This issue is related to issue #19983 on Windows.
Also, I do not think the suggested -z option implementation should be
accepted 'as is'.
On Unix it would make Ctrl-C silently terminate the process if it occurs
before default Python signal h
Changes by Jurko Gospodnetić :
Added file: http://bugs.python.org/file33140/crash-info-11.txt
___
Python tracker
<http://bugs.python.org/issue19983>
___
___
Python-bug
Changes by Jurko Gospodnetić :
Removed file: http://bugs.python.org/file33139/crash-info-11.txt
___
Python tracker
<http://bugs.python.org/issue19983>
___
___
Python-bug
Jurko Gospodnetić added the comment:
I reproduced the issue about 10 more times to see if I'd get some more useful C
tracebacks in Visual Studio, but they seems to be the pretty much the same
every time (as seen in the attached
http://bugs.python.org/file33137/crash-info-10.txt file).
Jurko Gospodnetić added the comment:
I can reproduce this most easily if I run a command like:
clean.cmd & run.py
where clean.cmd is any short batch script and run.py is a file containing only
the '#! python3' shabang line.
The batch script in front is not necessary, and I
Changes by Jurko Gospodnetić :
Added file: http://bugs.python.org/file33138/crash-info-1-9 - Python tracebacks
only.txt
___
Python tracker
<http://bugs.python.org/issue19
New submission from Jurko Gospodnetić:
If you press Ctrl-C during Python startup on Windows you may get interpreter
crashes with different Python tracebacks displayed on the standard system error
output stream.
Reproduced using:
- Windows 7 SP1 x64
- Python 3.3.3 (64-bit) as downloaded
Changes by Jurko Gospodnetić :
--
components: +email -Interpreter Core
nosy: +Jurko.Gospodnetić, barry
___
Python tracker
<http://bugs.python.org/issue14
Jurko Gospodnetić added the comment:
Clicked send too soon on the previous comment. :-(
The simplest way I see you can fix the __del__ issue is to patch
TemporaryDirectory.__init__() as follows:
def __init__(self, suffix="", prefix=template, dir=None):
self._clo
Jurko Gospodnetić added the comment:
Also this class, because it defines __del__ too simply, will display a
user-unfriendly error message when cleaning up a TemporaryDirectory object
whose constructor raised an exception when attempting to create its temporary
folder.
For example try to
59 matches
Mail list logo