7;t gentle: as you go over the 1e50 boundary,
the number of significant digits produced suddenly changes
from 56 to 6; it would make more sense to me if it
stayed fixed at 56 sig digits for numbers larger than 1e50.
> - now that we're using David Gay's 'perfect roun
Mark Dickinson wrote:
> On Sun, Apr 26, 2009 at 8:11 PM, Scott David Daniels
> wrote:
>> As a user of Idle, I would not like to see the change you seek of
>> having %f stay full-precision. When a number gets too long to print
>> on a single line, the wrap depends on
ark Dickinson wrote:
> On Sun, Apr 26, 2009 at 10:42 PM, Scott David Daniels wrote:
>...
>> I had also said (without explaining:
>>>> only the trailing zeroes with the e, so we wind up with:
>>>> 11579208923731619542357098500868
remaining question is whether that is a reasonable use case, a
frequent use case, or a stupid use case; and whether the resulting visible
Reasonable I don't know, but frequent (FSDO frequent) and out of
our control yes. It happens often when downloading files with wget,
for ex
world where everyone (including Windows) acts like
we are hearing OS/X does and rejects the garbled encoding _at the OS
level_, then we'd be able to trust the file system encoding (FSDO trust)
and there would be no need for this PEP or any similar solution.
--David
.
Unless I'm missing something, one of these is type str, and the other is
type bytes, so no ambiguity.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
On Tue, 28 Apr 2009 at 20:29, Glenn Linderman wrote:
On approximately 4/28/2009 7:40 PM, came the following characters from the
keyboard of R. David Murray:
On Tue, 28 Apr 2009 at 13:37, Glenn Linderman wrote:
> C. File on disk with the invalid surrogate code, accessed via the
ved the problem that Martin is
trying to solve, even if it is possible to put Unix specific code into
your Mono ap to deal with byte filenames on disk from within your GUI.
FWIW I'm +1 on seeing PEP 383 in 3.1, if Martin can manage the patch
in time.
--David
(*) I'd argue that in an i
(ie: instead you have a generalized is_valid_unicode test
function that you always use).
--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
tive.
Georg, maybe you should post the link to the python-ideas discussion?
--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
k trunk.
Especially the security issues you cite (which I don't understand).
--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
.
So this posting is a general reminder that the tests should not make
assumptions about the writabilty of the test directory (or, for that
matter, of the CWD).
When I get time I'll file bugs on the particular failures I'm seeing,
after I do an install fro
dress; it depends on the context.
FWIW I hate dealing with non-subnet-aligned IP address ranges whenever
they come up. But it is true that they do come up.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
On Mon, 1 Jun 2009 at 18:54, Jake McGuire wrote:
On Mon, Jun 1, 2009 at 12:16 PM, "Martin v. L?wis" wrote:
As for Clay McLure's issue: I feel it's primarily a matter of taste.
I see nothing morally wrong in using the same class for hosts and
networks, i.e. representing a host as a network of siz
an
ip-without-netmask data type to be also useful (but a lot less important!)
I would also find a subclass that was network-only (rejects anything
but the zero of the subnet for the IP) useful. But I think both of
those can be implemented fairly trivially as subclasses of the existing
ipaddr o
these issues are *precisely*
the sort of things that can be fixed with documentation and
backward-compatible changes - but I also think that a bit more time to
address such things would be reasonable.
If they are documentation and backward compatible cha
ning strings from __getitem__), I withdraw
my support for keeping it in 3.1.
--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
up (I initially did not know I
could just hit reply either).
You can even open new tickets via email, but I've never tried that.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
rable developer coordination headaches.
Any Mercurial boffins want to talk about how this works in practice?
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/
On Sun, 7 Jun 2009 at 18:55, "Martin v. L?wis" wrote:
B. "Yes."
This answer means that the 3.1 to 3.2 development cycle will need to
be truncated by roughly 6 months so that 3.2 can be released before 2.7
with any new features of interest. The 3.2 and 2.7 releases should then
occur within a fe
On Sun, 7 Jun 2009 at 21:21, "Martin v. L?wis" wrote:
I'm neutral on time frames, but I think that it _should_ be a policy
that new features only get released to the 2.x branch after they have
been released in the 3.x branch. Or, rather, I though that policy was
implicit in the idea that we were
On Sun, 7 Jun 2009 at 21:55, Michael Foord wrote:
R. David Murray wrote:
[snip...]
> By the policy you propose, we could not have released 2.6 in October
> 2008, which we really really wanted to because Apple wanted us to.
I don't think the 2.6 release date is relevant to this
e the main difficulty may have to
do with the C implementation.
I've also noticed that sort appears far faster;
is the C implementation working as expected?
It may be nice to have the reverse parameter
as well, but I'm not sure how that could be
implemented right off the bat.
David A. Bar
st_creation_time
Speaking as somebody who thought the c in ctime meant creation, I'm +1
on this proposal with Greg's modification.
--Scott David Daniels
scott.dani...@acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http:
I tend to prefer zero-ish defaults, how about:
def peek(self, size=None, nonblocking=False)
We still don't have "at most one read" code, but something a bit like
data = obj.peek(size=desired, nonblocking=True)
if len(data) < desired:
data = obj.peek(size
lihood that code in the wild would break if the bug were fixed.
--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
on has a
tradition of having "one obvious way" to do something, so introducing an
"alternative" syntax that you admit is sub-optimal does not seem to me
to have enough benefit to justify breaking that design guideline.
Congratulations on your first foray into the core, though :
start Python. One opens a Dos-like window presumably
for "command-line" entry. I can't make anything of it.
I did a straight install on a XP system.
Any help would be appreciated.
Have a good day,
David H. Burns
___
Python-Dev mailing
only one of the four I checked; I suspect
the other three are similarly mislabeled.
--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
works:
$ python setup.py uninstall some_package
Then explicitly say so for us poor schlubs.
--Scott David Daniels
scott.dani...@acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Kevin Teague wrote:
On Jun 30, 2009, at 4:46 PM, Tarek Ziadé wrote:
On Tue, Jun 30, 2009 at 10:06 PM, Scott David
Daniels wrote:
Tarek Ziadé wrote:
On Tue, Jun 30, 2009 at 8:37 PM, Paul Moore wrote:
[1] I'd actually like it if the PEP defined an uninstall command -
something like "
On Tue, 30 Jun 2009 at 20:06, Scott David Daniels wrote:
Kevin Teague wrote:
On Jun 30, 2009, at 4:46 PM, Tarek Ziad? wrote:
> On Tue, Jun 30, 2009 at 10:06 PM, Scott David
> Daniels wrote:
> > Tarek Ziad? wrote:
> > > On Tue, Jun 30, 2009 at 8:37 PM, Paul Moore
>
ber correctly, the default csv dialect is just the Excel dialect, so
this would be two different ways of saying the same things.
Right, but Guido's point is, decide which one is the is the definition
and stick to talking about it in that form.
--Scott David Daniels
scott.dani...
ry out the workflow".
The idea would be to have committers actually exercise the workflow on
their platform for at least one patch, including whatever replaces
the svnmerge step.
I can almost guarantee we will find some issues that need to be resolved,
and that people won't try it out
;t an explicitly stated goal. But it was the
direction my mind went when I read Tarek's notes, given that the first
stated goal is "standardize more metadata".
But I'm not one of the people involved in system packaging tools, so
I&
no tool like svnmerge for tracking changesets to be merged, which could
be an issue that needs a resolution.
IIUC, the discussion about named versus cloned branches is part of
figuring out the workflow
--David
___
Python-Dev mailing list
P
On Tue, 7 Jul 2009 at 23:30, Tarek Ziad? wrote:
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote:
At 03:23 PM 7/7/2009 +0200, Tarek Ziad? wrote:
When I started to work on this I didn't realize the gigantic amount of
work and coordination it requires
No one expects the package inquisition. ?;-
ere some page I overlooked? Is there a better forum
in which to ask this question?
--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.pyt
der myself done until comments
come back on the patch.
--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
them.
--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
em?
Can we learn anything from the solution to that problem? Does not the
fact that a (standard) solution to that problem was required indicate
that a similar solution needs to be provided by core Python? (And yes,
it's out of scope for PEP 376).
--David
(*) or, for our Windows users,
On Sun, 19 Jul 2009 at 16:07, Nick Coghlan wrote:
David Lyon wrote:
So it isn't clear why you want to remove the thing that you are
advocating works so great
Jim was quoting someone *else* that had suggested removing it (I'm not
sure how serious the original suggestion actually
those
variables at the top level of the file, so I have no idea why
this function exists, except to make the code more confusing.
It could potentially be used for testing, but that's a guess.
regrtest calls it from dash_R_cleanup as part of "clear[ing]
assorted module caches&
ython community?
--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
Raymond Hettinger wrote:
[Scott David Daniels]
I find I have a need in randomized testing for a shorter version
of getstate, even if it _is_ slower to restore. [blah about big state]
Sounds like you could easily wrap the generator to get this.
It would slow you down but would give the
On Wed, 19 Aug 2009 at 08:19, Peter Moody wrote:
On Wed, Aug 19, 2009 at 6:47 AM, Tino Wildenhain wrote:
Le Tue, 18 Aug 2009 13:00:06 -0700, Peter Moody a ?crit :
o.broadcast
? ?IPv4Address('1.1.1.255')
this is often used but not the only valid broadcast address,
in fact, any address betwee
clear bug: blank path elements were being
introduced into the path _unintentionally_ and unexpectedly. Setting
PYTHONPATH would be a way to do it intentionally.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
ork' with an IP address of 192.168.1.1.
That looks like a host-address-plus-netmask to me, not a network
address.
--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
r
an attribute error or return self.
--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
On Tue, 15 Sep 2009 at 18:43, Antoine Pitrou wrote:
R. David Murray bitdance.com> writes:
x = IPv4AddressWithMask('192.168.1.1/24')
x.network == IPv4Network('192.168.1.0/24')
x.network[1] == x
I don't think we need an IPAddressWithMask which w
On Tue, 15 Sep 2009 at 19:20, Antoine Pitrou wrote:
R. David Murray bitdance.com> writes:
I would find that acceptable but sub-optimal. Most of my use cases
(which involve manipulating router and firewall configuration files) would
then start by making a little class named AddressWithNetw
On Tue, 15 Sep 2009 at 21:58, Antoine Pitrou wrote:
Le mardi 15 septembre 2009 ?? 15:48 -0400, R. David Murray a ??crit :
It's useful functionality is parsing/validating an address+mask, rendering
as address+mask, and being able to get the associated IP and network objects
from it. I
ather than as
a boolean 'strict' option)
This seems to be the right solution to me, particularly the use of an
alternate constructor rather than an ambiguously named flag.
+1
--David
___
Python-Dev mailing list
Python-Dev@python.org
http:
fact that it didn't was what scuttled
inclusion last time.
--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
tructor method to return the network object
representing the network that a given IP address is in when a given
mask is applied to it. (Which is easily computed by applying the mask
to the IP.)
--David
___
Python-Dev mailing list
Python-Dev@python.org
wait and see what develops and add it later if
there is demand for it.
--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%4
ous:
the network address really is the first address in the network range,
and the broadcast really is the last, in common usage. Exceptional cases
can then be handled by custom subclasses, without having someone who
has to handle weird broadcast addresses (for example) submittin
appears to use the same object class for both addresses and networks.
It has neither a 'network' nor a 'broadcast' attribute; instead it has
'ip' (it isn't clear from the docs if that returns the network address
or the
other modules/tools
that are missing, or submodules that should be broken out into
separate lines, please let me know.
After the initial flurry of updates and comments dies down I will check
this in.
--David
--
Maintainers Inde
me of avoiding confusion
doesn't make sense when the same confusion can be alleviated w/o the
loss.
We're suggesting moving that functionality (accepting a non-masked IP
plus netmask and returning the corresponding Network object) into
a different constructor, not eliminating the function
On Thu, 17 Sep 2009 at 10:38, Peter Moody wrote:
On Thu, Sep 17, 2009 at 10:32 AM, R. David Murray wrote:
On Thu, 17 Sep 2009 at 09:16, Peter Moody wrote:
I mentioned before that IPy's insistence on receiving masked out
networks was one of the main reasons I wrote ipaddr to begin
On Thu, 17 Sep 2009 at 10:59, Brett Cannon wrote:
On Thu, Sep 17, 2009 at 10:38, Georg Brandl wrote:
??Could we *please* have tracker names that match the committer names?
(This doesn't even need to be done by the individual users, I would
volunteer to rename all committer accounts and notify
On Thu, 17 Sep 2009 at 10:57, Brett Cannon wrote:
Looks great to me! Only thing missing that I can think of is sticking
Eric down as the guy who does str.format(). =)
OK, I've added that one to the last table ;)
--David
___
Python-Dev mailing
On Thu, 17 Sep 2009 at 14:08, R. David Murray wrote:
On Thu, 17 Sep 2009 at 10:59, Brett Cannon wrote:
On Thu, Sep 17, 2009 at 10:38, Georg Brandl wrote:
> ??Could we *please* have tracker names that match the committer names?
>
> (This doesn't even need to be done by the in
I decided to commit the draft of maintainers.rst in case people would
rather update it themselves. I'm happy to continue collecting updates
and applying them as well.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
On Fri, 18 Sep 2009 at 07:45, Nick Coghlan wrote:
R. David Murray wrote:
I would have IPv4Address itself be strict, and thus the new constructors
would compute the network address and call the regular IPv4Address
constructor.(*)
s/Address/Network/ in this paragraph :)
Ah, yes, sorry for the
, and retype
the url. I don't have that problem with docs, obviously :)
--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
On Fri, 18 Sep 2009 at 02:24, Sebastian Rittau wrote:
On Thu, Sep 17, 2009 at 02:04:11PM -0400, R. David Murray wrote:
I mean, eg, IPv4Network.fromHostIP('192.168.1.1/24').
I'd actually suggest to use
>>> net, host = parse_network_and_host("192.168.111.33/24&q
st amount of
confusion on everyone's part, and I'm guessing it is because the common
terminology and usage blurs the line between addresses and networks.
And that's what we are trying to make clear(er) through a well structured
API.
--David
refinement we can of the API for handling all of them.
--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
an
error codes to act accordingly). For IOError types that really matter (eg.
Doesn't matter if it isn't very many, I think, just that it can be done.
But I suspect it is fairly common. I know I have inspected OSError codes
(though I can't remember if I've don
able"(*) message from
PyObject_GetItem.
The logic appears to be, roughly, if an object does not have mapping
methods, or has them but does not have mp_subscript, and does have
sequence methods but does not have sq_item, then you get a 'does
not support indexing'. Otherwise you ge
cluding download logic
in the test to go retrieve it from a known URL (I believe we already do
that for some of the codec tests).
We do. There's even support code in test.support for handling such
downloads relatively cleanly (and cleaning up afterward, though
On Thu, 24 Sep 2009 at 13:49, Antoine Pitrou wrote:
Le Thu, 24 Sep 2009 00:23:31 -0400, David Lyon a ??crit??:
Depends on where the machines are. There are good tools do check all
automatically. Nagios is one.
Anyway, this would suite my work schedule for the next 12 months.
Do we already
On Sun, 27 Sep 2009 at 13:59, Peter Moody wrote:
On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou wrote:
Peter Moody hda3.com> writes:
def parse_net_and_addr(s):
?return (IPNetwork(s), IPAddress(s.split('/')[0]))
I've only heard talk of new classes and new methods, not new
constructor func
On Mon, 28 Sep 2009 at 05:57, "Martin v. L?wis" wrote:
Finally, to Stephen's point about seeing the other side of the
argument, I wrote this offlist a week ago:
I *understand* what you're saying, I *understand* that
192.168.1.1/24 isn't a network,
But you still want to treat it as one.
Coul
On Mon, 28 Sep 2009 at 07:34, R. David Murray wrote:
The fundamental divide here is between two behaviors.
ipaddr:
> > > x = IPv4Network('192.168.1.1/24')
> > > y = IPv4Network('192.168.1.0/24')
> > > x == y
False
>
On Sun, 27 Sep 2009 at 10:06, David Moss wrote:
On 27 Sep 2009, at 07:56, "Martin v. L??wis" wrote:
I wouldn't ask for that: it should certainly be possible to supply
masks. However, I would want to reject masks that don't correspond to
a prefix, and have only the
On Mon, 28 Sep 2009 at 22:11, "Martin v. L??wis" wrote:
Martin v. L??wis v.loewis.de> writes:
Could you explain what benefit there is for allowing the user to create
network objects that don't represent networks? Is there a use-case
where these networks-that-aren't-networks are something other
On Mon, 28 Sep 2009 at 22:32, Antoine Pitrou wrote:
Le lundi 28 septembre 2009 ?? 22:11 +0200, "Martin v. L??wis" a ??crit :
That's not the question that was asked, though - the question asked
was "Under what circumstances would I want to specify...". I hope
most people agree that it is desirab
On Mon, 28 Sep 2009 at 13:43, Guido van Rossum wrote:
On Mon, Sep 28, 2009 at 1:36 PM, R. David Murray wrote:
I would say that there certainly are precedents in other areas for
keeping the information about the input form around. For example,
occasionally it would be handy if parsing a hex
or the 'nat' access list. I first wrote the line like
this:
print >>output, 'permit ip {} {} any'.format(inside.ip, inside.hostmask)
because I wanted the base IP of the inside network to go into the
access-list statement. The code would have run, but it would have
prod
On Tue, 29 Sep 2009 at 15:24, R. David Murray wrote:
There's one place in this code where the inclusion of the 'ip' information
in the IPNetwork class could have been used. In the line that allows ICMP
traffic to the router's outside port, I could have written 'inside.
uot;.net_ip" would also help (this latter change
would also eliminate the mental disconnect caused by an attribute called
.network returning an IPAddress instance).
+1
--David (RDM)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
On Wed, 30 Sep 2009 at 13:27, Vinay Sajip wrote:
I'm planning to "officially" drop support for Python 1.5.2 in the logging
package.
What's the minimum version of Python that the logging module now officially
supports?
--David (RDM)
__
s,
IPNetwork) tuple, then the user would choose the right class, IMO,
because otherwise they couldn't even get their code to parse the input.
That seems like good design to me.
But I think I'm descending to beating a dead horse here
--David (RDM)
(*) yes, I'm ignoring the IPv4/IPv
2) add a class that differs from IPvXAddress by having a 'network'
attribute that points (possibly lazily) to an IPvXNetwork object,
and perhaps 'netmask' and 'hostmask' attributes.
Especially after my experience with writing a real example program, I
prefer
uld function in both formatting styles and
expect the same parameters must be very rare in the real world.
Define "fails":
"{a} {b} c" % {'a':12}
'{a} {b} c'
That didn't fail...
Also, what if both fail? Which fai
there would be a new rc. Only when no
bugs needing fixed are found does the rc turn into the actual release.
But I understand that this is an idealized rc/release policy :)
--David (RDM)___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
On Tue, 20 Oct 2009 at 09:27, sstein...@gmail.com wrote:
Shouldn't this be on python-ideas?
IMO this question is appropriate for python-dev, not python-ideas.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
g that both Mark Dickinson and Raymond Hettinger will
comment on this thread eventually...)
--David (RDM)
___
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
n't :)
(It raises an attribute error.)
__doc__ is a funny beast. If someone can come up with a better
fix for 5890, that would be great.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
[x for x in res][0]
x, = res # I didn't think of this one before recently
Are all answers, but none of them I would consider *obvious*.
And from my SQL-hacking experience:
x = min(s)
--Scott David Daniels
scott.dani...@acm.org
___
Pyt
s 4970, 3892,
and 6462 in this category, and there are a few more that we can/will file
if we continue to pay attention to the failure reports now arriving on
the irc channel.
--David (RDM)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
On Fri, 30 Oct 2009 at 08:55, Jesse Noller wrote:
On Fri, Oct 30, 2009 at 4:53 AM, "Martin v. L?wis" wrote:
I'm confused: first you said they fail, now you say they get skipped.
Which one is it? I agree with R. David's analysis: if they fail, it's
a multiprocessing bug, if they get skipped, it'
On Fri, 30 Oct 2009 at 09:57, "Martin v. L?wis" wrote:
But the real reason for having a buildbot category (or at least a keyword)
would be to be able to tag all bugs that are currently making buildbots
fail that are _not_ the result of a recent checkin. This would make
the task of finding the bu
he idea of EC2 buildslaves seems pretty attractive...
--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
On Mon, 2 Nov 2009 at 10:09, Guido van Rossum wrote:
On Mon, Nov 2, 2009 at 10:06 AM, Raymond Hettinger wrote:
[Guido van Rossum]
I'm -0 on backporting nonlocal to 2.7. I could be +0 if we added "from
__future__ import nonlocal_keyword" (or some such phrasing) to enable
it.
With the "from
On Mon, 2 Nov 2009 at 22:17, "Martin v. L?wis" wrote:
I don't currently have an opinion on this backport proposal, but in
regard to this argument: if we do not do any 2.x releases after 2.7,
then over time the number of packages that can afford to drop 2.6 support
will grow, yet many will need t
it a "sloppy mode" parser, and then yes, that would solve the
problem.
--David (RDM)___
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
1401 - 1500 of 2106 matches
Mail list logo
