when I *do* put all
my declarations before my non-declarations, I can
live with that. :-)
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyt
program-accessible entities.
So we'd end up implementing our own form of
dynamic dispatch anyway, and it would probably
look a lot like the current C-based type objects.
I don't see that C++ would help much.
--
Greg
___
Python-Dev m
dated to look for __send__ or
something like that, and existing iterators
need not have been affected.
So the reason I'd like to see this changed
in 3.0 is not because of consistency for its
own sake, but because it would provide a
better basis for future development.
--
Greg
_
them to just bytes and characters?
Following that through leads to giving *every*
object .encode() and .decode() methods. I
don't think we should go that far, but it's
hard to see where to draw the line. Are
bytes and strings special enough to justify
them having their own peculiar methods
Bill Janssen wrote:
> No, once it's in a particular encoding it's bytes, no longer text.
The point at issue is whether the characters produced
by base64 are in a particular encoding. According to
my reading of the RFC, they're not.
--
Greg Ewing, Com
it
> might make things clearer over decode and encode.
Another thing is that it only works if the codec
transforms between two different types. If you
have a bytes-to-bytes transformation, for example,
then
b2 = b1.tobytes('some-weird-encoding
Raymond Hettinger wrote:
> [Greg Ewing]
>
> > And you don't think there are many different
> > types of iterables?
>
> Um, I meant iterators and suspect you meant the same --
The same comment applies either way. Each type of iterable
usually has its own correspondi
Baptiste Carvello wrote:
> while manipulating binary data will happen mostly with bytes objects, some
> operations are better done with ints, like the bit manipulations with the
> &|~^
> operators.
Why not just support bitwise operations directly
on the bytes object?
--
Greg
seq, sep):
if hasattr(sep, '__join__'):
return sep.__join__(seq)
else:
# generic implementation
Then you could get nice fast type-specific implementations
for strings, bytes, etc., without being limited to those
types.
--
Greg Ewing, Computer Science Dept, +-
your strings contain piglatin and which don't.
Is this scheme any better than having encode and
decode methods/functions? I'm not sure, but it
shows that a suitably enhanced notion of "data
type" can be used to replace the notions of
encoding and decoding and maybe reduce poten
ing to continue to use 'encode' and 'decode',
why not just make them functions:
b = encode(u, 'utf-8')
u = decode(b, 'utf-8')
In the case of Unicode encodings, if you get them
backwards you'll get a type error.
The advantage of u
rse.
A rather heavyweight solution to a problem that does
not seem to have been a problem in practice so far,
only in theory.
Practicality beats purity once again...
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
you *can* load an
XML file into what we call a "text editor" say something?)
> nobody but authors of
> wire drivers[2] and introspective code will need to _explicitly_ call
> .encode('base64').
Even a wire driver writer will only need it if he's
trying to turn
etc -- because mail and
news at the time were strictly text channels. They
still are, really -- otherwise we wouldn't be using
anything as hairy as MIME, we'd just mail our binary
files as-is.
--
Greg
___
Python-Dev mailing list
Python-Dev@python
fixed type that you
then transform to what you want.
I suspect that said transformation would involve some
further encoding or decoding, in which case you really
have more than one codec.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
htt
enough
to find out how much of a disaster this would
have been to use, though. :-)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a mor
7;s enough that you *can* put 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 pe
at would be
while (next_x() as x) < threshold:
...
i.e. 'x as y' would be an expression.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christ
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 S
ditional gains can be
> made be focusing just on builtins.
As long as builtins can be shadowed, I can't see how
to make any extra use of the fact that it's a builtin.
A semantic change would be needed, such as forbidding
shadowing of builtins,
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, e
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
Py
ing a couple of dictionary lookups.
However, if a more general way is found of
optimising global lookups, this may become a
non-issue.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
ls it uses. Builtins
can have dedicated opcodes which perform a fast check for
shadowing in the module and builtin arrays. Everything
goes as fast as possible while still allowing anything
to be overridden.
Greg
___
Python-Dev mailing list
Python-Dev@pyt
ferent * functions with different numbers
of parameters.
BTW, I did use Lisp and Scheme fairly heavily
for a period, and didn't find them to be
disasters -- at least not because of the parens.
Greg
___
Python-Dev mailing list
Python-Dev@pyth
es" ;-)
Could whoever did this perhaps post a brief description
of what sort of information their tool produces, and
how good a hit rate they have of finding real problems?
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
returned, how are
you supposed to know which one is the junk?
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
For Py3k, any thoughts on changing the syntax of
the except clause from
except , :
to
except as :
so that things like
except TypeError, ValueError:
will do what is expected?
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http
; or "license" for more information.
>>> f = open("DU", "rqwerty")
>>>
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchu
interests of refusing the temptation to
guess, I'd go for the ValueError.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
. Could we perhaps call it a bytevector
or bytearray or something?
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
egory. For example:
> Sequence Types (str, unicode, list, tuple, buffer, xrange)
> Mapping Types (dict)
+1
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Baptiste Carvello wrote:
> what about
>
> except with :
>
> 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 &qu
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-
ray interface is only for temporary use.
I also don't see what relevance the semantics of
Python indexing or mutation has. The array interface
should just report the location and shape of the
data as it happens to be when the call is made.
What happens to it in between times is entirely
up
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 "
ing warnings whenever you inherit
directly from Exception.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
cially
compared to some of the other exception hierarchy
reorganisations that have been proposed.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
bound name
is of secondary importance and only relevant to
the code in the except clause.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
the disadvantage that
except E1 or E2 as e:
would *not* be equivalent to
except (E1 or E2) as e:
On the other hand, in
except E1, E2 as e:
the E1, E2 is just a tuple expression, so it's
exactly equivalent to
except (E1, E2) as e:
Greg
__
gt; # something
If except clauses are changed to use "as", then
as long as we're still allowing bare excepts, that
could become
except as e:
...
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
stand the proposals, the important thing for
interoperability between different types is to have
(1). Whereas (2) would be useful to have, it's not
a prerequisite for (1).
Do I understand correctly?
Greg
___
Python-Dev mailing list
Python-Dev@pytho
earrange their internal structure to use
this new C-object.
So I still think the standardised interface is more
important and should have a higher priority than the
new object.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
Just van Rossum wrote:
> Greg Ewing wrote:
>
> > Also maybe start issuing warnings whenever you inherit
> > directly from Exception.
>
> Ugh. I hate it when it's made (virtually) impossible to write code that
> runs warnings-free on both Python X.Y and X.(Y+1
For the purpose of minimising bare-except problems,
recommending direct derivation from Exception seems
like a particularly bad idea, whether the exception
hierarchy is changed or not.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
Guido added them because 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.)
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 Z
tion details 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.
n" will not catch all exceptions.
My thoughts exactly.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not
around making
sure everyone's 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!
things
that you will almost always not want 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!
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
to pickle or where
abouts it turns up in the data structure.
Anyone have any ideas how the situation could
be improved? At the very least, it could
include some info about the type and identity
of the offending object.
Greg
___
Python-Dev mailing list
P
ot what I'd want.
The general principle brought out here is that when
you use a metaclass, it gets inherited by subclasses,
but if we had class decorators, they would only affect
to the classes that you explicitly applied them to.
I think there are uses for both behaviours.
Greg
___
but which uses the general iterator protocol
underneath.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ensional arrays really are very useful for
> all sorts of stuff that have nothing to do with high-performance Numeric
> computing.
I'm all in favour of including such an object, as long
as we keep in mind that this is an orthogonal issue to
having an array interface. The discussion sti
to force an arithmetic interpretation for "+" when adding
a sequence to an array.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyth
ss to it is probably wrong.
Clearability is not a general feature in Python land --
a few types have a clear() method, but this is an
ad hoc feature of the type concerned. I don't think
it makes sense to have a general PyObject_Clear
function at all.
--
Greg
__
l like actually
using it, though. Class decorators would be so much
more straightforward and explicit.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
b.
This would be very different from the current behaviour
of Numeric arrays. I don't know whether Numeric users
would consider it a serious problem or not, but I
think we need to consider the implications before
charging ahead too fast with slot unification.
--
Greg
I an albatross."
And perhaps in Py3k the same could be done for dicts,
and any other builtin types with concrete access
functions?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
t
and what it does give is based on the assumption
that concatenation is what the user has in mind.
He might just as easily have been thinking of
addition, or something else entirely.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
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
___
Py
s no discussion of
the issue at all.
Seems to me that, since we now already have @-decorators
for functions, a *very* good reason will be needed for
requiring a completely different syntax to get exactly
the same effect for classes.
--
Greg
___
Python-D
ion is hoopy"
@def biguglydecorator(longconvolutedarglist)
Someone is going to object that the evaluation
time and environment of the decorator is screwy.
But I don't care. :-)
Greg
___
Python-Dev mailing list
Python-Dev@python.o
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 wo
the conceptual notion that a += b is equivalent to
a = a + b when a can't be modified in-place.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
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
evel of a reorganised package namespace, I
don't think it would be out of place to reserve "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 &quo
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, | Carp
ariable length argument list instead of a single 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?
-
d you provide this information?
Still want class decorators, though. :-)
BTW, the system I'm working on is a response to
some hair-tearing problems I was experiencing
trying to pickle some of my data, and also to
address some disadvantages I see in using pickle
for long-term data storage. I'
with concurrency or large
amounts of data that I know 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, +--
the hierarchy completely and going 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
want them inherited) for large amounts of information
that wouldn't comfortably 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
[EMAIL PROTECTED] wrote:
> Greg> There's a big difference between "db" and "em": "db" is an
> Greg> extremely well-known abbreviation, whereas "em" isn't.
>
> Unless you're a typesetter or a TeX hound... :-)
Good p
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
I've been thinking about an 'instance' statement that
creates an instance of a class:
instance my_thing(MyClass):
# attribute assignments go here
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
One issue is that I'm also abusing a
class statement to create a namespace for my extra
info. Inserting that as a decorator argument obviously
wouldn't be possible...
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
Boolean Operators PEP, by the way.)
I'd like to see some way of attacking this problem
head-on, rather than endlessly looking for convoluted
ways around it.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
gs with attribute access when
the attribute is a descriptor.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 supp
tabase, embedded or otherwise, to give it a go.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
tart
using stuff from the new db package, he would just
have to rename his module.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
tes:
> obj.__del__()
I think we need to be very careful about doing
anything like this. From what Tim said recently,
the consequences of an object getting its __del__
annotation wrong could be as bad as crashing the
interpreter.
--
Greg
___
e
memory leaks, through no fault of my own and
without my being able to do anything about it.
Will there be a coding practice one can follow
to ensure that this doesn't happen?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
avoid leaking memory.
I'm becoming more and more convinced that we
desperately need something better than __del__
methods to do finalisation. A garbage collector
that can't be relied upon to collect garbage
is simply not acceptable.
--
Greg
___
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 reso
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.
-
ere so 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! |
C
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.
ry
I'm distributing, I can't be sure people won't put
them in cycles.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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
operations.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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...
-
don't want this, I'm
happy to write
isinstance(c, type) and issubclass(c, d)
> B) issubclass() won't work on a list of classs,
> the way isinstance() does.
That sounds more reasonable. I can't think of any
reason why it shouldn't work.
--
Greg
___
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
ee containing 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
naming of things added 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
e or cElementTree or \
elementtree.ElementTree or lxml.etree as ET
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
2101 - 2200 of 2499 matches
Mail list logo
