New submission from Antoine Pitrou :
http.server has support for old-style HTTP 0.9 requests ("command path" without
a version string). This issue proposes to remove this support, since there are
probably no clients around which still issue such requests.
See issue10711 for the c
Antoine Pitrou added the comment:
I'm opening a separate issue (issue10721) for the server side and retargetting
this issue to client support. Patch attached.
--
title: Rip out HTTP 0.9 support -> Rip out HTTP 0.9 client support
Added file: http://bugs.python.org/f
Antoine Pitrou added the comment:
Committed in r87323.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: -Python 3.3
___
Python tracker
<http://bugs.python.or
Changes by Antoine Pitrou :
--
stage: -> patch review
versions: +Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue10723>
___
___
Python-
Changes by Antoine Pitrou :
--
nosy: +loewis, tim.golden
___
Python tracker
<http://bugs.python.org/issue1449496>
___
___
Python-bugs-list mailing list
Unsub
Changes by Antoine Pitrou :
--
stage: unit test needed ->
versions: +Python 3.2 -Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/issue1
Antoine Pitrou added the comment:
The _total_size thing looks like a wildly bad idea to me, since it's so poorly
defined (and relying on a couple of special cases).
Also, "currsize" is quite bizarre. Why not simply "size"?
Antoine Pitrou added the comment:
> Velko: on the other hand, given Victor's research, I don't see float
> seconds since an epoch appearing anywhere as a standard.
Well, given that we already have fromtimestamp(), this sounds like a
poor argument against a totimestamp() method
Antoine Pitrou added the comment:
> 1. Different application may need different epoch and retained
> precision depends on the choice of the epoch.
But then why does fromtimestamp() exist?
And returning a (seconds, microseconds) tuple does retain the precision.
> 2. The code above w
Antoine Pitrou added the comment:
Patch committed in r87340.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
Ok, I committed the patch in r87341 (3.2), r87342 (3.1) and r87343 (2.7).
--
priority: high -> normal
stage: patch review -> needs patch
title: Lib/threading.py causes infinite recursion when running as verbose ->
test_threading hang when r
Antoine Pitrou added the comment:
> Updated to use ABCs but still relies on user objects implementing
> __sizeof__. So it is accurate whenever sys.getsizeof() is accurate.
I'm really -1 on this. It's better to give no measurement than to give a
totally wrong indication. The f
Antoine Pitrou added the comment:
> >> 1. Different application may need different epoch and retained
> >> precision depends on the choice of the epoch.
> >
> > But then why does fromtimestamp() exist?
>
> A better question is why datetime.utcfromtimestamp(s
Antoine Pitrou added the comment:
Now that 0.9 client support has been removed, this can proceed (at least for
3.2).
--
___
Python tracker
<http://bugs.python.org/issue6
Antoine Pitrou added the comment:
> > ??? EPOCH is not even a constant in the datetime module.
> >
> No, and it does not belong there.
And so what was your point exactly?
> A higher level library that uses
> seconds since epoch for interchange
I don't think the
Antoine Pitrou added the comment:
Here is a patch limiting line length everywhere in http.client, + tests (it
also affects http.server since the header parsing routine is shared).
--
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20100/httplinelength.pa
New submission from Antoine Pitrou :
It really looks like a subprocess issue:
==
ERROR: test_usage (test.test_cmd_line.CmdLineTest)
--
Traceback (most recent
Antoine Pitrou added the comment:
> Yes, UTC not being a proper acronym in any human language is one
> problem,
Ok. Too bad you don't live on the same planet than most of us. I bail
out.
--
___
Python tracker
<http://bugs.python
Antoine Pitrou added the comment:
> When running a Python script from within a desktop application (which
> embeds Python and has /LARGEADDRESSAWARE set) [...]. Essentially this
> discounts Python scripts as an option for automation in this case.
Well, if you already embed Pytho
Antoine Pitrou added the comment:
Partially backported in r87382 (3.1) and r87383 (2.7). Not everything could be
merged in because of HTTP 0.9 support and (in 2.7) a slightly different
architecture. Thank you.
--
stage: patch review -> committed/rejected
status: open ->
New submission from Antoine Pitrou :
In getargs.c, in addcleanup_convert(), PyCapsule_SetContext() is called with a
second argument "int (*destr)(PyObject*,void*)", but it really expects a "void
(*PyCapsule_Destructor)(PyObject *)".
I'm not sure it's a good
Antoine Pitrou added the comment:
> I fail to see the problem. The context is a plain void*, not
> (necessarily) a function pointer, and getargs uses it with the same
> type it put in. Why do you think PyCapsule_Destructor is of relevance?
Woops, sorry. Apparently I
Changes by Antoine Pitrou :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10732>
___
___
Python-bugs-
New submission from Antoine Pitrou :
It looks like the Windows buildbots have been failing since the tk upgrade (at
least, I'm assuming it is related since there haven't been any tk changes
recently).
=
Antoine Pitrou added the comment:
> Perhaps there is a race condition with cleaning up the p2c pipe from a
> previous run?
This would be rather strange, since it would have a different file descriptor.
Or it means there's a bug somewgere (perhaps in subprocess, or perhaps even
New submission from Antoine Pitrou :
This has been happening recently on our Windows Server 2008 buildbot:
==
FAIL: test_first_completed (test.test_concurrent_futures.ThreadPoolWaitTests
Antoine Pitrou added the comment:
> Instead of the platform module, one must resort to hacks like examining
> sys.maxsize
I'm not sure why you think it's a hack. To me, it's, by construction, the right
way to check for 64-bitness (and also the easiest since it doesn&#
Antoine Pitrou added the comment:
> It's only a hack in the sense that platform.architecture is the
> documented interface in the std library to report "bits" and,
> unfortunately, users try to use it to determine whether running in
> 64-bit or 32-bit mode. For
New submission from Antoine Pitrou :
PyGILState_GetThisThreadState() is "documented" in Include/pystate.h but not in
the official docs. It should be documented along PyGILState_Ensure() and
friends.
--
assignee: d...@python
components: Documentation
messages: 124394
nosy: d
Antoine Pitrou added the comment:
> > The problem is to detect that stderr file descriptor changes (eg. closed,
> > duplicated, reopened, etc.). I don't think that it's possible to detect
> > such
> > changes (with a portable function).
>
> When I sa
Antoine Pitrou added the comment:
Does it work properly if CC and CXX are not defined by the user?
(probably a naïve question, sorry)
--
nosy: +pitrou
stage: -> patch review
type: -> behavior
versions: +Python 3.1, Python 3.2
___
Python t
Antoine Pitrou added the comment:
Agreed it should probably be a release blocker. I guess it has to do with (not)
following symlinks, right?
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue10
Changes by Antoine Pitrou :
--
stage: unit test needed -> patch review
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/iss
Changes by Antoine Pitrou :
--
nosy: +mark.dickinson, ncoghlan
___
Python tracker
<http://bugs.python.org/issue10742>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pitrou added the comment:
Thanks for the patch. A couple of comments:
- the C code is misindented in some places (using 8 spaces rather than 4)
- you should use support.unlink consistently in the tests (rather than
sometimes os.unlink or posix.unlink)
- when cleaning up in tests
Antoine Pitrou added the comment:
> Adding a warning sounds like a good idea. Is it reasonable to include
> a recommended cross-platform approach in the platform doc, like either
> the sys.maxsize test or the struct.calsize("P") test (which is used as
>
New submission from Antoine Pitrou :
"make html" in the Doc directory and then:
[...]
/home/antoine/py3k/__svn__/Doc/howto/logging.rst:507: WARNING: duplicate object
description of logging.logging.Formatter.__init__, other instance in
/home/antoine/py3k/__svn__/Doc/library/loggin
Changes by Antoine Pitrou :
--
nosy: +d...@python
___
Python tracker
<http://bugs.python.org/issue10749>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
I'm committing a doc update in r87421 with a suggestion to use sys.maxsize.
I'll let Marc-André decide how to deal with the rest of the patch.
--
___
Python tracker
<http://bugs.python.o
Changes by Antoine Pitrou :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue10746>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Antoine Pitrou :
This really looks backwards:
>>> f = open("LICENSE", "rb")
>>> f.name = "bar"
Traceback (most recent call last):
File "", line 1, in
AttributeError: attribute 'name' of
Antoine Pitrou added the comment:
Here is a patch.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20132/io_roattrs.patch
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
Le mardi 21 décembre 2010 à 20:36 +, Benjamin Peterson a écrit :
> Benjamin Peterson added the comment:
>
> 2010/12/21 Antoine Pitrou :
> >
> > Antoine Pitrou added the comment:
> >
> > Here is a patch.
>
> I assu
Antoine Pitrou added the comment:
Thank you, committed in r87427 (3.2), r87428 (3.1) and r87429 (2.7).
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Antoine Pitrou :
--
assignee: -> ocean-city
nosy: +loewis, ocean-city
___
Python tracker
<http://bugs.python.org/issue10752>
___
___
Python-bugs-lis
Antoine Pitrou added the comment:
> (1) Is there documentation for the 'smalltable' field of the Py_buffer
> struct anywhere? What are the requirements for the exporter here?
No, and no particular requirements AFAIR. It is a piece of internal
storage aimed at avoiding the na
Antoine Pitrou added the comment:
The list of errnos indicating missing access seems open-ended.
Things such as:
[ENAMETOOLONG]
The length of a component of a pathname is longer than {NAME_MAX}.
[ENOENT]
A component of path does not name an existing file or path is an empty
string
Changes by Antoine Pitrou :
--
nosy: +brian.curtin
___
Python tracker
<http://bugs.python.org/issue10737>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +gps
___
Python tracker
<http://bugs.python.org/issue10763>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> A person writing an exception handler should have control over what
> the user sees.
There is already support for this in the traceback module (see the
"chain" parameter to various funcs).
--
__
Antoine Pitrou added the comment:
> I'm not sure how that's going to help as I don't want my library code
> to be responsible for printing out exceptions, I just want them to
> print reasonably -- and it seems very unreasonable to have the
> exception I'm
Antoine Pitrou added the comment:
+1 on simply removing this test. *.xmlrpc.com look(s) totally unmaintained.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue6
New submission from Antoine Pitrou :
This on the Windows Server 2008 buildbot:
(http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%203.x)
Re-running test 'test_logging' in verbose mode
test_flat (test.test_logging.BuiltinLevelsTest) ... FAIL
test_neste
Antoine Pitrou added the comment:
> During handling of the above exception, another exception occurred:
>
> This is a blatant falsehood -- another exception did not occur, a
> different exception was raised.
This doesn't make any difference in any other context, so why would
Antoine Pitrou added the comment:
> and, finally, if all I have is
>
> except ValueError as exc:
> raise AttributeError("blah")
>
> I just get the normal, previous context free, traceback.
And what if the exception
Antoine Pitrou added the comment:
> > And what if the exception is raised from a subroutine?
>
> Well, if I have it surrounded by a try/except block, presumably I'm
> aware that an exception could be raised. ;)
I'm talking about the exception rai
Antoine Pitrou added the comment:
Le mercredi 29 décembre 2010 à 01:15 +, Ethan Furman a écrit :
> Ethan Furman added the comment:
>
> > I'm talking about the exception raised from the except block.
>
> So was I -- why should this:
>
> try:
> x = y /
Antoine Pitrou added the comment:
This should be easy to fix, if only the "readable" and "writable" methods are
needed. Do you want to try writing a patch?
--
___
Python tracker
<http://bug
Antoine Pitrou added the comment:
> While you're at it, maybe someone could add an 'open' function to bz2
> to make it symmetrical with gzip as well :-).
That's a nice idea, but quite orthogonal to this issue.
--
___
Antoine Pitrou added the comment:
> C or not, wrapping a BZ2File instance with a TextIOWrapper to get text
> still seems like something that someone might want to do. I doubt it
> would take much modification to give BZ2File instances the required
> set of methods.
BZ2File uses F
Antoine Pitrou added the comment:
> Do Python devs really view gzip and bz2 as two totally completely
> different animals? They both have the same functionality and would be
> used for the same kinds of things. Maybe I'm missing something.
Well, the reality of divergent
Antoine Pitrou added the comment:
> Arguably, it is not a bug if codec's decode method rejects unicode
> strings with a TypeError.
Agreed, but it would be better if it did so deliberately and explicitly, rather
than as a result of a bogus f
Antoine Pitrou added the comment:
There are open issues for specific modules: #8808 for imaplib, #8809 for
smtplib.
In 3.2, poplib already has support for SSL contexts, as do ftplib, http.client
and nntplib. If I'm missing a module please tell me.
--
resolution: -> duplicat
Antoine Pitrou added the comment:
> > using `None` as the cause of an exception would be the
> > best solution in my opinion:
>
> +1
We are talking about context, not cause.
--
___
Python tracker
<http://bugs
Antoine Pitrou added the comment:
Le vendredi 31 décembre 2010 à 00:07 +, Patrick W. a écrit :
> Patrick W. added the comment:
>
> Antoine Pitrou (pitrou) at 2010-12-30 18:32 (UTC)
> > We are talking about context, not cause.
>
> Yes, but - as said before - obviou
Antoine Pitrou added the comment:
While this patch looks conformant to the documentation, it is very likely to
break code in the wild. Even in the stdlib, there are uses of makefile() +
socket timeouts (e.g. in http.client and urllib). It would be better to find a
way to make readline
Changes by Antoine Pitrou :
--
nosy: +amaury.forgeotdarc, haypo, loewis
___
Python tracker
<http://bugs.python.org/issue10801>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
Thanks for the patch. Comments/questions:
- please don't use C++-style comments ("//") in C code; some compilers can
choke on them
- should the code path be also enabled for netbsd? (or other variants?)
- why does the test silence socket.
Antoine Pitrou added the comment:
> Hmm, it may indeed be the best option to add a new directive option to
> say "this function does not take keyword args". It would result in
> some form of unobtrusive but noticeable output in HTML.
Isn't it kind of a CPython
Changes by Antoine Pitrou :
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue10802>
___
___
Python-
Antoine Pitrou added the comment:
I've tried the patch under OpenSolaris and the test fails (EAGAIN),
meaning that accept() semantics there are the same as under BSD:
==
ERROR: testInherit
Antoine Pitrou added the comment:
> Attached is a patch which basically uses fcntl if necessary to remove
> the close-on-exec flag, and tests.
Python adds extra output at the end of stderr when compiled in debug
mode. Therefore you first have to strip that output, like this:
Antoine Pitrou added the comment:
After further testing, it turns out that Windows exhibits BSD-like behaviour
too. So instead of complicating the flag-setting code again, I suggest an
alternative of doing it in the Python wrapper. Patch attached.
--
Added file: http
Antoine Pitrou added the comment:
Patch committed in r87639 (3.2), r87641 (3.1) and r87640 (2.7). Thank you!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: -Python 2.5, Python 2.6
_
Antoine Pitrou added the comment:
Patch committed in r87643, thank you.
--
nosy: +pitrou
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> Updated patch for debug mode. Does this also need to be applied for 3.1?
Yes, but we can port it ourselves (unless you're really motivated)
--
___
Python tracker
<http://bugs.python.org
Antoine Pitrou added the comment:
Patch works fine, thank you. Here is an attempt at a slightly more readable
code by refactoring.
--
Added file: http://bugs.python.org/file20230/sp.patch
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
> $(CC) and $(CXX) should be expanded by `make`, but configure.in
> contains wrong quoting, which results in incorrect expansion during
> running `configure`.
Oops, sorry. Should be fixed, now.
--
_
Antoine Pitrou added the comment:
This further patch also addresses issue9905 (incorporating Ross' tests).
--
Added file: http://bugs.python.org/file20234/sp2.patch
___
Python tracker
<http://bugs.python.org/is
Changes by Antoine Pitrou :
--
assignee: -> ghaering
nosy: +ghaering
___
Python tracker
<http://bugs.python.org/issue10811>
___
___
Python-bugs-list mai
Changes by Antoine Pitrou :
--
nosy: +pitrou
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue10805>
___
___
Python-bugs-list mailin
New submission from Antoine Pitrou :
See e.g. http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.1
test_time
f:\dd\vctools\crt_bld\self_x86\crt\src\asctime.c(130) : Assertion failed: ( (
tb->tm_mday >= 1 ) && ( ( ( _days[ tb->tm_mon + 1 ] - _days[ tb->tm_mon
Antoine Pitrou added the comment:
Agreed, not a Python bug.
--
nosy: +pitrou
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Antoine Pitrou added the comment:
First couple comments:
- you don't have to modify Misc/NEWS yourself; it will probably make patch
maintenance easier
- it would seem more natural for readv() to take a sequence of writable buffers
(such as bytearrays) instead; I don't think t
Antoine Pitrou added the comment:
This new patch makes tests more comprehensive (closes all combinations of the
three standard fds).
--
Added file: http://bugs.python.org/file20242/sp3.patch
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
For the record, I get the following failures under OpenSolaris:
==
ERROR: test_lutimes (test.test_posix.PosixTester
Antoine Pitrou added the comment:
According to the posix_fallocate() man page under OpenSolaris:
EINVALThe len argument is less than or equal to zero, or
the offset argument is less than zero, or the
underlying file system does not support this
Antoine Pitrou added the comment:
This is under 3.1, not 3.2.
--
___
Python tracker
<http://bugs.python.org/issue10814>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
I can reproduce under Windows 7, 32-bit debug build, with the following line:
time.asctime((12345, 1, 0, 0, 0, 0, 0, 0, 0))
Apparently, the debugger tells me that tb->tm_mday is 0.
Actually, most of the tb fields are 0 except tm_year (10445), tm_wday (1)
Antoine Pitrou added the comment:
I agree with Martin here.
Also, since test_site is a special case here, perhaps it could arrange to
launch its test cases in a subprocess? I don't think complicating regrtest is
the most maintainable app
Antoine Pitrou added the comment:
Committed in r87695 (3.2), r87696 (3.1) and r87697 (2.7).
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1
___
Python tracker
<http://bug
Antoine Pitrou added the comment:
Fixed in issue10806.
--
nosy: +pitrou
resolution: -> duplicate
status: open -> closed
superseder: -> Subprocess error if fds 0,1,2 are closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Thank you for the patch! It is committed in r87698 (3.2), r87699 (3.1) and
r87700 (2.7).
--
nosy: +pitrou
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: -Python 2.6
_
Antoine Pitrou added the comment:
Well, under 2.x, print_traceback(None, None, None) would just print "None", but
I'm not sure that's a supported use case.
--
nosy: +ncoghlan
___
Python tracker
<http://bug
Antoine Pitrou added the comment:
> I like the logic of Antoine's patch much better (basing this on
> whether the listening socket had a timeout). I wonder whether it's
> correct though if there is a defaulttimeout: shouldn't it then leave
> the timeout on the socke
Antoine Pitrou added the comment:
Le lundi 03 janvier 2011 à 19:37 +, R. David Murray a écrit :
> Or another idea: change site so that it does not execute on import,
> but instead the machinery that currently imports test site runs a
> 'setup' function after it does t
Changes by Antoine Pitrou :
--
priority: high -> low
versions: -Python 3.2
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mai
Changes by Antoine Pitrou :
--
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue444582>
___
___
Python-bugs-list mailin
Changes by Antoine Pitrou :
--
resolution: accepted ->
___
Python tracker
<http://bugs.python.org/issue444582>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Antoine Pitrou :
--
stage: -> patch review
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue10566>
___
___
Python-
3201 - 3300 of 16792 matches
Mail list logo
