Re: [Python-Dev] Wrong OSX platform in sysconfig.py causing installation problems
On Sat, May 7, 2016 at 10:59 PM, Chris Barker wrote: > > Trying to decide if I want to go through the hassle of installing an > old XCode to see if i can replicate the bug the OP is reporting > OK, I found this gitHub repo with all the old SDKs: https://github.com/phracker/MacOSX-SDKs I put a copy of the 10.6 SDk in it's old location: /Developer/SDKs/MacOSX10.6.sdk/ /before I did that, I did a pip install of zodb in a virtualenv, and all seemed to go fine. THe extensions rae linked against : $ otool -L cPersistence.cpython-35m-darwin.so cPersistence.cpython-35m-darwin.so: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) where that comes from -- who knows?? then I tried again, after putting the sdk in place: [note: serious pain the $%^# to get pip to stop using it's cache! ] and everything seemed to build fine, and at least one simple test of zodb works fine. And this is how the extensions are linked: $ otool -L cPersistence.cpython-35m-darwin.so cPersistence.cpython-35m-darwin.so: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11) which is the same as above, but the "current version" is much older -- so does that mean it used the 10.6 SDK Anyway, I can't reproduce the OP's bug. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Wrong OSX platform in sysconfig.py causing installation problems
On Fri, May 6, 2016 at 10:43 AM, Joseph Lee Nunn III wrote: > Then I have found the right list to post on, for my problem is a bug in > the Python 3.5.1 distribution. Albeit one which will only manifest in > certain situations. > > The presence of numerous `-isysroot /Developer/SDKs/MacOSX10.6.sdk` > directives in the following file > > > /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/_sysconfigdata.py > As I understand it, that is all there so that when extensions are built, they are linked against that SDK -- so you can build extensions that can then be run on any system 10.6 and greater. > Will cause errors for people who have kept around the old /Developer > directory tree, and old SDKs like 10.6, for building backwards compatible > old code. what are the errors -- wouldn't the old SDK be found, and used, and that's exactly what's intended? > Newer versions of the SDKs are now kept inside the Xcode application > itself. And then they will only have a problem when trying to install a > package with C extensions, well, sure. of course this is an issue for building C extensions. > which in my case was Persistence, a dependency of ZODB. And even more so, > ONLY when trying to pip install said package into a virtual environment > created by 3.5’s pyvenv command, if installing the package into the system > wide Python there will be no error. > hmm, As I understand it the building process should be exactly the same whether you are on a virtualenv or not. but if so -- maybe the "solution" is to build a wheel outside virtualenv, and then install that wheel in the virtualenv. But I agree, it should work, of course. > You see the -isysroot flag has the unusual behavior where instead of > reporting an error when it cannot find the newly specified system root it > simply has no effect. So if you don’t have the SDK specified in the > location specified then the flag does nothing, as I assume is the case for > 99% of people. > Indeed, that's been working fine for me for a while. However it's this behavior that is actually the bug -- extensions are supposed to be build against the 10.6 SDK -- and that's not what's happening in this case > I understand the need to make Python 3.5 backwards compatible, but doing > it this way would appear to have the side effect of breaking the ability to > install packages using C extensions in virtual environments, or at least it > did for me. > It does sound like you've hit a bug, but I actually think you've misidentified the bug -- I'm trying to understand why it's not working in a virtualenv -- THAT's the bug. And I have no idea what to do about it -- thanks Apple for moving things -- that's a great way to keep backward compatibility! Ned: I'm trying to explore this a bit now (on a 10.9 system), so I followed the instructions in the Python developers guide, and did: xcode-select --install And was a bit surprised that It did a substantial download -- I thought I already had the XCode command line tools -- but whatever. After running that, I found I had the 10.9 and 10.10 SDKs (I think that installed the 10.10 one, I previously had only 10.9). And they are buried deep in XCode.app OK, but how would I go about getting the 10.6 SDK??? This SO post: http://stackoverflow.com/questions/11989007/where-to-get-macos-sdk-10-6-for-xcode indicates that it's a serious pain in the $%^% -- thank Apple! But, as far as I can tell, if you install an old XCode, you will get the older SDKs, and installed into the old location. (this is why I kept a 10.6 system around for a long time -- to build python extensions...) But what should we do? IF you are building extensions only for yourself, then I think whatever the heck SDK you have will work fine -- but how to build for distribution? Trying to decide if I want to go through the hassle of installing an old XCode to see if i can replicate the bug the OP is reporting -CHB > https://docs.python.org/devguide/setup.html#build-dependencies > > > > > Installing Xcode by itself is not sufficient. The sysroot and flag > values you note in _sysconfigdata.py are normal and there for compatibility > with installing on older versions of OS X; they should not cause a problem > on newer releases. For what it's worth, I was able to install ZODB with > the current python.org 3.5.1 on OS X 10.11.4 using either venv or > virtualenv. > > > > Good luck! > > > > --Ned > > > > P.S. Mailing list info is available here: https://mail.python.org. The > bug tracker is here: https://bugs.python.org > > > > -- > > Ned Deily > > n...@python.org -- [] > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 5
Re: [Python-Dev] Tracker Etiquette
On 7 May 2016 at 23:23, Senthil Kumaran wrote: > > On Sat, May 7, 2016 at 4:17 PM, MRAB wrote: >> >> I think you shouldn't delete them. It would be better just to say that >> you've changed your mind and explain why. > > > I support this. Please leave your new comments correcting previous one and > support your current stance. I think, it is alright to make revisions in > comments. Taking a middle ground between this and what Brett said, I would say it is okay to delete stuff if it is fresh and hasn’t been replied to (but maybe leave a message if it is not obvious why you delete it). On the other hand, avoid deleting stuff if it would harm the overall thread. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker Etiquette
On Sat, May 7, 2016 at 4:17 PM, MRAB wrote: > I think you shouldn't delete them. It would be better just to say that > you've changed your mind and explain why. > I support this. Please leave your new comments correcting previous one and support your current stance. I think, it is alright to make revisions in comments. -- Senthil ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker Etiquette
On 2016-05-08 00:06, Ethan Furman wrote: I just reviewed an issue on the tracker, and found that many, if not all, of my comments made at the time I completely disagree with (both now, and before -- I'm going to claim sleep deprivation). Obviously I should post a new comment explaining my thoughts about the issue, but what should I do with the old comments? Is it acceptable to delete them? I think you shouldn't delete them. It would be better just to say that you've changed your mind and explain why. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of alternative constructors
On 05/07/2016 03:39 PM, Serhiy Storchaka wrote: Some types have alternative constructors -- class methods used to create an instance of the class. For example: int.from_bytes(), float.fromhex(), dict.fromkeys(), Decimal.from_float(). But what should return these methods for subclasses? Should they return an instance of base class or an instance of subclass? Almost all alternative constructors return an instance of subclass (exceptions are new in 3.6 bytes.fromhex() and bytearray.fromhex() that return bare bytes and bytearray). But there is a problem, because this allows to break invariants provided by the main constructor. Please ignore my comments in that issue. I actually prefer that class constructors go through the subclass' __new__ and __init__. Overriding parent class methods for the sole purpose of getting the subclass's type is quite irritating. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker Etiquette
I think if you leave a comment that to deleted your own comments and why you did it then it's fine. On Sat, May 7, 2016, 16:07 Ethan Furman wrote: > I just reviewed an issue on the tracker, and found that many, if not > all, of my comments made at the time I completely disagree with (both > now, and before -- I'm going to claim sleep deprivation). > > Obviously I should post a new comment explaining my thoughts about the > issue, but what should I do with the old comments? Is it acceptable to > delete them? > > -- > ~Ethan~ > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tracker Etiquette
I just reviewed an issue on the tracker, and found that many, if not all, of my comments made at the time I completely disagree with (both now, and before -- I'm going to claim sleep deprivation). Obviously I should post a new comment explaining my thoughts about the issue, but what should I do with the old comments? Is it acceptable to delete them? -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Return type of alternative constructors
Some types have alternative constructors -- class methods used to create an instance of the class. For example: int.from_bytes(), float.fromhex(), dict.fromkeys(), Decimal.from_float(). But what should return these methods for subclasses? Should they return an instance of base class or an instance of subclass? Almost all alternative constructors return an instance of subclass (exceptions are new in 3.6 bytes.fromhex() and bytearray.fromhex() that return bare bytes and bytearray). But there is a problem, because this allows to break invariants provided by the main constructor. For example, there are only two instances of the bool class: False and True. But with the from_bytes() method inherited from int you can create new boolean values! >>> Confusion = bool.from_bytes(b'\2', 'big') >>> isinstance(Confusion, bool) True >>> Confusion == True False >>> bool(Confusion) True >>> Confusion False >>> not Confusion False bool is just the most impressive example, the same problem exists with IntEnum and other enums derived from float, Decimal, datetime. [1] The simplest solution is to return an instance of base class. But this can breaks a code, and for this case we should be use static method (like str.maketrans), not class method. Should alternative constructor call __new__ and __init__ methods? Thay can change signature in derived class. Should it complain if __new__ or __init__ were overridden? [1] http://bugs.python.org/issue23640 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
