Ned Batchelder wrote:
Any of the tweaks people are suggesting could be applied individually
using this technique. We could just as easily choose to make the site
left-justified, and let the full-justification fans use custom
stylesheets to get it.
Is it really necessary for the site to speci
Can we please get rid of the sidebar, or at least provide
a way of turning it off? I don't think it's anywhere
near useful enough to be worth the space it takes up.
You can only use it when you're scrolled to the top of
the page, otherwise it's just a useless empty space.
Also, I often want to pu
Glyph Lefkowitz wrote:
"do I have to resize my browser every time I visit a new site to get a
decent width for reading".
If all sites left the width to the browser, then I would
be able to make my browser window a width that is comfortable
for me with my chosen font size and leave it that way.
PJ Eby wrote:
Weird - I have the exact *opposite* problem, where I have to resize my
window because somebody *didn't* set their text max-width sanely (to a
reasonable value based on ems instead of pixels), and I have nearly 1920
pixels of raw text spanning my screen.
If you don't want 1920-p
Steven D'Aprano wrote:
While I sympathize with the ideal of making the docs readable,
particular for those of us who don't have 20-20 vision, "must be
readable from halfway across the room" is setting the bar too high.
The point is that reducing contrast never makes anything more
readable, an
Cameron Simpson wrote:
People have been saying "hires" throughout the
threads I think, but I for one would be slightly happier with "highres".
hirez?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
Lennart Regebro wrote:
Since the only monotonic clock that can be adjusted by NTP is Linux'
CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
give a clock that isn't adjusted by NTP.
I thought we decided that NTP adjustment isn't an issue, because
it's always gradual.
--
Greg
Cameron Simpson wrote:
A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent
polls of the clock. On its own it says nothing about steadiness or
correlation with real world time.
No, no, no.
This is the strict mathematical meaning of the word "monotonic",
but the way it's used
Cameron Simpson wrote:
I maintain that
"monotonic" still means what I said, and that it is the combination of
the word with "clock" that brings in your other criteria.
I'm not trying to redefine the word "monotonic" in general.
All I'm saying is that *if* the PEP is going to talk about
a "mono
Steven D'Aprano wrote:
Greg Ewing wrote:
the important thing about a clock that it *keeps going forward*
That would be a *strictly* monotonic clock, as opposed to merely monotonic.
Well, yes, but even that's not enough -- it needs to go forward
at a reasonably constant rate, othe
Mark Shannon wrote:
We have recently removed the f_yieldfrom field from the frame object.
(http://bugs.python.org/issue14230)
Hey, wait a minute. Did anyone consider the performance effect
of that change on deeply nested yield-froms?
The way it was, a yield-from chain was traversed by a very
Antoine Pitrou wrote:
(and here we see why reference-stealing APIs are a nuisance: because
you never know in advance whether a function will steal a reference or
not, and you have to read the docs for each and every C API call you
make)
Fortunately, they're very rare, so you don't encounter
th
On 19/04/12 11:22, Tres Seaver wrote:
Maybe we should mandate that their names end with '_rtfm'.
+1
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mai
Alexandre Vassalotti wrote:
We have custom stack and
dictionary implementations just for the sake of speed. We also have fast
paths for I/O operations and function calls.
All of that could very likely be carried over almost
unchanged into a Cython version. I don't see why it
should take mult
Larry Hastings wrote:
On 05/03/2012 10:07 PM, Benjamin Peterson wrote:
+if (times && ns) {
+PyErr_Format(PyExc_RuntimeError,
Why not a ValueError or TypeError?
Well it's certainly not a TypeError.
TypeError is not just for values of the wrong type,
it's also used for passing
Nick Coghlan wrote:
Instead, I'm now thinking we should add a _types C extension module
and expose the new function as types.build_class(). I don't want to
add an entire new module just for this feature, and the types module
seems like an appropriate home for it.
Dunno. Currently the only thin
Mark Dickinson wrote:
Is the gain from this kind of micro-optimization really worth the cost
of replacing obviously correct code with code whose correctness needs
several minutes of thought?
The original code isn't all that obviously correct to me either.
I would need convincing that the arith
Nick Coghlan wrote:
In that case, consider me convinced: static method it
is.
-0.93. Static methods are generally unpythonic, IMO.
Python is not Java -- we have modules. Something should
only go in a class namespace if it somehow relates to
that particular class, and other classes could might
Nick Coghlan wrote:
On Thu, May 10, 2012 at 10:03 AM, Greg Ewing
wrote:
Something should
only go in a class namespace if it somehow relates to
that particular class, and other classes could might
implement it differently. That's not the case with
build_class().
Not true - you *will*
Dag wrote:
I'm not asking you to consider the details of all that.
Just to allow some kind of high-performance extensibility of
PyTypeObject, so that we can *stop* bothering python-dev with
specific requirements from our parallel universe of
nearly-all-Cython-and-Fortran-and-C++ codebases :-)
On 17/05/12 12:17, Robert Bradshaw wrote:
This is exactly what was proposed to start this thread (with minimal
collusion to avoid conflicts, specifically partitioning up a global ID
space).
Yes, but I think this part of the mechanism needs to be spelled out in
more detail, perhaps in the form
PJ Eby wrote:
At the least, if they're
not going to be in decorator order, the member shouldn't be called
"__decorators__". ;-)
Obviously it should be called __srotaroced__.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
Alexander Belopolsky wrote:
The problem is again the DST ambiguity. One day a year, datetime(y,
m, d, 1, 30, tzinfo=Local) represents two different times and another
day it represents no valid time.
The documentation example (fixed in issue 9063) addresses the
ambiguity by defaulting to standar
Terry Reedy wrote:
"A rich comparison method may return the singleton NotImplemented if it
does not implement the operation for a given pair of arguments. By
convention, False and True are returned for a successful comparison.
However, these methods can return any value,"
That's to give the
Is there any provision for keeping the compiled
C code and distributing it along with an application?
Requiring a C compiler to be present at all times
could be a difficulty for Windows.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://m
Nick Coghlan wrote:
I'm fine with exposing a memoryview.buffer_address attribute in 3.4.
What about objects whose buffer address can change
when the buffer isn't locked?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
Antonio Cuni wrote:
Traceback (most recent call last):
File "", line 1, in
TypeError: __complex__ should return a complex object
i.e., the complex constructor does not check that __complex__ returns an
actual complex, while the cmath functions do.
Looks to me like cmath is being excessively
Stephen J. Turnbull wrote:
It's a design bug, yes. The question is, does it conform to
documented behavior?
The 2.7 docs say this about __complex__:
Called to implement the built-in function complex() ...
Should return a value of the appropriate type.
So the question is whether float i
I think I've changed my mind on this, since it was pointed
out that if you're going to return a float instead of a
complex, you should really be implementing __float__, not
__complex__.
So I think it's fine to require __complex__ to return a
complex, and the docs should perhaps be clarified on th
Chris Angelico wrote:
Python 2 (future directives aside) also required you to explicitly ask
for floating point. That was also changed in Python 3.
The solution adopted was different, though: use different
operators for int and float division. This means you can't
accidentally end up with a flo
Devin Jeanpierre wrote:
(Complex
numbers get a free pass because "complex numbers with rational real
and imaginary parts" is not a memorable name for a type.)
Complexional?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
Steven D'Aprano wrote:
When you're dealing with numbers that represent real quantities, getting
a complex result is nearly always an error condition. Better to get an
exception at the point that occurs, than somewhere distant when the number
gets fed to %f formatting, or worse, no error at all,
Stephen J. Turnbull wrote:
Evidently somebody
thought "float" was appropriate, or they would have just written
"Returns a complex value."
It's not quite as simple as that, because that paragraph in the
docs is actually shared between the descriptions of __int__,
__float__ and __complex__. So it
Stephen J. Turnbull wrote:
For most
users, it doesn't matter whether an environment variable is set
incorrectly without their knowledge, or if the kernel is buggy, or if
the disk is corrupt. And from Python's point of view, the world as a
whole no longer makes.
So it shuts down abnormally. Tha
Nick Coghlan wrote:
On Mon, Nov 5, 2012 at 10:08 PM, Mark Dickinson wrote:
In Python 2, the 'exec' statement supports 'exec'-ing a (statement,
globals, locals) tuple:
If this is a deliberate feature, I'd guess it's because exec
is a statement rather than a function in Python 2, so you
can't
MRAB wrote:
That would make augmented assignment more difficult. For example, how
would you write the equivalent of "x -= y"?
SUBTRACT x FROM y.
CLOSE POST WITH SMILEY.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
Chris Angelico wrote:
Perhaps an alternative question: What can be done to make the latter
less unpalatable?
* We could introduce a new syntax such as {a = 1, b = 2}.
* If the compiler were allowed to recognise builtins, it could
turn dict(a = 1, b = 2) into {'a':1, 'b':2} automatically.
--
G
mar...@v.loewis.de wrote:
It's faster than calling dict() because the dict code will
create a second dictionary, and discard the keywords dictionary.
Perhaps in the case where dict() is called with keyword
args only, it could just return the passed-in keyword
dictionary instead of creating anot
Stefan Behnel wrote:
This should work as long as this still creates a copy of d at some point:
d = {...}
dict(**d)
It will -- the implementation of the function call opcode always
creates a new keyword dict for passing to the called function.
--
Greg
__
On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou wrote:
Do we have statistics showing that Python
gets more use in summer?
Well, pythons are cold-blooded, so they're probably more
active during the warmer seasons...
--
Greg
___
Python-Dev mailing li
Richard Oudkerk wrote:
Personally I would like to get rid of the "purge globals" behaviour for
modules deleted before shutdown has started: if someone manipulates
sys.modules then they can just call gc.collect() if they want to
promptly get rid of orphaned reference cycles.
Now that we have c
Nick Coghlan wrote:
Agreed, but it's the security implications that let us even
contemplate the backwards compatibility break.
I don't think that's a sufficient criterion for choosing a
name. The backwards compatibility issue is a transitional
thing, but we'll be stuck with the name forever.
I
Nick Coghlan wrote:
The problem is the mechanism is *not the same* on Windows and POSIX -
the Windows mechanism (noinherit) means the file won't be accessible
in child processes, the POSIX mechanism (cloexec) means it won't
survive exec().
But since there is no such thing as a fork without exe
Charles-François Natali wrote:
Anyway, only dup2() should probably release the GIL.
Depending on how your kernel is implemented, both pipe()
and socketpair() could create file system entries, and
therefore could block, although probably only for a
very short time.
--
Greg
_
Amaury Forgeot d'Arc wrote:
One reasonable heuristic is to check the man page: if the syscall can
return EINTR, then the GIL should be released.
Hmmm, curious. According to the MacOSX man pages, both
dup() and dup2() can return EINTR, but pipe() and
socketpair() can't.
I'm particularly
Terry Reedy wrote:
I agree. Since the exception type is not documented and since no one
should intentionally pass anything but strings, and therefore should not
be writing
try:
os.path.join(a,b)
except AttributeError:
barf()
I think it would be acceptable to make a change in 3.4.
Why sh
Steven D'Aprano wrote:
The documentation for strings is also clear that you should not rely on
this
optimization:
> ...
>
It
can, and does, fail on CPython as well, as it is sensitive to memory
allocation details.
If it's that unreliable, why was it ever implemented
in the first place?
--
Guido van Rossum wrote:
Here's a patch that gets rid of unbound methods, as
discussed here before. A function's __get__ method
now returns the function unchanged when called without
an instance, instead of returning an unbound method object.
I thought the main reason for existence of unbound
method
Josiah Carlson wrote:
While it seems that super() is the 'modern paradigm' for this,
I have been using base.method(self, ...) for years now, and have been
quite happy with it.
I too would be very disappointed if base.method(self, ...)
became somehow deprecated. Cooperative super calls are a
differe
Tim Peters wrote:
I expect that's because he stopped working on Zope code, so actually
thinks it's odd again to see a gazillion methods like:
class Registerer(my_base):
def register(*args, **kws):
my_base.register(*args, **kws)
I second that! My PyGUI code is *full* of __init__
methods
r unsigned otherwise. In Python the
value itself knows whether it's signed or not.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsid
more time machine activity to me. Any minute
now you'll find there's suddenly a positive_id() builtin
that's been there ever since 1.3 or so. And the 'P' format,
then always never having just become useful, will have
unappeared...
--
Greg Ewing, Computer Science Dept,
uter
block.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
[EMAIL
rosses block
boundaries. It's not clear how big a win that is, due to the added
opcodes even on non-error paths.
Only exceptions and break statements would require stack
pointer adjustment, and they're relatively rare. I don't
think an extra opcode in those cases would mak
hods, without
getting tripped up by strings.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidi
Josiah Carlson wrote:
if we could change import in such a
way that made standard library imports different from standard library
imports, we could
...go on to prove that black is white and get
ourselves killed by a python on the next
zebra crossing.
--
Greg Ewing, Computer Science Dept
Nick Coghlan wrote:
A suggestion was made on c.l.p a while back to have a specific module
dedicated to reductive operations. That is, just as itertools is
oriented towards manipulating iterables and creating iterators, this
module would be oriented towards consuming iterators in a reductive fash
Brian Sabbey wrote:
I prefer re-using the 'for' loop for this purpose because it allows the
problem to be solved in a general way by re-using a structure with which
most users are already familiar, and uses generators, which are easier
to use in this case than defining a class with __exit__, __e
Nick Coghlan wrote:
That 'x in seq' bit still shouts "containment" to me rather than
iteration, though.
Perhaps repurposing 'from':
(x from seq if f(x))
That rather breaks TOOWTDI though (since it is essentially new syntax
for a for loop). And I have other hopes for the meaning of (x from ()).
there is a mechanism for passing a code block as
a thunk to an arbitrary function, the function is
free to loop or not as it sees fit. I'd just prefer
the spelling of it didn't force you to make it
look like it's looping when it's not.
--
Greg Ewing, C
think that if an
identity is specified, it should be used even
if the sequence is non-empty. The reason being
that the user might be relying on that to get
the semantics he wants.
Think of the second argument as "accumulator
object" rather than "identity".
--
Greg Ewing, C
ke that would be better, yes. Maybe even just
dt = stopwatch():
a()
b()
Whatever keyword is used is bound to not sound right
for some usages, so it would be best if no keyword
were needed at all.
--
Greg Ewing, Computer Science Dept, +--+
Universit
were implemented by
passing a thunk to a function that calls it repeatedly.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc.
ction to find out how
many parameters it has been passed, and most C implementations
don't provide any way at all. That's why the calling interface
to varargs functions invariably includes some way for the caller
to indicate the number of arguments, such as a format string or
a terminating NULL.
specified explicitly.
In that case I would argue in favour of keeping it the
way it is, since...
currently sum([1,1], 40) equals 42.
...seems quite reasonable to me. Or at least as reasonable
as anything else.
--
Greg Ewing, Computer Science Dept, +--+
University of
ntity(y)
Not that it's false, it just seems like a completely
unnecessary layer of mental gymnastics...
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand
Eric Nieuwland wrote:
Perhaps the second argument should not be optional to emphasise this.
After all, there's much more to sum() than numbers.
I think practicality beats purity here. Using it on
numbers is surely an extremely common case.
--
Greg Ewing, Computer Science
def g(...):
...
Of course if the functions then are
allowed to change the surrounding bindings this could be used for
resource release issues etc.
Yes, rebinding in the surrounding scope is the one thing
that style wouldn't give you
--
Greg Ewing, Comput
nt to "".join(x). Although it might be
better to call it str.concat() instead of str.sum().
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-o
ted until the function is called.
Not to mention that if the seq is empty, there's no
way of knowing what T to instantiate...
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christc
scoped.
(7) A __leave__ or __exit__ special method really turns into another
name for __del__.
Not really. A PEP-310-style __exit__ method is explicitly
invoked at well-defined times, not left until the object
is reclaimed. It doesn't suffer from any of the problems
of __del__.
--
Greg Ewing, C
read,
and EOF. This means recording that IOError(EAGAIN) is raised for an empty
non-blocking read.
Isn't that unix-specific? The file object is supposed to
provide a more or less platform-independent interface, I
thought.
--
Greg Ewing, Computer Science Dept, +
lines significant.
Currently I can leave some space before/after a
docstring without breaking anything. This can
help readability, especially for class docstrings.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCo
methods which behave more like os.read/os.write, maybe called
something like readsome() and writesome(). That would eliminate
the need to extract and manipulate the fds, and might make it
possible to do some of this stuff in a more platform-independent
way.
--
Greg Ewing, Computer
Donovan Baarda wrote:
On Mon, 2005-03-21 at 17:32 +1200, Greg Ewing wrote:
I don't agree with that. There's no need to use non-blocking
I/O when using select(), and in fact things are less confusing
if you don't.
Because staller.py outputs and flushes a fragment of data smaller t
t;OldStyleSpam.__radd__", self, other
return 42
y1 = OldStyleSpam()
y2 = OldStyleSpam()
print y1 + y2
produces:
OldStyleSpam.__add__ <__main__.OldStyleSpam instance at 0x4019054c>
<__main__.OldStyleSpam instance at 0x401901ec>
OldStyleSpam.__radd__ <
Travis Oliphant wrote:
I'm proposing to pickle the buffer object so that it unpickles as a
string.
Wouldn't this mean you're only solving half the problem?
Unpickling a Numeric array this way would still use an
intermediate string.
--
Greg Ewing, Comput
s that from
the point of view of the user of withfile, the name 'thefile'
magically appears in the namespace without it being obvious
where it comes from.
(but
assignments within the block should still affect its _surrounding_
namespace, it seems to me...).
I agree with that much.
--
Gre
There isn't all that
much left that people want to do on a regular basis.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned su
You can't rely on a function's signature alone to tell
you much in any case. A distressingly large number of
functions found in third-party extension modules have
a help() string that just says something like
fooble(arg,...)
There's really no substitute for a good docstring!
--
Gre
ffect, not to compute a value for consumption
by the block function. I don't see a great need for blocks
to be able to return values.
How do blocks work with control flow statements like
"break", "continue", "yield", and "return"? Perhaps
"break&qu
se()
return func
Usage example:
with_file("foo.txt", "w") as f:
f.write("My hovercraft is full of parrots.")
Does that help?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZea
sion of the regular assignment statement.
Syntactically, yes, but semantically it's more
complicated than just a "simple extension", to
my mind.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZea
t;readme.txt")
def _(fileobj):
...
(Disclaimer: This post should not be taken as
an endorsement of this abuse! I'd still much
rather have a proper language feature for it.)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
to understand what it was doing. We already
have "return" and "yield"; this would be a third similar-yet-
different thing.
If it were considered important enough, it could easily be added
later, without disturbing anything. But I think it's best left
out of an initial specifi
x27;m +1 on moving towards __next__, BTW. IMO, that's the
WISHBDITFP. :-)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-own
tercepting break
and continue isn't so bad, since they're already associated
with the loop they're in, but return has always been an
unconditional get-me-out-of-this-function. I'd feel uncomfortable
if this were no longer true.
--
Greg Ewing, Computer Science Dept, +-
and iterators (even though they are)
doesn't seem right, because they're being used for a purpose
very different from generating and iterating.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealand
;help", "copyright", "credits" or "license" for more information.
>>> "foo" is "foo"
True
>>> "foo" is "f" + "oo"
False
>>> "foo" is intern("f" + "oo")
True
you're defining it by means of a generator, you don't
need a class at all -- just make the whole thing a generator
function.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
being switched on all the time,
and the operator being used for comparison.
2) The first case is syntactically different from subsequent ones,
even though semantically all the cases are equivalent.
--
Greg Ewing, Computer Science Dept, +--+
University of Cante
ning the main
.py file for .pth files? This would make it easier to
have collections of Python programs sharing a common
set of modules, without having to either install them
system-wide or write hairy sys.path-manipulating code
or use platform-dependent symlink or PATH hacks.
--
Greg Ewing, Comp
Jim Jewett wrote:
defmacro myresource(filename):
with myresource("thefile"):
def reader():
...
def writer():
...
def fn():
-1. This is ugly.
--
Greg Ewing, Computer Science Dept, +--+
University of
readable. Or prohibit
anything that would permit creating a new dialect. Or something.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidi
sing syntax is
fairly unobtrusive.
So in summary, I don't think you necessarily *need*
macros to get nice-looking user-defined control structures.
It depends on other features of the language.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbu
Brett C. wrote:
It executes the body, calling next() on the argument
> name on each time through until the iteration stops.
But that's no good, because (1) it mentions next(),
which should be an implementation detail, and (2)
it talks about iteration, when most of the time
the high-level intent has
Guido van Rossum wrote:
[Greg Ewing]
* It seems to me that this same exception-handling mechanism
would be just as useful in a regular for-loop, and that, once
it becomes possible to put 'yield' in a try-statement, people
are going to *expect* it to work in for-loops as well.
(You can a
nt, and register a
single atexit() hander to invoke it. I don't think
there's any need to mess with the way atexit()
currently works.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp,
only that, in those cases where they
*do* feel so compelled, they might not if lambda weren't
such a long word.
I was just trying to understand why Smalltalkers seem to
get on fine without macros, whereas Lispers feel they are
needed. I think Smalltalk's lightweight block-passing
syntax ha
could
use the normal exec statement to invoke the block whenever needed.
There's no need for all that. They're just callable objects.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZeal
1801 - 1900 of 2443 matches
Mail list logo
