New submission from patrick vrijlandt patrick.vrijla...@gmail.com:
This causes a crash in python 3.2.2 and 3.2, but not in 2.7.2
C:\Python32python
Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
Łukasz Langa luk...@langa.pl added the comment:
Hello, Alexander. ConfigObj is an external library. It is not maintained by the
core team. You can report your issue to the ConfigObj issue tracker here:
http://code.google.com/p/configobj/issues/list
--
components: +None -Regular
maniram maniram maniandra...@gmail.com added the comment:
This bug can not be reproduced in Python 3.2.2 on Ubuntu.
Since Python 2.7.2 on your system raises a ValueError for dates below 1900
,your system's strftime probably does not allow dates below 1900 (unlike
Ubuntu).
Python 3.2.2's
Antoine Pitrou pit...@free.fr added the comment:
It owns the lock, but hasn't yet updated the lock's owner
(lock-tstate), so another thread calling detect_circularity() will
think that this lock is available, and will proceed, which can
eventually lead to a deadlock.
That's true. Do you
Antoine Pitrou pit...@free.fr added the comment:
Patch is now applied to 3.3, thank you for your patience :)
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
New submission from James Hutchison jamesghutchi...@gmail.com:
In python is currently there a way to elegantly throw an error if a variable is
already in the current scope?
For example:
def longfunc(self, filename):
FILE = open(filename);
header = FILE.readline();
... bunch of
Tim Golden m...@timgolden.me.uk added the comment:
Yes, but the MS crt strftime *for %y* requires a year = 1900 (ie
tm_year = 0). Looks like we need a special check.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13674
Antoine Pitrou pit...@free.fr added the comment:
I've checked the latest patch to work fine under Windows 7 (and Linux, of
course).
--
stage: - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12715
Changes by Hynek Schlawack h...@ox.cx:
Added file: http://bugs.python.org/file24102/8330f2045f4d.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12715
___
Michael Foord mich...@voidspace.org.uk added the comment:
Thanks
--
resolution: - duplicate
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13675
___
sbt shibt...@gmail.com added the comment:
I have tried the same with Python 2.7.1 on Linux. The problem is the same, but
one gets a partial traceback with no exception:
import sys, testsigint
testsigint.wait()
^CTraceback (most recent call last):
File stdin, line 1, in module
Hynek Schlawack h...@ox.cx added the comment:
Added new patch with protection for the remaining UF_NODUMPs in the test case.
All raised issues should be fixed now. :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12715
Changes by Florent Xicluna florent.xicl...@gmail.com:
--
nosy: +belopolsky, flox, haypo
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13674
___
Antoine Pitrou pit...@free.fr added the comment:
I think calling PyErr_WriteUnraisable would be more appropriate than
PyErr_Clear.
I also wonder whether it's ok to ignore the exception. Pressing e.g. Ctrl-C
generally shouldn't fail to stop the program, even if another exception is
being
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset cf57ef65bcd0 by Antoine Pitrou in branch 'default':
Issue #12715: Add an optional symlinks argument to shutil functions (copyfile,
copymode, copystat, copy, copy2).
http://hg.python.org/cpython/rev/cf57ef65bcd0
STINNER Victor victor.stin...@haypocalc.com added the comment:
timemodule.c has the following check:
#if defined(_MSC_VER) || defined(sun)
if (buf.tm_year + 1900 1 || buf.tm_year + 1900) {
PyErr_SetString(PyExc_ValueError,
strftime() requires year in
New submission from Jim Jewett jimjjew...@gmail.com:
The current docstring for compile suggests that the flags are strictly for
selecting future statements. These are not the only flags.
It also suggests that the source must be source code and the result will be
bytecode, which isn't quite
Roger Serwy roger.se...@gmail.com added the comment:
This is a duplicate of issue4625 and was fixed.
The silently failing is part of issue13582.
--
nosy: +serwy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13675
Tim Golden m...@timgolden.me.uk added the comment:
This is happening on Windows x86 against the current tip. The MS C runtime can
handle older dates; it's just that we're taking 1900 off the year at some
point. (At least, I think that's what's happening). FWIW you only need
time.strftime to
sbt shibt...@gmail.com added the comment:
Attached is a patch for the default branch.
Before calling PyFile_WriteString() the patch saves the current exception.
Then it calls PyErr_CheckSignals() and clears the current exception if any.
After calling PyFile_WriteString() the exception is
Tim Golden m...@timgolden.me.uk added the comment:
... and that's because the tm struct defines the tm_year field as an offset
from 1900. Sorry for the false start. I'll look at the MS runtime stuff instead
--
___
Python tracker
New submission from Petri Lehtinen pe...@digip.org:
Inserting a string with embedded zero byte only inserts the string up to the
first zero byte:
import sqlite3
connection = sqlite3.connect(':memory:')
cursor = connection.cursor()
cursor.execute('CREATE TABLE test (value TEXT)')
New submission from Michael Foord mich...@voidspace.org.uk:
Reported by a user. Reported on Windows but probably not Windows specific.
If IDLE doesn't have permission to read the recent-files.lst file then it
crashes. (When launched with pythonw.exe on Windows it silently fails to open
with
Charles-François Natali neolo...@free.fr added the comment:
IIUC, the deadlock avoidance code just checks that acquiring a
per-module lock won't create a cycle.
However, I think there's a race, because the cycle detection and the
lock acquisition is not atomic.
For example, let's say we have a
sbt shibt...@gmail.com added the comment:
I think I have found the problem. PyTraceBack_Print() calls
PyFile_WriteString(), which calls PyFile_WriteObject(), which calls
PyObject_Str() which begins with
PyObject_Str(PyObject *v)
{
PyObject *res;
if (PyErr_CheckSignals())
Eric Snow ericsnowcurren...@gmail.com added the comment:
Interesting thought, the syntax seems unnecessary. Adding new syntax to the
language is something that happens rarely and only with a _lot_ of
consideration.
As a slightly more verbose alternative, currently you can do this:
def
Benjamin Peterson benja...@python.org added the comment:
I think this more the domain of pylint/pyflakes.
--
nosy: +benjamin.peterson
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Zbyszek Szmek zbys...@in.waw.pl added the comment:
Review of both patches (python-2.5.1-distutils-aixnfs.patch and
dir_util.py.diff) as they are essentially the same:
I think that the test is in wrong place: we would want to ignore those .nfs*
files always, not just when checking for
James Hutchison jamesghutchi...@gmail.com added the comment:
For starters, this would be most efficient implementation:
def unique(varname, value, scope):
assert(not varname in scope);
scope[varname] = value;
Usage:
unique('b', 1, locals());
print(b);
But you can't put that in a loop
Antoine Pitrou pit...@free.fr added the comment:
Here is a patch adding the source code size to the pyc header.
The number of places where details of the pyc file format are hard coded is
surprisingly high...
Unfortunately, I had to modify importlib's public API (path_mtime -
path_stats). I
Benjamin Peterson benja...@python.org added the comment:
I suggest you mail python-ideas.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13678
___
sbt shibt...@gmail.com added the comment:
I think calling PyErr_WriteUnraisable would be more appropriate than
PyErr_Clear.
You mean just adding
PyErr_CheckSignals();
if (PyErr_Occurred())
PyErr_WriteUnraisable(NULL);
before the call to PyFile_WriteString()? That seems to
patrick vrijlandt patrick.vrijla...@gmail.com added the comment:
Is it relevant that 2.7.2 _does_ throw a correct exception?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13674
___
Antoine Pitrou pit...@free.fr added the comment:
Where are the tests? :)
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13676
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13645
___
New submission from Rock Achu rockac...@gmail.com:
running this script repeatedly causes corruption in the console window.
Just before posting this report, it led to a complete windows system freeze.
running python 2.7 x86 on windows x64.
The programs seems to run a couple times (when it is
Rock Achu rockac...@gmail.com added the comment:
I hit Ctrl-C right after opening the bat file and got this mess:
--
Added file: http://bugs.python.org/file24109/error.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13679
Rock Achu rockac...@gmail.com added the comment:
On a hunch opened task manager. There were over 9000 python processes open.
Shocking.
That was probably the cause of the system freeze.
However I only had 20 threads open. Why so many processes?
--
Rock Achu rockac...@gmail.com added the comment:
Or did I only have 20 threads?
if the program was running in a loop, then it would have spawned 20 threads
each, leading to the huge amount of processes, and probably the other issues.
So why does it run so many times?
--
Rock Achu rockac...@gmail.com added the comment:
Ok, using other code, I narrowed it down to this code and before:
for i in xrange(10):
spawner.newproc(run=True)
repeating infinitely
which only should set a variable (self.busy) to false
--
___
Rock Achu rockac...@gmail.com added the comment:
By inserting print statements and feverishly killing the process, I narrowed it
down to the statement:
self.thread.start()
that causes the issue.
which runs _M_Process.func() in a multiprocessing.Process
--
Rock Achu rockac...@gmail.com added the comment:
More clues:
the function _M_Process.func isn't being called.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13679
___
Rock Achu rockac...@gmail.com added the comment:
Changing the function name and removing the argument (self) passed to func
doesn't change a thing.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13679
Rock Achu rockac...@gmail.com added the comment:
Alright. The issue stays here. Passing nothing to multiprocessing.Process still
reproduces the issue.
someone else know how to deal with this?
--
___
Python tracker rep...@bugs.python.org
Rock Achu rockac...@gmail.com added the comment:
Alright. Just running:
import multiprocessing
thread = multiprocessing.Process()
thread.start()
raw_input()
-
Causes the crash. This time there is no output, so it is essentailly invisible.
Caught me by surprise.
--
45 matches
Mail list logo
