[issue9761] stale .pyc files aren't cleaned out
New submission from Steve Thompson : I'm running pythong 2.6.1 on Windows XP SP3. On many occasions I have ran into cases where I've installed a new package via the package's setup.py (pylint, logilab-common, etc) and new .pyc files don't get generated when I attempt to run the tools/packages. I'm not sure if this should be considered a package issue or an interpreter issue. I'd like to see the interpreter regenerate the .pyc file as expected so my colleagues and I don't burn time on "broken" packages we know nothing about only to find out it was due to some stale .pyc files. A quick fix would be to make the packages in question clean out their installation directories or regenerate all the pyc files manually. How should this issue be handled? -- components: Interpreter Core, Windows messages: 115488 nosy: Steve.Thompson priority: normal severity: normal status: open title: stale .pyc files aren't cleaned out type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue9761> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9761] stale .pyc files aren't cleaned out
Steve Thompson added the comment: "Setup.py install". We've also seen this happen when checking our python files out of our version control system. Also seen a .pyc get used when the .py no longer exists, but I could see that being intentional behavior. On Sep 3, 2010 2:57 PM, "Brett Cannon" wrote: Brett Cannon added the comment: So are you installing new versions of a package you already have installed using ``python setup.py install``? Exactly what command are you using to do the install? -- nosy: +brett.cannon ___ Python tracker <http://bugs.python... -- Added file: http://bugs.python.org/file18734/unnamed ___ Python tracker <http://bugs.python.org/issue9761> ___"Setup.py install". We've also seen this happen when checking our python files out of our version control system. Also seen a .pyc get used when the .py no longer exists, but I could see that being intentional behavior. On Sep 3, 2010 2:57 PM, "Brett Cannon" <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Brett Cannon <mailto:br...@python.org";>br...@python.org> added the comment: So are you installing new versions of a package you already have installed using ``python setup.py install``? Exactly what command are you using to do the install? -- nosy: +brett.cannon ___Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org><http://bugs.python.";>http://bugs.python... ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9761] stale .pyc files aren't cleaned out
Steve Thompson added the comment: Hmmm... this definitely sounds like the issue for version controlled files, but does not explain the issue when installing packages from source. On Sep 3, 2010 3:16 PM, "Amaury Forgeot d'Arc" wrote: Amaury Forgeot d'Arc added the comment: Does your version control system let the files read-only by default? In this case, see issue6074. -- nosy: +amaury.forgeotdarc ___ Python tracker <http://bugs.python... -- Added file: http://bugs.python.org/file18735/unnamed ___ Python tracker <http://bugs.python.org/issue9761> ___Hmmm... this definitely sounds like the issue for version controlled files, but does not explain the issue when installing packages from source. On Sep 3, 2010 3:16 PM, "Amaury Forgeot d'Arc" <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Amaury Forgeot d'Arc <mailto:amaur...@gmail.com";>amaur...@gmail.com> added the comment: Does your version control system let the files read-only by default? In this case, see issue6074. -- nosy: +amaury.forgeotdarc ___Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org><http://bugs.python.";>http://bugs.python... ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite
Steve Thompson added the comment: So what's the current status of this on Windows Platforms? -- nosy: +Steve.Thompson ___ Python tracker <http://bugs.python.org/issue6074> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite
Steve Thompson added the comment: Any idea if this will be fixed (at all) and/or back ported to 2.6.x or 2.7.x? On Fri, Sep 3, 2010 at 3:36 PM, Amaury Forgeot d'Arc wrote: > > Amaury Forgeot d'Arc added the comment: > > This is still the case: on Windows, if foo.py is readonly, >python -c "import foo" > generates foo.pyc with the readonly attribute. > > Tested with 3.1 and current py3k (where the file is named > __pycache__\foo.cpython-32.pyc) > > -- > nosy: +amaury.forgeotdarc > > ___ > Python tracker > <http://bugs.python.org/issue6074> > ___ > -- Added file: http://bugs.python.org/file18739/unnamed ___ Python tracker <http://bugs.python.org/issue6074> ___Any idea if this will be fixed (at all) and/or back ported to 2.6.x or 2.7.x?On Fri, Sep 3, 2010 at 3:36 PM, Amaury Forgeot d'Arc <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Amaury Forgeot d'Arc <mailto:amaur...@gmail.com";>amaur...@gmail.com> added the comment: This is still the case: on Windows, if foo.py is readonly, Â Â python -c "import foo" generates foo.pyc with the readonly attribute. Tested with 3.1 and current py3k (where the file is named __pycache__\foo.cpython-32.pyc) -- nosy: +amaury.forgeotdarc ___ Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> <http://bugs.python.org/issue6074"; target="_blank">http://bugs.python.org/issue6074> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11920] ctypes: Strange bitfield structure sizing issue
New submission from Steve Thompson : Consider the following: import ctypes class struct1( ctypes.Structure ): _pack_ = 1 _fields_ = [ ( "first", ctypes.c_uint8, 1 ), ( "second", ctypes.c_uint8, 1 ), ( "third", ctypes.c_uint8, 1 ), ( "fourth", ctypes.c_uint8, 1 ), ( "fifth", ctypes.c_uint8, 1 ), ( "pad",ctypes.c_uint16, 11 ), ] s1 = struct1() print ctypes.sizeof( s1 ) class struct2( ctypes.Structure ): _pack_ = 1 _fields_ = [ ( "first", ctypes.c_uint16, 1 ), ( "second", ctypes.c_uint16, 1 ), ( "third", ctypes.c_uint16, 1 ), ( "fourth", ctypes.c_uint16, 1 ), ( "fifth", ctypes.c_uint16, 1 ), ( "pad",ctypes.c_uint16, 11 ), ] s2 = struct2() print ctypes.sizeof( s2 ) The output is: 3 2 I'm generating python code from real c code. The compiler I'm using for the real c code packs both of these structures into two bytes. I need a way to make the first example work in python like the compiler without having to modify the source code. Is this possible? -- components: ctypes messages: 134393 nosy: Steve.Thompson priority: normal severity: normal status: open title: ctypes: Strange bitfield structure sizing issue versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue11920> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11920] ctypes: Strange bitfield structure sizing issue
Steve Thompson added the comment:
So, knowing there's a potential cross platform inconsistency here, is there
a proposed way to deal with this that doesn't involve modifying the real c
code I'm interfacing with? That's not always an option.
On Mon, Apr 25, 2011 at 2:49 PM, Santoso Wijaya wrote:
>
> Santoso Wijaya added the comment:
>
> What compilers were used to build your Python distro and the native
> structure?
>
> I found out in _ctypes/cfield.c (lns. 76-95):
>
>if (bitsize /* this is a bitfield request */
>&& *pfield_size /* we have a bitfield open */
> #ifdef MS_WIN32
>/* MSVC, GCC with -mms-bitfields */
>&& dict->size * 8 == *pfield_size
> #else
>/* GCC */
>&& dict->size * 8 <= *pfield_size
> #endif
>&& (*pbitofs + bitsize) <= *pfield_size) {
>/* continue bit field */
>fieldtype = CONT_BITFIELD;
> #ifndef MS_WIN32
>} else if (bitsize /* this is a bitfield request */
>&& *pfield_size /* we have a bitfield open */
>&& dict->size * 8 >= *pfield_size
>&& (*pbitofs + bitsize) <= dict->size * 8) {
>/* expand bit field */
>fieldtype = EXPAND_BITFIELD;
> #endif
>
> So the allocation of the extra byte for the structure seems to depend on
> Python's compiler. To make sure, I compiled a native structure using MSVC:
>
> #pragma pack(1)
> typedef struct _struct1
> {
>UINT8 first : 1;
>UINT8 second : 1;
>UINT8 third : 1;
>UINT8 fourth : 1;
>UINT8 fifth : 1;
>UINT16 pad: 11;
> } struct1;
>
> And I got the same value (sizeof == 3).
>
> --
>
> ___
> Python tracker
> <http://bugs.python.org/issue11920>
> ___
>
--
Added file: http://bugs.python.org/file21777/unnamed
___
Python tracker
<http://bugs.python.org/issue11920>
___So, knowing there's a potential cross platform inconsistency here, is there
a proposed way to deal with this that doesn't involve modifying the real c
code I'm interfacing with? Â That's not always an option.
On Mon, Apr 25, 2011 at 2:49 PM, Santoso Wijaya
<mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
wrote:
Santoso Wijaya <mailto:santoso.wij...@gmail.com";>santoso.wij...@gmail.com> added
the comment:
What compilers were used to build your Python distro and the native
structure?
I found out in _ctypes/cfield.c (lns. 76-95):
  if (bitsize /* this is a bitfield request */
    && *pfield_size /* we have a bitfield open */
#ifdef MS_WIN32
    /* MSVC, GCC with -mms-bitfields */
    && dict->size * 8 == *pfield_size
#else
    /* GCC */
    && dict->size * 8 <= *pfield_size
#endif
    && (*pbitofs + bitsize) <= *pfield_size) {
    /* continue bit field */
    fieldtype = CONT_BITFIELD;
#ifndef MS_WIN32
  } else if (bitsize /* this is a bitfield request */
    && *pfield_size /* we have a bitfield open */
    && dict->size * 8 >= *pfield_size
    && (*pbitofs + bitsize) <= dict->size * 8) {
    /* expand bit field */
    fieldtype = EXPAND_BITFIELD;
#endif
So the allocation of the extra byte for the structure seems to depend on
Python's compiler. To make sure, I compiled a native structure using
MSVC:
#pragma pack(1)
typedef struct _struct1
{
  UINT8 first  : 1;
  UINT8 second  : 1;
  UINT8 third  : 1;
  UINT8 fourth  : 1;
  UINT8 fifth  : 1;
  UINT16 pad   : 11;
} struct1;
And I got the same value (sizeof == 3).
--
___
Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
<http://bugs.python.org/issue11920";
target="_blank">http://bugs.python.org/issue11920>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11241] ctypes: subclassing an already subclassed ArrayType generates AttributeError
New submission from Steve Thompson : Consider the following: python code: class my_array( ctypes.Array ): _type_= ctypes.c_uint8 _length_ = 256 class my_array2( my_array ): pass Output: class my_array2( my_array ): AttributeError: class must define a '_length_' attribute, which must be a positive integer This is analogous to the C code typedef char my_array[ 256 ]; typedef my_array my_array2; However, the python code raises exceptions claiming _type_ and _length_ have not been defined. This seems like a bug. I shouldn't need to redefine _type_ and _length_, otherwise there was no point in subclassing my_array. I tried to step into this using pdb but didn't have any luck. -- assignee: theller components: ctypes messages: 128769 nosy: Steve.Thompson, theller priority: normal severity: normal status: open title: ctypes: subclassing an already subclassed ArrayType generates AttributeError type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue11241> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
