[ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86

[SourceForge.net]

Bugs item #1675511, was opened at 2007-03-07 02:54
Message generated for change (Comment added) made by cgaspar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 7
Private: No
Submitted By: Carson Gaspar (cgaspar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python still uses broken -xcode option on Solaris/x86

Initial Comment:
Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting 
a new bug against 2.5 in the hopes that someone will read it... text updated 
with minor corrections.

Python 2.5, Solaris x86 10 Update 3, Sun Studio 11

xcode=pic32 option is not supported on Solaris x86 Sun C  . Python's 
./configure script on Solaris systems sets the
compiler flag -xcode=pic32 when any compiler other than gcc is used. 
Unfortunately, the -xcode flag is only available in the sparc version of Sun C. 
The x86 version of Sun C does not support the -xcode option at all and 
generates an error that an illegal option was used. The portable flag supported 
on both platforms to use independent 32-bit addressing is -KPIC.

--

>Comment By: Carson Gaspar (cgaspar)
Date: 2007-03-09 03:06

Message:
Logged In: YES 
user_id=664506
Originator: YES

While the doc labels the -KPIC option as "obsolete" for SPARC, it works
fine. Perhaps Studio 12 will break it, but all current compilers understand
it fine.

If you want to be pedantically correct and use -xcode=pic32, you don't
need an architecture test, you need to actually _try_ the option, as older
SPARC compilers won't accept it either.


--

Comment By: Martin v. Löwis (loewis)
Date: 2007-03-09 02:08

Message:
Logged In: YES 
user_id=21627
Originator: NO

One problem is that the proposed change is incorrect. According to the C
User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete
option on SPARC, and should be replaced with -xcode=pic32 (section
A.1.15).

So I think a patch should be architecture-specific. Can somebody come up
with a patch that does that?



--

Comment By: James Lick (jlick)
Date: 2007-03-07 03:34

Message:
Logged In: YES 
user_id=673069
Originator: NO

Perhaps I was unclear in bug #1561333 that this resulted in only a
warning.  Actually the build will fail because of the incorrect flag.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1675026 ] Redirect cause invalid descriptor error

[SourceForge.net]

Bugs item #1675026, was opened at 2007-03-06 16:58
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675026&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jean-Marc Ranger (jmranger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Redirect cause invalid descriptor error

Initial Comment:
Test setup:
- Windows 2000 (french)
- Python 2.5 (reproducible with 2.4.2 and 2.4.4)

One python source file, test.py:
---
  import os
  print os.system("echo test")
---

Console output:
---
C:\test>test.py
test
0

C:\test>test.py > test.log
Descripteur non valide

C:\test>type test.log
0

C:\test>c:\python25\python test.py
test
0

C:\test>c:\python25\python test.py > test.log

C:\test>type test.log
test
0

C:\test>
---

The "Descripteur non valide" error would translate to "invalid file descriptor".

I would expect the 2nd call to perform the same way the 4th does.


--

>Comment By: Thomas Heller (theller)
Date: 2007-03-09 09:25

Message:
Logged In: YES 
user_id=11105
Originator: NO

This is a windows bug.  See the Microsoft Knowledge Base:

http://support.microsoft.com/kb/321788

This entry talks about Windows 2000.  I do not use Windows 2000 anymore,
so I cannot test on this version.  I have created the registry entry that
is mentioned on WinXP SP2 (German version, fwiw), and it does fix the
problem.  I had to open a new command window after changing the registry.

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-03-09 08:10

Message:
Logged In: YES 
user_id=21627
Originator: NO

Do you have an explanation for the cause of the problem?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675026&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86

[SourceForge.net]

Bugs item #1675511, was opened at 2007-03-07 08:54
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 5
Private: No
Submitted By: Carson Gaspar (cgaspar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python still uses broken -xcode option on Solaris/x86

Initial Comment:
Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting 
a new bug against 2.5 in the hopes that someone will read it... text updated 
with minor corrections.

Python 2.5, Solaris x86 10 Update 3, Sun Studio 11

xcode=pic32 option is not supported on Solaris x86 Sun C  . Python's 
./configure script on Solaris systems sets the
compiler flag -xcode=pic32 when any compiler other than gcc is used. 
Unfortunately, the -xcode flag is only available in the sparc version of Sun C. 
The x86 version of Sun C does not support the -xcode option at all and 
generates an error that an illegal option was used. The portable flag supported 
on both platforms to use independent 32-bit addressing is -KPIC.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-03-09 09:56

Message:
Logged In: YES 
user_id=21627
Originator: NO

I don't want to make a change now, just to have to deal with a bug report
two years from now which then will sit again in this tracker for years
again. I'm fine with documenting that older SunPRO compilers are not
supported; -xcode has been supported atleast since Sun Forte 6 (released in
2000); earlier products had reached their end-of-life long ago. So either
this gets fixed properly now, or not at all.


--

Comment By: Carson Gaspar (cgaspar)
Date: 2007-03-09 09:06

Message:
Logged In: YES 
user_id=664506
Originator: YES

While the doc labels the -KPIC option as "obsolete" for SPARC, it works
fine. Perhaps Studio 12 will break it, but all current compilers understand
it fine.

If you want to be pedantically correct and use -xcode=pic32, you don't
need an architecture test, you need to actually _try_ the option, as older
SPARC compilers won't accept it either.


--

Comment By: Martin v. Löwis (loewis)
Date: 2007-03-09 08:08

Message:
Logged In: YES 
user_id=21627
Originator: NO

One problem is that the proposed change is incorrect. According to the C
User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete
option on SPARC, and should be replaced with -xcode=pic32 (section
A.1.15).

So I think a patch should be architecture-specific. Can somebody come up
with a patch that does that?



--

Comment By: James Lick (jlick)
Date: 2007-03-07 09:34

Message:
Logged In: YES 
user_id=673069
Originator: NO

Perhaps I was unclear in bug #1561333 that this resulted in only a
warning.  Actually the build will fail because of the incorrect flag.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1675026 ] Redirect cause invalid descriptor error

[SourceForge.net]

Bugs item #1675026, was opened at 2007-03-06 15:58
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675026&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jean-Marc Ranger (jmranger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Redirect cause invalid descriptor error

Initial Comment:
Test setup:
- Windows 2000 (french)
- Python 2.5 (reproducible with 2.4.2 and 2.4.4)

One python source file, test.py:
---
  import os
  print os.system("echo test")
---

Console output:
---
C:\test>test.py
test
0

C:\test>test.py > test.log
Descripteur non valide

C:\test>type test.log
0

C:\test>c:\python25\python test.py
test
0

C:\test>c:\python25\python test.py > test.log

C:\test>type test.log
test
0

C:\test>
---

The "Descripteur non valide" error would translate to "invalid file descriptor".

I would expect the 2nd call to perform the same way the 4th does.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-09 10:16

Message:
Logged In: YES 
user_id=849994
Originator: NO

So we can do nothing about the bug, but we should definitely document that
somewhere and link to the Knowledge Base.

What would be the correct location?

--

Comment By: Thomas Heller (theller)
Date: 2007-03-09 08:25

Message:
Logged In: YES 
user_id=11105
Originator: NO

This is a windows bug.  See the Microsoft Knowledge Base:

http://support.microsoft.com/kb/321788

This entry talks about Windows 2000.  I do not use Windows 2000 anymore,
so I cannot test on this version.  I have created the registry entry that
is mentioned on WinXP SP2 (German version, fwiw), and it does fix the
problem.  I had to open a new command window after changing the registry.

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-03-09 07:10

Message:
Logged In: YES 
user_id=21627
Originator: NO

Do you have an explanation for the cause of the problem?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675026&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Feature Requests-1665292 ] Datetime enhancements

[SourceForge.net]

Feature Requests item #1665292, was opened at 2007-02-21 15:55
Message generated for change (Comment added) made by jcrocholl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1665292&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Datetime enhancements

Initial Comment:
I'm proposing some small enhancements to the datetime module:

Add a totimestamp() method to datetime.datetime that returns the seconds since 
1/1/1970 00:00:00. The datetime class has already a fromtimestamp() factory but 
is missing a totimestamp() method.

Add a __int__() and __float__() method to datetime.timedelta which return the 
seconds (seconds + 86400 * days) as int and seconds + miliseconds as float. It 
would save some typing if somebody needs an integer representation of a 
timedelta object :]

The datetime module is implemented in C. I've never written a Python C 
extension so I can't help with a patch.

Thx

--

Comment By: Johann C. Rocholl (jcrocholl)
Date: 2007-03-09 17:33

Message:
Logged In: YES 
user_id=656137
Originator: NO

The patch confuses microseconds with milliseconds.
The divisor in delta_float should be 100.0, not 1000.0.
The result of the last test should be 86401.01, not 86401.001.

--

Comment By: Christian Heimes (tiran)
Date: 2007-02-21 17:16

Message:
Logged In: YES 
user_id=560817
Originator: YES

File Added: timedelta.patch

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1665292&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-805194 ] Inappropriate error received using socket timeout

