EuroPython 2017 Keynote: Aisha Bello & Daniele Procida
We are pleased to announce our next keynote speakers for EuroPython 2017: ** Aisha Bello & Daniele Procida ** About Aisha Aisha currently serves as vice chair for the Python Nigeria community. She has helped co-organized and support a number of Django Girls workshops in Namibia & Nigeria. She also is a co-organizer for PyLadies Nigeria. She is an ardent Tech and Python community enthusiast with a strong desire and passion for social change, women’s tech education and empowerment in Africa. In 2016 she won the Django Software Foundation Malcolm Tredinnick Memorial prize for her contributions to the community. Currently she works as an Associate Systems Engineer for Cisco Systems. About Daniele Daniele is an avid contributor to open source software and its communities. He has been a core developer of Django for over three years and recently joined the Django Software Foundation board. He works at Divio, where he helps support and develop open source Django products. Daniele is a veteran community builder. His contribution as part of the organising committee of PyCon Namibia has been key in establishing a successful Python community in Namibia. The Keynote: The Encounter: Python’s adventures in Africa A genuine encounter changes both parties. In this talk Daniele and Aisha will report on the dialogue opened up by recent PyCons and other Python events in Africa. They’ll discuss Python’s impact in countries including Namibia, Nigeria and Zimbabwe, and what open-source software means for Africa at large - and what the encounter means for Python too. Enjoy, -- EuroPython 2017 Team http://ep2017.europython.eu/ http://www.europython-society.org/ PS: Please forward or retweet to help us reach all interested parties: https://twitter.com/europython/status/866623463691366400 Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Scala considering significant indentation like Python
On 22/05/17 00:53, Steve D'Aprano wrote: The creator of Scala, Martin Odersky, has proposed introducing Python-like significant indentation to Scala and getting rid of braces: I was playing for a while now with ways to make Scala's syntax indentation-based. I always admired the neatness of Python syntax and also found that F# has benefited greatly from its optional indentation-based syntax, so much so that nobody seems to use the original syntax anymore. https://github.com/lampepfl/dotty/issues/2491 From the link: "Impediments What are the reasons for preferring braces over indentations? Provide visual clues where constructs end. With pure indentation based syntax it is sometimes hard to tell how many levels of indentation are terminated at some point... " I am a huge python fan (but also a C++ and Java fan) and I agree with Scala creator, sometimes the readability is complicated. So, more often than I would like to, I end up missing the braces :-O -- Cholo Lennon Bs.As. ARG -- https://mail.python.org/mailman/listinfo/python-list
Re: Scala considering significant indentation like Python
Cholo Lennon writes: > On 22/05/17 00:53, Steve D'Aprano wrote: >> The creator of Scala, Martin Odersky, has proposed introducing >> Python-like significant indentation to Scala and getting rid of >> braces: >> >> I was playing for a while now with ways to make Scala's syntax >> indentation-based. I always admired the neatness of Python >> syntax and also found that F# has benefited greatly from its >> optional indentation-based syntax, so much so that nobody seems >> to use the original syntax anymore. >> >> https://github.com/lampepfl/dotty/issues/2491 >> >> >> > > From the link: > > "Impediments > > What are the reasons for preferring braces over indentations? > > Provide visual clues where constructs end. With pure indentation based > syntax it is sometimes hard to tell how many levels of indentation are > terminated at some point... " > > I am a huge python fan (but also a C++ and Java fan) and I agree with > Scala creator, sometimes the readability is complicated. So, more > often than I would like to, I end up missing the braces :-O I am the inventor of multiple ends on the same line. This way, in a language where all of several nested constructs end with an end - not going to name the language but it's Julia - instead of end end end end end, one combines the uninformative lines into one by writing end end end end end, and with four-space indentation the ends align neatly with the starts. Technically, the ends on the remaining line of ends are backwards. -- https://mail.python.org/mailman/listinfo/python-list
Re: Scala considering significant indentation like Python
On 22/05/2017 14:59, Jussi Piitulainen wrote: Cholo Lennon writes: I am a huge python fan (but also a C++ and Java fan) and I agree with Scala creator, sometimes the readability is complicated. So, more often than I would like to, I end up missing the braces :-O I am the inventor of multiple ends on the same line. This way, in a language where all of several nested constructs end with an end - not going to name the language but it's Julia - instead of end end end end end, one combines the uninformative lines into one by writing end end end end end, and with four-space indentation the ends align neatly with the starts. Technically, the ends on the remaining line of ends are backwards. I think 'end' can be used in Python too: if (cond): stmts end But: - You need to define a dummy variable 'end' - It's not enforced nor checked by the language, it's only to aid readability, so ends may be placed incorrectly or left out - Multple ends on one line need a comma separator: end, end, end - No one actually does this so it can't solve any of the problems people might have with indentation -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Scala considering significant indentation like Python
On Mon, May 22, 2017 at 9:14 AM, bartc wrote: > I think 'end' can be used in Python too: > > if (cond): > stmts > end > > But: > > - You need to define a dummy variable 'end' Interesting idea. You can avoid the dummy variable part by just using '#end', however: if cond: stmts #end Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Scala considering significant indentation like Python
22.05.17 17:24, Skip Montanaro пише: On Mon, May 22, 2017 at 9:14 AM, bartc wrote: I think 'end' can be used in Python too: if (cond): stmts end But: - You need to define a dummy variable 'end' Interesting idea. You can avoid the dummy variable part by just using '#end', however: if cond: stmts #end See pindent.py. -- https://mail.python.org/mailman/listinfo/python-list
Re: Scala considering significant indentation like Python
On Monday, May 22, 2017 at 3:34:07 PM UTC+1, Serhiy Storchaka wrote: > 22.05.17 17:24, Skip Montanaro пише: > > On Mon, May 22, 2017 at 9:14 AM, bartc wrote: > >> I think 'end' can be used in Python too: > >> > >> if (cond): > >> stmts > >> end > >> > >> But: > >> > >> - You need to define a dummy variable 'end' > > > > Interesting idea. You can avoid the dummy variable part by just using > > '#end', however: > > > > if cond: > > stmts > > #end > > See pindent.py. To save others looking it's in C:\Program Files\Python36\Tools\scripts on my setup. Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: Scala considering significant indentation like Python
Any nesting beyond third level should be strong candidate for refactoring. Soon after you do that, big surprise, refactored block gets better documented, gets used elsewhere, becomes testable on its own, etc. I.e. if structure is not obvious from indentation alone, refactoring is the proper solution, not braces. Also deeply nested structures tend to involve variables in the deepest levels that are also used in the outer levels, making the scope of variables harder to manage (leading to similar bugs as result from use of global variables). So languages that do not require braces for code blocks encourage refactoring, and hence clearer code structure, separation of concerns, isolation of namespaces, etc. On Mon, May 22, 2017, 09:31 Cholo Lennon wrote: > On 22/05/17 00:53, Steve D'Aprano wrote: > > The creator of Scala, Martin Odersky, has proposed introducing > Python-like > > significant indentation to Scala and getting rid of braces: > > > > I was playing for a while now with ways to make Scala's syntax > > indentation-based. I always admired the neatness of Python syntax > > and also found that F# has benefited greatly from its optional > > indentation-based syntax, so much so that nobody seems to use > > the original syntax anymore. > > > > https://github.com/lampepfl/dotty/issues/2491 > > > > > > > > From the link: > > "Impediments > > What are the reasons for preferring braces over indentations? > > Provide visual clues where constructs end. With pure indentation based > syntax it is sometimes hard to tell how many levels of indentation are > terminated at some point... " > > I am a huge python fan (but also a C++ and Java fan) and I agree with > Scala creator, sometimes the readability is complicated. So, more often > than I would like to, I end up missing the braces :-O > > > -- > Cholo Lennon > Bs.As. > ARG > -- > https://mail.python.org/mailman/listinfo/python-list > -- Oliver My StackOverflow contributions My CodeProject articles My Github projects My SourceForget.net projects -- https://mail.python.org/mailman/listinfo/python-list
Re: getting the center of mass of each part of a molecule
On Saturday, May 20, 2017 at 9:13:39 AM UTC-7, qasi...@gmail.com wrote > I have more than 100 ligand molecules. The image I showed at the beginning of > this discussion was only an example. It had missing atoms. > See it without missing any atom in the pdb format (coordinates in Angstrom > unit): [snip atomic coordinate tables] > I am doing molecular dynamics simulation of protein-ligand complex. The issue > is to keep the ligand in the binding site of the protein during simulation > when turned off the interactions (van der waals, coulomb...) between the > ligand and protein. In that case, to keep the ligand in the bindind site I > need to apply the translational and rotational restraints (distance, angle, > dihedral restraints). The more detail is here > http://pubs.acs.org/doi/abs/10.1021/jp0217839 Well now, that's Ph.D level work. I work with GROMACS myself. I tried to obtain a copy of the paper. Why is a 14 year old article behind a paywall? I requested a reprint from the authors through ResearchGate. > My aim is to get the COM of the whole ligand (I already do it) and divide the > ligand in two parts and find to the COM of each part. Then I will apply the > distance, angle and dihedral restraints on the atoms of the ligand and > protein. > -The first distance restraints will be between one of the ligand heavy atom > closest to the ligand COM (COM for whole ligand atoms) and one of the protein > atoms closest to the ligand COM. > -The second distance restraints will be between one of the ligand heavy atom > closest to the COM of the first part of ligand in two parts and one of the > protein atoms closest to the COM of the first part of ligand in two parts. > -And the third distance restraints will be between one of the ligand heavy > atom closest to the COM of the second part of ligand in two parts and one of > the protein atoms closest to the COM of the second part of ligand in two > parts. > > That is, I will form 3 bonds between ligand and protein. Hope that makes > clear what I am trying to do. Is that the method that was used in the research paper, or is that something that you devised on your own? > Please tell me on the python code what I need to do. Your requirements are still rather more vague than you realize. I think that you are counting on the fact that the atomic coordinates in a PDB file include a certain amount of noise, and possibly also any strain in the ligand molecule. If you have a truly symmetrical ligand, your center of mass computations will not be robust. But I see the general idea behind what you are trying to do. And I suppose any method that forms three virtual bonds between three distinct atoms in ligand and the protein will do the job. Maybe you don't care that you get the true center of mass, just that you get close to it. How much Python do you want to learn? I am going to suggest a basic modification to your approach to coding. You will have several steps in this algorithm. Learn to structure your code in in a way which allows you to read your algorithm in plain language using comments, descriptive variable names, or descriptive function names. Right now you show one function called heavy_atoms. That is not a very descriptive name. I'm not even sure why it's a function at all, because it doesn't return any values to whatever called it. If your program is short and you only want to work with global variables, you can skip the use of functions. I would like to see your whole program. However, at this stage it's probably not of interest to other readers of the newsgroup. Please consider continuing through email. Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Scala considering significant indentation like Python
On 05/22/2017 07:59 AM, Jussi Piitulainen wrote: > I am the inventor of multiple ends on the same line. This way, in a > language where all of several nested constructs end with an end - not > going to name the language but it's Julia - instead of > > end > end > end > end > end, > > one combines the uninformative lines into one by writing > > end end end end end, > > and with four-space indentation the ends align neatly with the starts. > Technically, the ends on the remaining line of ends are backwards. Kind of reminds me of LISP. Lots of closing parenths, and often then just all get stuck together on a long. But I guess that's why they invented paren matching shortcuts in editors. To make it easy to see if you have them matched up. This works with braces too. Perhaps there is a plugin for Vim to jump back and forth between the beginning and end of a blog? Wouldn't be too hard to just look at indent. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install Python package from source on Windows
On Sun, May 21, 2017 at 5:40 PM, bartc wrote: > I think it was YOU that got me wasting time downloading that VS2015 > solution, all 1MB of it [download size; unknown installation size], Visual Studio installs a multi-architecture (x86, x64, arm, arm64) build environment for native and managed C++. It's more than CPython needs, but it's the preferred build environment on Windows. VC++ installs about a gigabyte of static libs (.obj archive) and import libs (dynamic linking) for C, C++, and other runtime libraries and features (e.g COM support, partially trusted applications, and the default delay loader), built for both debug and release, including PDB symbol files. The SDK (in "Windows Kits") also has about a gigabyte of libs (mostly import, but some static) built for multiple architectures. The Windows 10 SDK also has static and import libs for the Universal CRT. On top of this you have the various headers, CRT source files, tools, documentation, and samples. Here's an incomplete list of the VC++ libs (x64 sizes): /MT[d]: static linking [debug] /MD[d]: dynamic linking [debug] Universal C Runtime (SDK) libucrt.lib57000 KB /MT libucrtd.lib 6 KB /MTd ucrt.lib 285 KB /MD api-ms-win-crt-*.dll ucrtbase.dll ucrtd.lib249 KB /MDd ucrtbased.dll VC Runtime libvcruntime.lib 811 KB /MT libvcruntime.pdb 242 KB libvcruntimed.lib795 KB /MTd libvcruntimed.pdb250 KB vcruntime.lib 17 KB /MD vcruntime140.dll vcruntimed.lib17 KB /MDd vcruntime140d.dll CRT Startup (static libs) libcmt.lib 1850 KB /MT libcmt.pdb 299 KB libcmtd.lib 1858 KB /MTd libcmtd.pdb 299 KB msvcrt.lib 3352 KB /MD msvcrtd.lib 3385 KB /MDd CRT Mixed Native-Managed Startup (static libs) msvcmrt.lib 1897 KB /clr, /MD mscoree.dll msvcmrtd.lib1977 KB /clr, /MDd mscoree.dll CRT Pure Managed Startup (static libs) msvcurt.lib45462 KB /clr:pure, /MD msvcurtd.lib 48244 KB /clr:pure, /MDd C++ Runtime libcpmt.lib11297 KB /MT libcpmt.pdb 2191 KB libcpmtd.lib 13411 KB /MTd libcpmtd.pdb2265 KB msvcprt.lib 784 KB /MD msvcp140.dll msvcprtd.lib 795 KB /MDd msvcp140d.dll VC WinRT Core Library (C++/CX) vccorlib.lib3302 KB /ZW, /MD vccorlib140.dll vccorlibd.lib 3375 KB /ZW, /MDd vccorlib140d.dll Concurrency Runtime libconcrt.lib 12031 KB /MT libconcrt.pdb 1855 KB libconcrtd.lib 13378 KB /MTd libconcrtd.pdb 1872 KB concrt.lib 120 KB /MD concrt140.dll concrtd.lib 120 KB /MDd concrt140d.dll C/C++ OpenMP Runtime vcomp.lib 28 KB /openmp, /MD | /MT vcomp140.dll vcompd.lib28 KB /openmp, /MDd | /MTd vcomp140d.dll C++ AMP Runtime (Accelerated Massive Parallelism) vcamp.lib 85 KB /MT | /MD vcamp140.dll vcampd.lib85 KB /MTd | /MDd vcamp140d.dll COM Support comsuppw.lib 591 KB /Zc:wchar_t comsuppwd.lib610 KB /Zc:wchar_t comsupp.lib 592 KB /Zc:wchar_t- comsuppd.lib 610 KB /Zc:wchar_t- Partially-Trusted Managed Applications ptrustm.lib 708 KB ptrustmd.lib 723 KB ptrustu.lib 530 KB ptrustud.lib 548 KB -- https://mail.python.org/mailman/listinfo/python-list
Re: Survey: improving the Python std lib docs
A portion of this thread seems to be focusing on what key word args parameters actually mean, in the Python sense. There is documentation for that, and a modicum of experience with Python makes this a relatively simple question and answer. However, when docs for a specific function or method specify keyword arguments without any indication of what the *expected* arguments might be, or what *useful* arguments might be, then it's not really helpful. If I have to look at the source code to figure out how the args are used, I don't need the docs at all. Which is why I suggest a line or two with sample invocations to provide at least a starting point to understand the parameters. A doc signature that says something like "do_something(p1, d)" tells me very little. Even knowing that p1 is a "Point" is not all that valuable, except to give me another item to look up (the expected Point implementation). However, an example like 'do_something((141,380),"January, 2017")' tells me a lot more - that the Point is actually a tuple with (probably) x-y coordinates, and 'd' is a description associated with that position. That's a lot of useful information at a cost of a couple of dozen characters. So why not add a few examples? -- https://mail.python.org/mailman/listinfo/python-list
Re: Scala considering significant indentation like Python
On 05/22/2017 12:13 PM, Michael Torrie wrote: On 05/22/2017 07:59 AM, Jussi Piitulainen wrote: I am the inventor of multiple ends on the same line. This way, in a language where all of several nested constructs end with an end - not going to name the language but it's Julia - instead of end end end end end, one combines the uninformative lines into one by writing end end end end end, and with four-space indentation the ends align neatly with the starts. Technically, the ends on the remaining line of ends are backwards. Kind of reminds me of LISP. Lots of closing parenths, and often then just all get stuck together on a long. But I guess that's why they invented paren matching shortcuts in editors. To make it easy to see if you have them matched up. This works with braces too. Perhaps there is a plugin for Vim to jump back and forth between the beginning and end of a blog? Wouldn't be too hard to just look at indent. It's built-in, no plug-in necessary. I still find white-space indentation easier to read, though. Is that block 20 lines down inside or outside the above if/for/while? Just put your cursor on it and go straight down and you'll find out. Not so easy if the braces aren't lined up (at least for me). -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Scala considering significant indentation like Python
On 05/22/2017 02:57 PM, Ethan Furman wrote: >> Kind of reminds me of LISP. Lots of closing parenths, and often then >> just all get stuck together on a long. But I guess that's why they >> invented paren matching shortcuts in editors. To make it easy to see if >> you have them matched up. This works with braces too. Perhaps there is >> a plugin for Vim to jump back and forth between the beginning and end of >> a blog? Wouldn't be too hard to just look at indent. Sigh. Missing words, the wrong words! Block, not blog. agg. > It's built-in, no plug-in necessary. > > I still find white-space indentation easier to read, though. Is that block 20 lines down inside or outside the above > if/for/while? Just put your cursor on it and go straight down and you'll find out. Not so easy if the braces aren't > lined up (at least for me). True enough. Would still be nice to jump, though. Sometimes things get longer than a page (like a class definition). -- https://mail.python.org/mailman/listinfo/python-list
Re: Scala considering significant indentation like Python
> The creator of Scala, Martin Odersky, has proposed introducing Python-like > significant indentation to Scala and getting rid of braces: > > I was playing for a while now with ways to make Scala's syntax >indentation-based. I always admired the neatness of Python syntax >and also found that F# has benefited greatly from its optional >indentation-based syntax, so much so that nobody seems to use >the original syntax anymore. > > https://github.com/lampepfl/dotty/issues/2491 People sort of like indentation structuring. It introduces some typography into source code representaion, and restricts possibilities to [ugly]format the code. I've looked quickly through the linked discussion, and not sure if many think of the whole issue globally. I understand the indentation, as well as many other syntactical tricks as a trade-off for bringing nice code look in pure *textual* editors. And that's one part of the indentation concept - a trade-off, assuming that one looks at the code by means of relatively primitive text renderer. Once I've came across this blog: http://tratt.net/laurie/blog/entries/an_editor_for_composed_programs.html This man seems to have the 'feel' for the whole issue and I agree with his many points about the tendencies. So to look slightly further than own nose - I suppose the era of "char-by-char" code rendering/editing will not last so long and code editors should deal with the code in a structured way. The question how exactly to show structure - as indent, or vertical lines with nodes, will become just a user setup option, same as colors, etc. IOW for future human-oriented development environment, the look of a source file in an average notepad should become a secondary criteria, but a better *parse-ability* will become primary criterion. Even if speak about 'now' situation - looking e.g. into C code I understand that braces are not the biggest problem for me. I can ignore them more or less, but then come other readability issues - lines starting with type names, unintuitive declarations, asterisks jumping to the left or right depending on author's habits, etc. So braces is not the major issue in the whole syntax problematics. In some cases (though rare and if used with craft) they can help to avoid unwanted indentations. For sure an average indented Python code looks way better than any 'braced' analogue and for common textual presentation indented blocks is probably the optimal way. Mikhail -- https://mail.python.org/mailman/listinfo/python-list
