[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 EOF on
[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 hackish
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 ...
And so
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:
l = [2.0, Decimal(3), 3.5,
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 the hackish
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
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,
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
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 exit' not
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
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 list
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 make test.
You
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.
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(locale.LC_ALL, )
[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 function
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 tell
python to do
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.
/F
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 struct { long
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
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 turn exit and quit
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
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?
exit
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):
And another example:
a = 1+2j
b = 2+1j
a b
Traceback (most recent call last):
File stdin, line 1, in module
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
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 by
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 explicit
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
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, people
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
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 stdin, line 1, in module
TypeError: no ordering relation is defined for complex numbers
I came to think that, when forgetting backwards
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 can be tested for
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
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 object.
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 has important
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
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, admittedly by
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 is that 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
(like:
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 thing that bothers me about
[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
implemented by
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 builder? Should I have
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
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
currently
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 better to make
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 with
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 quit,
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 brainstorming, but --
[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 bothers me about it is
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 it
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 allows
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
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
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 should
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 - start
[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
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.
Looking at the code in
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
--- 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 compiled
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.
The
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
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, and correct -
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
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
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
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 return a deep copy,
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
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.
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 memory to the
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 agree that
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 more
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 memory
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 downside
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 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
block,
--- 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 insight! For
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
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_str
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_*
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 input should
[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
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!wink
Martin or they are entirely unaware of the
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's add
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 script and
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 Python programmer
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 knows that the right
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 rule.
What nonsense.
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
87 matches
Mail list logo