[SourceForge.net]

Bugs item #805194, was opened at 2003-09-12 12:56
Message generated for change (Comment added) made by dmeranda
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805194&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Popov (evgeni_popov)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inappropriate error received using socket timeout

Initial Comment:
When using the timeout option with a socket object 
(python 2.3), I don't have the same behaviour under 
Windows than under Linux / Mac.

Specifically, if trying to connect to an unopened port of 
the localhost, I get a timeout exception on Windows 
(tested under W2K Server), whereas I get a "111 - 
Connection Refused" exception on Linux and "22 - Invalid 
Argument" on Mac (OS X).

Even if the error message under Mac is not really 
appropriate (someone said to me he got the 
right 'Connection Refused' on his MAC), I think that the 
behaviour under Linux and Mac is the right one, in that it
sends (quickly) an error message and not timeouting.

Note that when using blocking socket the behaviour is 
ok under all platforms: they each return back quickly 
a "Connection refused" error message (err codes are 
different depending on the platform (61=Mac,
111=Linux, 10061=Windows)). FYI, I don't use firewall or 
similar prog on my windows box (but that should not 
matter, because it does work in blocking mode, so that 
can't be a firewall problem).

I heard that the timeout option was implemented based 
on Timothy O'Malley timeoutsocket.py. Then, maybe the 
pb can come from the usage of select in the connection 
function: select is not asked to get back exceptions in 
the returned triple, whereas I think some errors can be
returned back through this mean under Windows 
(according to Tip 25 of Jon C. Snader book's "Effective 
TCP/IP Programming"). So, by not checking the returned 
exceptions, we would miss the "connection refused" 
error and get instead the timeout error...


--

Comment By: Deron Meranda (dmeranda)
Date: 2007-03-09 11:53

Message:
Logged In: YES 
user_id=847188
Originator: NO

This is also a problem under HP-UX 11.0 with Python 2.5

The socket connect_ex() will return errno 22 EINVAL instead of
the more appropriate 239 ECONNREFUSED when connecting to a
non-listening socket ... but only if a socket timeout is being
used.

A system call trace reveils a little more what is going on.
For the python code

  import socket
  s = socket.socket( socket.AF_INET, socket.SOCK_STREAM )
  s.settimeout(15.0)
  res = s.connect_ex( ('127.0.0.1', 8099) )  # An unused port number

the system call sequence is as follows:

Calling socket.socket()
  socket(AF_INET, SOCK_STREAM, 0)  = 3
Calling s.settimeout(15.0)
  fcntl(3, F_GETFL, 0) = 2
  fcntl(3, F_SETFL, 65538) = 0
Calling s.connect_ex(...)
  connect(3, 0x400b43f0, 16)  = -1  -> ERR#245 EINPROGRESS
  poll(0x7cff1914, 1, 15000)  = 1
  connect(3, 0x400b43f0, 16)  = -1  -> ERR#22 EINVAL

If the call to settimeout is removed, then an ERR#239 ECONNREFUSED
is returned by the first connect() and no subsequent poll+connect
is attempted.  With the timeout set, note that the poll() returns
immediately no timeout actually occurs.

Note that tracing the same code under Linux shows the exact same
set of system calls, but that the second connect() call returns
ECONNREFUSED instead.

So this appears to be a specific behavior of HP-UX (and
perhaps other Unixes).

Excerpted from the HP man pages for connect(2):

  [EINVAL] The socket has already been shut down or
   has a listen() active on it; addrlen is
   a bad value; an attempt was made to
   connect() an AF_UNIX socket to an NFS-
   mounted (remote) name; the X.121 address
   length is zero, negative, or greater
   than 15 digits.

   For datagram sockets, if addrlen is a
   bad value, the peer address is no longer
   maintained by the system.

  [ECONNREFUSED] The attempt to connect was forcefully
 rejected.

  [EINPROGRESS] Nonblocking I/O is enabled using
O_NONBLOCK, O_NDELAY, or FIOSNBIO, and
the connection cannot be completed
immediately.  This is not a failure.
Make the connect() call again a few
seconds later.  Alternatively, wait for
completion by calling select() and
selecting for write.


--

Comment By: Troels Walsted Hansen (troels)
Date: 2004-06-02 04:51

Message:
Logged In: YES 
user_id=32863

The Windows part of this bug is a duplicate of bug #777597.

[ python-Bugs-1629566 ] documentation of email.utils.parsedate is confusing

[SourceForge.net]

Bugs item #1629566, was opened at 2007-01-06 16:37
Message generated for change (Settings changed) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629566&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nicholas Riley (nriley)
>Assigned to: Collin Winter (collinwinter)
Summary: documentation of email.utils.parsedate is confusing

Initial Comment:
This sentence in the documentation for email.utils.parsedate confused me:

"Note that fields 6, 7, and 8 of the result tuple are not usable."

These indices are zero-based, so it's actually fields 7, 8 and 9 that they are 
talking about (in normal English).  Either this should be changed to 7-9 or be 
re-expressed in a way that makes it clear it's zero-based, for example by using 
Python indexing notation.

Thanks.

--

Comment By: Mark Roberts (mark-roberts)
Date: 2007-01-19 20:16

Message:
Logged In: YES 
user_id=1591633
Originator: NO

Link to document in question:
http://www.python.org/doc/lib/module-email.utils.html

www.python.org/sf/1639973 for doc patch

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629566&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1629566 ] documentation of email.utils.parsedate is confusing

[SourceForge.net]

Bugs item #1629566, was opened at 2007-01-06 16:37
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629566&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nicholas Riley (nriley)
Assigned to: Collin Winter (collinwinter)
Summary: documentation of email.utils.parsedate is confusing

Initial Comment:
This sentence in the documentation for email.utils.parsedate confused me:

"Note that fields 6, 7, and 8 of the result tuple are not usable."

These indices are zero-based, so it's actually fields 7, 8 and 9 that they are 
talking about (in normal English).  Either this should be changed to 7-9 or be 
re-expressed in a way that makes it clear it's zero-based, for example by using 
Python indexing notation.

Thanks.

--

>Comment By: Collin Winter (collinwinter)
Date: 2007-03-09 13:13

Message:
Logged In: YES 
user_id=1344176
Originator: NO

Fixed in r54243. I changed the ambiguous word "fields" to "indexes", which
should make it perfectly clear where the count starts from.

Thanks for the bug report!

--

Comment By: Mark Roberts (mark-roberts)
Date: 2007-01-19 20:16

Message:
Logged In: YES 
user_id=1591633
Originator: NO

Link to document in question:
http://www.python.org/doc/lib/module-email.utils.html

www.python.org/sf/1639973 for doc patch

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629566&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1628987 ] inspect trouble when source file changes

