Re: GUIs - A Modest Proposal

[Gabriele Lanaro]

I'd really like to s/tkinter/WxWidgets/g, the multiplatformness is (almost)
the same but wx looks infinitely better. IMHO a good intention is to best
the API of wx.
Anyway, GUI programmers usually choose the toolkit (often 3rd party) more
appropriate for the situation, wether it is or not in the standard library,
to cite again Java, python interface looks generally better than Java ones
because of this "freedom" of choicing the appropriate GUI.

Personally If I'll have to develop a windows GUI I will use IronPython
(choosing a different python implementation!).

My 2 cents

2010/6/6 Michael Torrie 

> On 06/05/2010 08:22 PM, ant wrote:
> > WxPython and PyGtk are both powerful, but quirky in different ways.
> > PyQt is tied to one platform. And there are dozens more.
>
> In what way is PyQt (or the new PySide bindings) tied to one platform?
> PyQt is "native" on Win32, Mac, and Linux.  Would your universal GUI be
> any less quirky?
>
> > I ask the group; should we try to create a new GUI for Python, with
> > the following properties?:
> > 
> > - Comprehensive, for complicated things - Cross-platform
> Most GUI toolkits currently are, to some degree or another.  Qt is the
> most comprehensive cross-platform toolkit that I know of.  You can
> pretty much do any application operation using its API.
>
> > - Looks good (to be defined)
> Does that mean it looks native?  Should it be native?  Does not the
> Tkinter gui look "good?"
>
> I can think of at least the following reasons why a new universal GUI
> for Python will have acceptance issues:
>  - stuck with the lowest common denominator of functionality on each
> platform if you thunk to native widgets (a la wxWidgets)
>  - often look and feel is not quite native even when using native themes
> (GTK on windows, for example)
>  - if you take the Java Swing approach, you'll look out of place
> everywhere, which is kind of where tkinter is now.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Lie Ryan]

On 06/06/10 12:22, ant wrote:
> I get the strong feeling that nobody is really happy with the state of
> Python GUIs.
> Tkinter is not widely liked, but is widely distributed. WxPython and
> PyGtk are both
> powerful, but quirky in different ways. PyQt is tied to one platform.
> And there are
> dozens more.
> 
> Whether or not we like graphics programming, it's not going to go
> away. I get the
> uneasy feeling whenever I start a new project that there should be a
> 'better' GUI
> than the ones I currently use (WxPython and PyGtk).
> 
> Fragmentation is our enemy. Our resources are being dissipated. Is it
> not time to
> start again? We have shown that it is possible to do the right thing,
> by creating Python3.
> 
> I ask the group; should we try to create a new GUI for Python, with
> the following
> properties?:
> 
> - Pythonic
> - The default GUI (so it replaces Tkinter)
> - It has the support of the majority of the Python community
> - Simple and obvious to use for simple things
> - Comprehensive, for complicated things
> - Cross-platform
> - Looks good (to be defined)
> - As small as possible in its default form
> 
> If so, what are the next steps?
> 
> The Python SIG on GUIs closed years ago. Should that be revived?
> 
> This is "A Modest Proposal" (J. Swift). In a sense, I am suggesting
> that
> we eat our own babies.
> 
> But don't we owe it to the community?

Pick any two:
- Simple
- Beautiful
- Cross-platform
-- 
http://mail.python.org/mailman/listinfo/python-list

ANN: PiCloud cloud library 1.9 release

[Ken Elkabany]

PiCloud, a cloud computing platform for the Python Programming Language, has
released version 1.9 of its client library, cloud. PiCloud enables Python
users to leverage the power of an on-demand, high performance, and auto
scaling compute cluster with as few as three lines of code! No server
management necessary. You can find out more here: http://www.picloud.com

What's New:
* Store your data files on the cloud using our cloud.files interface!
* Greatly reduced the cloud library's memory and cpu usage when sending
large data.
* Map jobs begin processing before cloud.map() returns--large
performance gains.
* Persistent user processes has in many cases reduced function overhead
by over 50%.
* Increased network protocol reliability.
* Profiling is now disabled by default, but can be enabled with the
_profile keyword.
* Bug fixes, and much more!

Full service description:
PiCloud is a cloud computing platform that integrates into the Python
Programming Language. It enables you to leverage the compute power of Amazon
Web Services without having to manage, maintain, or configure virtual
servers.

PiCloud integrates seamlessly into your existing code base through a custom
Python library, cloud. To offload the execution of a function to the cloud,
all you must do is pass your desired function into the cloud library.
PiCloud will then run the function on its high-performance and
automatically-scaling cluster. We quickly scale our server capacity to meet
your computational needs, and only charge you for the resources you actually
consume. Getting on the cloud has never been this easy!

PiCloud improves the full cycle of software development and deployment.
Functions that are run on PiCloud have their resource usage monitored,
performance analyzed, and errors traced; we further aggregate all your
functions to give you a bird's eye view of your service. Through these
introspective capabilities, PiCloud enables you to develop faster, easier,
and smarter.

Common use cases for our platform:
* Scientific computing
* Video and image encoding
* Statistical analysis of data sets
* Real-time data processing
* Charts and graphs generation

Cheers,

Ken Elkabany
PiCloud, Inc.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py_single_input and the side-effects...

[moerchendiser2k3]

thx, thats it! :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Stef Mientki]

Aren't all programms going webbased in the near future ?
And if so, wouldn't it be better to hook to GWT or something like that
(I can't oversee all the conesquences)?
cheers,
Stef Mientki

On 06-06-2010 04:22, ant wrote:
> I get the strong feeling that nobody is really happy with the state of
> Python GUIs.
> Tkinter is not widely liked, but is widely distributed. WxPython and
> PyGtk are both
> powerful, but quirky in different ways. PyQt is tied to one platform.
> And there are
> dozens more.
>
> Whether or not we like graphics programming, it's not going to go
> away. I get the
> uneasy feeling whenever I start a new project that there should be a
> 'better' GUI
> than the ones I currently use (WxPython and PyGtk).
>
> Fragmentation is our enemy. Our resources are being dissipated. Is it
> not time to
> start again? We have shown that it is possible to do the right thing,
> by creating Python3.
>
> I ask the group; should we try to create a new GUI for Python, with
> the following
> properties?:
>
> - Pythonic
> - The default GUI (so it replaces Tkinter)
> - It has the support of the majority of the Python community
> - Simple and obvious to use for simple things
> - Comprehensive, for complicated things
> - Cross-platform
> - Looks good (to be defined)
> - As small as possible in its default form
>
> If so, what are the next steps?
>
> The Python SIG on GUIs closed years ago. Should that be revived?
>
> This is "A Modest Proposal" (J. Swift). In a sense, I am suggesting
> that
> we eat our own babies.
>
> But don't we owe it to the community?
>   

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Steven D'Aprano]

On Sun, 06 Jun 2010 12:42:30 +0200, Stef Mientki wrote:

> Aren't all programms going webbased in the near future ? 


Yes, just wait until somebody builds a web-browser that runs in your web-
browser!


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Replace in large text file ?

[Eknath Venkataramani]

On Sat, Jun 5, 2010 at 1:23 PM, Steve  wrote:

>
> Remove all comma's
> Replace all @ with comma's
> Save as a new file.
>

Why don't you use 'sed'. It'd be way faster
-- 
Eknath Venkataramani
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Petite Abeille]

On Jun 6, 2010, at 12:52 PM, Steven D'Aprano wrote:

> Yes, just wait until somebody builds a web-browser that runs in your web-
> browser!

There you go:

"A good browser should be able to reproduce itself. Safari 4, built entirely 
with valid HTML5 and CSS3."

http://general-metrics.com/Safari/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Lie Ryan]

On 06/06/10 22:09, Petite Abeille wrote:
> 
> On Jun 6, 2010, at 12:52 PM, Steven D'Aprano wrote:
> 
>> Yes, just wait until somebody builds a web-browser that runs in your web-
>> browser!
> 
> There you go:
> 
> "A good browser should be able to reproduce itself. Safari 4, built entirely 
> with valid HTML5 and CSS3."
> 

Can't wait to see "Download Firefox for Chrome OS"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Irmen de Jong]

On 6-6-2010 14:32, Lie Ryan wrote:

On 06/06/10 22:09, Petite Abeille wrote:


On Jun 6, 2010, at 12:52 PM, Steven D'Aprano wrote:


Yes, just wait until somebody builds a web-browser that runs in your web-
browser!


There you go:

"A good browser should be able to reproduce itself. Safari 4, built entirely with 
valid HTML5 and CSS3."



Can't wait to see "Download Firefox for Chrome OS"


That would mean that Chrome OS *is* Firefox, because Firefox is written in 
itself...
Just open the following URL in Firefox to see proof of that:
chrome://browser/content/browser.xul

Irmen
--
http://mail.python.org/mailman/listinfo/python-list

Re: Where's the List?

[Victor Subervi]

On Sat, Jun 5, 2010 at 4:52 PM, Stephen Hansen wrote:

>
> cur.execute(sql, [pkg, prodid, tmpTable, quantity] +
> list(option_values))
>
> Or:
>
>cur.execute(sql, (pkg, prodid, tmpTable, quantity) + option_values)
>
> I removed the explicit conversion-to-tuple in the first, because... you
> don't need to. Execute takes a sequence. It doesn't have to be a tuple. A
> list is fine. In the second one, I just build my first arguments as a tuple
> instead of as a list, and then add option_values to it... You'll just have
> to go up top and do:
>
> option_values = ()
>
> In both places where you currently use []. As you can't add a list to a
> tuple anymore then a tuple to a list, for the same reasons.
>

Thanks. I always get tripped up on lists and tuples. In fact, just now I
decided to look up the difference again, it's so slight. At any rate, I
deliberately checked my variables using isinstance() and they all checked
out as tuples, so that's why I couldn't figure out where the list was!
Thanks again,
beno
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Colin J. Williams]

On 05-Jun-10 23:03 PM, Benjamin Peterson wrote:

ant  uklinux.net>  writes:


  PyQt is tied to one platform.


What do you mean one platform?





Source Packages

This is the latest stable version of PyQt4.
PyQt-x11-gpl-4.7.3.tar.gz   Linux, UNIX source
PyQt-win-gpl-4.7.3.zip  Windows source
PyQt-mac-gpl-4.7.3.tar.gz   MacOS/X source

Colin W.

--
http://mail.python.org/mailman/listinfo/python-list

Re: [RELEASE] Python 2.7 release candidate 1 released

[Franck Ditter]

Just an advice as I see that "old" Python is maintained.
When starting with Python (simple programs and GUIs) should I start
with Python 3.x ? If it has a decent implementation on Mac/Linux/Windows of 
course...
Thanks,

   franck
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Joshua Kordani]

"Yo dawg I heard you like browsers, so we put a browser in your browser 
so you can browse while you browse!"  -- Xibit


On 6/6/2010 8:52 AM, Irmen de Jong wrote:

On 6-6-2010 14:32, Lie Ryan wrote:

On 06/06/10 22:09, Petite Abeille wrote:


On Jun 6, 2010, at 12:52 PM, Steven D'Aprano wrote:


Yes, just wait until somebody builds a web-browser that runs in your
web-
browser!


There you go:

"A good browser should be able to reproduce itself. Safari 4, built
entirely with valid HTML5 and CSS3."



Can't wait to see "Download Firefox for Chrome OS"


That would mean that Chrome OS *is* Firefox, because Firefox is written
in itself...
Just open the following URL in Firefox to see proof of that:
chrome://browser/content/browser.xul

Irmen

--
http://mail.python.org/mailman/listinfo/python-list

store .png file in a script

[Navid Parvini]

Dear All,

Would you please let me know that how can I 
store a .png or .gif or .jpg file, in a python script? 

Thank you in advance.

Navid



  -- 
http://mail.python.org/mailman/listinfo/python-list

Re: [RELEASE] Python 2.7 release candidate 1 released

[Aahz]

In article ,
Franck Ditter   wrote:
>
>When starting with Python (simple programs and GUIs) should I start
>with Python 3.x ? 

That depends on the extent to which you rely strictly on the standard
Python library.  If there's any likelihood that you will want to use
random third-party libraries, you probably want to stick with 2.x; ditto
if you want to rely on your users having their own copy of Python (in
which case you probably should target Python 2.4).
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra
-- 
http://mail.python.org/mailman/listinfo/python-list

Forcing any output (file / stdout) to UTF-8

[News123]

Hi,

I'm having a small python script printing out UTF-8 characters.

# -*- coding: utf-8 -*-
print sys.stdout.encoding
s=u"abcdéfg" # string containing one non ASCII character
 # just in case nntp kills it
for c in s:
print c


It work perfectly fine on my utf-8 capable terminal.


However when trying to redirect its output or to just pipe it through
more, then the application fails with

'ascii' codec can't encode character u'\xe9' in position 0: ordinal not
in range(128), as encoding has been switched to none.

because sys.stdout.encoding is now None


The same problem would also occur if I had written directly to a file.

So my qusetion are:
- How can I force the encoding of stdout to a certain encoding. (UTF-8)

- How can I configure the default encoding of any file to be opened to
UTF-8?


Thanks for any suggestions or other ideas how you solve the problem.

A current workaround for forcing UTF-8 output for all output to stdout
could be:

class UtfStdOut():
def write(self,data):
sys.__stdout__.write(data.encode('UTF-8'))
sys.stdout = UtfStdOut()


