[ 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 (Tracker Item Submitted) made by Item Submitter 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: Open Resolution: None 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. -- 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-1387483 ] sys.path[0] when executed thru a symbolic link
Bugs item #1387483, was opened at 2005-12-21 21:23
Message generated for change (Comment added) made by jackjansen
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: Jack Jansen (jackjansen)
Date: 2005-12-21 21: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 (Tracker Item Submitted) made by Item Submitter 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: Open Resolution: None 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. -- 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-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: Open Resolution: None 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 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-1387650 ] weird behavior when assigning locals() to a variable
Bugs item #1387650, was opened at 2005-12-21 16:04 Message generated for change (Comment added) made by nnorwitz 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: Neal Norwitz (nnorwitz) Date: 2005-12-21 21: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-21 16: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-1355842 ] Incorrect Decimal-float behavior for += and *=
Bugs item #1355842, was opened at 2005-11-13 03:17
Message generated for change (Comment added) made by nnorwitz
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: Neal Norwitz (nnorwitz)
Date: 2005-12-21 21: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-01 22: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-13 20: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
