[ python-Bugs-1514404 ] Typo in signal.alarm() description

[SourceForge.net]

Bugs item #1514404, was opened at 2006-06-29 17:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514404&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Shirley (kormat)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in signal.alarm() description

Initial Comment:
In the alarm() description paragraph on
http://docs.python.org/lib/module-signal.html , the
phrase 'no alarm id scheduled' should be 'no alarm is
scheduled' (i.e. the 'id' changed to 'is').

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514404&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1514420 ] Missing module code does spurious file search

[SourceForge.net]

Bugs item #1514420, was opened at 2006-06-29 16:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514420&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing module code does spurious file search

Initial Comment:
Now, exactly WHY is it looking for a file called
? :-)

This bug has been present since at least 2.3.3 - I
can't be bothered to
check back further.  Not surprisingly, it causes
misbehaviour if there
is a file called  in any of the places searched,
but it doesn't
strike me as the world's most catastrophic bug.



strace -e open python
Python 2.5b1 (trunk:47059, Jun 29 2006, 14:26:46)
[GCC 4.1.0 (SUSE Linux)] on linux2
>>> import dismal
open("dismal.so", O_RDONLY) = -1 ENOENT (No
such file or directory)open("dismalmodule.so",
O_RDONLY)   = -1 ENOENT (No such file or directory)
open("dismal.py", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("dismal.pyc", O_RDONLY)= -1 ENOENT (No
such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/dismal.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/plat-linux2/",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/lib-tk/",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/lib-dynload/",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/site-packages/",
O_RDONLY) = -1 ENOENT (No such file or directory)
  File "", line 1, in 
ImportError: No module named dismal
>>>


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514420&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1514428 ] NaN comparison in Decimal broken

[SourceForge.net]

Bugs item #1514428, was opened at 2006-06-29 16:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514428&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm)
Assigned to: Nobody/Anonymous (nobody)
Summary: NaN comparison in Decimal broken

Initial Comment:
Methinks this is a bit off :-)  True should be False.


Python 2.5b1 (trunk:47059, Jun 29 2006, 14:26:46)
[GCC 4.1.0 (SUSE Linux)] on linux2
>>> import decimal
>>> d = decimal.Decimal
>>> inf = d("inf")
>>> nan = d("nan")
>>> nan > inf
True
>>> nan < inf
False
>>> inf > nan
True
>>> inf < nan
False
b

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514428&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1514451 ] zipfile "append" mode should create a file if not present

[SourceForge.net]

Bugs item #1514451, was opened at 2006-06-29 22:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514451&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ritesh Raj Sarraf (riteshsarraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile "append" mode should create a file if not present

Initial Comment:
The line 

filename = zipfile.ZipFile(zip_file_name, "a") 

throws an exception if the given filename is not 
present already.

Shouldn't it create a file (in case one is not there) 
since it is "append" mode ??

It's throwing an OSError Exception stating "No such 
file/directory".

Normal convention has been that when opening a file 
in append mode, if the file is not present a new file 
is created.

Why is this non-standard?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514451&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1514404 ] Typo in signal.alarm() description

[SourceForge.net]

Bugs item #1514404, was opened at 2006-06-30 01:01
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514404&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Stephen Shirley (kormat)
>Assigned to: George Yoshida (quiver)
Summary: Typo in signal.alarm() description

Initial Comment:
In the alarm() description paragraph on
http://docs.python.org/lib/module-signal.html , the
phrase 'no alarm id scheduled' should be 'no alarm is
scheduled' (i.e. the 'id' changed to 'is').

--

>Comment By: George Yoshida (quiver)
Date: 2006-06-30 02:01

Message:
Logged In: YES 
user_id=671362

Thanks for the report, but this is already fixed in the
repository.

See bug #1462496
http://www.python.org/sf/1462496



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514404&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1504333 ] sgmllib should allow angle brackets in quoted values

[SourceForge.net]

Bugs item #1504333, was opened at 2006-06-11 08:58
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504333&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Sam Ruby (rubys)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: sgmllib should allow angle brackets in quoted values

Initial Comment:
Real live example (search for "othercorrections")

http://latticeqcd.blogspot.com/2006/05/non-relativistic-qcd.html

This addresses the following (included in the file):

# XXX The following should skip matching quotes (' or ")


--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-06-29 13:17

Message:
Logged In: YES 
user_id=3066

I checked in a modified version of this patch: changed to
use separate REs for start and end tags to reduce matching
cost for end tags; extended tests; updated to avoid breaking
previous changes to support IPv6 addresses in unquoted
attribute values.

Committed as revisions 47154 (trunk) and 47155
(release24-maint).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504333&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1202533 ] a bunch of infinite C recursions

[SourceForge.net]

Bugs item #1202533, was opened at 2005-05-15 16:43
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
>Assigned to: Armin Rigo (arigo)
Summary: a bunch of infinite C recursions

Initial Comment:
There is a general way to cause unchecked infinite recursion at the C level, 
and I have no clue at the moment how it could be reasonably fixed.  The idea is 
to define special __xxx__ methods in such a way that no Python code is actually 
called before they invoke more special methods (e.g. themselves).

>>> class A: pass
>>> A.__mul__=new.instancemethod(operator.mul,None,A)
>>> A()*2
Segmentation fault

--

Comment By: Brett Cannon (bcannon)
Date: 2006-06-26 12:31

Message:
Logged In: YES 
user_id=357491

Yes, Armin, that is a rather evil piece of code.  =)  But I
have a possible simple solution.  =)

If you add a check after the PyExceptionClass_Check() in the
'if' statement that tstate->recursion_depth is greater than
0, you short-circuit the infinite recursion and still get a
sensible output.

I have attached a patch with my proposed changes for
PyObject_Call() and PyErr_NormalizeException() and the
remove of the recursion check for slot_tp_call().  The only
issue I can see with this is if the recursion_depth check
turns out to be too small of a number.  But I really doubt
that will be an issue since one shouldn't be having a depth
of tracebacks greater than the current recursion depth.

