Antoine Pitrou added the comment:
Committed in r84495 (3.x), r84498 (3.1), r84499 (2.7). Thank you!
--
nosy: +pitrou
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bug
Antoine Pitrou added the comment:
With the patches applied except linux-pass-unterminated.diff, I get the
following test failure:
==
ERROR: testMaxPathLen (test.test_socket.TestLinuxPathLen
Antoine Pitrou added the comment:
Modified patch committed in r84501. Thanks!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: performance -> resource usage
___
Python tracker
<http://bugs.pytho
Antoine Pitrou added the comment:
Fixed in r84504, thank you!
--
nosy: +pitrou
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue9771>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Updated patch against py3k.
--
stage: patch review -> commit review
versions: -Python 2.7
Added file: http://bugs.python.org/file18755/json-opts4.patch
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
Committed in r84505.
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Updated patch so that the tests pass with -Werror.
Do you think this should be committed before the next alpha?
--
Added file: http://bugs.python.org/file18756/assertwarns2.patch
___
Python tracker
<h
Antoine Pitrou added the comment:
> baikie: why did the test pass for you?
The test passes (I assume) if linux-pass-unterminated.diff is applied. The
latter patch is only meant to exhibit the issue, though, not to be checked in.
--
___
Pyt
Antoine Pitrou added the comment:
Ok, I've committed the patch in r84506 (3.x), r84507 (3.1) and r84508 (2.7).
Thank you!
--
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python
New submission from Antoine Pitrou :
Currently, Python produces hash values with fit in a C "long". This is fine at
first sight, but in the context of dict and set implementations, it means that
1) holding hashes and indices in the same field of a structure requires some
care (see is
Antoine Pitrou added the comment:
As an example of padding behaviour (under Win64 with 32-bit longs and 64-bit
pointers):
Python 3.2a1+ (py3k, Sep 4 2010, 22:50:10) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license"
Changes by Antoine Pitrou :
--
assignee: -> giampaolo.rodola
stage: -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
___
Python tracker
<http://bugs.python.org/
Antoine Pitrou added the comment:
> I guess there are not that many people running Python applications with
> a big memory footprint on AIX or SunOS, otherwise this problem would be
> more popular.
Not only, but integrating a big chunk of foreign code in something as critical
as t
Antoine Pitrou added the comment:
> Correct. So it either needs to happen before 3.2, or wait until 4.0,
Shouldn't there be a provision for ABI versioning?
Or do you suggest bumping to the next major number (4.0, 5.0...) be done on the
basis of ABI
Antoine Pitrou added the comment:
Other patch, fixes all failures.
--
Added file: http://bugs.python.org/file18758/m32-2.patch
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
The patch has been outdated by other independent performance work on the
zipfile module. In Python 3.2, the zipfile module is actually slightly faster
than the "unzip" program:
- first with the supplied "zeroes.zip" file:
$ rm -f zeroes
Antoine Pitrou added the comment:
The whole approach doesn't seem to bear much fruit. I tried to apply again
likely_decref.diff and got a 0% performance change on 3.2 (on a Core i3
processor).
--
resolution: -> rejected
status: open -
Antoine Pitrou added the comment:
The subprocess doc now has a note about buffering and performance issues,
closing.
--
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Antoine Pitrou added the comment:
Closing: Neil's algorithm is not different from what is already in 3.2, except
for the additional type_attrcache_callback() which probably doesn't make a
difference in normal workloads.
--
resolution: accepted -> out of date
status: o
Antoine Pitrou added the comment:
Suggestions:
- do it on BufferedReader, rather than TextIOWrapper: if you want full-speed
scanning of log files, you probably want to open them in binary mode
- rather than implementing a full-blown iterator, you can start with simple
primitives: e.g. a
Antoine Pitrou added the comment:
> I agree with Georg: The patch seems not to make things worse, and if
> it makes the tests pass, I think it should be committed. Antoine, you
> decide if you want to commit it now or wait for Tarek’s review.
Well, ideally, someone should have kno
Antoine Pitrou added the comment:
Committed in r84544.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
New submission from Antoine Pitrou :
There are various warnings when compiling the _multiprocessing extension in
64-bit mode under Windows. Many seem related to the fact that read() and
friends under Windows take "int" size arguments rather than "size_t".
20>--
New submission from Antoine Pitrou :
Some of these warnings could be serious (e.g. the one where the 64-bit "self"
is converted to a 32-bit "long"):
13>..\Modules\_elementtree.c(696) : warning C4244: 'function' : conversion from
'Py_uintptr_t' to
New submission from Antoine Pitrou :
I'm posting this in case it is a sign of a problem. Apparently some variable
named "hf" is an INT_PTR used as an int (according to Visual Studio), but "hf"
doesn't seem to be defined or declared in _msi.c at all.
12>
Antoine Pitrou added the comment:
Thank you. For the record, here is the patch adapted for 3.2 development
branch. It looks ok to me.
--
stage: unit test needed -> patch review
versions: +Python 3.2 -Python 2.6
Added file: http://bugs.python.org/file18767/aix32.d
Antoine Pitrou added the comment:
> * there are no more warnings for 'Duplicate symbol': I changed
> build_ext.py to not link extensions with libpython since the symbols
> are already defined by python.exp
Could this affect building extensions with gcc under AIX? Or does g
Antoine Pitrou added the comment:
The patch doesn't apply cleanly anymore. Furthermore, I discovered some
additional issues:
- load, dump, loads and dumps from the _pickle module were never used because
they were shadowed by the same functions in pickle.py
- once the C functions abov
Antoine Pitrou added the comment:
Here is a patch. Benchmark numbers:
* dumps():
./python -m timeit -s "import pickle, io; d={(x, 'a'): x for x in
range(1)}" "pickle.dumps(d)"
-> before: 100 loops, best of 3: 7.47 msec per loop
-> after: 100
Antoine Pitrou added the comment:
Gosh. My patch is based on an outdated patch :(
--
___
Python tracker
<http://bugs.python.org/issue9410>
___
___
Python-bug
Antoine Pitrou added the comment:
Ok, this patch merges my changes with Alexandre's previous patch. Performance
is similar as the previous posted patch.
--
Added file: http://bugs.python.org/file18779/pickle_optimizations5.diff
___
Python tr
Antoine Pitrou added the comment:
This was committed in r84562.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Committed in r84563!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Well, I suppose if flock needs libbsd on AIX (which is quite weird in itself),
and AIX fails to ship libbsd for some executable formats, then it's AIX's
problem.
--
nosy: +pitrou
___
Python trac
Antoine Pitrou added the comment:
> Anyway, I will run the test with gcc on Wednesday and know for sure if
> that works.
Thank you! If it works, it's good for commit.
--
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
See the context management patch at #9757.
--
___
Python tracker
<http://bugs.python.org/issue9789>
___
___
Python-bugs-list m
Antoine Pitrou added the comment:
Just tried to apply the patch:
- test_capi now freezes in auto-thread-state
- test_threading now freezes in test_finalize_runnning_thread
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
You have a bug in PyThread_delete_key_value() (to_free = NULL?).
Also, you should move the "/* NB This does *not* free p->value! */" comments at
the right places.
--
nosy: +pitrou
___
Python t
Antoine Pitrou added the comment:
LIFO looks preferable if you want your setup/teardown code to be properly
nested (that is, if I set up A before B, I want B to be torn down before A).
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
I've just merged Sébastien's patches in r84584 (3.x), r84585 (2.7) and r84586
(3.1). If you'd like to improve the fixes (as per your latest message), please
say so, otherwise I'll close the issue.
(and thanks for your contributions!)
-
Antoine Pitrou added the comment:
For the record, here are the unladen swallow benchmark results against stock
py3k:
### pickle ###
Min: 1.644222 -> 0.812691: 2.0232x faster
Avg: 1.652311 -> 0.814994: 2.0274x faster
Significant (t=297.660908)
Stddev: 0.00594 -> 0.00207: 2.8732
Antoine Pitrou added the comment:
The patch in #1926 is more modern and up-to-date, closing as duplicate.
--
nosy: +pitrou
resolution: -> duplicate
stage: unit test needed ->
status: open -> closed
superseder: -> NNTPS suppor
Antoine Pitrou added the comment:
The patch might need a little reworking to make it work under 3.x, although
probably not much.
It should also, IMHO, take an instance of the new SSLContext class (*) as a
parameter, rather than the keyfile and certfile args.
(*) http://docs.python.org/dev
Antoine Pitrou added the comment:
> Given this explanation, of course I am +1 on an explicit release()
> method. But I'm still skeptical that a context manager adds much (not
> sure if that counts as -0 or +0 :-).
Ok, release() is probably enough.
> I suppose after releas
Antoine Pitrou added the comment:
Actually, writing a test ended up quite easy (by re-using an existing test in
test_ioctl and simply enlarging its buffer). I've committed an updated patch in
r84589 (3.x), r84590 (3.1) and r84591 (2.7).
Thank you!
--
resolution: -> fix
Changes by Antoine Pitrou :
--
nosy: +loewis
versions: +Python 3.1, Python 3.2 -Python 3.0
___
Python tracker
<http://bugs.python.org/issue3402>
___
___
Python-bug
Antoine Pitrou added the comment:
Note that according to RFC 3977, “The character set for all NNTP commands is
UTF-8”.
But it also says this about multi-line data blocks:
Note that texts using an encoding (such as UTF-16 or UTF-32) that may
contain the octets NUL, LF, or CR other than
Antoine Pitrou added the comment:
Actually, I just noticed there's some beginnings of a test file in #9360.
--
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
> Sorry to be pedantic - but it looks like (don't have a build
> environment at hand at the moment) it will fail to build as 64bit on
> the not-so-up-to-date AIX with missing 64bit flock implementation:
> There, the compile-check will s
New submission from Antoine Pitrou :
When you call socket.create_connection() and it fails because it hits the
socket timeout, the socket.timeout error is recast as a generic socket.error,
which makes analyzing the failure more difficult (also, it means the "errno"
attribute is lost
Antoine Pitrou added the comment:
Here is a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file18788/createconn.patch
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
Patch committed in r84598. Needs backporting to 3.1 and 2.7.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> pending
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Improved again and committed in r84597 and r84599. Needs backporting.
--
nosy: +pitrou
resolution: -> fixed
stage: -> committed/rejected
status: open -> pending
versions: -Python 2.6
___
Python track
Changes by Antoine Pitrou :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue8574>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Antoine Pitrou :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue9792>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
Committed in r84607.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
You don't need to use socketserver. Take a look at how the other tests in
test_socket are written. Inheriting from ThreadedTCPSocketTest should be easy.
--
___
Python tracker
<http://bugs.python.org/i
New submission from Antoine Pitrou :
As the title says. __exit__() simply has to call self.quit(), AFAICT.
--
components: Library (Lib)
messages: 115815
nosy: pitrou
priority: normal
severity: normal
status: open
title: nntplib.NNTP should support the context protocol
type: feature
Changes by Antoine Pitrou :
--
nosy: +giampaolo.rodola
___
Python tracker
<http://bugs.python.org/issue9795>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Antoine Pitrou :
pystate.c assumes that when autoTLSkey is 0, it hasn't been created yet.
However, some TLS implementations can return 0 as a valid key value. Lots of
interesting things then happen.
Here is a patch.
--
files: autotlskey.patch
keywords:
Antoine Pitrou added the comment:
The problem turns out to be in pystate.c (my system returns 0 as a valid key
number). See issue #9797.
--
dependencies: +wrong assumption in pystate.c
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
Ok, it is simpler indeed. Here is an updated patch.
--
Added file: http://bugs.python.org/file18795/autotlskey2.patch
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
Committed in r84623 (3.x), r84627 (2.7) and r84628 (3.1).
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
I would suggest trying r80723 and then r80724.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue9799>
___
___
Antoine Pitrou added the comment:
Le mercredi 08 septembre 2010 à 15:28 +, Sébastien Sablé a écrit :
> Sébastien Sablé added the comment:
>
> For the moment I have:
>
> r73580 = OK
> r83318 = OK
> r83584 = OK
> r83800 = OK
>
> r84000 = ERR
Antoine Pitrou added the comment:
> Bingo, you got it.
>
> r73580 = OK
> r83318 = OK
> r83584 = OK
> r83800 = OK
> r83900 = OK
> r83950 = OK
> r83985 = OK
> r83986 = ERR
> r84000 = ERR
> r84522 = ERR
>
> It was commited by some guy named "antoine
Antoine Pitrou added the comment:
By the way, all traces of 0711-596 on the Web seem to point to IBM compiler
errata. Apparently xlc tries to support computed gotos (which is originally a
GCC-specific feature) but doesn't do it very well.
The support for computed gotos is det
New submission from Antoine Pitrou :
This is an experiment which turns out to yield little benefits, except on
micro-benchmarks such as:
$ ./python -m timeit -s "a=[1,2,3]"
"a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[
Antoine Pitrou added the comment:
Here is a new patch adding the release() method as well.
--
Added file: http://bugs.python.org/file18801/memcontext2.patch
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
This is a patch for 3.x, tested in the following situations:
- gdb: UCS2, inferior: UCS2
- gdb: UCS2, inferior: UCS4
--
Added file: http://bugs.python.org/file18803/test_gdb2.patch
___
Python tracker
<h
New submission from Antoine Pitrou :
This is on an UCS-2 py3k build:
>>> ascii('\U00012FFF')
"'\\U00012fff'"
>>> ascii('\U0001D121')
"'\\ud834\\udd21'"
--
components: Interpreter Core, Unicode
messages: 1
Antoine Pitrou added the comment:
Fixed in r84635, r84636, r84638 (3.x) and r84637 (2.7). Also prompted the
creation of issue9804.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python track
Antoine Pitrou added the comment:
> On an eyeball review, the structure of do_release seems a little
> questionable to me. I'd be happier if view.obj and view.buf were
> copied to C locals and then set to NULL at the start of the function
> before any real work is done.
Antoine Pitrou added the comment:
How about the following solution:
>>> def a(s):
...s = s.encode('unicode-escape').decode('ascii')
...s = s.replace("'", r"\'")
...return "'" + s + "'"
...
>
Antoine Pitrou added the comment:
Actually, it would probably be simpler to export a
_PyUnicode_Repr(PyUnicodeObject *, int only_ascii) function since all the code
is already there in unicodeobject.c.
--
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
Or perhaps not, since we would like surrogate pairs to be fused in other cases
(ascii() of other types) as well.
So "backslashreplace" would need to be changed instead:
>>> print("\U00012345".encode('ascii', 'bac
Antoine Pitrou added the comment:
Here is a patch (lacking tests for now).
--
keywords: +patch
Added file: http://bugs.python.org/file18805/backslashsurrogates.patch
___
Python tracker
<http://bugs.python.org/issue9
Changes by Antoine Pitrou :
--
assignee: -> jnoller
nosy: +jnoller
versions: +Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
Similarly:
>>> x = man.list()
>>> x.append({})
>>> x[0]
{}
>>> x[0]['a'] = 5
>>> x[0]
{}
Lots of fun!
--
nosy: +pitrou
__
Changes by Antoine Pitrou :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue8655>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Antoine Pitrou :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue9799>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
New patch with tests.
--
Added file: http://bugs.python.org/file18810/backslashsurrogates2.patch
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
Committed in r84649. Thanks for the comments!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
The patch was finally committed in r84653. Thanks to everyone who participated
in this.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python track
Antoine Pitrou added the comment:
Modified patch committed in r84655 (3.x) and r84656 (3.1). Thanks!
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Ok, closing. The original install was on a rather strange setup.
--
resolution: -> works for me
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Antoine Pitrou added the comment:
Ok, thank you. The improvement has been committed in all three branches (3.2,
3.1, 2.7).
--
stage: -> committed/rejected
status: open -> closed
versions: -Python 2.6, Python 3.3
___
Python tracker
Antoine Pitrou added the comment:
I've committed the latest patch in r84680 (3.x), r84682 (3.1) and r84683 (2.7).
Perhaps you want to check it's ok. Thank you anyway!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status
Changes by Antoine Pitrou :
--
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue8835>
___
___
Python-bugs-
Changes by Antoine Pitrou :
--
assignee: -> haypo
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue9836>
___
___
Python-bugs-list mailing list
Un
Antoine Pitrou added the comment:
I can't reproduce under Linux. Is 3.1 also affected?
Can you try the following patch:
Index: Python/pythonrun.c
===
--- Python/pythonrun.c (révision 84718)
+++ Python/pythonrun.c (cop
Antoine Pitrou added the comment:
Indeed. In most cases, though, read1(n) will return exactly n bytes and the
loop will therefore end immediately with the right buf size. Do you have a
simple test case?
--
versions: +Python 3.2
___
Python tracker
Antoine Pitrou added the comment:
> As an aside, I still like Jeffrey Yasskin's suggestion on the
> python-dev mailing list that the sensible definition for max would
> maintain the invariant that max(iterable) be equivalent to
> sorted(iterable)[-1]
What's intere
Antoine Pitrou added the comment:
> Instead, every call must go through PyObject_CallMethod, and the file
> objects only handle `PyBytes` and `PyByteArray` which are cumbersome
> and inefficient to use in extension modules.
Because of the generic nature of the 3.x I/O stack, even
Antoine Pitrou added the comment:
It should be noted that repeatedly calling Py_Initialize / Py_Finalize leaks a
lot (even without the "import _ctypes"):
--- 0 ---
[34543 refs]
--- 1 ---
[37540 refs]
--- 2 ---
[40504 refs]
--- 3 ---
[43468 refs]
--- 4 ---
[46432 refs]
--- 5 ---
[
Antoine Pitrou added the comment:
> Unfortunately, 2.6 and 3.1 are stable releases, they only get security > and
> documentation fixes. 2.7 is nearly in the same state
Well, that's false. 2.7 and 3.1 both receive bug fixes (and this looks like a
bug to me :-)).
--
Antoine Pitrou added the comment:
Actually, there's a Misc/AIX-NOTES file which needs updating. Sébastien, do you
want to do that?
--
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
Ok, thank you. I've fixed the issue and added a test in r84737 (3.x) and r84739
(2.7).
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python
Changes by Antoine Pitrou :
--
versions: +Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/issue9759>
___
___
Python-bugs-list mailing list
Unsub
1501 - 1600 of 16792 matches
Mail list logo
