[ python-Bugs-1688274 ] Python/C PyClass_* are not documented
Bugs item #1688274, was opened at 2007-03-26 14:24 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=1688274&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tommi Vainikainen (tvainika) Assigned to: Nobody/Anonymous (nobody) Summary: Python/C PyClass_* are not documented Initial Comment: Python/C API Reference Manual chapter 7.5 Other Objects does not contain subchapter for Class objects, but only Instance objects and many other are documented there. >From header I can find that at least PyClass_Check and PyClass_New exist, I >just don't know what those do until I take time to read source code... :( -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-542314 ] long file name support broken in windows
Bugs item #542314, was opened at 2002-04-11 06:23
Message generated for change (Comment added) made by titty
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542314&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mark Hammond (mhammond)
Assigned to: Nobody/Anonymous (nobody)
Summary: long file name support broken in windows
Initial Comment:
>From c.l.py, thread ""
Peter D:
I'm using windows and trying to call os.path.getmtime
() after using os.path.walk... However, I'm choking
with "[Errno 38] Filename too long" on paths with len
> ~260
Adding Martin's reply in a new comment (so it is not
at the top of each and every mail I get on this bug :)
--
Comment By: Ralf Schmitt (titty)
Date: 2007-03-26 14:36
Message:
Logged In: YES
user_id=17929
Originator: NO
or if the c library is just insane:
from http://msdn2.microsoft.com/en-us/library/aa365247.aspx:
Maximum Path Length
In the Windows API, the maximum length for a path is MAX_PATH, which is
defined as 260 characters. A path is structured in the following order:
drive letter, colon, backslash, components separated by backslashes, and a
null-terminating character, for example, the maximum path on the D drive is
D:\<256 chars>NUL.
The Unicode versions of several functions permit a maximum path length of
approximately 32,000 characters composed of components up to 255 characters
in length. To specify that kind of path, use the "\\?\" prefix.
Note The maximum path of 32,000 characters is approximate, because
the "\\?\" prefix can be expanded to a longer string, and the expansion
applies to the total length.
For example, "\\?\D:\". To specify such a UNC path, use the
"\\?\UNC\" prefix. For example, "\\?\UNC\\". These prefixes
are not used as part of the path itself. They indicate that the path should
be passed to the system with minimal modification, which means that you
cannot use forward slashes to represent path separators, or a period to
represent the current directory. Also, you cannot use the "\\?\" prefix
with a relative path. Relative paths are limited to MAX_PATH characters.
When using the API to create a directory, the specified path cannot be so
long that you cannot not append an 8.3 file name.
The shell and the file system may have different requirements. It is
possible to create a path with the API that the shell UI cannot handle.
-
the explicit checks for pathnames longer than 260 characters seem to be
removed in python 2.5
and one can use the "magic prefix" to stat/create files with pathnames
longer than 260 characters.
--
Comment By: Stuart Norton (stunorton)
Date: 2005-03-30 18:54
Message:
Logged In: YES
user_id=1152606
I came across this suggestion while googling... and I would
have expected it to work, but this code:
import os
os.chdir("ussvs-file02
\\radpubs\\wip\\zStaging\\translation\\D10
\\previous_test\\cumulative\\Common\\Reference\\API\\Borland
.Eco.Persistence.Configuration\\classes\\PersistenceMapper
DefinitionCollection\\Methods")
for filename in os.listdir("."):
print filename
infile = file(filename)
gives me
C:\Documents and
Settings\snorton\Desktop\h2build\buildtools>test.py
PersistenceMapperDefinitionCollection.AddRange.xml
PersistenceMapperDefinitionCollection.Assign.xml
PersistenceMapperDefinitionCollection.FindByName.xml
PersistenceMapperDefinitionCollection.NameExists.xml
PersistenceMapperDefinitionCollection.PersistenceMapperDefi
nitionCollection.xml
Traceback (most recent call last):
File "C:\Documents and
Settings\snorton\Desktop\h2build\buildtools\test.py", line 6,
in ?
infile = file(filename)
IOError: [Errno 2] No such file or
directory: 'PersistenceMapperDefinitionCollection.Persistence
MapperDefinitionCollection.xml'
... funny that the file with the long path comes up in listdir()
but isn't found with file()...
--
Comment By: Mark Hammond (mhammond)
Date: 2002-04-11 06:26
Message:
Logged In: YES
user_id=14198
Martin v. Loewis's reply on c.l.py:
Since you are asking for a work-around: cd into one of the
more nested directories when the path gets longer
(os.chdir), and use relative paths from then on.
If you want to study how to solve the problem: the relevant
code snippet is in Modules/posixmodule.c
/* the library call can blow up if the file name is
too long! */
if (pathlen > MAX_PATH) {
PyMem_Free(pathfree);
errno = ENAMETOOLONG;
return posix_error();
}
There might be different ways to approa
[ python-Bugs-1688393 ] sock.recvfrom(-24) crashes
Bugs item #1688393, was opened at 2007-03-27 00:13
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=1688393&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: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: sock.recvfrom(-24) crashes
Initial Comment:
Actually sock.recvfrom(x) crashes or causes memory corruption for all values in
-sizeof(PyStringObject) <= x < 0, I think.
This script demonstrates the problem:
import socket, sys
s1 = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s1.bind(('127.0.0.1', ))
s2 = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s2.sendto('fdsjkldsfkj', ('127.0.0.1', ))
print s1.recvfrom(-24)
Try e.g. -1 instead of -24 as well.
I'm attaching a patch that fixes this bug, and adds a simple test for it too.
Other sock_recv* functions in socketmodule.c seem to already catch negative
recvlen values and raise ValueError, but for some reason recvfrom missed out.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688393&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1688564 ] os.path.join.__doc__ should mention absolute paths
Bugs item #1688564, was opened at 2007-03-26 10:12
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=1688564&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.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Eugene Kramer (zdes)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.join.__doc__ should mention absolute paths
Initial Comment:
Currently, automatically generated docs from os.path.join do not mention that
all paths prior to the last absolute path are discarded.
The __doc__ says:
"Join two or more pathname components, inserting '/' as needed"
>From this documentation, it is not obvious that os.path.join("abc", "/cde",
>"fgh") results in "/cde/fgh".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688564&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1687163 ] Inconsistent Exceptions for Readonly Attributes
Bugs item #1687163, was opened at 2007-03-23 16:51
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&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: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Collin Winter (collinwinter)
Summary: Inconsistent Exceptions for Readonly Attributes
Initial Comment:
Attempting assignment to a readonly attribute raises an Attribute error for
pure Python attributes but raises a TypeError for C readonly attributes. I
think the AttributeError is the correct exception.
>>> class A(object):
... _x = []
...
... @property
... def x(self):
... return self._x
...
>>> a = A()
>>> a.x = None
Traceback (most recent call last):
a.x = None
AttributeError: can't set attribute
>>> def f():
... yield None
>>> g = f()
>>> g.gi_frame = None
Traceback (most recent call last):
g.gi_frame = None
TypeError: readonly attribute
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-03-26 15:18
Message:
Logged In: YES
user_id=80475
Originator: YES
Collin, would you please apply this to the Py3K code.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-03-23 18:52
Message:
Logged In: YES
user_id=80475
Originator: YES
Here's the one line change:
Index: Python/structmember.c
===
--- Python/structmember.c (revision 54557)
+++ Python/structmember.c (working copy)
@@ -160,7 +160,7 @@
if ((l->flags & READONLY) || l->type == T_STRING)
{
- PyErr_SetString(PyExc_TypeError, "readonly attribute");
+ PyErr_SetString(PyExc_AttributeError, "readonly
attribute");
Four of the tests will need to be updated:
test_csv test_descr test_generators test_os
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-03-23 17:16
Message:
Logged In: YES
user_id=80475
Originator: YES
Readonly methods throw an AttributeError, but readonly members (anything
defined in PyMemberDef with an RO or READONLY flag) raise a TypeError.
--
Comment By: Jack Diederich (jackdied)
Date: 2007-03-23 17:12
Message:
Logged In: YES
user_id=591932
Originator: NO
I think this has something peculiar to frames, for instance:
Python 2.5 (r25:51908, Sep 25 2006, 17:50:07)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = 'asdf'
>>> f.strip = 42
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'str' object attribute 'strip' is read-only
>>>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&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
Bugs item #1662529, was opened at 2007-02-17 13:38 Message generated for change (Comment added) made by nnorwitz 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: 3rd Party >Status: Closed >Resolution: Invalid 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: Neal Norwitz (nnorwitz) Date: 2007-03-26 23:18 Message: Logged In: YES user_id=33168 Originator: NO These problems are almost always issues in the third party modules. I'm closing this on the basis that the problem is likely in ORBit. If you have more information that points to the core as the likely cause, please reopen this report. Without more info, we can't help with this problem. Note another problem could be that Python 2.5 does not allow the memory APIs to be mixed as they used to. This could also lead to a problem like this (though I think it often leads to a crash earlier IIRC.) -- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 19: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