Let me know what you think of the patch.

--

Comment By: Armin Rigo (arigo)
Date: 2006-06-25 02:33

Message:
Logged In: YES 
user_id=4771

Yes, it seems reasonable.  You should probably manipulate
tstate->recursion_depth directly instead of via the
macros, as e.g. ceval.c does.

This would fix most crashes here.  It would make the attached
test17.py segfault, though.  This test17 already segfaults a
debug build of Python, but not a release build because the
recursive PyErr_NormalizeException() is turned into a tail
call by gcc.  (What, a convoluted mind, mine?)

--

Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 14:54

Message:
Logged In: YES 
user_id=357491

I just had an idea, Armin.  What if, at the recursive call
site in PyErr_NormalizeException(), we called
Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall()
after?  That would keep the recursion limit the same when
the normalization was done, but still allow the check in
PyObject_Call()::

Py_LeaveRecursiveCall();
PyErr_NormalizeException(exc, val, tb);
Py_EnterRecursiveCall("");

Since it is an internal call I think it would be safe to
"play" with the recursion depth value like this.  What do
you think?

--

Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 13:57

Message:
Logged In: YES 
user_id=357491

The rev. that Armin checked in was actually r47061.

--

Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 13:53

Message:
Logged In: YES 
user_id=357491

I thought the check was in slot_tp_call and not
PyObject_Call.  So yeah, I basically forgot.  =)

The problem with allowing the segfault to stay is that it
destroys security in terms of protecting the interpreter,
which I am trying to deal with.  So leaving random ways to
crash the interpreter is currently a no-no for me.  I will
see if I can come up with another way to fix this issue.

--

Comment By: Armin Rigo (arigo)
Date: 2006-06-23 13:05

Message:
Logged In: YES 
user_id=4771

I'd have answer "good idea, go ahead", if it were not for
what I found out a few days ago, which is that:

* you already checked yourself a Py_EnterRecursiveCall() into
PyObject_Call() -- that was in r46806 (I guess you forgot)

* I got a case of Python hanging on me in an infinite busy
loop, which turned out to be caused by this (!)

So I reverted r46806 in r47601, added a test (see log for an
explanation), and moved the PyEnter_RecursiveCall()
elsewhere, where it still catches the originally intended
case, but where it will probably not catch the cases of the
present tracker any more.  Not sure what to do about it.  I'd
suggest to be extra careful here; better some extremely
obscure and ad-hoc ways to provoke a segfault, rather than
busy-loop hangs in previously working programs...

---

[ python-Bugs-1303614 ] Bypassing __dict__ readonlyness

[SourceForge.net]

Bugs item #1303614, was opened at 2005-09-24 16:40
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Armin Rigo (arigo)
Summary: Bypassing __dict__ readonlyness

Initial Comment:
The __dict__ attribute of some objects is read-only,
e.g. for type objects.  However, there is a generic
way to still access and modify it (without hacking with
gc.get_referrents(), that is).  This can lead to
obscure crashes.  Attached is an example that shows
a potential "problem" involving putting strange keys
in the __dict__ of a type.

This is probably very minor anyway.  If we wanted to
fix this, we would need a __dict__ descriptor that
looks more cleverly at the object to which it is
applied.

BTW the first person who understand why the attached
program crashes gets a free coffee.

--

>Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 10:45

Message:
Logged In: YES 
user_id=357491

For the deldict.py crasher, if you look at the traceback
there is no good place to do a check that tp_dict is sane
except in type_module() or PyDict_GetItem().  Now adding the
NULL check in type_module() will fix this specific problem,
but that seems like an ad-hoc patch.

Why don't we check for NULL in PyDict_GetItem() and return
NULL just like the PyDict_Check() test?  I am sure the
answer is "performance", but this is not PyDict_GETITEM()and
thus already is not the performance-critical version anyway.
 So why shouldn't we check for NULL there and possibly catch
other errors?

--

Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 10:41

Message:
Logged In: YES 
user_id=357491

Simple patch for the loosing_dict_ref.py crasher is
attached.  Just checked for possible NULL values in what is
needed by _Py_ForgetReference().  Let me know what you
think, Armin.

--

Comment By: Michael Hudson (mwh)
Date: 2005-12-14 07:36

Message:
Logged In: YES 
user_id=6656

Yikes!

--

Comment By: Armin Rigo (arigo)
Date: 2005-12-14 07:32

Message:
Logged In: YES 
user_id=4771

A proposed fix for the later crash: the __dict__ descriptor of user-defined 
classes should verify if there is another __dict__ descriptor along the solid 
path of the type (i.e. following "tp_base" pointers).  If so, it should 
delegate to it.

--

Comment By: Armin Rigo (arigo)
Date: 2005-12-14 06:49

Message:
Logged In: YES 
user_id=4771

Uh oh.  There is a much simpler crash.  The technique outlined in deldict.py 
can be used to rebind or even delete the __dict__ attribute of instances where 
it should normally not be allowed.

--

Comment By: Armin Rigo (arigo)
Date: 2005-09-25 01:55

Message:
Logged In: YES 
user_id=4771

The bug is related to code like PyObject_GenericGetAttribute and _PyType_Lookup 
which are not careful about the reference counters of the objects they operate 
on.  This allows a much simpler crash (test67.py): the __dict__ of an object 
can be decrefed away while lookdict() is looking at it.  This has a simple fix 
-- drop some amount of Py_INCREF/Py_DECREF in core routines like 
PyObject_GenericGetAttr.  We probably need to measure if it has a performance 
impact, though.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1514540 ] String Methods 2.3.6.1 not in TOC

[SourceForge.net]

Bugs item #1514540, was opened at 2006-06-29 14:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514540&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Terry J. Reedy (tjreedy)
Assigned to: Nobody/Anonymous (nobody)
Summary: String Methods 2.3.6.1 not in TOC

Initial Comment:
Quoting from c.l.p thread Python Docs Bug:
"One long-standing irritation I have with the table 
of contents for the Python Library Reference 
, is that 
there is one very important section, "String Methods" 
, 
which does not appear there. That's because it is 
section 2.3.6.1, and the table of contents 
only goes to 3 levels."