[SourceForge.net]

Bugs item #1628987, was opened at 2007-01-05 13:43
Message generated for change (Comment added) made by philipdumont
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628987&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: phil (philipdumont)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect trouble when source file changes

Initial Comment:
backtrace (relevant outer frames only):

  File "/path/to/myfile", line 1198, in get_hook_name
for frame_record in inspect.stack():
  File "/usr/mbench2.2/lib/python2.4/inspect.py", line 819, in stack
return getouterframes(sys._getframe(1), context)
  File "/usr/mbench2.2/lib/python2.4/inspect.py", line 800, in getouterframes
framelist.append((frame,) + getframeinfo(frame, context))
  File "/usr/mbench2.2/lib/python2.4/inspect.py", line 775, in getframeinfo
lines, lnum = findsource(frame)
  File "/usr/mbench2.2/lib/python2.4/inspect.py", line 437, in findsource
if pat.match(lines[lnum]): break
IndexError: list index out of range

Based on a quick look at the inspect code, I think
this happens when you:

  - Start python and load a module
  - While it's running, edit the source file for the
module (before inspect tries to look into it).
  - Call a routine in the edited module that will
lead to a call to inspect.stack().

During an inspect.stack() call, inspect will open
source files to get the source code for the
routines on the stack.  If the source file that is
opened doesn't match the byte compiled code that's
being run, there are problems.  Inspect caches the
files it reads (using the linecache module), so if
the file gets cached before it is edited, nothing
should go wrong.  But if the source file is edited
after the module is loaded and before inspect has
a chance to cache the source, you're out of luck.

