[issue16124] fcntl_ioctl still not 100% sane with unsigned longs
Garrett Cooper added the comment: Another note: mixed endianness might have been a factor as previous versions of the product that were shipped used bi-arch x86 (32-bit userland on 64-bit kernel. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16124 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16124] fcntl_ioctl still not 100% sane with unsigned longs
Garrett Cooper added the comment: Yes, it's a duplicate. That being said, documentation alone it should be unsigned long for Darwin (OS/X), FreeBSD, OpenBSD. Looking at the definition for ioctl(2), the below example would cause a failure. I need to hunt around for a practical example as I don't have one offhand (it's something that was found a long time ago in a couple of python 2.6 at my current employer because they have ioctl's that go beyond the 32-bit boundary IIRC...) fuji:~ ngie$ clang -Wall -c test_ioctl.c fuji:~ ngie$ clang -DBROKEN -Wall -c test_ioctl.c test_ioctl.c:9:9: warning: incompatible pointer types initializing 'ioctl_t' (aka 'int (*)(int, int, ...)') with an expression of type 'int (int, unsigned long, ...)' [-Wincompatible-pointer-types] ioctl_t _ioctl = ioctl; ^~ 1 warning generated. fuji:~ ngie$ cat test_ioctl.c #include sys/ioctl.h #ifdef BROKEN typedef int (*ioctl_t)(int, int, ...); #else typedef int (*ioctl_t)(int, unsigned long, ...); #endif ioctl_t _ioctl = ioctl; fuji:~ ngie$ uname -a Darwin fuji.local 13.4.0 Darwin Kernel Version 13.4.0: Wed Dec 17 19:05:52 PST 2014; root:xnu-2422.115.10~1/RELEASE_X86_64 x86_64 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16124 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21915] telnetlib.Telnet constructor does not match telnetlib.Telnet.__init__ docstring
New submission from Garrett Cooper: telnetlib.Telnet.__init__ supports keyword arguments, but the documentation for 2.7.8 ( https://docs.python.org/2/library/telnetlib.html ) claims they're non-keyword arguments. The py3k docs are much better ( https://docs.python.org/3/library/telnetlib.html ), but unfortunately they still claim that timeout is a non-keyword argument. -- assignee: docs@python components: Documentation messages: 63 nosy: docs@python, yaneurabeya priority: normal severity: normal status: open title: telnetlib.Telnet constructor does not match telnetlib.Telnet.__init__ docstring ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21915 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21915] telnetlib.Telnet constructor does not match telnetlib.Telnet.__init__ docstring
Changes by Garrett Cooper yaneg...@gmail.com: -- versions: +Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21915 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11907] SysLogHandler can't send long messages
Garrett Cooper added the comment: The code doesn't appear to be conforming to RFC-3164 or RFC-5424: (From RFC-3164): 4.1 syslog Message Parts The full format of a syslog message seen on the wire has three discernable parts. The first part is called the PRI, the second part is the HEADER, and the third part is the MSG. The total length of the packet MUST be 1024 bytes or less. There is no minimum length of the syslog message although sending a syslog packet with no contents is worthless and SHOULD NOT be transmitted. (From RFC-5424) The reason syslog transport receivers need only support receiving up to and including 480 octets has, among other things, to do with difficult delivery problems in a broken network. Syslog messages may use a UDP transport mapping with this 480 octet restriction to avoid session overhead and message fragmentation. In a network with problems, the likelihood of getting one single-packet message delivered successfully is higher than getting two message fragments delivered successfully. Therefore, using a larger size may prevent the operator from getting some critical information about the problem, whereas using small messages might get that information to the operator. It is recommended that messages intended for troubleshooting purposes should not be larger than 480 octets. To further strengthen this point, it has also been observed that some UDP implementations generally do not support message sizes of more than 480 octets. This behavior is very rare and may no longer be an issue. ... It must be noted that the IPv6 MTU is about 2.5 times 480. An implementation targeted towards an IPv6-only environment might thus assume this as a larger minimum size. With MTUs being what they are by default with ethernet, using an MTU 1500 with UDP when jumbo frames aren't available seems like a foolhardy thing to do. I believe part of the problem is that the socket send buffer size is not being set in the SysLogHandler via socket.setsockopt and it's trying to jam as much information as it can down the pipe and failing, but I need to do more digging... -- nosy: +yaneurabeya ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11907 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11907] SysLogHandler can't send long messages
Garrett Cooper added the comment: Please note that when I said the code I was looking at python 3.3 on OSX (compiled with MacPorts): $ python3.3 Python 3.3.5 (default, Mar 11 2014, 15:08:59) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin Type help, copyright, credits or license for more information. It's of course similar in lineage (BSD-foundation), but not the same of course.. I have a couple FreeBSD systems I can test this out on as well.. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11907 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20558] ECONNRESET value in logging.config is valid with Linux [distros]; not valid with *BSD
Garrett Cooper added the comment: Updated patch to incorporate Vinay's comments. Thanks :)! -- Added file: http://bugs.python.org/file34030/patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20558 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20558] ECONNRESET value in logging.config is valid with Linux [distros]; not valid with *BSD
Changes by Garrett Cooper yaneg...@gmail.com: Removed file: http://bugs.python.org/file33986/patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20558 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20558] ECONNRESET value in logging.config is valid with Linux [distros]; not valid with *BSD
Changes by Garrett Cooper yaneg...@gmail.com: -- components: +Library (Lib) type: - behavior versions: +Python 2.7, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20558 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20558] ECONNRESET value in logging.config is valid with Linux [distros]; not valid with *BSD
New submission from Garrett Cooper: The logging module checks for ECONNRESET if it's equal to 104. This is valid on Linux, but not [some] other OSes. On FreeBSD and OpenBSD [*] it's 54, not 104. The attached patch fixes the logging code to check for errno.ECONNRESET in !win32 environments. http://www.openbsd.org/cgi-bin/man.cgi?query=errnoapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=htmlvim -- files: patch messages: 210580 nosy: yaneurabeya priority: normal severity: normal status: open title: ECONNRESET value in logging.config is valid with Linux [distros]; not valid with *BSD Added file: http://bugs.python.org/file33985/patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20558 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20558] ECONNRESET value in logging.config is valid with Linux [distros]; not valid with *BSD
Garrett Cooper added the comment: Good to know! I updated the patch to remove the errno abstraction, grab the errno attribute from the OSError, and sort the imports. -- Added file: http://bugs.python.org/file33986/patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20558 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19657] List comprehension conditional evaluation order seems backwards
New submission from Garrett Cooper:
I was a bit surprised when I ran into this issue when porting some nose tests
from Windows to Linux:
#!/usr/bin/env python
with open('/etc/services') as fd:
lines = fd.readlines()
lines.append('')
SERVICES = [line.split()[0] for line in lines
if (line and not line.startswith('#'))]
$ python list_comprehension.py
Traceback (most recent call last):
File list_comprehension.py, line 5, in module
if (line and not line.startswith('#'))]
IndexError: list index out of range
$ python3.2 list_comprehension.py
Traceback (most recent call last):
File list_comprehension.py, line 4, in module
SERVICES = [line.split()[0] for line in lines
File list_comprehension.py, line 5, in listcomp
if (line and not line.startswith('#'))]
IndexError: list index out of range
$ python -V
Python 2.7.5
$ python3.2 -V
Python 3.2.5
This is occurring of course because the .split() is being done on an empty line.
The docs don't note (at least in the list comprehension section [*]) that
if-statements are evaluated after the value is generated for the current index
in the loop. This seems very backwards because generating a value could in fact
be very expensive, whereas determining whether or not a precondition has been
met should be less expensive.
What could/should be done is one of two things: 1. evaluation order should be
clearly spelled out in the docs, or 2. the list comprehension handling code
should be changed to support evaluating the conditional statements before
calculating a result. Otherwise discouraging use of [map+]filter (at least
pylint does that) seems incredibly unwise as I can get the functionality I want
in a single line as opposed to an unrolled loop.
[*] http://docs.python.org/2/tutorial/datastructures.html#list-comprehensions
--
messages: 203409
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: List comprehension conditional evaluation order seems backwards
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19657
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5300] distutils ignores file permissions
Garrett Cooper added the comment: The whole permissions setting operation seems a bit convoluted. I was hoping there was something formalized with install_data.py where I could specify a default or fine-grained user/group/mode for files, but it doesn't appear to be possible. I'll investigate applying a custom rule after install is run, but I would prefer for this to be formalized in the future. -- nosy: +yaneurabeya ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5300 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8079] make install fails with -j8 with python2.6/config on FreeBSD
Garrett Cooper added the comment: Feel free to close this. I don't have any interest in pursuing it further. -- nosy: +Garrett.Cooper ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16124] fcntl_ioctl still not 100% sane with unsigned longs
Garrett Cooper added the comment: Yes. Submitting a patch to fix this based on hg master shortly.. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16124] fcntl_ioctl still not 100% sane with unsigned longs
Garrett Cooper added the comment: $ uname -a FreeBSD bayonetta.local 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r240836M: Sat Sep 22 12:30:11 PDT 2012 gcooper@bayonetta.local:/usr/obj/store/freebsd/stable/9/sys/BAYONETTA amd64 $ ./configure --prefix=/scratch/python-bin/3k/ ... $ make all; make install ... $ /scratch/python-bin/3k/bin/python3 Lib/test/test_ioctl.py test_ioctl (__main__.IoctlTests) ... ok test_ioctl_mutate (__main__.IoctlTests) ... ok test_ioctl_mutate_1024 (__main__.IoctlTests) ... ok test_ioctl_mutate_2048 (__main__.IoctlTests) ... ok test_ioctl_signed_unsigned_code_param (__main__.IoctlTests) ... ok -- Ran 5 tests in 0.003s OK -- keywords: +patch versions: +Python 2.6, Python 3.1, Python 3.2, Python 3.5 Added file: http://bugs.python.org/file27951/python-issue13500-test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16124] fcntl_ioctl still not 100% sane with unsigned longs
Garrett Cooper added the comment: Sorry; previous patch is not applicable to this issue. This one is. -- Added file: http://bugs.python.org/file27952/python-issue16124.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16124] fcntl_ioctl still not 100% sane with unsigned longs
Changes by Garrett Cooper yaneg...@gmail.com: Removed file: http://bugs.python.org/file27951/python-issue13500-test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16124] fcntl_ioctl still not 100% sane with unsigned longs
Garrett Cooper added the comment: And I missed the int - unsigned int part. Resubmitting one last time for tonight.. -- Added file: http://bugs.python.org/file27953/python-issue16124.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16124] fcntl_ioctl still not 100% sane with unsigned longs
Changes by Garrett Cooper yaneg...@gmail.com: Removed file: http://bugs.python.org/file27953/python-issue16124.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16124] fcntl_ioctl still not 100% sane with unsigned longs
Garrett Cooper added the comment: Grr... Let's try again. -- Added file: http://bugs.python.org/file27954/python-issue16124.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16124] fcntl_ioctl still not 100% sane with unsigned longs
Garrett Cooper added the comment: ... g'night. -- Added file: http://bugs.python.org/file27955/python-issue16124.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16124] fcntl_ioctl still not 100% sane with unsigned longs
New submission from Garrett Cooper: As discussed in ID # 1471, the type for request is not 100% correct on some platforms (FreeBSD, NetBSD, and OpenBSD, for instance) and the custom platform that I'm using unfortunately uses non-32-bit int ioctls. An autoconf test needs to be added for these platforms and the request parameter needs to be handled properly (I'll take charge of doing that). -- components: Extension Modules messages: 171918 nosy: yaneurabeya priority: normal severity: normal status: open title: fcntl_ioctl still not 100% sane with unsigned longs type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15942] Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime()
New submission from Garrett Cooper: Windows doesn't return sane values for localtime(3) (per POSIX [1]) when the BIOS is set to the local time (the host is a Win2k8-R2 machine): $ python -V; python -c 'import time; print time.strftime(%m-%d-%y %H:%M:%S, time.localtime())'; date; uname -a Python 2.6.1 09-13-12 19:56:03 Thu, Sep 13, 2012 11:56:03 AM CYGWIN_NT-6.1-WOW64 QAQA-ORPTO8B466 1.7.11(0.260/5/3) 2012-02-24 14:05 i686 Cygwin This seems to be a conscious design choice on Microsoft's part: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724961%28v=vs.85%29.aspx I'll try and follow this up with the POSIX folks or maybe Microsoft, but for the time being this needs to be documentation as an issue with downstream consumers (perl 5.8.9 also illustrates this issue). -- components: Library (Lib) messages: 170453 nosy: yaneurabeya priority: normal severity: normal status: open title: Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime() type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15942] Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime()
Garrett Cooper added the comment: 1. http://pubs.opengroup.org/onlinepubs/009695299/functions/localtime.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15942] Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime()
Garrett Cooper added the comment: Except it wasn't built within the Cygwin environment... $ python -c 'import sys; print sys.version' 2.6.1 (r261:67515, Dec 5 2008, 13:58:38) [MSC v.1500 32 bit (Intel)] $ ldd `which python` | grep -i ygwin || echo not cygwin not cygwin -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15942] Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime()
Garrett Cooper added the comment: Ok. Turns out I got this backwards. The BIOS clock is set to UTC (which works with the CentOS install on the same drive) and Windows assumes the clock is set to local time [1]. I'll follow it up with the my $work lab team, but it would be nice if this could be tuned properly to report the proper time according to Windows (even if the bloody clock/tz was wrong to begin with). 1. https://help.ubuntu.com/community/UbuntuTime -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15942] Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime()
Garrett Cooper added the comment: Hahaha... you're right: $ perl -e 'use POSIX; print strftime(%m-%d-%y %H:%M:%S, localtime).\n;'; date 09-13-12 23:25:49 Thu, Sep 13, 2012 3:25:49 PM $ python -c 'import time; print time.strftime(%m-%d-%y %H:%M:%S, time.localtime())'; date 09-13-12 23:26:25 Thu, Sep 13, 2012 3:26:25 PM $ python -c 'import time; print time.strftime(%m-%d-%y %H:%M:%S, time.localtime())'; env TZ=utc date 09-13-12 23:27:35 Thu, Sep 13, 2012 10:27:35 PM Now I've just moved the dang clock ahead 8 hours because the timezone is screwed up (now python assumes UTC, Cygwin assumes local time, and Windows assumes UTC), I guess I'll have to recommend `fixing` our Linux installs to use local time (dog gone Windows). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: strptime format string nasty default
On May 9, 2012, at 12:38 PM, Javier Novoa C. jsti...@invernalia.homelinux.net wrote: Hi, I am using time.strptime method as follows: I receive an input string, representing some date in the following format: %d%m%Y However, the day part may be a single digit or two, depending on magnitude. For example: '10052012' will be parsed as day 10, month 5, year 2012 Again: '8052012' will be parsed as day 8, month 5, year 2012 What happens when day is 1 or 2? '1052012' will be parsed as day 10, month 5, year 2012 That's not the expected behaviour! Not for me at least. I mean, in my case, month will always be a 2 digit string, so there's no ambiguity problem by pretending that... say '1052012' is correctly parsed. Is there a way out of here? I know I can pre-parse the string and append a '0' to it when lenght == 7, but I think that a better way would be if strptime allowed me to define my format in a better way... To say that the month is the optional one-two digit part is just a default, isn't it? Why can't I specify that the day part is the one with one-or-two digits on the input string...? Or is there a way out that I don't know yet? Delimiters, e.g. dashes, slashes, etc, can remove ambiguity in the date string. Leading 0s in elements in the date would help as well. HTH! -Garrett -- http://mail.python.org/mailman/listinfo/python-list
Lack of whitespace between contain operator (in) and other expression tokens doesn't result in SyntaxError: bug or feature?
Hi Python folks!
I came across a piece of code kicking around a sourcebase that
does something similar to the following:
START
#!/usr/bin/env python
import sys
def foo():
bar = 'abcdefg'
foo = [ 'a' ]
# Should throw SyntaxError?
for foo[0]in bar:
sys.stdout.write('%s' % foo[0])
sys.stdout.write('\n')
sys.stdout.write('%s\n' % (str(foo)))
# Should throw SyntaxError?
if foo[0]in bar:
return True
return False
sys.stdout.write('%r\n' % (repr(sys.version_info)))
sys.stdout.write('%s\n' % (str(foo(
END
I ran it against several versions of python to ensure that it
wasn't a regression or fixed in a later release:
$ /scratch/bin/bin/python ~/test_bad_in.py
(2, 3, 7, 'final', 0)
abcdefg
['g']
True
$ python2.7 ~/test_bad_in.py
sys.version_info(major=2, minor=7, micro=3, releaselevel='final', serial=0)
abcdefg
['g']
True
$ python3.2 ~/test_bad_in.py
sys.version_info(major=3, minor=2, micro=3, releaselevel='final', serial=0)
abcdefg
['g']
True
$ uname -rom
FreeBSD 9.0-STABLE amd64
$
And even tried a different OS, just to make sure it wasn't a
FreeBSD thing...
% python test_bad_in.py
(2, 6, 5, 'final', 0)
abcdefg
['g']
True
% uname -rom
2.6.32-71.el6.x86_64 x86_64 GNU/Linux
I was wondering whether this was a parser bug or feature (seems
like a bug, in particular because it implicitly encourages bad syntax,
but I could be wrong). The grammar notes (for 2.7 at least [1]) don't
seem to explicitly require a space between 'in' and another parser
token (reserved work, expression, operand, etc), but I could be
misreading the documentation.
Thanks!
-Garrett
1. http://docs.python.org/reference/grammar.html
--
http://mail.python.org/mailman/listinfo/python-list
Re: Lack of whitespace between contain operator (in) and other expression tokens doesn't result in SyntaxError: bug or feature?
On Thu, May 3, 2012 at 12:03 PM, Ian Kelly ian.g.ke...@gmail.com wrote: On Thu, May 3, 2012 at 12:49 PM, Garrett Cooper yaneg...@gmail.com wrote: I was wondering whether this was a parser bug or feature (seems like a bug, in particular because it implicitly encourages bad syntax, but I could be wrong). The grammar notes (for 2.7 at least [1]) don't seem to explicitly require a space between 'in' and another parser token (reserved work, expression, operand, etc), but I could be misreading the documentation. The grammar doesn't require whitespace there. It tends to be flexible about whitespace wherever it's not necessary to resolve ambiguity. x = [3, 2, 1] x [0]if x [1]else x [2] 3 1 . real 1 1.5.real 1.5 Sure.. it's just somewhat inconsistent with other expectations in other languages, and seems somewhat unpythonic. Not really a big deal (if it was I would have filed a bug instead), but this was definitely a bit confusing when I ran it through the interpreter a couple of times... Thanks! -Garrett -- http://mail.python.org/mailman/listinfo/python-list
[issue13500] Hitting EOF gets cmd.py into a infinite EOF on return loop
Garrett Cooper yaneg...@gmail.com added the comment:
Here's a unittest patch for the py3k branch.
{{{
1 items passed all tests:
32 tests in test.test_cmd.samplecmdclass
32 tests in 19 items.
32 passed and 0 failed.
Test passed.
doctest (test.test_cmd) ... 32 tests with zero failures
test_file_with_missing_final_nl (__main__.TestAlternateInput) ... ok
test_input_reset_at_EOF (__main__.TestAlternateInput) ... ok
--
Ran 2 tests in 0.000s
OK
}}}
--
Added file: http://bugs.python.org/file24257/python-issue13500-test.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13500
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13500] Hitting EOF gets cmd.py into a infinite EOF on return loop
Garrett Cooper yaneg...@gmail.com added the comment: I'll verify the fix in another day or two. FWIW unless python is willing to import pexpect, or provide an equivalent, I'm not sure how items like this which require interactive input can be run via the python project testing framework. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13500 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13500] Hitting EOF gets cmd.py into a infinite EOF on return loop
Garrett Cooper yaneg...@gmail.com added the comment: Ok. I'll see if I can provide a unittest for this by the 12th. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13500 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13497] Fix for broken nice test on non-broken platforms with pedantic compilers
New submission from Garrett Cooper yaneg...@gmail.com: Was poking around config.log and I saw that gcc was complaining of some undefined built-in symbols for the broken nice test in configure. This patch fixes that. -- files: configure-fix-broken-broken-nice-test.patch keywords: patch messages: 148554 nosy: yaneurabeya priority: normal severity: normal status: open title: Fix for broken nice test on non-broken platforms with pedantic compilers type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file23804/configure-fix-broken-broken-nice-test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13497 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13497] Fix for broken nice test on non-broken platforms with pedantic compilers
Garrett Cooper yaneg...@gmail.com added the comment: Other potential issues are provided below: configure:9015: checking if PTHREAD_SCOPE_SYSTEM is supported configure:9038: gcc -pthread -o conftest -I/usr/include/edit conftest.c 5 conftest.c: In function 'main': conftest.c:101: warning: incompatible implicit declaration of built-in function 'exit' configure:9038: $? = 0 configure:9079: checking if --enable-ipv6 is specified configure:9119: gcc -pthread -o conftest -I/usr/include/edit conftest.c 5 conftest.c: In function 'main': conftest.c:102: warning: incompatible implicit declaration of built-in function 'exit' configure:9119: $? = 0 configure:12462: checking whether wchar_t is signed configure:12482: gcc -pthread -o conftest -I/usr/include/edit conftest.c -lutil 5 conftest.c: In function 'main': conftest.c:272: warning: incompatible implicit declaration of built-in function 'exit' configure:12482: $? = 0 configure:12800: checking whether right shift extends the sign bit configure:12818: gcc -pthread -o conftest -I/usr/include/edit conftest.c -lutil 5 conftest.c: In function 'main': conftest.c:273: warning: incompatible implicit declaration of built-in function 'exit' configure:12818: $? = 0 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13497 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13500] Hitting EOF gets cmd.py into a infinite EOF on return loop
New submission from Garrett Cooper yaneg...@gmail.com: Pressing enter produces no output with cmd.py whenever ^D has been entered in; after I enter in ^D it gets into an infinite loop spewing out messages via cmd.Cmd.default() about EOF because self.lastcmd isn't being reset properly. The attached patch fixes that usability nit to be more intuitive (I debated about changing 'EOF' to 0x10, but that's probably less intuitive..). -- components: Library (Lib) files: python-cmd-reset-lastcmd-on-EOF.patch keywords: patch messages: 148575 nosy: yaneurabeya priority: normal severity: normal status: open title: Hitting EOF gets cmd.py into a infinite EOF on return loop type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file23805/python-cmd-reset-lastcmd-on-EOF.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13500 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
New submission from Garrett Cooper yaneg...@gmail.com: The attached patch enables libedit support in a generic way via configure.in, so I can pass in --with-readline=editline, --with-readline=readline, --with-readline=yes, or --with[out]-readline[=no] and it will do one of the following: 1. Enable editline support. 2. Enable readline support. 3. Enable default OS support (editline on OSX, readline otherwise). 4. Explicitly disable readline support. Tested functional via cmd.py and with basic poking around via the readline module. The attached patch was created against the 2.7 branch, but I'll produce a patch against 'trunk' sometime later on this week. PS. The only quirk I found was the fact that FreeBSD 9's libedit lied when it reports the number of available history items. Hrmmm.. -- components: Library (Lib) files: python-port-readline-module-to-libedit-on-freebsd.patch keywords: patch messages: 148577 nosy: yaneurabeya priority: normal severity: normal status: open title: Make libedit support more generic; port readline / libedit to FreeBSD type: feature request versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file23806/python-port-readline-module-to-libedit-on-freebsd.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13501 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13500] Hitting EOF gets cmd.py into a infinite EOF on return loop
Garrett Cooper yaneg...@gmail.com added the comment:
Sure -- the repro steps are pretty easy:
1. Startup an interactive python shell.
2. Enter in the following code:
{{{
import cmd
class Foo(cmd.Cmd):
def do_bar(self, arg):
bar
Foo().cmdloop()
}}}
3. You will be greeted with the standard `(Cmd)' prompt.
4. Press enter. Nothing will be printed out (it will continue on to the next
line).
5. Enter in Control-D, you will be greeted with `Unknown syntax: EOF' error
message from cmd.Cmd.default(..).
6. Press enter multiple times.
Expected output:
- Since a do_EOF handler isn't installed in 5., I expect to see the `Unknown
syntax: EOF' error print out on the console. I don't want to delve into whether
or not this should or shouldn't be printed out in this ticket.
- Every time I press enter I should be greeted with the prompt, and not the
`Unknown syntax: EOF` error.
Actual output:
- I see `Unknown syntax: EOF' error, and every time I press enter it displays
the error beforementioned error.
Example:
{{{
import cmd
class Foo(cmd.Cmd):
... def do_bar(self, arg):
... bar
...
Foo().cmdloop()
(Cmd)
(Cmd)
bar help
(Cmd) help bar
bar
(Cmd) ^D*** Unknown syntax: EOF
(Cmd)
*** Unknown syntax: EOF
(Cmd)
*** Unknown syntax: EOF
}}}
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13500
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13214] Cmd: list available completions from the cmd.Cmd subclass and filter out EOF handler(s)
Garrett Cooper yaneg...@gmail.com added the comment: Here's a version incorporating your suggestion and better documenting the choices and the method for overriding purposes. I have a few reservations with the current implementation: 1. As noted, the information for the class really could be and should be cached as the attributes of a given cmd.Cmd derived class don't change all that frequently. 2. One has to override the entire function in order to get what I consider standard functionality (filtering).. so I don't know if that's a good idea. 3. I've thought about the do_EOF handler stuff, and it would be nice if that was shoved into the completer method(s) as a keyword argument, defaulting to False -- that way one could avoid having to explicitly install an EOF handler when dealing with ^D, etc, but this can be hashed out better in a different issue, over IRC, email, etc. This module could be better cleaned up (isn't PEP8 compliant, overrides built-ins, is pythonic but not super pythonic, etc), but I'll see what other modules exist out there that could be used in its place, because they could have resolved some of these issues. There is some value that can be obtained from pexpect, some of the other cmd module variants, etc .. I just like this module because it's nice, simple, and standard -- it just needs a little love and it will be awesome. Anyhow -- thanks again for the work :). -- Added file: http://bugs.python.org/file23485/python-cmd-better-filtering.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13214 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294] Management of KeyboardInterrupt in cmd.py
Garrett Cooper yaneg...@gmail.com added the comment: I realize that this bug is closed, but I just had a comment to make. Handling EOF is simple: def do_EOF(self, arg): pass For my purposes I want to raise an EOFError so I can trickle up the chain to the appropriate caller because I'm coding a CLI where I have a nested set of commands, e.g. command subcommand_0 command subcommand_1 I'd like the behavior to match what's done in Cisco IOS or IronPort's CLI (to some degree). The only part that's annoying is that I have to hide do_EOF in the help and completion output, otherwise the user will see the handler when completing or running help, but I'll bring that up in another issue. -- nosy: +yaneurabeya ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13214] Cmd: list available completions from the cmd.Cmd subclass and filter out EOF handler(s)
New submission from Garrett Cooper yaneg...@gmail.com: 1. The current code in cmd.get_names does a dir on the derived class for cmd.Cmd object instead, which means that if I do something similar to the following: class CLI(cmd.Cmd): def register_subcommand(self, cmd, cli_class): def call_cli(self): cli = cli_class() cli.cmdloop() setattr(self, 'do_%s' % (cmd, ), call_cli) it won't register the command in the completion list or help list. 2. Registering a do_EOF handler is a bit of a hack to work around the fact that entering in ^D on the command line prints out: (Cmd) *** Unknown syntax: EOF I can't speak to the fact that my desired behavior should be enforced (basically trickle up the EOFError like so): def do_EOF(self, arg): raise EOFError so what I'm proposing instead is that it be filtered out by default. Given that there's some value in allowing developers to build custom filter rules for the completions (example: certain commands can be undocumented, hidden to lower privilege users, etc), I figured it would be wise to create a custom mechanism for filtering out commands. This could be cleaned up to use better python idioms like a generator, cache the data and have a refresh method, etc, but this is a good first start. -- components: Library (Lib) files: python-cmd-better-filtering.patch keywords: patch messages: 145856 nosy: yaneurabeya priority: normal severity: normal status: open title: Cmd: list available completions from the cmd.Cmd subclass and filter out EOF handler(s) type: feature request versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file23449/python-cmd-better-filtering.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13214 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8065] Memory leak in readline.get_current_history_length
Garrett Cooper yaneg...@gmail.com added the comment: As a note for future reference, FreeBSD/NetBSD/OpenBSD doesn't use the term bug, but instead uses the term problem report (the NetBSD website says bug though BTW). The PR system for NetBSD can be accessed here: http://www.netbsd.org/cgi-bin/sendpr.cgi?gndb=netbsd . -- nosy: +yaneurabeya ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8065 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12433] make clean doesn't clean up static libraries on 2.x
New submission from Garrett Cooper yaneg...@gmail.com: Running 'make clean' leaves libpython*.a behind. The attached patch removes it when make clean is run. This was resolved on py3k, not trunk; the attached patch matches what was done on py3k. -- components: Build files: cleanup-libpython-dot-a-trunk.patch keywords: patch messages: 139364 nosy: yaneurabeya priority: normal severity: normal status: open title: make clean doesn't clean up static libraries on 2.x type: compile error versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file22509/cleanup-libpython-dot-a-trunk.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12433 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12433] make clean doesn't clean up static libraries on 2.x
Garrett Cooper yaneg...@gmail.com added the comment: Is svn not being updated anymore (in lieu of hg)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12433 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8746] os.chflags() and os.lchflags() are not built when they should be be
Garrett Cooper yaneg...@gmail.com added the comment: I apologize for taking so long with this. The attached patch is for test_posix against trunk (I shuffled around some code and extended some things to improve PosixTester.tearDown). Let me know if I need to wash, rinse, repeat for py3k, etc. Thanks! # Standard ports copy of python 2.7 without the *chflags configure fix. $ python2.7 Lib/test/test_posix.py testNoArgFunctions (__main__.PosixTester) ... ok test_access (__main__.PosixTester) ... ok test_chdir (__main__.PosixTester) ... ok test_chflags (__main__.PosixTester) ... skipped 'test needs os.chflags()' test_chown (__main__.PosixTester) ... ok test_confstr (__main__.PosixTester) ... ok test_dup (__main__.PosixTester) ... ok test_dup2 (__main__.PosixTester) ... ok test_fchown (__main__.PosixTester) ... ok test_fdopen (__main__.PosixTester) ... ok test_fstat (__main__.PosixTester) ... ok test_fstatvfs (__main__.PosixTester) ... ok test_ftruncate (__main__.PosixTester) ... ok test_getcwd_long_pathnames (__main__.PosixTester) ... ok test_getresgid (__main__.PosixTester) ... ok test_getresuid (__main__.PosixTester) ... ok test_initgroups (__main__.PosixTester) ... ok test_lchflags_regular_file (__main__.PosixTester) ... skipped 'test needs os.lchflags()' test_lchflags_symlink (__main__.PosixTester) ... skipped 'test needs os.lchflags()' test_lchown (__main__.PosixTester) ... ok test_lsdir (__main__.PosixTester) ... ok test_osexlock (__main__.PosixTester) ... ok test_osshlock (__main__.PosixTester) ... ok test_pipe (__main__.PosixTester) ... ok test_setresgid (__main__.PosixTester) ... ok test_setresgid_exception (__main__.PosixTester) ... ok test_setresuid (__main__.PosixTester) ... ok test_setresuid_exception (__main__.PosixTester) ... ok test_stat (__main__.PosixTester) ... ok test_statvfs (__main__.PosixTester) ... ok test_strerror (__main__.PosixTester) ... ok test_tempnam (__main__.PosixTester) ... ok test_tmpfile (__main__.PosixTester) ... ok test_umask (__main__.PosixTester) ... ok test_utime (__main__.PosixTester) ... ok -- Ran 35 tests in 0.020s OK (skipped=3) # Hand compiled version using sources from trunk. $ /scratch/python/2.7/bin/python Lib/test/test_posix.py testNoArgFunctions (__main__.PosixTester) ... ok test_access (__main__.PosixTester) ... ok test_chdir (__main__.PosixTester) ... ok test_chflags (__main__.PosixTester) ... ok test_chown (__main__.PosixTester) ... ok test_confstr (__main__.PosixTester) ... ok test_dup (__main__.PosixTester) ... ok test_dup2 (__main__.PosixTester) ... ok test_fchown (__main__.PosixTester) ... ok test_fdopen (__main__.PosixTester) ... ok test_fstat (__main__.PosixTester) ... ok test_fstatvfs (__main__.PosixTester) ... ok test_ftruncate (__main__.PosixTester) ... ok test_getcwd_long_pathnames (__main__.PosixTester) ... ok test_getresgid (__main__.PosixTester) ... ok test_getresuid (__main__.PosixTester) ... ok test_initgroups (__main__.PosixTester) ... ok test_lchflags_regular_file (__main__.PosixTester) ... ok test_lchflags_symlink (__main__.PosixTester) ... ok test_lchown (__main__.PosixTester) ... ok test_lsdir (__main__.PosixTester) ... ok test_osexlock (__main__.PosixTester) ... ok test_osshlock (__main__.PosixTester) ... ok test_pipe (__main__.PosixTester) ... ok test_setresgid (__main__.PosixTester) ... ok test_setresgid_exception (__main__.PosixTester) ... ok test_stat (__main__.PosixTester) ... ok test_statvfs (__main__.PosixTester) ... ok test_strerror (__main__.PosixTester) ... ok test_tempnam (__main__.PosixTester) ... ok test_tmpfile (__main__.PosixTester) ... ok test_umask (__main__.PosixTester) ... ok test_utime (__main__.PosixTester) ... ok -- Ran 35 tests in 0.009s OK -- Added file: http://bugs.python.org/file22337/issue8746-test_posix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8746 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8746] os.chflags() and os.lchflags() are not built when they should be be
Garrett Cooper yaneg...@gmail.com added the comment: Sorry -- got off-track for a while. I assume these should go into Lib/test/test_os.py ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8746 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8746] os.chflags() and os.lchflags() are not built when they should be be
Garrett Cooper yaneg...@gmail.com added the comment: On Mon, Jan 17, 2011 at 5:11 PM, Ned Deily rep...@bugs.python.org wrote: Ned Deily n...@acm.org added the comment: There is an existing test_lchflags in Lib/test/test_posix.py. Additional test cases should go there. Ok, but again this isn't POSIX functionality -- it's a BSD functional piece. Another thing that's nasty that I've discovered is that the function prototype isn't the same across the board. After things are consolidated in FreeBSD I'll talk to the NetBSD and OpenBSD folks. Thanks! -Garrett -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8746 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10699] [patch] fix incorrect help doc with time.tzset
New submission from Garrett Cooper yaneg...@gmail.com: The following patch fixes the help docstring as time.tzset when called doesn't require any arguments (as noted in the source and also in the library documentation). The patch produced was against trunk, but this appears to be an issue on release-maint26 and release-maint27 (and the patch applies cleanly) as the text is the same. -- assignee: d...@python components: Documentation files: fix-timemodule-helpdoc.patch keywords: patch messages: 123908 nosy: d...@python, yaneurabeya priority: normal severity: normal status: open title: [patch] fix incorrect help doc with time.tzset versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file20033/fix-timemodule-helpdoc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10699 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8746] os.chflags() and os.lchflags() are not built when they should be be
Garrett Cooper yaneg...@gmail.com added the comment: *NOUNLINK was not implemented by OSX, so there's actually a bug with the compile tests if you take that into consideration. And again, only FreeBSD defines *NOUNLINK. The other BSDs, not so much. As far as the reason why I implemented the flags, the documentation that I was looking at didn't implement those flags. I looked at the latest documentation and it appears to be correct though. I will implement tests for *UNLINK and *HIDDEN (FWIW the tests I wrote are ok for cross-compilation because they just test for the existence of the values -- they don't test to ensure that the functionality is correct, like some of the logic in configure was recently `fixed' to do). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8746 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8746] os.chflags() and os.lchflags() are not built when they should be be
Garrett Cooper yaneg...@gmail.com added the comment: I'll add new tests in the next submit for the bug, but here's the code to add the relevant symbols for common to *BSD and OSX, and the Snow Leopard+ and FreeBSD specific chflags of importance for python 2.7 and py3k. -- Added file: http://bugs.python.org/file18848/issue8746-trunk.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8746 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8746] os.chflags() and os.lchflags() are not built when they should be be
Changes by Garrett Cooper yaneg...@gmail.com: Added file: http://bugs.python.org/file18849/issue8746-py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8746 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8746] os.chflags() and os.lchflags() are not built when they should be be
Garrett Cooper yaneg...@gmail.com added the comment: Do you prefer exhaustive tests, or just smoke tests? Honestly IMO, the OS should come prepackaged with tests to ensure that things function according to the requirements set forth in the manpage, so I would prefer the latter because the os methods in the posixmodule are nothing more than thin wrappers above the actual OS syscalls. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8746 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8746] os.chflags() and os.lchflags() are not built when they should be be
Garrett Cooper yaneg...@gmail.com added the comment:
That definitely fixes detection for FreeBSD CURRENT with 2.7 and py3k for me.
I'm looking into providing some unit-tests, but the problem is that whether or
not chflags functions on the underlying filesystem is problematic. For
instance, it won't function on msdosfs (Linux calls it vfat), it won't function
on ext[23] (AFAIK), and it didn't function on ZFS (until recently? I'm not sure
whether or not the latest patches for ZFS enhance the filesystem to support
this functionality). So unfortunately adding tests for this feature (while
nice) would potentially be error prone.
Something I tried was:
UF_IMMUTABLE = 2
import tempfile
f = tempfile.mkstemp()[1]
os.getuid()
1000
os.chflags('/tmp', UF_IMMUTABLE)
Traceback (most recent call last):
File stdin, line 1, in module
OSError: [Errno 1] Operation not permitted: '/tmp'
os.chflags(f, UF_IMMUTABLE)
fd = open(f, 'w')
Traceback (most recent call last):
File stdin, line 1, in module
IOError: [Errno 1] Operation not permitted: '/tmp/tmpi_hwY7'
fd = open(f, 'r')
fd = open(f, 'r')
fd.read()
''
os.chflags(f, 0)
fd = open(f, 'w')
fd.write('foo')
fd.close()
fd = open(f, 'r')
fd.read()
'foo'
fd.close()
Also, the flags are missing that are described in the manpage. I'll provide a
patch for those.
Otherwise, it looks like everything's functioning as expected for basic
end-to-end tests with chflags(2).
Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8746
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8747] Autoconf tests in python not portably correct
Garrett Cooper yaneg...@gmail.com added the comment: The issue is still present. The overall problem I suppose is with consistency and presentation of features in the python language. Many features cannot be presented in a 100% portable manner, and the problem is that such features that aren't POSIX conforming should be 100% spelled out instead of being implied functional on all Unix based platforms. So, again... if these platforms can't function with these preprocessor defines, the platforms need to be fixed -- not python. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8747 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9311] os.access can return bogus values when run as superuser
Garrett Cooper yaneg...@gmail.com added the comment: Well, bash screws up in this dept: $ ls -l typescript -rw-r--r-- 1 gcooper gcooper 37875 Jul 12 22:19 typescript $ sudo sh -c 'test -x typescript; echo $?' 1 $ sudo bash -c 'test -x typescript; echo $?' 0 $ csh %if (-x typescript) then if? echo executable if? endif % test(1) is a built-in in bash; on FreeBSD/NetBSD(/OpenBSD?) it's a standalone app (which uses eaccess(2)). csh does some tricky code for testing file access in sh.exp.c (see sh_access). perl does some tricky stuff in pp_sys.c (look for pp_ftrread), where it uses eaccess(2) if it's present, else falls back to access(2) to do its bidding. So maybe os.access should use eaccess(2) if it's present on the OS instead of access(2), and note that the item is OS implementation dependent (beware!)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9311] os.access can return bogus values when run as superuser
Garrett Cooper yaneg...@gmail.com added the comment: My initial analysis was incorrect after talking with the bash(1) folks. test(1) is doing things wrong too: case FILEX: /* XXX work around eaccess(2) false positives for superuser */ if (eaccess(nm, X_OK) != 0) return 0; if (S_ISDIR(s.st_mode) || geteuid() != 0) return 1; return (s.st_mode (S_IXUSR | S_IXGRP | S_IXOTH)) != 0; So it looks like test(1) is broken as well (doesn't check for ACLs, or MAC info). Interesting why it's only implemented for X_OK though... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9311] os.access can return bogus values when run as superuser
Garrett Cooper yaneg...@gmail.com added the comment: My initial analysis was incorrect after talking with the bash(1) folks. test(1) is doing things wrong too: case FILEX: /* XXX work around eaccess(2) false positives for superuser */ if (eaccess(nm, X_OK) != 0) return 0; if (S_ISDIR(s.st_mode) || geteuid() != 0) return 1; return (s.st_mode (S_IXUSR | S_IXGRP | S_IXOTH)) != 0; So it looks like test(1) is broken as well (doesn't check for ACLs, or MAC info). Interesting why it's only implemented for X_OK though... Based on this analysis, I'd say that access(2) is broken on FreeBSD and needs to be fixed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9311] os.access can return bogus values when run as superuser
New submission from Garrett Cooper yaneg...@gmail.com: As seen in the nose bug [1], I stumbled upon an OS quirk with FreeBSD, where apparently (as superuser) due to the wording of the POSIX spec for access(2), it's considered free game to return 0 for the system call (True) for os.[RWX]_OK. Only python was affected by this on the system I was using (both perl and sh did the right thing in detecting the executable bit(s) on the file). An example should be provided to do the right thing with the stat module, and developers should be warned against using os.access because (as the patch and test log demonstrate), stat(2) does the right thing when access(2) does not as superuser... Here's an example of the code I used to detect the executable bit: import os import stat s = os.stat(afile) executable = (s.st_mode stat.S_IXUSR | stat.S_IXGRP | stat.S_IXOTH) == 0 [1] http://code.google.com/p/python-nose/issues/detail?id=351 [2] http://www.opengroup.org/onlinepubs/95399/functions/access.html -- components: Library (Lib) messages: 110850 nosy: yaneurabeya priority: normal severity: normal status: open title: os.access can return bogus values when run as superuser type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8746] *chflags detection broken on FreeBSD 9-CURRENT
Garrett Cooper yaneg...@gmail.com added the comment: . -- Added file: http://bugs.python.org/file17414/config.log ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8746 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8746] *chflags detection broken on FreeBSD 9-CURRENT
New submission from Garrett Cooper yaneg...@gmail.com:
os.chflags isn't `available' even though chflags support is available on the
system:
filter(lambda x: x.startswith('chflags'), dir(os))
[]
platform.uname()
('FreeBSD', 'bayonetta.local', '9.0-CURRENT', 'FreeBSD 9.0-CURRENT #0 r206173M:
Mon Apr 26 22:45:06 PDT 2010
r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA.ata', 'amd64', 'amd64')
filter(lambda x: x.startswith('chflags'), dir(os))
[]
sys.version
'2.6.5 (r265:79063, May 16 2010, 23:37:42) \n[GCC 4.2.1 20070719 [FreeBSD]]'
I'm looking into why this is not properly detected via configure (here's the
snippet though):
configure:17257: checking for chflags
configure:17288: cc -o conftest -O2 -pipe -fno-strict-aliasing -pipe -O2
-march=nocona -D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x10 -pthread
conftest.c 5
conftest.c:173: error: expected identifier or '(' before '[' token
In file included from /usr/include/sys/_types.h:33,
from /usr/include/sys/_timespec.h:37,
from /usr/include/sys/stat.h:42,
from conftest.c:174:
/usr/include/machine/_types.h:75: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '__int_least8_t'
In file included from /usr/include/sys/time.h:37,
from /usr/include/sys/stat.h:99,
from conftest.c:174:
/usr/include/sys/types.h:64: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'int8_t'
conftest.c:182: error: expected identifier or '(' before ']' token
configure:17291: $? = 1
Compiling the standalone test works:
$ cat ~/test_chflags.c
#include sys/stat.h
#include unistd.h
int main(int argc, char*argv[])
{
if(chflags(argv[0], 0) != 0)
return 1;
return 0;
}
$ gcc -o ~/test_chflags ~/test_chflags.c
$ echo $?
0
Also, another sidenote: nowhere is *chflags(2) considered a POSIX feature (I
doublechecked opengroup.org and Google). It is strictly a _Unix_ feature. I say
this because the POSIX functionality tester explicitly looks for this `POSIX'
compatible feature.
--
messages: 105957
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: *chflags detection broken on FreeBSD 9-CURRENT
type: compile error
versions: Python 2.6, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8746
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8747] Autoconf tests in python not portably correct
New submission from Garrett Cooper yaneg...@gmail.com: A number of features are being blindly enabled on python that aren't correct from a porting standpoint; a handful in configure.in I noticed are: # The later defininition of _XOPEN_SOURCE disables certain features # on Linux, so we need _GNU_SOURCE to re-enable them (makedev, tm_zone). AC_DEFINE(_GNU_SOURCE, 1, [Define on Linux to activate all library features]) # The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables # certain features on NetBSD, so we need _NETBSD_SOURCE to re-enable # them. AC_DEFINE(_NETBSD_SOURCE, 1, [Define on NetBSD to activate all library features]) # The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables # certain features on FreeBSD, so we need __BSD_VISIBLE to re-enable # them. AC_DEFINE(__BSD_VISIBLE, 1, [Define on FreeBSD to activate all library features]) # The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables # u_int on Irix 5.3. Defining _BSD_TYPES brings it back. AC_DEFINE(_BSD_TYPES, 1, [Define on Irix to enable u_int]) # The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables # certain features on Mac OS X, so we need _DARWIN_C_SOURCE to re-enable # them. AC_DEFINE(_DARWIN_C_SOURCE, 1, [Define on Darwin to activate all library features]) these are only applicable on certain platforms and thus, shouldn't be enabled on all platforms (the default should be off, and then the values should be tuned according to the platform detection performed by autoconf). -- components: Build messages: 105958 nosy: yaneurabeya priority: normal severity: normal status: open title: Autoconf tests in python not portably correct type: compile error versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8747 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8079] make install fails with -j8 with python2.6/config on FreeBSD
New submission from Garrett Cooper yaneg...@gmail.com:
When attempting to install and deinstall lang/python26 to run some unit tests
for a change I was going to provide to the maintainer, I ran into this issue:
install -o root -g wheel -m 444 ./../Include/ucnhash.h
/usr/local/include/python2.6
install -o root -g wheel -m 444 ./../Include/unicodeobject.h
/usr/local/include/python2.6
install -o root -g wheel -m 444 ./../Include/warnings.h
/usr/local/include/python2.6
install -o root -g wheel -m 444 ./../Include/weakrefobject.h
/usr/local/include/python2.6
install -o root -g wheel -m 444 pyconfig.h
/usr/local/include/python2.6/pyconfig.h
Creating directory /usr/local/lib/python2.6/config
install: /usr/local/lib/python2.6/config exists but is not a directory
*** Error code 71
Stop in /scratch/freebsd/ports/lang/python26/work/Python-2.6.4/portbld.static.
*** Error code 1
Stop in /scratch/freebsd/ports/lang/python26.
*** Error code 1
The problem was caused by an incomplete install into ${prefix} [which I will
take up with the FreeBSD project], but manifests itself because the -j value I
specified, was too high. I say this because of another comment placed in a
top-level Makefile at a previous job about compiling Python 2.4.2 with this
particular goal (installing the modules) and race conditions.
I would provide a patch but I'm not sure what the issue could stem from, other
than a race conditions with a busted install-sh and incomplete dependencies
specified in Makefile.pre.in.
I'll provide more info if needed.
Reproducible via the following on FreeBSD, given a fast enough machine:
cd lang/python26; make deinstall clean; make -j8 all; make -j8 install
[gcoo...@bayonetta /scratch/freebsd/ports/lang/python26]$ uname -a
FreeBSD bayonetta.localdomain 9.0-CURRENT FreeBSD 9.0-CURRENT #2: Thu Mar 4
13:16:39 PST 2010
gcoo...@bayonetta.localdomain:/usr/obj/usr/src/sys/BAYONETTA amd64
[gcoo...@bayonetta /scratch/freebsd/ports/lang/python26]$ sysctl -a hw.model
hw.model: Intel(R) Xeon(R) CPU W3520 @ 2.67GHz
[From top(1)]
Mem: 43M Active, 10G Inact, 870M Wired, 76M Cache, 1237M Buf, 537M Free
Swap: 20G Total, 108K Used, 20G Free
--
components: Build
messages: 100518
nosy: yaneurabeya
severity: normal
status: open
title: make install fails with -j8 with python2.6/config on FreeBSD
versions: Python 2.5, Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8079
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8079] make install fails with -j8 with python2.6/config on FreeBSD
Changes by Garrett Cooper yaneg...@gmail.com: Added file: http://bugs.python.org/file16467/all.log ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8079] make install fails with -j8 with python2.6/config on FreeBSD
Changes by Garrett Cooper yaneg...@gmail.com: Added file: http://bugs.python.org/file16468/clean.log ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1006238] cross compile patch
Garrett Cooper yaneg...@gmail.com added the comment: On Sun, Nov 1, 2009 at 5:50 AM, Mike Frysinger rep...@bugs.python.org wrote: Mike Frysinger vap...@users.sourceforge.net added the comment: AC_TRY_RUN is already documented: http://www.gnu.org/software/autoconf/manual/html_node/Obsolete-Macros.html#index-AC_005fTRY_005fRUN-1992 there are a bunch of distros out there (like OE and Gentoo) that have been maintaining cross-compile patches for python. i'm pretty sure the stuff in Gentoo works for 2.6.x, but i havent tried 3.1.x yet. ive given up on pushing to upstream as this bug (among others)) shows that such attempts go nowhere Actually what Mike showed was helpful for me. I didn't realize that the 3rd argument to AC_TRY_RUN was for Canadian cross, aka cross-compiling. My personal opinion on why past attempts have failed (and it's just my opinion) is probably because: 1. The change set wasn't incremental, thus the diff was large, and the checkin was rejected. 2. The patch was based on previous versions of python, which doesn't help the current trunk, release-maint* branches, etc. I'm more than happy to steal existing code (if possible :)..), but it should be well designed so longterm maintenance can be eased, and the cross-compile issue can be resolved in a correct manner. It took me 2 months to rewrite the Makefile infrastructure for LTP -- this should be a lot simpler and less painful to resolve (in terms of autotools input files, Makefile, etc). setup.py and distutils is something that I need to defer to someone more seasoned in the python internals (at least for mentoring) s.t. it can be resolved on all branches. First comes first, I'll propose some changes for cross-compilation dealing with some of the AC_TRY_RUN tests -- there are some tests that can be turned into preprocessor defines and/or AC_TRY_COMPILES [the sizeof(pthread_t), etc], then I'll look at the other tests and propose appropriate action for them. If needed individuals in the python org. aren't aware of this work, it probably should be brought to their attention sometime in the next couple of weeks, because I need to make sure core team members are aware of these changes so that they can get reviewed and checked into the project in a timely manner (my group needs to upgrade from 2.4.2 to python 2.6.x in the next couple months; this is a stopgap item for us because we use a cross-compilation environment). All the best, -Garrett -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1006238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1006238] cross compile patch
Garrett Cooper yaneg...@gmail.com added the comment: Ok. Taking a look at trunk... The following could be converted to AC_TRY_COMPILE statements for the 3rd AC_TRY_RUN tuple: 1. $ac_enable_profiling : 697 2. $ac_cv_no_strict_aliasing_ok : 921 3. $ac_cv_opt_olimit_ok : 1070 4. $ac_cv_olimit_ok : 1092 5. $ac_cv_pthread_is_default : 1126 6. $ac_cv_kpthread : 1163 7. $ac_cv_pthread : 1225 8. $ac_osx_32bit : 1569 9. $ac_cv_pthread_system_supported : 2229 10. $ac_cv_have_size_t_format : 3959 The following can just be converted to AC_TRY_COMPILE: 1. $ipv6 : 2278 2. $ac_cv_have_chflags : 2663 3. $ac_cv_have_lchflags : 2693 The following will need to be sorted out, as to what needs to be done here, as they are legitimate runtime only tests: 1. $ac_cv_little_endian_double : 3249 2. $ac_cv_big_endian_double : 3271 3. $ac_cv_mixed_endian_double : 3299 4. $ac_cv_x87_double_rounding : 3354 5. $ac_cv_broken_sem_getvalue : 3395 6. $ac_cv_tanh_preserves_zero_sign : 3430 7. $ac_cv_wchar_t_signed : 3510 8. $ac_cv_rshift_extends_sign : 3597 9. $ac_cv_broken_nice : 3714 10. $ac_cv_broken_poll : 3735 11. $ac_cv_working_tzset : 3772 Taking a look at py3k, most of the offsets are the same -- some have changed, but the only the test which doesn't exist in trunk is the following: 1. $ac_cv_broken_mbstowcs : 3872 Again, this is a valid runtime test, so it needs to be sorted out what should be done here with cross-compilation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1006238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1006238] cross compile patch
Garrett Cooper yaneg...@gmail.com added the comment: I'm trying to resolve this issue on: 2.6-releasemaint trunk 3.1-releasemaint py3k first by resolving issues configure.in, but there are a TON of AC_TRY_RUN's, which means that this code cannot be cross-compiled as-is (25 on 2.x -- 27 on 3.x). Is requiring the end-user to define the autoconf variables appropriately to their platform when running configure (when provided an error message telling them so), a longterm sustainable requirement? I know it isn't as user friendly, but this is a definite problem that either needs to be fixed in the autoconf tests (if possible) or the C code itself. I wouldn't mind updating the INSTALL or README files to reflect this change either, if needed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1006238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6558] #ifdef linux is incorrect; should be #ifdef __linux__ (preferred standard)
Garrett Cooper yaneg...@gmail.com added the comment: __linux is legitimate too, so the patch looks ok, but... 1) It won't apply cleanly against 2.4.5, most likely. 2) Why __linux instead of __linux__ ? gcoo...@orangebox ~ $ echo | gcc --std=c89 -E -dM -c - | grep linux #define __linux 1 #define __linux__ 1 #define __gnu_linux__ 1 __linux__ is the preferred nomenclature in the kernel.org sources, IIRC... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6558 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6558] #ifdef linux is incorrect; should be #ifdef __linux__ (preferred standard)
New submission from Garrett Cooper yaneg...@gmail.com: The following files are looking for the `linux' constant, when it fact they should be looking for `__linux__' (from 2.6.2 release's sources): Modules/_ctypes/libffi/src/mips/ffitarget.h:#ifdef linux Modules/socketmodule.c:#ifdef linux Modules/socketmodule.c:#ifdef linux The correct check is being made for FreeBSD (__FreeBSD__), for instance. This is a defacto standard set by gcc, as discussed here: http://lists.debian.org/debian-devel/2001/01/msg00951.html. You can dump out all of the available constants for any given gcc compiler via: [garrc...@sjc-lds-102 ~/Python-2.6.2]$ echo | gcc -E -dM -c - | grep linux #define __linux 1 #define __linux__ 1 #define __gnu_linux__ 1 #define linux 1 I point this out because one of our compilers, doesn't have this definition and it's tossing up errors with the linuxaudiodev and oss modules periodically when cross-compiling, as shown below :(: /nobackup/shujagan/tmp/contrib/python/Modules/linuxaudiodev.c:31: error: conflicting types for 'uint32_t' /nobackup/shujagan/tmp/linkfarm/mips32/usr/include/stdint.h:52: error: previous declaration of 'uint32_t' was here /nobackup/shujagan/tmp/contrib/python/Modules/ossaudiodev.c:37: error: conflicting types for 'uint32_t' /nobackup/shujagan/tmp/linkfarm/mips32/usr/include/stdint.h:52: error: previous declaration of 'uint32_t' was here We've suggested using --without-audio, but this is a standard which should be adhered to as __linux__ is the constant of choice when looking for the Linux compiler... Thanks! -Garrett -- assignee: theller components: Build, Extension Modules, ctypes messages: 90868 nosy: theller, yaneurabeya severity: normal status: open title: #ifdef linux is incorrect; should be #ifdef __linux__ (preferred standard) type: compile error versions: Python 2.4, Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6558 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1006238] cross compile patch
Garrett Cooper yaneg...@gmail.com added the comment: Coming back to this issue, I really want to resolve it on TRUNK and for it to make its way into 2.6.3 and 2.x trunk, as well as 3.0.2 and 3.x trunk. I am more than happy to sign a contributor agreement if this will push things along quicker. Thanks, -Garrett -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1006238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5850] Full example for emulating a container type
Garrett Cooper yaneg...@gmail.com added the comment: Maybe the documentation for other examples should be referenced then? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5679] cleanUp stack for unittest
Garrett Cooper yaneg...@gmail.com added the comment: Cool! Thanks for all of the hard work Michael :D. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5679 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5738] multiprocessing example wrong
Garrett Cooper yaneg...@gmail.com added the comment: Priorities shifted again at work, so I'll get around to this some time around early June when I get an opportunity to implement multiprocessing in my work code... Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5850] Full example for emulating a container type
New submission from Garrett Cooper yaneg...@gmail.com: This is just an example that I want to offer to the community to help improve overall documentation in the handbook. I've attached the example file, but it's also available on my journal post with example output: http://yaneurabeya.livejournal.com/3437.html -- assignee: georg.brandl components: Documentation files: somecontainerclass.py messages: 86637 nosy: georg.brandl, yaneurabeya severity: normal status: open title: Full example for emulating a container type versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file13794/somecontainerclass.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5850] Full example for emulating a container type
Garrett Cooper yaneg...@gmail.com added the comment: BTW, the documentation item that this should be attached to is: http://docs.python.org/reference/datamodel.html#emulating-container-types -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5770] SA bugs with unittest.py
New submission from Garrett Cooper yaneg...@gmail.com: A handful of valid bugs were reported with pylint when I was backporting unittest.py r71263 to 2.4/2.5 from HEAD. The attached diff fixes them. -- components: Extension Modules, Tests files: unittest-sa_fix-r71263.diff keywords: patch messages: 86018 nosy: yaneurabeya severity: normal status: open title: SA bugs with unittest.py type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file13700/unittest-sa_fix-r71263.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5770 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5771] SA bugs with unittest...@r71263
New submission from Garrett Cooper yaneg...@gmail.com: A handful of valid bugs were reported with pylint when I was backporting unittest.py r71263 to 2.4/2.5 from HEAD for http://code.google.com/p/python-unittest-backport. The attached diff fixes them. -- components: Extension Modules, Tests files: unittest-sa_fix-r71263.diff keywords: patch messages: 86019 nosy: benjamin.peterson, gregory.p.smith, michael.foord, yaneurabeya severity: normal status: open title: SA bugs with unittest...@r71263 type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file13701/unittest-sa_fix-r71263.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5771] SA bugs with unittest...@r71263
Garrett Cooper yaneg...@gmail.com added the comment: Ugh... The `...@staticmethod fix' was invalid. -- Added file: http://bugs.python.org/file13702/unittest-sa_fix-r71263.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5771] SA bugs with unittest...@r71263
Changes by Garrett Cooper yaneg...@gmail.com: Removed file: http://bugs.python.org/file13701/unittest-sa_fix-r71263.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5740] multiprocessing.connection.Client API documentation incorrect
New submission from Garrett Cooper yaneg...@gmail.com: In the API for connections.Client, it says: multiprocessing.connection.Client(address[, family[, authenticate[, authkey]]]) In the final paragraph is says: `If authentication is True or authkey ' As per the API provided it should be: `If authenticate is True or authkey ' This is true for the 2.6.1 and 3.1 documentation, so I assume it's incorrect for the 2.7 and 3.0 documentation as well. -- assignee: georg.brandl components: Documentation messages: 85887 nosy: georg.brandl, jnoller, yaneurabeya severity: normal status: open title: multiprocessing.connection.Client API documentation incorrect versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5706] setuptools doesn't honor standard compiler variables
Garrett Cooper yaneg...@gmail.com added the comment: I did some quick inspection and it appears to be tied purely into setuptools, not distutils. distutils does support the environment variables properly. So I take this item and submit it to PEAK I suppose? Fun times . Thanks for the help. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5743] multiprocessing.managers not accessible even though docs say so
New submission from Garrett Cooper yaneg...@gmail.com: I'm not sure why but my copy doesn't have a managers module. I'm really confused because multiprocessing.managers exists in Lib/multiprocessing/managers.py and it should have been installed with easy_install... Please see the attached testcase (it shows the details verifying that I don't have support). I ran it against all copies of python I have besides 3.x (nose doesn't support 3.x because setuptools isn't there yet for 3.x support). -bash-3.00$ python2.4 `which nosetests` ~/test_managers_support.py Python version: 2.4.5 (#1, Mar 28 2009, 14:54:51) [GCC 3.4.6 20060404 (Red Hat 3.4.6-9)]F == FAIL: test_managers_support.test_has_managers -- Traceback (most recent call last): File /ws/garrcoop-sjc/tools/lib/python2.4/site-packages/nose-0.10.4-py2.4.egg/nose/case.py, line 182, in runTest self.test(*self.arg) File /users/garrcoop/test_managers_support.py, line 9, in test_has_managers assert hasattr(multiprocessing, 'managers') AssertionError -- Ran 1 test in 0.050s FAILED (failures=1) -bash-3.00$ python2.5 `which nosetests` ~/test_managers_support.py /ws/garrcoop-sjc/tools/lib/python2.4/site-packages/multiprocessing-2.6.1.1-py2.4-linux-i686.egg/multiprocessing/__init__.py:86: RuntimeWarning: Python C API version mismatch for module _multiprocessing: This Python has API version 1013, module _multiprocessing has version 1012. import _multiprocessing Python version: 2.5.4 (r254:67916, Mar 28 2009, 15:01:19) [GCC 3.4.6 20060404 (Red Hat 3.4.6-9)]F == FAIL: test_managers_support.test_has_managers -- Traceback (most recent call last): File /ws/garrcoop-sjc/tools/lib/python2.4/site-packages/nose-0.10.4-py2.4.egg/nose/case.py, line 182, in runTest self.test(*self.arg) File /users/garrcoop/test_managers_support.py, line 9, in test_has_managers assert hasattr(multiprocessing, 'managers') AssertionError -- Ran 1 test in 0.159s FAILED (failures=1) -bash-3.00$ python2.6 `which nosetests` ~/test_managers_support.py F == FAIL: test_managers_support.test_has_managers -- Traceback (most recent call last): File /ws/garrcoop-sjc/tools/lib/python2.4/site-packages/nose-0.10.4-py2.4.egg/nose/case.py, line 182, in runTest self.test(*self.arg) File /users/garrcoop/test_managers_support.py, line 7, in test_has_managers assert hasattr(multiprocessing, 'managers') AssertionError -- Ran 1 test in 0.029s FAILED (failures=1) -- components: Extension Modules, Installation files: test_managers_support.py messages: 85921 nosy: jnoller, yaneurabeya severity: normal status: open title: multiprocessing.managers not accessible even though docs say so versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file13679/test_managers_support.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5743 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5743] multiprocessing.managers not accessible even though docs say so
Garrett Cooper yaneg...@gmail.com added the comment: Sorry -- the info for my python2.6 was out of date. Here's the info (I had to set PYTHONPATH to to avoid a multiprocessing module conflict): bash-3.00$ PYTHONPATH=; python2.6 `which nosetests` ~/test_managers_support.py Python version: 2.6.1 (r261:67515, Mar 28 2009, 06:39:52) [GCC 3.4.6 20060404 (Red Hat 3.4.6-9)]F == FAIL: test_managers_support.test_has_managers -- Traceback (most recent call last): File /ws/garrcoop-sjc/tools/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/nose/case.py, line 182, in runTest self.test(*self.arg) File /users/garrcoop/test_managers_support.py, line 9, in test_has_managers assert hasattr(multiprocessing, 'managers') AssertionError -- Ran 1 test in 0.045s FAILED (failures=1) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5743 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5744] multiprocessing.managers.BaseManager.connect example typos
New submission from Garrett Cooper yaneg...@gmail.com: The example under multiprocessing.managers.BaseManager.connect has 2 typos: from multiprocessing.managers import BaseManager m = BaseManager(address='127.0.0.1', authkey='abc)) m.connect() Here's a corrected example: from multiprocessing.managers import BaseManager m = BaseManager(address='127.0.0.1', authkey='abc') m.connect() -- assignee: georg.brandl components: Documentation messages: 85924 nosy: georg.brandl, jnoller, yaneurabeya severity: normal status: open title: multiprocessing.managers.BaseManager.connect example typos versions: Python 2.6, Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5744 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5744] multiprocessing.managers.BaseManager.connect example typos
Garrett Cooper yaneg...@gmail.com added the comment: Thanks for noting that George Y. and thanks for fixing the documentation on SVN Benjamin :). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5744 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5738] multiprocessing example wrong
New submission from Garrett Cooper yaneg...@gmail.com: The last example on the multiprocessing documentation page is clearly wrong. It references a lot of renamed / deprecated API's from processing that are no longer in multiprocessing. I'll try and come up with a comparable working example on all platforms (I use FreeBSD). -- assignee: georg.brandl components: Documentation messages: 85874 nosy: georg.brandl, yaneurabeya severity: normal status: open title: multiprocessing example wrong type: feature request versions: Python 2.6, Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5738] multiprocessing example wrong
Garrett Cooper yaneg...@gmail.com added the comment: How about this? I'll do both :). I'm avoiding sync + semaphore stuff because it's still non-portable (Issue 3770 fun), even though I have a functioning copy of FreeBSD... but I do have a Mac, VMware fusion, etc, and I'll toss in a working example with Fedora 10. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5679] cleanUp stack for unittest
Garrett Cooper yaneg...@gmail.com added the comment: I think some perspective is required on this enhancement request. I originally filed this issue -- http://bugs.python.org/issue5538 -- because of the unneeded complexity involved with duplicating teardown-related code in setUp because of a step in setUp failing. From my perspective, there are two issues: - setUp failing doesn't cleanup on failure unless the test writer explicitly adds cleanup logic. - cleanup shouldn't partially replace tearDown -- either supplement it or completely replace it longterm. Otherwise the unittest code and expectations associated with it will potentially confuse end users. Another thought: Why not have an option for defining a method called `incrementalTearDown', which replaces `tearDown' from a functional standpoint? A method like that would clearly convey that this is designed to replace tearDown, it's not the same functionally, and would ease migration over the long-term if people chose to use this design when writing testcases. I personally think that doing something like this would be trivial (yet novel) functionality as it makes more sense than the current implementation of setUp-test-tearDown. -- nosy: +yaneurabeya ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5679 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5679] cleanUp stack for unittest
Garrett Cooper yaneg...@gmail.com added the comment: I see the validity in the concern raised by Virgil: I think this can be simplified from a user perspective by saying `I'm electing to use cleanUp over tearDown'. The two systems are similar, but also very different semantically as tearDown gets executed in the event of test completion (regardless of whether or not it passed) whereas cleanUp gets executed based on what occurs in setUp. Or am I missing the boat here on what's trying to be accomplished? We really shouldn't be mixing and matching both implementations because that will confuse people... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5679 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5706] setuptools doesn't honor standard compiler variables
New submission from Garrett Cooper yaneg...@gmail.com: I realize that cross-compilation isn't supported yet, _but_ setuptools needs to be modified such that standard compilation variables are supported, e.g. CC, CFLAGS, CPPFLAGS, LD, LDFLAGS, LDLIBS. The -i, -l, and -L flags with setup.py with build_ext provide a basic level of support, but unfortunately it doesn't match what these environment variables provide. -- components: Installation messages: 85611 nosy: yaneurabeya severity: normal status: open title: setuptools doesn't honor standard compiler variables type: feature request versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5538] tearDown in unittest should be executed regardless of result in setUp
Garrett Cooper yaneg...@gmail.com added the comment: As an FYI, I'm going to push this off until next week or the week after because I have more pressing things to take care of and have an OK workaround for this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5538] tearDown in unittest should be executed regardless of result in setUp
Garrett Cooper yaneg...@gmail.com added the comment: I agree with you guys to a certain extent, but doing so only complicates my setup procedure to the extent that I'm calling a lot of my teardown code in a dumb manner, unless I actually kept track of how far into the setup process I got before everything went awry and split it into a multistep rollback process for atomicity. This in and of itself seems like a lot to track with complicated processes like configuring a daemon interactively via pexpect, or modifying a remote VM instance with multiprocessing being used for injection, and I don't know if I can expect consumers of my test suites to get it right twice. Could you guys provide some examples of existing test suites where this may potentially break things? Thanks! -Garrett -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5538] tearDown in unittest should be executed regardless of result in setUp
Garrett Cooper yaneg...@gmail.com added the comment: And maybe the addCleanup components could be a stack of callable objects? This would make life easier for folks like me and would make the overall flow much cleaner / clearer as it would allow us to break things down into atomic steps which could be reverted in a LIFO order. Steve / Raymond: Do you guys like Jean-Paul's proposal? If so, I'll write up a patch sometime this coming weekend to implement that functionality. For now I'll just call tearDown blindly on Exceptions *shivers*. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5538] tearDown in unittest should be executed regardless of result in setUp
Garrett Cooper yaneg...@gmail.com added the comment: Ok, sounds good then ;). I'll open another issue with the enhancement later on this week. Cheers! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5538] tearDown in unittest should be executed regardless of result in setUp
Garrett Cooper yaneg...@gmail.com added the comment: Before I forget though -- should the requirements for the functionality be that it be called strictly in setUp on failure, or should it be executed as a part of tearDown as well? Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5538] tearDown in unittest should be executed regardless of result in setUp
Garrett Cooper yaneg...@gmail.com added the comment: Excellent point Kumar. Here's what I'm trying to accomplish... I'm a part of a team that's testing out IOSd on an up and coming Unix foundation platform. This requires starting up a series of services, ensuring that they have come up, and then login to the IOS console, then IF the user gets their configuration correct (because I'm providing a means for the user to configure IOS) the setup stage of the testcase will be complete. IF NOT (and here comes the tricky part), the UUT is in a really questionable / funky state and I can't be sure if the system is really usable for additional tests without restarting / reinitializing it. This in and of itself is more problematic to deal with as that means I'd need to attach myself to the local console and listen for restart to complete, then issue configuration parameters to boot up the device, etc... This is being done once by another Tcl script, so I'm trying to avoid having to reinvent the wheel for known working methods. Hopefully that better illustrates the quandary that I'm dealing with :). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5538] tearDown in unittest should be executed regardless of result in setUp
Garrett Cooper yaneg...@gmail.com added the comment: Unfortunately we're still stuck on 2.4.5 because I don't have enough buy-in from tech leads and architects to upgrade right now -_-... Good idea though :] *stores for later*. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5538] tearDown in unittest should be executed regardless of result in setUp
New submission from Garrett Cooper yaneg...@gmail.com: While trying to deal with some annoying issues with setting up and tearing down consoles via pexpect, I noticed that the teardown functions / methods weren't being executed via nose. After applying this change to 2.4.5 and 2.6.1, things work as expected (note: this patch only applies cleanly with 2.4.5 AFAICT -- it didn't work with 2.6.1). My expectations are: I'd expect that the best fix would be for tearDown to be unconditionally called if setUp is called, s.t. testers can ensure that the operating state of the UUT and testbed are at a predefined state. So in my testcase provided, I would expect the following flow: 1. Keeping assert False in setup_module... `Calling setup_module' assert fails `Calling teardown_module' 2. Removing assert False from setup_module... `Calling setup_module' - `Calling function_setup' assert fails - `Calling function_teardown' - `Calling TestClass:setUp' assert fails - `Calling TestClass:tearDown' `Calling teardown_module' If this isn't done, it makes some operations, like tearing down consoles with pexpect _extremely_ painful to perform... Please see http://code.google.com/p/python-nose/issues/detail?id=234 for more details. -- components: Tests files: issue-blah-2.4.5.diff keywords: patch messages: 83983 nosy: yaneurabeya severity: normal status: open title: tearDown in unittest should be executed regardless of result in setUp versions: Python 2.4, Python 2.5, Python 2.6 Added file: http://bugs.python.org/file13397/issue-blah-2.4.5.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5538] tearDown in unittest should be executed regardless of result in setUp
Changes by Garrett Cooper yaneg...@gmail.com: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
