[issue7242] Forking in a thread raises RuntimeError

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Using issue7242-gps01.diff on release26-maint and a freshly downloaded 
opensolaris 2009-06 VM test_thread, test_threading and test_subprocess all pass 
for me both before -and- after the patch.  Nor does the original thread_test.py 
cause the problem for me (meaning I'm unable to reproduce the problem in this 
VM in the first place so... someone else needs to)

Regardless, I altered patch_2 a bit in that diff to do what I though 
_PyImport_ReInitLock() should really do.  I also added the thread_unittest 
testcase to that diff.

% uname -a
SunOS opensolaris-vm 5.11 snv 111b i86pc i386 i86pc Solaris"

Can someone who could reproduce the problem in the first place please test that 
patch.

The logic change makes sense to me.  I don't know why 
test_threading.ThreadJoinOnShutdown.test_3_join_in_forked_from_thread would be 
changing behavior for you.

--
components: +Extension Modules -Library (Lib)
priority: normal -> high
Added file: http://bugs.python.org/file16395/issue7242-gps01.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7232] Support of 'with' statement fo TarFile class

[Lars Gustäbel]

Lars Gustäbel  added the comment:

Another version of the patch (issue7232.6.diff) that checks if the TarFile 
object is still open in the __enter__() method (plus a test for that). I 
removed the docstrings as Eric suggested. This is common practice in the 
standard library.

--
Added file: http://bugs.python.org/file16396/issue7232.6.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8029] bug in 2to3 dealing with "print FOO, " followed by "sys.stdout.write('')"

[R. David Murray]

Changes by R. David Murray :


--
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7242] Forking in a thread raises RuntimeError

[Greg Jednaszewski]

Greg Jednaszewski  added the comment:

The problem only seems to appear on Solaris 9 and earlier.  I'll try to test 
the updated patch tonight or tomorrow and let you know what I find.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

[R. David Murray]

R. David Murray  added the comment:

Because the shell argument provides important functionality.  Or are you 
suggesting that passing a list implies shell=False and passing a string implies 
shell=True?  That is a possibility, but I think it would not be a good idea, 
because people will 'accidentally' get shell=True (which, you will note is 
*not* the default), which is less secure.  It is much better, IMO, to make 
people ask explicitly for the less-safe behavior.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

[Eric Smith]

Eric Smith  added the comment:

I think the better design is to have 2 distinct APIs: Popen_shell and 
Popen_exec. I'm not wild about the name Popen_exec, suggestions welcome. 
Neither of these would accept a shell parameter.

For starters these could be convenience APIs that just call Popen with the 
correct shell= value, and check the type of args. We could ultimately deprecate 
Popen itself.

I don't see a use case where you programmatically compute the value of shell: 
it's always known as a function of how you're building up args. And even if 
such a rare case exists, you could select between the two APIs to call.

Whether at this point we can make this change is another issue, of course. I'm 
just trying to get at the best design. But if it's done over a number of 
releases I think it's doable.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

[Brian Curtin]

Brian Curtin  added the comment:

That seems reasonable. We already have subprocess.call, the thin wrapper around 
Popen. Maybe add this as subprocess.call_shell and call_exec?

--
nosy: +brian.curtin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

[R. David Murray]

R. David Murray  added the comment:

Hmm.  I liked Eric's idea, and it would be easier to get in, but 'call' is 
actually an argument against it.  It would mean that in addition to PopenExec 
and PopenShell we'd need call_exec and call_shell, and check_call_exec and 
check_call_shell.  Proliferating interfaces to handle a boolean parameter 
doesn't seem minimalist.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7232] Support of 'with' statement fo TarFile class

[Meador Inge]

Meador Inge  added the comment:

> This is common practice in the standard library.

This doesn't necessarily mean it is a correct practice :-).  All 
kidding aside, I think the assumption that the standard documentation 
on '__enter__' and '__exit__' is sufficient is a bad one.  With respect 
to how the 'tarfile' versions of these methods behave, that 
documentation is not that helpful.

In particular, the special behavior of an 'IOError' potentially being 
thrown from '__enter__' and the fact that '__exit__' does not swallow 
the exception.  These special behaviors should be documented either in 
a docstring or the library documentation.  I think this is important, 
but I may be being a bit pedantic.

Also, the last change to 'test_context_manager_exception' has a bug. 
If the call to 'tarfile.open' throws an exception, then the call to
'self.assertRaises' will swallow it.  This will cause an undefined
variable reference to 'tar' in 'self.assertTrue(tar.closed, ...)'.  I 
attached another update that fixes this problem.

--
Added file: http://bugs.python.org/file16398/issue7232.7.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7242] Forking in a thread raises RuntimeError

[Gregory P. Smith]

Gregory P. Smith  added the comment:

If you have a chance tonight that'd be awesome.  I'd love to get this in before 
2.6.5rc1 (being cut tomorrow) but as its platform specific (and a pretty-old 
platform at that) its not worth holding up the release.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8030] documentation bugs and improvements

