Jurko Gospodnetić jurko.gospodne...@gmail.com 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
Jurko Gospodnetić jurko.gospodne...@gmail.com 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
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com:
--
components: +email -Interpreter Core
nosy: +Jurko.Gospodnetić, barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14228
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ć jurko.gospodne...@gmail.com:
Added file: http://bugs.python.org/file33138/crash-info-1-9 - Python tracebacks
only.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19983
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've originally
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).
I'm
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com:
Removed file: http://bugs.python.org/file33139/crash-info-11.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19983
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com:
Added file: http://bugs.python.org/file33140/crash-info-11.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19983
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 handling
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:
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
instead.
Can be seen
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 rep...@bugs.python.org
http
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\PythonCore\3.4
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 could fall
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.
_bootstrap.__name__ = 'importlib
Jurko Gospodnetić added the comment:
David: Nope, the issue does not exist with 3.3.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20884
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 hive
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
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
thread/issue
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 rep...@bugs.python.org
http
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 (most recent
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 in an hour or so
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 commit
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 'frozen
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 quotes
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 caused by importlib
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 rep
Jurko Gospodnetić added the comment:
+1 for the clean solution :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20884
___
___
Python-bugs-list
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 rep...@bugs.python.org
http
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 (32-bit).
To reproduce do
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 up there even for the current
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.
Each 32-bit
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
not know
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:
Thanks Brett! :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20884
___
___
Python-bugs-list mailing
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 packages
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 here
Jurko Gospodnetić added the comment:
err... by Python 3.5 I meant Python 3.4.1 as well :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19983
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 there without
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/jurko/cpython/commits
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:
[l['r'](x
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 rep...@bugs.python.org
http://bugs.python.org/issue21161
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
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com:
--
keywords: +patch
Added file: http://bugs.python.org/file35130/81c5ba188805.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21415
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
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 following works
Jurko Gospodnetić added the comment:
Might be related to the following issues:
http://bugs.python.org/issue9571
http://bugs.python.org/issue13922
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3
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
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com:
Added file: http://bugs.python.org/file36823/218ef482e1e4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7511
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com:
Removed file: http://bugs.python.org/file36823/218ef482e1e4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7511
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:
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
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:
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 would norma
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
59 matches
Mail list logo
