that my importer
works, because if it fails things might be done by the built-in importer
and I won't notice. These parts can be removed, of course.)
Do you think that it might be useful? Maybe something like that can go
into the examples section of the imp module?
Thanks,
Noam Raphael
import imp
, Class.func = staticmethod(func), and Class.func
= func, don't behave by this rule. If the suggestions are accepted,
both will.
I just think it's simpler and cleaner that way. Just making
staticmethods callable would solve my practical problem too.
Noam Raphael
and is more consistent with the general convention, that running
A = B
causes
A == B
to be true. Currently, Class.func = staticmethod(func), and Class.func
= func, don't behave by this rule. If the suggestions are accepted,
both will.
Well, given that attribute assignment can be
On 5/30/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Noam's suggestion seems reasonable to me, but I'm not
sure what the performance implications are.
I think that they are not critical. The number of lines can grow by at
most twice, because shorter words would not have a line of their own.
The
: if the
excellent development environment IDLE can't develop inside standard
Python, it should be developed outside it. As I said, I prefer the
first option.
Have a good week,
Noam Raphael
___
Python-Dev mailing list
Python-Dev@python.org
http
On 9/11/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 9/10/05, Noam Raphael [EMAIL PROTECTED] wrote:
I and my colleges use IDLE intensively - that is, a heavily patched
IDLE. It includes my patch and many other improvements made by me and
my friends.
The improved IDLE is MUCH better
Hello,
I have thought about freezing for some time, and I think that it is a
fundamental need - the need to know, sometimes, that objects aren't
going to change.
This is mostly the need of containers. dicts need to know that the
objects that are used as keys aren't going to change, because if
That might be reasonable. I just noticed that it is convenient to do
svn propset svn:ignore -F .cvsignore .
Without a file, I wouldn't know how to edit the property, so I would
probably do
svn propget svn:ignore . ignores
vim ignores
svn propset svn:ignore -F ignores .
rm ignores
Hello,
It seems that we both agree that freezing is cool (-; . We disagree on
whether a copy-on-write behaviour is desired. Your arguments agains
copy-on-write are:
1. It's not needed.
2. It's complicated to implement.
But first of all, you didn't like my use cases. I want to argue with that.
Hello,
I have slept quite well, and talked about it with a few people, and I
still think I'm right.
About the users-changing-my-internal-data issue:
Again, user semantics. Tell your users not to modify entries, and/or
you can make copies of objects you return. If your users are too daft
to
On 10/31/05, Josiah Carlson [EMAIL PROTECTED] wrote:
...
And I'm going to point out why you are wrong.
I still don't think so. I think that I need to reclarify what I mean.
About the users-changing-my-internal-data issue:
...
You can have a printout before it dies:
I'm crashing your program
I thought about something -
I think that the performance penalty may be rather small - remember
that in programs which do not change strings, there would never be a
need to copy the string data at all. And since I think that usually
most of the dict lookups are for method or function names,
On 11/1/05, Josiah Carlson [EMAIL PROTECTED] wrote:
...
I am an advocate for PEP 351. However, I am against your proposed
implementation/variant of PEP 351 because I don't believe it ads enough
to warrant the additional complication and overhead necessary for every
object (even tuples would
On 11/1/05, Reinhold Birkenfeld [EMAIL PROTECTED] wrote:
Hmm, using the function's own namespace is an interesting idea. It
might also be a good place to put other functionals:
results = f.map(data)
newf = f.partial(somearg)
And we have solved the map, filter and reduce are
On 11/1/05, Josiah Carlson [EMAIL PROTECTED] wrote:
...
I still consider it dead.
If the implementation is hard to explain, it's a bad idea.
It is sometimes true, but not always. It may mean two other things:
1. The one trying to explain is not talented enough.
2. The implementation is
Hello,
While writing my PEP about unifying mutable and immutable, I came upon this:
Is there a reason why the default __hash__ method returns the id of the objects?
It is consistent with the default __eq__ behaviour, which is the same
as is, but:
1. It can easily become inconsistent, if
Thank you for your encouraging words!
I am currently working on a PEP. I am sure that writing it is a good
idea, and that it would help with explaining this idea both to others
and to myself.
What I already wrote makes me think that it can be accomplished with
no really large changes to the
On 11/2/05, Josiah Carlson [EMAIL PROTECTED] wrote:
...
A quick search in the list archives via google search
site:mail.python.org object __hash__
Says that Guido wanted to remove the default __hash__ method for object
in Python 2.4, but that never actually happened.
I think it should.
(I copy here messages from the thread about the default hash method.)
On 11/2/05, Michael Chermside [EMAIL PROTECTED] wrote:
Why not make the default __eq__ really compare the objects, that is,
their dicts and their slot-members?
Short answer: not the desired behavior.
I've looked for classes in my /usr/lib/python2.4 directory. I won't go
over all the 7346 classes that were found there, but let's see:
identity objects that will continue to work because they contain
other identity objects
SocketServer, and everything which inherits from
On 11/2/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
Should the default equality operator compare valuesinstead of
identities?
No. Look back into last year's python-dev postings where we agreed that
identity would always imply equality. There were a number of practical
reasons. Also,
On 11/3/05, Greg Ewing [EMAIL PROTECTED] wrote:
3. If someone does want to associate values with objects, he can
explicitly use id:
dct[id(x)] = 3.
This is fragile. Once all references to x are dropped,
it is possible for another object to be created having
the same id that x used to
On 11/3/05, Josiah Carlson [EMAIL PROTECTED] wrote:
...
Right, but lists (dicts, tuples, etc.) are defined as containers, and
their comparison operation is defined on their contents. Objects are
not defined as containers in the general case, so defining comparisons
based on their contents
On 11/5/05, Josiah Carlson [EMAIL PROTECTED] wrote:
...
1. It doesn't add complexity, or a new builtin.
It changes default behavior (which I specified as a portion of my
statement, which you quote.
And you are wrong, it adds complexity to the implementation of both
class instantiation and
On 11/6/05, Josiah Carlson [EMAIL PROTECTED] wrote:
...
Sorry, I meant complexity to the Python user - it won't require him to
learn more in order to write programs in Python.
Ahh, but it does add complexity. Along with knowing __doc__, __slots__,
__metaclass__, __init__, __new__,
On 11/13/05, Greg Ewing [EMAIL PROTECTED] wrote:
Noam Raphael wrote:
All that is needed to make Tkinter and Michiels'
code run together is a way to say add this callback to the input
hook instead of the current replace the current input hook with this
callback. Then, when the interpreter
On 11/14/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
We have to draw a line somewhere - otherwise you could
just as well add all functions that accept single
string arguments as methods to the basestring
sub-classes.
Please read my first post in this thread - I think there's more reason
for
Just two additional notes:
On 9/15/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
-1
Let it continue to live in textwrap where the existing pure python code
adequately serves all string-like objects. It's not worth losing the
duck typing by attaching new methods to str, unicode,
On 11/14/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
so is putting the string constant in a global variable, outside the scope
you're in, like you'd do with any other constant.
Usually when I use a constant a single time, I write it where I use
it, and don't give it a name. I don't do:
messagea
On 11/15/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
If you want to write portable code that keeps things running in the
background while the users hack away at the standard interactive
prompt, InputHook won't help you.
So probably it should be improved, or changed a bit, to work also on
On 11/19/05, Steven Bethard [EMAIL PROTECTED] wrote:
You are missing an important point here: There are intentionally no line
breaks in this string; it must be a single line, or else showerror will
break it in funny ways. So converting it to a multi-line string would
break it, dedent or
Three weeks ago, I read this and thought, well, you have two options
for a default comparison, one based on identity and one on value, both
are useful sometimes and Guido prefers identity, and it's OK. But
today I understood that I still think otherwise.
In two sentences: sometimes you wish to
On 11/27/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
Noam Raphael wrote:
I would greatly appreciate repliers that find a tiny bit of reason in
what I said (even if they don't agree), and not deny it all as a
complete load of rubbish.
I don't understand what your message
On 11/27/05, Samuele Pedroni [EMAIL PROTECTED] wrote:
well, this still belongs to comp.lang.python.
...
not if you think python-dev is a forum for such discussions
on OO thinking vs other paradigms.
Perhaps my style made it look like a discussion on OO thinking vs
other paradigms, but my
On 12/12/05, Aahz [EMAIL PROTECTED] wrote:
Please submit a doc patch to SF (or even just a bug report if you don't
have time). The patch may be plain text or reST; no need for Latex.
Done - patch number 1379023.
Noam
___
Python-Dev mailing list
Hello,
I'm going over setobject.c/setobject.h, while trying to change them to
support cheap frozen-copying. I have a few questions.
1) This is a part of setobject.h:
typedef struct {
long hash;
PyObject *key;
} setentry;
typedef struct _setobject PySetObject;
struct _setobject
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
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 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
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
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
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
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
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
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
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
On 12/29/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
Noam Raphael wrote:
I'm not saying that practically it must be used - I'm just saying that
it can't be called a heuristic, and that it doesn't involve any fancy
overkill size hinting or history tracking. It actually means
something like
Hello,
I thought about another reason to resize the hash table when it has
too few elements. It's not only a matter of memory usage, it's also a
matter of time usage: iteration over a set or a dict requires going
over all the table. For example, iteration over a set which once had
1,000,000
On 12/31/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Noam]
For example, iteration over a set which once had
1,000,000 members and now has 2 can take 1,000,000 operations every
time you traverse all the (2) elements.
Do you find that to be a common or plausible use case?
I don't have
Hello,
I just wanted to say this: you can reject PEP 351, please don't reject
the idea of frozen objects completely. I'm working on an idea similar
to that of the PEP, and I think that it can be done elegantly, without
the concrete problems that Raymond pointed. I didn't work on it in the
last
Hello,
I've found out that the hash value of tuples isn't saved after it's
calculated. With strings it's different: the hash value of a string is
calculated only on the first call to hash(string), and saved in the
structure for future use. Saving the value makes dict lookup of tuples
an operation
Ok, I uploaded it.
Patch no. 1462796:
https://sourceforge.net/tracker/index.php?func=detailaid=1462796group_id=5470atid=305470
On 4/1/06, Aahz [EMAIL PROTECTED] wrote:
On Sat, Apr 01, 2006, Noam Raphael wrote:
I've found out that the hash value of tuples isn't saved after it's
calculated
On 4/2/06, Guido van Rossum [EMAIL PROTECTED] wrote:
I tried the change, and it turned out that I had to change cPickle a
tiny bit: it uses a 2-tuple which is allocated when the module
initializes to lookup tuples in a dict. I changed it to properly use
PyTuple_New and Py_DECREF, and now
Hello all again!
Thanks to Mike's suggestion, I now opened a new wiki page,
AlternativePathDiscussion, in
http://wiki.python.org/moin/AlternativePathDiscussion
The idea is to organize the discussion by dividing it into multiple
sections, and seeing what is agreed and what should be further
almost nothing about the AST).
* It causes no backwards compatibilities issues.
Ok, here's the pre-PEP. Please say what you think about it.
Have a good day,
Noam
PEP: XXX
Title: Allow Empty Subscript List Without Parentheses
Version: $Revision$
Last-Modified: $Date$
Author: Noam Raphael [EMAIL
Hello,
I'll try to answer the questions in one message. Sorry for not being
able to do it until now.
About the joke - it isn't, I really need it.
About the timing - Of course, I can live with this getting into 2.6,
and I think that I may even be able to stay alive if this were
rejected. I still
Hello,
2006/6/10, Nick Coghlan [EMAIL PROTECTED]:
The closest parallel would be with return/yield, as those actually create real
tuples the same way subscripts do, and allow the expression to be omitted
entirely.
By that parallel, however, an implicit subscript (if adopted) should be None
Hello,
It seems to me that people don't object to my proposal, but don't find
it useful to them either.
The question is, what to do next. I guess one possibility is to raise
this discussion again in a few months, when people will be less
occupied with 2.5 beta. This is ok, although I would
Hello,
2006/6/16, Josiah Carlson [EMAIL PROTECTED]:
I'm not a mathematician, and I don't really work with arrays of any
dimensionality, so the need for 0-D subscripting via arr[] while being
cute, isn't compelling to my uses for Python.
Thanks for appreciating its cuteness...
Now, I
2006/6/17, Martin v. Löwis [EMAIL PROTECTED]:
Noam Raphael wrote:
I meant the extra code for writing a special class to handle scalars,
if I decide that the x[()] syntax is too ugly or too hard to type,
so I write a special class which will allow the syntax x.value.
What I cannot
really short and
obvious.
I thought that it might convince someone that it's just a little
generalization of syntax, nothing frightening...
Noam
2006/6/17, Noam Raphael [EMAIL PROTECTED]:
I know that it's not such a big difference, but I'm not talking about
a big change to the language either
2006/6/18, Shane Hathaway [EMAIL PROTECTED]:
Try to think more about how users will use your API. You haven't
specified where those names (sheet1, income_tax, and profit) are coming
from. What do you expect users of your library to do to bring those
names into their namespace?
That's a good
not agree with my distinction in this
case. As it is, I barely consider this as an added feature - I would
say it's mostly a small generalization.
2006/6/30, Georg Brandl [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote:
Noam Raphael posted an empty subscript PEP on the Python Wiki:
http
Hello,
I wanted to tell you that I wrote a Python bytecode
assembler/disassembler, and would be happy if people tried it and said
what they think.
I send this message to this list because this module deals with pretty
low-level Python, so I thought it might interest the audience here. If
I was
2006/8/24, Brett Cannon [EMAIL PROTECTED]:
On 8/23/06, K.S.Sreeram [EMAIL PROTECTED] wrote:
Hi all,
I noticed in Python/ceval.c that LOAD_GLOBAL uses a dictionary lookup,
and was wondering if that can be optimized to a simple array lookup.
No, not as the language stands now.
If
65 matches
Mail list logo
