[ python-Feature Requests-1509798 ] replace dist/src/Tools/scripts/which.py with tmick's which
Feature Requests item #1509798, was opened at 2006-06-21 10:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509798&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: wrstl prmpft (wrstlprmpft) Assigned to: Nobody/Anonymous (nobody) Summary: replace dist/src/Tools/scripts/which.py with tmick's which Initial Comment: see http://starship.python.net/~tmick/#which The author agrees with me in his README. Even better: include which as a module in the standard library so it can be used programmatically and as:: python -m which ... or maybe:: python -m os.which ... cheers -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509798&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1509132 ] compiler module builds incorrect AST for TryExceptFinally
Bugs item #1509132, was opened at 2006-06-20 08:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1509132&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: Closed Resolution: Fixed Priority: 5 Submitted By: Adrien Di Mascio (adimasci) Assigned to: Nobody/Anonymous (nobody) Summary: compiler module builds incorrect AST for TryExceptFinally Initial Comment: the finally clause in a try ... except ... finally statement is seen as a "else" clause by transformer.py. There is no special code to handle finally clauses for a try / except node (Maybe ast.TryExcept should accept a finally_ argument after the else_ one) Python version : 2.5b1 (r46858) -- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-21 17:45 Message: Logged In: YES user_id=849994 Fixed in rev. 47057. -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-20 15:57 Message: Logged In: YES user_id=849994 Thanks for reporting! I fixed this and will commit as soon as the trunk is unfrozen. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1509132&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1510172 ] Absolute/relative import not working?
Bugs item #1510172, was opened at 2006-06-21 13:35 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=1510172&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: Mitch Chapman (mitchchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Absolute/relative import not working? Initial Comment: Trying to import from a module using dotted import syntax produces this exception: ValueError: Relative importpath too deep This behavior has been confirmed on Mac OS X 10.4 using the Python 2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source tarball. The exception is raised regardless of whether the PYTHONPATH environment variable can see the toplevel directory of the package being tested; regardless of whether the import is performed from an interactive Python session or from a script invoked from the command line; and regardless of whether the main script starts with from __future__ import absolute_import To test, I tried to re-create the package structure used as an example in PEP 328. (See attachments.) Most of the files were empty, except moduleX.py and moduleY.py: #moduleX.py: from __future__ import absolute_import from .moduleY import spam #moduleY.py: spam = "spam" According to the PEP, if should be possible to import moduleX without error. But I get the above exception whenever I try to import moduleX or to run it from the command line. $ python2.5 moduleX.py Traceback (most recent call last): File "moduleX.py", line 3, in from .moduleY import spam ValueError: Relative importpath too deep Is this a usage/documentation error? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1510172 ] Absolute/relative import not working?
Bugs item #1510172, was opened at 2006-06-21 12:35 Message generated for change (Comment added) made by mnot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&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: Mitch Chapman (mitchchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Absolute/relative import not working? Initial Comment: Trying to import from a module using dotted import syntax produces this exception: ValueError: Relative importpath too deep This behavior has been confirmed on Mac OS X 10.4 using the Python 2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source tarball. The exception is raised regardless of whether the PYTHONPATH environment variable can see the toplevel directory of the package being tested; regardless of whether the import is performed from an interactive Python session or from a script invoked from the command line; and regardless of whether the main script starts with from __future__ import absolute_import To test, I tried to re-create the package structure used as an example in PEP 328. (See attachments.) Most of the files were empty, except moduleX.py and moduleY.py: #moduleX.py: from __future__ import absolute_import from .moduleY import spam #moduleY.py: spam = "spam" According to the PEP, if should be possible to import moduleX without error. But I get the above exception whenever I try to import moduleX or to run it from the command line. $ python2.5 moduleX.py Traceback (most recent call last): File "moduleX.py", line 3, in from .moduleY import spam ValueError: Relative importpath too deep Is this a usage/documentation error? -- Comment By: Mark Nottingham (mnot) Date: 2006-06-21 14:16 Message: Logged In: YES user_id=21868 Seeing the same behaviour; OSX with the installer. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1510172 ] Absolute/relative import not working?
Bugs item #1510172, was opened at 2006-06-21 21:35 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&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: Mitch Chapman (mitchchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Absolute/relative import not working? Initial Comment: Trying to import from a module using dotted import syntax produces this exception: ValueError: Relative importpath too deep This behavior has been confirmed on Mac OS X 10.4 using the Python 2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source tarball. The exception is raised regardless of whether the PYTHONPATH environment variable can see the toplevel directory of the package being tested; regardless of whether the import is performed from an interactive Python session or from a script invoked from the command line; and regardless of whether the main script starts with from __future__ import absolute_import To test, I tried to re-create the package structure used as an example in PEP 328. (See attachments.) Most of the files were empty, except moduleX.py and moduleY.py: #moduleX.py: from __future__ import absolute_import from .moduleY import spam #moduleY.py: spam = "spam" According to the PEP, if should be possible to import moduleX without error. But I get the above exception whenever I try to import moduleX or to run it from the command line. $ python2.5 moduleX.py Traceback (most recent call last): File "moduleX.py", line 3, in from .moduleY import spam ValueError: Relative importpath too deep Is this a usage/documentation error? -- Comment By: iga Seilnacht (zseil) Date: 2006-06-22 00:59 Message: Logged In: YES user_id=1326842 I think this is a usage error. The problem is that you run moduleX as a script. This puts the module's directory as the first entry in sys.path (see http://docs.python.org/dev/lib/module-sys.html#l2h-5058 for detais). As a consequence, moduleX is recognised as a top level module, not as part of a package. If you want to test relative import, try opening an interactive shell in the directory where `package` resides, and type: >>> from package.subpackage1 import moduleX >>> moduleX.spam 'spam' -- Comment By: Mark Nottingham (mnot) Date: 2006-06-21 23:16 Message: Logged In: YES user_id=21868 Seeing the same behaviour; OSX with the installer. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1510172 ] Absolute/relative import not working?
Bugs item #1510172, was opened at 2006-06-21 13:35 Message generated for change (Comment added) made by mitchchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&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: Mitch Chapman (mitchchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Absolute/relative import not working? Initial Comment: Trying to import from a module using dotted import syntax produces this exception: ValueError: Relative importpath too deep This behavior has been confirmed on Mac OS X 10.4 using the Python 2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source tarball. The exception is raised regardless of whether the PYTHONPATH environment variable can see the toplevel directory of the package being tested; regardless of whether the import is performed from an interactive Python session or from a script invoked from the command line; and regardless of whether the main script starts with from __future__ import absolute_import To test, I tried to re-create the package structure used as an example in PEP 328. (See attachments.) Most of the files were empty, except moduleX.py and moduleY.py: #moduleX.py: from __future__ import absolute_import from .moduleY import spam #moduleY.py: spam = "spam" According to the PEP, if should be possible to import moduleX without error. But I get the above exception whenever I try to import moduleX or to run it from the command line. $ python2.5 moduleX.py Traceback (most recent call last): File "moduleX.py", line 3, in from .moduleY import spam ValueError: Relative importpath too deep Is this a usage/documentation error? -- >Comment By: Mitch Chapman (mitchchapman) Date: 2006-06-21 17:57 Message: Logged In: YES user_id=348188 Hm... but the same error occurs if one tries to import moduleX from an interactive Python session, or from a sibling module. In other words, in 2.5b1 any module which uses relative imports can be used only as a fully-qualified member of a package. It cannot be imported directly by a sibling module, and it cannot be used as a main module at all: $ python2.5 -m package.subpackage1.moduleX ... from .moduleY import spam ValueError: Relative importpath too deep Given other efforts (PEP 299; PEP 338) to make it easier to use modules both as mainlines and as imports, I still think this is a bug. -- Comment By: iga Seilnacht (zseil) Date: 2006-06-21 16:59 Message: Logged In: YES user_id=1326842 I think this is a usage error. The problem is that you run moduleX as a script. This puts the module's directory as the first entry in sys.path (see http://docs.python.org/dev/lib/module-sys.html#l2h-5058 for detais). As a consequence, moduleX is recognised as a top level module, not as part of a package. If you want to test relative import, try opening an interactive shell in the directory where `package` resides, and type: >>> from package.subpackage1 import moduleX >>> moduleX.spam 'spam' -- Comment By: Mark Nottingham (mnot) Date: 2006-06-21 15:16 Message: Logged In: YES user_id=21868 Seeing the same behaviour; OSX with the installer. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1495488 ] make altinstall installs pydoc
Bugs item #1495488, was opened at 2006-05-26 12:19
Message generated for change (Comment added) made by theaney
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&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: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Heaney (theaney)
Assigned to: Nobody/Anonymous (nobody)
Summary: make altinstall installs pydoc
Initial Comment:
I did the "make altinstall" rather than the "make
install" as suggested on
http://www.python.org/download/releases/2.5/
This worked great, creating a
/usr/local/bin/python2.5
which doesn't clash with my /usr/bin/python. However,
it also created a
/usr/local/bin/pydoc
which did clash with my /usr/bin/pydoc. I just removed
it and all is well. Should altinstall not create pydoc?
It could create pydoc2.5 rather than pydoc, but then
the shebang line would have to be changed to python2.5.
What about smtpd.py, idle, and python-config, which
were also created by altinstall? They don't currently
conflict with anything I have for Python 2.4, but the
potential is there for the same problem.
--
>Comment By: Tim Heaney (theaney)
Date: 2006-06-22 00:14
Message:
Logged In: YES
user_id=827666
Sorry, I haven't had a chance to look at this again. I just
installed Python-2.5b1 and it's still the same way. Here's
what I did to fix things up after the make altinstall...
# cd /usr/local/bin
# for file in pydoc idle smtpd.py python-config; do
mv $file ${file}2.5
sed -i 's@/usr/local/bin/python@/usr/local/bin/python2.5@'
${file}2.5
done
Now, how to fix up the Makefile.pre and setup.py so this
isn't necessary...
--
Comment By: Tim Heaney (theaney)
Date: 2006-06-06 11:19
Message:
Logged In: YES
user_id=827666
I'm not sure I know how. It looks like the downloaded files
have the following shebang lines
Tools/scripts/pydoc => #!/usr/bin/env python
Tools/scripts/idle=> #! /usr/bin/env python
Lib/smtpd.py => #! /usr/bin/env python
Misc/python-config.in => [EMAIL PROTECTED]@/python
whereas the installed files have
/usr/local/bin/pydoc => #!/usr/local/bin/python
/usr/local/bin/idle => #!/usr/local/bin/python
/usr/local/bin/smtpd.py => #!/usr/local/bin/python
/usr/local/bin/python-config => #!/usr/local/bin/python
so they're already getting rewritten somewhere. We want both
their names and their shebang lines to have the version
/usr/local/bin/pydoc2.5 => #!/usr/local/bin/python2.5
/usr/local/bin/idle2.5 => #!/usr/local/bin/python2.5
/usr/local/bin/smtpd.py2.5 => #!/usr/local/bin/python2.5
/usr/local/bin/python-config2.5 => #!/usr/local/bin/python2.5
It seems that python-config appears in the Makefile, so
adding something like
sed -e "s,@BINDIR@,$(BINDIR)," <
$(srcdir)/Misc/python-config.in >python-config$(VERSION)$(EXE)
$(INSTALL_SCRIPT) python-config
$(BINDIR)/python-config$(VERSION)$(EXE)
rm python-config
to Makefile.pre.in in an altlibainstall section or something
might be all we need for that.
The others are named in setup.py
# Scripts to install
scripts = ['Tools/scripts/pydoc',
'Tools/scripts/idle',
'Lib/smtpd.py']
but I haven't worked out where they get rewritten or
installed yet.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-06-04 20:02
Message:
Logged In: YES
user_id=21627
You are right: altinstall shouldn't overwrite these
conflicting files. For idle and pydoc, I would think that
altinstall should install version-specific copies - users
actually might want to run an idle or pydoc associated with
a specific version, likewise for python-config. I'm
uncertain why smtpd.py is installed at all.
Would you be willing to work on a patch? You are right that
the shebang line should get updated during the installation,
too.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-513840 ] entity unescape for sgml/htmllib
Feature Requests item #513840, was opened at 2002-02-06 12:55 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=513840&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: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: entity unescape for sgml/htmllib Initial Comment: The parsers defined in htmllib and sgmllib do not provide any facilities for unescaping a tag attribute which has an embedded html entityref (i.e., they do not provide a way to convert "a&b" to "a&b"). The parser in HTMLParser unescapes all tag attributes automatically. I'm not sure that's the right approach for sgmllib and htmllib (since it might break existing code), but it seems to me that one of the modules ought to provide a function or method which can do the unescaping if needed. (I'm not familiar with either the SGML or the HTML specification, but I assume one of them mandates the escaping of '&' (e.g.) in tag attributes. If so, then it seems appropriate for one of the modules to provide a function which undoes the mandated transformation.) -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-21 23:57 Message: Logged In: YES user_id=3066 This request is making me reconsider some other changes that have already been made on the trunk (and are now in 2.5b1). Reading this, I thought "Doesn't it already do that?" Turns out that in Python 2.4, it doesn't. Both versions handle this in parsed character data; the difference is confined to attribute values. I'd like to propose adding a Boolean configuration attribute on the parser instance that, when set, causes the parser to decode entity and character references. By default, it would be unset. This would support backward compatibility and make it easier to get attribute value decoding. Another possibility would be to revert the new feature and add a separate method to perform the decoding. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=513840&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