[Christopher the Magnificent]

New submission from Christopher the Magnificent 
:

Help for list looks like this:

>>> help(list)
class list(object)
 |  list() -> new list
 |  list(sequence) -> new list initialized from sequence's items
 |  
 

Help for dict looks like this:

>>> help(dict)
class dict(object)
 |  dict() -> new empty dictionary.
 |  dict(mapping) -> new dictionary initialized from a mapping object's
 |  (key, value) pairs.
 |  dict(seq) -> new dictionary initialized as if via:
 |  d = {}
 |  for k, v in seq:
 |  d[k] = v
 |  dict(**kwargs) -> new dictionary initialized with the name=value pairs
 |  in the keyword argument list.  For example:  dict(one=1, two=2)
 |  
 

As suggested by the documentation above -- and proven by verification:

>>> a = [1, 2, 3]# a new list
>>> b = list(a)
>>> a is a
True
>>> a == b
True
>>> a is b
False
>>> a is list(a)
False

>>> a = {'do': 1, 'rey': 2, 'mi': 3}# a new dict
>>> b = dict(a)
>>> a is a
True
>>> a == b
True
>>> a is b
False
>>> a is dict(a)
False

-- we can clearly see that list(x) and dict(x) ALWAYS return a new, unique 
object.


What about set?  

>>> help(set)
class set(object)
 |  set(iterable) --> set object
 |  
 |  Build an unordered collection of unique elements.
 |  
 


help(set) simply reports that set(x) returns a set object.  For all we know, 
this could mean creating a new object only if coercion is necessary; that 
sounds plausible enough, and people could easily write code dependent on that 
assumption that would introduce VERY subtle bugs!

Experimentation shows however that, like list and dict, set always returns a 
new, unique object:

>>> a = {1, 2, 3}
>>> b = set(a)
>>> a is a
True
>>> a == b
True
>>> a is b
False
>>> a is set(a)
False

Yipes!  CONFUSION!!!  


How about we fix the documentation for set so that it matches that of list and 
dict, including disclosure of its always-create-new-object behavior?  We can 
also make the "returns" arrow have one hyphen instead of two for consistency 
with most other Python documentation.

Let's replace this line:
X   set(iterable) --> set object

with this line:
√   set(iterable) -> new set object
   
so that our help(set) documentation ends up looking like this:

class set(object)
 |  set(iterable) -> new set object
 |  
 |  Build an unordered collection of unique elements.
 |  
 


While we're at it, I'd recommend changing the help for list and dict so that 
instead of saying "list(sequence)", "dict(seq)", and "for k, v in seq:" -- 
which, besides being inconsistent in use of abbreviation, also use the older 
paradigm of sequences instead of iterables -- we instead say "list(iterable)", 
"dict(iterable)", and "for k, v in iterable:", giving us (X's by altered lines):

>>> help(list)
class list(object)
 |  list() -> new list
X|  list(iterable) -> new list initialized from sequence's items
 |  
 

>>> help(dict)
class dict(object)
 |  dict() -> new empty dictionary.
 |  dict(mapping) -> new dictionary initialized from a mapping object's
 |  (key, value) pairs.
X|  dict(iterable) -> new dictionary initialized as if via:
 |  d = {}
X|  for k, v in iterable:
 |  d[k] = v
 |  dict(**kwargs) -> new dictionary initialized with the name=value pairs
 |  in the keyword argument list.  For example:  dict(one=1, two=2)
 |  
 

Making these changes from "seq"/"sequence" to "iterable" will serve to 
eliminate confusion as to whether set objects are usable in list and dict 
constructors -- for example, like this:

>>> x = {('spam', 'icky'), 
...  ('balony', 'stomachable'), 
...  ('beef', 'palatable'),
...  ('turkey', 'yummy')}
>>> dict(x)
{'turkey': 'yummy', 'balony': 'stomachable', 'beef': 'palatable', 'spam': 
'icky'}

Python's clear and helpful online documentation is one of my most favorite 
features of the language, and I'm  not alone in feeling this way, so we should 
make it the very best resource that we can!  Python rules!!

--
assignee: georg.brandl
components: Documentation
messages: 100212
nosy: christopherthemagnificent, georg.brandl
severity: normal
status: open
title: documentation bugs and improvements
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7481] Failing to start a thread leaves "zombie" thread in "initial" state

[Gregory P. Smith]

Gregory P. Smith  added the comment:

fixed in trunk r78517 and release26-maint r78518.

still needs merging into py3k and release31-maint

--
resolution:  -> accepted

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7232] Support of 'with' statement fo TarFile class

[Lars Gustäbel]

Lars Gustäbel  added the comment:

IMO it is okay for __enter__() and __exit__() not to have docstrings.
I cannot see what's so special about the behaviour of __enter__() and 
__exit__().

