ly not something that
should be a program-wide setting.
--
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
not be at the end of the mro
with respect to a particular method?
The only thing I can think of is to write all my
super()-using methods defensively like this:
def m(self):
...
s = super(C, self)
if hasattr(s, 'm'):
Guido van Rossum wrote:
> In the world where cooperative multiple inheritance
> originated (C++), this would be a static error.
I wasn't aware that C++ had anything resembling super().
Is it a recent addition to the language?
--
Greg
___
jects not to have upper() and lower()
methods at all 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
ode in to avoid them or even using a different algorithm.
But couldn't you just put in an interrupt handler that
counts the interrupts, for the purpose of measurement?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
articular piece of
code generates. Surely that's deterministic, and isn't
affected by any of that stuff?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
re is no way such
> changes would go into mainstream CPython.
How much code is actually out there that uses __subclasses__?
It seems like a fairly esoteric corner of the language to me.
In any case, I think this approach should certainly be tried,
and if it works out, considere
d idea
to rely on Microsoft turning a blind eye to 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/python-dev/archive%40mail-archive.com
o different objects in the first place.
It sounds to me like Zope is using the approach it's
using because it's having to work with Python as it
currently is, not because its approach is the best one.
--
Greg
___
Python-Dev mailing list
Py
e were talking about floating point exceptions. Unless
your TLB miss handler uses floating point arithmethic,
there's no way it can get interrupted by one. (And if
it does use floating point arithmetic in a way that
can cause an exception, you'd better write it to d
fine-grained enough to begin
with.
--
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
that mess with unrelated critical
data structures.
--
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__ on an existing object; only to have __init__
> implicitly called when a new object is constructed.
What about calling an inherited __init__ method?
Your proposed rule would seem to disallow
BaseClass.__init__(self, ...)
--
Greg
___
ubclassed. Which means we're back to the
situation of having to prevent access to class objects.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
(Fixing the inadvertent ValueError is trivial, so I'm
concentrating on getting the tests right first.)
Oh yeah, my patch is relative to the 2.4 branch.
Greg
--
Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/
I don't
; result to fit in a Py_ssize_t.
Why is it defined to do this instead of raising OverflowError?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/option
r range exception that *should* be produced by the code
using the index, and would be if it got the equivalent
index value as an int or long directly.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
Guido van Rossum wrote:
> In my recollection I tried to avoid this exact behavior. I wanted
> __index__() to just return the unclipped int or long value, but have a
> C API that clipped it for use in slice operations.
So is there still a chance to fix it?
which rounds and converts to
an int in one go? Whenever I use round(), I almost
always want the result as an int, and making me do
it in two steps seems unnecessarily bothersome.
Since automatic float->int coercion is being increasingly
disallowed, use cases for this are becoming more and m
portably, though. Well, I'll see if I can whip up a Unix-y
solution and see if anyone knows how to make it portable.
Greg
--
Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/
Be careful: sometimes, you're only standing on the shoulders of idiots
ill do with
negative numbers. It's not even immediately obvious
that it's doing round-to-nearest-integer unless
you're familiar with the idiom. A single well-named
function would be much more explicit.
--
Greg
___
Python-Dev mailing list
Py
the argument.
No, round() wouldn't have that option at all. If
you wanted it, you would use fround() instead,
which would have the option and return a float
always.
This would be a Py3k thing, obviously. If done
before then, the new function would have to be
gi
give a different result than you would
want.
> Hmm, looks like a YAGNI to me,
In all my programming so far I've found
numerous uses for round-to-int, and exactly
zero uses for round-binary-float-to-decimal-
places. So from my point of view, the YAGNI
applies to the *current
to *have* both.
What's the feeling about this? If, e.g. int()
were changed in Py3k to round instead of truncate,
would it cause anyone substantial pain?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
Michael Chermside wrote:
> (Why you would WANT
> more than around 53 bits of precision is a different question, but
> Decimal handles it.)
You can't have travelled far beyond Alpha Centauri
recently. The major interstellar banking corporations
need *quite* a lot of bits for dealing with the
econom
r something else.
--
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
an integer instead of
> a float would buy you.
It saves you a function call in the vast
majority of cases, where an int is what
you ultimately want.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
t.
Sure you can define your own function to do
this. But that's still a considerable burden
when you add up the effort over all the
programs that use int(round()).
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
h use for
it personally.
I'm also *not* advocating changing the existing
behaviour of round() or int(). That was just
tentative speculation.
All I'm asking for is another function that does
round-to-int directly. I wouldn't have thought
that was such a controversial idea, g
M.-A. Lemburg wrote:
> Perhaps we ought to add an exception to the dict lookup mechanism
> and continue to silence UnicodeErrors ?!
Seems to be that comparison of unicode and non-unicode
strings for equality shouldn't raise exceptions in the
first plac
James Y Knight wrote:
> And it does in C because C doesn't have arbitrary size integers, so if
> round returned integers, round(1e+308) couldn't work.
Also, in C you can use the result directly in an int
context without complaint. In Python these days, that
is usually disa
disputing that an exception should be raised
if the string *must* be interpretable as characters in
order to continue. But that's not true here if you allow
for the interpretation that they're simply objects of
different (duck) type and therefore unequal.
--
Greg
_
ypes
may or may not indicate a bug in the code as well,
but we don't seem to worry that it doesn't raise an
exception.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
nt,
and distributing a binary doesn't violate the patent,
then what *would* constitute a violation of a software
patent?
Writing new code using the algorithm? Compiling
something which uses it?
--
Greg
___
Python-Dev mailing list
Python-Dev@python
Martin v. Löwis wrote:
> In the context of an encryption algorithm, the right to
> use would be the most prominent one; you wouldn't be
> allowed to use the algorithm unless you have a patent
> license.
But what does "use" *mean* in relatio
n
with open source software.
--
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 remember there being much discussion about it.
Has anyone had any thoughts on 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/py
e done.
Can you show a realistic use case for this, that
demonstrates a clear advantage to having new
syntax?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
n arrays concisely. The +: family would fill this
need.
PPS: Yes, I know the use of : might be ill-advised.
It's just an example - any other concise notation
would do as well.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
otHashableError, that hash functions were
expected to raise in this situation instead of a
generic TypeError.
For backwards compatibility it could be a subclass
of TypeError.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
Martin v. Löwis wrote:
> We had this discussion before; if you use ob_size==0 to indicate
> that it's an int, this space isn't needed in a long int.
What about int subclasses?
--
Greg
___
Python-Dev mailing list
Python-Dev
Guido van Rossum wrote:
> I worry that dropping the special allocator will be too slow.
Surely there's some compromise that would allow
recently-used ints to be kept around, but reclaimed
if memory becomes low?
--
Greg
___
Python-Dev mail
ere isn't? Actually a lot of APIs currently assumen that.
Also it means you'd pay a penalty every time you
access it, whereas presumably short ints are the
case we want to optimise for speed as well.
--
Greg
___
Python-Dev mailing list
Python-
Martin v. Löwis wrote:
> Greg Ewing schrieb:
>>Also it means you'd pay a penalty every time you
>>access it
>
> That penalty is already paid today.
You'd still have that penalty, *plus* the
overhead of bit masking to get at the value.
Maybe that wouldn'
Georg Brandl wrote:
> Or disallow tabs altogether.
-1. I'd be annoyed if Python started telling me I wasn't
allowed to write my source the way my preferred editor
(BBEdit) works best. Very annoyed.
--
Greg
___
Python-Dev mailing li
non-pep8-compliant module naming structure?
--
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:
> ET was written years before the "certain modules should use camelcase" stuff
> was removed from PEP 8.
Maybe so, but I was hoping that additions to the
stdlib in this day and age might be adapted to follow
modern conventions instead of just being plonked in
Nick Coghlan wrote:
>reversed(seq[start:stop:step]) becomes
> seq[(stop-1)%abs(step):start-1:-step]
>
> An rslice builtin would make the latter version significantly easier to read:
>
>seq[rslice(start, stop, step)]
How would this deal with omitted start and/or sto
Jan Kanis wrote:
> However, PyGTKs problem does get
> solved, as long as there is _a_ thread that returns to the interpreter
> within some timeframe. It seems plausible that this will happen.
I don't see that this makes the situation much better,
as it just shifts the need for polling to anoth
that it *always* steals a reference,
regardless of whether it succeeds or fails. I expect the
same is true of Py_BuildValue.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:/
ur
differs when it fails is awkward to use safely
at best, impossible at worst (if there's no way
of finding out what needs to be decrefed in
order to clean up properly).]
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
that buffer may fill and
> we lose signals.
That might be an argument for *not* trying to
communicate the signal number by the value
written to the pipe, but keep a separate set
of signal-pending flags, and just use the pipe
as a way of indicating that *something* has
happened.
--
Greg Ewing, C
omputer architectures have become far
too clever for their own good. :-(
--
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
Talin wrote:
> Is the result a new-style or classic-style class? It would be nice if
> using the empty parens forced a new-style class...
No, it wouldn't, IMO. Too subtle a clue.
Best to just wait for Py3k when all classes will
be new-styl
system structure. There really shouldn't be
any such thing as sys.path -- the view that any
given module has of the package namespace should
depend only on where it is, not on the history of
how it came to be invoked.
--
Greg Ewing, Computer Science Dept, +--
7;s sufficient to be
able to lock just one object at a time. Maybe it is,
but some more formal consideration of that might be
a good idea.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Chris
ct. What *looks* like read-only access at the
Python level involves refcount updates just from the
act of touching the object.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, N
o go through the relevant motions, and
see what timings are produced for single-threaded
code. It wouldn't be a working implementation, but
you'd find out pretty quickly if it were going to
be a disaster.
--
Greg Ewing, Computer Science Dept, +--
Martin Devera wrote:
> Greg, what change do you have in mind regarding that "3 instruction
> addition" to refcounting ?
I don't have any change in mind. If even an atomic inc
is too expensive, it seems there's no hope for us.
--
Greg
of static
information is the layout of the filesystem.
--
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
s in Eiffel), which is a kind of
meta-language for describing the shape of the class
namespace, and it allows each source file to have its
own unique view of that namespace. I'm groping towards
something equivalent for the Python module namespace.
(AMP - Ass
Another thought on static module namespace configuration:
It would make things a *lot* easier for py2exe, py2app
and the like that have to figure out what packages
a program depends on without running the program.
--
Greg
___
Python-Dev mailing list
ue view of the module
namespace, defined at the time the module is installed,
that can't be disturbed by anything that any other module
does.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
, and
more efficient.
--
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
Guido van Rossum wrote:
> While I agree with your idea(l), I don't think that's what Greg meant.
> He clearly say "sys.path should not exist at all".
Refining that a bit, I don't think there should be
a *single* sys.path for the whole program -- more
like each modu
e item is
not found. I don't think I've ever found getting an exception
from it to be useful, and I've often found it a nuisance.
What experiences have others had with it?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
ould probably use this technique
more often.
> So, before being entertained for addition to the standard library, this
> idea should probably first be posted as an ASPN recipe,
That's a reasonable idea.
--
Greg
___
Python-Dev mailing list
Pyth
together,
without going into low-level details. Then there was a
"Reference" section that systematically went through and
gave all the details of the API.
While Inside Mac could often be criticised for omitting
rather important info in either section now and then, I
think they ha
a frequent enough
problem to be worth the effort.
--
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
hat would make good link partners" when
obviously no human eye of theirs has actually seen my site.
Addressing me as "Canterbury" in the To: line wasn't a good
sign either. :-)
I'm tempted to take them up on the offer and see whether
they actual
a python-version-independent protocol.
--
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
[0] in '#;':+ if line.strip() == '' or line.strip()[0] in '#;':
continueRegards,Greg Willden (Not a member of python-dev)-- Linux. Because rebooting is for adding hardware.
___
Python-Dev mailing
Fredrik Lundh wrote:
> marshal hasn't changed in many years:
Maybe not, but I was given to understand that it's
regarded as a private format that's not guaranteed
to remain constant across versions. So even if
it happens not to change, it wouldn't be wise to
perate on path objects. That would make sense,
because the path algebra ought to be a closed set
of operations that's tightly coupled to the platform's
path semantics.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
ed "file:".
That's not to say there shouldn't be a function available
that understands it, but I wouldn't want it built into
all functions that take pathnames.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
try )
I don't think that expressing one platform's pathnames
in the format of another is something you can do in
general, e.g. going from Windows to Unix, what do you
do with the drive letter?
You can only really do it if you have some sort of
network file system connect
unlikely that such a
platform will be invented in the foreseeable future
(even classic MacOS *had* a notion of paths, even
if it wasn't the preferred representation). So
all this is probably YAGNI.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
htt
out all the offsets
(which is tedious, error-prone and hostile to
modification)?
--
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/arc
Nick Coghlan wrote:
> Greg Ewing wrote:
>> Also, what if I want to refer to fields by name
>> but don't want to have to work out all the offsets
> Use the list definition form. With the changes I've
> suggested above, you wouldn't even have to name the f
it would make sense to expose the associated data layout descriptors as
> array.datatype.
Seem to me that arrays are a sub-concept of binary data,
not the other way around. So maybe both arrays and data
types should be in a module called 'binary' or some such.
--
Greg
__
Travis E. Oliphant wrote:
> The 'kind' does not specify how "big" the data-type (data-format) is.
What exactly does "bit" mean in that context?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
Travis E. Oliphant wrote:
> How to handle unicode data-formats could definitely be improved.
> Suggestions are welcome.
'U4*10' string of 10 4-byte Unicode chars
Then for consistency you'd want 'S*10' rather than
just 'S10' (or at le
Travis E. Oliphant wrote:
> Greg Ewing wrote:
>>What exactly does "bit" mean in that context?
>
> Do you mean "big" ?
No, you've got a data type there called "bit",
which seems to imply a size, in contradiction
to the size-independe
ommunicate via this mechanism,
or is that outside its scope?
--
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
worth including some features in the standard
for describing pixel formats.
Pygame seems to have a very detailed and flexible system
for doing this, so it might be a good idea to have a
look at that.
--
Greg
___
Python-Dev mailing list
Pytho
butes distinguishing between struct, array, etc.
That would be single-type but multi-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
signed int
'u4' # 4-byte unsigned int
'u4b' # 4-bit unsigned int
(Next we can have an argument about whether bit
fields should be packed MSB-to-LSB or vice versa...:-)
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
s or trees).
Yes, and more complex arrangements of types that
reference each other.
> If that is the case, then it's
> easily supported once support for pointers is added.
But it doesn't fit easily into the single-object
model.
--
Greg
___
getting a ctypes type corresponding
to a given data layout description and vice versa.
--
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
Fredrik Lundh wrote:
> the "right solution" for things like this is an *API* that lets you do
> things like:
>
> view = object.acquire_view(region, supported formats)
And how do you describe the "supported formats"?
That's where Travis's propos
pret the
second path in the context of the first".
Having said that, I can see there could be an
element of confusion in calling it "join".
--
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
not necessarily another NumPy
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/python-dev/archive%40mail-archive.com
ct should almost certainly
be immutable. Since it's separated from the data
it's describing, it's possible for one datatype
object to describe multiple chunks of data. So
you wouldn't want to mutate one in case it's being
used for something
ed to tolerate the presence of a previous
partial result when re-trying).
It could be argued that shutil.copytree should clean
up after itself if there is an error, but that might
not be what you want -- e.g. you might want to find
out how far it got, and maybe carry on from there
next time. It'
ary can do about this. Whatever it tries
to do, the fact will remain that it's impossible to
have a regular file called "con", and users will
have to live with that.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
a path that
wasn't rooted in some existing absolute path.
--
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
n't want to do.
--
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
an element datatype and a shape.
--
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
Steve Holden wrote:
> Greg Ewing wrote:
>
>>Having said that, I can see there could be an
>>element of confusion in calling it "join".
>>
>
> Good point. "relativise" might be appropriate,
Sounds like something to make my computer go at
warp sp
along sys.path into memory and then go searching
through 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/python-dev/archive%40mail-archive.com
1101 - 1200 of 2499 matches
Mail list logo
