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 sayi
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 s
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 sim
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,
On 4/19/05, Ralph Hilton <[EMAIL PROTECTED]> wrote:
> 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 yd
Hi, I believe it's not the appropriate place to ask such questions.
You should check the Python users' list (
http://python.org/community/lists.html )
Anyway, here you go :
now = time.time()
nowTuple = time.localtime(now)
yesterdayTuple = time.localtime(now-60*60*24)
Regards,
Patrick.
2005/4/19
We're running into the problem described in bug 1177468, where urandom tries to
use a cached file descriptor that was closed by a daemonizing function. A quick
fix/workaround is to have os.urandom open /dev/urandom everytime it gets called
instead of using the a cached fd.
Would that create a
(I apologize that this is my first post. Please don't flame me into
oblivion or think I'm a quack!)
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
"Shannon -jj Behrens" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>Have you guys considered the following syntax for anonymous blocks?
There have probably been about 10 such proposals bandied about over the
years, mostly on comp.lang.python, which is the more appropriate place f
> (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 gi
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 proposal
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
>
> Y
Brian Sabbey wrote:
In short, if doFoo is defined like:
def doFoo(func1, func2):
pass
You would be able to call it like:
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
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 abo
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
Yo
> 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
pretty much exa
Fredrik Lundh wrote:
In short, if doFoo is defined like:
def doFoo(func1, func2):
pass
You would be able to call it like:
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 a
From: Guido van Rossum <[EMAIL PROTECTED]>
...
This reflects a style pattern that I've come to appreciate more
recently: when breaking a call with a long argument list to fit on
your screen, instead of trying to find the optimal break points in the
argument list, take one or two of the longest arg
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 h
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
>
> bl
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 =
> > IMO this is clearer, and even shorter!
> But it clutters the namespace with objects you don't need.
Why do people care about cluttering namespaces so much? I thought
thats' what namespaces were for -- to put stuff you want to remember
for a bit. A function's local namespace in particular seems
> @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".
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 "user-de
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 adv
Guido van Rossum wrote:
This reflects a style pattern that I've come to appreciate more
recently:
what took you so long? ;-)
Why do people care about cluttering namespaces so much? I thought
thats' what namespaces were for -- to put stuff you want to remember
for a bit. A function's local namespace
> 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 b
Guido van Rossum wrote:
But what exactly are you trying to accomplish here? I think that
putting the defs *before* the call (and giving the anonymous blocks
temporary local names) actually makes the code clearer:
I'm afraid that 'block1', 'block2', and 'doFoo' aren't really making
anything clear f
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 poss
Guido van Rossum wrote:
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 de
[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
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 luck
> 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
I am currently adding some code for a Py_COMPILER_DEBUG build for use on the
AST branch. I thought that OPT was the proper variable to put stuff like this
into for building (``-DPy_COMPILER_DEBUG``), but that erases ``-g -Wall
-Wstrict-prototypes``. Obviously I could just tack all of that into my
At 01:00 PM 04/19/2005 -0700, Guido van Rossum wrote:
> Interestingly, this syntax also works to do decoration, though it's not a
> syntax that was ever proposed for that. e.g.:
>
> foo = classmethod(foo) where:
> def foo(cls,x,y,z):
> # etc.
This requires you to write foo three time
I apologize for sparking such debate on this list instead of on
c.l.py. By the way, the only reason I brought this up was as a
replacement for lambdas in Py3K.
Guido, in response to your much earlier comment about supporting "{}"
for normal defs as a matter of consistency within my proposal, yes,
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 fun
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
On Apr 19, 2005, at 15:57, BJörn Lindqvist 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? And wouldn't
Well, one
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
Michael Walter <[EMAIL PROTECTED]> wrote:
>
> 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
>
*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 suitabl
Brett C. wrote:
> I am currently adding some code for a Py_COMPILER_DEBUG build for use on the
> AST branch. I thought that OPT was the proper variable to put stuff like this
> into for building (``-DPy_COMPILER_DEBUG``), but that erases ``-g -Wall
> -Wstrict-prototypes``. Obviously I could just
Josiah Carlson wrote:
See the previous two discussions on thunks here on python-dev, and
notice how the only problem that seem bettered via blocks/thunks /in
Python/ are those which are of the form...
#setup
try:
block
finally:
#finalization
... and depending on the syntax, properties. I o
Shane Hathaway wrote:
Brian's suggestion makes the code read more like an outline. In Brian's
example, the high-level intent stands out from the details
that assumes that when you call a library function, the high-level intent of
*your* code is obvious from the function name in the library, and to
49 matches
Mail list logo
