[RELEASED] Python 3.3.0 alpha 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I'm happy to announce the second alpha release of Python 3.3.0. This is a preview release, and its use is not recommended in production settings. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. Major new features and changes in the 3.3 release series are: * PEP 380, Syntax for Delegating to a Subgenerator (yield from) * PEP 393, Flexible String Representation (doing away with the distinction between wide and narrow Unicode builds) * PEP 409, Suppressing Exception Context * PEP 3151, Reworking the OS and IO exception hierarchy * A C implementation of the decimal module, with up to 80x speedup for decimal-heavy applications * The new packaging module, building upon the distribute and distutils2 projects and deprecating distutils * The new lzma module with LZMA/XZ support * PEP 3155, Qualified name for classes and functions * PEP 414, explicit Unicode literals to help with porting * The new faulthandler module that helps diagnosing crashes * Wrappers for many more POSIX functions in the os and signal modules, as well as other useful functions such as sendfile() * Hash randomization, introduced in earlier bugfix releases, is now switched on by default. For a more extensive list of changes in 3.3.0, see http://docs.python.org/3.3/whatsnew/3.3.html (*) To download Python 3.3.0 visit: http://www.python.org/download/releases/3.3.0/ Please consider trying Python 3.3.0 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! (*) Please note that this document is usually finalized late in the release cycle and therefore may have stubs and missing entries at this point. - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk95PJgACgkQN9GcIYhpnLCN1QCfeYWp+QbPGYhaLSxc4YKnlE/F zU8An2q5qzvjL0qaxqaYleFGoGKPzzJu =qo4v -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
[RELEASED] Python 3.3.0 alpha 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I'm happy to announce the second alpha release of Python 3.3.0. This is a preview release, and its use is not recommended in production settings. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. Major new features and changes in the 3.3 release series are: * PEP 380, Syntax for Delegating to a Subgenerator (yield from) * PEP 393, Flexible String Representation (doing away with the distinction between wide and narrow Unicode builds) * PEP 409, Suppressing Exception Context * PEP 3151, Reworking the OS and IO exception hierarchy * A C implementation of the decimal module, with up to 80x speedup for decimal-heavy applications * The new packaging module, building upon the distribute and distutils2 projects and deprecating distutils * The new lzma module with LZMA/XZ support * PEP 3155, Qualified name for classes and functions * PEP 414, explicit Unicode literals to help with porting * The new faulthandler module that helps diagnosing crashes * Wrappers for many more POSIX functions in the os and signal modules, as well as other useful functions such as sendfile() * Hash randomization, introduced in earlier bugfix releases, is now switched on by default. For a more extensive list of changes in 3.3.0, see http://docs.python.org/3.3/whatsnew/3.3.html (*) To download Python 3.3.0 visit: http://www.python.org/download/releases/3.3.0/ Please consider trying Python 3.3.0 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! (*) Please note that this document is usually finalized late in the release cycle and therefore may have stubs and missing entries at this point. - - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors) - -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk95PJgACgkQN9GcIYhpnLCN1QCfeYWp+QbPGYhaLSxc4YKnlE/F zU8An2q5qzvjL0qaxqaYleFGoGKPzzJu =qo4v - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk95P10ACgkQN9GcIYhpnLBo8QCePW2BuTqXSmtVl6/Yae1HWrGB UFgAn0ytSqd70vq58gj9N8xUtKC+BJ2D =3DA/ -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: Will MySQL ever be supported for Python 3.x?
On 3/31/2012 10:54 PM, Tim Roberts wrote: John Naglena...@animats.com wrote: On 3/30/2012 2:32 PM, Irmen de Jong wrote: Try Oursql instead http://packages.python.org/oursql/ oursql is a new set of MySQL bindings for python 2.4+, including python 3.x Not even close to being compatible with existing code. Every SQL statement has to be rewritten, with the parameters expressed differently. It's a good approach, but very incompatible. Those changes can be automated, given an adequate editor. Oursql is a far better product than the primitive MySQLdb wrapper. It is worth the trouble. It's an interesting approach. As it matures, and a few big sites use it. it will become worth looking at. The emphasis on server-side buffering seems strange. Are there benchmarks indicating this is worth doing? Does it keep transactions locked longer? This bug report https://answers.launchpad.net/oursql/+question/191256 indicates a performance problem. I'd expect server side buffering to slow things down. Usually, you want to drain results out of the server as fast as possible, then close out the command, releasing server resources and locks. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: [RELEASED] Python 3.3.0 alpha 2
To download Python 3.3.0 visit: http://www.python.org/download/releases/3.3.0/ The Windows links point to 3.3a1 installers, even though the links say 3.3a2. -- CPython 3.2.2 | Windows NT 6.1.7601.17640 -- http://mail.python.org/mailman/listinfo/python-list
Re: tabs/spaces
Am 30.03.2012 14:47, schrieb Dave Angel: But since it doesn't do it on all messages, have you also confirmed that it does it for a text message? My experience seems to be that only the html messages are messed up that way. I can't find any HTML in what I posted, so HTML is not the problem. A difference could be the content type. I had in my posting: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Another one titled Pipelining in Python, where TB doesn't mess up the formatting, has: Content-Type: text/plain; charset=ISO-8859-1 Searching the web turned up [1], the gist is that format=flowed means that your mailer is allowed to move linebreaks and quotation signs ( ) as it wants. Which is not what I meant. Some more search turned up [2], which tells us how to disable this. Go to the settings, advanced section and find the button that fires up the raw configuration editor. There, locate the key mailnews.send_plaintext_flowed and change the according value to false. # Checking... if this.worked: hurray(I didn't even have to close the message in writing) Uli [1] http://joeclark.org/ffaq.html [2] http://www.firstpr.com.au/web-mail/Mozilla-mail/ -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
Hi Adrian, see my comments below.
From: Adrian Hunt cybor...@hotmail.com
...
It could break old code... okay you may say you should’nt allow
certain characters but if they're printable and used in a controlled
environment those characters can dramatically increase the security
of a username and password.
What you said makes lots of sense to me.
if strings are interpolated *automatically*.
But it won't and shouldn't.
They are called Dynamic strings.
Dynamic strings can achieve formatting,
but the mechanism under the hood differ
from common strings dramatically.
Many here didn't realize that this is not
another formatting proposal, it is a new
kind of *expression*.
To have it in Python, we will need
a new kind of syntax to distinguish it
from other strings, such as raw strings
and the like. A raw string looks like:
r'my\\ raw str'
'my raw str'
A dynamic string may look like this:
name = Peter #common string
dThank you, $name$! #dynamic string!
'Thank you, Peter!'
The following example would make it feel
a lot more safe (suppose a = raw_input()):
a = 'dAre you $name$?'
print(a)
'dAre you $name$?'
eval('dAre you $name$?')
'Are you Peter?'
dIt contains $len(_.split())$ words!
'It contains 3 words!'
An interesting question might be:
what if a dynamic string is referring
to another dynamic string, which
in turn refers back to the former?
The answer is: no variable can hold
a dynamic string itself, only its result,
which can only be a common string.
However, a infinite recursion may
occur if the eval function is used inside:
a = 'd$eval(a)$'
eval(a)
This is just to show a dynamic string
is really an expression in disguise.
Like evaluating any expression containing
function calls, there is risk of getting into
infinite recursion.
Cheers,
Yingjie
--
http://mail.python.org/mailman/listinfo/python-list
Re: tabs/spaces
On 4/2/2012 3:12 AM, Ulrich Eckhardt wrote: I can't find any HTML in what I posted, so HTML is not the problem. A difference could be the content type. I had in my posting: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Another one titled Pipelining in Python, where TB doesn't mess up the formatting, has: Content-Type: text/plain; charset=ISO-8859-1 Searching the web turned up [1], the gist is that format=flowed means that your mailer is allowed to move linebreaks and quotation signs ( ) as it wants. Which is not what I meant. Some more search turned up [2], which tells us how to disable this. Go to the settings, advanced section and find the button that fires up the raw configuration editor. There, locate the key mailnews.send_plaintext_flowed and change the according value to false. # Checking... if this.worked: hurray(I didn't even have to close the message in writing) Looks great! I never knew about that setting. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
You can already do essentially that without adding a special-case string
formatting method to the general methods we already have.
balls = 5
people = 3
'The {people} people have {balls}
balls.'.format(**locals())
'The 3 people have 5 balls.'
Clearly dynamic strings are much more powerful,
allowing arbitrary expressions inside. It is also
more terse and readable, since we need no dictionary.
I would probably rather liken dynamic expressions
as a little brother of computable documents in
Mathematica. It is a new kind of expression,
rather than formatting -- though it has formatting
connections.
Dynamic strings are mainly useful at time of
writing readable code before compilation.
The compiler can choose to convert it into
a string formatting expression, of course.
To efficiently format strings at runtime,
the best choice (especially
for safty reasons) is string formatting,
not evaluating a dynamic string.
On the implementation, I would suppose new
syntax is needed (though very small).
Yingjie
--
http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
Python already has *3* different built-in string formatting/interpolation systems: ... I would surmise that your key implicitly grab variable values from the enclosing scope feature has previously been rejected for being too magical. It grabs because it is an expression in disguise (not a literal). If we could make that clear in the way we write it, seems the magic level should reduce.to a tolerable (or even likable) level. Cheers, Yingjie -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
On Mon, Apr 2, 2012 at 5:24 PM, Yingjie Lan lany...@yahoo.com wrote: They are called Dynamic strings. Dynamic strings can achieve formatting, but the mechanism under the hood differ from common strings dramatically. Many here didn't realize that this is not another formatting proposal, it is a new kind of *expression*. To have it in Python, we will need a new kind of syntax to distinguish it from other strings, such as raw strings and the like. A raw string looks like: r'my\\ raw str' 'my raw str' A dynamic string may look like this: name = Peter #common string dThank you, $name$! #dynamic string! 'Thank you, Peter!' From the Zen of Python: Special cases aren't special enough to break the rules. It's fairly cheap to propose a new function. If people don't like it, they can ignore it... it can get stuck into a module somewhere and be easily ignored. If people DO like it, they can back-port it to older versions by simply copying and pasting the Python code (or equivalent Python code, if the main version's written in C). New syntax like this has to be implemented in the parser, is (practically) impossible to back-port with pure Python, and has far higher potential to break existing code. The onus is on you to demonstrate that this syntax is worth this hassle. I'm -1 on the idea, mainly because there are already two perfectly good string interpolation syntaxes that don't require a new kind of string. I'm also against the notion of interpolated strings vs non-interpolated strings in general, having worked with them in PHP and not found any real benefit. But if you want it, you could fairly easily do something with an explicit interpolation parsing function: dThank you, $name$! #dynamic string! 'Thank you, Peter!' becomes: d(Thank you, $name$!) #dynamic string! 'Thank you, Peter!' To make the magic of evaluation scope work, though, you'd need to fiddle around with tracebacks. It'd be far simpler and clearer to pass locals() and/or globals() to your function, if indeed you want that. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
Yingjie Lan writes: Clearly dynamic strings are much more powerful, allowing arbitrary expressions inside. It is also more terse and readable, since we need no dictionary. ... On the implementation, I would suppose new syntax is needed (though very small). I don't think you need any new syntax to implement this. You can use a syntax like Dynamite(Hello, $world$) now, similar to fraction.Fraction: Fraction(3,4) + 1 Fraction(7, 4) No special syntax there, yet it can be done. -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
On Mon, 02 Apr 2012 17:52:33 +1000, Chris Angelico wrote:
I'm -1 on the idea, mainly because there are already two perfectly good
string interpolation syntaxes that don't require a new kind of string.
Three.
% formatting
{} formatting
$ formatting using string.Template
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
On Mon, 02 Apr 2012 00:39:42 -0700, Yingjie Lan wrote:
You can already do essentially that without adding a special-case
string
formatting method to the general methods we already have.
balls = 5
people = 3
'The {people} people have {balls}
balls.'.format(**locals())
'The 3 people have 5 balls.'
Clearly dynamic strings are much more powerful, allowing arbitrary
expressions inside.
And so it may be a security risk, if user-input somehow ends up treated
as a dynamic string.
We already have three ways to evaluate arbitrary expressions:
* Python code
* eval
* exec
Why do we need yet another one?
It is also more terse and readable, since we need no
dictionary.
I think you mean terse and unreadable, since we need no dictionary. That
means that variables will be evaluated by magic from... where? Globals?
Local scope? Non-local scope? All of the above?
We already have one way of evaluating implicit variables using implicit
rules, namely regular Python code. Why do we need a second one?
I would probably rather liken dynamic expressions as a little brother of
computable documents in Mathematica. It is a new kind of expression,
rather than formatting -- though it has formatting connections.
Why do we need a new kind of expression?
Dynamic strings are mainly useful at time of writing readable code
before compilation.
What does that mean?
The compiler can choose to convert it into a string
formatting expression, of course. To efficiently format strings at
runtime, the best choice (especially
for safty reasons) is string formatting, not evaluating a dynamic
string.
So you're suggesting that we should have dynamic strings, but not
actually use dynamic strings. The compiler should just convert them to
regular string formatting.
Why not cut out the middle-man and just use regular string formatting?
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
On Mon, Apr 2, 2012 at 6:26 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Mon, 02 Apr 2012 00:39:42 -0700, Yingjie Lan wrote: The compiler can choose to convert it into a string formatting expression, of course. To efficiently format strings at runtime, the best choice (especially for safty reasons) is string formatting, not evaluating a dynamic string. So you're suggesting that we should have dynamic strings, but not actually use dynamic strings. The compiler should just convert them to regular string formatting. Why not cut out the middle-man and just use regular string formatting? Actually, this sounds like a job for a precompiler/preprocessor. Do whatever translations you want on your code, then turn it into a .py file for execution. But hardly necessary, as there are already two - err, three, I stand corrected - perfectly good ways to do it. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Threads on google groups not on gmane?
On 3/31/12 1:47 AM, Mark Lawrence wrote: I went onto google groups to do a search and saw three threads (there may be more) that I've never seen on gmane, which I read via thunderbird on windows. The titles are Is programming art or science, breezypythongui: A New Toolkit for Easy GUIs in Python and weird behaviour: pygame plays in shell but not in script. Is anyone else seeing the same thing? I also don't see these on GMane. It's possible that they are getting caught in one of GMane's several levels of spam filtering. http://gmane.org/spam.php -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
- Original Message -
From: Steven D'Aprano steve+comp.lang.pyt...@pearwood.info
To: python-list@python.org
Cc:
Sent: Monday, April 2, 2012 4:26 PM
Subject: Re: string interpolation for python
On Mon, 02 Apr 2012 00:39:42 -0700, Yingjie Lan wrote:
You can already do essentially that without adding a special-case
string
formatting method to the general methods we already have.
balls = 5
people = 3
'The {people} people have {balls}
balls.'.format(**locals())
'The 3 people have 5 balls.'
Clearly dynamic strings are much more powerful, allowing arbitrary
expressions inside.
And so it may be a security risk, if user-input somehow ends up treated
as a dynamic string.
We already have three ways to evaluate arbitrary expressions:
* Python code
* eval
* exec
Why do we need yet another one?
It is also more terse and readable, since we need no
dictionary.
I think you mean terse and unreadable, since we need no dictionary. That
means that variables will be evaluated by magic from... where? Globals?
Local scope? Non-local scope? All of the above?
We already have one way of evaluating implicit variables using implicit
rules, namely regular Python code. Why do we need a second one?
I would probably rather liken dynamic expressions as a little brother of
computable documents in Mathematica. It is a new kind of expression,
rather than formatting -- though it has formatting connections.
Why do we need a new kind of expression?
Dynamic strings are mainly useful at time of writing readable code
before compilation.
What does that mean?
The compiler can choose to convert it into a string
formatting expression, of course. To efficiently format strings at
runtime, the best choice (especially
for safty reasons) is string formatting, not evaluating a dynamic
string.
So you're suggesting that we should have dynamic strings, but not
actually use dynamic strings. The compiler should just convert them to
regular string formatting.
Why not cut out the middle-man and just use regular string formatting?
I believe non of the other three alternatives are as terse and readable.
We've got template based, formatting with dict, formatting with tuple.
They all require the coder extra effort:
Both template based and dict-based formatting require writing the
identifier three times:
name = 'Peter'
Are you %(name)s%{'name':name}
If dynamic string is used:
Are you $name$?
Template:
Template(Are you $name?).substitute(name=name)
It is three to one in compactness, what a magic 3!
Of course, the old C style way:
Are you %s?%name
Almost as terse, but not as readable, especially
when there are many parts to substitute --
the coder and reader need to be careful
to make sure the sequence is correct.
Why the Python community is so
hostile to new things now?
Python has merits,
but it is far from being perfect.
Cheers,
Yingjie
--
http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
Actually, this sounds like a job for a precompiler/preprocessor. Do whatever translations you want on your code, then turn it into a .py file for execution. But hardly necessary, as there are already two - err, three, I stand corrected - perfectly good ways to do it. Agree and disagree. The other ways are not perfectly good. They stinks in Python. This new way is the most natural way. Effortless, natural. That's my Python. Cheers, Yingjie -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
On Mon, Apr 2, 2012 at 7:11 PM, Yingjie Lan lany...@yahoo.com wrote:
I believe non of the other three alternatives are as terse and readable.
We've got template based, formatting with dict, formatting with tuple.
They all require the coder extra effort:
Both template based and dict-based formatting require writing the
identifier three times:
name = 'Peter'
Are you %(name)s%{'name':name}
If dynamic string is used:
Are you $name$?
Yes, it's more compact. But it's also more magic. However, there's an
alternative that's almost as compact. The only requirement is that you
use a two-character token instead of your dollar sign: a double-quote
and a plus.
Are you +name+?
That allows arbitrary expressions and everything.
Of course, the old C style way:
Are you %s?%name
Almost as terse, but not as readable, especially
when there are many parts to substitute --
the coder and reader need to be careful
to make sure the sequence is correct.
I quite like this notation, personally. It's convenient, and is
supported (with variants) in quite a few C-derived languages (and, in
spite of the massive syntactic differences, Python does have C
heritage).
Why the Python community is so
hostile to new things now?
Python has merits,
but it is far from being perfect.
Hey now, no need to get defensive :) Thing is, it's up to you to
demonstrate that your proposal justifies itself. You're proposing to
create a massive backward-compatibility issue, so you need to prove
that your new way of formatting strings is sufficiently awesome to be
able to say Well, you need Python 3.4+ to use this.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Threads on google groups not on gmane?
Robert Kern robert.k...@gmail.com writes: I also don't see these on GMane. It's possible that they are getting caught in one of GMane's several levels of spam filtering. I'm seeing some weird issues where google groups posts on another newsgroup aren't making it to the non-google nntp server that I use. The paranoid in me wonders if google is doing that on purpose, but it's a pretty recent development, and other explanations are possible. -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
Yingjie Lan lany...@yahoo.com wrote:
Both template based and dict-based formatting require writing the
identifier three times:
name = 'Peter'
Are you %(name)s%{'name':name}
ÿ
If dynamic string is used:
Are you $name$?
Template:
Template(Are you $name?).substitute(name=name)
It is three to one in compactness, what a magic 3!
You can avoid the duplication fairly easily:
name='Peter'
'Are you {name}?'.format(**vars())
'Are you Peter?'
though if you're doing that it would be better to limit the scope to a
specific namespace.
--
Duncan Booth http://kupuguy.blogspot.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
On Mon, Apr 2, 2012 at 2:11 AM, Yingjie Lan lany...@yahoo.com wrote:
snip
I believe non of the other three alternatives are as terse and readable.
We've got template based, formatting with dict, formatting with tuple.
They all require the coder extra effort:
Both template based and dict-based formatting require writing the
identifier three times:
False. Only once is required, though the technique to achieve it is kinda hacky.
name = 'Peter'
Are you %(name)s%{'name':name}
Are you %(name)s % locals() # or vars()
If dynamic string is used:
Are you $name$?
Template:
Template(Are you $name?).substitute(name=name)
Template(Are you $name?).substitute(locals()) # or vars()
It is three to one in compactness, what a magic 3!
snip
Why the Python community is so
hostile to new things now?
It's more conservative than hostile. Here's some insight:
http://www.boredomandlaziness.org/2011/02/status-quo-wins-stalemate.html
Personally, in isolation, the only part of your proposal I find
/truly/ objectionable is the support for arbitrary expressions, since
it would tend towards encouraging suboptimal factoring. But we also
don't live in an ideal world, so the existence of the other 3 (2 of
them particularly relatively similar) alternatives is a legitimate
practical concern when evaluating your proposal. Python is
middle-aged; it's a blessing and a curse.
Cheers,
Chris
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: IDLE can't get out of mainloop
On Sat, 2012-03-31 at 06:29 -0400, Terry Reedy wrote: On 3/31/2012 3:42 AM, Frederic Rentsch wrote: Hi all, Is is a bad idea to develop Tkinter applications in IDLE? I understand that IDLE is itself a Tkinter application, supposedly in a mainloop and mainloops apparently don't nest. In standard configuration, one process runs IDLE, another runs user code, including tkinter code. So there should be no interference. The example in the tkinter doc runs from IDLE edit window on my system. The revised example in coming releases works even better. There have been several IDLE bugs fixed in the last few months, and even more since 2.6 before that. Upgrade if you can to get fixes, suffer the bugs since fixed, or patch your 2.6 installation. -- Terry Jan Reedy Terry, It helps to know that an upgrade might improve things. Thank you for the suggestion. And thanks also to Chris for his remark on .pyc files. Frederic -- http://mail.python.org/mailman/listinfo/python-list
Re: Threads on google groups not on gmane?
On Mon, 02 Apr 2012 03:16:26 -0700, Paul Rubin wrote: Robert Kern robert.k...@gmail.com writes: I also don't see these on GMane. It's possible that they are getting caught in one of GMane's several levels of spam filtering. I'm seeing some weird issues where google groups posts on another newsgroup aren't making it to the non-google nntp server that I use. The paranoid in me wonders if google is doing that on purpose, but it's a pretty recent development, and other explanations are possible. Most likely, other providers are blocking google groups as a known source of spam. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
Are you +name+? That allows arbitrary expressions and everything. To make that work for any type, you need: Are you + str(name) + ? Another concern is performance. You are absolutely right, they are equivalent in that both are expressions. As long as people start to realize that dynamic strings are expressions, there is no magic in it any more. And allowing expressions in those dynamic strings would make sense since they are of the same sort. dsin($x$) = $ sin(x):0.3f $ is equivalent to the expression of sin(%s%x + )= %0.3f%sin(x) Comparing th e two, I would say the latter is more computer friendly while the former, more human friendly. If the computed result is only to be used in formatting the string, it would be nice to save an assignment stmt. Almost as terse, but not as readable, especially when there are many parts to substitute -- the coder and reader need to be careful to make sure the sequence is correct. I quite like this notation, personally. It's convenient, and is supported (with variants) in quite a few C-derived languages (and, in spite of the massive syntactic differences, Python does have C heritage). Sure, once you get used to it, it would be harder to stop it the harder it is :). That's part of human nature, anyway. Why the Python community is so hostile to new things now? Python has merits, but it is far from being perfect. Hey now, no need to get defensive :) Thing is, it's up to you to demonstrate that your proposal justifies itself. You're proposing to create a massive backward-compatibility issue, so you need to prove that your new way of formatting strings is sufficiently awesome to be able to say Well, you need Python 3.4+ to use this. OK. I have put it out as is. I trust people knows good things. I would simply say: this new way is much more simple and much more powerful. And there is no security issues as long as you don't use the evil eval to evaluate expressions, which is always a security issue. It is new, and has no compatibility issues with old ways at all. In syntax, all you need is to allow d..., which clearly won't affect any old ways of business. Cheers, Yingjie -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
On Mon, 02 Apr 2012 02:11:46 -0700, Yingjie Lan wrote:
Both template based and dict-based formatting require writing the
identifier three times:
name = 'Peter'
Are you %(name)s%{'name':name}
They don't *require* this at all.
Are you %s % name
For trivial examples, you have trivial syntax. For more complex examples,
you have a more powerful system: % can accept *any* dictionary, so you
aren't limited to just pre-existing variables.
That, by the way, is perhaps the biggest problem with this idea of
dynamic strings: not that it is too powerful, but that it is TOO WEAK. It
can only retrieve names from a single namespace, and the programmer has
no control over which namespace that will be. The only way to feed named
values into the dynamic string is by creating variables.
With existing formatting systems, the programmer has complete control
over what names get used. You can set up a series of separate namespaces
and choose between them as needed:
a = dict(name=Fred, job=butcher)
b = dict(name=Sue, job=SAS sharp-shooter)
c = dict(name=Mary, job=brain surgeon)
d = dict(name=Tony, job=enforcer for the Russian mob)
for namespace in (a, b, c, d):
print (%(name)s works as a %(job)s. % namespace)
Using your dynamic strings:
for namespace in (a, b, c, d):
name = namespace[name]
job = namespace[job]
print ($name$ works as a $job$.)
and it has the side-effect that it has created some variables that are no
longer needed.
Also notice that because you have to create variables first, the dynamic
string actually requires you to write the identifier MORE times, not
fewer.
So your proposal is actually weaker than what Python already has. So why
bother? All this does is add more things to learn, more complexity in the
compiler and parser, for what? Things that you can already do.
If dynamic string is used:
Are you $name$?
And where does name come from? It's all too magical. With the existing
format strings, the programmer has *complete* control of where it comes
from:
Are you %(name)s? % locals() # from a local variable `name`
Are you %(name)s? % globals() # from a global variable `name`
Are you %(name)s? % namespace # from any namespace you like
and similar for both format() and Template.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
Are you %(name)s % locals() # or vars() This partly solves the problem, however, you can't work with expressions inside, like: dsin($x$) = $sin(x)$ Also, what if locals() or vars() does not contain the variable x? (x could be nonlocal or global). It's more conservative than hostile. Here's some insight: http://www.boredomandlaziness.org/2011/02/status-quo-wins-stalemate.html You are probably right...Harmless enhancement is still probable? Personally, in isolation, the only part of your proposal I find /truly/ objectionable is the support for arbitrary expressions, since it would tend towards encouraging suboptimal factoring. But we also I don't quite see that as a problem. The compiler (or translator, as you mentioned earlier) could easily make dsin($x$) = $sin(x)$ into something like: ''.join([sin(, str(x), ) = , str(sin(x))] which would far more efficient than calling the format() method. Cheers, Yingjie -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
... That, by the way, is perhaps the biggest problem with this idea of dynamic strings: not that it is too powerful, but that it is TOO WEAK. ... and similar for both format() and Template. Seems you miss understood my notion of dynamic string. Dynamic strings are expressions in disguise: the things in between $...$ are plain old expressions (with optional formatting specifications). They are evaluated as if they were outside the dynamic string. We put them in there to to kill two birds with one stone: 1) ease of reading; 2) place holding. Cheers, Yingjie -- http://mail.python.org/mailman/listinfo/python-list
I look for a package to make some simple console form
Hi, I look for a package to make some console form. It's a standard stuff, I think there are a package to do that. Example : What is your name ? Select your lang [EN, FR, DE…] ? Do you want … [Y, N] ? Type of field : * textline * select choice * boolean question Thank for your help, Stéphane -- Stéphane Klein steph...@harobed.org blog: http://stephane-klein.info Twitter: http://twitter.com/klein_stephane pro: http://www.is-webdesign.com -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
Seems you miss understood my notion of dynamic string.
Dynamic strings are expressions in disguise: the things
in between $...$ are plain old expressions (with optional
formatting specifications). They are evaluated
as if they were outside the dynamic string. We put them
in there to to kill two birds with one stone:
1) ease of reading;
2) place holding.
like this one ?
b = dict(name=Sue, job=SAS sharp-shooter)
print $b['name']$ works as b['job']
Is it really easier to read that the following ?
{0} works as {1}.format(b['name'],b['job'])
In the case in which b is an object having job and name attribute,
the dynamic string will write
$b.name$ works as $b.job$
instead of
{0}.name works as {0}.job.format(b)
Laurent
--
http://mail.python.org/mailman/listinfo/python-list
Re: I look for a package to make some simple console form
Stéphane Klein wrote: Hi, I look for a package to make some console form. It's a standard stuff, I think there are a package to do that. Example : What is your name ? Select your lang [EN, FR, DE…] ? Do you want … [Y, N] ? Type of field : * textline * select choice * boolean question Thank for your help, Stéphane Hi, Have a look at http://excess.org/urwid/ JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Tools for refactoring/obfuscation
Well, a .pyc file would be a too blatant obfuscation, and people at my job would get angry. I need something more subtle. So I need a refactoring tool, preferably with which I can do scripting. These is what I found up to now in the CheeseShop: http://pypi.python.org/pypi/bicyclerepair/0.7.1 http://pypi.python.org/pypi/rope/0.9.3 I need to check how to do scripting with them. There seems to be no manual for them. This code also looks interesting, but in its present state it is for blatant obfuscation, although it could be changed to do some refactoring: http://pypi.python.org/pypi/pyfuscate/0.1 Lie Ryan lie.1...@gmail.com wrote: On 03/29/2012 03:04 AM, Javier wrote: Yes, in general I follow clear guidelines for writing code. I just use modules with functions in the same directory and clear use of name spaces. I almost never use classes. I wonder if you use some tool for refactoring. I am mainly intersted in scripting tools, no eclipse-style guis. Just let me know if you use some scripting tool. And, as somebody pointed in this thread obfuscating or refactoring the code are very different things but they can be done with the same tools. trollif you're not using classes, your code is obfuscated already/troll Anyway, I think it's better if you describe why you want such a tool. If you want to keep your code a secret, just distribute the .pyc file. If you want to refactor your code to improve readability, there is rope. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonect 0.1.0 Release
Itzik Kotler wrote: Hi All, I'm pleased to announce the first beta release of Pythonect interpreter. Pythonect is a new, experimental, general-purpose dataflow programming language based on Python. It aims to combine the intuitive feel of shell scripting (and all of its perks like implicit parallelism) with the flexibility and agility of Python. Pythonect interpreter (and reference implementation) is written in Python, and is available under the BSD license. Here's a quick tour of Pythonect: The canonical Hello, world example program in Pythonect: Hello World - print MainProcess:Thread-1 : Hello World Hello World '-' and '|' are both Pythonect operators. The pipe operator (i.e. '|') passes one item at a item, while the other operator passes all items at once. Python statements and other None-returning function are acting as a pass-through: Hello World - print - print MainProcess:Thread-2 : Hello World MainProcess:Thread-2 : Hello World Hello World 1 - import math - math.log 0.0 Parallelization in Pythonect: Hello World - [ print , print ] MainProcess:Thread-4 : Hello World MainProcess:Thread-5 : Hello World ['Hello World', 'Hello World'] range(0,3) - import math - math.sqrt [0.0, 1.0, 1.4142135623730951] In the future, I am planning on adding support for multi-processing, and even distributed computing. The '_' identifier allow access to current item: Hello World - [ print , print ] - _ + and Python MainProcess:Thread-7 : Hello World MainProcess:Thread-8 : Hello World ['Hello World and Python', 'Hello World and Python'] [ 1 , 2 ] - _**_ [1, 4] True/False return values as filters: Hello World - _ == Hello World - print MainProcess:Thread-9 : Hello World Hello World - _ == Hello World1 - print False range(1,10) - _ % 2 == 0 [2, 4, 6, 8] Last but not least, I have also added extra syntax for making remote procedure call easy: 1 - inc@xmlrpc://localhost:8000 - print MainProcess:Thread-2 : 2 2 Download Pythonect v0.1.0 from: http://github.com/downloads/ikotler/pythonect/Pythonect-0.1.0.tar.gz More information can be found at: http://www.pythonect.org I will appreciate any input / feedback that you can give me. Also, for those interested in working on the project, I'm actively interested in welcoming and supporting both new developers and new users. Feel free to contact me. Regards, Itzik Kotler | http://www.ikotler.org It should be renamed Perlonect :) JM -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
like this one ?
b = dict(name=Sue, job=SAS sharp-shooter)
print $b['name']$ works as b['job']
Is it really easier to read that the following ?
{0} works as {1}.format(b['name'],b['job'])
In the case in which b is an object having job and name
attribute, the dynamic string will write
$b.name$ works as $b.job$
instead of
{0}.name works as {0}.job.format(b)
When you already have a dict, the dict-based
formatting would be nice.
%(name)s works as %(job)s%b
If it you need to create a dict just for string
formatting, dynamic string would be nice.
Say your object has methods/properties
that fetch things from your database.
class staff:
...@property
...def name(): return 'Peter'
...
t = staff()
vars(t)
{}
t.name
'Peter'
dStaff name: $t.name$ #note the d... format
'Staff name: Peter'
Because of the d... format, it won't
affect old ways of doing things one bit.
Allowing dynamic string wouldn't hurt
a bit to anything that is already there.
--
http://mail.python.org/mailman/listinfo/python-list
Re: I look for a package to make some simple console form
Le 02/04/2012 15:54, Jean-Michel Pichavant a écrit : Stéphane Klein wrote: Hi, I look for a package to make some console form. It's a standard stuff, I think there are a package to do that. Example : What is your name ? Select your lang [EN, FR, DE…] ? Do you want … [Y, N] ? Type of field : * textline * select choice * boolean question Thank for your help, Stéphane Hi, Have a look at http://excess.org/urwid/ No, I don't look for high level feature based on ncurse… I would like very low level feature, form like sphinx quick start or modern-package-template… Regards, Stephane -- Stéphane Klein steph...@harobed.org blog: http://stephane-klein.info Twitter: http://twitter.com/klein_stephane pro: http://www.is-webdesign.com -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
Yingjie Lan wrote: Seems you miss understood my notion of dynamic string. Dynamic strings are expressions in disguise: the things in between $...$ are plain old expressions (with optional formatting specifications). They are evaluated as if they were outside the dynamic string. In that case you should re-think the delimiters, so that you have something that can be nested. An example (example only, I'm not in love with it as a final form): A string that gets %(count*spacer%) in the middle A string that gets %(count*%(spacer%)%) in the middle Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: I look for a package to make some simple console form
On 2012-04-02, St?phane Klein steph...@harobed.org wrote: Le 02/04/2012 15:54, Jean-Michel Pichavant a ?crit : St?phane Klein wrote: I look for a package to make some console form. It's a standard stuff, I think there are a package to do that. Example : What is your name ? Select your lang [EN, FR, DE?] ? Do you want ? [Y, N] ? Type of field : * textline * select choice * boolean question Have a look at http://excess.org/urwid/ No, I don't look for high level feature based on ncurse? For something simpler, your two best options are dialog and newt: http://pythondialog.sourceforge.net/ https://en.wikipedia.org/wiki/Newt_%28programming_library%29 https://hurley.wordpress.com/2008/01/25/create-simple-ansi-based-ui-with-python-newt/ http://www.wanware.com/tsgdocs/snack.html I'm rather partial to newt since it was intended from day 1 for use with Python. It was written by RedHat many, many years ago for use in their console-mode-installer (which was written in Python). But, the docs are pretty sparse, and it's not very active these days. I would like very low level feature, form like sphinx quick start or modern-package-template? Sorry, no clue what those are... -- Grant Edwards grant.b.edwardsYow! Did I do an INCORRECT at THING?? gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: I look for a package to make some simple console form
Stéphane Klein wrote:
Le 02/04/2012 15:54, Jean-Michel Pichavant a écrit :
Stéphane Klein wrote:
Hi,
I look for a package to make some console form.
It's a standard stuff, I think there are a package to do that.
Example :
What is your name ?
Select your lang [EN, FR, DE…] ?
Do you want … [Y, N] ?
Type of field :
* textline
* select choice
* boolean question
Thank for your help,
Stéphane
Hi,
Have a look at
http://excess.org/urwid/
No, I don't look for high level feature based on ncurse…
I would like very low level feature, form like sphinx quick start or
modern-package-template…
Regards,
Stephane
Don't know if there is such package. There's nothing that rawinput
cannot handle in what you're asking for.
Anyway since you refered to sphinx, it does not use any package, look at
quickstar.py, you may reuse their do_prompt.
And because being lazy is cool :
from sphinx import quickstart
d = {}
quickstart.do_prompt(d, 'foo', 'enter the foo value', '5', lambda x: int(x))
print d
{'foo': 8}
JM
--
http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
On Mon, Apr 2, 2012 at 9:46 PM, Yingjie Lan lany...@yahoo.com wrote:
Are you +name+?
That allows arbitrary expressions and everything.
To make that work for any type, you need:
Are you + str(name) + ?
Another concern is performance.
You are absolutely right, they are
equivalent in that both are expressions.
Right, meaning that both have the same issues of performance, need for
str(), etc. There's absolutely no difference.
As long as people start to realize that
dynamic strings are expressions,
there is no magic in it any more.
And no benefit. You lose out on syntax highlighting in your editor and
gain nothing.
And allowing expressions in those
dynamic strings would make sense
since they are of the same sort.
dsin($x$) = $ sin(x):0.3f $
is equivalent to the expression of
sin(%s%x + )= %0.3f%sin(x)
Comparing th e two, I would say the latter
is more computer friendly while
the former, more human friendly.
The former is more magical, the second is more explicit. Computers do
tend to like the explicit, but I wouldn't assume that humans like the
magical *necessarily*. There are times when we prefer the explicit,
too.
Sure, once you get used to it, it would be harder to stop it
the harder it is :). That's part of human nature, anyway.
Maybe. But it (percent-notation) is expressive and insanely powerful.
Moreover, it obeys the rule that you pay for the complexity you use,
no more and no less. (Although I think there's one lack in Python's
implementation - I can't find a way to use an argument more than once,
without switching to dictionary mode and using keys for everything.
I can't, for instance, use Hello hello, %s %[0]s!%name to use the
name twice. But since that isn't in the original C implementation,
it's hardly mandatory.)
Some implementations go even further than Python's does and allow an
array notation.
sprintf(UPDATE tablename SET modified=now()%{,%s=:%[0]s%} WHERE
key=%d,array_of_field_names,primary_key_value)
-- UPDATE tablename SET modified=now(),foo=:foo,bar=:bar,quux=:quux
WHERE key=1234
You're still paying for no complexity you aren't actually using. It's
clear and readable.
I would simply say: this new way is much more simple
and much more powerful. And there is no security issues
as long as you don't use the evil eval to evaluate expressions,
which is always a security issue.
It's powerful only if you use eval to allow full expression syntax.
Otherwise, what does it have above str.format()?
It is new, and has no compatibility issues with old ways at all.
In syntax, all you need is to allow d..., which clearly won't
affect any old ways of business.
You may well be able to get past the compatibility issues. I'm not yet
convinced that the new syntax is worth it, but it may be possible.
Here's a recommendation: Write a parser for your notation that turns
it into executable Python code (that is, executable in Python 3.3
without any d... support). Since a dynamic string is really an
expression in disguise, it doesn't need to be translated at run time,
and in fact is best translated at compile time. It wouldn't be hard to
make the precompiler as per your equivalency above; and since you can
use %s%123 without raising TypeError, you don't even have to figure
out data types. With that written, the Python community can more
adequately evaluate your proposal, and even start making use of it and
getting a feel for the new syntax. If it catches on, someone'll
probably invite you to write a PEP or something; if it doesn't, well,
you still have it on your own version, and you don't have to worry
about upgrades (your precompiler/patch should be able to slide up to
a new version easily).
I'm still against the idea personally, mainly because it's nothing but
a more magical way of doing what we already can do, but there may well
be many who disagree.
Chris Angelico
--
http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
mwil...@the-wire.com wrote: Yingjie Lan wrote: Seems you miss understood my notion of dynamic string. Dynamic strings are expressions in disguise: the things in between $...$ are plain old expressions (with optional formatting specifications). They are evaluated as if they were outside the dynamic string. In that case you should re-think the delimiters, so that you have something that can be nested. An example (example only, I'm not in love with it as a final form): A string that gets %(count*spacer%) in the middle A string that gets %(count*%(spacer%)%) in the middle A less than great example, I guess. Maybe A string that gets %(count*-%(spacer%)-%) in the middle Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
Right, meaning that both have the same issues
of performance, need for
str(), etc. There's absolutely no difference.
OK, performance. Here is a new solution:
Suppose we have a new string method
str.format_join([...])
taking a list of strings and objects,
with even-indexed ones being strings,
odd-indexed ones being objects.
Each even-indexed string *ends* with a formatting
specification for the next object in the list.
Then we can have:
dsin($x$) = $ sin(x):0.3f $
get translated to:
''.format_join([sin(%s,x,) = %0.3f, sin(x)])
This seems to be at least as good in performance.
And no benefit. You lose out on syntax highlighting
in your editor and gain nothing.
Gain: readability, terseness, hassle-free, and possibly
better performance if done right.
Syntax highlighting: can be done more creatively.
For dynamic strings, string parts are like normal
strings, but the embedded expressions are like
normal expressions :)
sprintf(UPDATE tablename SET modified=now()%{,%s=:%[0]s%} WHERE
key=%d,array_of_field_names,primary_key_value)
-- UPDATE tablename SET modified=now(),foo=:foo,bar=:bar,quux=:quux
WHERE key=1234
You're still paying for no complexity you aren't actually using.
It's clear and readable.
You are really good at that. Maybe not everybody is as
experience as you, and I suppose the learning curve is
kind of hard to climb.
It's powerful only if you use eval to allow full expression syntax.
Otherwise, what does it have above str.format()?
Those expressions are embedded, you don't need eval()
to have the result though. Are we on the same page?
You may well be able to get past the compatibility issues. I'm not yet
convinced that the new syntax is worth it, but it may be possible.
Here's a recommendation: Write a parser for your notation that turns
it into executable Python code (that is, executable in Python 3.3
without any d... support).
You mean a translator?
The syntax is essential for compatibility.
We must distinguish dynamic strings from common strings.
They will live peacefully together.
(escaping the '$' in normal strings breaks compatibility,
and the consequence of forgetting to escape could be
disastrous, so definitely not an option).
May be d is too tiny, $... is easier to pick out.
Cheers,
Yingjie
--
http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
In that case you should re-think the delimiters, so that you have something that can be nested. An example (example only, I'm not in love with it as a final form): Haven't really thought about that. Nesting is a big issue if in the embedded expression, there is another dynamic string expression. For example (the first '%' immediately preceding the first quote denotes the start of a dynamic string expression):: first_name, family_name = Peter, Johns %Hi $ first_name+%, $family_name$ $! 'Hi Peter, Johns!' However, nesting is really cluttering things up and we should forbid it without loosing power: The above example can be done without nesting: %Hi $ first_name$, $family_name$! 'Hi Peter, Johns!' Can you offer an example where nesting is better or necessary? Cheers, Yingjie -- http://mail.python.org/mailman/listinfo/python-list
Re: [RELEASED] Python 3.3.0 alpha 2
In article 4f794c1a.7020...@gmail.com, Andrew Berg bahamutzero8...@gmail.com wrote: To download Python 3.3.0 visit: http://www.python.org/download/releases/3.3.0/ The Windows links point to 3.3a1 installers, even though the links say 3.3a2. Thanks for the heads up. The links have now been updated to point to the 3.3a2 files. -- Ned Deily, n...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
On Tue, 03 Apr 2012 00:58:38 +1000, Chris Angelico wrote:
Maybe. But it (percent-notation) is expressive and insanely powerful.
Moreover, it obeys the rule that you pay for the complexity you use, no
more and no less. (Although I think there's one lack in Python's
implementation - I can't find a way to use an argument more than once,
without switching to dictionary mode and using keys for everything. I
can't, for instance, use Hello hello, %s %[0]s!%name to use the name
twice. But since that isn't in the original C implementation, it's
hardly mandatory.)
Ack.
In this case, you can use format:
Hello {0}, what's up with {1}? Hey, {0} I'm speaking to you!.format
('George', 'Melissa')
Hello George, what's up with Melissa? Hey, George I'm speaking to you!
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: I look for a package to make some simple console form
Le 02/04/2012 16:52, Jean-Michel Pichavant a écrit :
Stéphane Klein wrote:
Le 02/04/2012 15:54, Jean-Michel Pichavant a écrit :
Stéphane Klein wrote:
Hi,
I look for a package to make some console form.
It's a standard stuff, I think there are a package to do that.
Example :
What is your name ?
Select your lang [EN, FR, DE…] ?
Do you want … [Y, N] ?
Type of field :
* textline
* select choice
* boolean question
Thank for your help,
Stéphane
Hi,
Have a look at
http://excess.org/urwid/
No, I don't look for high level feature based on ncurse…
I would like very low level feature, form like sphinx quick start or
modern-package-template…
Regards,
Stephane
Don't know if there is such package. There's nothing that rawinput
cannot handle in what you're asking for.
Anyway since you refered to sphinx, it does not use any package, look at
quickstar.py, you may reuse their do_prompt.
And because being lazy is cool :
from sphinx import quickstart
d = {}
quickstart.do_prompt(d, 'foo', 'enter the foo value', '5', lambda x:
int(x))
print d
{'foo': 8}
Yes, quickstart.do_prompt is a good starting point :
https://bitbucket.org/birkenfeld/sphinx/src/164f59b2d946/sphinx/quickstart.py
--
Stéphane Klein cont...@stephane-klein.info
blog: http://stephane-klein.info
Twitter: http://twitter.com/klein_stephane
pro: http://www.is-webdesign.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
Tim Rowe wrote: On 22 March 2012 19:14, Chris Angelico ros...@gmail.com wrote: In any case, though, I agree that there's a lot of people professionally writing code who would know about the 3-4 that you say. I'm just not sure that they're any good at coding, even in those few languages. All the best people I've ever known have had experience with quite a lot of languages. I know 10 languages. But I'm not telling you what base that number is :) There are 10 types of people in the world: those who know binary and those who don't. ;) ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: I look for a package to make some simple console form
You might look into formencode. It basically takes the philosophy that a form is nothing more and nothing less than an interface between user input and python data. It doesn't make assumptions about how you present the form to the user. It just handles validation and conversion of that data into useful python objects, and from python objects to displayable values. http://www.formencode.org/en/latest/Validator.html Might be what you're looking for. Cheers, Cliff On Mon, 2012-04-02 at 14:55 +0200, Stéphane Klein wrote: Hi, I look for a package to make some console form. It's a standard stuff, I think there are a package to do that. Example : What is your name ? Select your lang [EN, FR, DE…] ? Do you want … [Y, N] ? Type of field : * textline * select choice * boolean question Thank for your help, Stéphane -- Stéphane Klein steph...@harobed.org blog: http://stephane-klein.info Twitter: http://twitter.com/klein_stephane pro: http://www.is-webdesign.com -- http://mail.python.org/mailman/listinfo/python-list
Python Script Works Locally But Not Remotely with SSH
Hi,
I have a WinXP PC running an SSH server and I have a Linux PC with an
SSH client and logged into the XP seemingly OK. It's all on my
personal LAN, the connection seems OK.
I have a py file on the XP that I run via SSH from the Linux, it's:
import webbrowser
webbrowser.open('www.google.com')
This runs OK started on the local XP PC, the browser Firefox opens and
goes to the site, or it opens a tab to the site. But executing that
same file via SSH does not open Firefox...doing it via SSH starts
Firefox ( I see it begin in the process manager and I see web
activity) but Firefox does not open it's window.
Why the does the window not open when the script is started remotely?
Thanks.
--
http://mail.python.org/mailman/listinfo/python-list
Online SharePoint 2010 training sessions for end users with 12 Hours and $415 per person from 6th April 2012
Greetings, Techies Platform’s training programs are essential to anyone in Information Management. With Techies Platform, you will experience rich content and an environment that is interesting, up-to-date, and engaging. Our instructors, materials, and in lab sessions are there to help build on your determination and drive to succeed. When you partner with Techies Platform, you’ll find that our training program meets and exceeds your expectations. You can visit our website www.techiesplatform.com and check out on the wide training curriculum we offer. We are happy to answer any questions you may have about our firm. We are launching our Online SharePoint 2010 training sessions for end users with 12 Hours and $415 per person from 6th April 2012. We present our training sessions as an on-site offering at your work location or home. We can customize this training program to suit your precise training needs. Feel free to contact us any time on the following email. i...@techiesplatform.com emi...@techiesplatform.com Regards, Emiley Bradley Training Coordinator Techies Platform emi...@techiesplatform.com www.techiesplatform.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way to structure data for efficient searching
On Mar 28, 1:52 pm, Jon Clements jon...@googlemail.com wrote: On Wednesday, 28 March 2012 19:39:54 UTC+1, larry@gmail.com wrote: I have the following use case: I have a set of data that is contains 3 fields, K1, K2 and a timestamp. There are duplicates in the data set, and they all have to processed. Then I have another set of data with 4 fields: K3, K4, K5, and a timestamp. There are also duplicates in that data set, and they also all have to be processed. I need to find all the items in the second data set where K1==K3 and K2==K4 and the 2 timestamps are within 20 seconds of each other. I have this working, but the way I did it seems very inefficient - I simply put the data in 2 arrays (as tuples) and then walked through the entire second data set once for each item in the first data set, looking for matches. Is there a better, more efficient way I could have done this? It might not be more *efficient* but others might find it more readable, and it'd be easier to change later. Try an in-memory SQL DB (such as sqlite3) and query as (untested) select t2.* from t1 join t2 on k1=k3 and k2=k4 where abs(t1.timestamp - t2.timestamp) 20 This is part of django app, and the data came from mysql. Through a mechanism I can't change at this time (it would take a lot of code changes and this new functionality is needed ASAP) I get all the data at once and have to winnow it down. Failing that, two (default)dicts with a tuple as the pair, then use that as your base. Since there are duplicates, I can't use a dict. And if I have any extraneous data in the keys (i.e. something to make them unique) then I still have to walk through the entire dict to find the matches. -- http://mail.python.org/mailman/listinfo/python-list
Best way to structure data for efficient searching
I have the following use case: I have a set of data that is contains 3 fields, K1, K2 and a timestamp. There are duplicates in the data set, and they all have to processed. Then I have another set of data with 4 fields: K3, K4, K5, and a timestamp. There are also duplicates in that data set, and they also all have to be processed. I need to find all the items in the second data set where K1==K3 and K2==K4 and the 2 timestamps are within 20 seconds of each other. I have this working, but the way I did it seems very inefficient - I simply put the data in 2 arrays (as tuples) and then walked through the entire second data set once for each item in the first data set, looking for matches. Is there a better, more efficient way I could have done this? -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way to structure data for efficient searching
On Wednesday, 28 March 2012 19:39:54 UTC+1, larry@gmail.com wrote: I have the following use case: I have a set of data that is contains 3 fields, K1, K2 and a timestamp. There are duplicates in the data set, and they all have to processed. Then I have another set of data with 4 fields: K3, K4, K5, and a timestamp. There are also duplicates in that data set, and they also all have to be processed. I need to find all the items in the second data set where K1==K3 and K2==K4 and the 2 timestamps are within 20 seconds of each other. I have this working, but the way I did it seems very inefficient - I simply put the data in 2 arrays (as tuples) and then walked through the entire second data set once for each item in the first data set, looking for matches. Is there a better, more efficient way I could have done this? It might not be more *efficient* but others might find it more readable, and it'd be easier to change later. Try an in-memory SQL DB (such as sqlite3) and query as (untested) select t2.* from t1 join t2 on k1=k3 and k2=k4 where abs(t1.timestamp - t2.timestamp) 20 Failing that, two (default)dicts with a tuple as the pair, then use that as your base. Jon. -- http://mail.python.org/mailman/listinfo/python-list
No os.copy()? Why not?
I'm looking for a Python (2.7) equivalent to the Unix cp command. Since the equivalents of rm and mkdir are in the os module, I figured I look there. I haven't found anything in the documentation. I am also looking through the Python source code in os.py and its child, posixfile.py. Any help? Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: weird behaviour: pygame plays in shell but not in script
I can't believe I am so dumb! after sound.play() the script was terminating I didn't notice that 'play()' actually returns... What a nice way to introduce myself to the group!!! :-) sorry for bothering you guys :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: unittest: assertRaises() with an instance instead of a type
On Mar 28, 6:55 pm, Ben Finney ben+pyt...@benfinney.id.au wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
(By the way, I have to question the design of an exception with error
codes. That seems pretty poor design to me. Normally the exception *type*
acts as equivalent to an error code.)
Have a look at Python's built-in OSError. The various errors from the
operating system can only be distinguished by the numeric code the OS
returns, so that's what to test on in one's unit tests.
To the extent that numeric error codes are poor design (see Steven's
comment) but part of the language (see Ben's comment), it may be
worthwhile to consider a pattern like below.
Let's say you have a function like save_config, where you know that
permissions might be an issue on some systems, but you don't want to
take any action (leave that to the callers). In those cases, it might
be worthwhile to test for the specific error code (13), but then
translate it to a more domain-specific exception. This way, all your
callers can trap for a much more specific exception than OSError.
Writing the test code for save_config still presents some of the
issues that the OP alluded to, but then other parts of the system can
be tested with simple assertRaises().
import os
class ConfigPermissionError:
pass
def save_config(config):
try:
dir = os.mkdir('/config')
except OSError, e:
if e[0] == 13:
raise ConfigPermissionError()
else:
raise
fn = os.path.join(dir, 'config.txt')
f = open(fn, 'w')
# and so on...
try:
save_config({'port': 500})
except ConfigPermissionError:
# do some workaround here
print 'Config not saved due to permissions'
--
http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
On Mar 29, 7:03 am, Chris Angelico ros...@gmail.com wrote: On Fri, Mar 30, 2012 at 12:44 AM, Nathan Rice nathan.alexander.r...@gmail.com wrote: We would be better off if all the time that was spent on learning syntax, memorizing library organization and becoming proficient with new tools was spent learning the mathematics, logic and engineering sciences. Those solve problems, languages are just representations. Different languages are good at different things. REXX is an efficient text parser and command executor. Pike allows live updates of running code. Python promotes rapid development and simplicity. PHP makes it easy to add small amounts of scripting to otherwise-static HTML pages. C gives you all the power of assembly language with all the readability of... assembly language. SQL describes a database request. You can't merge all of them without making a language that's suboptimal at most of those tasks - probably, one that's woeful at all of them. I agree with you on the overall point, but I think that Python actually does a fine job of replacing REXX and PHP. I've used both of the latter (and, of course, Python). REXX and PHP are great at what they do, but I don't think their slight advantages over Python justify all the weight they carry--incompatible syntax to Python, archaic libraries, missing modern language features, etc. It's great to have languages like C and HTML that carve out their own strong niches. No argument there. On the other hand, if you know Python, then having to contend with the learning curves and idiosyncrasies of Perl and Ruby might feel more frustrating than empowering. Like REXX and PHP, Perl and Ruby arguably have corners where they are more expressive than Python, but I'd rather have a boring system written in 100% Python than a Ruby/ Python hybrid. Python should also be a perfectly good superset of Bash Scripting language. (To the extent that Python isn't, there's nothing intrinsic about the language that prevents you from orchestrating processes.) I mention SQL because, even if you were to unify all programming languages, you'd still need other non-application languages to get the job done. Here I absolutely agree with you. SQL, to me, is a perfect illustration of a language that's optimal for a particular task. Of course, people still can't resist hiding it behind an ORM. The web stack is notorious for requiring multilingual juggling. HTML, CSS, JS, Python, and SQL are easy enough to juggle, but then you might also get template languages (with all the interpolation escaping), config files (XML, YAML, etc.), regexes (possibly multiple dialects), SQL, testing DSLs (ugh, Cucumber and friends), etc. Keep the diversity and let each language focus on what it's best at. ChrisA who has lots and lots of hammers, so every problem looks like... lots and lots of nails. I know you're just joking here, because you're obviously not advocating for multiple hammers. You're advocating for multiple tools in the toolbox. Which is good, of course. I think the problem these days is that the programmer's brain is like a small toolbox. Maybe twenty tools fit in the toolbox. Instead of filling it up with 20 useful tools, a lot of us have it cluttered up with ten hammers, when only one of the hammers is what we need for the nails. -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way to structure data for efficient searching
Larry.Mart wrote:
Since there are duplicates, I can't use a dict. And if I have any
extraneous data in the keys (i.e. something to make them unique) then
I still have to walk through the entire dict to find the matches.
You can use slightly different approach. With double mapping you could
simplify the lookup. What I mean?
Get the first set and build lookup map as:
MAP := {
KEY1-VALUE : {
KEY2-VALUE : [SET, SET, n-th duplicate SET]
}
}
In the worst case you would have quadratic complexity of the
algorithm. Otherwise the lookup would be really fast.
--
http://mail.python.org/mailman/listinfo/python-list
ANN: Leo 4.10 final released
Leo 4.10 final is now available at: http://sourceforge.net/projects/leo/files/Leo/4.10%20final/ Leo is a text editor, data organizer, project manager and much more. http://webpages.charter.net/edreamleo/intro.html Leo 4.10 contains 9 months of intense work on Leo. Several very important features are subtle; you could almost call them Easter Eggs, so please read the following notes carefully. The highlights of Leo 4.10: -- * Dozens of new and improved features and commands, including... - Tab completion now shows all @command @button nodes. - Leo tabs may be detached from the main window. - The Open With menu now works. - The leoInspect module answers questions about Python code. - Leo can highlight the pane containing the focus. - The bigdash plugin searches across multiple files. - Improved abbreviation capabilities. - Improved handling of URL's. - Improved editing of non-Leo files. - Improvements create weightless unit testing. - Improved Leo's home page. * Easier installation on MacOS. * Fixed almost 70 bugs. The Easter Eggs --- 1. Tab completion now shows all @command @button nodes. Put all your common scripts in @command nodes in myLeoSettings.leo. Typing Alt-X@cTab will remind you of the names of these scripts. You can execute the scripts by name without the @command- prefix. 2. Improved abbreviation capabilities. Virtually any kind of abbreviation is possible. For example, ~a to ã. 3. Improved handling of URL's. URL's can be used as links to other Leo outlines. 4 Weightless unit testing. The mantra is edit, alt-4 (run-marked-unit-tests-externally), edit, alt-4,... Several seemingly innocuous changes made this work without friction. The result is a remarkable increase in productivity. Links: -- Leo: http://webpages.charter.net/edreamleo/front.html Forum:http://groups.google.com/group/leo-editor Download: http://sourceforge.net/projects/leo/files/Leo/4.10%20final/ Bzr: http://code.launchpad.net/leo-editor/ Quotes: http://webpages.charter.net/edreamleo/testimonials.html Edward K. Ream -- Edward K. Ream email: edream...@gmail.com Leo: http://webpages.charter.net/edreamleo/front.html -- -- http://mail.python.org/mailman/listinfo/python-list
help with subclassing problem
I am attempting to subclass the date class from the datetime package. Basically I want a subclass that can take the date as a string (in multiple formats), parse the string and derive the year,month and day information to create a date instance i.e. class MyDate(datetime.date): def __init__(self, the_date): # magic happens here to derives year, month and day from the_date datetime.date.__init__(self, year, month, day) But no matter what I do, when I attempt to create an instance of the new class, I get the error message: Traceback (most recent call last): File stdin, line 1, in module TypeError: Required argument 'year' (pos 1) not found I have even created a class which doesn't include the argument I want to use but with default arguments i.e. class MyDate (datetime.date): def __init__(self, year = 1, month = 1, day = 1): datetime.date.__init__(self, year, month, day) and get the same error message. What am I doing wrong here? Thanks for any help, Peter -- http://mail.python.org/mailman/listinfo/python-list
Is Programing Art or Science?
the refreshen of the blood, from Xah's Entertainment Enterprise, i bring you: 〈Is Programing Art or Science〉 http://xahlee.org/UnixResource_dir/writ/art_or_science.html penned in the year of our lord two thousand and two, plain text version follows. Is Programing Art or Science? Dear friends, You mentioned the title of Donald Knuth's magnum opus Art of Programming in the context of discussion that fringes on whether programing is science or art. I'm quite pissed off at work at the moment, so let me take the time to give some guide on this matter to the daily programers. At the bottom rung of programers, there's no question about whether programing is science or art. Because monkey coders could not care less. These folks ain't be reading this post, for they hardly will have heard of lisp. This leaves us with elite programers who have a smattering of interests on cogitation and philosophical conundrums. So, is programing a science or art? For the programing morons, this question is associated with erudition. It certainly is a hip subject among hackers such as those hardcore Perl advocates and unix proponents, who would casually hint on such realization, impressing a sophistication among peers. Such a question is not uncommon among those curious. For example, “Is mathematics science or art?”, is the same type of question that has been broached by dabblers now and then. We can also detect such dilemma in the titles conferred to blathering computer jockeys: which one are thee: baccalaureate of science or baccalaureate of arts? It really makes no fucking difference. Ultimately, fantastically stupid questions like these are not discussed by mathematicians nor philosophers. These are natural language side-effects, trapping dummies to fuzz about nothing; not unlike quotations. For these computing jockeys, there remains the question of why Knuth named his books the “Art” of Computer Programing, or why some computing luminaries litter the caution that programing is as much a art as science. What elite dimwits need to realize is that these authors are not defining or correcting, but breaking precepts among the automatons in programing industry. To the readers of hip literature, words like science and art are spellbinding, and the need to pigeonhole is imminent. Of these ruminating class of people, the problem lies in their wanting of originality. What fills their banal brain are the stale food of thought that has been chewed and spewed. These above-average eggheads mop up the scholastic tidbits of its day to mull and muse with fellow eggheads. They could not see new perspectives. Could not understand gists. Could not detect non-questions. They are the holder and passer of knowledge, a bucket of pre-digested purees. Their train of thought forever loops around established tracks — going nowhere, anytime! So, is programing a art or science? is it art or science? I really need to know. • Theory vs Practice • Jargons of IT Industry • The Lambda Logo Tour • English Lawers PS don't forget to checkout: 〈From Why Not Ruby to Fuck Python, Hello Ruby〉 @ http://xahlee.org/UnixResource_dir/writ/why_not_Ruby.html yours humbly, Xah -- http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
On Mar 29, 11:53 am, Devin Jeanpierre jeanpierr...@gmail.com wrote: Well, what sort of language differences make for English vs Mandarin? Relational algebraic-style programming is useful, but definitely a large language barrier to people that don't know any SQL. I think this is reasonable. (It would not matter even if you gave SQL python-like syntax, the mode of thinking is different, and for a good reason.) I don't see any fundamental disconnect between SQL thinking and Python thinking. List comprehensions are very close to SQL SELECTs semantically, and not that far off syntactically. [row.x for row in foo if x == 3] select x from foo where x = 3 Many people can grok the basics of relational algebraic style programming quite easily, which is why SQL is so popular. It just happens that many programming languages up until now have obscured the idea. SQL is so strongly associated with RDBMS implementations that people tend to forget that it makes sense as an abstract language--people tend to view SQL as a very concrete mechanism for pulling data out of storage, instead of as a notation for describing the relating and transforming of sets. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Script Works Locally But Not Remotely with SSH
Hi,
You can try using ssh -X xxx.xxx.xxx.xxx for GUI ssh connection.
Thanks,
Anoop Thomas Mathew
atm
___
Life is short, Live it hard.
On 28 March 2012 06:21, goldtech goldt...@worldpost.com wrote:
Hi,
I have a WinXP PC running an SSH server and I have a Linux PC with an
SSH client and logged into the XP seemingly OK. It's all on my
personal LAN, the connection seems OK.
I have a py file on the XP that I run via SSH from the Linux, it's:
import webbrowser
webbrowser.open('www.google.com')
This runs OK started on the local XP PC, the browser Firefox opens and
goes to the site, or it opens a tab to the site. But executing that
same file via SSH does not open Firefox...doing it via SSH starts
Firefox ( I see it begin in the process manager and I see web
activity) but Firefox does not open it's window.
Why the does the window not open when the script is started remotely?
Thanks.
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: help with subclassing problem
On Thursday, 29 March 2012 21:23:20 UTC+1, Peter wrote: I am attempting to subclass the date class from the datetime package. Basically I want a subclass that can take the date as a string (in multiple formats), parse the string and derive the year,month and day information to create a date instance i.e. class MyDate(datetime.date): def __init__(self, the_date): # magic happens here to derives year, month and day from the_date datetime.date.__init__(self, year, month, day) But no matter what I do, when I attempt to create an instance of the new class, I get the error message: Traceback (most recent call last): File stdin, line 1, in module TypeError: Required argument 'year' (pos 1) not found I have even created a class which doesn't include the argument I want to use but with default arguments i.e. class MyDate (datetime.date): def __init__(self, year = 1, month = 1, day = 1): datetime.date.__init__(self, year, month, day) and get the same error message. What am I doing wrong here? Thanks for any help, Peter Details here: http://stackoverflow.com/questions/399022/why-cant-i-subclass-datetime-date Jon. -- http://mail.python.org/mailman/listinfo/python-list
weird behaviour: pygame plays in shell but not in script
Dear all, I am a bit frustrated by the following as I believe it is something silly that I am not able to see. I am using python 2.7.1+ under ubuntu. When I run the following script as in $python script.py I do not get any sound out of it BUT if I run every line in the python shell it works great. It doesn't make sense to me, maybe someone has a clue? Thanks for any clue! Mik import pygame #done twice to get rid of a sound card error pygame.mixer.init() pygame.mixer.init() pygame.mixer.pre_init(44100, -16, 2, 2048) pygame.init() # called twice to make it so that it detects sound card pygame.init() print init sounds = [] sounds.append(pygame.mixer.Sound(../audio/song01.wav)) sounds.append(pygame.mixer.Sound(../audio/song02.wav)) sounds.append(pygame.mixer.Sound(../audio/song03.wav)) sounds.append(pygame.mixer.Sound(../audio/song04.wav)) for sound in sounds: print .. sound.play() -- http://mail.python.org/mailman/listinfo/python-list
How do I use PyGTK to put text besides clickable buttons?
I've decided to use PyGTK instead of gtkdialog for providing configuration menus/dialog boxes in Swift Linux, the Linux distro I started. The problem with gtkdialog is that the i386 version is no longer available in the Debian repository. Since a picture is worth a thousand words, I'll give you a link to a screenshot of antiX Linux: http://antix.freeforums.org/download/file.php?id=23 How do I use PyGTK to create something similar to the logout dialog box in the above graphic? I've figured out how to create clickable buttons that each run a different script. What I haven't figured out is how to add text beside each button. -- http://mail.python.org/mailman/listinfo/python-list
Re: weird behaviour: pygame plays in shell but not in script
On Mar 29, 10:41 pm, Mik mikp...@gmail.com wrote: What a nice way to introduce myself to the group!!! :-) Hey, don't beat yourself up, you: - summarised the problem in the subject heading - included actual code showing the problem - reported back on the problem you found That puts you ahead of most new posters. sorry for bothering you guys :-) No bother at all, welcome to the party :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Mar 29, 9:38 pm, Nathan Rice nathan.alexander.r...@gmail.com wrote: The mathematics of the 20th century, (from the early 30s onward) tend to get VERY abstract, in just the way Joel decries. Category theory, model theory, modern algebraic geometry, topos theory, algebraic graph theory, abstract algebras and topological complexes are all very difficult to understand because they seem so incredibly abstract, yet most of them already have important applications. I'm 100% positive if you just presented Joel with seminal papers in some of those areas, he would apply the astronaut rubber stamp, because the material is challenging, and he wouldn't get it (I love math, and I've had to read some papers 10+ times before they click). Nathan, Don't worry too much about Joel Spolsky, and worry even less about people that allude to him. Joel Spolksy is an early 21st century businessman. He's a smart guy with decent writing skills and semi-interesting thoughts, but he's not gonna change the world. He runs his business by promoting pragmatic processes, writing blogs, procuring comfortable chairs for developers, renting nice loft space in NYC, and building some useful, but basically unoriginal, websites and apps. Everything that Joel Spolsky has ever said in his blog has already been put into practice 100 times over by a bunch of similarly pragmatic early 21st century folk. If you really like math, it is no surprise that you find the current state of computer programming a bit inelegant. 90% of what programmers do in the early 21st century is move the data from HERE to THERE, then another 9% is placing the data in just the right part of the screen. I'm exaggerating a bit, but we're still in the backwaters. It's all engineering now; it's all breeding the faster horse. Or so it seems. There's a natural ebb and flow to progress. In the early to mid 20th century, there were tremendous advances in math, science, and technology, and maybe it's gonna take a full century or two of playing around with shit and arguing about stupid shit until the dust finally settles and we make another quantum jump. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Mar 30, 9:02 pm, Steve Howell showel...@yahoo.com wrote: Steven, how do you predict which abstractions are going to be useless? There was a time when imaginary numbers were just little toys that the mathematicians played around with in their ivory towers. A non-science/math analogous question: When Beethoven wrote his last sonatas and quartets they were called 'the abortions of a German idealist' or less charitably the only music that a stone-deaf man could possibly write Likewise, Bach's wrote Art of Fugue was regarded as a merely academic work that codified his knowledge of fugal writing. It was many decades after their death that everyone began to regard these as the greatest pieces of music (maybe 50 for Beethoven, almost 100 for Bach). However for every one Bach/Beethoven there are 100s of fadists who are great in one generation and garbage-dumped the next. The encyclopedia of music I grew up on regarded Schoenberg et al in the Bach/Beethoven category. Almost certainly a more recent view would not. So if I side with Steven/Spolsky I would regard a (future) Bach/ Beethoven as an 'abortion.' If I side with Nathan I may waste my money and life betting on serialists/cubists and such fashionable but ephemeral fads. tl;dr version The usefulness of uber-abstractions is undecidable in the near timeframe. -- http://mail.python.org/mailman/listinfo/python-list
Re: weird behaviour: pygame plays in shell but not in script
Oh thanks alex! that's kind! PS: It looks like a party indeed: plenty of interesting discussions :-) On Mar 30, 4:33 am, alex23 wuwe...@gmail.com wrote: On Mar 29, 10:41 pm, Mik mikp...@gmail.com wrote: What a nice way to introduce myself to the group!!! :-) Hey, don't beat yourself up, you: - summarised the problem in the subject heading - included actual code showing the problem - reported back on the problem you found That puts you ahead of most new posters. sorry for bothering you guys :-) No bother at all, welcome to the party :) -- http://mail.python.org/mailman/listinfo/python-list
Re: No os.copy()? Why not?
On Mar 28, 9:50 pm, alex23 wuwe...@gmail.com wrote: On Mar 29, 6:12 am, John Ladasky john_lada...@sbcglobal.net wrote: I'm looking for a Python (2.7) equivalent to the Unix cp command. Any help? Thanks. Try the shutil module:http://docs.python.org/library/shutil.html Many thanks! That's what I was looking for. -- http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
On Mar 29, 9:42 am, Devin Jeanpierre jeanpierr...@gmail.com wrote: On Thu, Mar 29, 2012 at 10:03 AM, Chris Angelico ros...@gmail.com wrote: You can't merge all of them without making a language that's suboptimal at most of those tasks - probably, one that's woeful at all of them. I mention SQL because, even if you were to unify all programming languages, you'd still need other non-application languages to get the job done. Not really. You can turn SQL (or something equivalent) into a subset of your programming language, like C# does with LINQ, or like Scheme does with macros. I'm glad your moving the discussion away from the fake debate between diversity (good) and one-language-fits-all (horribly naive at best, evil at worse). Of course, there's a middle ground, where (some degree of) language unification is a completely sane goal, at least worthy of discussion. SQL is a well-established lingua franca for describing relationships between sets, or relational algebra. General-purpose languages like C#, Scheme, and Python are well suited to subsuming SQL semantics, and, in fact, they already do, but sometimes they do it a way that's unnecessarily foreign to people who quite easily grok the basics of SQL. The extreme position for language unification would be that Python completely subsumes SQL under its umbrella as first-class syntax. I don't necessarily advocate for that, but I think it's an interesting thought experiment to ask why it doesn't. Just to be clear, I'm talking about SQL as a mechanism to transform sets within Python itself, not external RDMBS engines (although first-class SQL integration could also be useful for that as well). On the other hand, even similar languages are really hard to run in the same VM: imagine the hoops you'd have to jump through to get libraries written in Python 2 and 3 to work together. My take on Python 2 vs. Python 3 is that it's simply a tactical program to get people to upgrade to Python 3. The fact that the two languages can't run on the same VM doesn't really bother me. With that in mind, the interesting languages to merge aren't things like SQL or regular expressions -- these are so easy to make work with programming languages, that we do it all the time already (via string manipulation, but first-class syntax would also be easily possible). The hard problems are when trying to merge in the semantics of languages that only make sense because they have drastically different expectations of the world. The example that comes to mind is Haskell, which relies incredibly strongly on the lack of side effects. How do you merge Haskell and Python? My view on Haskell and Python is that they should stay alive as competing paradigms. I think you're making a useful distinction between Haskell and SQL. Neither language is well integrated with Python. With Haskell, I think it's for good reason. With SQL, I don't quite understand the status quo (beyond the obvious reasons-- maybe we're just not there yet). I guess what I really want to say is that the world looks, to me, to be more optimistic than so many people think it is. If we wanted to, we could absolutely take the best features from a bunch of things. This is what C++ does, this is what Scheme does, this is what D does. They sometimes do it in different ways, they have varying tradeoffs, but this isn't a hard problem except when it is, and the examples you mentioned are actually the easy cases. We can merge Python and C, while keeping roughly the power of both, it's called Cython. I love the fact that C dominates all other languages at its level of abstraction. I wish this were the case one level up, where you still have Python, Ruby, JavaScript, PHP, Perl, and others essentially solving the same classes of problems. Don't get me wrong--I'm all for diversity; I'm not saying we should arbitrarily kill off languages, etc. I'm just saying that there will be *some* benefit when a clear victor emerges, and hopefully that will be Python 3. Whatever language emerges as the victor, it will probably subsume some of the best features of the conquered. To a degree that has already happened. We can merge Python and PHP, in that PHP adds nothing incompatible with Python technically (it'd be a lot of work and there would be many tears shed because it's insane) -- but Python Server Pages probably add the feature you want. PHP is a language that I wish would die off quickly and gracefully. I feel like the good things of PHP have already been subsumed into the ecosystems of stronger programming languages (including Python). We could merge SQL and Python, arguably we already do via e.g. SQLAlchemy's query API (etc.) or DBAPI2's string API. These can all becomes subsets of a language that interoperate well with the rest of the language with no problems. These are non-issues: the reasons for not doing so are not technical, they are political or sociological (e.g., bloat
Re: Is Programing Art or Science?
Programming is neither an art nor a science, but a trade. It's not an art in the sense of painting, music, dance, poetry, etc., because the objective isn't to make a beautiful something, but to give instructions to a machine to accomplish some useful task. It's not a science in the sense of either physics and chemistry (experimental) or geology or astronomy (observational) or cosmology or psychology (theoretical) because the objective isn't to test hypothetical s against data, but to give instructions to a machine to accomplish some useful task. Obviously, it's very much connected with art (e.g., user interface design) and science (e.g., artificial intelligence) but the practice of giving instructions to a machine is more like assembling machines in a factory than the pursuit of an art or the practice of a science. CC. -- http://mail.python.org/mailman/listinfo/python-list
breezypythongui: A New Toolkit for Easy GUIs in Python
breezypythongui is an open source toolkit that enables the Python programmer to learn realistic GUI programming quickly and easily. For free source code, demo programs, and a tutorial, visit http://home.wlu.edu/~lambertk/breezypythongui/index.html. Brought to you by Ken Lambert, the author of Fundamentals of Python: First Programs. -- http://mail.python.org/mailman/listinfo/python-list
Re: weird behaviour: pygame plays in shell but not in script
On Mar 30, 8:33 am, alex23 wuwe...@gmail.com wrote: On Mar 29, 10:41 pm, Mik mikp...@gmail.com wrote: What a nice way to introduce myself to the group!!! :-) Hey, don't beat yourself up, you: - summarised the problem in the subject heading - included actual code showing the problem - reported back on the problem you found That puts you ahead of most new posters. Well said. I only disagree with the 'new' wink -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Mar 29, 8:36 pm, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: The Romans had perfectly functioning concrete without any abstract understanding of chemistry. If I ever stumbled upon a technology that proved how useless abstract thinking was, do you know what I would call it? Concrete. Damn, those clever Romans beat me to it by a couple millennia! And they had AQUEDUCTS!!! [...] Medicine and pharmaceuticals continue to be discovered even when we can't predict the properties of molecules. I know this is really, really far out, and I should probably come back down to earth, but I can envision some sort of 25th century utopia where scientists measure the weights and charges and atoms, and arrange them into some kind of chart, and just BASED ON THE CHART ALONE, these 25th century scientists might be able to predict behaviors that have never been observed, just BASED ON ABSTRACT REASONING. Whoa! That's really far out stuff. Give me some oxygen! (preferably of the 1s2 2s2 2p4 variety) (Yep, I get it, the periodic table is about atoms, and medicine/ pharmaceuticals are about molecules, so your point is not invalid. It's still alchemy, though.) -- http://mail.python.org/mailman/listinfo/python-list
Problem connecting to SMTP/IMAP server using SSL
Hi, I'm able to connect to an Exchange server via SMTP and IMAP from my iPhone using SSL and without using a VPN. So I would expect to be able to do the same from my computer using Python. However, the following hangs and times out on my computer when I'm not connected to the VPN: import imaplib imap = imaplib.IMAP4_SSL(my.server.address) If I am connected to the VPN, then it works fine. Do you know why it won't work with SSL and without the VPN? Am I missing something? Thanks a lot, Julien -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Mar 30, 1:20 pm, Chris Angelico ros...@gmail.com wrote: Really? Or could it be that algorithms for natural language processing that don't fail miserably is a very recent development, restricted natural languages more recent still, and pretty much all commonly used programming languages are all ~20+ years old? Could it also be that most programmers don't see a lot of incentives to make things accessible, since they're already invested in the status quo, and they might lose some personal value if programming stopped being an arcane practice? Totally. That's why we're all still programming in assembly language and doing our own memory management, because we would lose a lot of personal value if programming stopped being so difficult. If it weren't for all these silly new-fangled languages with their automatic garbage collection and higher order function handling, we would all be commanding much higher salaries. While I don't subscribe to the conspiracy theory that programmers invest in arcane practices to preserve personal value [paraphrase of Nathan], surely you could come up with a better argument than garbage collection. Garbage collection was invented over 50 years ago (1959, according to Wikipedia), and it was implemented in a whole bunch of popular programming languages in the 90s (and earlier too, if you count Smalltalk as a popular language). Python's over 20 years old, and it had garbage collection pretty early on. Java's not quite 20 years old, but if Java is your best example of a new-fangled language with automatic garbage collection, then I have a hard time appreciating your sarcastic comments. There hasn't been much progress in programming language design in the last 20 years. It's been incremental at best. Nobody's really thinking outside the box, as far as I can tell. Please prove me wrong. It's true that we've moved past assembly language. -- http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
On Mar 30, 4:37 am, Devin Jeanpierre jeanpierr...@gmail.com wrote: On Thu, Mar 29, 2012 at 3:50 PM, Nathan Rice nathan.alexander.r...@gmail.com wrote: Well, a lisp-like language. I would also argue that if you are using macros to do anything, the thing you are trying to do should classify as not natural in lisp :) You would run into disagreement. Some people feel that the lisp philosophy is precisely that of extending the language to do anything you want, in the most natural way. At least, I disagree, but my lisp thoughts are the result of indoctrination of the Racket crowd. I guess Paul Graham would likewise disagree. See 7,8,9 in http://paulgraham.com/diff.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
On Mar 31, 1:13 pm, Tim Rowe digi...@gmail.com wrote: I know 10 languages. But I'm not telling you what base that number is :) Well, that means you know at least two programming languages, which puts you ahead of a lot of people. :) obligatory joke Some folks, when confronted with a problem, decide to solve it with binary numbers. And then they have 10 problems. /try the fish -- http://mail.python.org/mailman/listinfo/python-list
Python-URL! - weekly Python news and links (Mar 31)
I pine for the fjords. And it's time to bring Python-URL! to a close. Python-URL!, which Jean-Claude Wippler and I appear to have launched in 1998, has reached the end of its utility. We still have many loyal and enthusiastic readers--one subscription request arrived within the last day, in fact--and certainly much writing turns up every week that *deserves* the spotlight Python-URL! has shone in the past. However, the Python world has changed a great deal over the last fourteen years. There are many, MANY other ways for those with an interest in Python to nourish themselves, and Python itself has grown and normalized so much that it no longer fits particularly well in the Python-URL! format. Enjoy Mouse vs. Python URL: http://www.blog.pythonlibrary.org/ , the Python areas of DZone, Reddit, developerWorks, stackoverflow, and so on. For your reference, I append below the most-recent-but-not- particularly- current version of Python-URL!'s coda of related readings. That is all. Everything Python-related you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org Notice especially the master FAQ http://www.python.org/doc/FAQ.html Just beginning with Python? This page is a great place to start: http://wiki.python.org/moin/BeginnersGuide/Programmers Planet Python: you want to visit there: http://planet.python.org But don't confuse it with Planet SciPy: http://planet.scipy.org And don't confuse *that* with SciPyTip, a high-quality daily (!) tip for the numerically-inclined: http://twitter.com/SciPyTip Python Insider is the official blog of the Python core development team: http://pyfound.blogspot.com/2011/03/python-dev-launches-python-insider -blog.html The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donations/ Keep up with the PSF at Python Software Foundation News: http://pyfound.blogspot.com The Python Papers aims to publish the efforts of Python enthusiasts: http://pythonpapers.org/ Doug Hellman's Module of the week is essential reading: http://www.doughellmann.com/PyMOTW/ comp.lang.python.announce announces new Python software. Be sure to scan this newsgroup weekly. http://groups.google.com/group/comp.lang.python.announce/topics Python411 indexes podcasts ... to help people learn Python ... Updates appear more-than-weekly: http://www.awaretek.com/python/index.html The Python Package Index catalogues packages. http://www.python.org/pypi/ Much of Python's real work takes place on Special-Interest Group mailing lists http://www.python.org/sigs/ Python Success Stories--from air-traffic control to on-line match-making--can inspire you or decision-makers to whom you're subject with a vision of what the language makes practical. http://www.pythonology.com/success The Summary of Python Tracker Issues is an automatically generated report summarizing new bugs, closed ones, and patch submissions. http://search.gmane.org/?author=status%40bugs.python.orggroup=gmane.c omp.python.develsort=date nullege is an interesting search Web application, with the intelligence to distinguish between Python code and comments. It provides what appear to be relevant results, and demands neither Java nor CSS be enabled: http://www.nullege.com Although unmaintained since 2002, the Cetus collection of Python hyperlinks retains a few gems. http://www.cetus-links.org/oo_python.html The Cookbook is a collaborative effort to capture useful and interesting recipes: http://code.activestate.com/recipes/langs/python/ Many Python conferences around the world are in preparation. Watch this space for links to them. Among several Python-oriented RSS/RDF feeds available, see: http://www.python.org/channews.rdf For more, see: http://www.syndic8.com/feedlist.php?ShowMatch=pythonShowStatus=all The old Python To-Do List now lives principally in a SourceForge reincarnation. http://sourceforge.net/tracker/?atid=355470group_id=5470func=browse http://www.python.org/dev/peps/pep-0042/ del.icio.us presents an intriguing approach to reference commentary. It already aggregates quite a bit of Python intelligence. http://del.icio.us/tag/python At least one of the Python magazines is explicitly multilingual: http://www.python.org/ar/
Python-URL! - weekly Python news and links (Mar 31)
I pine for the fjords. And it's time to bring Python-URL! to a close. Python-URL!, which Jean-Claude Wippler and I appear to have launched in 1998, has reached the end of its utility. We still have many loyal and enthusiastic readers--one subscription request arrived within the last day, in fact--and certainly much writing turns up every week that *deserves* the spotlight Python-URL! has shone in the past. However, the Python world has changed a great deal over the last fourteen years. There are many, MANY other ways for those with an interest in Python to nourish themselves, and Python itself has grown and normalized so much that it no longer fits particularly well in the Python-URL! format. Enjoy Mouse vs. Python URL: http://www.blog.pythonlibrary.org/ , the Python areas of DZone, Reddit, developerWorks, stackoverflow, and so on. For your reference, I append below the most-recent-but-not- particularly- current version of Python-URL!'s coda of related readings. That is all. Everything Python-related you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org Notice especially the master FAQ http://www.python.org/doc/FAQ.html Just beginning with Python? This page is a great place to start: http://wiki.python.org/moin/BeginnersGuide/Programmers Planet Python: you want to visit there: http://planet.python.org But don't confuse it with Planet SciPy: http://planet.scipy.org And don't confuse *that* with SciPyTip, a high-quality daily (!) tip for the numerically-inclined: http://twitter.com/SciPyTip Python Insider is the official blog of the Python core development team: http://pyfound.blogspot.com/2011/03/python-dev-launches-python-insider -blog.html The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donations/ Keep up with the PSF at Python Software Foundation News: http://pyfound.blogspot.com The Python Papers aims to publish the efforts of Python enthusiasts: http://pythonpapers.org/ Doug Hellman's Module of the week is essential reading: http://www.doughellmann.com/PyMOTW/ comp.lang.python.announce announces new Python software. Be sure to scan this newsgroup weekly. http://groups.google.com/group/comp.lang.python.announce/topics Python411 indexes podcasts ... to help people learn Python ... Updates appear more-than-weekly: http://www.awaretek.com/python/index.html The Python Package Index catalogues packages. http://www.python.org/pypi/ Much of Python's real work takes place on Special-Interest Group mailing lists http://www.python.org/sigs/ Python Success Stories--from air-traffic control to on-line match-making--can inspire you or decision-makers to whom you're subject with a vision of what the language makes practical. http://www.pythonology.com/success The Summary of Python Tracker Issues is an automatically generated report summarizing new bugs, closed ones, and patch submissions. http://search.gmane.org/?author=status%40bugs.python.orggroup=gmane.c omp.python.develsort=date nullege is an interesting search Web application, with the intelligence to distinguish between Python code and comments. It provides what appear to be relevant results, and demands neither Java nor CSS be enabled: http://www.nullege.com Although unmaintained since 2002, the Cetus collection of Python hyperlinks retains a few gems. http://www.cetus-links.org/oo_python.html The Cookbook is a collaborative effort to capture useful and interesting recipes: http://code.activestate.com/recipes/langs/python/ Many Python conferences around the world are in preparation. Watch this space for links to them. Among several Python-oriented RSS/RDF feeds available, see: http://www.python.org/channews.rdf For more, see: http://www.syndic8.com/feedlist.php?ShowMatch=pythonShowStatus=all The old Python To-Do List now lives principally in a SourceForge reincarnation. http://sourceforge.net/tracker/?atid=355470group_id=5470func=browse http://www.python.org/dev/peps/pep-0042/ del.icio.us presents an intriguing approach to reference commentary. It already aggregates quite a bit of Python intelligence. http://del.icio.us/tag/python At least one of the Python magazines is explicitly multilingual: http://www.python.org/ar/
Re: Python is readable
On Mar 31, 2:02 am, Steve Howell showel...@yahoo.com wrote: Steven, how do you predict which abstractions are going to be useless? A useless abstraction is one that does nothing to simplify a problem *now*: being so fixated on over-arching abstract concepts that, far from those abstractions making it easier to solve the problems they are being paid to solve, they actually make them harder An abstraction is also useless if it's so clever that it isn't readily understandable to an average developer; architecture astronauts don't tend to be big on sticking around to provide ongoing support. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Mar 30, 11:25 pm, Lie Ryan lie.1...@gmail.com wrote: On 03/21/2012 01:44 PM, Steve Howell wrote: Also, don't they call those thingies object for a reason? ;) A subject is (almost?) always a noun, and so a subject is also an object. It's true that words that can act as a subject can also act like objects in other sentences. That doesn't really answer my question, though. Why do we call programming objects objects instead of calling them subjects or nouns? -- http://mail.python.org/mailman/listinfo/python-list
Nature of Heavenly Bodies
THE QUR'AN AND MODERN SCIENCE Extracted from the Book The Bible, The Qur'an and Science Maurice Bucaille Nature of Heavenly Bodies THE SUN AND THE MOON The Sun is a shine (diya') and the Moon a light (nur). This translation would appear to be more correct than those given by others, where the two terms are inverted. In fact there is little difference in meaning since diya' belongs to a root (daw') which, according to Kazimirski's authoritative Arabic/French dictionary, means 'to be bright, to shine' (e.g. like a fire). The same author attributes to the substantive in question the meaning of 'light'. The difference between Sun and Moon will be made clearer by further quotes from the Qur'an. - Surah 25, verse 61: Blessed is the One Who placed the constellations in heaven and placed therein a lamp and a moon giving light - Surah 71, verses 15-16: Did you see how God created seven heavens one above another and made the moon a light therein and made the sun a lamp? - Surah 78, verses 12-13: We have built above you seven strong (heavens) and placed a blazing lamp The blazing lamp is quite obviously the sun. Here the Moon is defined as a body that gives light (munir) from the same root as nur (the light applied to the Moon). The Sun however is compared to a torch (siraj) or a blazing (wahhaj) lamp. A man of Muhammad's time could easily distinguish between the Sun, a blazing heavenly body well knows to the inhabitants of the desert, and the Moon, the body of the cool of the night. The comparisons found in the Qur'an on this subject are therefore quite normal. What is interesting to note here is the sober quality of the comparisons, and the absence in the text of the Qur'an of any elements of comparison that might have prevailed at the time and which in our day would appear as phantasmagoric. It is known that the Sun is a star that generates intense heat and light by its internal combustion, and that the Moon, which does not give off light itself, merely reflects the light received from the Sun, constituting an inert body (on its external layers at least). There is nothing in the text of the Qur'an that contradicts what we know today about these two celestial bodies. THE STARS As we know, the stars are heavenly bodies like the Sun. They are the scene of various physical phenomena of which the easiest to observe is their generation of light. They are heavenly bodies that produce their own light. The word 'star' appears thirteen times in the Qur'an (najm, plural nujum); it comes from a root meaning to appear, to come into sight. The word designates a visible heavenly body without saying of what kind, i.e. either generator of light or mere reflector of light received. To make it clear that the object so designated is a star, a qualifying phrase is added as in the following Surah: - Surah 86, verses 1-3: By the sky and the Night-Visitor, who will tell thee what the Night- Visitor is, the Star of piercing brightness The evening star is qualified in the Qur'an by the word thakib meaning 'that which pierces through something' (here the night shadows). The same word is moreover used to designate shooting stars (Surah 37, verse 10): the latter are the result of combustion. It is difficult to say whether these are referred to in the Qur'an with the same exact meaning that is given to the heavenly bodies in the present day. PLANETS It is difficult to say that planets are mentioned in the Qur. an with the specific meaning we give today to these heavenly bodies. The planets do have their own light. They revolve around the Sun, Earth being one of them. While one may presume that others exist elsewhere, the only ones known are those in the solar system. Five planets other than Earth were known to the ancients: Mercury, Venus, Mars, Jupiter and Saturn. Three have been discovered in recent times: Uranus, Neptune and Pluto. The Qur'an would seem to designate these by the word kaukab (plural kawakib) without stating their number. Joseph's dream (Surah 12) refers to eleven of them, but the description is, by definition, an imaginary one. A good definition of the meaning of the word kaukab in the Qur'an seems to have been given in a very famous verse. The eminently spiritual nature of its deeper meaning stands forth, and is moreover the subject of much debate among experts in exegesis. It is nevertheless of great interest to offer an account of the comparison it contains on the subject of the word that would seem to designate a 'planet'. Here is the text in question: (Surah 24, verse 35) God is the light of the heavens and the earth. The similitude of His light is as if there were a niche and within it a luminary. The luminary is in a glass. The glass is as if it were a planet glittering like a pearl Here the subject is the projection of light onto a body that reflects it (glass) and gives it the glitter of a pearl, like a planet that is lit by the sun. This is the only explanatory
M2Crypto.SSL.Checker.NoCertificate Exception
I have a weird quirk with the M2Crypto module and I hope someone would be able
to point me in the right direction. I am working with a colleague to develop
an internal tool to check SSL certificates on a list of IPv4 addresses obtained
via stdin.
We are using M2Crypto to help with validating the certificates. If we only
have it check one IPv4 address, it is able to provide us with the correct
certificate and we are able to do our validation checks on the information that
the SSL certificate contains.
However, if we try to check multiple IPv4 addresses we receive the
M2Crypto.SSL.Checker.NoCertificate. There are some cases where we should be
receiving this. However, regardless of what the second or third IPv4 address
is (even if it tested good as the first one), it will fail.
Context creation:
global context
context = M2Crypto.SSL.Context()
if sys.platform.startswith('linux'):
context.load_verify_info(capath=/etc/ssl/certs/) #Linux with
real open SSL installed
elif sys.platform.startswith('darwin'):
context.load_verify_info(cafile=certfile)
else:
print Unknown platform, bail!
exit(1)
context.set_allow_unknown_ca(True)
context.set_verify(M2Crypto.SSL.verify_none,9)
Socket creation:
conn = M2Crypto.SSL.Connection(context)
socket.setdefaulttimeout(2.0)
conn.set_socket_read_timeout(M2Crypto.SSL.timeout(sec=2))
conn.set_socket_write_timeout(M2Crypto.SSL.timeout(sec=2))
try:
conn.connect((ip,443))
The above two portions of code exist in their own functions. The latter block
gets called as part of the loop over the array of addresses. The IP is passed
from the caller.
Thank you in advance!
-Tim
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Apr 1, 8:30 pm, alex23 wuwe...@gmail.com wrote: On Mar 31, 2:02 am, Steve Howell showel...@yahoo.com wrote: Steven, how do you predict which abstractions are going to be useless? A useless abstraction is one that does nothing to simplify a problem *now*: That's the very definition of short-sighted thinking. If it doesn't do anything *now* being so fixated on over-arching abstract concepts that, far from those abstractions making it easier to solve the problems they are being paid to solve, they actually make them harder An abstraction is also useless if it's so clever that it isn't readily understandable to an average developer; architecture astronauts don't tend to be big on sticking around to provide ongoing support. You are careless and sloppy with your quoting here. I didn't say the above; you should give proper attribution. -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
On Mar 31, 3:29 am, Terry Reedy tjre...@udel.edu wrote:
On 3/31/2012 2:22 AM, Yingjie Lan wrote:
Hi all,
I'd really like to share this idea of string interpolation for formatting.
Let's start with some code:
name = Shrek
print( Hi, $name$!)
Hi, Shrek!
balls = 30
print( We have $balls$ balls.)
We have 30 balls
You can already do essentially that without adding a special-case string
formatting method to the general methods we already have.
balls = 5
people = 3
'The {people} people have {balls} balls.'.format(**locals())
'The 3 people have 5 balls.'
I was wondering how much of a performance penalty you pay for using
the **locals() idiom, because I use it myself sometimes.
It turns out there is a slight penalty for **locals() vs. explicitly
passing in arguments to format (e.g. .format(balls=balls,
people=people), although it's probably negligible in 99.9% of use
cases.
def yo(a):
x = 1
y = 2
z = 3
a = b = c = d = 7
for i in range(10):
# s = {x} {y} {z}.format(**locals())
s = {x} {y} {z}.format(x=x, y=y, z=z)
for i in range(1):
yo(i)
# .150s for **locals()
# .131s for explicit x/y/z
--
http://mail.python.org/mailman/listinfo/python-list
why can't I pickle a class containing this dispatch dictionary?
Hi All
I'm clearly not understanding the 'can't pickle instancemethod
objects' error; can someone help me to understand, maybe suggest a
workaround, (apart from the obvious if ... elif...).
I'm running Python 2.6 on an embedded system.
== testpickle.py ==
import pickle
class Test(object):
def __init__(self):
self.myDict = {
1: self.tag1,
2: self.tag2
}
def dispatch(self, v):
try:
self.myDict[v]()
except KeyError:
print No corresponding dictionary entry!
#
def tag1(self):
print one
def tag2(self):
print two
t = Test()
t.dispatch(1)
t.dispatch(2)
t.dispatch(0)
fd = open(pickle.out, w)
pickle.dump(t, fd)
fd.close()
# EOF
$ python testpickle.py
one
two
No corresponding dictionary entry!
Traceback (most recent call last):
File ptest.py, line 29, in module
pickle.dump(t, fd)
File /usr/lib/python2.6/pickle.py, line 1362, in dump
Pickler(file, protocol).dump(obj)
File /usr/lib/python2.6/pickle.py, line 224, in dump
self.save(obj)
File /usr/lib/python2.6/pickle.py, line 331, in save
self.save_reduce(obj=obj, *rv)
File /usr/lib/python2.6/pickle.py, line 419, in save_reduce
save(state)
File /usr/lib/python2.6/pickle.py, line 286, in save
f(self, obj) # Call unbound method with explicit self
File /usr/lib/python2.6/pickle.py, line 649, in save_dict
self._batch_setitems(obj.iteritems())
File /usr/lib/python2.6/pickle.py, line 663, in _batch_setitems
save(v)
File /usr/lib/python2.6/pickle.py, line 286, in save
f(self, obj) # Call unbound method with explicit self
File /usr/lib/python2.6/pickle.py, line 649, in save_dict
self._batch_setitems(obj.iteritems())
File /usr/lib/python2.6/pickle.py, line 663, in _batch_setitems
save(v)
File /usr/lib/python2.6/pickle.py, line 306, in save
rv = reduce(self.proto)
File /usr/lib/python2.6/copy_reg.py, line 70, in _reduce_ex
raise TypeError, can't pickle %s objects % base.__name__
TypeError: can't pickle instancemethod objects
$
Thanks
J^n
--
http://mail.python.org/mailman/listinfo/python-list
588 Python programs
Hi everyone, I have compiled over 500 Python programs from the Rosetta Code website in this page: http://shpaml.webfactional.com/misc/RosettaCoffee/python.htm For those of you unfamiliar with Rosetta Code, you can read more here: http://rosettacode.org/wiki/Rosetta_Code For the record, I'm not affiliated with the site, although I'm an occasional contributor. I'm also not the author of the programs, which were contributed/authored my multiple people and are covered under the GNU Free Documentation License 1.2. I did write the code to aggregate the examples in one place. I hope you find the examples interesting to read! -- http://mail.python.org/mailman/listinfo/python-list
Re: No os.copy()? Why not?
On Wed, Mar 28, 2012 at 2:12 PM, John Ladasky john_lada...@sbcglobal.net wrote: I'm looking for a Python (2.7) equivalent to the Unix cp command. Since the equivalents of rm and mkdir are in the os module, I figured I look there. I haven't found anything in the documentation. I am also looking through the Python source code in os.py and its child, posixfile.py. Any help? Thanks. The os module wraps system calls, not shell commands. You want the shutil module, not the os module. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Script Works Locally But Not Remotely with SSH
Bump(?) -- http://mail.python.org/mailman/listinfo/python-list
Re: No os.copy()? Why not?
On Wed, 28 Mar 2012 13:12:30 -0700, John Ladasky wrote: I'm looking for a Python (2.7) equivalent to the Unix cp command. Since the equivalents of rm and mkdir are in the os module, I figured I look there. I haven't found anything in the documentation. I am also looking through the Python source code in os.py and its child, posixfile.py. Any help? Thanks. One way: import os os.system (cp src sink) -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: string interpolation for python
On 01/-10/-28163 01:59 PM, Yingjie Lan wrote: Because of the d... format, it won't affect old ways of doing things one bit. Allowing dynamic string wouldn't hurt a bit to anything that is already there. Why don't you just write a function that does it? I think someone already suggested this... import dynamic_strings # write this d = dynamic_strings.dynamic x = 5 print(d(x=$x$)) ? Sure, it's not *quite* as pretty as if you could just say dx=$x$, and you might have to do some hacky uglyness in the implementation to get at the locals of the calling procedure, but it solves a bazillion problems, such as: 1. YOU can do it, instead of hoping it gets into the mainline interpreter 2. You can do it NOW, and it will work with any version of Python 3. You have the freedom to easily add eval from *this dictionary* if you want, which solves Steven D'Aprano's objection that your suggestion is too weak. 4. Languages changes should be viewed suspiciously in general. Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way to structure data for efficient searching
larry.mart...@gmail.com wrote: I have the following use case: I have a set of data that is contains 3 fields, K1, K2 and a timestamp. There are duplicates in the data set, and they all have to processed. Then I have another set of data with 4 fields: K3, K4, K5, and a timestamp. There are also duplicates in that data set, and they also all have to be processed. I need to find all the items in the second data set where K1==K3 and K2==K4 and the 2 timestamps are within 20 seconds of each other. I have this working, but the way I did it seems very inefficient - I simply put the data in 2 arrays (as tuples) and then walked through the entire second data set once for each item in the first data set, looking for matches. Is there a better, more efficient way I could have done this? Build a lookup table that maps (K3, K4) to the matching records in the second table. Then you can walk through the first table, look up the matching records in the second and filter by the timestamp constraint: from collections import defaultdict, namedtuple # simulate a database One = namedtuple(One, K1 K2 T) Two = namedtuple(Two, K3 K4 K5 T) one = [ [alpha, beta, 10], [gamma, delta, 20], [gamma, delta, 25], [gamma, delta, 40], [kappa, lambda, 40], ] one = (One(*row) for row in one) two = [ [alpha, beta, epsilon, 10], [gamma, delta, zeta, 20], [gamma, delta, eta, 60], ] two = (Two(*row) for row in two) # build the lookup table lookup = defaultdict(list) for rtwo in two: lookup[rtwo.K3, rtwo.K4].append(rtwo) # show the matches for rone in one: for rtwo in lookup.get((rone.K1, rone.K2), ()): if abs(rone.T-rtwo.T) = 20: print rone, --, rtwo (Personally I'd go for the SQL approach proposed by Jon; I find the argument why you can't do it unconvincing) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Script Works Locally But Not Remotely with SSH
On Wednesday, March 28, 2012 2:51:37 AM UTC+2, goldtech wrote:
Hi,
I have a WinXP PC running an SSH server and I have a Linux PC with an
SSH client and logged into the XP seemingly OK. It's all on my
personal LAN, the connection seems OK.
I have a py file on the XP that I run via SSH from the Linux, it's:
import webbrowser
webbrowser.open('www.google.com')
This runs OK started on the local XP PC, the browser Firefox opens and
goes to the site, or it opens a tab to the site. But executing that
same file via SSH does not open Firefox...doing it via SSH starts
Firefox ( I see it begin in the process manager and I see web
activity) but Firefox does not open it's window.
Why the does the window not open when the script is started remotely?
Thanks.
Do You have a GUI over SSH? Something like ssh -X in Linux systems, or do You
just have a terminal window? If You just have a terminal, You wont be able to
run GUI apps.
Rgrds
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is Programing Art or Science?
ccc31807 carte...@gmail.com writes:
Programming is neither an art nor a science, but a trade.
It's not an art in the sense of painting, music, dance, poetry, etc.,
because the objective isn't to make a beautiful something, but to give
instructions to a machine to accomplish some useful task.
It's not a science in the sense of either physics and chemistry
(experimental) or geology or astronomy (observational) or cosmology or
psychology (theoretical) because the objective isn't to test
hypothetical s against data, but to give instructions to a machine to
accomplish some useful task.
Obviously, it's very much connected with art (e.g., user interface
design) and science (e.g., artificial intelligence) but the practice
of giving instructions to a machine is more like assembling machines
in a factory than the pursuit of an art or the practice of a science.
This is a narrow-minded definition of programming.
Watch: http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute
Read:Structure and Interpretation of Computer Programs
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html
http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
On Mar 30, 3:37 pm, Nathan Rice nathan.alexander.r...@gmail.com wrote: We live in a world where the tools that are used are based on tradition (read that as backwards compatibility if it makes you feel better) and as a mechanism for deriving personal identity. The world is backwards and retarded in many, many ways, this problem is interesting to me because it actually cuts across a much larger tract than is immediately obvious. Do you produce commercial code in a team? Because going by your absolutist bullshit here, it certainly doesn't sound like it. When I join an organisation that requires language A as all of its systems are written in it, is that 'tradition' or 'personal identity'? How is 'compatibility' - either with existing systems or existing *developers* - a backwards and retarded approach to complex problems? If I've chosen language A because some aspect of its syntax maps better onto my mind (or for _whatever_ reason that makes individuals prefer one language to another), and you've chosen language B: who gets to decide which is the 'superior' language, which is the 'better' mapping etc? You're arguing for a top-down centralised approach to language development that just will _never_ exist, simply because it cannot. If you don't accept that, I believe there's a fascinating fork called Python 4000 where your ideas would be readily adopted. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Mar 31, 6:30 am, Neil Cerutti ne...@norwich.edu wrote: See, for example, Inform 7, which translates a subset of English into Inform 6 code. I never thought too deeply about why I disliked it, assuming it was because I already knew Inform 6. I've always respected Inform 7 while being also unwilling to use it. When you're trying to make your language grammar a subset of your data grammar and then combine them interchangeably, it can be unclear about where the error lies, even if the combination is done in prescribed and restricted ways. Whereas keywords are key words: they give texture to source code, like visual braille. -- http://mail.python.org/mailman/listinfo/python-list
Re: string interpolation for python
On Apr 2, 2:11 pm, Yingjie Lan lany...@yahoo.com wrote: Almost as terse, but not as readable, especially... Hi Yingjie, Just in case you are not a native speaker of English, 'terse' is a mildly pejorative word, ie it is not 'good'. You probably want to use something like 'concise', or just plain 'short.' As for your suggestion, Ive nothing much to say: It probably comes from a perl culture and who is to way which culture is better? Not me anyway, whenever I look at perl code my head spins... [No flaming here -- I just dont know perl] -- http://mail.python.org/mailman/listinfo/python-list
Re: Threads on google groups not on gmane?
On 02/04/2012 12:23, Steven D'Aprano wrote: On Mon, 02 Apr 2012 03:16:26 -0700, Paul Rubin wrote: Robert Kernrobert.k...@gmail.com writes: I also don't see these on GMane. It's possible that they are getting caught in one of GMane's several levels of spam filtering. I'm seeing some weird issues where google groups posts on another newsgroup aren't making it to the non-google nntp server that I use. The paranoid in me wonders if google is doing that on purpose, but it's a pretty recent development, and other explanations are possible. Most likely, other providers are blocking google groups as a known source of spam. Thanks for all the replies, but as I've have just seen a pile of messages, some of which date back to 28/03/2012, I'd hazard a guess that something somewhere was wrong and has now been fixed :) Or ... ? -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
AddNamedItem throws exception
We have a scripting engine interface in our application. This works fine for loading/calling VBscript and Javascript scripting engines, but PythonScript fails. Specifically, it fails at : m_pAxsScript-AddNamedItem(application, SCRIPTITEM_NAMEDITEM) where m_pAxsScript is the IActiveScript interface acquired through CoCreateInstance. The exception returned is: 80004005 which to my mind implies some kind of 'access denied' error. We are using Python 2.7.2 and Pywin32 2.7 on a Windows 7 32-bit system. We have this problem here on a test machine that was set up to match that in use at one of our customers who is now stuck being unable to run his scripts. Any clues or suggestions would be gratefully received. David -- http://mail.python.org/mailman/listinfo/python-list