but I wonder if there's something better









-- 
http://mail.python.org/mailman/listinfo/python-list

Re: store .png file in a script

[Ian Kelly]

On Sun, Jun 6, 2010 at 8:28 AM, Navid Parvini  wrote:
>
> Dear All,
>
> Would you please let me know that how can I store a .png or .gif or .jpg 
> file, in a python script?
>
> Thank you in advance.
>
> Navid

Encode it in base64 and store it in a triple-quoted string literal:

import base64

png_data = """
iVBORw0KGgoNSUhEUgEBCAIAAACQd1PeAXNSR0IArs4c
6QlwSFlzAAALEwAACxMBAJqcGAd0SU1FB9oGBg40CoQ7CHYZ
dEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIEdJTVBXgQ4XDElEQVQI12P4
//8/AAX+Av7czFnnAElFTkSuQmCC
"""
png = base64.b64decode(png_data)

Cheers,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list

Sniffer Linux with Raw Socket

[castor91]

Hi all, i try to make a python sniffer for linux using raw socket and not
pcap or scapy.. But i have a lot of problems..
I use the code that i found here:
http://docs.python.org/library/socket.html


import socket
# the public network interfaceHOST = socket.gethostbyname(socket.gethostname())
# create a raw socket and bind it to the public interfaces =
socket.socket(socket.AF_INET, socket.SOCK_RAW,
socket.IPPROTO_IP)s.bind((HOST, 0))
# Include IP headerss.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1)
# receive all packagess.ioctl(socket.SIO_RCVALL, socket.RCVALL_ON)
# receive a packageprint s.recvfrom(65565)
# disabled promiscuous modes.ioctl(socket.SIO_RCVALL, socket.RCVALL_OFF)

but the attribute "ioctl" is only for windows platform... and also i must
replace "socket.IPPROTO_IP" with "9" because it doesn't work ( i found the
answer in a web topic)

How do i ???

Thanks and sorry for bad english.

--castor91
-- 
http://mail.python.org/mailman/listinfo/python-list

Drop Table w/ MySQLdb?

[Victor Subervi]

Hi;
I tried this:

cursor.execute('drop table tmp%s', tmpTable)

and got this error:

Traceback (most recent call last):
  File "/var/www/html/angrynates.com/cart/cart.py", line 196, in ?
cart()
  File "/var/www/html/angrynates.com/cart/cart.py", line 189, in cart
cursor.execute('drop table tmp%s', tmpTable)
  File "/usr/lib64/python2.4/site-packages/MySQLdb/cursors.py", line 163, in
execute
self.errorhandler(self, exc, value)
  File "/usr/lib64/python2.4/site-packages/MySQLdb/connections.py", line 35,
in defaulterrorhandler
raise errorclass, errorvalue
ProgrammingError: (1064, "You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right syntax to
use near ''127541158007'' at line 1")

But when I print that statement out (exchanging the comma for a %) and
manually enter it:

mysql> drop table tmp127541158007;
Query OK, 0 rows affected (0.00 sec)

I am able to successfully drop the table. Why?
TIA,
beno
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sniffer Linux with Raw Socket

[Giampaolo Rodolà]

RAW sockets are not recommended for doing such kind of things.
It is a lot easier and portable using libpcap.
Python has a lot of libpcap bindings you can use (pcapy, pypcap, etc...).
Just google for it.


--- Giampaolo
http://code.google.com/p/pyftpdlib
http://code.google.com/p/psutil

2010/6/6 castor91 :
> Hi all, i try to make a python sniffer for linux using raw socket and not
> pcap or scapy.. But i have a lot of problems..
> I use the code that i found here:
> http://docs.python.org/library/socket.html
>
> import socket
>
> # the public network interface
> HOST = socket.gethostbyname(socket.gethostname())
>
> # create a raw socket and bind it to the public interface
> s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_IP)
> s.bind((HOST, 0))
>
> # Include IP headers
> s.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1)
>
> # receive all packages
> s.ioctl(socket.SIO_RCVALL, socket.RCVALL_ON)
>
> # receive a package
> print s.recvfrom(65565)
>
> # disabled promiscuous mode
> s.ioctl(socket.SIO_RCVALL, socket.RCVALL_OFF)
>
> but the attribute "ioctl" is only for windows platform... and also i must
> replace "socket.IPPROTO_IP" with "9" because it doesn't work ( i found the
> answer in a web topic)
> How do i ???
> Thanks and sorry for bad english.
> --castor91
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[python]

Why not a GUI based on HTML, CSS and Javascript?

To paraphrase another poster and to borrow from SQLite:

Pick any *THREE*:
- Simple
- Beautiful
- Cross-platform

Malcolm
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[python]

> Yes, just wait until somebody builds a web-browser that runs in your 
> web-browser!

 ?

Malcolm
-- 
http://mail.python.org/mailman/listinfo/python-list

map is useless!

[rantingrick]

Everyone knows i'm a Python fanboy so nobody can call me a troll for
this...

Python map is just completely useless. For one it so damn slow why
even bother putting it in the language? And secondly, the total "girl-
man" weakness of lambda renders it completely mute!

Ruby has a very nice map

>>> [1,2,3].map{|x| x.to_s}

Have not done any benchmarking but far more useful from the
programmers POV. And that really stinks because map is such a useful
tool it's a shame to waste it. Here are some test to back up the rant.


>>> import time
>>> def test1():
l = range(1)
t1 = time.time()
map(lambda x:x+1, l)
t2= time.time()
print t2-t1


>>> def test2():
l = range(1)
t1 = time.time()
for x in l:
x + 1
t2 = time.time()
print t2-t1


>>> test1()
0.0029346008
>>> test2()
0.00027520752
>>> def test3():
l = range(1)
t1 = time.time()
map(str, l)
t2= time.time()
print t2-t1


>>> def test4():
l = range(1)
t1 = time.time()
for x in l:
str(x)
t2= time.time()
print t2-t1


>>> test3()
0.0032098083
>>> test4()
0.0034850159
>>>

So can anyone explain this poor excuse for a map function? Maybe GVR
should have taken it out in 3.0?  *scratches head*

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Drop Table w/ MySQLdb?

[James Mills]

