headers
Martin v. Löwis | 1 Jan 2008 22:18
Picon
Gravatar

Re: Tkinter problems with Tcl/Tk 8.5

> It seems very peculiar how the text widget's bbox is returning a  
> Python-like list and therefore breaking the Tcl callback.  I haven't  
> thus far been able to determine which python method is causing that,  
> or if it's something related to the hooks you have added.  The same  
> problem doesn't occur with 8.4.

I have now studied this in detail, and fixed it in Python's trunk;
see the tracker item for details.

In short:
- IDLE redirects all widget sub-commands, either calling an overridden
  definition, or the original Tk command.
- in the redirection of "bbox", Tk 8.4 would return a string, whereas
  8.5 now returns a list.
- _tkinter converts the string to a Python string, and the list to a
  Python tuple
- IDLE returns the Python value to _tkinter, which in turn converts
  it to a string. This leaves the 8.4 string unchanged, but converts
  the 8.5 tuple into something like "(10, 10, 20, 20)".
- Tk interprets it as a list of numbers, choking as "(10," is not
  a meaningful number.

The fix is to return an ObjResult to Tcl from a Python callback.
I'm skeptical about back-porting this to 2.5, as it may affect behavior.
So for 2.5, we probably have to recommend not using Tk 8.5.

There are a number of additional incompatible changes. For example,
text::index returns textindex objects now, where it used to return
strings. I have fixed that in Tkinter, which converts the textindex
back to a string. I'm sure there are other places where Tk 8.5 will
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raymond Hettinger | 3 Jan 2008 02:19
Favicon

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
(Continue reading)

Permalink | Reply | 14 comments |
headers
John Barham | 3 Jan 2008 02:59
Picon
Gravatar

Re: 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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Guido van Rossum | 3 Jan 2008 03:05
Favicon

Re: 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 <python <at> rcn.com> 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:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aahz | 3 Jan 2008 03:08

Re: 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 (aahz <at> pythoncraft.com)           <*>         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 <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Terry Jones | 3 Jan 2008 03:23
Picon
Favicon
Gravatar

Re: Syntax suggestion for imports

>>>>> "John" == John Barham <jbarham <at> gmail.com> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Barry Warsaw | 3 Jan 2008 04:18
Favicon

Re: Syntax suggestion for imports


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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raymond Hettinger | 3 Jan 2008 04:29
Favicon

Re: 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:
(Continue reading)

Permalink | Reply | 502 comments |
headers
Jeroen Ruigrok van der Werven | 3 Jan 2008 07:38
Gravatar

Re: Syntax suggestion for imports

-On [20080103 04:29], Raymond Hettinger (python <at> rcn.com) 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(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
In every stone sleeps a crystal...
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 502 comments |
headers
Michael Urman | 3 Jan 2008 07:56
Picon

Re: Syntax suggestion for imports

On Jan 2, 2008 7:19 PM, Raymond Hettinger <python <at> rcn.com> 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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane