Antoine Pitrou added the comment:
Why wouldn't you give byte variables in env too?
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue8640>
___
___
Antoine Pitrou added the comment:
Confirmed. It even segfaults under 3.x.
--
nosy: +pitrou
priority: normal -> high
stage: -> patch review
versions: +Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/
Changes by Antoine Pitrou :
--
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue8571>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue8571>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Here is a patch fixing the issue, and a similar one in compressobj.compress().
It also adds tests which are only enabled with the bigmem option.
--
Added file: http://bugs.python.org/file17245/zlibbigbuf.patch
Antoine Pitrou added the comment:
> in the unittests there is some use of 'compress' and 'decompress'
> mixed with 'zlib.decompress'. which one is right
When testing the decompressor, data needs to be prepared first
(compressed). I didn't bother
Antoine Pitrou added the comment:
> Is there a reason to keep inplen and max_length ints instead of making
> them Py_ssize_t too?
zlibmodule.c isn't 64-bit clean internally. Actually, the zlib itself
uses uInt in its z_stream structure. This should be the target of a
separate issue
Antoine Pitrou added the comment:
Patch committed in r80926 (trunk), r80927 (2.6), r80928 (py3k) and r80929
(3.1). Thank you!
--
___
Python tracker
<http://bugs.python.org/issue8
Changes by Antoine Pitrou :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
New submission from Antoine Pitrou :
zlibmodule.c doesn't define PY_SSIZE_T_CLEAN, and uses lots of "int" variables
for length values internally.
Besides, the zlib itself uses "uInt" and "uLong" variables in its z_stream
structure (rather than something guara
Changes by Antoine Pitrou :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue8650>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Antoine Pitrou :
When PY_SSIZE_T isn't defined and a format such as "s#" receives an object
whose length fits in a Py_ssize_t but not in an int, the buffer length is
silently truncated:
>>> s = 'x' * (4 * 1024**3 + 100)
>>> t
Antoine Pitrou added the comment:
A question about the patch: in configure.in, after "if test
$define_xopen_source = yes" (lines 395 and following), there's a bunch of
Solaris-specific stuff. Shouldn't it be removed, given that _XOPEN_SOURCE isn't
defi
Antoine Pitrou added the comment:
You must use either ssl.CERT_OPTIONAL or ssl.CERT_REQUIRED if you want to
retrieve the client certificate. I admit this makes the getpeercert() API a bit
strange, and I'm not sure why the original decision was made.
Can you confirm this fixes your
Antoine Pitrou added the comment:
Are you able to compile a fresh checkout of either the py3k or release3.1-maint
branch? A bunch of fixes have been committed recently, some of which may (or
even should) address your issue.
--
___
Python tracker
Antoine Pitrou added the comment:
> When I use the argument to make certs optional, it gave me an error
> saying it need the ca certs, so I downloaded them and specified to use
> them, and now I am getting errors from ssl.c
You have to specify the CA cert corresponding to the Ce
Antoine Pitrou added the comment:
Thank you!
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue4171>
___
___
Python-bugs-list mai
Antoine Pitrou added the comment:
Ronald, I've reverted the patch since it broke compilation on almost every
buildbot, and we're close to beta2 release.
--
nosy: +benjamin.peterson
stage: committed/rejected -> commit review
___
P
Antoine Pitrou added the comment:
It's not a very useful thing to join a single string, though.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/i
New submission from Antoine Pitrou :
Distutils fails logging characters which are not part of the "default encoding":
http://www.python.org/dev/buildbot/builders/AMD64%20Ubuntu%20wide%203.x/builds/1062/steps/compile/logs/stdio
[...]
File
"/home/buildbot/cpython-ucs4-no
New submission from Antoine Pitrou :
This is probably because you remove the directory while find is walking it:
$ make pycremoval
find . -name '*.py[co]' -exec rm -f {} ';'
find . -name '__pycache__' -exec rmdir {} ';'
find: `./Lib/http/__pycache__&
Antoine Pitrou added the comment:
As I answered on IRC, this is on a buildbot environment. Compiling from the
command line works fine, but not from the buildbot environment.
>From the command line, the locale is as following:
$ locale
LANG=en_GB.UTF-8
LC_CTYPE="en_GB.UTF-8&quo
Antoine Pitrou added the comment:
Ok, this might be more interesting:
$ cat | ./python -i
Python 3.2a0 (py3k:81010, May 8 2010, 23:25:47)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> impor
Antoine Pitrou added the comment:
Anyway, regardless of the actual stdout encoding, distutils should be able to
log messages without crashing, IMO.
--
___
Python tracker
<http://bugs.python.org/issue8
Antoine Pitrou added the comment:
> If the standard output is not a TTY, Python uses ASCII encoding for
> sys.stdout
We could perhaps fix this too, if python-dev agrees.
--
___
Python tracker
<http://bugs.python.org/
Antoine Pitrou added the comment:
> Wasn’t PYTHONIOENCODING added for such cases?
Yes, it was, but it's a very bad workaround. In most if not all cases,
people will set PYTHONIOENCODING to their system's default encoding.
Therefore, they shouldn't have to set an environme
Changes by Antoine Pitrou :
--
___
Python tracker
<http://bugs.python.org/issue8613>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/m
Changes by Antoine Pitrou :
--
components: +Library (Lib) -IO
stage: -> needs patch
versions: +Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/iss
New submission from Antoine Pitrou :
This is a list of extension modules making use of one of the "#" format codes
("s#", "y#", etc.) without defining PY_SSIZE_T_CLEAN, and therefore being
64-bit unclean:
Modules/audioop.c
Modules/_cursesmodule.c
Modules/_eleme
Changes by Antoine Pitrou :
--
dependencies: +audioop module needs an int -> Py_ssize_t upgrade
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
The documentation says that sometimes in the future Py_ssize_t will be the
default, so we may also need some kind of transition period for non-complying
third-party extensions; first with warnings and then with errors perhaps.
--
nosy: +loewis
Antoine Pitrou added the comment:
After a bit of debugging, it seems your data is not actually a complete zlib
stream (*). What did you generate it with?
(*) in technical terms, the zlib never returns Z_STREAM_END when decompressing
your data. The decompressobj ignores it, but the top-level
Antoine Pitrou added the comment:
> Thanks for the debugging. The stream comes from within a matlab 'mat'
> file. I maintain the scipy matlab file readers; the variables within
> these files are zlib compressed streams.
So this would be a Matlab issue, right?
> Is the
New submission from Antoine Pitrou :
This is a patch to use our own error descriptions when the zlib doesn't provide
anything in particular. It would have made issue8672 easier to diagnose for the
reporter (and for us).
--
components: Extension Modules
files: zliberrors.patch
key
Antoine Pitrou added the comment:
I also think we should improve the zlib module's error messages. I've added a
patch in issue8681 for that. With that patch, the message you'd've encountered
would have been "Error -5 while decompressing data: incomplete or truncated
Antoine Pitrou added the comment:
I uploaded the latest patch at http://codereview.appspot.com/1124044
--
___
Python tracker
<http://bugs.python.org/issue8
Antoine Pitrou added the comment:
Ok, it turned out to be quite easy indeed. Here is a patch adding a test.
--
keywords: +patch
Added file: http://bugs.python.org/file17288/zlib-8672.patch
___
Python tracker
<http://bugs.python.org/issue8
Changes by Antoine Pitrou :
--
components: +Tests -Library (Lib)
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue8672>
___
_
New submission from Antoine Pitrou :
PyWeakref_GetObject() returns a borrowed reference, which can therefore become
invalid at any time (especially when the GIL gets released). This provides a
way to crash the interpreter deliberately.
The returned reference should be incref'ed immedi
Antoine Pitrou added the comment:
This must be retargeted to 3.2. Also, the patch lacks some tests.
It seems PEP 8 compliance could be better: function names shouldn't be
CamelCased.
Is LocalSynchronize() an implementation detail rather than a public API? If so,
I think it would be bett
Antoine Pitrou added the comment:
By the way, the patch lacks docs for new public APIs.
--
___
Python tracker
<http://bugs.python.org/issue8684>
___
___
Pytho
Antoine Pitrou added the comment:
> Adding a call:
>
> scheduler = sched.scheduler(time.time, time.sleep)
> scheduler.enter(10, 1, function, (arg,))
>
> ...vs:
>
> asyncore.call_later(10, function, arg)
I don't really see the difference. How hard it is to build
Antoine Pitrou added the comment:
> Still debugging it. In gcmodule.c:collect(..) the value of the
> variable `generation` is 80 - shouldn't it be less than
> NUM_GENERATIONS (3)?
Certainly. Have you tried using different optimization options? Which
compiler
Antoine Pitrou added the comment:
Ok, I'm closing. Thank you for testing Python, anyway!
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python
Antoine Pitrou added the comment:
The patch was committed in r81094 (2.7), r81095 (2.6), r81096 (3.2) and r81097
(3.1). Thank you!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python track
Antoine Pitrou added the comment:
Committed in r81098 (2.7), r81099 (2.6), r81100 (3.2), r81101 (3.1). Thanks!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bug
Antoine Pitrou added the comment:
> 1. In constrained memory environments, creating a temporary internal
> copy of a large set may cause the difference operation to fail that
> would otherwise succeed.
It's a space/time tradeoff. There's nothing wrong about that.
(do no
Changes by Antoine Pitrou :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue6610>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +haypo, lemburg
stage: -> patch review
versions: +Python 3.2 -Python 2.7
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
You know, one benefit of having user-settable sleep() and time() functions is
that you can mock them easily, and therefore check that sched.py really
schedules callables at the right intervals.
--
___
Python
Antoine Pitrou added the comment:
> I agree. Are you recommending to take advantage of this and change the
> tests in some way?
Yes, it would allow you to check that if you have e.g. :
- A scheduled in 1 s
- B scheduled in 3 s
sched.py first sleeps for 1 s, then calls A, then sleeps f
Changes by Antoine Pitrou :
--
nosy: +haypo
versions: +Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue1813>
___
___
Python-bug
Antoine Pitrou added the comment:
Would the test still be correct if it didn't close stderr? I feel closing
stderr is very bad from a debuggability standpoint.
--
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
This looks reasonable. Perhaps you should add a reference to the relevant
OpenBSD bug number(s) or URL(s), if any.
--
nosy: +exarkun, mark.dickinson, pitrou
___
Python tracker
<http://bugs.python.org/issue8
Antoine Pitrou added the comment:
> Is it better to say “for encoding x, use y” or “to encode x,
> use y”?
The latter, IMO. "Encoding" is also a noun.
--
nosy: +pitrou
___
Python tracker
<http://bugs.p
Antoine Pitrou added the comment:
I'm not sure this change is necessary. Why don't you catch StandardError
instead of Exception? StandardError catches all Exception subtypes
except GeneratorExit, StopIteration and the various Warnings.
--
nos
Antoine Pitrou added the comment:
This could probably be solved with an optional argument to getLogger()
and a weakref. Do you want me to write a patch?
--
nosy: +pitrou
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/is
New submission from Antoine Pitrou:
Lib/test.test_logging.py doesn't use unittest. Here is a patch (against
SVN trunk) to fix the problem.
--
components: Tests
files: logtest.patch
messages: 59348
nosy: pitrou
severity: normal
status: open
title: use unittest for test_logging
ver
Antoine Pitrou added the comment:
Ok here is an updated patch with slightly more complete setUp/tearDown
semantics. I don't backup all the objects though since some of them
(e.g. _loggerClass) aren't touched by the tests.
Added file: http://bugs.python.org/file9074/log
Antoine Pitrou added the comment:
Well, I have met this problem too some time ago, so could you please
reopen the bug?
Saying creating a lot of connection-bound logger objects is an
"antipattern" doesn't help. It's the only simple way of doing something
useful: have a
Antoine Pitrou added the comment:
s/in every logging class/in every logging call/, sorry.
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue932563>
___
Pyth
New submission from Antoine Pitrou:
The contextmanager function should call functools.wraps instead of
having its own attribute copying code. Just something I noticed while
reading the source.
--
components: Library (Lib)
messages: 59413
nosy: pitrou
severity: minor
status: open
title
Antoine Pitrou added the comment:
Hi Vinay,
Thanks for your reply.
I think it's important to rephrase the problem in a simple way. The
basic pattern is that there is a class C (say, a TCP connection class)
where a specific part of each log line should from an instance-specific
"
Antoine Pitrou added the comment:
The 2.6 patch should probably use long instead of int.
--
nosy: +pitrou
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
I don't follow comp.lang.python either, so I'd be grateful if you give a
link to the gmane thread ;)
I hope we can find an useful solution to this limitation, logging is a
very important task and the stdlib should satisfy all common
Antoine Pitrou added the comment:
This is my attempt at a patch for this. It fixes inspect.getmembers and
inspect.classify_class_attrs to work with Dieter's example. I hope it
doesn't mess anything else.
As for pydoc, things look a bit more complicated... The annoying thing
is that th
Changes by Antoine Pitrou:
--
versions: +Python 2.6 -Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1785>
__
___
Python-bugs-list
Antoine Pitrou added the comment:
For the record the same problem also happens with toscawidgets.
>>> from toscawidgets.widgets.forms import validators
>>> help(validators)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.
Antoine Pitrou added the comment:
Here is a (hopefully complete) patch against both pydoc and inspect. It
fixes one more bug compared to the previous one (descriptors can also
have a special __getattr__ in addition to __get__, which gave problems
when trying to access __classobj__).
Added file
Antoine Pitrou added the comment:
Just tried on 2.5.1 and on trunk, I can't reproduce it. On both I get:
>>> import locale
>>> locale.setlocale(locale.LC_NUMERIC, "fr_FR.UTF-8")
'fr_FR.UTF-8'
>>> locale.format("%9.2f", 12345.
Antoine Pitrou added the comment:
Unless I'm mistaken, the patch provides only half of the solution: the
stringToLong part, but not longToString.
I agree this feature is interesting, not for optimization but becomes it
avoids using clunky ways (long -> hex -> bin) to implement somet
Antoine Pitrou added the comment:
Here is a patch applicable for SVN trunk.
However, as Bob I have mixed results on this. For example, functions
with variable parameter count have become slower:
# With patch
$ ./python -m timeit -s "def f(*x): pass" 'for x in xrange(1):
New submission from Antoine Pitrou:
This is a patch for SVN trunk which substantially speeds up function
calls with named parameters. It does so by taking into account that
parameter names should be interned, so before doing full compares we do
a first quick loop to compare pointers.
On a
Changes by Antoine Pitrou:
--
type: -> rfe
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1819>
__
___
Python-bugs-list mailing list
Uns
Antoine Pitrou added the comment:
Sorry, my editor indents with spaces by default. Attaching a fixed patch
with tabs.
No, it is independent from #1479611 (and much simpler).
Added file: http://bugs.python.org/file9157/namedparam.patch
__
Tracker <[EM
Antoine Pitrou added the comment:
Another quick test:
# With patch
$ ./python -m timeit -s "d=dict(a=1,b=2,c=3,d=4,e=5);f = lambda
a,b,c,d,e:0" "f(**d)"
100 loops, best of 3: 0.727 usec per loop
$ ./python -m timeit -s "d=dict(b=2,c=3,d=4,e=5);f = lambda a,b,c,d,
Antoine Pitrou added the comment:
Hi,
Sending a 302 in response to a POST is a very common practice so that
the browser is redirected to a "normal", non state-changing page after
the POST request has been processed. It is useful in that it allows the
user to reload the resulting pag
Antoine Pitrou added the comment:
Rather than devising something specific to the co_firstlineno attribute,
why not have functools.update_wrapper add a "wrapped_func" attribute
pointing to the original function object? That way, each function
inspecting the decorated function woul
Antoine Pitrou added the comment:
FWIW, an use case of this I have encountered is to generate a string of
random bytes from the long object returned by random.getrandbits().
--
nosy: +pitrou
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Antoine Pitrou added the comment:
Ok, I manage to reproduce it on an Ubuntu box with both 2.5.2a0 and SVN
trunk.
IMO it's a bug since the expected behaviour would be to enforce the
locale settings for number formatting. That's the whole purpose of
locale.format() after all. (no to m
New submission from Antoine Pitrou:
test_locale uses its own result printout and doesn't throw an exception
when a test fails. It should be probably converted to unittest.
--
components: Library (Lib)
messages: 60085
nosy: pitrou
severity: normal
status: open
title: test_locale do
Changes by Antoine Pitrou:
--
versions: +Python 2.6 -Python 2.4
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1222>
__
___
Python-bugs-list
Antoine Pitrou added the comment:
> A patch is welcome.
I'll try to work on it in a few days.
> Was the test covered by a GHOP task?
Hmm, what is a "GHOP task"?
__
Tracker <[EMAIL PROTECTED]>
<ht
Antoine Pitrou added the comment:
Ok, here is an almost straight conversion of the original test_locale to
unittest.
Added file: http://bugs.python.org/file9202/locale_test.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Antoine Pitrou added the comment:
Eric, your diagnostic looks right, format() gets confused when it tries
to remove padding characters to account for the added thousands
separators. It does not check that there were padding characters in the
first place, and it assumes that the thousands
Antoine Pitrou added the comment:
The second proposal shouldn't be accepted as-is. If you compare two very
long or undecipherable strings, you don't want them to appear in the
failure message.
--
nosy: +pitrou
Tracker <[EMAIL PROT
Antoine Pitrou added the comment:
I'm adding a French translation, and removing the "Application" category
(which doesn't exist as per the freedesktop specification).
Also, I think the Name is too long right now. "The Python programming
language" or "Le lan
Changes by Antoine Pitrou:
Added file: http://bugs.python.org/file9208/pycon.png
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1353344>
_
___
Pyth
Antoine Pitrou added the comment:
> Making the mutex module thread safe is a low hanging fruit for the bug
day.
But would it bring anything that the threading module doesn't have?
--
nosy: +pitrou
_
Tracker <[EMAIL PROTEC
Antoine Pitrou added the comment:
So what's the status of this? Skipping test is still an important
ability to have.
--
nosy: +pitrou
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.or
Antoine Pitrou added the comment:
FWIW, Georg's patch works here.
Perhaps there should be a test for unicode attribute names since it is
special-cased in the patch.
--
nosy: +pitrou
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
New submission from Antoine Pitrou:
In test_operator we find the following lines:
class C(object):
def __getattr(self, name):
raise SyntaxError
self.failUnlessRaises(AttributeError,
operator.attrgetter('foo'), C())
Obviously "__getattr
Antoine Pitrou added the comment:
This should be a better patch, although it only applies to the text
formatter of pydoc, not the HTML one (I'm too lazy for this :-)).
--
nosy: +pitrou
Added file: http://bugs.python.org/file9246/pydocsubmodules.
Antoine Pitrou added the comment:
I can confirm that with SVN trunk, and it's actually even worse because
it can return unexpected results without raising an exception at all:
>>> class Foo(object):
... def __getattr__(self, name): return 42
... @property
... def bacon
Antoine Pitrou added the comment:
PyObject_GenericGetAttr is invoked from slot_tp_getattr_hook in
typeobject.c via tp_getattro. The problem is that, when tp_getattro
returns with an AttributeError, there is no way for slot_tp_getattr_hook
to know whether the error was raised by
Antoine Pitrou added the comment:
It seems to me that, when a boolean is to be represented, most C
programmers would expect a char rather than an int. Also an int would
make the object larger without any benefit.
As for type checking, Angelo's patch already does a PyBool_Check agains
Antoine Pitrou added the comment:
I can reproduce this with both SVN trunk and 2.5.1 (on an x86 Mandriva box).
--
nosy: +pitrou
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
Actually, HtmlDoc already lists all module members in the inspected
module (regardless of whether they are modules imported from outside or
submodules defined inline). You can try it with the updated pydocfodder:
>>> import pydoc
>>>
Antoine Pitrou added the comment:
I'm not sure about the implications of Amaury's proposal, but in any
case here is a patch which contains an unit test as well.
(it seems to me swapping __stop() and __delete() can do no harm as there
is no way for user code to be executed synchronous
Antoine Pitrou added the comment:
> There is still the possibility of a switch
> between the two calls. In this case the thread is not marked as stopped,
> but enumerate() does not return it.
But user code is unlikely to rely on this because in most cases the
thread *will* be marked a
5101 - 5200 of 16792 matches
Mail list logo