__enter__() raises IOError only if the TarFile object has been already closed. 
This is exactly the behaviour I would expect, because it is the same every 
other TarFile method does when the object has been closed. IOW, using a closed 
TarFile as a context manager is the programmer's mistake, and I don't feel the 
need to document that case.

The fact that __exit__() only closes the TarFile object and does not swallow 
exceptions is what everyone expects from a "file object". It is the only 
logical thing to do, no need to document that either.

The test_context_manager_exception() test is fine. If the call to 
tarfile.open() really raises an exception then something is so terribly wrong 
and probably all of the testsuite's 200 tests will fail anyway. We can safely 
assume here that this will work, no need to double-check.

However, I have changed the docs again to be a bit more specific.

--
Added file: http://bugs.python.org/file16400/issue7232.8.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7481] Failing to start a thread leaves "zombie" thread in "initial" state

[Gregory P. Smith]

Gregory P. Smith  added the comment:

r78519 r78520 for py3k and 3.1.

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5802] The security descriptors of python binaries in Windows are not strict enough

[Hong Chen]

Hong Chen  added the comment:

Sorry for the delay, it's been a busy month.

I just tried python 3.1  If installed under c:\program files, the
access control list would be correct, only system & administrator
accounts get the modify privilege.

The default installation is to c:\python31, in which the access
control list has the issue that unprivileged users can modify it.

I guess a possible remedy to this is that after installation, the
setup program can just remove "authenticated users" from the access
control list, or at least remove the "modify" privilege from the
corresponding entry.

Thanks,
Hong

On Mon, Feb 8, 2010 at 7:23 AM, Brian Curtin  wrote:
>
> Brian Curtin  added the comment:
>
> Is the situation any different if you install Python to "C:\Program Files"? 
> This seems to be at least part of the reason IronPython installs to 
> "C:\Program Files", which was discussed on the IronPython list [1] a few 
> months ago.
>
>
> [1] 
> http://lists.ironpython.com/pipermail/users-ironpython.com/2009-October/011345.html
>
> --
> nosy: +brian.curtin
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Reviewers: gregory.p.smith, Benjamin, ilya.sandler,

Message:
Also, can you take a look at how the pdb unittests work and see if you
can come up with a way to unittest the KeyboardInterrupt behavior?

Particular for the 4 scenarios you outlined in your prior comments in
the bug (those all make sense to me).

http://codereview.appspot.com/216067/diff/2001/2002
File Lib/pdb.py (right):

http://codereview.appspot.com/216067/diff/2001/2002#newcode63
Lib/pdb.py:63: def sigint_handler(self, signum, frame):
Please move this below the __init__ definition.  It makes classes odd to
read when __init__ isn't the first method defined when people are
looking for the constructor to see how to use it.

http://codereview.appspot.com/216067/diff/2001/2002#newcode64
Lib/pdb.py:64: if self.allow_kbdint:
Initialize self.allow_kdbint in __init__ so that a SIGINT coming in
before _cmdloop has run doesn't cause an AttributeError.

http://codereview.appspot.com/216067/diff/2001/2002#newcode215
Lib/pdb.py:215: # keyboard interrupts allow for an easy way to interrupt
"to cancel the current command"

http://codereview.appspot.com/216067/diff/2001/2002#newcode356
Lib/pdb.py:356: #it appears that that when pdb is reading input from a
pipe
Space after the # please.

Also, could you add a comment in here describing what the effect of this
code is?

It looks like you catch KeyboardInterrupt here and remove the particular
interrupted command from the list of commands to run at the current
breakpoint but I may be misreading things as I haven't spent much time
in pdb.py.

Please review this at http://codereview.appspot.com/216067/show

Affected files:
   M Lib/pdb.py

Index: Lib/pdb.py
===
--- Lib/pdb.py  (revision 78520)
+++ Lib/pdb.py  (working copy)
@@ -13,8 +13,10 @@
  import re
  import pprint
  import traceback
+import signal

+
  class Restart(Exception):
  """Causes a debugger to be restarted for the debugged python  
program."""
  pass
@@ -58,6 +60,13 @@

  class Pdb(bdb.Bdb, cmd.Cmd):

+def sigint_handler(self, signum, frame):
+if self.allow_kbdint:
+raise KeyboardInterrupt()
+print >>self.stdout, "\nProgram interrupted. (Use 'cont' to  
resume)."
+self.set_step()
+self.set_trace(frame)
+
  def __init__(self, completekey='tab', stdin=None, stdout=None,  
skip=None):
  bdb.Bdb.__init__(self, skip=skip)
  cmd.Cmd.__init__(self, completekey, stdin, stdout)
@@ -72,6 +81,7 @@
  import readline
  except ImportError:
  pass
+signal.signal(signal.SIGINT, self.sigint_handler)

  # Read $HOME/.pdbrc and ./.pdbrc
  self.rcLines = []
@@ -176,7 +186,7 @@
  if not self.commands_silent[currentbp]:
  self.print_stack_entry(self.stack[self.curindex])
  if self.commands_doprompt[currentbp]:
