[issue35572] Logging module cleanup
New submission from Solomon Ucko : The logging module should be changed to use snake_case (as opposed to camelCase). Also, logger.basicConfig should list keyword arguments and defaults in the argument list, as opposed to using `**kwargs` and `dict.pop` (for readability and improved inspection capabilities). These should both be relatively easy changes to make. The case conversion should leave the camelCase versions as deprecated but left for backwards compatibility (as in the operator module). -- components: Extension Modules messages: 332401 nosy: Solomon Ucko priority: normal severity: normal status: open title: Logging module cleanup type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35572> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35574] Coconut support
New submission from Solomon Ucko : Any chance we could integrate [Coconut](http://coconut-lang.org/) into Python? Any sain Python code should work with Coconut and Coconut allows making code *so* much more readable. IMO, the reason not many people use Coconut is that they haven't heard of it and because of its lack of IDE support. (I would use it if it had more IDE support than just syntax highlighting.) The reason it has so little IDE support is that not many people use it. Making it a part of Python would alleviate these concerns. -- messages: 332402 nosy: Solomon Ucko, benjamin.peterson, brett.cannon, yselivanov priority: normal severity: normal status: open title: Coconut support type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue35574> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35575] Improved range syntax
New submission from Solomon Ucko : 3 independent but related proposals. (#4 requires #3.) The main issue for #2 and #4 is the readability of a mix of square and round brackets, especially within nested brackets. This would be less of an issue with [Coconut support](https://bugs.python.org/issue35574). #1. Range inclusive/exclusive keyword arguments (mostly backward compatible) Inclusive/exclusive options for range as keyword arguments (defaulting to `inc_start=True, inc_stop=False`). Code that processes range objects will ignore these unless using `in` tests. The semantics would be as follows: ```python class range: ... def __iter__(self): if self.inc_start: yield self.start i = self.start + self.step while i < self.stop if self.step > 0 else i > self.stop: yield i i += self.step if self.inc_stop and i == self.stop: yield i ``` This would allow for control over the slightly controversial decision of inclusivity/exclusivity for ranges on a case-by-case basis. Any existing code that creates ranges would not be impacted. #2. Range syntax (fully backward compatible) Maybe `(start:stop)`, `(start:stop]`, `[start:stop)` and `[start:stop]` could be used to represent ranges? (`(` = exclusive; `[` = inclusive.) Step notation would also be legal. (E.g. `(start:stop:step)`.) This would allow for a concise, familiar notation for ranges. #3. Slice inclusive/exclusive keyword arguments (mostly backward compatible) This is analogous to #1, except with `slice` instead of `range`. #4. Slice inclusive/exclusive syntax (would require a __future__ in Python 3) As opposed to forcing half-open intervals, a mix of round parentheses and square brackets could be allowed to be used for slices, analogously to #2. Since square brackets with a colon currently represent half-open intervals, this would have to require a __future__ import in Python 3. This could become the default in Python 4. -- components: Interpreter Core messages: 332403 nosy: Solomon Ucko, benjamin.peterson, brett.cannon, yselivanov priority: normal severity: normal status: open title: Improved range syntax type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue35575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11614] import __hello__ is broken in Python 3
Solomon Ucko added the comment:
The byte code could be further optimized (because this is such a speed-critical
module! :)):
1 0 LOAD_CONST 2 (True)
3 STORE_NAME 1 (initialized)
2 6 LOAD_NAME2 (print)
9 LOAD_CONST 0 ('Hello world...')
12 CALL_FUNCTION1
15 RETURN_VALUE
--
nosy: +Solomon Ucko
___
Python tracker
<https://bugs.python.org/issue11614>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11614] import __hello__ is broken in Python 3
Solomon Ucko added the comment: > It changes the semantics of Python. When would the return value actually matter? Would it affect the value of the variable `__hello__`? -- ___ Python tracker <https://bugs.python.org/issue11614> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