I am third to agree.  To not change rule, perhaps 
this section could be lifted to third level.  It 
really is one that people need to refer back to.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514540&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1513646 ] os.access reports incorrect write permissions in Windows

[SourceForge.net]

Bugs item #1513646, was opened at 2006-06-28 00:01
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: Yi S. Ding (yi_ding)
>Assigned to: Martin v. Löwis (loewis)
Summary: os.access reports incorrect write permissions in Windows

Initial Comment:
Platform: Python 2.5b1 Windows XP

Bug:
os.access will report that a user doesn't have write
permissions to a file or directory when the user
actually does.

Reproducibility: always

This is being run on an administrator account.
>>> import os
>>> os.access("C:\\", os.W_OK)
False
>>> os.access("C:\\test.txt", os.W_OK)
False

I have also checked that Python can indeed write to the
file.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-28 07:28

Message:
Logged In: YES 
user_id=33168

Does this problem only occur with 2.5 or is it also present
in 2.4?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1511964 ] Can't use sockets in 2.5b1

[SourceForge.net]

Bugs item #1511964, was opened at 2006-06-25 01:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511964&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Bryan O'Sullivan (bos)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't use sockets in 2.5b1

Initial Comment:
I'm testing Mercurial with Python 2.5b1, and I am getting severe badness in the 
socket module, complaining that _socket.socket doesn't have a recv_into method.

+  File "/tmp/hgtests.u_b_G-/install/lib/python/mercurial/httprangereader.py", 
line 24, in read
+f = urllib2.urlopen(req)
+  File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 121, in 
urlopen
+return _opener.open(url, data)
+  File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 374, in open
+response = self._open(req, data)
+  File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 392, in 
_open+'_open', req)
+  File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 353, in 
_call_chain
+result = func(*args)
+  File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 1099, in 
http_open
+return self.do_open(httplib.HTTPConnection, req)
+  File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 1071, in 
do_open
+h.request(req.get_method(), req.get_selector(), req.data, headers)
+  File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 862, in 
request
+self._send_request(method, url, body, headers)
+  File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 885, in 
_send_request
+self.endheaders()
+  File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 856, in 
endheaders
+self._send_output()
+  File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 728, in 
_send_output
+self.send(msg)
+  File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 695, in send
+self.connect()
+  File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 666, in 
connect
+self.sock = socket.socket(af, socktype, proto)
+  File "/export/home/bos/src/py25/lib/python2.5/socket.py", line 154, in 
__init__
+self.recv_into = self._sock.recv_into
+AttributeError: '_socket.socket' object has no attribute 'recv_into'


--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-06-29 20:46

Message:
Logged In: YES 
user_id=21627

Also, please report what operating system this is on.

--

Comment By: Armin Rigo (arigo)
Date: 2006-06-25 11:38

Message:
Logged In: YES 
user_id=4771

This looks like a broken install.  The socket objects
do have a recv_into() method in socketmodule.c.  Try "make
clean; make".  If it does not help, check where the _socket
module comes from with:

python2.5
>>> import _socket
>>> print _socket.__file__

and make sure that this file is among the ones you just
recompiled.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511964&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1512604 ] Install on Windows Vista locks up

[SourceForge.net]

Bugs item #1512604, was opened at 2006-06-26 13:15
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512604&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Lucas (michael_lucas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install on Windows Vista locks up

Initial Comment:
I have had problems trying to install this version on 
Vista. When the install gets to the verifying disk 
space requirements the system locks up. It does not go 
any further. I have to cancel the instalation of 
python. The only way I have got around this is to 
install an older version of python (version 2.3.5) 
this version does work, but there are newer versions 
that I want to work with on my system. If anyone has a 
work around for this please contact me at 
[EMAIL PROTECTED]

--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-06-29 20:48

Message:
Logged In: YES 
user_id=21627

I can confirm the problem, but I doubt I can do much about it.

In fact, I believe this is a bug in Vista/Windows Installer
4.0.  The installer GUI waits for the CostingComplete
property to be set, but this never happens.

If you are a beta tester, please make a bug report to Microsoft.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512604&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1508010 ] msvccompiler.py using VC6 with Python 2.5a2

[SourceForge.net]

Bugs item #1508010, was opened at 2006-06-18 09:11
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508010&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: Jimmy Retzlaff (jretz)
>Assigned to: Martin v. Löwis (loewis)
Summary: msvccompiler.py using VC6 with Python 2.5a2

Initial Comment:
The change in revision 42515 checks if MSSdk is
defined, and if so it will "Assume that the SDK set up
everything alright." The problem is that the SDK may be
set up for a different version of cl.exe than is
expected. In my case I have VC6 and VC7.1 installed and
the SDK is set up for VC6. When building extensions for
Python 2.5a2, distutils tries to use VC6 in my case.

--

Comment By: Jimmy Retzlaff (jretz)
Date: 2006-06-25 01:01

Message:
Logged In: YES 
user_id=101588

There is an option when installing VC (or at least there
used to be, I haven't checked lately) to set the environment
variables to take effect system wide. This is useful in that
the build environment is always available at any command
line (and they are also set when I build from my editor
which is not VS). I've left mine pointed at VC6 as I
typically do standalone DLLs using VC6 so they are easier to
redistribute. Distutils has always selected the right
version so it hasn't been an issue for me when working on
Python things before.

The issue wouldn't be as difficult if the resulting behavior
were more obvious. Unfortunately the initial errors in my
case were syntax errors arising from macro definitions that
changed between VC6 and VC7.1. Most of the time I spent
updating py2exe to work with 2.5 was spent on diagnosing
this. It wasn’t helped by the fact that I had a blind spot
regarding the compiler version. I use a batch file to build
py2exe for 2.3, then 2.4, and finally 2.5. Since 2.3 and 2.4
were building fine I didn’t even consider the idea of the
wrong compiler version being used for quite a while.

For now I just do "set MSSDK=" before building and then
everything works just fine.


--

Comment By: Martin v. Löwis (loewis)
Date: 2006-06-24 12:30

Message:
Logged In: YES 
user_id=21627

I don't understand the problem. MSSdk gets defined by
opening a specific SDK build environment. Just don't open
that build environment, but open a regular cmd.exe window,
and it should work fine.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508010&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1513646 ] os.access reports incorrect write permissions in Windows

