Maciek Fijalkowski fi...@genesilico.pl added the comment:
I cannot honestly make much sense from what you said. My concern is whether
python and C version behaves the same or not. It seems that in current version
they intentionally behave differently, for simplicity and it's against policy
Maciek Fijalkowski fi...@genesilico.pl added the comment:
Hello.
I would like to complain. It was decided at some point some time ago that both
pure-python and C version should run against the same test suite and should not
have any differencies. The reasoning behind it is that other python
New submission from Maciek Fijalkowski fi...@genesilico.pl:
In ceval.c there is such code:
PyObject *
PyEval_CallObject(PyObject *func, PyObject *arg)
{
return PyEval_CallObjectWithKeywords(func, arg, (PyObject *)NULL);
}
#define PyEval_CallObject(func,arg
Maciek Fijalkowski fi...@genesilico.pl added the comment:
The bug with this is that setuptools uses it (and even relies on what is
there and in what order), while it has no single tests and no documentation.
--
___
Python tracker rep
Maciek Fijalkowski fi...@genesilico.pl added the comment:
it == _zip_directory_cache
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2953
Maciek Fijalkowski fi...@genesilico.pl added the comment:
setuptools at least deletes stuff from _zip_directory_cache (via _uncache
function in easy_install.py). it also iterates over it and checks for
existance of elements.
What about documenting details about _zip_directory_cache:
* does
Maciek Fijalkowski fi...@genesilico.pl added the comment:
Seems I meant setuptools indeed. Note that brett's importlib contains
some tests for _zip_directory_cache.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2953
New submission from Maciek Fijalkowski fi...@genesilico.pl:
A patch and a test. The problem is a bit broader - what about import * etc?
Patch fixes that, but without a test.
--
components: Interpreter Core
files: out.diff
keywords: patch
messages: 84259
nosy: fijal
severity: normal
New submission from Maciek Fijalkowski fi...@genesilico.pl:
I have troubles actually finding such a file, but I encountered it at
least once (file is gone by now though). The lines in question are for
bz2 compression:
in _BZ2Proxy.read:
try:
raw = self.fileobj.read
New submission from Maciek Fijalkowski fi...@genesilico.pl:
the reason is that it of course raises TypeError, since number of args
is wrong.
--
files: out.diff
keywords: patch
messages: 80121
nosy: fijal
severity: normal
status: open
title
New submission from Maciek Fijalkowski fi...@genesilico.pl:
this is at least a bad practice. It also might break silently at any point.
--
components: Library (Lib), Tests
files: out.diff
keywords: patch
messages: 79846
nosy: fijal
severity: normal
status: open
title: Lib/test
New submission from Maciek Fijalkowski [EMAIL PROTECTED]:
Although it doesn't start with _ and is definitely necessary as codecs
call it.
--
components: Library (Lib)
messages: 73569
nosy: fijal
severity: normal
status: open
title: codecs.charmap_build is untested and undocumented
type
Maciek Fijalkowski [EMAIL PROTECTED] added the comment:
Next wave of tests - error handling. More specifically all errors that
might happen during parsing XML and reported by parser itself.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2982
Maciek Fijalkowski [EMAIL PROTECTED] added the comment:
On the one hand, no it does not hurt when we're resetting errno before
any call. On the other hand if we try hard to be like C, it's a bit
strange that we always reset errno (which is on the other hand very good
practice anyway).
IMO it's
New submission from Maciek Fijalkowski [EMAIL PROTECTED]:
_zip_directory_cache has no single test nor piece of documentation. The
only place where it's mentioned is a call to method .clear() on it in
tests. Besides, it can be whatever. Despite _ prefix, which I would
consider to be private
Maciek Fijalkowski [EMAIL PROTECTED] added the comment:
thread local storage sounds also a bit weird to me. Errcheck sounds way
better, I would also like to have errcheck as a possible default on
library, when calling CDLL constructor. This would be a convinient way
of specifying errno handling
New submission from Maciek Fijalkowski [EMAIL PROTECTED]:
Infinite recursion problem. I know this file is obscure, but it's still
pretty valid python.
--
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: ssl.py
messages: 64829
nosy: collinwinter, fijal
severity
Maciek Fijalkowski added the comment:
There is another untested and undocumented attribute called prefix on
zipimporter objects.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1326
Maciek Fijalkowski added the comment:
Attached file that handles stack overflow slightly better (from pypy).
It really measures stack size, not some arbitrary limit of python calls.
Yes, this have slightly bigger overhead than just passing around number,
but as a side effect solves Lib/test
Maciek Fijalkowski added the comment:
Wuaaa, sorry
Added file: http://bugs.python.org/file9259/stack.h
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1881
__
___
Python-bugs
Maciek Fijalkowski added the comment:
PyPy is all MIT, no problem at license. This should not be plugged into
the parser, this is not a patch (especially not a patch for the parser).
This file is rather to illustrate possible solution to solve the problem
of sys.setrecursionlimit not being
Changes by Maciek Fijalkowski:
--
nosy: +cfbolz, fijal
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1875
__
___
Python-bugs-list mailing list
Unsubscribe:
http
New submission from Maciek Fijalkowski:
Code in example abuses the fact that _as_parameter_ is passed
recursively. Not sure if this is for fixing or not.
--
components: Extension Modules
files: crash.py
messages: 59993
nosy: arigo, fijal
severity: normal
status: open
title: Ctypes C
23 matches
Mail list logo