lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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