On Jul 3, 2017, at 9:49 AM, steve donovan <steve.j.donovan@gmail.com> wrote: > > On Sat, Jul 1, 2017 at 9:17 PM, Jay Carlson <nop@nop.com> wrote: >> If only Lua had a (reasonable) subset of the Python libraries. > > Heh, that was precisely the start of the Penlight project - nostalgia > for the Python libraries. But I lost interest in staying faithful to > that mission, recognizing the differences between the languages, and > wanting to work with the strengths of Lua. Yeah. What I’m not missing is tools for dealing with arrays so much as, well, let’s just start down the list: asyncore,, cmd, codecs (subsetted), fnctl, http.client, http.cookiejar, http.server, imaplib, BytesIO, os, os.path, pathlib, pty, queue, re, readline/rlcompleter (did that one), secrets, shutil, socket/socketserver, sqlite3, ssl, subprocess, termios, timeit, uuid, winreg, zlib Things you could do in pure Lua, but probably shouldn’t: base64, email.encoders, hashlib, hmac, json, xml (btdt). Things you should do in pure Lua: argparse, configparser, datetime (please please), email, some subset of logging, mailbox, pdb, plistlib, shlex, struct, tarfile/zipfile, Yes, I can do much of this already for my platforms (pick a posix library). Perhaps the Lua way would be to define the OS mechanisms in a very raw form, and then let people squabble over the API. > I don't doubt that it is doable, but it sounds like a lot of work that > could be futile - because why should Lua try to be a better Python? I still get a lot of mileage out of Microlight. So let’s not do that again. :-) Jay
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail