Antoine Pitrou added the comment:
Interesting! If you are motivated, a further approach would be to expose the
compressor and decompressor objects from the C extension, and write the file
object in Python (as in Lib/gzip.py).
> One thing I was unsure of is how to handle exceptions that oc
Antoine Pitrou added the comment:
> How would I go about doing this? Would it be sufficient to raise a
> DeprecationWarning if the argument is provided by the caller, and add
> a note to the docstring and documentation?
Yes, totally.
--
_
New submission from Antoine Pitrou :
Since r87651, subprocess can raise a RuntimeWarning if pipe2() fails.
I'm not sure there's any point in that, since it's very low-level and it's
nothing the user can do about anyway.
Ironically, there is no warning if pipe2() is
Antoine Pitrou added the comment:
This can be seen on the sparc Debian buildbot by the way:
/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/subprocess.py:1085:
RuntimeWarning: pipe2 set errno ENOSYS; falling back to non-atomic pipe+fcntl.
c2pread, c2pwrite = _create_pipe()
/home
Antoine Pitrou added the comment:
> > The expectation is that it returns the memory footprint of the given
> > object, and only it (not taking into account sharing, caching,
> > dependencies or anything else).
>
> It would be nice if this was a well-defined definition
Antoine Pitrou added the comment:
> Which experts you had in mind?
People who know how the Python implementation works.
--
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
> Even if you know implementation quite well a single number per object
> does not provide enough information.
Enough information for what? It can certainly provide information about
the overhead of that particular object (again, regardless of s
Antoine Pitrou added the comment:
Well, given you have the line number at which the method is defined, it is easy
to know which class it belongs to.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
So, I added some debug info to test_pass_fds:
-- fds that should have been closed: {5, 6, 7, 8, 9, 10, 11, 12, 13}
-- fds that remained open: {0, 1, 2, 3, 5}
-- debug info:
0 8194 posix.stat_result(st_mode=8592, st_ino=12582920, st_dev=82051072,
st_nlink=1
Antoine Pitrou added the comment:
I managed to get further debug info from the OpenIndiana buildbot:
-- maxfd = 65536
-- fds that should have been closed: {5, 6, 7, 8, 9, 10, 11, 12, 13}
-- fds that remained open: {0, 1, 2, 3, 5}
-- debug info:
0 2 posix.stat_result(st_mode=4096, st_ino
Changes by Antoine Pitrou :
--
stage: -> needs patch
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue6926>
___
___
Python-
Antoine Pitrou added the comment:
> 'D' denotes a door file. There are several of them in the system; the
> following ones (from /var/run) match the time stamp:
Thanks for the explanation!
> It's common for library routines to open a door and keep it open for
>
New submission from Antoine Pitrou :
Solaris has an additional kind of special files named doors. The standard
headers define the following macro:
#define S_ISDOOR(mode) (((mode)&0xF000) == 0xd000)
Perhaps it would be nice to include the equivalent in the stat module.
(although fun
Antoine Pitrou added the comment:
> Thanks for the feature request. It seems trivial to implement, but not
> trivial to test :).
You can test against an existing file, such as "/var/run/syslog_door"
(given its name, it is unlikely to be anything o
Antoine Pitrou added the comment:
> I do know, but when you are working inside a zone, I am not sure you
> can count of that file being always present. Syslog even could be
> disabled or not available inside a zone.
Then you can just skip the test.
> I am thinking about how to
Antoine Pitrou added the comment:
> But now I am wondering... Which organization defines flags like
> S_IFSOCK or S_IFIFO?. Posix members?. I am worried about flag
> collision between OSs.
They are defined unconditionally in Lib/stat.py.
> For instance, if DOORS were a real fla
Antoine Pitrou added the comment:
> * The read*() methods are implemented very inefficiently. Since they
> have to deal with the bytes objects returned by
> BZ2Decompressor.decompress(), a large read results in lots of
> allocations that weren't necessary in the C implementat
New submission from Antoine Pitrou :
This was found by Nadeem in issue5863.
Index: Lib/test/test_bz2.py
===
--- Lib/test/test_bz2.py(révision 88199)
+++ Lib/test/test_bz2.py(copie de travail)
@@ -86,7 +86,7
Antoine Pitrou added the comment:
There's a missing conversion in mailbox.patch. Running with -bb shows the
issue. Here is an updated patch.
--
Added file: http://bugs.python.org/file20532/mailbox2.patch
___
Python tracker
<http://bugs.py
Antoine Pitrou added the comment:
Would it be possible to add a test case to the patch?
--
nosy: +georg.brandl, pitrou
stage: -> patch review
type: behavior -> crash
versions: +Python 3.1, Python 3.2 -Python 2.6
___
Python tracker
Antoine Pitrou added the comment:
Committed in r88204 (3.2), r88205 (3.1) and r88206 (2.7).
--
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions: +Python 2.7
___
Python track
Changes by Antoine Pitrou :
--
stage: needs patch -> patch review
versions: +Python 3.3 -Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
For the record, you don't have to use pax, recent GNU tar handles xz fine (use
the -J option).
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
> Both cases indicate the users desire to change a specific locale
> setting and thus - of course - all the changes which that implies!
> So why should there be a difference?
I don't think it's intentional. I would be +1 on changing to
g
Antoine Pitrou added the comment:
> >> Both cases indicate the users desire to change a specific locale
> >> setting and thus - of course - all the changes which that implies!
> >> So why should there be a difference?
> >
> > I don't think it
Antoine Pitrou added the comment:
Looks good to me.
--
resolution: -> accepted
stage: needs patch -> commit review
___
Python tracker
<http://bugs.python.org/i
New submission from Antoine Pitrou :
Here are the system calls when importing a single pure Python module:
stat("/home/antoine/py3k/py3k/Lib/copyreg", 0x7fff1ed1f740) = -1 ENOENT (No
such file or directory)
open("/home/antoine/py3k/py3k/Lib/copyreg.cpython-32m.so", O_RDON
Antoine Pitrou added the comment:
Well, I think you can commit.
--
___
Python tracker
<http://bugs.python.org/issue10989>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
Here is a patch to ignore door files when running the fd_status script. It
seems to eradicate the intermittent failures on the solaris buildbots.
--
keywords: +patch
Added file: http://bugs.python.org/file20600/spdoors.patch
Antoine Pitrou added the comment:
+os.mkdir(os.path.join(TESTFN, TESTFN))
Please don't. This will break the day TESTFN becomes a non-trivial path.
+def test_make_bad_fd(self):
+fd = support.make_bad_fd()
+self.assertRaises(OSError, os.write, fd, b"foo&quo
Antoine Pitrou added the comment:
Works fine here.
--
nosy: +pitrou
resolution: -> works for me
___
Python tracker
<http://bugs.python.org/issue11059>
___
_
Antoine Pitrou added the comment:
Nick, a more problematic issue is that __main__ is always called __main__,
regardless of whether it is actually imported as the real "main module" or
through a regular import. This means that it is impossible to discriminate
between both uses by
Antoine Pitrou added the comment:
Actually, forget that (!). The following patch seems to work:
Index: Lib/multiprocessing/forking.py
===
--- Lib/multiprocessing/forking.py (révision 88224)
+++ Lib/multiprocessing/forking.py
Antoine Pitrou added the comment:
> (Replaced patch file to fix a typo in a comment)
Does that patch still work if the objects marshalled between parent and
child refer to classes living in the __main__.py module?
--
___
Python tracker
&l
Changes by Antoine Pitrou :
--
components: +Interpreter Core -None
nosy: +loewis
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue11067>
___
_
Changes by Antoine Pitrou :
--
keywords: +easy
stage: -> needs patch
versions: +Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
> > Something has gone out of control here. Why do we need to check so many
> > alternative locations?
>
> What change do you propose?
First, I don't understand why we need to check both "foo.so" and
"foomodule.so"
Antoine Pitrou added the comment:
> 'Had to look on a sunday once again, and it is still impossible to
> clone branches/release2.7-maint.
It failed here on one attempt and succeeded on others. "hg verify" ran fine
too, including on the server.
I'm closing the issu
Changes by Antoine Pitrou :
--
stage: needs patch -> patch review
versions: +Python 3.3 -Python 2.6, Python 3.1
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
As far as I can tell, the same change also needs to be done in build-amd64.bat
and clean-amd64.bat.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
By the way, the order of these lines in clean-amd64.bat looks wrong:
cd PCbuild
@echo Deleting .pyc/.pyo files ...
del /s Lib\*.pyc Lib\*.pyo
--
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
Oh, and the regrtest command line in test-amd64.bat lacks some options ("-rwW
-n") compared to test.bat.
--
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
You don't have to use any staticmethod here (actually, staticmethod is an
anti-pattern in Python). Just write:
class Foo():
def __init__(self):
self.thread = Thread(target=self.runner)
self.thread.start()
def runner(self):
#
Antoine Pitrou added the comment:
Patch verified to work under Linux and win32. It looks good, except for tab
characters in the Modules/_ctypes/_ctypes_test.c (indentation of C files should
use 4 spaces); that's a detail that we can fix ourselves.
--
assignee: th
Antoine Pitrou added the comment:
Let's reopen until then.
--
assignee: pitrou ->
resolution: fixed -> accepted
stage: -> committed/rejected
status: closed -> open
versions: -Python 3.2
___
Python tracker
<http://bugs.p
Antoine Pitrou added the comment:
The issue looks quite clear: cStringIO.write() asserts that the required
storage size is less than INT_MAX. Therefore, in all likelihood, the pickle
dump is simply larger than 2GB.
Now, the cStringIO structures seem 64-bit safe, so the comparison to INT_MAX
Antoine Pitrou added the comment:
I wouldn't be surprised if the crash was related to some concurrency issues
during shutdown. Other (Python or not Python) threads can continue running
while the main thread is running Py_Finalize; this might be the reason; or
perhaps some extension mo
Antoine Pitrou added the comment:
Ok, committed in r88284 (3.2), r88285 (3.1) and r88286 (2.7). Thank you!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bug
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue11086>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> Apparently, contributor have the illusion that the values they put
> into the file are somehow standardized, when they are actually not.
Are there actual bugs with that or is it merely a theoretical c
Changes by Antoine Pitrou :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue11022>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Antoine Pitrou :
--
assignee: -> lukasz.langa
nosy: +lukasz.langa
___
Python tracker
<http://bugs.python.org/issue11089>
___
___
Python-bugs-lis
Changes by Antoine Pitrou :
--
versions: +Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue11089>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pitrou added the comment:
Any benchmark numbers for the slice cache?
Also, is the call to PyObject_INIT necessary?
--
___
Python tracker
<http://bugs.python.org/issue10
Antoine Pitrou added the comment:
> I ran the list tests in pybench and got this:
>
> Test minimum run-timeaverage run-time
> thisother diffthis
Changes by Antoine Pitrou :
--
resolution: fixed ->
stage: committed/rejected -> patch review
status: closed -> open
type: crash -> behavior
___
Python tracker
<http://bugs.pytho
Antoine Pitrou added the comment:
> I find it interesting that the base line is way below the other
> timings. That makes me think it's actually worth caching constant
> slice instances, as CPython already does for tuples.
Indeed. I have never touched it, but I suppose it needs
Antoine Pitrou added the comment:
Ok, things are at best 3-4% faster here (often unchanged).
--
versions: -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue11
Antoine Pitrou added the comment:
> That's an interesting point.
>
> Do you know of places where we use fd 2 instead of sys.stderr?
We normally don't. One reason is that buffering inside sys.stderr can
make ordering of output incorrect. There are some places in C code w
Changes by Antoine Pitrou :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue11107>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +exarkun, loewis
___
Python tracker
<http://bugs.python.org/issue7111>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> > We normally don't. One reason is that buffering inside sys.stderr can
> > make ordering of output incorrect. There are some places in C code where
> > we do "fprintf(stderr, ...)" but that's for specialized debugging
&g
Antoine Pitrou added the comment:
Le jeudi 03 février 2011 à 19:59 +, Alexander Belopolsky a écrit :
> Alexander Belopolsky added the comment:
>
> > On Thu, Feb 3, 2011 at 2:44 PM, Antoine Pitrou
> > wrote:
> > ..
> >> Do you know of places where
Antoine Pitrou added the comment:
> I don't think so. One more important use case is when running a Unix
> daemon, which has (AFAIK) to close all std handles.
I just took a look at http://pypi.python.org/pypi/python-daemon/, and it
uses dup2() to redirect standard streams, which i
Antoine Pitrou added the comment:
> Hmm, ok, but AFAICT, your patch was rejected rather because of the way
> it approached the problem, not so much because of the issue itself.
I would be rather for the patch myself. The bytecode currently generated
for sliced indexing is awfully subo
Antoine Pitrou added the comment:
That's expected. seek() and tell() on text (unicode) files are slow by
construction. You should open your file in binary mode instead, if you want to
do any seeking.
Maybe I should add a note in
http://docs.python.org/dev/library/io.html#perfor
Antoine Pitrou added the comment:
>From the python-dev thread:
http://mail.python.org/pipermail/python-dev/2010-October/104782.html
“os._exit is useful. os.open is useful. aio_* are *not* useful. For anything.
If there's anything you think you want to use them for, you're wro
Antoine Pitrou added the comment:
That said, I think it is possible to make algorithmic improvements to
TextIOWrapper.tell() so that at least performance becomes acceptable.
--
stage: -> needs patch
title: file.tell extremely slow -> TextIOWrapper.tell extremely slo
Antoine Pitrou added the comment:
> opening file binary has a dramatic effect as well, I would say. After 2
> minutes I stopped execution of the program
Hint: b'' is not equal to '' ;)
--
___
Python tracker
<http
Antoine Pitrou added the comment:
Here is a proof-of-concept patch for the pure Python version of
TextIOWrapper.tell(). It turns the O(CHUNK_SIZE) operation into an O(1)
operation most of time (still O(CHUNK_SIZE) worst-case - weird decoders and/or
crazy input).
--
keywords: +patch
Antoine Pitrou added the comment:
> Here is a proof-of-concept patch for the pure Python version of
> TextIOWrapper.tell(). It turns the O(CHUNK_SIZE) operation into an
> O(1) operation most of time (still O(CHUNK_SIZE) worst-case - weird
> decoders and/or crazy input).
Actually,
Antoine Pitrou added the comment:
New patch also optimizing the C version. tell() can be more than 100x faster
now (still much slower than binary tell()).
--
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20680/textiotell2.pa
Antoine Pitrou added the comment:
The doc needs a versionadded attribute. Otherwise, looks good to me.
--
nosy: +pitrou
resolution: -> accepted
stage: -> commit review
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
Looks good to me.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue11121>
___
___
Python-bugs-list mailin
New submission from Antoine Pitrou :
test_posix has started failing deterministically on the Leopard buildbot.
Stephen, did you change something in its configuration?
http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.x/builds/786/steps/test/logs/stdio
Antoine Pitrou added the comment:
It seems that my patch for issue10956 also fixes this issue (although it
doesn't try to fix FileIO). It also has tests and fixes read() as well as
write().
I'm sorry for not noticing that the two issues were so similar. Suggest closing
thi
Antoine Pitrou added the comment:
I hadn't noticed that issue9504 is similar. The patch there does less things,
although it also touches FileIO.readall().
--
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
Sorry, bad analysis. The patch in issue10956 only seemed to work because my
system is too fast and "find /" in the script returned in less than 5 seconds.
Replacing it with "yes" shows that the two issued are actually independent.
-
Changes by Antoine Pitrou :
--
assignee: -> pitrou
nosy: +neologix
___
Python tracker
<http://bugs.python.org/issue10956>
___
___
Python-bugs-list mai
Antoine Pitrou added the comment:
> Regarding the implementation, knowing your reluctance to turn modules
> into packages, I guess you’re talking about exposing collections.abc in
> a similar manner to os.path, which is fine IMO.
That makes things confusing:
>>> import o
Changes by Antoine Pitrou :
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue7108>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +gregory.p.smith
stage: -> patch review
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.1
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
Well, sockets cannot be pickled on any platform:
>>> sock = socket.create_connection(("www.python.org", 80))
__main__:1: ResourceWarning: unclosed
>>> s = pickle.loads(pickle.dumps(sock))
>>> s.getpeername()
Traceback (mo
New submission from Antoine Pitrou :
Like already done for file objects, sockets should refuse pickling by raising a
TypeError.
--
components: Library (Lib)
messages: 127976
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: sockets should not be
Antoine Pitrou added the comment:
Opened issue11127 for raising a TypeError when trying to pickle any socket.
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
I can't reproduce either, but the latest traceback posted in msg127985 seems to
hint at a parameter marshalling problem. "create" is one of the parameters to
the called Tk function, but it seemed to be mistaken for another.
Since it'
Antoine Pitrou added the comment:
The "UpdateStringProc should not be invoked for type cmdName" message (as
quoted above in the traceback) apparently can mean that there's a mismanagement
of Tcl reference counts.
>From
>http://sourceforge.net/tracker/?func=detail&am
Antoine Pitrou added the comment:
> As a side note, if Tkinter is intended to be thread safe, the
> documentation should say so. Clearly, and in the first paragraph.
I'm no Tkinter specialist but, judging by its source code, Tkinter (the Python
module) *is* intended to be thread
Antoine Pitrou added the comment:
Thanks for posting a patch! I have two comments:
- Have you run test_uuid? When I run it, it seems to go into an infinite loop
somewhere and I need to kill the process.
- uuid should work even when ctypes is not available, so you can't just put an
i
Antoine Pitrou added the comment:
> A bit of offtopic: why can't we assume that ctypes is available?
Because ctypes (or, actually, the libffi it relies on) needs specific low-level
code for each platform it runs on, and not all platforms have such code.
Another reason is that c
Antoine Pitrou added the comment:
> Maybe I understood and ctypes ImportError simply must be handled and
> fallbacked to something else.
Indeed.
> But there are only 3 ways of getting MAC address:
> 1. using popen
> 2. using ctypes and native calls
> 3. using C API and perfo
Antoine Pitrou added the comment:
> I'm thinking Python could use a general purpose ifconfig/mac-layer
> module that uuid.py could then just use.
Perhaps, but that's really out of scope for this issue. Feel free to
open another issue.
--
__
Changes by Antoine Pitrou :
--
assignee: ronaldoussoren ->
___
Python tracker
<http://bugs.python.org/issue7108>
___
___
Python-bugs-list mailing list
Un
Antoine Pitrou added the comment:
Why is OPT duplicated in get_config_vars(...)?
Why do OPT and BASECFLAGS environ vars override their Makefile values instead
of accumulating with them?
Why is EXTRA_CFLAGS not configurable through environ
Changes by Antoine Pitrou :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue10971>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> I am not convinced that the minimal patch would work for my original
> issue. I wanted to be able to override the -march option which shows
> up in OPT on Fedora. I was cross-compiling to a target architecture
> that does not support the -march
Antoine Pitrou added the comment:
Given the recent multiple additions of "forgotten things" in the ABI, wouldn't
it be better to mark the ABI experimental so that things can get ironed out in
3.2.1? (especially with user feedback after the release)
-
Antoine Pitrou added the comment:
> > Given the recent multiple additions of "forgotten things" in the ABI,
> > wouldn't it be better to mark the ABI experimental so that things can
> > get ironed out in 3.2.1? (especially with user feedback after the
> >
Antoine Pitrou added the comment:
> IMAP4_SSL.close()
> IMAP4_SSL.logout()
> IMAP4_SSL.shutdown()
logout() already calls shutdown() for you and closes the socket, so you don't
have to do it yourself.
--
nosy: +pitrou
resolution: -> invalid
status
Antoine Pitrou added the comment:
Please leave open until a patch is actually committed ;)
--
status: pending -> open
___
Python tracker
<http://bugs.python.org/issu
3601 - 3700 of 16792 matches
Mail list logo
