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 ru
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 hav
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 o
* 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 mappab
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, ...)
practic
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 n
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 co
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 abo
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,
>
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, des
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 tok
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 anot
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
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
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
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
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 limit
"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
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 th
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
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 on
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 compil
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 Pyt
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, wh
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
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.
Pyth
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 P
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
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 co
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
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 doub
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 meaningles
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).
He
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
"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
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
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 t
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 se
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 tha
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/
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
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
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 di
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
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
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
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
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 r
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
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?" in
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 th
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 w
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 vo
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 da
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,
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
http://www.youtube.com/watch?v=fRZSzdQuOqM&feature=related
http://www.youtube.com/watch?v=0q7yEnMjQ6U&feat
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/watc
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
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)un
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
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)d
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
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
>
* 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 J
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
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\\l
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.pytho
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 every
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 no
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 res
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
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/
74 matches
Mail list logo
