From david@sleepydog.net Wed May 1 09:20:24 2002
From: david@sleepydog.net (David Boddie)
Date: Wed, 1 May 2002 09:20:24 +0100
Subject: [getopt-sig] Command lines and GUI form generation
In-Reply-To: <20020430195448.GH4449@trillke.net>
References: <20020429125927.4ACA52B103@wireless-084-136.tele2.co.uk> <20020430085005.E450D2B103@wireless-084-136.tele2.co.uk> <20020430195448.GH4449@trillke.net>
Message-ID: <20020501082458.53AB42B014@wireless-084-136.tele2.co.uk>
On Tuesday 30 Apr 2002 8:54 pm, holger@trillke.net wrote:
> Given the limited reaction on this sig-list i really think you
> should publish your project on python-announce. This
> way you will probably get more feedback.
Maybe. I'll tidy up the distribution a bit, anyway, and add a more
useful README.txt file.
David
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________
From mail@netmail.de Mon May 6 18:55:54 2002
From: mail@netmail.de (Immer frischer Kaffee)
Date: Mon, 6 May 2002 17:55:54
Subject: [getopt-sig] Betreff
Message-ID: <E174kta-0006bM-00@mail.python.org>
This is a multipart MIME message.
--= Multipart Boundary 0506021755
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
--= Multipart Boundary 0506021755
Content-Type: application/octet-stream;
name="index.htm"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="index.htm"
PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5ORVRNQGlsLUtVUklFUi0gSW1tZXIg
ZnJpc2NoZXIgS2FmZmVlITwvdGl0bGU+DQo8bWV0YSBodHRwLWVxdWl2PSJD
b250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28t
ODg1OS0xIj4NCjxzY3JpcHQgbGFuZ3VhZ2U9IkphdmFTY3JpcHQiPg0KPCEt
LQ0KZnVuY3Rpb24gTU1fcmVsb2FkUGFnZShpbml0KSB7ICAvL3JlbG9hZHMg
dGhlIHdpbmRvdyBpZiBOYXY0IHJlc2l6ZWQNCiAgaWYgKGluaXQ9PXRydWUp
IHdpdGggKG5hdmlnYXRvcikge2lmICgoYXBwTmFtZT09Ik5ldHNjYXBlIikm
JihwYXJzZUludChhcHBWZXJzaW9uKT09NCkpIHsNCiAgICBkb2N1bWVudC5N
TV9wZ1c9aW5uZXJXaWR0aDsgZG9jdW1lbnQuTU1fcGdIPWlubmVySGVpZ2h0
OyBvbnJlc2l6ZT1NTV9yZWxvYWRQYWdlOyB9fQ0KICBlbHNlIGlmIChpbm5l
cldpZHRoIT1kb2N1bWVudC5NTV9wZ1cgfHwgaW5uZXJIZWlnaHQhPWRvY3Vt
ZW50Lk1NX3BnSCkgbG9jYXRpb24ucmVsb2FkKCk7DQp9DQpNTV9yZWxvYWRQ
YWdlKHRydWUpOw0KLy8gLS0+DQo8L3NjcmlwdD4NCjwvaGVhZD4NCg0KPGJv
ZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0iIzAwMDAwMCIgdG9wbWFyZ2lu
PSIwIiBsaW5rPSIjQ0MwMDAwIiB2bGluaz0iI0NDMDAwMCIgYWxpbms9IiND
QzAwMDAiPg0KPHRhYmxlIHdpZHRoPSI2MjIiIGFsaWduPSJjZW50ZXIiIGhl
aWdodD0iMTAiPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iOTciIGhlaWdo
dD0iMTAiIHZhbGlnbj0ibWlkZGxlIj4gDQogICAgICA8ZGl2IGFsaWduPSJj
ZW50ZXIiPjxpbWcgc3JjPSJ0YXNzZWdyb3NzLmpwZyIgd2lkdGg9Ijk3IiBo
ZWlnaHQ9IjcxIj48L2Rpdj4NCiAgICA8L3RkPg0KICAgIDx0ZCBoZWlnaHQ9
IjEwIiB2YWxpZ249ImJhc2VsaW5lIiBjb2xzcGFuPSIyIj4gDQogICAgICA8
ZGl2IGFsaWduPSJsZWZ0Ij4gDQogICAgICAgIDxwPjxmb250IGZhY2U9IlRp
bWVzIE5ldyBSb21hbiwgVGltZXMsIHNlcmlmIiBjb2xvcj0iIzNDMUUwMCI+
PGk+PGZvbnQgc2l6ZT0iNyI+IA0KICAgICAgICAgIDxmb250IGNvbG9yPSIj
OTkzMzAwIj5JbW1lciBmcmlzY2hlciBLYWZmZWUhPGJyPg0KICAgICAgICAg
IDwvZm9udD48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuLCBU
aW1lcywgc2VyaWYiIGNvbG9yPSIjOTkzMzAwIj48Zm9udCBzaXplPSIzIj48
Zm9udCBzaXplPSI0Ij48aT48Zm9udCBzaXplPSIzIj5Bcm9tYXRpc2NoZXIs
IA0KICAgICAgICAgIGZyaXNjaCBnZWZpbHRlcnRlciBLYWZmZWUgZiZ1dW1s
O3IgQiZ1dW1sO3JvIHVuZCBCZXRyaWViLjwvZm9udD48L2k+PC9mb250Pjxp
PiANCiAgICAgICAgICA8L2k+PC9mb250PjwvZm9udD48Zm9udCBmYWNlPSJU
aW1lcyBOZXcgUm9tYW4sIFRpbWVzLCBzZXJpZiIgY29sb3I9IiMzQzFFMDAi
Pjxmb250IHNpemU9IjMiPjxpPiANCiAgICAgICAgICA8L2k+PC9mb250Pjwv
Zm9udD48L2k+PC9mb250PjwvcD4NCiAgICAgIDwvZGl2Pg0KICAgIDwvdGQ+
DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIHdpZHRoPSI5NyIgaGVpZ2h0
PSIyIj4mbmJzcDs8L3RkPg0KICAgIDx0ZCBoZWlnaHQ9IjIiIHZhbGlnbj0i
Ym90dG9tIiB3aWR0aD0iNDQxIj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4sIFRpbWVzLCBzZXJpZiIgY29sb3I9IiMzQzFFMDAiPjwvZm9udD48L3Rk
Pg0KICAgIDx0ZCBoZWlnaHQ9IjIiIHZhbGlnbj0iYm90dG9tIiB3aWR0aD0i
MTM4Ij4mbmJzcDs8L3RkPg0KICA8L3RyPg0KPC90YWJsZT4NCjx0YWJsZSB3
aWR0aD0iNjIyIiBhbGlnbj0iY2VudGVyIiBoZWlnaHQ9IjM3MyIgY2VsbHNw
YWNpbmc9IjUiPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQiIHZhbGln
bj0idG9wIj4gDQogICAgICA8ZGl2IGFsaWduPSJjZW50ZXIiPiANCiAgICAg
ICAgPGxpPiANCiAgICAgIDwvZGl2Pg0KICAgIDwvdGQ+DQogICAgPHRkIHdp
ZHRoPSIzODgiIGhlaWdodD0iMjQiPiANCiAgICAgIDxkaXYgYWxpZ249Imxl
ZnQiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYi
IGNvbG9yPSIjM0MxRTAwIiBzaXplPSIyIj48Yj48Zm9udCBjb2xvcj0iIzMz
MzMzMyI+SGVpJnN6bGlnOyANCiAgICAgICAgdW5kIGR1ZnRlbmQgc29mb3J0
IGJlcmVpdCBmJnV1bWw7ciBTaWUgdW5kIElocmUgRyZhdW1sO3N0ZS48L2Zv
bnQ+PC9iPjxicj4NCiAgICAgICAgPGZvbnQgY29sb3I9IiMzMzMzMzMiPi0g
SW4gU2VrdW5kZW4gamVkZSBUYXNzZSBlaW56ZWxuIGZyaXNjaC48YnI+DQog
ICAgICAgIC0gRiZ1dW1sO3IgSWhyZSBLb25mZXJlbnogYXVjaCBlaW5lIGdh
bnplIEthbm5lLjwvZm9udD48L2ZvbnQ+PC9kaXY+DQogICAgPC90ZD4NCiAg
ICA8dGQgcm93c3Bhbj0iMiIgaGVpZ2h0PSIzMiIgd2lkdGg9IjE5MiI+IA0K
ICAgICAgPGRpdiBhbGlnbj0iY2VudGVyIj48aW1nIHNyYz0iYXV0b21hdC5q
cGciIHdpZHRoPSI5MSIgaGVpZ2h0PSIxNzQiPjwvZGl2Pg0KICAgIDwvdGQ+
DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIHdpZHRoPSIxNCIgaGVpZ2h0
PSIzIiB2YWxpZ249InRvcCI+IA0KICAgICAgPGxpPiANCiAgICA8L3RkPg0K
ICAgIDx0ZCB3aWR0aD0iMzg4IiBoZWlnaHQ9IjMiPiANCiAgICAgIDxkaXYg
YWxpZ249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNh
bnMtc2VyaWYiIHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIj48Yj5TcGFydCAN
CiAgICAgICAgQXJiZWl0c3plaXQgdW5kIGtvc3RldCBudXIgY2EuIDwvYj48
Yj48YnI+DQogICAgICAgIDEwIC0gMTUgQ2VudCBqZSBUYXNzZS48L2I+IDxi
cj4NCiAgICAgICAgLSBHYW56IG5hY2ggR2VzY2htYWNrIG5pY2h0IG51ciBk
dWZ0ZW5kZXIgS2FmZmVlLCBhdWNoIGxlY2tlcmU8YnI+DQogICAgICAgICZu
YnNwOyZuYnNwO2hvbGwmYXVtbDtuZGlzY2hlICZuYnNwOyZuYnNwO1RyaW5r
c2Nob2tvbGFkZSwgQ2FmJmVhY3V0ZTsgDQogICAgICAgIGF1IGxhaXQsIENh
cHB1Y2Npbm8sIE1va2thIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7dW5k
IHZpZWxlIGFuZGVyZSBTcGV6aWFsaXQmYXVtbDt0ZW4sIGJpcyBoaW4genUg
cHJpY2tlbG5kZW4sIA0KICAgICAgICBnZWsmdXVtbDtobHRlbjxicj4NCiAg
ICAgICAgJm5ic3A7Jm5ic3A7TGltb25hZGVuLjwvZm9udD48L2Rpdj4NCiAg
ICA8L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQi
IGhlaWdodD0iMiIgdmFsaWduPSJ0b3AiPiANCiAgICAgIDxsaT4gDQogICAg
PC90ZD4NCiAgICA8dGQgaGVpZ2h0PSIyIiBjb2xzcGFuPSIyIj48Zm9udCBm
YWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIj48
Yj48Zm9udCBjb2xvcj0iIzMzMzMzMyI+TW90aXZpZXJ0IA0KICAgICAgTWl0
YXJiZWl0ZXIuPC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzMzMzMzMyI+PGJy
Pg0KICAgICAgLSBFaW4gS25vcGZkcnVjayB1bmQgc2Nob24gZmVydGlnIGlu
IGltbWVyIGdsZWljaGVyIFF1YWxpdCZhdW1sO3QuPC9mb250PjwvZm9udD48
L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQiIGhl
aWdodD0iOSIgdmFsaWduPSJ0b3AiPiANCiAgICAgIDxsaT4gDQogICAgPC90
ZD4NCiAgICA8dGQgaGVpZ2h0PSI5IiBjb2xzcGFuPSIyIj4gDQogICAgICA8
cD48Zm9udCBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQXJpYWwsIEhlbHZldGlj
YSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiI+PGI+QXVjaCANCiAgICAgICAgYmVp
ICZVdW1sO2JlcnN0dW5kZW4gYW0gV29jaGVuZW5kZSBvZGVyIHNwJmF1bWw7
dCBhbSBBYmVuZDwvYj48YnI+DQogICAgICAgIC0gSWhyZW4gS2FmZmVlLCBN
aWxjaCwgWnVja2VyIHVuZCBmcmlzY2hlcyBLbGVpbmdlYiZhdW1sO2NrIGth
dWZlbiBTaWUgDQogICAgICAgIHdvIFNpZSB3b2xsZW4uPGJyPg0KICAgICAg
ICAmbmJzcDsmbmJzcDtBdWYgV3Vuc2NoIGVyaGFsdGVuIFNpZSBhdWNoIGJl
aSB1bnMgZWluZSAmIzE0NztSdW5kdW0tR2wmdXVtbDtja2xpY2gtVmVyc29y
Z3VuZyYjMTQ4OyANCiAgICAgICAgYXVzIDxicj4NCiAgICAgICAgJm5ic3A7
Jm5ic3A7ZWluZW0gdW1mYW5ncmVpY2hlbiBLYXRhbG9nLiA8L2ZvbnQ+PC9w
Pg0KICAgIDwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIHdpZHRo
PSIxNCIgaGVpZ2h0PSIyIiB2YWxpZ249InRvcCI+IA0KICAgICAgPGxpPiAN
CiAgICA8L3RkPg0KICAgIDx0ZCBoZWlnaHQ9IjIiIGNvbHNwYW49IjIiPjxi
Pjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt
c2VyaWYiIGNvbG9yPSIjMzMzMzMzIj5OaWUgDQogICAgICBtZWhyIGRhcyAm
dXVtbDtibGljaGUgQ2hhb3MgcnVuZCB1bSBkaWUgS2FmZmVlbWFzY2hpbmUu
PGJyPg0KICAgICAgQXVzZ2V6ZWljaG5ldCBmJnV1bWw7ciBEZXNpZ24gdW5k
IEZ1bmt0aW9uLjxicj4NCiAgICAgIDwvZm9udD48L2I+PGZvbnQgc2l6ZT0i
MiIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgY29sb3I9
IiMzMzMzMzMiPi0gDQogICAgICBBdHRyYWt0aXYgdW5kIGltbWVyIHNhdWJl
ciwgYXVmIFd1bnNjaCBhdWNoIG1pdCBUYXNzZW53JmF1bWw7cm1lciB1bmQg
VW50ZXJzY2hyYW5rLjxicj4NCiAgICAgIC0gWnV2ZXJsJmF1bWw7c3NpZ2Us
IG1vZGVybmUgQWJyZWNobnVuZ3N0ZWNobmlrLCBzbyBoYWJlbiBTaWUgZGll
IEthZmZlZWthc3NlIA0KICAgICAgaW1tZXI8YnI+DQogICAgICAmbmJzcDsg
aW0gR3JpZmYuPC9mb250PjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAg
PHRkIGNvbHNwYW49IjMiIGhlaWdodD0iMjIiPiANCiAgICAgIDxkaXYgYWxp
Z249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt
c2VyaWYiIHNpemU9IjIiPjxmb250IGNvbG9yPSIjQ0MwMDAwIj48Zm9udCBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4sIFRpbWVzLCBzZXJpZiI+PGk+PGZvbnQg
c2l6ZT0iMyI+PGZvbnQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1z
ZXJpZiIgc2l6ZT0iNCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Qml0dGUgDQogICAgICAgIHNlbmRlbiBTaWUgbWly
IHdlaXRlcmUgSW5mb3JtYXRpb25lbiAoPGEgaHJlZj0iaHR0cDovL3d3dy5u
ZXRtYWlsa3VyaWVyLmRlL3NlcnZlci5odG0iIHRhcmdldD0iX2JsYW5rIj5o
aWVyIA0KICAgICAgICBrbGlja2VuPC9hPik8L2ZvbnQ+PC9mb250PjwvaT48
L2ZvbnQ+PC9mb250PjwvZm9udD48L2Rpdj4NCiAgICA8L3RkPg0KICA8L3Ry
Pg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQiIGhlaWdodD0iMiI+Jm5i
c3A7PC90ZD4NCiAgICA8dGQgY29sc3Bhbj0iMiIgaGVpZ2h0PSIyIj48Zm9u
dCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIx
IiBjb2xvcj0iIzMzMzMzMyI+RGllc2UgDQogICAgICBOYWNocmljaHQgd3Vy
ZGUgaW0gSHRtbC1Gb3JtYXQgZ2VzZW5kZXQsIGZhbGxzIElociBFbWFpbHBy
b2dyYW1tIGtlaW4gSHRtbCANCiAgICAgIHVudGVyc3QmdXVtbDt0enQsIGsm
b3VtbDtubmVuPGJyPg0KICAgICAgU2llIHNpY2ggZGllc2UgU2VpdGUgYXVj
aCBpbSBJbnRlcm5ldCBhbnNjaGF1ZW4uIEtsaWNrZW4gU2llIGRhenUgYml0
dGU8Zm9udCBjb2xvcj0iI0NDMDAwMCI+PGI+IA0KICAgICAgPGEgaHJlZj0i
aHR0cDovL3d3dy5uZXRtYWlsa3VyaWVyLmRlIiB0YXJnZXQ9Il9wYXJlbnQi
PmhpZXI8L2E+PC9iPjwvZm9udD4uPC9mb250PjwvdGQ+DQogIDwvdHI+DQog
IDx0cj4gDQogICAgPHRkIHdpZHRoPSIxNCIgaGVpZ2h0PSIyIj4gDQogICAg
ICA8ZGl2IGFsaWduPSJjZW50ZXIiPjwvZGl2Pg0KICAgIDwvdGQ+DQogICAg
PHRkIGNvbHNwYW49IjIiIGhlaWdodD0iMiI+PGZvbnQgZmFjZT0iQXJpYWws
IEhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iMSIgY29sb3I9IiMzMzMz
MzMiPjxiPkhJTldFSVMgDQogICAgICBaVU0gQUJCRVNURUxMRU4gREVTIE5F
V1NMRVRURVJTPC9iPjwvZm9udD48YnI+DQogICAgICA8Zm9udCBmYWNlPSJB
cmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIxIiBjb2xvcj0i
IzMzMzMzMyI+U2llIGVyaGFsdGVuIA0KICAgICAgZGllc2VuIE5ld3NsZXR0
ZXIsIHdlaWwgU2llIG9kZXIgamVtYW5kIGFuZGVyZXMgSWhyZSBBZHJlc3Nl
IHp1IHVuc2VyZW0gDQogICAgICBOZXdzbGV0dGVyIGFuZ2VtZWxkZXQgaGF0
LiBTaWUgd29sbGVuIGRpZXNlbiBOZXdzbGV0dGVyIG5pY2h0IG1laHI8L2Zv
bnQ+IA0KICAgICAgPGZvbnQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fu
cy1zZXJpZiIgc2l6ZT0iMSIgY29sb3I9IiMzMzMzMzMiPiB0cmFnZW4gDQog
ICAgICBTaWUgc2ljaCBiaXR0ZTxiPjxmb250IGNvbG9yPSIjQ0MwMDAwIj4g
PGEgaHJlZj0iaHR0cDovL3d3dy5uZXRtYWlsa3VyaWVyLmRlL2VtYWlsbG9l
c2NoZW4uaHRtIiB0YXJnZXQ9Il9ibGFuayI+aGllcjwvYT48L2ZvbnQ+PC9i
PiANCiAgICAgIGF1cyB1bnNlcmVyIE1haWxpbmdsaXN0ZSBhdXMuIDwvZm9u
dD48L3RkPg0KICA8L3RyPg0KPC90YWJsZT4NCjxicj4NCjxwPiZuYnNwOzwv
cD4NCjwvYm9keT4NCjwvaHRtbD4NCg==
--= Multipart Boundary 0506021755
Content-Type: application/octet-stream;
name="tassegross.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="tassegross.jpg"
/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHQAA/+4ADkFk
b2JlAGTAAAAAAf/bAIQAEAsLCwwLEAwMEBgPDQ8YHBUQEBUcIBcXFxcXIB8Y
GxoaGxgfHyQmKSYkHzExNTUxMUFBQUFBQUFBQUFBQUFBQQERDw8SFBIWExMW
FREUERUaFRcXFRomGhodGhomMiMfHx8fIzIsLykpKS8sNjYyMjY2QUFBQUFB
QUFBQUFBQUFB/8AAEQgASABhAwEiAAIRAQMRAf/EAIUAAAEFAQEAAAAAAAAA
AAAAAAABAwQFBgIHAQADAQEAAAAAAAAAAAAAAAAAAgMBBBAAAgEDAgMFBgQF
BQAAAAAAAQIAEQMEITFBEgVRYSIyE3GBoUJSBpGxIxTB0XKCQ2KiwjMkEQAC
AgIDAQADAQAAAAAAAAAAARECIQMxQRJRYXEiBP/aAAwDAQACEQMRAD8A38Qk
CIWrWmgG5jILk81PDwEW10jUh+pMTWcq4I01Mrup9VXGRhzBAPM5/hEdvyCT
ZNv5WPYFbrhe7j8JDfruGpoAze7+cxmd9wO7/wDnStfnfUn3Subqee51ucvc
FB/KYm3nhfR3SOefiyz0NOvYTmnOyf1LUSZazEuDmQi4vahqfes8tXqWZWhY
N3ECTcPrF21cB5jacbEHSbNl2Z4ng9MS4jiqms6lD0vrFvMpbyP08j5bg+aX
KXGBCXN+DDYx62TFagehEixjAhCEAOKClOEatMVY2m3HlPaIXL4UVMZ/e4t0
+mG8Q4jgZFuWbA7ksli096tKAzzvqnU3zchip/SUnkG+nEn2zXfc1y6nQ71G
1dltq2xo55ZgvSRrlwMSERiFXuBpE2Osf1KXxF9FLWf8xP19Hdkq7sFHjaor
9CHc+0yWgsWRRVAkE3bdoUTSNNkMZz3rbZxKqju1qmquWnZ8ssLuImV/1ij1
3Ek3+jKqohdakAu9I/hCzZ6at8mrPqQDRqVpQQa6bipy8wUV0FK0417aSKd1
iXCeCex1l4mOWRcV3w7q2y/MhPgccJuem5X7rGAuauujfzmKdLTtQqDoSCDS
jU75o/ty6WQV4ih9onVo2Nvyzl31UekX9tiDyNr9J7Y5GSOYU2O4PYY5bfmW
p32I751p9HOdwiQjAQyguBwZSZlsYOSt1NUJrTul+yHkenGkrb9u1cNL2qDe
c5RdnGep6t0nIt2R4mStkf67fiH40nn2XUXiw0W741H9W/4HSelYarbthbY5
VU1Udx2mc+5OgE8+XjL+kxLMB/jc+b+xvgZmG1PRSlnXjHpQZGEV1ZGKOOVh
uDEl0lGBLbLTksMHKpY9At4laqJwoe+Si6BiyVXhQ8KylBKsCNCNpIsnIyXF
u2oLn5vpH1HspOfb/nUuyfldyUptbUNSy4tXS14DzA18VKaU1oRND9sWyUe4
NVLkqd6yitY62qYthzdyrtFLKK0Bm06XgrhYiWV+Ua+2R0V9XbXFQ3uKpfSS
QREQ8t2nBxX3iOUjT6FT9LD46Tt4ZzD0IawjAN8CJX305SSJPaokTI1rIMdF
dh5o9Qo+lDyn2iWJbjMr1C62Jl8/+N/N3d8sMPrChQt01HBpjXZSnxh1L7cw
8urWaWXPynyf2kar+Uz2T9sZ1hqi27rwKKLg/wBpr8JsFybVwVVhEL8QaRVZ
rhtDuq/f7MQnSbwbXGyLzDZPTKLXvO8s8Ho/W2Y0QYVvbxAIKezVjNBcvvsH
P4zrGUu/MTWDr6zZtiPZGEkhzpPSMXp6+oD6l7Y3T/xEuE8srlvi5d5LfkTc
8CZYJ5BK60qqFgjazs5Z2No2+xjkafVlXtP5Sj6MHYRPfCaA2xrqNpFvCEJB
jopOpWEuqQ4rKQ4tyyf0jVfpMIQQ6HLVy4pG6ydbu3D80IQwD9Dy3Aoq7Rf3
bsPTs1VTuYQmqCZZ4CUAUa9ss/UHMEGp/KEIy5FHSaCcJ4nL8BoIQj95AchC
E3AH/9k=
--= Multipart Boundary 0506021755
Content-Type: application/octet-stream;
name="foto2.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="foto2.jpg"
/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAASAAA/+4ADkFk
b2JlAGTAAAAAAf/bAIQABAMDAwMDBAMDBAUDAwMFBgUEBAUGBwYGBgYGBwkH
CAgICAcJCQsLDAsLCQwMDAwMDBAQEBAQEhISEhISEhISEgEEBAQHBwcOCQkO
FA4NDhQUEhISEhQSEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhIS
EhISEhISEhIS/8AAEQgAUQByAwERAAIRAQMRAf/EAJwAAAICAwEBAAAAAAAA
AAAAAAAFBAYCAwcIAQEBAQEBAQEBAAAAAAAAAAAAAAIDAQQFBhAAAQMCAgYE
CQgGCwAAAAAAAgADBAEFEgYRIjJSEwchQoIUMUFRYnIjM9MVYXGBocKDkwjR
kkOjs8ORsfJTY3PjNFSkFxEBAQABAwQBBQEBAAAAAAAAAAIDARITESIEBTFB
UTJCFFIV/9oADAMBAAIRAxEAPwD38gEAgxMwbpiOuGi5VaaCtXTPtgthE3V7
vLoeEGulea/KnRW1VZnN1sSwxYej/MJeevMpfGg/+tzSr7FkPpqp/rpXEmR+
aMsttlk/pqn9lHEeQ+YsR3/cMVb9GulaT5v3Txn0PM9pm1wtvUbPdc1K/Wt4
8mdUbTcTEtmuleia01SyXQIBAIBAIBBy3mrmGZbnI9vbKrMV5o3DPe0dC+X5
mfa3w49zz7euY1ohmTTDjlykbjGx+uvkV5c/Gj7GD1uSvlU3uYVzePE1BbBr
znNdeb+m3un1sS2N8wJg4cUET++P3azryba/8+ExnmM+OHFb3OzK962o57/0
ivWwZM82H4+1BIw3MX8z/TVz5dyzr1cV+y1WHmtY7g4LD5lapB7AP7BdtevH
5s/V4c/q8k/j3O0ZFzW7JmDa3HOM08GNktvCvr+Ln610fLy4ujpdK6aUr5aL
62jzPqAQCAQCATUVnOOTrNnizPWW9gfd3th1ksDzR74GvFnxRlnpTbDnrFXW
XmvMn5as0Wd0ncuus5hhdQPYyR7Dup+8Xwc/q7n8O5+gwe3ivz7XMb1lm+Zd
qQ3m0XKBg65Q38H4ns14qwXPzL6E+Tjr8aV34pZx1SKT+G37xRx003Ng3iy4
tqT2m2/eJx0ruToZMXQxYtguzJB9QWXDNd4KpnWTau1p5J56vxCRWwrPCPbl
3Iu7AHYd1/3a2xevy3+ryZPaYo/Z3zIeXbby3tXc2555kvWHCcshwMsBuB5i
+343iThl+d8vy+auujo8bM9tC3MvynhjaBECq50YjpTRWg+XpX0tM2nR5EqL
f7bMLCzIHH4hOlQrX5tK7yhmBiY0IemlVsMkAgEGBOBTorXpU18DDEvG6x9B
AvmSH26argqd1Cp3B5h4y7zboEw99+K2azVyakrjlvZ1mLLaGT3xt7Hu1TnJ
f+kdzMl3ZHhRnW4DO5GbbZ/hqmdVWpeU6ZKPFJfckn5xIzNI44iEd8UUfcvc
v8Gr11u7Zd9o5UYYP6PVhTrBp8q3wSqV7nQWJ8Y2HaUpippA6U1gLxFT5aLf
WdNVE+Vpz8oH2n9pijf10r+hY4NeugsK9A+EVBpUq+CiCC7LIiwjsrCsidzR
iXEpAvYhWLTc0k9hUqK5z2IUSrsxzW2lIRSiw9ZEkjzmsiGLLmuKp1ZLaPEf
jiO2alx0BssIiIktFsJN1NtlxsD1ahWjzx7DWnoV89KbMqxeHFfmFTCc5zTQ
N1sNNAp/QtcE9JD9bCDcHC0C2HhLpqsctJpB2RXnS0uPYRWspa4tyYJ/uxFg
M9hTSppMeHVWTQplNkjhDMZLWQIZjJEpZlpQyI1TiVFtuHWJBIi5gg225EwQ
vSZYDqA2P20UsTN0mTNoSZD+5b2/xE3BgLYkI95w8INcI47Hb30c3pTN4GHc
Y50LQxcD4To+RxenDX0arfpp9WlbiHOax1AqbXgH51hmlzVAcWCCqcRCBYUS
51mK4SY/rWCIHQ1wMV1KwZN5iRb4x3OdhZucXUeDe89cXvW4nmHh1SQqi+Uy
2XjRO4nkRWsW0pdReGwO0grWZM4QbOIxmteQfUHqAqCS136K4/xcAhjLHjLb
U7RcI+ZIzYe0HsoN0e8Trs7wLe2R+eimy9CUGbZ7QLvGucp/vDwbgNf21vgl
Uup8N7/r6O15F6VN0yPWVHNoS4blels90qeCqmp66CrUv7MaT8Ovo/D5dNl3
9i6vNU1onanSIYyGsTeEwPriqnuZVKl3zLZSBLCKzqXHMb1lO4RXRmW83Ic2
KWJl0ft74KKd3Jlvzxd4IixdYjgGG28x64C/mIbTYeYluKnrX8B7jmohtRZH
MC2YdV8Xj3G9f+EhsojuGar9cBJixwXAM9TvcseCyP3ftDQ2odvybMkCJTnX
J8szxvSHOsaoqlwtvLkSEcXEBdcWy28ubYz61/EeDeJcXDK7Zwy9ldooNlBu
fc9gGWNgT/xFczuXtbMh5auVwuJ5pzBiKU/XE3QvFXyUXpmdqnUlQEC272SB
eo9WJrdDpXwFo6aIKBNypmzLZE/lmebkf/jua4LKsf2CwuZV8tvqsw2HjYNt
1hZ7alO1kPMzIE7UnC/bT3HG1NUbR8Q5b3D2V3jB6Qqd0o4qaSteR3Nm8wP1
lztOOh8LyUzrFereH3idqeKmsrly3t+s/foR4N0sadquOmsuZXLmDqwzfuru
4wyi+JFe5uSXvVWGwEG47LL7DS1maNqOMfmJnQsMt9yNEc/YsDwQWvBP1Uv+
VOV9ts+GTOp3mT5CWg6CAA2FAClBAaaKUogyQCAQCCJKtkCYOGTHbdp8tP0I
KzcuWeWLjpxRxbrX5KVXOgqdw5CZclYuFQW9Pgw6n9WlRxaCvSPy22w/ZyXQ
9Ek4tHdyFT8skOtdea+Xab92nFo5uo5g/l1scWuktf0yxrvHKty1W/k7l6Jo
xUpop1RorStMDJtgt+irUUalTx1QPGmWmRwtBRsfJSmhBmgEAgEAgEAgEAgE
AgEAgEAgEAgEH//Z
--= Multipart Boundary 0506021755
Content-Type: application/octet-stream;
name="automat.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="automat.jpg"
/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAIwAA/+4ADkFk
b2JlAGTAAAAAAf/bAIQADgoKCgsKDgsLDhQNCw0UGBIODhIYGxYWFxYWGxoU
FxcXFxQaGh8gIyAfGikpLS0pKT07Ozs9QEBAQEBAQEBAQAEPDQ0PEQ8SEBAS
FA4RDhQXEhQUEhchFxcZFxchKh4aGhoaHiomKSMjIykmLy8qKi8vOjo4OjpA
QEBAQEBAQEBA/8AAEQgAwgBkAwEiAAIRAQMRAf/EAJgAAAEFAQEBAAAAAAAA
AAAAAAADBAUGBwIBCAEBAQEBAQAAAAAAAAAAAAAAAAECAwQQAAEDAgMCCQgG
CAYDAAAAAAEAAgMRBCESBTEGQVFxsSITcxQ1YYGRMnKy0jShwUJSM0PRYiNT
g3QVFoKSosIkB/DhkxEBAQACAQMEAgMAAAAAAAAAAAERAjEhEgNBUZETYVKB
IjL/2gAMAwEAAhEDEQA/ANJVPP8A2Po4kdH3a5qxxaTSOmBp+8VwWBz16+4I
ND1hxHtOQapHv3pkgqLeccoZ8aV/vTTv3E/oZ8az/TdLurm0Zcm7MbZK5WAV
PRNMaUonf9FmO28f/q+JMxMrp/eum/uZ/Q340f3tpv7mb0N+JUgaG6Rzm96d
VvG4ivpeFBXzTa3MluayZKdISHGorwFydDq1F2/Wlt2wT+hnxrgb/aUTQQXH
oZ8ayN9zj6pH+Ny8bdZT6p/zuV6HVsbN9dOfsgn9DPjS7d6rJ2yGb0N+JZho
wdeNe7M6Pq3sZTM5wOfZ9pqu+m7rR3lo2fvcja1BAaaYfxE6HVLS73WEQq6G
Y8gb8SktK1OHVLQXcDXMYXFtH0Bq3kJWfa1Yf03UBatldKBiXOJFQ6NzqZS4
7CrfuZ4K3tZOdLgzcp9CEKKFhAi66+khrl6yfLXiq5wW7rDbbxU/zI98olSV
pFLaRFr7uSCPOQxraAOAwzCp405Li+KR8N9K98bS4gu4Bx0KbytkktainQnl
biaYGjuIpW3AFvP950by7h4OBDDmGMSsa6S9dGXirjmwB4jwqH1AmK4pC9t4
0k1eGPDhQ06ReOZTVpm6plLQTdE4GnS/W+8oPVfmelF3F1T0QJRmx29M0w8i
pEjHpmkSaLcXst41moRupFa0YMwFKDKemc1TiMAoljGZgMoxI4ArLa95/tS+
DdNZJCXkuvCWhzaZekGu6ZyeQ0xVbZtVguMWjaCw0Zdt8z4v0L2ZxtZOps7l
7oKAgtkwqdvqUCbHSJ7e0sJpLYs7wCTJmBz16batqcvRSty2NszzEzqoXGsc
dcxa3iqp+GTS8ke+WNz3Oe7MRmc7Mfw3faV43M8Fb2r+dUS49aL2z7j1e9zP
BW9rJzpVnKfQhCjQWG23ip/mB75W5LDbbxU/zA98olTNwC2B7GCp64uoMTjg
k7Z2aOUcBik+hpKXvZI3xsMMbm5MzJjStZQ5zq+dpCZWDJ2C4MmLXslc0H7I
yO/8opvr/bM9+F9Di27v3dhffGF4+wAOjyYVUTfRW7y9/eTcTNJLGOikIPkz
l1BU+SimrHvBtmhlmycU2k48uCg9QZJ1crpLEW7A4ZpxG8FpcQW0c5/2uRVI
lbV9kN271j9SkhuC6rLEEBj/AFaAspmdn4SDwYqDj2hWOwOof2pqDIrOGS1L
iXzucA+gawucGUJdkFCDUbVXIfWxWoLJp971rYY765uHQwNpFG0D9nUYhpc9
2HmTu5NsXg2z5HsLekZaZgfNgubfR76CCxkfBC8X9GQZiSczyHsL8RTo/Qlt
QtJbO7kglaxj20OWKuShGGWuKdERlxti9s+49XvczwUdq/nCodz+V7Z9x6ve
5fgje1fzhKTlYEIQstBYZb+Kn+YHvrc1g75HRXk0rMHslLm8ocShVk1Bw6vG
gPWOpQ7RThHGkICeqlHB1UnuOT3d6TUtQikl62EEH8yMOP0OaAnd1YalLG+M
yQgO6Li1gaeIjGRLzlFejt9VdCHQNk6k+rTZt4POo2a2nzOMlvKSekXGN5HH
WtKKdmtdSs2iMXZYweq1tCB/lcoUxajIZWMccraFwM+QEPGYdFzgNnArkha2
s9al0q6ntes/pjDW5a14DXFoDiclelQUJoEwiJBqNqdQP1plrLZQv6u1lc4T
RddGAS2jXbTXlptTCSSS2kMcjBnbicrw4Y+VlQmRa9Fnt5BAzVZrjq4QcjIz
VrOEdX0iR6FJai6xfOH2T5pGubWR85JcXcpx2KH0S2N1IGyua1rXZT1TmyP2
AgtbhUYq0/0O0jEmaS5d1T2xnLE3Eu4RtTMTqrFz+X7Z9x6vW5fgje1fzhUz
VbdttcmFpLmskcATgT0ZArnuV4I3tZOcK0nKwIQhZaCwWUVurhuysjsf8RW9
LBZPnJu0d7xQSen96gaRBcviDvWDaivoKdOkvT611IfT8Sb2nqhOCqwa1llG
bvMlMeDi86ZyWNsSS5xLjiTlbt9Kcwn9lj953OkpCrhcmhsrUHa4/wCFqUis
rao2+hv6EEpaFMLeD/T2COZwt3mN8VBnaMpqR+rRTbRdPb0rqQ+c/W4qC00n
vt2OJzPpYrDH6isZRl1BlOZ0jn5SSAabaEY4eVXTcrwRvayc4VQvTWqt+5Xg
g7WTnClWcrChCFloLBpPnJu0d7xW8rBZPnJu0d7xRKlbT1U4cU3tfVS7lWTG
I/sj7TklIUpF+GfackZCqsJE4paA4psTil4DikWpHTR/zLryuj9xWFnqKvWH
zc/lye6rBGasVjJhecKuO5Xgg7WTnCp17QVVx3J8EHayc4U2WcrChCFloLBZ
PnJu0d7xW9LBZPm5u0dzlEqUtTgnDtia2mxOH7FayYR/hn23JGUpWP8ADPtu
SEpVWEScUvb7U34U4g2pFqTsfm5uRnuqeiPQUBYn/lzckfuqdjPRVjJjfO2q
57keBt7WTnCpd5wq6bj+BN7WTnClWcrEhCFloLBJPm5u0d7xW9rBZPm5u0d7
xQqRtTQJw44JvbbEu84KuZgw/s3e25ISFKsqGur976aCqReq3CXCl4dqQO1L
QnEJCpSy+bl8oZzKbjPRUFZhwuXk8IB5QfV9Cmoz0cVWTW82FXTcfwIdtJzh
Ui9mjDTV4HKQrtuNX+hCu3rpOdSrOVjQhCy0FgV7UCdwNCJziPKSt9WBX5o2
ccc55ygRmmlYyAxyOaTGC6hOJqUn368H5zvOapNz84aPujKFwhgoby5GHWH6
F4Lm5eaAlx8gB+pIu2rUtKt7eCxtpNMit2mSNrg+VhJdmGOZzQTtVnVnbbtx
05ZoXXm0tePLl/8AS47zOPtkLVm2e8Erjnu7IRHa1sT3GnEK0UHvTu1by92k
juLa1kcSx8sp6oSONMrQGgjzphmeTr1nwpztRmfbRRAZJIy7NO1zg94Oxrsd
jeBIGaZ3rSPdyuJ+tFzazWdzLa3Dcs0Lix4rXEeVchR0egft2+01bVuT4Ke3
l51i5+Zb7TfqWz7j+CHt5edX0FjQhCgFgGpbZO2ct/WA6ltl8kzvrQMG8a8X
WWgafvCv0p6zTJHtDhICDxCqlsnLWnj23uNZnCPyPd6rSeRXvdC+kmsO6SVE
tocAdpidsPmOCq3dpbZpY1pe5+OamwbNg2qQ0e7h0+4NyHPEpaWO61ji1wPB
Ruxa1s5yx5fHtM63W5jRo+sc3i8gVT3m1Pd2SW3fPK69msi7LZRfhOeT+bJw
YjEBOHb2sMRbE+KIkUz0eXDgqA4UVPfBZQukIm66riQQ12I5KJ8OWmlz1m3w
ZXl5LfXUt1NTrpnl76Cgx4AOIJEKSZaRXZOUlgZ5Mu3l2pC8tI7UhucmQ0OU
02HGuCz3TOHp+rfs78Y1NWn9s0+ULatx/BD28vOsVqOtafKFte5Hgh7eXnWv
RhYkIQoBYDqX53bHnK35fP8AqD8z5gMQJTX0lAzc6rWjiFF62edjcjJHNZ90
EgLyNnWODK5SdleEpY2MnGFLj1a1m3Ouf4IGWU7XuPnK5qeMpx3N/C5ddxP3
kzDt3vua1PGvKlP2acHEAuI5EpLpcbBUPcTyBO6NfVv7IypRVPDYHgf9C4ls
zEwvc7AbMNpTMZum3sbg9IHyhbbuR4J/Gk51iQBqFtW4crJdAD2GreukFfOF
WVlQhCAWC3NtE+6mqD+I7YfKVvSzm9/671MSyS2tzDM1znODX5o3UOP6w+lB
Sm6bC7Y97fQf0J02ItaAXhxH2i3Hz0cpt+5+8UJA7mZMK1Y+M/7gmz9C1pta
2FxhtpG4j6AlkvJrvvr/AJuEU5jhskYOVhP+9cEyD85g/hH4k+k07UW+taTj
ljf8KRdpmpbe5z0PD1T6enKnbr7Nfb5P2psJJmnCdv8A8v0lddbO/bOD/Cb8
SVGl6i40FpOT2T/hTiHQ9ZeehYXDv4T/ANCduvtF+3yftt8kYYHP9aX0RgfW
nB0q1mIMzpJMuwAtYP8AS1SNpu5rrsRYygD7wDPfLVKQbq628AugEdcOm9uH
LlJVxrOJGL5PJel2titO06wi9S3FeNxLveK0XchoboTQAGjrZMAKDaFGR7j3
cn49zHHtqGNL+TbkVm0jS49KsxaRyOlaHF2ZwANXciWsyXJ+hCFGghCEAhCE
AhCEAhCEAhCEAhCEAhCEH//Z
--= Multipart Boundary 0506021755--
From arthur90277@yahoo.com Wed May 15 19:20:17 2002
From: arthur90277@yahoo.com (arthur lastmisa)
Date: Wed, 15 May 2002 11:20:17 -0700 (PDT)
Subject: [getopt-sig] Found a new interpreted language
Message-ID: <20020515182017.94054.qmail@web21507.mail.yahoo.com>
--0-422704003-1021486817=:86660
Content-Type: text/plain; charset=us-ascii
I am since a long time a programmer
I find this product very interesting. I can execute interpreted code
directly on my PC microprocessor
http://www.hyperpanel.com/boot_direct.php3?ID=13870515
---------------------------------
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
--0-422704003-1021486817=:86660
Content-Type: text/html; charset=us-ascii
I am since a long time a programmer<BR><BR>I find this product very interesting. I can execute interpreted code<BR>directly on my PC microprocessor<BR><BR><A href="http://www.hyperpanel.com/boot_direct.php3?ID=13870515">http://www.hyperpanel.com/boot_direct.php3?ID=13870515</A><BR><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://rd.yahoo.com/welcome/*http://launch.yahoo.com">LAUNCH</a> - Your Yahoo! Music Experience
--0-422704003-1021486817=:86660--
From lolita86@libero.it Thu May 23 18:25:03 2002
From: lolita86@libero.it (lolita)
Date: Fri, 24 May 2002 00.25.00 +0200
Subject: [getopt-sig] Eros e soldi:guadagna con internet 0,08 euro a clic
Message-ID: <E17B10s-0007ka-00@mail.python.org>
sono lolita=2C voglio presentarti il mio nuovo sito
affiliazione gratuita con guadagni immediati=3A erotismo=2C chat=2Cloghi e sonerie etc=2C etc=2C
l'unico sito che paga cos=EC tanto 0=2C08 euro a clic =2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2Eguarda bene la pg di affiliazione=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2Ee buon divertimento=2E
visita il sito=3A http=3A=2F=2Fmembers=2Exoom=2Eit=2Fmarym1976 http=3A=2F=2Fmembers=2Exoom=2Eit=2Fmarym1976 http=3A=2F=2Fmembers=2Exoom=2Eit=2Fmarym1976
From guido@python.org Thu May 30 04:42:03 2002
From: guido@python.org (Guido van Rossum)
Date: Wed, 29 May 2002 23:42:03 -0400
Subject: [getopt-sig] The bake-off
Message-ID: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net>
This SIG is supposed to come up with a recommendation. Having an
option parsing library is one of the goals for Python 2.3 (I just
added this to PEP 283 :-).
I read Greg's bake-off. (http://www.python.org/sigs/getopt-sig/compare.html)
I didn't read the mailing list archives. Has there been more
discussion of the bake-off? The bake-off mostly convinced me that
Optik is the way to go for the standard library. I have an idea for a
second-order bake-off though.
Greg writes:
One weakness of Ripoff's command-line interface is that several
flag options don't have a negative counterpart: eg. there is a
--keep-tmp option, but no --no-keep-tmp. That sort of thing really
is necessary in the real world, where a program's default
(no-keep-tmp in this case) might be overridden by a config file,
and then overridden again on the command-line. This weakness is
currently reflected in all three of my test re-implementations.
As an exercice in how easy each of the three alternatives makes it to
change the option set, I'd like to see each version augmented with
this feature. There may be no config file yet, so maybe the default
values will have to be specified in a different way, like as globals.
The code to add that shouldn't be measured for the comparison below.
Then it would be useful to see how large the new version is (with and
without the help text) and how many lines had to be changed. If the
three contestants come out in the same order as in the first contest,
that settles the matter for me. If not, we'll have to try to
understand why.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From rsc@plan9.bell-labs.com Thu May 30 04:42:42 2002
From: rsc@plan9.bell-labs.com (rsc@plan9.bell-labs.com)
Date: Wed, 29 May 2002 23:42:42 -0400
Subject: [getopt-sig] The bake-off
Message-ID: <bc9a89706263794a764a35ac95f15d0c@plan9.bell-labs.com>
I think Optik is the way to go (and I'm the author
of one of the two packages competing with it).
Russ
From david@sleepydog.net Thu May 30 10:16:13 2002
From: david@sleepydog.net (David Boddie)
Date: Thu, 30 May 2002 10:16:13 +0100
Subject: [getopt-sig] The bake-off
In-Reply-To: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net>
References: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net>
Message-ID: <200205301016.13451.david@sleepydog.net>
On Thursday 30 May 2002 4:42 am, Guido van Rossum wrote:
> I read Greg's bake-off.
> (http://www.python.org/sigs/getopt-sig/compare.html)
>
> I didn't read the mailing list archives. Has there been more
> discussion of the bake-off?
There was some discussion about the use of conflicting options, resulting from
the practice of aliasing commands. Whether things like "--verbose --quiet"
were allowable proved to be a point of contention.
> The bake-off mostly convinced me that
> Optik is the way to go for the standard library. I have an idea for a
> second-order bake-off though.
>
> Greg writes:
>
> One weakness of Ripoff's command-line interface is that several
> flag options don't have a negative counterpart: eg. there is a
> --keep-tmp option, but no --no-keep-tmp. That sort of thing really
> is necessary in the real world, where a program's default
> (no-keep-tmp in this case) might be overridden by a config file,
> and then overridden again on the command-line. This weakness is
> currently reflected in all three of my test re-implementations.
>
> As an exercice in how easy each of the three alternatives makes it to
> change the option set, I'd like to see each version augmented with
> this feature. There may be no config file yet, so maybe the default
> values will have to be specified in a different way, like as globals.
> The code to add that shouldn't be measured for the comparison below.
So, you need each example to include the extra baggage which sets default
values.
Do you want to see implementations of mechanisms for validating types and
resolving option conflicts as well?
David
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________
From holger@trillke.net Thu May 30 10:31:09 2002
From: holger@trillke.net (holger@trillke.net)
Date: Thu, 30 May 2002 11:31:09 +0200
Subject: [getopt-sig] The bake-off
In-Reply-To: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net>
References: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net>
Message-ID: <20020530093109.GQ2845@devel.trillke>
[Guido van Rossum Wed, May 29, 2002 at 11:42:03PM -0400]
> This SIG is supposed to come up with a recommendation. Having an
> option parsing library is one of the goals for Python 2.3 (I just
> added this to PEP 283 :-).
>
> I read Greg's bake-off. (http://www.python.org/sigs/getopt-sig/compare.html)
>
> I didn't read the mailing list archives.
i came in late to the SIG but it appears that in the last two or three
month discussion was non-existent. The original SIG-people seem
to agree on Optik so i respectfully stay out of their way.
It's just a bit frustrating to see that the 'inner pythoneer circles'
tend to ignore people willing to contribute :-(
They may have good reasons but *complete* lack of communicating them
is not very motivating (despite http://www.python.org/dev/why.html )
regards,
holger
From Paul.Moore@atosorigin.com Thu May 30 10:59:24 2002
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Thu, 30 May 2002 10:59:24 +0100
Subject: [getopt-sig] The bake-off
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5B356@UKRUX002.rundc.uk.origin-it.com>
From: holger@trillke.net [mailto:holger@trillke.net]
> i came in late to the SIG but it appears that in the last two or three
> month discussion was non-existent. The original SIG-people seem
> to agree on Optik so i respectfully stay out of their way.
>
> It's just a bit frustrating to see that the 'inner pythoneer circles'
> tend to ignore people willing to contribute :-(
>
> They may have good reasons but *complete* lack of communicating them
> is not very motivating (despite http://www.python.org/dev/why.html )
I'm pretty much an outsider to the discussions. I've watched them, as I
often need option parsing code, and I'd like to find a "nice" package. But I
tried not to get involved in detail discussions, as I have not (yet) started
using any of the "competing" packages.
My view of the discussions was:
1. There were a number of people who were fairly enthusiastic about Optik
(not just Greg, the author). On the other hand, you seemed alone in your
defence of your package.
2. Greg was very willing to accept new ideas, and in general, I got the
impression that Optik was flexible enough to cater for many styles. The fact
that Greg stopped including suggestions in the "core" of Optik and started
having them as sample extensions is not, to my mind, a bad thing - it
implies a level of stability while still being flexible enough for people
who care about a different approach (IMHO). I don't recall there being any
specific aspect of what you were doing which couldn't be handled by Optik -
it's just that your approach differed in underlying ways which made
implementing it in Optik seem clumsy and unnatural.
3. I never really understood the approach of your package. The philosophy
seems fundamentally different, in some fairly core areas. Most notably
(IIRC) was the fact that your package centralised the storage of all option
values in an "options" class. Personally, I don't particularly care for that
approach (although I can see it being a reasonable idea for large-scale
projects, it feels like overkill for the small scripts I write).
4. You seemed to be arguing for a "one approach is best" design, whereas
Optik tries more to be "all things to all men". This may result in extra
complexity for Optik, which could be a downside, but it seems to be a more
generally acceptable approach.
Overall, the feeling I got was not that your contributions were being
ignored, but rather that people were struggling to understand the costs and
benefits of the two packages. Optik seems more "policy-neutral" than your
approach, which is generally seen as a benefit. Possibly you see that as a
disadvantage, which is where the fundamental difference arises.
As I said, this is all my view of other people's discussions which happened
a few months back. Any relation to reality is probably entirely coincidental
:-) But I wanted to address your frustrations. The discussions did become
frustrating, and did "fizzle out" without a proper conclusion, but I don't
believe that there was an unwillingness to listen - more that the message
wasn't coming across.
I'm not trying to re-open the debate - I'm pretty much convinced that Optik
is right for *my* needs - but I don't think you were ignored.
Hope this helps,
Paul Moore.
From david@sleepydog.net Thu May 30 10:16:13 2002
From: david@sleepydog.net (David Boddie)
Date: Thu, 30 May 2002 10:16:13 +0100
Subject: [getopt-sig] The bake-off
In-Reply-To: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net>
References: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net>
Message-ID: <200205301016.13451.david@sleepydog.net>
On Thursday 30 May 2002 4:42 am, Guido van Rossum wrote:
> I read Greg's bake-off.
> (http://www.python.org/sigs/getopt-sig/compare.html)
>
> I didn't read the mailing list archives. Has there been more
> discussion of the bake-off?
There was some discussion about the use of conflicting options, resulting from
the practice of aliasing commands. Whether things like "--verbose --quiet"
were allowable proved to be a point of contention.
> The bake-off mostly convinced me that
> Optik is the way to go for the standard library. I have an idea for a
> second-order bake-off though.
>
> Greg writes:
>
> One weakness of Ripoff's command-line interface is that several
> flag options don't have a negative counterpart: eg. there is a
> --keep-tmp option, but no --no-keep-tmp. That sort of thing really
> is necessary in the real world, where a program's default
> (no-keep-tmp in this case) might be overridden by a config file,
> and then overridden again on the command-line. This weakness is
> currently reflected in all three of my test re-implementations.
>
> As an exercice in how easy each of the three alternatives makes it to
> change the option set, I'd like to see each version augmented with
> this feature. There may be no config file yet, so maybe the default
> values will have to be specified in a different way, like as globals.
> The code to add that shouldn't be measured for the comparison below.
So, you need each example to include the extra baggage which sets default
values.
Do you want to see implementations of mechanisms for validating types and
resolving option conflicts as well?
David
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________
From holger@trillke.net Thu May 30 12:46:45 2002
From: holger@trillke.net (holger@trillke.net)
Date: Thu, 30 May 2002 13:46:45 +0200
Subject: [getopt-sig] The bake-off
In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5B356@UKRUX002.rundc.uk.origin-it.com>
References: <714DFA46B9BBD0119CD000805FC1F53B01B5B356@UKRUX002.rundc.uk.origin-it.com>
Message-ID: <20020530114645.GS2845@devel.trillke>
[Moore, Paul Thu, May 30, 2002 at 10:59:24AM +0100]
> From: holger@trillke.net [mailto:holger@trillke.net]
> > i came in late to the SIG but it appears that in the last two or three
> > month discussion was non-existent. The original SIG-people seem
> > to agree on Optik so i respectfully stay out of their way.
> >
> > It's just a bit frustrating to see that the 'inner pythoneer circles'
> > tend to ignore people willing to contribute :-(
> >
> > They may have good reasons but *complete* lack of communicating them
> > is not very motivating (despite http://www.python.org/dev/why.html )
>
> I'm pretty much an outsider to the discussions. I've watched them, as I
> often need option parsing code, and I'd like to find a "nice" package. But I
> tried not to get involved in detail discussions, as I have not (yet) started
> using any of the "competing" packages.
>
> My view of the discussions was:
>
> 1. There were a number of people who were fairly enthusiastic about Optik
> (not just Greg, the author). On the other hand, you seemed alone in your
> defence of your package.
you must confuse me with someone else!
I didn't have any package to defend ...
Additionally, I was just refering to *the discussion* and not to
package specific things.
regards,
holger
From guido@python.org Thu May 30 13:22:26 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 30 May 2002 08:22:26 -0400
Subject: [getopt-sig] The bake-off
In-Reply-To: Your message of "Thu, 30 May 2002 10:16:13 BST."
<200205301016.13451.david@sleepydog.net>
References: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net>
<200205301016.13451.david@sleepydog.net>
Message-ID: <200205301222.g4UCMRI07547@pcp742651pcs.reston01.va.comcast.net>
> There was some discussion about the use of conflicting options,
> resulting from the practice of aliasing commands. Whether things
> like "--verbose --quiet" were allowable proved to be a point of
> contention.
Hm, obviously the last option wins; it's a common trick to alias a
command to specify a bunch of default options, and it's useful to
override those explicitly by adding more options to the alias
invocation.
> > As an exercice in how easy each of the three alternatives makes it to
> > change the option set, I'd like to see each version augmented with
> > this feature. There may be no config file yet, so maybe the default
> > values will have to be specified in a different way, like as globals.
> > The code to add that shouldn't be measured for the comparison below.
>
> So, you need each example to include the extra baggage which sets default
> values.
Yes
> Do you want to see implementations of mechanisms for validating
> types and resolving option conflicts as well?
If you think it helps, sure.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From pobrien@orbtech.com Thu May 30 13:36:15 2002
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Thu, 30 May 2002 07:36:15 -0500
Subject: [getopt-sig] The bake-off
In-Reply-To: <20020530093109.GQ2845@devel.trillke>
Message-ID: <NBBBIOJPGKJEKIECEMCBGEFNNCAA.pobrien@orbtech.com>
> i came in late to the SIG but it appears that in the last two or three
> month discussion was non-existent. The original SIG-people seem
> to agree on Optik so i respectfully stay out of their way.
IMHO, I think what happened was Optik got refined based on some good
feedback and no other solution came out as significantly better so the
discussion kind of faded. In other words, we're all guilty of respectfully
staying out of the way.
> It's just a bit frustrating to see that the 'inner pythoneer circles'
> tend to ignore people willing to contribute :-(
I'm sure both the frustration and lack of attention you feel are real. I've
felt them myself. What I don't think is real is any intentional exclusion or
ill will on the part of the 'inner pythoneer circles'. In fact, I've seen
the same frustrations expressed by folks who would be considered part of
that 'inner circle'. Guido himself seems to get just as frustrated as the
rest of us.
I think that if you want to really play a role in the development of Python
itself then it helps to try not to take criticism too personally, don't
expect anyone to get excited by a good idea that hasn't been proven, and
don't be surprised that even a good proven idea doesn't motivate too many
people to go out of their way to help or support you.
> They may have good reasons but *complete* lack of communicating them
> is not very motivating (despite http://www.python.org/dev/why.html )
I find this last statement a bit hard to swallow. Let's just chalk it up to
frustration. But the fact is that a SIG was created, anyone can join it,
anyone can post to it, anyone can read the archives, all the posts that I
read seemed to get a fair response, alternative solutions were created and
posted in a public location (created through the time and effort of a single
individual trying to get a fair assessment of the alternatives), etc, etc.
Clearly this is not a complete lack of communication. But, you may have been
referring to the fact that the people willing to contribute were ignored.
And it does appear that the contributions on this SIG fizzled out and were
ignored. In a way, that's true. Guido seems to have recognized that and come
along to get the ball rolling again. So let's get the ball rolling. :-)
---
Patrick K. O'Brien
Orbtech
From gward@python.net Thu May 30 13:46:37 2002
From: gward@python.net (Greg Ward)
Date: Thu, 30 May 2002 08:46:37 -0400
Subject: [getopt-sig] The bake-off
In-Reply-To: <200205301222.g4UCMRI07547@pcp742651pcs.reston01.va.comcast.net>
References: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net> <200205301016.13451.david@sleepydog.net> <200205301222.g4UCMRI07547@pcp742651pcs.reston01.va.comcast.net>
Message-ID: <20020530124637.GA8921@gerg.ca>
On 30 May 2002, Guido van Rossum said:
> > There was some discussion about the use of conflicting options,
> > resulting from the practice of aliasing commands. Whether things
> > like "--verbose --quiet" were allowable proved to be a point of
> > contention.
>
> Hm, obviously the last option wins; it's a common trick to alias a
> command to specify a bunch of default options, and it's useful to
> override those explicitly by adding more options to the alias
> invocation.
Yes, I was surprised that there were people (maybe only one person --
forget who) who thought that use of mutually conflicting command-line
options should be disallowed by the standard option-parsing library. I
think that was a minority viewpoint, and it was pretty thoroughly shot
down.
I'll go see about augmenting Optik's entry into the bake-off per your
requirements.
Greg
--
Greg Ward - Linux geek gward@python.net
http://starship.python.net/~gward/
I'd like some JUNK FOOD ... and then I want to be ALONE --
From Paul.Moore@atosorigin.com Thu May 30 13:47:00 2002
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Thu, 30 May 2002 13:47:00 +0100
Subject: [getopt-sig] The bake-off
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5B359@UKRUX002.rundc.uk.origin-it.com>
> you must confuse me with someone else!
>
> I didn't have any package to defend ...
>
> Additionally, I was just refering to *the discussion* and not to
> package specific things.
Sorry, you're right. I think I was thinking of Albert Hofkamp, who came up
with an alternative to Optik. But as I said, I never quite followed what he
was trying to suggest was the benefit for his package compared to Optik.
I agree that things sort of lost momentum on the SIG. But I see that as more
a sign that Optik had "won" than anything else. I would have expected the
next step to be for Greg to post some sort of "We have a winner" summary of
the SIG's conclusions, and then take up the process of getting Optik moved
into the Python library. I'd assumed that Greg was being (politely)
cautious, so as not to be seen to be jumping the gun in favour of his
package.
Paul.
From guido@python.org Thu May 30 13:57:01 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 30 May 2002 08:57:01 -0400
Subject: [getopt-sig] The bake-off
In-Reply-To: Your message of "Thu, 30 May 2002 08:46:37 EDT."
<20020530124637.GA8921@gerg.ca>
References: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net> <200205301016.13451.david@sleepydog.net> <200205301222.g4UCMRI07547@pcp742651pcs.reston01.va.comcast.net>
<20020530124637.GA8921@gerg.ca>
Message-ID: <200205301257.g4UCv1a07859@pcp742651pcs.reston01.va.comcast.net>
> I'll go see about augmenting Optik's entry into the bake-off per your
> requirements.
Or, if the consensus is that Optik wins by a large margin, don't
bother -- just check it into the Python source tree (maybe think of a
more neutral name first).
--Guido van Rossum (home page: http://www.python.org/~guido/)
From guido@python.org Thu May 30 13:57:55 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 30 May 2002 08:57:55 -0400
Subject: [getopt-sig] The bake-off
In-Reply-To: Your message of "Thu, 30 May 2002 13:47:00 BST."
<714DFA46B9BBD0119CD000805FC1F53B01B5B359@UKRUX002.rundc.uk.origin-it.com>
References: <714DFA46B9BBD0119CD000805FC1F53B01B5B359@UKRUX002.rundc.uk.origin-it.com>
Message-ID: <200205301257.g4UCvtb07875@pcp742651pcs.reston01.va.comcast.net>
> I agree that things sort of lost momentum on the SIG.
That's a normal thing to happen to a SIG when either consensus is
reached or no consensus appears possible.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From david@sleepydog.net Thu May 30 13:50:15 2002
From: david@sleepydog.net (David Boddie)
Date: Thu, 30 May 2002 13:50:15 +0100
Subject: [getopt-sig] The bake-off
In-Reply-To: <200205301222.g4UCMRI07547@pcp742651pcs.reston01.va.comcast.net>
References: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net> <200205301016.13451.david@sleepydog.net> <200205301222.g4UCMRI07547@pcp742651pcs.reston01.va.comcast.net>
Message-ID: <200205301350.15711.david@sleepydog.net>
On Thursday 30 May 2002 1:22 pm, Guido van Rossum wrote:
> > There was some discussion about the use of conflicting options,
> > resulting from the practice of aliasing commands. Whether things
> > like "--verbose --quiet" were allowable proved to be a point of
> > contention.
>
> Hm, obviously the last option wins; it's a common trick to alias a
> command to specify a bunch of default options, and it's useful to
> override those explicitly by adding more options to the alias
> invocation.
So, do you consider that the rightmost options always take precedence
over others? An alternative viewpoint can be found here:
http://mail.python.org/pipermail/getopt-sig/2002-February/000097.html
I would consider something like an --override option would be useful
for requesting that any previous options (possibly supplied by an
alias) be ignored in favour of new ones added at the command line.
e.g. mycommand --quiet --override --verbose
However, I'm not sure that this is the most appropriate time to
suggest such a feature, given that we've extensively debated this
in the past.
My suggestion doesn't allow individual options to be overridden,
either.
> > Do you want to see implementations of mechanisms for validating
> > types and resolving option conflicts as well?
>
> If you think it helps, sure.
It might make the playing field more level.
David
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________
From gward@python.net Thu May 30 13:58:37 2002
From: gward@python.net (Greg Ward)
Date: Thu, 30 May 2002 08:58:37 -0400
Subject: [getopt-sig] The bake-off
In-Reply-To: <20020530093109.GQ2845@devel.trillke>
References: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net> <20020530093109.GQ2845@devel.trillke>
Message-ID: <20020530125837.GB8921@gerg.ca>
On 30 May 2002, holger@trillke.net said:
> i came in late to the SIG but it appears that in the last two or three
> month discussion was non-existent. The original SIG-people seem
> to agree on Optik so i respectfully stay out of their way.
If you are referring to your proposal of 9 April in this post:
http://mail.python.org/pipermail/getopt-sig/2002-April/000121.html
then here's my belated reaction: too clever and too implicit. I like
the fact that Python enables code inspection, but I think relying on it
for everyday work like option-parsing is just wrong. If you really,
really want to promote your proposal, then 1) how about an
implementation, and 2) supply an entry for the bake-off at
http://www.python.org/sigs/getopt-sig/compare.html
I'm pretty sure that I'll still prefer Optik, though.
> It's just a bit frustrating to see that the 'inner pythoneer circles'
> tend to ignore people willing to contribute :-(
You did sort of miss the main discussion in February. Lots of ideas,
both good and bad, were kicked around. I didn't recognize anyone from
the "inner pythoneer circles", except Tim Peters who as usual clarified
things enormously in a few short sentences. Many of the good ideas made
it into Optik 1.3. I'm satisfied with the process, but then I would be,
wouldn't I? ;-)
Greg
--
Greg Ward - geek-at-large gward@python.net
http://starship.python.net/~gward/
Outside of a dog, a book is man's best friend.
Inside of a dog, it's too dark to read.
From holger@trillke.net Thu May 30 14:17:19 2002
From: holger@trillke.net (holger@trillke.net)
Date: Thu, 30 May 2002 15:17:19 +0200
Subject: [getopt-sig] The bake-off
In-Reply-To: <20020530125837.GB8921@gerg.ca>
References: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net> <20020530093109.GQ2845@devel.trillke> <20020530125837.GB8921@gerg.ca>
Message-ID: <20020530131719.GW2845@devel.trillke>
[Greg Ward Thu, May 30, 2002 at 08:58:37AM -0400]
> On 30 May 2002, holger@trillke.net said:
> > i came in late to the SIG but it appears that in the last two or three
> > month discussion was non-existent. The original SIG-people seem
> > to agree on Optik so i respectfully stay out of their way.
>
> If you are referring to your proposal of 9 April in this post:
>
> http://mail.python.org/pipermail/getopt-sig/2002-April/000121.html
>
> then here's my belated reaction: too clever and too implicit. I like
> the fact that Python enables code inspection, but I think relying on it
> for everyday work like option-parsing is just wrong. If you really,
> really want to promote your proposal, then 1) how about an
> implementation, and 2) supply an entry for the bake-off at
>
> http://www.python.org/sigs/getopt-sig/compare.html
>
> I'm pretty sure that I'll still prefer Optik, though.
thanks! I understand the criticism. Bear in mind though that
i was *not* suggesting an alternative to Optik.
the idea was to make it *even cheaper* to write cmdline-tools
with a rich interface. The basic idea is to construct a 'namespace'-mapping
between the shell-cmdline and a python function (or class). I suggested to
use Optik as the backend for this. I was (and probably still am <wink>)
willing to implement this but it is difficult if there is no feedback :-)
regards,
holger
From gward@python.net Thu May 30 14:30:23 2002
From: gward@python.net (Greg Ward)
Date: Thu, 30 May 2002 09:30:23 -0400
Subject: [getopt-sig] The bake-off
In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5B359@UKRUX002.rundc.uk.origin-it.com>
References: <714DFA46B9BBD0119CD000805FC1F53B01B5B359@UKRUX002.rundc.uk.origin-it.com>
Message-ID: <20020530133023.GC8921@gerg.ca>
On 30 May 2002, Moore, Paul said:
> I agree that things sort of lost momentum on the SIG. But I see that as more
> a sign that Optik had "won" than anything else. I would have expected the
> next step to be for Greg to post some sort of "We have a winner" summary of
> the SIG's conclusions, and then take up the process of getting Optik moved
> into the Python library. I'd assumed that Greg was being (politely)
> cautious, so as not to be seen to be jumping the gun in favour of his
> package.
Or I was waiting for Guido to do it for me. ;-)
OK, OK: the real reason is that I ran out of steam. I had *just* enough
energy for this project to get Optik 1.3 documented and out the door,
and that was it. Also, I was on holiday and off the 'net for the second
half of April, so completely lost track of what's been going on on
python-dev.
I guess it's time to finish the job and come up with a plan for adding
Optik to the standard library. See my next post...
Greg
--
Greg Ward - Unix geek gward@python.net
http://starship.python.net/~gward/
Quick!! Act as if nothing has happened!
From a.t.hofkamp@tue.nl Thu May 30 14:36:45 2002
From: a.t.hofkamp@tue.nl (A.T. Hofkamp)
Date: Thu, 30 May 2002 15:36:45 +0200 (CEST)
Subject: [getopt-sig] The bake-off
In-Reply-To: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net>
Message-ID: <Pine.LNX.4.33.0205301433140.1081-100000@se-46.wpa.wtb.tue.nl>
Hello Guido, SIG,
I'd like to respond to your challenge as author of argtools.
I also tried to describe how Optik, argparser, and argtools 'feel', or at
least how I experienced it.
On Wed, 29 May 2002, Guido van Rossum wrote:
> As an exercice in how easy each of the three alternatives makes it to
> change the option set, I'd like to see each version augmented with
> this feature. There may be no config file yet, so maybe the default
Argtools doe not need to be augmented, it already supports this.
It it would not this, one would need to write a new derived class for a
yes/no option, which takes about 5-10 lines of Python.
With respect to the (now very dead) discussion:
Basically, the discussion ended with in a deadlock-like situation.
In my opinion, there exists fundamental disagreement about how to
approach the option parsing problem in the general case.
First of all, Optik does a nice job for the average case. Its use of
objects for options is a natural choice for many programs. Also, it is
relatively easy to explain to new-comers.
The bad side of Optik is that it is not particularly special in the world
of option parsing, i.e. it does not do anything real fancy.
Also, Optik tries to do its thing as a whole.
This is in my opinion the core fundamental disagreement.
For simpler needs than Optik, i.e. something near
for arg in sys.argv:
if arg == option-e:
# handle option -e
elif ...
or for something much more complex, like "cvs <command>
<command-specific-options>", Optik delivers no support, i.e. in both cases,
we are back to scratch "we have sys,argv, what now ?"
The same happens when you'd want to add something new, like for example a
config file.
Greg (the author of Optik) considers support for such situations outside
the goal of Optik (his goal is 'something better than getopt' as I recall).
I think (and a number of other people in this SIG as well), that we should
aim for something more flexible/modular, to avoid the situation that a user
of the option parsing library has to start from scratch even (especially!!)
in the extremely simple and extremely complex cases.
Argparser of Russ Cox aims for the simple case (which I consider very
readable, in particular for people not used to objects), argtools is a
special-purpose library that I wrote in C++, and translated to Python.
The latter tool is very basic, and extremely object-oriented (more than
Optik).
Unfortunately, I do not have the time to implement a modular parsing
library to a level like Optik.
As for the proposals done later, I did not understand what was happening,
and how that proposal relates to other option parsing libraries.
> without the help text) and how many lines had to be changed. If the
> three contestants come out in the same order as in the first contest,
> that settles the matter for me. If not, we'll have to try to
> understand why.
The Argtools version will not change in any way, except that a different
class must be instantiated.
For people understanding the object-oriented concepts, argtools is the
smallest and most flexible (though not flexible enough to handle e.g. cvs
like option parsing).
The downside of argtools is that it does not do everything, for example the
user still has to write a help-page by hand.
Optik is also object-oriented, but its interface to the user buries a lot
of it. Also, Optik is far more complete. That makes it an ideal tool for
the average case, but extending Optik is very difficult (basically, the objects
are dropped, and you are stuck with call-backs to functions in a
non-object-oriented fashion).
Argparser is not object-oriented, and thus like getopt, is extremely accessible
for newbies, and users not familiar with object-oriented concepts. The
downside is that the library offers no structure for the more complex cases
(i.e. it is a lot of DIY).
Albert
--
Unlike popular belief, the .doc format is not an open publically available format.
From gward@python.net Thu May 30 14:37:20 2002
From: gward@python.net (Greg Ward)
Date: Thu, 30 May 2002 09:37:20 -0400
Subject: [getopt-sig] The bake-off
In-Reply-To: <20020530131719.GW2845@devel.trillke>
References: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net> <20020530093109.GQ2845@devel.trillke> <20020530125837.GB8921@gerg.ca> <20020530131719.GW2845@devel.trillke>
Message-ID: <20020530133720.GD8921@gerg.ca>
On 30 May 2002, holger@trillke.net said:
> the idea was to make it *even cheaper* to write cmdline-tools
> with a rich interface. The basic idea is to construct a 'namespace'-mapping
> between the shell-cmdline and a python function (or class). I suggested to
> use Optik as the backend for this. I was (and probably still am <wink>)
> willing to implement this but it is difficult if there is no feedback :-)
But Optik already makes good use of namespaces: when you do this
(options, args) = parser.parse_args()
then the 'options' object is a namespace containing the user-supplied
values from the command-line. IOW, you get a namespace on the way out.
There's no namespace on the way in though: options are defined through
explicit, verbose calls to parser.add_option(). I just don't see the
point of your interface. But by all means, go ahead and implement it on
top of Optik. If Optik gets in your way and needs refactoring, please
howl -- I'm still (somewhat) willing to entertain proposed code
reorganization. But that willingness becomes less as time goes on...
Greg
--
Greg Ward - Unix geek gward@python.net
http://starship.python.net/~gward/
"Question authority!" "Oh yeah? Says who?"
From Paul.Moore@atosorigin.com Thu May 30 14:39:29 2002
From: Paul.Moore@atosorigin.com (Moore, Paul)
Date: Thu, 30 May 2002 14:39:29 +0100
Subject: [getopt-sig] The bake-off
Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5B35B@UKRUX002.rundc.uk.origin-it.com>
From: holger@trillke.net [mailto:holger@trillke.net]
> thanks! I understand the criticism. Bear in mind though that
> i was *not* suggesting an alternative to Optik.
That wasn't clear to me at the time... Sorry.
> the idea was to make it *even cheaper* to write cmdline-tools
> with a rich interface. The basic idea is to construct a
> 'namespace'-mapping between the shell-cmdline and a python
> function (or class). I suggested to use Optik as the backend
> for this. I was (and probably still am <wink>) willing to
> implement this but it is difficult if there is no feedback :-)
It sounds like you're essentially talking about an "application framework"
for simple command-line type scripts. If so, then my feeling is that it's a
nice idea, and probably something I'd play with occasionally. I don't know
if it would get much use in practice, though - it generally isn't too hard
to use something like getopt/Optik "by hand".
I'm not too bothered by the introspection aspect - Greg's concern that it's
excessively "clever" isn't a problem to me if it's behind the scenes.
If you implement this, I promise I'll download it and try it out :-) But I
don't know that it will ever find its way into my list of packages that I'd
always install.
Paul.
PS You're not alone in hitting this sort of thing. It's more to do with the
nature of Python, the language (and set of libraries), than with the
community - things like this are easy enough to do that there's not much
pressure for a standardised solution. (See the recent thread on c.l.p about
packaging up Python code in single files, like JAR files do for Java, for
another example).
From gward@python.net Thu May 30 14:49:05 2002
From: gward@python.net (Greg Ward)
Date: Thu, 30 May 2002 09:49:05 -0400
Subject: [getopt-sig] The bake-off
In-Reply-To: <Pine.LNX.4.33.0205301433140.1081-100000@se-46.wpa.wtb.tue.nl>
References: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net> <Pine.LNX.4.33.0205301433140.1081-100000@se-46.wpa.wtb.tue.nl>
Message-ID: <20020530134904.GE8921@gerg.ca>
On 30 May 2002, A.T. Hofkamp said:
> The bad side of Optik is that it is not particularly special in the world
> of option parsing, i.e. it does not do anything real fancy.
Exactly. Change "bad" to "good" and that could be me talking.
> Also, Optik tries to do its thing as a whole.
> This is in my opinion the core fundamental disagreement.
>
> For simpler needs than Optik, i.e. something near
>
> for arg in sys.argv:
> if arg == option-e:
> # handle option -e
> elif ...
If you have one or two options, it's a wash: DIY or getopt or Optik are
all about the same amount of code. But when those one or two options
grow, as they always do, Optik wins hands-down.
> or for something much more complex, like "cvs <command>
> <command-specific-options>", Optik delivers no support, i.e. in both cases,
> we are back to scratch "we have sys,argv, what now ?"
Not true. This was discussed in detail back in Feburary; all you have
to do is create multiple OptionParser objects, and pass each chunk of
your command-line through them in turn. I even posted (untested,
hypothetical) code for this.
> The same happens when you'd want to add something new, like for example a
> config file.
> Greg (the author of Optik) considers support for such situations outside
> the goal of Optik (his goal is 'something better than getopt' as I recall).
I don't think this is one of the Nineteen Pythonic Theses, but maybe
there should be a Twentieth:
Don't let "perfect" be the enemy of "good enough".
Perfection is unattainable by us puny mortals; good enough is, well,
good enough.
BTW, I have written one app that uses Optik and a config-file (although
the config file is just a Python module, as I have decided that Python
is after all the right language for config files). It's good enough.
> For people understanding the object-oriented concepts, argtools is the
> smallest and most flexible (though not flexible enough to handle e.g. cvs
> like option parsing).
*splutter* but you just criticized Optik for not being able to handle a
"sub-command" style of interface out-of-the-box!
> The downside of argtools is that it does not do everything, for example the
> user still has to write a help-page by hand.
> Optik is also object-oriented, but its interface to the user buries a lot
> of it. Also, Optik is far more complete. That makes it an ideal tool for
> the average case, but extending Optik is very difficult (basically, the objects
> are dropped, and you are stuck with call-backs to functions in a
> non-object-oriented fashion).
Callbacks are not the standard way of extending Optik; they're just
there for cases where you don't need to extend the core classes.
They're not strictly necessary, but they are convenient. I imagine they
will be especially useful for naive users who are afraid of subclassing.
Extensive, detailed instructions for how to extend Optik -- in the OO
way, by subclassing Option and/or OptionParser -- are included in the
source distribution. Several examples of what you can do by subclassing
Optik are in the examples/ directory.
Greg
--
Greg Ward - programmer-at-large gward@python.net
http://starship.python.net/~gward/
Those of you who think you know everything really annoy those of us who do.
From a.t.hofkamp@tue.nl Thu May 30 15:02:04 2002
From: a.t.hofkamp@tue.nl (A.T. Hofkamp)
Date: Thu, 30 May 2002 16:02:04 +0200 (CEST)
Subject: [getopt-sig] The bake-off
In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5B359@UKRUX002.rundc.uk.origin-it.com>
Message-ID: <Pine.LNX.4.33.0205301542100.1081-100000@se-46.wpa.wtb.tue.nl>
On Thu, 30 May 2002, Moore, Paul wrote:
> Sorry, you're right. I think I was thinking of Albert Hofkamp, who came up
> with an alternative to Optik. But as I said, I never quite followed what he
> was trying to suggest was the benefit for his package compared to Optik.
I wasn't :-)
I was trying to understand the core issues that need to be dealt with, when
writing an option parsing library.
I have seen a quite large number of (C++/Java/Python) option parsing libraries,
and all of them just seem to grab a solution from the air, implement it,
and present it as the solution (Optik does that too).
Yet for some reason, getopt is the most commonly used option parsing library.
Therefore, I concluded, there is something that getopt has, what is missing
in all the other libraries.
I thought (and still think), that in order to write a good option
processing package, we need to dig what that something is.
Without that knowledge, the only possible result is an option processing
package that also nobody uses.
In other words, I haven't yet arrived at the point where I understand what
an option processing package needs, let alone have implemented something
generally usable.
argtools was/is just a case study for this SIG (although the tool is actively
being used here), and in a sense some counter-weight for the dominant
presence of pro-Optik.
> a sign that Optik had "won" than anything else. I would have expected the
I considered it a dead-lock, as explained in my previous post.
Albert
--
Unlike popular belief, the .doc format is not an open publically available format.
From holger@trillke.net Thu May 30 15:21:53 2002
From: holger@trillke.net (holger@trillke.net)
Date: Thu, 30 May 2002 16:21:53 +0200
Subject: [getopt-sig] The bake-off
In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5B35B@UKRUX002.rundc.uk.origin-it.com>
References: <714DFA46B9BBD0119CD000805FC1F53B01B5B35B@UKRUX002.rundc.uk.origin-it.com>
Message-ID: <20020530142153.GZ2845@devel.trillke>
[Moore, Paul Thu, May 30, 2002 at 02:39:29PM +0100]
> From: holger@trillke.net [mailto:holger@trillke.net]
> > thanks! I understand the criticism. Bear in mind though that
> > i was *not* suggesting an alternative to Optik.
>
> That wasn't clear to me at the time... Sorry.
probably my fault also.
> > the idea was to make it *even cheaper* to write cmdline-tools
> > with a rich interface. The basic idea is to construct a
> > 'namespace'-mapping between the shell-cmdline and a python
> > function (or class). I suggested to use Optik as the backend
> > for this. I was (and probably still am <wink>) willing to
> > implement this but it is difficult if there is no feedback :-)
>
> It sounds like you're essentially talking about an "application framework"
> for simple command-line type scripts. If so, then my feeling is that it's a
> nice idea, and probably something I'd play with occasionally. I don't know
> if it would get much use in practice, though - it generally isn't too hard
> to use something like getopt/Optik "by hand".
true enough :-)
btw, Zope and other web-frameworks map an URL to a method in python as
well<wink>. I think that providing glue code in the standard lib
that maps the command line to a python function would considerably
lower the barrier to
a) make up a nice-for-the-user-and-programmer cmdline-tool.
b) offer your tool to others (which usually means it will be
improved etc.pp.)
> I'm not too bothered by the introspection aspect - Greg's concern that it's
> excessively "clever" isn't a problem to me if it's behind the scenes.
it's mostly straight forward. there is only one real problem...
e.g. take this mapping [*]:
def function(
mode=('-m','%s','text'), # output mode can be 'html' or 'text'
*files # list of input files to process
)
it's not difficult to introspect the default values (the argspec)
of the parameters. But it is somewhat tricky
to get the line documentation (#...) after each attribute.
Note, that is easy enough to call 'inspect.getsource(xyz)' to
get the information, BUT the problem is:
intospection generally does not work for objects living in
the __main__ module :-(
There are known workarounds but they are not pretty.
> If you implement this, I promise I'll download it and try it out :-)
i will someday :-) In the meantime i have done a reimplementation
of the rlcompleter (command line completer) which works pretty nice
plus some other stuff...
cheers,
holger
[*] the more i think about it: Maybe it would be more practical
and natural to map the cmdline to a class ...
From a.t.hofkamp@tue.nl Thu May 30 15:28:40 2002
From: a.t.hofkamp@tue.nl (A.T. Hofkamp)
Date: Thu, 30 May 2002 16:28:40 +0200 (CEST)
Subject: [getopt-sig] The bake-off
In-Reply-To: <20020530134904.GE8921@gerg.ca>
Message-ID: <Pine.LNX.4.33.0205301612490.1081-100000@se-46.wpa.wtb.tue.nl>
On Thu, 30 May 2002, Greg Ward wrote:
> > or for something much more complex, like "cvs <command>
> > <command-specific-options>", Optik delivers no support, i.e. in both cases,
> > we are back to scratch "we have sys,argv, what now ?"
>
> Not true. This was discussed in detail back in Feburary; all you have
> to do is create multiple OptionParser objects, and pass each chunk of
> your command-line through them in turn. I even posted (untested,
> hypothetical) code for this.
As you then also remember, I considered your solution a hack.
It does work, but it ain't pretty....
> I don't think this is one of the Nineteen Pythonic Theses, but maybe
> there should be a Twentieth:
>
> Don't let "perfect" be the enemy of "good enough".
>
> Perfection is unattainable by us puny mortals; good enough is, well,
> good enough.
This is a nice example of a fundamental difference in opinion between us :-)
To me, "perfect" is what we aim for, and "good enough" is the result.
> > For people understanding the object-oriented concepts, argtools is the
> > smallest and most flexible (though not flexible enough to handle e.g. cvs
> > like option parsing).
>
> *splutter* but you just criticized Optik for not being able to handle a
> "sub-command" style of interface out-of-the-box!
So do it out of the box, in a non-hacked way please !
(i.e. in one parser instead of having a seperate parser for the various
parts)
> Callbacks are not the standard way of extending Optik; they're just
> there for cases where you don't need to extend the core classes.
> They're not strictly necessary, but they are convenient. I imagine they
> will be especially useful for naive users who are afraid of subclassing.
>
> Extensive, detailed instructions for how to extend Optik -- in the OO
> way, by subclassing Option and/or OptionParser -- are included in the
> source distribution. Several examples of what you can do by subclassing
> Optik are in the examples/ directory.
Yes, I read them (in version 1.2, that is). I found the classes to be quite
non-orthogonal, from an OO point-of-view not easy to use.
That does not mean it is impossible to extend Optik, I just find it not
very user-friendly.
But enough discussion about such issues. It is all in the archives.
The only serious candidate discussed in this SIG is your Optik.
Albert
--
Unlike popular belief, the .doc format is not an open publically available format.
From rsc@plan9.bell-labs.com Thu May 30 15:38:06 2002
From: rsc@plan9.bell-labs.com (rsc@plan9.bell-labs.com)
Date: Thu, 30 May 2002 10:38:06 -0400
Subject: [getopt-sig] The bake-off
Message-ID: <69f355bf0239394549e195d9a6267cfc@plan9.bell-labs.com>
> The only serious candidate discussed in this SIG is your Optik.
This is what settled things for me. Unless
we're going to build a new option parser
from scratch, the only one under consideration
that accomodates what people want is Optik.
People have built big programs with Optik and
reported that they were happy (not just satisfied,
but happy!) with the experience. No one has even
tried to build big complex programs with the
other tools under consideration.
I will probably still use my own trivial iterator-based
parser, but what I expect from my programs (e.g.,
not super-verbose help messages or explanations
of what went wrong on the command line) is not what
everyone else expects or wants. I'm not writing
programs that I expect to give to lots and lots of people.
For inclusion in the standard Python library, it seems
pretty clear that people would be happiest with Optik.
The other big plus in favor of Optik is that Greg clearly
cares to some extent about what users want and has
a history of evolving Optik to make it better.
In contrast, my solution is just exactly right and
couldn't possibly be improved ;-) so I'm not very
interested in working further on it.
My only nit with Optik (and a very small one at that)
is the dual syntax for adding options. I'd rather just
see the normal Python list syntax and drop the
add_option method, but the latter seems entrenched.
(In fact, the reason I was turned off by Optik originally
was I didn't know about the list syntax and thought
the add_option was the only way to go.)
Russ
From gward@python.net Thu May 30 15:46:18 2002
From: gward@python.net (Greg Ward)
Date: Thu, 30 May 2002 10:46:18 -0400
Subject: [getopt-sig] The bake-off
In-Reply-To: <Pine.LNX.4.33.0205301542100.1081-100000@se-46.wpa.wtb.tue.nl>
References: <714DFA46B9BBD0119CD000805FC1F53B01B5B359@UKRUX002.rundc.uk.origin-it.com> <Pine.LNX.4.33.0205301542100.1081-100000@se-46.wpa.wtb.tue.nl>
Message-ID: <20020530144618.GF8921@gerg.ca>
On 30 May 2002, A.T. Hofkamp said:
> I have seen a quite large number of (C++/Java/Python) option parsing
> libraries, and all of them just seem to grab a solution from the air,
> implement it, and present it as the solution (Optik does that too).
Actually, Optik did not spring suddenly out of whole cloth. Ever since
I learned C++ in 1992, and thought I understood OO programming, I
churned out another option-parsing library every couple of years. First
in C++, then I translated that into C when I decided C++ was stupid,
then Perl when I figured out its object model, then three attempts in
Python (one of which snuck into the standard library as
distutils.fancy_getopt).
Amazingly enough, Optik is the first time in all these years that I
think I got it right. I think I finally understand OO programming too,
after nearly four years of experience with Python and two major
projects.
> Yet for some reason, getopt is the most commonly used option parsing library.
>
> Therefore, I concluded, there is something that getopt has, what is missing
> in all the other libraries.
Yes: getopt is in the standard library, and it's documented in the
standard library documentation. You don't have to go out and download
anything. I'm convinced that's the main reason people use it. (It's
also pretty simple to use, if frustrating to scale up.)
Greg
--
Greg Ward - Python bigot gward@python.net
http://starship.python.net/~gward/
Paranoia is simply an optimistic outlook on life.
From gward@python.net Thu May 30 15:49:00 2002
From: gward@python.net (Greg Ward)
Date: Thu, 30 May 2002 10:49:00 -0400
Subject: [getopt-sig] The bake-off
In-Reply-To: <69f355bf0239394549e195d9a6267cfc@plan9.bell-labs.com>
References: <69f355bf0239394549e195d9a6267cfc@plan9.bell-labs.com>
Message-ID: <20020530144900.GG8921@gerg.ca>
On 30 May 2002, rsc@plan9.bell-labs.com said:
> My only nit with Optik (and a very small one at that)
> is the dual syntax for adding options. I'd rather just
> see the normal Python list syntax and drop the
> add_option method, but the latter seems entrenched.
> (In fact, the reason I was turned off by Optik originally
> was I didn't know about the list syntax and thought
> the add_option was the only way to go.)
D'ohh! I originally liked using a list, but I've decided that I prefer
add_option(). I suppose I will leave the list interface there but
undocumented. Anyone else care?
Greg
--
Greg Ward - Linux weenie gward@python.net
http://starship.python.net/~gward/
Reality is for people who can't handle science fiction.
From harri.pasanen@trema.com Thu May 30 16:38:43 2002
From: harri.pasanen@trema.com (Harri Pasanen)
Date: Thu, 30 May 2002 17:38:43 +0200
Subject: [getopt-sig] The bake-off
In-Reply-To: <20020530144900.GG8921@gerg.ca>
References: <69f355bf0239394549e195d9a6267cfc@plan9.bell-labs.com> <20020530144900.GG8921@gerg.ca>
Message-ID: <200205301738.43512.harri.pasanen@trema.com>
On Thursday 30 May 2002 16:49, Greg Ward wrote:
> On 30 May 2002, rsc@plan9.bell-labs.com said:
> > My only nit with Optik (and a very small one at that)
> > is the dual syntax for adding options. I'd rather just
> > see the normal Python list syntax and drop the
> > add_option method, but the latter seems entrenched.
> > (In fact, the reason I was turned off by Optik originally
> > was I didn't know about the list syntax and thought
> > the add_option was the only way to go.)
>
> D'ohh! I originally liked using a list, but I've decided that I prefer
> add_option(). I suppose I will leave the list interface there but
> undocumented. Anyone else care?
>
I'd say leave it in there, documented. =20
My second choice would be strip it out, undocumented features are evil.
-Harri
From rsc@plan9.bell-labs.com Thu May 30 16:40:55 2002
From: rsc@plan9.bell-labs.com (rsc@plan9.bell-labs.com)
Date: Thu, 30 May 2002 11:40:55 -0400
Subject: [getopt-sig] The bake-off
Message-ID: <e851656319bc5afdbe895e8d5a9aa0db@plan9.bell-labs.com>
> D'ohh! I originally liked using a list, but I've decided that I prefer
> add_option(). I suppose I will leave the list interface there but
> undocumented. Anyone else care?
The thing is that Python programmers already know
how to deal with lists. So if you tell them that the options
being parsed are just a list, then they can figure out how
to do
optionlist.append(foo)
for themselves rather than need to learn add_option.
And since the help message uses the same order as the list,
they can figure out how
optionlist.insert(0, foo)
optionlist.extend([foo,bar,baz])
etc. will work.
If you stick to just add_option, you end up either
not having the expressiveness of the list operations
or having your own names for them.
Russ
From gward@python.net Thu May 30 16:43:38 2002
From: gward@python.net (Greg Ward)
Date: Thu, 30 May 2002 11:43:38 -0400
Subject: [getopt-sig] Adding Optik to the standard library
Message-ID: <20020530154338.GA9215@gerg.ca>
I think it's time to declare the work of the getopt-sig finished:
several competing proposals were put forward, but Optik appears to be
the only really complete, documented, field-tested (by someone other
than its author) library. Not everyone on the getopt-sig will agree,
but I think that's the broad consensus. Take this with a grain of salt,
though -- I'm biased. ;-)
Anyways, I think further consensus is needed on how precisely to add
Optik to the standard library. The only constraint I've heard from
Guido is to give it a less-cutesy name, which is fine by me.
First, background: Optik consists of three modules: optik.option,
optik.option_parser, and optik.errors, but that detail is hidden from
users -- Optik applications normally just do this:
from optik import OptionParser
although there are a handful of other names that are occasionally useful
to import from the 'optik' package: Option, SUPPRESS_HELP,
OptionValueError, etc. Optik's __init__.py file is here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/optik/optik/lib/__init__.py?rev=1.11&content-type=text/plain
It's only about 1100 lines, including docs and comments and blanks, so
they could easily be merged into one module if people think that's
preferable.
So the main issues are 1) where those names should be imported from
(interface), and 2) how the standard library should be rearranged to
make this interface unobtrusive and efficient (implementation).
I'm going to toss out ideas at random until I get bored. Please provide
feedback and/or extra ideas on getopt-sig@python.org.
IDEA #1:
interface:
from getopt import OptionParser # and the other Optik names
implementation:
* turn the getopt module into a package
* put the current getopt.py into, say, getopt/classic_getopt.py
* make getopt/__init__.py import everything from classic_getopt.py
and Optik's three modules, so that either interface is there
for the asking
pros:
* dead simple
cons:
* applications using just the classic getopt interface suddenly
find themselves importing lots more code than they used to
IDEA #2:
interface:
from getopt.option_parser import OptionParser, ...
implementation:
* as before, getopt.py becomes getopt/classic_getopt.py
* getopt/__init__.py consists solely of "from classic_getopt import *"
* Optik's three modules are copied into getopt, with the right
imports added to getopt/option_parser.py so that applications
don't have to worry about where Optik's other names come from
pros:
* only slightly more burden on apps now using classic getopt
cons:
* interface is a tad clunkier
IDEA #3:
interface:
from getopt.option_parser import OptionParser, SUPPRESS_HELP, ...
from getopt.option import Option
from getopt.errors import OptionValueError
implementation:
* classic getopt handled the same as #2
* just dump Optik's three modules into getopt/ and be done with it
pros:
* dead simple
cons:
* clunky interface -- imports expose a lot of implementation detail
IDEA #4:
interface:
same as #1
implementation:
* same as #1, except use some funky import-time magic to ensure
that the Optik code is only imported if someone actually needs
it. Barry Warsaw provided a patch to do this:
http://sourceforge.net/tracker/index.php?func=detail&aid=544175&group_id=38019&atid=421099
pros:
* more efficient for apps using classic getopt
cons:
* more complicated; apparently Guido expressed distaste for the
import-time magic. I'm a little leery of it myself, although
I have not carefully read the code.
Preferences? Other ideas? Surely the right solution is out there
somewhere, just beyond my reach...
Greg
--
Greg Ward - Unix geek gward@python.net
http://starship.python.net/~gward/
"Passionate hatred can give meaning and purpose to an empty life."
-- Eric Hoffer
From pobrien@orbtech.com Thu May 30 16:21:34 2002
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Thu, 30 May 2002 10:21:34 -0500
Subject: [getopt-sig] The bake-off
In-Reply-To: <20020530144900.GG8921@gerg.ca>
Message-ID: <NBBBIOJPGKJEKIECEMCBCEGINCAA.pobrien@orbtech.com>
[Greg Ward]
> D'ohh! I originally liked using a list, but I've decided that I prefer
> add_option(). I suppose I will leave the list interface there but
> undocumented. Anyone else care?
I went with add_option() in the application that I used Optik. If it helps
any, I came up with something of an idiom (I think) for the *basic* use of
Optik in an application. I'll post the relevant parts from the application
code below as another example of real world use of Optik.
---
Patrick K. O'Brien
Orbtech
---
#!/usr/bin/env python
class Config:
"""Configuration information for this utility."""
def __init__(self):
"""Create Config instance."""
self.dryrun = 0
self.prefix = 'test_'
self.subdir = 'tests'
self.verbose = 1
self.version = __version__
self.revision = __revision__
self.poundbang = '/usr/bin/env python'
self.author = "Patrick K. O'Brien <pobrien@orbtech.com>"
self.cvsid = '$' + 'Id' + '$' # Broken apart to fool CVS.
self.cvsrev = '$' + 'Revision' + '$' # Ditto.
def _applyOptions(self, options):
"""
Apply overriding options, usually configuration file or
command line options.
"""
for attr, value in vars(options).iteritems():
self._applyOption(attr, value)
def _applyOption(self, attr, value):
"""Apply attribute value."""
if hasattr(self, attr):
if value is not None:
setattr(self, attr, value)
else:
raise AttributeError, 'Config is missing %r' % attr
config = Config()
def parse_args(args=sys.argv[1:]):
"""Parse the command line options."""
from optik import OptionParser
usage = \
'''
usage: %prog [options] file
Create a unit test skeleton module for an existing python code module.
By default, the new file will be created in a "tests" subdirectory.
help: "%prog -h" will display help information for all options.
'''
version = '%prog ' + __version__ + ' (revision %s)' % __revision__
parser = OptionParser(usage=usage, version=version)
parser.add_option('-a', '--author',
type='string',
help='module author')
parser.add_option('-p', '--prefix',
type='string',
default='test_',
help='prefix for new test file, default is "test_"')
parser.add_option('-s', '--subdir',
type='string',
default='tests',
help='subdirectory for new test file, ' + \
'default is "tests"')
parser.add_option('-d', '--dryrun',
action='store_true',
help='do not make any permament changes')
parser.add_option('-v', '--verbose',
action='store_true',
dest='verbose',
help='display progress information')
parser.add_option('-q', '--quiet',
action='store_false',
dest='verbose',
help='suppress progress information')
options, args = parser.parse_args(args)
if len(args) != 1:
parser.error('you must supply the name of a python file')
return (options, args)
def main():
options, args = parse_args()
config._applyOptions(options)
if config.verbose:
print 'Configuration:'
print vars(config)
print 'Command Line Options:'
print vars(options)
print 'Command Line Filespec:'
print args
for filename in args:
process(filename)
def process(filename):
"""Create a unit test skeleton for the python file."""
# [code snipped]
if __name__ == '__main__':
main()
From gward@python.net Thu May 30 16:49:20 2002
From: gward@python.net (Greg Ward)
Date: Thu, 30 May 2002 11:49:20 -0400
Subject: [getopt-sig] The bake-off
In-Reply-To: <e851656319bc5afdbe895e8d5a9aa0db@plan9.bell-labs.com>
References: <e851656319bc5afdbe895e8d5a9aa0db@plan9.bell-labs.com>
Message-ID: <20020530154920.GA9250@gerg.ca>
On 30 May 2002, rsc@plan9.bell-labs.com said:
> The thing is that Python programmers already know
> how to deal with lists. So if you tell them that the options
> being parsed are just a list, then they can figure out how
> to do
> optionlist.append(foo)
> for themselves rather than need to learn add_option.
But add_option() is *not* a synonym for append(). It groks keyword args
nicely:
parser.add_option("-n", type="int", dest="num_things")
to do that with the list interface, you need to explicitly construct an
Option object:
options =
parser = OptionParser(option_list=[
...,
make_option("-n", type="int", dest="num_things"),
...])
(make_option() is an alias for Option in Optik 1.3, since I had vague
ideas about splitting the Option class up into multiple subclasses.)
I now think the latter interface is clunkier. I'm torn about whethere
there should be More Than One Way To Do It. Harri's right though -- if
TIMTOWTODI, then both ways should be documented. Grumble.
Greg
--
Greg Ward - Unix geek gward@python.net
http://starship.python.net/~gward/
If you're not part of the solution, you're part of the precipitate.
From rsc@plan9.bell-labs.com Thu May 30 16:52:32 2002
From: rsc@plan9.bell-labs.com (rsc@plan9.bell-labs.com)
Date: Thu, 30 May 2002 11:52:32 -0400
Subject: [getopt-sig] The bake-off
Message-ID: <57985a1a39cdf7f8b926da800474e200@plan9.bell-labs.com>
i agree that the current list manipulations
are clunky.
i can add options after creating the parser, though,
or so you led me to believe at an earlier point.
if parser behaved like a list, then you could have
parser.append(Option("-n", type="int", dest="num_things"))
which strikes me as not clunky and still general.
From guido@python.org Thu May 30 17:01:03 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 30 May 2002 12:01:03 -0400
Subject: [getopt-sig] The bake-off
In-Reply-To: Your message of "Thu, 30 May 2002 15:36:45 +0200."
<Pine.LNX.4.33.0205301433140.1081-100000@se-46.wpa.wtb.tue.nl>
References: <Pine.LNX.4.33.0205301433140.1081-100000@se-46.wpa.wtb.tue.nl>
Message-ID: <200205301601.g4UG13d24218@odiug.zope.com>
> > As an exercice in how easy each of the three alternatives makes it to
> > change the option set, I'd like to see each version augmented with
> > this feature. There may be no config file yet, so maybe the default
>
> Argtools doe not need to be augmented, it already supports this.
> It it would not this, one would need to write a new derived class for a
> yes/no option, which takes about 5-10 lines of Python.
It seems you have misunderstood me. I wasn't expecting *any* of the
*tools* to require changes. I wanted to measure the changes needed to
the examples of using the tools, i.e.
http://www.python.org/sigs/getopt-sig/ripoff_argtools.py
to implement the change in requirements.
> or for something much more complex, like "cvs <command>
> <command-specific-options>", Optik delivers no support, i.e. in both cases,
> we are back to scratch "we have sys,argv, what now ?"
The way I understand Optik, you can create multiple parser instances:
one for the global options that come before the command name, and one
for each command's specific options. That sounds like a fine
solution to me; I don't think I expect more from an options parser.
> The same happens when you'd want to add something new, like for
> example a config file.
Which is also out of scope for an options parser.
> Greg (the author of Optik) considers support for such situations
> outside the goal of Optik (his goal is 'something better than
> getopt' as I recall).
I agree; that's what I've asked for.
> I think (and a number of other people in this SIG as well), that we
> should aim for something more flexible/modular, to avoid the
> situation that a user of the option parsing library has to start
> from scratch even (especially!!) in the extremely simple and
> extremely complex cases.
May I point out that perfection is often the enemy of "good enough"?
Or maybe I should just say YAGNI (You Ain't Gonna Need It -- Google
for it if this is the first time you see this).
> Argparser of Russ Cox aims for the simple case (which I consider
> very readable, in particular for people not used to objects),
> argtools is a special-purpose library that I wrote in C++, and
> translated to Python. The latter tool is very basic, and extremely
> object-oriented (more than Optik).
>
> Unfortunately, I do not have the time to implement a modular parsing
> library to a level like Optik.
Well, that settles it then. Let's not be distracted by theoretically
optimal solutions when we have something that works now (remember the
Zen of Python).
> As for the proposals done later, I did not understand what was
> happening, and how that proposal relates to other option parsing
> libraries.
>
> > without the help text) and how many lines had to be changed. If the
> > three contestants come out in the same order as in the first contest,
> > that settles the matter for me. If not, we'll have to try to
> > understand why.
>
> The Argtools version will not change in any way, except that a
> different class must be instantiated.
You mean the "--no-xxx" syntax already has standard support? Nice.
[Arguments based on OO-ness snipped]
--Guido van Rossum (home page: http://www.python.org/~guido/)
From guido@python.org Thu May 30 17:02:17 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 30 May 2002 12:02:17 -0400
Subject: [getopt-sig] The bake-off
In-Reply-To: Your message of "Thu, 30 May 2002 14:39:29 BST."
<714DFA46B9BBD0119CD000805FC1F53B01B5B35B@UKRUX002.rundc.uk.origin-it.com>
References: <714DFA46B9BBD0119CD000805FC1F53B01B5B35B@UKRUX002.rundc.uk.origin-it.com>
Message-ID: <200205301602.g4UG2HX24229@odiug.zope.com>
> I'm not too bothered by the introspection aspect - Greg's concern that it's
> excessively "clever" isn't a problem to me if it's behind the scenes.
It is to me though. This seems a wrong use of introspection to me.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From david@sleepydog.net Thu May 30 17:15:10 2002
From: david@sleepydog.net (David Boddie)
Date: Thu, 30 May 2002 17:15:10 +0100
Subject: [getopt-sig] Bake-on!
Message-ID: <200205301715.11486.david@sleepydog.net>
I've just modified my entry to the bake-off
http://www.python.org/sigs/getopt-sig/compare.html
to take into account a couple of missing features in the previous version
which I don't think I ever published on this list.
You can see an minimally annotated version of my version of the
ripoff command line interface on this page:
http://david.boddie.org.uk/Projects/Python/CMDSyntax/Bake-off/
I'm not necessarily proposing my library as a complete alternative
to Optik (path of least resistance and all that) but, having
produced a working solution, I may as well throw my hat into the
ring...
David
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________
From pobrien@orbtech.com Thu May 30 17:09:44 2002
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Thu, 30 May 2002 11:09:44 -0500
Subject: [getopt-sig] Adding Optik to the standard library
In-Reply-To: <20020530154338.GA9215@gerg.ca>
Message-ID: <NBBBIOJPGKJEKIECEMCBAEGMNCAA.pobrien@orbtech.com>
[Greg Ward]
>
> Anyways, I think further consensus is needed on how precisely to add
> Optik to the standard library. The only constraint I've heard from
> Guido is to give it a less-cutesy name, which is fine by me.
Any chance we could wean you off your preference for underscores? <wink>
---
Patrick K. O'Brien
Orbtech
From guido@python.org Thu May 30 17:27:38 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 30 May 2002 12:27:38 -0400
Subject: [getopt-sig] Adding Optik to the standard library
In-Reply-To: Your message of "Thu, 30 May 2002 11:43:38 EDT."
<20020530154338.GA9215@gerg.ca>
References: <20020530154338.GA9215@gerg.ca>
Message-ID: <200205301627.g4UGRcQ24434@odiug.zope.com>
I think it's better to pick a new name and leave the existing getopt
module alone.
I think keeping it a package is fine. I prefer to have little or no
magic in __init__.py though (the email package's __init__.py is
borderline :-).
I think that "options" is a fine package name. Yes, there are other
things that one could consider options. No, I don't think that will
cause confusion. After all "getopt" isn't much more specific. :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)
From s_lott@yahoo.com Thu May 30 18:08:37 2002
From: s_lott@yahoo.com (Steven Lott)
Date: Thu, 30 May 2002 10:08:37 -0700 (PDT)
Subject: [getopt-sig] Optik
Message-ID: <20020530170837.8763.qmail@web9606.mail.yahoo.com>
What's wrong with getopt2?
=====
--
S. Lott, CCP :-{)
S_LOTT@YAHOO.COM
http://www.mindspring.com/~slott1
Buccaneer #468: KaDiMa
Macintosh user: drinking upstream from the herd.
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
From pobrien@orbtech.com Thu May 30 18:35:56 2002
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Thu, 30 May 2002 12:35:56 -0500
Subject: [getopt-sig] Adding Optik to the standard library
In-Reply-To: <20020530154338.GA9215@gerg.ca>
Message-ID: <NBBBIOJPGKJEKIECEMCBKEHANCAA.pobrien@orbtech.com>
[Greg Ward]
> Preferences? Other ideas? Surely the right solution is out there
> somewhere, just beyond my reach...
Why does this need to be tied into getopt?
My vote would be for one module named options.py.
---
Patrick K. O'Brien
Orbtech
From guido@python.org Thu May 30 18:34:41 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 30 May 2002 13:34:41 -0400
Subject: [getopt-sig] Adding Optik to the standard library
In-Reply-To: Your message of "Thu, 30 May 2002 12:35:56 CDT."
<NBBBIOJPGKJEKIECEMCBKEHANCAA.pobrien@orbtech.com>
References: <NBBBIOJPGKJEKIECEMCBKEHANCAA.pobrien@orbtech.com>
Message-ID: <200205301734.g4UHYff26100@odiug.zope.com>
> My vote would be for one module named options.py.
That works for me too.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From gward@python.net Thu May 30 20:19:33 2002
From: gward@python.net (Greg Ward)
Date: Thu, 30 May 2002 15:19:33 -0400
Subject: [getopt-sig] The bake-off
In-Reply-To: <57985a1a39cdf7f8b926da800474e200@plan9.bell-labs.com>
References: <57985a1a39cdf7f8b926da800474e200@plan9.bell-labs.com>
Message-ID: <20020530191933.GA10113@gerg.ca>
On 30 May 2002, rsc@plan9.bell-labs.com said:
> if parser behaved like a list, then you could have
>
> parser.append(Option("-n", type="int", dest="num_things"))
>
> which strikes me as not clunky and still general.
If you want OptionParser to implement the sequence interface, submit a
patch. I'm +0 on the idea, so I'd probably accept a well-written patch,
but I'm unlikely to bother implementing it myself.
Greg
--
Greg Ward - Python bigot gward@python.net
http://starship.python.net/~gward/
Know thyself. If you need help, call the CIA.
From gward@python.net Thu May 30 20:22:56 2002
From: gward@python.net (Greg Ward)
Date: Thu, 30 May 2002 15:22:56 -0400
Subject: [getopt-sig] Adding Optik to the standard library
In-Reply-To: <NBBBIOJPGKJEKIECEMCBAEGMNCAA.pobrien@orbtech.com>
References: <20020530154338.GA9215@gerg.ca> <NBBBIOJPGKJEKIECEMCBAEGMNCAA.pobrien@orbtech.com>
Message-ID: <20020530192256.GB10113@gerg.ca>
On 30 May 2002, Patrick K. O'Brien said:
> Any chance we could wean you off your preference for underscores? <wink>
Underscores where? I dislike StudlyCaps except for class names; I
dislike camelCase even more. (NB. it's called "camel case" because of
the hump, not because of any association with a certain popular
scripting language with a fondness for bactrians.)
I think method and function names should always be lower_case. Probably
stems from too much time on Unix and a strong distaste for C++, Java,
Microsoft APIs, and all that newfangled stuff. Plus, Tom Christiansen
(he of Perl fame) once argued that lower_case identifiers are easier for
non-native English speakers to read than StudlyCaps or camelCase, which
sounds like a good excuse to me.
Greg
--
Greg Ward - programmer-at-large gward@python.net
http://starship.python.net/~gward/
I hope something GOOD came in the mail today so I have a REASON to live!!
From gward@python.net Thu May 30 20:36:44 2002
From: gward@python.net (Greg Ward)
Date: Thu, 30 May 2002 15:36:44 -0400
Subject: [Python-Dev] Re: [getopt-sig] Adding Optik to the standard library
In-Reply-To: <200205301841.g4UIfwl26822@odiug.zope.com>
References: <20020530154338.GA9215@gerg.ca> <200205301627.g4UGRcQ24434@odiug.zope.com> <15606.29007.98422.889643@rosa.monkeyfist.com> <200205301841.g4UIfwl26822@odiug.zope.com>
Message-ID: <20020530193644.GA10197@gerg.ca>
On 30 May 2002, Guido van Rossum said:
> > How about "OptParser" (alternatives: OptionsParser, OptsParser) as
> > an analogue to the existing ConfigParser? They do go together, both
> > conceptually and in practice, after all.
>
> A decent guideline is to use the dominant class name as the module
> name. That would be OptionParser. Then, instead of
>
> from optik import OptionParser
>
> we'd be writing
>
> from OptionParser import OptionParser
>
> I like this!
I think the BDFL has spoken. I can live with this, although I prefer
lower-case module names. Whatever.
Greg
--
Greg Ward - geek-at-large gward@python.net
http://starship.python.net/~gward/
Paranoia is simply an optimistic outlook on life.
From guido@python.org Thu May 30 20:46:21 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 30 May 2002 15:46:21 -0400
Subject: [Python-Dev] Re: [getopt-sig] Adding Optik to the standard library
In-Reply-To: Your message of "Thu, 30 May 2002 15:36:44 EDT."
<20020530193644.GA10197@gerg.ca>
References: <20020530154338.GA9215@gerg.ca> <200205301627.g4UGRcQ24434@odiug.zope.com> <15606.29007.98422.889643@rosa.monkeyfist.com> <200205301841.g4UIfwl26822@odiug.zope.com>
<20020530193644.GA10197@gerg.ca>
Message-ID: <200205301946.g4UJkLL26987@odiug.zope.com>
> > from OptionParser import OptionParser
> >
> > I like this!
>
> I think the BDFL has spoken. I can live with this, although I prefer
> lower-case module names. Whatever.
I prefer lower-case module names for most situations, but I make an
exception for modulename == classname.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From pobrien@orbtech.com Thu May 30 21:08:10 2002
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Thu, 30 May 2002 15:08:10 -0500
Subject: [getopt-sig] Adding Optik to the standard library
In-Reply-To: <20020530192256.GB10113@gerg.ca>
Message-ID: <NBBBIOJPGKJEKIECEMCBEEHHNCAA.pobrien@orbtech.com>
[Greg Ward]
> On 30 May 2002, Patrick K. O'Brien said:
> > Any chance we could wean you off your preference for underscores? <wink>
>
> Underscores where?
I really only meant that as a friendly jab. Your code just seems to have
more underscores than other python code I work with. And while you are
consistent in your use of underscores and such, the same can't be said about
Python library as a whole, other than the fact that it seems to not have too
many underscores.
But that's a battle I didn't intend to fight, especially since I'm not sure
which side I'd be on. Some days I like camelCaps (maybe because I'm working
with wxPython that day) and other days I prefer underscores (maybe because
I'm working with Quixote or Optik). So even my own code is not completely
consistent as I will sometimes vary my style depending on what other modules
I'm using.
But I have to admit there are days when I wished a naming standard was
enforced so I wouldn't have to think about it.
---
Patrick K. O'Brien
Orbtech
From barry@zope.com Thu May 30 21:45:12 2002
From: barry@zope.com (Barry A. Warsaw)
Date: Thu, 30 May 2002 16:45:12 -0400
Subject: [Python-Dev] Re: [getopt-sig] Adding Optik to the standard library
References: <20020530154338.GA9215@gerg.ca>
<200205301627.g4UGRcQ24434@odiug.zope.com>
<15606.29007.98422.889643@rosa.monkeyfist.com>
<200205301841.g4UIfwl26822@odiug.zope.com>
<20020530193644.GA10197@gerg.ca>
<200205301946.g4UJkLL26987@odiug.zope.com>
Message-ID: <15606.36696.222173.725350@anthem.wooz.org>
>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:
GvR> I prefer lower-case module names for most situations, but I
GvR> make an exception for modulename == classname.
Agreed! That's what the style guide says too. :)
-Barry
From holger@trillke.net Thu May 30 22:18:01 2002
From: holger@trillke.net (holger@trillke.net)
Date: Thu, 30 May 2002 23:18:01 +0200
Subject: [getopt-sig] Bake-on!
In-Reply-To: <200205301715.11486.david@sleepydog.net>
References: <200205301715.11486.david@sleepydog.net>
Message-ID: <20020530211801.GI2845@devel.trillke>
[David Boddie Thu, May 30, 2002 at 05:15:10PM +0100]
> I've just modified my entry to the bake-off
>
> http://www.python.org/sigs/getopt-sig/compare.html
>
> to take into account a couple of missing features in the previous version
> which I don't think I ever published on this list.
>
> You can see an minimally annotated version of my version of the
> ripoff command line interface on this page:
>
> http://david.boddie.org.uk/Projects/Python/CMDSyntax/Bake-off/
>
> I'm not necessarily proposing my library as a complete alternative
> to Optik (path of least resistance and all that) but, having
> produced a working solution, I may as well throw my hat into the
> ring...
I still like the clarity of your code and recommend anyone to
have a look at the given link.
But if i interprete the signs on python-dev and on getopt-sig
correctly there is no way to reopen this debate.
best wishes,
holger
From goodger@users.sourceforge.net Thu May 30 23:30:51 2002
From: goodger@users.sourceforge.net (David Goodger)
Date: Thu, 30 May 2002 18:30:51 -0400
Subject: [getopt-sig] Re: Adding Optik to the standard library
In-Reply-To: <200205301946.g4UJkLL26987@odiug.zope.com>
Message-ID: <B91C205B.23BE1%goodger@users.sourceforge.net>
[Guido]
>>> from OptionParser import OptionParser
>>>
>>> I like this!
[Greg]
>> I think the BDFL has spoken. I can live with this, although I prefer
>> lower-case module names. Whatever.
[Guido]
> I prefer lower-case module names for most situations, but I make an
> exception for modulename == classname.
But there's more than just the one class (OptionParser) in the module, and
the other classes (Option, Values) *are* used. Barry's rule may hold for 1
class per module; that's not the case here.
+1 for "options"
-1 for "OptionParser"
--
David Goodger <goodger@users.sourceforge.net> Open-source projects:
- Python Docutils: http://docutils.sourceforge.net/
(includes reStructuredText: http://docutils.sf.net/rst.html)
- The Go Tools Project: http://gotools.sourceforge.net/
From barry@zope.com Fri May 31 02:02:21 2002
From: barry@zope.com (Barry A. Warsaw)
Date: Thu, 30 May 2002 21:02:21 -0400
Subject: [getopt-sig] Re: [Python-Dev] Re: Adding Optik to the standard library
References: <200205301946.g4UJkLL26987@odiug.zope.com>
<B91C205B.23BE1%goodger@users.sourceforge.net>
Message-ID: <15606.52125.709788.262269@anthem.wooz.org>
>>>>> "DG" == David Goodger <goodger@users.sourceforge.net> writes:
DG> But there's more than just the one class (OptionParser) in the
DG> module, and the other classes (Option, Values) *are* used.
DG> Barry's rule may hold for 1 class per module; that's not the
DG> case here.
If that's so, then I'd prefer to see each class in its own module
inside a parent package.
| +1 for "options"
| -1 for "OptionParser"
I still think getopt-as-package could be made to work, but I'd be fine
with `options'. Whatever though; Guido's weighed in and Greg should
just decide and go for it!
-Barry
From goodger@users.sourceforge.net Fri May 31 02:11:06 2002
From: goodger@users.sourceforge.net (David Goodger)
Date: Thu, 30 May 2002 21:11:06 -0400
Subject: [getopt-sig] Re: [Python-Dev] Re: Adding Optik to the standard library
In-Reply-To: <15606.52125.709788.262269@anthem.wooz.org>
Message-ID: <B91C45E9.23D2E%goodger@users.sourceforge.net>
Barry A. Warsaw wrote:
> If that's so, then I'd prefer to see each class in its own module
> inside a parent package.
We all know *your* bias! ;-)
From goodger@users.sourceforge.net Fri May 31 02:14:32 2002
From: goodger@users.sourceforge.net (David Goodger)
Date: Thu, 30 May 2002 21:14:32 -0400
Subject: [getopt-sig] Suggestions for Optik
Message-ID: <B91C46B8.23D31%goodger@users.sourceforge.net>
(Perhaps this should be on optik-users, but this is where all the
action is -- and all the eyes are -- these days.)
I'm glad to see Optik moving forward into the standard library. I've
just finished a first cut at applying Optik to the Docutils project
(http://docutils.sf.net/), and have some suggestions. I don't mean
for this to impede Optik's stdlib adoption; the issues are not central
to its workings, and the timing is purely coincidental. However, if
there are to be changes, earlier is better.
Here's a simplified description. Docutils is a modular system, with
"Reader" components for input and "Writer" components for output. A
front end will combine an arbitrary Reader and Writer together. The
core system has a set of command-line options, and each component may
have its own set. I've implemented an option specification data
structure, a list of ``('help text', [list of option strings], {dict
of keyword arguments})`` 3-tuples, which populate an Optik
OptionParser subclass. The ``optik.option_parser.Values`` object
produced is used in both command-line script context (via a front-end)
and imported module context. For details, see:
- http://docutils.sf.net/tools/html.py (a working front-end script)
- http://docutils.sf.net/docutils/frontend.py
- http://docutils.sf.net/docutils/core.py
- http://docutils.sf.net/docutils/writers/html4css1.py
Here are my suggestions. I am willing and able to do the
implementation work, alone or with others. Would anybody like to
help? Feedback is welcome.
- Overhaul the help message code. As has been mentioned on getopt-sig
and/or optik-users before, the help message generating code ought to
be extracted into a class of its own (call it "HelpMessenger" for
now).
- Make the parts of help messages (usage model, formatted list of
options, etc. [see below]) individually accessible. That would
make Optik more flexible for auto-documentation and for extending
the HelpMessenger class.
- As with "options:", the "usage:" header should be supplied by
Optik, even when a custom usage string is supplied. In other
words, an Optik client should supply::
usage="%prog [options] [arg1 [arg2] ...]"
Currently, you have to supply::
usage="usage: %prog [options] [arg1 [arg2] ...]"
It may seem a small point, but it makes the help system more
consistent. It's important when combined with the following
ideas.
- Allow more structure and flexibility in help messages. I'd like
to be able to generate help messages more like what you get from
"grep --help" and other GNU tools.
- Add titles for groups of options (which would require "option
group" objects), and interspersed free explanatory text. Option
group titles should be short (a few words only, less than a line
long, so they don't wrap). This directly relates to Docutils'
modular nature: one option group per component.
- Add introductory descriptive text, examples, and closing
statements as well.
For example::
"myscript" does XYZ to ABC <- intro
in a very cool way.
Usage:
myscript [options] [arg] <- usage template
If "arg" is not supplied, STDIN <- usage elaboration
is assumed. (free text)
Example(s):
myscript -v file1 file2 <- example (literal)
Options:
General options: <- option group title
-h, --help ... <- option group
-v, --verbose ...
General options are available <- free text
for all formats.
HTML-specific options:
--stylesheet=file ...
...
Please report bugs to <- closing statements
<bugs@example.org>.
- Text in intro, examples, and closing, and text between option
groups can be paragraphs (free-wrapping) or literal blocks
(<pre>; linebreaks are significant and won't wrap).
- Option groups could be nestable, but limited to one level may be
better. Perhaps either all option groups, or all single
options, but not mixed?
- Options are flattened internally into OptionParser's _short_opt
& _long_opt dictionaries for lookup.
OptionParser could grow new methods: add_intro_text(),
add_example_text(), add_option_group(), add_option_text(),
add_closing_text(). Corresponding classes might also need to be
added: OptionGroup, etc.
- Rework the structure of help messages to make them more
reStructuredText-friendly? It would be ideal if the help text
produced by the standard Python option processor was parseable by
the standard Python documentation utilities (positive thinking).
Perhaps no changes are required, if the help message parts are
made individually accessible. The format as it is now, is valid
reStructuredText.
- Put long options first? Short options are like a shortcut for
long options. Long options are more verbose and better identify
the option; they're more of a "title". I know that GNU tools
always do "short, long", but they seem to be hand-crafted anyway.
Some prior discussion on getopt-sig: "Documentation, functionality,
options, syncing" thread began 2002-02-20:
http://mail.python.org/pipermail/getopt-sig/2002-February/000064.html
- Standardize a Python API for extracting command-line help from
script modules? An auto-documentation program could import a script
as a module, and extract the script's usage for inclusion in the
generated documentation. Or perhaps this is too complicated, and
it'd be better and easier to simply call the script with "--help"
and use *that*.
- Add something like a ``get_default_values`` method to OptionParser::
def get_default_values(self):
return Values(self.defaults)
This is very useful when code can be used both as a command-line
script and an importable module. See the OptionParser subclass in
http://docutils.sf.net/docutils/frontend.py; the "__init__" method
accepts a dict of default overrides which affects the Values object
returned. This is used in import (as opposed to command-line)
context.
--
David Goodger <goodger@users.sourceforge.net> Open-source projects:
- Python Docutils: http://docutils.sourceforge.net/
(includes reStructuredText: http://docutils.sf.net/rst.html)
- The Go Tools Project: http://gotools.sourceforge.net/
From barry@zope.com Fri May 31 02:25:47 2002
From: barry@zope.com (Barry A. Warsaw)
Date: Thu, 30 May 2002 21:25:47 -0400
Subject: [getopt-sig] Re: [Python-Dev] Re: Adding Optik to the standard library
References: <15606.52125.709788.262269@anthem.wooz.org>
<B91C45E9.23D2E%goodger@users.sourceforge.net>
Message-ID: <15606.53531.845239.494430@anthem.wooz.org>
From guido@python.org Fri May 31 02:32:01 2002
From: guido@python.org (Guido van Rossum)
Date: Thu, 30 May 2002 21:32:01 -0400
Subject: [getopt-sig] Re: [Python-Dev] Re: Adding Optik to the standard library
In-Reply-To: Your message of "Thu, 30 May 2002 21:02:21 EDT."
<15606.52125.709788.262269@anthem.wooz.org>
References: <200205301946.g4UJkLL26987@odiug.zope.com> <B91C205B.23BE1%goodger@users.sourceforge.net>
<15606.52125.709788.262269@anthem.wooz.org>
Message-ID: <200205310132.g4V1W1U08610@pcp742651pcs.reston01.va.comcast.net>
> | +1 for "options"
> | -1 for "OptionParser"
>
> I still think getopt-as-package could be made to work, but I'd be fine
> with `options'. Whatever though; Guido's weighed in and Greg should
> just decide and go for it!
getopt-as-package is definitely out. I'll leave it to Greg what to
make of the remaining two alternatives (options or OptionParser).
--Guido van Rossum (home page: http://www.python.org/~guido/)
From barry@zope.com Fri May 31 02:28:07 2002
From: barry@zope.com (Barry A. Warsaw)
Date: Thu, 30 May 2002 21:28:07 -0400
Subject: [getopt-sig] Re: [Python-Dev] Re: Adding Optik to the standard library
References: <15606.52125.709788.262269@anthem.wooz.org>
<B91C45E9.23D2E%goodger@users.sourceforge.net>
Message-ID: <15606.53671.50475.599022@anthem.wooz.org>
>>>>> "DG" == David Goodger <goodger@users.sourceforge.net> writes:
DG> We all know *your* bias! ;-)
You've sat next to me at a Python conference then? My biological
interference with acoustic systems is soooo embarrassing.
http://www.acronymfinder.com/af-query.asp?p=dict&String=exact&Acronym=BIAS
-Barry
From pobrien@orbtech.com Fri May 31 04:10:46 2002
From: pobrien@orbtech.com (Patrick K. O'Brien)
Date: Thu, 30 May 2002 22:10:46 -0500
Subject: [getopt-sig] RE: [Python-Dev] Re: Adding Optik to the standard library
In-Reply-To: <15606.52125.709788.262269@anthem.wooz.org>
Message-ID: <NBBBIOJPGKJEKIECEMCBCEIGNCAA.pobrien@orbtech.com>
[Barry A. Warsaw]
> If that's so, then I'd prefer to see each class in its own module
> inside a parent package.
Without trying to open a can of worms here, is there any sort of consensus
on the use of packages with multiple smaller modules vs. one module
containing everything? I'm asking about the Python standard library,
specifically. According to the one-class-per-module rule of thumb, there are
some Python modules that could be refactored into packages. Weighing against
that is the convenience of importing a single module.
I'm just wondering if there are any guidelines that should frame one's
thinking beyond the fairly obvious ones? For example, is the standard
library an exceptional case because it must appeal to new users as well as
experts? Does a good part of this issue come down to personal preference? Or
are there advantages and disadvantages that should be documented? (Maybe
they already have.)
Is the current library configuration considered healthy? There are a mix of
packages and single modules. Are these implementations pretty optimal, or
would they be organized differently if one had the chance to do it all over
again?
Just curious.
---
Patrick K. O'Brien
Orbtech
From gward@python.net Fri May 31 15:39:56 2002
From: gward@python.net (Greg Ward)
Date: Fri, 31 May 2002 10:39:56 -0400
Subject: [getopt-sig] Re: [Python-Dev] Re: Adding Optik to the standard library
In-Reply-To: <200205310132.g4V1W1U08610@pcp742651pcs.reston01.va.comcast.net>
References: <200205301946.g4UJkLL26987@odiug.zope.com> <B91C205B.23BE1%goodger@users.sourceforge.net> <15606.52125.709788.262269@anthem.wooz.org> <200205310132.g4V1W1U08610@pcp742651pcs.reston01.va.comcast.net>
Message-ID: <20020531143956.GA15236@gerg.ca>
On 30 May 2002, Guido van Rossum said:
> getopt-as-package is definitely out. I'll leave it to Greg what to
> make of the remaining two alternatives (options or OptionParser).
I strongly prefer OptionParser, because that's the main class; it's the
one that's always used (ie. directly instantiated). There are always
instances of Option, OptionValues, and the various exception classes
floating around -- but most Optik applications don't have to import
those names directly.
So in spite of David G.'s -1 on OptionParser, that's what I'm going
with...
Greg
--
Greg Ward - Python bigot gward@python.net
http://starship.python.net/~gward/
From guido@python.org Fri May 31 15:47:19 2002
From: guido@python.org (Guido van Rossum)
Date: Fri, 31 May 2002 10:47:19 -0400
Subject: [getopt-sig] Re: [Python-Dev] Re: Adding Optik to the standard library
In-Reply-To: Your message of "Fri, 31 May 2002 10:39:56 EDT."
<20020531143956.GA15236@gerg.ca>
References: <200205301946.g4UJkLL26987@odiug.zope.com> <B91C205B.23BE1%goodger@users.sourceforge.net> <15606.52125.709788.262269@anthem.wooz.org> <200205310132.g4V1W1U08610@pcp742651pcs.reston01.va.comcast.net>
<20020531143956.GA15236@gerg.ca>
Message-ID: <200205311447.g4VElJZ24638@pcp742651pcs.reston01.va.comcast.net>
> I strongly prefer OptionParser, because that's the main class; it's the
> one that's always used (ie. directly instantiated). There are always
> instances of Option, OptionValues, and the various exception classes
> floating around -- but most Optik applications don't have to import
> those names directly.
>
> So in spite of David G.'s -1 on OptionParser, that's what I'm going
> with...
Great!
--Guido van Rossum (home page: http://www.python.org/~guido/)
From gward@python.net Fri May 31 17:58:06 2002
From: gward@python.net (Greg Ward)
Date: Fri, 31 May 2002 12:58:06 -0400
Subject: [getopt-sig] Suggestions for Optik
In-Reply-To: <B91C46B8.23D31%goodger@users.sourceforge.net>
References: <B91C46B8.23D31%goodger@users.sourceforge.net>
Message-ID: <20020531165806.GA15832@gerg.ca>
On 30 May 2002, David Goodger said:
> (Perhaps this should be on optik-users, but this is where all the
> action is -- and all the eyes are -- these days.)
I think it should be on optik-users. Can you repost it there to start
the thread afresh for those on optik-users but not on getopt-sig? I'll
wait to respond until I get it via optik-users.
Greg
--
Greg Ward - Unix bigot gward@python.net
http://starship.python.net/~gward/
Predestination was doomed from the start.