sysconfig on OS X 10.7 (Lion) and XCode 4.2
Hello all, I've struggled mightily to get Numpy and pyopencl installed on my brand-new Lion machine running XCode 4.2 (not recommended, I know, but I'm a sucker for punishment). I did finally succeed, anyway. I found that the greatest problem I had (after installing gfortran from a precompiled package) was getting setup.py and subsidiaries to use the right GCC. The python.org official builds of Python (I'm specifically using 3.2.2, though I'm sure this applies to 2.7 as well) have some trouble with building extensions because CC is specified as "gcc-4.2", which no longer exists in XCode 4.2 (one could chalk that up to being Apple's problem, but hey). The root of this problem is in the sysconfig module, which I assume has hardcoded names for the compiler, etc. Most insidious was fixing LDSHARED, which was gcc-4.2 with a bunch of flags appended to it including the system framework (for 10.6, I should point out, which is also what sysconfig returned for sysconfig.platform()). Is there any way to permanently override these values in sysconfig short of building my own Python and installing it? I'm having to override the environment variables whenever I build a C/C++ module, and it's getting to be a pain. For anyone looking for the answer to a similar problem (usually gcc-4.2 not being found when running setup.py), export the following environment variables to build things under XCode 4.2: CC=gcc CXX=g++ LDSHARED="gcc -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.7.sdk -isysroot /Developer/SDKs/MacOSX10.7.sdk -g" (obviously, replace 10.7 with 10.6 if you're building under 10.6) For example: sudo CC=gcc CXX=g++ LDSHARED="gcc -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.7.sdk -isysroot /Developer/SDKs/MacOSX10.7.sdk -g" pip install pyopencl This will override the default values taken from the sysconfig module. - Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: help
"Libel" and "slander" also generally indicate malice. Perhaps just "That's incorrect" might have come off a little less harsh. :-) - Dave On Oct 23, 2011, at 12:05 PM, Matej Cepl wrote: > Dne 22.10.2011 17:02, Steven D'Aprano napsal(a): >> Rather than assume malice, we should give X1 the benefit of the doubt and >> assume he genuinely believed what he wrote but was merely mistaken. > > Sure, I didn't want to assume malice (sorry, English is my second language > and sometimes it shows; would "libel" or "slander" fit the bill better?). I > just wanted to slip in the information about repoquery which is an awesome > tool, but not many people know about it. > > Matěj > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: How to use shell return value like $? In python?
On Oct 23, 2011, at 10:44 PM, [email protected] wrote: > exp: > os.system('ls -al'） > #I like to catch return value after this command. 0 or 1,2,3 > does python support to get "$?"? > then I can use something like: > If $?==0: > > From the manual (http://docs.python.org/library/os.html#os.system): "On Unix, the return value is the exit status of the process encoded in the format specified for wait(). Note that POSIX does not specify the meaning of the return value of the C system() function, so the return value of the Python function is system-dependent." From the linked wait() documentation, the data returned is in a 16-bit integer, with the high byte indicating the exit status (the low byte is the signal that killed the process). So: status = os.system("foo") retval, sig = ((status >> 8) & 0xFF), (status & 0xFF) In the above example, your return status will end up in "retval". Of course, you probably ought to be using subprocess to run your subprocesses anyway; it's a lot more powerful and a lot harder to enable things like shell injection attacks. See: http://docs.python.org/library/subprocess.html#subprocess-replacements (which, of course, shows a direct replacement for os.system which is just as vulnerable to shell injection) - Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode literals and byte string interpretation.
On Oct 27, 2011, at 11:05 PM, Fletcher Johnson wrote: > If I create a new Unicode object u'\x82\xb1\x82\xea\x82\xcd' how does > this creation process interpret the bytes in the byte string? Does it > assume the string represents a utf-16 encoding, at utf-8 encoding, > etc...? > > For reference the string is これは in the 'shift-jis' encoding. Try it and see! One test case is worth a thousand words. And Python has an interactive interpreter. :-) - Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Python lesson please
On Nov 6, 2011, at 3:34 PM, Cameron Simpson wrote: > Perhaps more relevantly: > > If you have unmangled a lot of tabs, remember that control flow is > indentation based in python, and you may have broken some logic. > (For this reason a number of us set our editors to work only in spaces). I would absolutely check this first. I can't count the number of programs I've screwed up in difficult-to-detect ways because I've converted from tabs to spaces incorrectly. It's how I've finally learned to let a program/script do it for me, because Python is the first language I've used with significant leading whitespace. - Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: suppressing import errors
On Nov 15, 2011, at 12:35 PM, Andreea Babiuc wrote:
>
>
> On 15 November 2011 17:24, Chris Kaynor wrote:
> As with any Python code, you can wrap the import into a try: except block.
>
> try:
> import badModule
> except:
>
>
> pass # Or otherwise handle the exception - possibly importing an
> alternative module.
>
>
> Hmm, I know this might sound silly, but if it fails I still want to import
> the module and disable those lines of code that are related to the reason
> while the module failed to be imported in the first place. Even if that
> makes the code not 100% correct.
>
> Does that make sense ?
It makes sense. It probably also makes sense to only do an "except
ImportError", since if there are other errors (say, syntax errors in a module
you're trying to import, rather than its absence, you probably want to know
about it.
To disable code that won't work without the module you're trying to import, you
can always set flags in your module. For example, I've got a project at work
that can use a variety of communications interfaces, including using PySerial
for serial port comms. But if someone doesn't have PySerial installed, I want
it to fail gracefully and just not support serial. So I can do the following:
try:
import serial
_serial_enabled = True
except ImportError:
print("PySerial not installed - serial ports not supported!")
_serial_enabled = False
And then elsewhere in my module, I can check the value of _serial_enabled to
see if I should e.g. list the serial ports in available communications
interfaces.
Of course, if there's some other error in PySerial (maybe I installed a broken
version with a syntax error?), that error will get propagated up, which is a
good thing, because I'd rather know that PySerial is broken than just have it
tell me it's not installed (which is what would happen if I simply caught all
exceptions). Your mileage may vary.
- Dave
--
http://mail.python.org/mailman/listinfo/python-list
Re: suppressing import errors
On Nov 15, 2011, at 1:58 PM, Jean-Michel Pichavant wrote: > PS : @Dave there is a way to avoiding adding symbols to your global > namespace, assign None to the module's name on import errors. Then before > using it, just test the module bool value : if serial: serial.whateverMethod() True, and that does avoid polluting namespace. However, you shouldn't be testing for None as a bool; you should instead do an "if is None:" (or, of course, "is not None"). - Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: suppressing import errors
On Nov 15, 2011, at 3:01 PM, Chris Angelico wrote: > On Wed, Nov 16, 2011 at 6:39 AM, David Riley wrote: >> True, and that does avoid polluting namespace. However, you shouldn't be >> testing for None as a bool; you should instead do an "if is None:" >> (or, of course, "is not None"). > > Why not? Is there some other way for the module object to evaluate as false? Well, probably not. It was my understanding that "None" evaluating to a Boolean false was not necessarily guaranteed; I've even gotten some warnings from Python to that effect, though I can't recall the context in which that happened. In any case, PEP 8 states: Comparisons to singletons like None should always be done with 'is' or 'is not', never the equality operators. Also, beware of writing "if x" when you really mean "if x is not None" -- e.g. when testing whether a variable or argument that defaults to None was set to some other value. The other value might have a type (such as a container) that could be false in a boolean context! Obviously, that last bit doesn't apply to modules; they're not going to evaluate as False in general. I just bristle when I see people writing "if x" when they really mean "if x is not None", perhaps because it's not The Right Way(tm)? It mostly comes down to aesthetics, I guess. Write what you really mean. - Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: suppressing import errors
On Nov 15, 2011, at 5:59 PM, Alan Meyer wrote: > On 11/15/2011 4:20 PM, David Riley wrote: > ... >> None was set to some other value. The other value might have a type >> (such as a container) that could be false in a boolean context! >> >> Obviously, that last bit doesn't apply to modules; they're not going to >> evaluate as False in general. I just bristle when I see people writing "if >> x" when they really mean "if x is not None", perhaps because it's not The >> Right Way(tm)? It mostly comes down to aesthetics, I guess. Write what you >> really mean. > > Actually Dave, as your quote from PEP 8 says, the difference is real. It's > not just aesthetics. I guess I meant it's aesthetics when it comes down to determining whether a module is None or not; a module is never going to evaluate to False under any feasible circumstances. It's not an aesthetic difference when you consider that the global (or local) namespace may be polluted with other variables that have the same name as your module, but then your evaluation would be entirely invalid anyway. But yes, in the general case, it's much more than an aesthetic difference, which is why I always write "if x is None" when I want to know if it's None (rather than False, 0, [], "", etc). I have been bitten way too many times by doing the lazy thing to keep doing it. - Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Non-POSIX parity (mark/space) with Python-Serial on Linux.
On Nov 21, 2011, at 11:28 AM, Matthew Lenz wrote: > Using 8N1 under minicom with this device resulted in garbled text when once > connected. Connection using 7M1 resulted in the correct text. So there must > be something else that needs to be done in my python program correct? Under minicom in 8N1, it's going to look garbled because the high bit will always be set. Minicom will try to spit out those characters anyway, which will print out whatever extended ASCII garbage your terminal supports in the 0x80-0xFF range. Programmatically, though, you can strip off the high bit when you're receiving it in Python. "Space" parity, on the other hand, should look normal under Minicom because the high bit will always be low, giving you standard 7-bit ASCII. - Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Non-POSIX parity (mark/space) with Python-Serial on Linux.
On Nov 21, 2011, at 11:52 AM, Matthew Lenz wrote:
> Ahh. Ok. So how would I go about doing that with python? I think in perl
> (sorry for the naughty word) I could use the tr// (translate) but is there a
> quick way to do so with python? Is it going to be necessary to convert
> commands I SEND to the device or only convert what I receive?
The high-level overview is that you'll want to OR in 0x80 on transmit, and AND
0x7F on receive (thus inserting the high bit when you send it out and removing
it when you receive). If you wanted to be extra-sure you're receiving things
correctly, you should also check to see if your value ANDed with 0x80 is not
zero.
In Python 2.x, as mentioned, when you iterate over a string, you get a bunch of
tiny one-character strings, which you then need to convert into numbers with
ord() and back into strings with chr() when you re-concatenate it. ord() and
chr() may be familiar to you from Perl. For example, you could do this on
reception:
# However you get your data out of serial
received_str = receive_my_string()
ord_str = [ord(x) for x in received_str]
# An exception may be extreme in this case, but hey. Note that
# the filter() function actually returns a list of all the
# characters that don't have the high bit set, so you could
# actually use that if you wanted to.
if filter((lambda x: x < 0x80), ord_str):
raise IOError("Received character without mark parity")
return "".join([chr(x & 0x7F) for x in received_str])
In Python 3.x, iterating over a bytes array (which is, hopefully, what your
serial interface returns) will give you a bunch of ints, so you shouldn't need
to do the conversions:
# However you get your data out of serial
received_bytes = receive_my_string()
# In Python 3.x, filter() returns an iterator, which is generally a
# better thing to return, but doesn't test as nicely for a bool.
for b in received_bytes:
if b < 0x80:
raise IOError("Received character without mark parity")
# None of this "".join() nonsense with byte arrays!
return bytes([(x & 0x7F) for x in received_bytes])
There are surely more efficient ways to do what I've typed up there, but those
should work pretty well for whatever you're looking to do. For sending, you
pretty much want to swap (x & 0x7F) with (x | 0x80) to insert that high bit.
- Dave
--
http://mail.python.org/mailman/listinfo/python-list
Re: Non-POSIX parity (mark/space) with Python-Serial on Linux.
On Nov 21, 2011, at 12:25 PM, gene heskett wrote: > And that is 9600 baud 8n1 on both ends. Ascii is normally 7 bit and will > have a low 8th bit if fed normal ascii data, so how is the 8th bit getting > set other than purposely setting 7M1 on the other end of the cable? That's what I thought the OP was doing; it sounds like he's trying to receive 7M1 in Minicom using 8N1 on the terminal and getting garbled data because the high bit is set (because the other end is sending 7M1). I never meant to imply that 8N1 would give garbled data if both ends were set to it; indeed, that's pretty much standard communications settings for short cables in low to moderate noise environments. If anyone else read it that way, that's not what I meant. :-) - Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Non-POSIX parity (mark/space) with Python-Serial on Linux.
On Nov 21, 2011, at 12:59 PM, Matthew Lenz wrote: > Thanks, this will be a great help. > > Just wanted to confirm that you meant to use [ .. for x in ord_str] in the > example conversion? Got a TypeError using the received_str. Yes, I probably should have double-checked that. ord_str is indeed what I meant. :-) - Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Non-POSIX parity (mark/space) with Python-Serial on Linux.
On Nov 21, 2011, at 2:29 PM, Matthew Lenz wrote: > Another thing I noticed is that the & and | appear to give the same result as > adding or subtracting 128 from the ordinal value. I'm assuming that isn't > coincidence. :) It's not, though the difference is important. They're binary ANDs (&) and ORs (|), so (0x0F | 0x80) = 0x8F, but (0x8F | 0x80) = 0x8F as well, whereas (0x8F + 0x80) = 0x10F. For manipulating bit values (which is what you're doing, you should almost never be adding or subtracting, but rather ANDing and ORing (or XORing, but not nearly as often). Just in case you're not familiar, 0x is the prefix for a hexadecimal number. 0x80 = 128, which is binary 1000 (i.e. the high bit in a byte). - Dave -- http://mail.python.org/mailman/listinfo/python-list
