Dino Viehland wrote:
Why don't you just use binary mode then?
That just flips the problem to the other side.
Seems to me that IronPython really needs two string
types, Python string and .NET string, with automatic
conversion when crossing a boundary between Python
code and .NET code.
--
Greg
to different domains. Although I suppose
you could have another attribute to distinguish them
if necessary.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand
environment variables.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAIL PROTECTED
Nick Maclaren wrote:
Grrk. That's the problem. You don't get back what you have written
You do as long as you *don't* use universal newlines mode
for reading. This is the best that can be done, because
universal newlines are inherently ambiguous.
If you want universal newlines, you just have
On 9/29/07, Nick Maclaren [EMAIL PROTECTED] wrote:
Now, BCPL was an ancestor of C, but always was a more portable
language (i.e. it didn't start with a specific operating system in
mind), and used/uses a rather better model. In this, line separators
are atomic - e.g. '\f' is
Michael Foord wrote:
One of the great things about IronPython is that you don't *need* any
wrappers - you access .NET objects natively
But it seems that you really *do* need wrappers to
deal with the line endings problem, whether they're
provided automatically or you it yourself manually.
are represented
*inside* a Python program. The convention is quite clear -
a newline is \n and only \n. Confusion only arises when
people try to process strings internally that don't adhere
to that convention.
--
Greg Ewing, Computer Science Dept, +--+
University
. If you write just
\f, you get back \f. What the \f *means* is a separate
issue.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning person
at the source, which is the Python/.NET boundary.
Anything else would just lead to ambiguity.
So I'm voting -1 on my own proposal here.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem
internal representations of line endings.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAIL PROTECTED
. To make
that really true would require IronPython to become
a different language that has a different canonical
representation of newlines.
It's fine with me to keep things as they are.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury
than would happen if mark-and-sweep were used
for all memory management. Also, the programmer can
minimise the need for it by manually breaking cycles
where they are known to occur.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury
Nick Maclaren wrote:
if Python's own
interpretation is ambiguous, it is a sure recipe for different
translators being incompatible,
Python's own interpretation is not ambiguous. The
problem at hand is people wanting to use some random
mixture of Python and .NET conventions.
--
Greg Ewing
-platform ones like wxPython.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAIL PROTECTED
mallocs more if that fails.
I think it also counts the number of allocations
made since the last GC and does a GC when it gets
up to some threshold, so that things get cleaned
out periodically and the processing is spread
out somewhat.
--
Greg Ewing, Computer Science Dept
Adam Olsen wrote:
This isn't true at all. It's triggered by heuristics based on the
total number of allocated objects.
Hmmm, all right, it seems I don't know what I'm
talking about. I'll shut up now before I spread
any more misinformation. Sorry.
--
Greg Ewing, Computer Science Dept
Hrvoje Nikšić wrote:
That sounds like a case for the Pixbuf object to have a close method
(not necessarily called that) that releases the resources. The point of
GC is that you normally don't care if memory is released sooner or
later;
I think the problem here is that the GC's lack of
Martin v. Löwis wrote:
For stack frames,
such a registration is difficult to make efficient.
Also very error-prone if you happen to miss one. Although
maybe no more error-prone than getting the reference
counting right.
--
Greg
___
Python-Dev mailing
A while back I wrote about a problem I was having with
the ordering of -framework options in distutils compilation
commands. Well, now I've discovered something even stranger.
When distutils executes the following link command, I get
a bunch of undefined OpenGL-related symbols. But if I
copy and
Ronald Oussoren wrote:
Is that the system supplied version of Python?
No, it's my own installation of 2.3, but it's installed
as a framework in /Library/Frameworks.
My guess is MACOSX_DEPLOYMENT_TARGET: this is set in the
environment by distutils.
I wondered about that -- I've noticed that
Ronald Oussoren wrote:
The deployment target does have an influence on how the compiler
functions, which can explain when setting the target to a different
value causes problems.
I did some more experimenting, and it doesn't seem to be
related to MACOSX_DEPLOYMENT TARGET. I tried setting
Graham Horler wrote:
I would be inclined to move gcc to gcc-real (for example), and create a script
called gcc which dumps all environment variables, and command-line arguments
Well, I tried that -- and things got even weirder still.
With the wrapper in place between distutils and gcc, the
Oleg Broytmann wrote:
Do you have a few different copies of gcc installed with setup.py called
the wrong one and your shell script the right one?
As far as I can tell, it's using my PATH to find gcc,
and that leads to /usr/bin/gcc, which is the same one
my wrapper calls.
--
Greg
I wrote:
As far as I can tell, it's using my PATH to find gcc,
and that leads to /usr/bin/gcc, which is the same one
my wrapper calls.
To make sure, I installed my wrapper in place of /usr/bin/gcc
and the same behaviour occurs.
--
Greg
___
Shane Hathaway wrote:
I was aware of Guido's earlier rejections, but I figured the rejection
was due to the risky implicit optimization proposed by others. Perhaps
the objection is deeper than that; I suspect Guido specifically objects
to excessive use of recursion.
As I recall, one of the
Steve Holden wrote:
Using a radix notation for literals would, IMHO, be acceptable if you
can get the idea accepted
This would make decimal (or at least a part of it) a required
part of the Python core rather than an optional module. There
might be some resistance to that.
--
Greg
[EMAIL PROTECTED] wrote:
This interface follows the completely stupid semantics of System V and
IEEE Std 1003.1-1988 (``POSIX.1'') that require that all locks
associated with a file for a given process are removed when any file
descriptor for that file is closed by that
[EMAIL PROTECTED] wrote:
Does fcntl.flock work over NFS and SMB and on Windows?
I don't think file locking will ever work over NFS, since
it's a stateless protocol by design, and locking would
require maintaining state on the server.
--
Greg
___
Lauri Alanko wrote:
In the end, for now, I made protocol 0 textual,
That could be a mistake. I believe there are some objects,
such as array.array, that use a binary format for pickling
even in protocol 0.
--
Greg
___
Python-Dev mailing list
Guido van Rossum wrote:
Isn't there? You can just use super() ISTR,
That may work, now that I come to think about it.
However, super() is not a complete solution, because
it doesn't let you choose which inherited method
to call in a multiple inheritance situation.
--
Greg
Guido van Rossum wrote:
if you want more control, you can just get the property object out of
the class you want
You're quite right. I was thinking that getting the
property would trigger the access machinery, but of
course you're getting it from the class rather than
the instance, so that
Fred Drake wrote:
@property
def attribute(self):
return 42
@property.set
def attribute(self, value):
self._ignored = value
Hmmm... if you were allowed general lvalues as the target of a
def, you could write that as
def
Raymond Hettinger wrote:
Let's stick with propset which has precedent as an svn action and
serves as a short, simple mnemonic to the functionality.
But if we're going to have propset, it raises the question
of why there isn't a propget.
--
Greg
___
Phillip J. Eby wrote:
The lookup sequence should probably be something like:
1. type(ob) is cls
2. issubclass(type(ob), cls)
But can't issubclass be overridden as well?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury
in this case)
Fine by me. I've always thought they were of dubious
value in the first place.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm
Guido van Rossum wrote:
Not quite. You can evolve an API from an instancemethod into a
staticmethod without changing the call sites.
But is there ever any need to do that, rather than leave
it as an instance method?
Personally it would never have occurred to me to do that.
If you want to be
Phillip J. Eby wrote:
If you are configuring it per-class and
accessing it per-instance, and reusing an existing function, you have to
make it a staticmethod.
I don't understand that. Can you provide an example?
some subclasser later finds that he wants access to
'self'?
Then he
Christian Heimes wrote:
Should the node structure gain an additional field to drag the filename
around?
Why not?
Early on in the design of the Pyrex compiler, I made the decision
that every parse tree node would contain a source filename and
position, down to character resolution. It's paid
André Malo wrote:
* Greg Ewing wrote:
But you could just as well wrap
it in a function that takes self and discards it,
I always thought, that this is exactly what staticmethod does.
Not quite -- staticmethod prevents a self from getting
passed in the first place, so there's no need
Steve Holden wrote:
The namespace should really be called __global__. I doubt this will fly,
because it's too radical, and unfortunately would undermine the global
keyword
__uberglobal__
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Guido van Rossum wrote:
You can do that but the special entry in globals is still required in
order to pass it on to all scopes that need it.
Unless you use something other than a plain dict for
module namespaces.
--
Greg
___
Python-Dev mailing list
The next step up from global would be __galactic__.
--
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
Nick Coghlan wrote:
why not call it __implicit__?
But isn't __explicit__ better than __implicit__? :-)
I tend to agree about __root__, though -- it just
doesn't seem quite right somehow.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Another idea:
__ubiquitous__
--
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_dictionary_where_all_the_builtins_are_now__
__the_entry_formerly_known_as_builtins__
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Terry Reedy wrote:
The only problem would be if someone put
the incantation into a non-main module named 'main.py', but the same is
true today of '__main__.py'. And I would consider either a buggy practice.
I often put the real main code into a separate module, so
that it gets compiled to a
Bill Janssen wrote:
What I'd like to do is just use the socket API,
something like:
blocking = self.getblocking()
try:
self.setblocking(1)
self.do_handshake()
finally:
self.setblocking(blocking)
I'm not sure this is the right approach. If the calling
Terry Reedy wrote:
I would prefer plain 'yield' to 'yield break' as a synonym for 'raise
StopIteration'.
Don't we already have a plain yield these days meaning
something else?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Manuel Alejandro Cerón Estrada wrote:
The real problem is that
raising StopIteration is not orthogonal.
This is a non-problem as far as I can see. In a generator,
the way to stop the iteration is simply to return. In a
non-generator iterator, you're still going to have to
raise StopIteration.
Guido van Rossum wrote:
Does Unix even promise that a signal gets delivered twice if it gets
sent quickly twice in a row?
No, it doesn't.
However, this doesn't necessarily mean that you can just
drop them when the pipe becomes full. If more than one
type of signal is sharing a pipe, you don't
Manuel Alejandro Cerón Estrada wrote:
Acording to PEP 255:
Note that return isn't always equivalent to raising StopIteration: the
difference lies in how enclosing try/except constructs are treated.
All that means is that
def g():
try:
if 0:
yield
, using CPU unnecessarily
is a bad thing for any application to do on a multitasking
system.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm
Guido van Rossum wrote:
Hm, Apple and Microsoft don't seem to think so. They go out of their
way to implement elaborate visual effects.
Well, that's a different issue -- assuming the visual
effect is something wanted, then the CPU required to
produce it isn't unnecessary.
But there's no
tomer filiba wrote:
the idea i came up with is, using exceptions for functional
continuations: after all, the exception's traceback holds the entire
context...
The problem with this is that, if the call chain has passed
through a C-implemented function at some point, the traceback
*doesn't*
By the way, I wouldn't call this a continuation, as that
word implies a bit more (reusability). It's more like a
coroutine or lightweight thread.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
On Jan 25, 2008 11:21 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
... int() for making ints from the non-fractional
portion of a float.
To me, the concept of the integer part of a float isn't all that
well defined. It's really a property of a particular representation
rather than the
Isaac Morland wrote:
What about an option (maybe even a default) to send the prompt to stdin?
The Postgres command line interface psql appears to do this:
$ psql 21 /dev/null
Password:
$
No, it's probably using the C stdlib routine getpass(). From the man
page:
The getpass()
Jeroen Ruigrok van der Werven wrote:
I cannot find anything explicitly in favour of or against this in POSIX. The
stuff quoted below is what I could find.
3.105 Command Language Interpreter
STDERR
This section does not describe error messages that refer to incorrect
operation of the
Guido van Rossum wrote:
On Jan 28, 2008 12:35 AM, Greg Ewing [EMAIL PROTECTED] wrote:
So it appears that the official Unix Way prefers using stderr
over stdout for prompting, if using the std files for it at all.
That's a dangerous generalization from just one example. I'd prefer it
if you
Travis Oliphant wrote:
You could
argue that it would be more informative by showing the C-equivalent
structure as a 2-d array. However, it would also create the possibility
of confusion by implying an absolute relationship between the C-compiler
and the type description.
Just to check
Lisandro Dalcin wrote:
Travis, all this make me believe that (perhaps) the 'format'
specification in the new buffer interface is missing the 'C' or 'F'
ordering in the case of a countiguos block.
Not strictly necessary, since you can always reverse the
indices when dealing with Fortran if need
Christian Heimes wrote:
By the way objects are always aligned at 8 byte address boundaries. A 12
or 4 bytes object occupies 16 bytes.
Maybe pymalloc should be enhanced so it can cope with
certain odd-sized objects, such as 12 bytes?
--
Greg
___
Eric Smith wrote:
Are you saying I should call _PyType_Lookup first?
No, I think he's saying that you don't need to call
_PyType_Lookup at all, because anything that it could
find will also be found by PyObject_GetAttr.
So just call PyObject_GetAttr and it should Just Work.
--
Greg
Eric Smith wrote:
1: exposing builtin_format(), probably giving it another name
(PyObject_Format?) and moving it somewhere other than bltinmodule.c.
PyObject_Format sounds more like an API for invoking the
__format__ lookup mechanism. Maybe something like
PyObject_DefaultFormat would be
Raymond Hettinger wrote:
ISTM that we need two versions of oct() like
we need a hole in the head.
I don't know about oct(), but I found hex() to be quite useful
the other day when I was using the interactive interpreter to
to some hex calculations. It would have been quite tedious
having to say
Neal Becker wrote:
(Or, help me understand, what is the difference between a type that I create
using python C api and a python class?)
Classes that you create in Python have a __dict__ attribute
holding a dictionary for arbitrary attributes to go in.
Most types defined in C don't bother
M.-A. Lemburg wrote:
Why not also make unicode() the default type constructor and only
keep str() as alias to simplify porting (perhaps with a warning) ?
-1 on making us type 7 characters instead of
3 all over the place.
The term string is just too overloaded with all kinds of
Christian Heimes wrote:
The latest alphas of Python 2.6 and 3.0 are build with VS 2088.
Wow, that must be a very, very pre-alpha release...
Or has someone at Redmond stolen Guido's time machine?
--
Greg Ewing, Computer Science
is to rename the Library Reference
to the Class and Module Reference or something like
that.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm
*that* library instead. If it were compiled with
gcc but using one of the Microsoft libraries, the same
situation would exist as before.
The entire mess is all Microsoft's fault for not picking
one version of libc and sticking to it.
--
Greg Ewing, Computer Science Dept
Mike Meyer wrote:
Trying to install it from the repository is a PITA, because
it uses both the easyinstall and Pyrex
It shouldn't depend on Pyrex as long as it's distributed
with the generated C files. If it's not, that's an
oversight on the part of the distributor.
--
Greg Ewing, Computer
Adam Olsen wrote:
The term Displays is pretty obscure as well,
Hmmm, I'd call them constructor expressions or some such.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Georg Brandl wrote:
Adam Olsen schrieb:
Another example is the use of BNF, which although dominant in its
field, it provides a steep learning curve for most programmers.
We could of course accompany each BNF-described item with an example.
An alternative to BNF would be syntax diagrams.
Steven Bethard wrote:
Is this mainly a request to use more open source tools? Because if
the concern is just cost, Python 2.6 and 3.0 compile with the free
Microsoft Visual Studio 2008 Express editions.
I don't think it's only about cost, it's about not
being reliant on tools that appear and
Alexey Borzenkov wrote:
I think the best lesson here is Tcl. Because it uses stubs mechanism,
you don't need to depend on tclXX.dll, you don't deal with really
direct implementation details, you don't care about runtimes,
How does that solve the problem of an extension using
one stdio library
Aahz wrote:
* Other Python implementations (Jython, PyPy, IronPython) may not be
able to provide the same type implementations
* Algorithmic information does sometimes change between versions, and
keeping the docs updated is not trivial
Still, I think there are some general expectations one
Martin v. Löwis wrote:
Yes - the assumption is that more del calls will follow, so that the
dictionary eventually ends up empty. Only when new inserts are made,
that assumption is proven wrong, and the shrinking can be done in
one sweep.
Hmmm. So the most efficient way to copy a dict that
Forrest Voight wrote:
Slice objects that are produced in a list index area would be different,
and optionally the syntax for slices in list indexes would be expanded
to work everywhere.
Something like this was quite close to getting in a while
back, but it was eventually dropped. Anyone
Dimitrios Apostolou wrote:
On the other hand notes could be added for various oddities according to
experience. For example that for sets up to 10(?) elements, a list would
probably be better because of the hashing overhead.
That's the sort of thing that tends to be *very*
implementation
Martin v. Löwis wrote:
To implement such a system, you need to get all ABI dependencies out
of the header files; this includes the structure layouts in particular.
That could hurt the performance of some things. Macros
like PyList_GET_ITEM etc. rely on knowing about struct
layouts to get at
Martin v. Löwis wrote:
I follow the advice Guido gave: I use the data
structure that will make my code shortest and easiest
to read,
But given a choice such as list vs. dict, the code
is almost identical either way. What do you do then?
Toss a coin? Or make a few educated guesses based on
I'm trying to send a proxy form, but all my mail to
[EMAIL PROTECTED] or [EMAIL PROTECTED] is getting bounced.
Is there another address I can send it to that goes
through a different mail server?
--
Greg
___
Python-Dev mailing list
Hrvoje Niksic wrote:
Is there a reason why the operator module doesn't have an operator.call
function?
I've been thinking about proposing an enhancement
concerning generators that would entail making
call a reserved word, so I'd be a little
disappointed if this name were used.
Maybe apply()
Guido van Rossum wrote:
What's so special about your proposal that requires a new keyword?
I was thinking about the proposals that are made
from time to time for things like
yield *foo
to yield all the items from a sub-generator. I was
also thinking about what could be done to make
using
Guido van Rossum wrote:
Why is call expr a more enticing syntax than yield *expr ?
I was thinking it would read better when you're
using generators as lightweight threads, and you
want the one-level-deep nature of generators to
be hidden as much as possible.
The fact that yielding is going
Stephen J. Turnbull wrote:
Greg Ewing writes:
The fact that yielding is going on is not of
interest in that situation
But doesn't yield in the sense of yield the right of way mean
exactly that?
I've no problem with using 'yield' when actually
giving up control. But the code making
Guido van Rossum wrote:
It would be way too confusing to have a different form of call with
totally different semantics that nevertheless used the same
*terminology* as is used for regular calls.
I expect you're right, so I won't argue for calling
it call any more.
I'd still like to find a
Willem Broekema wrote:
Function g violates the current limitation that generators can't
return with a value. So can g only be used using yield * then, or
would that limitation be removed?
The limitation would be removed, in the interests
of making it easier to use generators as coroutines.
Guido van Rossum wrote:
We already have yield expressions and they mean something else...
They don't have a * in them, though, and I don't
think the existing meaning of yield as an expression
would carry over into the yield * variant, so there
shouldn't be any conflict.
But if you think there
gl...@divmod.com wrote:
has anyone considered the syntax 'yield from iterable'?
That would be reasonable, too. I don't really have any
strong feelings about the syntax at the moment, except
that I'd like it to be something reasonably short so
that embedding it in an expression is a feasible
I've discovered something slightly misleading in the docs
for PyObject_IsInstance:
When testing if B is a subclass of A, if A is B, PyObject_IsSubclass
returns true. If A and B are different objects, B‘s __bases__
attribute is searched...
This suggests that issubclass(A, A) will always be
Raymond Hettinger wrote:
This smells like a bug that brings issubclass() out of sync with
isinstance().
No, it affects both isinstance() and issubclass().
They both raise a TypeError if the purported class
object doesn't have a __bases__ attribute that is
a tuple.
This isn't necessarily
Brett Cannon wrote:
Is there a Python connection I'm missing?
http://www.latimes.com/news/science/la-sci-satellite-collision15-2009feb15,0,7901281.story
Well, the front page of python.org does say NASA uses Python...
Also it sounds like they could do with a really good
garbage
Georg Brandl wrote:
Since I cannot imagine a scenario where you would want to have non-classes
as the arguments of issubclass(),
I had one today, which is what led me to discover this.
I'm working on a Python-Ruby bridge that wraps Ruby
objects and classes in Python objects.
I wanted to make
Terry Reedy wrote:
The new (in 3.0 and maybe 2.6, but undocumented) special methods
__instancecheck__ and __subclasscheck__ let one overload the default
behavior of isinstance and issubclass.
That's fine for 3.0, but I don't think the current behaviour
should be removed from any 2.x version,
Leif Walsh wrote:
If only we had a second Earth to mess with, we could just copy and swap.
Or we could use a generational approach, doing all our
messy stuff around the moon and copying to earth when
we've got our traffic control issues sorted out.
--
Greg
Sebastian Rittau wrote:
Is it a design decision that duck-typing self does not work or is there a
technical reason?
There's no technical reason as far as user-defined
classes are concerned. I think it was introduced to
help catch errors due to making inherited method
calls to the wrong class,
Christian Heimes wrote:
In 2.x a class objects wrap their functions in a method wrapper. The
method wrapper does the type check. You can get around the type check by
using the im_func attribute of the method wrapper.
You could probably also create a decorator that
gives you something behaving
Steven D'Aprano wrote:
Currently, if I want to verify that (say) cFoo and Foo do the same
thing, or compare their speed, it's easy because I can import the
modules separately.
Also, won't foo.py be wasting time in most cases by
defining python versions that get overwritten?
Instead of
Brett Cannon wrote:
So while this alleviates the worry
above, it does mean that anything that gets rewritten needs to have a
name that does not lead with an underscore for this to work.
You can use an __all__ list to explicitly say what
is to be exported.
--
Greg
801 - 900 of 2277 matches
Mail list logo
