Re: Simple graphic library for beginners
On 01/11/2018 11:48 PM, Jan Erik Moström wrote: > On 10 Jan 2018, at 13:40, Jan Erik Moström wrote: > >> I'm looking for a really easy to use graphic library. The target users >> are teachers who have never programmed before and is taking a first >> (and possible last) programming course. > > Thanks for all the suggestions, I'm going to take a look at them and see > what fits my requirements best. I'm glad you are willing to overlook all the noise in this thread! Good luck and let us know what path you end up taking. -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple graphic library for beginners
On 12 January 2018 at 17:25, Mikhail V wrote: > And the target Python where the package will be installed should be defined by > a switch, e.g. 'pip -2', 'pip -3' (in analogy with 'py -2', 'py -3'). > The question is though, how pip will know what version(s) of python I have, > and > if I installed them later? Hmm, not an easy problem. So in this case pip shoud > track the multiple versions each time I install another version of python. If that's how you want it to behave, just use "py -2 -m pip" or "py -3 -m pip" or "py -3.6 -m pip" as required. Works now, no hassle. You still have to install pip (the package, not the executable) in each Python home, but that's just how Python packages work (and pip is already installed by default when you install Python on Windows anyway). Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple graphic library for beginners
On Fri, Jan 12, 2018 at 10:38 AM, Paul Moore wrote: > On 12 January 2018 at 06:47, Steven D'Aprano > wrote: >> If pip is joined at the hip to a specific version of Python, I think that >> we ought to be able to specify the version number like we can with Python. >> >> Something like: >> >> pip ... # use whichever version of pip comes first on the PATH >> pip3.6 ... # use the pip installed with Python 3.6 >> pip2.7 ... # use the pip installed with Python 2.7 > > Well, that's sort of how it's intended to work, but in practice it > doesn't seem to be as straightforward as it ought to be. I can't > really say why, as it's a Unix-only thing and I don't really > understand the reasons, but it's why I'm a fan of the "python -m pip" > approach. There's discussion on the pip tracker if you're interested > enough to go searching - I know it's something that's been debated, > but I don't recall the context. In general I think more than one app and executable with same name on a system already asks for problems. On Windows I had issues with pip and pygame and I have two Pythons - 2.7.14 and 3.6.2. The problem was that I could not make it install to 2.7, and tried many options, looking in SO there were so many different solutions, but finally I found something that reinstalled newer pip, but I don't remember frankly. My opinion (from Windows user's POV) - I'd prefer if there should be only one PIP in system, so running pip will unambigiosly mean that I run (or upgrade) THE pip. (and not something which I don't even know where it is located). Ideally also it should be installed in separate Directory. So I'd have folders: python 27 python 36 pip And the target Python where the package will be installed should be defined by a switch, e.g. 'pip -2', 'pip -3' (in analogy with 'py -2', 'py -3'). The question is though, how pip will know what version(s) of python I have, and if I installed them later? Hmm, not an easy problem. So in this case pip shoud track the multiple versions each time I install another version of python. Mikhail -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple graphic library for beginners
bartc writes: > If you a beginner, outsider, or infrequent user of Python with no idea of > what the latest version is, except that you already have 3.6 but it might > have a problem, which would you choose? Unless you are also unable to read *and* understand, by any chance you'd follow the very first link related to 3.7, and seeing "This is an early developer preview of Python 3.7" you could *decide* if that's appropriate for your goal. But it seems you belong to yet a different category of people indeed, who blindly follows the "I'm feeling lucky" Google advices. ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. l...@metapensiero.it | -- Fortunato Depero, 1929. -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple graphic library for beginners
On 12/01/2018 01:56, Chris Angelico wrote: On Fri, Jan 12, 2018 at 12:21 PM, bartc wrote: On 11/01/2018 23:23, Chris Angelico wrote: On Fri, Jan 12, 2018 at 10:11 AM, bartc wrote: I'm almost ready to plonk you, but I think there is still SOME value in your posts. But please, stop denigrating what you don't understand. And please try to see things from the pointer of view of a beginner or outsider, where anything to do with Python seems to have a bewildering and conflicting array of solutions. You mean the sort of person who goes to the front page The front page of what? and sees just two options, 2.7 and 3.6, and won't see anything about 3.7 until it's released? Google for 'download python windows'. The first hit is this site: https://www.python.org/downloads/windows/ But before you click on it, the google search summary includes two links in big type, to 2.7.14 and 3.7.0a2 (which are to information not downloads). That is a strong suggestion that those are the latest versions. When you do go to that page, you are looking for a link that has 'download' next to it. The first 6 such links on the page are all for 3.7. If you a beginner, outsider, or infrequent user of Python with no idea of what the latest version is, except that you already have 3.6 but it might have a problem, which would you choose? Again, a number of people have put in a lot of hours to make that easy. It appears that because of that I'm not allowed to make any observations, not ones that could be construed as criticism. But as another example, search for 'download pelles c', the first hit should be this page: http://www.pellesc.de/index.php?lang=en&page=download That I think is a better presentation than Python's. It's also clearer which is 32-bit and which is 64. (Will a beginner programmer who's not going to be coding low level really appreciate the difference between x86 and x86-64?) But here's another example that goes the other way; the first hit for 'download lua windows' is this: https://www.lua.org/download.html A rather puzzling page with some gobbledygook on it that appears to do with Linux. And the download link gives a list of tar.gz files; not very useful. The second hit isn't much more use; the third one is more promising. I do get the impression that applications that originate on Windows are generally more accessible. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
在 2006年12月8日星期五 UTC+8下午7:07:09，Mark Tarver写道： > How do you compare Python to Lisp? What specific advantages do you > think that one has over the other? > > Note I'm not a Python person and I have no axes to grind here. This is > just a question for my general education. > > Mark 12 years ago. -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple graphic library for beginners
On Friday, January 12, 2018 at 6:52:32 AM UTC, Steven D'Aprano wrote: > On Fri, 12 Jan 2018 12:45:04 +1300, Gregory Ewing wrote: > > > Seems to me it would help if pip were to announce which version of > > Python it's installing things into. And instead of just saying "not > > compatible with this version of Python", say "not compatible with Python > > X.Y.Z". That would make these kinds of problems much easier to diagnose. > > This. > > If pip is joined at the hip to a specific version of Python, I think that > we ought to be able to specify the version number like we can with Python. > > Something like: > > pip ... # use whichever version of pip comes first on the PATH > pip3.6 ... # use the pip installed with Python 3.6 > pip2.7 ... # use the pip installed with Python 2.7 The time machine has struck again. The scripts directory on Windows always gives you three executables. pip.exe is always one of them, and then (say) pip3.exe and pip3.6.exe. > etc. > > And don't say "use a venv" :-) > -- > Steven D'Aprano -- Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple graphic library for beginners
On Fri, Jan 12, 2018 at 9:00 PM, Paul Moore wrote: > On 12 January 2018 at 09:12, Tim Golden wrote: >> I think the shame here is that there is a learning opportunity on both >> sides. As Paul says: by and large, the huge amount of work which the Python >> Packaging team, especially the pip developers, have put in has paid off. >> It's now usually possible to say: "pip install XXX" and have it work out of >> the box for any recentish version of Python on any recentish version of a >> mainstream OS. Once people understand the basics of using that "interface", >> many things become simple. >> >> Unfortunately, where that *doesn't* work, it probably won't be because of >> low-hanging fruit: it'll be because of some strange interaction of different >> versions, odd leftover PATH setups, obscure Windows C Runtime redistribution >> issues, poor encoding interactions between Python and the Windows console, >> and so on. > > Agreed. The other factor, and in my experience one of the most > frustrating to deal with, is when people *don't* start with "pip > install XXX", but instead find some complex process on the web, try > that, have it fail, and then we have to help them untangle whatever > mess that might have left for them. This is particularly common on Windows, where the normal way to get software is "go look on the web, download something, hope it's the right thing, and give it free reign to install itself on your computer". On Linux systems, people tend to be a bit more familiar with the concept of package managers, so they aren't surprised to learn that Python has one. (Of course, there is still the big question of "which package manager ought I to be using", very much an XKCD 927 situation, but at least that's easier to ask about. "How did you install Python?" "With apt-get." "Okay, then use apt-get to install the package." "It's not in apt's repositories." "No problem, pip it is.") ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Generating SVG from turtle graphics
On 2018-01-11 12:03, Steven D'Aprano wrote:
> I'd like to draw something with turtle, then generate a SVG file from it.
>
> Is this possible?
>
> If not, is there something I can do which lets me plot lines, shapes and
> curves and output to SVG?
>
> Ideally, I'd like to draw a figure pixel by pixel, and then have the SVG
> library fit a bezier curve to it.
>
You *could* use matplotlib, which can export to SVG.
Of course, the API is far from ideal for drawing arbitrary shapes --
though it's naturally quite good with lines.
There are some helpful examples in the docs:
https://matplotlib.org/examples/
https://matplotlib.org/examples/shapes_and_collections/index.html
https://matplotlib.org/api/patches_api.html
https://matplotlib.org/api/pyplot_summary.html
... and so on ...
I just played around with it for a few minutes to get a feel for how
much boilerplate you need -
###
from matplotlib import pyplot as plt
from matplotlib.patches import Circle, Rectangle
import numpy as np
ax = plt.gca()
ax.set_ylim([-2, 2])
ax.set_xlim([-2, 2])
ax.set_aspect('equal')
plt.axis('off')
circle = Circle([0,0], 1, fc='red', ec='none')
halfdiag = np.sqrt(0.5)
rect = Rectangle([-halfdiag, -halfdiag],
2*halfdiag, 2*halfdiag,
fc='yellow', ec='none')
ax.add_patch(circle)
ax.add_patch(rect)
plt.savefig('/tmp/test.svg')
###
- and this gave a reasonable-looking SVG -
###
http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd";>
http://www.w3.org/2000/svg";
xmlns:xlink="http://www.w3.org/1999/xlink";>
*{stroke-linecap:butt;stroke-linejoin:round;}
--
https://mail.python.org/mailman/listinfo/python-list
Re: Simple graphic library for beginners
On 12 January 2018 at 09:12, Tim Golden wrote: > I think the shame here is that there is a learning opportunity on both > sides. As Paul says: by and large, the huge amount of work which the Python > Packaging team, especially the pip developers, have put in has paid off. > It's now usually possible to say: "pip install XXX" and have it work out of > the box for any recentish version of Python on any recentish version of a > mainstream OS. Once people understand the basics of using that "interface", > many things become simple. > > Unfortunately, where that *doesn't* work, it probably won't be because of > low-hanging fruit: it'll be because of some strange interaction of different > versions, odd leftover PATH setups, obscure Windows C Runtime redistribution > issues, poor encoding interactions between Python and the Windows console, > and so on. Agreed. The other factor, and in my experience one of the most frustrating to deal with, is when people *don't* start with "pip install XXX", but instead find some complex process on the web, try that, have it fail, and then we have to help them untangle whatever mess that might have left for them. That's really annoying because we can't really do anything about out of date information - and expecting people to realise that things are moving fast enough that 6 month old instructions are out of date isn't realistic either. (In fact, until this thread I wasn't aware that pygame had published wheels, so I'd have probably tried something unnecessarily complex myself - just proves that even being intimately familiar with the packaging ecosystem isn't enough!!!) > All of these admit of solutions (if only by way of more informative error > messages and useful FAQs) but they take time and patience to reproduce and > work through. Many people -- and especially beginners -- don't really have > the time or the inclination to follow through. They're not really interested > in the mechanics of pip or the interaction of Python with the Windows > installation subsystem. They just want to use numpy or pygame, or whatever. > > Where there *are* people who are willing to take the time to work things > through, we [the Python community and especially the packaging/pip crew] can > welcome them and try to identify weak spots in our own story. But of course > we react poorly if someone wants merely to dismiss stuff. (Typical tweet: > "Sigh; Python packaging is still broken!"). > > I've actually been installing pygame quite a few times recently as part of a > Coding Dojo I help to run once a term at a school in South London. And, even > with the wonderful packaging work which the pygame guys have done to get > wheels on PyPI, it's still sometimes a little painful. Of course, in that > context, I'm just hustling to get people up-and-running and I'll do whatever > it takes without stopping to take notes. So I sympathise when people say > it's not easy for them. But not when they're dismissive about it. Understood. I've recently been working with a complete beginner, and it's quite surprising (and a real eye-opener) where the pain points lie. Running python and pip (PATH issues) was a huge problem, but "pip install numpy" was trivial. That's totally not what I'd expected... Often the big issue for people like myself working on packaging is being too close to the problem, and as a result focusing on the wrong things. *Any* feedback from beginners is good for improving that situation. If you have any details on particular pain points your users have experienced, feel free to pass them on to me and I'll see if I can work them into something actionable. I understand what you mean though, getting details of what's wrong isn't the priority when you have a class to get running. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple graphic library for beginners
On 12 January 2018 at 06:47, Steven D'Aprano wrote: > On Fri, 12 Jan 2018 12:45:04 +1300, Gregory Ewing wrote: > >> Seems to me it would help if pip were to announce which version of >> Python it's installing things into. And instead of just saying "not >> compatible with this version of Python", say "not compatible with Python >> X.Y.Z". That would make these kinds of problems much easier to diagnose. > > This. That does indeed sound like a reasonable suggestion. I don't know immediately where in the code we'd put something like that (a banner that says "Installing packages into Python at " wouldn't be too hard, it could probably be added near the top of pip._internal.commands.InstallCommand.run(), but the compatibility stuff is a lot trickier because of how pip's finder works) but I'm sure PRs would be acceptable. > If pip is joined at the hip to a specific version of Python, I think that > we ought to be able to specify the version number like we can with Python. > > Something like: > > pip ... # use whichever version of pip comes first on the PATH > pip3.6 ... # use the pip installed with Python 3.6 > pip2.7 ... # use the pip installed with Python 2.7 Well, that's sort of how it's intended to work, but in practice it doesn't seem to be as straightforward as it ought to be. I can't really say why, as it's a Unix-only thing and I don't really understand the reasons, but it's why I'm a fan of the "python -m pip" approach. There's discussion on the pip tracker if you're interested enough to go searching - I know it's something that's been debated, but I don't recall the context. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple graphic library for beginners
On 12 January 2018 at 06:45, Steven D'Aprano wrote: >> The recommendation was already given to use "python3 -m pip". That gets >> around those problems. > > If you google for installation instructions, they're nearly always given > in terms of "use pip", not "use python3.4 -m pip". > > My point isn't that there is *no* solution to this problem, but that its > not necessarily an *obvious* solution. We've discussed this a number of times on the pip mailing lists and changing recommendations like this is a slow and difficult process. We're only just managing to get people to change websites from recommending easy_install... The question of "pip" vs "python -m pip" is a hard one. On Windows, "py -m pip" is better for a lot of reasons, but the Unix users involved in the debates were pretty reluctant to standardise on "python -m pip" rather than the familiar "pip" (or "pip3"? I'm not sure I completely follow what is natural for Unix users). Personally, I still think a lot of confusion would be addressed if we settled on "python -m pip" (with the established understanding that "python" stands for whichever of "python", "python2", "python3", "py", "/full/path/to/python", ... you're using to access Python) - but I don't know how we make that the "obvious" approach. For all of Bart's rhetoric, it *is* hard to find a good way to present a consistent message when people go to Google/Stack Overflow first, and only check the official docs as a last resort. >>> How do I deal with permissions errors? [semi-rhetorical question -- I >>> know *an* answer, but I don't know if it is the *right* answer] >> >> That's a fair point, but a perms error is reported properly by pip. > > Is it? Last time I tried, I just got an uninformative error that the > package installation failed. Admittedly that was probably a year or two > ago, so maybe the error message has been improved. Installs from wheels are not bad, as pip is in control of the whole process. Installs from source are dreadful, because it's setuptools/distutils that give the errors and pip can't do anything more than report the tracebacks produced (we tried trimming junk and summarising, and got lots of complaints about hiding the causes of problems). But pip's error reporting isn't wonderful. We do tend to spew out tracebacks rather than user-friendly messages. It's usually easy enough to work out what the common tracebacks mean, but they are still an intimidating wall of text to a non-expert. The usual "contributions accepted" applies here, as pip developer time is extremely limited, but it's not going to be an easy task for anyone. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple graphic library for beginners
On 12/01/2018 08:47, Paul Moore wrote: On 12 January 2018 at 01:21, bartc wrote: On 11/01/2018 23:23, Chris Angelico wrote: On Fri, Jan 12, 2018 at 10:11 AM, bartc wrote: I'm almost ready to plonk you, but I think there is still SOME value in your posts. But please, stop denigrating what you don't understand. And please try to see things from the pointer of view of a beginner or outsider, where anything to do with Python seems to have a bewildering and conflicting array of solutions. The beginners I've worked with downloaded Python 3.6 and did "pip install numpy", successfully and without help from me. Sure, some beginners have issues, but they are usually willing to be helped. To be as aggressively resistant to the simplest suggestions the way you're being isn't the behaviour of a beginner in my experience. I think the shame here is that there is a learning opportunity on both sides. As Paul says: by and large, the huge amount of work which the Python Packaging team, especially the pip developers, have put in has paid off. It's now usually possible to say: "pip install XXX" and have it work out of the box for any recentish version of Python on any recentish version of a mainstream OS. Once people understand the basics of using that "interface", many things become simple. Unfortunately, where that *doesn't* work, it probably won't be because of low-hanging fruit: it'll be because of some strange interaction of different versions, odd leftover PATH setups, obscure Windows C Runtime redistribution issues, poor encoding interactions between Python and the Windows console, and so on. All of these admit of solutions (if only by way of more informative error messages and useful FAQs) but they take time and patience to reproduce and work through. Many people -- and especially beginners -- don't really have the time or the inclination to follow through. They're not really interested in the mechanics of pip or the interaction of Python with the Windows installation subsystem. They just want to use numpy or pygame, or whatever. Where there *are* people who are willing to take the time to work things through, we [the Python community and especially the packaging/pip crew] can welcome them and try to identify weak spots in our own story. But of course we react poorly if someone wants merely to dismiss stuff. (Typical tweet: "Sigh; Python packaging is still broken!"). I've actually been installing pygame quite a few times recently as part of a Coding Dojo I help to run once a term at a school in South London. And, even with the wonderful packaging work which the pygame guys have done to get wheels on PyPI, it's still sometimes a little painful. Of course, in that context, I'm just hustling to get people up-and-running and I'll do whatever it takes without stopping to take notes. So I sympathise when people say it's not easy for them. But not when they're dismissive about it. TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple graphic library for beginners
On 12 January 2018 at 01:21, bartc wrote: > On 11/01/2018 23:23, Chris Angelico wrote: >> >> On Fri, Jan 12, 2018 at 10:11 AM, bartc wrote: > > >> I'm almost ready to plonk you, but I think there is still SOME value >> in your posts. But please, stop denigrating what you don't understand. > > > And please try to see things from the pointer of view of a beginner or > outsider, where anything to do with Python seems to have a bewildering and > conflicting array of solutions. The beginners I've worked with downloaded Python 3.6 and did "pip install numpy", successfully and without help from me. Sure, some beginners have issues, but they are usually willing to be helped. To be as aggressively resistant to the simplest suggestions the way you're being isn't the behaviour of a beginner in my experience. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple graphic library for beginners
On 2018-01-11 12:37, Oivvio Polite wrote: On ons, jan 10, 2018 at 01:40:28 +0100, Jan Erik Moström wrote: I'm looking for a really easy to use graphic library. The target users are teachers who have never programmed before and is taking a first (and possible last) programming course. I do a two day workshop for design and illustration students once a year and use Processing (https://processing.org) for it. It's a programming tool primarly for visual artists. The original version uses a subset of Java but there is also a python mode (https://py.processing.org). I've found it quite appropriate for an educational setting. I was going to suggest p5.js... the tutorials on YouTube under 'The Coding Train' are pretty helpful. -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple graphic library for beginners
On Fri, Jan 12, 2018 at 5:45 PM, Steven D'Aprano wrote: > On Fri, 12 Jan 2018 12:14:03 +1100, Chris Angelico wrote: >>> How do I deal with permissions errors? [semi-rhetorical question -- I >>> know *an* answer, but I don't know if it is the *right* answer] >> >> That's a fair point, but a perms error is reported properly by pip. > > Is it? Last time I tried, I just got an uninformative error that the > package installation failed. Admittedly that was probably a year or two > ago, so maybe the error message has been improved. Hmm. Last time I tried, it was pretty informative, but that was on Linux. I actually don't know about Windows, and whether there are weird situations that would result in obscure messages. Would have to get someone to try it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple graphic library for beginners
Am 11.01.18 um 06:16 schrieb Michael Torrie: On 01/10/2018 01:13 PM, bartc wrote: I couldn't see anything obviously simple there. A lot seems to do with interaction which is always much more complicated than just drawing stuff. Yes the link didn't have the simple examples I hoped for. How's this: - import pygame import time pygame.init() screen = pygame.display.set_mode((1024, 768) ) red = (255,0,0) green = (0,255,0) screen.fill( (255,255,255) ) pygame.draw.lines(screen, red, False, ((0,0),(100,100))) pygame.draw.lines(screen, green, False, ((0,100),(100,0))) pygame.display.update() time.sleep(5) pygame.quit() -- This looks very reasonable. If one wants buttons, however, I still recommend to use Tkinter. The same program looks not much more complex: -- import tkinter as Tk from tkinter import ttk # Boilerplate: set up a resizeable canvas in a window root = Tk.Tk() canvas = Tk.Canvas(root) canvas.pack(expand=True, fill='both') canvas.create_line(0, 0, 100, 100, fill='red') canvas.create_line(0, 100, 100, 0, fill='green') # add a button to close the program button = ttk.Button(root, text='Leave', command=exit) button.pack() # run the program Tk.mainloop() --- The boilerplate looks a bit less intuitive - instead of pygame.init() you have to set up a canvas in a window - but the actual drawing code looks quite similar. And it is trivial to add a button or other widgets, as shown above. Christian -- https://mail.python.org/mailman/listinfo/python-list
