[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"
Mateusz Loskot added the comment: Possibly, the new partial-input mode of the parser (https://bugs.python.org/issue46521#msg412832) will improve this issue in 3.11. I'm going to play with it soon and I will report back. -- ___ Python tracker <https://bugs.python.org/issue46502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"
Mateusz Loskot added the comment: Not quite the answer I'd like to received, but thank you very much for the explanation. I've submitted pull request removing the deprecated FAQ entry https://github.com/python/cpython/pull/30925 -- ___ Python tracker <https://bugs.python.org/issue46502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"
Mateusz Loskot added the comment: Irit, I can and I will submit a patch. However, I'm very keen to learn what is an alternative solution then to distinguish hard invalid from incomplete input. IOW, what would be the new way of achieving what's described in the old FAQ? I believe it would be more useful to the community if I updated the sample in the FAQ instead of just removing it. -- ___ Python tracker <https://bugs.python.org/issue46502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"
New submission from Mateusz Loskot : Something has changed in Python 3.7 through 3.10 (I'm observing it in 3.10) in behaviour of the Python C API function Py_CompileString such that for an incomplete input it no longer raises SyntaxError: "unexpected EOF while parsing" but IndentationError: expected an indented block after ... The new behaviour makes the sample program from the "How do I tell “incomplete input” from “invalid input”?" at https://docs.python.org/3/faq/extending.html no longer work as described there. For example: ``` for i in []: ``` raises IndentationError: expected an indented block after 'for' statement on line 1 ``` if True: ``` raises IndentationError: expected an indented block after 'if' statement on line 1 instead of SyntaxError: unexpected EOF while parsing This effectively makes it impossible to detect incomplete input using the Py_CompileString in applications where it is not possible to use PyRun_InteractiveLoop. I have failed to identify what could be related changes in the release notes and the documentation does not seem to offer any update on that. So, I'm assuming the new behaviour is not desired or expected. Attached, is the VS 2022 screenshot with debugging session of the sample program from the FAQ presenting the difference in the behaviour between Python 3.6 and 3.10 on Windows. -- components: C API files: Py_CompileString-Py36-vs-Py310.png messages: 411484 nosy: mloskot priority: normal severity: normal status: open title: Py_CompileString no longer allows to tell "incomplete input" from "invalid input" versions: Python 3.10 Added file: https://bugs.python.org/file50582/Py_CompileString-Py36-vs-Py310.png ___ Python tracker <https://bugs.python.org/issue46502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45064] Raising AttributeError in descriptor decorator causing searching attribute in __mro__
New submission from Mateusz :
A descriptor that is raising AttributeError in __get__() causes that the
Python's interpreter continues searching for attributes in __mro__ calling
__getattr__() function in inherited classes.
Let's take a look for example script with this bug.
class A1:
def __getattr__(self, name):
print("A1 visited")
raise AttributeError(f"{self.__class__.__name__}: {name} not found.")
class A2(A1):
def __getattr__(self, name):
print("A2 visited")
super().__getattr__(name)
class A3(A2):
def __getattr__(self, name):
print("A3 visited")
super().__getattr__(name)
class B:
def __init__(self, f):
self.f = f
def __get__(self, obj, objtype=None):
raise AttributeError("Python bug?")
class C(A3):
@B
def test(self):
return 25
B is a decorator attached to C.test() and it is throwing AttributeError. When
c.test() is performed it starts for walking through C.__mro__ and calling
__getattr__() function in objects.
>>> from bug import C
>>> c = C()
>>> c.test()
A3 visited
A2 visited
A1 visited
Traceback (most recent call last):
File "", line 1, in
File "/home/blooser/python-bug/bug.py", line 17, in __getattr__
super().__getattr__(name)
File "/home/blooser/python-bug/bug.py", line 11, in __getattr__
super().__getattr__(name)
File "/home/blooser/python-bug/bug.py", line 6, in __getattr__
raise AttributeError(f"{self.__class__.__name__}: {name} not found.")
AttributeError: C: test not found.
Changing error in B.__get__() to NameError:
class B:
def __init__(self, f):
self.f = f
def __get__(self, obj, objtype=None):
raise NameError("Python bug?")
causes it omits C.__mro__.
>>> from bug import C
>>> c = C()
>>> c.test()
Traceback (most recent call last):
File "", line 1, in
File "/home/blooser/python-bug/bug.py", line 26, in __get__
raise NameError("Python bug?")
NameError: Python bug?
I'm thinking that it is expected behavior or is this a bug?
--
components: Interpreter Core
files: bug.py
messages: 400743
nosy: blooser
priority: normal
severity: normal
status: open
title: Raising AttributeError in descriptor decorator causing searching
attribute in __mro__
type: behavior
versions: Python 3.11
Added file: https://bugs.python.org/file50248/bug.py
___
Python tracker
<https://bugs.python.org/issue45064>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32599] Add dtrace hook for PyCFunction_Call
Change by Mateusz Piotrowski <0...@freebsd.org>: -- nosy: +0mp ___ Python tracker <https://bugs.python.org/issue32599> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29077] build failure when enabling dtrace on FreeBSD
Mateusz Piotrowski <0...@freebsd.org> added the comment: Patch for the FreeBSD Ports to fix the build failure: https://reviews.freebsd.org/D31489 -- ___ Python tracker <https://bugs.python.org/issue29077> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29077] build failure when enabling dtrace on FreeBSD
Change by Mateusz Piotrowski <0...@freebsd.org>: -- nosy: +0mp versions: +Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue29077> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)
Change by Mateusz Loskot : -- nosy: +mloskot ___ Python tracker <https://bugs.python.org/issue39511> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32954] Lazy Literal String Interpolation (PEP-498-based fl-strings)
Change by Mateusz Bysiek : -- nosy: +mbdevpl ___ Python tracker <https://bugs.python.org/issue32954> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31871] Support for file descriptor params in os.path
New submission from Mateusz Kurek : Since Python 3.3, some os module functions, like os.stat (https://docs.python.org/3/library/os.html#os.stat), support passing file descriptor instead of a path. os.path functions, on the other hand (like os.path.exists - https://docs.python.org/3/library/os.path.html#os.path.exists - or os.path.samefile - https://docs.python.org/3/library/os.path.html#os.path.samefile) mention using os.stat underneath, but according to documentation, does not support passing file descriptor instead of a path (at least it's not mentioned in the docs that this feature is supported). Is this intentional (os.path functions should not take file descriptor params) or this feature is officialy supported, but it's ommited in the docs? -- assignee: docs@python components: Documentation messages: 305023 nosy: Mateusz Kurek, docs@python priority: normal severity: normal status: open title: Support for file descriptor params in os.path type: enhancement versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue31871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31826] Misleading __version__ attribute of modules in standard library
New submission from Jakub Mateusz Dzik : Several modules of the standard library (at least `re` and `csv`) have `__version__` strings. The string is the same for Python 2.7-3.6: >>> import re, csv; print(re.__version__, csv.__version__) 2.2.1 1.0 while documentation indicates changes in the modules. Semantic versioning (recommended by PEP 440) suggests that at least minor version should change in such case. I suspect it to be a "code fossil" which may be removed according to PEP 396. -- components: Library (Lib) messages: 304654 nosy: abukaj priority: normal severity: normal status: open title: Misleading __version__ attribute of modules in standard library type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.org/issue31826> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29715] Argparse improperly handles "-_"
Changes by Mateusz Bysiek : -- title: Arparse improperly handles "-_" -> Argparse improperly handles "-_" ___ Python tracker <http://bugs.python.org/issue29715> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28964] AST literal_eval exceptions provide no information about line number
Changes by Mateusz Bysiek : -- nosy: +mbdevpl ___ Python tracker <http://bugs.python.org/issue28964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10399] AST Optimization: inlining of function calls
Changes by Mateusz Bysiek : -- nosy: +mbdevpl ___ Python tracker <http://bugs.python.org/issue10399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer
Changes by Mateusz Bysiek : -- nosy: +mbdevpl ___ Python tracker <http://bugs.python.org/issue11549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29471] AST: add an attribute to FunctionDef to distinguish functions from generators and coroutines
Changes by Mateusz Bysiek : -- nosy: +mbdevpl ___ Python tracker <http://bugs.python.org/issue29471> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24119] Carry comments with the AST
Mateusz Bysiek added the comment: For some time now, there's an alternate ast implementation https://github.com/python/typed_ast that carries PEP 484 type comments with the AST as attributes of certain nodes. Their approach is described here: https://github.com/python/typed_ast/blob/master/typed_ast/ast3.py#L5 If type comments become mainstream in Python, could this approach maybe be adopted as official Python AST at some point? -- nosy: +mbdevpl ___ Python tracker <http://bugs.python.org/issue24119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29051] Improve error reporting involving f-strings (PEP 498)
Changes by Mateusz Bysiek : -- nosy: +mbdevpl ___ Python tracker <http://bugs.python.org/issue29051> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29814] parsing f-strings -- opening brace of expression gets duplicated when preceeded by backslash
New submission from Mateusz Bysiek:
with Python 3.6.0 and the following script:
```
#!/usr/bin/env python3.6
import ast
code1 = '''"\\{x}"'''
code2 = '''f"\\{x}"'''
tree1 = ast.parse(code1, mode='eval')
print(ast.dump(tree1))
tree2 = ast.parse(code2, mode='eval')
print(ast.dump(tree2))
```
I get the following output:
```
Expression(body=Str(s='\\{x}'))
Expression(body=JoinedStr(values=[Str(s='\\{'),
FormattedValue(value=Name(id='x', ctx=Load()), conversion=-1,
format_spec=None)]))
```
Therefore, the normal string is `'\\{x}'`.
But the f-string has two parts: `'\\{'` and an expression `Name(id='x',
ctx=Load())`.
Where does the `{` in the string part of f-string come from? I can't believe
this is the intended behavior... Or, is it?
When I escape the backslash once like above, what gets parsed is actually
unescaped backslash. So this might just boil down to inconsistency in parsing
`\{` in normal vs. f-strings.
I originally discovered this in typed_ast
https://github.com/python/typed_ast/issues/34 but the behaviour of ast is
identical and since developers of typed_ast aim at compatibility with ast, I
bring this issue here.
--
components: Library (Lib)
messages: 289642
nosy: mbdevpl
priority: normal
severity: normal
status: open
title: parsing f-strings -- opening brace of expression gets duplicated when
preceeded by backslash
type: behavior
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue29814>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29025] random.seed() relation to hash() function and its determinism is vague
Jakub Mateusz Kowalski added the comment: Python 2.7 I think note to the docs is enough. Python 3.5+ I have a doubt. Isn't .seed(a, version=1) still coupled with PYTHONHASHSEED? The manual says version 1 is "reproducing random sequences from older versions of Python", and for 3.1 (and earlier) hash() is used, which (according to the manual) depends on PYTHONHASHSEED. Also, in Python 3.2-3.4 it is stated explicitly, that hash() is used. -- ___ Python tracker <http://bugs.python.org/issue29025> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29025] random.seed() relation to hash() function and its determinism is vague
New submission from Jakub Mateusz Kowalski: 2.7 (https://docs.python.org/2/library/random.html#random.seed) - warning about PYTHONHASHSEED (environmental variable) voiding determinism - no warning on -R interpreter switch - relation to hash() function omitted 2.6 (https://docs.python.org/2.6/library/random.html#random.seed) 3.0 (https://docs.python.org/3.0/library/random.html#random.seed) 3.1 (https://docs.python.org/3.1/library/random.html#random.seed) 3.2 (https://docs.python.org/3.2/library/random.html#random.seed) 3.3 (https://docs.python.org/3.3/library/random.html#random.seed) 3.4 (https://docs.python.org/3.4/library/random.html#random.seed) - no warning about PYTHONHASHSEED nor -R switch - relation to hash() function acknowledged 3.5 (https://docs.python.org/3.5/library/random.html#random.seed) 3.6 (https://docs.python.org/3.6/library/random.html#random.seed) 3.7 (https://docs.python.org/3.7/library/random.html#random.seed) - no warning about PYTHONHASHSEED nor -R switch - relation to hash() function omitted -- assignee: docs@python components: Documentation messages: 283688 nosy: Jakub.Mateusz.Kowalski, docs@python priority: normal severity: normal status: open title: random.seed() relation to hash() function and its determinism is vague versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue29025> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29023] Results of random.seed() call with integer argument should be claimed deterministic.
New submission from Jakub Mateusz Kowalski: In https://docs.python.org/2/library/random.html#random.seed I can find that "If a hashable object is given, deterministic results are only assured when PYTHONHASHSEED is disabled." Both int and long are hashable. However, tests on the random module as well as C source code of random_seed (as indicated in http://stackoverflow.com/a/41228062/4879688) suggest that behaviour of the module is deterministic when seeded with an integer. -- assignee: docs@python components: Documentation messages: 283686 nosy: Jakub.Mateusz.Kowalski, docs@python priority: normal severity: normal status: open title: Results of random.seed() call with integer argument should be claimed deterministic. versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue29023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14597] Cannot unload dll in ctypes until script exits
Changes by Mateusz Loskot : -- nosy: +mloskot ___ Python tracker <http://bugs.python.org/issue14597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28364] Windows - Popen (subprocess.py) does not call _handle.Close() at all
New submission from Mateusz Klatt: _subprocess.TerminateProcess(self._handle, 1) is not enough, on windows need to call self._handle.Close() after that self._handle.Close() should be also called in __del__ - for the process es that ware not killed bu user, but terminated by themselves. To reproduce... run popen in loop and observe file descriptors usage (SysInternals... handle -s -p ) -- components: Library (Lib) messages: 278129 nosy: Mateusz Klatt priority: normal severity: normal status: open title: Windows - Popen (subprocess.py) does not call _handle.Close() at all versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue28364> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26608] RLock undocumented behavior in case of multiple acquire
New submission from Mateusz: The number of acquisitions must be the same as the number of releases or else lock will not be released for other threads leading to deadlock. This is not mentioned in documentation. First acquisition returns boolean and further acquisitions return 1. This is also not mentioned in documentation. -- assignee: docs@python components: Documentation, Library (Lib) messages: 262165 nosy: docs@python, smbrd priority: normal severity: normal status: open title: RLock undocumented behavior in case of multiple acquire versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue26608> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24490] DeprecationWarning hidden even after warnings.filterwarnings('always') called
New submission from Jakub Mateusz Kowalski:
The error occurs when there was a warning before the call to filterwarnings():
$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> warnings.warn('aa', DeprecationWarning)
>>> warnings.filterwarnings('always')
>>> warnings.warn('aa', DeprecationWarning)
>>>
When filterwarnings() is called before warnings, everything is working as
expected:
$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> warnings.filterwarnings('always')
>>> warnings.warn('aa', DeprecationWarning)
__main__:1: DeprecationWarning: aa
>>> warnings.warn('aa', DeprecationWarning)
__main__:1: DeprecationWarning: aa
>>>
--
components: Interpreter Core
messages: 245691
nosy: Jakub.Mateusz.Kowalski
priority: normal
severity: normal
status: open
title: DeprecationWarning hidden even after warnings.filterwarnings('always')
called
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue24490>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment: Re msg238016, I confirm python-3.5.0a2-fdvalidation.patch fixes the problem for Python 3.5.0a4 and VS2013. The only issue I encountered was with HAVE_FSTAT which is missing from PC/pyconifg.h, so I edited the patch and removed the check if defined(HAVE_FSTAT). Does PC/pyconifg.h need update? I also confirm vanilla Python 3.5.0a4 with VS2015RC does not require this patch, because the fileno regression/bug has been fixed in VS2015RC (details at https://connect.microsoft.com/VisualStudio/feedback/details/785119/). -- ___ Python tracker <http://bugs.python.org/issue17797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22526] file iteration crashes for huge lines (2GiB+)
New submission from Jakub Mateusz Kowalski:
File /tmp/2147483648zeros is 2^31 (2GiB) zero-bytes ('\0').
Readline method works fine:
>>> fh = open('/tmp/2147483648zeros', 'rb')
>>> line = fh.readline()
>>> len(line)
2147483648
However when I try to iterate over the file:
>>> fh = open('/tmp/2147483648zeros', 'rb')
>>> for line in fh:
... print len(line)
SystemError Traceback (most recent call last)
/home/jkowalski/ in ()
> 1 for line in fh:
2 print len(line)
3
SystemError: Negative size passed to PyString_FromStringAndSize
Same is for greater files (issue discovered for 2243973120 B).
For a shorter file iteration works as expected.
File /tmp/2147483647zeros is 2^31 - 1 (< 2GiB) zero-bytes.
>>> fh = open('/tmp/2147483647zeros', 'rb')
>>> for line in fh:
... print len(line)
2147483647
I guess the variable used for size is of 32bit signed type.
I am using Python 2.7.3 (default, Feb 27 2014, 19:58:35) with IPython 0.12.1 on
Ubuntu 12.04.5 LTS.
--
components: IO
messages: 227949
nosy: Jakub.Mateusz.Kowalski
priority: normal
severity: normal
status: open
title: file iteration crashes for huge lines (2GiB+)
type: crash
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue22526>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22353] re.findall() documentation lacks information about finding THE LAST iteration of repeated capturing group (greedy)
Mateusz Dobrowolny added the comment: The official help https://docs.python.org/3/library/re.html?highlight=findall#re.findall in fact contains more information, especially the one mentioned in http://bugs.python.org/issue3384. Regarding my issue - I am afraid it was my misunderstanding, because it looks like Regular Expressions return always LAST match and Python re.findall reutrns what it is said to be: the list of groups. And since I repeat a captured group, I get only the last match. More here for example here: http://www.regular-expressions.info/captureall.html I was learning regexp yesterday, and first I reported this without knowing everytnig about capturing groups. If returning the last match for repeting a capturing group is defined within RegEx itself, than there is no need to mention it in Python documentation... -- ___ Python tracker <http://bugs.python.org/issue22353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22353] re.findall() documentation lacks information about finding THE LAST iteration of repeated capturing group (greedy)
Changes by Mateusz Dobrowolny : -- title: re.findall() documentation lacks information about finding THE LAST iteration of reoeated capturing group (greedy) -> re.findall() documentation lacks information about finding THE LAST iteration of repeated capturing group (greedy) ___ Python tracker <http://bugs.python.org/issue22353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22353] re.findall() documentation lacks information about finding THE LAST iteration of reoeated capturing group (greedy)
New submission from Mateusz Dobrowolny:
Python 3.4.1, Windows.
help(re.findall) shows me:
findall(pattern, string, flags=0)
Return a list of all non-overlapping matches in the string.
If one or more capturing groups are present in the pattern, return
a list of groups; this will be a list of tuples if the pattern
has more than one group.
Empty matches are included in the result.
It seems like there is missing information regarding greedy groups, i.e.
(regular_expression)*
Please take a look at my example:
-EXAMPLE-
import re
text = 'To configure your editing environment, use the Editor settings page and
its child pages. There is also a ' \
'Quick Switch Scheme command that lets you change color schemes, themes,
keymaps, etc. with a couple of ' \
'keystrokes.'
print('Text to be searched: \n' + text)
print('\nSarching method: re.findall()')
regexp_result = re.findall(r'\w+(\s+\w+)', text)
print('\nRegexp rule: r\'\w+(\s+\w+)\' \nFound: ' + str(regexp_result))
print('This works as expected: findall() returns a list of groups (\s+\w+), and
the groups are from non-overlapping matches.')
regexp_result = re.findall(r'\w+(\s+\w+)*', text)
print('\nHow about making the group greedy? Here we go: \nRegexp rule:
r\'\w+(\s+\w+)*\' \nFound: ' + str(regexp_result))
print('This is a little bit unexpected for me: findall() returns THE LAST
MATCHING group only, parsing from-left-to-righ.')
regexp_result_list = re.findall(r'(\w+(\s+\w+)*)', text)
first_group = list(i for i, j in regexp_result_list)
print('\nThe solution is to put an extra group aroung the whole RE: \nRegexp
rule: r\'(\w+(\s+\w+)*)\' \nFound: ' + str(first_group))
print('So finally I can get all strings I am looking for, just like expected
from the FINDALL method, by accessing first elements in tuples.')
--END OF EXAMPLE-
I found the solution when practicing on this page:
http://regex101.com/#python
Entering:
REGULAR EXPRESSION: \w+(\s+\w+)*
TEST STRING: To configure your editing environment, use the Editor settings
page and its child pages. There is also a Quick Switch Scheme command that lets
you change color schemes, themes, keymaps, etc. with a couple of keystrokes.
it showed me on the right side with nice color-coding:
1st Capturing group (\s+\w+)*
Quantifier: Between zero and unlimited times, as many times as possible, giving
back as needed [greedy]
Note: A repeated capturing group will only capture the last iteration. Put a
capturing group around the repeated group to capture all iterations or use a
non-capturing group instead if you're not interested in the data
I think some information regarding repeated groups should be included as well
in Python documentation.
BTW: I have one extra question.
Searching for 'findall' in this tracker I found this issue:
http://bugs.python.org/issue3384
It looks like information about ordering information is no longer in 3.4.1
documentation. Shouldn't this be there?
Kind Regards
--
assignee: docs@python
components: Documentation
messages: 226534
nosy: Mateusz.Dobrowolny, docs@python
priority: normal
severity: normal
status: open
title: re.findall() documentation lacks information about finding THE LAST
iteration of reoeated capturing group (greedy)
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue22353>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment: FYI, I've got it confirmed fix for the bug in VS has been released [1] """ We have fixed this behavior for the next major release, Visual Studio "14." The fix is present in the Visual Studio "14" CTP that was released earlier this month. """ [1] https://connect.microsoft.com/VisualStudio/feedback/details/785119/fileno-stdin-0-for-non-console-application#tabs -- ___ Python tracker <http://bugs.python.org/issue17797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21452] make_buildinfo.exe with VS2013 fails due ill-formed IntDir path
Mateusz Łoskot added the comment: On 9 May 2014 19:21, Tim Golden wrote: > > Fixed. Thanks for the report > Thank you for the fix. -- ___ Python tracker <http://bugs.python.org/issue21452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21452] make_buildinfo.exe with VS2013 fails due ill-formed IntDir path
Mateusz Łoskot added the comment:
On 8 May 2014 11:53, Tim Golden wrote:
>
> What effect does your patch have on a VS2010 build?
I don't know. I don't use VS2010.
However, I suspect the option 1) fix should be applied anyway as it is
suggested by the comment in make_buildinfo.c.
Why the pythoncore.vc[x]proj project files do not use "$(IntDir)\" by
default, no idea.
> Also: does the same problem occur on the development branch?
I haven't tested, I work with released Python sources now.
I noticed though, that this issue is somewhat random.
I'm building from VS2013 command prompt, and I've just successully
built the non-patched make_buildinfo.{c|vcxproj}.
This made me wonder if the problem is related to cmd.exe
configuration, extensions enabled/disabled, and such.
--
nosy: +Mateusz.Łoskot
___
Python tracker
<http://bugs.python.org/issue21452>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21452] make_buildinfo.exe with VS2013 fails due ill-formed IntDir path
New submission from Mateusz Loskot: While building Python 3.2 or Python 3.4 with Visual Studio 2013 on Windows 8.1, pythoncore.vcxproj fails to build due to illformed pre-link event command. (FYI, I have upgraded all .vcxproj files to VS2013 locally.) Here is the command and the error: 1>PreLinkEvent: 1> Description: Generate build information... 1> cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -D_DEBUG -MDd ..\Modules\getbuildinfo.c -Fo"D:\tmp\Python-3.4.0-vs2013\PCbuild\Win32-temp-Debug\pythoncore" \getbuildinfo.o" -I..\Include -I..\PC 1> getbuildinfo.c 1>..\Modules\getbuildinfo.c(1): fatal error C1083: Cannot open include file: 'Python.h': No such file or directory Notice the superfluous double quote followed by whitespace in the following argument: -Fo"D:\tmp\Python-3.4.0-vs2013\PCbuild\Win32-temp-Debug\pythoncore" \getbuildinfo.o" The problem is somewhat known as there is related comment in the make_buildinfo.c file about the custom commands arguments parsing: /* Hack fix for bad command line: If the command is issued like this: * $(SolutionDir)make_buildinfo.exe" Debug "$(IntDir)" * we will get a trailing quote because IntDir ends with a backslash that then * escapes the final ". To simplify the life for developers, catch that problem * here by cutting it off. * The proper command line, btw is: * $(SolutionDir)make_buildinfo.exe" Debug "$(IntDir)\" * Hooray for command line parsing on windows. */ There are two solutions possible: 1) Correct the PreLinkEvent command in make_buildinfo.vcxproj according to the comment above: $(SolutionDir)make_buildinfo.exe" Debug "$(IntDir)\" 2) Patch make_buildinfo.c (attached). Then, the cl.exe command is correct: 1> cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -D_DEBUG -MDd ..\Modules\getbuildinfo.c -Fo"F:\V81-VS2013.win32\Librarie s\External\Source\Python\Debug\PCbuild\Win32-temp-Debug\pythoncore\getbuildinfo.o" -I..\Include -I..\PC 1> getbuildinfo.c I'm not sure why this problems leaks while building with VS2013. I have been building Python 3.2 with VS2012 for long time w/o any issues. Perhaps, it is related to combination of VS2013 and Windows 8.1. Although, I'm not observing this problem while building with VS2012 on Windows 8.1, it would be helpful if someone else who uses VS2012 or VS2013 could confirm my results. -- components: Build files: Python340-make_buildinfo-vs2013.patch keywords: patch messages: 218097 nosy: mloskot priority: normal severity: normal status: open title: make_buildinfo.exe with VS2013 fails due ill-formed IntDir path type: compile error versions: Python 3.2, Python 3.4 Added file: http://bugs.python.org/file35183/Python340-make_buildinfo-vs2013.patch ___ Python tracker <http://bugs.python.org/issue21452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment:
I have just tested Windows GUI application built against Python 3.2.1 with
is_valid_fd patch according to http://hg.python.org/cpython/rev/f15943505db0/
All built using VS2012.
Again, I can confirm that is_valid_fd does NOT solve the problem.
Here is extract of execution flow in initstdio function:
1. fd = 0, despite it is GUI app, see
https://connect.microsoft.com/VisualStudio/feedback/details/785119/
fd = fileno(stdin);
2. is_valid_fd will return __true__, so it moves to calling create_stdio()
if (!is_valid_fd(fd)) {
...
}
else {
std = create_stdio(iomod, fd, 0, "", encoding, errors);
if (std == NULL)
goto error;
}
3. The create_stdio() call fails though, causing error followed by abort
Still, the only solution that solves this problem in Windows GUI applications
buitl using VS2012 is to use check_fd() function to check fd, instead of
is_valid_fd(). The check_fd() is more reliable as it will return -1 due to
errno == EBADF.
My previous attempt to analyse _PyVerify_fd() is not relevant for the problem,
let's forget it.
--
___
Python tracker
<http://bugs.python.org/issue17797>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment:
On 12 September 2013 00:06, Antoine Pitrou wrote:
>> Shortly, is_valid_fd always returns true because fd < 0 is always
>> false as my tests with Visual Studio 2012
>
> Well, that's not all there is, is_valid_fd() does other checks before
> returning true.
Given the function:
is_valid_fd(int fd)
{
int dummy_fd;
if (fd < 0 || !_PyVerify_fd(fd))
return 0;
dummy_fd = dup(fd);
if (dummy_fd < 0)
return 0;
close(dummy_fd);
return 1;
}
for fd values of 0, 1 or 2
1. fd < 0 is always false
2. _PyVerify_fd(fd) is always true. Given the current definition:
#define _PyVerify_fd(fd) (_get_osfhandle(fd) >= 0)
for those values of fd _get_osfhandle(fd) >= 0, always.
3. for those fd values, dup() never returns fd < 0
--
___
Python tracker
<http://bugs.python.org/issue17797>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment: On 11 September 2013 12:34, Antoine Pitrou wrote: >> I'm not sure which minor version of Python 3.2 it was, but in my >> comment in msg187362, I confirmed that I have tested the later >> version with added is_valid_fd function. As far as I understand, the >> changes in http://hg.python.org/cpython/rev/f15943505db0/ introduce >> that is_valid_fd function, which does not seem to solve the problem. > > Could you try to investigate this a bit further? Does is_valid_fd() > return true, and why? I have already checked that (see msg187362) Shortly, is_valid_fd always returns true because fd < 0 is always false as my tests with Visual Studio 2012 (Visual C++ 11.0 (1700) confirmed (see also bug report linked in msg188117) assert(fdi == 0); assert(fdo == 1); assert(fde == 2); IOW, fd is always larger than 0. -- ___ Python tracker <http://bugs.python.org/issue17797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment: @Antoine (Re msg197480) I'm not sure which minor version of Python 3.2 it was, but in my comment in msg187362, I confirmed that I have tested the later version with added is_valid_fd function. As far as I understand, the changes in http://hg.python.org/cpython/rev/f15943505db0/ introduce that is_valid_fd function, which does not seem to solve the problem. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue17797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17128] OS X system openssl deprecated - installer should build local libssl
Mateusz Lenik added the comment: I finally managed to find some time to clean up the script I used to compile multiarch openssl. The diff is available at https://bitbucket.org/_mlen/cpython/commits/319f10362eb4b947b12750a6eb66fb622bbb0079 For 10.8 I had to comment out Tk related part and use the command below to build: ./build-installer.py --sdk-path=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/ --third-party=/Users/m/Documents/Code/sources --universal-archs=intel --dep-target=10.8 The test results are below: test-osx ➤ arch -i386 python3 -m test -unetwork test_ssl [1/1] test_ssl Resource 'ipv6.google.com' is not available 1 test OK. test-osx ➤ arch -x86_64 python3 -m test -unetwork test_ssl [1/1] test_ssl Resource 'ipv6.google.com' is not available 1 test OK. -- hgrepos: +204 ___ Python tracker <http://bugs.python.org/issue17128> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17128] OS X system openssl deprecated - installer should build local libssl
Mateusz Lenik added the comment: The other way to solve problem with CA certs may be this script[1] that can be used to generate pem files from mozilla CA cert bundle[2] during compilation or installation. [1]: http://curl.haxx.se/docs/caextract.html [2]: http://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt -- ___ Python tracker <http://bugs.python.org/issue17128> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment: This is still an issue in VS 2012 Version 11.0.60610.01 Update 3 -- ___ Python tracker <http://bugs.python.org/issue17797> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17128] OS X system openssl deprecated - installer should build local libssl
Mateusz Lenik added the comment: I managed to build Python with OpenSSL 1.0.1e on Mac OS 10.8.4 using build-installer.py script during Europython sprint. I'll attach patches in few days, as I'll try to clean the code a bit. Currently the build works only for intel. Here is an example output: test-osx ~ ➤ uname -a Darwin test-osx.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64 test-osx ~ ➤ arch -i386 python3 Python 3.4.0a0 (default, Jul 7 2013, 17:12:34) [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.maxsize 2147483647 >>> import ssl >>> ssl.OPENSSL_VERSION 'OpenSSL 1.0.1e 11 Feb 2013' >>> ^D test-osx ~ ➤ arch -x86_64 python3 Python 3.4.0a0 (default, Jul 7 2013, 17:12:35) [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.maxsize 9223372036854775807 >>> import ssl >>> ssl.OPENSSL_VERSION 'OpenSSL 1.0.1e 11 Feb 2013' >>> ^D test-osx ~ ➤ -- nosy: +mlen ___ Python tracker <http://bugs.python.org/issue17128> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17557] test_getgroups of test_posix can fail on OS X 10.8 if more than 16 groups
Mateusz Lenik added the comment: I signed it today. -- ___ Python tracker <http://bugs.python.org/issue17557> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17557] test_getgroups of test_posix can fail on OS X 10.8 if more than 16 groups
Mateusz Lenik added the comment: I attached a patch implementing a workaround for getgroups(2) call. When compiled for OS X it first calls getgroups with 0 as the first argument to get number of groups and then in subsequent call the code fetches the gids. This patch applies cleanly on 2.7 and 3.x branches. -- keywords: +patch nosy: +mlen Added file: http://bugs.python.org/file30816/getgroups_osx.patch ___ Python tracker <http://bugs.python.org/issue17557> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment: I've just got an update on the bug report [1] I submitted to Microsoft. The Visual C++ team confirmed "It does appear to be a regression from Visual Studio 2010." So, it's not a bug in Python, but I think it may be important for Python to consider applying some reliable workaround (i.e. use of check_fd() function) [1] http://connect.microsoft.com/VisualStudio/feedback/details/785119/ -- ___ Python tracker <http://bugs.python.org/issue17797> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment: Replacing if the current test in Python 3.2 if (fd < 0) with if (check_fd(fd) < 0) Seems to be a working solution. I just noticed, that in current Python/pythonrun.c in the repo, there the fd < 0 tests have been replaced with new function is_valid_fd(). But, its semantic is equivalent to fd < 0, so it does not check anything really. Perhaps is_valid_fd could be redefined as check_fd. Here are Visual C++ 11.0 (1700) vs 10.0 differences of fileno return value for all the standard streams int fdi, fdo, fde; fdi = fileno(stdin); fdo = fileno(stdout); fde = fileno(stderr); #if _MSC_VER < 1700 assert(fdi == -2); assert(fdo == -2); assert(fde == -2); #else assert(fdi == 0); assert(fdo == 1); assert(fde == 2); #endif By the way, I assume such sudden change in fileno(std*) behaviour between Visual C++ versions is suspicious, so I also submitted bug report to Visual Studio: https://connect.microsoft.com/VisualStudio/feedback/details/785119/ -- ___ Python tracker <http://bugs.python.org/issue17797> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment: > In file Modulfileio.c, I messed the path and filename above I meant: In file Modules/_io/fileio.c, -- ___ Python tracker <http://bugs.python.org/issue17797> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment:
Yes, it does. In file Modulfileio.c, in function fileio_init, there is this
code:
if (fd >= 0) {
if (check_fd(fd))
goto error;
self->fd = fd;
self->closefd = closefd;
}
The check_fd tests:
if (!_PyVerify_fd(fd) || (fstat(fd, &buf) < 0 && errno == EBADF)) {
The _PyVerify_fd(fd) == 1, but errno is "Bad file descriptor".
This eventually leads to Py_InitializeEx failure at:
if (initstdio() < 0)
Py_FatalError(
"Py_Initialize: can't initialize sys standard streams");
--
___
Python tracker
<http://bugs.python.org/issue17797>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
New submission from Mateusz Loskot:
In pythonrun.c, there is function initstdio() with the following test:
static int
initstdio(void)
{
...
/* Set sys.stdin */
fd = fileno(stdin);
/* Under some conditions stdin, stdout and stderr may not be connected
* and fileno() may point to an invalid file descriptor. For example
* GUI apps don't have valid standard streams by default.
*/
if (fd < 0) {
#ifdef MS_WINDOWS
std = Py_None;
Py_INCREF(std);
#else
goto error;
#endif
}
else {
...
}
This function is fails for non-console applications (i.e. MFC) built using
Visual C++ 11.0 (Visual Studio 2012), becasue **strangely**, fileno(stdin) ==
0, so this test results in false and Python initialisation routines attempt to
setup streams.
Apparently, fileno(stdin) return value has changed between Visual C++ 10.0 (VS
2010)
and 11.0. The VC++ 10.0 reports fileno(stdin) == -2.
--
components: IO, Interpreter Core
messages: 187351
nosy: mloskot
priority: normal
severity: normal
status: open
title: Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue17797>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4442] document immutable type subclassing via __new__
Mateusz Loskot added the comment: Chris Withers' note clarifies it to me, that this should be Python-level rather than C-level documentation. Then the note under __new__() in 3. Data model seems right. Simply, I expected to have some notes in C API too Side note: as mainly Python C API user, I expected to have it documented at C API level too. -- ___ Python tracker <http://bugs.python.org/issue4442> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue621526] docs do not include spec info from PEPs
Mateusz Loskot added the comment: I reported issue 15029 [1] which may be related to this one. [1] http://bugs.python.org/issue15029 -- nosy: +mloskot ___ Python tracker <http://bugs.python.org/issue621526> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15029] Update Defining New Types chapter according to PEP 253
Mateusz Loskot added the comment: Similar request has been rejected in response to the Issue 621526 [1], but I'm not proposing to include PEP into docs, but to update and improve docs with material discussed in accepted PEPs. [1] http://bugs.python.org/issue621526 -- ___ Python tracker <http://bugs.python.org/issue15029> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15029] Update Defining New Types chapter according to PEP 253
New submission from Mateusz Loskot : The chapter '2. Defining New Types" in the Python 3.2 documentation [1] does not cover all important elements, especially in the subsection 2.1.4. Subclassing other types. The accepted PEP 253 [2] provides much more detailed and thorough explanation for Python C API users willing to define and subclass new types, than the official manual. I'd like to suggest update of the manual with information enclosed in the PEP 253. In fact, the PEP's sections like * Preparing a type for subtyping * Creating a subtype of a built-in type in C could be copied with little editing, IMHO. The PEP 253 really seems to be a must-read document for Python C API users. [1] http://docs.python.org/release/3.2.2/extending/newtypes.html [2] http://www.python.org/dev/peps/pep-0253/ -- assignee: docs@python components: Documentation messages: 162480 nosy: docs@python, mloskot priority: normal severity: normal status: open title: Update Defining New Types chapter according to PEP 253 type: enhancement versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue15029> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4442] document immutable type subclassing via __new__
Mateusz Loskot added the comment: Is this report about documenting of the concept of immutable types in Python in general or regarding existing built-in types, like datetime.datetime? Generally, the concept of immutable type with relation to tp_new is mentioned (sneaked) here: 1) http://docs.python.org/release/3.2.2/c-api/typeobj.html "A good rule of thumb is that for immutable types, all initialization should take place in tp_new, while for mutable types, most initialization should be deferred to tp_init." 2) http://www.python.org/dev/peps/pep-0253/ Note that for immutable object types, the initialization cannot be done by the tp_init() slot: this would provide the Python user with a way to change the initialization. Therefore, immutable objects typically have an empty tp_init() implementation and do all their initialization in their tp_new() slot. IMHO, it deserves a dedicated section/chapter in the docs. -- ___ Python tracker <http://bugs.python.org/issue4442> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4442] document immutable type subclassing via __new__
Changes by Mateusz Loskot : -- nosy: +mloskot ___ Python tracker <http://bugs.python.org/issue4442> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