[SourceForge.net]

Bugs item #1513646, was opened at 2006-06-27 15:01
Message generated for change (Comment added) made by yi_ding
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Yi S. Ding (yi_ding)
Assigned to: Martin v. Löwis (loewis)
Summary: os.access reports incorrect write permissions in Windows

Initial Comment:
Platform: Python 2.5b1 Windows XP

Bug:
os.access will report that a user doesn't have write
permissions to a file or directory when the user
actually does.

Reproducibility: always

This is being run on an administrator account.
>>> import os
>>> os.access("C:\\", os.W_OK)
False
>>> os.access("C:\\test.txt", os.W_OK)
False

I have also checked that Python can indeed write to the
file.

--

>Comment By: Yi S. Ding (yi_ding)
Date: 2006-06-29 12:56

Message:
Logged In: YES 
user_id=1081617

Yeah, it's only 2.5, and only 2.5b1.  Basically, there's a
double ampersand used instead of a single ampersand in
posixmodule.c.  I've attached the patch.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-27 22:28

Message:
Logged In: YES 
user_id=33168

Does this problem only occur with 2.5 or is it also present
in 2.4?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1510984 ] 2.5b1 windows won't install or admit failure

[SourceForge.net]

Bugs item #1510984, was opened at 2006-06-22 18:53
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.5b1 windows won't install or admit failure

Initial Comment:
I downloaded the Windows 2.5b1, and then tried to 
install following all defaults.

I had previously installed 2.5a2, and it is possible 
that I switched between "install for all users" and 
"install just for me".

The install offered me a finish button, and no protest 
when I clicked it -- but after that, the shortcuts did 
not start python (nor did they protest; they just went 
into never neverland).  Starting python at the command 
line did work.

Reinstall with a repair did not fix anything.

Uninstall, then uninstall 2.5a, then install on a 
"clean" system did work.

--

>Comment By: Jim Jewett (jimjjewett)
Date: 2006-06-29 16:21

Message:
Logged In: YES 
user_id=764593

I can no longer locate the alpha installers, but I'll see 
if I can reproduce it with the beta installer plus a 2.4 
version.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-06-29 14:59

Message:
Logged In: YES 
user_id=21627

I could not reproduce the problem. Can you please try to
reproduce it, installing things in the order you did? Please
provide all details, such as sequence of MSI invocations,
options selected, reboots/logouts performed, etc.

--

Comment By: Jim Jewett (jimjjewett)
Date: 2006-06-27 11:39

Message:
Logged In: YES 
user_id=764593

All versions are binary downloads for windows, from 
python.org

I have a 2.4, which seems not to be relevant.

I don't remember whether I had installed 2.5a1, though I 
think so.  If I had, it was successfully overwritten by 
2.5a2.

I had definately installed 2.5a2.

The problem came when I attempted to install 2.5b1 on top 
of 2.5a2.


--

Comment By: Martin v. Löwis (loewis)
Date: 2006-06-24 06:28

Message:
Logged In: YES 
user_id=21627

Can you please give a precise reference to what you've
downloaded?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1303614 ] Bypassing __dict__ readonlyness

[SourceForge.net]

Bugs item #1303614, was opened at 2005-09-24 23:40
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Armin Rigo (arigo)
Summary: Bypassing __dict__ readonlyness

Initial Comment:
The __dict__ attribute of some objects is read-only,
e.g. for type objects.  However, there is a generic
way to still access and modify it (without hacking with
gc.get_referrents(), that is).  This can lead to
obscure crashes.  Attached is an example that shows
a potential "problem" involving putting strange keys
in the __dict__ of a type.

This is probably very minor anyway.  If we wanted to
fix this, we would need a __dict__ descriptor that
looks more cleverly at the object to which it is
applied.

BTW the first person who understand why the attached
program crashes gets a free coffee.

--

>Comment By: Armin Rigo (arigo)
Date: 2006-06-29 21:19

Message:
Logged In: YES 
user_id=4771

Brett: I think you're approaching the problem from the wrong
angle.  The problem is being allowed to freely tamper with
the dict stored in objects.  Getting NULL errors here and
there is only a symptom.  As I explain, the '__dict__'
descriptor object needs to do some more checks, and to be
fully safe some Py_INCREF/Py_DECREF are needed in some
critical places.

--

Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 17:45

Message:
Logged In: YES 
user_id=357491

For the deldict.py crasher, if you look at the traceback
there is no good place to do a check that tp_dict is sane
except in type_module() or PyDict_GetItem().  Now adding the
NULL check in type_module() will fix this specific problem,
but that seems like an ad-hoc patch.

Why don't we check for NULL in PyDict_GetItem() and return
NULL just like the PyDict_Check() test?  I am sure the
answer is "performance", but this is not PyDict_GETITEM()and
thus already is not the performance-critical version anyway.
 So why shouldn't we check for NULL there and possibly catch
other errors?

--

Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 17:41

Message:
Logged In: YES 
user_id=357491

Simple patch for the loosing_dict_ref.py crasher is
attached.  Just checked for possible NULL values in what is
needed by _Py_ForgetReference().  Let me know what you
think, Armin.

--

Comment By: Michael Hudson (mwh)
Date: 2005-12-14 15:36

Message:
Logged In: YES 
user_id=6656

Yikes!

--

Comment By: Armin Rigo (arigo)
Date: 2005-12-14 15:32

Message:
Logged In: YES 
user_id=4771

A proposed fix for the later crash: the __dict__ descriptor of user-defined 
classes should verify if there is another __dict__ descriptor along the solid 
path of the type (i.e. following "tp_base" pointers).  If so, it should 
delegate to it.

