Steve Holden wrote:
> I *have* been surprised by the amount on brainpower that's been
> expended on this discussion.
number of posts != amount of brainpower
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
Steve Holden wrote:
> Except that if you have iPython installed on Windows you *don't* enter
> the platform EOF any more, you enter CTRL/D (which threw me for a
> while).
To be fair, that's due to the win32 readline library used by ipython, which
modifies console handling. IPython itself doesn't
Guido van Rossum wrote:
> On 12/27/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
>>but now we're back to today's situation:
>>
>>>>> quit
>>'Use Ctrl-Z plus Return to exit.'
>>
>>which violates the basic "if you know what I mean, why the /!"&/&!//%¤
>>don't you do what I say" usability ru
Guido van Rossum wrote:
> > but now we're back to today's situation:
> >
> > >>> quit
> > 'Use Ctrl-Z plus Return to exit.'
> >
> > which violates the basic "if you know what I mean, why the /!"&/&!//%¤
> > don't you do what I say" usability rule.
>
> What nonsense. Every Python programmer
On 12/27/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> but now we're back to today's situation:
>
> >>> quit
> 'Use Ctrl-Z plus Return to exit.'
>
> which violates the basic "if you know what I mean, why the /!"&/&!//%¤
> don't you do what I say" usability rule.
What nonsense. Every Pytho
On Wed, Dec 28, 2005, Brett Cannon wrote:
> On 12/28/05, Aahz <[EMAIL PROTECTED]> wrote:
>>
>> Here's yet a different take on this: why not simply change the startup
>> message? Whether we choose "quit" or "exit", someone will get it wrong
>> unless there's an alias. Changing the message is free.
On 12/28/05, Aahz <[EMAIL PROTECTED]> wrote:
> Here's yet a different take on this: why not simply change the startup
> message? Whether we choose "quit" or "exit", someone will get it wrong
> unless there's an alias. Changing the message is free. Currently we
> have
>
> Type "help", "copyri
Noam Raphael <[EMAIL PROTECTED]> wrote:
>
> On 12/29/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > What could be done is to add a test for excess dummy entries and trigger
> > a periodic resize operation. That would make the memory available for
> > other parts of the currently running sc
Here's yet a different take on this: why not simply change the startup
message? Whether we choose "quit" or "exit", someone will get it wrong
unless there's an alias. Changing the message is free. Currently we
have
Type "help", "copyright", "credits" or "license" for more information.
Let'
> "Martin" == Martin v Löwis <[EMAIL PROTECTED]> writes:
Martin> That would assume that the user knows that exit is a
Martin> function: apparently, people expect it to be a statement
Martin> (like print),
Oh, the irony of that analogy!
Martin> or they are entirely unaware of
[Martin v. Löwis]
> ...
> One challenge is that PyObject_GC_Del doesn't know how large the
> memory block is that is being released. So it is difficult to find out how
> much memory is being released in the collection.
"Impossible in some cases" is accurate. When pymalloc isn't enabled,
all these
Reinhold Birkenfeld wrote:
> Fredrik Lundh wrote:
>> Walter Dörwald wrote:
>>
>>> We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook?
>>> sys.inputhook gets passed each line entered and may return True if it has
>>> processed the line inself and False if normal handling of the
Martin v. Löwis <[EMAIL PROTECTED]> wrote:
> One challenge is that PyObject_GC_Del doesn't know how large the memory
> block is that is being released. So it is difficult to find out how
> much memory is being released in the collection.
Another idea would be to add accounting to the PyMem_* inter
Adal Chiriliuc wrote:
> MSVC 7.1 and 8.0 malloc always uses the Windows heap functions
> (HeapAlloc & friends) if running on Windows 2000 or newer
> (malloc.c and heapinit.c).
>
> So it seems that for both Linux (gcc) and Win (msvc) the memory is
> released to the operating system.
How so? HeapFr
Ralf W. Grosse-Kunstleve wrote:
> - there is only one FILE* that is seen by Visual C++. It appears in the
> signature of a function assigned to the tp_print slot. As far as I can tell
> this is the only soft spot. I'll lobby for having the print function removed
> since it is optional and both tp_s
I did a little test using MSVC 8.0 on WinXP.
I allocated 128 MB using 128 different buffers of 1 MB each,
freed half of them (alternatively) then freed the remaining half.
I monitored memory usage using the Task Manager and memory is really
freed as indicated by both the "Mem Usage" and "VM Size"
On 12/29/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Noam Raphael wrote:
> > The computer scientist in me prefers O() terms over changes in a
> > constant factor, but that's only me.
>
> That remark, I don't understand. In a hash table, most "simple"
> operations are O(n) as the worst-case t
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Well, yes: the areas are
> - memory management
> - stdio
> - locales
> for the C library; for the C++, I'm not so sure, but I think one of the
> areas is
> - static members of class templates, in particular in STL containers
Thanks for the insigh
On Thursday, December 29, 2005 "Martin v. Löwis" wrote:
> Noam Raphael wrote:
> In this specific case, perhaps. malloc will typically return memory to
> the system only if that memory is at the end of the heap. If there
> is more memory after block to be released, it can't return the memory
> bloc
Noam Raphael wrote:
> The computer scientist in me prefers O() terms over changes in a
> constant factor, but that's only me.
That remark, I don't understand. In a hash table, most "simple"
operations are O(n) as the worst-case time, except for operations
that may cause resizing, which are O(n**2)
On 12/29/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> What could be done is to add a test for excess dummy entries and trigger
> a periodic resize operation. That would make the memory available for
> other parts of the currently running script and possibly available for
> the O/S.
>
> The d
Noam Raphael wrote:
> I checked - when doing the same thing with lists, all the memory was
> released for use by other Python objects, and most of it was released
> for use by the operating system.
In this specific case, perhaps. malloc will typically return memory to
the system only if that memor
On 12/29/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> If "makes no sense" means "would not make a difference", then you
> are wrong. Objects in a set are not necessarily unmodifiable;
> they just have to be hashable.
>
Oh, you are right. I thought so much about dropping default hash=id,
or mo
> > It's very difficult to do something useful about it. Even if
> > you manage to determine how much memory you want to release,
> > it's nearly impossible to actually release the memory to the
> > operating system, because of the many layers of memory
> > management software that all need to agre
On 12/29/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Noam Raphael wrote:
> > Should something be done about it?
>
> It's very difficult to do something useful about it. Even if
> you manage to determine how much memory you want to release,
> it's nearly impossible to actually release the mem
Noam Raphael wrote:
> Perhaps it bothers the programmer with something that shouldn't bother
> him. I mean that I might do help(set.copy), and then think, "Oh, it
> returns a shallow copy. Wait a minute - 'shallow' means that I get a
> new object, which references the same objects as the old one. P
Noam Raphael wrote:
> Should something be done about it?
It's very difficult to do something useful about it. Even if
you manage to determine how much memory you want to release,
it's nearly impossible to actually release the memory to the
operating system, because of the many layers of memory
man
On 12/29/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Noam Raphael wrote:
> > is currently "Return a shallow copy of a set."
> >
> > Perhaps "shallow" should be removed, since set members are supposed to
> > be immutable so there's no point in a deep copy?
>
> That still doesn't make copy ret
Andrea Arcangeli wrote:
> If there's anybody willing to suggest the files to hook into (the
> location where the interpreter allocates all anonymous memory) and how
> to invoke gc.collect() from C, that would help. thanks!
It all happens in Modules/gcmodule.c:_PyObject_GC_Malloc. There are
per-gen
Hello,
If I do something like this:
s = set()
for i in xrange(100):
s.add(i)
while s:
s.pop()
gc.collect()
the memory consumption of the process remains the same even after the pops.
I checked the code (that's where I started from, really), and there's
nothing in set.pop or set.remo
Ralf W. Grosse-Kunstleve wrote:
> However, we don't have any home-grown
> C++ GUI code. Could it be that problems due to mixing objects from different
> compiler versions are restricted to certain areas, like GUI libraries?
Well, yes: the areas are
- memory management
- stdio
- locales
for the C l
Noam Raphael wrote:
> is currently "Return a shallow copy of a set."
>
> Perhaps "shallow" should be removed, since set members are supposed to
> be immutable so there's no point in a deep copy?
That still doesn't make copy return a deep copy, right? "shallow copy"
is more precise than "copy", an
On Wed, Dec 28, 2005 at 05:52:06AM -0800, Aahz wrote:
> If you feel comfortable with C code, the best way to get this to happen
> would be to make the change yourself, then test to find out what effects
I'm more confortable with C code than with python code, that's not the
problem (infact I think
On Wed, Dec 28, 2005 at 03:32:29PM +0100, "Martin v. Löwis" wrote:
> you should really consider comming up with a patch yourself. Bonus
> points if the code integrates with the current strategies, instead
> of replacing them.
As I wrote in the first email, I've no intention to replace anything.
Th
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> P.P.S. You do know that this configuration (extension compiled
> with VS2005, Python compiled wit VS.NET2003) is not supported,
> right?
Thanks to Adal's help I got all our C++ extensions (about 50) to work with VC8.
I am using Python 2.4.2 compil
is currently "Return a shallow copy of a set."
Perhaps "shallow" should be removed, since set members are supposed to
be immutable so there's no point in a deep copy?
Noam
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
Hi Marc,
On Wed, Dec 28, 2005 at 09:56:43PM +0100, M.-A. Lemburg wrote:
> > d += 1.2
> > d
> >> NotImplemented
>
> The PEP documenting the coercion logic has complete tables
> for what should happen:
Well, '+=' does not invoke coercion at all, with new-style classes like
Decimal.
> Look
[Martin v. Löwis]
> ...
> Unfortunately, it doesn't work at all, because svn_buildbot.py does
> not report branches on which a change happened, so if you have multiple
> schedulers for a subversion source, they either all build when a change
> occurs, or none of them.
>
> If svn_version knew about
On 12/29/05, Robert Brewer <[EMAIL PROTECTED]> wrote:
>
> Just to keep myself sane...
>
> def date_range(start=None, end=None):
> if start == None:
> start = datetime.date.today()
> if end == None:
> end = datetime.date.today()
> return end
Title: RE: [Python-Dev] Keep default comparisons - or add a second set?
Noam Raphael wrote:
> I don't think that every type that supports equality
> comparison should support order comparison. I think
> that if there's no meaningful comparison (whether
> equality or order), an exception shoul
Jean-Paul Calderone wrote:
> I guess the config for this particular behavior would look something
> like...
You were right that I needed two schedulers for that.
Unfortunately, it doesn't work at all, because svn_buildbot.py does
not report branches on which a change happened, so if you have mult
Armin Rigo wrote:
> Hi Facundo,
>
> On Sat, Dec 24, 2005 at 02:31:19PM -0300, Facundo Batista wrote:
> d += 1.2
> d
>> NotImplemented
>
> The situation appears to be a mess. Some combinations of specific
> operators fail to convert NotImplemented to a TypeError, depending on
> old- or ne
Fredrik Lundh wrote:
> Walter Dörwald wrote:
>
>> We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook?
>> sys.inputhook gets passed each line entered and may return True if it has
>> processed the line inself and False if normal handling of the input should be
>> done. This all
Jean-Paul Calderone wrote:
> A slave is an entity capable of performing tasks. It can be
> asked to perform any task you like, though it may not be able
> to perform them all if it lacks some requirements.
This is clear in principle. However, what constitutes a "task"?
I see that you can send i
[Alex Martelli]
>On Dec 28, 2005, at 3:24 AM, Michael Hudson wrote:
>> [EMAIL PROTECTED] writes:
>>> Fredrik> a quit/exit command that actually quits, instead of
>>> Fredric> printing a "you didn't say please!" message.
>>> I like Fredrik's idea more and more.
>> The thing that bother
Alex Martelli wrote:
>
> On Dec 28, 2005, at 3:24 AM, Michael Hudson wrote:
>> The thing that bothers me about it is that the standard way you tell
>> python to do something is "call a function" -- to me, a special case
>> for exiting the interpreter seems out of proportion.
>
> Just brainstorm
Walter Dörwald wrote:
> We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook?
> sys.inputhook gets passed each line entered and may return True if it has
> processed the line inself and False if normal handling of the input should be
> done. This allows special treatment of "qui
I wrote:
> all() can be terminated at the first false element. For very long
> sequences this has important performance benefits. Besides, it makes
> all(seq,pred) the equivalent of pred(seq[0]) and pred(seq[1]) and
> pred(seq[2]) and ...
then, Martin v. Löwis wrote:
>
> And so does the version w
> > > I think it should be ok because it's never used
> > > really as a PyObject. Am I missing something? (Ok, I now thought
that
> > > maybe it's because some parts don't treat dummy elements
specially.
> > > But it seems to me that most parts do treat them specially, so
perhaps
> > > it would be
On 12/28/05, Walter Dörwald <[EMAIL PROTECTED]> wrote:
...
> We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook?
Sure, particularly with Nick's suggestion for a default input hook it
would be fine.
> > sessions in which I want to perform some action repeatedly, and
> > cur
> The setentry typedef clearly violates the principles of the API, so
> it should be renamed.
In my next update, will rename it to match the Py or _Py convention.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
On Wed, 28 Dec 2005 17:43:04 +0100, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
>Tim Peters wrote:
>> Someone sets up a "buildbot master"
>
>That's what I now did:
>
>http://www.python.org/dev/buildbot/
>
>I'm not quite sure on a number of concepts: should there
>be multiple "slaves" per "bui
Martin> If anybody wants to contribute additional builders, or has ideas
Martin> for organizing this all, please let me know.
Martin,
I installed buildbot on a dual-processor Powermac G5 running OSX 10.3.9
(montanaro-g5.dyndns.org). Let me know the parameters I need to give to the
build
[Alex]
>> Just brainstorming, but -- maybe this means we should generalize the idea?
>> I.e., allow other cases in which "just
>> mentioning X" means "call function Y [with the following arguments]", at
>> least at the interactive prompt if not more
>> generally. If /F's idea gets
>> impl
Alex Martelli wrote:
> On Dec 28, 2005, at 3:24 AM, Michael Hudson wrote:
>
>> [EMAIL PROTECTED] writes:
>>
>>> Fredrik> a quit/exit command that actually quits, instead of
>>> printing a
>>> Fredrik> "you didn't say please!" message.
>>>
>>> I like Fredrik's idea more and more.
>>
>> The
Tim Peters wrote:
> Someone sets up a "buildbot master"
That's what I now did:
http://www.python.org/dev/buildbot/
I'm not quite sure on a number of concepts: should there
be multiple "slaves" per "builder"? Should I have multiple
factories? How should I pass build-machine specific information
On Wednesday 28 December 2005 10:59, Alex Martelli wrote:
> (The Italian closest word "paio" would imply that the two items are
> in some sense "homogeneous"; to avoid that implication one would use
> "coppia", which differently from English "a couple" ALWAYS, not just
> sometimes, implies exac
On Dec 28, 2005, at 3:24 AM, Michael Hudson wrote:
> [EMAIL PROTECTED] writes:
>
>> Fredrik> a quit/exit command that actually quits, instead of
>> printing a
>> Fredrik> "you didn't say please!" message.
>>
>> I like Fredrik's idea more and more.
>
> The thing that bothers me about it
On Dec 28, 2005, at 2:57 AM, Martin v. Löwis wrote:
> Phillip J. Eby wrote:
>> Since I routinely use 2-item tuples (twoples?)
>
> I've been using "pairs" to describe that datatype. Not sure
> how common it is in English, but in German, "Zweitupel"
> is often called "Paar".
I use 'pair', too, adm
On Sun, Dec 25, 2005 at 12:54:32PM -0500, Tim Peters wrote:
> This really helps at Zope Corp. One downside is that we seem unable
> to get an in-house Windows buildbot slave to work reliably, and so far
> don't even know whether that's because of Windows, the buildbot code,
> or flakiness in our i
On Dec 27, 2005, at 11:06 PM, Eric Nieuwland wrote:
...
>>> def zerop(x):
>>> return x==0
>>>
>>> all(some_objects, zerop)
>>
>> and why would that be better than
>> all(o==0 for o in some_objects)
>> ?
>
> all() can be terminated at the first false element. For very long
> sequences this
On 12/28/05, Noam Raphael <[EMAIL PROTECTED]> wrote:
> On 12/28/05, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Speaking of id, there's no reason why "id(a) == id(b)" has to fail for
> > mismatched types in the face of persistence so long as the result of
> > id() has the same lifetime as the target
Early bird registration for PyCon TX 2006 ends on December 31st,
so there are only a few days LEFT. To register, please visit:
http://us.pycon.org/TX2006/Registration
You can still register after Dec. 31st, but the cost will go up by
US$65 (US$25 for students).
This year PyCon will featu
On 12/28/05, Adam Olsen <[EMAIL PROTECTED]> wrote:
> I agree for greaterthan and lessthan operators but I'm not convinced
> for equality. Consider this in contrast to your example:
> >>> a = 1+2j
> >>> b = 1+2j
> >>> a is b
> False
> >>> a == b
> True
>
> Complex numbers can't be sorted but they c
On 12/28/05, Noam Raphael <[EMAIL PROTECTED]> wrote:
> And another example:
>
> >>> a = 1+2j
> >>> b = 2+1j
> >>> a > b
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: no ordering relation is defined for complex numbers
>
> I came to think that, when forgetting backwards
Andrea Arcangeli wrote:
> To implement this we need two hooks, in the malloc and free that
> allocate python objects. Then we have to store the minimum of this
> value (i.e. the last minimum of memory allocated by the interpreter).
I would like to underline Aahz' comment: it is unlikely that anyth
Michael Hudson wrote:
> The thing that bothers me about it is that the standard way you tell
> python to do something is "call a function" -- to me, a special case
> for exiting the interpreter seems out of proportion.
That would assume that the user knows that exit is a function:
apparently, peop
Fredrik Lundh wrote:
> this is done in site.py, before sitecustomize is loaded. I'm not sure
> how anyone else would be able to squeeze in an excepthook at this
> point, even if they wanted...
I see. Still, I think the Python code should give a good example.
There *is* an excepthook installed at
On Wednesday, December 28, 2005 Noam Raphael wrote:
> I came to think that, when forgetting backwards compatibility for a
> while, the best thing for comparison operators to do is to raise a
> TypeError by default, and work only for types that it makes sense to
> compare. I think it is more "explic
On Tue, Dec 27, 2005, Andrea Arcangeli wrote:
>
> My suggestion to fix this problem in autopilot mode (without requiring
> explicit gc.collect()) is to invoke a gc.collect() (or anyway to go
> deep down freeing everything possible) at least once every time the
> amount of anonymous memory allocated
And another example:
>>> a = 1+2j
>>> b = 2+1j
>>> a > b
Traceback (most recent call last):
File "", line 1, in
TypeError: no ordering relation is defined for complex numbers
I came to think that, when forgetting backwards compatibility for a
while, the best thing for comparison operators to d
Fredrik> if isinstance(exc_value, NameError) and not exc_info.tb_next:
Fredrik> text = exc_value[0]
Fredrik> name = ... extract name from nameerror string ...
Fredrik> if sys.commandline.strip() == name:
Fredrik> if name in ("exit", "quit
Michael Hudson wrote:
> > that would turn exit and quit into reserved keywords.
>
> In what sense? Not in the sense of "things in single quotes in
> Grammar"...
no, but in the sense of "names that can no longer be used in code"
>>> def exit():
... print "bye"
>>> # what is it?
Hello,
I run into a problem recently with a reconnectingclientfactory with
twisted while write some spare time software, that turned out to be a gc
inefficiency.
In short the protocol memory wasn't released after the reconnect and the
protocol had about 50M attached to it. So with frequent reconn
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> In other news, clever hacks with tb_next and so on also seem
>> excessive. Why not have the equivalent of "if input.rstrip() ==
>> 'exit': sys.exit()" in the implementation of the interactive
>> interpreter?
>
> that would t
Noam Raphael wrote:
>>The setentry typedef clearly violates the principles of the API, so
>>it should be renamed.
>
> (And so will _setobject, although I think it will be much easier to remove
> it.)
That's not that certain. setentry is a typedef; _setobject is a tag
name of a struct. The docume
On 12/28/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> The setentry typedef clearly violates the principles of the API, so
> it should be renamed.
(And so will _setobject, although I think it will be much easier to remove it.)
>
> > Perhaps the header file should stick
> > with writing "stru
Michael Hudson wrote:
> In other news, clever hacks with tb_next and so on also seem
> excessive. Why not have the equivalent of "if input.rstrip() ==
> 'exit': sys.exit()" in the implementation of the interactive
> interpreter?
that would turn exit and quit into reserved keywords.
Michael Hudson wrote:
> [EMAIL PROTECTED] writes:
>
>
>>Fredrik> a quit/exit command that actually quits, instead of printing a
>>Fredrik> "you didn't say please!" message.
>>
>>I like Fredrik's idea more and more.
>
>
> The thing that bothers me about it is that the standard way you te
[EMAIL PROTECTED] writes:
> Fredrik> a quit/exit command that actually quits, instead of printing a
> Fredrik> "you didn't say please!" message.
>
> I like Fredrik's idea more and more.
The thing that bothers me about it is that the standard way you tell
python to do something is "call a
someone recently broke floating point literals in a rather spectacular
way:
$ export LANG=sv_SE.utf8
$ ./python
Python 2.5a0 (41806M, Dec 25 2005, 12:12:29)
Type "help", "copyright", "credits" or "license" for more information.
>>> 3.14
3.1401
>>> import locale
>>> locale.setlocale(loc
Martin v. Löwis wrote:
> Introducing sys.commandline is fine; overriding sys.excepthook
> still worrisome.
>
> What's wrong with triggering this in some __repr__ implementation?
because simple introspection may exit your program. unexpected
exits are a lot more annoying than unexpected non-exits
Neal Norwitz <[EMAIL PROTECTED]> writes:
> On 12/23/05, Tim Peters <[EMAIL PROTECTED]> wrote:
>> _assumed_ this was known damage everywhere so was waiting for someone
>> else to fix it ;-) (A parenthentical question: is there a reason you
>> don't pass -uall to regrtest.py?)
>
> It's calling mak
Phillip J. Eby wrote:
> Since I routinely use 2-item tuples (twoples?)
I've been using "pairs" to describe that datatype. Not sure
how common it is in English, but in German, "Zweitupel"
is often called "Paar".
Regards,
Martin
___
Python-Dev mailing lis
Tim Peters wrote:
> You seem to be ignoring possiblities for sharing across lists, and
> such sharing is natural in many graph algorithms.
No doubt cons cells are a useful construct. I think Martin Blais
(and others) advocated a plain list container type, only implemented
as a linked list, instead
Jeremy Kloth wrote:
> Ka-Ping Yee wrote:
> > I'd be happy with having Python exit when the user types just plain
> > 'exit' without parentheses, but only in that case, not others.
> > However, i'm starting to think that may be impossible to implement.
> > I can't think of any way to make 'print ex
Fredrik Lundh wrote:
> any suggestions on how to improve this ?
Introducing sys.commandline is fine; overriding sys.excepthook
still worrisome.
What's wrong with triggering this in some __repr__ implementation?
If an excepthook must be installed, why couldn't the previous
excepthook be preserved
Ka-Ping Yee wrote:
> I'd be happy with having Python exit when the user types just plain
> 'exit' without parentheses, but only in that case, not others.
> However, i'm starting to think that may be impossible to implement.
> I can't think of any way to make 'print exit' not exit, for example.
OK,
Noam Raphael wrote:
> Is this desirable?
Not sure what "this" refers to in your message: the text of the C API
documentation certainly is desirable as it stands (although it should
be clearer as to whether struct names should be prefixed).
The setentry typedef clearly violates the principles of
Martin v. Löwis wrote:
> > In short, I think it makes a lot of sense to support a bare "exit" and/or
> > "quit" as a completely intuitive platform-independent newbie-friendly way to
> > exit the interpreter.
>
> I can readily agree to this part of Fredrik's proposal. What slightly
> bothers me is
On 12/27/05, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Tell me:
> >>> a = [0] * 3
> >>> b = [0] * 3
> >>> a[0] = b
> >>> b[0] = a
>
> What order should a and b have?
More gems:
>>> Decimal(3) < 4.0
False
>>> Decimal(3) == 3.0
False
>>> Decimal(3) > 4.0
True
And the pièce de résistance:
Eric Nieuwland wrote:
>>all(o==0 for o in some_objects)
>>?
>
>
> all() can be terminated at the first false element. For very long
> sequences this has important performance benefits. Besides, it makes
> all(seq,pred) the equivalent of pred(seq[0]) and pred(seq[1]) and
> pred(seq[2]) and ...
[EMAIL PROTECTED] wrote:
> In short, I think it makes a lot of sense to support a bare "exit" and/or
> "quit" as a completely intuitive platform-independent newbie-friendly way to
> exit the interpreter.
I can readily agree to this part of Fredrik's proposal. What slightly
bothers me is the hackis
[EMAIL PROTECTED] wrote:
> Fredrik> a quit/exit command that actually quits, instead of printing a
> Fredrik> "you didn't say please!" message.
>
> I like Fredrik's idea more and more. Without my Unix bifocals it wouldn't
> occur to me that Ctrl-D is the way to exit. Knowing Ctrl-Z is EO
94 matches
Mail list logo
