"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> 2) When going back and forth between languages, it is easy to forget
> that only Python returns something other than a boolean.
Perl certainly works the same way and I've never heared anybody have
problems with that, but that might be because Perl
Hello Josiah,
JC> Alexander,
JC> The essence of what you have proposed has been proposed (multiple times)
before,
JC> and I seem to remember it was shot down.
To increase my understanding of Python-way, can you (or someone else)
explain the reasons why such proposals were rejected?
JC> The belo
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
> > 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_T
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.
>
> 1) The construct can be error-prone. When an error occurs it can be
> invisible
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
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 ".
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 Pytho
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 wo
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 wh
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 mor
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 wh
On Monday 19 September 2005 19:20, Raymond Hettinger wrote:
> 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 down quickly, taking the former down
> with it.
Tr
Greg Ewing wrote:
> Matthias Andreas Benkard wrote:
>
>> /home -> usr/home
>> /usr
>> /usr/home
>>
>> What does os.path.diff("/home/", "/usr/") yield? "../usr/", I would
>> presume? But that's obviously wrong:
>
> IMO, the relpath method should just work textually on
> the pathnames. It's up to
Matthias Andreas Benkard wrote:
> /home -> usr/home
> /usr
> /usr/home
>
> What does os.path.diff("/home/", "/usr/") yield? "../usr/", I would
> presume? But that's obviously wrong:
IMO, the relpath method should just work textually on
the pathnames. It's up to the user to ensure it makes
sense
>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
> 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
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
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
Alexander,
The essence of what you have proposed has been proposed (multiple times) before,
and I seem to remember it was shot down.
The below functions offer the equivalent of list comprehensions with a
final post-processing step.
def cross(*args):
if len(args) == 1:
for i in args[
[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 bi
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 thin
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
[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
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 com
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 yo
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 Danie
* 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 g
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 b
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
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 comple
* 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 d
* 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 He
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 t
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
"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 progra
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 th
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
> 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 the
> 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 pro
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
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.
--- Buc
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
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
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]
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). Comp
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:
>
> http://pytho
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
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
> shou
On Monday 2005-09-19 06:38, Josiah Carlson wrote:
> > > [ 'x', *a, 'y']
> > >
> > > as syntactic sugar for
> > >
> > > [ 'x' ] + a + [ 'y' ].
> > >
> > > Notes:
> > > - This is a common operation
> >
> > is it?
>
> Not in the code that I read/use. While "not all 3 line functions should
Sokolov Yura wrote:
> Would it be usefull to define new magic class variable __mixins__ for a
> new style classes, which
> will accept list of classes and will drop all members of them into
> definition of class before they went to metaclass.
First off, this is probably more appropriate for comp.l
Excuse my english.
Is there any pythonic way to make real mixin into a class?
Problem: Django model (and may be SQLObject).
I have a common peaces of model declaration. Sometimes they are in table
definition together,
sometimes table have just one of them. I cannot use inheritance,
cause Dja
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
Per
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 s
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 suppressio
55 matches
Mail list logo