--

Comment By: Armin Rigo (arigo)
Date: 2005-12-14 14:49

Message:
Logged In: YES 
user_id=4771

Uh oh.  There is a much simpler crash.  The technique outlined in deldict.py 
can be used to rebind or even delete the __dict__ attribute of instances where 
it should normally not be allowed.

--

Comment By: Armin Rigo (arigo)
Date: 2005-09-25 08:55

Message:
Logged In: YES 
user_id=4771

The bug is related to code like PyObject_GenericGetAttribute and _PyType_Lookup 
which are not careful about the reference counters of the objects they operate 
on.  This allows a much simpler crash (test67.py): the __dict__ of an object 
can be decrefed away while lookdict() is looking at it.  This has a simple fix 
-- drop some amount of Py_INCREF/Py_DECREF in core routines like 
PyObject_GenericGetAttr.  We probably need to measure if it has a performance 
impact, though.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1514685 ] radians() doesn't work correctly

[SourceForge.net]

Bugs item #1514685, was opened at 2006-06-29 21:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514685&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lingl (gregorlingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: radians() doesn't work correctly

Initial Comment:
>>> from turtle import *
>>> left(90)
>>> heading()
90.0
>>> radians()
>>> heading()
90.0# should give pi/2, i.e. 1.5707... 
>>> forward(50) # turtle goes in direction 90 rad
# i.e. approx. 116.62 degrees
  

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514685&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1514685 ] radians() doesn't work correctly

[SourceForge.net]

Bugs item #1514685, was opened at 2006-06-29 21:27
Message generated for change (Settings changed) made by gregorlingl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514685&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: Lingl (gregorlingl)
>Assigned to: Martin v. Löwis (loewis)
Summary: radians() doesn't work correctly

Initial Comment:
>>> from turtle import *
>>> left(90)
>>> heading()
90.0
>>> radians()
>>> heading()
90.0# should give pi/2, i.e. 1.5707... 
>>> forward(50) # turtle goes in direction 90 rad
# i.e. approx. 116.62 degrees
  

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514685&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1513802 ] __del__: Type is cleared before instances

[SourceForge.net]

Bugs item #1513802, was opened at 2006-06-28 07:41
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513802&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Arun (arunarunarun)
Assigned to: Nobody/Anonymous (nobody)
Summary: __del__: Type is cleared before instances

Initial Comment:
[Python n00b alert]

I'm trying this little script, and I see an exception like:

Exception exceptions.AttributeError: "'NoneType' object
has no attribute 'refcount'" in  ignored

If I change the variable name 's1' to something like
's4', I don't see this exception. Also, if I manually
delete the object before the script ends, the exception
does not occur.

Seems that class Shape is destroyed before all it's
objects are destroyed. Is this acceptable?

--

>Comment By: Armin Rigo (arigo)
Date: 2006-06-29 21:29

Message:
Logged In: YES 
user_id=4771

It is not the type object that is cleared, it is the global
names of the module.  They are replaced with None when the
interpreter shuts down, which is why the expression
'Shape.refcount' find None under the name 'Shape'.  It's an
obscure leftover for historical reasons.  I'm not sure why
the problem somes bites and sometimes not.  A workaround is
to avoid reading globals from __del__() methods; e.g. use
self.__class__.refcount instead of Shape.refcount...

(This of course doesn't excuse the fact that this is a
long-standing bug.)

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513802&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1514693 ] circle doesn't work correctly after radians()

[SourceForge.net]

Bugs item #1514693, was opened at 2006-06-29 21:38
Message generated for change (Settings changed) made by gregorlingl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514693&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: Lingl (gregorlingl)
>Assigned to: Martin v. Löwis (loewis)
Summary: circle doesn't work correctly after radians()

Initial Comment:
>>> from turtle import *
>>> radians()
>>> circle(100,pi/2)  # turtle doesn't draw
>>> degrees()
>>> circle(100,90) # turtle draws again, but goes
   # in the wrong direction

You must see it.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514693&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1514703 ] setup in Pen.__init__()

[SourceForge.net]

Bugs item #1514703, was opened at 2006-06-29 21:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514703&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lingl (gregorlingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup in Pen.__init__()

Initial Comment:
Each time a Pen is constructed, the graphics
window is resized and recenter (if position or
size was changed before by the user).

I think a call of a window-oriented function
doesn't belong in the Pen-cunstructor.

Must somehow be called separately.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514703&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1514725 ] turtle.py: setup() call in Pen.__init__()

[SourceForge.net]

Bugs item #1514725, was opened at 2006-06-29 22:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514725&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lingl (gregorlingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: turtle.py: setup() call in Pen.__init__()

Initial Comment:
Each time a Pen is constructed, the graphcis window
gets resized and recenter (restored to ist's initial state)
if the user had changed that state.

I think a window-oriented function call doesn't
belong into the Pen-constructor

Must be called somewhere else


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514725&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1514725 ] turtle.py: setup() call in Pen.__init__()

[SourceForge.net]

Bugs item #1514725, was opened at 2006-06-29 22:14
Message generated for change (Settings changed) made by gregorlingl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514725&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
>Resolution: Duplicate
>Priority: 1
Submitted By: Lingl (gregorlingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: turtle.py: setup() call in Pen.__init__()

Initial Comment:
Each time a Pen is constructed, the graphcis window
gets resized and recenter (restored to ist's initial state)
if the user had changed that state.

I think a window-oriented function call doesn't
belong into the Pen-constructor

Must be called somewhere else


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514725&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1514730 ] turtle.py docs out of date

[SourceForge.net]

Bugs item #1514730, was opened at 2006-06-29 22:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514730&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lingl (gregorlingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: turtle.py docs out of date

Initial Comment:
Python Docs / Global Module Index / turtle(Tk)
has simply not been updated to Vern Ceders
revision and is way out of date

many functions like position(), heading(),
setheading(), begin_fill(), end_fill()
and more are not mentioned.

Also class Turte is not mentioned



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514730&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1514730 ] turtle.py docs out of date