Of course, this shouldn't be a problem in production
code, but it has bit us more than once in a
development environment.

Seems like it would be easy to avoid by just comparing
the timestamps on the source/object files.  If the
source file is newer, just behave the same as if it
wasn't there.

Attached is a stupid little python script that
reproduces the problem.



--

>Comment By: phil (philipdumont)
Date: 2007-03-09 13:25

Message:
Logged In: YES 
user_id=1364034
Originator: YES

What I had in mind was something like changing:

def getsourcefile(object):
"""Return the Python source file an object was defined in, if it
exists."""
filename = getfile(object)
if string.lower(filename[-4:]) in ['.pyc', '.pyo']:
filename = filename[:-4] + '.py'
# ...the rest of the function...

to

def getsourcefile(object):
"""Return the Python source file an object was defined in, if it
exists."""
filename = getfile(object)
if string.lower(filename[-4:]) in ['.pyc', '.pyo']:
src_filename = filename[:-4] + '.py'
try:
# if src file has been edited since we loaded the obj
file, ignore it
if os.stat(filename).st_mtime >
os.stat(src_filename).st_mtime:
filename = src_filename
except OSError:
pass
# ...the rest of the function...


But now that I've tried to implement it, and thought about it a bit more,
I see some
of the issues with what I thought would be a simple fix:

- I originally thought that, if a module is loaded from source (either
because the
objfile did not exist, or because objfile was older), and the compiled src
was successfully
written to a new objfile, that inspect.getfile() would return the path to
the objfile.
I see now that that is not the case; it returns the srcfile.  That makes
my fix
a bit more difficult -- now you have to find out if there is an obj file,
and if
so, what it's called.

And even if you had a handle on both the srcfile and the objfile:

- Even if the srcfile's timestamp is newer than the objfile's, it doesn't
necessarily
mean that the srcfile has been edited since it was loaded.  It could be
that the srcfile
was already newer than the objfile before the module was loaded, so the
module was
loaded from the srcfile, and the objfile was not updated because it was
not writable by
the user.

- Even if the srcfile's timestamp is older than the objfile's, it doesn't
necessarily
mean that the srcfile represents what you have loaded in memory.  It could
be that
after you loaded the module, your colleague down the hall edited the
source, loaded
the module, and in the process was successful in updating the objfile. 
(Not a likely
scenario, but...)

- If the module was loaded from source, there wa

[ python-Bugs-805194 ] Inappropriate error received using socket timeout

[SourceForge.net]

Bugs item #805194, was opened at 2003-09-12 12:56
Message generated for change (Comment added) made by dmeranda
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805194&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Popov (evgeni_popov)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inappropriate error received using socket timeout

Initial Comment:
When using the timeout option with a socket object 
(python 2.3), I don't have the same behaviour under 
Windows than under Linux / Mac.

Specifically, if trying to connect to an unopened port of 
the localhost, I get a timeout exception on Windows 
(tested under W2K Server), whereas I get a "111 - 
Connection Refused" exception on Linux and "22 - Invalid 
Argument" on Mac (OS X).

Even if the error message under Mac is not really 
appropriate (someone said to me he got the 
right 'Connection Refused' on his MAC), I think that the 
behaviour under Linux and Mac is the right one, in that it
sends (quickly) an error message and not timeouting.