-self.cmdloop()
+self._cmdloop()
  self.forget()
  return
  return 1
@@ -199,11 +209,22 @@
  self.interaction(frame, exc_traceback)

  # General interaction function
+def _cmdloop(self):
+while 1:
+try:
+# keyboard interrupts allow for an easy way to interrupt
+# cancel current command
+self.allow_kbdint = True
+self.cmdloop()
+self.allow_kbdint = False
+break
+except KeyboardInterrupt:
+print >>self.stdout, '--KeyboardInterrupt--'

  def interaction(self, frame, traceback):
  self.setup(frame, traceback)
  self.print_stack_entry(self.stack[self.curindex])
-self.cmdloop()
+self._cmdloop()
  self.forget()

  def displayhook(self, obj):
@@ -329,9 +350,18 @@
  prompt_back = self.prompt
  self.prompt = '(com) '
  self.commands_defining = True
-self.cmdloop()
-self.commands_defining = False
-self.prompt = prompt_back
+try:
+self.cmdloop()
+except (KeyboardInterrupt, IOError):
+#it appears that that when pdb is reading input from a pipe
+# we may get IOErrors, rather than KeyboardInterrupt
+self.commands.pop(bnum)   # remove this cmd list
+self.commands_doprompt.pop(bnum)
+self.commands_silent.pop(bnum)
+raise KeyboardInterrupt()
+finally:
+self.commands_defining = False
+self.prompt = prompt_back

  def do_break(self, arg, temporary = 0):
  # break [ ([filename:]lineno | function) [, "condition"] ]

--
title: better Ctrl-C support in pdb (program can be resumed) -> better Ctrl-C 
support in pdb (program can be resumed) (issue216067)

___
Python tracker 

[issue7232] Support of 'with' statement fo TarFile class

[Lars Gustäbel]

Lars Gustäbel  added the comment:

I found an issue that needs to be addressed: if there is an error while the 
TarFile object is opened for writing, we cannot simply call TarFile.close() in 
the __exit__() method. close() would try to finalize the archive, i.e. write 
two zero end-of-archive blocks and a number of padding blocks.

I changed __exit__() to call close() only if everything went fine. If there was 
an exception only the most basic cleanup is done.

I added more tests and adapted the docs.

--
Added file: http://bugs.python.org/file16401/issue7232.9.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7832] assertSameElements([0, 1, 1], [0, 0, 1]) does not fail

[Gregory P. Smith]

Gregory P. Smith  added the comment:

fwiw - The documentation was updated in trunk, py3k and release31-maint to 
mention this behavior of assertSameElements.

Assigning to Michael for a decision on whether or not to add to the API.

python-unittest-backport has since been supplanted by Michael's 
http://pypi.python.org/pypi/unittest2/.

--
assignee: gregory.p.smith -> michael.foord
priority: normal -> low

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8031] Can't get f2py to work at all

[Peter Jones]

New submission from Peter Jones :

I am user 11943. OS is Windows Vista Ultimate. I have followed the instructions 
on how to use f2py and get this error when I try it (is this a known bug? It 
appears that there is bug in f2py):

C:\Python26\Scripts>python f2py.py
Traceback (most recent call last):
  File "f2py.py", line 3, in 
import f2py2e
  File "C:\Python26\lib\site-packages\f2py2e\__init__.py", line 10, in 
import f2py2e
  File "C:\Python26\lib\site-packages\f2py2e\f2py2e.py", line 26, in 
import crackfortran
  File "C:\Python26\lib\site-packages\f2py2e\crackfortran.py", line 1586
as=b['args']
 ^
SyntaxError: invalid syntax

I have also tried the example to create a fortran module for python and get 
this error:

C:\Python26\Scripts>python f2py.py -c --fcompiler=gnu95 --compiler=mingw32 
-lmsvcr71 -m cep cep.for

Traceback (most recent call last):
  File "f2py.py", line 3, in 
import f2py2e
  File "C:\Python26\lib\site-packages\f2py2e\__init__.py", line 10, in 
import f2py2e
  File "C:\Python26\lib\site-packages\f2py2e\f2py2e.py", line 26, in 
import crackfortran
  File "C:\Python26\lib\site-packages\f2py2e\crackfortran.py", line 1586
as=b['args']
 ^
SyntaxError: invalid syntax

Additionally I use the Lahey/Fujitsu 95 compiler. Do I just replace the gnu95 
with lahey? 
Also Is the msvrc71.dll file the correct one to use? I use MSVC VS 2009, which 
uses msvc90.dll. Should I use it instead?

--
files: unnamed
messages: 100225
nosy: PeterJones
severity: normal
status: open
title: Can't get f2py to work at all
Added file: http://bugs.python.org/file16402/unnamed

___
Python tracker 

___






I am user 11943. OS is Windows Vista 
Ultimate. I have followed the instructions on how to use f2py and get this 
error when I try it (is this a known bug? It appears that there is bug in 
f2py):
 
