On Tue, 2 Jun 2009 at 12:26, Clay McClure wrote:
On Tue, Jun 2, 2009 at 2:08 AM, "Martin v. L?wis" wrote:
py> x = ipaddr.IP("30.40.50.60")
py> print(x.ip_ext_full)
30.40.50.60
Thankfully the authors have provided this obscure and strangely-named
method to get at the correct string representat
On Tue, 2 Jun 2009 at 21:02, Paul Moore wrote:
* I'd expect separate classes for "an IP address" and "a subnet" -
I've no problem with that expectation being wrong, but I'd like some
documentation as to *why* a single class is appropriate. (More
generally, the documentation seems pretty terse). S
On Wed, 3 Jun 2009 at 03:42, Mike Pennington wrote:
That said, I test drove ipaddr for about 30 minutes and so far like the
big-picture API design quite a bit. I'll specifically address Clay's concern
about hosts vs networks, because this issue is important to me; I've been in
the network engi
On Thu, 4 Jun 2009 at 12:23, Greg Ewing wrote:
Michael Foord wrote:
if you are added as nosy on a tracker item (which happens when you make a
comment or you can do yourself) then you get emailed about new comments.
That's good, but...
only going to the tracker to add responses.
is not
I just wanted to share my experience with the mercurial checkout. I cloned
http://code.python.org/hg/branches/py3k to continue work on
http://bugs.python.org/issue1578269 but I found that when I click on
PC/VS8.0/pcbuild.sln, nothing happens.
This appears to be due to a bug/limitation in vslau
On Thu, 4 Jun 2009 at 17:30, Oleg Broytmann wrote:
On Thu, Jun 04, 2009 at 09:02:53AM -0400, Jason R. Coombs wrote:
It seems that within the hg repository, everything has been converted to LF for
line endings. I suspect this is because HG provides no integrated support for
line-ending
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
On Fri, 19 Jun 2009 at 14:15, Antoine Pitrou wrote:
Benjamin Peterson python.org> writes:
I mean that if you pass X and Y into a function and get Z in 2.6, then
you should be able to get Z from passing X and Y in 2.7 even if
there's a new argument that returns Z' if you pass True to it.
Wel
On Sun, 21 Jun 2009 at 12:36, Jerry Chen wrote:
For better or for worse, I have created a patch against the py3k trunk
which introduces a binary operator '@' as an alternative syntax for
the new string formatting system introduced by PEP 3101 ("Advanced
String Formatting"). [1]
It seems to me t
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
> > > wrote:
> > > > [1]
On Sat, 4 Jul 2009 at 12:28, Brett Cannon wrote:
On Sat, Jul 4, 2009 at 01:03, Dirkjan Ochtman wrote:
On Fri, Jul 3, 2009 at 20:04, Brett Cannon wrote:
Fine by me as long as people realize that if anything is questionable
then
the switch will not happen. Getting this right takes precedence
On Tue, 7 Jul 2009 at 13:05, Paul Moore wrote:
2009/7/7 Ben Finney :
[... lots of interesting stuff deleted ...]
I think it's not the developer's burden to decide *where* such files go;
rather, they should be declaring only the *purpose* of these files in
the distribution metadata, and it's up t
On Tue, 7 Jul 2009 at 15:26, M.-A. Lemburg wrote:
The merge process itself is more or less clear. What I'm missing
is the agreed upon strategy for applying the patches to the various
branches.
I've seen a few discussions about this, but no final statement
of what strategy to follow and whether h
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. ?;-
On Wed, 15 Jul 2009 at 09:29, Benjamin Peterson wrote:
2009/7/15 Peter Hanecak :
So, my question is: In which Python release has been this fix distributed?
Python 2.6 and above.
But it doesn't solve your problem, since the ticket says it only fixes
reading long ints, not writing them.
--Dav
On Wed, 15 Jul 2009 at 16:14, Paul Moore wrote:
Bluntly, as Python stands, import and sys.path do not offer any core
support for multiple versions. Custom solutions can be built on top of
that - that's what setuptools does. But they are precisely that -
custom solutions, and should be supported a
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 was though)
On Fri, 31 Jul 2009 at 15:17, Brett Cannon wrote:
* It creates a _default_mime_types() function which declares a
bunch of global variables, and then immediately calls
_default_mime_types() below the definition. There is literally
no difference in result between this and just putting tho
I'd like to express additional interest in python patch 1660179, discussed
here:
http://mail.python.org/pipermail/patches/2007-February/021687.html
On several occasions, I've had the desire for something like this. I've
made due with lambda functions, but as was mentioned, the lambda is cl
Steven D'Aprano wrote:
> Sent: Sunday, 16 August, 2009 08:15
>
> On Sat, 15 Aug 2009 04:39:03 am Jason R. Coombs wrote:
>
> >
> > def meta_decorator(data):
> > return compose(dec_register_function_for_x, dec_alter_docstring,
> > dec_inject_some_dat
> Raymond Hettinger wrote:
> Sent: Sunday, 16 August, 2009 12:42
>
> [Antoine Pitrou]
> > I also think it would be a nice addition.
> > (but someone has to propose a patch :-))
The patch was proposed and rejected here: http://bugs.python.org/issue1660179;
my reason for mentioning it here is bec
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
On Tue, 25 Aug 2009 at 16:59, Chris Withers wrote:
In any case, as a parting comment, http://bugs.python.org/issue1232023 seems
to have been committed with no tests and the only documentation being a one
liner in the NEWS.txt file. Was there other discussion of this?
It probably should have go
On Tue, 15 Sep 2009 at 14:28, Antoine Pitrou wrote:
Andrew McNamara object-craft.com.au> writes:
>>> ipaddr.IPv4Network('192.168.1.1/16').network
IPv4Address('192.168.0.0')
Er, does this mean that taking the `network` attribute from a network object
actually gives an address object (n
On Tue, 15 Sep 2009 at 14:16, Scott Dial wrote:
In other words, I don't see why obtaining a host address would *not*
retain the hostmask from the network it was obtained from. I am not
disagreeing with it being an individual address. I am disagreeing that
IPNetwork itself already does represent i
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
On Wed, 16 Sep 2009 at 12:50, [email protected] wrote:
On 11:10 am, [email protected] wrote:
Or, to put it another way, given an arbitrary host in a network (e.g.
your own machine or the default gateway) and the netmask for that
network, calculate the network address.
With a "lax" pars
On Wed, 16 Sep 2009 at 12:04, Paul Moore wrote:
Of course, the discussion seems to imply that even the experts have a
confused view, so maybe I'm being too ambitious here :-)
Part of the problem, as we discovered in the last go-round on
ipaddr, is that there are two types of experts: those who
On Thu, 17 Sep 2009 at 09:59, Greg Ewing wrote:
Nick Coghlan wrote:
Or, to put it another way, given an arbitrary host in a network (e.g.
your own machine or the default gateway) and the netmask for that
network, calculate the network address.
Some people have claimed that the gateway addr
On Thu, 17 Sep 2009 at 22:32, Nick Coghlan wrote:
Eric Smith wrote:
Antoine Pitrou wrote:
As it is, -1 from me. Either we only keep two concepts (Address and
Network), or if we introduce a third one (AddressWithMask,
whatever) for added practicality; but we shouldn't blur the line
between the
On Wed, 16 Sep 2009 at 20:26, Peter Moody wrote:
On Wed, Sep 16, 2009 at 7:48 PM, Greg Ewing wrote:
I'm not sure what usefulness the zero address on its own
has, but if it's considered useful enough to have an
attribute for it, calling it something like 'base_address'
would be less confusing.
On Thu, 17 Sep 2009 at 15:44, DrKJam wrote:
Granted, there are decisions to be made about exactly what the
properties/methods should be named to avoid ambiguity, but they are
important enough to be given access to in their own right. Details in
docstrings help too ;-) 'network' and 'broadcast' ar
I floated a proposal on stdlib-sig to create a file named
Misc/maintainers.rst. The purpose of this file is to collect knowledge
about who knows which modules well enough to make decision about issues
in the tracker when the participants in the issue aren't sure, and to
write down the community k
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 with.
Having ipaddr mimic this behavior would make it significantly less
useful. Removing functionality in the name of avo
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 list
Py
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
[email protected]
http://mail.python.org/mail
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
On Thu, 17 Sep 2009 at 14:19, Fred Drake wrote:
One of the reasons www.python.org/doc/ was considered less discoverable was
the about of only-sometimes-interesting information there; docs.python.org
contains only "current" docs (for some vague notion of current and only,
given that dev builds a
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
On Fri, 18 Sep 2009 at 11:04, Andrew McNamara wrote:
[attribution lost; apparently Steven D'Aprano given the CC]
To a non-specialist, "the network address" is ambiguous. There are many
addresses in a network, and none of them are the entire network. It's
like saying, given a list [2, 4, 8, 12],
On Thu, 17 Sep 2009 at 20:29, Peter Moody wrote:
On Thu, Sep 17, 2009 at 6:17 PM, Andrew McNamara
wrote:
off to patch the pep and implement some of the non controversial changes.
It might be a good idea to add some use-cases to the PEP.
There are several use-cases in the PEP already.
The p
On Sat, 19 Sep 2009 at 12:31, Pascal Chambon wrote:
stream operations into IOErrors. Error codes are not the same as unix ones
indeed, but I don't know if it's really important (imo, most people just want
to know if the operation was successful, I don't know if many developers scan
error codes
On Wed, 23 Sep 2009 at 02:01, MRAB wrote:
Dino Viehland wrote:
Is there a reason or a rule by which CPython reports different error
message for different failures to subscript?
For example:
> > > set()[2]
Traceback (most recent call last):
File "", line 1, in
TypeError: 'set' object
On Thu, 24 Sep 2009 at 12:07, Nick Coghlan wrote:
Mark Dickinson wrote:
On Wed, Sep 23, 2009 at 4:54 PM, Dino Viehland wrote:
We are going to start contributing tests back real soon now. I'm not sure
that these are the best tests to contribute as they require a version of
Python to compare ag
that could run
KVM based stuff.
--David (R. David Murray)___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 prefix length in the intern
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
On Tue, 29 Sep 2009 at 14:19, Glyph Lefkowitz wrote:
In addition to the somebody-must-have-mentioned-this-already feeling that I
got, I hesitated to post this message because it doesn't actually seem that
important to me. While I'm firmly convinced that Network.ip is a design
mistake, it's not l
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.
On Wed, 30 Sep 2009 at 11:07, Nick Coghlan wrote:
At the risk of bikeshedding a bit, I'm still somewhat uncomfortable with
the "net.network" and "net.ip" attribute names. RDMs example application
elicited the reason for that discomfort pretty well: the current naming
seems like an invitation to w
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)
___
Python-Dev mai
On Wed, 30 Sep 2009 at 10:52, Paul Moore wrote:
2009/9/30 Mark Dickinson :
Please could someone who understands the uses of IPNetwork better than
I do explain why the following wouldn't be a significant problem, if __eq__
and __hash__ were modified to disregard the .ip attribute as suggested:
On Wed, 30 Sep 2009 at 13:11, Guido van Rossum wrote:
On Wed, Sep 30, 2009 at 4:33 AM, Mark Dickinson wrote:
On Wed, Sep 30, 2009 at 12:06 PM, Nick Coghlan wrote:
Mark Dickinson wrote:
Okay, so maybe this is an abuse of IPv4Network. ?But I'd (mis?)understood
that the retention of the .ip att
On Sat, 3 Oct 2009 at 17:08, Paul Moore wrote:
2009/10/3 Antoine Pitrou :
Steven Bethard gmail.com> writes:
? If %-formatting is to be deprecated, the transition strategy here
? is trivial. However, no one has yet written translators, and it is
? not clear what heuristics should be used, e.g.
On Tue, 13 Oct 2009 at 12:57, Barry Warsaw wrote:
On Oct 13, 2009, at 11:16 AM, Tarek Ziad? wrote:
I still need to do some more tests, I didn't have time to try the
various projects under win32.
It's planned to night.
The tests are consisting of compiling and insatling a dozain of
projects on l
On Tue, 20 Oct 2009 at 09:27, [email protected] wrote:
Shouldn't this be on python-ideas?
IMO this question is appropriate for python-dev, not python-ideas.
--David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/li
On Tue, 20 Oct 2009 at 09:55, [email protected] wrote:
On Oct 20, 2009, at 9:43 AM, Stefan Krah wrote:
[email protected] wrote:
> Shouldn't this be on python-ideas?
I found previous discussions about "Decimal in C" on python-dev, that's why
used this list.
python-ideas:
This list is to
On Thu, 22 Oct 2009 at 13:16, Tres Seaver wrote:
The fix for 5890 has a funny "smell" to me: copying __doc__ into the
instance dict just feels wrong. How does that work with a pure Python
class using slots? E.g.:
It doesn't. There's even a test to make sure it doesn't :)
(It raises an attrib
On Thu, 29 Oct 2009 at 19:41, Jesse Noller wrote:
Then again, I know for a fact certain tests fail ONLY on certain
buildbots because of the way they're configured. For example, certain
multiprocessing tests will fail if /dev/shm isn't accessible on Linux,
and several of the buildbosts are in tigh
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
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
On Fri, 30 Oct 2009 at 19:46, Paul Moore wrote:
2009/10/30 C. Titus Brown :
Once things are up and running, I'll be prepared to do basic care and
feeding of the buildslave, but as my time is limited, it would be nice
if others would pitch in to help.
I would be somewhat unhappy about giving mo
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
On Mon, 2 Nov 2009 at 22:06, Guido van Rossum wrote:
On Mon, Nov 2, 2009 at 9:51 PM, [email protected] wrote:
BeautifulSoup, which I use every day, is one such product. ?Since the crappy
old SMGL parser's gone, BeautifulSoup uses the one that's left in Python 3
and it makes BeautifulSoup comp
sion of python. And it
would prevent users from having to deal with them.
--
Bobby R. Ward
--
[email protected]
http://github.com/bobbyrward
http://launchpad.net/~bobbyrward
"While many languages can be used to encrypt data, PERL has something
built-in that g
The buildbot waterfall is much greener now. Thanks to all who have
contributed to making it so (and it hasn't just been Mark and Antoine
and I, though we've been the most directly active (and yes, Mark, you
did contribute several fixes!)).
The 'stable builders' fleet is green now except for:
On Sun, 8 Nov 2009 at 19:44, "Martin v. L?wis" wrote:
JFTR, I didn't set up the IRC bot (I assume that credit goes to Martin,
even if it's only one line in the buildbot config :). I just tried to
get it to say something :)
Yes, it was always "on". I don't use IRC regularly, so I don't know
whe
On Thu, 12 Nov 2009 at 15:42, Terry Reedy wrote:
Part of the pypi problem is a startup problem of initially low numbers. If
the only people who bother to log in to rate are the disgruntled, then the
ratings/reviews will be biased. I wonder how many of the people promoting the
new feature have t
On Sat, 14 Nov 2009 at 00:09, Antoine Pitrou wrote:
Martin v. L??wis v.loewis.de> writes:
The buildbots still show occasional oddities. For example, right now in
the page "http://www.python.org/dev/buildbot/3.x/";, some results have
disappeared (the columns for "AMD64 Ubuntu" builders have be
There are non-stable buildbots that are failing consistently, but this
message is about something else. Now that the biggest stability
issues have been addressed some less-noisy stability issues are visible.
The two that I have noticed most often are test_httpsservers, which
hangs occasionally, a
On Tue, 17 Nov 2009 at 10:31, Greg Hewgill wrote:
I've constructed an example program that does not leak memory in Python
2.x, but causes unbounded memory allocation in Python 3.1. Here is the
code:
import gc
import sys
class E(Exception):
def __init__(self, fn):
self.fn = fn
def c
On Wed, 09 Dec 2009 18:23:11 +0100, Lennart Regebro wrote:
> If the exception format has changed, I consider it a bug. Possibly a
> bug in doctest, as the only way to test for exceptions in that case is
> like this:
>
> >>> try:
> ... throw_an_exception()
> ... print "Did not t
On Fri, 11 Dec 2009 01:49:33 +0100, =?ISO-8859-1?Q?Tarek_Ziad=E9?=
wrote:
> On Fri, Dec 11, 2009 at 1:14 AM, Ben Finney
> wrote:
> > I don't see any information in the PEP for alternate proposals that were
> > made during its drafting. It's customary to explain what alternative
> > proposals ha
#x27;d also like to point out that IMO the idea behind the one-for-five offer
is to leverage the "I have an itch to scratch" energy to the benefit of
all and, just as important (and as Martin already pointed out), perhaps
set some new people on the path to b
>=, etc, operators,
so I think talking about changing the proposed syntax radically is
probably misplaced.
--
R. David Murray www.bitdance.com
Business Process Automation - Network/Server Management - Routers/Firewalls
On Wed, 06 Jan 2010 11:41:28 +, Chris Withers
wrote:
> Nick Coghlan wrote:
> > I'm pretty sure the bugs list is still the primary spooled notification
> > mechanism:
> > http://mail.python.org/mailman/listinfo/python-bugs-list
>
> That's what I was after, thanks!
Just for completeness, ther
le
if you grant him tracker privs.
Brian, I assume you'll be cognizant of Antoine's advice about making
sure a bug really should be closed before closing it :) Hanging out in
#python-dev on freenode while working on issues can be helpful, as well,
since you can quickly ask whoever is there
theory is that we close a lot of bugs fairly
promptly, but the ones in the above categories make the average age of
*open* issues high.
--
R. David Murray www.bitdance.com
Business Process Automation - Network/Server Management - Routers/Firewalls
(*) For
al.
By the way, you could talk to people who aren't going to be at the
summit on #python-dev; I think all the currently tracker-active people
hang out there on a regular basis.
I'll have to give some thought to what changes/improvements might be
most useful, now that I've been doi
the transition to python3. It could be that "use virtualenv"
is the best answer, but I feel we should think about it carefully to
make sure that is really true.
[1] http://bugs.python.org/issue2375
--
R. David Murray www.bitdance.com
Business Process
r operations you might otherwise perform at the shell command line using
OS facilities. As far as I can tell, archive_util does the same, and
seems quite within the shutil mission of "high level file operations".
So +1 from me for putting thes
ewly regenerated article
> numbers matched the originals. I'd highly recommend going through that
> painful process, since I suspect a *lot* of people have links to the
> python-dev archive. Hope you have a backup (or can find caches on
> google or archive.org or someth
ling `pyc` file
> exists, but its magic number does not match.
>
> In the default case, when Python finds a `pyc` file with a
> non-matching magic number, it simply overwrites the `pyc` file with
> the new byte code and magic number. In the absence of the `-R` flag,
> this remain
On Sat, 30 Jan 2010 20:37:32 -0800, Jeffrey Yasskin wrote:
> On Sat, Jan 30, 2010 at 8:22 PM, Vitor Bosshard wrote:
> > A trickier case: My GUI app offers scripting facilities. The
> > associated open file dialog hides all .pyc files, and users select
> > just from .py files. if subfolders are in
> > I don't know whether I in favour of using a single pyr folder or not
> > but if a single folder is used I'd definitely prefer the folder to be
> > called __pyr__ rather than .pyr.
>
> And to come complete with standard library functions to find
Python version. Or is something
missing from my understanding? If not, I think the motivation section
should address why the PEP is a better idea than improving the os
packaging systems as I've suggested. (The os vendors are going to have
to change details of their packaging systems if the
at
> need to be solved, and an explanation of why each individual solution
> has flaws, prepare for this conversation to take a few more weeks.
Well, I certainly don't want the conversation to take a few more months.
I'm not against the PEP, I'
601 - 700 of 1206 matches
Mail list logo
