Calvin Spealman wrote:
I mean, come on, its like making a module just to store a bunch of
unrelated types just to lump them together because they're types.
import types
/F
___
Python-Dev mailing list
Python-Dev@python.org
Greg Ewing wrote:
Nick Coghlan wrote:
Sometimes I miss the obvious. There's a *much*, *much* better place to store
the return value of a generator than on the StopIteration exception that it
raises when it finishes. Just save the return value in the *generator*.
I'm not convinced that
This might be minor-- but I didn't see anyone mentioning it so far. If
`exec` functionality is to be provided, then I think it still should be a
keyword for the parser to know; currently bytecode generation is affected if
`exec` is present. Even if that changes for Python 3k (we don't know
On Sat, Oct 08, 2005 at 08:04:13PM -0400, jamesr wrote:
if ((sys.argv[1] =='debug') if len(sys.argv) 1 else False):
pass
Very good example! Very good example why ternary operators must be
forbidden!
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL
On Sat, 8 Oct 2005 20:04:13 -0400, jamesr [EMAIL PROTECTED] wrote:
Congragulations heartily given. I missed the ternary op in c... Way to
go! clean and easy and now i can do:
if ((sys.argv[1] =='debug') if len(sys.argv) 1 else False):
pass
and check variables IF AND ONLY if they exist,
Congragulations heartily given. I missed the ternary op in c... Way to
go! clean and easy and now i can do:
if ((sys.argv[1] =='debug') if len(sys.argv) 1 else False):
pass
and check variables IF AND ONLY if they exist, in a single line!
Umm... Is this a joke?
Andrew Umm... Is this a joke?
I hope so. I must admit the OP's intent didn't make itself known to me with
the cursory glance I gave it. Jp's formulation is how I would have written
it. Assuming of course, that was the OP's intent.
Skip
___
On Mon, 2005-10-10 at 01:47, Calvin Spealman wrote:
Never created for a reason? lumping things together for having the
similar usage semantics, but unrelated purposes, might be something to
avoid and maybe that's why it hasn't happened yet for decorators. If
ever there was a makethreadsafe
On Fri, 2005-10-07 at 23:54, Nick Coghlan wrote:
[...]
The few times I have encountered anyone saying anything resembling threading
is easy, it was because the full sentence went something like threading is
easy if you use message passing and copy-on-send or release-reference-on-send
to
On 10/10/05, Nick Coghlan [EMAIL PROTECTED] wrote:
It also works for situations where the first n items are mandatory, the rest
are optional. This usage was brought up in the context of a basic line
interpreter:
cmd, *args = input.split()
That's a really poor example though. You really
On 10/10/05, Nick Coghlan [EMAIL PROTECTED] wrote:
I'm starting to think we want to let PEP 342 bake for at least one release
cycle before deciding what (if any) additional behaviour should be added to
generators.
Yes please!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
On Fri, 2005-10-07 at 17:47, Bruce Eckel wrote:
Early in this thread there was a comment to the effect that if you
don't know how to use threads, don't use them, which I pointedly
avoided responding to because it seemed to me to simply be
inflammatory. But Ian Bicking just posted a weblog
On Monday 10 Oct 2005 15:45, Donovan Baarda wrote:
Sounds like yet another reason to avoid threading and use processes
instead... effort spent on threading based message passing
implementations could instead be spent on inter-process messaging.
I can't let that pass (even if our threaded
On 29 Sep 2005, at 12:06, Steven Bethard wrote:
On 9/29/05, Robey Pointer [EMAIL PROTECTED] wrote:
Yesterday I ran into a bug in the C API docs. The top of this page:
http://docs.python.org/api/unicodeObjects.html
says:
Py_UNICODE
This type represents a 16-bit unsigned
The problem with threads is at first glance they appear easy...
Anyone who thinks that a glance is enough to understand something is
too far gone to worry about. On the other hand, you might be
referring to a putative brokenness of the Python documentation on
Python threads. I'm not sure
The hard part is knowing when and how to lock shared resources...
Bill Well, I might say the careful part.
With the Mojam middleware stuff I suffered quite awhile with a
single-threaded implementation that would hang the entire webserver if a
backend query took too long. I realized I
On Mon, 2005-10-10 at 18:59, Bill Janssen wrote:
The problem with threads is at first glance they appear easy...
Anyone who thinks that a glance is enough to understand something is
too far gone to worry about. On the other hand, you might be
referring to a putative brokenness of the
Skip,
With the Mojam middleware stuff I suffered quite awhile with a
single-threaded implementation that would hang the entire webserver if a
backend query took too long. I realized I needed to do something (threads,
asyncore, whatever), but didn't think I understood the issues well enough
On 10/10/05, Nick Coghlan [EMAIL PROTECTED] wrote:
cmd, *args = input.split()
These examples also have a reasonable implementation using list.pop(),
albeit one that requires more typing. On the plus side, it does not violate
DRY and is explicit about the error cases.
args = input.split()
Yes, there's a troublesome meme in the world: threads are hard.
They aren't, really. You just have to know what you're doing.
I would say that the troublesome meme is that threads are easy. I
posted an earlier, rather longish message about this. The gist of
which was: when someone says that
On 10/10/05, Christos Georgiou [EMAIL PROTECTED] wrote:
This might be minor-- but I didn't see anyone mentioning it so far. If
`exec` functionality is to be provided, then I think it still should be a
keyword for the parser to know; currently bytecode generation is affected if
`exec` is
On 10/10/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Mon, 2005-10-10 at 01:47, Calvin Spealman wrote:
Never created for a reason? lumping things together for having the
similar usage semantics, but unrelated purposes, might be something to
avoid and maybe that's why it hasn't happened yet
Phillip J. Eby wrote:
What the GIL-ranters don't get is that the GIL actually gives you just
enough determinism to be able to write threaded programs that don't crash,
and that maybe will even work if you treat every point of interaction
between threads as a minefield and program with
This might be minor-- but I didn't see anyone mentioning it so far.
If `exec` functionality is to be provided, then I think it still
should be a keyword for the parser to know; currently bytecode
generation is affected if `exec` is present. Even if that changes
for Python
My idea was to make the compiler smarter so that it would recognize
exec() even if it was just a function.
Another idea might be to change the exec() spec so that you are
required to pass in a namespace (and you can't use locals() either!).
Then the whole point becomes moot.
On 10/10/05, [EMAIL
[Martin v. Löwis]
What happened to the CurrentVersion registry entry documented at
http://www.python.org/windows/python/registry.html
AFAICT, even the python15.wse file did not fill a value in this
entry (perhaps I'm misinterpreting the wse file, though).
So was this ever used? Why is it
Paul Du Bois wrote:
On 10/10/05, Nick Coghlan [EMAIL PROTECTED] wrote:
cmd, *args = input.split()
These examples also have a reasonable implementation using list.pop(),
albeit one that requires more typing. On the plus side, it does not
violate
DRY and is explicit about the error
Delaney, Timothy (Tim) wrote:
args = input.split()
try:
cmd = arg.pop()
^^^ args ...
except IndexError:
cmd = ''
Can't even get it right myself - does that prove a point? wink
Tim Delaney
___
Suppose we run script.py while playground/ is the current directory.
I'm using 2.4.2 here, but doubt it matters much. No Python-related
envars are set.
Windows (and the PIL and pywin32 extensions are installed here):
C:\playground\python24\python.exe someother\script.py
Bruce Eckel:
I would say that the troublesome meme is that threads are easy. I
posted an earlier, rather longish message about this. The gist of
which was: when someone says that threads are easy, I have no idea
what they mean by it.
I think you are overcomplicating the issue by looking
Ian Bicking wrote:
What the GIL-ranters don't get is that the GIL actually gives you just
enough determinism to be able to write threaded programs that don't crash,
The GIL no doubt helps, but your threads can still get
preempted between bytecodes, so I can't see it making
much difference at
On 10/10/05, Greg Ewing [EMAIL PROTECTED] wrote:
I'm wondering whether Python threads should be
non-preemptive by default. Preemptive threading is
massive overkill for many applications. You don't
need it, for example, if you just want to use threads
to structure your program, overlap
On 10/11/05, Guido van Rossum [EMAIL PROTECTED] wrote:
My idea was to make the compiler smarter so that it would recognize
exec() even if it was just a function.
Another idea might be to change the exec() spec so that you are
required to pass in a namespace (and you can't use locals()
Brett Cannon wrote:
But the better answer is we will just find a way. =)
I think the best answer would be just to dump the idea of
exec-in-local-namespace altogether. I don't think I've
ever seen a use case for it that wasn't better done some
other way.
Most often it seems to be used to
On 10/10/05, Greg Ewing [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
But the better answer is we will just find a way. =)
I think the best answer would be just to dump the idea of
exec-in-local-namespace altogether. I don't think I've
ever seen a use case for it that wasn't better done
On 10/11/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I recall using a non-preemptive system in the past; in Amoeba, to be precise.
Initially it worked great.
But as we added more powerful APIs to the library, we started to run
into bugs that were just as if you had preemptive scheduling:
Guido writes:
Given the tendency of Python developers to build layers of
abstractions I don't think [non-preemptive threads] will help much.
I think that's right, although I think adding priorities to Python's
existing preemptive threads might be useful for real-time programmers
(yes, as
On Monday 10 October 2005 18:42, Tim Peters wrote:
never before this year -- maybe sys.path _used_ to contain the current
directory on Linux?).
It's been a long time since this was the case on Unix of any variety; I
*think* this changed to the current state back before 2.0.
-Fred
--
There's a problem with genexp's that I think really needs to get
fixed. See http://python.org/sf/1167751 the details are below. This
code:
foo(a = i for i in range(10))
generates NameError: name 'i' is not defined when run because:
2 0 LOAD_GLOBAL 0 (foo)
Delaney, Timothy (Tim) wrote:
Paul Du Bois wrote:
On 10/10/05, Nick Coghlan [EMAIL PROTECTED] wrote:
cmd, *args = input.split()
These examples also have a reasonable implementation using list.pop(),
albeit one that requires more typing. On the plus side, it does not
violate
DRY and is
On 10/10/05, Ron Adam [EMAIL PROTECTED] wrote:
The problem is the '*' means different things depending on where it's
located. In a function def, it means to group or to pack, but from the
calling end it's used to unpack. I don't expect it to change as it's
been a part of Python for a long
41 matches
Mail list logo