Note that when using blocking socket the behaviour is 
ok under all platforms: they each return back quickly 
a "Connection refused" error message (err codes are 
different depending on the platform (61=Mac,
111=Linux, 10061=Windows)). FYI, I don't use firewall or 
similar prog on my windows box (but that should not 
matter, because it does work in blocking mode, so that 
can't be a firewall problem).

I heard that the timeout option was implemented based 
on Timothy O'Malley timeoutsocket.py. Then, maybe the 
pb can come from the usage of select in the connection 
function: select is not asked to get back exceptions in 
the returned triple, whereas I think some errors can be
returned back through this mean under Windows 
(according to Tip 25 of Jon C. Snader book's "Effective 
TCP/IP Programming"). So, by not checking the returned 
exceptions, we would miss the "connection refused" 
error and get instead the timeout error...


--

Comment By: Deron Meranda (dmeranda)
Date: 2007-03-09 13:49

Message:
Logged In: YES 
user_id=847188
Originator: NO

Verified that AIX 5.2 works fine, it returns an ECONNREFUSED in
all cases.

Some interesting related links though:

Twisted bug# 2022
   http://twistedmatrix.com/trac/ticket/2022

"Non-blocking BSD socket connections" by D.J. Bernstein
   http://cr.yp.to/docs/connect.html

There's also an interesting comment in Apache's APR change
notes for APR 0.9 
which seems to indicate that perhaps doing a second connect()
is wrong:

  "*) Non-blocking connects shouldn't be calling connect a second
  time.  According to Single Unix, a non-blocking connect has
  succeeded when the select pops successfully.  It has failed
  if the select failed.  The second connect was causing 502's
  in the httpd-proxy.  [John Barbee [EMAIL PROTECTED]"

If the APR comment is correct, then perhaps this is a Python
bug after all??

--

Comment By: Deron Meranda (dmeranda)
Date: 2007-03-09 11:53

Message:
Logged In: YES 
user_id=847188
Originator: NO

This is also a problem under HP-UX 11.0 with Python 2.5

The socket connect_ex() will return errno 22 EINVAL instead of
the more appropriate 239 ECONNREFUSED when connecting to a
non-listening socket ... but only if a socket timeout is being
used.

A system call trace reveils a little more what is going on.
For the python code

  import socket
  s = socket.socket( socket.AF_INET, socket.SOCK_STREAM )
  s.settimeout(15.0)
  res = s.connect_ex( ('127.0.0.1', 8099) )  # An unused port number

the system call sequence is as follows:

Calling socket.socket()
  socket(AF_INET, SOCK_STREAM, 0)  = 3
Calling s.settimeout(15.0)
  fcntl(3, F_GETFL, 0) = 2
  fcntl(3, F_SETFL, 65538) = 0
Calling s.connect_ex(...)
  connect(3, 0x400b43f0, 16)  = -1  -> ERR#245 EINPROGRESS
  poll(0x7cff1914, 1, 15000)  = 1
  connect(3, 0x400b43f0, 16)  = -1  -> ERR#22 EINVAL

If the call to settimeout is removed, then an ERR#239 ECONNREFUSED
is returned by the first connect() and no subsequent poll+connect
is attempted.  With the timeout set, note that the poll() returns
immediately no timeout actually occurs.

Note that tracing the same code under Linux shows the exact same
set of system calls, but that the second connect() call returns
ECONNREFUSED instead.

So this appears to be a specific behavior of HP-UX (and
perhaps other Unixes).

Excerpted from the HP man pages for connect(2):

  [EINVAL] The socket has already been shut down or
   has a listen() active on it; addrlen is
   a bad value; an attempt was

[ python-Bugs-1646630 ] ctypes.string_at(buf, 0) is seen as zero-terminated-string

[SourceForge.net]

Bugs item #1646630, was opened at 2007-01-28 23:18
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646630&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Johannes Hölzl (johannes)
Assigned to: Thomas Heller (theller)
Summary: ctypes.string_at(buf, 0) is seen as zero-terminated-string

Initial Comment:
ctypes.string_at() interprets size=0 wrong.

When the size argument is 0, ctypes.string_at (and probably wstring_at too) 
string_at tries to read an zero-terminated string instead of an empty string.

Python 2.5 (r25:51908, Oct  6 2006, 15:22:41) 
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> bytes = (c_char*3)("1", "2", "\0")
>>> string_at(pointer(bytes))
'12'
>>> string_at(pointer(bytes), 0)
'12'
>>> string_at(pointer(bytes), 1)
'1'

instead of:

>>> string_at(pointer(bytes), 0)
''



--

>Comment By: Thomas Heller (theller)
Date: 2007-03-09 21:23

Message:
Logged In: YES 
user_id=11105
Originator: NO

Fixed in rev. 54244 (trunk) and rev. 54246 (release25-maint).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646630&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1516995 ] test_logging fails with reference count-checking enabled

[SourceForge.net]

Bugs item #1516995, was opened at 2006-07-04 10:34
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Collin Winter (collinwinter)
>Assigned to: Vinay Sajip (vsajip)
Summary: test_logging fails with reference count-checking enabled

Initial Comment:
When running from the following, test_logging fails:
./python Lib/test/regrtest.py -R :: test_logging.

Here's the traceback:

test test_logging crashed -- : 
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 554, in runtest_inner
dash_R(the_module, test, indirect_test, huntrleaks)
  File "Lib/test/regrtest.py", line 673, in dash_R
run_the_test()
  File "Lib/test/regrtest.py", line 660, in run_the_test
indirect_test()
  File
"/home/collin/src/python/Lib/test/test_support.py",
line 299, in inner
return func(*args, **kwds)
  File
"/home/collin/src/python/Lib/test/test_logging.py",
line 677, in test_main
test_main_inner()
  File
"/home/collin/src/python/Lib/test/test_logging.py",
line 640, in test_main_inner
globals()['test%d' % t]()
  File
"/home/collin/src/python/Lib/test/test_logging.py",
line 347, in test2
sh.close()
  File
"/home/collin/src/python/Lib/logging/__init__.py", line
687, in close
del _handlers[self]
KeyError: 




This problem does not occur when run without reference
count-checking.

System info:
Python SVN r47224
Linux 2.6.13
x86

--

>Comment By: Collin Winter (collinwinter)
Date: 2007-03-09 15:42

Message:
Logged In: YES 
user_id=1344176
Originator: YES

Still present as of 54248. Vinay, do you have any insights on this?

--

Comment By: Collin Winter (collinwinter)
Date: 2006-09-01 00:03

Message:
Logged In: YES 
user_id=1344176

This issue is still present as of r51654.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1651235 ] ctypes.Structure formal parameter dies given tuple

[SourceForge.net]

Bugs item #1651235, was opened at 2007-02-03 15:05
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1651235&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Gary Bishop (tgbishop)
Assigned to: Thomas Heller (theller)
Summary: ctypes.Structure formal parameter dies given tuple

Initial Comment:
With a structure like:

class CvRect(ctypes.Structure):
_fields_ = [("x", ctypes.c_int),
("y", ctypes.c_int),
("width", ctypes.c_int),
("height", ctypes.c_int)]

and a foreign function like:

cvSetImageROI = _cxDLL.cvSetImageROI
cvSetImageROI.restype = None # void
cvSetImageROI.argtypes = [
ctypes.c_void_p, # IplImage* image
CvRect # CvRect rect
]

The call

cvSetImageROI(img, CvRect(1,2,3,4))

works fine but the mistaken call:

cvSetImageROI(img, (1,2,3,4))

Produces the "Send Error Report" dialog from Windows.

Other erroneous arguments produce a message about correct argument type but the 
tuple triggers some other behavior.


--

>Comment By: Thomas Heller (theller)
Date: 2007-03-09 21:50

Message:
Logged In: YES 
user_id=11105
Originator: NO

Fixed in rev. 54248 (trunk) and rev. 54249 (release25-maint).

Thanks for the report.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1651235&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1628987 ] inspect trouble when source file changes

