[ python-Bugs-1387483 ] sys.path[0] when executed thru a symbolic link
Bugs item #1387483, was opened at 2005-12-21 18:23
Message generated for change (Comment added) made by kowaltowski
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387483&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: Macintosh
Group: Python 2.4
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Tomasz Kowaltowski (kowaltowski)
Assigned to: Jack Jansen (jackjansen)
Summary: sys.path[0] when executed thru a symbolic link
Initial Comment:
Under certain conditions there is a difference between
Mac OS X and Linux (both 2.4.1) with regard to the
value of the variable sys.path[0] which should contain
the directory from which the script was called.
This difference appears when the script is called
through a symbolic link by a different user. See the
attached example. It should be executed once by the
owner of the TESTPATH directory:
~/TESTPATH/sub1/testpath.py
and
~/TESTPATH/sub2/testpath.py
In both cases, under Linux and Mac OS X, the result is:
/home/owner/TESTPATH/sub1
If a different user executes:
~owner/TESTPATH/sub1/testpath.py
and
~owner/TESTPATH/sub2/testpath.py
he gets the same results under Linux:
/home/owner/TESTPATH/sub1
but two different results under Mac OS:
/Users/owner/TESTPATH/sub1
and
/Users/owner/TESTPATH/sub2
This seems like a minor problem but it breaks my
application because sys.path[0] is the first place to
look for imports!
I am not sure whether this is a Python problem or
something to do with the Mac OS X. My Mac OS X version
is 10.4.3.
--
>Comment By: Tomasz Kowaltowski (kowaltowski)
Date: 2005-12-22 09:40
Message:
Logged In: YES
user_id=185428
(1) I think it is a problem because under Mac OS X the user
#2 sees "sub2" (and not "sub1"!) as the working directory,
which is where it is different from Linux.
(2) The problem persists even if all permissions are open.
(3) The implementation of "os.readlink" migh be the right
clue about the problem: when the user #2 executes
"os.readlink("/Users/owner/TESTPATH/sub2/testpath.py") the
answer under Mac OS X is:
OSError: [Errorno 13] Permission denied:
'/Users/owner/TESTPATH/sub2/testpath.py'
even though all permissions are open.
Under Linux I get the expected answer: "../sub1/testpath.py".
Obviously there is a problem under Mac OS X, and this matter
should be reopen.
--
Comment By: Jack Jansen (jackjansen)
Date: 2005-12-21 18:39
Message:
Logged In: YES
user_id=45365
I don't see this problem: both users see "sub1" as the working directory. Also
on 10.4.3.
My guess: there is some problem with the readlink() call that Python uses to
obtain the real pathname of the script (this is how it finds out sub2/
testpath.py is really sub1/testpath.py. Easy to test: fire up Python as user 2
and do os.readlink("/Users/owner/TESTPATH/sub2").
I wouldn't be surprised if it is some sort of permission problem (maybe /
Users/owner being mode rwx--x--x so the readlink can't traverse through
it?).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387483&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1387650 ] weird behavior when assigning locals() to a variable
Bugs item #1387650, was opened at 2005-12-22 00:04 Message generated for change (Comment added) made by sambayer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387650&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.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Samuel Bayer (sambayer) Assigned to: Nobody/Anonymous (nobody) Summary: weird behavior when assigning locals() to a variable Initial Comment: Tried this on Python 2.3.3, under Redhat Linux Enterprise 3, and on Python 2.3.5, under MacOS X 10.4.3. Don't have access to 2.4 anywhere, so I can't test it, but I took a look at the bug queue and can't find any reference to this problem. The following function yields a KeyError when run: def foo(): b = locals() c = 5 print b["c"] The following function does not: def foo(): b = locals() c = 5 locals() print b["c"] There's no typo there. After referencing locals() again, without updating the value of b, the printout works. Note that b and locals(), as I believe is intended, are identical: def foo(): b = locals() c = 5 print id(b) print b.has_key() print id(locals()) print b.has_key() yields, when run: >>> foo() 285984 False 285984 True This has GOT to be a bug. -- >Comment By: Samuel Bayer (sambayer) Date: 2005-12-22 13:24 Message: Logged In: YES user_id=40146 This morning, as I thought about it some more, I had some vain hope that the __getitem__ method of that particular dictionary could be updated to refresh the dictionary, but after trolling through the source a little, I see that it's really just a regular dictionary, and it doesn't know anything about where it came from. Would it be dangerous to add the current stack frame to the locals() dictionary as a value like __frame___? Perhaps that would screw up the garbage collection by adding a circular reference. In any case, the current documentation for locals() reads: "Update and return a dictionary representing the current local symbol table. Warning: The contents of this dictionary should not be modified; changes may not affect the values of local variables used by the interpreter." I'd say something like "Update and return a dictionary representing the current local symbol table. Warnings: The contents of this dictionary should not be modified; changes may not affect the values of local variables used by the interpreter. Also, this dictionary is not guaranteed to be synchronized with the actual local environment; if the local symbol table changes between the time you retrieve the value of locals() and the time you use it, you won't see the changes." -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-22 05:48 Message: Logged In: YES user_id=33168 If you have suggestions for how we can improve the doc, let us know. I'll close this bug report since you seem to agree it's not a bug. -- Comment By: Samuel Bayer (sambayer) Date: 2005-12-22 00:25 Message: Logged In: YES user_id=40146 OK, it doesn't got to be a bug. After staring at the documentation for locals(), I realize that locals() is only updated when it's called again. So it's not a bug, but it is a little odd. It's the only namespace-like object you can't reliably use as a format string argument. Consider the following: >>> b = globals() >>> c = 5 >>> print "%(c)d" % b This prints the expected value. Ditto this: >>> Class Foo: pass >>> a = Foo(); b = a.__dict__ >>> a.c = 5 >>> print "%(c)d" % b Only with locals(), inside a function, does this pattern fail. I imagine it would be expensive to make work, though. Never mind... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387650&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1388141 ] Minor error in md5 docs
Bugs item #1388141, was opened at 2005-12-22 15:56 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=1388141&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Minor error in md5 docs Initial Comment: In the Library Reference 15.2 md5 section, the new() and md5() functions are introduced with the text "md5 objects support the following methods:". These are module-level functions, not instance methods, so a better text would be "The md5 module provides the following functions:" Thanks, Kent -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388141&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1388141 ] Minor error in md5 docs
Bugs item #1388141, was opened at 2005-12-22 16:56 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388141&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: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Minor error in md5 docs Initial Comment: In the Library Reference 15.2 md5 section, the new() and md5() functions are introduced with the text "md5 objects support the following methods:". These are module-level functions, not instance methods, so a better text would be "The md5 module provides the following functions:" Thanks, Kent -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-22 17:15 Message: Logged In: YES user_id=1188172 Thanks, corrected in rev. 41787/41788. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388141&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1355842 ] Incorrect Decimal-float behavior for += and *=
Bugs item #1355842, was opened at 2005-11-13 08:17
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&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: Connelly (connelly)
Assigned to: Facundo Batista (facundobatista)
Summary: Incorrect Decimal-float behavior for += and *=
Initial Comment:
The += and *= operators have strange behavior when the
LHS is a Decimal and the RHS is a float (as of
2005-11-13 CVS decimal.py).
Example:
>>> d = Decimal('1.02')
>>> d += 2.1
>>> d
NotImplemented
A blatant violation of "Errors should never pass silently."
Also, a bad error description is produced for the *=
operator:
>>> d = Decimal('1.02')
>>> d *= 2.9
Traceback (most recent call last):
File "", line 1, in ?
TypeError: can't multiply sequence by non-int
--
>Comment By: Facundo Batista (facundobatista)
Date: 2005-12-22 14:10
Message:
Logged In: YES
user_id=752496
Regarding problem 1:
Nick also detected this behaviour, back in March
(http://mail.python.org/pipermail/python-dev/2005-March/051834.html),
in python-dev discussions about how integrate better the
Decimal behaviour into Python framework.
Even knowing this, Raymond Hettinger and I made a patch
(almost exactly the same), and corrected another behaviour.
Will this issue be resolved somewhen? Raymond said that this
problem is also present in sets.py and datetime objects
(http://mail.python.org/pipermail/python-dev/2005-March/051825.html),
and that should be addressed in a larger context than decimal.
As Neil Schemenauer proposed
(http://mail.python.org/pipermail/python-dev/2005-March/051829.html),
Decimal now returns NotImplemented instead of raise
TypeError, which should be the correct way to deal with
operation capabilities in the numbers.
And look at this:
>>> d
Decimal("1") # using decimal.py rev. 39328 from svn
>>> d + 1.2
Traceback (most recent call last):
File "", line 1, in ?
TypeError: unsupported operand type(s) for +: 'Decimal' and
'float'
>>> d += 1.2
>>> d
NotImplemented
>>>
Why this happens? Really don't know, it's beyond my actual
knowledge, I'll keep searching. But I'm not so sure that
this is a Decimal issue.
Regarding problem 2:
I'll fix that.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-22 02:52
Message:
Logged In: YES
user_id=33168
Facundo, can you look into this? Are you still working on
Decimal?
--
Comment By: Connelly (connelly)
Date: 2005-12-02 03:17
Message:
Logged In: YES
user_id=1039782
The += and *= operations also give the same strange behavior
when the LHS is a Decimal and the RHS is str or unicode:
>>> d = Decimal("1.0")
>>> d += "5"
>>> d
NotImplemented
>>> d = Decimal("1.0")
>>> d *= "1.0"
Traceback (most recent call last):
File "", line 1, in ?
TypeError: can't multiply sequence by non-int
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-14 01:43
Message:
Logged In: YES
user_id=33168
Hmmm. __add__ returns NotImplemented which works with
classic classes, but not new-style classes. I wonder if
NotImplementedError is supposed to be raised for new-style
classes.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1355842 ] Incorrect Decimal-float behavior for += and *=
Bugs item #1355842, was opened at 2005-11-13 12:17
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&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: Connelly (connelly)
Assigned to: Facundo Batista (facundobatista)
Summary: Incorrect Decimal-float behavior for += and *=
Initial Comment:
The += and *= operators have strange behavior when the
LHS is a Decimal and the RHS is a float (as of
2005-11-13 CVS decimal.py).
Example:
>>> d = Decimal('1.02')
>>> d += 2.1
>>> d
NotImplemented
A blatant violation of "Errors should never pass silently."
Also, a bad error description is produced for the *=
operator:
>>> d = Decimal('1.02')
>>> d *= 2.9
Traceback (most recent call last):
File "", line 1, in ?
TypeError: can't multiply sequence by non-int
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-12-22 22:31
Message:
Logged In: YES
user_id=38388
Hi Facundo,
the problem you are seeing seems to be in the way new-style
classes implement number coercion.
Apparently some part in the (not so new-style anymore)
coercion logic is masking an exception which then triggers
later during processing.
The NotImplemented singleton should never make it to the
interactive shell since it is normally only used internally
by the number coercion logic to signal "object method
doesn't handle mixed type operation".
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-12-22 18:10
Message:
Logged In: YES
user_id=752496
Regarding problem 1:
Nick also detected this behaviour, back in March
(http://mail.python.org/pipermail/python-dev/2005-March/051834.html),
in python-dev discussions about how integrate better the
Decimal behaviour into Python framework.
Even knowing this, Raymond Hettinger and I made a patch
(almost exactly the same), and corrected another behaviour.
Will this issue be resolved somewhen? Raymond said that this
problem is also present in sets.py and datetime objects
(http://mail.python.org/pipermail/python-dev/2005-March/051825.html),
and that should be addressed in a larger context than decimal.
As Neil Schemenauer proposed
(http://mail.python.org/pipermail/python-dev/2005-March/051829.html),
Decimal now returns NotImplemented instead of raise
TypeError, which should be the correct way to deal with
operation capabilities in the numbers.
And look at this:
>>> d
Decimal("1") # using decimal.py rev. 39328 from svn
>>> d + 1.2
Traceback (most recent call last):
File "", line 1, in ?
TypeError: unsupported operand type(s) for +: 'Decimal' and
'float'
>>> d += 1.2
>>> d
NotImplemented
>>>
Why this happens? Really don't know, it's beyond my actual
knowledge, I'll keep searching. But I'm not so sure that
this is a Decimal issue.
Regarding problem 2:
I'll fix that.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-22 06:52
Message:
Logged In: YES
user_id=33168
Facundo, can you look into this? Are you still working on
Decimal?
--
Comment By: Connelly (connelly)
Date: 2005-12-02 07:17
Message:
Logged In: YES
user_id=1039782
The += and *= operations also give the same strange behavior
when the LHS is a Decimal and the RHS is str or unicode:
>>> d = Decimal("1.0")
>>> d += "5"
>>> d
NotImplemented
>>> d = Decimal("1.0")
>>> d *= "1.0"
Traceback (most recent call last):
File "", line 1, in ?
TypeError: can't multiply sequence by non-int
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-14 05:43
Message:
Logged In: YES
user_id=33168
Hmmm. __add__ returns NotImplemented which works with
classic classes, but not new-style classes. I wonder if
NotImplementedError is supposed to be raised for new-style
classes.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1388489 ] bug in rstrip & lstrip
Bugs item #1388489, was opened at 2005-12-23 00:43
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=1388489&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Whitlark (jcdelta)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in rstrip & lstrip
Initial Comment:
quick detail:
Python 2.4.2 (#1, Dec 9 2005, 22:48:42)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> "net.tpl".rstrip('.tpl')
'ne'
>>> "foo.tpl".rstrip('.tpl')
'foo'
I ran the following code to test this:
26 - [EMAIL PROTECTED]: ~/pythonBugTest
0> cat testForRStripBug.py
#! /usr/bin/python
for word in
open('/opt/openoffice/share/dict/ooo/en_US.dic', 'r'):
word = word.split('/')[0]
testWord = (word + '.tpl').rstrip('.tpl')
if word != testWord:
print word, testWord
And came up with the attached file of incorrect
matches. Out of 62075 words in the en_US.dic, 6864 do
not match. Here is the frequency count of the last
letter of the origional word, the only pattern I could
discern so far:
0> ./freqCount.py < run1
{'p': 566, 'l': 2437, 't': 3861}
No other letters seem to be clipped. Why this should
be so, I have no idea. I would guess that the error
was in function do_xstrip in
python/trunk/Objects/stringobject.c, but C is not my
strong suit. I will be looking at it further when I
have time, but if anyone knows how to fix this, please
help.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388489&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1388489 ] bug in rstrip & lstrip
Bugs item #1388489, was opened at 2005-12-23 01:43
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388489&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Whitlark (jcdelta)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in rstrip & lstrip
Initial Comment:
quick detail:
Python 2.4.2 (#1, Dec 9 2005, 22:48:42)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> "net.tpl".rstrip('.tpl')
'ne'
>>> "foo.tpl".rstrip('.tpl')
'foo'
I ran the following code to test this:
26 - [EMAIL PROTECTED]: ~/pythonBugTest
0> cat testForRStripBug.py
#! /usr/bin/python
for word in
open('/opt/openoffice/share/dict/ooo/en_US.dic', 'r'):
word = word.split('/')[0]
testWord = (word + '.tpl').rstrip('.tpl')
if word != testWord:
print word, testWord
And came up with the attached file of incorrect
matches. Out of 62075 words in the en_US.dic, 6864 do
not match. Here is the frequency count of the last
letter of the origional word, the only pattern I could
discern so far:
0> ./freqCount.py < run1
{'p': 566, 'l': 2437, 't': 3861}
No other letters seem to be clipped. Why this should
be so, I have no idea. I would guess that the error
was in function do_xstrip in
python/trunk/Objects/stringobject.c, but C is not my
strong suit. I will be looking at it further when I
have time, but if anyone knows how to fix this, please
help.
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2005-12-23 02:23
Message:
Logged In: YES
user_id=89016
This is not a bug. The documentation
(http://docs.python.org/lib/string-methods.html) says that:
"The chars argument is a string specifying the set of
characters to be removed". i.e. "net.tpl".rstrip(".tpl")
strips every ".", "t", "p" and "l" character from the right
end of the string, *not* every occurence of the character
sequence ".tpl". This seems to be a frequent
misunderstanding, so if you can suggest improvements to the
docstring or the documentation, please do so.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1388489&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