C:\Python26\Scripts>python f2py.pyTraceback 
(most recent call last):  File "f2py.py", line 3, in 
    import f2py2e  File 
"C:\Python26\lib\site-packages\f2py2e\__init__.py", line 10, in 
    import f2py2e  File 
"C:\Python26\lib\site-packages\f2py2e\f2py2e.py", line 26, in 
    import crackfortran  File 
"C:\Python26\lib\site-packages\f2py2e\crackfortran.py", line 
1586    as=b['args'] 
^SyntaxError: invalid syntax
 
 
 
I have also tried the example to create a fortran 
module for python and get this error:
 
C:\Python26\Scripts>python f2py.py -c 
--fcompiler=gnu95 --compiler=mingw32 -lmsvcr71 -m cep cep.for
 
Traceback (most recent call last):  File 
"f2py.py", line 3, in     import 
f2py2e  File "C:\Python26\lib\site-packages\f2py2e\__init__.py", line 
10, in     import f2py2e  File 
"C:\Python26\lib\site-packages\f2py2e\f2py2e.py", line 26, in 
    import crackfortran  File 
"C:\Python26\lib\site-packages\f2py2e\crackfortran.py", line 
1586    as=b['args'] 
^SyntaxError: invalid syntax
 
 
 
 
Additionally I use the Lahey/Fujitsu 95 compiler. 
Do I just replace the gnu95 with lahey? 
Also Is the msvrc71.dll file the correct one to 
use? I use MSVC VS 2009, which uses msvc90.dll. Should I use it 
instead?
 
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8032] Add gdb7 hooks to make it easier to debug Python

[Dave Malcolm]

New submission from Dave Malcolm :

gdb 7 can be extended with Python code, allowing the writing of domain-specific 
pretty-printers and commands.  

I've been working on gdb 7 hooks to make it easier to debug python itself, as 
mentioned here:
https://fedoraproject.org/wiki/Features/EasierPythonDebugging


I'm attaching a patch for merger with "trunk".  My hope is to be the maintainer 
of this work, although I do not yet have SVN commit rights (see 
http://mail.python.org/pipermail/python-committers/2010-February/000711.html )

The code is fully compatible with the existing "Misc/gdbinit" macros - you can 
freely use both as needed.

= Two versions of Python =
This code is intended to run inside gdb.  There are potentially two Python 
versions involved here: that of the "inferior process" (the one being 
debugged), and that of the debugger.

As I understand things, gdb only supports embedding Python 2 at the moment.  
This code is thus targeting that version of Python.

So far, I've attempted to keep this code so that it will run when the "inferior 
process" is either Python 2 or Python 3.  I could vary this code in the py3k 
branch if desired.  The code would then track the "inferior process" version of 
Python, so that code to debug Python 3 would live in the py3k branch.  That 
code would still be written for Python 2, though.

= Makefile changes =

The Makefile installs the gdb hooks to -gdb.py relative to the built python 
(even if you're not using them), which some may find irritating.  It needs to 
do this for the test_gdb.py selftest to work (and for the gdb hooks to be 
usable if you're actually using them to debug your build of Python).

Should I write a gdb configuration test to check for the availability of gdb 
built with python?

I've added the file to .hgignore and .bzrignore.  IIRC, a similar thing can be 
done to the SVN metadata (I don't think this is expressable as a patch, 
though).  Alternatively, I could wire up the gdb tests to load the file from 
its location in the source tree.

However, I intend for this code to be installed to a location alongside the 
build Python, so that it can be automatically detected and used by gdb.  
Typically this means copying it to the path of the ELF file with a -gdb.py 
file.  In my RPM builds I add an extra copy, locating it relative to the 
location of the stripped DWARF data (e.g. 
/usr/lib/debug/usr/lib64/libpython26.so.1.0-gdb.py)

= Selftests =
The selftest runs whatever version of "gdb" is in the path, which then invokes 
the built version of python, running simple "print" commands and verifying that 
gdb is corrrectly representing the results in backtraces (even in the face of 
corrupt data).  I haven't fully tested the error cases yet (e.g. for when gdb 
is not installed).

The tests take about 14 seconds to run on my box:
[da...@brick trunk-gdb]$ time ./python Lib/test/regrtest.py -v -s test_gdb
The CWD is now /tmp/test_python_19369
test_gdb
test_NULL_ob_type (test.test_gdb.DebuggerTests) ... ok
test_NULL_ptr (test.test_gdb.DebuggerTests)
Ensure that a NULL PyObject* is handled gracefully ... ok
test_classic_class (test.test_gdb.DebuggerTests) ... ok
test_corrupt_ob_type (test.test_gdb.DebuggerTests) ... ok
test_corrupt_tp_flags (test.test_gdb.DebuggerTests) ... ok
test_corrupt_tp_name (test.test_gdb.DebuggerTests) ... ok
test_dicts (test.test_gdb.DebuggerTests) ... ok
test_getting_backtrace (test.test_gdb.DebuggerTests) ... ok
test_int (test.test_gdb.DebuggerTests) ... ok
test_lists (test.test_gdb.DebuggerTests) ... ok
test_long (test.test_gdb.DebuggerTests) ... ok
test_modern_class (test.test_gdb.DebuggerTests) ... ok
test_singletons (test.test_gdb.DebuggerTests) ... ok
test_strings (test.test_gdb.DebuggerTests) ... ok
test_subclassing_list (test.test_gdb.DebuggerTests) ... ok
test_subclassing_tuple (test.test_gdb.DebuggerTests)
This should exercise the negative tp_dictoffset code in the ... ok
test_tuples (test.test_gdb.DebuggerTests) ... ok
test_unicode (test.test_gdb.DebuggerTests) ... ok

--
Ran 18 tests in 13.233s

OK
1 test OK.
[36833 refs]

real0m13.599s
user0m11.771s
sys 0m1.384s

= Platform support =
I don't have access to anything other than Linux, so I've no idea how well this 
stuff works on other platforms.  My testing so far has been on Fedora, though 
I've heard of successful usage of this on Debian.

= Legal stuff =

Earlier versions of this code were licensed under the LGPL 2.1
I'm relicensing the code to be "under the same license as Python itself", 
assuming that's legally OK.  Do I need to state that in the file header, or is 
that redundant?

I'm in the process of doing the PSF Contributor Agreement paperwork (as an 
individual); waiting to get my hands on a fax machine.  My employer, Red Hat, 
has agreed for me to retain copyright on all contributions I make to Python.

--
components: Demos and Tools
messages: 100226
nosy: dmalc

[issue8032] Add gdb7 hooks to make it easier to debug Python

[Dave Malcolm]

Changes by Dave Malcolm :


--
keywords: +patch
Added file: 
http://bugs.python.org/file16403/add-gdb7-python-hooks-to-trunk.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8031] Can't get f2py to work at all

[Benjamin Peterson]

Benjamin Peterson  added the comment:

This is a 3rd party package problem. Please ask the maintainers of it.

--
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8031] Can't get f2py to work at all

