Phillip J. Eby wrote:
So, this is a nice
example of how complex it can be to extend the distutils in ways that don't
break random popular packages.
It's probably also an example of what happens when
something doesn't have a well-documented extension
interface -- nobody can tell what's an
Paul Moore wrote:
I do things like
python setup.py build --compiler=mingw32 bdist_wininst
which seem to work for me. Is that any help?
Possibly. I'll have to try it next time I have the
problem and see.
BTW, does that do anything different from
python setup.py build
Nick Coghlan wrote:
During implementation, the meanings of context and context manager were
swapped from the meanings in the approved PEP, leading to the current
situation where decimal.Context is actually not, in fact, a context.
That's rather disappointing. I *liked* the way that
Paul Moore wrote:
Well, having 2 versions of a module installed and
knowing that which one is in use depends on require calls which get
issued at runtime worries me far more.
There's also the problem of having module A which requires
version 2.0 or earlier of Z, and B which requires 2.1 or
Thomas Heller wrote:
The best solution is to configure the mingw32 compiler in the distutils
configuration file.
That's the same conclusion I came to. But it's
unintuitive that you can't also do the same
thing using command line options, or if you
can, it's not obvious how to do it.
--
Greg
Thomas Wouters wrote:
On 4/21/06, *guido.van.rossum* python-3000-checkins@python.org
mailto:python-3000-checkins@python.org wrote:
somehow changing import foo into from . import foo ...
caused things to break. Bah.
Hm, this is possibly a flaw in the explicit relative import
Alex Martelli wrote:
GMP is covered by LGPL, so must any such derivative work
But the wrapper is just using GMP as a library, so
it shouldn't be infected with LGPLness, should it?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
A.M. Kuchling wrote:
Does this detail matter to users of the Decimal module, though? Those
users may well be thinking using the term 'context'.
Seems to me the most straightforward term should be
applied to the object that users are most likely to
know about and use. The term context is
Alex Martelli wrote:
gmpy.c
#include's gmp.h and uses (==expands) some of the C macros there
defined -- doesn't that make gmpy.o a derived work of gmp.h?
Assuming that gmp.h is the header which defines the
public interface of the gmp library, any code which
uses it as a library will be
Nick Coghlan wrote:
the context expression in the with
statement produces a context manager with __enter__ and __exit__ methods
which set up and tear down a managed context for the body of the with
statement. This is very similar to your later suggestion of context
guard and guarded
Delaney, Timothy (Tim) wrote:
So would this also be a SyntaxError?
for x in stuff:
x = somethingelse
That would be something to be debated. I don't
really mind much one way or the other.
--
Greg
___
Python-Dev mailing list
Terry Reedy wrote:
my way to call your example (given the data in separate variables):
make_person(name, age, phone, location)
your way:
make_person(name=name, age=age, phone=phone, location = location)
For situations like that, I've sometimes thought
it would be useful to be able to say
Josiah Carlson wrote:
for line in lines:
line = line.rstrip()
...
I'm generally -0 on the raise a SyntaxError in this particular case,
That's a good point. I'm inclined to agree.
I think I might have even done something like
that recently, but I can't remember the
Guido van Rossum wrote:
On 5/2/06, Greg Ewing [EMAIL PROTECTED] wrote:
make_person(=name, =age, =phone, =location)
And even with Terry's use case quoted I can't make out what you meant
that to do.
I meant it to do the same thing as
make_person(name=name, age=age, phone=phone
of potential arguments to many
of the constructors. The only sane way to deal with
that is for them to be keyword-only, at least
conceptually if not in actual implementation.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe
Terry Reedy wrote:
The dispute is about the sensibility and
politeness of requiring a small fixed number of required, no-default args
to be passed by name only
There seems to be some confusion between two different
subthreads here. BJörn Lindqvist seemed to be saying that
instead of my
Tim Peters wrote:
Instead it would make best sense for each
sprint project to work in its own branch, something SVN makes very
easy, but only for those who _can_ commit.
There's no way of restricting commit privileges to
a particular branch?
--
Greg
Nick Coghlan wrote:
So I suggest splitting the internal data into 'path elements separated
by os.sep', 'name elements separated by os.extsep'
What bothers me about that is that in many systems
there isn't any formal notion of an extension,
just a convention used by some applications.
Just
Mike Orr wrote:
How do you do slicing and joining? If Path subclasses object, it
could be done there like in the first example. But if Path subclasses
string,
Er, hang on, I thought the idea was that it wouldn't
subclass either tuple *or* str, but would be a new
class all of its own.
That
Edward Loper wrote:
If one of the path segments contained a path-splitting character,
should it automatically get quoted?
No, an exception should be raised if you try to construct
a Path object containing such a name. No such object could
exist in the file system, so there's no point in
BJörn Lindqvist wrote:
But IMHO, your design is broken if you need
to send dozens of arguments to any function or method.
My design allows property values to be specified using
keywords in the constructor. You typically only use
a few of them in any given call, but there are a large
number of
Joe Smith wrote:
AFAICT there would be no way to use raw strings with that method.
...
Additional backslashes are added to raw strings to remove anything that
resembles an escape sequence.
You seem to be very confused about the way strings work. If
you look at the repr() of a string
of that flag.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAIL PROTECTED
Heiko Wundram wrote:
for node in tree:
if not node.haschildren():
continue
do something with node
Er, you do realise that can be written more straightforwardly as
for node in tree:
if node.haschildren():
do something with node
--
Greg
Heiko Wundram wrote:
Yes, of course. Read my replies to Terry J. Reed, to Josiah Carlton, to
Talin,
to see why I chose to compare it to the 'continue' syntax.
I saw them. Your brain must be wired very differently
to mine, because I find loops with a continue in them
harder to follow than
Heiko Wundram wrote:
You can also do the same here (by using normal bracketing):
for expr in (some
non-trivial
stuff) if (one expr and
two expr and
three expr):
So you want to be able to write the if
Heiko Wundram wrote:
Am Montag 22 Mai 2006 01:59 schrieb Josiah Carlson:
Not everyone finds list comprehensions easy to read.
Why has Python added list-comprehensions, then? (or at least, why has Python
added the 'if'-expression to list-comprehensions if they're hard to read?
LCs are
Niko Matsakis [EMAIL PROTECTED] wrote:
For what it's worth, I also favor the continue syntax Heiko compared
his code against. Without it, you have to scroll to the end of the
loop to know whether there is an else clause;
Only if the code doesn't fit on one screen, which it should.
--
Steve Holden wrote:
In actual fact the effbot has lately found itself so permeated with
Windows that it has become constituionally incapable of using a forward
slash. Don't know what's with the square brackets though ...
I was thinking maybe that message had resulted from
a Windows and a
Fredrik Lundh wrote:
roughly speaking, epoll is kqueue for linux.
There are many different select-like things around now
(select, poll, epoll, kqueue -- are there others?) and
random combinations of them seem to be available on any
given platform. This makes writing platform-independent
code
Alex Martelli wrote:
On May 26, 2006, at 6:27 PM, Steve Holden wrote:
Of course that would mean establishing which *was* the best available
which, as we've seen this week, may not be easy.
I believe it's: kqueue on FreeBSD (for recent-enough versions
thereof), otherwise epoll where
Martin v. Löwis wrote:
Just end user experience's two cents here
(btw, this line is correct at English level?)
Wouldn't it be still be conventional to have an article somewhere?
e.g. Just /some/ end user's two cents here
Or Just two cents' worth of end-user experience here,
which is almost
Neal Norwitz wrote:
Should the following values be ints (limited to 2G)?
* line #s and column #s
Anyone with a source file more than 2G lines long
or 2G chars wide deserves whatever they get. :-)
Not-investing-in-a-1.3e10-pixel-wide-screen-any-time-soon-ly,
Greg
Fredrik Lundh wrote:
well, the empty string is a valid substring of all possible strings
(there are no null strings in Python). you get the same behaviour
from slicing, the in operator, replace (this was discussed on the
list last week), count, etc.
Although Tim pointed out that
Tim Peters wrote:
I liked benchmarking on Crays in the good old days. ...
Test times were reproducible to the
nanosecond with no effort. Running on a modern box for a few
microseconds at a time is a way to approximate that, provided you
measure the minimum time with a high-resolution
A.M. Kuchling wrote:
(At work we're trying to move toward this approach for doing realtime
audio: devote one CPU to the audio computation and use other CPUs for
I/O, web servers, and whatnot.)
Speaking of creative uses for multiple CPUs, I was thinking
about dual-core Intel Macs the other
Jim Jewett wrote:
For pkgutil in particular, the change is that instead of writing to
stderr (which can scroll off and get lost), it will write to the
errorlog. In a truly default setup, that still ends up writing to
stderr.
This might be better addressed by providing a centralised
way of
Thomas Heller wrote:
I think that hexlify should be able to use any buffer object that has
a readable memory block, not only those with charbuffers.
The docs say that the binascii methods are used to convert between binary
and various ASCII-encoded binary representations.
So why the heck
Noam Raphael wrote:
This PEP suggests to allow the use of an empty subscript list, for
example ``x[]``, which is currently a syntax error. It is suggested
that in such a case, an empty tuple will be passed as an argument to
the __getitem__ and __setitem__ methods. This is consistent with the
Alex Martelli wrote:
Well, x=23 on one side, and x[]=23 aka x[()]=23 on the other, have
drastically different semantics. Indexing refers to the contents of
the zero-dimensional container, rather than to a name to which the
container happens to be bound (but isn't any more, once one assigns
Tim Hochberg wrote:
In Numpy, a 0-D array [for example, array(5)] is almost, but not quite,
equivalent to scalar [for example, 5]. The difference is that the
former is mutable.
Hmmm, I hadn't considered that. I suppose this is
something that arises from NumPy's view semantics
of indexing
Nick Coghlan wrote:
I think it more comes from the n-dimensional array approach - 'n=0' is
then a natural issue to consider.
But only if it makes sense. I still think there are some
severe conceptual difficulties with 0D arrays. One is
the question of how many items it contains. With 1 or
Ka-Ping Yee wrote:
I think the whole discussion about the concept and meaning of
zero-dimensional arrays is mostly irrelevant to the original
issue. The original issue is a *syntax* question: should
x[()] be written as x[]?
But, at least as presented in the PEP, it's a
syntax that was
Robert Kern wrote:
OTOH, isn't the exact PRNG algorithm considered an implementation detail?
It's questionable whether the PRNG being used *should* be
an implementation detail. To anyone who cares even a little
bit about its quality, knowing the algorithm (or at least
some info about it, such
Tim Peters wrote:
Off the top of my head, then, since the Twister is provably
equidistributed in 623 dimensions to 32-bit accuracy, I expect it
should be able to fairly generate all permutations of a sequence of
= 623 elements (equidistribution in N dimensions implies
equidistribution in all
Terry Jones wrote:
That doc note should surely be removed. Perhaps it's an artifact from some
earlier shuffle algorithm.
The current algorithm (which is simple, well known, and which produces all
permutations with equal probability) only calls the RNG len(x) - 1 times.
It's not a matter of
[EMAIL PROTECTED] wrote:
switch raw_input(enter a, b or c: ):
case 'a':
print 'yay! an a!'
case 'b':
print 'yay! a b!'
case 'c':
print 'yay! a c!'
else:
print 'hey dummy! I said a, b or c!'
Before
Terry Jones wrote:
Suppose you have a RNG with a cycle length of 5. There's nothing to stop an
algorithm from taking multiple already returned values and combining them
in some (deterministic) way to generate 5 outcomes.
No, it's not. As long as the RNG output is the only input to
the
BJörn Lindqvist wrote:
I don't know how difficult it is to get rid of the
implicit return None or even if it is doable, but if it is, it
should, IMHO, be done.
It's been proposed before, and the conclusion was that
it would cause more problems than it would solve.
(Essentially it would
Talin wrote:
Since you don't have the 'fall-through' behavior of C, I would also
assume that you could associate more than one value with a case, i.e.:
case 'a', 'b', 'c':
...
Multiple values could be written
case 'a':
case 'b':
case 'c':
...
without conflicting
[EMAIL PROTECTED] wrote:
I agree, but that of course limits the expressions to constants which can be
evaluated at compile-time as I indicated in my previous mail.
A way out of this would be to define the semantics so that
the expression values are allowed to be cached, and the
order of
Terry Jones wrote:
The code below uses a RNG with period 5, is deterministic, and has one
initial state. It produces 20 different outcomes.
You misunderstand what's meant by outcome in this
context. The outcome of your algorithm is the whole
*sequence* of numbers it produces, not each
[EMAIL PROTECTED] wrote:
Greg Multiple values could be written
Gregcase 'a':
Gregcase 'b':
Gregcase 'c':
Greg ...
That would be an exception to the rule that a line ending in a colon
introduces an indented block.
Yes, but I don't see that as a big
[EMAIL PROTECTED] wrote:
Greg A way out of this would be to define the semantics so that the
Greg expression values are allowed to be cached, and the order of
Greg evaluation and testing is undefined. So the first time through,
Greg the values could all be put in a dict, to be
Dan Christensen wrote:
I think Terry's point is valid. While no one call to
random.shuffle(L) can produce every possible ordering of L (when
len(L) is large), since random.shuffle shuffle's the data in place,
repeated calls to random.shuffle(L) could in principle produce every
possible
Terry Jones wrote:
I was not meaning to say that anyone was wrong, just that I found Greg's
characterization a bit too general, or not as well defined as it might have
been.
I meant it in the context being discussed, which was a
shuffling algorithm being used the way shuffling algorithms
are
M.-A. Lemburg wrote:
My personal favorite is making the compiler
smarter to detect the mentioned if-elif-else scheme
and generate code which uses a lookup table for
implementing fast branching.
But then the values need to be actual compile-time
constants, precluding the use of symbolic
Josiah Carlson wrote:
Offering arbitrary expressions whose
meaning can vary at runtime would kill any potential speedup (the
ultimate purpose for having a switch statement)
I don't agree that speedup is *the* ultimate purpose
of a switch statement. There's also the matter of
providing a
Phillip J. Eby wrote:
Actually, one could consider case expressions to be computed at function
definition time, the way function defaults are. That would solve the
problem of symbolic constants, or indeed any sort of expressions.
That's an excellent idea!
It's just a question of which
Phillip J. Eby wrote:
Sadly, it's not *quite* that simple, due to the fact that co_lnotab must be
increase in line numbers as bytecode offsets increase.
I think it's high time all the cleverness was ripped out
of the lnotab and it just became a plain array of independent
entries.
--
Greg
Raymond Hettinger wrote:
switch x:
case 1: one()
case 2: two()
case 3: three()
default: too_many()
Do we require that x be hashable so that the compiler can use a lookup
table?
That sounds reasonable.
--
Greg
___
Guido van Rossum wrote:
Well, the hypothetical use case is one where we have an arbitrary
object of unknown origin or type, and we want to special-case
treatment for a few known values.
I'd need convincing that this use case is anything more
than hypothetical.
Also, you can always put your
Guido van Rossum wrote:
But it would be easy enough to define a dict-filling function that
updates only new values.
Or evaluate the case expressions in reverse order.
Was it decided yet how to write the cases for a switch that tests for
tuples of values? Requiring parentheses might be
Fredrik Lundh wrote:
Q: If a program calls the 'func' function below as 'func()'
and ONE and TWO are both integer objects, what does 'func'
^^
Nothing at all, because you didn't call it!
--
Greg
Phillip J. Eby wrote:
switch x:
case == 1: foo(x)
Aesthetically, I don't like that.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Phillip J. Eby wrote:
1. case (literal|NAME) is the syntax for equality testing -- you can't
use an arbitrary expression, not even a dotted name.
That's too restrictive. I want to be able to write
things like
class Foods:
Spam = 1
Eggs = 2
Ham = 3
...
switch f:
Guido van Rossum wrote:
I'm currently leaning
towards making static expressions outside a function illegal and limit
switches outside a function to compile-time-constant expressions.
I'm not sure I like the idea of having things that
are illegal outside a function, because it can be a
nuisance
as an
alternative way to mark it as a package?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAIL PROTECTED
. A
case at the module level would just be an instance
of that.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAIL
will be bypassed
by isinstance() (unless Guido decides to change that).
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning person
Phillip J. Eby wrote:
It's not inconsistent - isinstance() checks __class__ in *addition* to
type() in order to allow proxying tricks like lying about your
__class__.
If this is a deliberate feature, it's a bit patchy, because
it means the proxy can't lie about *not* being an instance
of
Martin v. Löwis wrote:
Again, I believe this is all included for ExtensionClasses: it looks
for __class__ on the object if the type check fails, so that an
ExtensionClass could be actually a class derived from the C type.
Now that we have had new-style classes for quite a
while, is there
Guido van Rossum wrote:
Bad idea IMO. The __name__ == __main__ rule is so ingrained, you
don't want to mess with it.
It would only make a difference for main modules inside
packages. Wouldn't that be fairly rare? The vast majority
of existing __name__ == __main__ uses ought to be
unaffected.
Giovanni Bajo wrote:
This is where I wonder why the def __main__() PEP was rejected in the
first place. It would have solved this problem as well.
Could this be reconsidered for Py3k?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Nick Coghlan wrote:
By 'current namespace' I really do mean locals() - the cell objects themselves
would be local variables from the point of view of the currently executing
code.
This is wrong. Cells are *parameters* implicitly passed
in by the calling function. They may temporarily be
Talin wrote:
The case - sub mapping doesn't need to be defined every time - that's
the point, you as the programmer decide when and how to construct the
dictionary,
Then you seem to be proposing a variation on the constant-only
case option, with a more convoluted control flow.
--
Greg
Jim Jewett wrote:
IMHO, I would prefer that it limit disk consumption; a deleted or
overwritten file would not count against the process, but even a
temporary spike would need to be less than the cap.
The problem is that there's no easy way to reliably measure
disk consumption by a particular
Martin v. Löwis wrote:
xturtle
BTW, I'm not sure if 'xturtle' is such a good name.
There's a tradition of X Windows executables having
names starting with 'x', whereas this is presumably
platform-independent.
Maybe 'turtleplus' or something?
--
Greg
Mark Hammond wrote:
that helps mozilla the platform more than it helps firebox the browser
^^^
Firebox - the sandfoxed web browser!
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Brett Cannon wrote:
1) Is removing 'file' from the builtins dict in PyInterpreterState (and
maybe some other things) going to be safe enough to sufficiently hide
'file' confidently (short of someone being stupid in their C extension
module and exposing 'file' directly)?
2) Changing
Ka-Ping Yee wrote:
while offering a way to get proper
lexical scopes for those who want to use them.
I don't disagree with anything you said, but I think it
would be a good idea to avoid using phrases like proper
lexical scopes, which is likely to set people off on
a tangent. The issue isn't
Andrew Koenig wrote:
Incidentally, I think that lexical scoping would also deal with the problem
that people often encounter in which they have to write things like lambda
x=x: where one would think lambda x: would suffice.
This is another red herring. Python's problem here
is not because its
Josiah Carlson wrote:
What I asked before, and what I'd like to ask again, is if there are any
_nontrivial uses_ of lexically nested scopes which are made cumbersome
by our inability to write to parent scopes.
The trouble with taking that position is that the very
cases which would benefit
Giovanni Bajo wrote:
a = []
for i in range(10):
... a.append(lambda: i)
...
print [x() for x in a]
[9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
This subtle semantic of lambda is quite confusing, and still forces people to
use the i=i trick.
This has *nothing* to do with the semantics of
Josiah Carlson wrote:
If the only code that benefits from such changes are very *simple*,
then I think that says something about its necessity.
The point is that they're only very simple if you
can write them using access to an outer scope. Without
that ability, they become less simple, less
Giovanni Bajo wrote:
I believe that names in
lambdas/nested-functions referring to local names in the outer scope should
really be bound at function definition time
No, you don't want that, because it would make functions that
call each other very awkward to arrange.
And it's also handy that
Tim Peters wrote:
Scheme has no loops in Python's sense --
things like do are shorthand for expressing stylized recursion
But it does have foreach and map, which are the
moral equivalent of Python's for-loops and list
comprehensions. The body is a lambda which takes
the loop variable as a
Josiah Carlson wrote:
I had hoped that there would be a response to my second (and I believe
more applicable statement); if the feature is really only useful for
generally trivial cases *without* the feature, then making them even
more trivial, I think, is a bit of over optimization.
I don't
Talin wrote:
To put it another way - I am an advocate of applying Claude Shannon's
theory of information to language design. The highest level of
compression should be used for expressions that occur the most frequently.
I believe the proposal in question would cause no
net worsening in
Marek Baczek Baczyński wrote:
I suggest - as an assignment operator instead of := - it's used in
OCaml and it looks *very* different, yet still makes sense.
But assigning to an outer scope isn't *very* different,
it's only slightly different.
--
And now for something slightly different...
Simon Percivall wrote:
def foo():
def bar():
foo.x = 3
That already had a different meaning - it assigns
to an attribute of the function object created by
executing def foo().
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
[EMAIL PROTECTED] wrote:
By naming the function in which the binding is to occur you avoid problems
of someone coming along and adding or deleting functions between the
assignment (in baz) and the target of the assignment (x in foo) but then
forgetting to increment or decrement the counters
Michael Chermside wrote:
That leaves the other problem: auxiliary means of accessing
objects. There are things like gc.get_objects(). In the special
case of file, which is a type that's also dangerous, there are
tricks like object().__class__.__subclasses__().
My approach to that would be to
Brett Cannon wrote:
Armin in an email said that he thought it was
a losing battle to try to hide 'file' from an interpreter.
And I would change file() so that it didn't open
files. Then it would be harmless for code to have
access to the file class.
--
Greg
Brett Cannon wrote:
On 7/5/06, *Greg Ewing* [EMAIL PROTECTED]
And I would change file() so that it didn't open
files. Then it would be harmless for code to have
access to the file class.
Right, that is essentially what I proposed initially with the whole
crippling idea
Another thing I perhaps should point out is that
I'm proposing the separation of open() and file()
for *all* code, not just restricted code. So it's
not a matter of crippling file() specially for
restricted code.
--
Greg
___
Python-Dev mailing list
Nick Coghlan wrote:
What would the signature of the file constructor be in that case?
If it's possible to call it at all, I think it would
have to take a file descriptor, or whatever the
platform's OS-level representation of an open file
is.
The other possibility is to just raise an exception
Boris Borcic wrote:
I believe that in this case native linguistic intuition made the decision...
The reason has nothing to do with language. Guido didn't
want sum() to become an attractive nuisance by *appearing*
to be an obvious way of joining a list of strings, while
actually being a very
Guido van Rossum wrote:
Then let's allow
nonlocal x = 12
as a shortcut for
nonlocal x
x = 12
I thought you didn't like that, because in
nonlocal x = 12
x = 42
it's not clear whether these are talking about the same
x or not.
--
Greg
Matthew Barnes wrote:
its
meaning in C/C++ (i.e. the symbol is defined outside of the current
scope).
It means more than that -- it means defined outside
the current *file*. That's much too drastic for
what we want.
--
Greg
___
Python-Dev mailing
401 - 500 of 2277 matches
Mail list logo
