[sage-devel] SciPy 2018 - one week left for submissions
SciPy 2018, the 17th annual Scientific Computing with Python conference, will be held July 9-15, 2018 in Austin, Texas. The annual SciPyConference brings together over 700 participants from industry, academia, and government to showcase their latest projects, learn from skilled users and developers, and collaborate on code development. The call for abstracts for SciPy 2018 for talks, posters and tutorials is now open. The new extended deadline for submissions is February 15, 2018. Conference Website: https://scipy2018.scipy.org Submission Website: https://easychair.org/conferences/?conf=scipy2018 *July 9-15, 2018 | Austin, Texas * - *Tutorials:* July 9-10, 2018 - *Conference (Talks and Posters):* July 11-13, 2018 - *Sprints: *July 14-15, 2018 In addition to the general track, this year will have specialized tracks focused on: - Data Visualization - Reproducibility and Software Sustainability *Mini Symposia* · Astronomy · Biology and Bioinformatics · Data Science · Earth, Ocean and Geo Science · Image Processing · Language Interoperability · Library Science and Digital Humanities · Machine Learning · Materials Science · Political and Social Sciences There will also be a SciPy Tools Plenary Session each day with 2 to 5 minute updates on tools and libraries. *Tutorials (July 9-10, 2018)* Tutorials should be focused on covering a well-defined topic in a hands-on manner. We are looking for awesome techniques or packages, helping new or advanced Python programmers develop better or faster scientific applications. We encourage submissions to be designed to allow at least 50% of the time for hands-on exercises even if this means the subject matter needs to be limited. Tutorials will be 4 hours in duration. In your tutorial application, you can indicate what prerequisite skills and knowledge will be needed for your tutorial, and the approximate expected level of knowledge of your students (i.e., beginner, intermediate, advanced). Instructors of accepted tutorials will receive a stipend. -- _ / \ A* \^ - ,./ _.`\\ / \ / ,--.S\/ \ / `"~,_ \\ __o ? _ \<,_ /:\ --(_)/-(_).../ | \ --...J Paul Ivanov http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Fwd: [Python-Dev] Friendly reminder: be kind to one another
I thought this was a good post on the python-dev mailing list, and an even better talk (the link to the youtube video--the actual talk starts about 7 minutes into the video). Not bringing this up here for any specific reason: I think this community does pretty well in terms of cordiality and mutual respect, but we all have bad days, and most of us (myself included) can always do better. Best, E -- Forwarded message -- From: Brett Cannon Date: Tue, Jan 30, 2018 at 3:16 AM Subject: [Python-Dev] Friendly reminder: be kind to one another To: python-dev Over the last 3 days I have had two situations come up where I was asked for my opinion in regards to possible CoC violations. I just wanted to take this opportunity to remind everyone that open source does not work if we are not open, considerate, and respectful to one another (which also happens to be the PSF CoC that we are all expected to follow when working on Python). When we stop being kind to each other is when open source falls apart because it drives people away, and for a project that is driven by volunteers like Python that will be what ends this project (not to say people should be rude to corporate open source projects, but they can simply choose to switch to a core dump approach of open source). I gave a talk at PyCascades this past week on setting expectations for open source participation: https://youtu.be/HiWfqMbJ3_8?t=7m24s . I had at least one person who was upset about no one getting to their pull request quickly come up to me afterwards and apologize for ever feeling that way after watching my talk, so do please watch it if you have ever felt angry at an open source maintainer or contributor to help keep things in perspective. I also wanted to say that I think core developers should work extra hard to be kind as we help set the tone for this project which can leak into the broader community. People with commit privileges are not beyond rebuke and so people should never feel they are not justified speaking up when they feel a core developer has been rude to them. Anyway, the key point is to remember is that people are what make this project and community work, so please make sure that you do what you can to keep people wanting to participate. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.
On 07/02/2018 12:17, Volker Braun wrote: On Wednesday, February 7, 2018 at 10:31:43 AM UTC+1, Jeroen Demeyer wrote: But what is the "desired implementation"? Again, surely its "Sage integers" for users of Sage. Anything else is just dumping a giant turd on your users just because its the lazy thing to do. Certainly not. The lazy way is to use Python integers and rationals. It was this way at the begining and I changed it partly because of Sage as I wanted to avoid useless traductions (at C level) and better C level integration. This was a non-trivial amount of work in upstream gmpy2. There are surely ways this can work. E.g. importing from pplpy.gmp gives you stuff that uses gmp ints, and importing from pplpy.sage gives you stuff that uses Sage integers. Or pplpy vs sage_pplpy, etc. Its not impossible to make it work, it just requires a bit more than the minimal developer effort to set it up. I never claimed that it was technically impossible. I said that it was not desirable to have two non-compatible API's. Having two libraries as you proposed above is one solution. Though I don't like it to have two copies of the same code. Another option is that I provide "universal wrappers" that makes the necessary translations to make you happy. Another option is to go with this small annoyance of dealing with explicit conversions. Vincent -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