[Peter Jones]

Peter Jones  added the comment:

I would like to recall this bug report. What happend was I went to the f2py 
web site and dowloaded the "latest" version and installed it over Pythoh 
x,y. So I uninstalled P x,y and resinstalled and the f2py works OK now. Some 
one should make it more clear in the documentation to not do what I did.

Peter.

- Original Message - 
From: "Peter Jones" 
To: 
Sent: Sunday, February 28, 2010 2:45 PM
Subject: [issue8031] Can't get f2py to work at all

New submission from Peter Jones :

I am user 11943. OS is Windows Vista Ultimate. I have followed the 
instructions on how to use f2py and get this error when I try it (is this a 
known bug? It appears that there is bug in f2py):

C:\Python26\Scripts>python f2py.py
Traceback (most recent call last):
  File "f2py.py", line 3, in 
import f2py2e
  File "C:\Python26\lib\site-packages\f2py2e\__init__.py", line 10, in 

import f2py2e
  File "C:\Python26\lib\site-packages\f2py2e\f2py2e.py", line 26, in 

import crackfortran
  File "C:\Python26\lib\site-packages\f2py2e\crackfortran.py", line 1586
as=b['args']
 ^
SyntaxError: invalid syntax

I have also tried the example to create a fortran module for python and get 
this error:

C:\Python26\Scripts>python 
f2py.py -c --fcompiler=gnu95 --compiler=mingw32 -lmsvcr71 -m cep cep.for

Traceback (most recent call last):
  File "f2py.py", line 3, in 
import f2py2e
  File "C:\Python26\lib\site-packages\f2py2e\__init__.py", line 10, in 

import f2py2e
  File "C:\Python26\lib\site-packages\f2py2e\f2py2e.py", line 26, in 

import crackfortran
  File "C:\Python26\lib\site-packages\f2py2e\crackfortran.py", line 1586
as=b['args']
 ^
SyntaxError: invalid syntax

Additionally I use the Lahey/Fujitsu 95 compiler. Do I just replace the 
gnu95 with lahey?
Also Is the msvrc71.dll file the correct one to use? I use MSVC VS 2009, 
which uses msvc90.dll. Should I use it instead?

--
files: unnamed
messages: 100225
nosy: PeterJones
severity: normal
status: open
title: Can't get f2py to work at all
Added file: http://bugs.python.org/file16402/unnamed

___
Python tracker 

___

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7242] Forking in a thread raises RuntimeError

[Greg Jednaszewski]

Greg Jednaszewski  added the comment:

I tested the updated patch, and the new unit test passes on my Sol 8 sparc, but 
the test_threading test still hangs on my system.  However, given that the test 
is skipped on several platforms and it does work on more relevant versions of 
Solaris, it's probably OK.  It's possible that an OS bug is causing that 
particular hang.

