Pascal Chambon added the comment:
I've just crossed again the doc of the daemon flag
(http://docs.python.org/library/multiprocessing.html), and it's still quite
confusing to newcomers.
daemon
The process’s daemon flag, a Boolean value. This must be set before start()
is calle
Pascal Chambon added the comment:
I guess it should, shouldn't it ?
--
___
Python tracker
<http://bugs.python.org/issue8734>
___
___
Python-bugs-list m
Pascal Chambon added the comment:
Is that normal to have two methods "test_full_traceback_is_full" at the same
place, in full_traceback.patch / r.david.murray / 2010-08-04 02:32 ?
format_exception should have the same semantic as print_except
Pascal Chambon added the comment:
Indeed I don't understand the following part :
+Traceback (most recent call last):
+ File "testmod.py", line 16, in
+{exception_action}
+ File "testmod
New submission from Pascal Chambon :
On freebsd 8, using python 2.6.6, I've run into the bug already widely dealt
with in these reports :
http://bugs.python.org/issue1380952
http://bugs.python.org/issue1153016
When using socket timeouts (eg. with socket.setdefaulttimeout()), whateve
Pascal Chambon added the comment:
The exception is raised too early, none of my calls takes more than 1-2 seconds
and I've a default timeout set at 10s or more.
This occurs rather rarely, one or two times on some hundreds of calls. I'll
make a little script to try to isol
Pascal Chambon added the comment:
Humz on second thought you may be right, now I have some trouble reproducing
the bugs (wich have been there since the beginning, though), so it may be that
the webservice I call seldom takes 10+ seconds to answer (weird anyway).
I've placed timers i
Pascal Chambon added the comment:
Allright, it actually looks more like a pathological latency behaviour of my
target platforms than a ssl bug...
I was mislead by the heavy history of socket.settimeout(), sorry. >_<
--
status: open -&g
Pascal Chambon added the comment:
I dont understand, if we use traceback.print_stack(), it's the stack at the
exception handling point which will be displayed.
In my view, the interesting think was not the stack trace at the point where
the exception is being handled, but where the unwi
New submission from Pascal Chambon :
My own fileio implementation fails against the latests versions of the io test
suite, under python2.6, because these now require FileIO objects to accept
unicode strings in their write methods, whereas the doc mentions raw streams
only deal with bytes
Pascal Chambon added the comment:
Allright - sorry for the failure - I've cleaned my hdd enough to launch
large_file tests too.
The thing is - are there platforms available to test a patch against the whole
test suite of python, and against several OSes ? I've found no such thi
Changes by Pascal Chambon :
Removed file:
http://bugs.python.org/file15909/patch26_truncate_pos_refcounts.patch
___
Python tracker
<http://bugs.python.org/issue6
Pascal Chambon added the comment:
Hum, it seems that in python2.6, the C API for PyArg_ParseTuple isn't yet ready
for bytes and bytearrays, is it ? "y"-like argument parsers don't exist, so I
guess we can't easily patch the C api on this, only tests (
Pascal Chambon added the comment:
Hello
Just to notify that I've just tested this patch on a fresh python2.6 SVN
checkout, on Ubuntu this time (previously, it was only win32), and it passes
all IO-related tests I know.
--
___
Python tr
Pascal Chambon added the comment:
Thanks a lot B-)
I'll make a patch for trunk from now to this W.E.
--
___
Python tracker
<http://bugs.python.org/i
Pascal Chambon added the comment:
Hello
Here is the patch for the python trunk, regarding truncate() behaviour.
I've tested it on windows and linux, against IO test suites (with -uall), in
debug and normal mode.
I've also updated some docstrings, and added tests for untested
New submission from Pascal Chambon :
I have a weird behaviour of the interpreter on my python2.6 win32 install : if
I launch as __main__ the file joined below, like "python
test_rsFileLocking.py", all works fine.
But if I put it in my PYTHONPATH (or current working directory), and
Pascal Chambon added the comment:
Allright, I guess in these conditions this bugs doesn't require a patch B-)
Thanks for the details.
--
___
Python tracker
<http://bugs.python.org/i
Pascal Chambon added the comment:
Argh, I had indeed missed some IO-related tests, hadn't noticed the new test_io
docstring:
# Tests of io are scattered over the test suite:
# * test_bufio - tests file buffering
# * test_memoryio - tests BytesIO and StringIO
# * test_fileio - tests F
Pascal Chambon added the comment:
Here is the patch you mentionned, it fixes my problem and seems unharmful
indeed.
The little problem is, I've not found related tests (test_pkgutil doesn't deal
with the importer part) to ad little checks around compile().
Is that patch worth
Changes by Pascal Chambon :
Removed file: http://bugs.python.org/file15759/seek_cur_buffers_py26.patch
___
Python tracker
<http://bugs.python.org/issue7640>
___
___
Pytho
Pascal Chambon added the comment:
BufferedRandom's seek() is still borken in the latest svn revision of python2.6
(I haven't checked python2.7 yet), so here is a new, smaller patch, tested with
the 6 IO-related test suites this time, on win32
Pascal Chambon added the comment:
The patch itself...
--
Added file: http://bugs.python.org/file16085/Py26_relative_seek.patch
___
Python tracker
<http://bugs.python.org/issue7
New submission from Pascal Chambon :
The current semantic of io streams is to swallow IOErrors on close(), eg. in
_pyio from the trunk, we have each time constructs like:
try:
self.flush()
except IOError:
pass # If flush() fails, just give up
and in C files :
/* If flush
New submission from Pascal Chambon :
Hello
I see some trouble in the semantic of logging.disable(lvl) :
according to the doc (and docstrings), it's the same as a logger.setLevel(lvl)
called on all logger, but in reality it doesn't act the same way : when we call
logger.setLevel
Pascal Chambon added the comment:
Thanks you B-)
I guess it's not important if messages of severity 0 will allways be ignored
with the current semantic ?
--
___
Python tracker
<http://bugs.python.org/i
Changes by Pascal Chambon :
--
nosy: +pakal
___
Python tracker
<http://bugs.python.org/issue1553375>
___
___
Python-bugs-list mailing list
Unsubscribe:
Pascal Chambon added the comment:
What's the status of this (imo quite useful) new traceback function ?
Shall I provide some help ?
--
___
Python tracker
<http://bugs.python.org/issu
New submission from Pascal Chambon :
Hello
Crawling into the logging module, I've just discovered its behaviour was
actually far from the one I expected, in a consequent gap that the
documentation had left.
I thought that depending on the "propagate" parameter of each lo
Pascal Chambon added the comment:
Thanks for the doc patch, if you don't mind I'd just add the paragraph below
too, to clarify the fact that logger levels are only "entry points" levels,
ignored he rest of the time. There might be slight redundancies with the rest
of the
Pascal Chambon added the comment:
Well, it would break code which currently ignores that it fails, so it's more a
benefit than a loss for programmers imo.
I doubt the impact will be important though, because the io module is still
quite recent, and furthermore errors on the last flus
Pascal Chambon added the comment:
Patch and test to stop swallowing exceptions on stream close(), for python SVN
trunk.
--
keywords: +patch
Added file: http://bugs.python.org/file17046/release_io_close_exceptions.patch
___
Python tracker
<h
Changes by Pascal Chambon :
Removed file: http://bugs.python.org/file17046/release_io_close_exceptions.patch
___
Python tracker
<http://bugs.python.org/issue7865>
___
___
Pascal Chambon added the comment:
SHould be better this way then B-)
--
Added file: http://bugs.python.org/file17077/no_swallow_on_close2.patch
___
Python tracker
<http://bugs.python.org/issue7
Pascal Chambon added the comment:
I'm quite surprised it wasn't already covered by the test suite :S
Anyway I'm quite confused about the semantic which is expected from IO
operations...
Should a flush on a closed stream fail (at the moment sometimes it does,
sometimes do
Pascal Chambon added the comment:
>Probably an oversight. Do you want to add some tests?
That's WIP
> Because it's not an IO error at all. No I/O occurs. You are just using
the file wrongly (or the wrong file), hence the ValueError.
Then when you try to wrap a non-readab
Changes by Pascal Chambon :
Removed file: http://bugs.python.org/file17077/no_swallow_on_close2.patch
___
Python tracker
<http://bugs.python.org/issue7865>
___
___
Pytho
Pascal Chambon added the comment:
Here is a code/test patch which *should* fix the multiple close() case, and
ensure flush() raise an error on closed file.
All IO test suites pass on my win32 (except test_largefile that I skip due to
lack of hdd space).
I've noticed that the d
Pascal Chambon added the comment:
Cool, thanks a lot B-)
--
___
Python tracker
<http://bugs.python.org/issue7865>
___
___
Python-bugs-list mailing list
Unsub
New submission from Pascal Chambon <[EMAIL PROTECTED]>:
I've created on my desktop a file flooder.py containing just the following:
##
import sys, os
progress=open(r"C:\Users\v-pascha\Desktop\STDERR.txt","w")
for i in range(101):
print str(i)*2
Pascal Chambon added the comment:
The latest doc has a quick mention about the fact that daemon is not used in
the Unix sens, so it seems fine now B-)
https://docs.python.org/3/library/multiprocessing.html?#multiprocessing.Process.daemon
"""Additionally, these are not
New submission from Pascal Chambon :
Is there any reasons why assertXXX methods in TestCase are instance methods and
not staticmethods/classmethods?
Since they (to my knowledge) don't need to access an instance dict, they could
be turned into instance-less methods, and thus be usable
Pascal Chambon added the comment:
Indeed I missed this ticket, thanks
--
___
Python tracker
<https://bugs.python.org/issue37262>
___
___
Python-bugs-list mailin
Pascal Chambon added the comment:
(Redirected here from https://bugs.python.org/issue37262)
I haven't dug the assertThat() idea, but why not make, as a first step, turn
assertion methods in TestCase to staticmethods/classmethods, instead of
instance methods?
Since they (to my know
Pascal Chambon added the comment:
I don't get it, why would failureException block anything ? The
unittest.TestCase API must remain the same anyway, but it could become just a
wrapper towards external assertions.
For example :
class TestCase:
assertEqual = wrap(assertions.assert_
Pascal Chambon added the comment:
"Suppose failureException is set to TypeError on that TestCase class, how would
your assertEquals signal failure to the test runner?"
failureException is an artefact from unittest.TestCase. It's only supposed to
be used in a TestCase c
New submission from Pascal Chambon :
According to https://bugs.python.org/issue30661#msg339300 , "format" argument
of Tarfile.open() only concerns the writing of files. It's worth mentioning it
in the doc, if it's True (confirmation from core maintainers is welcome).
-
Pascal Chambon added the comment:
PR is on https://github.com/pakal/cpython/pull/1
--
___
Python tracker
<https://bugs.python.org/issue37408>
___
___
Python-bug
Pascal Chambon added the comment:
My bad, this was a wrongly targeted PR, the real one is here:
https://github.com/python/cpython/pull/14389
--
___
Python tracker
<https://bugs.python.org/issue37
Pascal Chambon added the comment:
Looking at tarfile.py, "format" seems only used in addfile() indeed.
--
___
Python tracker
<https://bugs.python.o
New submission from Pascal Chambon :
It seems the properties of the write methods of these two classes are
mixed up in documentation. I've checked the sources, and actually it
seems the behviour is inverted :
rawiobase streams, which can be pipes or other limited streams, may
write less tha
Pascal Chambon added the comment:
Allright, then only rawIoBase's documentation is wrong... and I'll have
to modify my work-in-progress library to mimic FileIo more accurately.
Thansk for teh info B-)
--
___
Python tracker
<http://bu
Pascal Chambon added the comment:
I forgot to note - yep I was actually improperly looking at the python
2.6 documentation, which is erroneous ocncerning the io module.
But the py3k doc seems to summarize it allright B-)
--
___
Python tracker
<h
New submission from Pascal Chambon :
Hello
I'm having trouble around the behaviour of the io module's truncate
methods, in py3k. If I remember well, under unix and older versions of
Python (with other file types), truncate never move the fiel pointer
(and had to fake that behav
Pascal Chambon added the comment:
Well, I guess it deserve discussion on the pydev mailing lits, that's
imo a rather important point, to be documented precisely.
Concerning the padding, I guess the semantic doesn't change between the
io module and the old file type, i.e :
file.trun
Changes by Pascal Chambon :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue4192>
___
___
Python-bugs-list mailing list
Unsubscri
New submission from Pascal Chambon :
*Propositions of doc update*
*RawIOBase*.read(n: int) -> bytes
Read up to n bytes from the object and return them. Fewer than n bytes
may be returned if the operating system call returns fewer than n bytes.
If 0 bytes are returned, and n was not 0, t
Pascal Chambon added the comment:
Thanks for the memoryview tip - I though I was up-to-date with python's
features but obviously I wans't ^^ (I searched through dict views but
that wasn't it...)
It should be exactly what's needed to replace these unnecessary
additional ar
Pascal Chambon added the comment:
Thanks a lot B-)
--
___
Python tracker
<http://bugs.python.org/issue7022>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Pascal Chambon :
Hello,
It seems there is an important difference between the doc of the IO
module, and its implementation so far (until todcay trunk revision 76805)
"buffering is an optional integer used to set the buffering policy. By
default full buffering is on. P
Pascal Chambon added the comment:
Yep, I knew "full buffering" didn't mean "fill my RAM until crash" :p
The only visible problem was the interpretation of positive/negative
buffering value, which wasn't the same in doc and in code. But the patch
seems to f
Pascal Chambon added the comment:
Hello
I'm currently finalizing the API of my raw io file implementation, but I still
have trouble with the trunk implementation of IOBase.truncate().
If I remember well, in the mailing list topic on this subject, GvR noted that
this change of beha
New submission from Pascal Chambon :
I've noticed a severe bug in my python 2.6.2 io module, and looking at
_buffered_raw_seek in
http://svn.python.org/view/python/trunk/Modules/_io/bufferedio.c?view=markup,
it seems the bug is still there in the C reimplementation of buffered io
cl
Pascal Chambon added the comment:
Allright, I'll try to work on it as soon as I manage to gather a decent
compilation environment on windows...
--
___
Python tracker
<http://bugs.python.org/i
Pascal Chambon added the comment:
My bad, I had looked at _buffered_raw_seek, not buffered_seek >_<
Indeed, the code is OK in both trunk _io an _pyio modules.
And the SEEK_CUR flag (value : 1) seems more than sufficiently tested in
test_io actually, for example in the function wri
Pascal Chambon added the comment:
Hum, with a selective merge (tortoiseSVN makes it easy), backporting _pyio
should be doable in a decent time. Triaging pertinent tests should be more
brain damaging :p
I'm looking at this.
--
___
Python tr
Pascal Chambon added the comment:
Well, here is a patch for the seek() methods of io module, in python2.6
maintenance branch.
Finally, I've only backported some assertions and the offset stuffs - I'm not
comfortable enough about recent io refactorings to do more (it changed prett
Pascal Chambon added the comment:
Hi
Here is a patch for the python2.6 _fileio.c module, as well as the
corresponding testcase.
I'll check the _pyio and C _io trunk modules asap.
--
keywords: +patch
Added file: http://bugs.python.org/file15763/python26_io_truncate_bugfix.
Pascal Chambon added the comment:
Whoups - I forgot to bugfix as well the _bytesio classes... let's just forget
about the previous patch.
--
___
Python tracker
<http://bugs.python.org/i
Pascal Chambon added the comment:
Here is the new patch for py2.6, fixing (hopefully) all the truncate() methods.
Note that the python _BytesIO implementation isn't covered by the test suite,
as it's shadowed by the C implementation ; but imo we shouldn't care : I've
man
Pascal Chambon added the comment:
And here is the python trunk patch, covering _Pyio and _io modules (+
corresponding tests).
--
Added file: http://bugs.python.org/file15766/python27_full_truncate_bugfix.patch
___
Python tracker
<h
New submission from Pascal Chambon :
It seems we can't assign attributes to "objet" class instances, which don't
have a __dict__ :
IDLE 2.6.4
>>> a = object()
>>> a.abc = 3
Traceback (most recent call last):
File "", line 1, in
Pascal Chambon added the comment:
Allright, I suppose it's some kind of optimization ?
We get a proper error when we do :
>>> object.test=1
Traceback (most recent call last):
File "", line 1, in
object.test=1
TypeError: can't set attributes of built-in/ext
Pascal Chambon added the comment:
OK, eligible to QOTW:D
--
___
Python tracker
<http://bugs.python.org/issue7659>
___
___
Python-bugs-list mailing list
Unsub
Pascal Chambon added the comment:
Is there anything I can do to help this patch making its way to the trunk ?
I guess it'd be better if Python2.7 benefited from it, so that users don't run
anymore the risk of relying of this undocumented and non-canonical "truncate"
Pascal Chambon added the comment:
Allright, I shall fix all this asap.
But it seems the C code for truncate is actually buggy in the current 2.6
_fileio.c, around line 680.
CF code below :
posobj = portable_lseek(fd, posobj, 0); -> don't we lose the reference to the
old "
Changes by Pascal Chambon :
Removed file:
http://bugs.python.org/file15765/python26_full_truncate_patch.patch
___
Python tracker
<http://bugs.python.org/issue6
Changes by Pascal Chambon :
Removed file:
http://bugs.python.org/file15766/python27_full_truncate_bugfix.patch
___
Python tracker
<http://bugs.python.org/issue6
Pascal Chambon added the comment:
Thanks for the detailed feedback.
According to what you said (and to details found in python docs), the current
_fileio.truncate is actually quite buggy -> no reference counting ops were done
on posobj, even though it's sometimes retrie
Pascal Chambon added the comment:
Thansk a lot for reviewing the problem
Indeed, "p.wait()" seems to do the trick in this case.
Is there any global way to avoid such pipe problems ? I mean, in any
case, one end of each pipe has to be closed before the other end, so
such errors m
New submission from Pascal Chambon :
"Usually, daemon processes are processes which got disconnected from
their parent process, and work in the background, often under a
different user identity.
The multiprocessing module has the concept of "daemon" too, but this
time in r
Pascal Chambon added the comment:
I agree that for someone who discovers the multiprocessing api as a
"generalization" of the threading api, there won't be problems ;
I'm just worried about those (like me) who will see "daemonic" as coming
from unix processes, a
Pascal Chambon added the comment:
I guess we all agree on the fact that a renaming of the API would be
highly disproportionate ;-)
A simple line of warning in the doc, next to the daemonic-related
methods, should be sufficient to prevent people like me from wondering
weird stuffs for hours
New submission from Pascal Chambon :
Hello
I once was rather confused, because nothing in the sys and os modules
mentionned the behaviours that the exit() and _exit() functions were
supposed to have when called inside a non-main thread.
I've eventually found in multithreading-related docs
New submission from Pascal Chambon :
It seems that the "flock" wrapped by the fcntl module is the one
descriebd in "flock(2)", not "flock(3)" (just in case this might confuse
people...)
Quote :
"""
fcntl.flock(fd, op)
Perform the lock operation op
New submission from Pascal Chambon :
Hello
A minor detail in optparse documentation :
"If optparse‘s default error-handling behaviour does not suit your
needs, you’ll need to subclass OptionParser and override its exit()
and/or error() methods."
-> the links put on exit() and erro
New submission from Pascal Chambon :
I feel the description of the subprocess.popen semantics is a little
incomplete/confusing to me, on some points, eg. :
- what does the "shell" argument do on windows, exactly ? The beginning
of the description states that nothing changes (createPr
New submission from Pascal Chambon :
There seems to have been some broken commit on subprocess.py in trunk - the
moduel can't be imported due to unexisting argument defaults.
Here is a very quick patch, but more inquiry migh tbe necessary to find out
what happened.
--
Pascal Chambon added the comment:
Hello
I advocate the inclusion of this patch to the 2.6 maintenance branch, because
currently the io module in this branch (which is still the most recent 2.X
version released) is simply broken.
People using it will certainly encounter MAJOR file
New submission from Pascal Chambon :
In python trunk, _set_invalid_parameter_handler() has been dropped and replaced
by custom checking functions, but in msvcrt.get_osfhandle() these checks aren't
present, so providing a bad FD leads to a crash.
Here is the little fix + a test (add
Pascal Chambon added the comment:
My bad, here is a better patch...
--
Added file: http://bugs.python.org/file17382/msvcrt_crash2.patch
___
Python tracker
<http://bugs.python.org/issue8
Changes by Pascal Chambon :
Removed file: http://bugs.python.org/file17369/msvcrt_crash.patch
___
Python tracker
<http://bugs.python.org/issue8734>
___
___
Python-bug
Pascal Chambon added the comment:
Sorry to reraise an old issue, but the documentation of "test" module is
deceiving on that one : "The test.test_support module has been renamed to
test.support in Python 3.0. The 2to3 tool will automatically adapt imports when
converting your
New submission from Pascal Chambon :
I've created a pure-python package with py3k's bdist_msi, and weirdly, even
though the windows installer asks for the target directory, it installs the
package in ALL python distributions installed (py26, py27 and py31), which is
particularly e
Pascal Chambon added the comment:
Thansk for the attention,
Here it is (I ran bdist_msi with the latest SVN py3k version).
--
Added file: http://bugs.python.org/file17399/RSFile-1.0.tar.gz
___
Python tracker
<http://bugs.python.org/issue8
New submission from Pascal Chambon :
In test_fileio, one of the tests wants to ensure writing to closed raw streams
fails, but it actually tries to write an unicode string, which should rather
lead to an immediate TypeError.
Here is a tiny patch to prevent the "double error cause&qu
Pascal Chambon added the comment:
None at all, a simple python "setup.py bdist_msi".
Once I've installed the MSI(and whatever the target python version I chose),
launching it again will always trigger a "repair/uninstall" wizard, and the
operatiosn I do with
Pascal Chambon added the comment:
Allright, what's the expected behaviour then - implicitly converting unicode to
bytes (like C RawFileIO), or raising a typeerror (like buffered streams do) ?
--
___
Python tracker
<http://bugs.python.org/i
Pascal Chambon added the comment:
This would require patching separately py2k and py3k visibly...
I'll have a look at it when I have time.
--
___
Python tracker
<http://bugs.python.org/i
Pascal Chambon added the comment:
yes, but the same tests are used for py3k as well, where "xxx" is interpreted
as unicode (2to3 tools dont try to guess if a py2k string intended to be a byte
string or an unicode one).
--
___
Python trac
1 - 100 of 109 matches
Mail list logo
