[issue33965] [Windows WSL] Fatal Python error: _Py_InitializeMainInterpreter: can't initialize time, after year 2038
Franklin? Lee added the comment: Petter S reported the issue to Microsoft, and got the response that it was already fixed in Insider Preview. https://github.com/microsoft/WSL/issues/3514 Should be fixed in Windows 10 version 1809, according to the tags here: https://github.com/microsoft/WSL/issues/3252 -- nosy: +leewz ___ Python tracker <https://bugs.python.org/issue33965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37307] isinstance/issubclass doc isn't clear on whether it's an AND or an OR.
Franklin? Lee added the comment: > > It's likely also false that every entry will be checked, since presumably > > the function uses short-circuit logic. > This, however, would be good to verify first. Verified. https://github.com/python/cpython/blob/36dcaab7fde5d2e54cdeff5b705b5adcb27726dd/Objects/abstract.c#L2517 It loops through the tuple until it finds success or error. -- ___ Python tracker <https://bugs.python.org/issue37307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37307] isinstance/issubclass doc isn't clear on whether it's an AND or an OR.
Franklin? Lee added the comment: My mistake. I selected all versions after checking issubclass for 2.7 and several 3.x, but added the isinstance notes later without paying attention to versions. I copied the isinstance text from 3.2 docs. As you said, it's not the current text. -- ___ Python tracker <https://bugs.python.org/issue37307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37307] isinstance/issubclass doc isn't clear on whether it's an AND or an OR.
New submission from Franklin? Lee : isinstance: > If classinfo is not a class (type object), it may be a tuple of type objects, > or may recursively contain other such tuples (other sequence types are not > accepted). issubclass: > classinfo may be a tuple of class objects, in which case every entry in > classinfo will be checked. It is unclear from the docs whether issubclass(bool, (int, float)) should return True (because bool is a subclass of int), or False (because bool is NOT a subclass of float). (It returns True.) It's likely also false that every entry will be checked, since presumably the function uses short-circuit logic. issubclass's doc also doesn't mention the recursive tuple case that isinstance's doc has. -- assignee: docs@python components: Documentation messages: 345744 nosy: docs@python, leewz priority: normal severity: normal status: open title: isinstance/issubclass doc isn't clear on whether it's an AND or an OR. type: enhancement versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32982] Parse out invisible Unicode characters?
New submission from Franklin? Lee <leewangzh...@gmail.com>: The following line should have a character that trips up the compiler. indices = range(5) The character is \u200e, and was inserted by Google Keep. (I've already reported the issue to Google as a regression.) Here's the error message: """ File "", line 3 indices = range(5) ^ SyntaxError: invalid character in identifier """ Depending on the terminal or editor, it may not be possible to tell the problem just from looking. Without knowledge/experience of Unicode, it may not be possible to figure out the problem at all. Since Python source now uses Unicode by default, should certain invisible characters be stripped out during compilation? -- components: Unicode messages: 313127 nosy: ezio.melotti, leewz, vstinner priority: normal severity: normal status: open title: Parse out invisible Unicode characters? type: behavior ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32982> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26632] __all__ decorator
Franklin? Lee added the comment: BIKESHEDDING Here is another concern with decorators and `.__module__` (or `inspect.getmodule`). (Or is it the original concern?) If an earlier decorator creates a wrapper and doesn't set .__module__, you'll make the function public in the wrong module. @public @bad_wrapper def f(...): ... IMO, the correct solution is a new stdlib function, to get the currently-loading module. You wouldn't need explicit frame hacking, and it will be portable between different Python implementations because each implementation will have to define it correctly. The problem with this solution is the lack of other usecases for such a function, though maybe someone in python-ideas can think of one. Candidate owners: sys, importlib. Candidate names: - sys.getloadingmodule() - importlib.currentimport() - importlib.???() Effect: - Returns the "innermost" loading module. If no module is loading, returns None? - In a thread, return the module being loaded in that thread (possibly None, even if other threads are loading modules). - (I don't know what I'm talking about:) If a Python implementation uses multithreaded loading, each thread whose result could immediately be loaded into the module's namespace (i.e. it's close to the "surface" of the load) is considered to be loading that module. - Needs to handle re-imports, such as from `importlib.reload`. Other solutions include: - Require explicit `@public(__all__)` (or `__module__`) - Special `super()`-like treatment of `public` which automatically inserts the `__all__` (or whatever). - Hope that bad wrappers don't come up. I think nonexistence of module.__all__ should be an error. The behavior with a module with __all__ is very different from one without, so I think that if you want your module to have __all__, you should be required to create it, even if it's empty. Assuming that __all__ is, by convention, always near the top, someone reading your code would know whether the first dozen or so functions are part of the public interface, without searching for `@public`. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26632] __all__ decorator
Franklin? Lee added the comment: I probably won't submit a patch, but I can definitely write a bunch of private notes toward a patch and forget about them. >_> Idea 1: Crawl up the call tree and see whether you hit a module definition or a class definition first. Idea 2: Inspect __qualname__ to determine whether it's a method/inner function. That might have the same problems with @wraps, though, and you wouldn't be allowed to use a classmethod as a module's function. Idea 2 seems to be the right thing. If ".__qualname__ != .__name__", it's an error. If you really want to use `public` in the above cases, you should use the assignment form of `public` (whatever it turns out to be), or explicitly append to __all__. Rule: The programmer should not explicitly use `public(a_func)`, and should use assignment-form `public` if `@public` is not possible (== the decorator form is not being used at the point of definition). I think this way won't have errors passing silently and failing mysteriously. First draft of error message (not considering assignment-form): "'public' should only be used as a decorator for a function/class in module scope." -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27119] `compile` doesn't compile into an AST object as specified
Franklin? Lee added the comment: > What you're looking for is in the 2nd paragraph of the ast docs: Oh. I considered that, but then compile's docs say: The optional arguments flags and dont_inherit control which future statements (see PEP 236) affect the compilation of source. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26632] __all__ decorator
Franklin? Lee added the comment: >>If @public were only to be used as a decorator, it would not be possible to >>have `public` called on a function outside of its definition. But someone >>might call `public(some_decorator(some_function))`. > >Do you mean, they'd call this is some module other than the one some_function >was defined in? I don't know that this is a use case we even want to support. I mean they'd define their own function as a wrapped version of another function. >That's true in a sense. It doesn't change the decorated thing at all. I >think it's important to keep in mind that @public isn't the only way to add to >__all__. I mean more in that it acts in the scope of its caller, rather than its definition. >You should get something like: > >AttributeError: 'tuple' object has no attribute 'append' > >which seems pretty obvious. I don't think the C version shows a traceback, so it won't be clear that you're trying to assign to `__all__`. When I rewrote `public` from memory, I wrote it something like this: try: dunder_all.append(name) except TypeError: module.__all__ = [*dunder_all, name] >Well, consenting adults and all. I'm not sure we need to protect ourselves so >strictly against people who don't read the docs and don't understand Python >(i.e. random cargo-culters). Python is a popular learning language, and many will be students who haven't yet trained to reflexively look up docs. I saw the lack of such habits in Python's IRC channel. "Consenting adults", I feel, is a reason to grant power: don't stop people from doing something they might need to do. But @public on a class method is just an error. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27119] `compile` doesn't compile into an AST object as specified
New submission from Franklin? Lee: >From `compile`'s doc: "Compile the source into a code or AST object." The docs don't say how to compile into an AST object with `compile`, though. As it says later: "If you want to parse Python code into its AST representation, see ast.parse()." I checked 3.4-3.2, 3.0, 2.7, and 2.6. Versions before 3.4, and version 2.6, are missing the `ast.parse` line, but still have the first line. -- assignee: docs@python components: Documentation messages: 266311 nosy: docs@python, leewz priority: normal severity: normal status: open title: `compile` doesn't compile into an AST object as specified type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26632] __all__ decorator
Franklin? Lee added the comment:
>I don't know, but what practical effect will this have? I.e. under what
>conditions would you @public wrap a @functools.wraps function and want it to
>show up in __all__? Do you have a specific use case?
I sometimes wrap functions that return iterators to make functions that return
lists, because I work on the interpreter a lot. From there, it's not much of a
stretch to imagine functions which are implemented as decorated versions of
other functions.
If @public were only to be used as a decorator, it would not be possible to
have `public` called on a function outside of its definition. But someone might
call `public(some_decorator(some_function))`.
(@public is really a macro, if you think about it.)
>It would be possible.
(I meant, is it possible for someone to have a non-list __all__?)
If the `.append` fails, I think there should be a meaningful error. Perhaps
"'__all__' is not a list."
>Sure, we could probably add some heuristics, but I still don't see the need
>for the extra complexity. The error will be far from the declaration, but the
>exception should make it relatively obvious what's going on. I also really
>don't think folks would naturally be inclined to put @public on anything but a
>top-level definition. You wouldn't ever put such a thing in your __all__ so
>why would you decorate it with @public?
I'm thinking of the people who don't read docs and are coming from other
languages. They'd put `@public` over their method, and one day they'd `import
*` from that file (whereas they used to only import explicitly), getting an
error about a name not being defined in their module. "But why would that name
need to be defined? It's a method."
Or worse, the name of the method just happens to be the same as something in
some other file, so they'll focus on why that NAME is being expected in THIS
file.
>Also, I know that I have several cases where constants are actually
>instances. They could be marker objects like::
>
>MARKER = object()
(Here's food for thought: A MARKER could be a one-element enum, both
conceptually and by implementation. Just like how the "bool enum" is
{True,False} and the "None enum" is {None}.)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26632>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26632] __all__ decorator
Franklin? Lee added the comment: I like how ``@public`` keeps the declaration close to the definition. I am iffy about using ``public`` to define other values. That part might be considered unpythonic. Implementation issues: - ``__module__`` is not reliable. ``functools.wraps`` changes it. (Why does it do that, though?) - If `__all__` isn't a list, you'd have to make it a list before you mess with it. (Is this possible?) > > On the down side, you know somebody is going to @public a class' method -- > > how do we check for that? > > Do we need to? Consenting adults and __all__. It's a silent error waiting to happen. If you never use ``import *`` on it (e.g. because it's your main file), you won't get the error message. Things will work "as expected" (your methods are class-public!) until you give a method the same name as a builtin or something you imported or defined earlier. When that happens, the error message will have nothing to do with the problem. It might be detectable using ``thing.__qualname__ != thing.__name__``, but this disallows functions decorated without updating __qualname__, and static/class methods exposed in a module's interface. It might be detectable by checking, on the callstack, whether you're in a module load or a class definition. Bikeshed How many public module values aren't enum-type constants? It could be useful to be able to dump an enum into a module's space. I mean, a canonical way. With that, maybe maintaining module-level constants in __all__ isn't that big a deal. # Rather than: globals().update(MyEnum.__members__) __all__.extend(MyEnum.__members__) # Perhaps allow: enum.dump_namespace(MyEnum, globals()) About the cost paid at every load: - Should tools update __all__ for you, and comment out the ``@public``s? - If so, how would they deal with public non-callable values? - When compiling to .pyc, should the compiler remove ``@public`` calls and explicitly add the values to __all__? API: - Alternative syntax for constants, requiring less frame hackery: public(globals(), x=1, y=2, z=3) - Naming: Is it really "public"? Some names might be public but not in __all__. P.S. Typo in the ReadTheDocs. ``py_install`` should be a function call, right? >>> from public import py_install >>> py_install P.S.: Would OrderedSet (which doesn't exist) be the ideal type for __all__? I mean, if you had to use someone else's __all__, not if you had to maintain it. -- nosy: +leewz ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27062] `inspect` doesn't have `__all__`
New submission from Franklin? Lee: `inspect`'s names are pretty close to unique, except for `stack`, `unwrap`, and `trace`. It doesn't define `__all__`, though. -- components: Library (Lib) messages: 265893 nosy: leewz priority: normal severity: normal status: open title: `inspect` doesn't have `__all__` type: behavior versions: Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27000] improve document of filter
Franklin? Lee added the comment: In that case, I'm still wondering what you mean by "not equivalent". Are you saying there is code which will work only if the ``bool`` function is really called? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27000> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27000] improve document of filter
Franklin? Lee added the comment: > Although I still think it's telling readers incorrect info in the second > part. For ``bool``, it is not equivalent to ``(item for item in iterable if > function(item))`` but ``(item for item in iterable if item)``. For CPython, > you are not telling the truth. What do you mean by, "it is not equivalent"? Are you saying that the first one will give a different result from the second? In general, when interpreting an object in a boolean context, Python will do the "equivalent" of calling ``bool`` on it, where "equivalent" in the docs means "has the same result as". See, for example, the ``itertools`` docs: https://docs.python.org/3/library/itertools.html#itertools.accumulate In this case: If ``filter`` is passed ``None`` or ``bool``, it will call "PyObject_IsTrue" on the object. (https://github.com/python/cpython/blob/c750281ef5d8fa89d13990792163605302e972d4/Python/bltinmodule.c#L481) "PyObject_IsTrue" is defined here: https://github.com/python/cpython/blob/6aea3c26a22c5d7e3ffa3d725d8d75dac0e1b83b/Objects/object.c#L1223 On the other hand, ``bool`` is defined here, as "PyBool_Type": https://github.com/python/cpython/blob/c750281ef5d8fa89d13990792163605302e972d4/Python/bltinmodule.c#L2686 "PyBool_Type" is defined here, with the ``bool.__new__`` function defined as "bool_new": https://github.com/python/cpython/blob/2d264235f6e066611b412f7c2e1603866e0f7f1b/Objects/boolobject.c#L133 "bool_new" is defined here, using "PyObject_IsTrue": https://github.com/python/cpython/blob/2d264235f6e066611b412f7c2e1603866e0f7f1b/Objects/boolobject.c#L43 Both "filter_next" and "bool_new" call "PyObject_IsTrue" and take 0 as False, positive as True, and negative as an error. So it's equivalent to calling ``bool``, but the "bool_new" call is sort of inlined. Does that clear things up? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27000> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27000] improve document of filter
Franklin? Lee added the comment: Aren't these both implementation details? As in, they only affect efficiency, not effect, right? -- nosy: +leewz ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27000> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
