[issue46550] __slots__ updates despite being read-only
Ian Lee added the comment: @ronaldoussoren - right, I agree that I think that raising the AttributeErrors is the right thing. The part that feels like a bug to me is that the exception is saying it is read only and yet it is not being treated it that way (even though as you point out, the end result doesn't "work"). Maybe this is something about the augmented assignment that I'm just not grokking... I read the blurb @eryksun posted several times, but not seeming to see what is going on. -- ___ Python tracker <https://bugs.python.org/issue46550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46550] __slots__ updates despite being read-only
Ian Lee added the comment:
@sobolevn - Hmm, interesting.. I tested in python 3.9 which I had available,
and I can reproduce your result, but I think it's different because you are
using a tuple. If I use a list then I see my same reported behavior in 3.9:
```python
Python 3.9.10 (main, Jan 26 2022, 20:56:53)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
... __slots__ = ('x',)
...
>>> a = A()
>>> a.__slots__
('x',)
>>> a.__slots__ += ('y',)
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'A' object attribute '__slots__' is read-only
>>> a.__slots__
('x',)
>>>
>>>
>>>
>>> class B:
... __slots__ = ['x']
...
>>> b = B()
>>> b.__slots__
['x']
>>> b.__slots__ += ['y']
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'B' object attribute '__slots__' is read-only
>>> b.__slots__
['x', 'y']
```
--
___
Python tracker
<https://bugs.python.org/issue46550>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46550] __slots__ updates despite being read-only
New submission from Ian Lee : Hi there - I admit that I don't really understand the internals here, so maybe there is a good reason for this, but I thought it was weird when I just ran across it. If I create a new class `A`, and set it's `__slots`: ```python ➜ ~ docker run -it python:3.10 Python 3.10.2 (main, Jan 26 2022, 20:07:09) [GCC 10.2.1 20210110] on linux Type "help", "copyright", "credits" or "license" for more information. >>> class A(object): ... __slots__ = ["foo"] ... >>> A.__slots__ ['foo'] ``` If I then go to add a new attribute to extend it on the class, that works: ```python >>> A.__slots__ += ["bar"] >>> A.__slots__ ['foo', 'bar'] ``` But then if I create an instance of that class, and try to update `__slots__` on that instnace, I get an AttributeError that `__slots__` is read-only, and yet it still is updating the `__slots__` variable: ```python >>> a = A() >>> a.__slots__ ['foo', 'bar'] >>> a.__slots__ += ["baz"] Traceback (most recent call last): File "", line 1, in AttributeError: 'A' object attribute '__slots__' is read-only >>> a.__slots__ ['foo', 'bar', 'baz'] >>> A.__slots__ ['foo', 'bar', 'baz'] ``` Maybe there is a good reason for this, but I was definitely surprised that I would get a "this attribute is read-only" error, and yet still see that attribute updated. I first found this in python 3.8.5, but I also tested using docker to generate the above example using docker python:3.10 which gave me python 3.10.2. Cheers! -- components: Library (Lib) messages: 411886 nosy: IanLee1521 priority: normal severity: normal status: open title: __slots__ updates despite being read-only type: behavior versions: Python 3.10, Python 3.8 ___ Python tracker <https://bugs.python.org/issue46550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27187] Relax __all__ location requirement in PEP 8
Changes by Ian Lee <ianlee1...@gmail.com>: Added file: http://bugs.python.org/file43296/issue-27187-patch3.txt ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27187] Relax __all__ location requirement in PEP 8
Ian Lee added the comment: Good catch. I'm uploading a new patch that addresses ``from __future__`` imports issue explicitly. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27191] Add formatting around methods in PEP 8
New submission from Ian Lee: Noticed a couple methods in the text that aren't backtick quoted. -- assignee: docs@python components: Documentation files: rst-formatting.txt messages: 267015 nosy: IanLee1521, barry, docs@python priority: normal severity: normal status: open title: Add formatting around methods in PEP 8 Added file: http://bugs.python.org/file43136/rst-formatting.txt ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27191> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27187] Relax __all__ location requirement in PEP 8
Ian Lee added the comment: I added a comment on a pull request related to this that shows some of the cases that we probably don't want to allow: https://github.com/PyCQA/pycodestyle/pull/523#issuecomment-223464775 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23061] Update pep8 to specify explicitly 'module level' imports at top of file
Ian Lee added the comment: Are there any other concerns with the patch that I would be able to clean up? -- nosy: +barry ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27187] Relax __all__ location requirement in PEP 8
Changes by Ian Lee <ianlee1...@gmail.com>: Added file: http://bugs.python.org/file43134/issue-27187-patch2.txt ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27187] Relax __all__ location requirement in PEP 8
Ian Lee added the comment: I might also suggest that the entire "Version bookkeeping" section could be removed in this case, as it would be covered by my newly added dunder section. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27187] Relax __all__ location requirement in PEP 8
Ian Lee added the comment:
I think that it should be updated to specify that all dunders ('__all__',
'__version__', '__author__', etc) should be placed after the module docstring
and before any imports. See issue-27187-patch1.txt for a possible update.
--
Added file: http://bugs.python.org/file43132/issue-27187-patch1.txt
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27187>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27187] Relax __all__ location requirement in PEP 8
Changes by Ian Lee <ianlee1...@gmail.com>: -- nosy: +IanLee1521 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26763] Update PEP-8 regarding binary operators
Ian Lee added the comment:
> Aren't there many other examples in the PEP that need to be adjusted, since
> we're changing the style not just for 'and' and 'or' but for all binary
> operators?
Admittedly I'd only looked in that one section last night, but I just went
through the PEP and didn't see any other when I just went through the entire
PEP now...
> I also think the PEP needs some language about the previous style being still
> acceptable as long as it's being used consistently (Knuth notwithstanding),
> and an acceptable compromise style where and/or go at the start of the line
> but other binary operators stay at the end.
I'd updated my branch on GitHub [1] but Guido, you beat me to the update while
I was typing this message!
> I don't like the way "):" is indented in that example.
Honestly I don't either, I just like it more than artificially pushing the
other lines forward a space. Personally, I'm not a fan of the current change
either which puts the raise in line with the condition logic for the `if`::
if (width == 0
and height == 0
and color == 'red'
and emphasis == 'strong'
or highlight > 100):
raise ValueError("sorry, you lose")
My preference is to actually break that logic up and avoid the wrapping in the
first place, as in [2]. Which in this particular class has the side benefit of
that value being used again in the same function anyways.
I'm starting to realize that Brandon Rhodes really had a big impact on my ideas
of styling as I've been learning Python these past few years, as this was
another one style I'm stealing from that same talk [3].
> I've updated the PEP...
Great, thanks! I've created a ticket in pycodestyle [4] to update the style
checker, which in turn will fix the flake8 error downstream once I get around
(hopefully before PyCon) to releasing pycodestyle 1.8.0
[1] https://github.com/python/peps/compare/master...IanLee1521:issue26763
[2]
https://github.com/python/peps/commit/0c790e7b721bd13ad12ab9e6f6206836f398f9c4
[3]
http://rhodesmill.org/brandon/slides/2012-11-pyconca/#naming-intermediate-values
[4] https://github.com/PyCQA/pycodestyle/issues/498
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26763>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26763] Update PEP-8 regarding binary operators
Ian Lee added the comment: Link to GitHub branch with the patch as a commit [1]. [1] https://github.com/python/peps/compare/master...IanLee1521:issue26763 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26763] Update PEP-8 regarding binary operators
Ian Lee added the comment: Discussion link missing from msg263453: https://mail.python.org/pipermail/python-ideas/2016-April/039774.html -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26763] Update PEP-8 regarding binary operators
New submission from Ian Lee: Following up from discussion on python-ideas [1] about updating PEP-8 regarding wrapping lines before rather than after binary operators. -- files: wrap-before-binary-operator.patch keywords: patch messages: 263453 nosy: IanLee1521, gvanrossum priority: normal severity: normal status: open title: Update PEP-8 regarding binary operators type: enhancement Added file: http://bugs.python.org/file42463/wrap-before-binary-operator.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23639] Not documented special names
Changes by Ian Lee ianlee1...@gmail.com: -- nosy: +IanLee1521 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23639 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23182] Update grammar tests to use new style
New submission from Ian Lee: Per Guido's suggestion on the p...@python.org mailing list, I'm creating this issue to update the argument annotation tests at cpython/Lib/test/test_grammar.py to use the new style wording Guido requested on GitHub [1] that I proposed and was merged into PEP-8 [2] regarding annotated function definitions. [1] https://github.com/jcrocholl/pep8/issues/357#issuecomment-67527455 [2] https://hg.python.org/peps/rev/7eb1ddc0291c -- components: Library (Lib), Tests files: pep8-annotated-func-test-update.patch keywords: patch messages: 233569 nosy: IanLee1521, Rosuav, gvanrossum priority: normal severity: normal status: open title: Update grammar tests to use new style type: enhancement Added file: http://bugs.python.org/file37624/pep8-annotated-func-test-update.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23182 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23182] Update grammar tests to use new style for annotated function definitions
Changes by Ian Lee ianlee1...@gmail.com: -- title: Update grammar tests to use new style - Update grammar tests to use new style for annotated function definitions ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23182 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23061] Update pep8 to specify explicitly 'module level' imports at top of file
Ian Lee added the comment:
So one concern that was brought up on GitHub was the fact that currently this
is not actually followed universally in the Python standard library. In
particular there are 636 errors in the standard library ``python pep8.py
--select E402 --statistics /usr/lib/python3.4``.
The vast majority are due to issues with dunder definitions
``__{all,author,copyright,credits,version,etc...}__`` before the imports. A
lesser cause is imports in the middle of files. ``Lib/tokenize.py`` has pretty
much all of these issues. In particular ``__all__`` is specifically mentioned
that it should be declared AFTER the imports by PEP-8. That said, I would argue
this is a good time to clean up that code in the standard library.
Additionally, its possible that there might need to be some wording in the PEP
about intermixing try,except,else,finally and possibly if,elif,else into
the imports. E.g.
```
try:
import unittest2
except:
import unittest
```
```
if sys.platform == 'win32':
import foo
```
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23061
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23061] Update pep8 to specify explicitly 'module level' imports at top of file
Ian Lee added the comment: I should add that I would be happy to patch the standard libraries to be compliant w.r.t. the imports at top of the files. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23061 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23061] Update pep8 to specify explicitly 'module level' imports at top of file
New submission from Ian Lee: Minor update pep8 to specify explicitly that Imports at top of file refers specifically to module level imports, per input from Nick Coghlan @ https://github.com/jcrocholl/pep8/pull/304#issuecomment-66939162 -- assignee: docs@python components: Documentation files: pep-0008.patch keywords: patch messages: 232708 nosy: IanLee1521, docs@python, ncoghlan priority: normal severity: normal status: open title: Update pep8 to specify explicitly 'module level' imports at top of file type: enhancement Added file: http://bugs.python.org/file37459/pep-0008.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23061 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