On Mon, Jun 7, 2010 at 1:07 AM, Victor Subervi  wrote:
> Hi;
> I tried this:
>
>     cursor.execute('drop table tmp%s', tmpTable)
>
> and got this error:
>
> Traceback (most recent call last):
>   File "/var/www/html/angrynates.com/cart/cart.py", line 196, in ?
>     cart()
>   File "/var/www/html/angrynates.com/cart/cart.py", line 189, in cart
>     cursor.execute('drop table tmp%s', tmpTable)
>   File "/usr/lib64/python2.4/site-packages/MySQLdb/cursors.py", line 163, in
> execute
>     self.errorhandler(self, exc, value)
>   File "/usr/lib64/python2.4/site-packages/MySQLdb/connections.py", line 35,
> in defaulterrorhandler
>     raise errorclass, errorvalue
> ProgrammingError: (1064, "You have an error in your SQL syntax; check the
> manual that corresponds to your MySQL server version for the right syntax to
> use near ''127541158007'' at line 1")
>
> But when I print that statement out (exchanging the comma for a %) and
> manually enter it:
>
> mysql> drop table tmp127541158007;
> Query OK, 0 rows affected (0.00 sec)
>
> I am able to successfully drop the table. Why?

If I remember correctly, you should use '?', eg:

cursor.execute("DROP TABLE ?", my_table)

cheers
James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[James Mills]

On Mon, Jun 7, 2010 at 1:16 AM, rantingrick  wrote:
> So can anyone explain this poor excuse for a map function? Maybe GVR
> should have taken it out in 3.0?  *scratches head*

Let me get this straight... You're complaining about some trivial
code you've written and a 0.002 or less execution time ?

I must be missing something!

--James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[rantingrick]

On Jun 5, 9:22 pm, ant  wrote:

> I ask the group; should we try to create a new GUI for Python, with
> the following
> properties?:
>
> - Pythonic
> - The default GUI (so it replaces Tkinter)
> - It has the support of the majority of the Python community
> - Simple and obvious to use for simple things
> - Comprehensive, for complicated things
> - Cross-platform
> - Looks good (to be defined)
> - As small as possible in its default form

Yes i one hundred percent agree! The only problem is i am the only
one! Good luck finding others to climb into this boat. From the
beginning there has has been this really weird love-hate relationship
with Tkinter in the Python community. I myself experience this
emotional attachment every day as i wish for Tkinter to be more
"pretty" and "feature-rich" whilst at the same time loving it's
simplicity. Tkinter seems to be Python's whipping boy and nobody wants
to whip another, so we are stuck in limbo with a lobotomy.

Heres an idea though, why not expand Tkinter with some new really cool
widgets...? Hmmm...? That TIX package is a real PITA and could use a
re-write. Can you believe it took until py3.0 for Tkinter to get a
combobox :-O! Yea i know! :'-(



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Drop Table w/ MySQLdb?

[MRAB]

Victor Subervi wrote:

Hi;
I tried this:

cursor.execute('drop table tmp%s', tmpTable)

and got this error:

Traceback (most recent call last):
  File "/var/www/html/angrynates.com/cart/cart.py 
", line 196, in ?

cart()
  File "/var/www/html/angrynates.com/cart/cart.py 
", line 189, in cart

cursor.execute('drop table tmp%s', tmpTable)
  File "/usr/lib64/python2.4/site-packages/MySQLdb/cursors.py", line 
163, in execute

self.errorhandler(self, exc, value)
  File "/usr/lib64/python2.4/site-packages/MySQLdb/connections.py", line 
35, in defaulterrorhandler

raise errorclass, errorvalue
ProgrammingError: (1064, "You have an error in your SQL syntax; check 
the manual that corresponds to your MySQL server version for the right 
syntax to use near ''127541158007'' at line 1")


But when I print that statement out (exchanging the comma for a %) and 
manually enter it:


mysql> drop table tmp127541158007;
Query OK, 0 rows affected (0.00 sec)

I am able to successfully drop the table. Why?


As has been explained already, SQL might not (and here it clearly does
not) let you use placeholders for table or column names, only for
values.

Build the SQL statement with placeholders for the values (any values
which aren't constants) and then execute the SQL statement, passing the
values so that .execute performs the substitution itself.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Drop Table w/ MySQLdb?

[Victor Subervi]

On Sun, Jun 6, 2010 at 11:40 AM, MRAB  wrote:

>  As has been explained already, SQL might not (and here it clearly does
> not) let you use placeholders for table or column names, only for
> values.
>

Oops. Sorry. Thanks.
beno
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Drop Table w/ MySQLdb?

[James Mills]

On Mon, Jun 7, 2010 at 1:40 AM, MRAB  wrote:
> As has been explained already, SQL might not (and here it clearly does
> not) let you use placeholders for table or column names, only for
> values.

Yes I should have stated that '?' place-holders are used only for
"values" :) *sigh*

--James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Alf P. Steinbach]

* pyt...@bdurham.com, on 06.06.2010 17:17:

Why not a GUI based on HTML, CSS and Javascript?

To paraphrase another poster and to borrow from SQLite:

Pick any *THREE*:
- Simple
- Beautiful
- Cross-platform


I'm not sure what this discussion is about, but anyway, modern GUI frameworks 
/are/ based on XML, CSS and some code behind, which may be JavaScript or other 
language.


In particular Mozilla's XUL is based on XML, CSS and JavaScript, and Microsoft's 
whatever-its-name is based on XML, CSS and, as I understand it, your choice of 
programming language for the code behind.


I have done some XUL programming (a few Thunderbird extensions) but I haven't 
tried the Microsoft stuff since even their XML text editor, when I first looked 
at it, required minimum 512 MiB of RAM, and that was years ago; presumably the 
modern version of that MS XML text editor now requires 16 GiB or more RAM...



Cheers,

- Alf

--
blog at http://alfps.wordpress.com>
--
http://mail.python.org/mailman/listinfo/python-list

Re: Missing DLL in win98

[Martin v. Loewis]

Am 04.06.2010 14:38, schrieb Spyder42:

I hope this is the right place to ask this, and appologise if it's
not. I'm trying to install 2.6.5 in Win98 se final. It says "a
required dll could not be run". Do I have to upgrade my whole OS just
to install this, or is there a fix I can apply to 98 to make it work.


There is no fix. IIUC, it (actually) complains about some symbols 
missing from kernel32.dll (perhaps in addition to some DLLs missing).


Yes, you do have to upgrade your whole OS just to install this.

Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python Forum

[Monte Milanuk]

On 6/5/10 10:11 PM, Aahz wrote:

In article,
Monte Milanuk  wrote:


Decent NNTP access is harder to find.  Not impossible, but no longer
a 'free' part of most standard ISP access any more.


This seems like a good time to promote my ISP: panix.com


Used to have an account with them... but of less value to someone on 
local fiber with an essentially static IP and their own Linux server.


--
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[Roald de Vries]

On Jun 6, 2010, at 5:16 PM, rantingrick wrote:

Everyone knows i'm a Python fanboy so nobody can call me a troll for
this...

Python map is just completely useless. For one it so damn slow why
even bother putting it in the language? And secondly, the total "girl-
man" weakness of lambda renders it completely mute!

Ruby has a very nice map


[1,2,3].map{|x| x.to_s}


Have not done any benchmarking but far more useful from the
programmers POV. And that really stinks because map is such a useful
tool it's a shame to waste it. Here are some test to back up the rant.



import time
def test1():

l = range(1)
t1 = time.time()
map(lambda x:x+1, l)
t2= time.time()
print t2-t1



def test2():

l = range(1)
t1 = time.time()
for x in l:
x + 1
t2 = time.time()
print t2-t1



test1()

0.0029346008

test2()

0.00027520752

def test3():

l = range(1)
t1 = time.time()
map(str, l)
t2= time.time()
print t2-t1



def test4():

l = range(1)
t1 = time.time()
for x in l:
str(x)
t2= time.time()
print t2-t1



test3()

0.0032098083

test4()

0.0034850159




So can anyone explain this poor excuse for a map function? Maybe GVR
should have taken it out in 3.0?  *scratches head*


Use list comprehension. It's nicer than Ruby's map:

[x.to_s for x in 1, 2, 3]

--
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[Duncan Booth]

rantingrick  wrote:

> Python map is just completely useless. For one it so damn slow why
> even bother putting it in the language? And secondly, the total "girl-
> man" weakness of lambda renders it completely mute!

Do you realise that you don't have to use lambda? If you need more than a 
single expression just create a named function.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: store .png file in a script

[Adam Tauno Williams]

Just base64 encode the file, store it as a string in the file, and decode it to 
a byte-stream when you need the image.  Everything required to do that is in 
the standard library.
>Would you please let me know that how can I 
>store a .png or .gif or .jpg file, in a python script? 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Forum

[Aahz]

In article ,
Monte Milanuk   wrote:
>On 6/5/10 10:11 PM, Aahz wrote:
>> In article,
>> Monte Milanuk  wrote:
>>>
>>> Decent NNTP access is harder to find.  Not impossible, but no longer
>>> a 'free' part of most standard ISP access any more.
>>
>> This seems like a good time to promote my ISP: panix.com
>
>Used to have an account with them... but of less value to someone on 
>local fiber with an essentially static IP and their own Linux server.

Less perhaps, but I prefer to rely on someone else's sysadmin and I
really don't want to allow remote connections into my home network.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[Alain Ketterlin]

rantingrick  writes:

> Python map is just completely useless. [...]

 import time
 def test1():
>   l = range(1)
>   t1 = time.time()
>   map(lambda x:x+1, l)
>   t2= time.time()
>   print t2-t1
 def test2():
>   l = range(1)
>   t1 = time.time()
>   for x in l:
>   x + 1
>   t2 = time.time()
>   print t2-t1
>
 test1()
> 0.0029346008
 test2()
> 0.00027520752
 def test3():

Well, not building the resulting list saves some time. But even if you
do r.append(x+1) map appears to be slower...

Try this:

def test3():
l = range(1)
t1 = time.time()
[ x+1 for x in l]
t2 = time.time()
print t2-t1

I've not used map since I learned about list comprehensions.

-- Alain.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[Shashwat Anand]

map is not needed. LC is great :D

On Sun, Jun 6, 2010 at 10:32 PM, Alain Ketterlin <
al...@dpt-info.u-strasbg.fr> wrote:

> rantingrick  writes:
>
> > Python map is just completely useless. [...]
>
>  import time
>  def test1():
> >   l = range(1)
> >   t1 = time.time()
> >   map(lambda x:x+1, l)
> >   t2= time.time()
> >   print t2-t1
>  def test2():
> >   l = range(1)
> >   t1 = time.time()
> >   for x in l:
> >   x + 1
> >   t2 = time.time()
> >   print t2-t1
> >
>  test1()
> > 0.0029346008
>  test2()
> > 0.00027520752
>  def test3():
>
> Well, not building the resulting list saves some time. But even if you
> do r.append(x+1) map appears to be slower...
>
> Try this:
>
> def test3():
>l = range(1)
>t1 = time.time()
> [ x+1 for x in l]
> t2 = time.time()
>print t2-t1
>
> I've not used map since I learned about list comprehensions.
>
> -- Alain.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What's a good XSL to translate xmlrunner.py output into a test report?

[Phlip]

On Jun 3, 9:47 am, Phlip  wrote:
> Hypo Nt:
>
> Here's xmlrunner.py:
>
>  http://www.rittau.org/python/xmlrunner.py
>
> you attach it to your developer tests, and it emits a file called
> "TEST-unittest.TestSuite.xml", containing auspicious wackiness like
> this:
>
>    classname="tests.unit.gateways.authorize_net_tests.AuthorizeNetTests"
> name="test_failed_credit" time="0.0017">
>    classname="tests.unit.gateways.authorize_net_tests.AuthorizeNetTests"
> name="test_fraudulent_avs_result" time="0.0010">
>    classname="tests.unit.gateways.authorize_net_tests.AuthorizeNetTests"
> name="test_fraudulent_cvv_result" time="0.0011">
>
> That looks just like the kind of stereotypical XML thatXSLwas
> designed to convert into HTML, for civilian reading! All the verbiage
> for XML test runners claim they do JUnit output, so that JUnitXSL
> files can convert them into HTML.
>
> So here's a sample JUNIT.XSL:
>
> http://www.google.com/codesearch/p?hl=en#T32D24pjTaw/trunk/test-integ...
>
> It contains matchers like these:
>
>   
>
> And when I run it with this command line...
>
>    xsltproc JUNIT.XSLTEST-unittest.TestSuite.xml
>
> ...it outputs nothing!
>
> Long story short, how do I format my test output prettily? All the
> bloggage on this seems to assume that everyone already knows this
> because _everyone_ graduated to Python thru Java...

Bump? Anyone reporting on their unit tests here?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Forum

[rantingrick]

On Jun 2, 3:04 am, pyDev  wrote:
> Hello,
>
> I would like to let the community know that there is a new web-based
> forum for Python enthusiasts over at PythonForum.org (http://
> pythonforum.org).


There has been many arguments here for and against Usenet. Personally
I say the rein of Usenet is coming to its logical conclusion. Dead as
a clavo! Much better interfaces abound. But most importantly the
newbies are never aware of Usenet for some time (sadly).

Some would say keeping out the baby noobs is a good thing, i could not
disagree more! I ask of you, what is this group for if not to help the
very noobs you wish to keep out? Without the banner of help the only
flag left to fly is that of a troll fest nation.

I have seen even the most tangential issues linger on and on in
perpetual infantile poop tossing contests that only the following
thirsty orangutan could hold his candle to...

http://www.youtube.com/watch?v=6DBuk91phkI&feature=related

...notice the url on separate line.

Yes the die is cast people, the new generation awaits to claim their
stakes in the footholds of Pythonia. This is the natural course of
things really. But the old timers will linger for some time hashing
and re hashing old war stories that fall on placid ears.

Yes my friends, Rock n Roll is dead, Elvis has left the building,
Johnny's no longer here (or there), and whilst Usenet is not quite yet
dead, it is rapidly approaching putrefaction on the on the grapevine
of history.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[rantingrick]

On Jun 6, 12:02 pm, Alain Ketterlin 
wrote:
> rantingrick  writes:
> I've not used map since I learned about list comprehensions.

Thats has been my experienced also. Actually i've been at Python for
O... about 2 years now and i don't think i've ever used map in a
script even one time until a month or so ago. After a few unit tests
it seems i was right all along. But the funny thing is in other
languages i use map all the time. It's just too awkward in Python and
i wish it were not so... Oh well?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Forum

[Monte Milanuk]

On 6/6/10 9:46 AM, Aahz wrote:

but I prefer to rely on someone else's sysadmin and I
really don't want to allow remote connections into my home network.


To each their own... while Panix is fairly relaxed as a shell host, I 
prefer to not have someone else telling me what I can and can't install 
or use, especially when I'm paying.  To be honest I can't SSH out from 
work anymore, so the remote connections / static IP is somewhat of a 
moot point.  What I was trying to say was I don't get the point of 
paying for an account on a provider clear across the country simply for 
the sake of getting Usenet access... especially when more and more large 
institutions are shutting theirs down (i.e. the death knoll for usenet 
as others have pointed out).  Perhaps it would count for 'geek' points, 
but I'm not too worried about that ;)


YMMV,

Monte
--
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[rantingrick]

On Jun 6, 10:51 am, "Alf P. Steinbach"  wrote:
> * pyt...@bdurham.com, on 06.06.2010 17:17:
>
> > Why not a GUI based on HTML, CSS and Javascript?
>
> > To paraphrase another poster and to borrow from SQLite:
>
> > Pick any *THREE*:
> > - Simple
> > - Beautiful
> > - Cross-platform
>
> I'm not sure what this discussion is about, but anyway, modern GUI frameworks
> /are/ based on XML, CSS and some code behind, which may be JavaScript or other
> language.

> - Alf


Oh Please lets not help user in the age of "take-over-my-puter--all-my-
data, and-my-freedoms, and-then-force-me-to-be-a-slave-to-you-just-so-
i-can-use-my-data, with-your-permission, master!" era. Yes i have seen
these GUI, HTML, CSS, Javascript freaks of nature and lament them
daily! What a nightmare! Give me a good ole GUI and get the hell outta
my way!

~>:^(
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Petite Abeille]

On Jun 6, 2010, at 7:36 PM, rantingrick wrote:

> Oh Please lets not help user in the age of "take-over-my-puter--all-my-
> data, and-my-freedoms, and-then-force-me-to-be-a-slave-to-you-just-so-
> i-can-use-my-data, with-your-permission, master!" era. Yes i have seen
> these GUI, HTML, CSS, Javascript freaks of nature and lament them
> daily! What a nightmare! Give me a good ole GUI and get the hell outta
> my way!

Resistance is futile. You will be assimilated.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Forum

[Aahz]

In article ,
Monte Milanuk   wrote:
>On 6/6/10 9:46 AM, Aahz wrote:
>>
>> but I prefer to rely on someone else's sysadmin and I
>> really don't want to allow remote connections into my home network.
>
>To each their own... while Panix is fairly relaxed as a shell host, I 
>prefer to not have someone else telling me what I can and can't install 
>or use, especially when I'm paying.  To be honest I can't SSH out from 
>work anymore, so the remote connections / static IP is somewhat of a 
>moot point.  

And that is one reason why Panix is helpful (assuming your work does
simple port blocking and they don't have a formal policy banning SSH):

starfury:~> ssh -p 80 panix1.panix.com
a...@panix.com's Password:

>What I was trying to say was I don't get the point of paying for
>an account on a provider clear across the country simply for the
>sake of getting Usenet access... especially when more and more large
>institutions are shutting theirs down (i.e. the death knoll for usenet
>as others have pointed out).  Perhaps it would count for 'geek' points,
>but I'm not too worried about that ;)

Obviously, I don't use Panix only for Usenet, but Usenet is still a large
part of my social life.  I have no idea what I'll do when Usenet really
starts dying.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Mark Lawrence]

On 06/06/2010 16:31, rantingrick wrote:

On Jun 5, 9:22 pm, ant  wrote:


I ask the group; should we try to create a new GUI for Python, with
the following
properties?:

- Pythonic
- The default GUI (so it replaces Tkinter)
- It has the support of the majority of the Python community
- Simple and obvious to use for simple things
- Comprehensive, for complicated things
- Cross-platform
- Looks good (to be defined)
- As small as possible in its default form


Yes i one hundred percent agree! The only problem is i am the only
one! Good luck finding others to climb into this boat. From the
beginning there has has been this really weird love-hate relationship
with Tkinter in the Python community. I myself experience this
emotional attachment every day as i wish for Tkinter to be more
"pretty" and "feature-rich" whilst at the same time loving it's
simplicity. Tkinter seems to be Python's whipping boy and nobody wants
to whip another, so we are stuck in limbo with a lobotomy.

Heres an idea though, why not expand Tkinter with some new really cool
widgets...? Hmmm...? That TIX package is a real PITA and could use a
re-write. Can you believe it took until py3.0 for Tkinter to get a
combobox :-O! Yea i know! :'-(

Patches are welcome at any time.  I look forward to seeing your first 
contribution.


Kindest regards.

Mark Lawrence.



--
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[Lie Ryan]

On 06/07/10 03:22, rantingrick wrote:
> On Jun 6, 12:02 pm, Alain Ketterlin 
> wrote:
>> rantingrick  writes:
>> I've not used map since I learned about list comprehensions.
> 
> Thats has been my experienced also. Actually i've been at Python for
> O... about 2 years now and i don't think i've ever used map in a
> script even one time until a month or so ago. After a few unit tests
> it seems i was right all along. But the funny thing is in other
> languages i use map all the time. It's just too awkward in Python and
> i wish it were not so... Oh well?

In the most naive uses, map appears to have no advantage over list
comprehension; but one thing that map can do that list comprehension
still can't do without a walk around the park:

def foo(func, args):
g = lambda x: x+1
return [func(g, x) for x in args]

foo(map, [[4, 6, 3], [6, 3, 2], [1, 3, 5]])

I'm not going to argue how often that would be useful though.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [RELEASE] Python 2.7 release candidate 1 released

[Lie Ryan]

On 06/07/10 00:05, Franck Ditter wrote:
> Just an advice as I see that "old" Python is maintained.
> When starting with Python (simple programs and GUIs) should I start
> with Python 3.x ? If it has a decent implementation on Mac/Linux/Windows of 
> course...

I say, if you're learning the language and/or programming, python 3 is a
nicer to start with. However, as of now, not many third party libraries
has been ported to python 3.x yet; so if you're writing a real
application and you're expecting to use many third party libraries, then
stick with python 2.x.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[Thomas Jollans]

On 06/06/2010 05:16 PM, rantingrick wrote:
> So can anyone explain this poor excuse for a map function? Maybe GVR
> should have taken it out in 3.0?  *scratches head*
>
>   
Speaking of Py3k: map no longer builds lists. What once was map is no
more, what once was itertools.imap is now map.

Sometimes Py2.x map is useful, sometimes list comprehension is nicer.
Sometimes Py3.x map / Py2.x itertools.imap is useful, sometimes
generator expressions are more elegant.



Same goes for filter, by the way.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Drop Table w/ MySQLdb?

[Thomas Jollans]

On 06/06/2010 05:07 PM, Victor Subervi wrote:
> Hi;
> I tried this:
>
> cursor.execute('drop table tmp%s', tmpTable)

It looks like you're trying to %s-insert *part* of the table name. I
doubt any DB interface allows that. cursor.execute('drop table %s',
table_name) might work, otherwise, you'll have to write the query
yourself, in full.

>
> and got this error:
>
> Traceback (most recent call last):
>   File "/var/www/html/angrynates.com/cart/cart.py
> ", line 196, in ?
> cart()
>   File "/var/www/html/angrynates.com/cart/cart.py
> ", line 189, in cart
> cursor.execute('drop table tmp%s', tmpTable)
>   File "/usr/lib64/python2.4/site-packages/MySQLdb/cursors.py", line
> 163, in execute
> self.errorhandler(self, exc, value)
>   File "/usr/lib64/python2.4/site-packages/MySQLdb/connections.py",
> line 35, in defaulterrorhandler
> raise errorclass, errorvalue
> ProgrammingError: (1064, "You have an error in your SQL syntax; check
> the manual that corresponds to your MySQL server version for the right
> syntax to use near ''127541158007'' at line 1")
>
> But when I print that statement out (exchanging the comma for a %) and
> manually enter it:
>
> mysql> drop table tmp127541158007;
> Query OK, 0 rows affected (0.00 sec)
>
> I am able to successfully drop the table. Why?
> TIA,
> beno

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[Richard Thomas]

Python's map has the useful feature that nobody is in any doubt about
what it does. I don't know much about Ruby I have to say but looking
at that piece of syntax you gave I had no idea how to interpret it.
Anyway, I looked it up.

Calling an method on each of a collection of objects is best
accomplished without map. It is semantically different to mapping a
function over a set.

As far as speed goes, Python has an overhead for making a function
call which means that its often faster to use a for loop. It seems
like a rather small difference in speed though and if what you want to
do is semantically a map you should write it is a map thereby making
your code read like what it does. If it later turns out to slow down
your program too much optimise it then.

In your second pair of tests the map is faster because str is a
builtin and doesn't have that overhead. Additionally the name 'str' is
only looked up once rather than 1 times. :-)

Richard.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[D'Arcy J.M. Cain]

On Mon, 07 Jun 2010 05:27:43 +1000
Lie Ryan  wrote:
> In the most naive uses, map appears to have no advantage over list
> comprehension; but one thing that map can do that list comprehension
> still can't do without a walk around the park:
> 
> def foo(func, args):
> g = lambda x: x+1
> return [func(g, x) for x in args]
> 
> foo(map, [[4, 6, 3], [6, 3, 2], [1, 3, 5]])

foo = lambda x: [y + 1 for y in x]
[foo(x) for x in [[4, 6, 3], [6, 3, 2], [1, 3, 5]]]

Didn't seem like such a long walk.

-- 
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Replace in large text file ?

[Nobody]

On Sat, 05 Jun 2010 16:35:42 +0100, MRAB wrote:

>>> In plain language what I wish to do is:
>>>
>>> Remove all comma's
>>> Replace all @ with comma's

>> input_file = open("some_huge_file.txt", "r")
>> output_file = open("newfilename.txt", "w")
>> for line in input_file:

> I'd probably process it in larger chunks:
> 
>  CHUNK_SIZE = 1024 ** 2 # 1MB at a time
>  input_file = open("some_huge_file.txt", "r")
>  output_file = open("newfilename.txt", "w")
>  while True:
>  chunk = input_file.read(CHUNK_SIZE)

This is fine for the exact problem at hand. The moment the problem evolves
into replacing a sequence of two or more characters, processing
line-by-line eliminates the problem where the chunk boundary occurs in the
middle of the sequence.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[Lie Ryan]

On 06/07/10 05:54, D'Arcy J.M. Cain wrote:
> On Mon, 07 Jun 2010 05:27:43 +1000
> Lie Ryan  wrote:
>> In the most naive uses, map appears to have no advantage over list
>> comprehension; but one thing that map can do that list comprehension
>> still can't do without a walk around the park:
>>
>> def foo(func, args):
>> g = lambda x: x+1
>> return [func(g, x) for x in args]
>>
>> foo(map, [[4, 6, 3], [6, 3, 2], [1, 3, 5]])
> 
> foo = lambda x: [y + 1 for y in x]
> [foo(x) for x in [[4, 6, 3], [6, 3, 2], [1, 3, 5]]]
> 
> Didn't seem like such a long walk.
> 

that's because you're simplifying the problem, the correct walk is:

def foo(func, args):
g = lambda x: x+1
return [func(g, x) for x in args]

foo((lambda g, a: [g(x) for x in a]), [[4, 6, 3], [6, 3, 2], [1, 3, 5]])
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[rantingrick]

On Jun 6, 2:48 pm, Richard Thomas  wrote:
> Python's map has the useful feature that nobody is in any doubt about
> what it does. I don't know much about Ruby I have to say but looking
> at that piece of syntax you gave I had no idea how to interpret it.
> Anyway, I looked it up.

Well Ruby likes to pass block in the form { ...expression... }. I
don't really care for the braces but the map is more natural in Ruby

>>> array = [1,2,3].map{|x| x.to_s}
>>> array
['1', '2', '3']
>>> array.length
3
>>> 'abc'.map{|x| x.upcase}.join
'ABC'

#-- as in python you do the nested thing --#

>>> lst = map(str, [1,2,3])
>>> lst
['1', '2', '3']
>>> len(lst)
3
>>> ''.join(map(string.upper, 'abc'))
'ABC'

Thats the only thing that bother me about Python. But in Ruby the
sky's the limit since you pass a block. And no need for that clunky
lambda.

I think Guido and Matz need to set down for a cup of joe fire up their
interpretors and exchange thoughts about language design. Some awesome
synergy could come of it and maybe even create the next best
language.

Guido can teach Matz about the importance of forced indention over
braces, docstrings, command line help, explicitly calling functions/
method, perfect keyword naming, __specialmethodnames__, the Python
Zen! And Matz can show Guido how to build a better lambda and map
functions and more syntactically correct OOP style.

Just ideas folks ;)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[rantingrick]

On Jun 6, 2:06 pm, Mark Lawrence  wrote:
> On 06/06/2010 16:31, rantingrick wrote:
>
>
>
> > On Jun 5, 9:22 pm, ant  wrote:
>
> >> I ask the group; should we try to create a new GUI for Python, with
> >> the following
> >> properties?:
>
> >> - Pythonic
> >> - The default GUI (so it replaces Tkinter)
> >> - It has the support of the majority of the Python community
> >> - Simple and obvious to use for simple things
> >> - Comprehensive, for complicated things
> >> - Cross-platform
> >> - Looks good (to be defined)
> >> - As small as possible in its default form
>
> > Yes i one hundred percent agree! The only problem is i am the only
> > one! Good luck finding others to climb into this boat. From the
> > beginning there has has been this really weird love-hate relationship
> > with Tkinter in the Python community. I myself experience this
> > emotional attachment every day as i wish for Tkinter to be more
> > "pretty" and "feature-rich" whilst at the same time loving it's
> > simplicity. Tkinter seems to be Python's whipping boy and nobody wants
> > to whip another, so we are stuck in limbo with a lobotomy.
>
> > Heres an idea though, why not expand Tkinter with some new really cool
> > widgets...? Hmmm...? That TIX package is a real PITA and could use a
> > re-write. Can you believe it took until py3.0 for Tkinter to get a
> > combobox :-O! Yea i know! :'-(
>
> Patches are welcome at any time.  I look forward to seeing your first
> contribution.
>
> Kindest regards.
>
> Mark Lawrence.

Hello Mark,

Are you maintaining Tkinter or Tix or both? There is a nagging issue
with Tix that needs fixing. Upon subbclassing some widgets and when
using the import Tix and import Tix as *. Maybe it is already fixed in
3.0 (i have not checked) but we need to fix it.

I am still currently rewriting Tkinter Tix and IDLE in my spare time
but got a bit busy lately. Anyhoo, i would really like to bring some
patches, upgrades, and just a general spit shining to the entire three-
plexx so let me know.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[Terry Reedy]

On 6/6/2010 11:16 AM, rantingrick wrote:

Everyone knows i'm a Python fanboy so nobody can call me a troll for
this...


Non sequitor. It depends on your intention in posting this...


Python map is just completely useless. For one it so damn slow


Posting invalid speed comparisons stacked against the feature you are 
dissing is either trollish or lame.


> why even bother putting it in the language?

Map was put into the language about a decade before comprehensions and, 
I believe, zip. It encapsulates a basic functional programming idiom.


Consider the following snippet: (in 2.x, delete 'list(' and ...')'):

from operator import add
l1 = range(10)
l2 = range(15,30)
print(list(map(add, l1, l2)))
# [15, 17, 19, 21, 23, 25, 27, 29, 31, 33]

Now replace map with a for loop, no zip or listcomp or genexp allowed.
Time how long it takes. Do you get it right the first time, as I did 
with the above?. Your replacememt may or may not *run* faster, but even 
if so, it will hardly be enough to make much different in most uses.



Maybe GVR should have taken it out in 3.0?


That may have been considered, but map is shorter than the alternative, 
some prefer it stylistically, it can be passed as a function argument 
(including to functool.partial), and its removal would have broken code 
without much gain. It is also handy for explaing generator expressions 
and comprehensions.


Terry Jan Reedy




--
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Kevin Walzer]

