EuroPython 2019: More Attendee Updates
We have had a whole set of updates in the last two days. In order not to spam you too much with all the blog post texts, we're sending out a summary. EuroPython 2019 Keynotes We are proud to announce our keynote lineup for EuroPython 2019: - AI in Contemporary Art by Luba Elliott - Are women underrepresented in the High Performance Computing (HPC) community? by Athina Frantzana - Getting Your Data Joie De Vivre Back! by Lynn Cherny - Python Performance: Past, Present and Future by Victor Stinner - Why You Should Pursue Public Speaking and How to Get There by Yenny Cheung Full text: https://blog.europython.eu/post/185904088457/europython-2019-keynotes EuroPython 2019: Call for On-site Volunteers Ever wanted to help out during Europython ? Do you want to *really* take part in EuroPython, meet new people and help them at the same time ? We have just the right thing for you: apply as EuroPython Volunteer and be part of the great team that is making EuroPython 2019 a reality this year. Full text and how to sign up: https://blog.europython.eu/post/185904252962/europython-2019-call-for-on-site-volunteers EuroPython 2019: Social event tickets available --- After the keynotes and talks on Thursday, July 11th, we’ve organized a social event at the workshop venue, the FHNW Muttenz. Starting at 19:00 CEST, you can join us for an evening party with finger food, drinks and music. Full text: https://blog.europython.eu/post/185929674552/europython-2019-social-event-tickets-available EuroPython 2019: SIM cards for attendees Switzerland is often not included in European cell provider’s roaming packages and also not covered by the EU roaming regulation, so you can potentially incur significant charges when going online with your mobile or notebook. In order to make things easier for you, we have purchased 300 SIM cards from a local Swiss cell provider, which we will make available in our ticket shop. After purchase, you can then pick up the cards at the registration desk (please bring your receipt). Full text and how to buy: https://blog.europython.eu/post/185929675562/europython-2019-sim-cards-for-attendees Dates and Venues EuroPython will be held from July 8-14 2019 in Basel, Switzerland, at the Congress Center Basel (CCB) for the main conference days (Wed-Fri) and the FHNW Muttenz for the workshops/trainings/sprints days (Mon-Tue, Sat-Sun). The schedule is available at: https://ep2019.europython.eu/events/schedule/ Tickets can be purchased on our registration page: https://ep2019.europython.eu/registration/buy-tickets/ For more details, please have a look at our website and the FAQ: https://ep2019.europython.eu/faq Help spread the word Please help us spread this message by sharing it on your social networks as widely as possible. Thank you ! Link to the blog posts: https://blog.europython.eu/ Tweets: https://twitter.com/europython/ Enjoy, -- EuroPython 2019 Team https://ep2019.europython.eu/ https://www.europython-society.org/ -- https://mail.python.org/mailman/listinfo/python-list
EuroPython 2019: Introducing MongoDB
We are very pleased to have MongoDB as Keystone Sponsor for EuroPython 2019. You can visit them at the most central booth in our exhibit area on the second floor in the Congress Center Basel (CCB), and take the opportunity to chat with their staff and learn more about the MongoDB eco-system. Please find below a hosted blog post from MongoDB. Enjoy, – EuroPython 2019 Team https://ep2019.europython.eu/ https://www.europython-society.org/ MongoDB ❤ Python MongoDB is the leading modern, general-purpose database platform, designed to unleash the power of software and data for developers and the applications they build. We have architected our database to cater to the needs of modern-day applications from the ground-up with built-in support for high availability through sophisticated replication with self-healing recovery and horizontal scalability through native sharding. MongoDB Atlas is our fully-automated database-as-a-service offering, engineered and run by the same team that builds the database. At MongoDB, it is our mission to make data ridiculously easy to work with and we love, love, LOVE Python because it helps us do exactly that. To bring the power of MongoDB to the Python ecosystem, we’ve developed PyMongo - the Python driver for MongoDB. With over 3 million downloads per month, PyMongo is one of our most popular drivers. Our Driver team also maintains Motor - an asynchronous Python driver for MongoDB and PyMODM - our object-document mapper. While Python is an important and popular tool for our users, it is also an integral part of developer workflows across our engineering teams. Our Documentation team, for instance, maintains the Giza library which is used to render the entire official MongoDB documentation. Our Education team builds MongoDB University with Django and uses PyMODM and MongoDB Atlas to store application data. The University site has over 1 million registered users and over 100,000 active users per month–all powered by MongoDB. Python is also an integral part of our CI/CD process used to test our core database and all drivers. Join us at our workshop where we will teach you how to harness the power of MongoDB Atlas to build a highly-available CRUD application using Flask and PyMongo. You will learn more about MongoDB’s document data model, how we ensure high-availability and best practices for building applications using MongoDB. We will also showcase how to build the same application in MongoDB Stitch - our serverless platform. Bring your laptops! MongoDB is proud to support the Python community. In the past, we have sponsored conferences such as PyCon and PyGotham, and also hosted meetups such as PyLadies. Drop by our booth (#10) to say ‘hi’ to our awesome team and to learn more about Python at MongoDB! You can also join the conversation with other MongoDB and Python community members in our Community Slack Workspace. Register at http://launchpass.com/mongo-d or login at http://mongo-db.slack.com. -- https://mail.python.org/mailman/listinfo/python-list
Re: Handle foreign character web input
On 6/30/19 4:00 AM, moi wrote: > Le samedi 29 juin 2019 19:25:40 UTC+2, Richard Damon a écrit : >> >> Now (as I understand it), all Python (3) 'Strings' are internally >> Unicode, if you need something with a different encoding it needs to be >> in Bytes. >> >> -- > > Unfortunately not. > > The only thing Python succeeds to propose is a mechanism > which does the opposite of UTF-8 when it comes to handle > memory *and* - at the same time - which also does the opposite > of UTF-32 regarding performance. > > For some other reasons, this mechanism leads to buggy > code. > My understanding was that the Python 3 'String' class always used a Unicode encoding (never a code-page encoding). If you indexed into a string you would get at each location the full code point value of that character. Now Unicode isn't just UTF-8 or UTF-32/UCS-4 or the like, those are just different ways to encode into memory/a stream Unicode code points. It may be that Python makes some awkward choices of how it wants to store the characters in memory, but to the programmer, it is just Unicode code points. If you specifically want something list a UTF-8 encoding, that is one of the usages of Bytes was. -- https://mail.python.org/mailman/listinfo/python-list
Re: Make sure the window title is visible in tkinter
Cousin Stanley wrote >> You might try setting a given window geometry >> to accomodate the long title >> >> win_w = 400 >> win_h = 300 >> >> ofs_h = 40 >> ofs_v = 30 >> >> window.geometry( "%dx%d+%d+%d" % ( win_w , win_h , ofs_h , ofs_v ) ) >> >> >> Maybe add a bit of extra space for users >> with different default font sizes >> >> Not a general solution >> but perhaps workable moi wrote > No, huge mistake. It isn't clear to me how specifying a particular geometry for one's own self-coded tkinter gui prgrams with windows that are resize-able would be a mistake > Take for example the Windows installer. > > The window is so small, you can not even read the path > where Python will be installed. > > Bonus: the windows is not resizable and part of items > are not even visible. > > It would be to bad to not mimic this behavior. > > Just tested it 2 min ago on my Windows 7.1 with py3.7.3. I didn't suggest modifying 3rd party programs, but the suggestion I offered was meant to be applied to one's own code I have used a given geometry for dozens of my own tkinter gui programs such that a modest window size which assures that all widgets are viewable when first presented to the user -- Stanley C. Kitching Human Being Phoenix, Arizona -- https://mail.python.org/mailman/listinfo/python-list
Re: Handle foreign character web input
On Sun, Jun 30, 2019 at 10:26 PM Richard Damon wrote: > > On 6/30/19 4:00 AM, moi wrote: > > Le samedi 29 juin 2019 19:25:40 UTC+2, Richard Damon a écrit : > >> > >> Now (as I understand it), all Python (3) 'Strings' are internally > >> Unicode, if you need something with a different encoding it needs to be > >> in Bytes. > >> > >> -- > > > > Unfortunately not. > > > > The only thing Python succeeds to propose is a mechanism > > which does the opposite of UTF-8 when it comes to handle > > memory *and* - at the same time - which also does the opposite > > of UTF-32 regarding performance. > > > > For some other reasons, this mechanism leads to buggy > > code. > > > > My understanding was that the Python 3 'String' class always used a > Unicode encoding (never a code-page encoding). If you indexed into a > string you would get at each location the full code point value of that > character. Now Unicode isn't just UTF-8 or UTF-32/UCS-4 or the like, > those are just different ways to encode into memory/a stream Unicode > code points. It may be that Python makes some awkward choices of how it > wants to store the characters in memory, but to the programmer, it is > just Unicode code points. If you specifically want something list a > UTF-8 encoding, that is one of the usages of Bytes was. I didn't see who you were quoting, but it looks like our old "Py3's Unicode is buggy" troll is back (or maybe he never left, he just got banned from the mailing list). The ONLY bugginess he has ever shown is a performance regression on a very specific sort of operation where the old (Py2) behaviour was *actually* buggy. Take no notice of him; he is either trolling or somehow deluded, and either way, he never listens to people's responses. Waste none of your time on him. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Handle foreign character web input
On 06/30/2019 06:21 AM, Richard Damon wrote: > On 6/30/19 4:00 AM, moi wrote: >> Unfortunately not. >> >> The only thing Python succeeds to propose is a mechanism >> which does the opposite of UTF-8 when it comes to handle >> memory *and* - at the same time - which also does the opposite >> of UTF-32 regarding performance. I guess "moi" is banned from the mailing list for posting this kind of rubbish, just like our other old unicode troll as I see no trace of his post on the list. Which is just as well. It's completely wrong. The in-memory, internal byte encoding of unicode is irrelevant to the programmer. In Python 3 we deal with unicode. Period. Any performance issues he or our other unicode troll (perhaps the same person?) stem from not understanding the nature of immutable strings. >> For some other reasons, this mechanism leads to buggy >> code. No it doesn't. Without any evidence to back him up, this is a complete fabrication on Moi's part. > My understanding was that the Python 3 'String' class always used a > Unicode encoding (never a code-page encoding). If you indexed into a > string you would get at each location the full code point value of that > character. Now Unicode isn't just UTF-8 or UTF-32/UCS-4 or the like, > those are just different ways to encode into memory/a stream Unicode > code points. It may be that Python makes some awkward choices of how it > wants to store the characters in memory, but to the programmer, it is > just Unicode code points. If you specifically want something list a > UTF-8 encoding, that is one of the usages of Bytes was. That's correct. It doesn't matter what format Python chooses to use in memory. Some argue that O(1) indexing of a unicode string is not important because indexing a unicode string by code point (a "character") is incorrect some/much of the time, owing to the fact that sometimes what is seen as a single character on the screen is actually composed of more than one code point (grapheme cluster). Hence using UTF-8 internally is good enough, and encoding to bytes is a no-op (fast). -- https://mail.python.org/mailman/listinfo/python-list
Re: Handle foreign character web input
On 6/30/19 10:04 AM, Chris Angelico wrote: > On Sun, Jun 30, 2019 at 10:26 PM Richard Damon > wrote: >> On 6/30/19 4:00 AM, moi wrote: >> > I didn't see who you were quoting, but it looks like our old "Py3's > Unicode is buggy" troll is back (or maybe he never left, he just got > banned from the mailing list). The ONLY bugginess he has ever shown is > a performance regression on a very specific sort of operation where > the old (Py2) behaviour was *actually* buggy. Take no notice of him; > he is either trolling or somehow deluded, and either way, he never > listens to people's responses. Waste none of your time on him. > > ChrisA Looking back, I made that reply on comp.lang.python and I guess the person is blocked from being relayed to python-list. I guess I forgot which place I was reading at the time. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: I have anaconda, but Pycharm can't find it
Hi everyone, I know this problem's solution because I solve in my computer. First of all, you can delete the project files. After that download python on official website and last version. after this step restart pycharm and create new project... Good luck -- https://mail.python.org/mailman/listinfo/python-list
python
Use a while loop and write a python program to display the first n, numbers divisible by both 3 and 5 . the amount of numbers to be displayed should be dictated by the user input (Hint: if the users 10, then the numbers divisible by both 4 and 5 to be displayed should be 10) -- https://mail.python.org/mailman/listinfo/python-list
Re: python
Hi, On Sun, Jun 30, 2019 at 3:52 PM wrote: > > Use a while loop and write a python program to display the first n, numbers > divisible by both 3 and 5 . the amount of numbers to be displayed should be > dictated by the user input (Hint: if the users 10, then the numbers divisible > by both 4 and 5 to be displayed should be 10) And what are we suppose to do do with it? Please give more information - what you tried, what doesn't work, did you try to debug it, what algorithm being used? Thank you. > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: python
On Mon, Jul 1, 2019 at 6:51 AM wrote: > > Use a while loop and write a python program to display the first n, numbers > divisible by both 3 and 5 . the amount of numbers to be displayed should be > dictated by the user input (Hint: if the users 10, then the numbers divisible > by both 4 and 5 to be displayed should be 10) > This isn't a "do my homework for me" service. Do your homework. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Python 3.7.3 - ImportError: dynamic module does not define module export function (PyInit_*)
Hi, I was trying to upgrade a python 2 extension in Linux and hit this error upon trying to import it into python 3. The weird thing is that I can see the symbol when I use readelf -a, so it is not missing, it has visibility default and it defines as extern "C" PyObject* return type (using the macro). I build with g++ 6, global visibility hidden and inline hidden, would that affect it? does it need to find other functions? readelf -d shows that a NEEDED library is my altinstall build of python 3.7.3's libs, so that makes me think g++ found the correct library (there is an oder system library installed). RUNPATH is configured with a relative path that leads upwards in the folder tree to the python libs. It points to the same lib folder as the interpreter's RUNPATH, which is also relative. The module name starts with a underscore, so that's a point of worry, the standard mentioned ascii, so I assumed underscore is fine, but maybe it meant alphanumeric. The module is _mymodule_python3, and the init is PyInit__mymodule_python3, with the *.so being _mymodule_python3.so and a python file mymodule.py that loads the module inside using 'import my.package._mymodule_python3'. The cpp file is encoded in utf8, but the module name string that goes in the module def is not L"", it is plain char. I load python3 manually and then import this py file and it finds the so file, but at the end prints the error, I can exit, load another python3 and import the so directly and same outputs. sys.path doesnt point to the system install. I read the standard page and it seems everything is set up correctly (although it obviously isn't or it should be working). I've had a lot of difficulty debugging the import call because it is frozen so I can't just edit the _bootstrap.py file, I edit it and it still uses the frozen code. I even edited the file in the source tree itself by adding a few print calls then rebuilt cpython, and they seem to be consumed by the freeze pass, as nothing gets printed, how do you debug it properly? google is not helping me. import is failing at _gcd_import (name, package = None, level = 0) -> find and load. And if I use a different loading method by importing importlib (used in documentation page), it manages to obtain the spec which looks okay upon printing it, but fails upon trying to load and return the module object with spec.loader.create_module. Appreciate ideas or a proper debugging method for the import function. -- https://mail.python.org/mailman/listinfo/python-list