Plus, the original patch fixed the 'real world' scenario I was running into, so 
I'd like to see it get into the release candidate if you're OK with it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6560] socket sendmsg(), recvmsg() methods

[David Watson]

David Watson  added the comment:

Thanks for your interest!  I'm actually still working on the
patch I posted, docs and a test suite, and I'll post something
soon.

Yes, you could just use b"".join() with sendmsg() (and get
slightly annoyed because it doesn't accept buffers ;) ).  I made
sendmsg() take multiple buffers because that's the way the system
call works, but also to match recvmsg_into(), which gives you the
convenience of being able to receive part of the message into a
bytearray and part into an array.array("i"), say, if that's how
the data is formatted.

As you might know, gather-write with sendmsg() can give a
performance benefit by letting the kernel assemble the message
while copying the data from userspace rather than having
userspace copy the data once to form the message and then having
the kernel copy it again when the system call is made.  I suppose
with Python you just need a larger message to see the benefit :)
Since it can read from buffers, though, socket.sendmsg() can pull
a large chunk of data straight out of an mmap object, say, and
attach headers from a bytes object without the mmapped data being
touched by Python at all (or even entering userspace, in this
case).

The patch is for 3.x, BTW - "y*" is valid there (and does take a
buffer).

As for a good reference, I haven't personally seen one.  There's
POSIX and RFC 3542, but they don't provide a huge amount of
detail.  Perhaps the (updated) W. Richard Stevens networking
books?  I've got the Stevens/Rago second edition of Advanced
Programming in the Unix Environment, which discusses FD and
credential passing with sendmsg/recvmsg, but not very well (it
misuses CMSG_LEN, for one thing).  The networking books were
updated by different people though, so perhaps they do better.

The question of whether to use CMSG_NXTHDR() to step to the next
header when constructing the buffer for sendmsg() is a bit murky,
in particular.  I've assumed that this is the way to do it since
the examples in RFC 3542 (and most of the code I've seen
generally) use CMSG_FIRSTHDR() to get the initial pointer, but
I've found that glibc's CMSG_NXTHDR() can (wrongly, I think)
return NULL if the buffer hasn't been zero-filled beforehand
(this causes segfaults with the patch I initially posted).

@Wim:

Yes, the rfc3542 module from that package looks as if it would be
usable with these patches - although it's Python 2-only, GPL-only
and looks unmaintained.  Those kind of ancillary data
constructors will actually be needed to make full portable use of
sendmsg() and recvmsg() for things like IPv6, SCTP, Linux's
socket error queues, etc.  The same goes for data for the
existing get/setsockopt() methods, in fact - the present
suggestion to use the struct module is pretty inadequate when
there are typedefs involved and implementations might add and
reorder fields, etc.

The objects in that package seem a bit overcomplicated, though,
messing about with setter methods instead of just subclassing
"bytes" and having different constructors to create the object
from individual arguments or received bytes (say, ucred(1, 2, 3)
or ucred.from_bytes(...)).

Maybe the problem of testing patches well has been putting people
off so far?  Really exercising the system's CMSG_*HDR() macros in
particular isn't entirely straightforward.  I suppose there's
also a reluctance to write tests while still uncertain about how
to present the interface - that's another reason why I went for
the most general multiple-buffer form of sendmsg()!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3892] bsddb: test01_basic_replication fails sometimes

[Gregory P. Smith]

Gregory P. Smith  added the comment:

r.david.murray - sounds like a good idea.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8033] sqlite: broken long integer handling for arguments to user-defined functions

[Fred Fettinger]

New submission from Fred Fettinger :

Handling of long integers is broken for arguments to sqlite functions created 
with the create_function api. Integers passed to a sqlite function are always 
converted to int instead of long, which produces an incorrect value for 
integers outside the range of a int32 on a 32 bit machine. These failures 
cannot be reproduced on a 64 bit machine, since sizeof(long) == sizeof(long 
long).

I attached a program that demonstrates the failure. This program reports 
failures on a 32 bit machine, and all tests pass on a 64 bit machine.

--
components: Library (Lib)
files: sqlite_long_test.py
messages: 100235
nosy: BinaryMan32
severity: normal
status: open
title: sqlite: broken long integer handling for arguments to user-defined 
functions
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16404/sqlite_long_test.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8033] sqlite: broken long integer handling for arguments to user-defined functions

[Fred Fettinger]

Fred Fettinger  added the comment:

I've never really looked at the python source before, but this is my best guess 
at the problem:

For the standard SELECT query:
In Modules/_sqlite/cursor.c, _pysqlite_fetch_one_row() has this code:
PY_LONG_LONG intval;
...
} else if (coltype == SQLITE_INTEGER) {
intval = sqlite3_column_int64(self->statement->st, i);
if (intval < INT32_MIN || intval > INT32_MAX) {
converted = PyLong_FromLongLong(intval);
} else {
converted = PyInt_FromLong((long)intval);
}
}

