[issue16213] Expose private functions in marshal used by importlib

Brett Cannon added the comment: I've decided against this as issues #15031 and #16494 will alleviate the need to expose these functions. -- dependencies: -Split .pyc parsing from module loading resolution: -> rejected status: open -> closed ___ Pyt

[issue16213] Expose private functions in marshal used by importlib

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue16213] Expose private functions in marshal used by importlib

Martin v. Löwis added the comment: > AFAIR, the problem is that you first need to import the locale > module (and its dependencies) before you can decide what the > filesystem encoding is. I don't think this is true. The file system encoding works fine all along, and also doesn't have to do

[issue16213] Expose private functions in marshal used by importlib

Antoine Pitrou added the comment: > As for fix_co_filename, I think it would indeed be useful if > marshal.load(s) supported an optional filename= parameter, which then > fills rf.current_filename. AFAIR, the problem is that you first need to import the locale module (and its dependencies) befo

[issue16213] Expose private functions in marshal used by importlib

Terry J. Reedy added the comment: marshal currently has a simple, coherent, high-level interface: dump and load serializations. _fix_co_filename sounds a bit hackish and ad hoc. Martin's suggestion looks to me like a better way to publicly expose filename setting. Making a function public inde

[issue16213] Expose private functions in marshal used by importlib

Brett Cannon added the comment: _w_long and _r_long originally came from marshal; forgot I re-implemented them in pure Python in the end. -- ___ Python tracker ___ _

[issue16213] Expose private functions in marshal used by importlib

Martin v. Löwis added the comment: I don't understand this issue at all: a) _bootstrap does not currently use any private API of marshal. Instead, it has functions _w_long and _r_long implemented in pure Python. So where is the special functionality that only importlib has? Anybody could easil

[issue16213] Expose private functions in marshal used by importlib

Brett Cannon added the comment: http://bugs.python.org/issue15031 would deal with not needing to expose _r_long and _w_long, but that still means people are screwed for _fix_co_filename. You could argue that is a margin use-case, though. -- dependencies: +Split .pyc parsing from module

[issue16213] Expose private functions in marshal used by importlib

Antoine Pitrou added the comment: Le vendredi 12 octobre 2012 à 16:23 +, Brett Cannon a écrit : > Well, it means importlib becomes a special library and that no one > could ever replicate it as a third-party library. Well, it *is* a special library. It is tightly integrated with the interpre

[issue16213] Expose private functions in marshal used by importlib

Brett Cannon added the comment: Well, it means importlib becomes a special library and that no one could ever replicate it as a third-party library. Now if we can expose the various APIs around this such that they are abstracted away then it isn't a big deal. That can be done for the _r_long a

[issue16213] Expose private functions in marshal used by importlib

Antoine Pitrou added the comment: Why is it a problem for importlib to use internal APIs? I don't think support these low-level APIs as public helps anyone. -- nosy: +pitrou ___ Python tracker _

[issue16213] Expose private functions in marshal used by importlib

New submission from Brett Cannon: IOW make _w_long, _r_long, and __fix_co_filename public so as to not be some special ability that only importlib has. -- components: Library (Lib) messages: 172751 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open titl