"Martin v. Löwis" writes:
> This is what I refer to as YAGNI. Subversion has LF as the internal
> storage, and, IIRC, so does CVS. I don't think there is any precedence
> for wanting something else - and frankly, I can't see how repository
> storage would matter.
Well, internally you could us
Dirkjan Ochtman writes:
> On 05/09/2009 16:59, Stephen J. Turnbull wrote:
> > git has a nice filter-branch command, which would allow you to
> > automatically repair the problem (it works basically by checking out
> > each changeset and rerecording it with the appr
Paul Moore writes:
> The result is that user workspaces *may* (quite probably, will)
> contain files with a mixture of line endings if care is not taken.
Yes. Under your "fixed-EOL-files-are-binary" scheme, this is
guaranteed for Unix systems.
> As regards (1), I assume that for "text" files
Antoine Pitrou writes:
> Speaking as a non-network specialist, it actually looks logical to
> me to be given an address if I iterate over a network (the same way
> that, if I iterate on a list, I get individual elements, not
> 1-element sublists).
But if you iterate over a string you get one
Scott Dial writes:
> ipaddr.IPv4Network('1.1.1.0/24')[0] == ipaddr.IPv4Network('1.1.1.0/24')
So foo returns True?
def foo():
a = ipaddr.IPv4Network('1.1.1.0/24')
return a[0] == a
That seems ... weird. Maybe you committed a typo?
___
Python
I haven't looked closedly at the reference implementation, and my
experience is small. So take this as "POLA to the naive new user of
the API" discussion.
Scott Dial writes:
> This example here solidifies my support of RDM's suggestion of there
> being 3 types:
>
> IPv4Address
> IP
Antoine Pitrou writes:
> > An IPv4Address with 'network' and 'mask' attributes that could be
> > None would also not complicate the API, IMO, and would handle both
> > of these use cases.
>
> But it would be confusing and conceptually bizarre, because an address (in
> usually accepted termi
Andrew McNamara writes:
> As the module stands, we have a pair of address-without-mask classes
> called *Address, and a pair of address-with-mask classes called
> *Network. So, sometimes when you want to record an *address* you use
> a class called Network, and that class comes with a behaviou
Andrew McNamara writes:
> Conceptually, you sometimes need a bare address, and other times,
> you need an address with an associated network (host interface
> configs, router configs, etc). By AddressWithMask, I really mean
> AddressWithEnoughInformationToDeriveNetworkWhenNeeded. Conveniently,
Antoine Pitrou writes:
> James Y Knight fuhm.net> writes:
> >
> > Why are you just making things up? There is a *vast* amount of
> > precedent for how file operations should work. Python should follow
> > that precedent and do like POSIX unless there's a compelling reason
> > not to.
Antoine Pitrou writes:
> I don't believe that POSIX compliance is a sufficient argument to ask
> someone to shut up in the discussion of a cross-platform API. Which is
> more or less what James' answer was trying to do.
No, as I read it, James said, "when there's precedent, even a
standard,
Brett Cannon writes:
> OK, stop before it gets any nastier as your email already sounds
> rude
Rude, yes, but not entirely lacking in truth. Tarek's post to Python-
Dev *is* a mess from the point of view of English and organization --
it's *way* below Tarek's normal command of the language. G
Tarek Ziadé writes:
> On Wed, Sep 23, 2009 at 9:03 AM, Stephen J. Turnbull
> wrote:
> > At the very least, that would have kept this discussion on Distutils-
> > SIG, and Chris couldn't be accused of trying to make an end run around
> > that process. I suggest
Antoine Pitrou writes:
> There was a proposal to have a separate parse_address_and_mask
> method which would return a (Address, Network) tuple, I still don't
> know why you don't seem to consider it seriously, rather than
> trying to make the Network class a kind of all-in-one type
> conflati
Guido van Rossum writes:
> I don't doubt that Peter has a use case for denormalized IPNetwork
> objects.
If you know what it is, would you please describe it, or say "that's
proprietary"? Peter hasn't done either, despite repeated requests.
> I do note that if Peter's use case is at all comm
Let me first say that the module is overall quite nice; the
implementation seems concise and very efficient, and the API is
well-balanced. I'm sorry there's been such controversy (and for my
part in it, as I managed to completely misunderstand what you
absolutely require), when AFAICT the only "li
Greg Ewing writes:
> Peter Moody wrote:
>
> > I've mentioned at least once (and others have mentioned as well) that
> > it's very common, when describing the ip address/prefix of a NIC to
> > write, "192.168.1.100/24"
>
> Yes, but if you want to *retain* all of that information,
> the obj
Peter Moody writes:
> > > this is interesting. I would be open to doing this and making __lt__,
> > > __gt__, __eq__ and friends do the non-ip comparing by default. would
> > > this be sufficient or does the fact that the network has the .ip
> > > attribute break something pythonic?
> >
Mark Dickinson writes:
> >> 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:
> > linus = IPv4Network('1
Daniel Stutzbach writes:
> People have voiced support for the IPNetwork class
The obvious use cases are
1. parsing and validating strings that purport to describe networks,
2. providing a received for the result of a function that deduces the
network from an arbitrary address and a mask
Nick Coghlan writes:
> However, while I'd still be a little happier if the .ip attribute
> went away all together and another means was found to conveniently
> associate an IPAddress and an IPNetwork, keeping it doesn't bother
> me anywhere near as much as having network equivalence defined in
Tarek Ziadé writes:
> Maybe I should blog a summary of the situation and post it to
> python annoucement as well.
Please don't. It's unlikely to do anything except incite a lot of
flames.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
Antoine Pitrou writes:
> Guido van Rossum python.org> writes:
> >
> > There are plenty of things we
> > can learn about fighting spam and other forms of vandalism from other
> > areas of the social web, including our very own wiki, and other wikis
> > (WikiPedia survives despite spam).
>
Brett Cannon writes:
> On Fri, Oct 9, 2009 at 11:32, Michael Foord wrote:
> > Sorry for top-posting, mobile device.
Michael, I for one *very much* appreciate your courtesy.
> Aahz was the most adamant hater of top-posting and he isn't subscribed to
> python-dev anymore, so whatever.
Please
Greg Ewing writes:
> That's no reason to squander it, though. Quoting the entire
> message every time makes the size of the thread grow as
> O(n**2),
Agreed, but let's not exaggerate. Threads are finite, so big O is not
really relevant. Spam OTOH is boundless, and that's where the
bandwidth
Ben Finney writes:
> "Stephen J. Turnbull" writes:
>
> > Trimming can be a PITA if you're using a crummy MUA
>
> How so? It merely requires the ability to navigate up and down by lines,
> and to select and delete text. I've used some very crumm
David Lyon writes:
> On Wed, 21 Oct 2009 18:38:26 -0700, Brett Cannon wrote:
> > David, you are making a huge leap here thinking that we even want
> > a package manager in the stdlib.
>
> Well - who is 'we'? If it's python-dev people I can accept and
> respect that.
Yes. The stdlib is a
Antoine Pitrou writes:
> Besides, the more keywords there are, the messier it is.
That's what I've found in the XEmacs tracker. Keywords are a
reasonable way (in the context of the Roundup implementation) to test
new classifications before going to the effort of messing with the
page templates.
Steven D'Aprano writes:
> I'm not being tongue-in-cheek or sarcastic. My question was serious --
> if there is a moratorium, is there any reason to bother submitting
> patches for functional changes to built-ins?
Yes. Python is open source. Private and public forks are possible
and (at lea
Ben Finney writes:
> Steven D'Aprano writes:
> > "get" is such a generic term that I don't believe that is a problem.
>
> The problem above is made less problematic by the fact that the function
> signature (e.g. 'foo_dict.get(key)') clarifies the answer to the
> question "get what?". Wher
"Martin v. Löwis" writes:
> > res.get() would be a fairly obvious way to do it. Enough that I would
> > probably never have gone searching for any of the other answers. Though
> > personally, I think I would call it "set.peek()", but the specific name
> > doesn't really matter to me.
>
> So
geremy condra writes:
> On Wed, Oct 28, 2009 at 12:34 PM, average wrote:
> > [I wrote:]
> >> If Python3 were to have this feature it would make it worth
> >> migrating to
> >
> > Sorry that may have sounded more harsh than I expected. If I had more
> > resources,
> This is effectively th
Steven D'Aprano writes:
> The usual technique people tend to come up with is:
>
> x = s.pop()
> s.add(x)
>
> Which strikes many people (including myself) as inelegant. Surely "get
> an element" is a more fundamental operation than "get an element and
> remove it"?
Not in a literal urn
Guido van Rossum writes:
> On Tue, Nov 3, 2009 at 11:23 AM, M.-A. Lemburg wrote:
> > One question:
> >
> > There are currently number of patch waiting on the tracker for
> > additional Unicode feature support and it's also likely that we'll
> > want to upgrade to a more recent Unicode versi
~b
<4222a8490911051521r1b9c8165id6e0f12d62da0...@mail.gmail.com>
<48c184130911051555r9a5b78cs3a13cb1345d3c...@mail.gmail.com>
<20091106001430.3229.796306500.divmod.xquotient@localhost.localdomain>
<4af3cf69.6090...@gmx.net>
<20091
anatoly techtonik writes:
> Does that mean even if authors of some imaginary editor agree to
> incorporate their code into Python, the framework that it is built
> upon will have to be incorporated into Python also (and eventually
> abandoned at original location)?
I would assume so. How els
Ben Finney writes:
> I would make a bug report for that, but the Python bug tracker also
> requires yet-another-identity. It's lunacy.
No, it's legacy. The software predates the availability of OpenID.
If you'd like to integrate Open ID authentication into Roundup, I will
personally be happy
David Lyon writes:
> I'm not star-gazing, because all these things are already
> needed and already being done to some degree in some
> organisations. There's already the libraries on pypi for
> most of this anyway.
Sure. But in a volunteer project, it's beg, buy, or build. Begging
has not
David Lyon writes:
> > I am just describing the needs and the end user PoV with the reference
> > implementation that happens to be used by *all* tools out there.
>
> That's good. That's what we need right now.
Martin's point is that the PEP process doesn't *have* "reference"
implementations
Ben Finney writes:
> Instead, the default should be `=='. That is, `Requires-Python: 3'
> should be equivalent to `Requires-Python: ==3'; and only "3" or "3.0" or
> "3.0.0" etc. will match. I maintain that is what most people will expect
> on seeing that syntax.
I really don't think your asse
david.l...@preisshare.net writes:
> >> Before we had : Requires-Python: 2.5, 2.6
> >>
> >> That made much more sense. It was simple and unambiguous, and is
> >> relevant to typical packaging scenarios.
> >
> > Unfortunately, it is fairly ambiguous, and makes no sense. It means
> > "requires
david.l...@preisshare.net writes:
> With respect, it's not a very common use case for a developer to
> say that package needs a python interpretor 'older' than 2.5.
Of course it is. I don't claim it is the majority of cases out there,
but stable versions of many of the packages I use will spec
Antoine Pitrou writes:
>
> > And in fact this case is often more the important one. Packages that
> > depend on having a *recent* version of python will often crash
> > quickly, before doing permanent damage, when an undefined syntax,
> > function, or method is invoked, while packages that d
Antoine Pitrou writes:
>
> > > How can they know that they depend on "a quirk in behaviour of an older
> > > version" if a newer version hasn't been released? This sounds bogus.
> >
> > Of course a newer version has been released. Who said it hasn't been?
> > Eg, the discussion of <=2.5.
Guido van Rossum writes:
> I'm a little hesitant about this. First of all, UTF-8 + BOM is crazy
> talk.
That doesn't stop many applications from doing it. Python should
perhaps not produce UTF-8 + BOM without a disclaimer of
indemnification against all resulting damage, signed in blood, from
t
Neil Schemenauer writes:
> On Sun, Jan 10, 2010 at 09:06:15PM -0800, Brett Cannon wrote:
> > If people start taking the carrots we have added to 3.x and
> > backporting them to keep the 2.x series alive you are essentially
> > making the 3.x DOA by negating its benefits which I personally
> >
Barry Warsaw writes:
> (Besides, git in the stdlib doesn't make much sense :).
"Dulwich."
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-d
Michael Foord writes:
> This is why I'm keen that by *default* Python should honour the UTF8
> signature when reading files;
Unfortunately, your caveat about "a lot of the time it will *seem* to
work" applies to this as well. The only way that "honoring
signatures" really works is if Python
Michael Foord writes:
> When reading text files the presence of the UTF-8 signature *almost
> invariably* means a UTF-8 encoding. Honouring this will almost always be
> better than using the wrong encoding. Of course there are caveats, but
> it will be a substantial improvement.
Sure, that
Antoine Pitrou writes:
> Perhaps you are speaking with your emacs hat, where the purpose is
> to output to the same file that serves as input.
No, I'm not wearing my Emacs hat. If I was, there would be no
problem. You just use binary for most such purposes. Historically
that was how even Ema
Antoine Pitrou writes:
> Stephen J. Turnbull xemacs.org> writes:
> >
> > But it *does* determine the charset of ErrorDocuments displayed by
> > Apache. Users are likely to get somewhat confused if the
> > ErrorDocuments are in a different charset from your
"Martin v. Löwis" writes:
> My bet is that the majority of Python applications written today do
> "web" stuff. In the web, input encoding and output encoding are
> fairly decorrelated - in particular for databases and files read
> from disk.
Sure. Which means that programmers have to do a lo
Josiah Carlson writes:
> Lisp lists are really stacks
No, they're really (ie, concretely) singly-linked lists.
Now, stacks are an abstract data type, and singly-linked lists provide
an efficient implementation of stacks. But that's not what linked
lists "really are". For example, singly-lin
Josiah Carlson writes:
> On Thu, Jan 28, 2010 at 8:57 PM, Steve Howell wrote:
> > What do you think of LISP, and "car" in particular (apart from
> > the stupidly cryptic name)?
> Apples and oranges.
True, but speaking of Lisp lists, here's some possibly relevant
experience. About 10 years
Josiah Carlson writes:
> On Fri, Jan 29, 2010 at 11:31 PM, Stephen J. Turnbull
> wrote:
> > Some people complained, but we considered this well worthwhile (moving
> > one "type bit" from the car to the header allowed Lisp integers to
> > cover the
Minor erratum:
Stephen J. Turnbull writes:
> Emacs hasn't made that choice, XEmacs did. I believe Emacs is still
> "restricted" to 128MB, or maybe 256MB, buffers. They recently had an
> opportunity to increase integer size, and thus maximum buffer size,
> but
Antoine Pitrou writes:
> Yes, I hindsight I think Guido was right.
Guido does too. One of the benefits of having a time machine is
getting to turn your hindsight into foresight.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
Antoine Pitrou writes:
> Besides, as Barry said, classifying a bug as blocker is also a good way
> to attract some attention on it. Other classifications, even "critical",
> don't have the same effect.
If done for the sole purpose of attracting attention, it's no
different from spam. Opinions
anatoly techtonik writes:
> Is it possible to make exploits out of crashers?
Depends on how you define "exploit". If your definition includes
denial of service, yes, crashing a server application would count.
Privilege escalation is harder to achieve. The general answer is
"yes", but each cas
Brett Cannon writes:
> I prefer the subject so that I can easily skim them to see if someone edited
> a file I really care about, but if that is not possible then the body is
> acceptable, especially if it is the first thing in the body (that would let
> me at least see some of it in the initi
Guido van Rossum writes:
> "Future" is a pretty standard CS term for this concept (as noted
> "promise" is another),
I like the term "promise" better. "Future" is very generic ("not now,
but later"), whereas a "promise" is something I don't get from you
now, but you will give me later.
The wi
exar...@twistedmatrix.com writes:
> The "explicit" futures on the wikipedia page seems to cover what is
> commonly referred to as a future. For example, Java's futures look like
> this.
>
> The "implicit" futures are what is generally called a promise. For
> example, E's promises look
Jeffrey Yasskin writes:
> It seems like a good idea to follow the choice other languages have
> used for the name (if they tend to agree)
For the record, I've conceded that point.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
Steven D'Aprano writes:
> As usual though, NANs are unintuitive:
>
> >>> d = {float('nan'): 1}
> >>> d[float('nan')] = 2
> >>> d
> {nan: 1, nan: 2}
>
>
> I suspect that's a feature, not a bug.
I don't see how it can be so. Aren't all of those entries garbage?
To compute a histogram o
Mark Dickinson writes:
> On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull
> wrote:
> > Steven D'Aprano writes:
> > > I suspect that's a feature, not a bug.
>
> Right: distinct nans (i.e., those with different id()) are treated as
> distin
Barry Warsaw writes:
> On Mar 24, 2010, at 11:06 PM, Nick Coghlan wrote:
>
> >Ah yes, the recollection of seeing such a message is now quite fresh in
> >my mind :)
>
> Just don't tell Guido I borrowed his time machine keys!
Wouldn't that be preferable to revealing you've learned to hotwire
Steven D'Aprano writes:
> But unlike us, the equality operator only has a pinhole view of the
> operands. It can't distinguish between your example and this:
>
> x = float('nan')
> y = some_complex_calculation(x)
> if x == y:
> ...
>
> where y merely happens to end up with the same
anatoly techtonik writes:
> I would vote for allowing student work on community infrastructure
> tasks. Tracker, Wiki, Web site management tools are all outdated and
> everybody who cares agrees that they've seen a better tools.
I've also seen *much* worse tools in actual use. You don't have
Amaury Forgeot d'Arc writes:
> I don't think so. Unicode 3.2 did contain two entries with large
> numeric values. The file Unihan-3.2.0.txt contains these two
> lines:
>
> U+4EAC kPrimaryNumeric 10,000,000,000,000,000 ten quadrillion
> (American)
> U+5793 kPrimaryNumeric 100,
R. David Murray writes:
> A long time ago (in a galaxy far far...no, wrong show)
>
> Er, as I was saying, a long time ago Barry applied a patch to
> email that went more or less like this:
>
> ndex: email/Encoders.py
> ===
>
Nick Coghlan writes:
> they're available? Or even a separate OS field with "Windows, Mac OS X,
> Linux, *BSD, Other" as the options?
XEmacs has a multilink field "platform". The default is "Any or all"
(mislabeled N/A), and values include hardware (currently x86, PPC,
other), OS (POSIX, Window
Bill Janssen writes:
> > Fink or MacPorts are often a practical necessity.
>
> Fink is deadly, MacPorts much more benign, in my experience. Which is
> several years out-of-date, before I realized I didn't need either one of
> them, and before the UNIX community started adding configure patc
Tobias Herp writes:
> (we use Python because it is convenient!),
Speak for yourself, I want no part of that "we". I use Python because
it's well defined and well documented and makes sense and provides
powerful operations and runs quickly enough in those applications
where I use it.
The fact t
Tres Seaver writes:
> I think there is a definite "unpriced externality" to keeping the
> process barriers high here.
The proposed trial period is not a high barrier, except to those who
really didn't want to being doing the work anyway. Note that There is
also an externality to having account
Lennart Regebro writes:
> I'd say there is something wrong with the process. If a trusted
> developer can't get somebody more privilege on the tracker by
> saying that "I trust this guy", then a new process is needed.
> That's it's too hard to get privileges in the Python development
> commun
Terry Reedy writes:
> As said above, the need to do this should be fixed. In the meantime, if
> people really care about having 'no selection' replaced by 'normal', I
> could do more. I have not bothered because I regard the two as synonyms
> and have not bothered.
Technically they're very
Steve Holden writes:
> Yes, in the last year in particular there has been some excellent effort
> of maintaining the issue tracker content. But the question still remains
> - who are we worried about offending?
In this thread, we did worry about offending Sean and dangerjim. Now
that Sean has
Lennart Regebro writes:
> On Mon, Apr 26, 2010 at 20:30, Antoine Pitrou wrote:
> > In an open source community, "merit" relates to that community.
> > We don't give Linus Torvalds all rights on the project just
> > because we know (or assume ;-)) he is tremendously competent.
>
> Well, tha
Lennart Regebro writes:
> > Sure, but that's still *work*, and it's work for *somebody else*.
>
> Yes, but only when the checkin was wrong. For all other checkins, it's
> *less* work. Hence, a committer needs to basically fudge up every
> second checkin to cause more work than he relieves wo
Steven D'Aprano writes:
> As I see it, the two camps are divided purely on the question of how to
> get increased privileges.
As I see it, the division is over what constitutes merit, and how it
is created or improved.
> Both sides agree that merit is a requirement, but the disagreement
> i
"Martin v. Löwis" writes:
>
> > When I open http://bugs.python.org/iss...@template=item
> > priority is (still) set at no selection. Is this my local cache (which I
> > do not know how to clear in FF) or is 'normal' filled in after submission?
>
> It is filled in after submission.
You stil
A.M. Kuchling writes:
> True. This makes me wonder if we should be data-mining the tracker
> information to look for significant contributors that no one has
> noticed.
It's an interesting idea. But I've done something similar to this, ad
hoc[1], a few times in XEmacs, and it has never worke
David Abrahams writes:
>
> This is a bug report. bugs.python.org seems to be down.
>
> >>> from urlparse import *
> >>> urlunsplit(urlsplit('git+file:///foo/bar/baz'))
> git+file:/foo/bar/baz
>
> Note the dropped slashes after the colon.
That's clearly wrong, but what does "+" ha
John Arbash Meinel writes:
> Stephen J. Turnbull wrote:
> > David Abrahams writes:
> > >
> > > This is a bug report. bugs.python.org seems to be down.
> > >
> > > >>> from urlparse import *
> > > >>> urlunsp
David Abrahams writes:
> At Sat, 08 May 2010 11:04:47 -0500,
> John Arbash Meinel wrote:
> > Don't you need to register the "git+file:///" url for urlparse to
> > properly split it?
>
> Yes. But the question is whether urlparse should really be so fragile
> that every hierarchical scheme
Senthil Kumaran writes:
> Not all urls have the 'authority' component after the scheme. (sip
> based urls for e.g) urlparse differentiates those by maintaining a
> list of scheme names which will follow the pattern of parsing, and
> joining for the urls which have a netloc (or authority compo
Senthil Kumaran writes:
> I should have said, 'treatment of urls with authority' and 'treatment
> of urls without authority' in terms of parsing and joining is as per
> RFC. How it is doing practically is by maintaining a list of urls
> with known scheme names which use_netloc.
Why do that i
Lie Ryan writes:
> it disappoints me this does not compare equal:
>
> add3 = lambda a, b, c: a + b + c
> a = partial(partial(add3, 1), 2)
> b = partial(partial(add3, 2), 1)
> print a == b
>
> :-)
But it's not even true for floating point.
___
P
Giampaolo Rodolà writes:
> >>> class A:
> ... def echo(self, x):
> ... return x
> ...
> >>> a = A()
> >>> a.echo()
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: echo() takes exactly 2 arguments (1 given)
> >>>
>
> I bet my last 2 cents this
Brian Quinlan writes:
> If you are familiar with threads then writing a "good enough" solution
> without futures probably won't take you very long. Also, unless you
> are familiar with another futures implementation, you aren't likely to
> know where to look.
That looks like an argument
Cameron Simpson writes:
> There's a lot to be said for a robust implementation of a well defined
> problem. Brian's module, had it been present and presuming it robust and
> debugged, would have been quite welcome.
That, of course, is the consensus view, both in general and with
respect to thi
Nick Coghlan writes:
> Those that say "just put it on PyPI"
Nobody is saying that, AFAICS. Nobody is saying that *some* futures
module shouldn't *eventually* go into the stdlib.
The question is whether *this* futures module should go into the
stdlib *now*. And it is clear that more time on Py
Nick Coghlan writes:
> On 26/05/10 13:51, Stephen J. Turnbull wrote:
> > People have been asking "what's special about this module, to violate
> > the BCP principle?" There's nothing special about the fact that
> > several people would use a &
Paul Moore writes:
> On 27 May 2010 00:11, geremy condra wrote:
> > I'm not clear, you seem to be arguing that there's a market for many
> > augmented python distributions but not one. Why not just have one
> > that includes the best from each domain?
>
> Because that's "bloat". You later a
Lennart Regebro writes:
> One worry with an official sumo distribution is that it could become
> an excuse for *not* putting something in the stdlib.
> Otherwise it's an interesting idea.
On the contrary, that is the meat of why it's an interesting idea.
I really don't think the proponents o
Lennart Regebro writes:
> If licensing is a problem I guess you'd need to have permission to
> relicense them all to the Python license,
Licensing compatibility is only a problem for copyleft, but most
copyleft licenses have "mere aggregation is not derivation" clauses.
Corporate concern about
Michael Foord writes:
> To my mind one of the most important benefits of a "sumo" style
> distribution is not just that it easily provides a whole bunch of useful
> modules - but that it *highlights* which modules are the community
> blessed "best of breed".
That has several problems.
(1)
Chris McDonough writes:
> It might be useful to copy the identifiers and URLs of all the backport
> request tickets into some other repository, or to create some unique
> state in roundup for these.
A keyword would do. Please don't add a status or something like that,
though.
__
Antoine Pitrou writes:
> In which cases is this true? Hex is rarely used for ASCII-encoding of
> binary data, precisely because its efficiency is poor.
MIME quoted-printable, URL-quoting, and XBM come to mind.
___
Python-Dev mailing list
Python-Dev@p
l...@rmi.net writes:
> FWIW, after rewriting Programming Python for 3.1, 3.x still feels
> a lot like a beta to me, almost 2 years after its release.
Email, of course, is a big wart. But guess what? Python 2's email
module doesn't actually work! Sure, the program runs most of the
time, but e
801 - 900 of 1553 matches
Mail list logo