[SourceForge.net]

Bugs item #1628987, was opened at 2007-01-05 13:43
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628987&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: phil (philipdumont)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect trouble when source file changes

Initial Comment:
backtrace (relevant outer frames only):

  File "/path/to/myfile", line 1198, in get_hook_name
for frame_record in inspect.stack():
  File "/usr/mbench2.2/lib/python2.4/inspect.py", line 819, in stack
return getouterframes(sys._getframe(1), context)
  File "/usr/mbench2.2/lib/python2.4/inspect.py", line 800, in getouterframes
framelist.append((frame,) + getframeinfo(frame, context))
  File "/usr/mbench2.2/lib/python2.4/inspect.py", line 775, in getframeinfo
lines, lnum = findsource(frame)
  File "/usr/mbench2.2/lib/python2.4/inspect.py", line 437, in findsource
if pat.match(lines[lnum]): break
IndexError: list index out of range

Based on a quick look at the inspect code, I think
this happens when you:

  - Start python and load a module
  - While it's running, edit the source file for the
module (before inspect tries to look into it).
  - Call a routine in the edited module that will
lead to a call to inspect.stack().

During an inspect.stack() call, inspect will open
source files to get the source code for the
routines on the stack.  If the source file that is
opened doesn't match the byte compiled code that's
being run, there are problems.  Inspect caches the
files it reads (using the linecache module), so if
the file gets cached before it is edited, nothing
should go wrong.  But if the source file is edited
after the module is loaded and before inspect has
a chance to cache the source, you're out of luck.

Of course, this shouldn't be a problem in production
code, but it has bit us more than once in a
development environment.

Seems like it would be easy to avoid by just comparing
the timestamps on the source/object files.  If the
source file is newer, just behave the same as if it
wasn't there.

Attached is a stupid little python script that
reproduces the problem.



--

>Comment By: Collin Winter (collinwinter)
Date: 2007-03-09 18:18

Message:
Logged In: YES 
user_id=1344176
Originator: NO

"""
To be able to fix this right, you'd have to know what the timestamp was
on
whatever file
was loaded at the time that import loaded it.  I guess import itself
would
have to stash
this away somewhere.
"""

While I don't see this change being made, you might talk to Brett Cannon
about it. He's working on a rewrite of the import machinery in Python and
probably knows that system better than most by this point. Unless he/you
can come up with something, though, I'm inclined to close the bug because
of its provocation difficulty.

--

Comment By: phil (philipdumont)
Date: 2007-03-09 13:25

Message:
Logged In: YES 
user_id=1364034
Originator: YES

What I had in mind was something like changing:

def getsourcefile(object):
"""Return the Python source file an object was defined in, if it
exists."""
filename = getfile(object)
if string.lower(filename[-4:]) in ['.pyc', '.pyo']:
filename = filename[:-4] + '.py'
# ...the rest of the function...

to

def getsourcefile(object):
"""Return the Python source file an object was defined in, if it
exists."""
filename = getfile(object)
if string.lower(filename[-4:]) in ['.pyc', '.pyo']:
src_filename = filename[:-4] + '.py'
try:
# if src file has been edited since we loaded the obj
file, ignore it
if os.stat(filename).st_mtime >
os.stat(src_filename).st_mtime:
filename = src_filename
except OSError:
pass
# ...the rest of the function...


But now that I've tried to implement it, and thought about it a bit more,
I see some
of the issues with what I thought would be a simple fix:

- I originally thought that, if a module is loaded from source (either
because the
objfile did not exist, or because objfile was older), and the compiled src
was successfully
written to a new objfile, that inspect.getfile() would return the path to
the objfile.
I see now that that is not the case; it returns the srcfile.  That makes
my fix
a bit more difficult -- now you have to find out if there is an obj file,
and if
so, what it's called.

And even if you had a handle on both the srcfile and the objfile:

- Even if the srcfile's timestamp i

[ python-Bugs-1531963 ] SocketServer.TCPServer returns different ports

[SourceForge.net]

Bugs item #1531963, was opened at 2006-07-31 15:58
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531963&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: hakker.de (hakker_de)
Assigned to: Nobody/Anonymous (nobody)
Summary: SocketServer.TCPServer returns different ports

Initial Comment:
Providing 0 as a port in __init__ of 
SocketServer.TCPServer leads to different values for 
port in server_address and socket.getsockname().

Example:
import SocketServer
s = SocketServer.TCPServer(("0.0.0.0", 0), Handler)
s.server_address
-> ('0.0.0.0', 0)
s.socket.getsockname()
-> ('0.0.0.0', 39129)