On 6/5/10 10:22 PM, ant wrote:

I get the strong feeling that nobody is really happy with the state of
Python GUIs.


Says who?


Tkinter is not widely liked, but is widely distributed.


I'm a strong advocate of Tkinter--there is very little that it cannot do.

WxPython and

PyGtk are both
powerful, but quirky in different ways. PyQt is tied to one platform.
And there are
dozens more.


Each has its strengths and weaknesses. They reflect the diversity of GUI 
programming in general.




Whether or not we like graphics programming, it's not going to go
away. I get the
uneasy feeling whenever I start a new project that there should be a
'better' GUI
than the ones I currently use (WxPython and PyGtk).


That's debatable. These other toolkits have a decade or more of 
development behind them. How are you going to improve on them?


Fragmentation is our enemy. Our resources are being dissipated. Is it
not time to
start again? We have shown that it is possible to do the right thing,
by creating Python3.


I'd say no. I used to be frustrated with the range of GUI options for 
Python, but the issue was just to get started. I found Tkinter to be 
useful for me, I was productive in it, and I have stayed with that.




I ask the group; should we try to create a new GUI for Python, with
the following
properties?:

- Pythonic
- The default GUI (so it replaces Tkinter)
- It has the support of the majority of the Python community
- Simple and obvious to use for simple things
- Comprehensive, for complicated things
- Cross-platform
- Looks good (to be defined)
- As small as possible in its default form


These goals are not all complementary. In fact, some of them, such as 
"small" and "comprehensive," are mutually exclusive. Tkinter is pretty 
small; people complain it lacks things. PyQt and wxPython are pretty 
comprehensive; people complain about their learning curve.


The very diversity of GUI toolkits came into effect because Python is 
very easy to extend and integrate with other C/C++ libraries. Writing a 
GUI toolkit from scratch is much, much harder. Even a simple toolkit 
like Tk has twenty years of developer-hours behind it. Do you really 
think the Python community will be able to a) agree on the design of a 
new toolkit to replace Tkinter and b) implement the code in a timely 
fashion across multiple platforms? It sounds like an impossible goal to me.


--Kevin

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[ant]

On Jun 6, 2:22 pm, ant  wrote:
> I get the strong feeling that nobody is really happy with the state of
> Python GUIs.


What an interesting set of responses I got!
And - even more interesting - how few of them actually seem to think
there is a problem, let
alone make any attempt to move the situation forward.
I appreciate that there are proponents of many different GUIs. I am
asking that all step back
from their particular interests and - for example - try to see the
situation from the viewpoint of
- say - a Python newbie, or an organisation that is thinking of
switching from (example only!) Visual Basic.

I obviously didn't make my main point clearly enough; I'll restate it
with a different emphasis:
The default GUI shipped with Python is Tkinter.
Few people seem to like it much. This has several consequences.
- It has not blossomed, like Python has.
- There are not hundreds of talented programmers making rapid and
impressive improvements to it.
- Books about Python use it in examples (because it IS the default),
but imply that one should move on.

