On 2/22/2011 6:32 PM, Senthil Kumaran wrote:
On Tue, Feb 22, 2011 at 6:01 PM, Steve Holdenst...@holdenweb.com wrote:
... It would appear from tests
that {0[X]}.format(...) first tries to convert the string X to in
integer. If it succeeds then __getitem__() is called with the integer as an
As pointed out by Ramiro Morales on the Python-Argentina list
(quoting Guido's blog post
http://python-history.blogspot.com/2009/01/brief-timeline-of-python.html
)
Python 0.9.0 was released on 20 Feb 1991
Python 3.2.0 was released on 20 Feb 2011
Python's come a long way.
I look forward to the
On 2/26/2011 4:09 AM, Hagen Fürstenau wrote:
Hi,
I just hunted down a change in behaviour between Python 3.1 and 3.2 to
possibly changed iteration order of sets due to the optimization in
issue #8685. Of course, this order shouldn't be relied on in the first
place, but the side effect of the
On 3/4/2011 7:40 PM, Guido van Rossum wrote:
On Fri, Mar 4, 2011 at 4:10 PM, Westley Martínezaniko...@gmail.com
All right I have to reply to all these singular they remarks. Just
because the singular they has been used for a long time doesn't make it
right. It sounds unnatural, at least to me,
On 3/5/2011 12:44 PM, Paul Moore wrote:
On 5 March 2011 15:09, Michael Foordfuzzy...@voidspace.org.uk wrote:
On 04/03/2011 21:35, Martin v. Löwis wrote:
It would also be good if the PEP took a position on providing
pythonXY.exe binaries on Windows (with the related question of
whether it's
On 3/6/2011 12:44 PM, Antoine Pitrou wrote:
Le dimanche 06 mars 2011 à 11:34 -0600, s...@pobox.com a écrit :
At this point you can push to the public repo from your 3.2 clone, or
repeat the above push merge to your default clone (with the
default branch checked out) and push from there.
I
On 3/6/2011 11:07 AM, Georg Brandl wrote:
On 06.03.2011 16:44, s...@pobox.com wrote:
Georg Yesterday's repository was still the test repository, now it's
Georg the real one. You'll need to clone again.
Thanks.
I have a question about updates from cloned clones. Suppose I clone
On 3/6/2011 11:43 AM, Antoine Pitrou wrote:
compute the base rev. Most reviewable patches should apply cleanly
against the latest revision on default,
That was sensible when we ported patches back, but if they should be
ported forward (3.1 = 3.2 = default), do we not want the patch to
apply
On 3/6/2011 8:18 PM, Mark Hammond wrote:
To be clear, I was suggesting that using .bat files in system32 is a
close analogy to the *nix situation - I didn't mean to advocate for it
to actually happen :) Further, I see the creation of a python3.exe in
the Python install directory as quite
On 3/6/2011 6:09 PM, Barry Scott wrote:
I see that PyCObject_AsVoidPtr has been removed from python 3.2.
The 3.2 docs do not seem to explain this has happened and what
to replace it with.
I searched the 3.2 docs and failed to find PyCObject_AsVoidPtr.
I looked at the whats new page and the API
On 3/7/2011 9:47 AM, Antoine Pitrou wrote:
On Mon, 7 Mar 2011 19:14:55 +1000
Nick Coghlanncogh...@gmail.com wrote:
On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
j...@arbash-meinel.com wrote:
Especially since, AIUI, deprecations are suppressed by default now.
True, but developers are
On 3/7/2011 5:54 AM, Victor Stinner wrote:
I don’t really understand this message (especially “cached into the
object”) :) Maybe in the Misc/NEWS entry you could also add a line to
explain to users the reason/goal/benefit of this change?
If you call str.encode() twice: the first call stores
On 3/7/2011 2:16 AM, Georg Brandl wrote:
On 07.03.2011 00:16, Terry Reedy wrote:
But would it work
??
to just pull once into default from the central
repository (slow) and then pull from there (fast) into maintenance
clones? I expect to nearly always be only working on issues that affect
On 3/7/2011 9:31 PM, Reliable Domains wrote:
The launcher need not be called python.exe, and maybe it would be
better called #@launcher.exe (or similar, depending on its exact
function details).
I do not know that the '#@' part is about, but pygo would be short and
expressive.
--
Terry Jan
On 3/9/2011 1:27 AM, Mark Hammond wrote:
your position but my personal opinion is that simple support for #! is
more desirable.
I agree. One weird line in a file is enough!
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
On 3/9/2011 4:14 PM, Antoine Pitrou wrote:
On Wed, 9 Mar 2011 19:42:36 +0100
Perhaps the part of the what's new document which deals with porting
issues and compatibility breakage would need more highlighting?
That could go at the tops.
Deletions in 3.3
...
Planned deletions in future
On 3/9/2011 9:50 AM, Tim Lesher wrote:
We used to do biweekly-ish Python-Dev summaries for this reason.
They were, is a sense, too detailed, complete, and voluminous.
In whatever format, terser announcement of just things others really
need to know - like decisions that affect them, would
On 3/12/2011 9:41 AM, Ross Lagerwall wrote:
Hi,
I have been offered commit rights for Python after making a few patches
on subprocess and the os module.
Antoine suggested that I should introduce myself on the python-dev list
so here we go:
I am a student from South Africa and decided to do
On 3/12/2011 8:59 AM, Nick Coghlan wrote:
On Sat, Mar 12, 2011 at 8:33 AM, Laura Creightonl...@openend.se wrote:
For those of you not at the Language Summit at PyCON the day before yesterday,
there was talk of identifying non-portable behaviour, such as relying on
CPython's reference counting
On 3/12/2011 3:04 PM, Thomas Wouters wrote:
It should be fixed, yes, but breaking existing code is going to piss off
a lot of people (like me) who already have enough worries when upgrading
Python. It is apparent that there *is* code out there that relies on
this behaviour, we shouldn't break
On 3/12/2011 8:33 AM, Laura Creighton wrote:
The thread with the whole gory details begins here:
http://codespeak.net/pipermail/pypy-dev/2011q1/006958.html
The second, multiplication issue does appears to be the same issue.
Augmenting my previous test:
class C(object):
def
On 3/12/2011 3:44 PM, Guido van Rossum wrote:
I was just reminded that in Python 3, list.sort() and sorted() no
longer support the cmp (comparator) function argument. The reason is
that the key function argument is always better. But now I have a
nagging doubt about this:
I recently advised a
On 3/12/2011 5:09 PM, Reid Kleckner wrote:
On Sat, Mar 12, 2011 at 4:58 PM, Nick Coghlanncogh...@gmail.com wrote:
On Sat, Mar 12, 2011 at 4:50 PM, Reid Klecknerreid.kleck...@gmail.com wrote:
They should be able to use a slotted cmp_to_key style class:
On 3/12/2011 8:28 PM, Steven D'Aprano wrote:
Fredrik Johansson wrote:
Consider sorting a list of pairs representing fractions. This can be
done easily in Python 2.x with the comparison function lambda
(p,q),(r,s): cmp(p*s, q*r). In Python 2.6, this is about 40 times
faster than using
On 3/12/2011 8:23 PM, Neil Schemenauer wrote:
Greg Ewinggreg.ew...@canterbury.ac.nz wrote:
So am I. It seems to result from the hisorical mess
of distinguishing between numeric and sequence operations
at the C level but not the Python level. I think CPython
should be moving in the direction of
On 3/12/2011 8:47 PM, Glenn Linderman wrote:
On 3/12/2011 2:09 PM, Terry Reedy wrote:
I believe that if the integer field were padded with leading blanks as
needed so that all are the same length, then no key would be needed.
Did you mean that if the integer field were converted to string
On 3/12/2011 10:52 PM, Glenn Linderman wrote:
On 3/12/2011 7:21 PM, Terry Reedy wrote:
The safest such character is \0,\
Works fine in Python.
unless you are coding in C,
Then \01 is next best.
I wouldn't have called you on this, except that it really is important
not to give people
On 3/13/2011 2:05 PM, Daniel Stutzbach wrote:
On Sat, Mar 12, 2011 at 3:44 PM, Guido van Rossum gu...@python.org
mailto:gu...@python.org wrote:
I recently advised a Googler who was sorting a large dataset and
running out of memory. My analysis of the situation was that he was
On 3/14/2011 9:23 PM, Eric Smith wrote:
On 3/14/2011 8:44 PM, James Mills wrote:
On Tue, Mar 15, 2011 at 9:48 AM, R. David
Murrayrdmur...@bitdance.com wrote:
But directly calling a __xxx__ method in Python is a very
unusual thing to do. It would be extremely odd to have that
be the expected
On 3/15/2011 11:17 AM, Nick Coghlan wrote:
On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 15/03/2011 07:59, Nick Coghlan wrote:
While I actually think the current API design is a decent compromise,
another option to consider would be to move the underscore
On 3/15/2011 11:57 AM, Brian Curtin wrote:
On Tue, Mar 15, 2011 at 11:28, Nick Coghlan ncogh...@gmail.com
mailto:ncogh...@gmail.com wrote:
On Tue, Mar 15, 2011 at 10:52 AM, Brian Curtin
brian.cur...@gmail.com mailto:brian.cur...@gmail.com wrote:
Agreed. I'll rename them to be more
On 3/15/2011 1:00 PM, Antoine Pitrou wrote:
On Tue, 15 Mar 2011 04:19:24 +0100
ezio.melottipython-check...@python.org wrote:
Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c
Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c
libffi is a third-party library and you should probably not
On 3/16/2011 12:10 PM, Brian Curtin wrote:
Hi all,
As I'm sure you're all aware, the PyCon sprints are going on right now
and will run for two more days. As a result, you may have noticed an
Yes. Emphasizing improved test coverage was a great idea. It is
relatively easy and definitely
On 3/17/2011 11:04 AM, Guido van Rossum wrote:
I've thought some more about deprecations and subsequent deletions in
Python 3 (but not read the whole thread -- sorry, I've gotten sick
right after coming home from PyCon).
I think that as long as a significant number of people are still using
On 3/17/2011 1:45 PM, Benjamin Peterson wrote:
2011/3/16 Thomas Hellerthel...@ctypes.org:
I would like my committer rights to be retracted.
I have been contributing to Python here and there for 10 years now,
and it was a pleasant experience.
Unfortunately, since about a year I have lots more
On 3/18/2011 10:48 AM, Senthil Kumaran wrote:
Doug Hellmann wrote:
On Mar 18, 2011, at 9:59 AM, Jesse Noller wrote:
Terry Reedy wrote:
there are several open issues. There is certainly a opening for a new person
with C experience.
about on the PSF blog. Having another ctypes expert
On 3/18/2011 10:17 AM, Doug Hellmann wrote:
Is there a job description for a ctypes maintainer?
I would say a knowledge of C and C implementations, a tolerance of OS
idiosyncrasies, and an interest bridging C to Python and in particular
the way ctpes does it. (I intentionally omitted
On 3/20/2011 3:22 AM, Glenn Linderman wrote:
On 3/19/2011 7:38 PM, Mark Hammond wrote:
[snip]
As both a writer and reader, I would like to just add, for instance,
#! python3
(or 3.3 or whatever) and have the launcher do the 'right thing'.
It seems to me that that really should be enough info
On 3/20/2011 10:51 AM, Antoine Pitrou wrote:
On Sun, 20 Mar 2011 14:39:20 +0100
Stefan Behnelstefan...@behnel.de wrote:
If anyone knows about a good benchmark for a currently pure Python standard
library module, preferably a smaller, self-contained one that's somewhat
computationally
What you felt like doing after doing the rest;-?
I believe your question and its answers have helped me understand hg
better for when I dive in. Thanks.
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
On 3/20/2011 6:35 PM, Westley Martínez wrote:
On Sun, 2011-03-20 at 05:36 -0400, Terry Reedy wrote:
As both a writer and reader, I would like to just add, for instance,
#! python3
(or 3.3 or whatever) and have the launcher do the 'right thing'.
It seems to me that that really should
On 3/26/2011 2:17 PM, Georg Brandl wrote:
Refactor doesn't sound like it belongs in the 3.1 branch...
-for i in range(len(pattern)):
-c = pattern[i]
+for i, c in enumerate(pattern):
I would call thin 'Replace obsolete idiom in' rather than 'Refactor'.
So are you
On 3/27/2011 2:13 PM, Eugene Toder wrote:
I'm not disputing that, and I understand that my current choice of mail
reader limits me. I was just asking if it would be possible (read: fairly
easy) to only generate utf-8 when it was necessary.
Isn't utf-8 itself same as ascii where no non-ascii
On 3/28/2011 6:13 AM, Paul Moore wrote:
This philosophy is essentially what the mq extension to Mercurial
tries to capture. In mq, you maintain a series of patches on top of
your repository, amending, refining and rebasing them as you wish
until they are ready to commit, at which time you take
On 3/29/2011 12:35 PM, Vinay Sajip wrote:
I'm planning a change to logging.basicConfig to add an optional handlers
keyword argument which defaults to None.
If specified, this should be an iterable of already created handlers, which will
be added to the root logger (if it doesn't already have
On 3/29/2011 4:02 PM, Matthew Woodcraft wrote:
Terry Reedytjre...@udel.edu wrote:
# Experiment with 2.7 shows that cmp wins. Though too late to change, I
consider this the worst choice of three. I think an exception should be
raised. Failing that, I think key should win on the basis that if
On 3/29/2011 2:23 PM, Michael Foord wrote:
Not sure how real the security risk is here:
http://blog.omega-prime.co.uk/?p=107
Basically he is saying that if you store a list of blacklisted files
with names encoded in big-5 (or some other non-utf8 compatible encoding)
if those names are passed
On 3/30/2011 2:57 AM, Gregory P. Smith wrote:
http://blog.omega-prime.co.uk/?p=107
I posted link to this as comment, with my summary of thread.
I don't see your comment on the blog post. So either the author is
moderating comments and hasn't seen yours yet (likely)
My comment and
The tracker was recently changed so that when I click on a link to a
tracker page, the page is properly displayed, but then a fraction of a
second it blinks and redisplays with the edit form hidden. This is so
obnoxious to me that I no longer want to visit the tracker. Then I have
to find and
On 3/30/2011 7:32 PM, Antoine Pitrou wrote:
There's a lot of noise but that noise is useful. I find the
natural language summary to be much too terse and doesn't make it easy
to visualize said information as opposed to the form fields.
Yes, there is a good reason why database records are
On 3/30/2011 6:39 PM, Toshio Kuratomi wrote:
Really, surrogates are a red herring to this whole issue. The issue is that
the original code was trying to compare two different transformations of
byte sequences and expecting them to be equal. Let's say that you have the
following byte value::
On 3/31/2011 12:31 AM, Mark Hammond wrote:
Hi,
There are a couple of changes I'd like to make and would like some
guidance on policy:
http://bugs.python.org/issue6498 is a documentation bug which exists in
Python 2.6 and later. The patch in that bug touches the docs and a
comment in one source
On 3/31/2011 9:59 AM, Antoine Pitrou wrote:
Le jeudi 31 mars 2011 à 23:48 +1000, Nick Coghlan a écrit :
On Thu, Mar 31, 2011 at 10:16 PM, Antoine Pitrousolip...@pitrou.net wrote:
It would be nice if someone with UI design experience was interested in
maintaining/improving the tracker.
The
On 3/31/2011 7:27 PM, Raymond Hettinger wrote:
On Mar 31, 2011, at 9:52 AM, Terry Reedy wrote:
I would like to try putting the comment box after the last (most
recent) comment, as that is the message one most ofter responds to.
Having to now scroll up and down between comment box and last
On 3/31/2011 7:15 PM, Raymond Hettinger wrote:
The Hg source viewer needs to be tweaked to improve its usability.
What we've got now is a step backwards from the previous svn viewer.
Looking at http://hg.python.org/cpython/file/default/Lib/linecache.py
for example,
there are two issues. 1) the
On 3/31/2011 8:26 PM, Antoine Pitrou wrote:
On Thu, 31 Mar 2011 12:52:23 -0400
Terry Reedytjre...@udel.edu wrote:
Here is my proposal for a redesign based on an analysis of my usage ;-).
I have a 1600x1050 (or thereabouts), 20 (measured) diagonal, 17 across
screen.
The left column has a 7/8
On 4/1/2011 9:45 AM, Michael Foord wrote:
See thread starting at
http://mail.python.org/pipermail/python-dev/2010-August/103263.html
As far as I can tell there was no clear decision there either. :-)
I read it as deciding no doc fixes.
(Other than no *need* to bother, which doesn't answer
On 4/1/2011 6:44 AM, Georg Brandl wrote:
Am 01.04.2011 06:02, schrieb Terry Reedy:
would switch. Just forgot here. Multiply everything by 2.4 for cm.
Or by 2.54, if you're using SI cm :)
Then its a good thing I did the conversions with a dual scale ruler ;-).
So the number were accurate.
I
On 4/1/2011 7:52 PM, Barry Warsaw wrote:
necessary, I leave it alone. I think we're still due one last bug fix release
of Python 3.1, right?
Yes, hopefully soon.
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
On 4/2/2011 9:55 PM, Eugene Toder wrote:
Documentation for ast module does not warn about possible changes,
The current boxed warning at the top of the dis doc is fairly recent.
The ast doc should gain something similar. It currently does say:
__version__ which is the decimal Subversion
On 4/3/2011 10:02 PM, Guido van Rossum wrote:
Sure, but do we have any indication that the warnings for dis make a difference?
I think there had been a few grumbles about bytecode not being stable.
Without that, it is part of the newish effort to specify in the docs
what is CPython
On 4/4/2011 2:00 PM, Guido van Rossum wrote:
On Mon, Apr 4, 2011 at 10:05 AM, fwierzbi...@gmail.com
fwierzbi...@gmail.com wrote:
As a re-implementor of ast.py that tries to be node for node
compatible, I'm fine with #1 but would really like to have tests that
will fail in test_ast.py to alert
On 4/4/2011 4:05 PM, Dino Viehland wrote:
reduce to the core DLR nodes on-demand). We already do a huge amount of
manipulation of those ASTs from optimizations (constant folding being the
primary
one) to re-writing them completely for things like generators or sys.settrace
support and
other
On 4/5/2011 3:57 PM, Raymond Hettinger wrote:
[Brett]
This PEP requires that in these instances that both
the Python and C code must be semantically identical
Are you talking about the guaranteed semantics
promised by the docs or are you talking about
every possible implementation detail?
I
On 4/6/2011 1:24 PM, Maciej Fijalkowski wrote:
No worries, it wasn't even my code. Someone
donated it. The was a discusion on python-dev
and collective agreement to allow it to have
semantic differences that would let it run faster.
IIRC, the final call was made by Uncle Timmy.
...
And, for
On 4/6/2011 2:54 PM, Terry Reedy wrote:
I believe that at the time of that decision, the Python [heapq] code was only
intended for humans, like the Python (near) equivalents in the itertools
docs to C-coded itertool functions. Now that we are aiming to have
stdlib Python code be a reference
On 4/8/2011 11:32 AM, Anthony Scopatz wrote:
an interpreter. For the purposes of benchmarking, the distinction
between compiler and interpreter, as some one said above, 'dubious'.
I agree. We should be comparing 'Python execution systems'. My
impression is that some of what Cython does in
On 4/8/2011 1:14 PM, Jon Riehl wrote:
I have a mostly functioning front end for 2.X that does these
expansions (MyFront), and I'm waiting for a stable Mercurial migration
Done and in use over a month. http://hg.python.org/
Further discussion of this idea is on the python-ideas list.
(The
On 4/12/2011 12:17 PM, Alexander Belopolsky wrote:
If you find specific versions that are affected by this bug, please
report it at bugs.python.org.
If Py version = 2.7 and != 3.0.
--
Terry Jan Reedy
___
Python-Dev mailing list
On 4/13/2011 7:52 AM, Antoine Pitrou wrote:
On Wed, 13 Apr 2011 06:28:58 +0200
Stefan Behnelstefan...@behnel.de wrote:
I think it would help to point out in the PEP that code that fails to touch
the theoretical 100% test coverage bar is not automatically excluded from
integration, but needs
On 4/14/2011 2:53 PM, Brett Cannon wrote:
I think you have the wrong issue #; that one has to do with string
exceptions.
Fix closes Issue1147.
Right, wrong issue. Log should be corrected if it has not been.
+- Issue #11474: Fix the bug with url2pathname() handling of '/C|/'
on
On 4/17/2011 1:32 AM, R. David Murray wrote:
As Brett said, people do come to depend on the details of the
implementation. But IMO the PEP should be clarified to say that the
tests we are talking about should be tests *of the published API*.
That is, blackbox tests, not whitebox tests.
I
On 4/20/2011 2:09 PM, Giampaolo Rodolà wrote:
No we haven't.
No we haven't what? Such out-of-context responses exemplify why
top-posting is greatly inferior for readers, who vastly outnumber the
one writer. If that line had been put where it belongs, right after what
it refers to, it would
On 4/20/2011 12:57 PM, Benjamin Peterson wrote:
On 4/19/2011 5:59 PM, victor.stinner wrote:
Issue #11223: Add threading._info() function providing informations about
the
thread implementation.
How about using a structseq ala sys.float_info or sys.long_info? (In
fact, we might want to
On 4/20/2011 10:11 AM, exar...@twistedmatrix.com wrote:
On 01:11 pm, benja...@python.org wrote:
It is a big mistake to think that documentation isn't necessary for
things just because you don't want application developers to use them.
Maintainers benefit from it just as much.
Maintainers
On 4/20/2011 7:57 AM, Ethan Furman wrote:
Victor Stinner wrote:
Finally, I'm very happy to see that my faulthandler module was as useful
as I expected [...]
Congratulations! Nice work.
Ditto. Multiple pats on the back.
--
Terry Jan Reedy
___
On 4/25/2011 1:21 PM, Rob Cliffe wrote:
type (3.)
type 'float'
3..__class__
type 'float'
type(3)
type 'int'
3.__class__
File stdin, line 1
3.__class__
^
SyntaxError: invalid syntax
Superficially the last example ought to be legal syntax (and return
type 'int').
You are a more
On 4/27/2011 10:53 AM, Guido van Rossum wrote:
On Wed, Apr 27, 2011 at 7:39 AM, Raymond Hettinger
Identity-implies-equality is necessary so that classes can maintain
their invariants and so that programmers can reason about their code.
[snip]
See
On 4/27/2011 2:41 PM, Glenn Linderman wrote:
One issue that I don't fully understand: I know there is only one
instance of None in Python, but I'm not sure where to discover whether
there is only a single, or whether there can be multiple, instances of
NaN or Inf.
I am sure there are multiple
On 4/27/2011 11:31 AM, Nick Coghlan wrote:
Currently, Python tries to split the difference: == and != follow
IEEE754 for NaN, but most other operations involving builtin types
rely on the assumption that equality is always reflexive (and IEEE754
be damned).
What that means is that correct
On 4/28/2011 3:54 AM, Tarek Ziadé wrote:
Hello
I removed some assert calls in distutils some time ago because the
package was not behaving correctly when people were using Python with
the --optimize flag. In other words, assert became a full part of the
code logic and removing them via -O was
On 4/28/2011 6:11 AM, Nick Coghlan wrote:
On Thu, Apr 28, 2011 at 6:30 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Thu, Apr 28, 2011 at 3:57 AM, Nick Coghlanncogh...@gmail.com wrote:
..
It is an interesting question of what sane invariants are. Why you
consider the
On 4/28/2011 4:40 AM, Mark Shannon wrote:
NaN is *not* a number (the clue is in the name).
The problem is that the committee itself did not believe or stay
consistent with that. In the text of the draft, they apparently refer to
Nan as an indefinite, unspecified *number*. Sort of like a
On 4/28/2011 12:55 PM, Guido van Rossum wrote:
*If* my proposal gets accepted, there will be a blanket rule that no
matter how exotic an type's __eq__ is defined, self.__eq__(self)
(i.e., __eq__ called with the same *object* argument) must return True
if the type's __eq__ is to be considered
On 4/28/2011 11:22 AM, s...@pobox.com wrote:
Barry I would agree. Use asserts for this can't possibly happen
Barry wink conditions.
Without looking, I suspect that's probably what the author thought he was
doing.
You wish: to repeat the example from threading:
def
On 4/29/2011 3:11 PM, Terry Reedy wrote:
On 4/29/2011 12:09 PM, Vinay Sajip wrote:
BTW, is there a public place somewhere showing stdlib coverage
statistics? I
looked on the buildbot pages as the likeliest home for them, but
perhaps I
missed them.
http://docs.python.org/devguide
On 5/1/2011 7:27 AM, Nick Coghlan wrote:
However, I did find Terry's suggestion of using the warnings module to
report some of the floating point corner cases that currently silently
produce unexpected results to be an interesting one. If those
operations issued a FloatWarning, then users could
On 4/29/2011 10:13 PM, Adrian Johnston wrote:
This may seem like an odd question, but I’m intrigued by the idea of
using Python as a data definition language with “undo” support.
If I were to try and instrument the Python interpreter to be able to
step backwards, would that be an unduly
On 5/5/2011 4:55 PM, Raymond Hettinger wrote:
Either way, the code is simpler by just using the default.
I thought about this and decided that the purpose of having defaults is
so one does not have to always spell it out. So use it. Readers can
always look it up and learn.
--
Terry Jan
On 5/9/2011 9:27 AM, Stefan Behnel wrote:
Eli Bendersky, 09.05.2011 14:56:
It's a known Python gotcha (*) that the following code:
x = 5
def foo():
print(x)
x = 1
print(x)
foo()
Will throw:
UnboundLocalError: local variable 'x' referenced before assignment
On the usage of 'x' in the *first*
A commit (push) partition time and behavior into before and after (with
a short change period in between during which behavior is undefined).
Some commit messages have the form 'x does y'. Does 'does' mean before
or after? Sometimes that is clear. 'x crashes' means before. 'x return
correct
On 5/9/2011 4:05 PM, Guido van Rossum wrote:
On Mon, May 9, 2011 at 12:36 PM, Eric Smithe...@trueblade.com wrote:
On 05/09/2011 03:17 PM, Guido van Rossum wrote:
While my own preference is make X properly raise an exception I'm
happy with any of the alternatives proposed here, and grateful
On 5/9/2011 1:54 PM, R. David Murray wrote:
If I do 'hg log' and search for a revno (that I got from hg annotate),
the commit message describing the change is not attached to that revno,
nor as far as I know is there a tool that makes it easy to get from that
revno to the explanatory commit
On 5/10/2011 10:59 AM, Nick Coghlan wrote:
On Tue, May 10, 2011 at 11:11 PM, R. David Murrayrdmur...@bitdance.com wrote:
How about:
reference to variable 'y' precedes an assignment that makes it a local
variable
For comparison, the error messages I was able to elicit from 2.7 were
as
On 5/11/2011 12:39 PM, Éric Araujo wrote:
Funny, I always use the present tense, to convey what the code does now.
Which code ;-).
At the moment you write a push message, your private clone does
something different from the public repository (and other private
clones). At the moment people
On 5/11/2011 2:08 PM, Victor Stinner wrote:
Le mercredi 11 mai 2011 à 19:05 +0200, Éric Araujo a écrit :
Le 10/05/2011 01:52, victor.stinner a écrit :
http://hg.python.org/cpython/rev/3c87a13980be
changeset: 70001:3c87a13980be
branch: 2.7
parent: 69996:c9f07c69b138
user:
On 5/18/2011 4:10 PM, Ethan Furman wrote:
Ethan Furman wrote:
[...]
Also posted to Python-Ideas.
Good. That is where it should have gone in the first place, as this is
about ideas not yet even in the PEP stage.
--
Terry Jan Reedy
___
Python-Dev
On 5/18/2011 2:51 PM, Ethan Furman wrote:
In Python 3 inequality comparisons became forbidden.
-- 123 [1, 2, 3]
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: unorderable types: int() list()
However, equality comparisons are still allowed
-- 123 == [1, 2, 3]
On 5/18/2011 10:19 AM, Nadeem Vawda wrote:
I'm not sure why you would encounter code like that in the first place.
Surely any code of the form:
''.join(c for c in my_string)
would just return my_string? Or am I missing something?
Good question. Anything useful like '-'.join(c for c in
On 5/18/2011 5:34 PM, Victor Stinner wrote:
You initial example gave me the impression that the issue has something
to do with join in particular, or even comprehensions in particular. It
is really about for loops.
squares = (x*x for x in range(1))
dis('for x in range(3): y =
1001 - 1100 of 2415 matches
Mail list logo