[SourceForge.net]

Bugs item #1514730, was opened at 2006-06-29 22:24
Message generated for change (Settings changed) made by gregorlingl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514730&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Library
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lingl (gregorlingl)
>Assigned to: Martin v. Löwis (loewis)
Summary: turtle.py docs out of date

Initial Comment:
Python Docs / Global Module Index / turtle(Tk)
has simply not been updated to Vern Ceders
revision and is way out of date

many functions like position(), heading(),
setheading(), begin_fill(), end_fill()
and more are not mentioned.

Also class Turte is not mentioned



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514730&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1514734 ] site.py can break the location of the python library

[SourceForge.net]

Bugs item #1514734, was opened at 2006-06-29 17:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514734&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Meyer (mwm)
Assigned to: Nobody/Anonymous (nobody)
Summary: site.py can break the location of the python library

Initial Comment:
Given a sufficiently bizarre(*) set of symlinks on a posix system,
site.py will change the directories in sys.path in such a way that
they will no longer refer to valid directories. In the
following. os.path refers to the posixpath file.

The root of the problem is that site.makepath invokes os.path.abspath
on it's paths, which calls os.path.normpath. os.path.normpath assumes
that changing "foo/bar/../baz" to "foo/baz". This isn't true if bar is
a symlink to somewhere where ../baz exists, but foo/baz doesn't.

The simple fix is to make site.py call os.path.realpath on the path
before calling os.path.abspath. This may not be the best fix. Possibly
os.path.abspath should call realpath instead of normpath. Maybe
normpath should check for symlinks and deal with them, effectively
making it an alias for realpath. However, those both change the
behavior of library functions, which may not be desirable.

Here's a patch for site.py that fixes the problem:

--- site.py Thu Jun 29 18:14:08 2006
+++ site-fixed.py   Thu Jun 29 18:13:57 2006
@@ -63,7 +63,7 @@
 
 
 def makepath(*paths):
-dir = os.path.abspath(os.path.join(*paths))
+dir = os.path.abspath(os.path.realpath(os.path.join(*paths)))
 return dir, os.path.normcase(dir)
 
 def abs__file__():


*) Python is invoked as /cm/tools/bin/python. That's a symlink to
../../paks/Python-2.4.3/bin/python, and the library is in
../../paks/Python-2.4.3/lib. /cm/tools/bin is a symlink to
/cm/tools/apps/bin. /cm/tools is a symlink to
/opt/local/cmtools. Changing that relative symlink to an absolute one
fixes the problem, but violates installation guidelines. Trying to
recreate this without all three symlnks in place inevitably fails to
reproduce the problem. And no, I didn't create this. I just diagnosed
it.



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514734&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1512695 ] cPickle.loads() seg.faults when interrupted with keyboard

[SourceForge.net]

Bugs item #1512695, was opened at 2006-06-26 13:05
Message generated for change (Comment added) made by illume
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Faik Uygur (faik)
Assigned to: Neal Norwitz (nnorwitz)
Summary: cPickle.loads() seg.faults when interrupted with keyboard

Initial Comment:
cPickle.loads() gives segmentation fault when 
interrupted with keyboard (CTRL+C). Attached python 
script tested with python version 2.4.3 and 2.5b1.


--

Comment By: Rene Dudfield (illume)
Date: 2006-06-30 00:59

Message:
Logged In: YES 
user_id=2042

Py_INCREF should check for NULL with an assert.

All uses of va_arg should be checked to see if they return
NULL... and handle error codes!

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-28 06:39

Message:
Logged In: YES 
user_id=33168

I'm impatient and think this fixes the problem.  So I'm
closing this report.  Please re-open if the patch didn't fix
your problem.  (I checked in something slightly different
that the patch attached.)

Committed revision 47139.
Committed revision 47140. (2.4)

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-28 06:09

Message:
Logged In: YES 
user_id=33168

Faik, can you see if the attached patch fixes this problem.
 I believe it should.  I can't reproduce the problem with
the patch.

--

Comment By: Faik Uygur (faik)
Date: 2006-06-27 08:12

Message:
Logged In: YES 
user_id=1541018

Back trace:

#0  PyTuple_Pack (n=0x3) at Objects/tupleobject.c:149
#1  0xa7b92024 in Instance_New (cls=0xa7bba064, 
args=0xa7c1a43c) 
at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:3637
#2  0xa7b93798 in load (self=0xa7c0a80c) 
at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:4389
#3  0xa7b953c8 in cpm_loads (self=0x0, args=0x0) 
at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:5481
#4  0xa7ec4d97 in PyCFunction_Call (func=0xa7bc9b0c, 
arg=0xa7bc9cec, kw=0x0) at Objects/methodobject.c:108
#5  0xa7efe3d8 in PyEval_EvalFrame (f=0x807e4bc) at 
Python/ceval.c:3563
#6  0xa7f00bb3 in PyEval_EvalCodeEx (co=0xa7bbda60, 
globals=0x0, locals=0x0, args=0xa7bbda60, argcount=0x0, 
kws=0x0, kwcount=0x0, defs=0x0, defcount=0x0, 
closure=0x0) at Python/ceval.c:2736
#7  0xa7f00e35 in PyEval_EvalCode (co=0x0, globals=0x0, 
locals=0x0) at Python/ceval.c:484
#8  0xa7f1ba98 in run_node (n=0xa7bfbe18, filename=0x0, 
globals=0x0, locals=0x0, flags=0x0) at 
Python/pythonrun.c:1265
#9  0xa7f1ce28 in PyRun_SimpleFileExFlags (fp=0x804a008, 
filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, 
flags=0xaf9aafe8) at Python/pythonrun.c:860
#10 0xa7f1d9aa in PyRun_AnyFileExFlags (fp=0x804a008, 
filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, 
flags=0xaf9aafe8) at Python/pythonrun.c:664
#11 0xa7f238d0 in Py_Main (argc=0x1, argv=0xaf9aafe8) at 
Modules/main.c:493
#12 0x0804867a in main (argc=0x0, argv=0x0) at 
Modules/python.c:23