s.server_address should also contain 39129 as the 
port number for the free port found.


--

>Comment By: Collin Winter (collinwinter)
Date: 2007-03-09 19:32

Message:
Logged In: YES 
user_id=1344176
Originator: NO

hakker, you marked this as "fixed"; was that intentional?

--

Comment By: Damon Kohler (damonkohler)
Date: 2006-08-22 21:36

Message:
Logged In: YES 
user_id=705317

Patch 1545011 is a proposed fix.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531963&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1677694 ] test_timeout refactoring

[SourceForge.net]

Bugs item #1677694, was opened at 2007-03-10 01:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1677694&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bj�rn Lindqvist (sonderblade)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_timeout refactoring

Initial Comment:
Please see #728815. 
https://sourceforge.net/tracker/index.php?func=detail&aid=728815&group_id=5470&atid=305470

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1677694&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1531963 ] SocketServer.TCPServer returns different ports

[SourceForge.net]

Bugs item #1531963, was opened at 2006-07-31 15:58
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531963&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Python 2.5
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: hakker.de (hakker_de)
Assigned to: Nobody/Anonymous (nobody)
Summary: SocketServer.TCPServer returns different ports

Initial Comment:
Providing 0 as a port in __init__ of 
SocketServer.TCPServer leads to different values for 
port in server_address and socket.getsockname().

Example:
import SocketServer
s = SocketServer.TCPServer(("0.0.0.0", 0), Handler)
s.server_address
-> ('0.0.0.0', 0)
s.socket.getsockname()
-> ('0.0.0.0', 39129)

s.server_address should also contain 39129 as the 
port number for the free port found.


--

>Comment By: Collin Winter (collinwinter)
Date: 2007-03-09 22:33

Message:
Logged In: YES 
user_id=1344176
Originator: NO

Fixed in r54253 (for 2.6), r54255 (for 2.5.1). Thanks for the bug report!

--

Comment By: Collin Winter (collinwinter)
Date: 2007-03-09 19:32

Message:
Logged In: YES 
user_id=1344176
Originator: NO

hakker, you marked this as "fixed"; was that intentional?

--

Comment By: Damon Kohler (damonkohler)
Date: 2006-08-22 21:36

Message:
Logged In: YES 
user_id=705317

Patch 1545011 is a proposed fix.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531963&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1677694 ] test_timeout refactoring

[SourceForge.net]

Bugs item #1677694, was opened at 2007-03-09 19:49
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1677694&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bj�rn Lindqvist (sonderblade)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_timeout refactoring

Initial Comment:
Please see #728815. 
https://sourceforge.net/tracker/index.php?func=detail&aid=728815&group_id=5470&atid=305470

--

>Comment By: Collin Winter (collinwinter)
Date: 2007-03-09 22:39

Message:
Logged In: YES 
user_id=1344176
Originator: NO

In a comment on patch #728815, you (Bjorn) said, "[p]lus, (I think) it
fixes a bug which (I think) only happens when you access the internet from
behind a web proxy." Could you split any bug fixes into a patch separate
from the code cleanup and refactoring? That will make reviewing it/them
easier.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1677694&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1662529 ] [2.5 regression?] failure to import the ORBit extension

[SourceForge.net]

Bugs item #1662529, was opened at 2007-02-17 16:38
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1662529&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: [2.5 regression?] failure to import the ORBit extension

Initial Comment:
seen with 2.5 SVN 20070216, with an interpreter built with --enable-pydebug, 
succeeds with a 2.4.4 interpreter built with --enable-pydebug:

pyorbit is version 2.14.1.

$ python-dbg -c 'import ORBit'
[26750 refs]
Fatal Python error: ../Objects/tupleobject.c:169 object at 0x8186bdc has 
negative ref count -1
Aborted (core dumped)

(gdb) bt
#0  0xb7f89410 in __kernel_vsyscall ()
#1  0xb7e11df0 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7e13641 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0x081174f8 in Py_FatalError (
msg=0xbfd0ef78 "../Objects/tupleobject.c:169 object at 0x8186bdc has 
negative ref count -1")
at ../Python/pythonrun.c:1555
#4  0x08093305 in _Py_NegativeRefcount (fname=0x816f958 
"../Objects/tupleobject.c", lineno=169, op=0x8186bdc)
at ../Objects/object.c:193
#5  0x080add27 in tupledealloc (op=0xb7a1bd1c) at ../Objects/tupleobject.c:169
#6  0x080973a6 in _Py_Dealloc (op=0xb7a1bd1c) at ../Objects/object.c:1928
#7  0x0814d037 in func_dealloc (op=0xb7a1d1c4) at ../Objects/funcobject.c:451
#8  0x080973a6 in _Py_Dealloc (op=0xb7a1d1c4) at ../Objects/object.c:1928
#9  0x0808eb99 in dict_dealloc (mp=0xb7a1c494) at ../Objects/dictobject.c:819
#10 0x080973a6 in _Py_Dealloc (op=0xb7a1c494) at ../Objects/object.c:1928
#11 0x0806459e in class_dealloc (op=0xb7a0bdb4) at ../Objects/classobject.c:184
#12 0x080973a6 in _Py_Dealloc (op=0xb7a0bdb4) at ../Objects/object.c:1928
#13 0x080add3b in tupledealloc (op=0xb7a22edc) at ../Objects/tupleobject.c:169
#14 0x080973a6 in _Py_Dealloc (op=0xb7a22edc) at ../Objects/object.c:1928
#15 0x08064540 in class_dealloc (op=0xb7a2446c) at ../Objects/classobject.c:183
#16 0x080973a6 in _Py_Dealloc (op=0xb7a2446c) at ../Objects/object.c:1928
#17 0x080add3b in tupledealloc (op=0xb7a243dc) at ../Objects/tupleobject.c:169
#18 0x080b13fe in subtype_dealloc (self=0xb7a243dc) at 
../Objects/typeobject.c:709
#19 0x080973a6 in _Py_Dealloc (op=0xb7a243dc) at ../Objects/object.c:1928
#20 0x0808eb99 in dict_dealloc (mp=0xb7dcf214) at ../Objects/dictobject.c:819
#21 0x080973a6 in _Py_Dealloc (op=0xb7dcf214) at ../Objects/object.c:1928
#22 0x08112acb in PyInterpreterState_Clear (interp=0x81b8020) at 
../Python/pystate.c:107
#23 0x081145be in Py_Finalize () at ../Python/pythonrun.c:441
#24 0x08059eb0 in Py_Main (argc=3, argv=0xbfd0f5b4) at ../Modules/main.c:545
#25 0x08058da6 in main (argc=Cannot access memory at address 0x155c
) at ../Modules/python.c:23


