EuroPython 2018: Ticket Sales Update
Some community members have been wondering why tickets are not available yet. We’d like to update you on the current status. EuroPython is run by the EuroPython Society located in Sweden. However, the conference being held in the UK, we have to charge UK VAT for the tickets we sell and submit the collected VAT to the UK tax authorities. In order to be able to do this, we have register with the UK tax authorities and this is where we have experienced unforseen delays. After several attempts at getting this sorted, our friends at PyCon UK have helped us find a capable accountant with whom we are currently implementing the registration. Hopefully, the tax authorities won’t take too long to issue us a UK VAT ID. As soon as we have it, we will start ticket sales. Ticket Prices Available --- That said, we do already have some more information for you: we have decided on the initial ticket prices for EuroPython 2018. In case you need budget approval from your employer, you may put in your request now. Please see our blog post or registration page for full details on the ticket pricing: * https://blog.europython.eu/post/173732504642/europython-2018-ticket-sales-update * https://ep2018.europython.eu/en/registration/buy-tickets/ Enjoy, -- EuroPython 2018 Team https://ep2018.europython.eu/ https://www.europython-society.org/ PS: Please forward or retweet to help us reach all interested parties: https://twitter.com/europython/status/994182851997421569 Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On 09/05/18 06:57, Chris Angelico wrote: On Wed, May 9, 2018 at 3:44 PM, Steven D'Aprano wrote: On Tue, 08 May 2018 22:48:52 -0500, Python wrote: I've always felt that this mentality was insulting to the programmer: "You're too stupid to get this right." Sure, I've created that bug in other languages (or rather its inverse) but not since college. You make it a few times, you go nuts debugging it, you learn what it is, you never do it again. And fortunately we don't have to deal with a steady stream of new programmers learning the language and making newbie errors, right? If all programmers were as awesome as you and never made typos, the world would be a better place. But we know from experience that even experienced C programmers can make this mistake by accident. Yes, and I'd go further: I *am* too stupid to get this right. Thirded. I am a C and assembler programmer by trade, and I often type "=" for "==" when I'm coding quickly, and sometimes even when I'm trying to be careful. I've met a lot of programmers over the years who assert that they are experienced enough not to make mistakes like that. They are, without fail, embarrassed when I turn on the compiler warning flags. -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Problems after upgrading Python 3.6.3 to 3.6.5
I am running Linux Mint 18.1 and Python3 version 3.5.2, Awhile ago I installed Python3.6 from LP-PPA-jonathonf-python-3.6/now. I did it to run 3.6 in virtual environment. Everything was working until I allowed the package manager to upgrade 3.6.3 to 3.6.5. See (1) below. First problem I had was pip would not run. I solved that problem with help from another forum. Then I discovered I could not import tkinter in my 3.6 EV. At the end of the error message (2) it said to install python3-tk. After i did so I could import tkinter in 3.6 but not the default system python3.5. At this point I checked the log (1) and saw that python3-tk had been removed. Looking at the installed version of python3-tk it now said 3.6.5~16.04.york0.2. So does the version matter between python3.5 and 3.6 or do I just have some kind of path problem. At this point I am somewhat lost as to how to get tkinter working again in 3.5. Regards, Jim (1) Commit Log for Thu May 3 13:26:38 2018 Removed the following packages: python3-tk Upgraded the following packages: libpython3.6-minimal (3.6.3-1ubuntu1~16.04.york1) to 3.6.5-5~16.04.york0 libpython3.6-stdlib (3.6.3-1ubuntu1~16.04.york1) to 3.6.5-5~16.04.york0 python3.6 (3.6.3-1ubuntu1~16.04.york1) to 3.6.5-5~16.04.york0 python3.6-minimal (3.6.3-1ubuntu1~16.04.york1) to 3.6.5-5~16.04.york0 python3.6-venv (3.6.3-1ubuntu1~16.04.york1) to 3.6.5-5~16.04.york0 Commit Log for Fri May 4 14:32:44 2018 Upgraded the following packages: python3-gdbm (3.6.3-0ubuntu1~16.04.york0) to 3.6.5-3~16.04.york0.2 Commit Log for Sun May 6 09:28:25 2018 Installed the following packages: python3-tk (3.6.5-3~16.04.york0.2) Commit Log for Sun May 6 11:42:31 2018 Installed the following packages: libexpat1-dev (2.1.0-7ubuntu0.16.04.3) libpython3-dev (3.5.1-3) libpython3.5-dev (3.5.2-2ubuntu0~16.04.4) python3-dev (3.5.1-3) python3.5-dev (3.5.2-2ubuntu0~16.04.4) (2) jfb@jims-mint18 ~ $ python3 Python 3.5.2 (default, Nov 23 2017, 16:37:01) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import tkinter Traceback (most recent call last): File "/usr/lib/python3.5/tkinter/__init__.py", line 36, in import _tkinter ImportError: No module named '_tkinter' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/tkinter/__init__.py", line 38, in raise ImportError(str(msg) + ', please install the python3-tk package') ImportError: No module named '_tkinter', please install the python3-tk package >>> -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On 09/05/2018 06:44, Steven D'Aprano wrote: On Tue, 08 May 2018 22:48:52 -0500, Python wrote: But by the time 1.4 came around, Guido had settled on a clean separation between statements and expressions as part of Python's design. That separation has gradually weakened over the years, Presumably it's non-existent now, as it seems you can type any expression as a statement in its own right: "stmt" a + b*c p == 0 with the addition of the ternary if operator If you mean that this is a kind of statement that can be incorporated into an expression, then just class it as an operator not a statement. (They are different in any case, for example statement-if doesn't return a value.) and comprehensions, And that one, although it's a more complex example. It might simply be that Guido (like many people) considered assignment to fundamentally be an imperative command, not an expression. You design a language, you get to choose how it works. (I allow assignments in expressions in my languages, but the two are different constructs: statement-assignment returns no value; expression-assignment does, although both use ":=" syntax for the assignment operator. That's OK ":=" doesn't really get mixed up with "=" for equality as "=" and "==" would do. So one answer would be to use something other than "=" for assignments within expressions. I don't however allow augmented assignments in expressions, as it's not that useful, and it would be too much (and I could never get the precedences right). But normal assignment is handy.) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking deeper (language theory) reason behind Python design choice
On Wed, 09 May 2018 22:48:42 +0100, bartc wrote: > On 09/05/2018 06:44, Steven D'Aprano wrote: >> On Tue, 08 May 2018 22:48:52 -0500, Python wrote: >> >> >> But by the time 1.4 came around, Guido had settled on a clean >> separation between statements and expressions as part of Python's >> design. >> >> That separation has gradually weakened over the years, > > Presumably it's non-existent now, as it seems you can type any > expression as a statement in its own right: That has always been the case. What I mean is that a few of the pure- statement features have now gained an expression form. >> with the addition of the ternary if operator > > If you mean that this is a kind of statement that can be incorporated > into an expression, then just class it as an operator not a statement. I called it an operator because it is an operator :-) To hopefully be more clear, any expression can be used as a statement (usually pointlessly). But statements (aside from expressions) cannot be used as expressions. There are, however, a small number of statements which have gained an equivalent expression form. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
