Antoine Pitrou added the comment:
Here is a first patch, tests still need to be written.
--
keywords: +patch
Added file: http://bugs.python.org/file19038/gzippeek.patch
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
I don't think there's any point doing this. Pickle is insecure by construction;
it shouldn't crash when used legitimately, but trying to make it robust in the
face of hand-crafted pickle strings sounds like an uphill battle (*).
(*) e.g. htt
Antoine Pitrou added the comment:
As an example of malicious pickle causing "excessive" memory usage, you can
simply write:
>>> s = b'\x80\x03cbuiltins\nbytearray\nq\x00J\x00\x00\x00\x7f\x85q\x01Rq\x02.'
>>> _ = pickle.loads(s)
This will allocate an a
Antoine Pitrou added the comment:
> > But if line buffering doesn't work, disabling buffering on
> > stdout/stderr does have a functional consequence: it allows process
> > output to appear as generated instead of coming in chunks when the
> > buffer is f
Antoine Pitrou added the comment:
Le mardi 28 septembre 2010 à 03:11 +, Lenard Lindstrom a écrit :
>
> Let's consider Pygame, and the SDL surface it wraps as a
> pygame.Surface. Pygame exposes a surface's data through the buffer
> protocol for manipulation by a Num
Antoine Pitrou added the comment:
My patch breaks pickling of transparent proxies such as weakref.proxy().
(since these have a different __class__ than Py_TYPE(self), through tp_getattr
hackery). I will need to remove a couple of optimizations.
(unfortunately, there don't seem to be any
Antoine Pitrou added the comment:
Corrected patch, including new tests for pickling of weak proxies.
--
Added file: http://bugs.python.org/file19044/pickleinst2.patch
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
Fixed, thank you.
--
nosy: +pitrou
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Antoine Pitrou added the comment:
Here is an updated patch wrapping all variants of recv() and send(), except
sendall() which already has its own retry loop.
--
Added file: http://bugs.python.org/file19046/selectretry2.patch
___
Python tracker
Antoine Pitrou added the comment:
> Yes, I was unclear. This refers to Python 3.2, not the 2.x series.
> PyObject_AsReadBuffer (defined at line 270 in abstract.c, code of
> routine attached) calls bf_getbuffer with the PyBUF_SIMPLE flag to
> retrieve a bytes buffer. I
Antoine Pitrou added the comment:
Committed in 3.2 in r85074. I don't plan to backport it, since the
_PyTime_gettimeofday abstraction is not available on earlier versions.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> pending
versions
Antoine Pitrou added the comment:
> Le mardi 28 septembre 2010 22:24:56, vous avez écrit :
> > I disagree. PyObject_As*Buffer functions are remnants of the old buffer
> > API in Python 2.x. They are here only to ease porting of existing C
> > code, but carefully written 3
Antoine Pitrou added the comment:
Same patch with tests.
--
Added file: http://bugs.python.org/file19053/gzippeek2.patch
___
Python tracker
<http://bugs.python.org/issue9
Changes by Antoine Pitrou :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue9962>
___
___
Python-bugs-list mailing list
Un
New submission from Antoine Pitrou :
This has started showing up since r85073.
==
ERROR: test_CTRL_BREAK_EVENT (test.test_os.Win32KillTests)
--
Traceback (most
Antoine Pitrou added the comment:
Ok, 3.x documentation is fixed to recommend the new buffer API funcs over the
old compatibility funcs. On Victor's private suggestion, I'm now closing the
issue.
--
resolution: -> wont fix
status: o
Antoine Pitrou added the comment:
> A possible duck-typing approach here would be to replace the
> "instance(x, str)" tests with "hasattr(x, 'encode')" checks instead.
Looks more ugly than useful to me. People wanting to emulate str had better
subclass it
Changes by Antoine Pitrou :
--
nosy: +loewis
stage: -> patch review
versions: +Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
That's expected behaviour, syntactically. Multiplying a sequence doesn't
deep-copy its elements.
If you want an array of distinct arrays, just write:
>>> m1 = [[0,0,0,0] for i in range(4)]
>>> m1[1][0] = 6
>>> m1
[[0, 0,
Antoine Pitrou added the comment:
Committed in r85100.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Antoine Pitrou :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue9090>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
Sounds reasonable to me.
(although I would like that to change, see issue1589)
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue9
Changes by Antoine Pitrou :
--
nosy: +orsenthil
versions: +Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue9983>
___
___
Python-bugs-list m
Antoine Pitrou added the comment:
> Hi pitrou, that bug you linked to is really long can state a summary
> of any changes made to python and their impact - alternatively the
> lack of (changes) and their impact.
No changes yet unfortunately. As for the impact, you already know it,
Antoine Pitrou added the comment:
I've added warnings for httplib, urllib, urllib2 in r85101, r85102 and r85103.
The changes can take a day or two to appear online.
--
resolution: -> fixed
status: open -> closed
___
Python tra
Changes by Antoine Pitrou :
--
resolution: -> duplicate
status: open -> closed
superseder: -> please add a large NOTE explaining that urllib does not perform
any ssl validation
___
Python tracker
<http://bugs.python.o
Changes by Antoine Pitrou :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> @pitrou you should also put an example of how to ACTUALLY establish a
> connection that can't be MITMed. Because lots of people are getting
> this wrong
It would require writing the code for checking hostnames that the ssl
module currently
Antoine Pitrou added the comment:
I've committed the latest patch in r85111.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyt
Antoine Pitrou added the comment:
Looks like a duplicate of #9437, and there's a patch you can review there :)
--
nosy: +pitrou
resolution: -> duplicate
status: open -> closed
superseder: -> can't build extensions with non-default
New submission from Antoine Pitrou :
The nntplib cleanup broke the "usenetrc" option to NNTP:
Traceback (most recent call last):
File
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_nntplib.py", line
167, in setUp
self.server = NNTP(self.NNTP_HOST, tim
Antoine Pitrou added the comment:
Fixed in r85114.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> Here is a letter that I just received, in my role as a developer of
> Tahoe-LAFS, from a concerned coder who doesn't know much about Python:
>
> > An FYI on Python.
> >
> > I'm not sure how businesses handle this (I&#x
Antoine Pitrou added the comment:
> > Correct me if I'm wrong, but the "well-maintained pyOpenSSL
> > package" doesn't have the missing functionality (hostname
> > checking in server certificates), either.
>
> I'm pretty sure it's just
Antoine Pitrou added the comment:
> What would the approximate cost on that be, do you think? My
> understanding was that the code was pretty much written given John
> Nagle's patch and M2Crypto.
To err on the safe side and account for integration work (unit tests,
coding sty
Changes by Antoine Pitrou :
--
assignee: -> pitrou
nosy: +pitrou
stage: -> needs patch
versions: +Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/
Changes by Antoine Pitrou :
--
nosy: +brett.cannon
___
Python tracker
<http://bugs.python.org/issue9988>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> What it does not do is to validate the server certificate in any form (AFAIU).
The warning I have added says “When opening HTTPS (or FTPS) URLs, it is
not attempted to validate the server certificate.”
(see http://docs.python.org/library/urllib.html )
S
Antoine Pitrou added the comment:
> The primary reason for supporting ASCII compatible bytes directly is
> specifically to avoid the encoding and decoding overhead associated
> with the translation to unicode text.
I think it's quite misguided. latin1 encoding and decoding is b
Changes by Antoine Pitrou :
--
nosy: +flox, loewis
___
Python tracker
<http://bugs.python.org/issue9991>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue9994>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> There's a configure-time check that works out whether resetting the
> precision is necessary; if so, the precision is changed before each
> conversion and reverted again afterwards
How about doing the check in Py_Initialize() instead? Then it
Changes by Antoine Pitrou :
--
nosy: +flox, loewis
___
Python tracker
<http://bugs.python.org/issue9996>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Regardless of the various arguments, I think it is too late to break
compatibility again, by disallowing bytes input, or changing the output type.
What we could do is allow str arguments to a2b_ functions, with the restriction
that the argument must not
Antoine Pitrou added the comment:
Hir Nir,
> BufferedIOBase is not documented to have peek():
> http://docs.python.org/dev/py3k/library/io.html
Ah, you're right.
> Small note about patch:
> 1) IOError string says "read() on write-only...", should be "peek(
Changes by Antoine Pitrou :
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue9962>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
Here is a patch fixing these issues.
--
Added file: http://bugs.python.org/file19074/gzipfixup.patch
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
The recommended way is to use PyBuffer_FillInfo() (and then fill in any
additional data if necessary), which will set the pointer and incref it itself.
I agree all this is a bit poorly documented.
--
assignee: -> d...@python
compone
Antoine Pitrou added the comment:
> Should be min(n, 1024) instead of max(...)
Well, no, because we want to buffer a non-trivial amount of bytes for
the next accesses. So, if n < 1024, buffer at least 1024 bytes.
--
___
Python tracker
Antoine Pitrou added the comment:
> Right, I missed the change from self.max_read_chunk to 1024
> (read_size). Should not peek() limit to self.max_read_chunk as read()
> does?
This is used for the chunking of huge reads, but for peek():
1) there is no chunking (peek() should do at mos
Antoine Pitrou added the comment:
Here is a patch that fixes the issue. Can you try it?
Unfortunately, more advanced uses such a slicing the memoryview are still
crashing. That's because the new buffer protocol doesn't define ownership of
Py_buffer structs. As a result, noth
Antoine Pitrou added the comment:
Of course, a patch is always better without the debugging prints :)
--
Added file: http://bugs.python.org/file19089/memview.patch
___
Python tracker
<http://bugs.python.org/issue9
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file19088/memview.patch
___
Python tracker
<http://bugs.python.org/issue9990>
___
___
Python-bugs-list m
Antoine Pitrou added the comment:
Mainly to protect against potential infinite recursion with isinstance checks.
Also, performance is probably better.
Here are the relevant code and comments in PyErr_GivenExceptionMatches() (in
Python/errors.c):
/* PyObject_IsSubclass() can recurse
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue9533>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> As per RDM's email to python-dev, a better way to create the
> pseudo_str values would be by decoding as ascii with a surrogate
> escape error handler rather than by decoding as latin-1.
If you were worried about performance, then surr
Antoine Pitrou added the comment:
> I think nttplib's use case can be satisfied via the issue 4661 patch
> coupled with the decode_header bytes-recovery enhancement.
I don't really understand how that could.
nntplib needs to "decode" (in the decode_header sense) hea
Antoine Pitrou added the comment:
Here is a proposal for decode_header_as_string().
--
Added file: http://bugs.python.org/file19118/decode_header.patch
___
Python tracker
<http://bugs.python.org/issue6
Changes by Antoine Pitrou :
--
assignee: d...@python -> ghaering
nosy: +ghaering
versions: +Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issu
Changes by Antoine Pitrou :
--
assignee: -> bob.ippolito
nosy: +bob.ippolito
___
Python tracker
<http://bugs.python.org/issue10019>
___
___
Python-bugs-lis
Antoine Pitrou added the comment:
> In addition, in 3.2 I will disallow non-ASCII parameter values unless
> they are specified in a three element tuple as in the example above.
Why would the caller be required to choose an encoding while you could simply
default to utf-8? There doesn&
Antoine Pitrou added the comment:
I'm not an asyncore expert, but I can't see anything wrong with the patch.
--
stage: needs patch -> patch review
versions: -Python 2.6, Python 2.7, Python 3.1
___
Python tracker
<http://bugs.pyth
Antoine Pitrou added the comment:
The use of fdst.truncate() is indeed wrong, since truncate() in 3.x is defined
as truncating up to the current file position (which has been moved forward by
the latest seek()).
--
nosy: +pitrou
___
Python tracker
Antoine Pitrou added the comment:
Ok, after experimenting, I now understand what the truncate() call is for.
However, your heuristic for detecting sparse files is wrong. The unit for
st_blocks is undefined as per the POSIX standard, although it gives
recommendations:
“The unit for the
Antoine Pitrou added the comment:
By the way:
> Thanks for your comments -- I'm trying to put together some unit tests > and
> documentation, against the Subversion trunk.
Please ignore trunk; all development (new features) should be done against
Antoine Pitrou added the comment:
Hello,
> I added some extra verification to Mercurial
> (http://www.selenic.com/hg/rev/f2937d6492c5). Feel free to use the
> following under the Python license in Python or elsewhere. It could be
> a separate method/function or it could i
Antoine Pitrou added the comment:
Is this 2.7-specific? Otherwise, it would be better to provide a patch for 3.2
first, and then svnmerge to other branches.
> My reading of Python/getargs.c is that this macro does affect "u#" in a >
> manner analogous to "s#";
Antoine Pitrou added the comment:
As I mentioned, the speedup is invisible anyway, so it's not really a "fast
path" ;)
--
___
Python tracker
<http://bugs.py
Antoine Pitrou added the comment:
> I agree that it makes sense to have consistent types in the output.
> As for whether to add a new method or fix the existing one, I'm a bit
> torn, but I'd probably opt for fixing the existing function rather
> than adding a new one
New submission from Antoine Pitrou :
There's some code in _ssl.c which exports more information in decoded SSL
certificates (such as notBefore or issuer), but it is only enabled when the
hidden function _ssl._test_decode_cert is used. It would be nice to export all
this information by de
Antoine Pitrou added the comment:
Here is a patch against py3k. It adds a single ssl.match_hostname method, with
rules from RFC 2818 (that is, tailored for HTTPS). Review welcome.
--
keywords: +patch
stage: -> patch review
Added file: http://bugs.python.org/file19128/sslcheck.pa
Antoine Pitrou added the comment:
> I think it looks good except for the wildcard checking. According to
> the latest draft of that TLS id-checking RFC, you aren't supposed to
> allow the wildcard as part of a fragment. Of course this contradicts
> RFC 2818.
Well, since it
Antoine Pitrou added the comment:
Alexandre, do you have opinion on this?
--
___
Python tracker
<http://bugs.python.org/issue9935>
___
___
Python-bugs-list mailin
New submission from Antoine Pitrou :
test_lib2to3
beginning 5 repetitions
12345
No handlers could be found for logger "RefactoringTool"
.
test_lib2to3 leaked [32, 32] references, sum=64
--
components: Library (Lib), Tests
messages: 117983
nosy: benjamin.peterson, pitro
New submission from Antoine Pitrou :
In http://docs.python.org/dev/extending/newtypes.html, you can read:
“To enable object creation, we have to provide a tp_new implementation. In this
case, we can just use the default implementation provided by the API function
PyType_GenericNew(). We’d
Antoine Pitrou added the comment:
I've committed the improvements in r85221. Thank you!
--
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
I've committed the patch in r85229. Let's see if this makes the buildbots happy.
--
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
Looks alright, thank you!
--
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> I did some spelunking. Guido committed the similar optimization in r8306.
> The diff is at:
> http://svn.python.org/view/python/trunk/Python/ceval.c?r1=8087&r2=8306
>
> His commit message was:
>
> Huge speedup by inl
Changes by Antoine Pitrou :
--
nosy: +belopolsky
stage: unit test needed -> needs patch
___
Python tracker
<http://bugs.python.org/issue7980>
___
___
Python-
Antoine Pitrou added the comment:
If nobody objects, I will commit this (with docs) soon. Then I will open a
separate issue for the http.client / urllib.request integration, since the
discussion is already quite long here.
--
___
Python tracker
Changes by Antoine Pitrou :
--
assignee: d...@python -> bob.ippolito
nosy: +bob.ippolito
___
Python tracker
<http://bugs.python.org/issue10038>
___
___
Python-
Antoine Pitrou added the comment:
> From a Python user/programmers point of view it would be nice if
> http://docs.python.org/library/ssl.html also clarified what
> "validation" means (apparently that the cert chain all the way from
> one of ca_certs is valid and with va
Antoine Pitrou added the comment:
Updated patch against current py3k.
--
Added file: http://bugs.python.org/file19142/unialloc6.patch
___
Python tracker
<http://bugs.python.org/issue1
Antoine Pitrou added the comment:
> I don't know if there is a point or not, but some hosts are for some
> reason intended to be connected to using IP address and their
> certificates thus contains IP addresses. I think we should support that
> too, and I find it a bit confu
Antoine Pitrou added the comment:
Here is a new patch with doc updates and the corrections mentioned above.
--
Added file: http://bugs.python.org/file19141/sslcheck2.patch
___
Python tracker
<http://bugs.python.org/issue1
Antoine Pitrou added the comment:
Patch committed in r85291 (3.x), and backported to 3.1 (r85293) and 2.7
(r85292). Thank you!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python track
Antoine Pitrou added the comment:
A big warning is now present (*) in the urllib and httplib documentation pages.
Also, once issue1589 is fixed, we can go forward and make
{http.client,urllib.request} check hostname and cert if the user gives the
location of a bunch of CA certs.
(*) see e.g
New submission from Antoine Pitrou :
This is an experimental patch to optimize some operations on small ints.
pystone is 5-10% faster, pybench 2-3% faster, and here are some relevant
benchmarks from unladen swallow:
### nbody ###
Min: 0.345136 -> 0.317502: 1.09x faster
Avg: 0.346
Antoine Pitrou added the comment:
I think the approach in issue10044 is better.
--
status: open -> pending
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
> Maybe we could consider adding an extra field to a PyLong giving its
> 'small_int' value for small values, and some flag value for non-small
> longs. An extra field wouldn't actually enlarge the size of a PyLong
> for small valu
Antoine Pitrou added the comment:
> Technically arbitrary relational comparisons of pointers are
> undefined, but in practice Antoine's assumptions here are very modest.
> They boil down to:
>
>v >= &array[0] && v < &array[array_len]
I can&#x
Antoine Pitrou added the comment:
> How does performance change if you adjust NSMALLPOSINTS and
> NSMALLNEGINTS, but make no other changes?
It makes a very small difference (which is understandable since it doesn't cut
down on code exec
Antoine Pitrou added the comment:
> Nope. It's only well-defined for pointers pointing into the same
> array (or to one past the end of an array). Otherwise it's undefined
> behaviour.
How can the compiler tell whether two pointers are "into the same
array"? Th
Antoine Pitrou added the comment:
> > How can the compiler tell whether two pointers are "into the same
> > array"? That sounds like an undecidable criterion.
>
> It doesn't have to be able to tell---it's allowed to assume. :-)
Tha
Antoine Pitrou added the comment:
> In the bad old days of 386 segment:offset memory architectures this
> was a problem. You could have overlapping segments but pointers inside
> an object were always in the same segment, so the segment selectors
> never had to be inspected.
Antoine Pitrou added the comment:
> See the example above: suppose that a compiler is looking at a (p >=
> q) comparison of pointers. Suppose furthermore that in a particular
> case that compiler is smart enough to figure out that q is a pointer
> to the start of an array.
W
Antoine Pitrou added the comment:
> In other words, when producing code for ptr_compare, the compiler is
> allowed to *assume* that a and b point into the same array, and act
> accordingly.
But this assumption doesn't bring *anything*, right?
That is, there is no shortcut way to
Antoine Pitrou added the comment:
For the record, a Py_uintptr_t version works and has the same performance.
Would you agree to it or is there still some menacing oddity from the i386 days
lurking around?
--
___
Python tracker
<h
Antoine Pitrou added the comment:
I don't think there's much point in fixing this. 2.7 users can use io.BytesIO,
which is a fast type implemented in C.
--
___
Python tracker
<http://bugs.python.o
1801 - 1900 of 16792 matches
Mail list logo
