Jason Orendorff wrote:
> Honestly, I think I would prefer this syntax. Examples from real
> code, before and after:
>
> lines = [line for line in pr.block.body
> if line.logical_line.strip() != '']
> lines = [for line in pr.block.body:
> if line.logical_line
Brett Cannon <[EMAIL PROTECTED]> writes:
> On 9/20/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> [SNIP]
>> I _like_ the explanation of 'and' and 'or' as they are now. They are
>> basically control flow constructs -- and have to be to get
>> short-circuiting to work -- and adding a coercion to b
> I think I'd prefer (if then else ) i.e. no
> colons. None of the other expression forms (list comprehensions and
> generator expressions) involving statement keywords use colons.
FWLIW, this was my (strong) preference back at the time of the
original discussion.
--
g
__
Guido van Rossum <[EMAIL PROTECTED]> writes:
>> Given the later addition of generator expressions with mandatory
>> parentheses , the mandatory-parentheses version of a conditional expression
>> looks less strange to me than it did then ;-). So I could happily use it
>> even though I may still le
On Tue, 2005-09-20 at 22:43, Guido van Rossum wrote:
> On 9/20/05, John J Lee <[EMAIL PROTECTED]> wrote:
[...]
> I don't know that any chips are designed with threading in mind. Fast
> threading benefits from fast context switches which benefits from
> small register sets. I believe the trend is to
On Wed, 2005-09-21 at 11:10, Michael Hudson wrote:
> My problem with this syntax is that it can be hard to read:
>
> return if self.arg is None then default else self.arg
>
> looks worryingly like
>
> return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
>
> to me.
I think that requriing pa
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>
>>I think if we go with (if ... then ... else ...) or (if ...:
>>... else: ...) we'll have to support elif as well:
>>
>>(if ... then ... elif ... then ... else ...)
>>or
>>(if ...: ... elif ...: ... else: ...)
>
>
> One nice thing about "x if b e
I suppose this is a dead horse now, but I will kick it one more time.
Under the rubrics of "explicit is better than implicit" and "there should
only be one wat to do it", I would rather see
bool_val = bool(foo or bar)
instead of having the "or" operator implicitly call bool() for me. There
On 9/21/05, Donovan Baarda <[EMAIL PROTECTED]> wrote:
> The reality is threads were invented as a low overhead way of easily
> implementing concurrent applications... ON A SINGLE PROCESSOR. Taking
> into account threading's limitations and objectives, Python's GIL is the
> best way to support threa
Nick Coghlan wrote:
> Greg Ewing wrote:
>>One nice thing about "x if b else y" is that it
>>chains without needing any more keywords:
>>
>> x if b else y if c else z
>>
>>But if you require parens, it's not so nice:
>>
>> (x if b else (y if c else z))
> If Guido chose this form, I would expec
Michael Hudson wrote:
>Guido van Rossum <[EMAIL PROTECTED]> writes:
>
>
>
>>>Given the later addition of generator expressions with mandatory
>>>parentheses , the mandatory-parentheses version of a conditional expression
>>>looks less strange to me than it did then ;-). So I could happily use i
On Wed, 2005-09-14 at 15:25 -0400, Peter Jones wrote:
[ comments and a patch for sysmodule.c and some configure related files]
... and that patch has obvious problems as well.
Here's a corrected one:
--- Python-2.4.1/pyconfig.h.in.canonicalize 2005-09-14 11:47:04.0
-0400
+++ Python-
Adam wrote:
> So looking at a few alternatives ...
>
[snip]
> (e ? (e1 ? a1 : b1) : (e2 ? a2 : b2))
>
[snip]
> (if e, (if e1, a1 else b1) else (if e2, a2 else b2))
>
[snip]
> (if e then (if e1 then a1 else b1) else (if e2 then a2 else b2))
>
[snip
> (e selects (e1 selects a1 else b1) else (e2 selec
On 21 sep 2005, at 12.33, Donovan Baarda wrote:
> In the short term there will be various hacks to try and make the
> existing plethora of threading applications run better on multiple
> processors, but ultimately the overheads of shared memory will force
> serious multi-processing to use IPC chann
On 9/21/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Please no more syntax proposals! There were enough in the PEP. It
> looks like most people support a conditional expression of some sort.
> We need to leave the syntax to Guido. We've already proved that like
> the decorators discussions, w
> The best way to make people stop complaining about the GIL and start
> using
> process-based multiprogramming is to provide solid, standardized support
> for process-based multiprogramming.
100% agreed. I needed a portable way to know if a program was already
running (and then to send it a si
> > But this begs the question: What is relpath good for, anyway?
>
> A couple of use cases I've encountered:
>
Another one:
- Build tools that work with paths alot can really improve their log
readability if relative paths can be used to keep paths short rather
than the common fallback of
> > I think I'd prefer (if then else ) i.e. no
> > colons.
>
> My problem with this syntax is that it can be hard to read:
>
> return if self.arg is None then default else self.arg
>
> looks worryingly like
>
> return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
That can already be written
> The best way to make people stop complaining about the GIL and start
> using process-based multiprogramming is to provide solid, standardized
> support for process-based multiprogramming.
+100
Huge amounts of effort would have to be invested to remove the GIL for
the benefit of threads. Not
Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
>
> > The best way to make people stop complaining about the GIL and start
> > using
> > process-based multiprogramming is to provide solid, standardized support
> > for process-based multiprogramming.
>
> 100% agreed. I needed a portable way to kno
On Wed, 21 Sep 2005 02:55:56 +0200, Greg Ewing
<[EMAIL PROTECTED]> wrote:
> Both of these happen to involve pathnames that exist on
> the currrently available file system, but I can easily
> imagine cases where that would not be so. E.g. I might
> be generating pathames to go into a tar file that
On 21-sep-2005, at 0:10, Bob Ippolito wrote:
My use case for this isn't so much about threads, but plug-ins.
Writing multiple Python-based plug-ins for an application is always a
mess, because they share too much (sys.modules, sys.path, etc.).
PyObjC would benefit greatly from this feature, bec
Neal Norwitz wrote:
> (I need to write a lot more suppression rules for gentoo.)
This could be due to your using GCC 4. Apparently, gcc 4
is willing to inline Py_ADDRESS_IN_RANGE even though it
appears at the end of the file, at -O3.
To suppress that, you can declare the function as
__attribute__
BJörn Lindqvist <[EMAIL PROTECTED]> writes:
>> My problem with this syntax is that it can be hard to read:
>>
>> return if self.arg is None then default else self.arg
>>
>> looks worryingly like
>>
>> return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
>
> That can already be written in Pytho
On 9/21/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> Brett Cannon <[EMAIL PROTECTED]> writes:
>
> > On 9/20/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> > [SNIP]
> >> I _like_ the explanation of 'and' and 'or' as they are now. They are
> >> basically control flow constructs -- and have to be
I know I'm coming too late to this discussion, but just for completeness
sake let me mention that the OCaml standard List module uses 'partition'
already in the sense that most mathematically educated people would
understand it:
val partition : ('a -> bool) -> 'a list -> 'a list * 'a list
Guido:
When you invited resumed discussion, did you intend to proceed from where
the revised PEP left off (with a few variations on the table), or to start
over from point zero (with potentially anything and everything on the
table). In particular, do we need to rehash the reasons for rejectio
(Interestign to see the PyObjC folks disagree. :-)
On 9/21/05, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
>
> On 21-sep-2005, at 0:10, Bob Ippolito wrote:
> >
> > My use case for this isn't so much about threads, but plug-ins.
> > Writing multiple Python-based plug-ins for an application is always
I think a recap of past arguments is useful. Me-too votes are not. i
will read everything and pick a syntax and that's it. We can do it in
Python 2.5.
On 9/21/05, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Guido:
>
> When you invited resumed discussion, did you intend to proceed from where
> the rev
Bob Ippolito <[EMAIL PROTECTED]> writes:
> Personally my biggest issue with the way the CPython VM works is that
> you can't reliably do multiple interpreters in a single process. If
> that worked well, you could start an independent interpreter per
> thread and with a per-interpreter GIL y
Ron Adam wrote:
> ( e selects (e1 selects a1, b1),
> (e2 selects a2, b2),
> (e3 selects a3, b3) )
I think you've just reinvented the case statement, which
disagrees with "if" over the order of true and false clauses.
For a conditional expression, I think the c
On 21-sep-2005, at 21:04, Guido van Rossum wrote:
A system like Java's classloader would be helpfull, where the
classloader of a class is used to load the classes used by that
class. I have no idea if this can be adapted to python at all. A
strict coding style seems to work for now.
You can
Steven Bethard wrote:
> Please no more syntax proposals! There were enough in the PEP. It
> looks like most people support a conditional expression of some sort.
> We need to leave the syntax to Guido. We've already proved that like
> the decorators discussions, we can't as a community agree o
At 12:04 PM 9/21/2005 -0700, Guido van Rossum wrote:
>Actually Python itself has a hard time keeping multiple interpreters
>truly separate. Also of course there are some shared resources
>maintained by the operating system: current directory, open file
>descriptors, signal settings, child processes
"Christian Stork" <[EMAIL PROTECTED]>
wrote in message news:[EMAIL PROTECTED]
> On Tue, Aug 30, 2005 at 12:49:26PM +1200, Greg Ewing wrote:
>> A more descriptive name than 'partition' would be 'split_at'.
>
> 'split_at' is really what's happening. (I came up with it independently
> of Greg, if t
On 9/21/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> > (I need to write a lot more suppression rules for gentoo.)
>
> This could be due to your using GCC 4. Apparently, gcc 4
> is willing to inline Py_ADDRESS_IN_RANGE even though it
> appears at the end of the file, at -
[Guido van Rossum]
> Could you at least admit that this was an oversight and not try to
> pretend it was intentional breakage?
Absolutely. I completely missed this one.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
Jim Jewett wrote:
>
> (3) What order should the clauses appear?
> (if test then True else False)
> (if test1 then Val1 elif test2 Val2 elif test3 Val3 else Val4)
> + Natural Order
> - do we need "then"?
> (True if normal else False)
> (Val1 if test1 else Val2 if t
I agree with Skip.
Bill
> I suppose this is a dead horse now, but I will kick it one more time.
>
> Under the rubrics of "explicit is better than implicit" and "there should
> only be one wat to do it", I would rather see
>
> bool_val = bool(foo or bar)
>
> instead of having the "or" opera
> The best way to make people stop complaining about the GIL and start
> using
> process-based multiprogramming is to provide solid, standardized support
> for process-based multiprogramming.
And the model provided by the thread abstraction is a good API for that
support...
Bill
___
Raymond Hettinger wrote:
> The Boolean value of an
> iterator is certainly not promised by the iterator protocol as specified
> in the docs or the PEP.
But if the docs don't mention anything about true or
false values for some particular type, one tends to
assume that all values are true, as is t
Ron Adam wrote:
> (a if e then b)
> ((a1 if e1 then b1) if e then b)
> (a if e then (a2 if e2 then b2))
> ((a1 if e1 then b1) if e then (a2 if e2 then b2))
I think you mean 'else' rather than 'then' in all
those, don't you?
--
Greg Ewing, Computer Science Dept, +
Greg Ewing wrote:
> Ron Adam wrote:
>
>
>>(a if e then b)
>>((a1 if e1 then b1) if e then b)
>>(a if e then (a2 if e2 then b2))
>>((a1 if e1 then b1) if e then (a2 if e2 then b2))
>
>
> I think you mean 'else' rather than 'then' in all
> those, don't you?
Yes of course, thanks for correcting.
Gary Herron wrote:
> And in fact, one read and understands your return statement just like an
> English sentence -- word by word from beginning to end. This seems an
> argument FOR the syntax not against.Moreover, if one uses the
> proposed parenthesized syntax, even the slightly odd word
On 9/21/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Guido van Rossum]
> > Could you at least admit that this was an oversight and not try to
> > pretend it was intentional breakage?
>
> Absolutely. I completely missed this one.
Thanks; spoken like a man.
I strongly feel that this needs t
Terry Reedy wrote:
> Many people, perhaps most, including me, read
>
> exp1 if exp2 else exp3 # as
> cond if etrue else efalse # in direct analogy with
> cond ? etrue : efalse # from C
I'd have thought only Forth programmers would be prone to that!
It would surprise me greatly if it's real
The platform module has a way to map system names such as returned by
uname() to marketing names. It maps SunOS to Solaris, for example. But
it doesn't map Darwin to Mac OS X. I think I know how to map Darwin
version numbers to OS X version numbers: from
http://www.opensource.apple.com/darwinsource
On 9/21/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The platform module has a way to map system names such as returned by
> uname() to marketing names. It maps SunOS to Solaris, for example. But
> it doesn't map Darwin to Mac OS X. I think I know how to map Darwin
> version numbers to OS X ve
On Sep 21, 2005, at 11:26 PM, Guido van Rossum wrote:
> The platform module has a way to map system names such as returned by
> uname() to marketing names. It maps SunOS to Solaris, for example. But
> it doesn't map Darwin to Mac OS X. I think I know how to map Darwin
> version numbers to OS X ver
[Guido]
> I strongly feel that this needs to be corrected in 2.5. Iterators
> should have neither __len__ nor __nonzero__.
Right. I'll get it fixed-up.
[Terry Reedy]
> I presume there were two reasons: internal efficiency of
> preallocations
> (list(some_it) for example)
[Guido]
> This coul
Bill Janssen <[EMAIL PROTECTED]> wrote:
>
> > The best way to make people stop complaining about the GIL and start
> > using
> > process-based multiprogramming is to provide solid, standardized support
> > for process-based multiprogramming.
>
> And the model provided by the thread abstraction
On 9/20/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Matthias Andreas Benkard wrote:
>
> * In a recent project, I had occasion to store pathnames of
>picture files in a relational database. I wanted to store
>the pathnames relative to a user-chosen "Pictures"
>directory, so that it could
Neal Norwitz wrote:
> I wonder if using attributes for other features would gain us much. I
> would really like to be able to use attributes for
> PyArgs_ParseTuple(), but I don't think gcc can use user defined
> formats. It's only printf AFAIR. Does anyone know if this isn't true
> and we can d
On 22-sep-2005, at 5:26, Guido van Rossum wrote:
The platform module has a way to map system names such as returned by
uname() to marketing names. It maps SunOS to Solaris, for example. But
it doesn't map Darwin to Mac OS X. I think I know how to map Darwin
version numbers to OS X version numbe
54 matches
Mail list logo
