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: 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

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-- 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: 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: 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: > 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 ) 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: 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 ", 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 ) > 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 ) 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: References: <200205300342.g4U3g8x06741@pcp742651pcs.reston01.va.comcast.net> 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 > ", 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: 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 ) 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. 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: On Thu, 30 May 2002, Greg Ward wrote: > > or for something much more complex, like "cvs > > ", 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: References: <714DFA46B9BBD0119CD000805FC1F53B01B5B359@UKRUX002.rundc.uk.origin-it.com> 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: > 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: [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 " 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: References: 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." References: 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 > ", 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: [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? --- 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: [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." References: 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: References: <20020530154338.GA9215@gerg.ca> 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? 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: [Greg Ward] > On 30 May 2002, Patrick K. O'Brien said: > > Any chance we could wean you off your preference for underscores? > > 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 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: [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 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> Message-ID: <15606.52125.709788.262269@anthem.wooz.org> >>>>> "DG" == David Goodger 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: 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: (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 . - Text in intro, examples, and closing, and text between option groups can be paragraphs (free-wrapping) or literal blocks (
; 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    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>
 
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> 
 <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>
 
Message-ID: <15606.53671.50475.599022@anthem.wooz.org>

>>>>> "DG" == David Goodger  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: 

[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>  <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>  <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: 
References: 
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.