--

Comment By: Faik Uygur (faik)
Date: 2006-06-26 14:08

Message:
Logged In: YES 
user_id=1541018

I tracked the seg. fault. It seg. faults in method 
PyTuple_Pack(). When python receives the keyboard 
interrupt:
o = va_arg(vargs, PyObject *);
Py_INCREF(o);

va_arg returns NULL, and Py_INCREF causes the seg.fault.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1303614 ] Bypassing __dict__ readonlyness

[SourceForge.net]

Bugs item #1303614, was opened at 2005-09-24 16:40
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Armin Rigo (arigo)
Summary: Bypassing __dict__ readonlyness

Initial Comment:
The __dict__ attribute of some objects is read-only,
e.g. for type objects.  However, there is a generic
way to still access and modify it (without hacking with
gc.get_referrents(), that is).  This can lead to
obscure crashes.  Attached is an example that shows
a potential "problem" involving putting strange keys
in the __dict__ of a type.

This is probably very minor anyway.  If we wanted to
fix this, we would need a __dict__ descriptor that
looks more cleverly at the object to which it is
applied.

BTW the first person who understand why the attached
program crashes gets a free coffee.

--

>Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 18:14

Message:
Logged In: YES 
user_id=357491

OK, then I am going to need a little guidance to dive into
this more since this is going into some murky waters for me.  =)

For the normal, non-evil case of an empty Python class
(``class Foo(object): pass``), I would think that accessing
__dict__ would fall through to the tp_getset for object, and
then fall to the same slot for type.  Now that is obviously
not happening since you get a straight dict back for that
attribute access and not a dict proxy as would be suggested
based on my logic listed above.

So, my question is, where is the code that handles fetching
Foo().__dict__?  And if you have an inkling of where I
should be looking in terms of possible refcounting additions
that would be great as well.

--

Comment By: Armin Rigo (arigo)
Date: 2006-06-29 14:19

Message:
Logged In: YES 
user_id=4771

Brett: I think you're approaching the problem from the wrong
angle.  The problem is being allowed to freely tamper with
the dict stored in objects.  Getting NULL errors here and
there is only a symptom.  As I explain, the '__dict__'
descriptor object needs to do some more checks, and to be
fully safe some Py_INCREF/Py_DECREF are needed in some
critical places.

--

Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 10:45

Message:
Logged In: YES 
user_id=357491

For the deldict.py crasher, if you look at the traceback
there is no good place to do a check that tp_dict is sane
except in type_module() or PyDict_GetItem().  Now adding the
NULL check in type_module() will fix this specific problem,
but that seems like an ad-hoc patch.

Why don't we check for NULL in PyDict_GetItem() and return
NULL just like the PyDict_Check() test?  I am sure the
answer is "performance", but this is not PyDict_GETITEM()and
thus already is not the performance-critical version anyway.
 So why shouldn't we check for NULL there and possibly catch
other errors?

--

Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 10:41

Message:
Logged In: YES 
user_id=357491

Simple patch for the loosing_dict_ref.py crasher is
attached.  Just checked for possible NULL values in what is
needed by _Py_ForgetReference().  Let me know what you
think, Armin.

--

Comment By: Michael Hudson (mwh)
Date: 2005-12-14 07:36

Message:
Logged In: YES 
user_id=6656

Yikes!

--

Comment By: Armin Rigo (arigo)
Date: 2005-12-14 07:32

Message:
Logged In: YES 
user_id=4771

A proposed fix for the later crash: the __dict__ descriptor of user-defined 
classes should verify if there is another __dict__ descriptor along the solid 
path of the type (i.e. following "tp_base" pointers).  If so, it should 
delegate to it.

--

Comment By: Armin Rigo (arigo)
Date: 2005-12-14 06:49

Message:
Logged In: YES 
user_id=4771

Uh oh.  There is a much simpler crash.  The technique outlined in deldict.py 
can be used to rebind or even delete the __dict__ attribute of instances where 
it should normally not be allowed.

--

Comment By: Armin Rigo (arigo)
Date: 2005-09-25 01:55

Message:
Logged In: YES 
user_id=4771

The bug is related to code like PyObject_GenericGetAttribute and _PyType_Lookup 
which are not careful about the reference counters of the objects they op

[ python-Bugs-1512695 ] cPickle.loads() seg.faults when interrupted with keyboard

[SourceForge.net]

Bugs item #1512695, was opened at 2006-06-26 06:05
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Faik Uygur (faik)
Assigned to: Neal Norwitz (nnorwitz)
Summary: cPickle.loads() seg.faults when interrupted with keyboard

Initial Comment:
cPickle.loads() gives segmentation fault when 
interrupted with keyboard (CTRL+C). Attached python 
script tested with python version 2.4.3 and 2.5b1.


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-29 18:19

Message:
Logged In: YES 
user_id=33168

Rene can you produce a patch to address any places you
believe there are problems?  If you can't produce a patch,
at least a bug report with specific areas that are problems
would be helpful.  Thanks.

--

Comment By: Rene Dudfield (illume)
Date: 2006-06-29 17:59

Message:
Logged In: YES 
user_id=2042

Py_INCREF should check for NULL with an assert.

All uses of va_arg should be checked to see if they return
NULL... and handle error codes!

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-27 23:39

Message:
Logged In: YES 
user_id=33168

I'm impatient and think this fixes the problem.  So I'm
closing this report.  Please re-open if the patch didn't fix
your problem.  (I checked in something slightly different
that the patch attached.)

Committed revision 47139.
Committed revision 47140. (2.4)

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-27 23:09

Message:
Logged In: YES 
user_id=33168

Faik, can you see if the attached patch fixes this problem.
 I believe it should.  I can't reproduce the problem with
the patch.

--

Comment By: Faik Uygur (faik)
Date: 2006-06-27 01:12

Message:
Logged In: YES 
user_id=1541018

Back trace:

