Re: String to Dictionary conversion in python
Rustom Mody writes:
> On Saturday, September 16, 2017 at 2:04:39 AM UTC+5:30, jlad...@itu.edu wrote:
> Yeah… I used to think thus
> But literal_eval has excessive crud in its error messages:
>
from ast import literal_eval
>
literal_eval("{'x':1}")
> {'x': 1}
>
> Ok…
>
literal_eval("{x:1}")
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python2.7/ast.py", line 80, in literal_eval
> return _convert(node_or_string)
> File "/usr/lib/python2.7/ast.py", line 63, in _convert
> in zip(node.keys, node.values))
> File "/usr/lib/python2.7/ast.py", line 62, in
> return dict((_convert(k), _convert(v)) for k, v
> File "/usr/lib/python2.7/ast.py", line 79, in _convert
> raise ValueError('malformed string')
> ValueError: malformed string
>
You can catch the exception and print a nice error message:
from ast import literal_eval
def literal(s):
try:
return literal_eval('{'+s+'}')
except Exception as e:
print "%s: %s" % (type(e).__name__, ', '.join(e.args))
>>> literal("'x':1")
{'x': 1}
>>> literal("x:1")
ValueError: malformed string
But in non-interactive use you probably want to propagate the exception.
--
Piet van Oostrum
WWW: http://piet.vanoostrum.org/
PGP key: [8DAE142BE17999C4]
--
https://mail.python.org/mailman/listinfo/python-list
Re: String to Dictionary conversion in python
On Sat, 16 Sep 2017 11:29 am, Rustom Mody wrote:
>> > py> import ast
>> > py> string = " 'msisdn': '7382432382', 'action': 'select',
>> > 'sessionId': '123', 'recipient': '7382432382', 'language': 'english'"
>> > py> ast.literal_eval('{%s}' % string)
>> > {'sessionId': '123', 'recipient': '7382432382', 'msisdn':
>> > '7382432382', 'action': 'select', 'language': 'english'}
>>
>> Very clever!
> Yeah… I used to think thus
> But literal_eval has excessive crud in its error messages:
>
from ast import literal_eval
>
literal_eval("{'x':1}")
> {'x': 1}
>
> Ok…
>
literal_eval("{x:1}")
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python2.7/ast.py", line 80, in literal_eval
> return _convert(node_or_string)
> File "/usr/lib/python2.7/ast.py", line 63, in _convert
> in zip(node.keys, node.values))
> File "/usr/lib/python2.7/ast.py", line 62, in
> return dict((_convert(k), _convert(v)) for k, v
> File "/usr/lib/python2.7/ast.py", line 79, in _convert
> raise ValueError('malformed string')
> ValueError: malformed string
Here's the bug tracker: make a feature request for literal_eval to be more
concise in its traceback and provide a more useful and detailed error message.
https://bugs.python.org/
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Which database system?
Stefan Ram wrote:
> Michael Torrie writes:
>>On 09/15/2017 12:04 PM, Stefan Ram wrote:
>>>writes some complex queries to the table, what can be expected
>>^^
>>How do you plan to code these queries?
>
> I did a quick prototype. I am aware that the code
> is very quick and very dirty. But since you ask:
>
> The table is filled after »# fill table« below.
>
> An example ad-hoc query then follows after
> »# query table« below.
>
> This code was not intended to be read by someone else,
> the next thing to do is a clean up of the code.
"import builtins", lines ending on ';', both extra and missing spaces, come
on ;)
Do yourself a favour, and steer your style a bit more into the direction of
PEP 8.
> So you have been warned!
>
> The output should be:
>
> |abend
> | - Beispiel = Montag abend
> |Abend
> | - Beispiel = des Abends
> |ähnlich
> | - Beispiel = dem Hause ähnlich
Based on the example I wonder if you really want a table, or whether
something tree-like would be more appropriate:
from collections import OrderedDict, defaultdict
data = {
"abend": {
"Beispiel": {"Montag abend"},
"Kategorie": {"Deutsches Wörterbuch", "Groß- und Kleinschreibung"}
},
"Abend": {
"Beispiel": {"des Abends"},
"Kategorie": {"Deutsches Wörterbuch",
"Getrennt -und Zusammenschreibung"}
},
"Montag abend": {
"Kategorie": {"Getrennt -und Zusammenschreibung"}
},
"ähnlich": {
"Kategorie": {"Deutsches Wörterbuch"},
"Beispiel": {"dem Hause ähnlich"}
},
}
data = OrderedDict(sorted(
((k, defaultdict(set, v)) for k, v in data.items()),
key=lambda kv: (kv[0].casefold(), kv[0])))
for key, value in data.items():
if "Deutsches Wörterbuch" in value["Kategorie"]:
print(key)
for example in value["Beispiel"]:
print(" -", example)
If this turns out to be too slow just throw more lookup tables at it:
by_relation = defaultdict(list)
for key, value in data.items():
for k, v in value.items():
for vv in v:
by_relation[k, vv].append(key)
Then you can rewrite the print loops to avoid iterating over the whole
table:
for key in by_relation["Kategorie", "Deutsches Wörterbuch"]:
print(key)
for example in data[key]["Beispiel"]:
print(" -", example)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Old Man Yells At Cloud
On 09/16/2017 12:38 AM, Steve D'Aprano wrote: > /rant on > > So apparently everyone who disagrees that Python should be more like > Javascript > is an old greybeard fuddy-duddy yelling "Get off my lawn!" to the cool kids -- > and is also too stupid to know how dumb they are. > > "Hi, I've been programming in Python for what seems like days now, and here's > all the things that you guys are doing wrong. I insist that you fix them > immediately, it doesn't matter how much code it will break, that's not > important. What is important is that Javascript programmers like me shouldn't > be expected to learn anything new or different when they program with Python." > > /rant off > > And no, for once it wasn't Ranting Rick. > > > > Well, the whole integer floor division thing years ago was the beginning of the end - Python was doomed ... -- https://mail.python.org/mailman/listinfo/python-list
Re: Old Man Yells At Cloud
On 09/16/2017 12:38 AM, Steve D'Aprano wrote: > /rant on > > So apparently everyone who disagrees that Python should be more like > Javascript > is an old greybeard fuddy-duddy yelling "Get off my lawn!" to the cool kids -- > and is also too stupid to know how dumb they are. > > "Hi, I've been programming in Python for what seems like days now, and here's > all the things that you guys are doing wrong. I insist that you fix them > immediately, it doesn't matter how much code it will break, that's not > important. What is important is that Javascript programmers like me shouldn't > be expected to learn anything new or different when they program with Python." > > /rant off > > And no, for once it wasn't Ranting Rick. > > > > Well, the whole integer floor division thing years ago was the beginning of the end - Python was doomed ... -- https://mail.python.org/mailman/listinfo/python-list
CPython has hit 100,000 commits
Looks as if people have been busy over the years. Read all about it https://github.com/python/cpython -- Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 2.7.14
I'm happy to announce to the immediate availability of Python 2.7.14, yet another bug fix release in the Python 2.7 series. 2.7.14 includes 9 months of conservative bug fixes from the 3.x branch. Downloads of source code and binaries are at: https://www.python.org/downloads/release/python-2714/ Bugs may be reported at https://bugs.python.org/ Warmly, Benjamin 2.7 release manager (on behalf of all of 2.7's contributors) -- https://mail.python.org/mailman/listinfo/python-list
Research paper "Energy Efficiency across Programming Languages: How does energy, time, and memory relate?"
I thought some might find this https://sites.google.com/view/energy-efficiency-languages/ interesting. -- Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: Old Man Yells At Cloud
On Sun, 17 Sep 2017 02:52 am, Dennis Lee Bieber wrote: > Yes -- that would give me fits if I were using Python3 currently... > Since so many of the languages I've learned over the past years use the > concept integer / integer => integer_result That would be C, and C derived languages, perhaps? Pascal uses integer / integer => float (except Pascal calls it "Real"). If you want integer division, use "div". I think so did Algol. > Come to think of it -- wasn't there a post from someone (seems to > expired or been filtered from my client) asking for help with some sorting > program... I'm pretty sure the partitioning logic would croak on Python3 > due to floating point results in the slice indices: > > pA = part[:n/2] > pB = part[n/2:] If you want integer division, you have to use integer division :-) pA = part[:n//2] -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Old Man Yells At Cloud
On 16/09/2017 19:00, Stefan Ram wrote: Steve D'Aprano writes: "Hi, I've been programming in Python for what seems like days now, and here's all the things that you guys are doing wrong. I never ever have written a line of Python 2. I started with Python 3.6.0. Yet a very frequent mistake of mine is the imission of parentheses after »print«. WRT my other common errors, It thought of writing a program that autocorrects my source code as follows: Whenever the next line is indented more, add a colon: abd def ghi jkl mno pqr I've used Komodo in the past and that editor works other way round, type a ':' at the end of a line and the next line is indented. I would presume other language aware editors take the same approach. print """ Your idea would require considerable inteligence in the editor, 1. Otherwise the previous line would print with a ':' 2. That would frustrate me. """ -> abd def ghi: jkl mno pqr Whenever the next line is indented more, add "def" to what looks like a call (and does not start with »class« or »def«; f( x ): return x * x -> def f( x ): return x * x Whenever a line starts with "print" and no parentheses are following, add them: print x, 2 Strangely I find it irksome to have to write print as a function call in Python 3. Must reflect those long ago days when I started to program (oops, I mean code - programming came later). Come to think of it there's something irksome about every language I've ever used. Python probably the least. -> print( x, 2 ) Implementing algorithms from "The Art of Computer Programming" might sometimes be difficult in Python, since those algorithms IIRC often use »goto«. Good point. I also have a copy of that work of art (and the fascicles - I must get out more). Sadly little work these days requires diving into them. In fairness to Knuth his pseudo code is a high level assembler fully described in Vol:1 and done as such so folk from any high level language background could follow the algorithms. Back then many like myself, or indeed most coders, had a hardware background and well used to assembler. The nearest thing most silicon has to structured programming is call and return, gotos are everywhere. I always think one of the reasons Basic became so popular was its /goto /statement. The other was the run command, no need to compile. See /http://entrian.com/goto// for a Python implementation from many years ago. No idea if it still works. To be honist never needed it - Python has exceptions. Also there was a interesting thread '/"Goto" statement in Python/' in April this year (not the 1st). Although mainly interesting for its references to gotos in 'C' which I use daily now. err 'C' that is. . . . . . Used to wind up colleagues by saying loudly "Great, I can use a /*goto */here.". This attracted considerable verbal abuse from purists in earshot and instruction from the boss NOT TO which I pretended to ignore. After all Python programming is supposed to be fun! -- https://mail.python.org/mailman/listinfo/python-list
Re: Old Man Yells At Cloud
On Sun, 17 Sep 2017 04:00 am, Stefan Ram wrote: > Steve D'Aprano writes: >>"Hi, I've been programming in Python for what seems like days now, and here's >>all the things that you guys are doing wrong. > > I never ever have written a line of Python 2. I started with > Python 3.6.0. Yet a very frequent mistake of mine is the > imission of parentheses after »print«. That's remarkable. Do you also forget the parentheses around `len`, and `iter`, and `math.sin()`? If not, what's so special about print? Javascript (at least the Rhino interpreter, if not others) includes a print function. It too requires parentheses: js> print 21 js: "", line 5: missing ; before statement js: print 21 js: ...^ js> print(21) 21 > WRT my other common errors, It thought of writing > a program that autocorrects my source code as follows: [...] > Whenever the next line is indented more, add "def" to > what looks like a call (and does not start with »class« > or »def«; > > f( x ): > return x * x Seriously Stefan, forgetting colons is one thing, but if you regularly forget to start function definitions with "def", I fear that you're just not paying attention to what you are doing. Do you occasionally find yourself halfway down the street after leaving home when you realise you're not wearing any pants? :-) -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Old Man Yells At Cloud
On 2017-09-17 02:00, Steve D'Aprano wrote: On Sun, 17 Sep 2017 02:52 am, Dennis Lee Bieber wrote: Yes -- that would give me fits if I were using Python3 currently... Since so many of the languages I've learned over the past years use the concept integer / integer => integer_result That would be C, and C derived languages, perhaps? Or Fortran. [snip] -- https://mail.python.org/mailman/listinfo/python-list
Re: Old Man Yells At Cloud
On Sun, Sep 17, 2017 at 11:28 AM, MRAB wrote: > On 2017-09-17 02:00, Steve D'Aprano wrote: >> >> On Sun, 17 Sep 2017 02:52 am, Dennis Lee Bieber wrote: >> >> >>> Yes -- that would give me fits if I were using Python3 currently... >>> Since so many of the languages I've learned over the past years use the >>> concept integer / integer => integer_result >> >> >> That would be C, and C derived languages, perhaps? >> > Or Fortran. Or machine code on every CPU I've ever worked with. Dividing integers yields an integer. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Old Man Yells At Cloud
On Sun, Sep 17, 2017 at 11:42 AM, Chris Angelico wrote: > On Sun, Sep 17, 2017 at 11:28 AM, MRAB wrote: >> On 2017-09-17 02:00, Steve D'Aprano wrote: >>> >>> On Sun, 17 Sep 2017 02:52 am, Dennis Lee Bieber wrote: >>> >>> Yes -- that would give me fits if I were using Python3 currently... Since so many of the languages I've learned over the past years use the concept integer / integer => integer_result >>> >>> >>> That would be C, and C derived languages, perhaps? >>> >> Or Fortran. > > Or machine code on every CPU I've ever worked with. Dividing integers > yields an integer. (Or more technically, yields two integers - div/mod) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Research paper "Energy Efficiency across Programming Languages: How does energy, time, and memory relate?"
On Sun, 17 Sep 2017 09:04 am, breamore...@gmail.com wrote: > I thought some might find this > https://sites.google.com/view/energy-efficiency-languages/ interesting. "Made with the new Google Sites, an effortless way to create beautiful sites." More like an effortless way to create a complete dog's breakfast. Once upon a time, web sites would degrade gracefully. If something interrupted the page loading, or something wasn't quite right, or you'd still get something usable. Now, if the tiniest thing goes wrong, you get a junk. I've tried to see the results, but I just get a bunch of broken images :-( On the linked page, starting from the top and scrolling down, I see: - about two screens worth of black white space; - followed by three giant black horizontal bars, each one about an inch high; - more white space; - what looks like something that was intended to be a side-bar, containing: SLE'17 Home Results Setup More - a giant down-pointing arrowhead, about three inches tall, which turns grey when you mouse-over it but doesn't do anything when clicked; - three more links: Home Results Setup which disappear when you mouse-over them; - finally some content! The tools and graphical data pointed by this page are included in the research paper "Energy Efficiency across Programming Languages: How does Energy, Time and Memory Relate?", accepted at the International Conference on Software Language Engineering (SLE) [1] Measuring Framework & Benchmarks [2] Complete Set of Results [3] Setup [4] Paper where the last four bits are links; - the smug, self-congratulatory comment quoted above about "beautiful sites"; - a button "Create a site" - What was presumably intended to be a link, but is actually just a piece of plain text: "Report abuse"; - more whitespace; - and finally a giant blue "i", pointed at the bottom, and slanted at 45 degrees. Presumably a logo for somebody or something. And yes, I am allowing scripts from Google and Gstatic to run, and the page is still broken. Including the hyperlinks, that's about 700 bytes of actual content. Let's double it for the overhead of HTML over plain text, so somewhat less than 1.5 KiB of content. The actual page is 27285 bytes or over 26 KiB. That gives us something with a useful content to bloat factor of 1:17, and *the page still doesn't work.* And that's not even counting any additional files the page requires, like CSS, external javascript files, images, ads, web-bugs, etc. You want to know why browsing the web today on full ADSL or faster speeds is *slower* than using a dial up modem in the 1990s? This is why. www.antipope.org/charlie/blog-static/2008/05/why_your_internet_experience_i.html Nine years later, and the problem is worse, not better. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Old Man Yells At Cloud
Steve D'Aprano writes: >> concept integer / integer => integer_result > That would be C, and C derived languages, perhaps? Certainly not. Fortran, machine languages, etc. all do that too. Haskell does the right thing and makes int/int a compile time type error. Its integer division functions are div and quot. Python 2 does something reasonable and Python 3 does something that is also debatably reasonable. Switching from one reasonable thing to another without a very good reason is called fixing things that weren't broken. Python 2 wasn't broken in that area and didn't need to be fixed. -- https://mail.python.org/mailman/listinfo/python-list
Re: Research paper "Energy Efficiency across Programming Languages: How does energy, time, and memory relate?"
On Sat, Sep 16, 2017 at 8:01 PM, Steve D'Aprano wrote: > On Sun, 17 Sep 2017 09:04 am, breamore...@gmail.com wrote: > >> I thought some might find this >> https://sites.google.com/view/energy-efficiency-languages/ interesting. > > "Made with the new Google Sites, an effortless way to create beautiful sites." > > More like an effortless way to create a complete dog's breakfast. Once upon a > time, web sites would degrade gracefully. If something interrupted the page > loading, or something wasn't quite right, or you'd still get something usable. > Now, if the tiniest thing goes wrong, you get a junk. > > I've tried to see the results, but I just get a bunch of broken images :-( > > > On the linked page, starting from the top and scrolling down, I see: > > - about two screens worth of black white space; > > - followed by three giant black horizontal bars, each one about an inch high; > > - more white space; > > - what looks like something that was intended to be a side-bar, containing: > > SLE'17 > Home > Results > Setup > More > > - a giant down-pointing arrowhead, about three inches tall, which turns > grey when you mouse-over it but doesn't do anything when clicked; > > - three more links: > > Home > Results > Setup > > which disappear when you mouse-over them; > > - finally some content! > > The tools and graphical data pointed by this page are included in the > research paper "Energy Efficiency across Programming Languages: How does > Energy, Time and Memory Relate?", accepted at the International Conference > on Software Language Engineering (SLE) > > [1] Measuring Framework & Benchmarks > [2] Complete Set of Results > [3] Setup > [4] Paper > > > where the last four bits are links; > > - the smug, self-congratulatory comment quoted above about "beautiful sites"; > > - a button "Create a site" > > - What was presumably intended to be a link, but is actually just a piece of > plain text: "Report abuse"; > > - more whitespace; > > - and finally a giant blue "i", pointed at the bottom, and slanted at 45 > degrees. Presumably a logo for somebody or something. > > > And yes, I am allowing scripts from Google and Gstatic to run, and the page is > still broken. It looks fine to me. > Including the hyperlinks, that's about 700 bytes of actual content. Let's > double > it for the overhead of HTML over plain text, so somewhat less than 1.5 KiB of > content. > > The actual page is 27285 bytes or over 26 KiB. That gives us something with a > useful content to bloat factor of 1:17, and *the page still doesn't work.* > > And that's not even counting any additional files the page requires, like CSS, > external javascript files, images, ads, web-bugs, etc. You want to know why > browsing the web today on full ADSL or faster speeds is *slower* than using a > dial up modem in the 1990s? This is why. > > www.antipope.org/charlie/blog-static/2008/05/why_your_internet_experience_i.html > > Nine years later, and the problem is worse, not better. If you're using a cell phone over 2G, then I tentatively agree. But on my laptop over WiFi, this page that you're complaining about loaded in 783 ms when I tried it. -- https://mail.python.org/mailman/listinfo/python-list
Re: ttk.Notebook Tabs Question
by widget["width"] i meant replace widget with your widget Abdur-Rahmaan Janhangeer, Mauritius abdurrahmaanjanhangeer.wordpress.com On 12 Sep 2017 06:45, "Wildman via Python-list" wrote: > I am working on a program that has a ttk.Notebook with > 12 tabs. Is there a way to determine the total width > of the tabs in pixels. Just to be clear I am not talking > about width of the nb container. I am talking about > tabs themselves that contain the text. > > I want the program to be resizable but I don't want to > allow the window width to fall below that of the tabs > which would hide them. Since I can find no way to have > more than one row of tabs, this appears to be my only > option. Any suggestions would be appreciated. > > -- > GNU/Linux user #557453 > May the Source be with you. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Research paper "Energy Efficiency across Programming Languages: How does energy, time, and memory relate?"
On 9/16/2017 7:04 PM, breamore...@gmail.com wrote: I thought some might find this https://sites.google.com/view/energy-efficiency-languages/ interesting. By 'energy', they only mean electricity, not food calories. This is the email I sent to the authors. --- As a two-decade user of Python, I was interested to read your paper. Unfortunately, it is deeply flawed with respect to Python in the sense that your conclusions are inapplicable to real-world usage of Python. The problem is your use of the Computer Language Benchmark Game. As the name says, it is a *game*. As a game, it has artificial rules dictated by the game masters. It uses toy problems, and for Python, the rules dictate unrealistic toy solutions. In particular, it appears to disallow use of 'import' with 3rd-party modules, whereas real-world Python is expected to use them, and nearly always does. The particular crippler for CLBG problems is the non-use of numpy in numerical calculations, such as the n-body problem. Numerical python extensions are over two decades old and give Python code access to optimized, compiled BLAS, LinPack, FFTPack, and so on. The current one, numpy, is the third of the series. It is both a historical accident and a continuing administrative convenience that numpy is not part of the Python stdlib. However, it is easily installed from the PSF-maintained repository (python -m pip install numpy), and is included with most third-party distributions of Python. The numerical extensions have been quasi-official in the sense that at least 3 language enhancements have been make for their use. Nearly all real-world scientific, financial, and neural-network Python programs are build on top of numpy. When a Python program spend 95% of the time in the optimized compiled C routines, it is nearly as fast as a 100% C solution. The reason people use Python instead of C for the other 5% is to save human time. Even when it come to executing the pure Python solutions, the CLBG rules apparently require the slowest execution possible. Execution would be at least 2 to 5 times faster if compilation to machine code were allowed, either before or during execution. But the point of the game is to provide a 'level' playing field for competition between Python programmers, even if the cost is to cripple comparison with other language solution. Terry Jan Reedy -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Research paper "Energy Efficiency across Programming Languages: How does energy, time, and memory relate?"
On Sun, Sep 17, 2017 at 4:00 PM, Terry Reedy wrote: > The numerical extensions have been quasi-official in the sense that at least > 3 language enhancements have been make for their use. I know about the matrix multiplication operator. What are the other two (or more)? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Research paper "Energy Efficiency across Programming Languages: How does energy, time, and memory relate?"
On 9/17/2017 2:04 AM, Chris Angelico wrote: On Sun, Sep 17, 2017 at 4:00 PM, Terry Reedy wrote: The numerical extensions have been quasi-official in the sense that at least 3 language enhancements have been make for their use. I know about the matrix multiplication operator. What are the other two (or more)? Stride slicing, which later became valid in regular code, and Ellipsis. (I could be wrong on the latter.) -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Old Man Yells At Cloud
Chris Angelico wrote: Or machine code on every CPU I've ever worked with. Dividing integers yields an integer. Every machine language I've used has different sets of instructions for int and float arithmetic, so there's no chance of confusion. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Old Man Yells At Cloud
Paul Rubin wrote: Python 2 does something reasonable I don't agree. It might be reasonable in a statically-typed language, but in a dynamically-typed language where you're encouraged to use ints as stand-ins for integer-valued floats, it's an invitation for trouble. There are good reasons it was changed in Python 3. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
