Hello All,
I using
jython 2.1. For that i need of Python 2.1 ( i am sure about this, pls clarify me
if any version of Python can be used with Jython). and i am working HP-UX
platform. I need to know that, whether Python can be Built in HP-UX, because i
seeing some of the mails saying
On Tue, Apr 19, 2005, Prakash A wrote:
I using jython 2.1. For that i need of Python 2.1 ( i am sure about
this, pls clarify me if any version of Python can be used with
Jython). and i am working HP-UX platform. I need to know that,
whether Python can be Built in HP-UX, because i seeing some
i'm a beginning python programmer.
I want to get the date for yesterday
nowTime = time.localtime(time.time())
print nowTime.
oneDay = 60*60*24 # number seconds in a day
yday = nowTime - oneDay # -- generates an error
print yday.strftime(%Y-%m-%d)
How can I just get yesterday's day? It a
On 4/19/05, Ralph Hilton [EMAIL PROTECTED] wrote:
i'm a beginning python programmer.
I want to get the date for yesterday
This is the wrong place for this question. Nip over to
http://mail.python.org/mailman/listinfo/python-list, and I'd be more
than happy answer it there...
--
Cheers,
(I apologize that this is my first post. Please don't flame me into
oblivion or think I'm a quack!)
(Having met JJ I can assure he's not a quack. But don't let that stop
the flames. :-)
Have you guys considered the following syntax for anonymous blocks? I
think it's possible to parse given
Shannon -jj Behrens wrote:
Have you guys considered the following syntax for anonymous blocks? I
think it's possible to parse given Python's existing syntax:
items.doFoo(
def (a, b) {
return a + b
},
def (c, d) {
return c + d
}
)
There was a
Greg Ewing wrote:
Travis Oliphant wrote:
I'm proposing to pickle the buffer object so that it unpickles as a
string.
Wouldn't this mean you're only solving half the problem?
Unpickling a Numeric array this way would still use an
intermediate string.
Well, actually, unpickling in the new numeric
See the thread pre-PEP: Suite-Based Keywords (shamless plug)
(an earlier, similar proposal is here:
http://groups.google.co.uk/groups?selm=mailman.403.1105274631.22381.python-list
%40python.org ).
In short, if doFoo is defined like:
def doFoo(func1, func2):
pass
You would be
At 11:55 AM 04/19/2005 -0700, Guido van Rossum wrote:
I'd recommend this:
tri = self.subcalculation(The quick brown fox jumps over the lazy dog)
self.disentangle(0x40, tri, self.indent+1)
IMO this is clearer, and even shorter!
What was your opinion on where as a lambda replacement? i.e.
foo =
At 03:39 PM 04/19/2005 -0400, Phillip J. Eby wrote:
I suspect that you like the define-first approach because of your tendency
to ask questions first and read later.
Oops; I forgot to put the smiley on that. It was supposed to be a humorous
reference to a comment Guido made in private e-mail
On 4/19/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I'm still not sure how this is particularly solving a pressing problem
that isn't solved by putting the function definitions in front of the
Well.
As to what I've read in my short python experience, people wants to
change the language
Guido van Rossum wrote:
See the thread pre-PEP: Suite-Based Keywords (shamless plug)
(an earlier, similar proposal is here:
http://groups.google.co.uk/groups?selm=mailman.403.1105274631.22381.python-list
%40python.org ).
In short, if doFoo is defined like:
def doFoo(func1, func2):
pass
You
Guido van Rossum wrote:
What was your opinion on where as a lambda replacement? i.e.
foo = bar(callback1, callback2) where:
def callback1(x):
print hello,
def callback2(x):
print world!
I don't recall seeing this proposed, but I might have -- I thought of
On Tue, 2005-04-19 at 15:24, Guido van Rossum wrote:
*If* we're going to create syntax for anonymous blocks, I think the
primary use case ought to be cleanup operations to replace try/finally
blocks for locking and similar things. I'd love to have syntactical
support so I can write
Guido van Rossum wrote:
tri = self.subcalculation(The quick brown fox jumps over the lazy
dog)
self.disentangle(0x40, tri, self.indent+1)
IMO this is clearer, and even shorter!
But it clutters the namespace with objects you don't need. So the
complete equivalent would be more close to:
tri =
@acquire(myLock):
code
code
code
It would certainly solve the problem of which keyword to use! :-) And
I think the syntax isn't even ambiguous -- the trailing colon
distinguishes this from the function decorator syntax. I guess it
would morph '@xxx' into user-defined-keyword.
How
Guido van Rossum wrote:
@acquire(myLock):
code
code
code
It would certainly solve the problem of which keyword to use! :-) And
I think the syntax isn't even ambiguous -- the trailing colon
distinguishes this from the function decorator syntax. I guess it
would morph '@xxx' into
Brian Sabbey wrote:
If suites were commonly used as above to define properties, event handlers
and other callbacks, then I think most people would be able to comprehend
what the first example above is doing much more quickly than the second.
wonderful logic, there. good luck with your future
Why not have the block automatically be inserted into acquire's argument
list? It would probably get annoying to have to define inner functions
like that every time one simply wants to use arguments.
But the number of *uses* would be much larger than the number of
block decorators you'd be
Guido van Rossum wrote:
As I said before, I'm not sure why keeping get_foo etc. out of the
class namespace is such a big deal. In fact, I like having them there
(sometimes they can even be handy, e.g. you might be able to pass the
unbound get_foo method as a sort key).
Not to mention that it's
[Guido van Rossum]
@EXPR:
CODE
would become something like
def __block():
CODE
EXPR(__block)
I'm not yet sure whether to love or hate it. :-)
Is it preferable for CODE to execute in its own namespace (the above
being a literal translation of the given code), or for it to
Fredrik Lundh wrote:
Brian Sabbey wrote:
If suites were commonly used as above to define properties, event handlers
and other callbacks, then I think most people would be able to comprehend
what the first example above is doing much more quickly than the second.
wonderful logic, there. good
RSMotD (random stupid musing of the day): so I wonder if the decorator
syntax couldn't be extended for this kind of thing.
@acquire(myLock):
code
code
code
Would it be useful for anything other than mutex-locking? And wouldn't
it be better to make a function of the block
On Tue, Apr 19, 2005 at 01:33:15PM -0700, Guido van Rossum wrote:
@acquire(myLock):
code
code
code
It would certainly solve the problem of which keyword to use! :-) And
I think the syntax isn't even ambiguous -- the trailing colon
distinguishes this from the function
On 4/19/05, BJörn Lindqvist [EMAIL PROTECTED] wrote:
RSMotD (random stupid musing of the day): so I wonder if the decorator
syntax couldn't be extended for this kind of thing.
@acquire(myLock):
code
code
code
Would it be useful for anything other than mutex-locking?
Fredrik Lundh wrote:
Brian Sabbey wrote:
doFoo(**):
def func1(a, b):
return a + b
def func2(c, d):
return c + d
That is, a suite can be used to define keyword arguments.
umm. isn't that just an incredibly obscure way to write
def func1(a, b):
*If* we're going to create syntax for anonymous blocks, I think the
primary use case ought to be cleanup operations to replace try/finally
blocks for locking and similar things. I'd love to have syntactical
support so I can write
I heartily agree! Especially when you have very similar try/finally
On 4/19/05, Alex Martelli [EMAIL PROTECTED] wrote:
Well, one obvious use might be, say:
@withfile('foo.bar', 'r'):
content = thefile.read()
but that would require the decorator and block to be able to interact
in some way, so that inside the block 'thefile' is defined suitably.
28 matches
Mail list logo
