Fred L. Drake, Jr. wrote:
> 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 s
On 10/10/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 10/10/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > 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(1
On 10/10/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> 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 b
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 lo
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
>>v
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)
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
--
F
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 machi
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 schedu
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 bette
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 answe
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() e
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 p
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 a
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 lo
> 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
> ['C:\\play
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?
Tim Delaney
___
Python-
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
[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 us
On 10/10/05, [EMAIL PROTECTED] <[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
> >> generatio
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 P
>> 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
>> f
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 ap
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 hap
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
> 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 t
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(
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 enoug
Robey Pointer wrote:
> 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
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 th
>> 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 realize
> 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
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
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 com
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 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 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
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
>
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
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
___
Pyth
> 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?
__
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
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 PROTEC
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!
but y'all knew that..
Guido van Rossum wrote:
> On 10/9/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
>
>>Based on the discussion, I think I'd go with defaultproperty.
>
>
> Great.
>
>
>>Questions:
>>
>>- Should this be in builtins, alongside property, or in
>> a library module? (Oleg suggested propertytools.)
>>
>>-
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 yet
Fred L. Drake, Jr. wrote:
> On Sunday 09 October 2005 22:44, Greg Ewing wrote:
> > I'm aware of the differences, but I still see a strong
> > similarity where this particular feature is concerned.
> > The pattern of thinking is the same: "I want to deal
> > with the first n of these things indi
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 conv
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
49 matches
Mail list logo
