JP Sugarbroad added the comment:
That matches our expectation. A subclass works - perhaps `c_void_p` could be
deprecated in favor of a built-in subclass for generic opaque pointers as well?
Glad you agree that a warning would be useful here
New submission from JP Sugarbroad :
The following code will likely crash on I32LP64 systems:
dim = lib.get_array_size(opaque)
ptrs = (c_void_p * dim)()
lib.get_array_values(opaque, ptrs)
for ptr in ptrs:
print(lib.get_object_value(ptr))
What happens is that `ptr` is not a `c_void_p
JP Zhang added the comment:
>>>python test.py --num_epochs 200
usage: test.py [-h] [--data_type DATA_TYPE]
test.py: error: unrecognized arguments: --num_epochs 200
I have a created a colab share link. You can check:
https://colab.research.google.com/drive/1TUvt4CCv2d43GD1ccmuRNBJ
New submission from JP Zhang :
Github repo for reproducing: https://github.com/zjplab/gc-mc-pytorch/tree/bug,
test.py.
In the presence of my custom data_loader, it will error as unrecognized
argument. But without importing it(comment it out) everything is just fine.
--
components
Change by JP Sugarbroad :
--
nosy: +taralx
___
Python tracker
<https://bugs.python.org/issue15994>
___
___
Python-bugs-list mailing list
Unsubscribe:
jp added the comment:
Have you checked if there are pyc files left around by the previous
installation? -- Yes, hundreds! After making a backup, i deleted all 900+
occurrences of "*.pyc" in c:\python27 and it still reports 2.7.8.
Have you specified the full path to python.exe from
jp added the comment:
Forget to mention this downgrade was installed over the existing python
installation.
--
___
Python tracker
<http://bugs.python.org/issue22
New submission from jp:
After downgrading from version 2.7.8 to 2.7.5 on Win7 x86 32bit Python, the
interpreter continues to report version 2.7.8.
I have verified that the installation folder has the correct files belonging to
2.7.5 as evidenced by python.exe having a 2013 timestamp.
Ran
New submission from jp:
The following code:
li = [[1,0]]*5
a = [[1,10], [2,20], [3,30]]
for line in a:
li[line[0]][0] = 2
print(li)
prints [[2,0],[2,0],[2,0],[2,0],[2,0]], but should print
[[1,0],[2,0],[2,0],[2,0],[1,0]].
The output is correct if you, instead of using li = [[1,0]]*5
Changes by JP St. Pierre :
--
keywords: +patch
Added file: http://bugs.python.org/file19462/tarinfo-10292.diff
___
Python tracker
<http://bugs.python.org/issue10
New submission from JP St. Pierre :
With all the tools I've used, the target of a symlink appears to be relative to
the actual symlink entry. Fix this.
--
components: Library (Lib)
messages: 120208
nosy: magcius
priority: normal
severity: normal
status: open
title: tarinfo shoul
JP St. Pierre added the comment:
This patch should fix the bug.
--
keywords: +patch
Added file: http://bugs.python.org/file15631/auth_7552.patch
___
Python tracker
<http://bugs.python.org/issue7
New submission from JP St. Pierre :
Uploading a file to PyPI fails when a user has a long password, as
base64.encodestring linewraps data. Either replace '\n' with '', or use
base64.standard_b64encode
--
assignee: tarek
components: Distutils
messages: 96709
nosy: mag
13 matches
Mail list logo
