Non-English names in the turtle module.
I've opened an issue for adding non-English names to the turtle module's function names: https://bugs.python.org/issue24990 This would effectively take this code: import turtle t = turtle.Pen() t.pencolor('green') t.forward(100) ...and have this code in French be completely equivalent: import turtle t = turtle.Plume() t.couleurplume('vert') t.avant(100) (Pardon my google-translate French.) This, of course, is terrible way for a software module to implement internationalization, which usually does not apply to the source code names itself. But turtle is used as a teaching tool. While professional developers are expected to obtain proficiency with English, the same does not apply to school kids who are just taking a small computer programming unit. Having the turtle module available in their native language (even if Python keywords are not) would remove a large barrier and let them focus on the core programming concepts that turtle provides. The popular Scratch tool has a similar internationalized setup and also has LOGO-style commands, so most of the translation work is already done. Are there any design or technical issues I should be aware of before doing this? It seems like a straight forward "Tortuga = Turtle" assignment of names, though I would have a set up so that it is easy to add languages to the source. I have a Google-translated set of translations here: https://github.com/asweigart/idle-reimagined/wiki/Turtle-Translations But of course, a native speaker would have to sign off on it before making it part of the turtle module API. -Al
On Thu, Sep 3, 2015, at 16:53, Al Sweigart wrote:
https://github.com/asweigart/idle-reimagined/wiki/Turtle-Translations
A couple of downsides I noticed: "The names will later be formatted to fit the code style of the turtle module. " is a bit handwavy, to be honest. Are things like "de la" required or optional? Should an apostrophe/space/hyphen become an underscore or be omitted? What can be abbreviated? What case/inflection/conjugation should be used? These are decisions that have to be made by native speakers based on what will be understandable to beginners who know each language. Your names aren't very consistent - I don't know French that well, but I doubt the module would benefit from mixing "plume", "crayon", and "stylo". What to call a pen needs to be decided at a high level and used globally. Also, things like "set...", "get...", "on...", need to be translated to something consistent throughout the module. For that matter, the naming conventions in the *English* ones are a bit questionable and inconsistent. Maybe this is an opportunity to clean up that API. Also, a bug to report: I know enough Spanish to know that "pantalla clara" means "clear screen" as a noun [screen that is clear], not a verb [clearing the screen]. The English is ambiguous, but most other languages are not. For design questions: Is it important to hide the English names? Is it important to be able to use the classes interchangeably to code that is written to use a different language's method names? Can the same name in one language ever translate to two different names in another language depending on context?
On Thu, Sep 3, 2015 at 11:27 PM, <random832@fastmail.us> wrote:
I would not be surprised if, among all languages in the world, there'd be a clash in one of turtle's attribute names. Why put everything in the same namespace? It might be better to use more of those – perhaps something like "from turtle.translations import tortuga" ("tortuga" being Spanish for turtle). That is probably too long, so why not just "import tortuga"? That "tortuga" module could live on PyPI for a while, before it's considered for addition to either the stdlib, or just the installers.
Just to reply to both Petr and Random832 at once: By "formatted to fit the code style of the turtle module" I meant that the names would be pushed together without camelcase or underscores (as they are already done in the turtle module). But you do bring up good points. Whether things like "de la" are omitted or how things can be abbreviated is left entirely up to the native speaker doing the translation. I don't see any way around it. But, as a rough guide, the Scratch tool has already done lots of translation work and translators can piggy back off their wording choices. The turtle module has been around long enough that I already see it's API as set in stone, for better or worse. If the English names should be changed, I see that as a separate issue. I don't see a reason to hide the English names. I want the names to be available without additional setup, i.e. there is no "language" setting that needs to be specified first. The fewer setup steps the better. All names in all languages would be available. I don't see being able to mix, say, English and Spanish names in the same program as a big enough problem that we have to force a fix to prevent it. I'd like to keep the setup as simple and as similar to existing code as possible. There is a slight difference between "import x" and "from x import x" and I'd want to avoid that. From a technical perspective, I don't think the additional names will hinder the maintenance of the turtle module (which rarely changes itself). Though I'll know for sure what the technical issues are, if any, once I produce the patch. The idea for putting these modules on PyPI is interesting. My only hesitation is I don't want "but it's already on PyPI" as an excuse not to include these changes into the standard library turtle module. -Al On Thu, Sep 3, 2015 at 3:55 PM, Petr Viktorin <encukou@gmail.com> wrote:
On Fri, Sep 04, 2015 at 11:05:51AM +0900, Stephen J. Turnbull wrote:
*cough typing cough* The turtle module has been in Python for many, many years. This proposal doesn't change the functionality, it merely offers a localised API to the same functionality. A bunch of alternate names, nothing more. I would argue that if you consider the user-base of turtle, putting it on PyPI is a waste of time: - Beginners aren't going to know to "pip install whatever". Some of us here seem to think that pip is the answer to everything, but if you look on the python-list mailing list, you will see plenty of evidence that people have trouble using pip. - Schools may have policies against the installation of unapproved software on their desktops, and getting approval to "pip install *" may be difficult, time-consuming or outright impossible. If they are using Python, we know they have approval to use what is in the standard library. Everything else is, at best, a theorectical possibility. One argument against this proposal is that Python is not really designed as a kid-friendly learning language, and we should just abandon that space to languages that do it better, like Scratch. I'd hate to see that argument win, but given our limited resources perhaps we should know when we're beaten. Compared to what Scratch can do, turtle graphics are so very 1970s. But if we think that there is still a place in the Python infrastructure for turtle graphics, then I'm +1 on localising the turtle module. -- Steve
Thinking about it some more, yeah, having a separate module on PyPI would just be a waste of time. This isn't changing functionality or experimenting with new features, it's just adding new names to existing functions. And installing stuff with pip is going to be insurmountable barrier for a lot of computer labs. I'd say Python is very much a kid-friendly language. It's definitely much friendlier than BASIC. I'd advise against using the _() function in gettext. That function is for string tables, which is set up to be easily changed and expanded. The turtle API is pretty much set in stone, and dealing with separate .po files and gettext in general would be more of a maintenance headache. It is also dependent on the machine's localization settings. I believe some simple code at the end of turtle.py like this would be good enough: _spanish = {'forward': 'adelante'} # ...and the rest of the translated terms _languages = {'spanish': _spanish} # ...and the rest of the languages def forward(): # this is the original turtle forward() function print('Blah blah blah, this is the forward() function.') for language in _languages: for englishTerm, nonEnglishTerm in _languages[language].items(): locals()[nonEnglishTerm] = locals()[englishTerm] Plus the diff wouldn't look too bad. This doesn't prohibit someone from mixing both English and Non-English names in the same program, but I don't see that as a big problem. I think it's best to have all the languages available without having to setup localization settings. -Al On Thu, Sep 3, 2015 at 7:45 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Hi all, Personal opinion, base by a bit of experience: There is one thing worse than programming in a foreign language IMHO (I’m native french) It’s programming in an environment which is half translated and/or mix english and native language. The cognitive load and the context switching it forces the brain to do when 2 languages are present is absolutely astronomical, and i guess translating the Turtle module will not allow to translate the control-flow structure, the docstrings....etc and so on, and so forth if you do simple `Tortue = Turtle` assignment, So while it looks nice 2 liners example you hit this problem pretty quickly. Taking fort given example: import turtle # import is english, should translate to importer, ou importez. turtle should be tortue also. t = turtle.Plume() t.couleurplume('vert’) # plume is a female, couleur should be “verte”, “crayon” would be male, so “vert" t.avant(100) # avance/avancer I can perfectly imagine a menu “insérer use boucle `pour ...`”, that insert a `for ....` in applications, which is confusing is confusing to explain. I also find it much easier to attach a programming meaning to a word that have no previous meaning for a kid (for, range, if, else, print are blank slate for French children), than shoehorn another concept biased by previous experience into it. This in particular make me think of Gibiane[1], which is basically: “Hey fortran is great let’s make it in french”, which was a really bad idea[2], no it’s not a joke, and yes people do nuclear physics using this language. While I appreciate in general the translation effort, in general most of the translated side of things (MDN, microsoft help pages, Apples ones) are much worse than trying to understand the english originals. So just a warning that the best is the enemy of the good, and despite good intentions[3], trying to translate Turtle module might not be the right thing to do. Thanks, -- Matthias [1]: https://fr.wikipedia.org/wiki/Gibiane <https://fr.wikipedia.org/wiki/Gibiane> [2]: but not the worse IMHO. [3]: http://www.bloombergview.com/articles/2015-08-18/how-a-ban-on-plastic-bags-c... <http://www.bloombergview.com/articles/2015-08-18/how-a-ban-on-plastic-bags-c...>
On Fri, Sep 4, 2015 at 9:26 AM, Matthias Bussonnier <bussonniermatthias@gmail.com> wrote:
Another opinion based on some experience: I use local-language names when teaching beginners. It gives a nice distinction between names provided by Python or a library (in English) and things that can be named arbitrarily. I haven't actually measured if this helps learning, though; and to the turtle module it might not apply at all.
I'm agree with Matthias: IT world is mostly English based. It's "sad" for non native English speakers like me because you must learn English before to work in IT. However, the positive side effect is that we can speak together in the common language. Ludovic Gasc (GMLudo) http://www.gmludo.eu/ On 4 Sep 2015 09:26, "Matthias Bussonnier" <bussonniermatthias@gmail.com> wrote:
On Fri, Sep 04, 2015 at 01:34:16PM +0200, Ludovic Gasc wrote:
I'm agree with Matthias: IT world is mostly English based.
Fortunately for the 95% of the world who speak English as a second language, or not at all, that is changing. For example, StackOverflow has a very successful Brazilian site, and they make the case for non-English speakers well: https://blog.stackexchange.com/2014/02/cant-we-all-be-reasonable-and-speak-e... Rather than just repeat what they say there, I will just ask everyone to read it. -- Steve
Thank you for the link, it's interesting. However, my remark it's mainly for the source code: Even if I sincerely think it's better to handle English the most possible you can, I see no issues to discuss about source code in your native language: I speak myself in French when I interact with French developers only in my company. Nevertheless, for the content of the source code or database structure, at least to me, you must write in English: I've already analysed source code in Dutch, it was a lot more complicated to understand the code, I've lost a lot of time for nothing. The world is now global and dev resources are enough rare to avoid to lock your source code content in a local language. See for example the big work of LibreOffice to translate German comments: https://wiki.documentfoundation.org/Development/Easy_Hacks/Translation_Of_Co... With a localized turtle, you should give a bad habit at the beginning. -- Ludovic Gasc (GMLudo) http://www.gmludo.eu/ 2015-09-04 14:18 GMT+02:00 Steven D'Aprano <steve@pearwood.info>:
I do agree with the comments of Ludovic about the source code, Python is in English, the code for an open source project is international, and in this case, I prefer English. In the past, I have seen some databases in french, with the accents é, è, ç in the columns of the database, that’s really ugly :/ because if you forgot the encoding in the database, you will have a problem. Yesterday, I have read a source code in Dutch, sorry but if you don’t know this language, good luck if you want to change the code. And an other example, the comments in the code of the EuroPython site is in Italian, ok, the project has been developed for PyCon Italia, but now, we are a lot of international developers on this code, and sincerely, I can speak Italian but not everybody. Sincerely, English for the code and the database! On 4 Sep 2015, at 21:56, Ludovic Gasc wrote:
-- Stéphane Wirtel - http://wirtel.be - @matrixise
I completely agree that Python and codebases already in English should remain in English. And I want the source code for turtle.py to stay in English as well. This is where the gray area for Turtle begins though. Turtle is not for professional developers, where the English expectation is there. It is used for school kids to program in, and this code will most likely be forgotten about a week after the programming assignment is done. And in a sense, turtle.py is not used as a module by kids so much as an app (albeit a scriptable one) that moves the turtle around and draws shapes. The language barrier is a very real one for non-technical instructors, parents, and students. If we could minimize it down to less than a dozen Python keywords & names (import turtle, for, in, range, while, if, else) that would be a significant gain for Python's reach. And I don't think it would be much technical debt for turtle.py. I hope to have a complete translated set soon so I can submit a patch that shows how light of a change this would be. -Al On Fri, Sep 4, 2015 at 1:02 PM, Stéphane Wirtel <stephane@wirtel.be> wrote:
Al Sweigart writes:
I don't see why you would want any non-localized identifiers (modules, functions) at all in the base feature set. So you can (and I think should) drop range and turtle. I don't see any point in discussing the keywords here -- they are what they are. If a student decides to use something weird like "continue" or "try ... finally" it will work. Of course, the recommended set of syntaxes and their associated keywords matter a lot pedagogically, but we can leave that discussion to the pedagogues. When you're wearing your pedagogue hat and actually writing the style guide for teaching programming using turtle, then those interested can talk about that. Or maybe that should be left to experimentation. Some teachers may prefer to avoid "while condition: suite" in of "for i in iterable: if condition: suite". (Normally that would be nuts, of course, but here you could reduce the base set of keywords and syntaxes by one each.) There may be reasons why advanced users (and teachers) might want to use "non-base" facilities. There it's possible to do things like
which allows teachers to add any extensions they like conveniently, albeit verbosely. I still think an i18n-based architecture is the way to go, to minimize such boilerplate (error-prone for translators) among other reasons. Neither users nor translators need to see it, unless they want to see "how'd they do that?" In which case, isn't more "educational" to show them the way it's done in the real world?
On 5 September 2015 at 16:46, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Sorting out such procedural questions *iteratively* is one of the reasons I think it's desirable to pursue this externally first. There are a *lot* of possible options here, including using a full translation platform like Zanata or Pootle to manage the interaction with translators, and also a need to allow teachers of students that aren't native English speakers to easily try out the revised module *before* we commit to adding it to CPython. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04.09.2015 13:34, Ludovic Gasc wrote:
This argument does not fit for students at K4-level so programming4all will not work. When constructing Ponto.py, (remote control for OpenOffice.org and LibreOffice via Python) we decided to write PontoE.py to enable students with English to use it, but also PontoD.py to use those classes, which are German-based - because of the bavarian textbooks for Informatik at the age of 11, which use German identifiers for classes, attributes and methods. You may take a look at to get a glimpse, how we dealt in automating the process to get the http://www.ham.nw.schule.de/pub/bscw.cgi/100606 The README.txt points out how the process it managed. Our actual approach without »internationalisierung« for Python3: http://www.ham.nw.schule.de/pub/bscw.cgi/2131956 TNX Ludger - -- https://twitter.com/n770 http://ddi.uni-wuppertal.de/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlXpjEYACgkQJQsN9FQ+jJ9gggCgiCO4V7oDF9QSFcoMkhd3GarW 1S8Ani7a5F7TlPe982q7ggWlGOTy5z0h =MpyW -----END PGP SIGNATURE-----
On Friday, September 4, 2015 at 12:56:33 PM UTC+5:30, Matthias Bussonnier wrote:
Hi all,
Personal opinion, base by a bit of experience:
And my personal experience from the (an) other side: Some students of mine worked to add devanagari to python: https://github.com/rusimody/l10Python [Re-copying something here from a post on dev list What I would wish to add is tl;dr at bottom ] Here's an REPL-session to demo: [Note १२३४५६७८९० is devanagari equivalent of 1234567890] -------------------------------------------------- Python 3.5.0b2 (default, Jul 30 2015, 19:32:42) [GCC 4.9.2] on linux Type "help", "copyright", "credits" or "license" for more information.
The last is actually more an embarrassment than the δ breaking since they’ve *changed the lexer* to read the Σ when all that was required was Σ = sum !! In short... Kids! tl;dr For me (yes an educated Indian) English is a natural first language However the idea that English is the *only* language is about as quaint the idea that the extent of the universe is as vast as a 100 kilometers with Garden of Eden in the center. Our tiny experience with internationalizing python showed us that the lexer (at least) is terribly ASCII centric My immediate wish-list: Modularize the lexer into a pre-lexer converting UTF-8 to unicode codepoint followed by a pure unicode 32-bit codepoint based lexer My long-term wishlist (yeah somewhat unrealistic and utopian) for python 4000 is the increased awareness that the only reasonable international language is mathematics. Or http://blog.languager.org/2014/04/unicoded-python.html
On Sat, Sep 5, 2015 at 4:01 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
If someone's just learning to program, surely s/he can learn on Python 3 rather than Python 2. If localized names aren't available on Py2, so be it. (For the record, I would be in favour of it being on PyPI. I just don't think that "Python 2.7" is sufficient argument for that.) ChrisA
Chris Angelico writes:
If someone's just learning to program, surely s/he can learn on Python 3 rather than Python 2.
In any case, I could replace "2.7" with the (not yet released!) "3.5". 'nuff said, yet?<wink /> Anyway, "learn with Python 3" is what we advocate, but the reality is otherwise in some places, and many platforms (eg, Mac). None of my students download Python 3 until I tell them to. They thought the system Python would be as "up to date" as the "Retina" display! I wouldn't be surprised if there aren't a lot of Mac systems in schools where many teachers just use the Python that is already there, and are far more likely to "pip tortuga" than they are to install a whole parallel Python 3.
First, does this proposal actually come from a non-English teacher, or someone who's talked to them, or is it just a guess that they might find it nice? Meanwhile: On Sep 3, 2015, at 19:45, Steven D'Aprano <steve@pearwood.info> wrote:
Of course a sizable chunk of those say "my Python didn't come with pip" and the after a bit of exploration you find that they're using Python 2.7.3 or something, so any feature added to Python 3.6 isn't likely to help them anyway. And that seems like a good argument to add it to PyPI even if it's also added to the stdlib. Sure, for some teachers it'll be easier to just require 3.6 than to require a particular package. But I'm guessing both will be problematic in different cases. For example, if the school is issuing students linux laptops that come with Python 3.4, would explaining apt-get, and getting permission from the IT department for it, is probably harder, not easier, than pip.
On Fri, Sep 04, 2015 at 12:18:52AM -0700, Andrew Barnert wrote:
You say "of course", but did you actually look at the python-list archives? If you do, you will see posts like these two within the last 24 hours: [quote] I am running Python 3.4 on Windows 7 and is facing [Error 13] Permission Denied while installing Python packages... [end quote] and: [quote] Well I have certainly noted more than once that pip is contained in Python 3.4. But I am having the most extreme problems with simply typing "pip" into my command prompt and then getting back the normal information on pip! [end quote] And a random selection of other issues which I just happen to still have visible in my news reader: [quote] Python 2.7.9 and later (on the python2 series), and Python 3.4 and later include pip by default. But I can not find it in python2.7.10 package. What's the matter? How can i install pip on my Embedded device? [end quote] [quote] I've installed a fresh copy of Python 3.5.0b2 and - as recommended - upgraded pip. I don't understand the reason for the permission errors as I am owner and have full control for the temporary directory created. [end quote] [quote] I was fed up with trying to install from pypi to Windows. Setup.py more often than not wouldn't be able to find the VS compiler. So I thought I'd try the direct route to the excellent Christoph Gohlke site at http://www.lfd.uci.edu/~gohlke/pythonlibs/ which is all whl files these days. However as you can see below despite my best efforts I'm still processing the tar.gz file, so what am I doing wrong? [end quote] (Some spelling errors and obvious typos corrected.) Please don't dismiss out of hand the actual experience of real users with pip. At least one of those quotes above is from a long-time Python regular who knows his way around the command line. This is not meant as an anti-pip screed, so please don't read it as such. But it is meant as a reminder that pip is not perfect, and that even experienced Python developers can have trouble installing packages. Children with no experience with the command line or Python can not be expected to install packages from PyPI without assistence, and if they are using school computers, they simply may not be permitted to run "pip install" even if it worked flawlessly. -- Steve
I find it really annoying when people pick one sentence out of a post to argue against at length, out of context. while entirely ignoring the actual substance of the post. Are you sincerely arguing that no children out there will have Python 3.5, 3.3, or 2.7, or that for all such student upgrading to 3.6 will be easier and face fewer permissions problems than using pip? If not, then how does this answer my point that some people will want this on PyPI even if it's in the 3.6 stdlib? Sent from my iPhone
I see your point. I think there are two different arguments here: It would be good to have non-English turtle modules of PyPI for older versions of Python. But it would also be good to have non-English names added to the turtle module in the 3.6 stdlib. My main concern was that if these modules were on PyPI, they would be left out of the standard library. Then the "install from PyPI headache" arguments would apply. -Al On Fri, Sep 4, 2015 at 2:05 PM, Andrew Barnert via Python-ideas < python-ideas@python.org> wrote:
On Sep 4, 2015, at 14:43, Al Sweigart <asweigart@gmail.com> wrote:
I see your point. I think there are two different arguments here: It would be good to have non-English turtle modules of PyPI for older versions of Python. But it would also be good to have non-English names added to the turtle module in the 3.6 stdlib.
My main concern was that if these modules were on PyPI, they would be left out of the standard library. Then the "install from PyPI headache" arguments would apply.
I understand, but I think that concern is misplaced. Having something on PyPI generally makes it easier, not harder, to get it into the stdlib. And it's also useful on its own, because not everyone has 3.6. The problem is that it seems like the obvious way to design the PyPI version and the stdlib version would be pretty different (unless you want to explain to novices how to install backports packages and import things conditionally). But hopefully someone can come up with a good solution to that?
On 5 September 2015 at 07:43, Al Sweigart <asweigart@gmail.com> wrote:
The last major upgrade to turtle was the adoption of Gregor Lindl's xturtle for 2.6 as the standard turtle implementation, and he iterated on that as an external project for a while first. I think this is another case where a similar approach would work well - you could create a new "eduturtle" project as a fork of the current turtle module to allow more rapid iteration and feedback from educators unconstrained by the standard library's release cycle, and then propose it for default inclusion in 3.6. Another potentially desirable thing that could be explored within such a "turtle upgrade" project is switching it to using a HTML5 canvas as its drawing surface, rather than relying on Tkinter. We made a similar change a while ago with PyDoc, and while the pages generated by the local web service could definitely use some TLC from a front-end designer, I think it was a good call. That "HTML5-compatible-browser-as-GUI-framework" model is also the way IPython Notebook went for data analysis, and it unlocks an incredibly rich world of visualisation capabilities, that are not only useful in full browsers, but also in HTML widgets in desktop and mobile GUI frameworks. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Sep 04, 2015 at 02:05:05PM -0700, Andrew Barnert wrote:
Your post was three rather short paragraphs. I ignored the first paragraph because it had nothing to do with me, and I don't know the answer. I didn't respond to the third paragraph because I thought the conclusion (that getting permission to install pip would be easier than getting the most up-to-date version of Python installed) was unlikely at best, but regardless, you used enough weasel words ("seems like ... I'm guessing ... is probably ...") that it would be churlish to argue. Who knows? Yes, there could be some teachers who get permission for their students to install anything they like with pip but aren't allowed to upgrade to the latest version of Python. It's a big world and IT departments sometimes appear to choose their policies at random. I focused on the second paragraph because that was the comment you made that I want to respond to, namely that a sizeable chunk of problems with pip is that pip isn't installed. To reiterate, I don't believe that is the case, based on what I see on the python-list mailing list. Judging by the comments in the "packaging" subthread, this may have hit a chord with at least some others.
Are you sincerely arguing that no children out there will have Python 3.5, 3.3, or 2.7,
No.
or that for all such student upgrading to 3.6 will be easier and face fewer permissions problems than using pip?
For "all" of them? Probably not.
I didn't respond to that point. If you want me to respond, I'll say that I consider it unlikely that putting it on PyPI will be of much practical utility, given the user-base for turtle, but if people want to do both, it's not likely to do much harm either. -- Steve
Steven D'Aprano writes:
So let's fix it, already![1] Now that we have a blessed package management module, why not have a builtin that handles the simple cases? Say def installer(package, command='install'): ... where command would also take values 'status' (in which case package could be None, meaning list all installed packages, and 'status' might check for available upgrades as well as stating whether the package is known to this python instance), 'upgrade', 'install' (which might error if the package is already installed, since I envision installations taking place in the user's space which won't work for upgrading stdlib packages in a system Python, at least on Windows), and maybe 'remove'. I'm not real happy with the name "installer", but I chose it to imply that there is a command argument, and that it can do more than just install new packages. In general, I would say installer() should fail-safe (to the point of fail-annoying<wink/>), and point to the pip (and maybe venv) docs. It should also be verbose (eg, explaining that it only knows how to install for the current user and things like that). Footnotes: [1] This really is not relevant to the "localized turtle" thread. If the current situation is acceptable in general, it's not an argument for putting turtle localizations in the stdlib. If it's not acceptable, well, let's fix it.
On 5 September 2015 at 17:08, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Running "python -m pip" instead of "pip" already avoids many of the issues with PATH configuration, which is one of the reasons why that's what I recommend in the main Python docs at https://docs.python.org/3/installing/ & https://docs.python.org/2/installing/ Unfortunately, I've yet to convince the rest of PyPA (let alone the community at large) that telling people to call "pip" directly is *bad advice* (as it breaks in too many cases that beginners are going to encounter), so it would be helpful if folks helping beginners on python-list and python-tutor could provide feedback supporting that perspective by filing an issue against https://github.com/pypa/python-packaging-user-guide Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I do have this package[1] That allow you to do `pip install <....>` from within an IPython session and will call the pip of the current python by importing pip instead of calling a subprocess. One of the things I would like is for that to actually wrap pip on python.org-installed python, and conda on conda-installed python. So if such a proposal is integrating into Python, it would be nice to have hooks that allow to "hide" which package manager is used under the hood. -- M [1]: https://pypi.python.org/pypi/pip_magic On Sat, Sep 5, 2015 at 10:30 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 5 September 2015 at 09:30, Nick Coghlan <ncoghlan@gmail.com> wrote:
I would love to see "python -m pip" (or where the launcher is appropriate, the shorter "py -m pip") be the canonical invocation used in all documentation, discussion and advice on running pip. The main problems seem to be (1) "but just typing "pip" is shorter and easier to remember", (2) "I don't understand why pip can't just be a normal command" and sometimes (3) "isn't this just on Windows because you can't update pip in place on Windows" (no it isn't, but it's a common misconception of the issue). But I would agree with Nick, and recommend that anyone advising people on how to use pip, *especially* if you are helping them with issues, to always use "python -m pip" as the canonical command. If you need to explain why, say that this makes sure that you run pip from the correct Python interpreter, that's the basic point here. Paul
Paul Moore <p.f.moore@gmail.com> writes:
Contrariwise, I would like to see ‘pip’ become the canonical invocation used in all documentation, discussion, and advice; and if there are any technical barriers to that least-surprising method, to see those barriers addressed and removed.
The main problems seem to be (1) "but just typing "pip" is shorter and easier to remember",
With the concomitant benefit that it's easier to teach and learn. This is not insignificant.
(2) "I don't understand why pip can't just be a normal command"
This is my main objection, but rather stated as: We already have a firmly-established naming convention for user-level commands, that works in a huge number of languages; Python has no good reason to be an exception, especially not in one of the first commands that new users will need to encounter. If something is preventing ‘pip’ from being the command to type to run Pip, then surely the right place to apply pressure is not on everyone who instructs and documents and interfaces with end-users now and indefinitely; but instead on whatever is preventing the One Obvious Way to work. No? -- \ “Yesterday I saw a subliminal advertising executive for just a | `\ second.” —Steven Wright | _o__) | Ben Finney
On 9 September 2015 at 08:33, Ben Finney <ben+python@benfinney.id.au> wrote:
There is at least one fundamental, technical, and (so far) unsolveable issue with using "pip" as the canonical invocation. pip install -U pip fails on Windows, because the exe wrapper cannot be replaced by a process running that wrapper (the "pip" command runs pip.exe which needs to replace pip.exe, but can't because the OS has it open as the current running process). There have been a number of proposals for fixing this, but none have been viable so far. We'd need someone to provide working code (not just suggestions on things that might work, but actual working code) before we could recommend anything other than "python -m pip install -U pip" as the correct way of upgrading pip. And recommending one thing when upgrading pip, but another for "normal use" is also confusing for beginners. (And we have evidence from the pip issue tracker people *do* find this confusing, and not just beginners...) Apart from that issue, which is Windows only (and thus some people find it less compelling) we have also had reported issues of people running pip, and it installs things into the "wrong" Python installation. This is typically because of PATH configuration issues, where "pip" is being found via one PATH element, but "python" is found via a different one. I don't have specifics to hand, so I can't clarify *how* people have managed to construct such breakage, but I can state that it happens, and the relevant people are usually very confused by the results. Again, "python -m pip" avoids any confusion here - that invocation clearly and unambiguously installs to the Python installation you invoked. In actual fact, if it weren't for the backward compatibility issues it would cause, I'd be tempted to argue that pip shouldn't provide any wrapper at all, and *only* offer "python -m pip" as a means of invoking it (precisely because it's so closely tied to the Python interpreter used to invoke it). But that's never going to happen and I don't intend it as a serious proposal. Paul
On Wednesday, September 9, 2015 at 2:27:08 PM UTC+5:30, Paul Moore wrote:
The amount of grief pip is currently causing is IMHO good reason to prefer incompatible changes that remove breakage to try-n-please-everyone and keep breaking.
On Sep 9, 2015, at 01:56, Paul Moore <p.f.moore@gmail.com> wrote:
If StackOverflow/SU/TD questions are any indication, a disproportionate number of these people are Mac users using Python 2.7, who have installed a second Python 2.7 (or, in some cases, two of them) alongside Apple's. Many teachers, blog posts, instructions for scientific packages, etc. recommend this, but often don't give enough information for a novice to get it right. Many people don't even realize they already have a Python 2.7; others are making their first foray into serious terminal usage and don't think about PATH issues; others are following old instructions written for OS X 10.5 that don't do the right thing in 10.6, much less 10.10; etc. And even experienced *nix types who aren't Mac experts may not realize the implications of LaunchServices not being launched by the shell (so anything you double-click, schedule, run as a service, etc. won't see your export PATH that you think should be solving things). Even Mac experts are thrown by the fact that Apple's pre-installed Python is in /usr but has a scripts directory in /usr/local, so if you install pip for both Apple's Python and a second one, whichever one goes second is likely to overwrite the first (but that isn't as common as just having /usr/bin ahead of /usr/local/bin on the PATH--because Apple's Python doesn't come with pip, this is enough to have your highest pip and python executables out of sync). Whenever someone has a PATH question, I always start by asking them if they're on a Mac, and using Python 2.7, and, if so, which if any Python installs they've done, and why they can't use virtual environments and/or upgrade to Python 3.x and/or use the system Python. The vast majority say yes, yes, [python.org|Homebrew|the one linked from this blog post|I don't remember], what's a virtual environment, my [book|teacher|friend] says 2.7 is the best version, this blog post says [Apple doesn't include Python|Apple's Python is 2.7.1 and broken|etc.]. As both Python 3 and virtual environments become more common (at least as long as Apple isn't shipping Python 3 or virtualenv for their 2.7), the problem seems to be becoming less common, but it's still depressing how many people are still writing blog posts and SO answers and so on that tell people "you need to install the latest version of Python, 2.7, because your computer doesn't come with it" and then proceed to give instructions that will lead to a screwed up PATH and make no mention of virtualenv...
On September 9, 2015 at 5:22:57 PM, Andrew Barnert via Python-ideas (python-ideas@python.org) wrote:
Apple's Python doesn't come with pip
As of the latest Yosemite release, and in El Capitan, it *does* however come with Python 2.7.10 and thus ``python -m ensurepip`` works. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Hi, sorry to bother you again, but the search problem on PyPI is still present after different weeks and it's very annoying. I've just released a new version of my ldap3 project and it doesn't show up when searching with its name. For mine (and I suppose for other emerging project, especially related to Python 3) it's vital to be easily found by other developers that use pip and PyPI as THE only repository for python packages and using the number of download as a ranking of popularity of a project. If search can't be fixed there should be at least a warning on the PyPI homepage to let users know that search is broken and that using Google for searching could help to find more packages. Bye, Giovanni
Hi there, My 2.5 year old offer to retrofit the old codebase with a new search system still stands[1]. :) There is no reason for this to be a complex affair, the prototype built back then took only a few hours to complete. No doubt the long term answer is probably "Warehouse fixes this", but Warehouse seems no nearer a reality than it did in 2013. David [1] https://groups.google.com/forum/#!search/%22david$20wilson%22$20search$20pyp... On Thu, Sep 10, 2015 at 12:35:04AM +0200, Giovanni Cannata wrote:
Wouldn't it be better if you'd just build an external search service? Getting a list of packages and descriptions should be possible no? (just asking, not 100% sure) I doubt the maintainers are just going to come out and say "ok, this guy has waited long enough, lets take his contribution in". If they didn't care about the search 2.5 years ago why would they care now. Sorry for being snide here but my impression is that Warehouse could had been shipped a while ago instead of getting rewritten s everal times. I'm not saying that's bad, it's just that there's a mismatch in goals here. Thanks, -- Ionel Cristian Mărieș On Thu, Sep 10, 2015 at 2:01 AM, David Wilson <dw+python-ideas@hmmz.org> wrote:
On Sep 9, 2015, at 14:25, Donald Stufft <donald@stufft.io> wrote:
Sure, and all the way back to 10.5, you could just "easy_install pip". That never solved the problem of people who've been told to install a second Python 2.7 without any explanation of why or any consideration of what problems that might lead to; in fact, it just means they're even more likely to end up installing two colliding pips. I don't think there's much chance that anything Apple or the Python community does will get people to stop writing blog posts/class notes/installation web pages/SO answers/etc. to do this. There is a chance that proselytizing for virtualenv and/or Python 3 will make the problem irrelevant (and it already seems to be having that effect, just not as fast as would be ideal). Of course there will still be some people who really do need two Python 2.7 installations and aren't expert enough to manage it, and some people who manage to make a mess of things even with separate 2 and 3 or with venvs or with only Apple's Python. But, based on my (admittedly anecdotal) experience and my educated-guess-but-still-a-guess, I think it'll become not much more common than the equivalent problems for Fedora or Ubuntu or FreeBSD, which is a huge improvement.
Andrew Barnert via Python-ideas writes:
Often enough it's the other way around: the distro catches up to the user as they upgrade. I didn't even realize "10.10 Yosemite" had 2.7, this box has been upgraded from "10.7 Lion" or so, and I just use MacPorts 2.7 all the time. I haven't worried about what Apple supplies as /usr/bin/python in 6 or 7 years. I don't know if this matters to the effect on pip, but I thought it should be mentioned.
On Sep 9, 2015, at 20:32, Stephen J. Turnbull <stephen@xemacs.org> wrote:
No, that's not the problem. Lion came with 2.7.1, so you already had it before upgrading it, and it's hard to imagine Apple upgrading your system 2.7.1 to 2.7.6 or 2.7.10 broke anything. More likely, Apple screwed up your PATH, or broke your MacPorts so you had to reinstall or repair it?
I'd assume most people on this list know what they're doing with their PATH. If you don't, then you just got lucky for a few years. Well, not just lucky--MacPorts does go out of its way to make things easier for you in various ways (hammering home keeping /opt/local/bin at the the start of your PATH, trying to adjust the PATH system-wide and for LaunchServices as well as shells, providing many packages as ports so you don't need pip, offering a python-select tool that autodetects Apple and PSF Pythons and tries to make them play nice with MacPorts Pythons, etc.). So MacPorts users don't see such problems nearly as often as Homebrew (or Fink or Gentoo Prefix, if anyone still uses those), PSF installers, and third-party extra-batteries installers. But they still can come up--and if you didn't even realize you were running multiple Python 2.7 versions in parallel, that just means you never tried anything that MacPorts didn't anticipate. And, of course, most people with two Python 2.7s on Mac are not using MacPorts anyway.
Andrew Barnert writes:
I've had no problems with PATH, personally. I'm just saying that learning that pip was actually version-specific, and then getting the right pip for the current Python of interest, has been an annoyance for me over the years, and I was very happy to switch to "python -m pip" because it Just Works. As far as the question of order of installation, I just wanted to point out that system upgrades do sometimes catch up to the user, resulting in duplicate installations, rather than the user following some blog to the letter and installing a verson they don't need.
I'd assume most people on this list know what they're doing with their PATH. If you don't, then you just got lucky for a few years.
For me, PATH is easy. <python> -m pip is easy. <pip> is hard. :-/
No, it just means that since forever my personal PATH has been set up to give precedence to /usr/local/bin and /opt/local/bin, and since the days of Python 2 I avoid the system Python at all costs. Specifically, I never invoke Python without a full 2-digit version number (except in venvs), and my shebangs specify it too (ditto). (It works out to the same semantics as "not surprising MacPorts", of course.)
I teach an intro to python class, and have been advocating python/supporting users of python on OS-X for years. AND I am one those folks that advocates starting out by installing the latest Python2.7 (unless your going with 3). And I don't think I'm going to stop.
because your computer doesn't come with it"
But never for that reason, but because I don't think users SHOULD rely on the system Python on OS-X (and probably orher systems). You can google the reasons why -- you'll probably find a fair number of posts with my name on it ;-). Or, if that debate really is relevant to this discussion I could repeat it all here...
and then proceed to give instructions that will lead to a screwed up PATH
Well, I hope I don't do that ;-) -- in fact, the python.org installer has done a pretty nice job with its defaults for years -- the people that get messed up the ones that try to "fix" it be hand, when they don't know what they are doing (and very few people DO know what they doing with PATH on OS-X)
and make no mention of virtualenv...
OK, I do that ..... But quite deliberately. Virtualenv solves some problems for sure, but NOT the "I can't import something I swear I just installed" problem. in fact, it creates even MORE different "python" and "pip" commands, and a greater need to understand PATH, and what terminals are configured how, etc. So no, I don't introduce virtualenv to beginners. But I'll probably start teaching: python -m pip install ...... -Chris
On Wed, Sep 9, 2015 at 1:56 AM, Paul Moore <p.f.moore@gmail.com> wrote:
At the very least, surely this could be "fixed" by detecting this case and exiting with a message "Sorry, Windows is annoying and this isn't going to work, to upgrade pip please type 'python -m pip ...' instead"? That seems more productive in the short run than trying to get everyone to stop typing "pip" :-). (Though I do agree that having pip as a separate command from python is a big mess -- another case where this comes up is the need for pip versus pip3.)
It sounds like this is another place where in the short term, it would help a lot of pip at startup took a peek at $PATH and issued some warnings or errors if it detected the most common types of misconfiguration? (E.g. the first python/python3 in $PATH does not match the one being used to run pip.) -n -- Nathaniel J. Smith -- http://vorpus.org
Nathaniel Smith writes:
That seems more productive in the short run than trying to get everyone to stop typing "pip" :-).
FWIW, I did as soon as I realized python_i_want_to_install -m pip worked; it's obvious that it DTRTs, and I felt like I'd just dropped the hammer I'd been whacking my head with.
Ah, that's the name of my hammer, although it's come up in 3.2 vs 3.3 as well.
I don't understand the logic for trying to save the pip command by making its environment checking more complex than the app itself. "python -m pip" suffers from no problems that pip itself doesn't suffer from, and is far more reliable, without blaming the user. Sure, people used to using a pip command shouldn't be deprived of it, but I'll never miss it, and I don't see why anybody who isn't already using it would miss it. The only problem with "python -m pip" is discoverability/memorability, and the fact that interactive use of "from pip import main" is not properly supported IIUC (not to mention clumsy). Thus the proposal for a builtin named "install" or similar.
On Thu, Sep 10, 2015 at 1:25 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
If the problem with this is the verbosity of it ("python -m pip install packagename" - five words), would there be benefit in blessing pip with some core interpreter functionality, allowing either: $ python install packagename or $ python -p packagename to do the one most common operation, installation? (And since it's new syntax, it could default to --upgrade, which would match the behaviour of other package managers like apt-get.) Since the base command is "python", it automatically uses the same interpreter and environment as you otherwise would. It's less verbose than bouncing through -m. It gives Python the feeling of having an integrated package manager, which IMO wouldn't be a bad thing. Of course, that wouldn't help with the 2.7 people, but it might allow the deprecation of the 'pip' wrapper. Would it actually help? ChrisA
On Sep 9, 2015, at 21:32, Chris Angelico <rosuav@gmail.com> wrote:
What about leaving the pip wrapper, but having it display a banner telling people to use python -m pip (and maybe suggesting they add an alias to their profile, if not Windows) and then do its thing as it currently does. (Maybe with some way to suppress the message if people want to say "I know what I'm doing; if my PATH is screwy I'll fix it".) If we also add the python -p, it can instead suggest that if version >= (3, 6). That seems like an easier way to get the message out there than trying to convince everyone to spread the word everywhere they teach anyone, or deprecating it and leaving people wondering what they're supposed to do instead.
Nathaniel Smith <njs@pobox.com> writes:
Isn't that something that would be better in the Python executable itself? Many commands would be better with a (overridable) default behaviour as you describe. -- \ “Considering the current sad state of our computer programs, | `\ software development is clearly still a black art, and cannot | _o__) yet be called an engineering discipline.” —Bill Clinton | Ben Finney
On Wed, Sep 9, 2015 at 8:37 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
While that's debatable, any plan that only benefits users of python 3.6+ is a non-starter is a non-starter, given that the goal here is short-term harm reduction. -n -- Nathaniel J. Smith -- http://vorpus.org
On 9 September 2015 at 23:40, Nathaniel Smith <njs@pobox.com> wrote:
That's already done (without the unnecessary passive-aggressive sniping at Windows) and we still get users raising bugs because they didn't read the message, or because they misinterpreted something. As I said, we've tried lots of solutions. What we haven't had yet is anyone come up with an actual working PR that fixes the issue (in the sense of addressing the bug reports we get) better than the current code (if we had, we'd have applied the PR). Paul
On 9 September 2015 at 23:40, Nathaniel Smith <njs@pobox.com> wrote:
People (including the pip devs) have talked about this type of thing before. To my knowledge no-one has actually implemented it. Care to provide a PR for this? Paul
On 9 September 2015 at 17:33, Ben Finney <ben+python@benfinney.id.au> wrote:
We're doing that too, but it's a "teaching people to use the command line for the first time is hard" problem and a "managing multiple copies of a language runtime and ensuring independently named commands are working against the right target environment" issue, moreso than a language level one. A potentially more fruitful path is likely to be making it so that folks don't need to use the system shell at all, and can just work entirely from the Python REPL. The two main things folks can't do from the REPL at the moment are: * install packages * manage virtual environments The idea of an "install()" command injected into the builtins from site.py would cover the first. The second couldn't be handled the way virtualenv does things, but it *could* be handled through a tool like vex which creates new subshells and runs commands in those rather than altering the current shell: $ python3 Python 3.4.2 (default, Jul 9 2015, 17:24:30) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux Type "help", "copyright", "credits" or "license" for more information.
The "vex nikola python" call there: 1. Starts a new bash subshell 2. Activates my "nikola" virtual environment in that subshell 3. Launches Python within that venv (hence the jump over to a Python 2.7 process, since I keep forgetting to recreate it as Python 3). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Sep 11, 2015 at 1:55 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Hmm. This looks like something that could confuse people no end. I already see a lot of people use Ctrl-Z to get out of a program (often because they've come from Windows, I think), and this would be yet another way to get lost as to which of various Python environments you're in. Is it safe to have Python exec to another process? That way, there's no "outer" Python to be left behind, and it'd feel like a transition rather than a nesting. ("Please note: Selecting a virtual environment restarts Python.") (Incidentally, what _would_ happen if you pressed Ctrl-Z while in that 'inner' Python? Would both Pythons get suspended?) ChrisA
On 11 September 2015 at 02:30, Chris Angelico <rosuav@gmail.com> wrote:
Using subprocess.call() to invoke vex was something I could do without writing a single line of code outside the REPL. An actual PEP would presumably propose something with a much nicer UX :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Sep 11, 2015 at 3:03 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Heh, fair enough! Mainly, though, I'm wondering whether there'd be any risks to using os.exec* from the REPL - anything that would make it a bad idea to even consider that approach. ChrisA
On Sat, Sep 05, 2015 at 04:08:24PM +0900, Stephen J. Turnbull wrote:
Python competes strongly with R in the scientific software area, and R supports a built-in to do just that: https://stat.ethz.ch/R-manual/R-devel/library/utils/html/install.packages.ht... -- Steve
On September 5, 2015 at 11:40:17 AM, Steven D'Aprano (steve@pearwood.info) wrote:
I don't know anything about R, but a built in function is a bad idea. It'll be a pretty big footgun I believe. For instance, if you already have requests 2.x installed and imported, and then you run the builtin and install something that triggers requests 1.x to be installed you'll end up with your Python in an inconsistent state. You might even end up importing something from requests and ending up with modules from two different versions of requests ending up in sys.modules. In addition, the standard library is not really enough to accurately install packages from PyPI. You need a real HTML parser that can handle malformed input safely, an implementation of PEP 440 versions and specifiers (currently implemented in the "packaging" library on PyPI), you also need some mechanism for inspecting the currently installed set of packages, so you need something like pkg_resources available to properly support that. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
In reading this discussion with interest. pip and PyPI are what make the Python ecosystem live and vital. Especially PyPI is what surprises any Python newbie. A single repository freely available where to find valuable ready-to-use software, accessible from anywhere, it's hard to believe if you are, for example, a Java or .NET developer. But are you aware of the problems that PyPI is currently suffering? It's about two weeks that its searching engine is faulty and doesn't find many packages, even if they are available. This is a very bad thing because PyPI is the frontgate to the Python system for many people, more than the python.org site itself. I think that PyPI should deserve a special attention for the sake of the whole Python community. -------- Messaggio originale -------- Da:Donald Stufft <donald@stufft.io> Inviato:Sat, 05 Sep 2015 18:38:29 +0200 A:Steven D'Aprano <steve@pearwood.info>,python-ideas@python.org Oggetto:Re: [Python-ideas] High time for a builtin function to manage packages (simply)?
On September 5, 2015 at 2:03:46 PM, Giovanni Cannata (cannatag@gmail.com) wrote:
But are you aware of the problems that PyPI is currently suffering? It's about two weeks that its searching engine is faulty and doesn't find many packages, even if they are available.
I’m aware. I’m only one person and my plate is extremely full. I’ve poking at the problem to try and figure it out. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Hi Donald, you mean you're the only one in charge of maintaining PyPI? I'm sorry for this, I thought that a critical service like PyPI was supported by a team. I (and presume other developers) rely heavily on it. Maybe this should be brought to the attention of the PSF. -------- Messaggio originale -------- Da:Donald Stufft <donald@stufft.io> Inviato:Sat, 05 Sep 2015 20:05:53 +0200 A:python-ideas@python.org,Steven D'Aprano <steve@pearwood.info>,Giovanni Cannata <cannatag@gmail.com> Oggetto:Re: [Python-ideas] High time for a builtin function to manage packages (simply)?
On September 5, 2015 at 3:49:07 PM, Giovanni Cannata (cannatag@gmail.com) wrote:
Yes and No. I’m the primary developer/administrator for it now and it doesn’t get much contribution from others. It is also supported by the Python infrastructure team, but there is only a handful of us and I’m the only person on that team who has paid time to work on that and the Infrastructure team is also responsible for many other python.org services. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 6 September 2015 at 05:49, Giovanni Cannata <cannatag@gmail.com> wrote:
We're aware. PyPI is currently the *only* python.org service with a dedicated full time developer (and Donald's time is actually contributed by the OpenStack group at HP rather than being funded directly by the PSF). There are also a number of organisations that donate resources to operating the python.org infrastructure (e.g. the Fastly CDN, and hosting services from Heroku, Rackspace and the Open Source Lab at Oregon State University). Bringing paid development in to support community driven projects, while also ensuring financial sustainability and fiscally responsible management of contributor's funds is an interesting challenge, and one the PSF continues to work to get better at. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On September 6, 2015 at 8:20:54 PM, Nick Coghlan (ncoghlan@gmail.com) wrote:
I'm not exactly full time on PyPI either, though I am full time on packaging. I split my time between PyPI, pip, and any other related work that I need to. So PyPI (as important as it is) really only has part of my attention. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Sat, 5 Sep 2015 at 08:40 Steven D'Aprano <steve@pearwood.info> wrote:
The reason R has a built-in for this is because it's used a vast majority of the time from a REPL to do data analytics in an exploratory manner (think Jupyter notebook type of data exploration). Python does not have the same typical usage style and so I don't think we should follow R in this instance (although I have had R users says that packaging in R is far superior than Python due to ease of getting extensions installed period and not because of the lack of a function, but that's another discussion).
On 9/5/2015 3:08 AM, Stephen J. Turnbull wrote:
Because new builtins have a high threashold to reach, and this doesn't reach it? Installation is a specialized and rare operation. Because pip must be installed anyway, so a function should be in the package and imported? from pip import main (I realized that PM indepedence is part of the proposal. See below.) I think a gui frontend is an even better idea. The tracker has a proposal to make such, once written, available from Idle. https://bugs.python.org/issue23551 I was thinking that the gui code should be in pip itself and not idlelib, so as to be available to any Python shell or IDE. If it covered multiple PMs, then it might go somewhere in the stdlib. -- Terry Jan Reedy
On Sun, Sep 6, 2015 at 7:03 AM, Terry Reedy <tjreedy@udel.edu> wrote:
If there's a simple entry-point like that in an importable module, anyone who wants it as a builtin can simply pre-import it (this would be used interactively anyway). All it'd take would be a known function to import. ChrisA
On 9/5/2015 5:03 PM, Terry Reedy wrote:
Inspired by this thread, I did some experiments and am fairly confident that pip.main can be imported and used directly, bypassing paths, subprocesses, and pipes. -- Terry Jan Reedy
On Sun, Sep 6, 2015 at 12:04 PM, Terry Reedy <tjreedy@udel.edu> wrote:
I can confirm that this is, indeed, possible. I use this exact technique in my tool Briefcase to simplify the process of packaging code as an app bundle. https://github.com/pybee/briefcase/blob/master/briefcase/app.py#L108 Yours, Russ Magee %-)
On 9/6/2015 4:57 AM, Russell Keith-Magee wrote:
There *is*, however, a potential gotcha suggested on the issue by Donald Stufft and verified by me. pip is designed for one command (main call) per invocation, not for repeated commands. When started, it finds and caches a list of installed packages. The install command does not update the cached list. So 'show new_or_upgraded_package' will not work. Your series of installs do not run into this. -- Terry Jan Reedy
Terry Reedy writes:
In your opinion. And in mine! Personally, I don't have a problem with remembering python -m pip, nor do I have a problem with explaining it as frequently as necessary to my students But there are only 20 of them, rather than the thousands that folks like Steven (and you?) are dealing with on python-list -- and there's the rub. I'm suggesting this because of the vehemence with which Steven (among others) objects to any suggestion that packages belong on PyPI, and the fact that he can back that up with fairly distressing anecdotes about the number of beginner posts asking about pip problems. I would really like to see that put to rest.
Installation is a specialized and rare operation.
help(), quit(), and quit are builtins. I never use quit or quit() (Ctrl-D works on all the systems I use), so I guess they are "specialized and rare" in some sense, and I'm far more likely to use dir() and a pydoc HTML server than help(). More to the point, the trouble packaging causes beginners and Steven d'Aprano on python-list is apparently widespread and daily. At some point beginner-friendliness has enough value to make it into the stdlib and even builtins.
I don't pronounce that "install". Discoverability matters a lot for the users in question (which is why I'm not happy with "installer", but it's somewhat more memorable than "pip").
I think a gui frontend is an even better idea.
I think it's a great idea in itself. But IMO it doesn't address this issue because the almost but not really universally-available GUI is Tcl/Tk, which isn't even available in any of the four packaged Python instances I have installed (Mac OS X system Python 2.6 and 2.7, MacPorts Python 2.7 and 3.4, although IIRC MacPorts offers a tk variant you can enable, but it's off by default).
Obviously; it doesn't address the present issue if it's not ensured by ensure_pip. Which further suggests something like ensure_pyqt as well. (Or ensure_tk, if you think that perpetuating Tcl/Tk is acceptable.) I think that's a huge mess, given the size and messiness of the dependencies. I suppose a browser-based interface like that of pydoc could deal with the "universality" issue, but I don't know how fragile it is.
On Sep 6, 2015, at 18:51, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Tcl/Tk, and Tkinter for all pre-installed Pythons but 2.3, have been included with every OS X since they started pre-installing 2.5. Here's a brand new laptop that I've done nothing to but run the 10.10.4 update and other recommended updates from the App Store app: $ /usr/bin/python2.6 Python 2.6.9 (unknown, Sep 9 2014, 15:05:12) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.391)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import Tkinter >>> root = Tkinter.Tk() >>> That works, and pops up an empty root window. And it works with all python.org installs for 10.6 or later, all Homebrew default installs, standard source builds... Just about anything besides MacPorts (which seems to want to build Tkinter against its own Tcl/Tk instead of Apple's) Also, why do you think Qt would be less of a problem? Apple has at various times bundled Qt into OS X and/or Xcode, but not consistently, and even when it's there it's often set up in a way that you can't use it, and of course Apple has never include PyQt or PySide. So, if pip used Qt, a user would have to go to qt.io, register an account, figure out what they need to download and install, figure out how to make it install system-wide instead of per-user, and then repeat for PySide against each copy of Python they want to use. Either that, or pip would have to include its own complete copy of Qt and PySide.
Andrew Barnert writes:
My mistake, it's only MacPorts where I don't have it. I used MacPorts' all-lowercase spelling, which doesn't work in the system Python. (The capitalized spelling doesn't work in MacPorts.)
I recall having problems with trying to build and run against the system Tcl/Tk in both source and MacPorts, but that was a *long* time ago (2.6-ish). Trying it now, on my Mac OS X Yosemite system python 2.7.10, "root=Tkinter.Tk()" creates and displays a window, but doesn't pop it up. In fact, "root.tkraise()" doesn't, either. Oops. On this system, IDLE has the same problem with its initial window, and furthermore complains that Tcl/Tk 8.5.9 is unstable. Quite possibly this window-raising issue is Just Me. But based on my own experience, it is not at all obvious that ensuring availability of a GUI is possible in the same way we can ensure pip.
Also, why do you think Qt would be less of a problem?
I don't. I think "ensure PyQt" would be a huge burden, much greater than Tkinter. Bottom line: IMO, at this point in time, if it has to Just Work, it has to Work Without GUI. (Modulo the possibility that we can use an HTML server and borrow the display engine from the platform web browser. I think I already mentioned that, and I think it's really the way to go. People who *don't* have a web browser probably can handle "python -m pip ..." without StackOverflow.)
On 9/7/2015 3:26 AM, Stephen J. Turnbull wrote:
My impression is that MacParts builds Tkinter 8.6 instead of 8.5.
Mac users who download the PSF Mac installer and want to use tkinter should read https://www.python.org/download/mac/tcltk/ Before the redesign, there was a link to this from the download page, but the redesign seems to have removed it. The page mentions that there may be a window update problem with the apple tk. -- Terry Jan Reedy
Terry Reedy writes:
My impression is that MacParts builds Tkinter 8.6 instead of 8.5.
If you mean that MacPorts' current Tcl and Tk ports install Tcl/Tk 8.6, that is correct.
The page mentions that there may be a window update problem with the apple tk.
It also mentions that various Tk versions "in common use" are unsupported by the python.org-installed Python, and in particular not the Cocoa Tk. I suppose it's not hard to do that? Or maybe chances are that the X11 and Cocoa Tks "just work", but aren't tested for the Mac installers?
On Sep 7, 2015, at 04:33, Stephen J. Turnbull <stephen@xemacs.org> wrote:
It's not just a matter of "not tested"; there are actual glitches with some of the versions, including two pretty serious ones that can lead to a freeze, or to some window management commands being ignored. But once you have some experience with it, and enough test machines of course, it's not actually that hard to build a binary-shippable GUI app that avoids all of these problems and runs against any of Apple's Tk versions from 10.6+ and against the Python.org recommended versions (which I know, because I've done it, at least with Python 2.7 and 3.3). Making it work reliably from the REPL, or for a script that's not wrapped as a .app, is definitely a lot less fun. But people who want to install from within the REPL or the system shell probably don't want the GUI. I don't know about making it work reliably from within IDLE. I don't see any reason IDLE couldn't just launch a .app on Mac if that's a problem, but you have to remember the extra fun bit that the app will get its environment from LaunchServices, not IDLE, so you'd need some other way to tell it to use the current venv. (Possibly this just means the app is linked into the venv?)
I just found this HTML web-based pip interface: Stallion "easy-to-use Python Package Manager interface with command-line tool" * http://perone.github.io/stallion/ * https://pypi.python.org/pypi/Stallion Qt would not be a reasonable requirement; Tk shouldn't be a requirement. I tend to try and work with repeatable CLI commands; rather than package manager GUIs. On Sep 7, 2015 2:26 AM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
On Sat, Sep 05, 2015 at 05:03:36PM -0400, Terry Reedy wrote:
You're right about the first part, but as Chris has already suggested, this need not be *literally* a built-in. Like help() it could be imported at REPL startup. And I'm not really so sure about how rare it is. Sure, installing a single package only happens once... unless you're installing it to multiple installations. Or upgrading the package. Or installing more than one package. Looking at questions on various programming forums, including Python but other languages as well, "how do I install X?" is an extremely common question. And, with the general reluctance to add new packages to the stdlib, and the emphasis on putting them onto PyPI first, I think that it will become even more common in the future.
As I see it, there are three high-level steps to an awesome installer: 1. Have an excellent repository of software to install; 2. have a powerful interactive interface to the repo that Just Works; 3. add a GUI interface. I think that with PyPI we certainly have #1 covered, but I don't think we have #2 yet, there are still too many ways that things can "Not Work". Number 3 is icing on the cake - it makes a great system even better. I didn't specify whether the interactive interface should be a stand-alone application like pip, or an command in the REPL like R uses, or even both. I like the idea of being able to install packages directly from the Python prompt. It works well within R, and I don't see why it wouldn't work in Python either. But it isn't much of an imposition to run "python -m pip ..." at the shell. -- Steve
On Sep 6, 2015, at 19:18, Steven D'Aprano <steve@pearwood.info> wrote:
Personally, I've never found ^Zpython -m pip spam && fg too hard (or just using ! from IPython), but I can understand why novices might. :) Anyway, the problem comes when you upgrade (directly or indirectly) a module that's already imported. Reloading is neither easy (especially if you need to reload a module that you only imported indirectly and upgraded indirectly) nor fool-proof. When I run into problems, I usually don't have much trouble stashing any costly intermediate objects, exiting the REPL, re-launching, and restoring, but I don't think novices would have as much fun. Is there a way the installer could, after working out the requirements, tell you something like "This command will upgrade 'spam' from 1.3.2 to 1.4.1, and you have imported 'spam' and 'spam.eggs' from the package, so you may need to restart after the upgrade. Continue?" That might be good enough. It's not exactly an everyday problem, so as long as it's visible when it's happened and obvious how to work around it so users who run into it for the first time don't just decide Python or pip or spam is "broken" and give up, that might be sufficient. (And a GUI installer integrated into IDLE would presumably have no additional problems, and could make the experience even nicer--especially since it's already got a "Restart Shell" option built in.)
On Mon, Sep 7, 2015 at 1:17 PM, Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
Anyway, the problem comes when you upgrade (directly or indirectly) a module that's already imported. Reloading is neither easy (especially if you need to reload a module that you only imported indirectly and upgraded indirectly) nor fool-proof. When I run into problems, I usually don't have much trouble stashing any costly intermediate objects, exiting the REPL, re-launching, and restoring, but I don't think novices would have as much fun.
Is there a way the installer could, after working out the requirements, tell you something like "This command will upgrade 'spam' from 1.3.2 to 1.4.1, and you have imported 'spam' and 'spam.eggs' from the package, so you may need to restart after the upgrade. Continue?" That might be good enough. It's not exactly an everyday problem, so as long as it's visible when it's happened and obvious how to work around it so users who run into it for the first time don't just decide Python or pip or spam is "broken" and give up, that might be sufficient.
How often does pip actually need to upgrade an already-installed package in order to install something you've just requested? Maybe the rule could be simpler: if there are any upgrades at all, regardless of whether you've imported from those packages, recommend a restart. The use-case I'd be most expecting is this:
In the uncommon case where spam depends on ham v1.4.7 or newer *AND* you already have ham <1.4.7 installed, a simple message should suffice. (Oh, and you also have to not have any version of spam installed already, else you won't be able to use install() anyway.) ChrisA
On September 6, 2015 at 11:26:04 PM, Chris Angelico (rosuav@gmail.com) wrote:
Due to the nature of ``pip install --upgrade``, it's fairly common. At this time ``pip install --upgrade`` is "greedy" and will try to upgrade the named package and all of it's dependencies, even if their is already a version of the dependency installed that satisfies the version constraints. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Sep 6, 2015 9:09 PM, "Chris Angelico" <rosuav@gmail.com> wrote:
On Mon, Sep 7, 2015 at 2:05 PM, Donald Stufft <donald@stufft.io> wrote:
On September 6, 2015 at 11:26:04 PM, Chris Angelico (rosuav@gmail.com)
wrote: this
FWIW the recursive behaviour of --upgrade is perhaps the single most hated feature of pip (almost all scientific packages find it so annoying that they refuse to provide dependency metadata at all), and AFAIK everyone has agreed to deprecate it in general and replace it with a non-recursive upgrade command, just no-one has gotten around to it: https://github.com/pypa/pip/issues/59 So I wouldn't worry about defining special interactive semantics in particular, someone just has to make the patch to change it in general :-) The trickier bit is that I'm not sure there's actually any way right now to know what python packages were affected by a given install or upgrade command, because it can be the case that after 'pip install X' you then do 'import Y' -- the wheel and module names don't have to match, and in practice it's not uncommon for there to be discrepancies. (For example, after 'pip install matplotlib' you can do both 'import matplotlib' and 'import pylab'.) -n
On Sep 6, 2015, at 20:25, Chris Angelico <rosuav@gmail.com> wrote:
Not that often, which is why I said "It's not exactly an everyday problem"; just often enough that some novices are going to run into it once or twice, so it can't be ignored.
I suppose that's possible too. It's overzealous, but it still won't happen _that_ often, so if my suggestion is too much work, this one seems fine to me. Especially if the message made the issue clear, something about "After an upgrade, you should restart, because any packages you already imported may be unchanged or inconsistent".
On 7 September 2015 at 12:18, Steven D'Aprano <steve@pearwood.info> wrote:
Technically it's "import site" that injects those - you have to run with "-S" to prevent them from being installed: $ python3 -c "quit()" $ python3 -Sc "quit()" Traceback (most recent call last): File "<string>", line 1, in <module> NameError: name 'quit' is not defined Regardless, I agree a "site builtin" like help() or quit() is a better option here than a true builtin, and I also think it's a useful idea. I'd make it simpler than the proposed API though, and instead just offer an "install(specifier)" API that was a thin shell around pip.main: try: import pip except ImportError: pass else: def install(specifier): cmd = ["install"] if sys.prefix == sys.base_prefix: cmd.append("--user") # User installs only when outside a venv cmd.append(specifier) # TODO: throw exception when there's a problem pip.main(cmd) If folks want more flexibility, then they'll need to access (and understand) the underlying installer. As far as other possible objections go: * the pkg_resources global state problem we should be able to work around just by reloading pkg_resources (if already loaded) after installing new packages (I've previously tried to address some aspects of that particular problem upstream, but doing so poses significant backwards compatibility challenges) * I believe integration with systems like conda, PyPM, and the Enthought installer should be addressed through a plugin model in pip, rather than directly in the standard library * providing a standard library API for querying the set of installed packages independently of pip is a separate question Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Friday, September 4, 2015 at 10:57:42 PM UTC+5:30, Steven D'Aprano wrote:
Packaging systems suffer from a Law: The quality of the packaging-system is inversely proportional to the quality of the language being packaged [Corollary to the invariable NIH syndrome that programmers suffer from] Notice: Haskell' hackage : Terrible Python's pip: Bad Ruby's gems: Ok Perl's CPAN : Good Debian's apt (mishmash of perl, shell and other unspeakbles) : Superb
Steven D'Aprano writes:
On Fri, Sep 04, 2015 at 11:05:51AM +0900, Stephen J. Turnbull wrote:
And? The objection will still be made. And I doubt Guido will agree that typing is a precedent that can be used to justify inclusion of turtle localizations. He might very well be in favor AFAIK, I just doubt he would base that on the precedent of typing. The rest of your post I don't really agree with, but I have no strong counterarguments, either. Here I just wanted to point out that the way these discussions have gone in the past is that without special support from the BDFL, the usual path for these things is through PyPI. Especially since AFAICT we don't actually have an implementation yet. Steve
On 4 September 2015 at 12:45, Steven D'Aprano <steve@pearwood.info> wrote:
Block based languages are to text based ones as picture books are to the written word - to get the combinatorial power of language into play, you need to be learning systems that have the capacity to be self hosting. You can write a Python interpreter in Python, but you can't write a Scratch environment in Scratch. This is reflected in the way primary schools digital environment curricula are now being designed - initial concepts of algorithms and flow control can be introduced without involving a computer at all (e.g. through games like Robot Turtles), then block based programming in environments like Scratch introduce the use of computers in a way that doesn't require particularly fine motor control or spelling skills. However, a common aspect I've seen talking to teachers from Australia, the US and the UK is that the aim is always to introduce kids to the full combinatorial power of a text based programming environment like Python, since that's what unlocks the ability to use computers to manipulate real world data and interfaces, rather than just a local constrained environment like the one in Scratch. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Sep 4, 2015 at 8:55 AM, Petr Viktorin <encukou@gmail.com> wrote:
+1. These modules could simply import a boatload of stuff from "turtle" under new names, which would make them fairly slim. Question: Should they start with "from turtle import *" so the English names are always available? It'd ensure that untranslated names don't get missed out, but it might be confusing. ChrisA
Chris Angelico writes:
That would be pretty horrible, and contrary to the point of allowing the new user to learn algorithmic thinking in a small world using intuitively named commands. I would think the sensible thing to do is to is invite participation from traditional translation volunteers with something like import turtle from i18n import _ _translations = { 'turtle' : _('turtle'), ... } for name in dir(turtle): if name in _translations: eval("from turtle import {} as {}".format(name, _translations[name])) elif english_fallbacks_please: eval("from turtle import {}".format(name))
On Fri, Sep 4, 2015 at 12:34 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Yeah, that'd be better than including all the original English names. And _translations can be generated easily enough: import turtle print("{" + ", ".join("%r: _(%r)" % (n, n) for n in dir(turtle)) + "}") Though the diffs would be disgusting any time anything in turtle changes. ChrisA
On Thu, Sep 3, 2015, at 16:53, Al Sweigart wrote:
https://github.com/asweigart/idle-reimagined/wiki/Turtle-Translations
A couple of downsides I noticed: "The names will later be formatted to fit the code style of the turtle module. " is a bit handwavy, to be honest. Are things like "de la" required or optional? Should an apostrophe/space/hyphen become an underscore or be omitted? What can be abbreviated? What case/inflection/conjugation should be used? These are decisions that have to be made by native speakers based on what will be understandable to beginners who know each language. Your names aren't very consistent - I don't know French that well, but I doubt the module would benefit from mixing "plume", "crayon", and "stylo". What to call a pen needs to be decided at a high level and used globally. Also, things like "set...", "get...", "on...", need to be translated to something consistent throughout the module. For that matter, the naming conventions in the *English* ones are a bit questionable and inconsistent. Maybe this is an opportunity to clean up that API. Also, a bug to report: I know enough Spanish to know that "pantalla clara" means "clear screen" as a noun [screen that is clear], not a verb [clearing the screen]. The English is ambiguous, but most other languages are not. For design questions: Is it important to hide the English names? Is it important to be able to use the classes interchangeably to code that is written to use a different language's method names? Can the same name in one language ever translate to two different names in another language depending on context?
On Thu, Sep 3, 2015 at 11:27 PM, <random832@fastmail.us> wrote:
I would not be surprised if, among all languages in the world, there'd be a clash in one of turtle's attribute names. Why put everything in the same namespace? It might be better to use more of those – perhaps something like "from turtle.translations import tortuga" ("tortuga" being Spanish for turtle). That is probably too long, so why not just "import tortuga"? That "tortuga" module could live on PyPI for a while, before it's considered for addition to either the stdlib, or just the installers.
Just to reply to both Petr and Random832 at once: By "formatted to fit the code style of the turtle module" I meant that the names would be pushed together without camelcase or underscores (as they are already done in the turtle module). But you do bring up good points. Whether things like "de la" are omitted or how things can be abbreviated is left entirely up to the native speaker doing the translation. I don't see any way around it. But, as a rough guide, the Scratch tool has already done lots of translation work and translators can piggy back off their wording choices. The turtle module has been around long enough that I already see it's API as set in stone, for better or worse. If the English names should be changed, I see that as a separate issue. I don't see a reason to hide the English names. I want the names to be available without additional setup, i.e. there is no "language" setting that needs to be specified first. The fewer setup steps the better. All names in all languages would be available. I don't see being able to mix, say, English and Spanish names in the same program as a big enough problem that we have to force a fix to prevent it. I'd like to keep the setup as simple and as similar to existing code as possible. There is a slight difference between "import x" and "from x import x" and I'd want to avoid that. From a technical perspective, I don't think the additional names will hinder the maintenance of the turtle module (which rarely changes itself). Though I'll know for sure what the technical issues are, if any, once I produce the patch. The idea for putting these modules on PyPI is interesting. My only hesitation is I don't want "but it's already on PyPI" as an excuse not to include these changes into the standard library turtle module. -Al On Thu, Sep 3, 2015 at 3:55 PM, Petr Viktorin <encukou@gmail.com> wrote:
On Fri, Sep 04, 2015 at 11:05:51AM +0900, Stephen J. Turnbull wrote:
*cough typing cough* The turtle module has been in Python for many, many years. This proposal doesn't change the functionality, it merely offers a localised API to the same functionality. A bunch of alternate names, nothing more. I would argue that if you consider the user-base of turtle, putting it on PyPI is a waste of time: - Beginners aren't going to know to "pip install whatever". Some of us here seem to think that pip is the answer to everything, but if you look on the python-list mailing list, you will see plenty of evidence that people have trouble using pip. - Schools may have policies against the installation of unapproved software on their desktops, and getting approval to "pip install *" may be difficult, time-consuming or outright impossible. If they are using Python, we know they have approval to use what is in the standard library. Everything else is, at best, a theorectical possibility. One argument against this proposal is that Python is not really designed as a kid-friendly learning language, and we should just abandon that space to languages that do it better, like Scratch. I'd hate to see that argument win, but given our limited resources perhaps we should know when we're beaten. Compared to what Scratch can do, turtle graphics are so very 1970s. But if we think that there is still a place in the Python infrastructure for turtle graphics, then I'm +1 on localising the turtle module. -- Steve
Thinking about it some more, yeah, having a separate module on PyPI would just be a waste of time. This isn't changing functionality or experimenting with new features, it's just adding new names to existing functions. And installing stuff with pip is going to be insurmountable barrier for a lot of computer labs. I'd say Python is very much a kid-friendly language. It's definitely much friendlier than BASIC. I'd advise against using the _() function in gettext. That function is for string tables, which is set up to be easily changed and expanded. The turtle API is pretty much set in stone, and dealing with separate .po files and gettext in general would be more of a maintenance headache. It is also dependent on the machine's localization settings. I believe some simple code at the end of turtle.py like this would be good enough: _spanish = {'forward': 'adelante'} # ...and the rest of the translated terms _languages = {'spanish': _spanish} # ...and the rest of the languages def forward(): # this is the original turtle forward() function print('Blah blah blah, this is the forward() function.') for language in _languages: for englishTerm, nonEnglishTerm in _languages[language].items(): locals()[nonEnglishTerm] = locals()[englishTerm] Plus the diff wouldn't look too bad. This doesn't prohibit someone from mixing both English and Non-English names in the same program, but I don't see that as a big problem. I think it's best to have all the languages available without having to setup localization settings. -Al On Thu, Sep 3, 2015 at 7:45 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Hi all, Personal opinion, base by a bit of experience: There is one thing worse than programming in a foreign language IMHO (I’m native french) It’s programming in an environment which is half translated and/or mix english and native language. The cognitive load and the context switching it forces the brain to do when 2 languages are present is absolutely astronomical, and i guess translating the Turtle module will not allow to translate the control-flow structure, the docstrings....etc and so on, and so forth if you do simple `Tortue = Turtle` assignment, So while it looks nice 2 liners example you hit this problem pretty quickly. Taking fort given example: import turtle # import is english, should translate to importer, ou importez. turtle should be tortue also. t = turtle.Plume() t.couleurplume('vert’) # plume is a female, couleur should be “verte”, “crayon” would be male, so “vert" t.avant(100) # avance/avancer I can perfectly imagine a menu “insérer use boucle `pour ...`”, that insert a `for ....` in applications, which is confusing is confusing to explain. I also find it much easier to attach a programming meaning to a word that have no previous meaning for a kid (for, range, if, else, print are blank slate for French children), than shoehorn another concept biased by previous experience into it. This in particular make me think of Gibiane[1], which is basically: “Hey fortran is great let’s make it in french”, which was a really bad idea[2], no it’s not a joke, and yes people do nuclear physics using this language. While I appreciate in general the translation effort, in general most of the translated side of things (MDN, microsoft help pages, Apples ones) are much worse than trying to understand the english originals. So just a warning that the best is the enemy of the good, and despite good intentions[3], trying to translate Turtle module might not be the right thing to do. Thanks, -- Matthias [1]: https://fr.wikipedia.org/wiki/Gibiane <https://fr.wikipedia.org/wiki/Gibiane> [2]: but not the worse IMHO. [3]: http://www.bloombergview.com/articles/2015-08-18/how-a-ban-on-plastic-bags-c... <http://www.bloombergview.com/articles/2015-08-18/how-a-ban-on-plastic-bags-c...>
On Fri, Sep 4, 2015 at 9:26 AM, Matthias Bussonnier <bussonniermatthias@gmail.com> wrote:
Another opinion based on some experience: I use local-language names when teaching beginners. It gives a nice distinction between names provided by Python or a library (in English) and things that can be named arbitrarily. I haven't actually measured if this helps learning, though; and to the turtle module it might not apply at all.
I'm agree with Matthias: IT world is mostly English based. It's "sad" for non native English speakers like me because you must learn English before to work in IT. However, the positive side effect is that we can speak together in the common language. Ludovic Gasc (GMLudo) http://www.gmludo.eu/ On 4 Sep 2015 09:26, "Matthias Bussonnier" <bussonniermatthias@gmail.com> wrote:
On Fri, Sep 04, 2015 at 01:34:16PM +0200, Ludovic Gasc wrote:
I'm agree with Matthias: IT world is mostly English based.
Fortunately for the 95% of the world who speak English as a second language, or not at all, that is changing. For example, StackOverflow has a very successful Brazilian site, and they make the case for non-English speakers well: https://blog.stackexchange.com/2014/02/cant-we-all-be-reasonable-and-speak-e... Rather than just repeat what they say there, I will just ask everyone to read it. -- Steve
Thank you for the link, it's interesting. However, my remark it's mainly for the source code: Even if I sincerely think it's better to handle English the most possible you can, I see no issues to discuss about source code in your native language: I speak myself in French when I interact with French developers only in my company. Nevertheless, for the content of the source code or database structure, at least to me, you must write in English: I've already analysed source code in Dutch, it was a lot more complicated to understand the code, I've lost a lot of time for nothing. The world is now global and dev resources are enough rare to avoid to lock your source code content in a local language. See for example the big work of LibreOffice to translate German comments: https://wiki.documentfoundation.org/Development/Easy_Hacks/Translation_Of_Co... With a localized turtle, you should give a bad habit at the beginning. -- Ludovic Gasc (GMLudo) http://www.gmludo.eu/ 2015-09-04 14:18 GMT+02:00 Steven D'Aprano <steve@pearwood.info>:
I do agree with the comments of Ludovic about the source code, Python is in English, the code for an open source project is international, and in this case, I prefer English. In the past, I have seen some databases in french, with the accents é, è, ç in the columns of the database, that’s really ugly :/ because if you forgot the encoding in the database, you will have a problem. Yesterday, I have read a source code in Dutch, sorry but if you don’t know this language, good luck if you want to change the code. And an other example, the comments in the code of the EuroPython site is in Italian, ok, the project has been developed for PyCon Italia, but now, we are a lot of international developers on this code, and sincerely, I can speak Italian but not everybody. Sincerely, English for the code and the database! On 4 Sep 2015, at 21:56, Ludovic Gasc wrote:
-- Stéphane Wirtel - http://wirtel.be - @matrixise
I completely agree that Python and codebases already in English should remain in English. And I want the source code for turtle.py to stay in English as well. This is where the gray area for Turtle begins though. Turtle is not for professional developers, where the English expectation is there. It is used for school kids to program in, and this code will most likely be forgotten about a week after the programming assignment is done. And in a sense, turtle.py is not used as a module by kids so much as an app (albeit a scriptable one) that moves the turtle around and draws shapes. The language barrier is a very real one for non-technical instructors, parents, and students. If we could minimize it down to less than a dozen Python keywords & names (import turtle, for, in, range, while, if, else) that would be a significant gain for Python's reach. And I don't think it would be much technical debt for turtle.py. I hope to have a complete translated set soon so I can submit a patch that shows how light of a change this would be. -Al On Fri, Sep 4, 2015 at 1:02 PM, Stéphane Wirtel <stephane@wirtel.be> wrote:
Al Sweigart writes:
I don't see why you would want any non-localized identifiers (modules, functions) at all in the base feature set. So you can (and I think should) drop range and turtle. I don't see any point in discussing the keywords here -- they are what they are. If a student decides to use something weird like "continue" or "try ... finally" it will work. Of course, the recommended set of syntaxes and their associated keywords matter a lot pedagogically, but we can leave that discussion to the pedagogues. When you're wearing your pedagogue hat and actually writing the style guide for teaching programming using turtle, then those interested can talk about that. Or maybe that should be left to experimentation. Some teachers may prefer to avoid "while condition: suite" in of "for i in iterable: if condition: suite". (Normally that would be nuts, of course, but here you could reduce the base set of keywords and syntaxes by one each.) There may be reasons why advanced users (and teachers) might want to use "non-base" facilities. There it's possible to do things like
which allows teachers to add any extensions they like conveniently, albeit verbosely. I still think an i18n-based architecture is the way to go, to minimize such boilerplate (error-prone for translators) among other reasons. Neither users nor translators need to see it, unless they want to see "how'd they do that?" In which case, isn't more "educational" to show them the way it's done in the real world?
On 5 September 2015 at 16:46, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Sorting out such procedural questions *iteratively* is one of the reasons I think it's desirable to pursue this externally first. There are a *lot* of possible options here, including using a full translation platform like Zanata or Pootle to manage the interaction with translators, and also a need to allow teachers of students that aren't native English speakers to easily try out the revised module *before* we commit to adding it to CPython. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04.09.2015 13:34, Ludovic Gasc wrote:
This argument does not fit for students at K4-level so programming4all will not work. When constructing Ponto.py, (remote control for OpenOffice.org and LibreOffice via Python) we decided to write PontoE.py to enable students with English to use it, but also PontoD.py to use those classes, which are German-based - because of the bavarian textbooks for Informatik at the age of 11, which use German identifiers for classes, attributes and methods. You may take a look at to get a glimpse, how we dealt in automating the process to get the http://www.ham.nw.schule.de/pub/bscw.cgi/100606 The README.txt points out how the process it managed. Our actual approach without »internationalisierung« for Python3: http://www.ham.nw.schule.de/pub/bscw.cgi/2131956 TNX Ludger - -- https://twitter.com/n770 http://ddi.uni-wuppertal.de/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlXpjEYACgkQJQsN9FQ+jJ9gggCgiCO4V7oDF9QSFcoMkhd3GarW 1S8Ani7a5F7TlPe982q7ggWlGOTy5z0h =MpyW -----END PGP SIGNATURE-----
On Friday, September 4, 2015 at 12:56:33 PM UTC+5:30, Matthias Bussonnier wrote:
Hi all,
Personal opinion, base by a bit of experience:
And my personal experience from the (an) other side: Some students of mine worked to add devanagari to python: https://github.com/rusimody/l10Python [Re-copying something here from a post on dev list What I would wish to add is tl;dr at bottom ] Here's an REPL-session to demo: [Note १२३४५६७८९० is devanagari equivalent of 1234567890] -------------------------------------------------- Python 3.5.0b2 (default, Jul 30 2015, 19:32:42) [GCC 4.9.2] on linux Type "help", "copyright", "credits" or "license" for more information.
The last is actually more an embarrassment than the δ breaking since they’ve *changed the lexer* to read the Σ when all that was required was Σ = sum !! In short... Kids! tl;dr For me (yes an educated Indian) English is a natural first language However the idea that English is the *only* language is about as quaint the idea that the extent of the universe is as vast as a 100 kilometers with Garden of Eden in the center. Our tiny experience with internationalizing python showed us that the lexer (at least) is terribly ASCII centric My immediate wish-list: Modularize the lexer into a pre-lexer converting UTF-8 to unicode codepoint followed by a pure unicode 32-bit codepoint based lexer My long-term wishlist (yeah somewhat unrealistic and utopian) for python 4000 is the increased awareness that the only reasonable international language is mathematics. Or http://blog.languager.org/2014/04/unicoded-python.html
On Sat, Sep 5, 2015 at 4:01 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
If someone's just learning to program, surely s/he can learn on Python 3 rather than Python 2. If localized names aren't available on Py2, so be it. (For the record, I would be in favour of it being on PyPI. I just don't think that "Python 2.7" is sufficient argument for that.) ChrisA
Chris Angelico writes:
If someone's just learning to program, surely s/he can learn on Python 3 rather than Python 2.
In any case, I could replace "2.7" with the (not yet released!) "3.5". 'nuff said, yet?<wink /> Anyway, "learn with Python 3" is what we advocate, but the reality is otherwise in some places, and many platforms (eg, Mac). None of my students download Python 3 until I tell them to. They thought the system Python would be as "up to date" as the "Retina" display! I wouldn't be surprised if there aren't a lot of Mac systems in schools where many teachers just use the Python that is already there, and are far more likely to "pip tortuga" than they are to install a whole parallel Python 3.
First, does this proposal actually come from a non-English teacher, or someone who's talked to them, or is it just a guess that they might find it nice? Meanwhile: On Sep 3, 2015, at 19:45, Steven D'Aprano <steve@pearwood.info> wrote:
Of course a sizable chunk of those say "my Python didn't come with pip" and the after a bit of exploration you find that they're using Python 2.7.3 or something, so any feature added to Python 3.6 isn't likely to help them anyway. And that seems like a good argument to add it to PyPI even if it's also added to the stdlib. Sure, for some teachers it'll be easier to just require 3.6 than to require a particular package. But I'm guessing both will be problematic in different cases. For example, if the school is issuing students linux laptops that come with Python 3.4, would explaining apt-get, and getting permission from the IT department for it, is probably harder, not easier, than pip.
On Fri, Sep 04, 2015 at 12:18:52AM -0700, Andrew Barnert wrote:
You say "of course", but did you actually look at the python-list archives? If you do, you will see posts like these two within the last 24 hours: [quote] I am running Python 3.4 on Windows 7 and is facing [Error 13] Permission Denied while installing Python packages... [end quote] and: [quote] Well I have certainly noted more than once that pip is contained in Python 3.4. But I am having the most extreme problems with simply typing "pip" into my command prompt and then getting back the normal information on pip! [end quote] And a random selection of other issues which I just happen to still have visible in my news reader: [quote] Python 2.7.9 and later (on the python2 series), and Python 3.4 and later include pip by default. But I can not find it in python2.7.10 package. What's the matter? How can i install pip on my Embedded device? [end quote] [quote] I've installed a fresh copy of Python 3.5.0b2 and - as recommended - upgraded pip. I don't understand the reason for the permission errors as I am owner and have full control for the temporary directory created. [end quote] [quote] I was fed up with trying to install from pypi to Windows. Setup.py more often than not wouldn't be able to find the VS compiler. So I thought I'd try the direct route to the excellent Christoph Gohlke site at http://www.lfd.uci.edu/~gohlke/pythonlibs/ which is all whl files these days. However as you can see below despite my best efforts I'm still processing the tar.gz file, so what am I doing wrong? [end quote] (Some spelling errors and obvious typos corrected.) Please don't dismiss out of hand the actual experience of real users with pip. At least one of those quotes above is from a long-time Python regular who knows his way around the command line. This is not meant as an anti-pip screed, so please don't read it as such. But it is meant as a reminder that pip is not perfect, and that even experienced Python developers can have trouble installing packages. Children with no experience with the command line or Python can not be expected to install packages from PyPI without assistence, and if they are using school computers, they simply may not be permitted to run "pip install" even if it worked flawlessly. -- Steve
I find it really annoying when people pick one sentence out of a post to argue against at length, out of context. while entirely ignoring the actual substance of the post. Are you sincerely arguing that no children out there will have Python 3.5, 3.3, or 2.7, or that for all such student upgrading to 3.6 will be easier and face fewer permissions problems than using pip? If not, then how does this answer my point that some people will want this on PyPI even if it's in the 3.6 stdlib? Sent from my iPhone
I see your point. I think there are two different arguments here: It would be good to have non-English turtle modules of PyPI for older versions of Python. But it would also be good to have non-English names added to the turtle module in the 3.6 stdlib. My main concern was that if these modules were on PyPI, they would be left out of the standard library. Then the "install from PyPI headache" arguments would apply. -Al On Fri, Sep 4, 2015 at 2:05 PM, Andrew Barnert via Python-ideas < python-ideas@python.org> wrote:
On Sep 4, 2015, at 14:43, Al Sweigart <asweigart@gmail.com> wrote:
I see your point. I think there are two different arguments here: It would be good to have non-English turtle modules of PyPI for older versions of Python. But it would also be good to have non-English names added to the turtle module in the 3.6 stdlib.
My main concern was that if these modules were on PyPI, they would be left out of the standard library. Then the "install from PyPI headache" arguments would apply.
I understand, but I think that concern is misplaced. Having something on PyPI generally makes it easier, not harder, to get it into the stdlib. And it's also useful on its own, because not everyone has 3.6. The problem is that it seems like the obvious way to design the PyPI version and the stdlib version would be pretty different (unless you want to explain to novices how to install backports packages and import things conditionally). But hopefully someone can come up with a good solution to that?
On 5 September 2015 at 07:43, Al Sweigart <asweigart@gmail.com> wrote:
The last major upgrade to turtle was the adoption of Gregor Lindl's xturtle for 2.6 as the standard turtle implementation, and he iterated on that as an external project for a while first. I think this is another case where a similar approach would work well - you could create a new "eduturtle" project as a fork of the current turtle module to allow more rapid iteration and feedback from educators unconstrained by the standard library's release cycle, and then propose it for default inclusion in 3.6. Another potentially desirable thing that could be explored within such a "turtle upgrade" project is switching it to using a HTML5 canvas as its drawing surface, rather than relying on Tkinter. We made a similar change a while ago with PyDoc, and while the pages generated by the local web service could definitely use some TLC from a front-end designer, I think it was a good call. That "HTML5-compatible-browser-as-GUI-framework" model is also the way IPython Notebook went for data analysis, and it unlocks an incredibly rich world of visualisation capabilities, that are not only useful in full browsers, but also in HTML widgets in desktop and mobile GUI frameworks. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Sep 04, 2015 at 02:05:05PM -0700, Andrew Barnert wrote:
Your post was three rather short paragraphs. I ignored the first paragraph because it had nothing to do with me, and I don't know the answer. I didn't respond to the third paragraph because I thought the conclusion (that getting permission to install pip would be easier than getting the most up-to-date version of Python installed) was unlikely at best, but regardless, you used enough weasel words ("seems like ... I'm guessing ... is probably ...") that it would be churlish to argue. Who knows? Yes, there could be some teachers who get permission for their students to install anything they like with pip but aren't allowed to upgrade to the latest version of Python. It's a big world and IT departments sometimes appear to choose their policies at random. I focused on the second paragraph because that was the comment you made that I want to respond to, namely that a sizeable chunk of problems with pip is that pip isn't installed. To reiterate, I don't believe that is the case, based on what I see on the python-list mailing list. Judging by the comments in the "packaging" subthread, this may have hit a chord with at least some others.
Are you sincerely arguing that no children out there will have Python 3.5, 3.3, or 2.7,
No.
or that for all such student upgrading to 3.6 will be easier and face fewer permissions problems than using pip?
For "all" of them? Probably not.
I didn't respond to that point. If you want me to respond, I'll say that I consider it unlikely that putting it on PyPI will be of much practical utility, given the user-base for turtle, but if people want to do both, it's not likely to do much harm either. -- Steve
Steven D'Aprano writes:
So let's fix it, already![1] Now that we have a blessed package management module, why not have a builtin that handles the simple cases? Say def installer(package, command='install'): ... where command would also take values 'status' (in which case package could be None, meaning list all installed packages, and 'status' might check for available upgrades as well as stating whether the package is known to this python instance), 'upgrade', 'install' (which might error if the package is already installed, since I envision installations taking place in the user's space which won't work for upgrading stdlib packages in a system Python, at least on Windows), and maybe 'remove'. I'm not real happy with the name "installer", but I chose it to imply that there is a command argument, and that it can do more than just install new packages. In general, I would say installer() should fail-safe (to the point of fail-annoying<wink/>), and point to the pip (and maybe venv) docs. It should also be verbose (eg, explaining that it only knows how to install for the current user and things like that). Footnotes: [1] This really is not relevant to the "localized turtle" thread. If the current situation is acceptable in general, it's not an argument for putting turtle localizations in the stdlib. If it's not acceptable, well, let's fix it.
On 5 September 2015 at 17:08, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Running "python -m pip" instead of "pip" already avoids many of the issues with PATH configuration, which is one of the reasons why that's what I recommend in the main Python docs at https://docs.python.org/3/installing/ & https://docs.python.org/2/installing/ Unfortunately, I've yet to convince the rest of PyPA (let alone the community at large) that telling people to call "pip" directly is *bad advice* (as it breaks in too many cases that beginners are going to encounter), so it would be helpful if folks helping beginners on python-list and python-tutor could provide feedback supporting that perspective by filing an issue against https://github.com/pypa/python-packaging-user-guide Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I do have this package[1] That allow you to do `pip install <....>` from within an IPython session and will call the pip of the current python by importing pip instead of calling a subprocess. One of the things I would like is for that to actually wrap pip on python.org-installed python, and conda on conda-installed python. So if such a proposal is integrating into Python, it would be nice to have hooks that allow to "hide" which package manager is used under the hood. -- M [1]: https://pypi.python.org/pypi/pip_magic On Sat, Sep 5, 2015 at 10:30 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 5 September 2015 at 09:30, Nick Coghlan <ncoghlan@gmail.com> wrote:
I would love to see "python -m pip" (or where the launcher is appropriate, the shorter "py -m pip") be the canonical invocation used in all documentation, discussion and advice on running pip. The main problems seem to be (1) "but just typing "pip" is shorter and easier to remember", (2) "I don't understand why pip can't just be a normal command" and sometimes (3) "isn't this just on Windows because you can't update pip in place on Windows" (no it isn't, but it's a common misconception of the issue). But I would agree with Nick, and recommend that anyone advising people on how to use pip, *especially* if you are helping them with issues, to always use "python -m pip" as the canonical command. If you need to explain why, say that this makes sure that you run pip from the correct Python interpreter, that's the basic point here. Paul
Paul Moore <p.f.moore@gmail.com> writes:
Contrariwise, I would like to see ‘pip’ become the canonical invocation used in all documentation, discussion, and advice; and if there are any technical barriers to that least-surprising method, to see those barriers addressed and removed.
The main problems seem to be (1) "but just typing "pip" is shorter and easier to remember",
With the concomitant benefit that it's easier to teach and learn. This is not insignificant.
(2) "I don't understand why pip can't just be a normal command"
This is my main objection, but rather stated as: We already have a firmly-established naming convention for user-level commands, that works in a huge number of languages; Python has no good reason to be an exception, especially not in one of the first commands that new users will need to encounter. If something is preventing ‘pip’ from being the command to type to run Pip, then surely the right place to apply pressure is not on everyone who instructs and documents and interfaces with end-users now and indefinitely; but instead on whatever is preventing the One Obvious Way to work. No? -- \ “Yesterday I saw a subliminal advertising executive for just a | `\ second.” —Steven Wright | _o__) | Ben Finney
On 9 September 2015 at 08:33, Ben Finney <ben+python@benfinney.id.au> wrote:
There is at least one fundamental, technical, and (so far) unsolveable issue with using "pip" as the canonical invocation. pip install -U pip fails on Windows, because the exe wrapper cannot be replaced by a process running that wrapper (the "pip" command runs pip.exe which needs to replace pip.exe, but can't because the OS has it open as the current running process). There have been a number of proposals for fixing this, but none have been viable so far. We'd need someone to provide working code (not just suggestions on things that might work, but actual working code) before we could recommend anything other than "python -m pip install -U pip" as the correct way of upgrading pip. And recommending one thing when upgrading pip, but another for "normal use" is also confusing for beginners. (And we have evidence from the pip issue tracker people *do* find this confusing, and not just beginners...) Apart from that issue, which is Windows only (and thus some people find it less compelling) we have also had reported issues of people running pip, and it installs things into the "wrong" Python installation. This is typically because of PATH configuration issues, where "pip" is being found via one PATH element, but "python" is found via a different one. I don't have specifics to hand, so I can't clarify *how* people have managed to construct such breakage, but I can state that it happens, and the relevant people are usually very confused by the results. Again, "python -m pip" avoids any confusion here - that invocation clearly and unambiguously installs to the Python installation you invoked. In actual fact, if it weren't for the backward compatibility issues it would cause, I'd be tempted to argue that pip shouldn't provide any wrapper at all, and *only* offer "python -m pip" as a means of invoking it (precisely because it's so closely tied to the Python interpreter used to invoke it). But that's never going to happen and I don't intend it as a serious proposal. Paul
On Wednesday, September 9, 2015 at 2:27:08 PM UTC+5:30, Paul Moore wrote:
The amount of grief pip is currently causing is IMHO good reason to prefer incompatible changes that remove breakage to try-n-please-everyone and keep breaking.
On Sep 9, 2015, at 01:56, Paul Moore <p.f.moore@gmail.com> wrote:
If StackOverflow/SU/TD questions are any indication, a disproportionate number of these people are Mac users using Python 2.7, who have installed a second Python 2.7 (or, in some cases, two of them) alongside Apple's. Many teachers, blog posts, instructions for scientific packages, etc. recommend this, but often don't give enough information for a novice to get it right. Many people don't even realize they already have a Python 2.7; others are making their first foray into serious terminal usage and don't think about PATH issues; others are following old instructions written for OS X 10.5 that don't do the right thing in 10.6, much less 10.10; etc. And even experienced *nix types who aren't Mac experts may not realize the implications of LaunchServices not being launched by the shell (so anything you double-click, schedule, run as a service, etc. won't see your export PATH that you think should be solving things). Even Mac experts are thrown by the fact that Apple's pre-installed Python is in /usr but has a scripts directory in /usr/local, so if you install pip for both Apple's Python and a second one, whichever one goes second is likely to overwrite the first (but that isn't as common as just having /usr/bin ahead of /usr/local/bin on the PATH--because Apple's Python doesn't come with pip, this is enough to have your highest pip and python executables out of sync). Whenever someone has a PATH question, I always start by asking them if they're on a Mac, and using Python 2.7, and, if so, which if any Python installs they've done, and why they can't use virtual environments and/or upgrade to Python 3.x and/or use the system Python. The vast majority say yes, yes, [python.org|Homebrew|the one linked from this blog post|I don't remember], what's a virtual environment, my [book|teacher|friend] says 2.7 is the best version, this blog post says [Apple doesn't include Python|Apple's Python is 2.7.1 and broken|etc.]. As both Python 3 and virtual environments become more common (at least as long as Apple isn't shipping Python 3 or virtualenv for their 2.7), the problem seems to be becoming less common, but it's still depressing how many people are still writing blog posts and SO answers and so on that tell people "you need to install the latest version of Python, 2.7, because your computer doesn't come with it" and then proceed to give instructions that will lead to a screwed up PATH and make no mention of virtualenv...
On September 9, 2015 at 5:22:57 PM, Andrew Barnert via Python-ideas (python-ideas@python.org) wrote:
Apple's Python doesn't come with pip
As of the latest Yosemite release, and in El Capitan, it *does* however come with Python 2.7.10 and thus ``python -m ensurepip`` works. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Hi, sorry to bother you again, but the search problem on PyPI is still present after different weeks and it's very annoying. I've just released a new version of my ldap3 project and it doesn't show up when searching with its name. For mine (and I suppose for other emerging project, especially related to Python 3) it's vital to be easily found by other developers that use pip and PyPI as THE only repository for python packages and using the number of download as a ranking of popularity of a project. If search can't be fixed there should be at least a warning on the PyPI homepage to let users know that search is broken and that using Google for searching could help to find more packages. Bye, Giovanni
Hi there, My 2.5 year old offer to retrofit the old codebase with a new search system still stands[1]. :) There is no reason for this to be a complex affair, the prototype built back then took only a few hours to complete. No doubt the long term answer is probably "Warehouse fixes this", but Warehouse seems no nearer a reality than it did in 2013. David [1] https://groups.google.com/forum/#!search/%22david$20wilson%22$20search$20pyp... On Thu, Sep 10, 2015 at 12:35:04AM +0200, Giovanni Cannata wrote:
Wouldn't it be better if you'd just build an external search service? Getting a list of packages and descriptions should be possible no? (just asking, not 100% sure) I doubt the maintainers are just going to come out and say "ok, this guy has waited long enough, lets take his contribution in". If they didn't care about the search 2.5 years ago why would they care now. Sorry for being snide here but my impression is that Warehouse could had been shipped a while ago instead of getting rewritten s everal times. I'm not saying that's bad, it's just that there's a mismatch in goals here. Thanks, -- Ionel Cristian Mărieș On Thu, Sep 10, 2015 at 2:01 AM, David Wilson <dw+python-ideas@hmmz.org> wrote:
On Sep 9, 2015, at 14:25, Donald Stufft <donald@stufft.io> wrote:
Sure, and all the way back to 10.5, you could just "easy_install pip". That never solved the problem of people who've been told to install a second Python 2.7 without any explanation of why or any consideration of what problems that might lead to; in fact, it just means they're even more likely to end up installing two colliding pips. I don't think there's much chance that anything Apple or the Python community does will get people to stop writing blog posts/class notes/installation web pages/SO answers/etc. to do this. There is a chance that proselytizing for virtualenv and/or Python 3 will make the problem irrelevant (and it already seems to be having that effect, just not as fast as would be ideal). Of course there will still be some people who really do need two Python 2.7 installations and aren't expert enough to manage it, and some people who manage to make a mess of things even with separate 2 and 3 or with venvs or with only Apple's Python. But, based on my (admittedly anecdotal) experience and my educated-guess-but-still-a-guess, I think it'll become not much more common than the equivalent problems for Fedora or Ubuntu or FreeBSD, which is a huge improvement.
Andrew Barnert via Python-ideas writes:
Often enough it's the other way around: the distro catches up to the user as they upgrade. I didn't even realize "10.10 Yosemite" had 2.7, this box has been upgraded from "10.7 Lion" or so, and I just use MacPorts 2.7 all the time. I haven't worried about what Apple supplies as /usr/bin/python in 6 or 7 years. I don't know if this matters to the effect on pip, but I thought it should be mentioned.
On Sep 9, 2015, at 20:32, Stephen J. Turnbull <stephen@xemacs.org> wrote:
No, that's not the problem. Lion came with 2.7.1, so you already had it before upgrading it, and it's hard to imagine Apple upgrading your system 2.7.1 to 2.7.6 or 2.7.10 broke anything. More likely, Apple screwed up your PATH, or broke your MacPorts so you had to reinstall or repair it?
I'd assume most people on this list know what they're doing with their PATH. If you don't, then you just got lucky for a few years. Well, not just lucky--MacPorts does go out of its way to make things easier for you in various ways (hammering home keeping /opt/local/bin at the the start of your PATH, trying to adjust the PATH system-wide and for LaunchServices as well as shells, providing many packages as ports so you don't need pip, offering a python-select tool that autodetects Apple and PSF Pythons and tries to make them play nice with MacPorts Pythons, etc.). So MacPorts users don't see such problems nearly as often as Homebrew (or Fink or Gentoo Prefix, if anyone still uses those), PSF installers, and third-party extra-batteries installers. But they still can come up--and if you didn't even realize you were running multiple Python 2.7 versions in parallel, that just means you never tried anything that MacPorts didn't anticipate. And, of course, most people with two Python 2.7s on Mac are not using MacPorts anyway.
Andrew Barnert writes:
I've had no problems with PATH, personally. I'm just saying that learning that pip was actually version-specific, and then getting the right pip for the current Python of interest, has been an annoyance for me over the years, and I was very happy to switch to "python -m pip" because it Just Works. As far as the question of order of installation, I just wanted to point out that system upgrades do sometimes catch up to the user, resulting in duplicate installations, rather than the user following some blog to the letter and installing a verson they don't need.
I'd assume most people on this list know what they're doing with their PATH. If you don't, then you just got lucky for a few years.
For me, PATH is easy. <python> -m pip is easy. <pip> is hard. :-/
No, it just means that since forever my personal PATH has been set up to give precedence to /usr/local/bin and /opt/local/bin, and since the days of Python 2 I avoid the system Python at all costs. Specifically, I never invoke Python without a full 2-digit version number (except in venvs), and my shebangs specify it too (ditto). (It works out to the same semantics as "not surprising MacPorts", of course.)
I teach an intro to python class, and have been advocating python/supporting users of python on OS-X for years. AND I am one those folks that advocates starting out by installing the latest Python2.7 (unless your going with 3). And I don't think I'm going to stop.
because your computer doesn't come with it"
But never for that reason, but because I don't think users SHOULD rely on the system Python on OS-X (and probably orher systems). You can google the reasons why -- you'll probably find a fair number of posts with my name on it ;-). Or, if that debate really is relevant to this discussion I could repeat it all here...
and then proceed to give instructions that will lead to a screwed up PATH
Well, I hope I don't do that ;-) -- in fact, the python.org installer has done a pretty nice job with its defaults for years -- the people that get messed up the ones that try to "fix" it be hand, when they don't know what they are doing (and very few people DO know what they doing with PATH on OS-X)
and make no mention of virtualenv...
OK, I do that ..... But quite deliberately. Virtualenv solves some problems for sure, but NOT the "I can't import something I swear I just installed" problem. in fact, it creates even MORE different "python" and "pip" commands, and a greater need to understand PATH, and what terminals are configured how, etc. So no, I don't introduce virtualenv to beginners. But I'll probably start teaching: python -m pip install ...... -Chris
On Wed, Sep 9, 2015 at 1:56 AM, Paul Moore <p.f.moore@gmail.com> wrote:
At the very least, surely this could be "fixed" by detecting this case and exiting with a message "Sorry, Windows is annoying and this isn't going to work, to upgrade pip please type 'python -m pip ...' instead"? That seems more productive in the short run than trying to get everyone to stop typing "pip" :-). (Though I do agree that having pip as a separate command from python is a big mess -- another case where this comes up is the need for pip versus pip3.)
It sounds like this is another place where in the short term, it would help a lot of pip at startup took a peek at $PATH and issued some warnings or errors if it detected the most common types of misconfiguration? (E.g. the first python/python3 in $PATH does not match the one being used to run pip.) -n -- Nathaniel J. Smith -- http://vorpus.org
Nathaniel Smith writes:
That seems more productive in the short run than trying to get everyone to stop typing "pip" :-).
FWIW, I did as soon as I realized python_i_want_to_install -m pip worked; it's obvious that it DTRTs, and I felt like I'd just dropped the hammer I'd been whacking my head with.
Ah, that's the name of my hammer, although it's come up in 3.2 vs 3.3 as well.
I don't understand the logic for trying to save the pip command by making its environment checking more complex than the app itself. "python -m pip" suffers from no problems that pip itself doesn't suffer from, and is far more reliable, without blaming the user. Sure, people used to using a pip command shouldn't be deprived of it, but I'll never miss it, and I don't see why anybody who isn't already using it would miss it. The only problem with "python -m pip" is discoverability/memorability, and the fact that interactive use of "from pip import main" is not properly supported IIUC (not to mention clumsy). Thus the proposal for a builtin named "install" or similar.
On Thu, Sep 10, 2015 at 1:25 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
If the problem with this is the verbosity of it ("python -m pip install packagename" - five words), would there be benefit in blessing pip with some core interpreter functionality, allowing either: $ python install packagename or $ python -p packagename to do the one most common operation, installation? (And since it's new syntax, it could default to --upgrade, which would match the behaviour of other package managers like apt-get.) Since the base command is "python", it automatically uses the same interpreter and environment as you otherwise would. It's less verbose than bouncing through -m. It gives Python the feeling of having an integrated package manager, which IMO wouldn't be a bad thing. Of course, that wouldn't help with the 2.7 people, but it might allow the deprecation of the 'pip' wrapper. Would it actually help? ChrisA
On Sep 9, 2015, at 21:32, Chris Angelico <rosuav@gmail.com> wrote:
What about leaving the pip wrapper, but having it display a banner telling people to use python -m pip (and maybe suggesting they add an alias to their profile, if not Windows) and then do its thing as it currently does. (Maybe with some way to suppress the message if people want to say "I know what I'm doing; if my PATH is screwy I'll fix it".) If we also add the python -p, it can instead suggest that if version >= (3, 6). That seems like an easier way to get the message out there than trying to convince everyone to spread the word everywhere they teach anyone, or deprecating it and leaving people wondering what they're supposed to do instead.
Nathaniel Smith <njs@pobox.com> writes:
Isn't that something that would be better in the Python executable itself? Many commands would be better with a (overridable) default behaviour as you describe. -- \ “Considering the current sad state of our computer programs, | `\ software development is clearly still a black art, and cannot | _o__) yet be called an engineering discipline.” —Bill Clinton | Ben Finney
On Wed, Sep 9, 2015 at 8:37 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
While that's debatable, any plan that only benefits users of python 3.6+ is a non-starter is a non-starter, given that the goal here is short-term harm reduction. -n -- Nathaniel J. Smith -- http://vorpus.org
On 9 September 2015 at 23:40, Nathaniel Smith <njs@pobox.com> wrote:
That's already done (without the unnecessary passive-aggressive sniping at Windows) and we still get users raising bugs because they didn't read the message, or because they misinterpreted something. As I said, we've tried lots of solutions. What we haven't had yet is anyone come up with an actual working PR that fixes the issue (in the sense of addressing the bug reports we get) better than the current code (if we had, we'd have applied the PR). Paul
On 9 September 2015 at 23:40, Nathaniel Smith <njs@pobox.com> wrote:
People (including the pip devs) have talked about this type of thing before. To my knowledge no-one has actually implemented it. Care to provide a PR for this? Paul
On 9 September 2015 at 17:33, Ben Finney <ben+python@benfinney.id.au> wrote:
We're doing that too, but it's a "teaching people to use the command line for the first time is hard" problem and a "managing multiple copies of a language runtime and ensuring independently named commands are working against the right target environment" issue, moreso than a language level one. A potentially more fruitful path is likely to be making it so that folks don't need to use the system shell at all, and can just work entirely from the Python REPL. The two main things folks can't do from the REPL at the moment are: * install packages * manage virtual environments The idea of an "install()" command injected into the builtins from site.py would cover the first. The second couldn't be handled the way virtualenv does things, but it *could* be handled through a tool like vex which creates new subshells and runs commands in those rather than altering the current shell: $ python3 Python 3.4.2 (default, Jul 9 2015, 17:24:30) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux Type "help", "copyright", "credits" or "license" for more information.
The "vex nikola python" call there: 1. Starts a new bash subshell 2. Activates my "nikola" virtual environment in that subshell 3. Launches Python within that venv (hence the jump over to a Python 2.7 process, since I keep forgetting to recreate it as Python 3). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Sep 11, 2015 at 1:55 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Hmm. This looks like something that could confuse people no end. I already see a lot of people use Ctrl-Z to get out of a program (often because they've come from Windows, I think), and this would be yet another way to get lost as to which of various Python environments you're in. Is it safe to have Python exec to another process? That way, there's no "outer" Python to be left behind, and it'd feel like a transition rather than a nesting. ("Please note: Selecting a virtual environment restarts Python.") (Incidentally, what _would_ happen if you pressed Ctrl-Z while in that 'inner' Python? Would both Pythons get suspended?) ChrisA
On 11 September 2015 at 02:30, Chris Angelico <rosuav@gmail.com> wrote:
Using subprocess.call() to invoke vex was something I could do without writing a single line of code outside the REPL. An actual PEP would presumably propose something with a much nicer UX :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Sep 11, 2015 at 3:03 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Heh, fair enough! Mainly, though, I'm wondering whether there'd be any risks to using os.exec* from the REPL - anything that would make it a bad idea to even consider that approach. ChrisA
On Sat, Sep 05, 2015 at 04:08:24PM +0900, Stephen J. Turnbull wrote:
Python competes strongly with R in the scientific software area, and R supports a built-in to do just that: https://stat.ethz.ch/R-manual/R-devel/library/utils/html/install.packages.ht... -- Steve
On September 5, 2015 at 11:40:17 AM, Steven D'Aprano (steve@pearwood.info) wrote:
I don't know anything about R, but a built in function is a bad idea. It'll be a pretty big footgun I believe. For instance, if you already have requests 2.x installed and imported, and then you run the builtin and install something that triggers requests 1.x to be installed you'll end up with your Python in an inconsistent state. You might even end up importing something from requests and ending up with modules from two different versions of requests ending up in sys.modules. In addition, the standard library is not really enough to accurately install packages from PyPI. You need a real HTML parser that can handle malformed input safely, an implementation of PEP 440 versions and specifiers (currently implemented in the "packaging" library on PyPI), you also need some mechanism for inspecting the currently installed set of packages, so you need something like pkg_resources available to properly support that. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
In reading this discussion with interest. pip and PyPI are what make the Python ecosystem live and vital. Especially PyPI is what surprises any Python newbie. A single repository freely available where to find valuable ready-to-use software, accessible from anywhere, it's hard to believe if you are, for example, a Java or .NET developer. But are you aware of the problems that PyPI is currently suffering? It's about two weeks that its searching engine is faulty and doesn't find many packages, even if they are available. This is a very bad thing because PyPI is the frontgate to the Python system for many people, more than the python.org site itself. I think that PyPI should deserve a special attention for the sake of the whole Python community. -------- Messaggio originale -------- Da:Donald Stufft <donald@stufft.io> Inviato:Sat, 05 Sep 2015 18:38:29 +0200 A:Steven D'Aprano <steve@pearwood.info>,python-ideas@python.org Oggetto:Re: [Python-ideas] High time for a builtin function to manage packages (simply)?
On September 5, 2015 at 2:03:46 PM, Giovanni Cannata (cannatag@gmail.com) wrote:
But are you aware of the problems that PyPI is currently suffering? It's about two weeks that its searching engine is faulty and doesn't find many packages, even if they are available.
I’m aware. I’m only one person and my plate is extremely full. I’ve poking at the problem to try and figure it out. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Hi Donald, you mean you're the only one in charge of maintaining PyPI? I'm sorry for this, I thought that a critical service like PyPI was supported by a team. I (and presume other developers) rely heavily on it. Maybe this should be brought to the attention of the PSF. -------- Messaggio originale -------- Da:Donald Stufft <donald@stufft.io> Inviato:Sat, 05 Sep 2015 20:05:53 +0200 A:python-ideas@python.org,Steven D'Aprano <steve@pearwood.info>,Giovanni Cannata <cannatag@gmail.com> Oggetto:Re: [Python-ideas] High time for a builtin function to manage packages (simply)?
On September 5, 2015 at 3:49:07 PM, Giovanni Cannata (cannatag@gmail.com) wrote:
Yes and No. I’m the primary developer/administrator for it now and it doesn’t get much contribution from others. It is also supported by the Python infrastructure team, but there is only a handful of us and I’m the only person on that team who has paid time to work on that and the Infrastructure team is also responsible for many other python.org services. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 6 September 2015 at 05:49, Giovanni Cannata <cannatag@gmail.com> wrote:
We're aware. PyPI is currently the *only* python.org service with a dedicated full time developer (and Donald's time is actually contributed by the OpenStack group at HP rather than being funded directly by the PSF). There are also a number of organisations that donate resources to operating the python.org infrastructure (e.g. the Fastly CDN, and hosting services from Heroku, Rackspace and the Open Source Lab at Oregon State University). Bringing paid development in to support community driven projects, while also ensuring financial sustainability and fiscally responsible management of contributor's funds is an interesting challenge, and one the PSF continues to work to get better at. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On September 6, 2015 at 8:20:54 PM, Nick Coghlan (ncoghlan@gmail.com) wrote:
I'm not exactly full time on PyPI either, though I am full time on packaging. I split my time between PyPI, pip, and any other related work that I need to. So PyPI (as important as it is) really only has part of my attention. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Sat, 5 Sep 2015 at 08:40 Steven D'Aprano <steve@pearwood.info> wrote:
The reason R has a built-in for this is because it's used a vast majority of the time from a REPL to do data analytics in an exploratory manner (think Jupyter notebook type of data exploration). Python does not have the same typical usage style and so I don't think we should follow R in this instance (although I have had R users says that packaging in R is far superior than Python due to ease of getting extensions installed period and not because of the lack of a function, but that's another discussion).
On 9/5/2015 3:08 AM, Stephen J. Turnbull wrote:
Because new builtins have a high threashold to reach, and this doesn't reach it? Installation is a specialized and rare operation. Because pip must be installed anyway, so a function should be in the package and imported? from pip import main (I realized that PM indepedence is part of the proposal. See below.) I think a gui frontend is an even better idea. The tracker has a proposal to make such, once written, available from Idle. https://bugs.python.org/issue23551 I was thinking that the gui code should be in pip itself and not idlelib, so as to be available to any Python shell or IDE. If it covered multiple PMs, then it might go somewhere in the stdlib. -- Terry Jan Reedy
On Sun, Sep 6, 2015 at 7:03 AM, Terry Reedy <tjreedy@udel.edu> wrote:
If there's a simple entry-point like that in an importable module, anyone who wants it as a builtin can simply pre-import it (this would be used interactively anyway). All it'd take would be a known function to import. ChrisA
On 9/5/2015 5:03 PM, Terry Reedy wrote:
Inspired by this thread, I did some experiments and am fairly confident that pip.main can be imported and used directly, bypassing paths, subprocesses, and pipes. -- Terry Jan Reedy
On Sun, Sep 6, 2015 at 12:04 PM, Terry Reedy <tjreedy@udel.edu> wrote:
I can confirm that this is, indeed, possible. I use this exact technique in my tool Briefcase to simplify the process of packaging code as an app bundle. https://github.com/pybee/briefcase/blob/master/briefcase/app.py#L108 Yours, Russ Magee %-)
On 9/6/2015 4:57 AM, Russell Keith-Magee wrote:
There *is*, however, a potential gotcha suggested on the issue by Donald Stufft and verified by me. pip is designed for one command (main call) per invocation, not for repeated commands. When started, it finds and caches a list of installed packages. The install command does not update the cached list. So 'show new_or_upgraded_package' will not work. Your series of installs do not run into this. -- Terry Jan Reedy
Terry Reedy writes:
In your opinion. And in mine! Personally, I don't have a problem with remembering python -m pip, nor do I have a problem with explaining it as frequently as necessary to my students But there are only 20 of them, rather than the thousands that folks like Steven (and you?) are dealing with on python-list -- and there's the rub. I'm suggesting this because of the vehemence with which Steven (among others) objects to any suggestion that packages belong on PyPI, and the fact that he can back that up with fairly distressing anecdotes about the number of beginner posts asking about pip problems. I would really like to see that put to rest.
Installation is a specialized and rare operation.
help(), quit(), and quit are builtins. I never use quit or quit() (Ctrl-D works on all the systems I use), so I guess they are "specialized and rare" in some sense, and I'm far more likely to use dir() and a pydoc HTML server than help(). More to the point, the trouble packaging causes beginners and Steven d'Aprano on python-list is apparently widespread and daily. At some point beginner-friendliness has enough value to make it into the stdlib and even builtins.
I don't pronounce that "install". Discoverability matters a lot for the users in question (which is why I'm not happy with "installer", but it's somewhat more memorable than "pip").
I think a gui frontend is an even better idea.
I think it's a great idea in itself. But IMO it doesn't address this issue because the almost but not really universally-available GUI is Tcl/Tk, which isn't even available in any of the four packaged Python instances I have installed (Mac OS X system Python 2.6 and 2.7, MacPorts Python 2.7 and 3.4, although IIRC MacPorts offers a tk variant you can enable, but it's off by default).
Obviously; it doesn't address the present issue if it's not ensured by ensure_pip. Which further suggests something like ensure_pyqt as well. (Or ensure_tk, if you think that perpetuating Tcl/Tk is acceptable.) I think that's a huge mess, given the size and messiness of the dependencies. I suppose a browser-based interface like that of pydoc could deal with the "universality" issue, but I don't know how fragile it is.
On Sep 6, 2015, at 18:51, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Tcl/Tk, and Tkinter for all pre-installed Pythons but 2.3, have been included with every OS X since they started pre-installing 2.5. Here's a brand new laptop that I've done nothing to but run the 10.10.4 update and other recommended updates from the App Store app: $ /usr/bin/python2.6 Python 2.6.9 (unknown, Sep 9 2014, 15:05:12) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.391)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import Tkinter >>> root = Tkinter.Tk() >>> That works, and pops up an empty root window. And it works with all python.org installs for 10.6 or later, all Homebrew default installs, standard source builds... Just about anything besides MacPorts (which seems to want to build Tkinter against its own Tcl/Tk instead of Apple's) Also, why do you think Qt would be less of a problem? Apple has at various times bundled Qt into OS X and/or Xcode, but not consistently, and even when it's there it's often set up in a way that you can't use it, and of course Apple has never include PyQt or PySide. So, if pip used Qt, a user would have to go to qt.io, register an account, figure out what they need to download and install, figure out how to make it install system-wide instead of per-user, and then repeat for PySide against each copy of Python they want to use. Either that, or pip would have to include its own complete copy of Qt and PySide.
Andrew Barnert writes:
My mistake, it's only MacPorts where I don't have it. I used MacPorts' all-lowercase spelling, which doesn't work in the system Python. (The capitalized spelling doesn't work in MacPorts.)
I recall having problems with trying to build and run against the system Tcl/Tk in both source and MacPorts, but that was a *long* time ago (2.6-ish). Trying it now, on my Mac OS X Yosemite system python 2.7.10, "root=Tkinter.Tk()" creates and displays a window, but doesn't pop it up. In fact, "root.tkraise()" doesn't, either. Oops. On this system, IDLE has the same problem with its initial window, and furthermore complains that Tcl/Tk 8.5.9 is unstable. Quite possibly this window-raising issue is Just Me. But based on my own experience, it is not at all obvious that ensuring availability of a GUI is possible in the same way we can ensure pip.
Also, why do you think Qt would be less of a problem?
I don't. I think "ensure PyQt" would be a huge burden, much greater than Tkinter. Bottom line: IMO, at this point in time, if it has to Just Work, it has to Work Without GUI. (Modulo the possibility that we can use an HTML server and borrow the display engine from the platform web browser. I think I already mentioned that, and I think it's really the way to go. People who *don't* have a web browser probably can handle "python -m pip ..." without StackOverflow.)
On 9/7/2015 3:26 AM, Stephen J. Turnbull wrote:
My impression is that MacParts builds Tkinter 8.6 instead of 8.5.
Mac users who download the PSF Mac installer and want to use tkinter should read https://www.python.org/download/mac/tcltk/ Before the redesign, there was a link to this from the download page, but the redesign seems to have removed it. The page mentions that there may be a window update problem with the apple tk. -- Terry Jan Reedy
Terry Reedy writes:
My impression is that MacParts builds Tkinter 8.6 instead of 8.5.
If you mean that MacPorts' current Tcl and Tk ports install Tcl/Tk 8.6, that is correct.
The page mentions that there may be a window update problem with the apple tk.
It also mentions that various Tk versions "in common use" are unsupported by the python.org-installed Python, and in particular not the Cocoa Tk. I suppose it's not hard to do that? Or maybe chances are that the X11 and Cocoa Tks "just work", but aren't tested for the Mac installers?
On Sep 7, 2015, at 04:33, Stephen J. Turnbull <stephen@xemacs.org> wrote:
It's not just a matter of "not tested"; there are actual glitches with some of the versions, including two pretty serious ones that can lead to a freeze, or to some window management commands being ignored. But once you have some experience with it, and enough test machines of course, it's not actually that hard to build a binary-shippable GUI app that avoids all of these problems and runs against any of Apple's Tk versions from 10.6+ and against the Python.org recommended versions (which I know, because I've done it, at least with Python 2.7 and 3.3). Making it work reliably from the REPL, or for a script that's not wrapped as a .app, is definitely a lot less fun. But people who want to install from within the REPL or the system shell probably don't want the GUI. I don't know about making it work reliably from within IDLE. I don't see any reason IDLE couldn't just launch a .app on Mac if that's a problem, but you have to remember the extra fun bit that the app will get its environment from LaunchServices, not IDLE, so you'd need some other way to tell it to use the current venv. (Possibly this just means the app is linked into the venv?)
I just found this HTML web-based pip interface: Stallion "easy-to-use Python Package Manager interface with command-line tool" * http://perone.github.io/stallion/ * https://pypi.python.org/pypi/Stallion Qt would not be a reasonable requirement; Tk shouldn't be a requirement. I tend to try and work with repeatable CLI commands; rather than package manager GUIs. On Sep 7, 2015 2:26 AM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
On Sat, Sep 05, 2015 at 05:03:36PM -0400, Terry Reedy wrote:
You're right about the first part, but as Chris has already suggested, this need not be *literally* a built-in. Like help() it could be imported at REPL startup. And I'm not really so sure about how rare it is. Sure, installing a single package only happens once... unless you're installing it to multiple installations. Or upgrading the package. Or installing more than one package. Looking at questions on various programming forums, including Python but other languages as well, "how do I install X?" is an extremely common question. And, with the general reluctance to add new packages to the stdlib, and the emphasis on putting them onto PyPI first, I think that it will become even more common in the future.
As I see it, there are three high-level steps to an awesome installer: 1. Have an excellent repository of software to install; 2. have a powerful interactive interface to the repo that Just Works; 3. add a GUI interface. I think that with PyPI we certainly have #1 covered, but I don't think we have #2 yet, there are still too many ways that things can "Not Work". Number 3 is icing on the cake - it makes a great system even better. I didn't specify whether the interactive interface should be a stand-alone application like pip, or an command in the REPL like R uses, or even both. I like the idea of being able to install packages directly from the Python prompt. It works well within R, and I don't see why it wouldn't work in Python either. But it isn't much of an imposition to run "python -m pip ..." at the shell. -- Steve
On Sep 6, 2015, at 19:18, Steven D'Aprano <steve@pearwood.info> wrote:
Personally, I've never found ^Zpython -m pip spam && fg too hard (or just using ! from IPython), but I can understand why novices might. :) Anyway, the problem comes when you upgrade (directly or indirectly) a module that's already imported. Reloading is neither easy (especially if you need to reload a module that you only imported indirectly and upgraded indirectly) nor fool-proof. When I run into problems, I usually don't have much trouble stashing any costly intermediate objects, exiting the REPL, re-launching, and restoring, but I don't think novices would have as much fun. Is there a way the installer could, after working out the requirements, tell you something like "This command will upgrade 'spam' from 1.3.2 to 1.4.1, and you have imported 'spam' and 'spam.eggs' from the package, so you may need to restart after the upgrade. Continue?" That might be good enough. It's not exactly an everyday problem, so as long as it's visible when it's happened and obvious how to work around it so users who run into it for the first time don't just decide Python or pip or spam is "broken" and give up, that might be sufficient. (And a GUI installer integrated into IDLE would presumably have no additional problems, and could make the experience even nicer--especially since it's already got a "Restart Shell" option built in.)
On Mon, Sep 7, 2015 at 1:17 PM, Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
Anyway, the problem comes when you upgrade (directly or indirectly) a module that's already imported. Reloading is neither easy (especially if you need to reload a module that you only imported indirectly and upgraded indirectly) nor fool-proof. When I run into problems, I usually don't have much trouble stashing any costly intermediate objects, exiting the REPL, re-launching, and restoring, but I don't think novices would have as much fun.
Is there a way the installer could, after working out the requirements, tell you something like "This command will upgrade 'spam' from 1.3.2 to 1.4.1, and you have imported 'spam' and 'spam.eggs' from the package, so you may need to restart after the upgrade. Continue?" That might be good enough. It's not exactly an everyday problem, so as long as it's visible when it's happened and obvious how to work around it so users who run into it for the first time don't just decide Python or pip or spam is "broken" and give up, that might be sufficient.
How often does pip actually need to upgrade an already-installed package in order to install something you've just requested? Maybe the rule could be simpler: if there are any upgrades at all, regardless of whether you've imported from those packages, recommend a restart. The use-case I'd be most expecting is this:
In the uncommon case where spam depends on ham v1.4.7 or newer *AND* you already have ham <1.4.7 installed, a simple message should suffice. (Oh, and you also have to not have any version of spam installed already, else you won't be able to use install() anyway.) ChrisA
On September 6, 2015 at 11:26:04 PM, Chris Angelico (rosuav@gmail.com) wrote:
Due to the nature of ``pip install --upgrade``, it's fairly common. At this time ``pip install --upgrade`` is "greedy" and will try to upgrade the named package and all of it's dependencies, even if their is already a version of the dependency installed that satisfies the version constraints. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Sep 6, 2015 9:09 PM, "Chris Angelico" <rosuav@gmail.com> wrote:
On Mon, Sep 7, 2015 at 2:05 PM, Donald Stufft <donald@stufft.io> wrote:
On September 6, 2015 at 11:26:04 PM, Chris Angelico (rosuav@gmail.com)
wrote: this
FWIW the recursive behaviour of --upgrade is perhaps the single most hated feature of pip (almost all scientific packages find it so annoying that they refuse to provide dependency metadata at all), and AFAIK everyone has agreed to deprecate it in general and replace it with a non-recursive upgrade command, just no-one has gotten around to it: https://github.com/pypa/pip/issues/59 So I wouldn't worry about defining special interactive semantics in particular, someone just has to make the patch to change it in general :-) The trickier bit is that I'm not sure there's actually any way right now to know what python packages were affected by a given install or upgrade command, because it can be the case that after 'pip install X' you then do 'import Y' -- the wheel and module names don't have to match, and in practice it's not uncommon for there to be discrepancies. (For example, after 'pip install matplotlib' you can do both 'import matplotlib' and 'import pylab'.) -n
On Sep 6, 2015, at 20:25, Chris Angelico <rosuav@gmail.com> wrote:
Not that often, which is why I said "It's not exactly an everyday problem"; just often enough that some novices are going to run into it once or twice, so it can't be ignored.
I suppose that's possible too. It's overzealous, but it still won't happen _that_ often, so if my suggestion is too much work, this one seems fine to me. Especially if the message made the issue clear, something about "After an upgrade, you should restart, because any packages you already imported may be unchanged or inconsistent".
On 7 September 2015 at 12:18, Steven D'Aprano <steve@pearwood.info> wrote:
Technically it's "import site" that injects those - you have to run with "-S" to prevent them from being installed: $ python3 -c "quit()" $ python3 -Sc "quit()" Traceback (most recent call last): File "<string>", line 1, in <module> NameError: name 'quit' is not defined Regardless, I agree a "site builtin" like help() or quit() is a better option here than a true builtin, and I also think it's a useful idea. I'd make it simpler than the proposed API though, and instead just offer an "install(specifier)" API that was a thin shell around pip.main: try: import pip except ImportError: pass else: def install(specifier): cmd = ["install"] if sys.prefix == sys.base_prefix: cmd.append("--user") # User installs only when outside a venv cmd.append(specifier) # TODO: throw exception when there's a problem pip.main(cmd) If folks want more flexibility, then they'll need to access (and understand) the underlying installer. As far as other possible objections go: * the pkg_resources global state problem we should be able to work around just by reloading pkg_resources (if already loaded) after installing new packages (I've previously tried to address some aspects of that particular problem upstream, but doing so poses significant backwards compatibility challenges) * I believe integration with systems like conda, PyPM, and the Enthought installer should be addressed through a plugin model in pip, rather than directly in the standard library * providing a standard library API for querying the set of installed packages independently of pip is a separate question Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Friday, September 4, 2015 at 10:57:42 PM UTC+5:30, Steven D'Aprano wrote:
Packaging systems suffer from a Law: The quality of the packaging-system is inversely proportional to the quality of the language being packaged [Corollary to the invariable NIH syndrome that programmers suffer from] Notice: Haskell' hackage : Terrible Python's pip: Bad Ruby's gems: Ok Perl's CPAN : Good Debian's apt (mishmash of perl, shell and other unspeakbles) : Superb
Steven D'Aprano writes:
On Fri, Sep 04, 2015 at 11:05:51AM +0900, Stephen J. Turnbull wrote:
And? The objection will still be made. And I doubt Guido will agree that typing is a precedent that can be used to justify inclusion of turtle localizations. He might very well be in favor AFAIK, I just doubt he would base that on the precedent of typing. The rest of your post I don't really agree with, but I have no strong counterarguments, either. Here I just wanted to point out that the way these discussions have gone in the past is that without special support from the BDFL, the usual path for these things is through PyPI. Especially since AFAICT we don't actually have an implementation yet. Steve
On 4 September 2015 at 12:45, Steven D'Aprano <steve@pearwood.info> wrote:
Block based languages are to text based ones as picture books are to the written word - to get the combinatorial power of language into play, you need to be learning systems that have the capacity to be self hosting. You can write a Python interpreter in Python, but you can't write a Scratch environment in Scratch. This is reflected in the way primary schools digital environment curricula are now being designed - initial concepts of algorithms and flow control can be introduced without involving a computer at all (e.g. through games like Robot Turtles), then block based programming in environments like Scratch introduce the use of computers in a way that doesn't require particularly fine motor control or spelling skills. However, a common aspect I've seen talking to teachers from Australia, the US and the UK is that the aim is always to introduce kids to the full combinatorial power of a text based programming environment like Python, since that's what unlocks the ability to use computers to manipulate real world data and interfaces, rather than just a local constrained environment like the one in Scratch. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Sep 4, 2015 at 8:55 AM, Petr Viktorin <encukou@gmail.com> wrote:
+1. These modules could simply import a boatload of stuff from "turtle" under new names, which would make them fairly slim. Question: Should they start with "from turtle import *" so the English names are always available? It'd ensure that untranslated names don't get missed out, but it might be confusing. ChrisA
Chris Angelico writes:
That would be pretty horrible, and contrary to the point of allowing the new user to learn algorithmic thinking in a small world using intuitively named commands. I would think the sensible thing to do is to is invite participation from traditional translation volunteers with something like import turtle from i18n import _ _translations = { 'turtle' : _('turtle'), ... } for name in dir(turtle): if name in _translations: eval("from turtle import {} as {}".format(name, _translations[name])) elif english_fallbacks_please: eval("from turtle import {}".format(name))
On Fri, Sep 4, 2015 at 12:34 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Yeah, that'd be better than including all the original English names. And _translations can be generated easily enough: import turtle print("{" + ", ".join("%r: _(%r)" % (n, n) for n in dir(turtle)) + "}") Though the diffs would be disgusting any time anything in turtle changes. ChrisA
participants (25)
-
Al Sweigart -
Andrew Barnert -
Ben Finney -
Brett Cannon -
Chris Angelico -
Chris Barker - NOAA Federal -
David Wilson -
Donald Stufft -
Giovanni Cannata -
Ionel Cristian Mărieș -
Ludovic Gasc -
Matthias Bussonnier -
Nathaniel Smith -
Nick Coghlan -
Paul Moore -
Petr Viktorin -
Prof. Dr. L. Humbert -
random832＠fastmail.us -
Russell Keith-Magee -
Rustom Mody -
Stephen J. Turnbull -
Steven D'Aprano -
Stéphane Wirtel -
Terry Reedy -
Wes Turner