Re: Lua is faster than Fortran???
On Saturday 03 July 2010 20:30:30 sturlamolden wrote: > I was just looking at Debian's benchmarks. It seems LuaJIT is now (on > median) beating Intel Fortran! That's amazing! Congrats to the Lua team! > If this keeps up we'll need a Python to Lua bytecode compiler very > soon. And LuaJIT 2 is rumoured to be much faster than the current... > > Looking at median runtimes, here is what I got: [snip] > The only comfort for CPython is that Ruby and Perl did even worse. Out of curiosity, does anyone know how the Unladen Swallow version of Python does by comparison? Rami Chowdhury "Given enough eyeballs, all bugs are shallow." -- Linus' Law +1-408-597-7068 / +44-7875-841-046 / +88-01819-245544 -- http://mail.python.org/mailman/listinfo/python-list
Re: python app development
On Jul 3, 1:48 pm, mo reina wrote: > an anyone recommend a resource (book,tutorial,etc.) that focuses on > application development in python? something similar to Practical > Django Projects, but for stand alone applications instead of web apps > (for now). > > i'm in a bit of a funny place, i have a decent/good grasp of python > syntax and my logic isn't bad, but i have no clue on how to assemble > an application, i seem to be stuck on writing scripts. Do you have a particular project in mind? Getting unstuck, I think, is about having a goal and then you'll begin to seek out what you need to make that happen (see below). > also, it seems that a lot of > app programming is 90% gui bindings, with very little actual code, or > am i totally way off mark? I'm sure it varies greatly depending on the application. Depending on the complexity of the GUI and how much care goes into it, that can be a lot of code (it seems to me). > i recently picked up the django practical projects book, and in a few > days i re-wrote a website i did with django. i feel it was the book's > project-centric approach that made this possible. I don't know of a book oriented that way (sounds like a good idea), but you might take a look at this video "learning path" from the ShowMeDo website: http://showmedo.com/learningpaths/14/view It is focused on GUI (desktop and web) application development. There is a super basic starter video in there about making a Python image viewer application. Then the video series about building emol seems very thorough (there are 35 videos!), though I haven't watched it yet. What I would suggest is that you first decide what you want to accomplish. Then research and pick a GUI framework first (Tkinter, wxPython, PyQT, PyGTK), then whatever other tools you'll need (database? drawing? math/science?), which will either be in the standard library or in a 3rd party library. Any of the research on what tools to use can be Googled with bountiful results, as those questions are asked a lot. Then just jump in. This will prompt you to learn in a directed way. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
sturlamolden, 04.07.2010 05:30: I was just looking at Debian's benchmarks. It seems LuaJIT is now (on median) beating Intel Fortran! C (gcc) is running the benchmarks faster by less than a factor of two. Consider that Lua is a dynamically typed scripting language very similar to Python. Sort of. One of the major differences is the "number" type, which is (by default) a floating point type - there is no other type for numbers. The main reason why Python is slow for arithmetic computations is its integer type (int in Py3, int/long in Py2), which has arbitrary size and is an immutable object. So it needs to be reallocated on each computation. If it was easily mappable to a CPU integer, Python implementations could just do that and be fast. But its arbitrary size makes this impossible (or requires a noticeable overhead, at least). The floating point type is less of a problem, e.g. Cython safely maps that to a C double already. But the integer type is. So it's not actually surprising that Lua beats CPython (and the other dynamic languages) in computational benchmarks. It's also not surprising to me that a JIT compiler beats a static compiler. A static compiler can only see static behaviour of the code, potentially with an artificially constructed idea about the target data. A JIT compiler can see the real data that flows through the code and can optimise for that. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
* 2010-07-04 10:03 (+0200), Stefan Behnel wrote: > The main reason why Python is slow for arithmetic computations is its > integer type (int in Py3, int/long in Py2), which has arbitrary size > and is an immutable object. So it needs to be reallocated on each > computation. If it was easily mappable to a CPU integer, Python > implementations could just do that and be fast. But its arbitrary size > makes this impossible (or requires a noticeable overhead, at least). > The floating point type is less of a problem, e.g. Cython safely maps > that to a C double already. But the integer type is. You may be right. I'll just add that Common Lisp's integers are of arbitrary size too but programmer can declare them as fixnums. Such declarations kind of promise that the numbers really are between most-negative-fixnum and most-positive-fixnum. Compiler can then optimize the code to efficient machine instructions. I guess Python might have use for some sort of (defun foo (variable) (declare (type fixnum variable)) ...) -- http://mail.python.org/mailman/listinfo/python-list
SyntaxError not honoured in list comprehension?
Python all versions. It's not a bug, but I'm suprised the following does not raise a SyntaxError (missing space between '9' and 'for'). >>> [9for c in 'abc'] [9, 9, 9] >>> Side effect: If this behaviour is considered as correct, it makes a correct Python code styling (IDLE, editors, ...) practically impossible to realise. -- http://mail.python.org/mailman/listinfo/python-list
[ANN] eric 5.0.0 released
Hi, I just uploaded eric 5.0.0. This is the first official release. It is available via the eric web site. http://eric-ide.python-projects.org/index.html What is it? --- eric5 is the Python3 variant of the well know eric4 Python IDE and is the first development environment, that runs natively with Python3. It comes with all batteries included. The features are too much to be listed in this announcement. Please see the eric web site for details. Regards, Detlev -- Detlev Offenbach det...@die-offenbachs.de -- http://mail.python.org/mailman/listinfo/python-list
Re: SyntaxError not honoured in list comprehension?
On Jul 4, 9:31 am, jmfauth wrote: > Python all versions. > > It's not a bug, but I'm suprised the following does > not raise a SyntaxError (missing space between > '9' and 'for'). > > > > >>> [9for c in 'abc'] > [9, 9, 9] > > Side effect: If this behaviour is considered as correct, > it makes a correct Python code styling (IDLE, editors, ...) > practically impossible to realise. Why? If Python itself has no problem parsing this code, why should it be so difficult for editors? Python's grammar is fairly simple: it's LL(1) (unlike C's, for example), so can be parsed with only 1 token of lookahead. -- Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: SyntaxError not honoured in list comprehension?
On Jul 4, 9:55 am, Mark Dickinson wrote: > Why? If Python itself has no problem parsing this code, why should it > be so difficult for editors? Python's grammar is fairly simple: it's > LL(1) (unlike C's, for example), so can be parsed with only 1 token of > lookahead. Bah. Ignore the bit about C. I was thinking that the dangling else issue made this a problem, but now I'm not sure that's true. -- Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: IMAP Problems
Brilliant! Thanks guys I will have to have a play around later
On 4 July 2010 04:12, Grant Edwards wrote:
>
> > I'm trying to write a simple script which displays the basic details
> > of a person's mailbox. My problem is that it causes all the messages
> > to be marked as read on the server,
> >
> > code, mailboxen= server.list()
> > print mailboxen
> > # if it's called INBOX, then…
> > server.select("INBOX")
>
> You probably want to try examine() instead of select(). That opens
> the mailbox in a read-only mode which and should avoid changing any
> flag values.
>
> >From RFC3501:
>
> The EXAMINE command is identical to SELECT and returns the same
> output; however, the selected mailbox is identified as
> read-only. No changes to the permanent state of the mailbox,
> including per-user state, are permitted; in particular, EXAMINE
> MUST NOT cause messages to lose the \Recent flag.
>
> --
> Grant
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: delegation pattern via descriptor
i'm confused which part that doesn't make sense?
this is my 2nd attempt to py, the 1st was on april this year, it was
just a month, i'm afraid i haven't got the fundamentals right yet. so
i'm gonna lay out how i got to this conclusion, CMIIW
**explanation of feeling (0) on my 1st post**
to me, descriptor is a particular kind of delegation, it takes the job
of coding the delegation by having a contract with programmers that
the tree meta operations (get, set, del) on attr are delegated to the
obj that is bound to the attr
are we agree that descriptor is a kind of delegation?
the mechanism that makes descriptor works is in __getattribute__,
__setattr__, __delattr__ of 'object' & 'type'
now, if i want a single descriptor obj to be delegated to multiple
tasks, i can't do it since __get__ doesn't get info that can be used
to determine which task to do
i must have diff descriptor obj for each task
class Helper:
def __init__(self, name):
self.name = name
def __get__(self, ins, cls):
if self.name == 'task0': ...
elif self.name == 'task1': ...
else: ...
class a:
task0 = Helper('task0')
task1 = Helper('task1')
if __get__ receives the name, then i could do
class Helper:
def __get__(self, ins, cls, name):
...
class a:
task0 = task1 = Helper()
but after explaining this, i have more doubt on my own stmt in the 1st
post "not passing name strengthens the coupling between delegator &
delegate". now i think it's more likely the opposite, it weakens the
coupling at the expense of more objs. moreover, is it wrong to justify
that descriptor is a kind of delegation?
my ego speaks:
- i think, if the name is passed on, programmers can choose to use it
or not (i don't know if it brokes any py principle, i only know KISS)
- i realize that using name as the info that descriptors use to
determine which task to do, is going to strongly couple the descriptor
& the classes that use it, meaning that the descriptor & the user
classes must agree on attr names to be used. a simple solution to it
is by mapping attr names & names used in the descriptor
class Helper:
def __init__(self, name_map=None):
self.name_map = name_map
def __get__(self, ins, cls, name):
if self.name_map is None:
if name == 'task0': ...
...
else:
if self.name_map[name] == 'task0': ...
...
class a:
do_this = do_that = Helper({'do_this':'task0', 'do_that':'task1'})
finally, like all shared things, shared descriptor objs require more
effort for synchronization
--
http://mail.python.org/mailman/listinfo/python-list
Re: SyntaxError not honoured in list comprehension?
On Jul 4, 1:31 am, jmfauth wrote: > Python all versions. > > It's not a bug, but I'm suprised the following does > not raise a SyntaxError (missing space between > '9' and 'for'). > > >>> [9for c in 'abc'] > [9, 9, 9] It does seem strange that Python's lexer wouldn't consider 9for as a single token. Even tough it's not a valid token in Python, your eye kind of sees it as one, so wouldn't it be better to raise a syntax error? Some other places were keyword can follow a number: 9if 0 else 1 (but not "9if 0else 1") 9and 0 9or 0 9in (1,2,3) 9is None > Side effect: If this behaviour is considered as correct, > it makes a correct Python code styling (IDLE, editors, ...) > practically impossible to realise. I'm not sure why an odd corner of the grammar would mess the whole thing up. Most code stylers only approximate the actual grammar anyway. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: delegation pattern via descriptor
thanks Greg, you get most of what i meant like i said before, i suspect descriptor encourages dedicated / not shared descriptor obj. this encouragement is expressed in the design, and the reasons behind the design were the ones that i was asking about, not how to get around it now, i'm asking another favor, what about the 2nd point in my 1st post? -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Sun, Jul 4, 2010 at 5:03 PM, Stefan Behnel wrote: > sturlamolden, 04.07.2010 05:30: >> >> I was just looking at Debian's benchmarks. It seems LuaJIT is now (on >> median) beating Intel Fortran! >> >> C (gcc) is running the benchmarks faster by less than a factor of two. >> Consider that Lua is a dynamically typed scripting language very >> similar to Python. > > Sort of. One of the major differences is the "number" type, which is (by > default) a floating point type - there is no other type for numbers. The > main reason why Python is slow for arithmetic computations is its integer > type (int in Py3, int/long in Py2), which has arbitrary size and is an > immutable object. So it needs to be reallocated on each computation. If it > was easily mappable to a CPU integer, Python implementations could just do > that and be fast. But its arbitrary size makes this impossible (or requires > a noticeable overhead, at least). The floating point type is less of a > problem, e.g. Cython safely maps that to a C double already. But the integer > type is. Actually, I think the main reason why Lua is much faster than other dynamic languages is its size. The language is small. You don't list, dict, tuples, etc... Making 50 % of python fast is "easy" (in the sense that it has been done). I would not be surprised if it is exponentially harder the closer you get to 100 %. Having a small language means that the interpreter is small - small enough to be kept in L1, which seems to matter a lot (http://www.reddit.com/r/programming/comments/badl2/luajit_2_beta_3_is_out_support_both_x32_x64/c0lrus0). If you are interested in facts and technical details (rather than mere speculations), this thread is interesting http://lambda-the-ultimate.org/node/3851. It has participation of LuaJIT author, Pypy author and Brendan Eich :) > It's also not surprising to me that a JIT compiler beats a static compiler. > A static compiler can only see static behaviour of the code, potentially > with an artificially constructed idea about the target data. A JIT compiler > can see the real data that flows through the code and can optimise for that. Although I agree that in theory, it is rather obvious that a JIT compiler can do many things that static analysis cannot, this is the first time it has happened in practice AFAIK. Even hotspot was not faster than fortran and C, and it has received tons of work by people who knew what they were doing. The only example of a dynamic language being as fast/faster than C that I am aware of so far is Staline, the aggressive compiler for scheme (used in signal processing in particular). David -- http://mail.python.org/mailman/listinfo/python-list
High Revenue Keywords
Check Out High Revenue Keywords In All Niche's At, http://highrevenuekeywords.blogspot.com/ . Stuff Your Content With These High Revenue Keywords And Maximize Your PPC Pay Per Click Value Doubling Your Revenue For All Clicks.. -- http://mail.python.org/mailman/listinfo/python-list
Re: SyntaxError not honoured in list comprehension?
On 4 juil, 12:35, Carl Banks wrote: > On Jul 4, 1:31 am, jmfauth wrote: > Thanks for having explained in good English my feelings. > > Some other places were keyword can follow a number: > Note, that this does not envolve numbers only. >>> ['z' for c in 'abc'] ['z', 'z', 'z'] >>> 'z'if True else 'a' z >>> > > Side effect: If this behaviour is considered as correct, > > it makes a correct Python code styling (IDLE, editors, ...) > > practically impossible to realise. > > I'm not sure why an odd corner of the grammar would mess the whole > thing up. Most code stylers only approximate the actual grammar > anyway. > I guess, most editors (so do I) are mainly using a "re" engine for their styling. --- Not a keyword, but space related, what should I thing about this? >>> print9 Traceback (most recent call last): File "", line 1, in NameError: name 'print9' is not defined >>> print+9 9 >>> print'abc' abc >>> print9.0 File "", line 1 print9.0 ^ SyntaxError: invalid syntax >>> Regards, jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 04 Jul 2010 04:15:57 GMT Steven D'Aprano wrote: > "Need" is a bit strong. There are plenty of applications where if your > code takes 0.1 millisecond to run instead of 0.001, you won't even > notice. Or applications that are limited by the speed of I/O rather than > the CPU. Which is 99% of the real-world applications if you factor out the code already written in C or other compiled languages. That's the point of Python after all. You speed up programming rather than programs but allow for refactoring into C when necessary. And it's not call CPython for nothing. off-the-shelf benchmarks are fun but mostly useless for choosing a language, priogram, OS or machine unless you know that it checks the actual things that you need in the proportion that you need. > But I'm nitpicking... this is a nice result, the Lua people should be > proud, and I certainly wouldn't say no to a faster Python :) Ditto, ditto, ditto and ditto. > It's not like this is a race, and speed is not the only thing which a > language is judged by. Otherwise you'd be programming in C, not Python, > right? Or assembler. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Sun, Jul 4, 2010 at 11:23 PM, D'Arcy J.M. Cain wrote: > On 04 Jul 2010 04:15:57 GMT > Steven D'Aprano wrote: >> "Need" is a bit strong. There are plenty of applications where if your >> code takes 0.1 millisecond to run instead of 0.001, you won't even >> notice. Or applications that are limited by the speed of I/O rather than >> the CPU. > > Which is 99% of the real-world applications if you factor out the code > already written in C or other compiled languages. This may be true, but there are areas where the percentage is much lower. Not everybody uses python for web development. You can be a python fan, be reasonably competent in the language, and have good reasons to wish for python to be one order of magnitude faster. I find LUA quite interesting: instead of providing a language simple to develop in, it focuses heavily on implementation simplicity. Maybe that's the reason why it could be done at all by a single person. David -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
"sturlamolden" wrote in message news:daa07acb-d525-4e32-91f0-16490027c...@w12g2000yqj.googlegroups.com... I was just looking at Debian's benchmarks. It seems LuaJIT is now (on median) beating Intel Fortran! C (gcc) is running the benchmarks faster by less than a factor of two. Consider that Lua is a dynamically typed scripting language very similar to Python. LuaJIT also runs the benchmarks faster than Java 6 server, OCaml, and SBCL. I know it's "just a benchmark" but this has to count as insanely impressive. Beating Intel Fortran with a dynamic scripting language, how is that even possible? And what about all those arguments that dynamic languages "have to be slow"? If this keeps up we'll need a Python to Lua bytecode compiler very soon. And LuaJIT 2 is rumoured to be much faster than the current... Looking at median runtimes, here is what I got: gcc 1.10 LuaJIT1.96 Java 6 -server2.13 Intel Fortran 2.18 OCaml 3.41 SBCL 3.66 JavaScript V8 7.57 PyPy 31.5 CPython 64.6 Perl 67.2 Ruby 1.9 71.1 The only comfort for CPython is that Ruby and Perl did even worse. I didn't see the same figures; LuaJIT seem to be 4-5 times as slow as one of the C's, on average. Some benchmarks were slower than that. But I've done my own brief tests and I was quite impressed with LuaJIT which seemed to outperform C on some tests. I'm developing my own language and LuaJIT is a new standard to beat for this type of language. However, Lua is quite a lightweight language with minimalist data types, it doesn't suit everybody. I suspect also the Lua JIT compiler optimises some of the dynamicism out of the language (where it can see, for example, that something is always going to be a number, and Lua only has one numeric type with a fixed range), so that must be a big help. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Sun, 4 Jul 2010 23:46:10 +0900 David Cournapeau wrote: > On Sun, Jul 4, 2010 at 11:23 PM, D'Arcy J.M. Cain wrote: > > Which is 99% of the real-world applications if you factor out the code > > already written in C or other compiled languages. > > This may be true, but there are areas where the percentage is much > lower. Not everybody uses python for web development. You can be a > python fan, be reasonably competent in the language, and have good > reasons to wish for python to be one order of magnitude faster. I wish it was orders of magnitude faster for web development. I'm just saying that places where we need compiled language speed that Python already has that in C. But, as I said in the previous message, in the end it is up to you to write your own benchmark based on the operations you need and the usage patterns you predict that it will need as well. If your application needs to calculate Pi to 100 places but only needs to do it once there is no need to include that in your benchmark a million times. A language that is optimized for calculating Pi shouln't carry a lot of weight for you. > I find LUA quite interesting: instead of providing a language simple > to develop in, it focuses heavily on implementation simplicity. Maybe > that's the reason why it could be done at all by a single person. Is that really true about LUA? I haven't looked that closely at it but that paragraph probably turned off most people on this list to LUA. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Sat, 3 Jul 2010 20:30:30 -0700 (PDT) sturlamolden wrote: >CPython 64.6 By the way, I assume that that's Python 2.x. I wonder how Python 3.1 would fare. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: SyntaxError not honoured in list comprehension?
On 07/04/2010 03:49 PM, jmfauth wrote: > On 4 juil, 12:35, Carl Banks wrote: >> On Jul 4, 1:31 am, jmfauth wrote: >> > > > Thanks for having explained in good English my feelings. > > >> >> Some other places were keyword can follow a number: >> > > Note, that this does not envolve numbers only. > ['z' for c in 'abc'] > ['z', 'z', 'z'] 'z'if True else 'a' > z > > > >>> Side effect: If this behaviour is considered as correct, >>> it makes a correct Python code styling (IDLE, editors, ...) >>> practically impossible to realise. >> >> I'm not sure why an odd corner of the grammar would mess the whole >> thing up. Most code stylers only approximate the actual grammar >> anyway. >> > > I guess, most editors (so do I) are mainly using > a "re" engine for their styling. > > --- > > Not a keyword, but space related, what should I thing > about this? > print9 looks like an identifier > Traceback (most recent call last): > File "", line 1, in > NameError: name 'print9' is not defined print+9 can't be a single identifier. Maybe it's a print statement followed by stuff? (stop being a statement, print!) > 9 print'abc' can't be an identifier or string literal. Maybe it's a print statement followed by stuff? > abc print9.0 looks like getattr(print9, '0') - but '0' is not a valid name. Impossible. Error! > File "", line 1 > print9.0 >^ > SyntaxError: invalid syntax somewhat strange, yes. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Mon, Jul 5, 2010 at 12:00 AM, D'Arcy J.M. Cain wrote: > On Sun, 4 Jul 2010 23:46:10 +0900 > David Cournapeau wrote: >> On Sun, Jul 4, 2010 at 11:23 PM, D'Arcy J.M. Cain wrote: >> > Which is 99% of the real-world applications if you factor out the code >> > already written in C or other compiled languages. >> >> This may be true, but there are areas where the percentage is much >> lower. Not everybody uses python for web development. You can be a >> python fan, be reasonably competent in the language, and have good >> reasons to wish for python to be one order of magnitude faster. > > I wish it was orders of magnitude faster for web development. I'm just > saying that places where we need compiled language speed that Python > already has that in C. Well, I wish I did not have to use C, then :) For example, as a contributor to numpy, it bothers me at a fundamental level that so much of numpy is in C. Also, there are some cases where using C for speed is very difficult, because the marshalling cost almost entirely alleviate the speed advantages - that means you have to write in C more than you anticipated. Granted, those may be quite specific to scientific applications, and cython already helps quite a fair bit in those cases. > > But, as I said in the previous message, in the end it is up to you to > write your own benchmark based on the operations you need and the usage > patterns you predict that it will need as well. If your application > needs to calculate Pi to 100 places but only needs to do it once there > is no need to include that in your benchmark a million times. I would question the sanity of anyone choosing a language because it can compute Pi to 100 places very quickly :) I am sure google search would beat most languages if you count implementation + running time anyway. > >> I find LUA quite interesting: instead of providing a language simple >> to develop in, it focuses heavily on implementation simplicity. Maybe >> that's the reason why it could be done at all by a single person. > > Is that really true about LUA? I haven't looked that closely at it but > that paragraph probably turned off most people on this list to LUA. I hope I did not turn anyone off - but it is definitely not the same set of tradeoff as python. LUA runtime is way below 1 Mb, for example, which is one reason why it is so popular for video games. The following presentation gives a good overview (by LUA creator): http://www.stanford.edu/class/ee380/Abstracts/100310-slides.pdf To go back to the original topic: a good example is numeric types. In python, you have many different numerical types with different semantics. In LUA, it is much simpler. This makes implementation simpler, and some aggressive optimizations very effective. The fact that a LUA interpreter can fit in L1 is quite impressive. David -- http://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 2.7 released
On behalf of the Python development team, I'm jocund to announce the second release candidate of Python 2.7. Python 2.7 will be the last major version in the 2.x series. However, it will also have an extended period of bugfix maintenance. 2.7 includes many features that were first released in Python 3.1. The faster io module, the new nested with statement syntax, improved float repr, set literals, dictionary views, and the memoryview object have been backported from 3.1. Other features include an ordered dictionary implementation, unittests improvements, a new sysconfig module, auto-numbering of fields in the str/unicode format method, and support for ttk Tile in Tkinter. For a more extensive list of changes in 2.7, see http://doc.python.org/dev/whatsnew/2.7.html or Misc/NEWS in the Python distribution. To download Python 2.7 visit: http://www.python.org/download/releases/2.7/ 2.7 documentation can be found at: http://docs.python.org/2.7/ This is a production release and should be suitable for all libraries and applications. Please report any bugs you find, so they can be fixed in the next maintenance releases. The bug tracker is at: http://bugs.python.org/ Enjoy! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 2.7's contributors) -- http://mail.python.org/mailman/listinfo/python-list
Twisted 10.1.0 released
On behalf of Twisted Matrix Laboratories, I am honored to announce the release of Twisted 10.1.0. Highlights include: * Deferreds now support cancellation * A new "endpoint" interface which can abstractly describe stream transport endpoints such as TCP and SSL * inotify support for Linux, which allows monitoring of file system events. * AMP supports transferring timestamps Note also that this is the *last* supported release of Twisted for Python 2.4 on Windows. For more information, see the NEWS file. It's stable, backwards compatible, well tested and in every way an improvement. Download it now from: http://tmrc.mit.edu/mirror/twisted/Twisted/10.1/Twisted-10.1.0.tar.bz2 http://tmrc.mit.edu/mirror/twisted/Twisted/10.1/Twisted-10.1.0.winxp32-py2.5.msi http://tmrc.mit.edu/mirror/twisted/Twisted/10.1/Twisted-10.1.0.winxp32-py2.6.msi Many thanks to Glyph Lefkowitz, who helped do the release preparation, and the PyCon 2010 sprinters, who did so much of the work for this release. jml -- http://mail.python.org/mailman/listinfo/python-list
Re: [RELEASE] Python 2.7 released
2010/7/4 Benjamin Peterson : > On behalf of the Python development team, I'm jocund to announce the second > release candidate of Python 2.7. Arg!!! This should, of course, be "final release". -- Regards, Benjamin -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 4 Jul, 16:47, "bart.c" wrote: > I suspect also the Lua JIT compiler optimises some of the dynamicism out of > the language (where it can see, for example, that something is always going > to be a number, and Lua only has one numeric type with a fixed range), so > that must be a big help. Python could do the same, replace int and float with a "long double". It is 80 bit and has a 64 bit mantissa. So it can in theory do the job of all floating point types and integers up to 64 bit (signed and unsigned). A long double can 'duck type' all the floating point and integer types we use. There is really no need for more than one number type. For an interpreted language, it's just a speed killer. Other number types belong in e.g. the ctypes, array, struct and NumPy modules. Speed wise a long double (80 bit) is the native floating point type on x86 FPUs. There is no penalty memory-wise either, wrapping an int as PyObject takes more space. For a dynamic language it can be quite clever to just have one 'native' number type, observing that the mantissa of a floating point number is an unsigned integer. That takes a lot of the dynamicity out of the equation. Maybe you like to have integers and floating point types in the 'language'. But that does not mean it should be two types in the 'implementation' (i.e. internally in the VM). The implementation could duck type both with a suffciently long floating point type, and the user would not notice in the syntax. MATLAB does the same as Lua. Native number types are always double, you have to explicitly create the other. Previously they did not even exist. Scientists have been doing numerical maths with MATLAB for decades. MATLAB never prevented me from working with integers mathematically, even if I only worked with double. If I did not know, I would not have noticed. a = 1; % a is a double a = 1 + 1; % a is a double and exactly 2 a = int32(1); Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 4 Jul, 10:03, Stefan Behnel wrote: > Sort of. One of the major differences is the "number" type, which is (by > default) a floating point type - there is no other type for numbers. The > main reason why Python is slow for arithmetic computations is its integer > type (int in Py3, int/long in Py2), which has arbitrary size and is an > immutable object. So it needs to be reallocated on each computation. That is why Lua got it right. A floating point type has a mantissa and can duck type an integer. MATLAB does the same. Sturla If it > was easily mappable to a CPU integer, Python implementations could just do > that and be fast. But its arbitrary size makes this impossible (or requires > a noticeable overhead, at least). The floating point type is less of a > problem, e.g. Cython safely maps that to a C double already. But the > integer type is. > > So it's not actually surprising that Lua beats CPython (and the other > dynamic languages) in computational benchmarks. > > It's also not surprising to me that a JIT compiler beats a static compiler. > A static compiler can only see static behaviour of the code, potentially > with an artificially constructed idea about the target data. A JIT compiler > can see the real data that flows through the code and can optimise for that. > > Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 4 Jul, 14:29, David Cournapeau wrote: > Actually, I think the main reason why Lua is much faster than other > dynamic languages is its size. The language is small. You don't list, > dict, tuples, etc... They have managed to combine list and dict into one type (table) that does the job of both. And yes there are tuples. There are no classes, but there are closures and other building blocks that can be used to create any object-oriented type system (just like CLOS is defined by Lisp, not a part of the basic Lisp syntax). So I imagine it would be possible to define an equivalent to the Python type system in Lua, and compile Python to Lua. Lua can be compiled to Lua byte code. Factoring Lua, out that means we should be able to compile Python to Lua byte code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Mon, Jul 5, 2010 at 1:12 AM, sturlamolden wrote: > On 4 Jul, 10:03, Stefan Behnel wrote: > >> Sort of. One of the major differences is the "number" type, which is (by >> default) a floating point type - there is no other type for numbers. The >> main reason why Python is slow for arithmetic computations is its integer >> type (int in Py3, int/long in Py2), which has arbitrary size and is an >> immutable object. So it needs to be reallocated on each computation. > > That is why Lua got it right. A floating point type has a mantissa and > can duck type an integer. MATLAB does the same. I sincerly doubt it - where do take the information that matlab use float to represent int ? It would not be able to represent the full range of 64 bits integer for example. David -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 4 Jul, 09:12, Rami Chowdhury wrote: > Out of curiosity, does anyone know how the Unladen Swallow version of Python > does by comparison? Judging from their PyCon slides, it's roughly 1.5 times faster than CPython. That might be important to Google, but not to me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 4 Jul, 18:34, David Cournapeau wrote: > I sincerly doubt it - where do take the information that matlab use > float to represent int ? I've used Matlab since 1994, so I know it rather well... Only the recent versions can do arithmetics with number types different from double (or complex double). > It would not be able to represent the full > range of 64 bits integer for example. There is a 53 bit mantissa plus a sign bit. Nobody complained on 32 bit systems. That is, when the signed 54 bit integer contained in a double was overflowed, there was a loss of precision but the numerical range would still be that of a double. You get an unsigned integer in MATLAB like this x = uint64(0) but until recently, MATLAB could not do any arithmetics with it. It was there for interaction with Java and C MEX files. A long double has a mantissa of 64 bit however, so it can represent signed 65 bit integers without loss of precision. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
sturlamolden, 04.07.2010 18:37: On 4 Jul, 09:12, Rami Chowdhury wrote: Out of curiosity, does anyone know how the Unladen Swallow version of Python does by comparison? Judging from their PyCon slides, it's roughly 1.5 times faster than CPython. A number like "1.5 times faster" is meaningless without a specific application and/or code section in mind. I'm pretty sure there are cases where they are much faster than that, and there are cases where the net gain is zero (or -0.x or whatever). Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 4 Jul, 19:02, Stefan Behnel wrote: > A number like "1.5 times faster" is meaningless without a specific > application and/or code section in mind. I'm pretty sure there are cases > where they are much faster than that, and there are cases where the net > gain is zero (or -0.x or whatever). Here is what they say: Benchmark CPython Unladen Change 2to325.13 s 24.87 s 1.01x faster django 1.08 s0.68 s 1.59x faster html5lib14.29 s 13.20 s 1.08x faster nbody0.51 s0.28 s 1.84x faster rietveld 0.75 s0.55 s 1.37x faster slowpickle 0.75 s0.55 s 1.37x faster slowspitfire 0.83 s0.61 s 1.36x faster slowunpickle 0.33 s0.26 s 1.26x faster spambayes0.31 s0.34 s 1.10x slower -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
sturlamolden, 04.07.2010 19:10: On 4 Jul, 19:02, Stefan Behnel wrote: A number like "1.5 times faster" is meaningless without a specific application and/or code section in mind. I'm pretty sure there are cases where they are much faster than that, and there are cases where the net gain is zero (or -0.x or whatever). Here is what they say: Benchmark CPython Unladen Change 2to325.13 s 24.87 s 1.01x faster django 1.08 s0.68 s 1.59x faster html5lib14.29 s 13.20 s 1.08x faster nbody0.51 s0.28 s 1.84x faster rietveld 0.75 s0.55 s 1.37x faster slowpickle 0.75 s0.55 s 1.37x faster slowspitfire 0.83 s0.61 s 1.36x faster slowunpickle 0.33 s0.26 s 1.26x faster spambayes0.31 s0.34 s 1.10x slower Ok, so, which of those do you care about? Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
"D'Arcy J.M. Cain" writes: >> I find LUA quite interesting: instead of providing a language simple >> to develop in, it focuses heavily on implementation simplicity. Maybe >> that's the reason why it could be done at all by a single person. > > Is that really true about LUA? I haven't looked that closely at it but > that paragraph probably turned off most people on this list to LUA. I would say Lua focuses on implementation compactness; it's intended as an embedded scripting interpreter. It's easy to sandbox and uses just 50k or so of memory. It's running in a lot of mobile phones, cameras, etc. The language itself is nowhere near as featureful as Python and I wouldn't want to use it for large scale development, but it appears pretty good for what it was intended for. Interestingly, it doesn't have lists or arrays. Its only container structure is comparable to a Python dictionary. Arrays are just the special case of dictionaries indexed by numbers. There is a little bit of syntax sugar to help with that, but it's just the dict structure underneath. I wouldn't say it was all done by one person though, and in particular I think LuaJIT was done by a different group than the main Lua developers. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 4 Jul, 19:51, Stefan Behnel wrote: > Ok, so, which of those do you care about? I have already said I don't care about unladen swallow. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Jul 4, 12:30 am, sturlamolden wrote: > I was just looking at Debian's benchmarks. It seems LuaJIT is now (on > median) beating Intel Fortran! > > C (gcc) is running the benchmarks faster by less than a factor of two. > Consider that Lua is a dynamically typed scripting language very > similar to Python. > > LuaJIT also runs the benchmarks faster than Java 6 server, OCaml, and > SBCL. > > I know it's "just a benchmark" but this has to count as insanely > impressive. Beating Intel Fortran with a dynamic scripting language, > how is that even possible? And what about all those arguments that > dynamic languages "have to be slow"? > > If this keeps up we'll need a Python to Lua bytecode compiler very > soon. And LuaJIT 2 is rumoured to be much faster than the current... > > Looking at median runtimes, here is what I got: > > gcc 1.10 > > LuaJIT 1.96 > > Java 6 -server 2.13 > Intel Fortran 2.18 > OCaml 3.41 > SBCL 3.66 > > JavaScript V8 7.57 > > PyPy 31.5 > CPython 64.6 > Perl 67.2 > Ruby 1.9 71.1 > > The only comfort for CPython is that Ruby and Perl did even worse. You should read this thread: http://lambda-the-ultimate.org/node/3851 There, you'll see this subject discussed and explained at length. Pay special attention to Mike Pall's comments (he is the creator of Luajit) and his opinion about python and pypy. You will read also about other projects, specially new javascript engines such as Mozila's Tracemonkey (the authors participate in this thread) and the pypy folks. It is a very good read for anyone interested in the subject. Very recommended! Good luck! Luis -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
sturlamolden, 04.07.2010 21:44: On 4 Jul, 19:51, Stefan Behnel wrote: Ok, so, which of those do you care about? I have already said I don't care about unladen swallow. What I meant, was: which of these benchmarks would have to be better to make you care? Because your decision not to care seems to be based on exactly these benchmarks. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On Jul 4, 4:51 pm, Luis M. González wrote: > On Jul 4, 12:30 am, sturlamolden wrote: > > > > > > > I was just looking at Debian's benchmarks. It seems LuaJIT is now (on > > median) beating Intel Fortran! > > > C (gcc) is running the benchmarks faster by less than a factor of two. > > Consider that Lua is a dynamically typed scripting language very > > similar to Python. > > > LuaJIT also runs the benchmarks faster than Java 6 server, OCaml, and > > SBCL. > > > I know it's "just a benchmark" but this has to count as insanely > > impressive. Beating Intel Fortran with a dynamic scripting language, > > how is that even possible? And what about all those arguments that > > dynamic languages "have to be slow"? > > > If this keeps up we'll need a Python to Lua bytecode compiler very > > soon. And LuaJIT 2 is rumoured to be much faster than the current... > > > Looking at median runtimes, here is what I got: > > > gcc 1.10 > > > LuaJIT 1.96 > > > Java 6 -server 2.13 > > Intel Fortran 2.18 > > OCaml 3.41 > > SBCL 3.66 > > > JavaScript V8 7.57 > > > PyPy 31.5 > > CPython 64.6 > > Perl 67.2 > > Ruby 1.9 71.1 > > > The only comfort for CPython is that Ruby and Perl did even worse. > > You should read this thread:http://lambda-the-ultimate.org/node/3851 > There, you'll see this subject discussed and explained at length. > Pay special attention to Mike Pall's comments (he is the creator of > Luajit) and his opinion about python and pypy. > You will read also about other projects, specially new javascript > engines such as Mozila's Tracemonkey (the authors participate in this > thread) and the pypy folks. > It is a very good read for anyone interested in the subject. Very > recommended! > Good luck! > > Luis To be more specific, check these comments on the above the above suggested thread: http://lambda-the-ultimate.org/node/3851#comment-57804 http://lambda-the-ultimate.org/node/3851#comment-57700 Luis -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On 2 Jul, 21:07, John Nagle wrote: > http://jens.mooseyard.com/2008/12/python-30-whats-the-point/ He is right on. The only thing Python 3k will do for me, is break all my code and be incompatible with all extension modules I need. "What's the point?" indeed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 7/4/2010 12:51 PM, Luis M. González wrote: Looking at median runtimes, here is what I got: gcc 1.10 LuaJIT1.96 Java 6 -server2.13 Intel Fortran 2.18 OCaml 3.41 SBCL 3.66 JavaScript V8 7.57 PyPy 31.5 CPython 64.6 Perl 67.2 Ruby 1.9 71.1 The only comfort for CPython is that Ruby and Perl did even worse. It's embarrassing that Javascript is now 9x faster than Python. Javascript has almost all the dynamic problems that make CPython slow, but they've been overcome in the Javascript JIT compiler. Here's how the Javascript V8 system does it: http://code.google.com/apis/v8/design.html They get rid of unnecessary dictionary lookups for attributes by automatically creating "hidden classes" which, in Python terms, use "slots". If an attribute is added to an object, another hidden class is created with that attribute. Each such class is hard-compiled to machine code while the program is running. So attribute access never requires a dictionary lookup. Adding a new, not-previously-used attribute is a relatively expensive operation, but with most programs, after a while all the new attributes have been added and the program settles down to efficient operation. That's in Google's Chrome browser right now. The Unladen Swallow people should in theory be able to reach that level of performance. (Both groups are employed at Google. So their effectiveness will be compared.) John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Getting the name of the file that imported current module
foo.py: import bar bar.show_importer() output: 'foo' or 'foo.py' or 'path/to/foo' etc. Possible? Thanks, Tobiah -- http://mail.python.org/mailman/listinfo/python-list
Re: Lua is faster than Fortran???
On 7/4/10 9:21 AM, sturlamolden wrote: > On 4 Jul, 14:29, David Cournapeau wrote: > >> Actually, I think the main reason why Lua is much faster than other >> dynamic languages is its size. The language is small. You don't list, >> dict, tuples, etc... > > They have managed to combine list and dict into one type (table) that > does the job of both. You say "managed" as if it were some technical accomplishment, or that the result is able to actually do the job of both: neither of these assertions are true. Have you actually *used* Lua? I quite like the language in certain contexts where its appropriate, but if you've actually used it in real code and found tables to be at all a substitute for *either* dictionaries *or* lists, then I think somehow you've managed to actually miss using either data structure in Python to any real extent, somehow. Lua's tables are at very weak "dictionary-like" and "list-like" objects, which indeed have been folded into one. To the detriment of both, at least as far as they are an actual useful data structure. You can't even get the equivalent of len(dict) in it: you have to actually brute-force iterate the table and count manually. Even for a purely array-like table with onlyn umbered indexes, #table can be unreliable: its quite possible through normal list-like operations that you perform on it, it can end up with holes where #table will fail. Since it is *not* an list internally at *all*, but simply an associative array with numbered indexes. I could go on, and on, and on: but the fundamental *weakness* of Lua' data types as data-structures is irrefutable, from its tables to strings to numbers: they are incredibly weak on capabilities. You end up writing all kinds of "library" functions to just do the normal things that should be really easy to do. Now, of course, there's really good reason why Lua is so simple in these ways. Its entirely suitable for Lua as an embedded scripting language to keep things very light, so it can be simple and fast. Good for Lua to fill this niche superbly. But you can't start saying its simple alternatives are at all comparable to Python's extremely rich and capable data types. > And yes there are tuples. No, there isn't. There's ways to create a tuple-like-thing which kind of behaves like a braindead tuple, and functions have a positively bizarre capability of returning more then one value (and accepting variable values), so there's these points in the language where you have this sort of Immutable Sequence, but its opaque until you unwrap it -- and then it ceases to be. That's not the same thing as having an immutable sequence that you can store data in at your discretion, with a rich series of capabilities that you can leverage. > There are no classes, but there are closures and other building blocks > that can be used to create any object-oriented type system Not really. Above, I spoke of tables as data structures, things just storing data. But you're right, they are capable of more then that-- but you're over-selling just how far that capability goes, by a long shot (and underselling just how much work it takes to get it there). Yes, tables have a limited series of 'hooks' that you can tie into to alter their behavior, and through this you can simulate certain higher order type systems as defined in other languages. In fact, lots of people have done this: there's multiple "classy" libraries out there to bring some kind of Class-or-Object-Oriented-Programming to Lua. They work to varying degrees: but the hooks that Lua provides to tables is still significantly lacking to really replace Python's comprehensively dynamic object model, without a LOT of wasted cycles. For example, while you can use __newindex to 'catch' someone setting a new 'key' on a table, and and __index to replace or forward the actual lookup, you can't actually capture someone trying to set a value to a key which already exists. So, you end up having to do a full proxy approach, where your table never actually stores anything directly (except a reference to another hidden table), and so when someone goes to set something you have to set it on the proxied object instead. Because you can't let there ever be any real keys on the proxying / external table. So you're able to work around its lack a bit, to simulate something /like/ what it means to have __setattr__. But then you run into problems. There's no way now to iterate over the table now, because pairs() will only return your internal hidden keys that you're using to point to the proxied table (Although you can get around this with some more complexity by hiding said key into a closure-- but even then, you still can't iterate over the proxied table's keys instead). So what do you do? Well you go replace the global "pairs" function, that's what you do! So it learns your particular style of Classness, and interacts well. Hope you never use any third-party code which has even a vaguely different kind of
Re: Getting the name of the file that imported current module
On 04/07/2010 22:05, Tobiah wrote: foo.py: import bar bar.show_importer() output: 'foo' or 'foo.py' or 'path/to/foo' etc. Possible? Thanks, Tobiah >>> import re >>> re.__file__ 'C:\\Python26\\lib\\re.pyc' HTH. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: SyntaxError not honoured in list comprehension?
On Jul 5, 1:08 am, Thomas Jollans wrote: > On 07/04/2010 03:49 PM, jmfauth wrote: > > File "", line 1 > > print9.0 > > ^ > > SyntaxError: invalid syntax > > somewhat strange, yes. There are two tokens, "print9" (a name) and ".0" (a float constant) -- looks like SyntaxError to me. -- http://mail.python.org/mailman/listinfo/python-list
Python 3 put-downs: What's the point?
-- http://mail.python.org/mailman/listinfo/python-list
Re: Getting the name of the file that imported current module
On 07/04/2010 03:17 PM, Mark Lawrence wrote: > On 04/07/2010 22:05, Tobiah wrote: >> foo.py: >> >> import bar >> bar.show_importer() >> >> output: >> >> 'foo' or 'foo.py' or 'path/to/foo' etc. >> >> Possible? >> >> Thanks, >> >> Tobiah > > >>> import re > >>> re.__file__ > 'C:\\Python26\\lib\\re.pyc' I think this is exactly opposite of what he was asking for. Given than any number of modules can import other modules but each module really only exists once in the Python object space (normally) would mean that what the OP is asking for isn't possible. -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting the name of the file that imported current module
On Sun, 04 Jul 2010 21:05:56 +, Tobiah wrote: > foo.py: > > import bar > bar.show_importer() > > output: > > 'foo' or 'foo.py' or 'path/to/foo' etc. > > Possible? I don't think so. Your question isn't even well-defined. Given three modules: # a.py import b import d # b.py import d # c.py import a import d import b print d.show_importer() and you run c.py, what do you expect d.show_importer() to return? And what about "from d import show_importer" -- does that count as "importing d"? Why do you think that a module needs to know what other modules imported it? I can't imagine why this would be necessary, what are you intending to do with it? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Shared object access problems
Using python 2.6.4 on slackware 13.1 I have MySQLdb 'by hand', that is: by 1)downloading MySQL-python-1.2.3c1.tar.gz 2)unzipping tarfile 3)running python setup.py build 4)running python setup.py install The build and install seemed to proceded without error, but upon invoking the interpreter and running >>> import MySQLdb I get the following ImportError: ## Traceback (most recent call last): File "", line 1, in File "build/bdist.linux-i686/egg/MySQLdb/__init__.py", line 19, in File "build/bdist.linux-i686/egg/_mysql.py", line 7, in File "build/bdist.linux-i686/egg/_mysql.py", line 6, in __bootstrap__ ImportError: libmysqlclient_r.so.15: cannot open shared object file: No such file or directory ## There was no libmysqlclient_r.so.15 on my machine, so I made symlinks at both /usr/lib/mysql/ and /usr/lib which are libmysqlclient_r.so.15 pointing to /usr/lib/mysql/libmysqlclient_r.so.16.0.0 Now when I run import MySQLdb, I get the following error: ## Traceback (most recent call last): File "", line 1, in File "MySQLdb/__init__.py", line 19, in import _mysql File "build/bdist.linux-i686/egg/_mysql.py", line 7, in File "build/bdist.linux-i686/egg/_mysql.py", line 6, in __bootstrap__ ImportError: /usr/lib/libmysqlclient_r.so.15: version `libmysqlclient_15' not found (required by /home/tim/.python-eggs/MySQL_python-1.2.3c1-py2.6-linux-i686.egg-tmp /_mysql.so) ## # Note that the parenthesized expression beginning with "(required" # has been broken to accomodate the newsgroup - was one line [sigh!] I've been using python and mysql on linux for 10 years and have done many 'hand installs' and boy has it gotten complicated. Any ideas? thanks -- Tim tim at johnsons-web.com or akwebsoft.com http://www.akwebsoft.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3 put-downs: What's the point?
I think it's the same venting of frustration that caused veteran VB6 developers to start calling VB.Net "Visual Fred" -- the language was too different and too non-backwards-compatible. The 2to3 tools are better (partly due to the less drastic language changes compared to the Fred'ification of VB) than the VB6->Fred conversion tools. I'd also agree that Py3 comes closer to the language ideals that Py2.x aspired to be, but Py2.x was held back by the fairly strict moratorium on the introduction of backwards incompatible changes. The language changes also introduce frustrations when searching for example code: what was "Python" code examples now may or may not now work in Py3 or Py2 (and more importantly, may not have a caveat regarding which interpreter to use). Finally, the slow transformation of the vast volume of existing Python libraries adds a bit of irritant to the masses. There was some dialog on the Django mailing list a while back about Py3 transitions, but it's still pretty distant on the roadmap. I've often wondered if changing the name of the language (such as "Adder", "Served", "Dwarf" or "Fawlty" for the Britcom fans in the crowd) would have mitigated some of the more vituperative slurs on what became Py3, designating a shared legacy without the expectation of 100% backwards-compatibility. -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On 7/4/2010 1:20 PM, sturlamolden wrote: On 2 Jul, 21:07, John Nagle wrote: http://jens.mooseyard.com/2008/12/python-30-whats-the-point/ He is right on. The only thing Python 3k will do for me, is break all my code and be incompatible with all extension modules I need. "What's the point?" indeed. Exactly. The "incompatible with all extension modules I need" part is the problem right now. A good first step would be to identify the top 5 or 10 modules that are blocking a move to Python 3 by major projects with many users. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3 put-downs: What's the point?
In article , Tim Chase wrote: > I've often wondered if changing the name of the language (such as > "Adder", "Served", "Dwarf" or "Fawlty" for the Britcom fans in > the crowd) would have mitigated some of the more vituperative > slurs on what became Py3, designating a shared legacy without the > expectation of 100% backwards-compatibility. Maybe it should have been "Python five, no, THREE!" -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3 put-downs: What's the point?
On Sun, Jul 4, 2010 at 5:05 PM, Roy Smith wrote: > In article , > Tim Chase wrote: >> I've often wondered if changing the name of the language (such as >> "Adder", "Served", "Dwarf" or "Fawlty" for the Britcom fans in >> the crowd) would have mitigated some of the more vituperative >> slurs on what became Py3, designating a shared legacy without the >> expectation of 100% backwards-compatibility. > > Maybe it should have been "Python five, no, THREE!" +1 QOTW Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On Sun, 04 Jul 2010 16:58:04 -0700, John Nagle wrote: > The "incompatible with all extension modules I need" part > is the problem right now. A good first step would be to identify the > top 5 or 10 modules that are blocking a move to Python 3 by major > projects with many users. Are you volunteering to assist, or just belly-aching? Migration to Python 3 is occurring at about the speed that should be expected, modulo the setback that was the seriously flawed 3.0 release. 3.1 should be treated as the "early adopter" version. I would expect 3.3 will probably be the first "mainstream" version, where v3 users start to outnumber v2 users. If people have concrete, *specific* issues that are holding them back from serious plans to migrate to Python 3 then reporting them is a good first step: e.g. telling the author of extension module Foo that you need Python 3 compatibility. Complaining that "extension modules aren't compatible" is just bitching for the sake of bitching and isn't helpful. Please take it elsewhere. Start a blog "why I hate Python 3" or something. Or just stick with Python 2.x forever, without the negativity. There's no law that says you have to upgrade. There are people still using 1.5, and more power to them. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On 5 Jul, 01:58, John Nagle wrote: > Exactly. > > The "incompatible with all extension modules I need" part > is the problem right now. A good first step would be to > identify the top 5 or 10 modules that are blocking a move to > Python 3 by major projects with many users. The big danger is Python 2.x becoming abandonware (2.7 being the final release) before major projects are ported. Using Python 2.x for new projects is not advisable (at least many will think so), and using 3.x is not possible. What to do? It's not a helpful situation for Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3 put-downs: What's the point?
Roy Smith writes: > Maybe it should have been "Python five, no, THREE!" +1 QOTW -- \ “Our products just aren't engineered for security.” —Brian | `\ Valentine, senior vice-president of Microsoft Windows | _o__)development, 2002 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: delegation pattern via descriptor
kedra marbun wrote: now, i'm asking another favor, what about the 2nd point in my 1st post? Your original post has dropped off my newsscope, so you'll have to remind me what the 2nd point was. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
VICIOUS Enemy Insurgents kill 34 US soldiers after 9 hrs attack - Bellies ripped open and numerous injured - call for TRUE PATRIOTS . The deep undercover spies mislead the public on the facts
VICIOUS Enemy Insurgents kill 34 US soldiers after 9 hrs attack - Bellies ripped open and numerous injured - call for TRUE PATRIOTS . The deep undercover spies mislead the public on the facts http://www.youtube.com/watch?v=fRZSzdQuOqM&feature=related http://www.youtube.com/watch?v=0q7yEnMjQ6U&feature=related http://www.youtube.com/watch?v=a3E2NcC0x20&feature=related http://www.youtube.com/watch?v=fRZSzdQuOqM&feature=related http://www.venusproject.com/911/911RussianSatellite1.html http://www.gtr5.com/ -- http://mail.python.org/mailman/listinfo/python-list
VICIOUS Enemy Insurgents kill 34 US soldiers after 9 hrs attack - Bellies ripped open and numerous injured - call for TRUE PATRIOTS . The deep undercover spies agents of influence mislead the public
VICIOUS Enemy Insurgents kill 34 US soldiers after 9 hrs attack - Bellies ripped open and numerous injured - call for TRUE PATRIOTS . The deep undercover spies agents of influence mislead the public on the facts http://www.youtube.com/watch?v=fRZSzdQuOqM&feature=related http://www.youtube.com/watch?v=0q7yEnMjQ6U&feature=related http://www.youtube.com/watch?v=a3E2NcC0x20&feature=related http://www.youtube.com/watch?v=fRZSzdQuOqM&feature=related http://www.venusproject.com/911/911RussianSatellite1.html http://www.gtr5.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3 put-downs: What's the point?
On Jul 4, 7:14 pm, Terry Reedy wrote: > I think there's a good point to Python 3 put-downs (if I take put-down to mean generally reasonable criticism, which is what I've read here recently, and not trolling). And that is simply to register dissent. Any online group is an opportunity to register dissent in a way that is public, open, immediate, interactive, and will (probably) be preserved for historians to check. The fact is, some people have gripes with Python 3; they are letting it be known. If no one did, there could be no later time at which people could look back and know what the reaction was to its introduction--it would just be a blank. Aren't opinions that dissent from the prevailing ones important to register, whether one thinks they are right or wrong? Che -- http://mail.python.org/mailman/listinfo/python-list
Re: Shared object access problems
hi Tim, This seems more likely to be a MySQLdb problem than a Python one. Have you considered asking in the MySQLdb forums? On Jul 4, 2010, at 7:46 PM, Tim Johnson wrote: Using python 2.6.4 on slackware 13.1 I have MySQLdb 'by hand', that is: by 1)downloading MySQL-python-1.2.3c1.tar.gz 2)unzipping tarfile 3)running python setup.py build 4)running python setup.py install The build and install seemed to proceded without error, but upon invoking the interpreter and running import MySQLdb I get the following ImportError: ## Traceback (most recent call last): File "", line 1, in File "build/bdist.linux-i686/egg/MySQLdb/__init__.py", line 19, in File "build/bdist.linux-i686/egg/_mysql.py", line 7, in File "build/bdist.linux-i686/egg/_mysql.py", line 6, in __bootstrap__ ImportError: libmysqlclient_r.so.15: cannot open shared object file: No such file or directory ## There was no libmysqlclient_r.so.15 on my machine, so I made symlinks at both /usr/lib/mysql/ and /usr/lib which are libmysqlclient_r.so.15 pointing to /usr/lib/mysql/libmysqlclient_r.so.16.0.0 Now when I run import MySQLdb, I get the following error: ## Traceback (most recent call last): File "", line 1, in File "MySQLdb/__init__.py", line 19, in import _mysql File "build/bdist.linux-i686/egg/_mysql.py", line 7, in File "build/bdist.linux-i686/egg/_mysql.py", line 6, in __bootstrap__ ImportError: /usr/lib/libmysqlclient_r.so.15: version `libmysqlclient_15' not found (required by /home/tim/.python-eggs/MySQL_python-1.2.3c1-py2.6-linux-i686.egg- tmp /_mysql.so) ## # Note that the parenthesized expression beginning with "(required" # has been broken to accomodate the newsgroup - was one line [sigh!] I've been using python and mysql on linux for 10 years and have done many 'hand installs' and boy has it gotten complicated. Any ideas? thanks -- Tim tim at johnsons-web.com or akwebsoft.com http://www.akwebsoft.com -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On 7/4/2010 5:34 PM, sturlamolden wrote: On 5 Jul, 01:58, John Nagle wrote: Exactly. The "incompatible with all extension modules I need" part is the problem right now. A good first step would be to identify the top 5 or 10 modules that are blocking a move to Python 3 by major projects with many users. The big danger is Python 2.x becoming abandonware (2.7 being the final release) before major projects are ported. Using Python 2.x for new projects is not advisable (at least many will think so), and using 3.x is not possible. What to do? It's not a helpful situation for Python. Projects have been known to get into a state where version N-1 is abandonware, and version N isn't usable yet. Then they die off. The VRML-Web3D transition is an example. VRML 97 was ahead of its time because few people had enough graphics power in 1997 to run it. During the dot-com boom, the "Web 3D Consortium" (http://www.web3d.org) was formed to put 3D on the web. The approach chosen was to recast VRML in XML notation. Users were starting to get 3D boards in quantity, and VRML was starting to really work. But the forced transition killed work on VRML, while there wasn't enough momentum to get people to use the XML version. The Web3D consortium is still around. They have conferences. They have something of a niche market in DoD training sims. But they're running on empty. Nobody is paying attention. There's no mainstream interest in either VRML or Web3D. It works fine; there are X3D players, and they work great on modern graphics processors. But nobody cares. That's what happens when you mismanage an incompatible transition. That could happen to Python. Python has strong competition. In the last two years, Javascript has become much faster, PHP is getting a JIT compiler, Lua, as recently mentioned, is getting up there with C in speed, and Google is promoting Go. The other scripting languages are becoming rocket-powered. Meanwhile, Python is in year 2 of a 5-year plan to transition to something that goes no faster (and maybe slower) than the previous version. (Yes, there's Unladen Swallow and PyPy, but neither of those projects seems to be anywhere near deployment, and even if they succeed, their claimed speed goals are well below where the competition is now.) That's just not good enough any more. Denying that there's a problem does not help. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Shared object access problems
On 7/4/2010 6:36 PM, Philip Semanchuk wrote: hi Tim, This seems more likely to be a MySQLdb problem than a Python one. Have you considered asking in the MySQLdb forums? On Jul 4, 2010, at 7:46 PM, Tim Johnson wrote: Using python 2.6.4 on slackware 13.1 I have MySQLdb 'by hand', that is: by 1)downloading MySQL-python-1.2.3c1.tar.gz 2)unzipping tarfile 3)running python setup.py build 4)running python setup.py install The build and install seemed to proceded without error, but upon invoking the interpreter and running import MySQLdb I get the following ImportError: ## Traceback (most recent call last): File "", line 1, in File "build/bdist.linux-i686/egg/MySQLdb/__init__.py", line 19, in File "build/bdist.linux-i686/egg/_mysql.py", line 7, in File "build/bdist.linux-i686/egg/_mysql.py", line 6, in __bootstrap__ ImportError: libmysqlclient_r.so.15: cannot open shared object file: No such file or directory Did you install the development libraries for MySQL first? Those are needed to build MySQLdb yourself. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.7 released
On Jul 4, 8:34 am, Benjamin Peterson wrote: > On behalf of the Python development team, I'm jocund to announce the second > release candidate of Python 2.7. > > Python 2.7 will be the last major version in the 2.x series. However, it will > also have an extended period of bugfix maintenance. > > 2.7 includes many features that were first released in Python 3.1. The faster > io > module, the new nested with statement syntax, improved float repr, set > literals, > dictionary views, and the memoryview object have been backported from 3.1. > Other > features include an ordered dictionary implementation, unittests > improvements, a > new sysconfig module, auto-numbering of fields in the str/unicode format > method, > and support for ttk Tile in Tkinter. For a more extensive list of changes in > 2.7, seehttp://doc.python.org/dev/whatsnew/2.7.htmlor Misc/NEWS in the Python > distribution. > > To download Python 2.7 visit: > > http://www.python.org/download/releases/2.7/ > > 2.7 documentation can be found at: > > http://docs.python.org/2.7/ > > This is a production release and should be suitable for all libraries and > applications. Please report any bugs you find, so they can be fixed in the > next > maintenance releases. The bug tracker is at: > > http://bugs.python.org/ > > Enjoy! > > -- > Benjamin Peterson > Release Manager > benjamin at python.org > (on behalf of the entire python-dev team and 2.7's contributors) Benjamin (or anyone else), do you know where I can get the Compiled Windows Help file -- python27.chm -- for this release? In the past I've been able to download it from the Python web site, but have been unable to locate it anywhere for this new release. I can't build it myself because I don't have the Microsoft HTML help file compiler. Thanks in advance. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.7 released
On Jul 5, 12:27 pm, Martineau wrote: > On Jul 4, 8:34 am, Benjamin Peterson wrote: > > > > > On behalf of the Python development team, I'm jocund to announce the second > > release candidate of Python 2.7. > > > Python 2.7 will be the last major version in the 2.x series. However, it > > will > > also have an extended period of bugfix maintenance. > > > 2.7 includes many features that were first released in Python 3.1. The > > faster io > > module, the new nested with statement syntax, improved float repr, set > > literals, > > dictionary views, and the memoryview object have been backported from 3.1. > > Other > > features include an ordered dictionary implementation, unittests > > improvements, a > > new sysconfig module, auto-numbering of fields in the str/unicode format > > method, > > and support for ttk Tile in Tkinter. For a more extensive list of changes > > in > > 2.7, seehttp://doc.python.org/dev/whatsnew/2.7.htmlorMisc/NEWS in the Python > > distribution. > > > To download Python 2.7 visit: > > > http://www.python.org/download/releases/2.7/ > > > 2.7 documentation can be found at: > > > http://docs.python.org/2.7/ > > > This is a production release and should be suitable for all libraries and > > applications. Please report any bugs you find, so they can be fixed in the > > next > > maintenance releases. The bug tracker is at: > > > http://bugs.python.org/ > > > Enjoy! > > > -- > > Benjamin Peterson > > Release Manager > > benjamin at python.org > > (on behalf of the entire python-dev team and 2.7's contributors) > > Benjamin (or anyone else), do you know where I can get the Compiled > Windows Help file -- python27.chm -- for this release? In the past > I've been able to download it from the Python web site, but have been > unable to locate it anywhere for this new release. I can't build it > myself because I don't have the Microsoft HTML help file compiler. > > Thanks in advance. If you have a Windows box, download the .msi installer for Python 2.7 and install it. The chm file will be in C:\Python27\Doc (if you choose the default installation directory). Otherwise ask a friendly local Windows user for a copy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Shared object access problems
* Philip Semanchuk [100704 18:13]: > hi Tim, > This seems more likely to be a MySQLdb problem than a Python one. You are correct > Have you considered asking in the MySQLdb forums? Didn't know there was one! where is it? I will join thanks tim > On Jul 4, 2010, at 7:46 PM, Tim Johnson wrote: > >> Using python 2.6.4 on slackware 13.1 >> I have MySQLdb 'by hand', that is: by >> 1)downloading MySQL-python-1.2.3c1.tar.gz >> 2)unzipping tarfile >> 3)running python setup.py build >> 4)running python setup.py install >> >> The build and install seemed to proceded without error, >> but upon invoking the interpreter and running > import MySQLdb >> I get the following ImportError: >> ## >> Traceback (most recent call last): >> File "", line 1, in >> File "build/bdist.linux-i686/egg/MySQLdb/__init__.py", >>line 19, in >> File "build/bdist.linux-i686/egg/_mysql.py", >>line 7, in >> File "build/bdist.linux-i686/egg/_mysql.py", >>line 6, in __bootstrap__ >> ImportError: libmysqlclient_r.so.15: >> cannot open shared object file: No such file or directory >> ## >> There was no libmysqlclient_r.so.15 on my machine, so I made >> symlinks at both /usr/lib/mysql/ and /usr/lib which >> are libmysqlclient_r.so.15 pointing to >> /usr/lib/mysql/libmysqlclient_r.so.16.0.0 >> >> Now when I run import MySQLdb, I get the following error: >> ## >> Traceback (most recent call last): >> File "", line 1, in >> File "MySQLdb/__init__.py", line 19, in >>import _mysql >> File "build/bdist.linux-i686/egg/_mysql.py", >>line 7, in >> File "build/bdist.linux-i686/egg/_mysql.py", >> line 6, in __bootstrap__ >> ImportError: /usr/lib/libmysqlclient_r.so.15: >> version `libmysqlclient_15' not found >> (required by >>/home/tim/.python-eggs/MySQL_python-1.2.3c1-py2.6-linux-i686.egg- >> tmp >> /_mysql.so) >> ## >> # Note that the parenthesized expression beginning with "(required" >> # has been broken to accomodate the newsgroup - was one line >> [sigh!] I've been using python and mysql on linux for 10 years and >> have done many 'hand installs' and boy has it gotten complicated. >> Any ideas? >> thanks >> >> -- >> Tim >> tim at johnsons-web.com or akwebsoft.com >> http://www.akwebsoft.com >> -- >> http://mail.python.org/mailman/listinfo/python-list > -- Tim tim at johnsons-web.com or akwebsoft.com http://www.akwebsoft.com -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On Jul 4, 8:59 pm, John Nagle wrote: > That's what happens when you > mismanage an incompatible transition. +1 > Python has strong competition. In the last two years, > Javascript has become much faster, PHP is getting a JIT compiler, > Lua, as recently mentioned, is getting up there with C in speed, and > Google is promoting Go. The other scripting languages are becoming > rocket-powered. Meanwhile, Python is in year 2 of a 5-year plan to > transition to something that goes no faster (and maybe slower) than > the previous version. (Yes, there's Unladen Swallow and PyPy, but > neither of those projects seems to be anywhere near deployment, > and even if they succeed, their claimed speed goals are well below where > the competition is now.) That's just not good enough any more. > > Denying that there's a problem does not help. +1 Hmm, i myself railed against the changes in Python3.x about 1 year ago. Then, as i pondered the reasons behind such changes i began to believe that the BDFL is wiser than us all! However, i must agree that many of the points you bring up here are real. People ARE stuck in limbo right now and there is no good direction to go... Stick with 2.x and have all the 3rd party support but soon enough you will need to do a major bug fixing, or move to 3.x -- oh wait i can't move to 3.x because module xxyy is not 3.x compatible! What we have here gentlemen is a situation, a terrible situation made worse by our lack to understand it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting the name of the file that imported current module
On 05/07/2010 00:25, Michael Torrie wrote: On 07/04/2010 03:17 PM, Mark Lawrence wrote: On 04/07/2010 22:05, Tobiah wrote: foo.py: import bar bar.show_importer() output: 'foo' or 'foo.py' or 'path/to/foo' etc. Possible? Thanks, Tobiah >>> import re >>> re.__file__ 'C:\\Python26\\lib\\re.pyc' I think this is exactly opposite of what he was asking for. Given than any number of modules can import other modules but each module really only exists once in the Python object space (normally) would mean that what the OP is asking for isn't possible. You're absolutely correct, thou shalt not post late at night when very tired. :) Cheers. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Why Python forbids multiple instances of one module?
Why Python forbids multiple instances of one module? If only Python allows multiple instances of one module, module will be enough to replace class in most cases. After all, it is much easier to write a module than a class, at least we do not have to write self everywhere. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why Python forbids multiple instances of one module?
2010/7/4 CHEN Guang : > Why Python forbids multiple instances of one module? > If only Python allows multiple instances of one module, module will > be enough to replace class in most cases. > After all, it is much easier to write a module than a class, at least we do > not have to write self everywhere. If you really want to do that, it should be possible by deleting the entry from sys.modules and re-importing it. You save yourself having to explicitly write self everywhere, but instead you have to declare all your "instance" variables as globals in each "method" that uses them, which isn't much less of a chore. You also lose inheritance, properties (and descriptors in general), magic method support, metaclasses, and pretty much all the other nice features that new-style classes have to offer. -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On 7/4/2010 7:58 PM, John Nagle wrote: The "incompatible with all extension modules I need" part is the problem right now. A good first step would be to identify the top 5 or 10 modules that are blocking a move to Python 3 by major projects with many users. Let me repeat. Last September, if not before, Guido identified numpy as a top package blocking moves by other packages and projects. I am not sure what he thought, but I consider it number 1. He encouraged the numpy people to produce a 3.x version even though some did not see any personal benefit. We supposedly will see numpy for 3.2. If we actually do, other dominoes will fall into place. I you have any other ideas about other top blockers, please share them. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Why Python forbids multiple instances of one module?
2010/7/4 CHEN Guang : > Why Python forbids multiple instances of one module? That's just how its import mechanism works. It allows for modules that need canonical program-wide state to rely on being singleton, and it's also an optimization. You can trick the import machinery and get around the restriction though. > If only Python allows multiple instances of one module, module will > be enough to replace class in most cases. Why do classes need replacement in the first place? Modules and classes serve distinct purposes. Also: How would you specify a class-module's superclasses? And what if a class depends on other modules/classes/packages? Then the class-module's namespace would be polluted with all the stuff it imported; ick. > After all, it is much easier to write a module than a class, at least we do > not have to write self everywhere. That seems a relatively petty reason; see also Ian's excellent point about `global`. Cheers, Chris -- Yay, Fireworks! http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On Sun, 04 Jul 2010 17:34:04 -0700, sturlamolden wrote: > Using Python 2.x for new > projects is not advisable (at least many will think so), and using 3.x > is not possible. What to do? It's not a helpful situation for Python. That's pure FUD. Python 2.7 will be supported longer than the normal support period for versions 2.6, 2.5, 2.4, ... so if you have a new project that requires libraries that aren't available for 3.1, then go right ahead and use 2.7. By the time 2.7 is no longer supported (probably around the time 3.4 comes out?), the library situation will be fixed. Those 3.1 features that can be backported to 2.x have been, specifically to reduce the pain in porting 2.7-based applications to 3.x. Feature- wise, 2.7 is designed to ease the transition from the 2.x series to the 3.x series. Claiming that it's not advisable to use 2.7 is simply nonsense. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as a scripting language. Alternative to bash script?
In message <7xpqzbj8st@ruckus.brouhaha.com>, Paul Rubin wrote: > ... and argc/argv were passed to the child process on its stack. I’ve always felt that to be a misfeature. It means you can’t implement a self-contained argument-parsing library, it still needs the mainline to explicitly pass/put its arguments somewhere. -- http://mail.python.org/mailman/listinfo/python-list
