[issue1116] reference in extending doc to non-existing file
New submission from Anthon van der Neut: The extending Python doc for 2.5 (and 2.6) is still referring to Python/pythonmain.c to look up how to call the Python parser with a string. However the code (for the -c commandline option) is now in Modules/main.c See attached diff.txt fixes Doc/extending/extending.rst (it is probably quiker to make the change by hand than to check the diff). -- components: Documentation files: diff.txt messages: 55682 nosy: anthon severity: minor status: open title: reference in extending doc to non-existing file versions: Python 2.5, Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1116> __--- Doc/extending/extending.rst?rev=57065 2007-09-06 10:46:11.0 +0200 +++ Doc/extending/extending.rst 2007-09-06 10:48:02.0 +0200 @@ -423,7 +423,7 @@ standard interface to call a Python function. (I won't dwell on how to call the Python parser with a particular string as input --- if you're interested, have a look at the implementation of the :option:`-c` command line option in -:file:`Python/pythonmain.c` from the Python source code.) +:file:`Modules/main.c` from the Python source code.) Calling a Python function is easy. First, the Python program must somehow pass you the Python function object. You should provide a function (or some other ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1238] dictobject and dictentry not used consistently in dictobject.c
New submission from Anthon van der Neut:
In dictobject.c the structures from dictobject.h are typedeffed to:
typedef PyDictEntry dictentry;
typedef PyDictObject dictobject;
However there are still a few locations in that file where the
PyDictEntry and PyDictObject types are used directly. IMHO these should
be replaced by dictentry resp. dictobject
Attached is a patch for that.
--
components: Interpreter Core
files: dictobject.c.patch
messages: 56234
nosy: anthon
severity: minor
status: open
title: dictobject and dictentry not used consistently in dictobject.c
versions: Python 2.5, Python 2.6
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1238>
__--- ../dictobject.c 2007-10-02 16:06:08.0 +0200
+++ ./dictobject.c 2007-10-05 09:19:33.0 +0200
@@ -168,7 +168,7 @@
There are two ways to create a dict: PyDict_New() is the main C API
function, and the tp_new slot maps to dict_new(). In the latter case we
can save a little time over what PyDict_New does because it's guaranteed
- that the PyDictObject struct is already zeroed out.
+ that the dictobject struct is already zeroed out.
Everyone except dict_new() should use EMPTY_TO_MINSIZE (unless they have
an excellent reason not to).
*/
@@ -186,7 +186,7 @@
/* Dictionary reuse scheme to save calls to malloc, free, and memset */
#define MAXFREEDICTS 80
-static PyDictObject *free_dicts[MAXFREEDICTS];
+static dictobject *free_dicts[MAXFREEDICTS];
static int num_free_dicts = 0;
PyObject *
@@ -397,7 +397,7 @@
{
PyObject *old_value;
register dictentry *ep;
- typedef PyDictEntry *(*lookupfunc)(PyDictObject *, PyObject *, long);
+ typedef dictentry *(*lookupfunc)(dictobject *, PyObject *, long);
assert(mp->ma_lookup != NULL);
ep = mp->ma_lookup(mp, key, hash);
@@ -1338,7 +1338,7 @@
int
PyDict_Merge(PyObject *a, PyObject *b, int override)
{
- register PyDictObject *mp, *other;
+ register dictobject *mp, *other;
register Py_ssize_t i;
dictentry *entry;
@@ -2066,7 +2066,7 @@
assert(type != NULL && type->tp_alloc != NULL);
self = type->tp_alloc(type, 0);
if (self != NULL) {
- PyDictObject *d = (PyDictObject *)self;
+ dictobject *d = (dictobject *)self;
/* It's guaranteed that tp->alloc zeroed out the struct. */
assert(d->ma_table == NULL && d->ma_fill == 0 && d->ma_used == 0);
INIT_NONZERO_DICT_SLOTS(d);
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1238] dictobject and dictentry not used consistently in dictobject.c
Anthon van der Neut added the comment:
Guido's suggestion to change all entries to PyDictEntry resp.
PyDictObject would work as well and declutter the code in a better way.
The only advantage of the typedefs that I see (and briefly used) it that
it is easy to have structures local to dictobject.c that hold some more
information, without having to touch dictobject.h (and trigger a more
general recompile. For the few that need that, they can globaly replace
PyDict{Entry,Object} when they do.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1238>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3531] file read preallocs 'size' bytes which can cause memory problems
Anthon van der Neut <[EMAIL PROTECTED]> added the comment: FWIW: I have performance problems on Windows XP (SP2) with Python 2.5.1 that could be caused by this behaviour. My code regularily calculates the sha1 sum of 10.000 files and because in another reuse of the code had to deal with files too big to fit in memory I set a limit of 256Mb. It looks like that is now allocated and deallocated for every one of the 10.000 files, making things *very* slow. -- nosy: +anthon ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3531> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8466] typo in tp_name of cStringIO
New submission from Anthon van der Neut : if you execute the following code from cStringIO import StringIO x = StringIO() x.get_value() you will see that the AttributeError line has a typo it displays 'cStringIO.StringO' instead of 'cStringIO.StringIO' this error is in line 529 of the Modules/cStringIO.c code (of 2.7b1) -- components: Library (Lib) messages: 103687 nosy: anthon severity: normal status: open title: typo in tp_name of cStringIO type: behavior versions: Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue8466> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40119] ensurepip should use ifferent pattern for pip/setuptool wheel files
New submission from Anthon van der Neut : Setuptools, starting with minor version 45.1.0 no longer is a -py2.py3-none-any.whl file, but a -py3-none-any.whl file. In ensurepip's __init__.py the former is hard-coded, so the setuptools shipping with python (for 3.9.0a5 this is 41.2.0) cannot be upgraded beyond 45.0.0 I can provide a PR that fixes this, (either by using glob.glob() to find the exact .whl available. or by extending the tuple in _PROJECTS.) -- messages: 365344 nosy: anthon priority: normal severity: normal status: open title: ensurepip should use ifferent pattern for pip/setuptool wheel files type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40119] ensurepip should use different pattern for pip/setuptool wheel files
Change by Anthon van der Neut : -- title: ensurepip should use ifferent pattern for pip/setuptool wheel files -> ensurepip should use different pattern for pip/setuptool wheel files ___ Python tracker <https://bugs.python.org/issue40119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25034] string.Formatter accepts empty fields but displays wrong when nested
New submission from Anthon van der Neut:
Since 3.4.1, string.Formatter() accepts empty keys {}. If these are nested they
give different results from explicitly numbered, where the same arguments
applied "".format() give the expected results:
from string import Formatter
f = Formatter()
fmt0 = "X {:<{}} {} X"
fmt1 = "X {0:<{1}} {2} X"
for fmt in [fmt0, fmt1]:
x = f.format(fmt, 'ab', 5, 1)
y = fmt.format( 'ab', 5, 1)
print(x)
print(y)
gives:
X ab5 X
X ab1 X
X ab1 X
X ab1 X
of which the first line is incorrect.
--
components: Library (Lib)
messages: 250253
nosy: anthon
priority: normal
severity: normal
status: open
title: string.Formatter accepts empty fields but displays wrong when nested
type: behavior
versions: Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue25034>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25034] string.Formatter accepts empty fields but displays wrong when nested
Anthon van der Neut added the comment:
Here is a patch for Python-3.5.0rc3/Lib/test/test_string.py unittests fail:
--- /opt/python/3.5/lib/python3.5/test/test_string.py 2015-09-08
17:06:07.099197904 +0200
+++ test_string.py 2015-09-08 21:47:01.471634309 +0200
@@ -58,6 +58,8 @@
'foo{1}{num}{1}'.format(None, 'bar', num=6))
self.assertEqual(fmt.format('{:^{}}', 'bar', 6),
'{:^{}}'.format('bar', 6))
+self.assertEqual(fmt.format('{:^{}} {}', 'bar', 6, 'X'),
+ '{:^{}} {}'.format('bar', 6, 'X'))
self.assertEqual(fmt.format('{:^{pad}}{}', 'foo', 'bar', pad=6),
'{:^{pad}}{}'.format('foo', 'bar', pad=6))
--
___
Python tracker
<http://bugs.python.org/issue25034>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25034] string.Formatter accepts empty fields but displays wrong when nested
Anthon van der Neut added the comment:
The problem lies in the recursive call to _vformat which might consume fields
without name ({}) and increment auto_arg_index, but that
incremented value was not returned to the parent.
Since the line became longer than pep8 allowed I wrapped all of the method call
arguments to the next line, hope that that's ok.
The patch is against the mercurial repository and works for 3.4.1 upwards.
--
keywords: +patch
Added file: http://bugs.python.org/file40419/25034.patch
___
Python tracker
<http://bugs.python.org/issue25034>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
