[ python-Bugs-1145231 ] No os.statvfs on FreeBSD
Bugs item #1145231, was opened at 2005-02-21 09:10 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=1145231&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Volker Stolz (volkersf) Assigned to: Nobody/Anonymous (nobody) Summary: No os.statvfs on FreeBSD Initial Comment: There's no statvfs-wrapper on FreeBSD because it doesn't have statvfs(). But there's statfs() which might be sufficient: http://www.freebsd.org/cgi/man.cgi? query=statfs&apropos=0&sektion=0&manpath=FreeBSD+5.3- RELEASE+and+Ports&format=html Python 2.4 (#2, Jan 4 2005, 04:22:40) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> dir (os) ...'spawnvpe', 'stat', 'stat_float_times', 'stat_result', 'statvfs_result', 'strerror',... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1145231&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1145257 ] shutil.copystat() may fail...
Bugs item #1145257, was opened at 2005-02-21 10:02 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=1145257&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Petr Prikryl (prikryl) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copystat() may fail... Initial Comment: Hi, The shutil.copystat() may fail in case when the destination file has read-only attribute. It's because the implementation calls the os.utime() first and os.chmod() later. In Windows (I am not sure if also in Unix-based system), the os.utime() fails for read-only files. The implementation should ensure the read/write access by " try: os.chmod(dst, 0600)..." before calling the os.utime(). The file mode will be copied from the source file in the next step anyway. The simplistic test attached (Unix line ending used inside the tst.py zipped inside). Petr -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1145257&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-1144057 ] future warning in commets
Feature Requests item #1144057, was opened at 2005-02-18 22:10 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1144057&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: future warning in commets Initial Comment: Python uses '#' as start of comment, generally these lines can (should) be ignored by python compiler but .. deprecation warnings are issued when comment contains non ascii letters - ord(ch) not in range 0-127 can we disable it in this situation ? -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-02-21 10:17 Message: Logged In: YES user_id=89016 I don't think we should change this. The encoding is something that affects the whole file not just the executable part of it. When a file that claims to be ASCII contains bytes > 0x7f there's something fishy going on, no matter where these bytes are. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1144057&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1145231 ] No os.statvfs on FreeBSD
Bugs item #1145231, was opened at 2005-02-21 17:10 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1145231&group_id=5470 Category: Python Library >Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Volker Stolz (volkersf) >Assigned to: Hye-Shik Chang (perky) Summary: No os.statvfs on FreeBSD Initial Comment: There's no statvfs-wrapper on FreeBSD because it doesn't have statvfs(). But there's statfs() which might be sufficient: http://www.freebsd.org/cgi/man.cgi? query=statfs&apropos=0&sektion=0&manpath=FreeBSD+5.3- RELEASE+and+Ports&format=html Python 2.4 (#2, Jan 4 2005, 04:22:40) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> dir (os) ...'spawnvpe', 'stat', 'stat_float_times', 'stat_result', 'statvfs_result', 'strerror',... -- >Comment By: Hye-Shik Chang (perky) Date: 2005-02-21 18:48 Message: Logged In: YES user_id=55188 FreeBSD has statvfs(3) since FreeBSD 5.0. Looking at FreeBSD's statvfs implementation (which is a wrapper function for statfs system call), statfs has little bit different structure than statvfs and it may need some translation routine. FreeBSD 4 is on the way to being a legacy platform, and you can still use py-freebsd to utilize statfs(2) on FreeBSD 4 and older. So I'm sorry but I don't feel that adding some ifdef blocks is worthy enough. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1145231&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1145950 ] Strange behaviour concerning variable names
Bugs item #1145950, was opened at 2005-02-22 03:47 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=1145950&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Felix Nawothnig (flexo_) Assigned to: Nobody/Anonymous (nobody) Summary: Strange behaviour concerning variable names Initial Comment: For some reason python coders seem to be unaware of the fact that Python allows variable names to be longer than one char - let's have a look at a function from BitTorrent for example: def decode_list(x, f): r, f = [], f+1 while x[f] != 'e': v, f = decode_func[x[f]](x, f) r.append(v) return (r, f + 1) I'm not sure about the reasons for this behaviour yet but I suspect serious brain-damage caused by indentation-based structuring. A possible workaround: switching to a sane language like Ruby. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1145950&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
