[ python-Bugs-1709506 ] struct.calcsize() incorrect
Bugs item #1709506, was opened at 2007-04-29 00:21
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=1709506&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: JoelBondurant (joelbondurant)
Assigned to: Nobody/Anonymous (nobody)
Summary: struct.calcsize() incorrect
Initial Comment:
The result of:
import struct
struct.calcsize('cd') #returns 16
appears to be incorrect. The correct result should be 1 + 8 = 9.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1709506&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1709506 ] struct.calcsize() incorrect
Bugs item #1709506, was opened at 2007-04-29 09:21
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1709506&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: Invalid
Priority: 5
Private: No
Submitted By: JoelBondurant (joelbondurant)
Assigned to: Nobody/Anonymous (nobody)
Summary: struct.calcsize() incorrect
Initial Comment:
The result of:
import struct
struct.calcsize('cd') #returns 16
appears to be incorrect. The correct result should be 1 + 8 = 9.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-04-29 12:38
Message:
Logged In: YES
user_id=21627
Originator: NO
No, the result is correct as it stands. If you define
struct Foo{
char c;
double d;
};
on your system, and then compute sizeof(struct Foo) using the C compiler,
it will tell you that the struct is 16 bytes in size. Read some text about
alignment and padding.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1709506&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1708538 ] TimedRotatingFileHandler's doRollover opens file in "w" mode
Bugs item #1708538, was opened at 2007-04-27 09:30 Message generated for change (Comment added) made by fastflo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1708538&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: Invalid Priority: 5 Private: No Submitted By: Florian Schmidt (fastflo) Assigned to: Vinay Sajip (vsajip) Summary: TimedRotatingFileHandler's doRollover opens file in "w" mode Initial Comment: if TimedRotatingFileHandler does an doRollover() it opens the new file hardcoded with mode "w" whilst the baseclass FileHandler opens it with mode "a" if nothing else is specified in the constructor. it should use the same default behavior as FileHandler and/or give a way to specify another open-mode. if multiple processes write to the same file, and one does the RollOver all other newly spawned processes write to the end of the new file but the still running first process who did the rollover will write from the beginning of the file - overwriting log entries from the other procs... -- >Comment By: Florian Schmidt (fastflo) Date: 2007-04-29 17:29 Message: Logged In: YES user_id=182876 Originator: YES i think opening the log file with "w" is inconsistent and therefore should be fixed. as a comment: i do not need IPC/synchronisation if all processes are writing in append-mode to the same file. i am aware that sometimes log messages could get mixed up, but no single one will get completely lost (just eventually scattert if its a really big one). for now we overloaded that function in our project. thanks! -- Comment By: Vinay Sajip (vsajip) Date: 2007-04-28 14:50 Message: Logged In: YES user_id=308438 Originator: NO Since there is no interprocess synchronisation in Python, writing to the same logging file from multiple processes is not supported. If you want output from multiple processes to end up in the same file, have all your processes send logging events to a SocketHandler, and set up a separate socket receiver (which could be in one of the processes) to receive the events and log to file. A working example is given here: http://docs.python.org/lib/network-logging.html Note that even if the system was changed to use 'a' rather than 'w', this would not eliminate potential problems with e.g. data in unflushed buffers, etc. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-04-28 03:40 Message: Logged In: YES user_id=33168 Originator: NO This sounds like a logging module issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1708538&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1686475 ] os.stat() WindowsError 13 when file in use
Bugs item #1686475, was opened at 2007-03-23 02:31
Message generated for change (Comment added) made by abkhd
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&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: d roberts (dcroberts)
Assigned to: Martin v. Löwis (loewis)
Summary: os.stat() WindowsError 13 when file in use
Initial Comment:
Using 2.5 Sept 19, 2006 on Windows XP, 32-bit.
os.stat() on an "in use" file (i.e., open by another process) erroneously
returns WindowsError [Error 13]. The file stats should be available on an open
file, even if you cannot read/write the file itself.
Python 2.4 correctly returns the stats on the file.
CORRECT in 2.4:
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32
>>> import os
>>> os.stat('c:\\hiberfil.sys')
(33206, 0L, 2, 1, 0, 0, 804311040L, 1173962381, 1173962381, 1069302780)
-
ERROR in 2.5:
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on
win32
>>> import os
>>> os.stat("c:\\hiberfil.sys")
Traceback (most recent call last):
File "", line 1, in
WindowsError: [Error 13] The process cannot access the file because it is being
used by another process: 'c:\\hiberfil.sys'
--
Comment By: A.B., Khalid (abkhd)
Date: 2007-04-30 01:54
Message:
Logged In: YES
user_id=1079026
Originator: NO
Please see http://www.python.org/sf/1709112 for comment and patch.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-04-04 18:31
Message:
Logged In: YES
user_id=21627
Originator: NO
I have now committed this patch as r54685 and r54686.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-30 06:29
Message:
Logged In: YES
user_id=21627
Originator: NO
Attached is a patch that makes it fall back to FindFirstFile if
GetFileAttributesEx fail with ERROR_SHARING_VIOLATION.
File Added: stat.diff
--
Comment By: d roberts (dcroberts)
Date: 2007-03-23 17:49
Message:
Logged In: YES
user_id=1750755
Originator: YES
Taking your hint, I just looked at the code in 42230 which uses the Win32
GetFileAttributesEx() function. This function does indeed return an error
for an in-use file. Not sure if this is a "feature" or "bug" in the
underlying Windows function. I did try FindFirstFile(), which is able to
return info on an in-use file. Not sure if this is a reasonable alternative
to GFAE(), but wanted to make folks aware of the possibility. It's probably
slower, since it can handle wild-cards, and returns a handle for subsequent
calls to FindNextFile(). The handle must be closed with FindClose(). I'm
not sure what underlying mechanism FindFirstFile() uses, but I'm assuming
it accesses the "directory" to get its information, rather than trying to
access the file itself. FWIW.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-23 10:24
Message:
Logged In: YES
user_id=21627
Originator: NO
It certainly is; Python is likely opening the file in the wrong mode now.
I'll investigate, although contributions would be welcome.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-03-23 10:15
Message:
Logged In: YES
user_id=849994
Originator: NO
May this be related to rev. 42230 - "Drop C library for stat/fstat on
Windows." ?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1707768 ] os.path.normpath changes path (chops of trailing slash)
Bugs item #1707768, was opened at 2007-04-25 23:44
Message generated for change (Comment added) made by josm
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707768&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: Robert Siemer (siemer)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.normpath changes path (chops of trailing slash)
Initial Comment:
Hello everybody!
>>> os.path.normpath('/etc/passwd')
'/etc/passwd'
I don't know any environment at all where
a) '/etc/passwd/'
b) '/etc/passwd'
are treated the same. It clearly does not apply for the path part of http urls
(this is left as an exercise for the reader).
But it also does not apply for (e.g.) Linux either:
an open() on path a) return ENOTDIR while it succeeds with b).
(assuming /etc/passwd is a file)
This is definitively not a documentation bug, as "normpath" should normalize a
path and not fuck it up.
Robert
--
Comment By: jos (josm)
Date: 2007-04-30 06:48
Message:
Logged In: YES
user_id=1776568
Originator: NO
I think we should be careful enough to tackle on this.
iszegedi's patch seems to work correctly,
but XBD's spec itself has some defect.
http://www.opengroup.org/austin/mailarchives/ag-review/msg01722.html
What do you think of the follow behavior?
>>> os.mkdir('dir/')
>>> os.mkdir('dir2/')
>>> os.rmdir(os.path.normpath('dir'))
>>> os.rmdir(os.path.normpath('dir2/'))
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 22] Invalid argument: 'dir2/.'
--
Comment By: Istvan Szegedi (iszegedi)
Date: 2007-04-28 20:27
Message:
Logged In: YES
user_id=1772412
Originator: NO
Here is what Posix standard says about pathnames:
"Base Definitions volume of IEEE Std 1003.1-2001, Section 3.266,
Pathname.
A character string that is used to identify a file. In the context of IEEE
Std 1003.1-2001, a pathname consists of, at most, {PATH_MAX} bytes,
including the terminating null byte. It has an optional beginning slash,
followed by zero or more filenames separated by slashes. A pathname may
optionally contain one or more trailing slashes. Multiple successive
slashes are considered to be the same as one slash."
And in the details:
"A pathname that contains at least one non-slash character and that ends
with one or more trailing slashes shall be resolved as if a single dot
character ( '.' ) were appended to the pathname."
So if I am not mistaken, according to the POSIX standard the example that
you gave - '/etc/passwd/' - should be normalized to '/etc/passwd/.' That
does not happen, indeed.
The reason for that is that in posixpath.py file the normpath() function
is using a split('/') function to split up the path into smaller chunks,
skips everything which is empty or '.' and at the end of the normpath()
function it adds slash(es) only to the beginning of the string.
As a test, I modified the normpath() function in the posixpath.py as
follows:
--- clip ---
def normpath(path):
"""Normalize path, eliminating double slashes, etc."""
if path == '':
return '.'
initial_slashes = path.startswith('/')
# The next two lines were added by iszegedi
path = path.rstrip()
trailing_slash = path.endswith('/')
# POSIX allows one or two initial slashes, but treats three or more
# as single slash.
if (initial_slashes and
path.startswith('//') and not path.startswith('///')):
initial_slashes = 2
comps = path.split('/')
new_comps = []
for comp in comps:
if comp in ('', '.'):
continue
if (comp != '..' or (not initial_slashes and not new_comps) or
(new_comps and new_comps[-1] == '..')):
new_comps.append(comp)
elif new_comps:
new_comps.pop()
comps = new_comps
path = '/'.join(comps)
if initial_slashes:
path = '/'*initial_slashes + path
# The next two lines were added by iszegedi
if trailing_slash:
path = path + '/.'
return path or '.'
-- clip --
So I added two lines (marked as "added by iszegedi" ) in the beginning to
remove any trailing whitespaces and check whether the path ends with slash.
Then at the end of the function I added another two lines to append '/.' to
the end of the return value if the input path variable ended by slash
This works now fine.
What makes it a bit tricky is that python os module imports different
xxxpath.py module depending on the host operating system. So it imports
different modules for nt, for mac, for os2, for posix, etc. The solution
above works for posix, but the other modules need to be chec