The result that our hypothetical new recruit has to make a choice for
the new, big project. Remember that
GUIs have hundreds (sometimes thousands) of classes, functions and
constants. Let alone idioms and design
patterns. That is what I meant by 'Our resources are being
dissipated'; the effort of learning, remembering
and relearning a workable subset of these is substantial.
So it would be good to be able to use One Right Way, not try several
(as I have - I will admit I didn't try PyQt;
GUI fatigue was setting in by then).

If we are to make progress, I can see two obvious approaches:
1) Improve Tkinter to the point where it is supportable and supported
by a good fraction of Python programmers
or
2) Drop Tkinter as the default and use something else.

If we choose 2) then we have a new set of possibilities:
2a) Use one of the 'major' GUIs, pretty much as is, but presumably
with a lot more people supporting it if it is the default.
2b) Use one of the 'minor' GUIs, and get a lot of people working on it
to make it really good.
2c) Start from scratch. With a project supported by the Community as a
whole, with the agreed objective of being the default.

None of these is easy. All require strong leadership and great
committment.

What surprises me is the apparent willingness of the Python community
to let this issue slide.
I can see that many people have committed to one GUI and want to use
that forever. Fair enough. For the reasons I stated
originally, I've not found one. I think a lot of people deep down are
uneasy about this.

My concern is simple: I think that Python is doomed to remain a minor
language unless we crack this problem.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[geremy condra]

On Sun, Jun 6, 2010 at 3:55 PM, ant  wrote:
> On Jun 6, 2:22 pm, ant  wrote:
>> I get the strong feeling that nobody is really happy with the state of
>> Python GUIs.
> 
>
> What an interesting set of responses I got!
> And - even more interesting - how few of them actually seem to think
> there is a problem, let
> alone make any attempt to move the situation forward.
> I appreciate that there are proponents of many different GUIs. I am
> asking that all step back
> from their particular interests and - for example - try to see the
> situation from the viewpoint of
> - say - a Python newbie, or an organisation that is thinking of
> switching from (example only!) Visual Basic.
>
> I obviously didn't make my main point clearly enough; I'll restate it
> with a different emphasis:
> The default GUI shipped with Python is Tkinter.
> Few people seem to like it much. This has several consequences.
> - It has not blossomed, like Python has.
> - There are not hundreds of talented programmers making rapid and
> impressive improvements to it.
> - Books about Python use it in examples (because it IS the default),
> but imply that one should move on.
>
> The result that our hypothetical new recruit has to make a choice for
> the new, big project. Remember that
> GUIs have hundreds (sometimes thousands) of classes, functions and
> constants. Let alone idioms and design
> patterns. That is what I meant by 'Our resources are being
> dissipated'; the effort of learning, remembering
> and relearning a workable subset of these is substantial.
> So it would be good to be able to use One Right Way, not try several
> (as I have - I will admit I didn't try PyQt;
> GUI fatigue was setting in by then).
>
> If we are to make progress, I can see two obvious approaches:
> 1) Improve Tkinter to the point where it is supportable and supported
> by a good fraction of Python programmers
> or
> 2) Drop Tkinter as the default and use something else.
>
> If we choose 2) then we have a new set of possibilities:
> 2a) Use one of the 'major' GUIs, pretty much as is, but presumably
> with a lot more people supporting it if it is the default.
> 2b) Use one of the 'minor' GUIs, and get a lot of people working on it
> to make it really good.
> 2c) Start from scratch. With a project supported by the Community as a
> whole, with the agreed objective of being the default.
>
> None of these is easy. All require strong leadership and great
> committment.

I take it you're volunteering?

