Re: Python documentation moronicities (continued)
I sympathize with you and also think there should be an "add comment" in the Python documentation website, so that users could post their code snippets in the relevant places. I found the Howto through Google. Somehow I didn't see that link in the documentation. And please do not make any assumptions about my reading of manuals. -- http://mail.python.org/mailman/listinfo/python-list
Re: preallocate list
what about : factors = [map(float, line.split()) for line in file] should be a hell of a lot faster and nicer. for line in f: factor = [] tokens = line.split() for i in tokens: factor.append(float(i)) factors.append(factor) Is this nasty? Jim -- http://mail.python.org/mailman/listinfo/python-list
Re: database in python ?
postgresql is slower than MySQL, at least for modest size tables. There must, I When not using transactions, MySQL will blow away postgres in INSERT/UPDATE speed until the concurrency gets up a bit and the readers block writers strategy used by MyISAM starts to show its weaknesses. This is in agreement with mass hosting for instance, a lot of small databases on a mysql will not have concurrency problems. Of course when not using transactions you have to remind that your data is not secure, and any power crash might corrupt your database. Postgres on a RAID with battery backed up cache will no longer have to sync the disk on each transaction so it gets a lot faster, and you still have data security. You can also run it with fsync=off for a massive speedup in transactions per second but you lose data security. When using transactions (innodb) I've read that postgres is a bit faster. Regarding query optimization, for simple dumb queries like grabbing a row from a table, mysql will be a little faster (say 0.2 vs 0.3 ms), and for medium complex queries like joins on >= 4 medium sized tables (>10 K rows) postgres can be faster by anything from 1x to 1000x. I've seen it happen, the same query taking 0.5 seconds in my and 0.5 ms in postgres, simply because mysql can't plan it correctly. suppose, be some turnover point on the size of the database? Or are you arguing that postgresql is now faster than MySQL in the general case? Can you I'd suggest that on anything medium postgres will be a lot faster. I don't know about the whole picture, but I know form evidence on this group that there are PostgreSQL driver modules (the name "psycopg" comes to mind, but this may be false memory) that appear to take diabolical liberties with DBAPI-2.0, whereas my experience with MySQLdb has been that I can interchange the driver with mxODBC (for example) as a drop-in replacement (modulo the differing paramstyles :-(). psycopg is extremely fast and powerful, so it makes a lot more things that the dbapi says. I'd say that database independence is an utopia, once you start to use triggers and stored procedures and specific column types, you'll be more or less tied to one database, and doing this is necessary to get good performance and generally do things right. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python appropriate for web applications?
The first one was a typo in the name of a variable ($actegories instead of $categories). Instead of raising an exception, this b**d "programming language" (err...) just created a new variable with a NULL value. Doh :-( Set error reporting to all. Marvel at how it reports this simple typo in a clear and easy to understand way. Then notice it also gives you a million warnings for a lot of valid stuff in your code. Cry. The second one was about array concatenation/union. I had used the "+" operator instead of the array_merge() function. My favourite is array_key_exists(). Without looking at the docs, can you tell me the order of the parameters ? Read the PHP doc about the "+" operators for arrays and the array_merge() function (don't forget that PHP uses the same construct for arrays and mappings - doh). Then imagine yourself programming PHP, and ask yourself if you'll really develop faster with such a braindead quick&dirty hack for language. PHP-is-VB-for-the-web-ly'yrs -- http://mail.python.org/mailman/listinfo/python-list
Re: pre-PEP: Simple Thunks
I think your proposal is very interesting, I've been missing code blocks
in Python more and more as time goes by.
I'll answer to both the 'thunks" proposal and the "suite-based keywords"
proposal here.
I find the Ruby syntax rather dirty though, because it has a lot of
implicit stuff, treats code blocks as different from normal arguments,
allows passing only one code block, needs a proc keyword, has yield
execute an implicit block... all this, coming from a Python "explicit is
better than implicit" background (which makes a lot of sense) is simply
ugly.
I like your syntax but have a few comments.
I'll give you an unordered list of ideas, up to you to do what you like
with them.
Keep in mind that most of the problems come from the "space is
significant" thing, which is IMHO a very good idea, but prevents us from
putting code in expressions, like :
func( a,b, def callback( x ):
print x
)
or does it ? maybe this syntax could be made to work ?
Comments on the thunks.
First of all I view code blocks as essential to a language. They are very
useful for a lot of common programming tasks (like defining callbacks in
an elegant way) :
button = create_button( "Save changes" ):
do
self.save()
However it seems your thunks can't take parameters, which to me is a big
drawback. In ruby a thunk can take parameters. Simple examples :
field = edit_field( "initial value", onsubmit={ |value| if
self.validate(value) then do something else alert( "the value is invalid"
) } )
[1,3,4].each { |x| puts x }
This has the advantage that the interface to the thunk (ie. its
parameters) are right there before your eyes instead of being buried in
the thunk invocation code inside the edit_field.
a more complex random example :
fields['password1'] = edit_field( "Enter Password" )
fields['password2'] = edit_field( "Enter it again", onsubmit = {|value,
other_values| if value != other_values['password_1'] then alert('the two
passwords must be the same !") }
So I think it's essential that thunks take parameters and return a value
(to use them effectively as callbacks).
What shall distinguish them from a simple alteration to def(): which
returns the function as a value, and an optional name ? really I don't
know, but it could be the way they handle closures and share local
variables with the defining scope. Or it could be that there is no need
for two kinds of function/blocks and so we can reuse the keyword def() :
If you wish to modify def(), you could do, without creating any keyword
:
# standard form
f = def func( params ):
code
# unnamed code block taking params
func = def (params):
code
Note that the two above are equivalent with regard to the variable
"func", ie. func contains the defined function. Actually I find def
funcname() to be bloat, as funcname = def() has the same functionality,
but is a lot more universal.
# unnamed block taking no params
f = def:
code
***
Comments on the suite-based keywords.
Did you notice that this was basically a generalized HEREDOC syntax ?
I'd say that explicit is better than implicit, hence...
Your syntax is :
do f(a,b):
a block
passes block as the last parameter of f.
I don't like it because it hides stuff.
I'd write :
f(a,b,@>,@>):
"""a very
large multi-line
string"""
def (x):
print x
Here the @> is a symbol (use whatever you like) to indicate "placeholder
for something which is on the next line".
Indentation indicates that the following lines are indeed argument for
the function. The : at the end of the function call is there for coherence
with the rest of the syntax.
Notice that, this way, there is no need for a "do" keyword, as the code
block created by an anonymous def() is no different that the other
parameter, in this case a multiline string.
This has many advantages.
It will make big statements more readable :
instead of :
f( a,b, [some very big expression made up of nested class constructors
like a form defintion ], c, d )
write :
f( a, b, @>, c, d ):
[the very big expression goes here]
So, independently of code blocks, this already improves the readability
of big statements.
You could also use named parameters (various proposals):
f( a,b, c=@>, d=@> ):
value of c
value of d
or :
f( a,b, @*> ):
value of c
value of d
f( a,b, @**> ):
c: value of c
d: value of d
Notice how this mimics f( a,b, * ) and f(a,b, ** ) for multiple
arguments, and multiple named arguments. Do you like it ? I do. Especially
the named version whe
Re: pre-PEP: Suite-Based Keywords
How would you write if f(x=1): print "yes" using suite-based keyword args? Good point. Then we should remove the extra ':' at the end of the function invocation : if f(x=@>): value of x print "yes" if f(@**>): x: value of x print "yes" -- http://mail.python.org/mailman/listinfo/python-list
