we're doing this, it might be better if VAR were simply
bound to EXPR in all cases. Otherwise the ability to liberally
sprinkle with-statements around will be hampered by uncertainty
about what kind of object VAR will end up being.
Greg
___
P
Guido van Rossum wrote:
> Unfortunately I can't quite decide whether either rule applies in the
> case of exceptions.
I think you'd at least be justified in using the "magic" rule,
since they're set by the exception machinery.
Greg
___
g to have to remember. . .)
>>
>>Practicality Beats Purity, surely...?
>
>
> D'oh! *slaps forehead*
>
> Cheers,
> Nick.
>
Hmmm... looks like Google needs a "Search Only in Python
Terminology" radio button...
Greg
__
k to the
throw, something would try to put the same frame in the
traceback twice, which can't work since it's a linked
list.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christch
ion of new-style generators,
there could be a new statement
for var from expr:
...
or maybe just a wrapper function
for var in partial(expr):
...
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of Ne
figure user code except for
> the explicit purpose of introspection). So I think the PEP should
> continue to use __traceback__ etc.
I was just thinking the same thing myself!
(Does Guido have a telepathy machine now, as well
as a time machine?)
--
Greg Ewing
Other than that, all this looks good.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
[EMAI
. Even if D(whatever)
didn't ignore the context settings, you'd get the same
oddity if the numbers came from somewhere else with a
different precision.
I'm very uncomfortable about the whole idea of a
context-dependent precision. It just seems to be
asking for trouble.
--
G
ow it
helps significantly to have just the very first
step -- turning the input into numbers -- be
exempt from this behaviour. If anything, people
are going to be even more confused. "But it
can obviously cope with 1.101,
so why does it give
levant, because digits in
a character string are not "digits of a decimal value"
according to what we are meaning by "decimal value"
(i.e. an instance of Decimal). In other words, this
principle only applies *after* we have constructed a
Decimal instance.
--
Greg Ewing, Computer
when the Decimal
module was being designed? It seems to go against
EIBTI, and even against Mr. Cowlishaw's own desire
for WYSIWIG, because WYG depends not only on what
you can see, but a piece of hidden state as well.
Greg
___
Python-Dev
Guido van Rossum wrote:
> So (a) would have my preference.
Mine, too.
> the PEP would have to be amended to state that
> VAR must be a single variable or a list of variables IN PARENTHESES.
+1
--
Greg Ewing, Computer Science Dept, +--+
Univ
es data:
out.write(data)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of
on't think you're doing anyone any favours by trying to protect
them from having to know about these things, because they *need* to
know about them if they're not to write algorithms that seem to
work fine on tests but mysteriously start producing garbage when
run on real data, p
are *not* characters -- if they're characters,
they would be better kept in strings or char arrays.
+1 on any eventual bytes literal looking completely different
from a string literal.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
Guido van Rossum wrote:
> There's also the consideration for APIs that, informally, accept
> either a string or a sequence of objects.
My preference these days is not to design APIs that
way. It's never necessary and it avoids a lot of
her bytes
object?
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
t just do 'setup.py install' directly?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a mo
o it cross-
platform, that's a very good reason to prefer using eggs
over a platform-specific package format.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand
I think the association of "open" with "file" is
established strongly enough in programmers' brains that
dropping it now would just lead to unnecessary confusion.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
str-used-as-bytes.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.) |
y how to *encode*
characters into the bytes object. If you want to be able
to specify how to *decode* a str argument as well, you'd
need a third argument.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post merid
at a
bug in the application.
Likewise, the user should be able to put it anywhere on
the HD, not just the Applications folder.
Also I consider the need for a dmg in the first place
to be a bug in the Web. :-) (You should be able to just
directly download the .app file.)
This sort of thing i
o be more robust
than one which scatters files far and wide and then
relies on some elaborate bookkeeping system to try
to make sure things don't step on each other's toes.
When everything goes right, I don't care either. But
things go wrong often enough to make me care about
unnece
cs.streamdecoder(encoding, openbinary(filename))
Having codecs be stream filters might be a good idea
anyway, since then you could use them to wrap anything
that can be treated as a stream of bytes (sockets,
some custom object in your program, etc.), you
could create pipelines of encoders and decod
good
idea, because the bytes you got that way would depend on
the internal representation of long integers. In particular,
bytes(0x12345678L)
via the buffer interface would most likely *not* give you
bytes[0x12, 0x34, 0x56, 0x78]).
Maybe types should grow a __bytes__ method?
Greg
___
hing up to the coding marker should
be ascii (or some other protocol-defined initial coding).
For protocols that are not sensibly designed (or if you're
just trying to guess) what you suggest may be needed. But
it would be good to have a nicer way of going about it
for when the protocol
Brett Cannon wrote:
> One protects us from ending up with an unusable AST since
> the seralization can keep the original AST around and if the version
> passed back in from Python code is junk it can be tossed and the
> original version used.
I don't understand why this is an issue. If Python code
se for low-level access
to that format, other than just treating it as an opaque
lump of data for turning back into a long later -- in
which case why not just leave it as a long in the first
place.
Greg
___
Python-Dev mailing list
Python-Dev@
and a < b
No, no, no.
If your algorithm is well-designed, it won't matter which
way the comparison goes if a and b are that close.
In any case, the idea behind nice() is fundamentally doomed.
IT CANNOT WORK, because the numbers it's returni
openbytes?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.) |
[E
ainers for data.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAI
/write) and all other stuff (readlines, text codecs,
etc.) implemented as wrappers around it.
To be compatible with that model, opentext() etc.
need to be factory functions returning the appropriate
stack of objects. As such they shouldn't be class
methods of any type.
--
G
Jason Orendorff wrote:
> Also the pseudo-encodings ('hex',
> 'rot13', 'zip', 'uu', etc.) generally scare me.
I think these will have to cease being implemented as
encodings in 3.0. They should really never have been
in the first
y, if you were insane enough
to turn that option on.)
> ...anyway this is getting seriously OT for python-dev. :)
Agreed. I will say no more about it here.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Ca
Josiah Carlson wrote:
> They may not be encodings of _unicode_ data,
But if they're not encodings of unicode data, what
business do they have being available through
someunicodestring.encode(...)?
Greg
___
Python-Dev mailing list
Python-Dev@py
.
Also I'm still wondering why we're going to all this effort
to build a whole new AST and compiler structure if the
purpose isn't to *avoid* all this transformation between
different representations.
Greg
___
Python-Dev mailing list
s recently, I called
it an "autodict" (i.e. a dict that automatically
extends itself with new entries). And perhaps the
value should be called an "initial value" rather
than a default value, to more strongly suggest that
it becomes a permanent part of the dict.
Greg
Martin v. Löwis wrote:
>>Another thought -- what is going to happen to os.open?
>>Will it change to return bytes, or will there be a new
>>os.openbytes?
>
> Nit-pickingly: os.open will continue to return integers.
Sorry, what I meant was will os.
quot;)
makes it obvious that you're going from the
binary side to the text side of the base64
conversion.
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
Would people perhaps feel better if defaultdict
*wasn't* a subclass of dict, but a distinct mapping
type of its own? That would make it clearer that it's
not meant to be a drop-in replacement for a dict
in arbitrary contexts.
Greg
___
Python-D
he dict itself, but provided by a wrapper
around the dict.
The you can fill the dict through the wrapper, and still
have a normal dict underneath to use for other purposes.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
on the
underlying dict, and then the semantics are clear.
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
really apply in the same way it does in statically
typed languages.
In other words, just because A inherits from B in
Python isn't meant to imply that an A is a drop-in
replacement for a B.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
h
sses in terms of a
conceptual interface hierarchy, without promising
that they will be implemented that way.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
is leading to people asking for
arithmetic operations to be *added* to the byte type so
they can do wrap-around arithmetic, and then for 16-bit,
32-bit, 64-bit etc. versions of it, etc. etc.
Do we really want to get onto that slope?
Greg
___
Python-Dev mai
is leading to people asking for
arithmetic operations to be *added* to the byte type so
they can do wrap-around arithmetic, and then for 16-bit,
32-bit, 64-bit etc. versions of it, etc. etc.
Do we really want to get onto that slope?
Greg
___
Python-Dev mai
'd prefer to see it
described that way in the docs. If that is done,
having 'default' in the name wouldn't be so appropriate.
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
channel uses for characters (probably ascii or an ascii
superset, but not necessarily).
So, however it's spelled, the typing is such that
base64_encode(bytes) --> unicode
and
base64_decode(unicode) --> bytes
--
Greg
___
Python-Dev
nonsubstitutability'-this-week-ly,
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
we will keep them Limited
and Fraught With Gotchas, so people will be discouraged
from using them.
Sounds a bit like the attitude of certain religious
groups to condoms. (Might encourage people to have
sex -- can't have that -- look at all the nasty diseases
you can get!)
Greg
ut just a collection of names that
would be implemented as local variables of my_func.
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
Jeremy Hylton wrote:
> The names of naming statements are quite hard to get right, I fear.
My vote goes for 'outer'.
And if this gets accepted, remove 'global' in 3.0.
--
Greg Ewing, Computer Science Dept, +--+
University of Cante
encoding step explicitly very often.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morn
Georg Brandl wrote:
> But why is that better than
>
> class namespace(object): pass
>
> def my_func():
> foo = namespace()
> (...)
Because then it would be extremely difficult for CPython to
optimise accesses to foo into local variable lookups.
--
Greg Ewing,
Alex Martelli wrote:
> If we call the type autodict, then having the factory attribute named
> autofactory seems to fit.
Or just 'factory', since it's the only kind of factory
the object is going to have.
--
Greg Ewing,
obal namespace, but that would have the name global by default,
>>>so
>>>global.x would essentially mean what globals()['x'] means now, except it
>>>would
>>>be a name error if x didn't pre-exist when accessed via
>>>namespace_name.nam
nk your design so that you don't
have to make that kind of distinction.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.)
t after having
failed to reach a consensus on an obviously right way
to go about it.
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
Phillip J. Eby wrote:
>def incrementer(val):
>def inc():
>.val += 1
>return .val
>return inc
-1, too obscure.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
on, and I'd like to see it stay
that way.
--
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
with" for something else.
Regardless, names with leading dots just look ugly and
perlish to me, so I wouldn't be in favour anyway.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
ther --
I'm open to suggestions. But my instincts still
tell me that 'defaultdict' is the best term
for something *else* that we might want to add
one day as well, so I'm just trying to make
sure we don't squander it lightly.
--
Greg
count and execution speed aren't the
only issues -- there is DRY to consider.
--
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
ing else. That's
even less like what we're discussing.
In our case the default values are only
virtual until you use them, upon which they
become real. Sort of like a wave function
collapse... hmmm... I suppose 'heisendict'
wouldn't fly, would it?
--
Greg
etter to do so with a firm hand rather than being half-
hearted and wishy-washy about it.
Then, if it's really necessary to support a wider variety
of types, provide an alternative API that separates the
different cases and isn't type-dependent at all. If someone
has a need for this API, usin
ding is done in the I/O objects, there
will be far less need for programmers to do explicit unicode
coding in the first place, so likely it will become more of
an advanced topic, rather than something you need to come to
grips with on day one of using unicode, like it is now.
--
Greg
___
Raymond Hettinger wrote:
> I'm concerned that the on_missing() part of the proposal is gratuitous.
I second all that. A clear case of YAGNI.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
must have thought at the time
that it was worth providing an alternative way.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning
hey manage to get into Google's
database if they're auto-generated. Anyone have any clues
what goes on?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand
Terry Reedy wrote:
> "Greg Ewing" <[EMAIL PROTECTED]> wrote in message
>
>>Efficiency is an implementation concern.
>
> It is also a user concern, especially if inefficiency overruns memory
> limits.
Sure, but what I mean is that it's better to find w
ds throught the scope hierarchy.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.)
Ron Adam wrote:
> While I prefer constructors with an explicit encode argument, and use a
> recode() method for 'like to like' coding. Then the whole encode/decode
> confusion goes away.
I'd be happy with that, too.
--
Greg Ewin
Steven Bethard wrote:
> Phillip J. Eby wrote:
>
>>Actually, "import .foo" is an abbreviation for "import myparent.foo", not
>>"import myparent.myself.foo".
Oops, sorry, you're right.
s/myself/myparent/g
--
Greg Ewing, Computer Science Dept
ng, because you'd first have to undo the default
encoding and then re-encode it using the one you wanted.
It may be reasonable to provide an easy way to go straight
from raw bytes to ascii-encoded-base64 bytes, but that should
be a different codec. The plain base64 codec should produce
to be a dubious
practice readability-wise, and I can't remember ever
using it. There are other ways of getting the same
effect, e.g. assigning it to another variable before
breaking out of the loop, or putting the loop in a
function and using return.
--
Greg Ewing, Computer Science D
than one special method is inherently ambiguous. What do
you do if both are defined? Sure you can come up with
some rule to handle it, but it's better to avoid the
situation in the first place.
--
Greg Ewing, Computer Science Dept, +--+
University of C
ions so far, it seems to me that
'outer' is the least radical and most consistent with
what we already have. How about we bung it in and see
how it goes? We can always yank it out in 3.0 if it
turns out to be a horrid mistake and we get swamped
with a terabyte of
m even with local filesystems, e.g. on MacOSX
where you can have both HFS (case-insensitive) and
Unix (case-sensitive) filesystems mounted.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christch
user-defined classes, where the
presence of a __getitem__ method causes both of these
slots to become populated.
Having two different slots for __getitem__ seems to have
been an ill-considered feature in the first place and
would probably best be removed in 3.0. I wouldn't mind if
these two function
encoding wisely. It's not possible to
shield him from having to know about encodings in
that situation, even if the encoding is just ascii.
Trying to do so will just lead to more confusion,
in my opinion.
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
r the other way.
Any thoughts about fixing this in 3.0?
--
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
t__() comes along with a function next(obj)
which calls obj.__next__().
--
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
Thomas Wouters wrote:
> On Thu, Feb 23, 2006 at 05:25:30PM +1300, Greg Ewing wrote:
>
>>As an aside, is there any chance that this could be
>>changed in 3.0? I.e. have the for-loop create a new
>>binding for the loop variable on each iteration.
>
> You can't
from
"binary data". So having base64 produce anything
other than a character string would be awkward
and inconvenient.
I phrased that paragraph carefully to avoid using
the word "unicode" anywhere. Does that make it
clearer what I'm getting at?
--
Greg
scores is
when defining a __next__ method. That would be no worse
than defining an __init__ or any other special method,
and has the advantage that it clearly marks the method
as being special.
--
Greg
___
Python-Dev mailing list
Python-Dev@p
bility in 3.0,
so perhaps this could be fixed then?
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
early distinguish between text and
binary data here is what will lead to confusion and
foot-shooting.
I think we need some concrete use cases to talk
about if we're to get any further with this. Do
you have any such use cases in mind?
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
l statement usage to begin
with, I'd say that narrows things down to something
well within the range of acceptable breakage in 3.0.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
cter
string in some way, taking into account the assumed ascii
encoding of said bytes. My way, you just use the result
directly, with no coding involved at all.
--
Greg Ewing, Computer Science Dept, +--+
Universit
Alex Martelli wrote:
> We stole list comprehensions and genexps from Haskell
The idea predates Haskell, I think. I first saw it in
Miranda, and it may have come from something even
earlier -- SETL, maybe?
Greg
___
Python-Dev mailing list
Python-
Stephen J. Turnbull wrote:
> Greg> I'd be perfectly happy with ascii characters, but in Py3k,
> Greg> the most natural place to keep ascii characters will be in
> Greg> character strings, not byte arrays.
>
> Natural != practical.
That seems to be an
ng an argument to next() anyway?
Or was that idea dropped?
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
be text or bytes in Py3k?
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
, where s is a str, works like array.array('b', s)
> - bytes(u, [encoding]), where u is a unicode,
> works like bytes(u.encode(encoding))
Agreed.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
al goal in life right now is to stay as
far away from C++ as I can get. If CPython becomes
C++-based (C++Python?) I will find it quite
distressing, because my most favourite language will
then be built on top of my least favourite language.
Greg
___
Py
his was the backwards compatibility
> problems at the C level.
I'm really quite happy either way. Having the
functionality available in some way is the important
thing.
I'd still like to see next(x) / x.__next__() in
some form in 3.0 for the sake of
Bill Janssen wrote:
> bytes -> base64 -> text
> text -> de-base64 -> bytes
It's nice to hear I'm not out of step with
the entire world on this. :-)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
Fredrik Lundh wrote:
> > My personal goal in life right now is to stay as
> > far away from C++ as I can get.
>
> so what C compiler are you using ?
Gcc, mostly. I don't mind if it's capable of
compiling C++, as long as I can choose not to
write any.
--
Greg
cters
are also a subset of EBCDIC. So it seems to be
talking about characters as abstract entities here,
not as bit patterns.
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://ma
2001 - 2100 of 2499 matches
Mail list logo
