New submission from Heijink:
In the end I tracked down the behaviour with the attached program
behaviour with an initially empty table:
7 : insert two records with values in the columns
two records show up, # 1,2
as expected
9 : show al records
none
whereas two are to be expected
8 : add
Andrew Svetlov added the comment:
Good catch!
That's because -R run the same test suite several times.
I'm working on patch.
--
resolution: fixed -
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11798
R. David Murray added the comment:
What happens if you actually call commit()?
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18892
___
Heijink added the comment:
your suggestion is a bit to cryptic for me
- you mean intermediate messages from Python: there are none
- you mean to change a command in another format
newbie with programming experience
drop me a program line / show three records where one is your alternative
Charles-François Natali added the comment:
2013/8/31 Guido van Rossum rep...@bugs.python.org:
But still I agree with Giampaolo that the decorator doesn't feel
right. It's like a try/except around the entire body of your function,
which is usually a code smell (even though I realize the
Charles-François Natali added the comment:
The final patch includes tests that are very reliable at
revealing the bug in 2.7 and 3.3.
Indeed, I could reproduce it systematically without the patch.
Thanks for accepting this patch!
Well, thanks for the patch!
--
resolution: - fixed
Peter Otten added the comment:
David means you should replace the line
conn.commit
in your script which does not invoke the method with
conn.commit()
Side note: as long as you are a newbie it is a good idea to ask on the python
mailing list first before adding a report to the bug tracker.
R. David Murray added the comment:
Sorry, I didn't mean to be cryptic. Yes, Peter has figured out what I was
trying to say.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18892
___
Charles-François Natali added the comment:
Oh, and FWIW, that's also what Java does:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5100121
http://hg.openjdk.java.net/jdk6/jdk6-gate/jdk/file/6daa81bdfd18/src/solaris/native/sun/nio/ch/PollArrayWrapper.c
(I know some people don't like Java,
Mark Dickinson added the comment:
This was already considered and rejected in issue18414.
--
nosy: +mark.dickinson, rhettinger
resolution: - duplicate
status: open - closed
superseder: - random.choices(seq, k)
___
Python tracker
Antoine Pitrou added the comment:
I don't understand the need for all the indirections in the second
patch. Like, why use a weakref? It's not like we have to worry about
an immortal tstate keeping a measly little lock object alive forever,
right? Seems to me that if the tstate object held
Heijink added the comment:
that did the trick, my confidence is restored.
sorry to have bothered you, I could have found in myself, by comparing
differences. Just staring blind after many attempts.
I did look in the list, but could not find an issue that matched my description
of the
New submission from Stefan Behnel:
The exception handling clauses in framework_find() are weird.
def framework_find(fn, executable_path=None, env=None):
Find a framework using dyld semantics in a very loose manner.
Will take input such as:
Python
Python.framework
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18893
___
Stefan Behnel added the comment:
changing title as it doesn't really look like a typo, more a converto
--
title: typo in Lib/ctypes/macholib/dyld.py - invalid exception handling in
Lib/ctypes/macholib/dyld.py
___
Python tracker
Madison May added the comment:
Whoops, my apologies.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1
___
___
Python-bugs-list mailing list
Giampaolo Rodola' added the comment:
I may be missing something here but isn't the whole point of EINTR to interrupt
a potentially long running syscall?
Why protract function return time as a consequence?
All the event loops I'm familiar with (twisted, tornado and asyncore) just
'return' on
Antoine Pitrou added the comment:
I may be missing something here but isn't the whole point of EINTR to
interrupt a potentially long running syscall?
Not exactly. The point is to signal (!) that a signal was received.
The received signal is not necessarily expected.
Also, from what I
Antoine Pitrou added the comment:
All the event loops I'm familiar with (twisted, tornado and asyncore)
just 'return' on EINTR, supposedly because that was the best
compromise to support syscall interruption without forcing users to
handle EINTR themselves.
What do you mean? Tornado simply
Charles-François Natali added the comment:
I may be missing something here but isn't the whole point of EINTR to
interrupt a potentially long running syscall?
No.
EINTR is an artifact of the early Unix design, because failing when a
signal was delivered was simpler than restarting the
Changes by Antoine Pitrou pit...@free.fr:
--
versions: +Python 3.4 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12304
___
___
Martin Mokrejs added the comment:
So with your test program I did not yet hit the error. It used in the end 1.3GB
of RAM, maybe in the good region. while this was python-2.7.5 configures as
--without-pymalloc maybe the output from valgrind becomes more useful.
--
Added file:
Brett Cannon added the comment:
builtins.__import__ and importlib.__import__ are different objects.
This isn't about whether this is whole situation is a bug per-se, but whether
users expect that overriding builtins.__import__ will affect all import-related
code in the stdlib and if that's
Antoine Pitrou added the comment:
Hardware failures or glitches can involve any number of parameters.
Instead of trying to reproduce the memory corruption with other Python
programs, I would suggest you run the exact same workload (including Python
version and build options) on another
Roundup Robot added the comment:
New changeset 1faaec66c73d by Eli Bendersky in branch 'default':
Fix XMLPullParser documentation to say non-blocking instead of asynchronous.
http://hg.python.org/cpython/rev/1faaec66c73d
--
___
Python tracker
Eli Bendersky added the comment:
The idea looks reasonable. Posted a code review.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
___
Guido van Rossum added the comment:
Charles-François Natali added the comment:
Well, I'll change it, but:
We have to change the select() docstring to Wait until some
registered file objects become ready, or for *at most* timeout
seconds
Doesn't sound so bad to me. It's about the same
Valerie Lambert added the comment:
Running through both your scripts on my machine (using Ubuntu) WCOREDUMP is
always True (though I'll only be able to find a core file when ulimit is set to
unlimited, as expected).
Because there doesn't seem to be a good way to test this, I've cut the test
Changes by Antoine Pitrou pit...@free.fr:
--
components: +Tests
stage: commit review - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18889
___
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18889
___
___
Python-bugs-list
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +brian.curtin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18889
___
___
Python-bugs-list
Serhiy Storchaka added the comment:
Why Lib/test/xmltestdata/test.xml.out contains '\r'? AFAIK Windows buildbots
are happy with current tests.
A nitpick for first proposed solution: you can append .replace(b'\r', b'')
just to f.read().
A nitpick for second proposed solution: encoding should
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18891
___
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18823
___
___
New submission from py.user:
http://docs.python.org/3/library/unittest.html#unittest.TestResult.failures
--
assignee: docs@python
components: Documentation
files: issue.diff
keywords: patch
messages: 196644
nosy: docs@python, py.user
priority: normal
severity: normal
status: open
title:
New submission from py.user:
http://docs.python.org/3/library/unittest.html#unittest.TestResult.addError
--
assignee: docs@python
components: Documentation
files: issue.diff
keywords: patch
messages: 196645
nosy: docs@python, py.user
priority: normal
severity: normal
status: open
title:
Changes by Serhiy Storchaka storch...@gmail.com:
--
components: +Library (Lib)
nosy: +serhiy.storchaka
stage: - patch review
type: - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18882
Gregory P. Smith added the comment:
FYI - use the changes made in http://bugs.python.org/issue12268 as a guide for
how to deal with EINTR properly at the C level. See the _PyIO_trap_eintr()
function for example.
See also _eintr_retry_call() in Lib/subprocess.py.
FWIW, there are times when
Changes by Guido van Rossum gu...@python.org:
--
nosy: +gvanrossum
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18885
___
___
Python-bugs-list
Charles-François Natali added the comment:
Gregory, thanks, that's what I was planning to do.
But since the recent discussions (mainly on selectors), there are points I
obviously don't - and won't - agree with (such as select() returning EINTR or
returning early, same for sleep()), I'm not
Changes by Charles-François Natali cf.nat...@gmail.com:
--
nosy: -neologix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18885
___
___
Antoine Pitrou added the comment:
FWIW, there are times when we *want* the interrupted system call to
return control to Python rather than retrying the call.
I'm a bit curious, do you know of any use cases?
If someone is making a Python equivalent of the low level system call
such as
Charles-François Natali added the comment:
Here's a patch returning [] on EINTR.
I've tested it on Linux, Windows, FreeBSD, OpenSolaris and OS-X.
--
Added file: http://bugs.python.org/file31536/selectors-15.diff
___
Python tracker
Terry J. Reedy added the comment:
Adding something like '(not builtins.__import__)' or '(different from
builtins.__import__') after 'importlib.__import__' should reduce the
possibility of confusing the two and expecting something that will not happen.
You might check the doc for
Antoine Pitrou added the comment:
Here's a patch returning [] on EINTR.
Hmm... Shouldn't it simply let the InterruptedError bubble up?
I know there's the sleep() precedent, but I find it a bit embarassing actually:
the call can return early, but there's no way for the caller to know that it
Roundup Robot added the comment:
New changeset 33727fbb4668 by Ethan Furman in branch 'default':
Close #18780: %-formatting now prints value for int subclasses with %d, %i, and
%u codes.
http://hg.python.org/cpython/rev/33727fbb4668
--
nosy: +python-dev
resolution: - fixed
stage:
Guido van Rossum added the comment:
On Sat, Aug 31, 2013 at 9:56 AM, Charles-François Natali
rep...@bugs.python.org wrote:
Charles-François Natali added the comment:
Gregory, thanks, that's what I was planning to do.
But since the recent discussions (mainly on selectors), there are points
Guido van Rossum added the comment:
Hm... I like the [] return just fine, it matches what Tulip's selector did.
The framework should be re-checking the clock anyway -- it's possible that
select() returned late too...
--
___
Python tracker
Terry J. Reedy added the comment:
As I said on #12037, I would rather \r was not in the file. I do not know if it
is present in the master repository or added by hg when cloning.
Buildbots and developer desktops are different environments. The tests must
work on both.
Nit 1: right, I should
Tim Peters added the comment:
Someone may find the new stress.valgrind.stderr interesting, but - since I've
never used valgrind - it doesn't mean much to me.
I _expected_ you'd run the little stress program under a debug Python and
without valgrind, since that's the only combination you've
Stephen J. Turnbull added the comment:
I did emerge =dev-lang/python-2.7.5-r1 *twice* with the environment
configuration described in msg196520, then *once* with it disabled because one
of the cases you described was when you tried to revert to a non-debug Python.
(Besides, I am willing to
Antoine Pitrou added the comment:
Ok, some comments about the patch (no review links appears so I'm gonna do it
inline here):
- the doc addition needs a versionadded tag
- The main thread is the thread that the OS creates to run application.: I
would rephrase this In normal conditions, the
Roundup Robot added the comment:
New changeset 868ad6fa8e68 by Andrew Svetlov in branch 'default':
Temporary disable tests cleanup (issue 11798).
http://hg.python.org/cpython/rev/868ad6fa8e68
--
___
Python tracker rep...@bugs.python.org
New submission from Alori:
Named tuples offer a useful mix of features from both dict and tuple data
structures. However, unlike dictionaries and tuples, Named tuples are only
allowed to hold up to 255 items.
This behavior seems inconsistent and un-Pythonic.
Is there a way to remove this
Gregory P. Smith added the comment:
I wrote too many words. In short:
time.sleep()'s behavior should remain as it is today given how it is documented
to behave. If you disagree, consider adding an optional interruptable=False
parameter so that both behavior options exist.
ALL IO calls and
Gregory P. Smith added the comment:
comments added to the review.
I don't think a DeprecationWarning should be raised as that'll infuriate users
of python programs more than developers who can fix code.
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
Ok, here is a new patch observing the timeout parameter. I've changed the
implementation strategy a bit, it seems hopefully sane.
There's a remaining (slightly bordeline) issue: the thread state lock isn't
reinitialized on fork(). Should it?
--
Added
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18885
___
___
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18896
___
___
Antoine Pitrou added the comment:
I'll let Raymond give his answer here, but namedtuples are meant as lightweight
structures or records (if you know C, think struct), not arbitrary containers.
--
nosy: +pitrou, rhettinger
___
Python tracker
Antoine Pitrou added the comment:
Er... your latest commit broke this issue's own tests!
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11798
___
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12304
___
___
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18100
___
___
Antoine Pitrou added the comment:
Thanks for the patch. It looks mostly ok.
Could you sign a contributor agreement so that we can move forward?
http://www.python.org/psf/contrib/
--
___
Python tracker rep...@bugs.python.org
Alori added the comment:
@pitrou:
Thank you for your answer.
I agree they should not replace databases or files, but I think 255 is just way
too lightweight. It feels unnatural to have this limitation for no specific
reason.
Recently, I've seen a lot of solutions that emulate the namedtuple
Roundup Robot added the comment:
New changeset 833246d42825 by Ethan Furman in branch 'default':
Issue #18780: code cleanup.
http://hg.python.org/cpython/rev/833246d42825
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18780
Roundup Robot added the comment:
New changeset 4179e2312089 by Terry Jan Reedy in branch '2.7':
Issue #18489: Add complete, gui-free tests for idlelib.SearchEngine.
http://hg.python.org/cpython/rev/4179e2312089
New changeset dfbf0f9034cc by Terry Jan Reedy in branch '3.3':
Issue #18489: Add
Terry J. Reedy added the comment:
By masking mock Text.index with instance functions, I removed the need for
tk.Text and hence the tests are gui free.
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python
Brett Cannon added the comment:
help(__import__) doesn't mention anything about overriding the function. I
already touched up the stdlib docs for builtins.__import__ to strongly advise
you don't override the function.
As for overriding importlib.__import__, it won't do anything; the code for
Tim Peters added the comment:
I'm getting a headache now - LOL ;-) Thanks for the explanation!
What I still don't understand: the new lock is an internal implementation
detail. How would it gain a weakref with a callback? Users aren't going to
mess with this lock, and if you want to stop
Roundup Robot added the comment:
New changeset f0eedca4b2a2 by Terry Jan Reedy in branch '3.3':
Issue #12037: Fix test_email for desktop Windows.
http://hg.python.org/cpython/rev/f0eedca4b2a2
--
nosy: +python-dev
___
Python tracker
Roundup Robot added the comment:
New changeset 5600e9a5c35d by Terry Jan Reedy in branch 'default':
Issue #12037: Fix test_email for desktop Windows.
http://hg.python.org/cpython/rev/5600e9a5c35d
--
___
Python tracker rep...@bugs.python.org
Changes by Terry J. Reedy tjre...@udel.edu:
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
title: test_email failures under Windows with the eol extension activated -
test_email failures under desktop Windows
Terry J. Reedy added the comment:
Looking at the actual doc:
importlib.__import__(name, globals=None, locals=None, fromlist=(), level=0) An
implementation of the built-in __import__() function.
I think this is pretty clear that builtin.__import__ has no effect unless
directly called.
Ethan Furman added the comment:
Final (hopefully ;) patch attached. Thanks, Eli, for your comments and help.
--
Added file: http://bugs.python.org/file31538/issue18738.stoneleaf.04.patch
___
Python tracker rep...@bugs.python.org
Ethan Furman added the comment:
Thanks, Eric, for teaching me a bunch about format. :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
Roundup Robot added the comment:
New changeset 038543d34166 by Eli Bendersky in branch 'default':
Switch the AF_* and SOCK_* constants in the socket module to IntEnum.
http://hg.python.org/cpython/rev/038543d34166
--
nosy: +python-dev
resolution: - fixed
stage: patch review -
Ethan Furman added the comment:
Okay, the final final patch. ;)
--
Added file: http://bugs.python.org/file31539/issue18738.stoneleaf.05.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
Ethan Furman added the comment:
Eli Bendersky added the comment:
Another issue is _intenum_converter. Ethan - do you think it belongs in the
enum module as a helper function or something of the sort?
I'm fine with it being a non-public member of enum, although if we had a place
for
Roundup Robot added the comment:
New changeset 4d604f1f0219 by Eli Bendersky in branch 'default':
Update whatsnew/3.4.rst wrt. the socket constants switch to IntEnum
http://hg.python.org/cpython/rev/4d604f1f0219
--
nosy: +python-dev
___
Python
Eli Bendersky added the comment:
On Sat, Aug 31, 2013 at 3:18 PM, Ethan Furman rep...@bugs.python.orgwrote:
Ethan Furman added the comment:
Eli Bendersky added the comment:
Another issue is _intenum_converter. Ethan - do you think it belongs in
the enum module as a helper function or
Eli Bendersky added the comment:
lgtm
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Martin Mokrejs:
I was trying to use DUMA to find errors in python runtime and it indeed killed
python-based utility called emerge. Let's see what you say now:
# export LD_PRELOAD=/usr/lib64/libduma.so.0.0.0
# sysctl -w vm.max_map_count=100
# emerge dev-lang/python:2.7
Martin Mokrejs added the comment:
To a naive user two places with numbers are in the stacktrace:
size = -1282872823
and
instr_ub = -1
instr_lb = 0
instr_prev = -1
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
This is a malloc() failure, not a Python bug (DUMA Aborting: mprotect()
failed: Cannot allocate memory).
Line 1173 in _sre.c allocates a fixed-sized structure (SRE_REPEAT):
ctx-u.rep = (SRE_REPEAT*) PyObject_MALLOC(sizeof(*ctx-u.rep));
That
Eric V. Smith added the comment:
Looks good to me, too. Thanks for considering all of the feedback!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
Martin Mokrejs added the comment:
I was actually printing every 10 seconds how much memory it was using, the last
before got killed was:
PIDVSZ RSS TIME ELAPSED %CPU %MEM COMMAND
4097 4938188 2445712 00:22:4425:04 90.7 15.0 /usr/bin/python2.7
/usr/bin/emerge
Tim Peters added the comment:
Note this line in your first post:
DUMA Aborting: mprotect() failed: Cannot allocate memory.
Python never calls mprotect(), but DUMA() probably does. Also note what it
said after that:
Check README section 'MEMORY USAGE AND EXECUTION SPEED'
if your
Martin Mokrejs added the comment:
Regarding benchmarking and code performance inspection, maybe you want to try
on your linux box:
perf top
perf stat /usr/bin/python mytest.py
http://perf.wiki.kernel.org/
--
nosy: +mmokrejs
___
Python tracker
Stephen J. Turnbull added the comment:
OK, I backed off the aggressive CFLAGS/CXXFLAGS to -ggdb -pipe, and ran
emerge =dev-lang/python-2.7.5-r1 *once* each with and without the
'EXTRA_ECONF=--with-pydebug' flag. Compiled with GCC 4.7.3.
No crash, same test results as described previously
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
title: Add aligned memroy variants to the suite of PyMem functions/macros -
Add aligned memory variants to the suite of PyMem functions/macros
___
Python tracker rep...@bugs.python.org
Raymond Hettinger added the comment:
Adding yet another API to allocate memory has a cost
Please don't FUD this one to death. Aligned memory access is sometimes
important and we currently have no straight-forward way to achieve it. If
you're truly worried about adding single new function
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
Removed message: http://bugs.python.org/msg196692
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18835
___
Raymond Hettinger added the comment:
Adding yet another API to allocate memory has a cost
Please don't FUD this one to death. Aligned memory access is sometimes
important and we currently have no straight-forward way to achieve it. If
you're truly worried about adding single new function
Tim Peters added the comment:
Thanks for that, Stephen! I don't know of anything else you could try that
would be helpful. The OP doesn't appear able to reproduce his problems either,
and last I heard he was off running `emerge` under DUMA:
http://duma.sourceforge.net/
Why? Hope
Stephen J. Turnbull added the comment:
Yeah, hope is a good thing. But I've spent the last 20 years debugging an X11
application based on a Lisp interpreter, I save hope for fireflies, my dog, and
my daughter these days. :-)
To the OP:
I don't follow Gentoo closely, but I have acquaintances
Martin Panter added the comment:
If this goes ahead, would a bytes.dedent() method be also considered? I
recently discovered that textwrap.dedent() does not work on bytes() in Python
3. I would have used it for the contents of an input file in a test case.
For the record there’s an older
Roundup Robot added the comment:
New changeset 058cb219b3b5 by Ethan Furman in branch 'default':
Close #18738: Route __format__ calls to mixed-in type for mixed Enums (such as
IntEnum).
http://hg.python.org/cpython/rev/058cb219b3b5
--
nosy: +python-dev
resolution: - fixed
stage:
Ethan Furman added the comment:
Fixed formatting in patch. ;)
--
Added file: http://bugs.python.org/file31541/issue18745.stoneleaf.02.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18745
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18896
___
___
1 - 100 of 114 matches
Mail list logo