Geremy Condra
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[Steven D'Aprano]

On Sun, 06 Jun 2010 08:16:02 -0700, rantingrick wrote:

> Everyone knows i'm a Python fanboy so nobody can call me a troll for
> this...

The first rule of trolling is, always deny being a troll, no matter how 
obvious the trolling. But on the chance I'm wrong, and for the benefit of 
others, your tests don't measure what you think they are measuring and 
consequently your results are invalid. Read on.


> Python map is just completely useless. For one it so damn slow why even
> bother putting it in the language? And secondly, the total "girl- man"
> weakness of lambda renders it completely mute!

Four trolls in three sentences. Way to go "fanboy".

(1) "Completely" useless? It can't do *anything*?

(2) Slow compared to what?

(3) Are you implying that map relies on lambda?

(4) What's wrong with lambda anyway?

By the way, nice sexist description there. "Girl-man weakness" indeed. 
Does your mum know that you are so contemptuous about females?



> Ruby has a very nice map

I'm thrilled for them. Personally I think the syntax is horrible.

 
 [1,2,3].map{|x| x.to_s}
> 
> Have not done any benchmarking 

"... but by counting under my breath while the code runs, I'm POSITIVE 
Ruby is much faster that Python!"

By complaining about Python being too slow while admitting that you 
haven't actually tested the speed of your preferred alternative, you have 
*negative* credibility.


> but far more useful from the programmers
> POV. And that really stinks because map is such a useful tool it's a
> shame to waste it. Here are some test to back up the rant.
> 
> 
 import time
 def test1():
>   l = range(1)
>   t1 = time.time()
>   map(lambda x:x+1, l)
>   t2= time.time()
>   print t2-t1

That's a crappy test.

(1) You include the cost of building a new function each time.

(2) You make no attempt to protect against the inevitable variation in 
speed caused by external processes running on a modern multi-process 
operating system.

(3) You are reinventing the wheel (badly) instead of using the timeit 
module.


 def test2():
>   l = range(1)
>   t1 = time.time()
>   for x in l:
>   x + 1
>   t2 = time.time()
>   print t2-t1

The most obvious difference is that in test1, you build a 10,000 item 
list, while in test2, you don't. And sure enough, not building a list is 
faster than building a list:

 test1()
> 0.0029346008
 test2()
> 0.00027520752



 def test3():
>   l = range(1)
>   t1 = time.time()
>   map(str, l)
>   t2= time.time()
>   print t2-t1
> 
> 
 def test4():
>   l = range(1)
>   t1 = time.time()
>   for x in l:
>   str(x)
>   t2= time.time()
>   print t2-t1
> 
> 
 test3()
> 0.0032098083
 test4()
> 0.0034850159


Look ma, not building a list is still faster than building a list!


> So can anyone explain this poor excuse for a map function? Maybe GVR
> should have taken it out in 3.0?  *scratches head*


So, let's do some proper tests. Using Python 2.6 on a fairly low-end 
desktop, and making sure all the alternatives do the same thing:

>>> from timeit import Timer
>>> t1 = Timer('map(f, L)', 'f = lambda x: x+1; L = range(1)')
>>> t2 = Timer('''accum = []
... for item in L:
... accum.append(f(item))
...
... ''', 'f = lambda x: x+1; L = range(1)')
>>>
>>> min(t1.repeat(number=1000))
3.5182700157165527
>>> min(t2.repeat(number=1000))
6.702117919921875

For the benefit of those who aren't used to timeit, the timings at the 
end are the best-of-three of repeating the test code 1000 times. The time 
per call to map is 3.5 milliseconds compared to 6.7 ms for unrolling it 
into a loop and building the list by hand. map is *much* faster.

How does it compare to a list comprehension? The list comp can avoid a 
function call and do the addition inline, so it will probably be 
significantly faster:

>>> t3 = Timer('[x+1 for x in  L]', "L = range(1)")
>>> min(t3.repeat(number=1000))
2.0786428451538086

And sure enough it is. But when you can't avoid the function call, the 
advantage shifts back to map:

>>> t4 = Timer('map(str, L)', "L = range(1)")
>>> t5 = Timer('[str(x) for x in  L]', "L = range(1)")
>>> min(t4.repeat(number=1000))
3.8360331058502197
>>> min(t5.repeat(number=1000))
6.6693520545959473



Lessons are:

(1) If you're going to deny being a troll, avoid making inflammatory 
statements unless you can back them up.

(2) Understand what you are timing, and don't compare apples to snooker 
balls just because they're both red.

(3) Timing tests are hard to get right. Use timeit.

(4) map is plenty fast.


Have a nice day.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[D'Arcy J.M. Cain]

On Mon, 07 Jun 2010 05:59:02 +1000
Lie Ryan  wrote:
> > foo = lambda x: [y + 1 for y in x]
> > [foo(x) for x in [[4, 6, 3], [6, 3, 2], [1, 3, 5]]]
> > 
> > Didn't seem like such a long walk.
> > 
> 
> that's because you're simplifying the problem, the correct walk is:

Well, since it gives the same answer and you didn't actually state the
problem I'm not sure how you can make that statement.

Show me the unit test that defines the problem.

-- 
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: save xls to csv/dbf without Excel/win32com.client

[noydb]

On Jun 5, 9:31 pm, Tim Chase  wrote:
> On 06/05/2010 06:47 PM, noydb wrote:
>
> > Is there a way to save a .xls file (the first worksheet) as a .dbf
> > or .csv without opening an instance of Excel with win32com.client
> > (been awhile, is this the best module these days for v2.5)?  In case a
> > computer does not have Excel (2007) installed.
>
> Use the "xlrd" module[1]
>
> 
> import csv
> import xlrd
>
> FILE_NAME = 'example.xls'
> wb = xlrd.open_workbook(FILE_NAME)
>
> for name in wb.sheet_names():
>    out = file('%s.csv' % name, 'wb')
>    writer = csv.writer(out)
>    sheet = wb.sheet_by_name(name)
>    for row in xrange(sheet.nrows):
>      writer.writerow([
>        sheet.cell_value(row, col)
>        for col in xrange(sheet.ncols)
>        ])
>    out.close()
> #
>
> You say you only want the first sheet, so adjust accordingly.
>
> -tkc
>
> [1]http://pypi.python.org/pypi/xlrd/

Many thanks Tim, this worked well!

In the interest of learning, anyone have a XLS to DBF solution?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[AD.]

On Jun 7, 10:55 am, ant  wrote:
> My concern is simple: I think that Python is doomed to remain a minor
> language unless we crack this problem.

I'm curious why you think fragmented GUI choices is a particular
problem for Python compared to other languages? Or why this is the
main issue holding Python back?

As far as I can tell, most of the other cross platform dynamic open
source languages (eg Perl, Ruby, PHP, Javascript) face the same
problem or don't even include a GUI toolkit. The one exception I can
think of that has a non-fragmented native GUI option is Tcl (which
being Tk is slightly ironic here), but it hasn't stopped Tcl being
doomed to be a much more minor language than Python is.

.NET/C# has had preferred GUI APIs come and go and isn't exactly what
I'd call crossplatform, Java has had (and still does?) multiple
toolkits, C/C++ never included any to begin with.

Objective C has an obvious native GUI choice, but it's not at all
crossplatform and is about as 'minor' a language as Python is anyway.
Legacy VB and Delphi had built in GUIs but they weren't really cross
platform and seem to be slipping out of relevance.

Looking at the state of other languages and their GUI toolkit
landscape, someone might even come to the conclusion that having one
true GUI toolkit is potentially a bad thing for a language.

I don't do any GUI coding so I don't have any toolkit preferences
myself, but I think the only sane way to address your concerns is to
incrementally improve Tkinter. Coming up with a new toolkit from
scratch is insanity, and switching the toolkit to something else
doesn't actually help much (ie you don't think any are currently
suitable anyway) and is just as likely to annoy other people.

--
Cheers
Anton
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Forum

[Ben Finney]

rantingrick  writes:

> There has been many arguments here for and against Usenet. Personally
> I say the rein of Usenet is coming to its logical conclusion. Dead as
> a clavo! Much better interfaces abound.

So you say. For the interface to be “better” it needs to keep the good
features of the existing interface. I include among the good features of
Usenet:

* No need for creating a new identity; my email address is enough.

* No need for balkanising my identity; messages cross to all
  participating Usenet servers.

* Forums are kept distinct, but the easy option to cross-post is there
  when appropriate.

* The forums don't live in any single server or organisation, and new
  servers in different organisations can be added to carry the load of
  distributed messaging, so there is no machine nor organisation acting
  as single point of failure.

* A single program allows me to subscribe to one, dozens, hundreds, or
  thousands of forums, and use exactly the same interface to participate
  two-way in all of them.

* I can replace that single program with any other program that follows
  the open standards, and the same messaging interface applies exactly.

Where is the “much better interface” that improves on all of that?

-- 
 \ “If nature has made any one thing less susceptible than all |
  `\others of exclusive property, it is the action of the thinking |
_o__)  power called an idea” —Thomas Jefferson |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[Lie Ryan]

On 06/07/10 09:56, D'Arcy J.M. Cain wrote:
> On Mon, 07 Jun 2010 05:59:02 +1000
> Lie Ryan  wrote:
>>> foo = lambda x: [y + 1 for y in x]
>>> [foo(x) for x in [[4, 6, 3], [6, 3, 2], [1, 3, 5]]]
>>>
>>> Didn't seem like such a long walk.
>>>
>>
>> that's because you're simplifying the problem, the correct walk is:
> 
> Well, since it gives the same answer and you didn't actually state the
> problem I'm not sure how you can make that statement.
> 
> Show me the unit test that defines the problem.

that you must use foo() and you can't change foo() (since foo is very
complex), and you give the same result as the original solution.


def solution(lst):
# make changes here only
return foo(map, lst)

def foo(func, args):
g = lambda x: x+1
return [func(g, x) for x in args]

import unittest
@unittest.FunctionTestCase
def test():
lst = [[4, 6, 3], [6, 3, 2], [1, 3, 5]]
ans = [[5, 7, 4], [7, 4, 3], [2, 4, 6]]
test.assertEqual(solution(lst), ans)

test.runTest()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Forum

[D'Arcy J.M. Cain]

On Mon, 07 Jun 2010 10:17:39 +1000
Ben Finney  wrote:
> So you say. For the interface to be “better” it needs to keep the good
> features of the existing interface. I include among the good features of
> Usenet:

That's a great list of features.  But they all apply to mailing lists as
well.

> * No need for creating a new identity; my email address is enough.

Obviously true for mailing lists.

> * No need for balkanising my identity; messages cross to all
>   participating Usenet servers.

Ditto.  Also, good word.  I usually use "ghetto" when talking about FB,
MS, etc.  Same idea.

> * Forums are kept distinct, but the easy option to cross-post is there
>   when appropriate.

Ditto although I'm not sure that this is a feature.  Mailing lists
sometimes have options to prevent this which might be a good thing.  In
any case, it's nice to be able to choose on a list by list basis.

> * The forums don't live in any single server or organisation, and new
>   servers in different organisations can be added to carry the load of
>   distributed messaging, so there is no machine nor organisation acting
>   as single point of failure.

As with mailing lists but MLs allow even better distribution.  With
Usenet the hubs still have to carry every group.  With mailing lists
only the servers involved need to carry it.  I guess the trade-off with
mailling lists is that you get one point of failure for a particular ML
but distribute the load much better.

> * A single program allows me to subscribe to one, dozens, hundreds, or
>   thousands of forums, and use exactly the same interface to participate
>   two-way in all of them.

Yes.  This is probably my second biggest issue with forums.
Ghettoization (balkanization) is number one.

> * I can replace that single program with any other program that follows
>   the open standards, and the same messaging interface applies exactly.

With mail that is also true.  In addition, its a program that you
already have if you have email.

> Where is the “much better interface” that improves on all of that?

I have always been a big fan of Usenet.  I was using it back when you
could subscribe and almost read every group.  For a while I was
a hub and downloaded the entire distribution to my little home
computer.  Binaries, what the heck is that? But I just gave it up a long
time ago.  Mailing lists just made so much more sense to me.  I now run
a number of mailing lists.  I can't even run a news server on my own
little ISP any more and have to contract out.

In fact, my biggest complaint with this mailing list is that it
gateways to Usenet.  That's where most of the spam on this list comes
from albeit the bulk of that is Google groups which I can easily filter
out.

By the way, what is the generic term for Usenet groups, mailing lists
and forums?  They all have a common overall purpose and it seems as if
there should be a word.

Hey, we could all go back to FIDO-Net.  :-)

-- 
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Adam Tauno Williams]

On Sun, 2010-06-06 at 17:03 -0700, AD. wrote:
> On Jun 7, 10:55 am, ant  wrote:
> > My concern is simple: I think that Python is doomed to remain a minor
> > language unless we crack this problem.
> I'm curious why you think fragmented GUI choices is a particular
> problem for Python compared to other languages? Or why this is the
> main issue holding Python back?

The base assumption is: there is some core issue holding Python back?  

Nah.

> .NET/C# has had preferred GUI APIs come and go and isn't exactly what
> I'd call crossplatform, 

Well, if you use Gtk# for your GUI it is probably one of the [if not
"the"] most cross-platform development solution for complex fat-clients.

> Looking at the state of other languages and their GUI toolkit
> landscape, someone might even come to the conclusion that having one
> true GUI toolkit is potentially a bad thing for a language.

+1  In the end the relationships with GUI toolkits is far more about
tool-chain and documentation then it is about language.  If there was an
awesome IDE that allowed RAD [of real complex applications] in toolkit X
then people will use toolkit X.   [Monodevelop and it's awesome Gtk#
support for Mono/.NET is a good example;  the tool makes the toolkit
east to use - people go with the toolkit].


-- 
Adam Tauno Williams  LPIC-1, Novell CLA

OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Adam Tauno Williams]

On Sun, 2010-06-06 at 15:55 -0700, ant wrote:
> On Jun 6, 2:22 pm, ant  wrote:
> > I get the strong feeling that nobody is really happy with the state of
> > Python GUIs.
> 
> What an interesting set of responses I got!
> And - even more interesting - how few of them actually seem to think
> there is a problem, let
> alone make any attempt to move the situation forward.
> I appreciate that there are proponents of many different GUIs. I am
> asking that all step back
> from their particular interests and - for example - try to see the
> situation from the viewpoint of
> - say - a Python newbie, or an organisation that is thinking of
> switching from (example only!) Visual Basic.

Taking a step back ^H ... H... yep, no issue here.

> The result that our hypothetical new recruit has to make a choice for
> the new, big project. Remember that
> GUIs have hundreds (sometimes thousands) of classes, functions and
> constants. Let alone idioms and design
> patterns.

Yes - this is the natural and *unavoidable* consequence of
"comprehensive". 

"Those who do not reuse, are doomed to reinvent."  And reinvention
includes rediscovering the exact same problems.

>  That is what I meant by 'Our resources are being
> dissipated'; the effort of learning, remembering
> and relearning a workable subset of these is substantial.
> So it would be good to be able to use One Right Way, not try several
> (as I have - I will admit I didn't try PyQt;
> GUI fatigue was setting in by then).

This isn't a language issue;  it is a tool-chain issue.  Get a better
IDE.

-- 
Adam Tauno Williams  LPIC-1, Novell CLA

OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[D'Arcy J.M. Cain]

On Mon, 07 Jun 2010 10:16:19 +1000
Lie Ryan  wrote:
> On 06/07/10 09:56, D'Arcy J.M. Cain wrote:
> > Show me the unit test that defines the problem.
> 
> that you must use foo() and you can't change foo() (since foo is very
> complex), and you give the same result as the original solution.

I reject the artificial restriction.  If foo has a proper unit test I
can refactor it any time I want.  If it doesn't then step one is to add
the missing unit tests.

In any case, the problem should be stated in terms of input and
output.  That's the client requrements.  Enforcing the solution is a
homework assignment, not a real requirements specification.

> def solution(lst):
> # make changes here only
> return foo(map, lst)

OK, so I can make changes here.  My change would not use foo.

-- 
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[Carl Banks]

On Jun 6, 8:16 am, rantingrick  wrote:
> Everyone knows i'm a Python fanboy so nobody can call me a troll for
> this...

1. I don't remember you so I don't know if you're a Python fanboy or
not
2. If you act like a troll I'll call you one even if you are Python
fanboy

Actually, your post only came off as slightly trollish, so you have
that.


> Python map is just completely useless. For one it so damn slow why
> even bother putting it in the language? And secondly, the total "girl-
> man" weakness of lambda renders it completely mute!
>
> Ruby has a very nice map
>
> >>> [1,2,3].map{|x| x.to_s}
>
> Have not done any benchmarking but far more useful from the
> programmers POV. And that really stinks because map is such a useful
> tool it's a shame to waste it. Here are some test to back up the rant.
>
> >>> import time
> >>> def test1():
>
>         l = range(1)
>         t1 = time.time()
>         map(lambda x:x+1, l)
>         t2= time.time()
>         print t2-t1
>
> >>> def test2():
>
>         l = range(1)
>         t1 = time.time()
>         for x in l:
>                 x + 1
>         t2 = time.time()
>         print t2-t1
>
> >>> test1()
> 0.0029346008
> >>> test2()
> 0.00027520752
> >>> def test3():
>
>         l = range(1)
>         t1 = time.time()
>         map(str, l)
>         t2= time.time()
>         print t2-t1
>
> >>> def test4():
>
>         l = range(1)
>         t1 = time.time()
>         for x in l:
>                 str(x)
>         t2= time.time()
>         print t2-t1
>
>
>
> >>> test3()
> 0.0032098083
> >>> test4()
> 0.0034850159
>
> So can anyone explain this poor excuse for a map function? Maybe GVR
> should have taken it out in 3.0?  *scratches head*

Since you claim to be a Python Fanboy, you probably know that you can
type "import this" at a Python prompt, and it brings up a list of
principles that guide the design of the language.

Tell me, do you see "Fast is better than slow" in that list?  No?
Well that's your answer.

(The technical answer is that map isn't slow, function call overhead
is.)


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Forum

[Lie Ryan]

On 06/07/10 10:45, D'Arcy J.M. Cain wrote:
> On Mon, 07 Jun 2010 10:17:39 +1000
> Ben Finney  wrote:
>> So you say. For the interface to be “better” it needs to keep the good
>> features of the existing interface. I include among the good features of
>> Usenet:
> 
> That's a great list of features.  But they all apply to mailing lists as
> well.

I think Ben Finney was making comparison between Usenet/Mailing-List vs
Forum. The argument basically sums up to Distributed vs. Centralized.

>> Where is the “much better interface” that improves on all of that?
> 
> I have always been a big fan of Usenet.  I was using it back when you
> could subscribe and almost read every group.  For a while I was
> a hub and downloaded the entire distribution to my little home
> computer.  Binaries, what the heck is that? But I just gave it up a long
> time ago.  Mailing lists just made so much more sense to me.  I now run
> a number of mailing lists.  I can't even run a news server on my own
> little ISP any more and have to contract out.

My only problem with mailing list is that for large lists, it can easily
overflows my inbox. Having a separate interface (e.g. NNTP) is quite
useful. For large list, I wouldn't be able to read all the posts anyway,
so from time-to-time I'd "Mark Everything as Read", you cannot reliably
do that in your Inbox even with filtering and all that stuffs.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Lie Ryan]

On 06/07/10 10:48, Adam Tauno Williams wrote:
> On Sun, 2010-06-06 at 17:03 -0700, AD. wrote:
>> On Jun 7, 10:55 am, ant  wrote:
>>> My concern is simple: I think that Python is doomed to remain a minor
>>> language unless we crack this problem.
>> I'm curious why you think fragmented GUI choices is a particular
>> problem for Python compared to other languages? Or why this is the
>> main issue holding Python back?
> 
> The base assumption is: there is some core issue holding Python back?  
> 
> Nah.

Any thought about drag-and-drop GUI builder in IDLE?

>> .NET/C# has had preferred GUI APIs come and go and isn't exactly what
>> I'd call crossplatform, 
> 
> Well, if you use Gtk# for your GUI it is probably one of the [if not
> "the"] most cross-platform development solution for complex fat-clients.
> 
>> Looking at the state of other languages and their GUI toolkit
>> landscape, someone might even come to the conclusion that having one
>> true GUI toolkit is potentially a bad thing for a language.
> 
> +1  In the end the relationships with GUI toolkits is far more about
> tool-chain and documentation then it is about language.  If there was an
> awesome IDE that allowed RAD [of real complex applications] in toolkit X
> then people will use toolkit X.   [Monodevelop and it's awesome Gtk#
> support for Mono/.NET is a good example;  the tool makes the toolkit
> east to use - people go with the toolkit].

The problem with the current GUI toolkits is their API is designed to be
cross-language (i18n). I'd say, keep the current GUI toolkits, make
their API easier to use (l10n).

In other words, current GUI API can be used everywhere (IOW, their API
works well accross many languages); but all those GUI API also feels
foreign everywhere (IOW, their API always feels like borrowed from
another language).

To abuse the language, i18n goal is already achieved, l10n is not met yet.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Forum

[D'Arcy J.M. Cain]

On Mon, 07 Jun 2010 11:02:21 +1000
Lie Ryan  wrote:
> On 06/07/10 10:45, D'Arcy J.M. Cain wrote:
> > That's a great list of features.  But they all apply to mailing lists as
> > well.
> 
> I think Ben Finney was making comparison between Usenet/Mailing-List vs
> Forum. The argument basically sums up to Distributed vs. Centralized.

I don't know what Ben was thinking so I was just making it explicit.

> My only problem with mailing list is that for large lists, it can easily
> overflows my inbox. Having a separate interface (e.g. NNTP) is quite
> useful. For large list, I wouldn't be able to read all the posts anyway,
> so from time-to-time I'd "Mark Everything as Read", you cannot reliably
> do that in your Inbox even with filtering and all that stuffs.

It's trivial to filter into separate folders and trivial to empty a
folder.  For me it's simply "^A" and "Del".

However, it would be nice to have an expire function so that messages
that I don't read for a specified time simply disappear.  Do any email
clients do that?

-- 
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Forum

[Ben Finney]

"D'Arcy J.M. Cain"  writes:

> On Mon, 07 Jun 2010 10:17:39 +1000
> Ben Finney  wrote:
> > So you say. For the interface to be “better” it needs to keep the good
> > features of the existing interface. I include among the good features of
> > Usenet:
>
> That's a great list of features. But they all apply to mailing lists
> as well.

Not quite, though mailing lists certainly have good uses. I agree that
mailing lists share some of the features I listed, but not all. The
points where I disagree are:

> > * No need for creating a new identity; my email address is enough.
>
> Obviously true for mailing lists.

No, since with many mailing lists I must maintain an identity separately
for the specific mailing list: a username + password pair. Sometimes
the username is the email address, which helps; but having to maintain
the identity (or opt out and stupidly use the same password at multiple
sites) is a worse option than Usenet.

So some mailing lists pass, but most fail on this feature.

> > * Forums are kept distinct, but the easy option to cross-post is there
> >   when appropriate.
>
> Ditto although I'm not sure that this is a feature.

Having the option is the feature; it's certainly true that the option
should be exercised only sparingly. But it's not something that should
be prevented by default.

> > * The forums don't live in any single server or organisation, and new
> >   servers in different organisations can be added to carry the load of
> >   distributed messaging, so there is no machine nor organisation acting
> >   as single point of failure.
>
> As with mailing lists but MLs allow even better distribution.

Not even remotely true. Mailing list transport and archiving is
generally maintained at a single site. With Usenet forums, these tasks
are distributed between all participating machines, in different nations
and organisations. Archives are not kept indefinitely in all cases, but
in many cases.

So mailing lists fail this feature.

> I guess the trade-off with mailling lists is that you get one point of
> failure for a particular ML but distribute the load much better.

Right. I'm not saying that there aren't trade-offs; I'm addressing only
the claim that “much better interfaces” exist.

> By the way, what is the generic term for Usenet groups, mailing lists
> and forums? They all have a common overall purpose and it seems as if
> there should be a word.

There is a good word: “forum”. That covers any place (even virtual
places) where people congregate to discuss on an agreed topic. Just
because a new kind of forum has appeared, it doesn't have any special
claim to the word. The existing forums are still forums.

-- 
 \“The fact of your own existence is the most astonishing fact |
  `\you'll ever have to confront. Don't dare ever see your life as |
_o__) boring, monotonous or joyless.” —Richard Dawkins, 2010-03-10 |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: map is useless!