For user-defined function arguments:
In Modules/_sqlite/connection.c, _pysqlite_build_py_params() has this code:
PY_LONG_LONG val_int;
...
case SQLITE_INTEGER:
val_int = sqlite3_value_int64(cur_value);
cur_py_value = PyInt_FromLong((long)val_int);
break;

A select query can return long integers from C to python but a user-defined 
function argument cannot.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6729] Add support for ssize_t

[Ryan Coyner]

Ryan Coyner  added the comment:

You don't want to do c_size_t = c_void_p because that will prevent type 
checking. We want c_size_t to be integers; setting it to c_void_p will accept 
other values. The lines that define c_size_t are doing a sizeof check to 
determine how many bits the CPU supports, and c_size_t should represent 
unsigned integers [1].

On a 16-bit machine: c_size_t = c_uint
On a 32-bit machine: c_size_t = c_ulong
On a 64-bit machine: c_size_t = c_ulonglong

Now, ssize_t is like size_t, except that it is signed [2]. So if I am not 
mistaken, all we have to do is:

if sizeof(c_uint) == sizeof(c_void_p):
c_size_t = c_uint
c_ssize_t = c_int
elif sizeof(c_ulong) == sizeof(c_void_p):
c_size_t = c_ulong
c_ssize_t = c_long
elif sizeof(c_ulonglong) == sizeof(c_void_p):
c_size_t = c_ulonglong
c_ssize_t = c_longlong


Patch attached with documentation and unit test.


[1] - 
http://www.gnu.org/software/libc/manual/html_node/Important-Data-Types.html
[2] - http://www.gnu.org/software/libc/manual/html_node/I_002fO-Primitives.html

--
keywords: +patch
nosy: +rcoyner
Added file: http://bugs.python.org/file16405/issue6729.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8031] Can't get f2py to work at all

[Éric Araujo]

Éric Araujo  added the comment:

Hello

This is indeed a problem with f2py. Please tell its maintaines that they can’t 
name an object “as” since it’s a reserved keyword in Python 2.6 and higher. 
Testing with 2.5 (previous stable version, released in 2006) would have shown 
it:  points to 
 which tells in “Transition Plan”:

“In Python 2.5, the new syntax will only be recognized if a future
statement is present:

  from __future__ import with_statement

This will make both 'with' and 'as' keywords.  Without the future
statement, using 'with' or 'as' as an identifier will cause a
Warning to be issued to stderr.

In Python 2.6, the new syntax will always be recognized; 'with'
and 'as' are always keywords.”

So we’ll close here, since it is a normal, documented behavior. The f2py people 
have to fix their code.

Regards

--
nosy: +merwok

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8031] Can't get f2py to work at all

[Éric Araujo]

Éric Araujo  added the comment:

While I’m thinking about this, is there a way to make the syntax error 
traceback more informative, i.e. adding “'{}' is a reserved keyword” in such 
cases?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7849] Improve "test_support.check_warnings()"

[Antoine Pitrou]

Antoine Pitrou  added the comment:

"lazy" sounds like a bad name for that parameter. It makes me think of lazy 
evaluation, not error checking.

There's also the problem that check_py3k_warnings() will check all 
DeprecationWarnings, not only py3k-specific ones. We need a 
Py3kDeprecationWarning subclass.
Besides, there doesn't seem to be any point accepting positional arguments in 
check_py3k_warnings(). If you want a custom filter, just use check_warnings() 
instead.

--
nosy: +benjamin.peterson, pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8032] Add gdb7 hooks to make it easier to debug Python

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
nosy: +gregory.p.smith
priority:  -> normal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4

[Gregory P. Smith]

Gregory P. Smith  added the comment:

In PC/pyconfig.h we #define Py_WINVER to _WIN32_WINNT_WIN2K  (0x500)  for 32bit 
builds.

I think we should update this to _WIN32_WINNT_WINXP  (0x501)  for all builds, 
not just 64bit.

Assigning to loewis as he does our windows release builds so likely knows what 
the ramifications of this would be.

--
assignee:  -> loewis
nosy: +gregory.p.smith, loewis
priority:  -> high
versions: +Python 3.2 -Python 2.5, Python 2.6, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Bumping the API level to XP might mean that we stop supporting Windows 2000; 
I'm not sure whether we agreed to that yet.

I'd be curious to find out why the constants were defined in Python 2.5.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6926] socket module missing IPPROTO_IPV6, IPPROTO_IPV4

[Gregory P. Smith]

Gregory P. Smith  added the comment:

"extended support" for windows 2000 server ends in a few months, mainstream 
support ended 5 years ago:

 http://support.microsoft.com/lifecycle/?LN=en-us&x=8&y=9&p1=7274

That, IMNSHO, implies that python 2.7 and 3.2 should not bother supporting 
win2k.

Regardless, I'd imagine we can look the particular constants in question up and 
hard code the values when the header files don't define them for us (that is 
also the obvious workaround for anyone needing them in code today).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com