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
anatoly techtonik writes:
> I do not know what are you intending to do, but my opinion that
> fund raising for patching library is a waste of money.
Of course it's not a waste of money. The need is real, so as long as
the PSF and other organizations (GSoC) choose reasonable projects/
people to
l...@rmi.net writes:
> I agree that 3.X isn't all bad, and I very much hope it succeeds. And
> no, I have no answers; I'm just reporting the perception from downwind.
The fact is, though, that many of your "downwind" readers are not the
audience for Python 3, not yet. If you want to do Pytho
Simon de Vlieger writes:
> As for the potentially harmful text on Python 3 which is included on
> the python-commandments website I do get the hint that it might not be
> clear enough that the text does not apply to people who are porting
> libraries.
It also doesn't apply to people wh
Steven D'Aprano writes:
> Frankly, I believe that pushing the meme that "Python 3 is different" is
> a strategic mistake.
I agree that it's strategically undesirable. Unfortunately, the
genuine backward incompatibility, as well as the huge mind-share
already garnered by what I consider wrong-
Antoine Pitrou writes:
> I think it's an unfortunate analogy.
Propose a better one, then. I'm definitely not wedded to the ones
I've proposed!
But we have a PR problem *now*. The loyal opposition clearly intend
to continue trash-talking Python 3 until the libraries get to 100% (or
a governmen
Laurens Van Houtven writes:
> > The only situation in which I'd direct someone new to programming
> > away from Python 3 would be if they had a specific need to use a
> > library that wasn't yet supported.
>
> Yeah, I think the reason for that rule is that the majority of people
> asking abo
Laurens Van Houtven writes:
> Also, I'm pretty sure nobody has ever said that Python 3.x was a
> "failure", or anything like it. #python has claims that Python 3.x, as
> a platform for building production apps, is a work in progress
How about "Python 3 is a work in progress" for the topic? Th
Pass the ketchup, I need to eat my words.
I wrote:
> The loyal opposition clearly intend to continue trash-talking
> Python 3 until the libraries get to 100% (or a government-approved
> approximation of 100%). The topic on #python seems unlikely to
> change at this point, with both Glyph and
Guido van Rossum writes:
> On the #python issue, I expect that IRC is much less influential that
> some here fear (and than some fervent IRC users believe). I don't see
> reason for panic or heavy-handed interference. OTOH engaging the
> channel operators more in python-dev sounds like a usefu
Robert Collins writes:
> Also, url's are bytestrings - by definition;
Eh? RFC 3896 explicitly says
A URI is an identifier consisting of a sequence of characters
matching the syntax rule named in Section 3.
(where the phrase "sequence of characters" appears in all ancestors I
found ba
Lennart Regebro writes:
> 2010/6/21 Stephen J. Turnbull :
> > IMO, the UI is right. "Something" like the above "ought" to work.
>
> Right. That said, many times when you want to do urlparse etc they
> might be binary, and you might want binary. So mayb
P.J. Eby writes:
> Note too that this is an argument for symmetry in wrapping the
> inputs and outputs, so that the code doesn't have to "know" what
> it's dealing with!
and
> After all, right now, if a stdlib function might return bytes or
> unicode depending on runtime conditions, I can'
Barry Warsaw writes:
> Would it make sense to have "encoding-carrying" bytes and str
> types?
Why limit that to bytes and str? Why not have all objects carry their
serializer/deserializer around with them?
I think the answer is "no", though, because (1) it would constitute an
attractive nuisa
Ben Finney writes:
> "Stephen J. Turnbull" writes:
>
> > your base URL is gonna be b'mailto:step...@xemacs.org', but the
> > natural thing the UI will want to do is
> >
> > formurl = baseurl + '?subject=うるさいやつだなぁ…'
>
"Martin v. Löwis" writes:
> Still, the question would be whether any of these failures can manage to
> block a release.
Exactly. Personally, I would say that in a volunteer-maintained
project, "Platform X is supported" means that "There is a bug that
seems to affect only Platform X" is a cand
Barry Warsaw writes:
> I'm still not sure ebytes solves the problem,
I don't see how it can. If you have an encoding to stuff into ebytes,
you could just convert to Unicode and guarantee that all internal
string operations will succeed. If you use ebytes instead, every
string operation has to
Toshio Kuratomi writes:
> One comment here -- you can also have uri's that aren't decodable into their
> true textual meaning using a single encoding.
>
> Apache will happily serve out uris that have utf-8, shift-jis, and
> euc-jp components inside of their path but the textual
> representa
Robert Collins writes:
> Perhaps you mean 3986 ? :)
Thank you for the correction.
> > A URI is an identifier consisting of a sequence of characters
> > matching the syntax rule named in Section 3.
> >
> > (where the phrase "sequence of characters" appears in all ancestors I
> > foun
P.J. Eby writes:
> In Kagoshima, you'd use pass in an ebytes with your encoding to a
> stdlib API, and *get back an ebytes with the right encoding*,
> rather than an (incorrect and useless) unicode object which has
> lost data you need.
How does the stdlib do that? Unless it guesses which en
Michael Urman writes:
> It is somewhat troublesome that there doesn't appear to be an obvious
> built-in idempotent-when-possible function that gives back the
> provided bytes/str,
If you want something idempotent, it's already the case that
bytes(b'abc') => b'abc'. What might be desirable is
P.J. Eby writes:
> I know, it's a hard thing to wrap one's head around, since on the
> surface it sounds like unicode is the programmer's savior.
I don't need to wrap my head around it. It's been deeply embedded,
point first, and the nasty barbs ensure that I have no desire to pull
it back out
Glyph Lefkowitz writes:
> On Jun 21, 2010, at 10:58 PM, Stephen J. Turnbull wrote:
> > Note also that the "complete solution" argument cuts both ways. Eg, a
> > "complete" solution should implement UTS 39 "confusables detection"[1]
>
Toshio Kuratomi writes:
> I'll definitely buy that. Would urljoin(b_base, b_subdir) => bytes and
> urljoin(u_base, u_subdir) => unicode be acceptable though?
Probably.
But it doesn't matter what I say, since Guido has defined that as
"polymorphism" and approved it in principle.
> (I think
Nick Coghlan writes:
> On Tue, Jun 22, 2010 at 4:49 PM, Stephen J. Turnbull
> wrote:
> > > Which works if and only if your outputs are truly unicode-able.
> >
> > With PEP 383, they always are, as long as you allow Unicode to be
> > decoded to the same
Ian Bicking writes:
> Just for perspective, I don't know if I've ever wanted to deal with a URL
> like that.
Ditto, I do many times a day for Japanese media sites and Wikipedia.
> I know how it is supposed to work, and I know what a browser does
> with that, but so many tools will clean that
James Y Knight writes:
> The surrogateescape method is a nice workaround for this, but I can't
> help thinking that it might've been better to just treat stuff as
> possibly-invalid-but-probably-utf8 byte-strings from input, through
> processing, to output.
This is the world we already
Guido van Rossum writes:
> For example: how we can make the suite of functions used for URL
> processing more polymorphic, so that each developer can choose for
> herself how URLs need to be treated in her application.
While you have come down on the side of polymorphism (as opposed to
separat
Guido van Rossum writes:
> On Thu, Jun 24, 2010 at 1:12 AM, Stephen J. Turnbull
> wrote:
> Understood, but both the majority of str/bytes methods and several
> existing APIs (e.g. many in the os module, like os.listdir()) do it
> this way.
Understood.
> Also, IMO a po
P.J. Eby writes:
> This doesn't have to be in the functions; it can be in the
> *types*. Mixed-type string operations have to do type checking and
> upcasting already, but if the protocol were open, you could make an
> encoded-bytes type that would handle the error checking.
Don't you rea
Ian Bicking writes:
> We've setup a system where we think of text as natively unicode, with
> encodings to put that unicode into a byte form. This is certainly
> appropriate in a lot of cases. But there's a significant class of problems
> where bytes are the native structure. Network protoc
P.J. Eby writes:
> I do know the ultimate target codec -- that's the point.
>
> IOW, I want to be able to do to all my operations by passing
> target-encoded strings to polymorphic functions.
IOW, you *do* have text and (ignoring efficiency issues) could just as
well use str. But That Other
Ian Bicking writes:
> I'm proposing these specials would be used in polymorphic functions, like
> the functions in urllib.parse. I would not personally use them in my own
> code (unless of course I was writing my own polymorphic functions).
>
> This also makes it less important that the obj
Ian Bicking writes:
> I don't get what you are arguing against. Are you worried that if
> we make URL code polymorphic that this will mean some code will
> treat URLs as bytes, and that code will be incompatible with URLs
> as text? No one is arguing we remove text support from any of
> the
P.J. Eby writes:
> it's just that if you already have the bytes, and all you want to
> do is tag them (e.g. the WSGI headers case), the extra encoding
> step seems pointless.
Well, I'll have to concede that unless and until I get involved in the
WSGI development effort.
> >But with your arch
Greg Ewing writes:
> Would there be any sanity in having an option to compile
> Python with UTF-8 as the internal string representation?
Losing Py_UNICODE as mentioned by Stefan Behnel (IIRC) is just the
beginning of the pain.
If Emacs's experience is any guide, the cost in speed and complexit
P.J. Eby writes:
> At 12:42 PM 6/26/2010 +0900, Stephen J. Turnbull wrote:
> >What I'm saying here is that if bytes are the signal of validity, and
> >the stdlib functions preserve validity, then it's better to have the
> >stdlib functions object to unicode da
Steve Holden writes:
> I agree - trying to step through -O2 optimized code isn't going to
> help debug your code, it's going to help you debug the
> optimizer. That's a very rare use case.
Not really. I don't have a lot of practice in debugging at that
level, so take it with a grain of salt,
"Martin v. Löwis" writes:
> It seems that both Dirkjan and Brett are very caught up
> with real life for the coming months. So I suggest that
> some other committer who favors the Mercurial transition
> steps forward and takes over this project.
I am not a committer, and am not intimately fam
anatoly techtonik writes:
> After reading PEP 384 and PEP 385 (finally) I got a strong impression
> that they are not ready for the change (read below the line for
> details), because they do not propose any workflow.
This was deliberate. There are a lot of different workflows, and we
are not
anatoly techtonik writes:
> Why this transition is not described in PEP?
Please reread the whole thread, and the PEP.
PEP 385 is *incomplete* (see the red Warning at the top), and the
original proponent *is not going to have enough time to complete it
soon*. That being the case, Martin suggest
Steve Holden writes:
> If the wave were to result in good documentation about how to *get*
> ready that would be an amazingly useful contribution.
I'm a coauthor of PEP 374 and of http://emacswiki.org/BzrForEmacsDevs.
I think that I can have a document adapted from the Python dev FAQ,
possibly
Brett Cannon writes:
> Mercurial has subrepo support, but that doesn't justify the need to
> have every module in its own repository so they can be checked out
> individually.
The point of submodules a la git is subtly different. It is that you
can mix and match *known versions* of the module
Jesse Noller writes:
> On Sat, Jul 3, 2010 at 7:05 AM, Dirkjan Ochtman wrote:
> > On Sat, Jul 3, 2010 at 12:53, Stephen J. Turnbull
> > wrote:
> >> The point of submodules a la git is subtly different. It is that you
> >> can mix and match *known vers
Georg Brandl writes:
> I wouldn't say that. strip works well and it does so logically,
> once one understands the DAG. The only thing discouraged is to strip
> changesets once pushed to the public repo, but that holds as well for
> getting rid of the changesets by making a new clone without
Antoine Pitrou writes:
> Which is the very wrong thing to do, though. License text should be
> understandable by non-lawyer people;
This is a common mistake, at least with respect to common-law systems.
Licenses are written in a formal language intended to have precise
semantics, especially in
Steven D'Aprano writes:
> On Tue, 6 Jul 2010 01:58:26 pm Stephen J. Turnbull wrote:
> > Licenses are written in a formal language intended to have
> > precise semantics, especially in the event of a dispute going to
> > court. What you wrote is precisely analog
LD 'Gus' Landis writes:
> Yes. The BSD license on FreeBSD has allowed Apple to
> make MacOS X a completely proprietary product.
That's simply not true.
http://www.opensource.apple.com/release/mac-os-x-1064/.
___
Python-Dev mailing list
Python-Dev@pytho
Greg Ewing writes:
> The use cases I had in mind for a 1-byte build are those for
> which the alternative would be keeping everything in bytes.
> Applications using a 1-byte build would need to be aware of
> the fact and take care to slice strings at valid places. If
> they were using bytes,
Antoine Pitrou writes:
> > http://selenic.com/hg/file/tip/mercurial/minirst.py
>
> Given that Mercurial is GPL, this is probably of no use to us,
> unfortunately.
Given that Martin apparently is the only or main author, I don't see a
problem as long as he's willing.
Martin?
__
Benjamin Peterson writes:
> 2010/7/7 Stephen J. Turnbull :
> > Antoine Pitrou writes:
> >
> > > > http://selenic.com/hg/file/tip/mercurial/minirst.py
> > >
> > > Given that Mercurial is GPL, this is probably of no use to us,
> > >
Steve Holden writes:
> That is _so_ Python 2 ;-)
High praise!
___
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.co
Antoine Pitrou writes:
> You don't have to receive e-mail from it. Just take a look at the
> archives from time to time after you have done some commits.
> In a threaded view, it's easy to spot the few messages which aren't
> commit notifications, since they are the only one not at the
> top-
Guilherme Polo writes:
> Adding tabs doesn't necessarily mean a single window, you should be
> able to continue using multiple windows with single tabs if that is
> your preference.
But it's very important to be able to *move* tabs across windows or
panes. For example, in XEmacs this is a som
Mark Lawrence writes:
> Is this the same login as for the issue tracker or is a new one needed?
It's different. Both trackers are supposed to support OpenID logins,
I believe. (However, there are somewhat frequent reports of
difficulties with it; I don't know if the system is fully debugged.
R. David Murray writes:
> During the most recent discussion I can remember, I thought I remembered
> Stephen Trumble saying that they'd tried that in xemacs and it really
> hadn't worked very well. Since he now says he thinks it's a good idea
> (or more likely I misremembered what he said the
Oleg Broytman writes:
> > Back on the topic, I don't think a drop-down list of all modules is
> > workable even in browsers that display them as combo boxes. How many
> > modules do we have in std lib? About 100? Maybe more. What if the
> > bug affects several modules? What if the patch mo
Alexander Belopolsky writes:
> On Wed, Jul 21, 2010 at 2:09 AM, Stephen J. Turnbull
> wrote:
> ..
> > > In this particular case I'd rather tend to agree - an editable
> > > single-line box to enter space-*and*-comma-separated modules list
&g
Greg Ewing writes:
> Scott McCarty wrote:
> > All, I have searched everywhere (mostly the code and a little google)
> > and I cannot understand where the SIGKILL signal gets checked when it is
> > set as a handler.
>
> Possibly it's not being checked at all by Python, but
> is being rejec
801 - 900 of 1495 matches
Mail list logo
