if anything
ought to be tweaked.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/arc
to look at Python/ceval.c.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/arc
_function_name(
var_one, var_two, var_three):
print x
vs
for x in long_function_name(
var_one, var_two, var_three):
print x
That's a case where I'd be likely to use even more than two indentation
levels. Usually, though, I try to refactor the statement
mentally ignore the "== typecode" part and see
> the switch structure more clearly.
I don't do much C coding, so I don't have the right to an opinion on
that (FWIW, I find constant-first jarring). But I'd hate to see the
above in python code. The fact that you li
On Wed, 08 Jun 2011 21:04:48 +1000, Steven D'Aprano wrote:
> Terry Reedy wrote:
> > On 6/7/2011 5:35 PM, David Malcolm wrote:
> >
> >> I know that this style is unpopular, but if it helps, try mentally
> >> pronouncing "==" in C as "is
I haven't read through your post, but if you don't know about it I
suspect that you will be interested in the following:
http://code.activestate.com/pypm/pysandbox/
I'm pretty sure Victor will be happy to have someone else interested in
this topic.
--
R. David Murray
On Sun, 19 Jun 2011 15:40:01 -0400, Jim Jewett wrote:
> Does this really need to be a bare except?
No, but that's a separate bug report, which you are welcome to
file. The issue I closed was about moving the existing code.
--
R. David Murray http://www.bitd
t is to
run just a selected set of fixers (so that you could use it to generate
python3 code), but it seems to me that renaming modules is something
that 3to2 (and 2to3, of course) should be good at.
--
R. David Murray http://www.bitdance.com
___
to following the existing coding
conventions of stdlib modules...
(I initially called it InvalidMultipartCTEDefect, but all of the other
names were spelled out, so)
--
R. David Murray http://www.bitdance.com
___
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
quest issues (ie: bugs) in
the tracker are tagged 2.7. I expect to see that percentage continue
to decrease over time.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
roposed code would allow me, when writing a generator in
my code, do something that would allow me to yield up all the
values from an arbitrary generator I'm calling, over which I have
no control (ie: I can't modify its code)?
--
R. David Murray http://www.bitdance.com
is that I am more comfortable calling them
all attributes than calling them all members. The term 'members'
isn't used anywhere in the language itself, as far as I can recall,
whereas getattr and setattr are evidence that the language considers
them all attributes. I think we do the
On Mon, 27 Jun 2011 15:27:12 +0100, Michael Foord
wrote:
> On 27/06/2011 15:08, R. David Murray wrote:
> > 'data attributes' can so easily become something else in Python...it
> > seems to me that the only real difference between 'data attributes' and
> &
type type). I don't think anyone would argue with you
about that in general. (In specific there might in fact be some
places in the docs where such a change would improve clarity!)
So, the correct generic term for something that can be accessed
via attribute notation is attribute. T
On Mon, 27 Jun 2011 20:30:12 +0100, Michael Foord
wrote:
> On 27/06/2011 20:22, R. David Murray wrote:
> > [snip...]
> > So, the correct generic term for something that can be accessed
> > via attribute notation is attribute. The more specific term for an
> > at
esn't cover "class attributes that aren't
> descriptors").
Also, instances can have methods as instance attributes.
Trying to use 'instance attributes' for non-method attributes is a bad
idea, I think.
Given that there is no one thing that covers al
cified, someone suggested that the overall sleep time could also be
> truncated to a minimum of zero, i.e. treating negative values as zero.
Please file a bug report at bugs.python.org.
--
R. David Murray http://www.bitdance.com
___
Pytho
Hi
Python 3.2.1 was scheduled to be released on 6/19, I believe but there
is no mention of it anywhere. Has it been delayed?
Thanks.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
we're not too
likely to know how to work with it on Windows if you don't install it
from the MSI.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
roject kicks off, but I wanted to release/post now
so that there might be a chance of some review happening while I still
have time to respond quickly to the feedback.
--
R. David Murray http://www.bitdance.com
[*] I believe that if you try to use an email6 Message object with the 3.2
things as flat as practical. Namespace
packages clearly have utility, but please let's not descend into
java-esq package hierarchies.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://
> Or perhaps worms dig their way carefully around known bugs?
Hexlify, wormaround...our Barry is just full of interesting words :)
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
-like system, I need to know the path to said script.
We're trying to make python as easy to use on Windows as it is on Unix.
If find-script-on-path is considered a worthwhile feature, then as Mark
said it should be added to base Python (on all platforms), not special-cased
in the Windows laun
On Thu, 21 Jul 2011 01:06:57 -0700, Glenn Linderman
wrote:
> Interesting, David, that you feel it that Python usability on Windows
> should be limited to its usability on Unix, rather than to exceed it. I
> don't see that as a necessary or appropriate limit. Windows and Unix
T
documentation for test.support to
the devguide, and then vet the test suite so that unlink and friends
are always called as 'support.unlink', etc.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@py
On Wed, 27 Jul 2011 16:58:53 +0300, Eli Bendersky wrote:
> R. David Murray wrote:
> > But they aren't redundant, since the test.support versions ignore
> > errors.
>
> As I mentioned elsewhere, it's not good practice to have two functions with
> the same name
On Fri, 29 Jul 2011 15:28:44 +0200, =?UTF-8?B?w4lyaWMgQXJhdWpv?=
wrote:
> Le 29/07/2011 14:50, Antoine Pitrou a écrit :
> >> changeset: 71562:bdad5bc9a2ed
> >> user:Ãric Araujo
> >> summary:
> >> Stop ignoring Mercurial merge conflits files
y? We are using a (D)VCS, you are not
> losing anything.
As Ãric said, the .orig files may contain uncommitted changes. The
.rej files are information about what parts of the patch were
*not* applied, which is information that is not retained
anywhere else.
--David
___
care to in
the same way. That would doubtless help our users, but more care than
just marking functions as unstable would be required, I think.
Personally, I always thought the devguide should be part of Docs anyway.
It isn't because people didn't want it versioned along si
#x27;hg status' tells me all the files
that have appeared in my tree that I'm either not currently tracking or
explicitly ignoring (because the project's automated tools will deal
with them). Nothing in there about limiting it to files I *might*
w
wouldn't be any more of a problem than the regular python docs if
the devguide were in the normal doc tree. Just saying :)
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
On Fri, 29 Jul 2011 23:36:03 +0200, Antoine Pitrou wrote:
> On Fri, 29 Jul 2011 12:19:45 -0400
> "R. David Murray" wrote:
> >
> > > Besides, "hg status" is meant to show untracked files which could
> > > *potentially* be tracked. It's not
worked like
> this (we have many private APIs without an underscore).
I'm not sure it makes merging more difficult. I haven't had any
problems with email test merges even though I moved (i.e. renamed)
the test directory.
--
R. David Murray http://www.bitdance.com
n project.
My understanding (I could well be wrong) is that one reason is that we
prefer that the tests be installed. That is also the reason that a number
of tests that use large data files fetch them from the network (if and
only if the relevant resource is enabled).
--
R. David Murray
quot;perfect" patch costs me more like
> between half an hour and an hour.
>
QOTW. I think this excerpt should show up in the
new developer area.
--Scott David Daniels
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@p
re in the
logging in process, there should be an indication of how much your box
must be opened up before you can "log on," at least in the screen you
get to when you log on.
However, each time I went to enter such a note, I needed to "log on."
I just
deos (former My Videos)
> yay, next up posix support
I suspect that the whole thing was done to make sure that developers
of applications could:
A: cope with stupidly long path names.
V: cope with spaces in path names.
I bet they never intended to keep the huge names, just t
Jeffrey Yasskin wrote:
> The second returns the simplest rational within some distance. For
> instance, it'll prefer 22/7 over 333/106 if both are close enough. We
> might call it .simplest_within() for now. This seems useful for
> converting from float and displaying results to users, where we pre
ot; API
> because you have to read the documentation to understand why
Excuse me, I don't know about you, but I don't mind a language
with a document to consult. I actually wasn't born understanding
_any_ computer (or for that matter natural) language.
0Scott David Daniels
[
Scott David Daniels
[EMAIL PROTECTED]
___
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
I just noticed that the bz2lib version was updated to 1.0.5 in December
of 2007, for security reasons. I suspect it would be good to be sure
to ship this with 2.6 or 3.0.
--Scott David Daniels
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev
% vars())
self.failure_exception("%(first)r %(op)r %(second): %(msg)"
% vars())
--Scott David Daniels
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
Ben Finney wrote:
Scott David Daniels <[EMAIL PROTECTED]> writes:>
I would rather something more like:
def assert_compare_true(op, first, second, msg=None):
if op(first, second):
return
raise self.failure_exception(msg)
if ms
t,
I implemented my own versions of these asserts (Le, Lt, ...) a year or
so ago, and still find them so useful that I'll re-implement them where-
ever I am working without similar tests available.
--Scott David Daniels
[EMAIL PROTECTED]
___
Pyth
urely
i = list(d)
is a more reasonable way to do this. I seldom find a reason
to use .keys
--Scott David Daniels
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ems to
accidentally escalating warnings into errors, and it looked
to me like this would accidentally swallow errors getting
warning context and make them fail silently. The Idle issue
that I'm fiddling with is that it doesn't take the new
showwarning call format, and it looked like this shou
gs.formatwarning and
warnings.showwarning. If you get it wrong, a deprecation warning can
prevent a module like md5 from loading (for example).
--Scott David Daniels
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
Scott David Daniels wrote:
>
> Match the new warning protocol exactly:
> def showwarning(message, category, filename, lineno,
> file=None, line=None):
> ...
> If the line is not None, use it (which will happen if you pass it
>
held[number_to_hold]
...
--Scott David Daniels
scott.dani...@acm.org
___
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
he keyword arg "delimited," rather than "delimiter."
On Windows, I'd like to see:
os.path.commonprefix(['a/b/c.d/e'f', r'a\b\c.d\eve'], delimited=True)
return either
'a/b/c.d'
or r'a\b\c.d'
Perhaps even ['a', 'b&#
ath.dirname(os.path.commonprefix([
os.path.normpath(p) for p in paths]))
give '/a', not '/a/b'.
--Scott David Daniels
scott.dani...@acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
10.873 1.28 12.31
** Text overwrite **
20K modify one unit at a time 0.296 0.0721.320 4.09 18.26
400K modify 20 units at a time 5.690 1.360 22.500 4.18 16.54
400K modify 4096 units at a time 151.000 88.300 509.000 1.71 5.76
--Scott David
d be an
the Ellipsis instance.
--Scott David Daniels
scott.dani...@acm.org
___
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
It is computationally hard to do that (may have to chase chains of
**kwarg-passing functions), but even hard to document.
So, I'd avoid it.
--Scott David Daniels
scott.dani...@acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
Christian Heimes wrote:
... The performance penalty is slime to nothing for the common case
Sorry, I love this typo.
-Scott
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:
ndicate that something about the fix is not right.
So, I'm not sure this skip is even valid. I'm not sure we've finished
diagnosing the bug.
If there are any helpful tests I can run on Gentoo, please let me know.
--
R. David Murray http://www.bitdance.com
__
stalled.
I get null as the final output of that regardless of whether I use
'tr_TR' or 'tr_TR.utf8'.
This is with glibc-2.13-r2 (the r2 is Gentoo's mod number).
I'll attach this to the bug report, too, perhaps the discussion should
move there.
--
R. David Murray
On Tue, 02 Aug 2011 18:48:11 +0100, Chris Withers
wrote:
> On 19/07/2011 22:21, R. David Murray wrote:
> > The basic additional API is that a 'source' attribute contains the
> > text the generator read from the input source, and a 'value' attribute
>
them. Everything else is just details. And yes,
that distinction is much more important than the distinction between
minor version numbers. That's the whole point of python3, after all.
--
R. David Murray http://www.bitdance.com
___
P
luding that you are -1 on
the PEP :).
--
R. David Murray http://www.bitdance.com
___
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
nstall, so be it.
True, but I think that is orthogonal to the purposes of the PEP, which
is about supporting writing of system independent scripts that are *not*
provided by the distribution (or installed via packaging). And PEP 397
aims to extend that to
at accepting unicode in the binascii and base64 APIs is a bad idea.
I'm on vacation this week so I may not be very responsive on this thread,
but unless other people agree with me (and will therefore advance the
relevant arguments) the thread can die and the patc
derstand how this proposal would help at all in dealing with email.
The PEP would be strengthened by providing specific examples of the
claims made in this section.
I am -0 on this proposal. I will bow to the experience of those actually
trying to port and support web code, which I am
that claim
> > (or I fail to see the argument).
>
> Python 2.6 code:
> this = u'that'
>
> Python 3.3 code:
> this = u('that')
>
> Not source compatible, not elegant. (Even though 2to3 could make this
> fix, it'
Just let's start deprecating it too, so that once Python 2.x
> compatibility is no longer relevant we can eventually stop supporting
> it (though that may have to wait until Python 4...). We need to send
> *some* sort of signal that this is a compatibility hack and that no
>
'.
Why can't you just continue to do the above for 3.3 and beyond?
Frankly, *I'm* not worried about the uptake pace of Python3. It feels
to me like it is pretty much on schedule, if not ahead of it.
But to repeat, I'm not voting -1 her
t-and-test, which to
> > me
> > is the main benefit of a single codebase.
>
> The downsides of a unicode_literals future import are spelled out in the
> PEP:
>
> http://www.python.org/dev/peps/pep-0414/#rationale-and-goals
But the PEP doesn'
gt;
> I'm way too lazy. The political wrangling is just too draining
> (especially over something so trivial). But I will definitely support
> other proposals that make it easier to straddle, sure.
"tip of the iceberg", eh? Or the nose of the camel in the tent.
This pushe
On Mon, 27 Feb 2012 22:11:36 +, Armin Ronacher
wrote:
> On 2/27/12 9:58 PM, R. David Murray wrote:
> > But the PEP doesn't address the unicode_literals plus str() approach.
> > That is, the rationale currently makes a false claim.
> Which would be exactly what tha
potential
porters may choose to wait until OS vendors are supporting 3.3 widely
before starting their ports. We are clearly expecting that the reality
is that the impact will be at worse neutral, and hopefully positive.
--David
___
Python-Dev mailing
it deviate from the specification?
> >
> > In this case, the specification is the grammar, and the implementation
> > certainly doesn't deviate from it. So it can't be a bug.
>
> I don't think anyone can assert that the specification itsel
m aware of a project where the availability of sandboxing
might be make-or-break for continuing to use Python. In this case
the idea would be sandboxing plugins called from a Python main program.
I *think* that Victor's project would enable that, but I haven't looked at
it closely.
--Davi
glier...but not as bad as the 2.5 exception hacks. Still, I'll
grant that it would be a harder sell to upstream than the changes Barry
mentioned. On the other hand, it's not like the code will get
*prettier* once you drop Python2 support :(.
--David
you are attacking
Python3 and arguing (out of your personal experience) that porting
is harder than other people (out of their personal experience) have
found it to be. This presumably reflects the different problem
domains people are working in.
--David
_
me from being a consenting adult. (Having to
name mangle by hand when someone has used a __ method is painful enough,
thank you...good thing the need to do that doesn't dome up often (mostly
only in unit tests)).
--David
___
Python-Dev mailing li
ally worked (try printing
l).
This is not a bug, it is a quirk of how extended assignment works.
I think there's an issue report in the tracker somewhere that
discusses it.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
I don't like any of the suggested wordings. I have no problem with
us recommending other modules, but most of the Python libraries are
perfectly functional (not "leaky" or some other pejorative), they just
aren't as capable as the wiz-bang new stuff that's av
mitter increases the chances that new
patches will actually get committed
--David
___
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
seem to be a way to filter search results in the tracker.
Is the advanced search ('search' link on left hand side) missing
some filtering capabilities?
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
? Or fix only the
> documentation? Or not touch them at all?
Our usual approach in cases like this is to not change it in the maint
releases. Why risk breaking someone's code for no particular benefit?
If you want some extra work you could add it as a deprecation warning,
I suppose.
--Davi
On Fri, 16 Mar 2012 15:49:33 -0400, Terry Reedy wrote:
> On 3/16/2012 11:33 AM, R. David Murray wrote:
> > On Fri, 16 Mar 2012 09:38:49 +0200, Eli Bendersky wrote:
> >> 1. The behavior of append, insert and extend should be similar in this
> >> respect
> &
BEST, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW,
GetTickCount64, QueryUnbiastedInterruptTime, etc? Then None would mean
it is allowable to use time.time and the cache-the-last-time-returned
algorithm, and BEST would be Victor's current 'strict=True'. And if you
require a Linux clock on Wi
jection really applies.
That said, there is an open bug in the tracker about the insecurity
of a system install of python (exactly that the files are writable
by anyone). So that would have to be solved first. I'd say this
is definitely a separate is
t easier for my eye to ignore it and just focus on
the content.
Hey, maybe you could make the sidebar only appear if the browser
supports javascript? Then I'd never have to see it, and that
I would consider "clean" :)
Thanks for working on improving things.
--David
___
On Wed, 21 Mar 2012 06:58:21 +0100, Georg Brandl wrote:
> On 21.03.2012 00:17, R. David Murray wrote:
> > On Tue, 20 Mar 2012 23:38:53 +0100, Georg Brandl wrote:
> >> Hi all,
> >>
> >> recently I've grown a bit tired of seeing our default Sphinx theme,
Sphinx, after all, and looks pretty good in general.
--David
___
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
..) and I can never
remember the key sequence to change the focus, because *most* sites I
don't have that problem with.
For whatever that's worth :)
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
gation block wasn't there when there's no CSS, but that's more
of an issue for easier access from screen readers, since the block is
reasonably short).
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
n order to make the text narrow enough to read
slows down my workflow. (Which means that on the python docs and
the bug tracker I just put up with reading it wide...)
I realize that I'm in the minority, though :)
--David
___
Python-Dev mailing l
On Wed, 28 Mar 2012 23:05:59 +1100, Steven D'Aprano wrote:
> +1 on Nick's suggestion of try_monotonic. It is clear and obvious and doesn't
> mislead.
How about "monotonicest".
(No, this is not really a serious suggestion.)
However, time.steadies
notes that points
to your more extensive discussion?
But keep in mind I'm not the release manager; we'll need their buy
in on this.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
Since Martin hasn't sent a note about this here I will:
I noticed that text search wasn't working right on the bug tracker, and Martin
has taken it offline again to re-index.
--David
___
Python-Dev mailing list
Python-Dev@pytho
racker and marking it as a
release-blocker. That way the release managers will see it and can
decide what if anything they want to do about it.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
rch working properly: Search all for "virtualenv" at the top
> right and issue 14357 doesn't appear in the list of results...
>
> Also, search open issues for "subprocess" and there is only 1 result. I
> wish :-)
I get three for 'all' issues, w
efore (unless
there were inter-thread synchronization issues involved, of course).
Nor am I sure the locking dict type suggested by Jim on the issue would
help, since a number of the dicts we are using are produced by library
code. So we'd have to wait for those librari
lso, search open issues for "subprocess" and there is only 1 result. I
> > wish :-)
>
> Please submit an issue to the meta tracker. It may take weeks until I
> can get to it.
I've reopened issue 443, with an example of a failing search giving
relevant issue numbers.
-
On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossum wrote:
> On Thu, Mar 29, 2012 at 12:58 PM, R. David Murray
> wrote:
> > Some of us have expressed uneasiness about the consequences of dict
> > raising an error on lookup if the dict has been modified, the fix Victor
> &
On Thu, 29 Mar 2012 16:31:03 -0400, "R. David Murray"
wrote:
> On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossum wrote:
> > My original assessment was that this only affects dicts whose keys
> > have a user-implemented __hash__ or __eq__ implementation, and that
&g
On Thu, 29 Mar 2012 23:00:20 +0200, Stefan Behnel wrote:
> R. David Murray, 29.03.2012 22:31:
> > On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossum wrote:
> >> On Thu, Mar 29, 2012 at 12:58 PM, R. David Murray wrote:
> >>> Some of us have expressed uneasiness
her than ship something
out-of-date, we choose to put the onus on the user to ensure that the
appropriate code+db exists on their system.
Hopefully someone will correct me if I'm wrong, and/or find a pointer
to the relevant thread.
--David
___
Python
1801 - 1900 of 2106 matches
Mail list logo
