On 9/18/05, Greg Ewing [EMAIL PROTECTED] wrote:
François Pinard wrote:
The only practical reason to like this feature is sparing the need of
finding an otherwise useless name for the formal argument.
If the argument represents a coherent enough concept
to be passed in as a tuple in the
I ran 2.4.x through valgrind and found two small problems on Linux
that have been fixed. There may be some other issues which could
benefit from more eyes (small, probably one time memory leaks). The
entire run is here:
http://python.org/valgrind-2.4.2.out
(I need to write a lot more
Hi,
This function would take two paths: A and B and give
the relation between them. Here are a few of examples.
os.path.diff(/A/C/D/, /A/D/F/)
== ../../D/F
os.path.diff(/A/, /A/B/C/)
== B/C
os.path.diff(/A/B/C/, /A/)
== ../..
I'm not sure whether something like this is generally
Hi,
/home - usr/home
Sorry, I forgot to mention what I meant by this: /home is a symlink
pointing to usr/home (that is, /usr/home).
Bye,
Matthias
Matthias Andreas Benkard, Anarchokommunist und Pythonprogrammierer
Greg Ewing wrote:
François Pinard wrote:
The only practical reason to like this feature is sparing the need of
finding an otherwise useless name for the formal argument.
If the argument represents a coherent enough concept
to be passed in as a tuple in the first place, it
should be
On 9/18/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 9/17/05, John J Lee [EMAIL PROTECTED] wrote:
c. Since time is needed to iron out bugs (and perhaps also to reimplememt
some pieces of code from scratch), very early in the life of Python 3
seems like the least-worst time to
On 9/19/05, Neal Norwitz [EMAIL PROTECTED] wrote:
I ran 2.4.x through valgrind and found two small problems on Linux
that have been fixed. There may be some other issues which could
benefit from more eyes (small, probably one time memory leaks). The
entire run is here:
On 9/19/05, Guido van Rossum [EMAIL PROTECTED] wrote:
That patch doesn't make sense to me -- the s code to
PyArg_ParseTuple doesn't return newly allocated memory, it just
returns a pointer into a string object that is owned by the caller
(really by the call machinery I suppose). Compare
So it is. I swear I saw s; I must've had an out of date version. The
change to et is less than a week old, but that's no excuse. :-(
It does look like the patch is correct then (but I can't build on
Windows any more either). Sorry for the confusion.
On 9/19/05, Neal Norwitz [EMAIL PROTECTED]
I consider the current situation to be a consistency feature. To a first
approximation, Python function calls 'pass' objects by name-binding:
param_name_list = arg_object_list
Disabling structure unpacking in this assignment would make the language
slightly more complex. Someone else posted
On 9/19/05, Terry Reedy [EMAIL PROTECTED] wrote:
I consider the current situation to be a consistency feature. To a first
approximation, Python function calls 'pass' objects by name-binding:
param_name_list = arg_object_list
Disabling structure unpacking in this assignment would make
Guido van Rossum wrote:
Also, I bet many people will be surprised to know that this code doesn't work:
add = lambda (x, y): x+y
print add(1, 2)
What, an example using lambda syntax that's unintuitive? Never! ;-)
STeVe
--
You can wordify anything if you just verb it.
--- Bucky
Gareth McCaughan [EMAIL PROTECTED] wrote:
The problems with syntax are
1 It adds cognitive load.
2 It makes your code look like line noise.
3 It reduces options for future development.
4 It complicates the parser.
I don't know about #4, but I suspect it (along with the related
I agree that we shouldn't mess with them in 2.x. Yet I think they are
a candidate for being dropped from Py3K. While every feature is used
by *someone* (as the feedback to Brett's query clearly shows) this one
has several things against it. For every user who is fond of them
there are
The only practical reason to like this feature is sparing the need of
finding an otherwise useless name for the formal argument. Another
reason, but not practical at all, is that the concept conveys some
elegance and originality (each programming language should ideally have
a few of these)
Neal Norwitz wrote:
I ran 2.4.x through valgrind and found two small problems on Linux
that have been fixed. There may be some other issues which could
benefit from more eyes (small, probably one time memory leaks). The
entire run is here:
http://python.org/valgrind-2.4.2.out
(I need
Andrew Koenig wrote:
It is possible to imagine using the feature to catch some
type errors at the point of call, rather than having to get into the
function itself before detecting them.
There can certainly be value in type-checking parameters and
return values, but in this case, I think the
Andrew Koenig [EMAIL PROTECTED] writes:
The only practical reason to like this feature is sparing the need of
finding an otherwise useless name for the formal argument. Another
reason, but not practical at all, is that the concept conveys some
elegance and originality (each programming
Martin Blais [EMAIL PROTECTED] writes:
On 9/18/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 9/17/05, John J Lee [EMAIL PROTECTED] wrote:
c. Since time is needed to iron out bugs (and perhaps also to reimplememt
some pieces of code from scratch), very early in the life of Python 3
On 9/19/05, Michael Hudson [EMAIL PROTECTED] wrote:
I was disappointed that that article (hey, it was the only issue of
ddj I've ever actually bought! :) didn't consider any concurrency
models other than shared memory threading.
The problem is that, for all its limitations, shared-memory
* Martin Blais:
http://www.gotw.ca/publications/concurrency-ddj.htm
The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
Herb Sutter
March 2005
This piece is fundamentally wrong. We all have been writing
concurrent server-side software for eons. I don't know what Herb
* Guido van Rossum:
That assumes a very specific model for how all that MP power is going
to be used.
Indeed.
I personally don't think the threaded programming model as found in
Java works all that well; without locks you end up with concurrent
modification errors, with locks you get
Karl Chen writes:
Hi, has anybody considered adding something like this:
a = [1, 2]
[ 'x', *a, 'y']
as syntactic sugar for
a = [1, 2]
[ 'x' ] + a + [ 'y' ].
A bit later in the thread, Josiah Carlson replies:
I don't think the parser would get measureably more complex, but
On Monday 19 September 2005 16:36, Michael Chermside wrote:
I'd just like to point out that this is a FRF (Frequently Requested
Feature). I'm not arguing in favor of it, just pointing out that
using star unpacking in tuple and list literals is an idea that
I'm sure I've seen proposed at
Florian Weimer [EMAIL PROTECTED] writes:
By the way, has anybody ever tried to create a CPython variant which
uses a (mostly) copying garbage collector (or something else except
reference counting or Boehm GC)?
Not to my knowledge. I've always thought that it would be pretty
hard. I'd be
* Michael Hudson:
Not to my knowledge. I've always thought that it would be pretty
hard. I'd be interested in being proved wrong.
The real problem is that you can ditch most extension modules. 8-(
It sounds more like a fun project for the Python core, though.
Copying GC might help to get
Michael Hudson wrote:
How does a copying gc differ much from a non-copying non-refcounted gc
here?
One important issue for C coded modules is that addresses may change
when a GC is invoked, so no remembering addresses in your module; you
must recalculate before each use.
-- Scott David
On Mon, 2005-09-19 at 17:52, Scott David Daniels wrote:
Michael Hudson wrote:
How does a copying gc differ much from a non-copying non-refcounted gc
here?
One important issue for C coded modules is that addresses may change
when a GC is invoked, so no remembering addresses in your
Hello,
Well, we have for, while and if. We also have statements,
list generator expressions and list comprehensions. In
comprehensions we have the opportunity to use several for-s and in a
same expression (for i in range (0, 640) for j in range (0, 640)),
in loops we cannot; in
[Fred L. Drake]
Indeed, star unpacking has been brought up many times; I think it
would
be
really cool myself.
It might have a chance of acceptance this time if the proponents stick
with unpacking at the end: a,b,*c=sometup instead of a,*b,c=sometup.
The latter has usually gotten shot
I propose that in Py3.0, the and and or operators be simplified to
always return a Boolean value instead of returning the last evaluated
argument.
1) The construct can be error-prone. When an error occurs it can be
invisible to the person who wrote it. I got bitten in published code
that had
On 9/19/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
I propose that in Py3.0, the and and or operators be simplified to
always return a Boolean value instead of returning the last evaluated
argument.
While you're at it, maybe we should switch to and || as well?
That's another thing I always
[Raymond Hettinger]
I propose that in Py3.0, the and and or operators be simplified to
always return a Boolean value instead of returning the last evaluated
argument.
1) The construct can be error-prone. When an error occurs it can be
invisible to the person who wrote it. I got bitten in
Raymond Hettinger wrote:
I propose that in Py3.0, the and and or operators be simplified to
always return a Boolean value instead of returning the last evaluated
argument.
1) The construct can be error-prone. When an error occurs it can be
invisible to the person who wrote it. I got
On Mon, 2005-09-19 at 20:03, Guido van Rossum wrote:
While you're at it, maybe we should switch to and || as well?
That's another thing I always mistype when switching between
languages...
Please no! 'and' and 'or' is so readably beautiful.
Also, this proposal needs to be considered
P.S. Simplifying and and or may create a need to introduce a
conditional operator but that is a discussion for another day.
While I don't disagree with some of your main points, I do think that
your proposal would eliminate a natural and easy to understand use of
the current behavior of or
While I don't disagree with some of your main points, I do think that
your proposal would eliminate a natural and easy to understand use of
the current behavior of or that I tend to use quite a bit. Your
proposal would break a lot of code, and I can't think of a better
conditional
Steven Bethard wrote:
I guess if tuple unpacking in function parameters goes away, I think
we should change the __getitem__ machinery so that:
obj[x1, x2, ..., xN]
is translated to:
obj.__getitem__(x1, x2, ..., xN)
where __getitem__ would now have to take a *args when called
Terry Reedy wrote:
I consider the current situation to be a consistency feature. To a first
approximation, Python function calls 'pass' objects by name-binding:
param_name_list = arg_object_list
Disabling structure unpacking in this assignment would make the language
slightly more
Andrew Koenig wrote:
One other reason: It is possible to imagine using the feature to catch some
type errors at the point of call, rather than having to get into the
function itself before detecting them.
Not a big deal - you just need to look one line further
up in the traceback to find
On Mon, Sep 19, 2005, Jonathan LaCour wrote:
Raymond Hettinger:
P.S. Simplifying and and or may create a need to introduce a
conditional operator but that is a discussion for another day.
While I don't disagree with some of your main points, I do think that
your proposal would eliminate
Raymond Hettinger wrote:
I propose that in Py3.0, the and and or operators be simplified to
always return a Boolean value instead of returning the last evaluated
argument.
But then I would no longer be able to write
foo = something or default_value
which is one of my favourite Pythonisms!
Delaney, Timothy (Tim) wrote:
In addition, I would presume that relpath would just return the absolute
path if passed an absolute path as the second parameter.
I don't think so. Wouldn't you expect the
result of
relpath(/usr/local/foo/bax/grump.c, /usr/local/flump/grump.c)
to be
On 9/19/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Mon, 2005-09-19 at 20:03, Guido van Rossum wrote:
While you're at it, maybe we should switch to and || as well?
That's another thing I always mistype when switching between
languages...
Please no! 'and' and 'or' is so readably
3) Even when it isn't being used, the possibility of non-boolean
return
value complicates the bytecode and parser. To allow for and/or,
the
conditional opcodes leave the tested value on the stack. In most
cases
both branches go directly to a POP_TOP instruction. Since the
POP_TOP
Raymond Hettinger wrote:
I propose that in Py3.0, the and and or operators be simplified to
always return a Boolean value instead of returning the last evaluated
argument.
Please no. I find things like:
def __cmp__(self, other):
return (cmp(self.a, other.a) or
46 matches
Mail list logo
