Ron Adam wrote:
> My concern is if it's used outside of functions, then on the left hand
> side of assignments, it will be used to pack, but if used on the right
> hand side it will be to unpack.
I don't see why that should be any more confusing than the
fact that commas denote tuple packing on
Guido van Rossum wrote:
> BTW, what should
>
> [a, b, *rest] = (1, 2, 3, 4, 5)
>
> do? Should it set rest to (3, 4, 5) or to [3, 4, 5]?
Whatever type is chosen, it should be the same type, always.
The rhs could be any iterable, not just a tuple or a list.
Making a special case of preserving
Brett Cannon wrote:
> 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 mayb
The multi-processing discussion reminded me that I have a few problems I run
into every time I try to use Queue objects.
My first problem is finding it:
Py> from threading import Queue # Nope
Traceback (most recent call last):
File "", line 1, in ?
ImportError: cannot import name Queue
Py> fr
Donovan Baarda wrote:
> 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
Neal Norwitz 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:
> I agree with the bug report that the code should either raise a
> SyntaxError or do the right thing.
I agree it should be a Synta
jamesr 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, in a single line!
>
> but y'all knew th
Guido van Rossum 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() either!).
> Then the whole point
Bruce Eckel wrote:
>>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
> w
Bruce Eckel wrote:
[Bill Janssen]
>>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.
>
But that begs the question, because there is a significant amount of
evidence that when it comes to threads "knowing what you ar
On 10/11/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Neal Norwitz 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:
> > I agree with the bug report that the code should either raise a
> >
Nick Coghlan wrote:
> Neal Norwitz 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:
>>I agree with the bug report that the code should either raise a
>>SyntaxError or do the right thing.
>
>
[Tim Peters]
>>> never before this year -- maybe sys.path _used_ to contain the current
>>> directory on Linux?).
[Fred L. Drake, Jr.]
>> 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.
[Martin v. Löwis]
> Pleas
Title: RE: [Python-Dev] Pythonic concurrency
Steve Holden wrote:
> The nice thing about Python threads (or rather threading.threads) is
> that since each thread is an instance it's *relatively* easy to ensure
> that a thread restricts itself to manipulating thread-local resources
> (i.e. inst
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>
>>BTW, what should
>>
>>[a, b, *rest] = (1, 2, 3, 4, 5)
>>
>>do? Should it set rest to (3, 4, 5) or to [3, 4, 5]?
>
>
> Whatever type is chosen, it should be the same type, always.
> The rhs could be any iterable, not just a tuple or a list.
>
Nick Coghlan wrote:
> For me, it stops when the rules for positional name binding are more
> consistent across operations that bind names (although complete consistency
> isn't possible, given that function calls don't unpack sequences
> automatically).
Oops - forgot to delete this bit once I r
Robert Brewer wrote:
> "Somewhat alleviated" and somewhat worsened. I've had half a dozen
> conversations in the last year about sharing data between threads; in
> every case, I've had to work quite hard to convince the other person
> that threading.local is *not* magic pixie thread dust. Each t
On 10/11/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The multi-processing discussion reminded me that I have a few problems I run
> into every time I try to use Queue objects.
>
> My first problem is finding it:
>
> Py> from threading import Queue # Nope
> Traceback (most recent call last):
>
On 10/11/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> Well, that's in interactive mode, and I see sys.path[0] == "" on both
> Windows and Linux then. I don't see "" in sys.path on either box in
> batch mode, although I do see the absolutized path to the current
> directory in sys.path in batch mode
[Tim]
>> Well, that's in interactive mode, and I see sys.path[0] == "" on both
>> Windows and Linux then. I don't see "" in sys.path on either box in
>> batch mode, although I do see the absolutized path to the current
>> directory in sys.path in batch mode on Windows but not on Linux -- but
>> Ma
On 10/11/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Tim]
> >> Well, that's in interactive mode, and I see sys.path[0] == "" on both
> >> Windows and Linux then. I don't see "" in sys.path on either box in
> >> batch mode, although I do see the absolutized path to the current
> >> directory in sy
Nick Coghlan wrote:
> Greg Ewing wrote:
>
>>Guido van Rossum wrote:
>>
>>
>>
>>>BTW, what should
>>>
>>> [a, b, *rest] = (1, 2, 3, 4, 5)
>>>
>>>do? Should it set rest to (3, 4, 5) or to [3, 4, 5]?
>>
>>
>>Whatever type is chosen, it should be the same type, always.
>>The rhs could be any iterabl
(my own 2 eurocents)
> I do feel that for Python 3 it might be better to make a clean
> separation between keywords and positionals: in other words, of the
> function definition specifies a keyword argument then a keyword must be
> used to present it.
Do you mean it would also be forbidden to
> Java's condition variables don't (didn't? has this been fixed?) quite
> work. The emphasis on portability and the resulting notions of
> red/green threading packages at the beginning didn't help either.
> Read Allen Holub's book. And Doug Lea's book. I understand much of
> this has been addre
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Optionally, the existing "put" and "get" methods could be deprecated, with
> > the
> > goal of eventually changing their signature to match the put_wait and
> > get_wait
> > methods above.
>
> Apart from trying to guess the API without reading the
Nick Coghlan wrote:
> So my vote would actually go for deprecating the use of square brackets to
> surround an assignment target list - it makes it look like an actual list
> object should be involved somewhere, but there isn't one.
I've found myself using square brackets a few times for more
comp
> Date: Tue, 11 Oct 2005 09:51:06 -0400 > From: Tim Peters <[EMAIL PROTECTED]>> Subject: Re: [Python-Dev] PythonCore\CurrentVersion > To: Martin v. L?wis <[EMAIL PROTECTED]>> Cc: python-dev@python.org > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > [Tim Pet
"Robert Brewer" <[EMAIL PROTECTED]> wrote:
> "Somewhat alleviated" and somewhat worsened. I've had half a dozen
> conversations in the last year about sharing data between threads; in
> every case, I've had to work quite hard to convince the other person
> that threading.local is *not* magic pixie
[Guido]
>> Apart from trying to guess the API without reading the docs (:-), what
>> are the use cases for using put/get with a timeout? I have a feeling
>> it's not that common.
[Josiah Carlson]
> With timeout=0, a shared connection/resource pool (perhaps DB, etc., I
> use one in the tuple space
On 10/11/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> Guido understands use cases for blocking and non-blocking put/get, and
> Queue always supported those possibilities. The timeout argument got
> added later, and it's not really clear _why_ it was added. timeout=0
> isn't a sane use case (becaus
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> BTW, what should
>>
>> [a, b, *rest] = (1, 2, 3, 4, 5)
>>
>> do? Should it set rest to (3, 4, 5) or to [3, 4, 5]?
>
> Whatever type is chosen, it should be the same type, always.
> The rhs could be any iterable, not just a tuple or a list.
>
[Guido]
> I tried your experiment but added 'print sys.argv[0]' and didn't see
> that. sys.argv[0] is the path to the script.
My mistake! You're right, sys.argv[0] is the path to the script for me too.
[Tim]
>> The directory of the script being run was
>> nevertheless in sys.path[0] on both Wind
On 10/7/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> the whole concept might be perfectly fine on the "this construct corre-
> sponds to this code" level, but if you immediately end up with things that
> are not what they seem, and names that don't mean what the say, either
> the design or the de
Reinhold Birkenfeld wrote:
> Greg Ewing wrote:
>
>>Guido van Rossum wrote:
>>
>>
>>>BTW, what should
>>>
>>>[a, b, *rest] = (1, 2, 3, 4, 5)
>>>
>>>do? Should it set rest to (3, 4, 5) or to [3, 4, 5]?
>>
>>Whatever type is chosen, it should be the same type, always.
>>The rhs could be any itera
[Guido]
> >> Apart from trying to guess the API without reading the docs (:-), what
> >> are the use cases for using put/get with a timeout? I have a feeling
> >> it's not that common.
[Josiah Carlson]
> > With timeout=0, a shared connection/resource pool (perhaps DB, etc., I
> > use one in the t
Guido van Rossum wrote:
> I see no need. Code that *doesn't* need Queue but does use threading
> shouldn't have to pay for loading Queue.py.
However, it does seem awkward to have a whole module
providing just one small class that logically is so
closely related to other threading facilities.
Wha
Jason Orendorff wrote:
> A contextmanager is a function that returns a new context manager.
>
> Okay, that last bit is weird.
If the name of the decorator is to be 'contextmanager', it
really needs to say something like
The contextmanager decorator turns a generator into a
function th
Nick Coghlan wrote:
> As a location for this, I would actually suggest a module called something
> like "metatools",
-1, too vague and meaningless a name. If "decorator" is the
official term for this kind of function, then calling the
module "decorators" is precise and helpful. Other kinds of
me
Nick Coghlan wrote:
> I'm also trying to figure out why you would ever write:
>[a, b, c, d] = seq
I think the ability to use square brackets is a
holdover from some ancient Python version where you had
to match the type of the thing being unpacked with
the appropriate syntax on the lhs. It wa
Steve Holden wrote:
> So presumably you'd need to be able to say
>
>((a, *b), c, *d) = ((1, 2, 3), 4, 5, 6)
Yes.
>a, *b = [1]
>
> to put the empty list into b, or is that an unpacking error?
Empty sequence in b (of whatever type is chosen).
> does this mean that you'd also like to b
that stm paper isn't the end.
there's a java implementation which seems to be exactly what we want:
http://research.microsoft.com/~tharris/papers/2003-oopsla.pdf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
41 matches
Mail list logo
