Message143913
Copied from msg143857:
> There are a lot of little internal routines in the standard library
> that aren't sufficiently fit to be exposed (perhaps a little too
> ad-hoc or special purpose, perhaps the API isn't sufficiently
> general, perhaps the routines rely on non-guaranteed aspects of the
> implementation). For example, visiblename() is more heuristic than
> algorithmic -- right now, we can change that as needed (for instance,
> the recent updates to accommodate named tuples), but as soon as the
> method or function becomes public, its API freezes and it is hard for
> us to make changes.
I agree with your general point. For this particular case, I’d be okay if you wanted to reject the request. Users can filter the output of dir depending on their needs (_private names, __magic__ names, etc.). For more useful code (that can cope with named tuples for example), I think generic functions would be a nice way to do this. |
|
Date |
User |
Action |
Args |
2011-09-12 16:00:30 | eric.araujo | set | recipients:
+ eric.araujo, rhettinger |
2011-09-12 16:00:30 | eric.araujo | set | messageid: <1315843230.01.0.618575184856.issue12917@psf.upfronthosting.co.za> |
2011-09-12 16:00:29 | eric.araujo | link | issue12917 messages |
2011-09-12 16:00:29 | eric.araujo | create | |
|