Re: How to install Python package from source on Windows
On Mon, May 15, 2017 at 4:48 PM, Deborah Swanson wrote: > Chris Angelico wrote on Sunday, May 14, 2017 11:30 PM >> >> On Mon, May 15, 2017 at 4:28 PM, Deborah Swanson >> wrote: >> > >> > Again, maybe I should go back to Python 2 for this. >> >> Won't help. The same problems will exist. >> >> ChrisA >> > > Good to know. Maybe I just won't be able to try recordclass until I get > Linux set up one way or another. Right now it's more important to me to > spend the few hours a day I have making progress in Python. > > (Now, if I can figure out how to make gettattr work in this one > namedtuple problem, I won't need anything like recordclass. I've > converted three more Excel spreadsheets to Python, but it's tricky > working with namedtuples when you want to group rows or take n colomns > at a time. I've done it, but this one is really tough.) Hmm. If you're working heavily with tabular data, you may want to consider numpy or pandas, both of which are designed for major computational work and will happily manipulate rows or columns of data. Both are well supported on Windows (and everywhere). They do have their own learning curve though. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Chris Angelico wrote, on Monday, May 15, 2017 1:02 AM > > On Mon, May 15, 2017 at 4:48 PM, Deborah Swanson > wrote: > > Chris Angelico wrote on Sunday, May 14, 2017 11:30 PM > >> > >> On Mon, May 15, 2017 at 4:28 PM, Deborah Swanson > >> wrote: > >> > > >> > Again, maybe I should go back to Python 2 for this. > >> > >> Won't help. The same problems will exist. > >> > >> ChrisA > >> > > > > Good to know. Maybe I just won't be able to try > recordclass until I > > get Linux set up one way or another. Right now it's more > important to > > me to spend the few hours a day I have making progress in Python. > > > > (Now, if I can figure out how to make gettattr work in this one > > namedtuple problem, I won't need anything like recordclass. I've > > converted three more Excel spreadsheets to Python, but it's tricky > > working with namedtuples when you want to group rows or > take n colomns > > at a time. I've done it, but this one is really tough.) > > Hmm. If you're working heavily with tabular data, you may > want to consider numpy or pandas, both of which are designed > for major computational work and will happily manipulate rows > or columns of data. Both are well supported on Windows (and > everywhere). They do have their own learning curve though. > > ChrisA > -- Yes. I want to spend more time with numpy and learn pandas, but right now I do have to consider the learning curves involved. Maybe in 4-5 months I'll pull out of this wretched state I'm in now, and I'll spread my wings in dozens of directions then - for about a year, don't ask me how I know. (I haven't calculated out beyond 2017 yet.) But there's another issue too. Contrary to popular belief, just because spreadsheets are what you build on a rectangular grid of cells, not many advanced spreadsheet applications are straight-up tabular. Most beginners start out tabular (though I didn't, a couple decades ago), and it seems that most never get out of the tabular framework. I've been finding that namedtuples covers a good 90-95% of my "not exactly tabular" (and "not at all tabular") spreadsheet applications, and I'm quite curious to keep extending my knowledge about what you can do with namedtuples. And it probably would be surprising to some how much that is. It's mainly a few awkward corner cases, like grouping rows and taking columns n at a time that can really be tricky. (But I've done both now.) Eventually I plan to know several tools to convert spreadsheets to Python with, including numpy and pandas. But considering the "tabular" discipline both of those have, I doubt I'd be saving myself any grief by switching to them. Learning curves are a bitch in their own right, and I can think of worse ways to spend a few broken months than getting to know one way really well. It's my fallback position when things get bad, to just stick with what I don't have to learn too much about and find out what I can do with it. You'd be surprised! Deborah -- https://mail.python.org/mailman/listinfo/python-list
Re: Survey: improving the Python std lib docs
On Friday, May 12, 2017 at 6:02:58 AM UTC-4, Steve D'Aprano wrote: > One of the more controversial aspects of the Python ecosystem is the Python > docs. Some people love them, and some people hate them and describe them as > horrible. > I have a number of ideas for improving the docs, but I think there is a larger issue that needs to be addressed first: there is no BDFL for the docs. They are written and maintained piecemeal, by the core dev that wrote the code. If one documentation-focused person had decision-making power over all the docs, then we might be able to get some consistency throughout. As it is, if I make a suggestion about the itertools docs (why do we need 20-line "equivalent to" Python code, and why don't we have any usage examples?), then I have to debate it with the developer of itertools, who has a different aesthetic and style than the developer of logging, or email, or re, and so on. If we had one person who had the authority to make doc-wide decisions, then we might be able to move towards coherent guidelines for the docs to be more uniform. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Wichtig für Maximus
https://www.heise.de/newsticker/meldung/WannaCry-Microsoft-liefert-Sicherheits-Patches-fuer-veraltete-Windows-Versionen-3713417.html -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On Mon, May 15, 2017 at 6:37 AM, Deborah Swanson wrote: > > Where did you find recordclass-0.4.3-cp34-cp34m-win32.whl? There > weren't any win32 builds on https://pypi.python.org/pypi/recordclass. It's in the middle of the file list: recordclass-0.4.3-cp34-cp34m-win32.whl (md5) Python Wheel cp34 2017-04-17 17KB Maybe you're looking at a cached page in your browser? But that doesn't explain why pip doesn't see it. > Maybe I can find an earlier 3 build that won't demand Visual C++. The wheel doesn't need a compiler. It has an ABI tag because it already includes the compiled extension module. -- https://mail.python.org/mailman/listinfo/python-list
Re: Rosetta: Zebra puzzle (2.)
On Sun, 14 May 2017 12:53:15 -0700, breamoreboy wrote:
> On Sunday, May 14, 2017 at 2:44:33 AM UTC+1, Steve D'Aprano wrote:
>> On Sun, 14 May 2017 07:03 am, Jan van den Broek wrote:
>>
>> > On 2017-05-13, Robert L. wrote:
>> >
>> > [Schnipp]
>> >
>> >> def build_permutations things
>> >> if block_given?
>> >> things.permutation.select{|x| yield x}
>> >> else
>> >> things.permutation.to_a
>> >> end
>> >> end
>> >
>> > I fail to recognize the Python-version.
>>
>> That is because it isn't Python, it is Ruby.
>>
>> Ironically given Robert's "No_spamming" fake email address, he is a
>> spammer.
>> He is posting Ruby code to the Python list as an excuse for sending his
>> vile, anti-Semitic and racist quotes. (Half of them are lies, the other
>> half are out-of-context half-truths.)
>>
>> And the coward doesn't even have the courage to stand behind his
>> convictions: he doesn't even use his full name.
>>
>> "Robert L" No_Spamming@fake-address thinks he is spreading his message
>> of White Power, but all he is doing is showing what a cowardly,
>> hypocritical, dumb-arse spammer he is.
>
> I report all of his posts on gg as hateful or violent content. What do
> you expect of the extreme right wing, honesty? In the UK we've been
> conned into leaving the EU in an advisory referendum that has been
> described by a Professor who specialises in EU law as won by using
> "dishonesty on an industrial scale".
But mostly by the remain side of the fence!
>
>> --
>> Steve Emoji: a small, fuzzy, indistinct picture used to replace a clear
>> and perfectly comprehensible word.
>
> Kindest regards.
>
> Mark Lawrence.
--
Rule a nation with justice.
Wage war with surprise moves.
Become master of the universe without striving.
How do I know that this is so?
Because of this!
The more laws and restrictions there are,
The poorer people become.
The sharper men's weapons,
The more trouble in the land.
The more ingenious and clever men are,
The more strange things happen.
The more rules and regulations,
The more thieves and robbers.
Therefore the sage says:
I take no action and people are reformed.
I enjoy peace and people become honest.
I do nothing and people become rich.
I have no desires and people return to the good and simple life.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Rosetta: Zebra puzzle (2.)
On Sunday, May 14, 2017 at 12:53:41 PM UTC-7, bream...@gmail.com wrote: > I report all of his posts on gg as hateful or violent content. I have been doing the same. Google, are you listening? -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
eryk sun wrote, on Monday, May 15, 2017 5:52 AM
>
> On Mon, May 15, 2017 at 6:37 AM, Deborah Swanson
> wrote:
> >
> > Where did you find recordclass-0.4.3-cp34-cp34m-win32.whl? There
> > weren't any win32 builds on
> https://pypi.python.org/pypi/recordclass.
>
> It's in the middle
> of the file list:
>
>recordclass-0.4.3-cp34-cp34m-win32.whl (md5) Python Wheel
> cp34 2017-04-17 17KB
Actually, I see now there are several win32.whl files on that page. I'm
not familiar with PyPi's link formatting and I didn't realize that both
the wheel and md5 files were available from each of those links, and I
only clicked on the md5s. (Truth be told I didn't even see the .whls. It
was late, and though I could read and write, I was a little bleary
around the edges.)
> Maybe you're looking at a cached page in your browser? But
> that doesn't explain why pip doesn't see it.
Actually, when I tried "pip install
recordclass-0.4.3-cp34-cp34m-win32.whl" it failed almost immediately
with:
"recordclass-0.4.3-cp34-cp34m-win32.whl is not a supported wheel on this
platform."
The one time I tried "pip install recordclass", it found
0.4.3-cp34-cp34m-win32 alright. It got as far as copying, building and
testing it, but failed in test:
Installing collected packages: recordclass
Running setup.py install for recordclass
Complete output from command C:\Programs\Coding\Anaconda3\python.exe
-c "imp
ort setuptools,
tokenize;__file__='E:\\temp\\pip-build-zhximvpd\\recordclass\\se
tup.py';exec(compile(getattr(tokenize, 'open',
open)(__file__).read().replace('\ r\n', '\n'), __file__, 'exec'))"
install --record E:\temp\pip-r7ky4fv1-record\in stall-record.txt
--single-version-externally-managed --compile:
running install
running build
running build_py
creating build
creating build\lib.win32-3.4
creating build\lib.win32-3.4\recordclass
copying lib\recordclass\record.py -> build\lib.win32-3.4\recordclass
copying lib\recordclass\__init__.py ->
build\lib.win32-3.4\recordclass
creating build\lib.win32-3.4\recordclass\test
copying lib\recordclass\test\test_memoryslots.py ->
build\lib.win32-3.4\reco rdclass\test
copying lib\recordclass\test\test_record.py ->
build\lib.win32-3.4\recordcla ss\test
copying lib\recordclass\test\__init__.py ->
build\lib.win32-3.4\recordclass\ test
running build_ext
building 'recordclass.memoryslots' extension
error: Microsoft Visual C++ 10.0 is required (Unable to find
vcvarsall.bat).
So it choked when it needed Visual C++ to test the installation, at
least that's what I'm assuming it was testing.
It continues to amaze me that Anaconda and Python.org, probably the two
biggest distributors of official Python builds, are now relying on
Visual C++. Why can't Python developers write the entire setup and
installation code in Python? Surely Python has the required
functionality, and it seems more than a little demeaning for Python to
be using Visual C++ as a crutch.
Relatedly, why is Python lacking in the basic build tools for users to
easily build and install packages and full releases from source?
Something for Python (loosely) akin to the earliest versions of Visual
Studio would do the job, and it wouldn't have to be real tricked out.
I've seen this lack show up in several threads on this list, including
my original question in this thread. I was fishing for hints about the
build tools in Python as a way to build recordclass from source, but
apparently there aren't any. Not that advanced users know about anyway.
Is the Python dev team so lacking in resources that they can't cover
this fundamental base? Microsoft had build teams in dev at least as
early as the first release of Windows NT, and probably much earlier. I'd
always assumed that major language developers would establish build and
installation teams very early on. Alhough, Microsoft's setup teams still
really sucked bananas as late as when the the first XP was released in
2001 (don't know anything about them since), but the build teams were
rock stars that everyone looked up to from the get go. Apparently Python
hasn't mirrored that sequence of development steps.
> > Maybe I can find an earlier 3 build that won't demand Visual C++.
>
> The wheel doesn't need a compiler. It has an ABI tag because
> it already includes the compiled extension module.
Ah, and you've got me there. I have no clue what an ABI tag is or why
it's significant, and I don't know a fraction enough about wheels to
know whether they'd use a compiler or not. Grist for the mill, so
thanks.
Deborah
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On Tue, May 16, 2017 at 4:12 AM, Deborah Swanson wrote: > It continues to amaze me that Anaconda and Python.org, probably the two > biggest distributors of official Python builds, are now relying on > Visual C++. Why can't Python developers write the entire setup and > installation code in Python? Surely Python has the required > functionality, and it seems more than a little demeaning for Python to > be using Visual C++ as a crutch. Are you suggesting that a C compiler should be written in Python? Because you're dealing with an extension library. It's not written in pure Python. That's why it needs a C compiler. While it is certainly possible to write a C compiler in Python, it is unlikely to outperform the existing popular compilers (gcc, clang, msvc, etc), which have had many years of expertise poured into them. None of this applies if you are actually depending on a pure Python module, which *can* be installed without a C compiler. Visual C++ is not a crutch but a critical part of the build process. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Rosetta: Zebra puzzle (2.)
On 2017-05-15, jlada...@itu.edu wrote: > On Sunday, May 14, 2017 at 12:53:41 PM UTC-7, bream...@gmail.com wrote: > >> I report all of his posts on gg as hateful or violent content. > > I have been doing the same. Google, are you listening? Google hates Usenet. -- Jan v/d Broek balgl...@dds.nl -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On 2017-05-15 13:52, eryk sun wrote: On Mon, May 15, 2017 at 6:37 AM, Deborah Swanson wrote: Where did you find recordclass-0.4.3-cp34-cp34m-win32.whl? There weren't any win32 builds on https://pypi.python.org/pypi/recordclass. It's in the middle of the file list: recordclass-0.4.3-cp34-cp34m-win32.whl (md5) Python Wheel cp34 2017-04-17 17KB Maybe you're looking at a cached page in your browser? But that doesn't explain why pip doesn't see it. Maybe I can find an earlier 3 build that won't demand Visual C++. The wheel doesn't need a compiler. It has an ABI tag because it already includes the compiled extension module. I used pip to install into Python 3.4 (32-bit) from PyPI. It fetched "recordclass-0.4.3.tar.gz" and compiled it instead of fetching "recordclass-0.4.3-cp34-cp34m-win32.whl". Why? Come to think of it, what's that "cp34m" in the name? I don't have that in the regex module's wheels, I have "none" instead. Rename "recordclass-0.4.3-cp34-cp34m-win32.whl" to "recordclass-0.4.3-cp34-name-win32.whl". With the new name, it installs and seems to work! -- https://mail.python.org/mailman/listinfo/python-list
getting the center of mass of each part of a molecule
Hi,
I need to get the center of mass (COM) of each half of the ligand shown in the
figure (https://i.stack.imgur.com/dtdul.png). I get the main COM all the
ligand, lets say it is close to C1 atom. In addition to the main COM of all the
ligand, I need to find the COM of each half of the ligand. The atoms of the
first part/half according to the main COM of the ligand are C2, C7, C8 and C9.
As for the second part they are C3, C4, C5 and C6 atoms. The question is how
can I divide the ligand in two parts according to the main COM and calculate
the COM of each divided part (except for the atom closest to the main COM, C1)?
By the way I have multiple ligands. The code should be user firendly.
A short part of the input file is here:
1LIG C11 4.434 5.366 1.780
1LIG C22 4.317 5.301 1.940
1LIG C33 4.430 5.286 1.888
1LIG C44 4.380 4.942 2.467
1LIG C55 4.148 4.929 2.443
A short snippet of the code used to get the main COM is here:
def heavy_atoms(atoms, xyz, ligand="LIG"):
ids = np.arange(len(atoms))
names = [(i[10:15].strip(),i[5:10].strip()) for i,j in atoms]
# Ligand atoms
lig_atoms = np.array([ rname == ligand and not aname.startswith('H') for
aname,rname in names ])
lig_xyz = xyz[lig_atoms,:]
# The main COM
lig_com = xyz[lig_atoms, :].mean(axis=0)
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On Mon, May 15, 2017 at 7:43 PM, MRAB wrote: > On 2017-05-15 13:52, eryk sun wrote: >> >> The wheel doesn't need a compiler. It has an ABI tag because it >> already includes the compiled extension module. >> > I used pip to install into Python 3.4 (32-bit) from PyPI. It fetched > "recordclass-0.4.3.tar.gz" and compiled it instead of fetching > "recordclass-0.4.3-cp34-cp34m-win32.whl". I suspect you're using pip version 7.1. Update to version 9: python -m pip install --upgrade pip > Come to think of it, what's that "cp34m" in the name? I don't have that in > the regex module's wheels, I have "none" instead. "recordclass-0.4.3-cp34-cp34m-win32" is broken down as follows [1]: Distribution: recordclass Version: 0.4.3 Python: cp34 [CPython 3.4] ABI: cp34m [CPython 3.4 w/ PyMalloc] Platform: win32 [32-bit Windows] Extension modules have to be built for a particular implementation of Python, ABI, and platform. [1]: https://www.python.org/dev/peps/pep-0491/#file-format -- https://mail.python.org/mailman/listinfo/python-list
Re: getting the center of mass of each part of a molecule
On 05/15/2017 01:29 PM, qasimp...@gmail.com wrote:
Hi,
I need to get the center of mass (COM) of each half of the ligand shown in the
figure (https://i.stack.imgur.com/dtdul.png). I get the main COM all the
ligand, lets say it is close to C1 atom. In addition to the main COM of all the
ligand, I need to find the COM of each half of the ligand. The atoms of the
first part/half according to the main COM of the ligand are C2, C7, C8 and C9.
As for the second part they are C3, C4, C5 and C6 atoms. The question is how
can I divide the ligand in two parts according to the main COM and calculate
the COM of each divided part (except for the atom closest to the main COM, C1)?
By the way I have multiple ligands. The code should be user firendly.
A short part of the input file is here:
1LIG C11 4.434 5.366 1.780
1LIG C22 4.317 5.301 1.940
1LIG C33 4.430 5.286 1.888
1LIG C44 4.380 4.942 2.467
1LIG C55 4.148 4.929 2.443
A short snippet of the code used to get the main COM is here:
def heavy_atoms(atoms, xyz, ligand="LIG"):
ids = np.arange(len(atoms))
names = [(i[10:15].strip(),i[5:10].strip()) for i,j in atoms]
# Ligand atoms
lig_atoms = np.array([ rname == ligand and not aname.startswith('H') for
aname,rname in names ])
lig_xyz = xyz[lig_atoms,:]
# The main COM
lig_com = xyz[lig_atoms, :].mean(axis=0)
You seem to be asking a chemistry or biochemistry question on this
Python programming list. We're a diverse group, but still, that seems
to be a vast mismatch. Do you have any hint of an algorithm that will
do what you want? Can you find one somewhere, or define one yourself?
Once you have an algorithm, it would be appropriate to ask here for help
in translating it into a Python program.
Gary Herron
--
Dr. Gary Herron
Professor of Computer Science
DigiPen Institute of Technology
(425) 895-4418
--
https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Chris Angelico wrote, on Monday, May 15, 2017 11:22 AM > > On Tue, May 16, 2017 at 4:12 AM, Deborah Swanson > wrote: > > It continues to amaze me that Anaconda and Python.org, probably the > > two biggest distributors of official Python builds, are now relying on > > Visual C++. Why can't Python developers write the entire setup and > > installation code in Python? Surely Python has the required > > functionality, and it seems more than a little demeaning for Python to > > be using Visual C++ as a crutch. > > Are you suggesting that a C compiler should be written in > Python? Because you're dealing with an extension library. > It's not written in pure Python. That's why it needs a C > compiler. While it is certainly possible to write a C > compiler in Python, it is unlikely to outperform the existing > popular compilers (gcc, clang, msvc, etc), which have had > many years of expertise poured into them. I don't know much about extensions yet, but I think I can see what you're saying. It probably is a shortcut for volunteer developers to use existing C/C++ code where they can, rather than writing all of it from scratch in Python. But I'm a little more mystified that official Python builds are leaning on Visual C++ (and that's what the crutch comment was primarily aimed at). Perhaps they're just as resource needy as the extension developers are and new requirements have come up as Python 3 progresses that they don't already have Python build and installation tools written and tested for. I'd be willing to step into that void when my Python skills are equal to the task (and my health permitting, of course). But that would be years from now, and maybe someone else will step up before then. I'm really thinking that build has languished far behind the rest of the language's development for way too long. > None of this applies if you are actually depending on a pure > Python module, which *can* be installed without a C compiler. > Visual C++ is not a crutch but a critical part of the build process. > > ChrisA I'll still think of it as a crutch for official Python builds, but I can see your point for extension developers. Maybe I have more pride in the Python language than is right and proper, but I do think it would be worth the relatively small investment to make and start growing Python's own build and installation tools asap. Python will be the reigning Queen of coding languages someday. Certainly seems like she should have all her own working parts and be beholden to no one. ;) Microsoft saw the need for build and installation teams very early on, and now everyone depends on what they made. And yes, Windows and all Microsoft software from thence forward was primarily made with C/C++, because MSDOS was appallingly incapable of meeting the challenge and that's all they had before Windows. Python has a lot more than MSDOS ever dreamed of, and that's what seems demeaning to me that Python is piggybacking on a lesser language, because their need to do so is so infinitesimally less than Microsoft's need was to move on from MSDOS. And I think the day is coming that Microsoft will be too much of a dinosaur (like IBM has become) to continue meeting the needs of evolving languages. Better to get going on our own tools, the sooner the better, in my opinion. Deborah -- https://mail.python.org/mailman/listinfo/python-list
Re: getting the center of mass of each part of a molecule
The last line of your function already calculates a center of mass for all atoms. How can you separate out that calculation into its own (one-line) function? How can you send just a subset of your data to that new function? -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
Deborah, I get the feeling you don't understand the architecture/implementation of Python. The (C)Python interpreter is written in C. A number of the built-in modules are least partially written in C. As such, C is a natural integration point for extensions. Many, many third-party extensions are written completely or partially in C or C++. If you're going to install Python or these modules from source, you need a C or C++ compiler. On Windows, this tends to be MSVC. On Linux, GCC or clang. On OS X, clang. You may consider C & C++ to be lesser languages, but Python's built upon those "lesser" languages. Personally, I love both C++ & Python. You need to know when to use the write tool for the job (hammer vs screwdriver). Comparing Python to MSDOS is comparing apples to oranges. MSDOS is not a language. It is an operating system (albeit a bare-bones, single-user one). Regards, Nathan On Mon, May 15, 2017 at 4:01 PM, Deborah Swanson wrote: > Chris Angelico wrote, on Monday, May 15, 2017 11:22 AM > > > > On Tue, May 16, 2017 at 4:12 AM, Deborah Swanson > > wrote: > > > It continues to amaze me that Anaconda and Python.org, probably the > > > two biggest distributors of official Python builds, are now relying > on > > > Visual C++. Why can't Python developers write the entire setup and > > > installation code in Python? Surely Python has the required > > > functionality, and it seems more than a little demeaning for Python > to > > > be using Visual C++ as a crutch. > > > > Are you suggesting that a C compiler should be written in > > Python? Because you're dealing with an extension library. > > It's not written in pure Python. That's why it needs a C > > compiler. While it is certainly possible to write a C > > compiler in Python, it is unlikely to outperform the existing > > popular compilers (gcc, clang, msvc, etc), which have had > > many years of expertise poured into them. > > I don't know much about extensions yet, but I think I can see what > you're saying. It probably is a shortcut for volunteer developers to use > existing C/C++ code where they can, rather than writing all of it from > scratch in Python. > > But I'm a little more mystified that official Python builds are leaning > on Visual C++ (and that's what the crutch comment was primarily aimed > at). Perhaps they're just as resource needy as the extension developers > are and new requirements have come up as Python 3 progresses that they > don't already have Python build and installation tools written and > tested for. I'd be willing to step into that void when my Python skills > are equal to the task (and my health permitting, of course). But that > would be years from now, and maybe someone else will step up before > then. I'm really thinking that build has languished far behind the rest > of the language's development for way too long. > > > None of this applies if you are actually depending on a pure > > Python module, which *can* be installed without a C compiler. > > Visual C++ is not a crutch but a critical part of the build process. > > > > ChrisA > > I'll still think of it as a crutch for official Python builds, but I can > see your point for extension developers. > > Maybe I have more pride in the Python language than is right and proper, > but I do think it would be worth the relatively small investment to make > and start growing Python's own build and installation tools asap. Python > will be the reigning Queen of coding languages someday. Certainly seems > like she should have all her own working parts and be beholden to no > one. ;) > > Microsoft saw the need for build and installation teams very early on, > and now everyone depends on what they made. > > And yes, Windows and all Microsoft software from thence forward was > primarily made with C/C++, because MSDOS was appallingly incapable of > meeting the challenge and that's all they had before Windows. > > Python has a lot more than MSDOS ever dreamed of, and that's what seems > demeaning to me that Python is piggybacking on a lesser language, > because their need to do so is so infinitesimally less than Microsoft's > need was to move on from MSDOS. And I think the day is coming that > Microsoft will be too much of a dinosaur (like IBM has become) to > continue meeting the needs of evolving languages. Better to get going on > our own tools, the sooner the better, in my opinion. > > Deborah > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: getting the center of mass of each part of a molecule
@Gary: No, I don't have any algorithm. Well, I can define what I want: 1) The script will read the atom coordinates of the ligand from the input file sent in previous message. 2) It will calculate the center of mass (COM) for all the ligand atoms and find the ligand heavy atom closest to its COM. I already do these two steps but 3. and 4.steps 3) The script should be able to seperate ligand atoms into two equal parts according to the main COM (COM for all atoms). Consider that the the main COM is reference point. 4) It should find the COM each of both equal parts. -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
MRAB wrote, on Monday, May 15, 2017 12:44 PM > > On 2017-05-15 13:52, eryk sun wrote: > > On Mon, May 15, 2017 at 6:37 AM, Deborah Swanson > > wrote: > >> > >> Where did you find recordclass-0.4.3-cp34-cp34m-win32.whl? There > >> weren't any win32 builds on > https://pypi.python.org/pypi/recordclass. > > > > It's in the > middle of the file list: > > > > recordclass-0.4.3-cp34-cp34m-win32.whl (md5) Python Wheel cp34 > > 2017-04-17 17KB > > > > Maybe you're looking at a cached page in your browser? But that > > doesn't explain why pip doesn't see it. > > > >> Maybe I can find an earlier 3 build that won't demand Visual C++. > > > > The wheel doesn't need a compiler. It has an ABI tag because it > > already includes the compiled extension module. > > > I used pip to install into Python 3.4 (32-bit) from PyPI. It fetched > "recordclass-0.4.3.tar.gz" and compiled it instead of fetching > "recordclass-0.4.3-cp34-cp34m-win32.whl". > > Why? Excellent question, though I have no clue what the answer is. > Come to think of it, what's that "cp34m" in the name? I don't have that > in the regex module's wheels, I have "none" instead. Another excellent question. "cp" in "cp34m" might stand for C++, but if so, what's the rest of it mean? Or maybe "CPython 3.4" plus "m" (whatever "m" stands for)? What's "the regex module's wheels"? I certainly don't know, though I know vague outines of what "regex" and "wheel" are. > Rename "recordclass-0.4.3-cp34-cp34m-win32.whl" to > "recordclass-0.4.3-cp34-name-win32.whl". > > With the new name, it installs and seems to work! Most excellent and I will try it. As a mutable alternative to namedtuples, recordclass certainly seems worth the detour to look at and try, if I can get it to install! All of the hairy points I've run into with namedtuples revolve around their immutability. Getattr works and solves some of them, but it's helpless and breaks with the "object has no attribute xxx" in others. So a mutable version of namedtuple functionality would be extremely useful indeed. I'll also take a look at the contents of "recordclass-0.4.3.tar.gz" to see what I can see. Maybe not much though. I'm real ignorant of how extensions are made, but I might see something worth seeing. Deborah -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On Tue, May 16, 2017 at 7:01 AM, Deborah Swanson wrote: > But I'm a little more mystified that official Python builds are leaning > on Visual C++ (and that's what the crutch comment was primarily aimed > at). Perhaps they're just as resource needy as the extension developers > are and new requirements have come up as Python 3 progresses that they > don't already have Python build and installation tools written and > tested for. I'd be willing to step into that void when my Python skills > are equal to the task (and my health permitting, of course). But that > would be years from now, and maybe someone else will step up before > then. I'm really thinking that build has languished far behind the rest > of the language's development for way too long. > > > Maybe I have more pride in the Python language than is right and proper, > but I do think it would be worth the relatively small investment to make > and start growing Python's own build and installation tools asap. Python > will be the reigning Queen of coding languages someday. Certainly seems > like she should have all her own working parts and be beholden to no > one. ;) You seem to be of the opinion that some day, binary executables will be compiled using pure Python code. Maybe that's true; maybe it's not. The point is, though, that high performance binaries can't be created without a LOT of expertise relating to the OS, the standard library, the CPU architecture, etc, etc, etc. That expertise has been coalesced into existing C compilers (I mentioned gcc, clang, and msvc earlier; others also exist but those are the most popular), and throwing that out means having a subpar Python. Perhaps a future version of gcc will be implemented in Python. Would you then say that Python is beholden to no one? You would still need to have a C compiler installed in order to compile extension modules. It's too big to include with every single Python installation. So you'd have the same situation even then. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Embedded Python import fails with zip/egg files (v3.6.1)
Thanks eryk! It looks like I have to dig deeper and step through the Python code again to see what's going on. On 11.05.2017 15:37, eryk sun wrote: On Thu, May 11, 2017 at 9:02 PM, Griebel, Herbert wrote: 07:59:04,3205458python.exe4224CreateFile C:\Users\hansi\Downloads\python-emb\python36.zipSUCCESS Desired Access: Read Attributes, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Open Reparse Point, Attributes: N, ShareMode: None, AllocationSize: n/a, OpenResult: Opened 07:59:04,3205860python.exe4224 QueryInformationVolume C:\Users\hansi\Downloads\python-emb\python36.zipSUCCESS VolumeCreationTime: 05.05.2015 12:28:45, VolumeSerialNumber: 36B5-A026, SupportsObjects: True, VolumeLabel: OS 07:59:04,3206127python.exe4224 QueryAllInformationFile C:\Users\hansi\Downloads\python-emb\python36.zipBUFFER OVERFLOW CreationTime: 18.04.2017 06:07:23, LastAccessTime: 18.04.2017 06:07:23, LastWriteTime: 21.03.2017 09:06:10, ChangeTime: 18.04.2017 06:07:23, FileAttributes: N, AllocationSize: 2.228.224, EndOfFile: 2.224.303, NumberOfLinks: 1, DeletePending: False, Directory: False, IndexNumber: 0x2000a9467, EaSize: 0, Access: Read Attributes, Synchronize, Position: 0, Mode: Synchronous IO Non-Alert, AlignmentRequirement: Word This looks like a regular Python stat call on Windows. It opens a handle without following links (i.e. reparse points) and calls GetFileInformationByHandle. That in turn gets the volume serial number from the volume information. Then it gets the file information, which includes the filename. But the FILE_ALL_INFORMATION buffer only has space for a single character of the name. That's the reason for the buffer overflow (0x8005). It's an NTSTATUS warning, not an error, and it doesn't fail the GetFileInformationByHandle call. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On 5/15/17, Chris Angelico wrote: > Perhaps a future version of gcc will be implemented in Python. Would > you then say that Python is beholden to no one? You would still need > to have a C compiler installed in order to compile extension modules. > It's too big to include with every single Python installation. So > you'd have the same situation even then. Don't forget that 640 kB was too big too! ;) (and compiler as service is also possibility) PL. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On Tue, May 16, 2017 at 8:50 AM, Pavol Lisy wrote: > On 5/15/17, Chris Angelico wrote: > >> Perhaps a future version of gcc will be implemented in Python. Would >> you then say that Python is beholden to no one? You would still need >> to have a C compiler installed in order to compile extension modules. >> It's too big to include with every single Python installation. So >> you'd have the same situation even then. > > Don't forget that 640 kB was too big too! ;) > > (and compiler as service is also possibility) Compiler As A Service is actually a very real possibility, and one that's been explored at times. But it's more of a packaging question than anything else; it's a means of simplifying the work of producing those wheel files. Once the wheels are built, anyone can already install them without a compiler (of course, you have to trust the wheel builder, since you're now installing a binary blob on your computer). There's not a lot of point having end users use CaaS; if you're making custom software or an unusual system, it's easier to get your own compiler than to match a host somewhere, and if you're using something completely standard, there's no need to reinvent - or rebuild - the wheel. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: getting the center of mass of each part of a molecule
On 15May2017 13:29, qasimp...@gmail.com wrote:
I need to get the center of mass (COM) of each half of the ligand shown in the
figure (https://i.stack.imgur.com/dtdul.png). I get the main COM all the
ligand, lets say it is close to C1 atom. In addition to the main COM of all
the ligand, I need to find the COM of each half of the ligand. The atoms of
the first part/half according to the main COM of the ligand are C2, C7, C8 and
C9. As for the second part they are C3, C4, C5 and C6 atoms. The question is
how can I divide the ligand in two parts according to the main COM and
calculate the COM of each divided part (except for the atom closest to the
main COM, C1)? By the way I have multiple ligands. The code should be user
firendly.
Leaving aside that you are using numpy arrays, if sources like you need to
partition an existing array into 2 parts around the dividing element (C1).
Figure out how to find the position of C1 in the array. If your atoms are
unique in the sense that C1 != C2 even if they are both carbon atoms) you could
use the .index method of a list (hoping numpy array support that). But
otherwise, loop over the array until you find the element C1 and return the
index. Write a short function for this purpose, eg (incomplete):
def find_atom(atom, atoms):
for i, a in enumerate(atoms):
if a is the target atom "atom":
return i
raise IndexError("no such atom")
Then all you need to do is:
- figure out _which_ atom is your "C1"
- locate it in the main array of atoms
- extract the left and half subarrays
For the last part, remember that to get a sublist you can write L[a:b] to get
all the elements of L from a up to but excluding b. And that omitting "a"
implies index 0 and omitting "b" implies len(L).
The homework suggestion that the "code should be user firendly" I would take to
imply that the last step should itself be a function, eg:
def partition_atoms(atom, atoms):
which takes your target atom (C1) and the original array, calls find_atom to
locate C1, and returns the left and right sublists.
Cheers,
Cameron Simpson
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On 2017-05-15 21:40, eryk sun wrote: On Mon, May 15, 2017 at 7:43 PM, MRAB wrote: > On 2017-05-15 13:52, eryk sun wrote: >> >> The wheel doesn't need a compiler. It has an ABI tag because it >> already includes the compiled extension module. >> > I used pip to install into Python 3.4 (32-bit) from PyPI. It fetched > "recordclass-0.4.3.tar.gz" and compiled it instead of fetching > "recordclass-0.4.3-cp34-cp34m-win32.whl". I suspect you're using pip version 7.1. Update to version 9: python -m pip install --upgrade pip > Come to think of it, what's that "cp34m" in the name? I don't have that in > the regex module's wheels, I have "none" instead. "recordclass-0.4.3-cp34-cp34m-win32" is broken down as follows [1]: Distribution: recordclass Version: 0.4.3 Python: cp34 [CPython 3.4] ABI: cp34m [CPython 3.4 w/ PyMalloc] Platform: win32 [32-bit Windows] Extension modules have to be built for a particular implementation of Python, ABI, and platform. [1]: https://www.python.org/dev/peps/pep-0491/#file-format I hadn't updated the pip for CPython 3.4 from the version it was originally shipped with. Once upgraded, the wheel installed from PyPI without a problem. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
Deborah Swanson wrote: It continues to amaze me that Anaconda and Python.org, probably the two biggest distributors of official Python builds, are now relying on Visual C++. Why can't Python developers write the entire setup and installation code in Python? The setup and installation code *is* written in Python. It's just that some of the source of the particular package you're trying to install is written in C, so installing it *from source* necessarily requires a C compiler. Most people's Windows machines aren't set up for compiling C code, and for that reason, prebuilt versions of such packages are usually supplied for Windows. So you have two reasonable options: 1) Find a prebuilt wheel that's compatible with your system. 2) Find another package written in pure Python that does what you want. It's also possible that you don't need the parts of recordclass that are written in C. If that's the case you might be able to install the pure Python parts manually. That's usually just a matter of dropping the .py files in appropriate places. Relatedly, why is Python lacking in the basic build tools for users to easily build and install packages and full releases from source? Something for Python (loosely) akin to the earliest versions of Visual Studio would do the job, Having the Python ecosystem stuck on some ancient version of Visual Studio would be a bad situation for many reasons. One of the main uses of C extensions is to interface with external libraries, which will most likely have been compiled with a recent toolset and rely on recent versions of Microsoft's runtime libraries. There's also the fact that Microsoft doesn't make the free versions of Visual Studio available forever and forbids anyone else distributing them, so sufficiently old versions are simply not available to most people. The alternative would be to use some other free compiler such as MinGW as the standard compiler for Python and its extensions. But this has been decided against on the grounds that it is better to use the standard Windows tools to compile code for Windows, for the same compatibility reasons as above, and that means Visual Studio. Ah, and you've got me there. I have no clue what an ABI tag is or why it's significant, ABI = Application Binary Interface. Essentially it's the interface between the Python interpreter and code that's been compiled from C, and it can change from one version of Python to another. The error message from pip could be more useful -- it would be nice to know exactly *what* it is about the wheel that doesn't match your system! Some things it could be: * Wrong version of Python * Wrong CPU architecture (32 vs 64 bit) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Nathan Ernst wrote, on Monday, May 15, 2017 2:14 PM Deborah, I get the feeling you don't understand the architecture/implementation of Python. The (C)Python interpreter is written in C. A number of the built-in modules are least partially written in C. As such, C is a natural integration point for extensions. Many, many third-party extensions are written completely or partially in C or C++. If you're going to install Python or these modules from source, you need a C or C++ compiler. On Windows, this tends to be MSVC. On Linux, GCC or clang. On OS X, clang. > You would be right, it has never occurred to me that built-in modules to the > language would be partially written in C. I'll plan to have a C compiler > asap, but it probably won't be until I'm up and running on Linux again. You may consider C & C++ to be lesser languages, but Python's built upon those "lesser" languages. Personally, I love both C++ & Python. You need to know when to use the write tool for the job (hammer vs screwdriver). > That may well be, and probably I should tone down my snark about C/C++. This > is why it's good to talk to people about these thoughts that might be > running amok and undetected inside your own head. That happens all too > easily when you spend years reading and studying alone, so thanks, and I'll > be looking more closely at C/C++ and it's role today. Comparing Python to MSDOS is comparing apples to oranges. MSDOS is not a language. It is an operating system (albeit a bare-bones, single-user one). Regards, Nathan On Mon, May 15, 2017 at 4:01 PM, Deborah Swanson wrote: Chris Angelico wrote, on Monday, May 15, 2017 11:22 AM > > On Tue, May 16, 2017 at 4:12 AM, Deborah Swanson > wrote: > > It continues to amaze me that Anaconda and Python.org, probably the > > two biggest distributors of official Python builds, are now relying on > > Visual C++. Why can't Python developers write the entire setup and > > installation code in Python? Surely Python has the required > > functionality, and it seems more than a little demeaning for Python to > > be using Visual C++ as a crutch. > > Are you suggesting that a C compiler should be written in > Python? Because you're dealing with an extension library. > It's not written in pure Python. That's why it needs a C > compiler. While it is certainly possible to write a C > compiler in Python, it is unlikely to outperform the existing > popular compilers (gcc, clang, msvc, etc), which have had > many years of expertise poured into them. I don't know much about extensions yet, but I think I can see what you're saying. It probably is a shortcut for volunteer developers to use existing C/C++ code where they can, rather than writing all of it from scratch in Python. But I'm a little more mystified that official Python builds are leaning on Visual C++ (and that's what the crutch comment was primarily aimed at). Perhaps they're just as resource needy as the extension developers are and new requirements have come up as Python 3 progresses that they don't already have Python build and installation tools written and tested for. I'd be willing to step into that void when my Python skills are equal to the task (and my health permitting, of course). But that would be years from now, and maybe someone else will step up before then. I'm really thinking that build has languished far behind the rest of the language's development for way too long. > None of this applies if you are actually depending on a pure > Python module, which *can* be installed without a C compiler. > Visual C++ is not a crutch but a critical part of the build process. > > ChrisA I'll still think of it as a crutch for official Python builds, but I can see your point for extension developers. Maybe I have more pride in the Python language than is right and proper, but I do think it would be worth the relatively small investment to make and start growing Python's own build and installation tools asap. Python will be the reigning Queen of coding languages someday. Certainly seems like she should have all her own working parts and be beholden to no one. ;) Microsoft saw the need for build and installation teams very early on, and now everyone depends on what they made. And yes, Windows and all Microsoft software from thence forward was primarily made with C/C++, because MSDOS was appallingly incapable of meeting the challenge and that's all they had before Windows. Python has a lot more than MSDOS ever dreamed of, and that's what seems demeaning to me that Python is piggybacking on a lesser language, because their need to do so is so infinitesimally less than Microsoft's need was to move on from MSDOS. And I think the day is coming that Microsoft will be too much of a dinosaur (like IBM has become) to continue meeting the needs of evolving languages. Better to get going on our own tools, the sooner the better, in my opinion. Deborah -- https://mail.python.org/mailman/listinfo/python-list -- https://mai
Re: How to install Python package from source on Windows
On Tue, May 16, 2017 at 9:54 AM, Gregory Ewing wrote: > There's also the fact that Microsoft doesn't make the free > versions of Visual Studio available forever and forbids anyone > else distributing them, so sufficiently old versions are > simply not available to most people. Yes and no. The Python.org support policy is that Python X.Y will be supported on Windows Z if and only if Windows Z was supported by Microsoft as of when Python X.Y.0 was released. This means that, for instance, Python 3.3 supported Windows XP, but Python 3.7 won't. If you need a Win2K-compatible compiler, you're using a too-old version of Python, and nobody's going to support that. There is, however, one exception. Python 2.7 supports Windows XP, and a specific version of MSVC (I don't remember which off-hand) that is now unsupported by Microsoft. However, *specifically for Python extension developers*, Microsoft offers the zero-dollar version of that compiler still, and will for a decent while (again, I don't remember the specifics, but it's something comparable to Py2.7's own upstream support). So in general, "sufficiently old versions" should actually still be available. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Chris Angelico wrote, on Monday, May 15, 2017 2:58 PM > > On Tue, May 16, 2017 at 7:01 AM, Deborah Swanson > wrote: > > But I'm a little more mystified that official Python builds are > > leaning on Visual C++ (and that's what the crutch comment was > > primarily aimed at). Perhaps they're just as resource needy as the > > extension developers are and new requirements have come up as Python 3 > > progresses that they don't already have Python build and installation > > tools written and tested for. I'd be willing to step into that void > > when my Python skills are equal to the task (and my health permitting, > > of course). But that would be years from now, and maybe someone else > > will step up before then. I'm really thinking that build has > > languished far behind the rest of the language's development for way > > too long. > > > > > > Maybe I have more pride in the Python language than is right and > > proper, but I do think it would be worth the relatively small > > investment to make and start growing Python's own build and > > installation tools asap. Python will be the reigning Queen of coding > > languages someday. Certainly seems like she should have all her own > > working parts and be beholden to no one. ;) > > You seem to be of the opinion that some day, binary > executables will be compiled using pure Python code. Well, my naive opinion is that they should be. But it was just one message back that I learned some Python built-in modules are at least partially written in C. I didn't know that, nor did I know or suspect that installation files for official Python releases likely contained C compilers. This raises a lot of questions for me, though it probably would be better for me to read and think about them on my own before coming back here with anything. > Maybe > that's true; maybe it's not. The point is, though, that high > performance binaries can't be created without a LOT of > expertise relating to the OS, the standard library, the CPU > architecture, etc, etc, etc. That expertise has been > coalesced into existing C compilers (I mentioned gcc, clang, > and msvc earlier; others also exist but those are the most > popular), and throwing that out means having a subpar Python. I'll accept that, though I still don't quite understand the recent dependence on Visual C++, after Python has been building its releases with the tools you and others mention from the beginning until shortly after the first 3 build was released, and the requirement has been so much deeper since 3.4.3, that Python (apparently) can no longer use the Visual C++ compiler built into XP. These are just things I wonder about since these new requirements put a real crimp in what I'm currently able to do, and I wonder how they will change Linux too. Again, lots of stuff for me to pursue on my own here. > Perhaps a future version of gcc will be implemented in > Python. Would you then say that Python is beholden to no one? > You would still need to have a C compiler installed in order > to compile extension modules. It's too big to include with > every single Python installation. So you'd have the same > situation even then. > > ChrisA No, with what I've learned today, I certainly would agree that Python has its beholdens, and likely always will. The bright side is that Python at least doesn't appear to be unduly constrained in how it uses the C/C++ code it does. I just hope that it continues to be kept to a minimum, but I guess I'm just a stinking purist about some things. Just another pretty fantasy smashed. So it goes. It's definitely better to have broken fantasies to feel bad about having, and to know the truth. Deborah -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On Tue, May 16, 2017 at 11:19 AM, Deborah Swanson wrote: > Chris Angelico wrote, on Monday, May 15, 2017 2:58 PM >> You seem to be of the opinion that some day, binary >> executables will be compiled using pure Python code. > > Well, my naive opinion is that they should be. But it was just one > message back that I learned some Python built-in modules are at least > partially written in C. I didn't know that, nor did I know or suspect > that installation files for official Python releases likely contained C > compilers. This raises a lot of questions for me, though it probably > would be better for me to read and think about them on my own before > coming back here with anything. It is possible to build a compiler for Python in Python. (See: PyPy.) The most normal way to build extension libraries is with C, though, because that's what most lower-level libraries depend on. For example, suppose you want to build a GUI toolkit for Python, using the GTK library. You can't easily do that in Python (technically you *can*, using ctypes, but ctypes is itself implemented in C), so you'll end up writing a C extension library. > I'll accept that, though I still don't quite understand the recent > dependence on Visual C++, after Python has been building its releases > with the tools you and others mention from the beginning until shortly > after the first 3 build was released, and the requirement has been so > much deeper since 3.4.3, that Python (apparently) can no longer use the > Visual C++ compiler built into XP. These are just things I wonder about > since these new requirements put a real crimp in what I'm currently able > to do, and I wonder how they will change Linux too. Again, lots of stuff > for me to pursue on my own here. An installed Python does not itself depend on MSVC. It's only when you need to compile additional C code - another Python module that is implemented in C - and you can't pick up someone else's precompiled version. It's not a new requirement; although you could perhaps argue that pip's presence in the standard library has made this a lot more likely to come up, as previously, you wouldn't have been able to install this module *at all* without fiddling around manually. > No, with what I've learned today, I certainly would agree that Python > has its beholdens, and likely always will. The bright side is that > Python at least doesn't appear to be unduly constrained in how it uses > the C/C++ code it does. I just hope that it continues to be kept to a > minimum, but I guess I'm just a stinking purist about some things. Actually, I'm glad that most of Python's core is implemented in C, because it means my code runs faster :) It's all thoroughly unit-tested, and I'm happy with it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: How to install Python package from source on Windows
Gregory Ewing wrote, on Monday, May 15, 2017 4:55 PM > > Deborah Swanson wrote: > > It continues to amaze me that Anaconda and Python.org, probably the > > two biggest distributors of official Python builds, are now relying on > > Visual C++. Why can't Python developers write the entire setup and > > installation code in Python? > > The setup and installation code *is* written in Python. It's > just that some of the source of the particular package you're > trying to install is written in C, so installing it *from > source* necessarily requires a C compiler. > > Most people's Windows machines aren't set up for compiling C > code, and for that reason, prebuilt versions of such packages > are usually supplied for Windows. > > So you have two reasonable options: > > 1) Find a prebuilt wheel that's compatible with your system. > > 2) Find another package written in pure Python that does what > you want. > > It's also possible that you don't need the parts of > recordclass that are written in C. If that's the case you > might be able to install the pure Python parts manually. > That's usually just a matter of dropping the .py files in > appropriate places. That might end up being the best choice for me, although I'm not entirely sure what the appropriate places to drop the .py files are. Probably the Scripts directory is one of them, but I don't know which files go there and which files go other places, and I definitely don't know what those other places are. However, I think MRAB's success in pip installing recordclass after upgrading pip might make workarounds unnecessary for me. I also haven't upgraded pip since I last installed Python, and I did see a nag notice that I should upgrade it. So that seems like the next step. > > Relatedly, why is Python lacking in the basic build tools for users to > > easily build and install packages and full releases from source? > > Something for Python (loosely) akin to the earliest versions of Visual > > Studio would do the job, > > Having the Python ecosystem stuck on some ancient version of > Visual Studio would be a bad situation for many reasons. Oh, and I was never thinking that should be done, that's why I said "loosely akin to". Just something along those lines, updated for Python and current realities, not the genuine original in the flesh! My point then was to develop purely Python tools to do the job we're leaning on Visual Studio to do, but I've learned in the last few messages why that might be more complicated than I originally thought it would be. > One > of the main uses of C extensions is to interface with > external libraries, which will most likely have been compiled > with a recent toolset and rely on recent versions of > Microsoft's runtime libraries. Another point I was unaware of, so thanks. > There's also the fact that Microsoft doesn't make the free > versions of Visual Studio available forever and forbids > anyone else distributing them, so sufficiently old versions > are simply not available to most people. Another reason why it's sad that Python hasn't been making its own build tools, or incorporating and developing open software tools all along. This is a tail that could easily end up wagging the dog, and soon. But likely there are stll many things I don't know or haven't fully understood from what I've learned today. > The alternative would be to use some other free compiler such > as MinGW as the standard compiler for Python and its > extensions. But this has been decided against on the grounds > that it is better to use the standard Windows tools to > compile code for Windows, for the same compatibility reasons > as above, and that means Visual Studio. Well, apparently that was the choice. I for one think it's sad, and that it will lead to trouble for Python somewhere down the road. Probably the trouble will be in its capacity to be available on all platforms, and I think it's sad to have such binding ties with newer Windows. Time will tell, but I think Windows is a slowly sinking ship, not unlike the eventual fate of the behemoth IBM. It's the way of all things, and Microsoft is no more immune to natural processes than anything else is. > > Ah, and you've got me there. I have no clue what an ABI tag is or why > > it's significant, > > ABI = Application Binary Interface. Essentially it's the > interface between the Python interpreter and code that's been > compiled from C, and it can change from one version of Python > to another. Thanks! Another mysterious acronym demystified! > The error message from pip could be more useful -- it would > be nice to know exactly *what* it is about the wheel that > doesn't match your system! Ahem, yes that would be most useful. > Some things it could be: > > * Wrong version of Python > > * Wrong CPU architecture (32 vs 64 bit) > > -- > Greg Or it could be any number of other things, since neither of those two are obviously the problem here.
Re: getting the center of mass of each part of a molecule
On Monday, May 15, 2017 at 1:30:05 PM UTC-7, qasi...@gmail.com wrote: > Hi, > > I need to get the center of mass (COM) of each half of the ligand shown in > the figure (https://i.stack.imgur.com/dtdul.png). I get the main COM all the > ligand, lets say it is close to C1 atom. ... I don't quite follow your terminology. A ligand is typically something that hangs onto something - usually a metal atom or some other larger molecule. It looks like you want the center of mass of the styrene molecule. Why not consider it as a benzene ring (C6H6) with the vinyl group (CH2CH) as a ligand? The benzene group will have its c.o.m. in the middle of the ring, by symmetry. Make this the origin. The vinyl group's c.o.m can be calculated by the methods given in http://hyperphysics.phy-astr.gsu.edu/hbase/cm.html Then you can find the c.o.m of the whole molecule by considering it as two masses in a specific geometry. This seems like the point of the exercise. What may make this tricky is that the vinyl group can rotate at the point where it attaches to the benzene ring so the full molecule may not lie in a plane. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On Tue, May 16, 2017 at 12:51 AM, Chris Angelico wrote: > > The Python.org support policy is that Python X.Y will be > supported on Windows Z if and only if Windows Z was supported by > Microsoft as of when Python X.Y.0 was released. Python 3.4 is the last to support XP (2014-04-08 EOL). Python 3.6 is the last to support Vista (2017-04-11 EOL). Estimates: Windows 7, 2020-01-14 EOL: Python 3.8 Windows 8, 2023-01-20 EOL: Python 3.10 Windows 10, 2025-10-14 EOL: Python 3.11 > There is, however, one exception. Python 2.7 supports Windows XP, The exception is 2.7's extended 10-year lifecycle (2010-2020). Given the ABI compatibility requirement to use an old, unsupported compiler, Python 2.7 is all but dead on Windows -- at least it should be. > a specific version of MSVC (I don't remember which off-hand) that is > now unsupported by Microsoft. Python 2.7 is built using the VS 2008 (VC++ 9.0) compiler toolset. This old compiler is required for compatibility with existing extension modules. Note that the main project files in PCbuild/ have been updated to VS 2010 format and require MSBuild from VS 2010 or newer (plus of course the VS 2008 compiler). However, the PC/VS9.0 project files are still supported if you only have VS 2008 installed. Getting VS 2008 requires an MSDN subscription. There is no free version available. > However, *specifically for Python extension developers*, Microsoft offers the > zero-dollar version of that compiler still, and will for a decent while > (again, I don't > remember the specifics, but it's something comparable to Py2.7's own > upstream support). That's VC++ Compiler for Python 2.7: https://www.microsoft.com/en-us/download/details.aspx?id=44266 Currently it can't build Python itself, but according to Steve Dower it's possible to configure it to work. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On 2017-05-16 02:19, Deborah Swanson wrote: [snip] I'll accept that, though I still don't quite understand the recent dependence on Visual C++, after Python has been building its releases with the tools you and others mention from the beginning until shortly after the first 3 build was released, and the requirement has been so much deeper since 3.4.3, that Python (apparently) can no longer use the Visual C++ compiler built into XP. These are just things I wonder about since these new requirements put a real crimp in what I'm currently able to do, and I wonder how they will change Linux too. Again, lots of stuff for me to pursue on my own here. CPython is being developed primarily on Linux. Linux and other Unix-like operating systems come with a C compiler as standard (the histories of Unix and C are closely linked). Windows, on the other hand, doesn't come with a C compiler. If you've ever wanted to write something in C on Windows, you've had to install a C compiler yourself. -- https://mail.python.org/mailman/listinfo/python-list
Re: Overriding methods on a per instance basis
There is another way to do it, but it's not pretty, and I don't recommend
it:
>>> class Foo:
... pass
...
>>> from functools import partial
>>> f = Foo()
>>> def hello(self, arg):
... print("hello", arg)
...
>>> f.hello = partial(hello, f)
>>> f.hello("world")
hello world
This basically relies upon binding in a closure. It's close, but not quite
right. i.e. if you copy the instance, the function will remember the
original and not know about the copy.
On Sun, May 14, 2017 at 11:01 AM, Steve D'Aprano wrote:
> It is common to add an attribute to a class, then over-ride it in the
> instance:
>
>
> class Document:
> pagesize = "A4"
>
> def __init__(self, pagesize):
> self.pagesize = pagesize
>
>
> A little-known fact, not appreciated by users of less powerful OOP
> languages: Python supports per-instance customized methods too, since
> methods are just attributes.
>
>
> py> class Parrot:
> ... name = "Polly"
> ... def speak(self):
> ... return "%s wants a cracker!" % self.name
> ...
> py> petey = Parrot()
> py> petey.speak()
> 'Polly wants a cracker!'
>
>
> We can shadow petey's "speak" method with a callable:
>
> py> petey.speak = lambda: "Who's a cheeky boy then!"
> py> petey.speak()
> "Who's a cheeky boy then!"
>
>
> Notice that using a regular function means that we cannot access "self".
> But
> all is not lost! We can do so by using a method object bound to the
> instance:
>
> py> from types import MethodType
> py> petey.speak = MethodType(
> ... lambda self: "%s is a cheeky boy!" % self.name,
> ... petey)
> py> petey.speak()
> 'Polly is a cheeky boy!'
>
>
>
>
> This can be considered a form of the Strategy design pattern. From
> Wikipedia:
>
> ... the strategy pattern (also known as the policy pattern)
> is a behavioural software design pattern that enables an
> algorithm's behavior to be selected at runtime. The strategy
> pattern:
>
> - defines a family of algorithms,
> - encapsulates each algorithm, and
> - makes the algorithms interchangeable within that family.
>
> https://en.wikipedia.org/wiki/Strategy_pattern
>
> the major difference being is that in the Strategy pattern there is not
> necessarily a default implementation provided by the class:
>
> class Dog:
> pass
>
> rover = Dog()
> butch = Dog()
> laddie = Dog()
>
> rover.do_trick = fetch_stick
> butch.do_trick = play_dead
> laddie.do_trick = solve_world_hunger
>
>
>
>
> --
> Steve
> Emoji: a small, fuzzy, indistinct picture used to replace a clear and
> perfectly comprehensible word.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: getting the center of mass of each part of a molecule
@Cameron: Thanks, I will try what you suggest. I am not sure that I'll tackle it because I am new to python. -- https://mail.python.org/mailman/listinfo/python-list
