Antoine Pitrou added the comment:
What are the results if, instead of piping through subprocess, you simply
redirect stdout to a file (using "... > myfile.txt")?
--
___
Python tracker
<http://bugs.pytho
Antoine Pitrou added the comment:
> Actually, it seems like this "-u" behaviour, should simply be the
> default for Python 3.x on Windows.
There is nothing in "-u" which should explain the behaviour you're
observing, so either way it's a bug. Making
Antoine Pitrou added the comment:
Done in 3.2 and 3.1. For 2.7 the structure of the doc page would lead to too
much repetition IMO.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: -P
Antoine Pitrou added the comment:
> Is there an easy way for me to find the code for -u?
"-u" just passes 0 for the "buffering" argument to open() when creating
stdout and stderr. Otherwise "buffering" equals -1.
You can find equivalent code for open() in Lib/_
Antoine Pitrou added the comment:
Actually, making PyMapping_Check() more robust produces a test failure in
test_builtin, because of the following code:
# Verify locals stores (used by list comps)
eval('[locals() for i in (2,3)]', g, d)
eval('[locals(
Antoine Pitrou added the comment:
> Rather than introduce "fixes" that break code and hurt performance, I
> think it would be better to deprecate PyMapping_Check() and wait for a
> fast, clean C version of the ABCs (that is supposed to be our one
> obvious way to do it).
Antoine Pitrou added the comment:
> But there has to be special handling somewhere for opening std*,
> because they are already open, unlike other files. That is no doubt
> where the bug is. Can you point me at that code?
See initstdio() in Python/py
Antoine Pitrou added the comment:
> I suppose the FileIO in _io is next to look at, wherever it can be found.
I don't get what you're looking for. FileIO is involved in both the
buffered and unbuffered cases, so it shouldn't make a difference.
In any case, please loo
Antoine Pitrou added the comment:
I adapted the patch for current py3k and committed it in r87786. Thank you for
your patience.
--
nosy: +pitrou
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
_
Antoine Pitrou added the comment:
> > As for the "clean C version of the ABCs",
> > I'm afraid we could wait quite a bit
>
> That may be true. I hope not. The ABCs were meant to solve exactly
> this problem. At this point, I would rather ignore the p
Antoine Pitrou added the comment:
Ok, actually it boils down to the following code in Modules/main.c:
if (Py_UnbufferedStdioFlag) {
#if defined(MS_WINDOWS) || defined(__CYGWIN__)
_setmode(fileno(stdin), O_BINARY);
_setmode(fileno(stdout), O_BINARY);
#endif
... which
New submission from Antoine Pitrou :
This is under a Windows 7 VM. I don't understand what the assertion means:
Z:\>__svn__\PCbuild\amd64\python_d.exe -m test -v test_multiprocessing
== CPython 3.2b2+ (py3k, Jan 6 2011, 10:56:48) [MSC v.1500 64 bit (AMD64)]
== Windows-7-6.1.7600 littl
Changes by Antoine Pitrou :
--
nosy: +brian.curtin
___
Python tracker
<http://bugs.python.org/issue10845>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Actually, it only happens if I use "-m test". If I use "-m test.regrtest" or
"Lib/test/regrtest.py" instead, it works fine.
--
nosy: +michael.foord, ncoghlan
___
Python tracker
<
Antoine Pitrou added the comment:
(I guess this means that multiprocessing under Windows is not compatible with
execution of a package through a __main__.py file...)
--
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
> So -u does do 2/3 of what my windows_binary() does :) Should I switch
> my test case to use stderr to demonstrate that it doesn't help with
> that?
Well, judging by the history of this code, selectively putting -u in
binary mode may be justifi
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue10785>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> Haypo: I believe that the consensus we've come to is that you
> shouldn't have to. FieldStorage should take a binary stream. So
> should cgi.parse. If defaulting to sys.stdin, then if stdin is text,
> they should turn it in to a bina
Antoine Pitrou added the comment:
I don't get any warnings with gcc -Wall and OpenSSL 1.0.x.
--
nosy: +pitrou
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python
Antoine Pitrou added the comment:
Anyone wants to produce an up-to-date patch for py3k?
--
keywords: +easy -patch
nosy: +pitrou
stage: -> needs patch
type: -> feature request
versions: +Python 3.3 -Python 2.6
___
Python tracker
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue10841>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue3163>
___
___
Python-bugs-list mailing list
Unsub
Changes by Antoine Pitrou :
--
nosy: +haypo
stage: unit test needed -> patch review
___
Python tracker
<http://bugs.python.org/issue1158490>
___
___
Python-
Antoine Pitrou added the comment:
Ok, done in r87792, r87793 and r87794, thank you.
--
nosy: +pitrou
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Antoine Pitrou :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue9909>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
stage: -> patch review
versions: +Python 3.2, Python 3.3 -Python 2.6
___
Python tracker
<http://bugs.python.org/issue4681>
___
_
Changes by Antoine Pitrou :
--
resolution: -> duplicate
status: open -> closed
superseder: -> Wrong powerpc define in Python/ceval.c
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Issue5369 is a duplicate with the same patch. Dave, can you apply?
--
assignee: -> dmalcolm
___
Python tracker
<http://bugs.python.org/issu
Changes by Antoine Pitrou :
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue1521196>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
In 3.2, you can instantiate a HTTPSHandler with a custom SSLContext, on which
you can load your client cert:
http://docs.python.org/dev/library/urllib.request.html#urllib.request.HTTPSHandler
http://docs.python.org/dev/library/ssl.html
Changes by Antoine Pitrou :
--
nosy: +haypo
stage: -> patch review
type: -> feature request
versions: +Python 3.3 -Python 3.1
___
Python tracker
<http://bugs.python.org/
Changes by Antoine Pitrou :
--
nosy: +haypo
stage: unit test needed -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6
___
Python tracker
<http://bugs.python.org/issue1
Antoine Pitrou added the comment:
Fixed with tests in r87797 (3.2), r87798 (3.1) and r87799 (2.7). Thank you!
--
nosy: +pitrou -BreamoreBoy
resolution: -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed
___
Pytho
Changes by Antoine Pitrou :
--
nosy: +pitrou, rosslagerwall
___
Python tracker
<http://bugs.python.org/issue1615158>
___
___
Python-bugs-list mailing list
Unsub
Changes by Antoine Pitrou :
--
assignee: jnoller ->
stage: -> patch review
type: behavior -> feature request
versions: +Python 3.3 -Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
We should do a bit sweep over unsupported platforms in 3.3.
--
nosy: +pitrou
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson -BreamoreBoy
___
Python tracker
<http://bugs.python.org/issue4346>
___
___
Python-bugs-list mailin
Changes by Antoine Pitrou :
--
nosy: +flox, loewis
___
Python tracker
<http://bugs.python.org/issue9373>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Committed in r87802 (3.2), r87803 (3.1) and r87804 (2.7). Will watch the
buildbots.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> pending
versions: -Python 2.6
_
Changes by Antoine Pitrou :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue7858>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
- should KeyboardInterrupt always exit with SIGINT, or only if it was actually
raised by a signal handler?
- if _Py_UnhandledKeyboardInterrupt is defined in Modules/main.c but used in
Python/pythonrun.c, can't it cause linker errors when embedding P
Antoine Pitrou added the comment:
Well, it merely means that OpenSSL has changed the const-ness of some of their
APIs over time. As I said I see no warnings with the most recent OpenSSL
versions. Buildbots will tell you the same story: for example, no warnings
under OS X "Snow Leopard&q
Antoine Pitrou added the comment:
> as a further extension to issue #5639 (sni) and issue #8322 this patch
> provides the ability to set ciphers in the SSLContext.wrap_socket and
> server_hostname in ssl.wrap_socket. This just makes all the ssl apis
> look the same. Rest
Antoine Pitrou added the comment:
> Server side SNI is still missing.
Right, re-opening.
--
resolution: duplicate ->
stage: -> needs patch
status: closed -> open
superseder: Support TLS SNI extension in ssl module ->
title: Support for TLS Server Name Indication exte
Antoine Pitrou added the comment:
Duplicate posting of #10852.
--
resolution: -> duplicate
status: open -> closed
superseder: -> SSL/TLS sni use in smtp,pop,imap,nntp,ftp client libs by default
___
Python tracker
<http://bug
Antoine Pitrou added the comment:
Oops, I hadn't noticed you had closed it.
--
nosy: +pitrou
resolution: duplicate ->
status: closed -> open
___
Python tracker
<http://bugs.python.
New submission from Antoine Pitrou :
Reading library source code will only be enlightening to expert users, since
most modules are not academic but real-world implementations, with all the
complications it entails. Therefore, putting a link at the top of module
sections is only confusing for
Antoine Pitrou added the comment:
I understand this patch relies on #10851. As I said there, I would rather have
SSLContext become the primary API, and the stdlib standardize on it. Part of
the stdlib, as you have witnessed, already allows the user to pass a custom
SSLContext, which is very
Changes by Antoine Pitrou :
--
stage: -> needs patch
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue8808>
___
___
Python-
Changes by Antoine Pitrou :
--
stage: -> needs patch
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue8809>
___
___
Python-
Antoine Pitrou added the comment:
As we discussed on IRC, there are two things here:
- unwrap() can give an error because it tries to shutdown the SSL layer
cleanly, and the other side doesn't support it or is already closed; unwrap()
is useful mostly if you plan to use the clear-text
Antoine Pitrou added the comment:
I will not bother backporting myself but an other core developer can do it if
(s)he desires.
--
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
> "This information" being no information, is that really all you can get out
> of OpenSSL?
Well the situation as the same as a system call which would return
failure but leave errno 0 (except that OpenSSL has its own
kind-of-errnos).
New submission from Antoine Pitrou :
contextlib.GeneratorContextManager doesn't have an underscore but it's not
documented either. Something has to be done (I would say make it private).
--
components: Library (Lib)
messages: 125683
nosy: michael.foord, ncoghlan, pitro
Antoine Pitrou added the comment:
> There was a discussion on python-dev about naming conventions in the
> standard library. There was no clear consensus that everything
> non-public should start with an underscore. Several developers thought
> that merely being undocumented or no
Antoine Pitrou added the comment:
Apparently, it's a problem on bankofamerica.com:
$ curl -v https://www.bankofamerica.com/
* About to connect() to www.bankofamerica.com port 443 (#0)
* Trying 171.161.148.173... connected
* Connected to www.bankofamerica.com (171.161.148.173) port 44
Antoine Pitrou added the comment:
Actually, perhaps the redirection loop would stop if we would send back those
cookies which the server sends us. So perhaps it's a feature request rather.
(but this still strikes me as a very poor use of
Antoine Pitrou added the comment:
> The goal is to reacquaint people with the source as an adjunct to the
> docs. The phrase use-the-source-luke used to be common in the python
> community but now many devs don't seem to be able to readily access
> the source (with it tucked
Antoine Pitrou added the comment:
> I have a few suggestions on how to make these links more useful:
The question is not how they could be more useful, but *whether* they
are useful at all. An user skilled enough to read the source code is
probably skilled enough not to require a prominen
Antoine Pitrou added the comment:
I've committed Matt's patch in r87835 (3.2), r87836 (3.1) and r87837 (2.7).
Thank you for contributing!
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
ver
Antoine Pitrou added the comment:
Well, since #10720 exists, while do you reopen this one?
--
___
Python tracker
<http://bugs.python.org/issue8844>
___
___
Pytho
Antoine Pitrou added the comment:
Ok, done in r87860.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
A backport would be more attractive if the Windows issue was fixed first...
(and I don't care about the "policy" here: anything which makes testing easier
is good IMO, and we have routinely backported tests as mentioned by someone
else)
Antoine Pitrou added the comment:
James, could you propose a proper patch? Even better if you also give a couple
of timing results, just for the record?
--
versions: +Python 3.2 -Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
Ok, closing then.
--
nosy: +pitrou
resolution: -> duplicate
status: open -> closed
superseder: -> multiprocessing.process using os.close(sys.stdin.fileno)
instead of sys.stdin.close()
___
Python track
Changes by Antoine Pitrou :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue10834>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
assignee: meador.inge -> mark.dickinson
stage: needs patch -> patch review
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/
Antoine Pitrou added the comment:
Looks like a good idea to me.
--
nosy: +benjamin.peterson, gvanrossum, pitrou
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issu
Changes by Antoine Pitrou :
--
components: +IO
nosy: +amaury.forgeotdarc, benjamin.peterson
type: -> feature request
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
Charles-François' analysis seems to be right. Note that the actual issue here
is that read() always succeeds, returning a partial result (because you're
executing a command, 'find /', which outputs a lot of data). If read() were
interru
Antoine Pitrou added the comment:
Here is a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file20328/textiorepr.patch
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
Committed in r87897. Left open for backport.
--
assignee: pitrou ->
resolution: -> accepted
stage: -> committed/rejected
type: feature request -> behavior
versions: +Python 2.7, Python 3.1 -Python 3.2
__
Antoine Pitrou added the comment:
> Attached is a tentative patch: it checks for pending signals inside
> _bufferedreader_read_generic, fileio_readall, and rawiobase_readall.
> I tested quickly on regular files and on pipes, and handlers are now
> called on time. As a an obvious
Antoine Pitrou added the comment:
There are still sporadic failures:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.x/builds/684/steps/test/logs/stdio
Of course, it seems to be because of stupid urllib wrapping the socket.error
inside an IOError:
Traceback (most recent
Antoine Pitrou added the comment:
Well, the password-checking scheme uses a one-byte check against the zip header
for consistency.
So there is a (near) 1/256 chance of false positives, that is of bad passwords
mistakenly detected as good; then the ZipFile class proceeds with unarchiving
and
Changes by Antoine Pitrou :
--
nosy: +pitrou
stage: -> patch review
type: -> feature request
___
Python tracker
<http://bugs.python.org/issue10866>
___
___
Antoine Pitrou added the comment:
I confirm that it works reliably under 3.2, while it hangs as reliably under
2.7 and 3.1. Since fixing involves a C extension that is too heavy to backport
to bugfix branches, I suggest closing.
By the way: triagers, please don't set stage to "
Antoine Pitrou added the comment:
Looks like an issue in test_site rather than site.py itself (which has
dedicated code to add a third site directory under framework builds). The
test_site failure is not enough to hold the release, IMO.
Given Ronald's absence, I think Ned could
Changes by Antoine Pitrou :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue10784>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
> Tested on Linux & FreeBSD - it should work on solaris but since it
> needs to link with the sendfile library and I have no idea how to link
> the posix module with the sendfile library only on Solaris, i couldn't
> test it.
Since the p
Antoine Pitrou added the comment:
Ok, so let's close the issue. The fix can't reasonably be backported since it
involves a whole new C extension and a rather large chunk of new code.
--
nosy: +gregory.p.smith
resolution: -> out of date
status: open -> closed
versio
Antoine Pitrou added the comment:
The aforementioned python-dev thread (available at
http://mail.python.org/pipermail/python-dev/2010-June/101186.html ) explains
things quite well.
The mailbox module needs to be modified to use binary I/O, both for
functionality and for speed. Right now, I
Antoine Pitrou added the comment:
[...]
>
> gcc-4.6 -O1 -ftree-vectorize
> -
> 0x00480991 <+5041>: mov%eax,%ecx
> 0x00480993 <+5043>: sub%edx,%ecx
> 0x00480995 <+5045>: mov%ecx,(%r12
Antoine Pitrou added the comment:
Agreed with Charles-François, this is normal behaviour since the bytes written
on stdout are buffered (up to a certain size). If calling flush() doesn't solve
the issue, please reopen the issue.
--
resolution: -> invalid
status: open -
Changes by Antoine Pitrou :
--
stage: -> patch review
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue10896>
___
___
Python-bugs-list
Antoine Pitrou added the comment:
> msg28537 shows a version with flush, and says that it fails
I cannot reproduce. Either with Python 2.5.2 (!), 2.7 or 3.2, on a remote
Debian system. Even using "kill -9" on the local ssh process does shut down the
remote Python process.
If
Antoine Pitrou added the comment:
Thanks for the patch! Committed in r87958 (3.2), r87959 (3.1) and r87961 (2.7).
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bug
Antoine Pitrou added the comment:
The problem is that it's a change in semantics. So it definitely can't be
backported to the bugfix branches, nor committed into 3.2 which is in feature
freeze now.
The question is which behaviour is the most expected by users of the module.
I'
Antoine Pitrou added the comment:
My take on this:
- adding underscores to locally-defined private functions is good. +1
- -0.5 on "from warnings import warn as _warn"; it's useless complication,
users should be able to realize warn() is a public API of the warnings module,
not
Antoine Pitrou added the comment:
Oh, by the way, it can be good to check that the APIs are not used too widely.
Example for such a query:
http://www.google.com/codesearch?q=lang%3Apython%20do_longs&hl=fr
(in this case, it's clear that only copies of the stdlib reference that
Antoine Pitrou added the comment:
Agreed with Georg. No OS resource is leaking if the file is explicitly closed
(since it releases the underlying file descriptor). That the Python "file
object" is still attached somewhere is of secondary importance.
--
nos
Antoine Pitrou added the comment:
> It allows garbage collection to close the file object if there are no
> more references to it.
This is a very bad policy to begin with. Garbage collection can be delayed for
a number of reasons:
- someone might be running your program on a
Antoine Pitrou added the comment:
> As James said I have written the patch using only regular expressions .
> This is going to be my first patch . I need help writing the test for it
You will find the current tests in Lib/test/test_re.py.
To execute them, run:
$ ./python -m test.regrt
Antoine Pitrou added the comment:
> On the other hand, having this precedent might give passers-by and
> perhaps future stdlib developers the idea that a convention has been
> adopted by the stdlib
Could we simply state in PEP 8 that annotations have no official meaning and
th
Antoine Pitrou added the comment:
This is an interesting approach. The problem is that AFAICT the issue is not
limited to readline. If you call e.g. read(1) and the socket times out
after having returned the first 5000 bytes, then those 5000 bytes might get
lost as well (depending on
Antoine Pitrou added the comment:
By the way, I recently fixed the makefile() documentation:
“The socket must be in blocking mode; it can have a timeout, but the file
object’s internal buffer may end up in a inconsistent state if a timeout
occurs.”
(in http://docs.python.org/dev/library
Antoine Pitrou added the comment:
Ok, closing as duplicate.
--
resolution: -> duplicate
status: open -> closed
superseder: -> urllib.request.urlretrieve hangs
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
issue10577 is a duplicate. See an URL allowing reproducing in msg122831.
--
nosy: +pitrou
priority: high -> normal
stage: unit test needed -> needs patch
title: urllib.request.urlretrieve hangs -> urllib.request.urlretrieve hangs
wa
Antoine Pitrou added the comment:
> """Generally there is no guarantee that a buffered object works
> "properly" when the raw IO object raises some exception
> intermittently"""
>
> I disagree. EINTR is a classic case of this and is some
Antoine Pitrou added the comment:
> > That's my opinion too. So, instead, of doing the above surgery inside
> > the IO stack, the SocketIO layer could detect the timeout and disallow
> > further access. What do you think?
>
> So after a timeout occurs the
3401 - 3500 of 16792 matches
Mail list logo
