> On Apr 5, 2020, at 20:12, Stephen J. Turnbull > <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > > Andrew Barnert via Python-ideas writes: > >> However, I think that a macaddress library could easily be one of >> the few things that does properly fit in the networking section of >> the stdlib. It’s a small feature, and it should be very stable—I >> think the last change to the protocol spec was about 20 years ago, >> and from a brief scan of the release notes for netaddr it looks >> like for the last decade its needed less than one bugfix or feature >> per year for dealing with MAC/EUI addresses… > > I wonder if it should go in a package of its own, or if we should > expand ipaddress to netaddress and have all the features at the same > level, or if we should have ipaddress.macaddress (the semantics there > are a bit wonky, but "ipaddress" is now canonical for the ipaddress > features).
If I were a sysadmin who didn’t know Python well, I’m pretty sure I wouldn’t go looking in a module named ipaddress for functions and classes to deal with MAC addresses. But on the other hand, if I went on StackOverflow or ServerFault and learned that’s where they were. I don’t think I’d complain. So… maybe we need a survey of what other libraries across languages do to guide us in the naming? The other big question is whether to use the “correct” names, so an eui_address function gives you an EUI48Address (or EUI64Address as appropriate), or the names real sysadmins will expect (unless they’re dealing with Bluetooth or FireWire or something instead of Ethernet or WiFi), so you just call mac_address and get a MACAddress. > From the Old Farts Must Reminisce Department: > >> But if the stdlib were designed from scratch today rather than over >> the past 30 years, I think it would have less than it does, not >> more. Up to around a decade ago, installing third-party libraries >> was a huge mess, but nowadays, PyPI works, Python comes with pip >> pre-installed, and telling developers they need internet access >> when they first start a new project isn’t considered onerous. > > That's OK for developers on their "own" machines, but I think there > are still a lot of folks who need approval from corporate Sure, but in this particular case, the people writing maintenance scripts that need to deal with MAC addresses are probably the IT department. They get to make the policy and/or administer the intranet PyPI repo, and somehow that always seems to make things easier for them than for the engineering department. :) > But for those not constrained by corporate policy, even if they don't > have good network access consistently, installing everything you think > you might ever need from PyPI on the infrequent occasions you do have > such access is only a small fraction of modern disks. Suboptimal, of > course, but there was a time I typed the bootstrap assembly code for a > C compiler from a book, and then did the optimized full-featured > self-hosting version the same way. Not saying "you kidz these dayz > don't know how good you have it", rather "where there's a will there's > a way." $python -m pip + PyPI makes TOOWTDI for packages quite > painless! A few months ago, I was on a plane, less than an hour away from landing and being online, and I wanted to pip install something into Pythonista on my iPad and the wait drove me crazy. And then I remembered an article in Cider with 6502 code for playing polyphonic (well, duophonic) audio and getting to the last page and seeing “code continues next issue” and having to wait a month to get the rest of it, and suddenly 40 minutes didn’t seem… well, no, it was still annoying as hell, I was just amazed at how patient that younger me must have been. 300 baud modems, overnight compiles, having to go to the library on the weekend to look up something simple instead of just checking on your phone… But we were happy in them days, though we had no bandwidth. You try and tell t’young people today. And they won’t believe ye. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ENCPKEIQ6GPIDBX5QG7X4RBET744WLCT/ Code of Conduct: http://python.org/psf/codeofconduct/
