Discussion of Python in High Energy Physics https://hepsoftwarefoundation.org/activities/pyhep.html
It has the from pylab import * touch, which is now, for good reasons, depreceated. For IPython, I have a startup script full of import package as pkg with suppressed ImporError warnings, because yeah, it's otherwise pain.
It’s only for interactive work
I see the use case, and it's nice. But I also see the abuse cases and prefer e.g. template python modules combined with an "optimize import" in my IDE that removes all unnecessary imports. No magic, just clean...
(or better, what I actually do: an editor that imports modules like np, pd with a single shortcut when I use them)
For IPython, I have a startup script full of import package as pkg
This is exactly what it can and should be used for - and your start up script slows down your IPython startup time, even if you don’t use all the packages. If you copy your start up script to ~/.pyforest/user_imports.py, you will have instant startup times again, and things get imported when you use them. And you gain the ability to quickly see what you have used. I don’t use the from pyforst import * at all, it’s just an extention to IPython. I rather which that wasn’t there, for misusage issues.
We are currently discussion a pythonic GDML implementation to do comparisons and came across your package
Would you be interested to put this on Github for further development or is it better to start from scratch?
Hi all, the first release of scikit-stats, part of the scikit-hep toolset, has just been published.
It contains 2 submodules:
modeling: with the Bayesian Blocks algorithm that moved fromscikit-heptoscikit-stats.hypotest: aims to provide tools do likelihood-based hypothesis tests such as discovery test, computations of upper limits or confidences intervals. Currently discovery test
using asymptotic formulae is available. More functionalities will be added in the future.
Quick documentation is available in the README and notebook examples in binder , a proper documentation will be added in future releases.
Suggestions are welcome, and feel free to give it a try.
(I will stop here as otherwise we will have the whole discussion just now LOL.)
Otherwise we will loose users.
I would argue not many or maybe any. If we add a new package, regardless of the requirements, we can’t loose a user. If we add a new release of a package that is Python 3 only, existing users will still get the old Python 2 version, and again, won’t be lost. If experiments are using our code, they would fall into this category. The only ones I think we would risk loosing would be a new users, who are Python 2 only and want to start using our code - but a) I don’t think we have that many, b) they will still be able use older versions, and c) they already have to be using older versions of numpy, SciPy, matplotlib, and IPython, so our packages would just be one more thing.
Keep in mind, the cost of keeping Python 2 compatibility is non-zero. It requires more complex code, limits use of time saving features, adds extra checks, increases binary build time, etc. It can also hamper the package API and user experience in Python 3. We could use the time we spend fiddling with Python 2 code or writing code in a way to be compatible with both instead developing new libraries and features.
Obviously, the final decision for any package has done on a per-case basis by the core maintainers of that package. I still support Python 2.6 in Plumbum, for example.
But we cannot afford to be as aggressive as some
I don't think we can afford to be less aggressive than numpy - I don't think the HEP community should take over maintaining numpy. Similarly with Python - Over time, the old versions will stop working with anything new, or on new systems, etc. I already had to drop Pandas from Particle/DecayLanguage, because they are missing some variants of Python 2 wheels and will not produce them - their hands are washed clean of Python 2 already.
python_requires in our setups, so that pip 9+ will automatically find the last supported Python 2 version, etc. The idea is not to cause Python 2 to stop working, but to stop producing new features for Python 2 (more or less). It will be very interesting after January, though, to see how long things hold together...
I think we needed to give one more minute to the lightning talks and have fewer of them.
I disagree with this, I think the lightning talks were just fine and we should have had more of them.
DON'T USE PYTHON 2!
Lol
this field has evolved from enthusiast working in isolation 2 real interactivity in just a year or two. It's amazing how quickly that happened.
:D
python in macOS Catalina, the header at the top of Python’s startup says:WARNING: Python 2.7 is not recommended.
This version is included in macOS for compatibility with legacy software.
Future versions of macOS will not include Python 2.7.
Instead, it is recommended that you transition to using 'python3' from within Terminal.
Yes the lightning talks were a lot about a way to get everyone to introduce itself to everyone else. I was hoping for more such talks but in the end I guess people were a bit shy … maybe because the session was a first? For sure we will do this again.
I think so, it is new and people don't yet know how to deal with this, but they will learn.
pyhepmc I thought we could fold this into scikit-hep