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
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 wr
now that adding unneeded feature to the language can be
considered "harmful". You may 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 <
2006/6/18, Guido van Rossum <[EMAIL PROTECTED]>:
> But more to the point, this discussion is pointless, since I won't
> accept the syntax change.
OK, too bad!
But don't say I haven't warned you, when you will all use my fabulous
package and get tired from typing all those extra parentheses! :)
N
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
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 ch
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
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 a
2006/6/16, Gareth McCaughan <[EMAIL PROTECTED]>:
> None of the above is intended to constitute argument for
> or against Noam's proposed change to Python. Python isn't
> primarily a language for mathematicians, and so much the
> better for Python.
>
Thanks for your explanation of mathematical zero
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 prefer
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 N
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
ementation (It was fairly easy for me to
implement it, and I know 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 Parenthes
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
discus
Hello all,
I just wanted to say thanks for your encouraging comments and
participation, and to say that I'm sorry that I haven't replied yet -
unfortunately, I don't have an Internet connection where I stay most
evenings. I now read all your replies, but I want to reply seriously
and the time is g
Hello,
I saw the discussion about including the path type in the standard
library. As it turned out, I recently wrote a program which does quite
a lot of path manipulation. This caused me to think that the proposed
path module:
* Makes path manipulation significantly easier
* Can be improved.
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,
Ok, I uploaded it.
Patch no. 1462796:
https://sourceforge.net/tracker/index.php?func=detail&aid=1462796&group_id=5470&atid=305470
On 4/1/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 01, 2006, Noam Raphael wrote:
> >
> > I've found out that the hash
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
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 few
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 d
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 member
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
> > overki
On 12/29/05, Donovan Baarda <[EMAIL PROTECTED]> wrote:
> Without some sort of fancy overkill size hinting or history tracking,
> that's probably as good a heuristic as you can get.
I'm sorry, but it's not correct. There's a simple resize scheduling
algorithm that is proven to take, when you sum th
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 &
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
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
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&#
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 th
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
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/
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
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
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
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
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/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
P
Hello,
I now discovered that a callback registered when creating a weak
reference will be called only if the weak reference object is still
alive. This is not documented in the weakref module documentation.
(It's a good behaviour - it just ought to be documented.)
Have a good day,
Noam
_
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 c
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
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 c
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, ded
Thanks for your examples. I understand tham sometimes it's a good idea
not to write the HTML inside the function (although it may be nice to
sometimes write it just before the function - and if it's a method,
then we get the same indentation problem.)
However, as you said, sometimes it is desired
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/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:
messa
On 11/14/05, Michiel Jan Laurens de Hoon <[EMAIL PROTECTED]> wrote:
> Ronald Oussoren wrote:
>
> > I wonder why nobody has suggested a seperate thread for managing the
> > GUI and
> > using the hook in Python's event loop to issue the call to update_plot.
> >
> Ha. That's probably the best solution
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, Use
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
f
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 curr
On 11/12/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > The motivation
> > is to be able to write multilined strings easily without damaging the
> > visual indentation of the source code
>
> That is somewhat misleading. We already have that ability. What is
> being proposed is moving existi
Following Avi's suggestion, can I raise this thread up again? I think
that Reinhold's .dedent() method can be a good idea after all.
The idea is to add a method called "dedent" to strings. It would do
exactly what the current textwrap.indent function does. The motivation
is to be able to write mul
On 11/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> If I have a Gtk app I have to feed other (socket, callback) pairs to it. It
> takes care of adding it to the select() call. Python could dictate that the
> way to play ball is for other packages (Tkinter, PyGtk, wxPython, etc) to
> feed
On 11/5/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> More generally, I claim that the current behaviour is better than
> *any* alternative. To refute this claim, you would have to come
> up with an alternative first.
>
The alternative is to drop the __hash__ method of user-defined classes
(as
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/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 instantia
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 conte
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
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.
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 fr
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 beha
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.
>
> http://www
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 langu
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 someo
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 i
On 11/1/05, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> Noam,
>
> There's a simple solution to all this - write a competing PEP. One of
> the two competing PEPs may be accepted.
I will. It may take some time, though.
>
> FWIW, I'm +1 on PEP 351 in general, and -1 on what you've proposed.
>
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 r
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
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 name
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
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
>
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.
>
> 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 ig
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 the
On 9/11/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Often the needs of certain user groups and the development speeds of
> > such 3rd party modules are so different that it simply doesn't make
> > sense to fold them in the Python distribution anyway -- consider what
>
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 f
t's actually quite simple: 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 mail
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
ee lines of _binsplit.
Do you think it's ok? Could this be added to email.Header?
(Should I send this as a patch? It's just that the patch list was full
of IDLE patches, and this change is really small, so I thought that it
would be easier to post it here. Please tell me i
On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>
> There is one problem with using no keyword: You cannot use arbitrary
> expressions
> in the new statement. Consider:
>
> resource = opening("file.txt")
> block resource:
> (...)
>
> resource = opening("file.txt")
> resource:
>
Hello,
I would like to suggest a new method decorator: abstractmethod. I'm
definitely not the only one who've thought about it, but I discussed
this on c.l.py, and came to think that it's a nice idea. An even
Pythonic!
This has nothing to do with type checking and adaptation - or, to be
more prec
> > 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 assi
= 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.
I just think it's simpler and cleaner that way. Just making
staticmethods callable would solve my p
t; parts in order to make sure 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
83 matches
Mail list logo