[Terry Reedy]

On 6/6/2010 7:20 PM, Steven D'Aprano wrote:

On Sun, 06 Jun 2010 08:16:02 -0700, rantingrick wrote:


Everyone knows i'm a Python fanboy so nobody can call me a troll for
this...


The first rule of trolling is, always deny being a troll, no matter how
obvious the trolling.


Such as the exagerated-claim subject that ends with an exclamation!


But on the chance I'm wrong, and for the benefit of
others, your tests don't measure what you think they are measuring and
consequently your results are invalid. Read on.


+1 on the rest. Thanks for posting it. I have nothing more to add.

Terry Jan Reedy



Python map is just completely useless. For one it so damn slow why even
bother putting it in the language? And secondly, the total "girl- man"
weakness of lambda renders it completely mute!


Four trolls in three sentences. Way to go "fanboy".

(1) "Completely" useless? It can't do *anything*?

(2) Slow compared to what?

(3) Are you implying that map relies on lambda?

(4) What's wrong with lambda anyway?

By the way, nice sexist description there. "Girl-man weakness" indeed.
Does your mum know that you are so contemptuous about females?




Ruby has a very nice map


I'm thrilled for them. Personally I think the syntax is horrible.



[1,2,3].map{|x| x.to_s}


Have not done any benchmarking


"... but by counting under my breath while the code runs, I'm POSITIVE
Ruby is much faster that Python!"

By complaining about Python being too slow while admitting that you
haven't actually tested the speed of your preferred alternative, you have
*negative* credibility.



but far more useful from the programmers
POV. And that really stinks because map is such a useful tool it's a
shame to waste it. Here are some test to back up the rant.



import time
def test1():

l = range(1)
t1 = time.time()
map(lambda x:x+1, l)
t2= time.time()
print t2-t1


That's a crappy test.

(1) You include the cost of building a new function each time.

(2) You make no attempt to protect against the inevitable variation in
speed caused by external processes running on a modern multi-process
operating system.

(3) You are reinventing the wheel (badly) instead of using the timeit
module.



def test2():

l = range(1)
t1 = time.time()
for x in l:
x + 1
t2 = time.time()
print t2-t1


The most obvious difference is that in test1, you build a 10,000 item
list, while in test2, you don't. And sure enough, not building a list is
faster than building a list:


test1()

0.0029346008

test2()

0.00027520752





def test3():

l = range(1)
t1 = time.time()
map(str, l)
t2= time.time()
print t2-t1



def test4():

l = range(1)
t1 = time.time()
for x in l:
str(x)
t2= time.time()
print t2-t1



test3()

0.0032098083

test4()

0.0034850159



Look ma, not building a list is still faster than building a list!



So can anyone explain this poor excuse for a map function? Maybe GVR
should have taken it out in 3.0?  *scratches head*



So, let's do some proper tests. Using Python 2.6 on a fairly low-end
desktop, and making sure all the alternatives do the same thing:


from timeit import Timer
t1 = Timer('map(f, L)', 'f = lambda x: x+1; L = range(1)')
t2 = Timer('''accum = []

... for item in L:
... accum.append(f(item))
...
... ''', 'f = lambda x: x+1; L = range(1)')


min(t1.repeat(number=1000))

3.5182700157165527

min(t2.repeat(number=1000))

6.702117919921875

For the benefit of those who aren't used to timeit, the timings at the
end are the best-of-three of repeating the test code 1000 times. The time
per call to map is 3.5 milliseconds compared to 6.7 ms for unrolling it
into a loop and building the list by hand. map is *much* faster.

How does it compare to a list comprehension? The list comp can avoid a
function call and do the addition inline, so it will probably be
significantly faster:


t3 = Timer('[x+1 for x in  L]', "L = range(1)")
min(t3.repeat(number=1000))

2.0786428451538086

And sure enough it is. But when you can't avoid the function call, the
advantage shifts back to map:


t4 = Timer('map(str, L)', "L = range(1)")
t5 = Timer('[str(x) for x in  L]', "L = range(1)")
min(t4.repeat(number=1000))

3.8360331058502197

min(t5.repeat(number=1000))

6.6693520545959473



Lessons are:

(1) If you're going to deny being a troll, avoid making inflammatory
statements unless you can back them up.

(2) Understand what you are timing, and don't compare apples to snooker
balls just because they're both red.

(3) Timing tests are hard to get right. Use timeit.

(4) map is plenty fast.


Have a nice day.





--
http://mail.python.org/mailman/listinfo/python-list

Re: save xls to csv/dbf without Excel/win32com.client

[Tim Chase]

On 06/06/2010 06:59 PM, noydb wrote:

On Jun 5, 9:31 pm, Tim Chase  wrote:

[1]http://pypi.python.org/pypi/xlrd/


Many thanks Tim, this worked well!

In the interest of learning, anyone have a XLS to DBF solution?


This becomes considerably trickier unless you're willing to have 
all your DBF fields be CHAR-format rather than their actual 
data-type.  In an Excel file, one column can hold multiple 
data-types (text, numbers, formulas, dates, currency, etc) 
whereas (from my humble understanding) a single column in a DBF 
must be of the same data-type.


That said, if you want to attempt it, I'd suggest using

http://dbfpy.sourceforge.net/

to create the DBF files using code similar to my CSV version 
(which mostly iterates over the Excel workbook and dumps the 
contents to CSV files -- just change it to dump the contents to 
your DBF).


-tkc





--
http://mail.python.org/mailman/listinfo/python-list

Re: Python Forum

[Ben Finney]

"D'Arcy J.M. Cain"  writes:

> On Mon, 07 Jun 2010 11:02:21 +1000
> Lie Ryan  wrote:
> > I think Ben Finney was making comparison between Usenet/Mailing-List
> > vs Forum. The argument basically sums up to Distributed vs.
> > Centralized.
>
> I don't know what Ben was thinking so I was just making it explicit.

You're right, D'Arcy. I don't know exactly what “much better interfaces
[than Usenet]” the poster was thinking of, that's why I listed some of
the features that Usenet has which I don't see improved on in other
interfaces.

Now it's up to those who think such features can be improved upon to
present a non-vapourware system that demonstrably has all of those
features or better.

-- 
 \  “I am too firm in my consciousness of the marvelous to be ever |
  `\   fascinated by the mere supernatural …” —Joseph Conrad, _The |
_o__) Shadow-Line_ |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Adam Tauno Williams]

On Mon, 2010-06-07 at 11:11 +1000, Lie Ryan wrote:
> On 06/07/10 10:48, Adam Tauno Williams wrote:
> > On Sun, 2010-06-06 at 17:03 -0700, AD. wrote:
> >> On Jun 7, 10:55 am, ant  wrote:
> >>> My concern is simple: I think that Python is doomed to remain a minor
> >>> language unless we crack this problem.
> >> I'm curious why you think fragmented GUI choices is a particular
> >> problem for Python compared to other languages? Or why this is the
> >> main issue holding Python back?
> > The base assumption is: there is some core issue holding Python back?  
> > Nah.
> Any thought about drag-and-drop GUI builder in IDLE?

Sure; someone should write one, or several.  That isn't a toolkit issue.

But then I don't know any of the local Python devs who use IDLE;  the
IDE landscape for Python is very fragmented,  which disincentives that
happening.  

> >> .NET/C# has had preferred GUI APIs come and go and isn't exactly what
> >> I'd call crossplatform, 
> > Well, if you use Gtk# for your GUI it is probably one of the [if not
> > "the"] most cross-platform development solution for complex fat-clients.
> >> Looking at the state of other languages and their GUI toolkit
> >> landscape, someone might even come to the conclusion that having one
> >> true GUI toolkit is potentially a bad thing for a language.
> > +1  In the end the relationships with GUI toolkits is far more about
> > tool-chain and documentation then it is about language.  If there was an
> > awesome IDE that allowed RAD [of real complex applications] in toolkit X
> > then people will use toolkit X.   [Monodevelop and it's awesome Gtk#
> > support for Mono/.NET is a good example;  the tool makes the toolkit
> > east to use - people go with the toolkit].
> The problem with the current GUI toolkits is their API is designed to be
> cross-language (i18n). I'd say, keep the current GUI toolkits, make
> their API easier to use (l10n).

Which is 'just' an implementation detail.  Comparing early Gtk#
implementations with current ones - they did a significant amount of
work to make Gtk# more .NET-ish, without rewriting Gtk.  [And PyGtk is
hardly neglected; significant features of GNOME 3 such as Zeitgeist are
Python apps ].  I haven't had a chance
to play with it but
 looks
encouraging.  But that is still far from the depth of functionality
available in .NET and Java toolchains [which, again, has nothing to do
with the specific widget set].


-- 
Adam Tauno Williams  LPIC-1, Novell CLA

OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba

-- 
http://mail.python.org/mailman/listinfo/python-list

Importing modules

[Anthony Papillion]

Hello Everyone,

I'm brand new to Python and have been finding it really easy to get
into. But I've run into my very first problem that I'm hoping someone
here might be able to help me with.

I'm working with the Google Storage API and all of their Python
library is under a directory called $HOME/gsutils/boto

To begin my Python script, I'm support to import boto but that doesn't
work because boto isn't in my search path (or my PYTHONPATH).

So I tried this:

import os

os.path.append('$HOME/gsutils/boto')

thinking I could then successfully do the import boto statement.
Nope.

Can anyone give me some direction on the correct way to import
modules?

Thanks!
Anthony
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Importing modules

[Ben Finney]

Anthony Papillion  writes:

> import os
>
> os.path.append('$HOME/gsutils/boto')
>
> thinking I could then successfully do the import boto statement.
> Nope.

You'll need to give the literal path. Substitution of environment
variables isn't performed implicitly in strings.

-- 
 \ “When we pray to God we must be seeking nothing — nothing.” |
  `\  —Saint Francis of Assisi |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Lie Ryan]

On 06/07/10 12:18, Adam Tauno Williams wrote:
> On Mon, 2010-06-07 at 11:11 +1000, Lie Ryan wrote:
>> On 06/07/10 10:48, Adam Tauno Williams wrote:
>>> On Sun, 2010-06-06 at 17:03 -0700, AD. wrote:
 On Jun 7, 10:55 am, ant  wrote:
> My concern is simple: I think that Python is doomed to remain a minor
> language unless we crack this problem.
 I'm curious why you think fragmented GUI choices is a particular
 problem for Python compared to other languages? Or why this is the
 main issue holding Python back?
>>> The base assumption is: there is some core issue holding Python back?  
>>> Nah.
>> Any thought about drag-and-drop GUI builder in IDLE?
> 
> Sure; someone should write one, or several.  That isn't a toolkit issue.

Sure it is, if it's concerning ease of writing a GUI-based program using
that particular toolkit.

> But then I don't know any of the local Python devs who use IDLE;  the
> IDE landscape for Python is very fragmented,  which disincentives that
> happening.  

I don't use IDLE either, but IDLE comes by default with standard
distribution of python.

 .NET/C# has had preferred GUI APIs come and go and isn't exactly what
 I'd call crossplatform, 
>>> Well, if you use Gtk# for your GUI it is probably one of the [if not
>>> "the"] most cross-platform development solution for complex fat-clients.
 Looking at the state of other languages and their GUI toolkit
 landscape, someone might even come to the conclusion that having one
 true GUI toolkit is potentially a bad thing for a language.
>>> +1  In the end the relationships with GUI toolkits is far more about
>>> tool-chain and documentation then it is about language.  If there was an
>>> awesome IDE that allowed RAD [of real complex applications] in toolkit X
>>> then people will use toolkit X.   [Monodevelop and it's awesome Gtk#
>>> support for Mono/.NET is a good example;  the tool makes the toolkit
>>> east to use - people go with the toolkit].
>> The problem with the current GUI toolkits is their API is designed to be
>> cross-language (i18n). I'd say, keep the current GUI toolkits, make
>> their API easier to use (l10n).
> 
> Which is 'just' an implementation detail.  