--

>Comment By: Collin Winter (collinwinter)
Date: 2007-03-09 22:51

Message:
Logged In: YES 
user_id=1344176
Originator: NO

The error message and backtrace here don't prove that it's a regression in
Python: it could easily be a problem with an extension module.

Do you get this error if you compile Python 2.5 without --with-pydebug?

Is "ORBit" provided by the project at
http://sourceforge.net/projects/orbit-python/ or the one at
http://ftp.gnome.org/pub/GNOME/sources/pyorbit/? If the former, the
project's SF page says active development stopped in 2004, so there's no
way it could support Python 2.5.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1662529&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-532631 ] Confusions in formatfloat

[SourceForge.net]

Bugs item #532631, was opened at 2002-03-20 18:34
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532631&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tim Peters (tim_one)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Confusions in formatfloat

Initial Comment:
stringobject.c's formatfloat seems confused in a 
couple respects.

1. Testing "fabs(x)/1e25 >= 1e25" is pretty baffling.  
What is it intending to do?  If it means what it says, 
it should be the simpler "fabs(x) >= 1e50".  But maybe 
it really intended to test "fabs(x) >= 1e25".

2. The "worst case length calc" is fantasy in some %f 
cases.  It assumes there's one digit before the 
decimal point, but, e.g., '%.100f'% 1e49 produces 
dozens of digits before the decimal point.  We're 
saved from a buffer overrun thanks to the PyOS_snprintf
() following, but unclear that truncation is sensible 
here (e.g., the user asked for a precision of 100 
here, but only gets back 50 digits after the decimal 
point).

Complication:  we're deliberately replacing C's %f 
with C's %g in some cases, but the docs don't document 
the rules Python intends for %f.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-10 07:03

Message:
Logged In: YES 
user_id=849994
Originator: NO

The docs say, "%f conversions for numbers whose absolute value is over
1e25 are replaced by %g conversions."

So is the correct solution "if fabs(x) >= 1e25"?

--

Comment By: Tim Peters (tim_one)
Date: 2003-01-08 21:28

Message:
Logged In: YES 
user_id=31435

Leaving this unassgned again, with the first and last points 
unresolved (I don't have time for this now).  The "worst 
case length calc" point is probably fixed.

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-08 19:55

Message:
Logged In: YES 
user_id=38388

Your first finding is baffling indeed. No idea how it came
to be 
(I don't remember having added such code). The test seems to
be intended to switch from 'g' format to 'f' format at an
arbirary number of decimals before the decimal point. 
"fabs(x) >= 1e50" should do the same. Feel free to change
this.

The second point should be fixed after my checkin:
>>> '%.100f'% 1e49
Traceback (most recent call last):
  File "", line 1, in ?
OverflowError: formatted float is too long (precision too
large?)


--

Comment By: Tim Peters (tim_one)
Date: 2003-01-08 01:29

Message:
Logged In: YES 
user_id=31435

Marc-Andre is in a better position to tell us what he fixed 
than I am, so assigned to him.  MAL, feel free to close this if 
you think it's history.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-08 01:24

Message:
Logged In: YES 
user_id=33168

Tim, did MALs recent checkin fix any of these problems?  Is
doc the only thing left to do?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532631&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-633930 ] Nested class __name__

[SourceForge.net]

Bugs item #633930, was opened at 2002-11-05 17:56
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633930&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Nested class __name__

Initial Comment:
The __name__ attribute of a nested class should be set
to 'outer.inner', both for classic and for new-style
classes. E.g.

>>> class C:
... class C1: pass
... 
>>> C.C1.__name__
'C.C1'
>>> 


--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-10 07:22

Message:
Logged In: YES 
user_id=849994
Originator: NO

Any interest for Python 3000 on this? Otherwise we can close it.

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-11 23:01

Message:
Logged In: YES 
user_id=6380

I'm less sure I even want this now, and not at all sure how
to do it any more, so lowering priority.


--

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-14 23:13

Message:
Logged In: YES 
user_id=6380

Hm, but should this also be done for functions inside
classes?  E.g.

class C:
 def foo(self): pass

assert C.foo.__name__ == "C.foo"
assert C.__dict__["foo"].__name__ == "C.foo"

And what about classes inside functions?

def f():
  class C: pass
  return C

assert f().__name__ == "f.C"

???


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633930&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com