Antoine Pitrou added the comment:
> pitrou: actually that seems a bit suspect now... you need to handle
> 'data' differently depending on its type,
Yes, but you can't know all appropriate types in advance, so it's better
to try and catch the TypeError.
I don't
Antoine Pitrou added the comment:
> > len(data) will raise anyway.
>
> No, it won't, if the iterable happens to be a sequence.
Well, it seems the patch is confused between iterable and iterator. Only
iterators have a __next__, but they usually don't have a __len__.
T
Antoine Pitrou added the comment:
One way to check that it's bytes-compatible is to take a memoryview of it:
>>> memoryview(b"abc")
>>> memoryview(bytearray(b"abc"))
>>> memoryview(array.array('b', b"abc"))
>>&
Antoine Pitrou added the comment:
> - Lets have the ValueError raised from the urllib/request.py. Changing
> it to isinstance(data,collections.Iterable) as Antoine suggested is
> okay here too.
Xuanji is right: it's not. We want bytes to be accepted, and it
Antoine Pitrou added the comment:
> You are right, Antoine.
> How about a string and a dict? the string can be "start" and "stop"
> and we can add interesting information to the dict as you suggest.
Looks good to me.
--
Antoine Pitrou added the comment:
Answering to myself, sorry. memoryview() does return the right answer of
whether the object supports the buffer interface, *however* it doesn't mean the
len() will be right. For example, take an array.array of ints:
>>> memoryview(array.arr
Changes by Antoine Pitrou :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue10589>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Raymond, unless you object, I'd like to commit this before beta1.
--
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
Modified patch committed in r86905. Thanks!
--
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
What does "unsupported" mean? "Abstract" would look more exact.
--
___
Python tracker
<http://bug
New submission from Antoine Pitrou :
$ ./python -m test.regrtest -R 3:2 test_os
[1/1] test_os
[35351 refs]
[35351 refs]
[35352 refs]
beginning 5 repetitions
12345
[35351 refs]
[35351 refs]
[35352 refs]
test test_os failed -- Traceback (most recent call last):
File "/home/antoine/py3k/__
Antoine Pitrou added the comment:
> > What does "unsupported" mean? "Abstract" would look more exact.
>
> It means they raise io.UnsupportedOperation when called (unless the
> subclass overrides them to do something else).
>
> They are not marked wit
Antoine Pitrou added the comment:
> Other suggestions for a better name for that column are certainly welcome. :-)
>
> "Stub Methods"?
Fine with me.
--
___
Python tracker
<http://bugs
Changes by Antoine Pitrou :
--
nosy: +stutzbach
___
Python tracker
<http://bugs.python.org/issue10478>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Raymond, I'll follow up in private with Shawn. All the recent performance
improvements done on JSON (in 3.2) mean the issue can be closed IMO.
--
resolution: -> out of date
status: open -> closed
___
Antoine Pitrou added the comment:
> just to confirm: we WANT array.array("I", [1,2,3]) to have a content-
> length of 12, right?
Yes, since it will emit 12 bytes in the body (you could actually have a test
for it).
--
___
Pytho
Antoine Pitrou added the comment:
Senthil:
+try:
+ self.sock.sendall(data)
Indentation problem here.
+if isinstance(data,str):
+content_length = len(data)
I'm not sure I understand. What does sending an unicode string
Antoine Pitrou added the comment:
You don't need to backport, we'll do it ourselves. Can someone from the doc
team please review/commit?
--
assignee: eli.bendersky -> d...@python
nosy: +pitrou
stage: -> patch review
___
Pytho
Antoine Pitrou added the comment:
HTTPSHandler now allows to pass an SSLContext and the old API should be buried
in the ground, closing.
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Changes by Antoine Pitrou :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue10596>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> if not request.has_header('Content-length'):
> if (not hasattr(data, '__read__') and
What is __read__ supposed to be?
> 2) Can call len but not buffer: assume len == #byt
Antoine Pitrou added the comment:
> Just wanted to post this so there weren't any illusions about the
> patch being a big win.
Daniel has already posted benchmark numbers, I would trust them rather
than any theoretical speculation about whether the patch is interes
Antoine Pitrou added the comment:
> Since the conventional mathematical symbols for the additional
> imaginary units of quaternions are j and k, confusion is bound to
> happen.
>
> My preferred solution is to limit PYTHONIMAGINARYSYMBOL values to "i",
> "
Antoine Pitrou added the comment:
Thank you!
--
___
Python tracker
<http://bugs.python.org/issue9915>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Le jeudi 02 décembre 2010 à 22:29 +, Mark Dickinson a écrit :
> Mark Dickinson added the comment:
>
> Maybe we need a complex analog to datetime.strptime:
>
> complex.strpcx('(3 + 4i)', '(%R + %Ii)') -> 3 + 4j
Antoine Pitrou added the comment:
> This issue remembers me #3618 (opened 2 years ago): I proposed to use
> RLock instead of Lock, but RLock was implemented in Python and were
> too slow. Today, we have RLock implemented in C and it may be possible
> to use them. Would it solve th
Antoine Pitrou added the comment:
Not all incompatibilities have to raise a py3k warnings; AFAIK, only those
which are not handled by 2to3 do.
--
nosy: +benjamin.peterson, pitrou
___
Python tracker
<http://bugs.python.org/issue2
Changes by Antoine Pitrou :
--
nosy: -pitrou
___
Python tracker
<http://bugs.python.org/issue10562>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Fixed in r86981 (3.2), r86987 (3.1) and r86992 (2.7). Thanks!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Requalifying this issue so that the ssl module is fixed to raise socket.timeout
on socket timeouts, which is not only more logical but much more useful (since
you can then specifically handle this error).
--
priority: low -> normal
title:
Antoine Pitrou added the comment:
Committed in r86997. I won't backport it to bugfix branches since it is a small
compatibility breach.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python
New submission from Antoine Pitrou :
See this buildbot log:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%203.x/builds/198/steps/test/logs/stdio
==
FAIL: test_done_callback_raises
Antoine Pitrou added the comment:
It is not possible to do this using a method, since "raise exc" will add a
context anyway. So, if this is desired, it needs some new syntax and should be
discussed on python-ideas.
(I don't think this is very important personally. Tra
Antoine Pitrou added the comment:
Same one under Ubuntu:
http://www.python.org/dev/buildbot/all/builders/PPC64%20Ubuntu%203.x/builds/265/steps/test/logs/stdio
--
title: test_concurrent_futures failure under Windows Server 2008 ->
test_concurrent_futures fail
Antoine Pitrou added the comment:
> Really ? Is this documented somewhere ? Do you know of any other case
> where a number for an existing opcode was changed ? I can't find any
> so far.
Opcodes are an implementation detail. If you are fiddling with opcodes,
how will your c
Antoine Pitrou added the comment:
> Well, I just checked, and from 2.3 to 2.6 opcodes were only added,
> existing ones were never renumbered.
>
> 2.7 however reshuffled a bunch of them, for no apparent reason at all:
LIST_APPEND was renumbered because it gained an argument.
There
Antoine Pitrou added the comment:
Minimal command line for reproducing:
./python -m test -uall test_pydoc test_logging test_concurrent_futures
[1/3] test_pydoc
[46429 refs]
[46430 refs]
[46430 refs]
[46429 refs]
[46430 refs]
[46425 refs]
[46425 refs]
[2/3] test_logging
[3/3
Changes by Antoine Pitrou :
--
stage: -> patch review
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue10576>
___
___
Python-
Antoine Pitrou added the comment:
I don't know, but I wouldn't call it a bug either.
In general it's not recommended to change the current directory except at the
very beginning of your application.
--
nosy: +pitrou
___
Python
Antoine Pitrou added the comment:
> I just tried using script_helper in a new test, so I have a couple of
> comments.
>
> I don't see stdout and stderr being conflated, it looks to me like
> they are returned separately, at least by the assert methods.
That's b
Antoine Pitrou added the comment:
> The problem of avoiding interfering with application level handlers
> while having unraisable errors visible by default is probably the
> biggest reason past attempts to get the standard library using the
> logging module internally haven&#
Antoine Pitrou added the comment:
> Wow, I didn't realize that's how logging worked. My understanding was
> a module should just get a logger and log messages, and if the
> application didn't do any setup beforehand, the first logging call
> would cause messages
Antoine Pitrou added the comment:
Which OS is it? It works for me:
Traceback (most recent call last):
File "socketbug.py", line 24, in
print(con.send(bytes("Hello", "ascii")))
socket.error: [Errno 32] Broken pipe
Regardless, the error returned is the on
Antoine Pitrou added the comment:
I tried on both 3.1.3 and 3.2. It works (raises an error) under Mandriva; I've
just tested under Debian stable and it fails.
Looking at netstat, the difference seems to be that "nc" closes the TCP
connection fine under Mandriva when killed, an
Antoine Pitrou added the comment:
> This is not consistent with the results reproduced above, however, the
> results from above are exactly what should happen. Maybe there should
> be a remark, that the return value of sendall (and send) may be system
> dependent.
Pretty much al
Antoine Pitrou added the comment:
> Having posted that it occurs to me that it could be useful to have the
> _remove_refcount function in test.support
There's already strip_python_stderr() :)
--
___
Python tracker
<http://b
Antoine Pitrou added the comment:
How about accepting either of these symbols? Do you want to provide a patch?
--
nosy: +pitrou
versions: +Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
Le mercredi 08 décembre 2010 à 23:06 +, Dave Malcolm a écrit :
> Dave Malcolm added the comment:
>
> One of RH's gcc gurus told me in IRC that:
> __ppc__ is not a standard powerpc*-linux macro
> __PPC__ or __powerpc__ is
Keep
New submission from Antoine Pitrou :
The configure.in sets a default OPT of "-O" if none was set by the user, but I
think that's wrong. The user could simply pass optimization flags as part of
CFLAGS instead, and then the contents of OPT could conflict with that of CFLAGS
(wh
Antoine Pitrou added the comment:
I think TAB is the key expected by most people, so let's make it the default.
As for the location, site.py is an adequate one IMO.
--
components: +Library (Lib) -Interpreter Core
versions: +Python 3.2
___
P
Antoine Pitrou added the comment:
When adding some C accelerations, we often try to keep a pure Python
alternative in the stdlib, since it can then benefit other Python
implementations (and easy prototyping).
If you move some of the methods inside a mixin and use multiple inheritance
with
Antoine Pitrou added the comment:
Not sure why you chose 0.11 here. It should probably be 0.2 as in the
command-line code.
As for applying the patch, this can't be done before 3.2 is released.
--
nosy: +pitrou
stage: unit test needed -> patc
Antoine Pitrou added the comment:
Ok, closing as invalid.
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
A test still fails under Windows:
==
FAIL: test_warnings_on_cleanup (test.test_tempfile.test_TemporaryDirectory
Antoine Pitrou added the comment:
> Sorry, I'm giving up.
Indeed, I think only an extensive rewrite could fulfill the feature
request here.
> The copyright notice for bz2module.c lists "Gustavo Niemeyer" as one
> of the holders, is he the maintainer? Maybe he should b
Antoine Pitrou added the comment:
It seems the canonical spelling is SIGCHLD. SIGCLD doesn't exist everywhere and
it produces test failures under OS X:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.x
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Le
Antoine Pitrou added the comment:
It seems there are (intermittent?) test failures:
==
FAIL: test_pass_fds (test.test_subprocess.POSIXProcessTestCase
Changes by Antoine Pitrou :
--
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue8106>
___
___
Python-bugs-list mailing list
Unsub
New submission from Antoine Pitrou :
There are two official ways to run tests:
- "make test" for beginners
- "./python -m test [etc.]" for experts
runtests.sh serves no useful purpose and had completely outdated reporting,
making it potentially confusing for newcomers who
New submission from Antoine Pitrou :
$ ./python -m compileall
Traceback (most recent call last):
File "/home/antoine/py3k/__svn__/Lib/runpy.py", line 160, in
_run_module_as_main
"__main__", fname, loader, pkg_name)
File "/home/antoine/py3k/__svn__/Lib/runpy.p
Changes by Antoine Pitrou :
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue10707>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Works under Windows 7.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue10453>
___
___
Python-bugs-list mailin
Changes by Antoine Pitrou :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue1975>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
First, I don't think the resource module needs to be used here. Second, I don't
see why getcode() would return 200. If no valid response was received then some
kind of error should certainly be raised, shouldn't it?
-
Antoine Pitrou added the comment:
Committed in r87261.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Antoine Pitrou :
Title says it all.
--
assignee: brett.cannon
components: Documentation
messages: 124023
nosy: brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: Misc/porting should be folded in to the development FAQ
versions: Python 3.2
Changes by Antoine Pitrou :
--
nosy: +sable
___
Python tracker
<http://bugs.python.org/issue10656>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Antoine Pitrou :
Sébastien, would you like to provide an updated version of that file? The
current contents look hopelessly outdated.
--
assignee: d...@python
components: Documentation
messages: 124024
nosy: d...@python, pitrou, sable
priority: normal
severity
New submission from Antoine Pitrou :
I guess it was created for ease of hosting CGI scripts written in Python, but
is it still useful (or even functional) nowadays? Last updated goes back to
1998.
--
components: Demos and Tools
messages: 124025
nosy: brett.cannon, gvanrossum, jhylton
Antoine Pitrou added the comment:
By the way, looking at the code, readline() without any parameter is used all
over http.client, so fixing only this one use case doesn't really make sense.
--
stage: unit test needed -> needs patch
__
Antoine Pitrou added the comment:
> That's true. Near the bottom of the code, it says:
>
> # The status-line parsing code calls readline(), which normally
> # get the HTTP status line. For a 0.9 response, however, this is
> # actually the first line of the body!
>
&
New submission from Antoine Pitrou :
Both http.client and http.server claim to support HTTP 0.9. The HTTP 1.0 RFC
was filed in 1996, and 1.1 is most commonly used nowadays. We should probably
rip off 0.9 support.
--
components: Library (Lib)
messages: 124032
nosy: jhylton, orsenthil
Changes by Antoine Pitrou :
--
title: Rip off HTTP 0.9 support -> Rip out HTTP 0.9 support
___
Python tracker
<http://bugs.python.org/issue10711>
___
___
Py
Antoine Pitrou added the comment:
Here is a patch.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20052/removehttp09.patch
___
Python tracker
<http://bugs.python.org/issu
Changes by Antoine Pitrou :
--
nosy: +exarkun
___
Python tracker
<http://bugs.python.org/issue10711>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file20052/removehttp09.patch
___
Python tracker
<http://bugs.python.org/issue10711>
___
___
Python-bug
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file20053/removehttp09.patch
___
Python tracker
<http://bugs.python.org/issue10711>
___
___
Python-bug
Antoine Pitrou added the comment:
> But http.client needs to be able to communicate with any random server
> created since the dawn of time.
Well, that sounds a bit unreasonable...
> Often on 8 bit microcontrollers that haven't been updated since 1994.
Anyone with such need
Antoine Pitrou added the comment:
> Would it be worth keeping (but modifying) test_http_0_9 to verify that
> the server complains in the expected way?
Actually, I don't think the server will complain, since the request is legit.
It will send back a full response with status line
Antoine Pitrou added the comment:
Patch with adapted tests.
--
Added file: http://bugs.python.org/file20061/removehttp09-2.patch
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
This was apparently fixed in r69209.
--
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Antoine Pitrou added the comment:
That server simply doesn't respect the HTTP RFC. It fails to send a last "0"
line to indicate that the chunked transfer has completed.
--
nosy: +pitrou
resolution: -> invalid
status: open -> pending
_
Changes by Antoine Pitrou :
--
assignee: -> orsenthil
nosy: +orsenthil
___
Python tracker
<http://bugs.python.org/issue7013>
___
___
Python-bugs-list mai
Changes by Antoine Pitrou :
--
resolution: -> fixed
status: open -> closed
versions: +Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/iss
Changes by Antoine Pitrou :
--
assignee: pitrou ->
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue9990>
___
___
Python-bugs-list mai
Changes by Antoine Pitrou :
--
assignee: pitrou ->
___
Python tracker
<http://bugs.python.org/issue8844>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Antoine Pitrou :
--
dependencies: -Make gettimeofday available in time module
___
Python tracker
<http://bugs.python.org/issue8844>
___
___
Python-bug
Changes by Antoine Pitrou :
--
assignee: pitrou ->
___
Python tracker
<http://bugs.python.org/issue10538>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Antoine Pitrou :
--
assignee: pitrou ->
___
Python tracker
<http://bugs.python.org/issue5218>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
I can reproduce the crash under 2.7, but not 2.6 or 3.x here. So it might be a
separate issue.
--
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
After a bit of debugging, the crash is due to the "skipped" array being
overflowed in nfc_nfkc() in unicodedata.c. "cskipped" goes up to 21 while the
array only has 20 entries. This happens in all branches (but only crashes in
2.7 ri
Antoine Pitrou added the comment:
I think this is a bit misleading. These functions are only needed if you are
implementing a container. For the general case where you don't display another
Python object in your repr() (or you only display objects which are themselves
atomic, such as st
Antoine Pitrou added the comment:
> How about if I change the first sentence to the following?
>
> Properly implementing :attr:`tp_repr` for container types requires
> special recursion handling.
This looks good to me.
--
__
Antoine Pitrou added the comment:
Committed in r87292. Thank you for doing this!
--
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Well, removing 0.9 support doesn't make this obsolete, does it?
--
status: pending -> open
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
> It does. Doesn't it? Because I saw in your patch that you fall back on
> HTTP 1.0 behaviour when the server does not return a status line and
> in which case a Exception will be raise and this issue won't be
> observed.
I don't thi
Changes by Antoine Pitrou :
--
nosy: +asksol, jnoller
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
Thanks for the patch. First, there's no need to use multiprocessing here.
Threading would be sufficient. Second, you shouldn't use an explicit port
number, but instead let the server bind itself to whatever port is available (I
think 0 using a
Antoine Pitrou added the comment:
It turns out the test could be simplified a lot by reusing the existing
infrastructure. I've committed the modified patch in r87317 (3.2), r87318 (3.1)
and r87320 (2.7). Thank you!
--
resolution: -> fixed
stage: -> committed/rejected
s
New submission from Antoine Pitrou :
The title says it all. This is related to r87292 (issue8844).
--
components: Library (Lib), Tests
messages: 124141
nosy: db3l, pitrou, rnk
priority: normal
severity: normal
status: open
title: test_threadsignals hang on FreeBSD 6.4
type: behavior
3101 - 3200 of 16792 matches
Mail list logo
