Fredrik Lundh wrote:
someone also pointed out in private mail (I think; it doesn't seem to
have made it to this list) that CPython's extensive use of inheritance
by aggregation is invalid C.
switching to C++ would be one way to address that, of course.
A rather heavyweight solution to a
Stephen J. Turnbull wrote:
What you presumably meant was what would you consider the proper type
for (P)CDATA?
No, I mean the whole thing, including all the ... tags
etc. Like you see when you load an XML file into a text
editor. (BTW, doesn't the fact that you *can* load an
XML file into what
Stephen J. Turnbull wrote:
Doesn't that make base64 non-text by analogy to other look but don't
touch strings like a .gz or vmlinuz?
No, because I can take a piece of base64 encoded data
and use a text editor to manually paste it in with some
other text (e.g. a plain-text (not MIME) mail
Ron Adam wrote:
This would apply to codecs that
could return either bytes or strings, or strings or unicode, or bytes or
unicode.
I'd need to see some concrete examples of such codecs
before being convinced that they exist, or that they
couldn't just as well return a fixed type that you
parentheses around
things if it helps readability.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAIL PROTECTED
be an expression.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAIL PROTECTED
Oleg Broytmann wrote:
IDEs. Edit a code in an editor, run python -i script.py, investigate the
environment, return to the editor, get error message.
An IDE is likely to want to catch SystemExits in the
debugged script and handle them specially anyway.
--
Greg Ewing, Computer Science Dept
Steven Elliott wrote:
One way of handling it is to
alter STORE_ATTR (op code for assigning to mod.str) to always check to
see if the key being assigned is one of the default builtins. If it is,
then the module's indexed array of builtins is assigned to.
As long as you're going to all that
Raymond Hettinger wrote:
That is going to be difficult as long as it is legal to write:
True = 0
BTW, are there any plans to make True and False hard
constants in 3.0 (like None is now)? Maybe also
others like Ellipsis, NotImplemented, etc.
Greg
Guido van Rossum wrote:
I don't think we should make any of these keywords.
Not even True and False? The only good reasons
I can see for anyone wanting to shadow these
are backwards compatibility ones.
Greg
___
Python-Dev mailing list
Guido van Rossum wrote:
I don't see why everything that doesn't make sense to be shadowed
ought to become a keyword.
That wasn't the reason. I was thinking it
would be nice if one could use True and False
instead of 1 and 0 in the knowledge that it
wasn't costing a couple of dictionary
Steven Elliott wrote:
a pyc file referencing a global in a module may
have been compiled with a different version of that module (that is
some_module.some_global can't compiled to single fixed index since
stuff may shift around in some_module).
Not sure I quite follow that. Since the code in
Joe Smith wrote:
LISP was a disaster to use, so I doubt your language would have been any
worse.
At least Lisp would let you say
(* 4 a c)
and not force you to write
(* (* 4 a) c)
My language would not have been so forgiving,
unless you were willing to define a bunch of
different *
Fredrik Lundh wrote:
But I'm wondering if the actual bugs list was transmitted to Python
developers,
and verified / acted upon.
and in case it wasn't clear from my previous post, the answer to
your specific question is yes ;-)
Could whoever did this perhaps post a brief description
of
Fredrik Lundh wrote:
return=NULL; output=junk = out of memory
return=junk; output=-1 = cannot do this
return=pointer; output=value = did this, returned value bytes
I agree that the design is a bit questionable;
It sure is. If you get both NULL and -1 returned, how are
you
For Py3k, any thoughts on changing the syntax of
the except clause from
except type, value:
to
except type as value:
so that things like
except TypeError, ValueError:
will do what is expected?
Greg
___
Python-Dev mailing list
, rqwerty)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAIL PROTECTED
Christos Georgiou wrote:
Well, what's the result of
bytes([1,0,0])^ bytes([1,0])
? Is it bytes([0,0,0]) (à la little-endian) or is it bytes([1,1,0])
(straight conversion to base-256)? Or perhaps throw a ValueError if the
sizes differ?
In the interests of refusing the temptation to
Baptiste Carvello wrote:
They are not *that* obvious. Logical operations on ints have allowed users to
forget about size (and shoot themselves in the foot from time to time). Or is
1^(~1) == -1 obvious ? Well, maybe that's not sane either :-)
It's about as sane as you can get in a world
Russell E. Owen wrote:
Fundamentally I think what's wanted is:
- Another level of sub-TOCs, e.g. one for Sequence Types, Mapping
Types, etc. Every page that has sub-topics or intimately related should
have a list of them at the beginning.
- The special methods for a given type of class
Baptiste Carvello wrote:
what about
except type with value:
a program dies with an error message, not as an error message.
No. The exception object you're catching *is* the value,
not something which *has* a value. I maintain that as
is the correct word to use here.
Greg
Georg Brandl wrote:
I predict people will come and write
except NameError as e, OtherError as f:
Then they'll learn very fast not to write that,
because they'll get a SyntaxError.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Nick Coghlan wrote:
The former seems fairly pointless, and the latter difficult (since it has
implications for moving the data store when the array gets resized).
I don't see why that should be a serious problem, as
long as it's understood that the address reported by
the array interface is
Barry Warsaw wrote:
On Sat, 2006-03-18 at 19:32 +0100, Giovanni Bajo wrote:
Unless this new proposal also includes changing the meaning of except: to
except Error.
Then maybe it should be called error: rather
than except:. :-)
Greg
___
Python-Dev
Barry Warsaw wrote:
One possible approach is to revert BaseException out of Py2.5,
re-position KeyboardInterrupt, and add Error as an alias for
StandardError. Then we can encourage people to start using Error as the
base classes for their own errors.
Also maybe start issuing warnings
Nick Coghlan wrote:
So, as a somewhat novel approach, what about putting the as *before* the
list of exceptions types?
-1. When you're scanning down a series of except
clauses, what you're looking for foremost is the
types of exceptions being caught. The bound name
is of secondary importance
Wolfgang Langner wrote:
try:
something
except NameError or OtherError as e:
I don't see that this really helps anything,
since it's no clearer how or and as should
bind than it is how , and as should bind.
Also it has the disadvantage that
except E1 or E2 as e:
would *not* be
Giovanni Bajo wrote:
The situation (in Py3k) I was thinking is when people see this code:
except:
# something
and want to change it so to get a name to the exception object. I *think* many
could get confused and write:
except Exception, e:
# something
If except clauses are
Giovanni Bajo wrote:
OTOH, I also understand that people have been told that deriving from
Exception
is the right thing to do forever now.
Have we really being telling them to derive *directly*
from Exception, or just that deriving somehow from
Exception will become mandatory?
For the
he thought it looked
better that way.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAIL PROTECTED
Guido van Rossum wrote:
respond with a +1
or -1 on the creation of the python-3000 mailing list.
+1
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand
of the function that aren't
relevant to the caller.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAIL PROTECTED
errors are standardised? :=)
Also, standard error sounds like some sort of
statistical term to me...
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand
to catch, even
in a top-level catch-almost-everything loop. So I'd
leave these two out on their own.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm
Tristan Seligmann wrote:
Greg Ewing [EMAIL PROTECTED] [2006-03-21 13:20:53 +1200]:
Gareth McCaughan wrote:
def f((x0,y0) as p0, (x1,y1) as p1):
For maximal utility, this would affect the calling signature of the
function, too: it would now have keyword arguments named p0 and p1.
I
There seems to be a need for better diagnostics
when pickle encounters something that can't be
pickled.
Recently when attempting to pickle a rather
large and complicated data structure, I got
the following incomprehensible message:
cPickle.PicklingError: args[0]
from __newobj__ args has
I've just been playing around with metaclasses, and
I think I've stumbled across a reason for having
class decorators as an alternative to metaclasses
for some purposes.
The metaclass I wrote was for the purpose of
adding a class to a registry, the reason for which
isn't important here. It
Barry Warsaw wrote:
We're clearly going in circles here, and it's obvious we're not going to
agree.
Would it perhaps help if there were a better API for
using the iterator protocol from C code? Something
that's as easy to use as the proposed set iterating
API, but which uses the general
Chris Barker wrote:
Can we have both? A defined interface, that existing code can be adapted
to provide, and a new C-Object, that future code can just use. If the
goal is to have as many extension types as possible use the same base
object, the sooner a standard object is provided the
Travis E. Oliphant wrote:
I think this can be fixed easily by first checking the sequence slot for
a sq_concat function before calling PyNumber_InPlaceAdd.
However, if this *is* fixed, it looks like it's going to
break NumPy, in the sense that it will no longer be able
to force an arithmetic
Barry Warsaw wrote:
My PySet_Clear() raises a SystemError
and returns -1 when the object is a frozen set.
Isn't SystemError a bit drastic? TypeError would be
sufficient here, surely.
If PyObject_Clear() is implemented something like
int PyObject_Clear(PyObject *o)
{
return
Phillip J. Eby wrote:
It registers a function as the __metaclass__ by poking it into the f_locals
of the frame that's defining the class.
That is stunningly brilliant! I'd nominate it for
Hack of the Year if there were such an award.
It's far too magical for me to feel like actually
using
Travis E. Oliphant wrote:
I can't imaging anybody relying on an in-place operations to return a
different object, but we could make the change and run all the
NumPy/SciPy tests to see what happens.
I'm really thinking more about the non-inplace operators.
If nb_add and sq_concat are
Barry Warsaw wrote:
Perhaps the PySet API can raise an error if it's ever called on
something that's not *exactly* a set? No subclassing allowed.
Shouldn't affect you, and should be an effective deterrent against
abuse of the kind that made the PyDict API an albatross.
And perhaps in Py3k
Armin Rigo wrote:
[].__add__(5)
TypeError: can only concatenate list (not int) to list
Would that be much of a loss? It doesn't really
give you much more information than something like
Unsupported operand types for '+': list, int
and what it does give is based on the assumption
Gareth McCaughan wrote:
For what it's worth[1], I think Raymond is absolutely on crack here.
+1 on a good concrete set API from me, too. Being such
similar types, sets should have about the same API richness
as dicts, IMO.
--
Greg
___
Python-Dev
Phillip J. Eby wrote:
http://mail.python.org/pipermail/python-dev/2004-March/043462.html
Or more precisely, the subsequent discussion and examples convinced me that
putting class decorators on top of the class was bad for readability, vs.
putting them in the body just after the docstring.
Armin Rigo wrote:
So if we provide a complete fix, [].__add__(x) will be modified to
return NotImplemented instead of raising TypeError if x is not a list,
and then [1,2,3]+array([4,5,6]) will fall back to array.__radd__() as
before.
Ah, okay. That seems like it would work.
--
Greg
Tim Hochberg wrote:
Still, perhaps for Py3K it's worth considering
if PyNumber_InplaceAdd should only call __iadd__ and __add__, not
__radd__. Thus giving the target object complete control during inplace
adds.
That's probably reasonable, although it would break
the conceptual notion that
I just thought of a possible name for the
Python package repository. We could call
it the PIPE - Python Index of Packages
and Extensions.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam
db
for database stuff. It can always be renamed on import
if it happens to conflict with anything in code, and
I wouldn't object to not being able to have my own
top-level package called db.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury
Phillip J. Eby wrote:
My comment above was only about readable *placement* of the decorators, not
the actual syntax.
The placement is part of the syntax...
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam
argument).
Would that really buy you anything much over just
making multiple PySet_Update() calls? Is it just
syntactic sugar, or is there some optimisation
you can do with multiple updates presented all
at once?
--
Greg Ewing, Computer Science Dept
of.
In fact, a Firebird interface might be an
alternative worth considering for the library.
It would have most of the advantages of SQLite
without these disadvantages.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post
relational.
Maybe a single dotted hierarchy of package names
is too restrictive? Should we be able to import
things by specifying attributes instead of a
pathname?
import db where db.stdlib == True and db.language == SQL \
and db.interface == DBAPI2.0
?-)
--
Greg Ewing, Computer Science Dept
fit up the top. That's
an extra degree of freedom that we don't have with
functions.
- - - - -
[1] Actually I would probably give it one optional
argument, the name to register under if different
from the class name.
--
Greg Ewing, Computer Science Dept
*. :-)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAIL PROTECTED
Fred L. Drake, Jr. wrote:
On Wednesday 29 March 2006 21:55, Greg Ewing wrote:
import db where db.stdlib == True and db.language == SQL \
and db.interface == DBAPI2.0
While we're at it, we could spell import select. :-)
Getting off on a tangent here, but I would actually
like
Phillip J. Eby wrote:
Are you actually *using* this IOClass thing, or is this just a
hypothetical proposal?
I'm using it. It's not hypothetical.
Putting all the info I want in the decorator itself
wouldn't be very nice in my case, or at least that's
my opinion. One issue is that I'm also
Thomas Wouters wrote:
Have you looked at SqlObject? (and its associated modules
sqlobject.sqlbuilder in particular)
SQLAlchemy (www.sqlalchemy.org http://www.sqlalchemy.org) is also
nice, in particular for more complex setups.
There's plenty of ways to reliably and sanely
Raymond Hettinger wrote:
FWIW, I do not consider it an abuse to use a class to create a small
namespace. Essentially that is what it is for -- it matters not whether
the class has no methods.
Two problems with that:
* The word class in front of it is a misnomer if
you've no intention of
Fredrik Lundh wrote:
Greg Ewing wrote:
Firebird could be a solution to this.
so a library that doesn't support multiple independent
readers/writers on a single file at all is much better
than one that does,
Where do you get that from? Firebird supports
multiple readers/writers
Fredrik Lundh wrote:
not according to the documentation (which says that the embedded library locks
the database file, to prevent other independent processes from accessing the
data).
I think that means other *non-Firebird* processes.
Firebird itself uses a system of file locks and
M.-A. Lemburg wrote:
I don't really care about the name, but please be aware that
you are talking about adding a *very* popular module name to
the top-level Python namespace if you go for db or database.
This would only be an issue for an application that
had a private module calle db, since
Jim Jewett wrote:
The checkins list has been struggling with generator reference leaks;
the latest conclusion was that some are unavoidable because of __del__
cycles. That sort of defeats the purpose of resource managers.
Seems to me we need a whole new approach to
finalization that's
Nick Coghlan wrote:
Generators are even more special, in that they only require finalisation in
the first place if they're stopped on a yield statement inside a try-finally
block.
I find it rather worrying that there could be a
few rare cases in which my generators cause
memory leaks,
Nick Coghlan wrote:
from contextlib import closing
with closing(itr):
# Use the iterator in here as you wish
# secure in the knowledge it will be
# cleaned up promptly when you are done
# whether it is a file, a generator or
# something with a database connection
for
Michael Hudson wrote:
And if we want to have a version of __del__ that can't reference
'self', we have it already: weakrefs with callbacks.
Does that actually work at the moment? Last I heard,
there was some issue with gc and weakref callbacks
as well. Has that been resolved?
--
Greg Ewing
Walter Dörwald wrote:
OK, the property setter does a % 7 now. (But the global
setfirstweekday() still does a range check).
Wouldn't it be better for the setter to raise an exception
if it's out of range? It probably indicates a bug in the
caller's code.
--
Greg Ewing, Computer Science Dept
that the callback is reachable,
that references enough stuff to clean up after the
generator, without referencing the generator itself?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch
Walter Dörwald wrote:
Greg Ewing wrote:
Wouldn't it be better for the setter to raise an exception
if it's out of range? It probably indicates a bug in the
caller's code.
The day before Monday is -1, so it adds a little convenience.
In that case, why doesn't the global function
allow
Tim Peters wrote:
A problem is that the variant semantics also seem pretty arbitrary ;-),
and there's a dearth of compelling use cases to guide a decision.
At the time I think I suggested that it would be
reasonable if weakref callbacks were guaranteed to
be called as long as they weren't trash
Neil Schemenauer wrote:
I think so but it depends on what the finalizer needs to reference.
That's really what I'm asking -- what *does* a
generator finaliser need to reference? Or does
it depend on what the generator's code does?
--
Greg
___
Martin v. Löwis wrote:
Of this kind, we have several spare bits: there are atleast two bits
in the ob_type field,
And that would require changing all code that dereferenced
the ob_type field! This would be much worse -- at least
Py_INCREF and Py_DECREF are macros...
--
Greg
Crutcher Dunnavant wrote:
A) issubclass() throws a TypeError if the object being checked is not
a class, which seems very strange.
If I ever pass a non-class to issubclass() it's almost
certainly a bug in my code, and I'd want to know about
it.
On the rare occasions when I don't want this,
Jess Austin wrote:
I'll go
so far as to suggest that the existence of groupby() obviates the
proposed tally().
Except that it requires building a list of values in
each group when all you want at the end is the length
of the list.
--
Greg
___
a module
called ElementTree containing a class called
ElementTree is just too confusing for words!
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm
to the stdlib, consistency
of naming is never going to improve.
Or should this wait for Py3k?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning
Trent Mick wrote:
try:
import xml.etree.ElementTree as ET # in python =2.5
except ImportError:
... etc ad nauseam
For situations like this I've thought it might
be handy to be able to say
import xml.etree.ElementTree or cElementTree or \
Georg Brandl wrote:
Suppose I wanted to implement that, what would be the best strategy
to follow:
- change handling of IMPORT_NAME and IMPORT_FROM in ceval.c
- emit different bytecodes in compile.c
- directly create TryExcept AST nodes in ast.c
I'd probably go for the third option. Isn't
Tim Peters wrote:
The PyObject_ memory family is generally faster and more
memory-efficient for small allocations than the PyMem_ memory family.
Lines of source code, and encoding strings, are usually small enough
to exploit that. The ob in obmalloc.c doesn't really have anything
to do
to see the module name
as well.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAIL PROTECTED
Steven Bethard wrote:
make callable name tuple:
block
I don't like the position of the name being defined.
It should be straight after the opening keyword, as
with 'def' and 'class'. This makes it much easier
to search for definitions of things, both by eyeball
and editor search
Josiah Carlson wrote:
One major problem with this is that except for function calls, * is the
multiplication operator, which operates on two arguments. *foo is an
operation on a single argument, and without parenthesis, would be
ambiguously parsed.
No, it wouldn't. There's no problem in
Travis Oliphant wrote:
For what it's worth, NumPy also defines a data-type object which it
uses to describe the fundamental data-type of an array. In the context
of this thread it is also yet another way to describe a binary-packed
structure in Python.
Maybe there should be a separate
Anthony Baxter wrote:
I started refactoring some of the ugliness out of the internals of
distutils last year, but was completely stymied by the demand that no
existing setup.py scripts be broken.
Instead of trying to fix distutils, maybe it would be better
to start afresh with a new package
Martin v. Löwis wrote:
If distutils is now abandoned and replaced with
something else, the same story will happen again: the developers will
run away, the package gets abandoned,
Seems to me that if we had something with a clean
design that was easy to understand, maintain and
extend, that
Terry Reedy wrote:
I took a look. The only thing that puzzles me is 'warp factor', which
appears exactly once.
It's been put there via time machine in connection
with the dilithium crystal support in that will be
added in Python 7.0. You don't need to worry about
it yet.
--
Greg
Fredrik Lundh wrote:
(distutils and setuptools are over 15000 lines of code, according to sloc-
count.
Ye cats! That's a *seriously* big ball of mud. I just checked,
and the whole of Pyrex is only 17000 lines.
--
Greg
___
Python-Dev mailing list
Phillip J. Eby wrote:
If they have Pyrex installed, setuptools uses
Pyrex to rebuild the .c from the .pyx.
I hope it would only do this if the .pyx was newer than the
.c. It's probably not a good idea to assume that just because
Pyrex is around, the user wants to use it in all cases. He
might
Anthony Baxter wrote:
http://www.joelonsoftware.com/articles/fog69.html
From what I remember, he didn't actually say that you
should never rewrite anything, but that if you do, you
need to be prepared for a very long period of time
when nothing new is working, and that *if you are a
Guido van Rossum wrote:
I'd rather recommend the approach that Joel suggests for truly large
systems: refactoring smaller components while keeping the overall
structure intact.
That's fine as long as the overall structure isn't the
very thing that's wrong and needs to be fixed.
Incremental
While we're on the subject of distutils revision, here
are a few things I've encountered about distutils which
seem less than desirable.
* There doesn't seem to be a way of supplying options
on the command line for anything except the top-level
command. Sometimes, e.g. I want to do an
tomer filiba wrote:
first of all -- i know there's a bunch of templating engines, but i
think it should be a built-in feature of the language.
One fairly serious drawback to this idea is that it
inhibits i18n. For security reasons it has to be
implemented at compile time and only work on
Martin v. Löwis wrote:
Some libraries (not necessarily in Python) have gone the path of
providing a unified API for all kinds of file stream access,
e.g. in KDE, any tool can open files over many protocols, without
the storage being mounted locally.
Maybe a compromise would be to provide an
Guido van Rossum wrote:
You
can't blame KDE for providing mechanisms that only work in the KDE
world. It's fine for Python to provide Python-specific solutions for
issues that have no cross-platform native solution.
Also keep in mind that we're talking about resources
used internally by the
Martin v. Löwis wrote:
Greg Ewing wrote:
The resources name is actually quite a common meme;
I believe it goes back to the original Macintosh,
I can believe that history. Still, I thought a resource
is something you can exhaust;
Haven't you heard the term renewable resource
Martin v. Löwis wrote:
I can readily believe that package authors indeed see this as
a simplification, but I also see an increased burden on system
admins in return.
There are two conflicting desires here. Package authors
don't want to have to make M different kinds of package
for M different
Phillip J. Eby wrote:
By now, however, the term is popularly used with GUI toolkits of all
kinds to mean essentially read-only data files that are required by a
program or library to function, but which are not directly part of the
code.
It's just occurred to me that there's another
Phillip J. Eby wrote:
You seem to believe that there are other
things more important than making things Just Work for this audience.
While it's clearly a good thing when something just
works, I don't think that this should be the only goal.
Just as important to my mind -- probably even more
301 - 400 of 2277 matches
Mail list logo
