Re: Python use growing fast
On 01/10/2011 08:31 PM, Katie T wrote: On Mon, Jan 10, 2011 at 10:29 PM, John Nagle na...@animats.com wrote: On 1/10/2011 1:02 PM, MRAB wrote: On 10/01/2011 20:29, Dan Stromberg wrote: I invite folks to check out Tiobe's Language Popularity Rankings: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html That's somehow derived from web searches, not from any real data source. Look how far down JavaScript is. Any measure is arbitrary and subject to biases, what methodology would you prefer ? Katie Measuring the Buzz about a language is actually a pretty good way to gauge its popularity. . -- http://mail.python.org/mailman/listinfo/python-list
Re: Can I have both Python 2.7 and Python 3.1 at the same time on the Mac?
On 01/06/2011 02:44 PM, Bill Felton wrote: Hi All, I'm new to python, trying to learn it from a variety of resources, including references posted recently to this list. I'm going through /www.openbookproject.net/thinkCSpy/ and find it makes use of gasp, which apparently is not compatible with 3.1. I've also seen various resources indicate that one can install both Python 2.7 and Python 3.1 -- but when I did this, I get no end of problems in the 2.7 install. IDLE, in particular, fails rather spectacularly, even if I launch it directly from the Python 2.7 directory in which it resides. So, either I've been misled and should only try to have one or the other. OR I'm missing some (probably simple) step that's mucking me up. Help? Thanks, Bill You probably want to use 'virtualenv' for keeping things separated. -- http://mail.python.org/mailman/listinfo/python-list
Re: CPython on the Web
On 01/04/2011 12:38 PM, gry wrote: On Jan 4, 1:11 am, John Nagle na...@animats.com wrote: On 1/1/2011 11:26 PM, azakai wrote: Hello, I hope this will be interesting to people here: CPython running on the web, http://syntensity.com/static/python.html That isn't a new implementation of Python, but rather CPython 2.7.1, compiled from C to JavaScript using Emscripten and LLVM. For more details on the conversion process, seehttp://emscripten.org On loading, I get script stack space quota is exhausted under firefox 3.5.12, under linux. Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.5.12-1.fc12 Firefox/3.5.12 It's a Firefox bug apparently fixed in Firefox 4.x. Some versions of Firefox 3.6.x do work but most do not. Regards, Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: CPython on the Web
On 01/03/2011 03:10 PM, azakai wrote: On Jan 2, 5:55 pm, Gerry Reno gr...@verizon.net wrote: I tried printing sys.path and here is the output: ['', '/usr/local/lib/python27.zip', '/usr/local/lib/python2.7/', '/usr/local/lib/python2.7/plat-linux2', '/usr/local/lib/python2.7/lib-tk', '/usr/local/lib/python2.7/lib-old', '/usr/local/lib/lib-dynload'] Now, those paths must be on your machine because they are not on my client machine. But the interpreter is now running on MY machine. Well in a sandbox really. So how is that going to work? Yeah, those are the paths on the machine where the binary was compiled (so, they are the standard paths on ubuntu). Anyhow the filesystem can't (and shouldn't) be accessed from inside a browser page. Well, the local filesystem could be accessible with the user's permission and this should be an option. Regards, Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: CPython on the Web
On 01/03/2011 03:13 PM, Diez B. Roggisch wrote: A fun hack. Have you bothered to compare it to the PyPy javascript backend - perfomance-wise, that is? Diez I don't think that exists anymore. Didn't that get removed from PyPy about 2 years ago? Regards, Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: CPython on the Web
On 01/03/2011 05:55 PM, Diez B. Roggisch wrote: Gerry Reno gr...@verizon.net writes: On 01/03/2011 03:13 PM, Diez B. Roggisch wrote: A fun hack. Have you bothered to compare it to the PyPy javascript backend - perfomance-wise, that is? Diez I don't think that exists anymore. Didn't that get removed from PyPy about 2 years ago? Ah, didn't know that. I was under the impression pyjamas was done with it. Apparently, that's wrong: http://pyjs.org/ But then I re-phrase my question: how does this relate to pyjamas/pyjs? Diez From what I've seen so far: Pyjamas is taking your python code and converting it into javascript so that your python code (converted to javascript) can run in a browser. CPotW is taking the whole python interpreter and converting the interpreter into javascript so that the python interpreter runs in the browser. Your python code remains as python code. Regards, Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: CPython on the Web
On 01/02/2011 02:26 AM, azakai wrote:
Hello, I hope this will be interesting to people here: CPython running
on the web,
http://syntensity.com/static/python.html
That isn't a new implementation of Python, but rather CPython 2.7.1,
compiled from C to JavaScript using Emscripten and LLVM. For more
details on the conversion process, see http://emscripten.org
This is a work in progress, main issues right now are that the code
isn't optimized (so don't expect good performance), and importing non-
static modules doesn't work. Otherwise, though, it seems to run
properly, in particular it runs all the examples in
http://wiki.python.org/moin/SimplePrograms that don't rely on
importing modules or receiving input from the user (with perhaps some
minor formatting errors). The demo runs fine on recent versions of
Firefox, Chrome and Safari, but has problems on IE9 and Opera
(hopefully those will be resolved soon).
The idea is that by compiling CPython itself, all the features of the
language are immediately present, and at the latest version, unlike
writing a new implementation which takes time and tends to lag behind.
As to why run it on the web, there could be various uses, for example
it could allow a simple learning environment for Python, which since
it's on the web can be entered immediately without any download (and
would run even in places where Python normally can't, like say an
iPad).
Feedback would be very welcome!
- azakai
Ok, visiting this page:
http://syntensity.com/static/python.html
I do not see anything happen when I click 'execute' button. I'm running
Firefox 3.6.3.
Here is what I see both before and after clicking 'execute':
=
This is CPython, the standard Python http://www.python.org
implementation, compiled from C to JavaScript using Emscripten
http://emscripten.org, running in your browser (without any plugins).
* Most core language stuff should work, except for importing
non-static modules (in other words, |import sys| will work, but
other modules won't).
* Please report bugs if you find them!
* Tested on Firefox 4 and Chrome 10.
* The editor is Skywriter https://mozillalabs.com/skywriter/.
*Enter some Python*:
import sys print 'Hello world! This is Python {} on
{}'.format(sys.version, sys.platform) print 'Here are some numbers:',
[2*x for x in range(5)][:4]
=
So what is happening is that the whole Python interpreter has been
converted to Javascript and is running the browser, is that correct?
Ok, but the usual browser 'sandbox' constraints would still apply would
they not?
And what is the build toolchain that you need if you want to convert
your modules to be importable with this CPython on the Web?
Regards,
Gerry
--
http://mail.python.org/mailman/listinfo/python-list
Re: CPython on the Web
On 01/02/2011 05:53 PM, azakai wrote: On Jan 2, 1:01 pm, Gerry Reno gr...@verizon.net wrote: Ok, visiting this page: http://syntensity.com/static/python.html I do not see anything happen when I click 'execute' button. I'm running Firefox 3.6.3. I've only tested with Firefox 4. I'm surprised though that it wouldn't work on 3.6.3. Can you see what errors appear in the error console (control-shift-J)? Errors when using Firefox 3.6.3: script stack space quota is exhausted Module is not defined ... line 56 Regards, Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: CPython on the Web
I tried printing sys.path and here is the output: ['', '/usr/local/lib/python27.zip', '/usr/local/lib/python2.7/', '/usr/local/lib/python2.7/plat-linux2', '/usr/local/lib/python2.7/lib-tk', '/usr/local/lib/python2.7/lib-old', '/usr/local/lib/lib-dynload'] Now, those paths must be on your machine because they are not on my client machine. But the interpreter is now running on MY machine. Well in a sandbox really. So how is that going to work? Regards, Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
For those that are lurking, this might provide a little background: http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong Essentially, there is nothing wrong with Tcl and Tkinter. They are part of a long evolutionary chain of how we got to where we are today. They deserve to be respected for the contributions that they have made. The question now is whether Python needs to evolve its own GUI toolset. Regards, Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 12/30/2010 10:28 PM, rantingrick wrote: Hmm, wxPython is starting to look like the answer to all our problems. WxPython already has an IDE so there is no need to rewrite IDLE completely. What do we have to loose by integrating wx into the stdlib, really? In the spirit of batteries included, Python needs to have something in the stdlib as far as gui. But it cannot be overwhelming. The problem with wx is that it is BIG. And so if we want something like wx to be in the stdlib then it would have to be refactored so that there was a small basic wx that was part of stdlib and then import wx-the-whole-enchilada if you need heavy gui artillery. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
wxPython looks good but I don't see anyone developing support for things like smartphones. Also, what do you think about frameworks such as pyjamas? It lets you write in python and compiles everything down to Javascript so it can be used across the Web as well as on the desktop. -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
On 12/17/2010 02:36 PM, Daniel Fetchinson wrote: How-To: Add VirtualEnv and Pylons (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42981 Maybe, if there's no Zope. Or we'll run away screaming... That is rather pathetically true... Ah well, each to their own... Chris What I really don't like right off is that Pyramid is contorting the MVC model just as Django did with their MTV model. They are both making the controller be the view and this confuses the hell out of people who come from true MVC based projects. The VIEW is the bits that stream out of the webserver back to the users browser. The CONTROLLER is the code that gathers all the pieces from the model and constructs the python code that is then fed to the engine that then creates the view. And just because the controller navigates the logic to dynamically contruct/render a view, that does not make 'it' the view. In turbogears that is exactly what happens. Cheers, Daniel How-To: Add VirtualEnv and TurboGears2 (WSGI frmwk) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=43207 -Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
On 12/16/2010 04:36 AM, Octavian Rasnita wrote: From: Ian Kelly ian.g.ke...@gmail.com On Mon, Dec 13, 2010 at 5:58 PM, Gerry Reno gr...@verizon.net wrote: The VIEW is the bits that stream out of the webserver back to the users browser. Why only to the user's browser? A web app could also offer the results in formats that can be accessed with something else than a browser. The view just offer the results, no matter what way. The CONTROLLER is the code that gathers all the pieces from the model and constructs the python code that is then fed to the engine that then creates the view. And just because the controller navigates the logic to dynamically contruct/render a view, that does not make 'it' the view. In traditional MVC, the controller is the part that receives the user input, decides how to react to it, and instructs the model to update itself accordingly. It is not supposed to be some sort of intermediary between the model and the view, as many people seem to make it; the view is supposed to gather the data it needs to render itself directly from the model. How can the view know what data it should render if the controller doesn't inform it about it? It is less important if the view uses a smart templating system that doesn't need to ask the controller for data but can access the model directly, but the view or that templating system need to be informed by the controller what data need to ask from the model, so we can say that the intermediary is still the controller. And accessing the model directly from the view/templating system is not a good idea, because MVC is also prefered because it decouples the programming code and the web design, and in some cases it can be a security issue if the web designer that might not know programming would be able to change by mistake or with intention the code from the view/templating system that access the model. In that light, I think that this quote from the Django FAQ is defensible: In our interpretation of MVC, the “view” describes the data that gets presented to the user. It’s not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It’s a subtle distinction. But if the view doesn't decide how the data looks, who decide it? :-) Traditionally, the view would describe both of these things, but since how you see it is ultimately decided by the user's browser, they are fundamentally separated in the context of the web. The Django template-view split is in recognition of this fact. The same data can have any format that's not decided by the user browser. For example it can be displayed in .csv format, or .xls, or .xlsx, or .pdf, or .html, or it can be submitted by email, or sent to Twitter or another web site... As for where the controller went, there are basically two decisions that need to be made when input is received: how to update the model as a result, and what data should be displayed next. The former decision belongs to the controller, the latter to the view. The update of the model depends on the model and the display of results depends on the view. But the decision is controlled by the... controller. That's why it has that name, because it controls these things. Of course, the frontiers between the M and V and C might be subtle in some cases, but it is a good idea to push as much logic to the base. It is not a good idea to make the controller do the job of the model and imply in the business logic or make the view do the job of the controller and do something else than just present the data it receives. But in a web app, these two things tend to be highly correlated, and there seems to be little reason to separate them out into distinct components. This part then is both controller and view, and which word we use for it is not terribly important. Yes, but in that case such a program wouldn't use the MVC model. And as I exemplified above, there are reasons why the view should only present the data it receives and don't access the model directly. Some web developers aren't even alowed to offer the ORM objects to the templates, although the coding would be much easier that way, but need to generate other objects in the controller that don't allow the web designers to change some things in the templates and access more data from the database than it is needed. For these reasons, I find that in practice traditional MVC does not lend itself well to the HTTP request/response cycle, where the view as you define it has no access to the model and lacks any continuity whatsoever from one request to the next; but the Django MTV approach works just fine once you're willing to accept that it's not the same thing. Cheers, Ian There is no traditional MVC. There is just MVC
Pyramid and MVC (split from: Re: Added Python, WSGI to XAMPP)
On 12/15/2010 05:03 PM, Chris Withers wrote: On 14/12/2010 00:58, Gerry Reno wrote: What I really don't like right off is that Pyramid is contorting the MVC model That specific pattern, I'm afraid, is a little antiquated nowadays, particularly when it comes to web apps... The VIEW is the bits that stream out of the webserver back to the users browser. Yep, and in Pyramid I guess this would be the template renderer, which is usually a decorator on the view function or class. The view's job is to process a request and turn it into a response dictionary. That sounds a lot like your controller to me ;-) The CONTROLLER is the code that gathers all the pieces from the model and constructs the python code Slightly scared as to what constructed the python code might mean :-S that is then fed to the engine that then creates the view. And just because the controller navigates the logic to dynamically contruct/render a view, that does not make 'it' the view. Well, for me, the MVC isn't really what happens anymore, here's my take: - the model nowadays has all the business logic in it, rather than just the data. The model is now a collection of objects that can be interacted on through many/any UIs needed, some of which may be web apps. - web apps are *always* a collection of request/response transactions. As such, the control layer does just become a view that does that. - singleton objects and other stuff that used to live in a control are now factored out into utilities and services (of which zope.component provides a pretty good abstraction, and doesn't really have anything to do with Zope, other than the fact that Zope makes use of it). Welcome to the 2nd decade in the new millenium ;-) Chris It doesn't matter whether you are building a desktop app or a webapp. MVC still applies. And that includes when things like Ajax are added to the mix because Ajax just performs a mini-MVC transaction. The problems arise when people start rigidly thinking that M only meant database. M means model, model means any source that emits data. A database, another webapp, whatever, that is M. The view as I said before is just the bits streaming out of the webserver back to the client device. There should be NOTHING on the server call view-anything. The view only exists on the clients. The view is the result of what the controllers(servers) in conjunction with renderers emit as their work product. -Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
On 12/15/2010 07:36 PM, Ian Kelly wrote: On Mon, Dec 13, 2010 at 5:58 PM, Gerry Reno gr...@verizon.net wrote: The VIEW is the bits that stream out of the webserver back to the users browser. The CONTROLLER is the code that gathers all the pieces from the model and constructs the python code that is then fed to the engine that then creates the view. And just because the controller navigates the logic to dynamically contruct/render a view, that does not make 'it' the view. In traditional MVC, the controller is the part that receives the user input, decides how to react to it, and instructs the model to update itself accordingly. It is not supposed to be some sort of intermediary between the model and the view, as many people seem to make it; the view is supposed to gather the data it needs to render itself directly from the model. In that light, I think that this quote from the Django FAQ is defensible: In our interpretation of MVC, the “view” describes the data that gets presented to the user. It’s not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It’s a subtle distinction. Traditionally, the view would describe both of these things, but since how you see it is ultimately decided by the user's browser, they are fundamentally separated in the context of the web. The Django template-view split is in recognition of this fact. As for where the controller went, there are basically two decisions that need to be made when input is received: how to update the model as a result, and what data should be displayed next. The former decision belongs to the controller, the latter to the view. But in a web app, these two things tend to be highly correlated, and there seems to be little reason to separate them out into distinct components. This part then is both controller and view, and which word we use for it is not terribly important. I suppose that view tends to prevail since there are other components, such as URL dispatch, that are controllerish in nature. For these reasons, I find that in practice traditional MVC does not lend itself well to the HTTP request/response cycle, where the view as you define it has no access to the model and lacks any continuity whatsoever from one request to the next; but the Django MTV approach works just fine once you're willing to accept that it's not the same thing. Cheers, Ian Django can use whatever approach they like. But don't call it an MVC framework and that is what they did initially at least. MTV is a contorted MVC. And it does not correlate very well with other MVC documentation which is very confusing to people. No doubt, the web is constraining. Request/response makes it difficult to have the Model independently notify the View that it needs to update itself because some state in the model has changed. That is why many of the diagrams about MVC on the web show the Controller interceding between the View and the Model. That doesn't mean MVC does not work on the web. It just means that there is a constraint imposed by the nature of the request/response stateless architecture. Maybe it's splitting hairs, but having things named 'View' on the server implies especially to newbies that the View exists on the server. The View exists on the client. And then later they discover that it's not really View but Controller and that Templates are View. I guess if we were screen-scraping we could actually have a server-side View. But normal MVC has the View on the client, and the Model and Controller in server capacities. And I don't see the value in naming things View on the server when for the most part the View (or view parts in the case of Ajax) are merely the output of render processes. -Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
On 12/13/2010 06:34 PM, Chris Withers wrote: On 09/12/2010 21:29, Gerry Reno wrote: How-To: Add VirtualEnv and Pylons (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42981 You mean Pyramid, right? ;-) Chris Maybe, if there's no Zope. Or we'll run away screaming... Anyway, Pyramid is still only alpha. But if it is a true WSGI framework then as my technique shows it can certainly be made to work with XAMPP. -Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
On 12/13/2010 07:12 PM, Chris Withers wrote: On 14/12/2010 00:14, Gerry Reno wrote: On 12/13/2010 06:34 PM, Chris Withers wrote: On 09/12/2010 21:29, Gerry Reno wrote: How-To: Add VirtualEnv and Pylons (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42981 Maybe, if there's no Zope. Or we'll run away screaming... That is rather pathetically true... Ah well, each to their own... Chris What I really don't like right off is that Pyramid is contorting the MVC model just as Django did with their MTV model. They are both making the controller be the view and this confuses the hell out of people who come from true MVC based projects. The VIEW is the bits that stream out of the webserver back to the users browser. The CONTROLLER is the code that gathers all the pieces from the model and constructs the python code that is then fed to the engine that then creates the view. And just because the controller navigates the logic to dynamically contruct/render a view, that does not make 'it' the view. -Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
On 12/13/2010 11:13 PM, rusi wrote: On Dec 10, 2:29 am, Gerry Reno gr...@verizon.net wrote: If you have any need of a portable LAMP stack, I just finished writing some How-To's for getting Python, VirtualEnv and WSGI frameworks running with XAMPP: How-To: Add VirtualEnv and Pylons (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42981 How-To: Add VirtualEnv and Django (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42992 How-To: Add Python and mod_wsgi to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42975 -Gerry What does XAMPP give (on linux) that the distro apache,mysql dont? It is a portable LAMP stack that is basically independent of your distro. If you want to upgrade PHP or Apache or whatever without disturbing your distro PHP or Apache you can do this. If you want to try out cutting edge releases of things you can do this on XAMPP without bothering your distro. It's an environment and what you can do with it is only limited by your imagination. -Gerry -- http://mail.python.org/mailman/listinfo/python-list
Added Python, WSGI to XAMPP
If you have any need of a portable LAMP stack, I just finished writing some How-To's for getting Python, VirtualEnv and WSGI frameworks running with XAMPP: How-To: Add VirtualEnv and Pylons (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42981 How-To: Add VirtualEnv and Django (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42992 How-To: Add Python and mod_wsgi to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42975 -Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: A web site using Python
If you have any need of a portable LAMP stack, I just finished writing some How-To's for getting Python, VirtualEnv and WSGI frameworks running with XAMPP: How-To: Add VirtualEnv and Pylons (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42981 How-To: Add VirtualEnv and Django (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42992 How-To: Add Python and mod_wsgi to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42975 -Gerry On 12/06/2010 07:42 PM, Alice Bevan–McGregor wrote: 1. Pick a web framework, I'd suggest looking at: Django (http://www.djangoproject.com/) Pyramid (http://docs.pylonshq.com/pyramid/dev/) I'm biased, but I can highly recommend WebCore (http://www.web-core.org/) as it more easily supports small to mid-sized applications and actively encourages the use of standard Python idioms. A reasonable example (though it was hurried) would be the codebase behind tsatimeline.org: https://github.com/GothAlice/TSA-Timeline The important files are application.py (controllers), model.py (data model), and the templates (views) folder. (The public folder is where CSS/JS/images go.) Similar to Stef's comment on web2py, development with WebCore (or web2py, or WebPy, or… basically any micro-framework) is extremely rapid. — Alice. -- http://mail.python.org/mailman/listinfo/python-list
Re: Strange factory pattern
This looks like a public class exposing an implementation private class.Jun 22, 2010 10:39:05 PM, zac...@gmail.com wrote:In the threading module there are several code bits following this convention:###def Class(*args, **kwargs): return _Class(*args, **kwargs)class _Class(...###This is true for Event, RLock, and others. Why do this? It seems to violate the rule of least astonishment (isinstance(Event(), Event) raises an exception). I assume there must be some trade-off that the designer intended to achieve. So, what is that trade-off and when should I follow this in my code? --Zachary Burns(407)590-4814Aim - Zac256FLProduction EngineerZindagi Games -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: getting up arrow in terminal to scroll thought history of python commands
These command just allow you to use 'vi editing mode' within python. If you've ever navigated a file with vi to go up and down the document you'll immediately know how it works.-GerryJun 13, 2010 07:39:35 PM, vinc...@vincentdavis.net wrote:On Sun, Jun 13, 2010 at 5:28 PM, Gerry Reno <gr...@verizon.net> wrote: sounds like your keymapping got messed with. you could just: set -o vi python ESC, Ctrl-j and now ESC-k and ESC-j will take you back and forth in history (std vi editing)This is done within python? Let make sure I am clear. This is only anissue within the interactive python for the python dist I have builtfrom source not other pythons or terminal in general. I look into thecommands you suggested more but ESC-k and ESC-j don't sound veryappealing to me.ThanksVincent -Gerry Jun 13, 2010 07:22:40 PM, vinc...@vincentdavis.net wrote: I just installed 2.6 and 3.1 from current maintenance source on Mac OSx. When I am running as an interactive terminal session the up arrow does not scroll thought the history of the py commands I have entered I just get ^[[A. When I install from a compiled source it works fine. Whats the fix for this? Thanks Vincent -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: getting up arrow in terminal to scroll thought history of python commands
sounds like your keymapping got messed with.you could just:set -o vipythonESC, Ctrl-jand now ESC-k and ESC-j will take you back and forth in history (std vi editing)-GerryJun 13, 2010 07:22:40 PM, vinc...@vincentdavis.net wrote:I just installed 2.6 and 3.1 from current maintenance source on MacOSx. When I am running as an interactive terminal session the up arrowdoes not scroll thought the history of the py commands I have enteredI just get ^[[A. When I install from a compiled source it works fine.Whats the fix for this?ThanksVincent-- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Distutils, bdist_XXX, rpmbuild issues
I've been trying to use the built distribution distutils commands such as bdist_rpm to create distro-specific packages for python applications but I'm running into some thorny issues specifically with pre-release versioning of source distributions and built distributions and how to get a final release to update these pre-release distributions. For example: We have an application, foo-5.0.0, and we want to put out some pre-release candidates for testing, so we set the version to 5.0.0_rc1 in setup.py. We create the source distribution with: $ python setup.py sdist which creates a source archive, foo-5.0.0_rc1.tar.gz. We extract this archive and 'cd' into the foo-5.0.0_rc1 directory and create a built distribution with: $ python setup.py bdist_rpm which creates source and binary RPMS in the form: foo-5.0.0_rc1-1.noarch.rpm. So we think everything is fine. Everyone installs and tests using the pre-release candidate and subsequent candidates but when you eventually get to the final release, foo-5.0.0, and build your final release RPMS, foo-5.0.0-1.noarch.rpm, you find that it will not update your last pre-release candidate RPM, foo-5.0.0_rcX-1.noarch.rpm because it is not rpm newer. So I've been working on this for a while but have not found a good way to do this by setting options in a setup.cfg file. It seems like for RPM purposes we have to keep the version to 5.0.0 and set release to 0_rcX for the pre-release candidates and this will work for RPM purposes but then sdist does not generate the correct tarball names for each pre-release candidate. It always generates foo-5.0.0.tar.gz. Has anyone managed to solve this issue or is distutils in need of some enhancement. We need the sdist command to generate distinct pre-release candidate tarball names. And we need the bdist_XXX commands to generate distro-specific package naming such that the pre-release candidate packages can be updated by the final release package. Regards, Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Distutils, bdist_XXX, rpmbuild issues
Ben Finney wrote: Gerry Reno gr...@verizon.net writes: We have an application, foo-5.0.0, and we want to put out some pre-release candidates for testing, so we set the version to 5.0.0_rc1 in setup.py. That's where your problems start (as you no doubt surmised). If you want version numbers to compare in a certain order, you should name them so that the version string will trivially compare in that order. In many instances we don't get to make that decision when we join projects already in motion. Otherwise, I would not have bothered to post the problem to the list. The fact is that many applications use version string constructs such as I illustrated, 5.0.0_rc1 when they create their release candidates. And yes, the final release, 5.0.0, is not lexically superior. But, as much as I might like that everyone would not do this, I cannot change the whole world which has developed a habit of such things. So I am looking for a solution that works with the world as it is. Regards, Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Why not Ruby?
There's been almost 50 responses to this rubbish post. Could you please all stop! -- http://mail.python.org/mailman/listinfo/python-list