Why is a GUI toolkit *API* an *implementation detail*? They seems to be
contradictory to me. The simplicity and ease of use of a library depends
on how well-designed their API is, and how "pythonic" the API appears to
a python programmer (unittest, for example, looks more Java-ish than
pythonic).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Importing modules

[Chris Rebert]

On Sun, Jun 6, 2010 at 8:16 PM, Ben Finney  wrote:
> Anthony Papillion  writes:
>
>> import os
>>
>> os.path.append('$HOME/gsutils/boto')
>>
>> thinking I could then successfully do the import boto statement.
>> Nope.
>
> You'll need to give the literal path. Substitution of environment
> variables isn't performed implicitly in strings.

Also, that should be sys.path.append(); os.path is an unrelated module
that has no `append` function. You'll need to import sys instead of os
obviously.

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Carl Banks]

On Jun 5, 7:22 pm, ant  wrote:
> I get the strong feeling that nobody is really happy with the state of
> Python GUIs.
> Tkinter is not widely liked, but is widely distributed. WxPython and
> PyGtk are both
> powerful, but quirky in different ways. PyQt is tied to one platform.
> And there are
> dozens more.
>
> Whether or not we like graphics programming, it's not going to go
> away. I get the
> uneasy feeling whenever I start a new project that there should be a
> 'better' GUI
> than the ones I currently use (WxPython and PyGtk).
>
> Fragmentation is our enemy. Our resources are being dissipated. Is it
> not time to
> start again? We have shown that it is possible to do the right thing,
> by creating Python3.
>
> I ask the group; should we try to create a new GUI for Python, with
> the following
> properties?:
>
> - Pythonic
> - The default GUI (so it replaces Tkinter)
> - It has the support of the majority of the Python community
> - Simple and obvious to use for simple things
> - Comprehensive, for complicated things
> - Cross-platform
> - Looks good (to be defined)
> - As small as possible in its default form
>
> If so, what are the next steps?
>
> The Python SIG on GUIs closed years ago. Should that be revived?
>
> This is "A Modest Proposal" (J. Swift). In a sense, I am suggesting
> that
> we eat our own babies.
>
> But don't we owe it to the community?

Speaking for myself, PySide has resolved this issue for me.  I used
PyQt for some things but didn't want to use it for everything because
of the license, but I'd be ok to use PySide for anything.  It's
portable to the major systems and generally better (IMHO) than the
other toolkits.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

RE - Parsing ipconfig /all output - question

[joblack]

I'm trying to get the first MAC address from the ipconfig /all output.
Unfortunately you can't just search for Physical Address because the
name is only valid in the English Windows version.

Here a test which isn't working:

import subprocess
import re
p = subprocess.Popen('ipconfig /all', shell = True, stdout
=subprocess.PIPE)
p.wait()
rawtxt = p.stdout.read()
print rawtxt
p = re.findall(r'(%X%X-){5}%X%X',rawtxt)
print p

Any ideas?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Aahz]

In article <80a7b823-6acb-4ac9-a273-525054265...@k25g2000prh.googlegroups.com>,
ant   wrote:
>
>My concern is simple: I think that Python is doomed to remain a minor
>language unless we crack this problem.

Where's your proof that Python is a minor language?
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Forum

[Aahz]

In article <87r5kj8zmk@benfinney.id.au>,
Ben Finney   wrote:
>
>So you say. For the interface to be "better" it needs to keep the good
>features of the existing interface. I include among the good features of
>Usenet:
>
>  [...]

You skipped over the crowning glories of Usenet:

* Threaded messaging (more robust than mailing lists, generally speaking,
because the behavior of the References: header is better defined, and
References: includes more than just the immediate parent)

* Marking articles as read does *not* delete them; they are still
available for walking through the threading, but by default you never
see them again

NOTHING else has these, thirty years later.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it."  --Dijkstra
-- 
http://mail.python.org/mailman/listinfo/python-list

ODFPY

[Lawrence D'Oliveiro]

Very handy library for creating and manipulating ODF documents without any
dependency on OpenOffice.org .

I’ve been looking at using it for automating the generation of the invoices
I send out at the end of each month. So far, it’s been a lot easier than
trying to figure out PyUNO. :)

One thing, though, the examples are full of procedural sequences involving
creating an object, and then calling some other object’s addElement method
to add the new object as a child—lots of repetitive accesses to intermediate
variables. So I wrote this nice, simple convenience routine

def AddElement(Parent, Construct, Attrs, Children) :
# convenience routine for building ODF structures.
NewElt = Construct(**Attrs)
for Child in Children :
NewElt.addElement(Child)
#end for
if Parent != None :
Parent.addElement(NewElt)
#end if
return NewElt
#end AddElement

With this, I can build quite complicated structures in a single statement,
using a more functional approach, e.g.

AddElement \
  (
Parent = TheDoc.text,
Construct = odf.text.P,
Attrs = dict
  (
stylename = AddElement
  (
Parent = TheDoc.automaticstyles,
Construct = odf.style.Style,
Attrs = dict(name = "work header", family = "paragraph"),
Children =
(
odf.style.TextProperties(fontweight = "bold"),
AddElement
  (
Parent = None,
Construct = odf.style.ParagraphProperties,
Attrs = dict
  (
marginbottom = "0.21cm"
  ),
Children =
(
AddElement
  (
Parent = None,
Construct = odf.style.TabStops,
Attrs = dict(),
Children =
(
odf.style.TabStop(position = 
"15.1cm"),
)
  ),
)
  ),
)
  )
  ),
Children =
(
odf.text.Span(text = "Description of Work"),
odf.text.Tab(),
odf.text.Span(text = "Charge"),
)
  )

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RE - Parsing ipconfig /all output - question

[Tim Pinkawa]

On Sun, Jun 6, 2010 at 10:47 PM, joblack  wrote:
> I'm trying to get the first MAC address from the ipconfig /all output.
> Unfortunately you can't just search for Physical Address because the
> name is only valid in the English Windows version.

> Any ideas?

(accidentally sent original to Johannes only)

This filters out all the false positives on my machine (Windows 7 x64 English):

import subprocess
import re
p = subprocess.Popen('ipconfig /all', shell = True, stdout=subprocess.PIPE)
p.wait()
rawtxt = p.stdout.read()
print rawtxt

p = re.findall(r'\s([0-9A-F-]{17})\s',rawtxt)
print p

Tim
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RE - Parsing ipconfig /all output - question

[joblack]

Great - seems to work =) ...

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUIs - A Modest Proposal

[Carl Banks]

On Jun 6, 3:55 pm, ant  wrote:
> I obviously didn't make my main point clearly enough;

I think you did make your point clearly enough, it's just that not
many agreed with you.  But I'll play along.

> I'll restate it
> with a different emphasis:
> The default GUI shipped with Python is Tkinter.
> Few people seem to like it much. This has several consequences.
> - It has not blossomed, like Python has.
> - There are not hundreds of talented programmers making rapid and
> impressive improvements to it.
> - Books about Python use it in examples (because it IS the default),
> but imply that one should move on.
>
> The result that our hypothetical new recruit has to make a choice for
> the new, big project. Remember that
> GUIs have hundreds (sometimes thousands) of classes, functions and
> constants. Let alone idioms and design
> patterns. That is what I meant by 'Our resources are being
> dissipated'; the effort of learning, remembering
> and relearning a workable subset of these is substantial.
> So it would be good to be able to use One Right Way, not try several
> (as I have - I will admit I didn't try PyQt;
> GUI fatigue was setting in by then).

GUI programming is too complex for us (i.e., mankind) to have reached
any condition where One Obvious Way makes sense, we just don't know
enough, and there might not ever be one.

So it would be foolish for Python to go out and say "this is the One
Obvious Way"--it'd be like claiming to be smarter than mankind.

Right now the best way is to let GUI toolkits be toolkits and to
compete with each other.


> If we are to make progress, I can see two obvious approaches:
> 1) Improve Tkinter to the point where it is supportable and supported
> by a good fraction of Python programmers
> or
> 2) Drop Tkinter as the default and use something else.
>
> If we choose 2) then we have a new set of possibilities:
> 2a) Use one of the 'major' GUIs, pretty much as is, but presumably
> with a lot more people supporting it if it is the default.
> 2b) Use one of the 'minor' GUIs, and get a lot of people working on it
> to make it really good.
> 2c) Start from scratch. With a project supported by the Community as a
> whole, with the agreed objective of being the default.

I believe choosing any one of these options would do far more harm
than good.

The bureaucracy of the standard library works to keep Python headed
down the straight path for stable, mature tasks like basic
networking.  But for  dynamic, complex, cutting-edge tasks like GUI
programming it would bog everything down.  Only straightforward,
simple GUIs like Tkinter are suitable for the standard library.

> None of these is easy. All require strong leadership and great
> committment.

Strong leaders in GUI programming are best left unhindered by the
constraints of Python's standard library process.

BTW, what's your plan for producing such a leader?  Because if we
don't have a leader it's kind of a moot point.  (I know some people
asked you to volunteer, but I suspect you would agree that you're not
up to the task, so I assume you are merely a visionary and have
someone lined up that you've somehow convince to do the dirty work of
leadership.)

> What surprises me is the apparent willingness of the Python community
> to let this issue slide.

It's not a willingness to let the issue slide; it's disagreement that
it's an issue at all.

> I can see that many people have committed to one GUI and want to use
> that forever. Fair enough. For the reasons I stated
> originally, I've not found one. I think a lot of people deep down are
> uneasy about this.

I haven't noticed much of that.  The main objection seems to be that
Python carries around the dead weight of Tkinter, or at least that
it's basic GUI isn't actually written in Python.

I've seen a lot more people clamoring for a web framework a la Ruby on
Rails, mostly, I suspect, out of greed for exposure.  Same issue,
though.

Notice that Ruby got typecast as a web language.  Then people started
jumping off the RoR bandwagon, so now it's a web language with few
users.  You want that for Python?  I don't.


> My concern is simple: I think that Python is doomed to remain a minor
> language unless we crack this problem.

Well, if Python is considered a "minor language" now, I'd happy to
welcome that particular damnation.

-1


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Importing modules

[Anthony Papillion]

On Jun 6, 10:33 pm, Chris Rebert  wrote:
> On Sun, Jun 6, 2010 at 8:16 PM, Ben Finney  wrote:
> > Anthony Papillion  writes:
>
> >> import os
>
> >> os.path.append('$HOME/gsutils/boto')
>
> >> thinking I could then successfully do the import boto statement.
> >> Nope.
>
> > You'll need to give the literal path. Substitution of environment
> > variables isn't performed implicitly in strings.
>
> Also, that should be sys.path.append(); os.path is an unrelated module
> that has no `append` function. You'll need to import sys instead of os
> obviously.
>
> Cheers,
> Chris
> --http://blog.rebertia.com

Hi Chris,
Thanks for saving me (again). I appreciate the help. While the
os.path.append() was a typo (I really had sys.path.append()), the
substitution was what was killing me.  Thanks for the help! I owe you
a beer.

Anthon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Importing modules

[Chris Rebert]

On Sun, Jun 6, 2010 at 10:25 PM, Anthony Papillion  wrote:
> On Jun 6, 10:33 pm, Chris Rebert  wrote:
>> On Sun, Jun 6, 2010 at 8:16 PM, Ben Finney  
>> wrote:
>> > Anthony Papillion  writes:
>>
>> >> import os
>>
>> >> os.path.append('$HOME/gsutils/boto')
>>
>> >> thinking I could then successfully do the import boto statement.
>> >> Nope.
>>
>> > You'll need to give the literal path. Substitution of environment
>> > variables isn't performed implicitly in strings.
>>
>> Also, that should be sys.path.append(); os.path is an unrelated module
>> that has no `append` function. You'll need to import sys instead of os
>> obviously.
>>
>> Cheers,
>> Chris
>
> Hi Chris,
> Thanks for saving me (again). I appreciate the help. While the
> os.path.append() was a typo (I really had sys.path.append()), the
> substitution was what was killing me.  Thanks for the help! I owe you
> a beer.

Er, in point of fact, the substitution problem was first pointed out
by Ben, not myself.
Not that I could legally have your beer anyway. :)

Cheers,
Chris
--
2 more months!
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Non Sequitur: Re: Python Forum

[Steven D'Aprano]

On Sun, 06 Jun 2010 21:45:44 -0700, Dennis Lee Bieber wrote:

> On Mon, 07 Jun 2010 11:29:59 +1000, Ben Finney
>  declaimed the following in
> gmane.comp.python.general:
> 
>> claim to the word. The existing forums are still forums.
>>
>   I favor "fora" 

I see your smiley, but the Oxford dictionary does suggest that "fora" is 
only acceptable as the plural when talking about more than one ancient 
Roman forum. When using it in the context of English, as we are doing 
here, the accepted plural is "forums". After all, we don't use Inuit 
pluralisation rules when talking about more than one anorak.

 
>   Like the difference between fish (plural species) and fishes 
> (which I tend to use for plural of one specie)


That's a hypercorrection. The singular of species is species, not specie. 
Specie is a different word: coins or hard cash.

There is a phrase "in specie", which means "in kind", which is formed 
from the same root as species, but the words are different and species is 
its own plural.

"Fish" can be either singular (as in "I fed the fish") or a collective 
noun ("there are many fish that live in salt water"). Plural is "fishes", 
as in "I ate three fishes", although in common use people tend to use 
fish/fishes as both plural and collective nouns.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list