Re: Running python from pty without prompt
Just in case it's not clear, this is running on a (virtual) PTY. -- https://mail.python.org/mailman/listinfo/python-list
Re: Running python from pty without prompt
Michael, yes. FYI, I found out why this works. Pressing Ctrl-D flushes the input buffer. If you do this on an empty line, it causes read(...) to return 0 which Ruby considers end of input for the script, but the pipe is not closed. -- https://mail.python.org/mailman/listinfo/python-list
Re: Running python from pty without prompt
Here are some examples of different languages: https://github.com/ioquatix/script-runner/blob/master/examples/python-eot.py -- https://mail.python.org/mailman/listinfo/python-list
Teaching Programming
Dear Friends, I'm looking for some help from the Python community. I hope this is the right place to ask for information. I'm putting together a website aimed at high school students and teachers, and would like to make sure the following page is as good as possible: http://programming.dojo.net.nz/languages/python/index In particular, "Why would I learn this language?" section needs to have a few paragraphs. I don't use Python predominantly so I hoped that you could provide the main reasons why Python is a language someone would want to learn about. Any other suggestions or ideas for the Python page would be fantastic, and any suggestions to other pages in general is also very helpful. http://programming.dojo.net.nz/ Kind regards, Samuel -- http://mail.python.org/mailman/listinfo/python-list
Re: Teaching Programming
Dear Chris, Thanks for reading further into the site. Yes, it is complicated to provide a good comparison. It isn't always accurate and I welcome feedback. Please be aware that orange does not mean problem - it simply means take note that there may be potential issues that you need to consider. It is highly subjective, so I appreciate your feedback. The red dot is when there is definitely an issue that needs to be taken into consideration. It isn't "Okay, Warning, Error" because it isn't possible to make this kind of judgement without being omnipotent. There are several reason why I decided to rate the syntax as not being simple. 1) Indentation model is not appreciated by everyone - I think its a good model, but feedback from some other people has been that they don't like it. Also, I've had perfectly good Python code fall to bits after editing in a different editor. I'm not saying that this was the fault of Python, but in an educational context it might be a problem, since people are fairly limited and don't understand these issues. 2) I don't think that the list comprehension integrates well with the rest of the language. It is an additional syntactic construct which seems to be separate from the rest of the language. It would be nice if list comprehension was implemented in a way that was more general, using a general closure syntax for example. This is just my opinion, and it might not be valid (I don't research this point very heavily). I appreciate that in general the Python syntax is good and concise. It is hard. Some teacher might want to consider these issues more carefully. Do you think I should change that spot to green? I don't have a problem with doing that, as long as it makes sense. Thanks for providing the syntax images, they are very interesting. With regards to Perl, yes, this is probably something I need to investigate further. It is not always easy to do a comparison of this nature. From my experience, Perl generally seems to have a robust object model that is consistently implemented (even if the syntax is pretty wonky at times). However, in a sense, it is no better or worse than Python implementation... so why is it green dot? Do you think I should change Perl to orange or Python to green. The main criteria is whether it is going to be an issue in an educational context - this means, for new programmers, or those who might make error easily (syntax, semantic), etc. Also, I wonder if Visual Basic needs to be reevaluated on this criteria too. I guess what is important is the relative importance. I will bring this issue up on the Perl mailing list in order to get advice. Would you recommend changing Perl to orange? Thanks for your well thought out response, it is very helpful. Kind regards, Samuel On 4/05/2010, at 1:06 AM, Chris Rebert wrote: > On Mon, May 3, 2010 at 5:29 AM, Chris Rebert wrote: >> On Mon, May 3, 2010 at 5:05 AM, Samuel Williams >> wrote: >>> Dear Friends, >>> >>> I'm looking for some help from the Python community. I hope this is the >>> right place to ask for information. >>> >>> I'm putting together a website aimed at high school students and teachers, >>> and would like to make sure the following page is as good as possible: >>> http://programming.dojo.net.nz/languages/python/index >>> In particular, "Why would I learn this language?" section needs to have a >>> few paragraphs. I don't use Python predominantly so I hoped that you could >>> provide the main reasons why Python is a language someone would want to >>> learn about. > >> - A very clean syntax and elegant design, compared to other languages > > Also, I take issue with your classifying Python as orange with regard > to "Is the general syntax simple and concise?" on > http://programming.dojo.net.nz/resources/programming-language-comparison/index > Python's syntax is at least as simple, if not simpler, than Ruby's, > which you rate as green. Ruby may be /slightly/ more concise than > Python in certain cases due to its Perl influences, but those > instances of specialized syntax also make it more complex. > To wit, I refer you to > http://webcache.googleusercontent.com/search?q=cache:dyugd_KlqvcJ:blog.nicksieger.com/articles/2006/10/27/visualization-of-rubys-grammar+ruby+grammar+visualization&cd=1&hl=en&ct=clnk&gl=us > Note the complexity of the graph for Ruby's grammar. By comparison, > here is the same graph for Python (generated from a file linked to in > the post's comment thread): > http://rebertia.com/images/python_grammar_graph.png > (Disclaimer: Neither of the graphs are current.) > > Additionally, you rate Python orange but P
Re: Teaching Programming
Dear Chris, I will take your feedback into consideration and let you know the outcome when I have time to think about it. Again, I appreciate your thoughts. Thanks for taking the time to think about the comparison chart. Kind regards, Samuel On 4/05/2010, at 1:58 AM, Chris Rebert wrote: >> I appreciate that in general the Python syntax is good and concise. It is >> hard. Some teacher might want to consider these issues more carefully. Do >> you think I should change that spot to green? I don't have a problem with >> doing that, as long as it makes sense. > > Yes, I do think it ought to be green, though I admit I'm not unbiased > on this. I will point out that (1) does not seem related to > "simplicity and conciseness", which is what that row in the comparison > claims to be about. > >> With regards to Perl, yes, this is probably something I need to investigate >> further. It is not always easy to do a comparison of this nature. From my >> experience, Perl generally seems to have a robust object model that is >> consistently implemented (even if the syntax is pretty wonky at times). >> However, in a sense, it is no better or worse than Python implementation... >> so why is it green dot? Do you think I should change Perl to orange or >> Python to green. > > I'm unsure, but in either case, at least based on my limited knowledge > of Perl 5, it again seems rather strange for Python & Perl to not be > rated approximately the same in this area (if anything, I'd think Perl > might be slightly worse off due to its syntax; but again, I'm not > unbiased and my Perl knowledge is limited). -- http://mail.python.org/mailman/listinfo/python-list
Re: new extension generator for C++
Dear Rouslan,
It looks interesting. I say go for it. You will learn something and might make
some improvements on existing ideas.
I recommend putting the code on www.github.com
Kind regards,
Samuel
On 4/05/2010, at 8:44 AM, Rouslan Korneychuk wrote:
> Hi, I'm new here. I'm working on a program that exposes C++ declarations to
> Python and I was wondering if there is any interest in it.
>
> It's a hobby project. I was originally using Boost.Python on another project
> but found a couple of things I didn't like. Eg: you can't really have private
> constructors. If you want a Python object created, you either have to expose
> the constructor in Python, or create an instance of the object somewhere else
> in memory, and have it either copied to the PyObject or have the PyObject
> hold a reference to it. I was working on a rudimentary 3D game engine that
> was a Python extension. It was important to avoid copying potentially huge
> amounts of data, but to have almost every PyObject just be a pointer to
> another object (and the object already is just a few or even one pointer)
> seemed like an pointless compromise, considering that I was writing code that
> was specifically designed to be a Python extension (There was also another
> issue I came across but don't remember now).
>
> So I looked for other solutions and noticed that Py++ (which simply generates
> Boost.Python code for you) was based on a seperate program called GCCXML. I
> figured I could use GCCXML and generate code however I wanted. So I did.
>
> My program generates human-readable code (it even uses proper indentation).
> The program still has a lot of work to be done on it, but it can already
> generate working Python extensions.
>
> It takes an input file like this:
>
>
>module doc string
>
>
>class doc string
>
>
>
>
>
>
>
> You can probably figure out what the resulting code does. The goal is to
> generate code that is as close to hand-written code as possible. It even
> forgoes using PyArg_ParseTupleAndKeywords and has the argument checks
> hard-wired. It also generates a header file that contains a PyObject
> implementation of MyClass called obj_AClass, with every constructor fowarded
> and with the new and delete operators overloaded to play nice with Python's
> memory handler:
> ...
> extern PyTypeObject obj_AClassType;
>
> struct obj_AClass {
>PyObject_HEAD
>MyClass base;
>bool initialized;
>
>void *operator new(size_t s) {
>void *ptr = PyMem_Malloc(s);
>if(!ptr) throw std::bad_alloc();
>return ptr;
>}
>
>void operator delete(void *ptr) {
>PyMem_Free(ptr);
>}
>
>obj_AClass(MyClass const & _0) : base(_0) {
>PyObject_Init(reinterpret_cast(this),&obj_AClassType);
>initialized = true;
>}
>
>obj_AClass(unsigned int _0) : base(_0) {
>PyObject_Init(reinterpret_cast(this),&obj_AClassType);
>initialized = true;
>}
>
> };
> ...
>
> If you want to expose one overload of a constructor or function but not the
> others, you can add overload="list,of,args" to or . Default
> values for arguments are handled automatically. When handling overloaded
> functions, it checks the types of the arguments to pick the best overload,
> taking into consideration polymorphism and the fact that basic types like
> ints can be converted from one-another. It will automatically detect if two
> overloads match to the same set of Python arguments (eg: void func(float) vs
> void func(double)). The only issue is it will not use keyword arguments for
> overloaded functions (I don't know if that can even be done reliably *and*
> efficiently. I would need to give it more thought).
>
> If there is enough interest I can put this project up on SourceForge or
> Google Code.
> --
> http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: Teaching Programming
I personally like indentation. I just wonder whether it is an issue that some people will dislike. But anyway, I updated the language comparison to remove this critique. Kind regards, Samuel On 4/05/2010, at 9:22 PM, Jean-Michel Pichavant wrote: > André wrote: >> To Samuel Williams:(and other interested ;-) >> >> If you want to consider Python in education, I would encourage you >> have a look at http://www.python.org/community/sigs/current/edu-sig/ >> >> I think you will find that there are quite a few resources available - >> perhaps more than you are aware of. >> >> And, I don't think that because "some people do not like the >> indentation strategy" is a valid reason not to consider that Python's >> syntax is concise and simple. Actually, I would almost argue for the >> contrary. Indentation indicate programming structure/logic very >> clearly, without the need for arbitrary keywords and other punctuation >> symbols. There are very few keywords in the language. >> >> You indicate that Python programs are readable. They are also known >> to be short (much shorter than some other languages). >> André >> > Python indentation has been already discussed many times around, I remember > someone saying something like "How is it possible not to like indentation > while any decent programmer will use it no matter the language, including all > those which feature statements/keywords for blocks". > > JM > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Is Python a functional programming language?
Dear Friends, Is Python a functional programming language? Is this a paradigm that is well supported by both the language syntax and the general programming APIs? I heard that lambdas were limited to a single expression, and that other functional features were slated for removal in Python 3... is this the case or have I been misinformed? Finally, even if Python supports functional features, is this a model that is used often in client/application code? Kind regards, Samuel -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python a functional programming language?
Thanks to everyone for their great feedback, it is highly appreciated. Kind regards, Samuel -- http://mail.python.org/mailman/listinfo/python-list
