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
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 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
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
[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
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
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
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
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
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
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
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.
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, +
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
> 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
___
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
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
[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
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 -
"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
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
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
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
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
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
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
(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
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
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
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
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
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__
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
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
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
> 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
> > 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
> > 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
> 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
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
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
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 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-
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
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
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
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
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
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
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
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
> 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
__
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
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
54 matches
Mail list logo
