[Python-Dev] Syntax suggestion for imports
The standard library, my personal code, third-party packages, and my employer's code base are filled with examples of the following pattern: try: import threading except ImportError: import dummy_threading as threading try: import xml.etree.cElementTree as ET except ImportError: try: import cElementTree as ET except ImportError: import elementtree.ElementTree as ET try: from cStringIO import StringIO except ImportError: from StringIO import StringIO try: import readline except ImportError: pass How about a new, simpler syntax: * import threading or dummy_threading as threading * import xml.etree.CElementTree or cElementTree or elementree.ElementTree as ET * from cStringIO or StringIO import StringIO * import readline or emptymodule ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
Raymond Hettinger wrote: > How about a new, simpler syntax: > > * import threading or dummy_threading as threading > * import xml.etree.CElementTree or cElementTree or elementree.ElementTree as > ET > * from cStringIO or StringIO import StringIO These all look good to me. The "short circuit" import syntax and semantics are compact and intuitive. > * import readline or emptymodule This I find more problematic as "emptymodule" seems too magical. Even now any code that wants to use a module that might not have been successfully imported needs to check if that's the case. E.g., a fuller current use-case would be: try: readline = None import readline except ImportError: pass if readline is not None: readline.foo() ... Conceivably emptymodule could act as a Null object but that could create more problems than it solves. John ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
I wonder if your perceived need for this isn't skewed by your working within the core? Also, in 3.0 many of the use cases should go away -- e.g. cStringIO vs, StringIO, etc., as we switch the stdlib to having a single "public" name for an API which automatically replaces or augments itself with the accelerated C version if available. --Guido On Jan 2, 2008 5:19 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > The standard library, my personal code, third-party packages, and my > employer's code base are filled with examples of the following pattern: > > try: >import threading > except ImportError: >import dummy_threading as threading > > try: > import xml.etree.cElementTree as ET > except ImportError: > try: > import cElementTree as ET > except ImportError: > import elementtree.ElementTree as ET > > try: > from cStringIO import StringIO > except ImportError: > from StringIO import StringIO > > try: > import readline > except ImportError: > pass > > > How about a new, simpler syntax: > > * import threading or dummy_threading as threading > > * import xml.etree.CElementTree or cElementTree or elementree.ElementTree as > ET > > * from cStringIO or StringIO import StringIO > > * import readline or emptymodule > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
On Wed, Jan 02, 2008, Raymond Hettinger wrote: > > The standard library, my personal code, third-party packages, and > my employer's code base are filled with examples of the following > pattern: > > try: >import threading > except ImportError: >import dummy_threading as threading > > How about a new, simpler syntax: > > * import threading or dummy_threading as threading My gut reaction is -0. For starters, many of these should go away with Python 3.0 (e.g. cStringIO). Also, annoying as the try/except is, I think the fact that it signals the special import is helpful; your suggestion is too light-weight IMO. If you could devise something just a bit heavier, that would be much better. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
> "John" == John Barham <[EMAIL PROTECTED]> writes: >> * import readline or emptymodule John> This I find more problematic as "emptymodule" seems too magical. John> Even now any code that wants to use a module that might not have been John> successfully imported needs to check if that's the case. E.g., a John> fuller current use-case would be: John> try: John>readline = None John>import readline John> except ImportError: John>pass John> if readline is not None: John>readline.foo() John> Conceivably emptymodule could act as a Null object but that could John> create more problems than it solves. How about import readline or None as readline This is just for cases where you don't want to trigger ImportException on import and do want the symbol set to None for later testing. A standalone "import None" could have no effect. Terry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 2, 2008, at 9:08 PM, Aahz wrote: > On Wed, Jan 02, 2008, Raymond Hettinger wrote: >> >> The standard library, my personal code, third-party packages, and >> my employer's code base are filled with examples of the following >> pattern: >> >> try: >> import threading >> except ImportError: >> import dummy_threading as threading >> >> How about a new, simpler syntax: >> >> * import threading or dummy_threading as threading > > My gut reaction is -0. For starters, many of these should go away > with > Python 3.0 (e.g. cStringIO). Also, annoying as the try/except is, I > think the fact that it signals the special import is helpful; your > suggestion is too light-weight IMO. If you could devise something > just > a bit heavier, that would be much better. I tend to agree. The little bit of syntactic sugar doesn't really seem worth it. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR3xT9nEjvBPtnXfVAQIX/QQAmg9RczTAxHUe3qsry3F9DcUQZX32C9HS VMETbSnoVS0Xrdm5J7cCYqjpHlPXLKRoFCuYGWJ03ivjws/DzAsTXhpFwSmISZId 43W2UCC6mX8izr3E+bC4uEagw7EiVFsDEIX52FoUx6vIig0piZq3XolpQUqk4tP2 EhxQzTZwx6c= =U9qz -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
[GvR] > I wonder if your perceived need for this isn't skewed by your > working within the core? The need was perceived by a colleague who does not work on the core. My own skew was in the opposite direction -- I've seen the pattern so often that I'm oblivious to it. Before posting, I ran some scans of our code base at work and found plenty of examples (mostly third-party cmodules vs python equivalents and a few that searched for similar functionality in different packages). It might be helpful if others were to also search their own code bases and post their findings: find . -name "*py" | xargs grep -C2 ImportError *py Also, Google's codesearch gives some examples (and a lot of cases that really do need the try/except form): http://www.google.com/codesearch?q=+lang:python+%22except+ImportError%22 I was surprised to see many examples in the form of: try: import xyz except ImportError: xyz = None I was also surprised to find plenty of code that is likely to be buggy because the two alternative loaded different names: try: from Products.OpenPT.OpenPTFile import OpenPTFile as ptFile except ImportError: from Products.PageTemplates.PageTemplateFile import PageTemplateFile I was not surprised to see searches for similar functionality across different packages like kjbuckets vs kjbuckets0 , Zope vs Zope2, or HTMLParser vs SGMLParser, or attempts to load any of several packages compliant with the DBAPI. Surely, Py3.0's automatic vectoring to C equivalent modules will help with the cases like cStringIO, cPickle. I don't think it will help with the general case of searching for a best available package (like gdbm vs dbm vs dumbdbm or threading vs dummythreading) or a best available implementation of a single function (like twisted.protocols._c_urlarg.unquote vs urllib.unquote or one of the various implementations of date utilities or encryption functions). Am curious to see what everyone else finds in their own code searches. [John Barham] > This I find more problematic as "emptymodule" seems too magical. > . . . > try: >readline = None >import readline > except ImportError: >pass Perhaps "import readline or None" would have been a better way to capture that pattern as well as the "except pass" pattern. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
-On [20080103 04:29], Raymond Hettinger ([EMAIL PROTECTED]) wrote: >Am curious to see what everyone else finds in their own code searches. On the Trac project using your grep gives me 203 lines, if we take ~2 lines for and after in consideration, it still means 203/5 ~= 40 occurences. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ In every stone sleeps a crystal... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
On Jan 2, 2008 7:19 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > How about a new, simpler syntax: > > * import threading or dummy_threading as threading > > * import xml.etree.CElementTree or cElementTree or elementree.ElementTree as > ET > > * from cStringIO or StringIO import StringIO > > * import readline or emptymodule I'm sympathetic to this syntax proposal, as I find the repetition and extra lines for a simple idea to be a little unpleasant. This would also allow us to decide whether the import 'or' handling would be triggered equivalently to the except ImportError case you described, or only for missing imports. The latter would stop errors in existing modules from being silenced (and may give reason to allow emptymodule or None), but I'm unsure if that's a good thing. Of the above I find the ElementTree migration to be the most compelling, yet it seems ill-timed to bring syntax into Python 2.x you'd be unable to use until you no longer needed it. However your later example of the PageTemplateFile, which appears to be due to a third-party module reorganization and could certainly happen during the lifetime of late 2.x, helps swing me back the other way. -- Michael Urman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
[Jeroen Ruigrok van der Werven] > On the Trac project using your grep gives me 203 lines, if we take ~2 lines > for and after in consideration, it still means 203/5 ~= 40 occurences. Thanks. I'm more curious about the content of those lines. Does the proposed syntax help, does the need go away in Py3.0, what is the typical pattern? Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Return type of round, floor, and ceil in 2.6
I've been backporting pep 3141 to the trunk, and ran into the issue that round, math.floor, and math.ceil, which it specifies to return Integrals, currently return floats. Guido suggested privately that, to make sure that 2.6 is compatible with 2.5, they should keep returning floats for float arguments. Probably this implies that they should also keep returning float for int and long arguments. For other types, we're probably free to do whatever. Consistency across all Real implementations suggests that those 3 functions should always return their argument type. Consistency and compatibility with 3.0 suggest that they should return long for every new type we add them to. What does the list think? Thanks, Jeffrey Yasskin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
