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 n
Pascal Chambon added the comment:
Looking at tarfile.py, "format" seems only used in addfile() indeed.
--
___
Python tracker
<https://bugs.python.o
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:
PR is on https://github.com/pakal/cpython/pull/1
--
___
Python tracker
<https://bugs.python.org/issue37408>
___
___
Python-bug
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:
"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 TestCa
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_equal
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 knowledge
Pascal Chambon added the comment:
Indeed I missed this ticket, thanks
--
___
Python tracker
<https://bugs.python.org/issue37262>
___
___
Python-bugs-list mailin
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 from
Pascal Chambon added the comment:
I guess it can, since retrocompatibility prevents some normalization here.
Or is it worth updating the doc about "AttributeError", misleading regarding
the type of exception expected in this case ?
--
status: pendi
Changes by Pascal Chambon <chambon.pas...@gmail.com>:
--
nosy: +pakal
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27141>
___
_
Pascal Chambon added the comment:
Well, since it's a tough decision to make (erasing all children modules when
rolling back parent, or instead reconnecting with children on 2nd import of
parent), I guess it should be discussed on python-dev first, shouldn't
Changes by Pascal Chambon chambon.pas...@gmail.com:
--
nosy: +Pascal.Chambon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17636
___
___
Python
Pascal Chambon added the comment:
(sorry for the long post, but it's a complex issue I guess)
I forgot to precise that I have this behaviour with the latest python2.7, as
well as python3.3 (I guess other versions behave the same).
I agree that having side effects in script imports looks
Pascal Chambon added the comment:
Thanks for the feedback, I'm gonna read those docs and related issues asap, and
check that planned evolutions will actually fix this.
just as a side note in the meantime: I dont think that the problem here is the
purge of sys.modules, the failure is actually
New submission from Pascal Chambon:
Hello,
we've encountered several times a very nasty bug on our framework, several
times tests or even production code (served by mod_wsgi) ended up in a broken
state, where imports like from . import processing_exceptions, which were NOT
in circular
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com 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 - closed
New submission from Pascal Chambon chambon.pas...@gmail.com:
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
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com added the comment:
Indeed I don't understand the following part :
+Traceback (most recent call last):
+ File testmod.py, line 16, in module
+{exception_action}
+ File testmod.py, line 6
Pascal Chambon chambon.pas...@gmail.com 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_exception indeed
Pascal Chambon chambon.pas...@gmail.com added the comment:
I guess it should, shouldn't it ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8734
Pascal Chambon chambon.pas...@gmail.com added the comment:
The change was announced in http://docs.python.org/dev/whatsnew/2.7.html, but
indeed it wasn't advertised in py3k changes - my apologies, I didn't check it
was.
I agree that the doc should be clarified on several aspects
Pascal Chambon chambon.pas...@gmail.com added the comment:
Good B-)
Woudl it be necessary to update the docstrings too ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8840
Pascal Chambon chambon.pas...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org/issue8765
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com 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 rep
New submission from Pascal Chambon chambon.pas...@gmail.com:
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
Pascal Chambon chambon.pas...@gmail.com 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 rep
New submission from Pascal Chambon chambon.pas...@gmail.com:
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
Pascal Chambon chambon.pas...@gmail.com 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 it are made
Pascal Chambon chambon.pas...@gmail.com added the comment:
My bad, here is a better patch...
--
Added file: http://bugs.python.org/file17382/msvcrt_crash2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8734
Changes by Pascal Chambon chambon.pas...@gmail.com:
Removed file: http://bugs.python.org/file17369/msvcrt_crash.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8734
Pascal Chambon chambon.pas...@gmail.com 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
New submission from Pascal Chambon chambon.pas...@gmail.com:
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
Pascal Chambon chambon.pas...@gmail.com 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
New submission from Pascal Chambon chambon.pas...@gmail.com:
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
Changes by Pascal Chambon chambon.pas...@gmail.com:
Removed file: http://bugs.python.org/file17077/no_swallow_on_close2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7865
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com 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
Changes by Pascal Chambon chambon.pas...@gmail.com:
Removed file: http://bugs.python.org/file17046/release_io_close_exceptions.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7865
Pascal Chambon chambon.pas...@gmail.com added the comment:
SHould be better this way then B-)
--
Added file: http://bugs.python.org/file17077/no_swallow_on_close2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7865
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com added the comment:
What's the status of this (imo quite useful) new traceback function ?
Shall I provide some help ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1553375
New submission from Pascal Chambon chambon.pas...@gmail.com:
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
Changes by Pascal Chambon chambon.pas...@gmail.com:
--
nosy: +pakal
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1553375
___
___
Python-bugs-list
New submission from Pascal Chambon chambon.pas...@gmail.com:
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
Pascal Chambon chambon.pas...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org
New submission from Pascal Chambon chambon.pas...@gmail.com:
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
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com 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
Changes by Pascal Chambon chambon.pas...@gmail.com:
Removed file: http://bugs.python.org/file15759/seek_cur_buffers_py26.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7640
Pascal Chambon chambon.pas...@gmail.com 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 and linux
Pascal Chambon chambon.pas...@gmail.com added the comment:
The patch itself...
--
Added file: http://bugs.python.org/file16085/Py26_relative_seek.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7640
New submission from Pascal Chambon chambon.pas...@gmail.com:
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
Pascal Chambon chambon.pas...@gmail.com added the comment:
Allright, I guess in these conditions this bugs doesn't require a patch B-)
Thanks for the details.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7813
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com added the comment:
Thanks a lot B-)
I'll make a patch for trunk from now to this W.E.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6939
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com 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
Changes by Pascal Chambon chambon.pas...@gmail.com:
Removed file:
http://bugs.python.org/file15909/patch26_truncate_pos_refcounts.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6939
Pascal Chambon chambon.pas...@gmail.com 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 (replacing xxx
Changes by Pascal Chambon chambon.pas...@gmail.com:
Removed file:
http://bugs.python.org/file15765/python26_full_truncate_patch.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6939
Changes by Pascal Chambon chambon.pas...@gmail.com:
Removed file:
http://bugs.python.org/file15766/python27_full_truncate_bugfix.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6939
Pascal Chambon chambon.pas...@gmail.com 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
New submission from Pascal Chambon chambon.pas...@gmail.com:
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
Pascal Chambon chambon.pas...@gmail.com 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 chambon.pas...@gmail.com 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
New submission from Pascal Chambon chambon.pas...@gmail.com:
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 pyshell#1, line 1, in module
a.abc = 3
Pascal Chambon chambon.pas...@gmail.com 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 pyshell#6, line 1, in module
object.test=1
TypeError: can't set attributes of built
Pascal Chambon chambon.pas...@gmail.com added the comment:
OK, eligible to QOTW:D
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7659
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com added the comment:
Whoups - I forgot to bugfix as well the _bytesio classes... let's just forget
about the previous patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6939
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com 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
New submission from Pascal Chambon chambon.pas...@gmail.com:
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
Pascal Chambon chambon.pas...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org/issue6939
New submission from Pascal Chambon chambon.pas...@gmail.com:
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
Pascal Chambon chambon.pas...@gmail.com 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 fix up the plot
Pascal Chambon chambon.pas...@gmail.com added the comment:
Thanks a lot B-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7022
___
___
Python
Pascal Chambon chambon.pas...@gmail.com 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
New submission from Pascal Chambon chambon.pas...@gmail.com:
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
Pascal Chambon chambon.pas...@gmail.com 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
New submission from Pascal Chambon chambon.pas...@gmail.com:
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
Pascal Chambon chambon.pas...@gmail.com 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
Pascal Chambon chambon.pas...@gmail.com 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
New submission from Pascal Chambon chambon.pas...@gmail.com:
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
New submission from Pascal Chambon chambon.pas...@gmail.com:
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
New submission from Pascal Chambon chambon.pas...@gmail.com:
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 on file descriptor fd (file
1 - 100 of 106 matches
Mail list logo