#0  PyTuple_Pack (n=0x3) at Objects/tupleobject.c:149
#1  0xa7b92024 in Instance_New (cls=0xa7bba064, 
args=0xa7c1a43c) 
at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:3637
#2  0xa7b93798 in load (self=0xa7c0a80c) 
at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:4389
#3  0xa7b953c8 in cpm_loads (self=0x0, args=0x0) 
at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:5481
#4  0xa7ec4d97 in PyCFunction_Call (func=0xa7bc9b0c, 
arg=0xa7bc9cec, kw=0x0) at Objects/methodobject.c:108
#5  0xa7efe3d8 in PyEval_EvalFrame (f=0x807e4bc) at 
Python/ceval.c:3563
#6  0xa7f00bb3 in PyEval_EvalCodeEx (co=0xa7bbda60, 
globals=0x0, locals=0x0, args=0xa7bbda60, argcount=0x0, 
kws=0x0, kwcount=0x0, defs=0x0, defcount=0x0, 
closure=0x0) at Python/ceval.c:2736
#7  0xa7f00e35 in PyEval_EvalCode (co=0x0, globals=0x0, 
locals=0x0) at Python/ceval.c:484
#8  0xa7f1ba98 in run_node (n=0xa7bfbe18, filename=0x0, 
globals=0x0, locals=0x0, flags=0x0) at 
Python/pythonrun.c:1265
#9  0xa7f1ce28 in PyRun_SimpleFileExFlags (fp=0x804a008, 
filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, 
flags=0xaf9aafe8) at Python/pythonrun.c:860
#10 0xa7f1d9aa in PyRun_AnyFileExFlags (fp=0x804a008, 
filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, 
flags=0xaf9aafe8) at Python/pythonrun.c:664
#11 0xa7f238d0 in Py_Main (argc=0x1, argv=0xaf9aafe8) at 
Modules/main.c:493
#12 0x0804867a in main (argc=0x0, argv=0x0) at 
Modules/python.c:23


--

Comment By: Faik Uygur (faik)
Date: 2006-06-26 07:08

Message:
Logged In: YES 
user_id=1541018

I tracked the seg. fault. It seg. faults in method 
PyTuple_Pack(). When python receives the keyboard 
interrupt:
o = va_arg(vargs, PyObject *);
Py_INCREF(o);

va_arg returns NULL, and Py_INCREF causes the seg.fault.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1296433 ] expat crash python

[SourceForge.net]

Bugs item #1296433, was opened at 2005-09-20 07:10
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Mike Rozhnov (rozhnov)
Assigned to: Nobody/Anonymous (nobody)
Summary: expat crash python

Initial Comment:
This simple script crash python.
Parsing of commented xml string work good.
(i.e. raised exception not crash python)
Buffer overflow during convertion to unicode?

Tested on Win XP and linux with kernel 2.4 with same
results.

--

>Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 18:33

Message:
Logged In: YES 
user_id=357491

Still seems to be failing even with the Expat 2.0 upgrade in
HEAD.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-12 12:53

Message:
Logged In: YES 
user_id=33168

I had recently upgraded to expat 1.95.8, so I was hopeful. 
But it still crashed for me on linux.  

I did get a better stack trace which allowed me to come up
with a patch that solves the problem and passes all the
tests.  The patch seems a bit odd and I think there might be
another problem going on here.  It would be great if someone
more familiar with xmlparse could take a look at the patch
and figure out if it's right or not.

--

Comment By: Fredrik Lundh (effbot)
Date: 2005-11-12 03:05

Message:
Logged In: YES 
user_id=38376

Works for me under 2.3.2 (with expat 1.95.6) and 2.4.1 (with
expat 1.95.8).

Try upgrading your expat and see if the problem goes away.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-22 14:54

Message:
Logged In: YES 
user_id=33168

I can reproduce on Linux with current CVS and expat
1.95.5-2.  Note the size of the data only needs to be
greater than 1024.

xml = "%s" %
('a' * 1025)

I am not certain this problem is specific to Python.  It
might be down in expat only.  Need to investigate further.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1510984 ] 2.5b1 windows won't install or admit failure

[SourceForge.net]

Bugs item #1510984, was opened at 2006-06-23 00:53
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.5b1 windows won't install or admit failure

Initial Comment:
I downloaded the Windows 2.5b1, and then tried to 
install following all defaults.

I had previously installed 2.5a2, and it is possible 
that I switched between "install for all users" and 
"install just for me".

The install offered me a finish button, and no protest 
when I clicked it -- but after that, the shortcuts did 
not start python (nor did they protest; they just went 
into never neverland).  Starting python at the command 
line did work.

Reinstall with a repair did not fix anything.

Uninstall, then uninstall 2.5a, then install on a 
"clean" system did work.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-06-30 06:40

Message:
Logged In: YES 
user_id=21627

The alpha installers are at

http://www.python.org/ftp/python/2.5/prev/

--

Comment By: Jim Jewett (jimjjewett)
Date: 2006-06-29 22:21

Message:
Logged In: YES 
user_id=764593

I can no longer locate the alpha installers, but I'll see 
if I can reproduce it with the beta installer plus a 2.4 
version.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-06-29 20:59

Message:
Logged In: YES 
user_id=21627

I could not reproduce the problem. Can you please try to
reproduce it, installing things in the order you did? Please
provide all details, such as sequence of MSI invocations,
options selected, reboots/logouts performed, etc.

--

Comment By: Jim Jewett (jimjjewett)
Date: 2006-06-27 17:39

Message:
Logged In: YES 
user_id=764593

All versions are binary downloads for windows, from 
python.org

I have a 2.4, which seems not to be relevant.

I don't remember whether I had installed 2.5a1, though I 
think so.  If I had, it was successfully overwritten by 
2.5a2.

I had definately installed 2.5a2.

The problem came when I attempted to install 2.5b1 on top 
of 2.5a2.


--

Comment By: Martin v. Löwis (loewis)
Date: 2006-06-24 12:28

Message:
Logged In: YES 
user_id=21627

Can you please give a precise reference to what you've
downloaded?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com