[issue47063] SimpleHTTPRequestHandler has hard coded index page list.
Myron Walker added the comment: I am adding a Github PR for this issue. -- ___ Python tracker <https://bugs.python.org/issue47063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47063] SimpleHTTPRequestHandler has hard coded index page list.
New submission from Myron Walker : SimpleHTTPRequestHandler has hard coded index page list in the send_head method. The fixed hard-coded list means that if you want to have a custom index page that is not named "index.htm" or "index.html" then you have to override the send_head method. There is alot of code in send_head so overriding it is not optimal just to have a custom indexer filename. -- components: Library (Lib) messages: 415534 nosy: Myron Walker priority: normal severity: normal status: open title: SimpleHTTPRequestHandler has hard coded index page list. type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue47063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40104] ElementTree does not find elements in a default namespace with namespaces
Myron Walker added the comment: Looks like this is fixed in the latest source code. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40104] ElementTree does not find elements in a default namespace with namespaces
New submission from Myron Walker :
When you have an xml document like the one with a default namespace below.
When you try to lookup nodes in the document they are not found.
```
docTree.find("specVersion")
None
```
If you add a namespaces map with the '' key and the default namespaces like:
{ '': 'urn:schemas-upnp-org:device-1-0' }
then the nodes are still not found. The issue is that there is a case
missing from xpath_tokenizer that does not yield a pair with the default
namespace when one is specified. Here is a fix.
https://github.com/myronww/cpython/commit/0fc65daca239624139f2a018a83f0b0ec04a8068
```
from xml.etree.ElementTree import fromstring as parse_xml_fromstring
from xml.etree.ElementTree import ElementTree
SAMPLEXML = """
10
urn:schemas-wifialliance-org:device:WFADevice:1
R7400 (Wireless AP)
rootNode = parse_xml_fromstring(SAMPLEXML)
# Create a namespaces map like { '': 'urn:schemas-upnp-org:device-1-0' }
defaultns = {"": docNode.tag.split("}")[0][1:]}
specVerNode = docNode.find("specVersion", namespaces=defaultns)
```
Results should look like this
```
docNode.find("specVersion", namespaces=defaultns)
```
------
components: Library (Lib)
messages: 365273
nosy: Myron Walker
priority: normal
severity: normal
status: open
title: ElementTree does not find elements in a default namespace with namespaces
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue40104>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25885] ast Str type does not annotate the string type when it parses a python document
New submission from Myron Walker: The 'ast' module does not indicate the type of string, ''' or '"' or '"""', that it has encountered when it parses a python document. This prevents accurate reproduction of the original parsed document by a writer walking over an instance of a abstract syntax tree. -- components: Extension Modules messages: 256529 nosy: Myron Walker priority: normal severity: normal status: open title: ast Str type does not annotate the string type when it parses a python document type: behavior versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25885> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25886] ast module is combining string literals that are concatenated with plus operator
Myron Walker added the comment: My thought on this is that a syntax tree needs to accurately represent parsed syntax of the code. Two strings being concatenated contain syntax information that is different from a single string. "Hello" + " World" Is not the same syntax as: "Hello World" To lose that syntax information seems to defeat the intent of abstract syntax tree which is to store the syntax associated with a document. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25886> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25885] ast Str type does not annotate the string type when it parses a python document
Myron Walker added the comment: I am re-opening this as I believe this is an important issue for work I would like to eventually push into the python core which is python code that recode themselves as declarations or as instance representation. "I don't see any benefit in supporting this even if we gain comment nodes in the AST." There would be a huge benefit to having accurate original syntax information of the document and being able to re-write the documents as it would enable self modifying code or software written code paradigms. TestCases that can update themselves in various modes, full auto, interactive, etc. TestData Pattern Generation object or Data Pattern Generation object that can be easily or efficiently modified and then asked to write themselves back out to files. The fact that there are other projects being worked on to provide round trip document to syntax tree and syntax tree to document transformations also indicates that the lack of accurate syntax storage in 'ast' is a problem that needs to be addressed. I would prefer to work with the core python modules in order to provide dynamic code modification functionality rather than relying on a third party module as eventually I would like to push this into core python. If a python object has script behind it, I would like to eventually be able to tell a the object to write itself to a file as a object declaration or as a object instance. As Declaration: class SomeObject(SomeBase): def some method(self): print "blah blah" As Instance: SomeObject() -- status: closed -> open ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25885> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25886] ast module is combining string literals that are concatenated with plus operator
New submission from Myron Walker: ast module is combining string literals that are concatenated with plus operator into a single string in the parsestrplus module rather than maintaining the true syntax tree of the original document. The fact that ast combines strings and does not maintain the original syntax of the document means that original syntax information is lost and a writer walking the abstract syntax tree is unable to reproduce the original syntax of the document. -- components: Interpreter Core messages: 256533 nosy: Myron Walker priority: normal severity: normal status: open title: ast module is combining string literals that are concatenated with plus operator versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25886> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25885] ast Str type does not annotate the string type when it parses a python document
Myron Walker added the comment: The purpose of a syntax tree is to represent the syntax and not a final processed result of processing of syntax. The current information stored for strings is losing syntax information which seems to defeat the purpose of offering the information in a syntax tree. I filed a separate bug because it is also combining strings and losing operators for string literals. "Hello" + " World" >From the looks of the code, the above would result in one string type with >"Hello World" and syntax information associated with the operator would be >lost. And as indicated, string type information is being lost as well. The user of the AST then has no way of getting the lost syntax information back once it is lost. -- components: +Interpreter Core -Extension Modules, Library (Lib) ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25885> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25885] ast Str type does not annotate the string type when it parses a python document
Myron Walker added the comment: Would it be prudent to add a Parse flag to the AST module that could provide one of two types of AST's an optimized AST or a complete AST -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25885> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25716] typeobject.c call_method & call_maybe can leak references on 'func'
Myron Walker added the comment: Found this with code inspection -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25716] typeobject.c call_method & call_maybe can leak references on 'func'
Myron Walker added the comment:
I think this usage of 'call_method' from typeobject.c would cause it to leak.
static PyObject*
slot_sq_slice(PyObject *self, Py_ssize_t i, Py_ssize_t j)
{
static PyObject *getslice_str;
if (PyErr_WarnPy3k("in 3.x, __getslice__ has been removed; "
"use __getitem__", 1) < 0)
return NULL;
return call_method(self, "__getslice__", _str,
"nn", i, j); <<<<<<< Maybe Bad Format Str <<<<<<<
}
Looks like the only place in 'call_method' that could cause args to be NULL is
if 'Py_VaBuildValue' which calls 'va_build_value' returns NULL.
'va_build_value' calls 'countformat' on the format string and 'countformat'
looks for some escaping in the format string. If no special format characters
like '(' or '{' are not found, then the count might be incremented but when the
NULL terminator on the end of the string is hit, the 'countformat' will return
-1.
So I believe this method has a bug because it doesn't look to be using the
formatter correctly and also it looks like it might cause a leak.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25716>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25716] typeobject.c call_method & call_maybe can leak references on 'func'
Myron Walker added the comment: I'll file a seperate bug on 'countformat' -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25817] modsupport: 'countformat' does not handle strings without bracket levels correctly
New submission from Myron Walker:
'countformat' does not appear to be handling the case where a format string is
passed with no parenthesis or brackets correctly. Here is an
example of a usage that might cause issues from typedobject.c:
static PyObject*
slot_sq_slice(PyObject *self, Py_ssize_t i, Py_ssize_t j)
{
static PyObject *getslice_str;
if (PyErr_WarnPy3k("in 3.x, __getslice__ has been removed; "
"use __getitem__", 1) < 0)
return NULL;
return call_method(self, "__getslice__", _str,
"nn", i, j); <<<<<<< Maybe Bad Format Str <<<<<<<
}
The format string "nn" does not have any level markers so when it gets
processed by 'countformat' the count will be incremented 2 times by the
'default' case but when the end of the string is reached and the NULL character
is processed bay "case '\0':". The function will ignore the count variable and
just return -1 anyway. The error created is unmatched paren in format but
'level' is never checked to see if a paren
was even hit to begin with.
It might be that the case should be changed to look at level before assuming a
error condition if strings are supposed to be processed as the one in the
example above. case '\0' should probably be doing something like:
case '\0':
if (level > 0) { // Check If Level Was Incremented
/* Premature end */
PyErr_SetString(PyExc_SystemError,
"unmatched paren in format");
return -1;
}
break;
--
components: Interpreter Core
messages: 256075
nosy: Myron Walker
priority: normal
severity: normal
status: open
title: modsupport: 'countformat' does not handle strings without bracket levels
correctly
type: behavior
versions: Python 2.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25817>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25817] modsupport: 'countformat' does not handle strings without bracket levels correctly
Myron Walker added the comment: There is not reproducer for this currently. Its a case of implied or shared usage between a function and the code that uses it. This function is only used in the Python core, so unless it is used incorrectly, by a python extension or modification, it may never hit the error condition. The case where this will fail is if for some reason it is called with a 'endchar' other than '\0'. The function assumes end char will be '\0', ')', ']', and ']'. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25817> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25817] modsupport: 'countformat' does not handle strings without bracket levels correctly
Myron Walker added the comment: There are format string like "O&" being passed in to Py_BuildValue which eventually make their way to 'countformat'. It looks like it would just break after the first & and not count anything else. So Im not sure it gives an accurate count. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25817> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25817] modsupport: 'countformat' does not handle strings without bracket levels correctly
Myron Walker added the comment: Yes, there are some other cases that look odd to me as if the code is not up to date though. I was looking at the documentation and it mentions format character combinations like 'es' which contain two characters sequences. When I look at this function, it does not handle two character sequences so the count in some cases may not be correct. Im not familiar with the code enough to know how critical the count might be. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25817> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25716] typeobject.c call_method & call_maybe can leak references on 'func'
New submission from Myron Walker:
The 'call_method' and 'call_maybe' function in typeobject.c are leaking
a reference on 'func' in cases where 'args == NULL'. In this case both
of these functions exit like so:
if (args == NULL)
return NULL;
When they need to do:
if (args == NULL)
{
Py_DECREF(func);
return NULL;
}
--
components: Interpreter Core
messages: 255235
nosy: Myron Walker
priority: normal
severity: normal
status: open
title: typeobject.c call_method & call_maybe can leak references on 'func'
type: resource usage
versions: Python 2.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25716>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25716] typeobject.c call_method & call_maybe can leak references on 'func'
Changes by Myron Walker <myron.wal...@gmail.com>: -- versions: +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/issue25716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
