On Mon, 17 May 2010 10:11:03 PDT
Bill Janssen wrote:
>
> I'd hate to let a fundamental flaw like this go through simply because
> someone somewhere somewhen set a completely synthetic deadline.
[...]
> I've read through that issue (several times), and I have to say that I
> wind up gnashing my te
On Mon, 17 May 2010 11:15:49 PDT
Bill Janssen wrote:
>
> What I did know was that
> some of our big complicated Python multi-threaded daemons had shown
> puzzling resource hogging when moved from small Macs to large 8-core
> machines with hardware RAID and lots of memory.
Could you give detailed
Le lundi 17 mai 2010 à 14:36 -0700, Bill Janssen a écrit :
>
> Could the macro that releases the GIL also release the thread affinity?
We release the GIL in a variety of situations which don't necessarily
involve heavy computations (such as: waiting for IO or sleeping).
Furthermore, having severa
On Tue, 18 May 2010 08:45:41 +0200
Lennart Regebro wrote:
> >>
> >> Are you referring to the "New GIL"?
> >
> > Yes.
>
> At has been shown, it also in certain cases will race with the OS
> scheduler, so this is not already fixed, although apparently improved,
> if I understand correctly.
"Race"
Le mardi 18 mai 2010 à 14:16 +0200, Lennart Regebro a écrit :
> > Please read and understand the issue report mentioned by Nir before
> > trying to make statements based on rumours heard here and there.
>
> Oh, so Dave Beazleys reports is a rumour now.
Your and other people's grandiloquent inter
On Tue, 18 May 2010 14:39:43 -0700
Mike Klaas wrote:
> On Sun, May 16, 2010 at 1:07 PM, Nir Aides wrote:
>
> > Relevant Python issue: http://bugs.python.org/issue7946
>
> Is there any chance Antoine's "gilinter" patch from that issue might
> be applied to python 2.7? I have been experiencing r
On Tue, 18 May 2010 21:43:30 +0200
"Martin v. Löwis" wrote:
>
> I can understand why Antoine is being offended: it's his implementation
> that you attacked. You literally said "At has been shown, it also in
> certain cases will race with the OS scheduler, so this is not already
> fixed", claiming
On Tue, 18 May 2010 17:26:44 -0700
Mike Klaas wrote:
>
> > I think your "rare long delays" might be related to the old GIL's own
> > problems, though. How long are they?
>
> Typically between 20 and 60s.
You mean milliseconds I suppose?
If it's the case, then you may simply be witnessing garbag
Hello,
I would like to check that it's possible to a new C API function in the
2.6 branch, on the basis that it would help solve what seems to be
reported as a security problem by several vendors (including Linux
distributions) -- see http://bugs.python.org/issue5753 for a thorough
discussion.
T
On Sun, 23 May 2010 12:43:57 +0200
Dirkjan Ochtman wrote:
>
> In general, this reminds me of the ipaddr discussions. I read through
> the thread from March real quick to see if there was reasoning there
> why this package should be an exception from the "normal" standards
> track (that is, ripen
On Sun, 23 May 2010 08:34:22 -0400
Jesse Noller wrote:
>
> Brian has already agreed to name spacing it to "concurrent.futures" -
> this means it will be a small part to a much larger concurrent.*
> implementation ala Java.
What I would question here is what other things will be part
of the "conc
On Sun, 23 May 2010 20:52:19 -0700
Steven Bethard wrote:
> I have a few feature
> requests, etc. for argparse, and I was planning to just copy them over
> to the Python bug tracker (and close them on the Google code tracker).
Yes, I think this is desireable. You should also maintain argparse
dire
On Wed, 26 May 2010 09:54:13 +1000
Nick Coghlan wrote:
> >
> > What I would question here is what other things will be part
> > of the "concurrent" package, and who will implement them. Are there
> > plans for that? (or even tracker issues open?)
>
> I'm not sure it is called out explicitly in th
On Wed, 26 May 2010 04:25:18 -0400
Glyph Lefkowitz wrote:
>
> In other words, while I kinda-sorta buy Brian's argument that having this
> module in easy reach
> will motivate more people to use a standard, tested idiom for
> parallelization, I *don't* think
> that the stdlib should be expanded
On Wed, 26 May 2010 20:42:12 +1000
Steven D'Aprano wrote:
>
> I'm not saying that Python-Dev should bend over backwards to accommodate
> such people to the exclusion of all else, but these folks are
> stakeholders too, and their wants and needs are just as worthy as the
> wants and needs of th
Le mercredi 26 mai 2010 à 13:19 +0100, Paul Moore a écrit :
>
> I'm not sure how a "Sumo" approach would work in practical terms, and
> this thread isn't really the place to discuss, but there's a couple of
> points I think are worth making:
>
> * For a "Sumo" distribution to make sense, some rel
On Wed, 26 May 2010 22:32:33 +1000
Nick Coghlan wrote:
> >
> > Ha, I'm a bit surprised. Isn't it what "futures" already provides?
> > (except that for some reason it insists on the "SomeExecutor" naming
> > scheme)
> > http://www.python.org/dev/peps/pep-3148/#processpoolexecutor
>
> Not really -
Le mercredi 26 mai 2010 à 23:41 +0100, Paul Moore a écrit :
>
> But a general
> purpose "Sumo" distribution *on top of* the stdlib? I'm skeptical.
> (Personally, my "essential extras" are pywin32, cx_Oracle and that's
> about it - futures might make it if it doesn't get into the stdlib,
> but that
On Thu, 27 May 2010 10:19:50 +1000
Nick Coghlan wrote:
>
> futures.ThreadPoolExecutor would likely be refactored to inherit from
> the mooted pool.ThreadPool.
There still doesn't seem to be reason to have two different thread pool
APIs, though. Shouldn't there be one obvious way to do it?
> I'
On Thu, 27 May 2010 14:29:28 +1200
Greg Ewing wrote:
> On 27/05/10 01:48, Nick Coghlan wrote:
>
> > I would say it is precisely that extra configurability which separates
> > the executor pools in the PEP implementation from more flexible general
> > purpose pools.
>
> Wouldn't this be better ad
On Fri, 28 May 2010 02:05:14 +1000
Nick Coghlan wrote:
>
> Executors and thread pools are not the same thing.
>
> I might create a thread pool for *anything*. An executor will always
> have a specific execution model associated with it (whether it be called
> futures, as in this case, or runna
On Thu, 27 May 2010 21:57:48 -0400
Reid Kleckner wrote:
>
> Unrelatedly, I feel like this behavior of waiting for the thread to
> terminate usually manifests as deadlocks when the main thread throws
> an uncaught exception. The application then no longer responds
> properly to interrupts, since
On Fri, 28 May 2010 20:31:02 -0400
Steve Holden wrote:
> I think it shows how developers can "get worked over" if they are
> insufficiently vigilant.
>
> 1) I completely agree, and adduce as evidence the fact that something
> like this always seems to happen when the rule is broken;
Well it's tr
On Wed, 09 Jun 2010 10:41:29 +0200
"M.-A. Lemburg" wrote:
>
> The above example will read:
>
> >>> b'abc'.transform("hex")
> b'616263'
> >>> b'616263'.untranform("hex")
> b'abc'
This doesn't look right to me. Hex-encoded "data" is really text (it's
a textual representation of bi
Le mercredi 09 juin 2010 à 12:38 +0100, Michael Foord a écrit :
> On 09/06/2010 12:35, Antoine Pitrou wrote:
> > On Wed, 09 Jun 2010 10:41:29 +0200
> > "M.-A. Lemburg" wrote:
> >
> >> The above example will read:
> >>
> >> >>
On Wed, 9 Jun 2010 13:57:05 +0200
Dirkjan Ochtman wrote:
> On Wed, Jun 9, 2010 at 13:40, Antoine Pitrou wrote:
> > No, I don't think so. If I'm using hex "encoding", it's because I want
> > to see a text representation of some arbitrary bytestring (in orde
On Wed, 09 Jun 2010 15:45:55 -0400
Terry Reedy wrote:
> On 6/9/2010 8:17 AM, Antoine Pitrou wrote:
> > On Wed, 9 Jun 2010 13:57:05 +0200
> > Dirkjan Ochtman wrote:
> >> On Wed, Jun 9, 2010 at 13:40, Antoine Pitrou wrote:
> >>> No, I don't think so. If
On Wed, 09 Jun 2010 22:13:28 +0200
"Martin v. Löwis" wrote:
> py> binascii.b2a_base64(b'foo')
> b'Zm9v\n'
> py> binascii.b2a_hex(b'foo')
> b'666f6f'
>
> Now, I'd admit that "b2a" may be a misnomer (binary -> ASCII), but then
> it may not because ASCII actually *also* implies "bytes" (it's an enco
On Sat, 19 Jun 2010 20:34:41 +0900
"Stephen J. Turnbull" wrote:
>
> And even now
> implementation is hanging up on the requirement that it not affect
> Windows-based developers adversely ... and it turns out that even
> being Python-based is nowhere near enough to guarantee that, but
> rather it
On Sat, 19 Jun 2010 17:43:02 +0530
Senthil Kumaran wrote:
> On Sat, Jun 19, 2010 at 01:51:04PM +0200, Antoine Pitrou wrote:
> > FWIW, the EOL extension is now part of Mercurial:
> > http://mercurial.selenic.com/wiki/EolExtension
>
> Should we all move soon now?
> Any
On Sat, 19 Jun 2010 11:14:51 -0400
Arc Riley wrote:
> python-commandments.org is owned and hosted by the same person (Allen Short
> aka dash aka washort) as pound-python.org which is the "official" website
> for #Python and which links to it.
>
> #Python is co-managed by Stephen Thorne (aka Jerub
On Sun, 20 Jun 2010 12:05:46 +1000
Steven D'Aprano wrote:
> On Sun, 20 Jun 2010 12:13:34 am Tres Seaver wrote:
>
> > > I guess tutorial welcome, rather than patch welcome then ;)
> >
> > The only folks who can write the tutorial are the ones who have
> > already drunk the koolaid. Note that I've
On Sun, 20 Jun 2010 18:14:02 +0900
"Stephen J. Turnbull" wrote:
>
> > had my experience would have been different. It's bad enough to have to
> > tell people "Python 3 is currently lacking some critical libraries,
> > particularly third-party libraries" without also telling them (wrongly
>
On Sun, 20 Jun 2010 13:33:35 +0200
Laurens Van Houtven wrote:
>
> (One of the problems people I've talked to in private that were
> "pretty miffed" about is the dissonance between #python and
> python-dev, and that there's some problem with people assuming things
> said on #python as being very a
On Mon, 21 Jun 2010 01:00:03 +0900
Steve Holden wrote:
>
> Given the amount of interest this thread has generated I can't help
> wondering why it isn't more prominent in python.org content. Is the
> developer community completely disjoint with the web content editor
> community?
Sorry for a naiv
On Mon, 21 Jun 2010 02:30:17 +0900
"Stephen J. Turnbull" wrote:
> 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!
I'm not sure why you
On Sun, 20 Jun 2010 14:26:28 +0200
Giampaolo Rodolà wrote:
> I attempted to port pyftpdlib to python 3 several times and the
> biggest show stopper has always been the bytes / string difference
> introduced by Python 3 which forces you to *know* and *use* Unicode
> every time you deal with some te
On Sun, 20 Jun 2010 14:40:56 -0400
"P.J. Eby" wrote:
>
> Actually, I would say that it's more that (in the network protocol
> case) we *have* bytes, some of which we would like to *treat* as
> text, yet do not wish to constantly convert back and forth to
> full-blown unicode
Well, then why do
On Mon, 21 Jun 2010 10:56:59 PDT
Bill Janssen wrote:
> Considering that we've just released 2.7rc2, there are an awful lot of
> red buildbots for 2.7. In fact, I don't remember having seen a green
> buildbot for OS X and 2.7. Shouldn't these be fixed?
>
> On OS X Leopard, I'm seeing failures in
On Mon, 21 Jun 2010 12:13:05 PDT
Bill Janssen wrote:
>
> > > On OS X Leopard, I'm seeing failures in test_py3kwarn,
> > > test_urllib2_localnet, test_uuid.
> > >
> > > On OS X Tiger, I'm seeing failures in test_pep277, test_py3kwarn,
> > > test_ttk_guionly, and test_urllib2_localnet.
>
> Um -- s
Le lundi 21 juin 2010 à 12:57 -0700, Bill Janssen a écrit :
>
> > Apparently some of these buildbots belong to you. Why don't you step
> > up and investigate?
>
> The fact that I'm running some buildbots doesn't mean I have to fix the
> problems that they reveal, I think.
You certainly don't have
Le lundi 21 juin 2010 à 21:13 +0100, Michael Foord a écrit :
>
> If OS X is a supported and important platform for Python then fixing all
> problems that it reveals (or being willing to) should definitely not be
> a pre-requisite of providing a buildbot (which is already a service to
> the Pyth
On Wed, 23 Jun 2010 14:23:33 -0400
Tres Seaver wrote:
>
> Perhaps such decisions need revisiting in light of subsequent experience
> / pain / learning. E.g:
>
> - - the repeated inability of the web-sig to converge on appropriate
> semantics for a Python3-compatible version of the WSGI spec;
On Wed, 23 Jun 2010 17:30:22 -0400
Toshio Kuratomi wrote:
> Note that this assumption seems optimistic to me. I started talking to Graham
> Dumpleton, author of mod_wsgi a couple years back because mod_wsgi and paste
> do decoding of bytes to unicode at different layers which caused problems
> fo
On Thu, 24 Jun 2010 20:07:41 +0100
Michael Foord wrote:
>
> Although it would require changes for builtin types like file to work
> with a new string ABC, right?
There is no builtin file type in 3.x.
Besides, it is not an ABC-level problem; the IO layer is written in C
(although there's still t
On Sat, 26 Jun 2010 14:29:24 +0100
Michael Foord wrote:
>
> the introduction of
> free-threading in Python has not been hampered by lack of
> synchronization primitives but by the difficulty of changing the
> interpreter without unduly impacting single threaded code.
Exactly what I think too.
On Sat, 26 Jun 2010 23:49:11 -0400
"P.J. Eby" wrote:
>
> Remember, bytes and strings already have to detect mixed-type
> operations.
Not in Python 3. They just raise a TypeError on bad
("mixed-type") arguments.
Regards
Antoine.
___
Python-Dev mail
On Sun, 27 Jun 2010 10:47:08 -0400
Alexander Belopolsky wrote:
>
> I have a patch for pybench attached to a not so related issue at
> http://bugs.python.org/issue5180 . All it took was a 2to3 run and a
> one line change. Of course it need a review before it can go in, but
> I am surprised that
On Tue, 29 Jun 2010 11:40:50 -0400
Steve Holden wrote:
> Sure. I attach the outputs of both files, as well as the program and the
> data. With profiling (python -m cProfile test3.py) the run took less
> than a third of a second under 2.5, and 168 seconds under 3.1. I'd say
> that was problematical
On Tue, 29 Jun 2010 12:52:28 -0400
"A.M. Kuchling" wrote:
>
> But should mailboxes really be opened in a UTF-8 encoding, or should
> they be treated as 7-bit text? I'll have to think about this.
I don't see how you can assume UTF-8 for mailbox files, given that each
message will have its partic
On Tue, 29 Jun 2010 20:05:29 -0400
"R. David Murray" wrote:
>
> I would imagine Guido is talking about an io.TextIOWrapper...in other
> words, take the binary file you've just finished grabbing info
> from, and reread it as a text file in order to grab the actual
> message content.
This sounds a
On Wed, 30 Jun 2010 09:00:09 PDT
Bill Janssen wrote:
>
> So, my question then is, why are these skips "unexpected"? Seems to me
> that if this is the case, this test will never run on any platform.
You can change the value of the "usepty" option in your buildbot.tac.
(you will also have to rest
On Wed, 30 Jun 2010 10:03:49 -0700
Guido van Rossum wrote:
>
> > Also, please note that values used by seek() and tell() on
> > text I/O are "opaque cookies". While they can happen to match the
> > raw binary file position, it is a mere coincidence (or an
> > implementation detail, at your will).
On Thu, 1 Jul 2010 15:26:12 -0700
Brett Cannon wrote:
>
> As I said, quick-and-dirty. It will take discussion to decide what we
> want to ask non-committers to do,
I don't think we have to ask them to do anything special, as long as
they can submit their contributions under the form of a patch.
On Fri, 2 Jul 2010 15:22:44 +0300
anatoly techtonik wrote:
> On Fri, Jul 2, 2010 at 3:02 PM, Éric Araujo wrote:
> > hg.python.org/cpython is a test setup for people working on the
> > transition. It is not guaranteed to be usable, it usually lags, and it
> > will be rewritten before the real swit
On Fri, 2 Jul 2010 09:09:48 -0400
Fred Drake wrote:
> On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou wrote:
> > The two sets of repositories use different conversion tools and rules.
> > They have nothing in common (different changeset IDs, different
> > metadata, differen
On Fri, 2 Jul 2010 17:29:02 +0300
anatoly techtonik wrote:
> To shed some light on the readiness of Python community for the switch
> I've opened public Google Wave. Please add your opinion if you can and
> send this link to other contributors you may know:
Am I the only one to think this should
On Fri, 02 Jul 2010 12:55:56 -0400
Steve Holden wrote:
> Fred Drake wrote:
> > On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou wrote:
> >> The two sets of repositories use different conversion tools and rules.
> >> They have nothing in common (different changeset I
On Sat, 3 Jul 2010 11:17:16 +0100
Mark Dickinson wrote:
> On Sat, Jul 3, 2010 at 4:28 AM, Benjamin Peterson wrote:
> > This is just a note that we have one bug blocking 2.7 final at the
> > moment: http://bugs.python.org/issue9144
>
> I've just made http://bugs.python.org/issue7673 a release blo
On Sat, 3 Jul 2010 14:40:57 +0200
Victor Stinner wrote:
> Le samedi 03 juillet 2010 14:26:53, Victor Stinner a écrit :
> > In the worst case, a function rejects valid data. If I have to choose, I
> > prefer to reject valid data than a security vulnerability. But audioop has
> > tests and I don't t
On Sat, 03 Jul 2010 14:16:08 -0400
Terry Reedy wrote:
>
> This is perhaps a naive question, but hat do you gain with the
> intermediate mirror clone of upstream? (Other than filling more of your
> disk?)
Filling less of your disk, actually, since local clones use hardlinks.
Also, pulling less
On Sun, 04 Jul 2010 00:51:58 +0200
"Martin v. Löwis" wrote:
> >>> I'd love to see a more detailed description of this, including why
> >>> someone new to Mercurial would choose one over the other.
> >
> >> I think someone new to Mercurial shouldn't choose either one.
> >
> >> Just sit back and w
On Sun, 4 Jul 2010 10:34:57 -0500
Benjamin Peterson wrote:
> On behalf of the Python development team, I'm jocund to announce the second
> release candidate of Python 2.7.
>
> Python 2.7 will be the last major version in the 2.x series. However, it will
> also have an extended period of bugfix m
On Tue, 6 Jul 2010 07:05:58 +1000
Nick Coghlan wrote:
>
> As Brett noted, yes, the LICENSE file is complicated, but most people
> don't bother reading it themselves - they ask what FSF and OSI think
> of it, and get the answers "BSD style" and "GPL compatible" and are
> happy with that.
Which is
Le mardi 06 juillet 2010 à 12:58 +0900, Stephen J. Turnbull a écrit :
> 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 respe
On Wed, 07 Jul 2010 11:13:09 +0200
"M.-A. Lemburg" wrote:
>
> And finally: RAM is cheap and today's CPUs work better with 16- or
> 32-bit values than 8-bit characters.
The latter is wrong. There is no cost in accessing bytes
rather than words on modern CPUs.
(actually, bytes are cheaper overall
On Tue, 06 Jul 2010 19:18:09 -0400
Terry Reedy wrote:
>
> Version A: Modify the heuristic to only eliminate common items when
> there are more than, say, 100 items (when len(b2j)> 100 where b2j is
> first calculated without popularity deletions).
[...]
>
> Version B: add a parameter to .__init
On Wed, 7 Jul 2010 19:44:31 +0200
Eli Bendersky wrote:
>
> For what it's worth, my benchmarking showed that modifying the
> heuristic to only kick in when there are more than 100 kinds of
> elements (Terry's option A) didn't affect the runtime of matching
> whatsoever, even when the heuristic *do
On Wed, 07 Jul 2010 16:39:38 +0100
Michael Foord wrote:
> On 07/07/2010 16:29, Alexander Belopolsky wrote:
> > [snip...]
> >
> >> 4. Does not ctypes make it possible to replace a method of a Python-coded
> >> class with a faster C version, with something like
> >> try:
> >> connect to method
On Wed, 7 Jul 2010 14:12:17 -0400
Barry Warsaw wrote:
> On Jul 07, 2010, at 07:30 PM, Georg Brandl wrote:
>
> >Overall, I think that we can make stdlib docstrings valid reST -- even
> >if it's reST without much markup -- but valid, so that people pulling
> >in stdlib doc- strings into Sphinx docs
On Wed, 07 Jul 2010 22:58:47 +0200
Martin Geisler wrote:
> "C. Titus Brown" writes:
>
> > I guess docutils isn't in the stdlib (should it be?) or else we could
> > modify 'help' to use it to prepare a straight text formatting.
>
> We're using light-weight ReST markup in the Mercurial help text
On Wed, 07 Jul 2010 21:04:17 -0400
Terry Reedy wrote:
>
> In other words, I see three options for 2.7.1+:
[...]
I don't think 2.7 should get any change at all here. Only 3.2 should be
modified. As Tim said, difflib works ok for its intended use (regular
text diffs). Making it work for other uses
On Wed, 07 Jul 2010 21:45:30 -0400
Terry Reedy wrote:
>
> > Except that ctypes doesn't help provide C extensions at all. It only
> > helps provide wrappers around existing C libraries, which is quite a
> > different thing.
> > Which, in the end, makes the original suggestion meaningless.
>
> To
On Fri, 9 Jul 2010 00:59:02 +1000
Nick Coghlan wrote:
> py_module_tests = support.import_fresh_module('moduletester',
> fresh=['modulename'], blocked=['_modulename'])
> c_module_tests = support.import_fresh_module('moduletester',
> fresh=['modulename', '_modulename'])
I don't really like the prol
On Thu, 08 Jul 2010 20:52:44 +0100
MRAB wrote:
>
> I'd be interested in any comments or feedback. How does it compare with
> "re" in terms of speed on real-world data? The benchmarks suggest it
> should be faster, or at worst comparable.
Can you publish these benchmarks somewhere?
(or send them
On Fri, 9 Jul 2010 08:38:53 +
Kristján Valur Jónsson wrote:
>
> In short, what the documentation fails to mention (and the pep) is whether
> posessing a
> locked Py_Buffer structure also constitutes holding a reference to the
> exporting object?
It does.
> I think it does, but is this gu
On Sat, 10 Jul 2010 18:04:32 +1000
Nick Coghlan wrote:
> With the trunk closed to new development, should we switch
> http://docs.python.org/dev/ to show the docs built from the Py3k
> branch?
Well, that page already says “Python v3.2a0 documentation” to me.
cheers
Antoine.
_
On Sat, 10 Jul 2010 21:33:28 -0400
Terry Reedy wrote:
>
> The problem here, it seems to me, is that all issues are autoassigned to
> an inactive person (KBK) who does not really accept them except once a
> year or so. I do not know whether all other commiter are unwilling to
> commit IDLE issu
On Sun, 11 Jul 2010 13:23:13 +
Reid Kleckner wrote:
>
> I'm also expecting to be doing more work merging unladen-swallow into
> the py3k-jit branch, so I was wondering if I could get commit
> privileges for that.
It sounds good to me. Also, thanks for your threading patches!
Regards
Antoin
On Sun, 11 Jul 2010 14:59:14 -0400
Glyph Lefkowitz wrote:
>
> Guido proposes to give someone interested in IDLE commit access, and
> hopefully that will help in > this particular area. But, as I recall, at the
> last language summit there was quite a bit of
> discussion about how to address th
On Mon, 12 Jul 2010 05:20:49 -0400
"Kurt B. Kaiser" wrote:
>
> I'm mystified about the comments that the GUI is ugly. It is minimal.
> On XP, it looks exactly like an XP window with a simple menubar. Those
> who haven't looked at it for awhile may not be aware of the recent
> advances made by T
After a few keystrokes in the interactive interpreter, I got the
following traceback:
Traceback (most recent call last):
File "Lib/idlelib/idle.py", line 11, in
idlelib.PyShell.main()
File "/home/antoine/py3k/__svn__/Lib/idlelib/PyShell.py", line 1420,
in main
root.mainloop()
File
On Mon, 12 Jul 2010 08:12:10 -0400
"Kurt B. Kaiser" wrote:
> >
> > Ok, I've just tried IDLE (on py3k) for the first time in years. Under
> > Linux, the look is ugly and outdated; it uses some kind of Motif-like
> > widgets.
>
> That's because Linux isn't using Tk 8.5 yet. Debian defaults to Tk 8
On Mon, 12 Jul 2010 00:36:33 +0200
"Martin v. Löwis" wrote:
> > I think Martin has always supported me in some way and I really
> > appreciate that. But, maybe because I won commit privileges solely
> > based on GSoC work, I felt other developers wouldn't approve my
> > commits without previous di
On Mon, 12 Jul 2010 16:18:38 +0100
Michael Foord wrote:
> On 12/07/2010 15:07, Nick Coghlan wrote:
> > On Mon, Jul 12, 2010 at 9:42 AM, Steven D'Aprano
> > wrote:
> >
> >> On Sun, 11 Jul 2010 09:37:22 pm Eric Smith wrote:
> >>
> re2 comparison is interesting from the point of if i
On Mon, 12 Jul 2010 11:23:04 -0400
"Kurt B. Kaiser" wrote:
>
> What distro are you using? Tk8.6 is still in beta.
It's Mandriva 2010.1
> Still looks crummy? Bummer.
Yes.
> Fine, I showed it as an example of the improvement in 8.5. Most people,
> I think, are using Windows or Macs. Looks d
On Mon, 12 Jul 2010 17:47:31 -0400
Fred Drake wrote:
> On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord
> wrote:
> > I'm sure Brett will love this idea, but if it was impossible to reimport the
> > script being executed as __main__ with a different name it would solve these
> > problems.
>
> Inde
Le lundi 12 juillet 2010 à 23:04 +0100, Michael Foord a écrit :
> Given how high traffic python-checkins is I don't consider that a
> reasonable place to send follow-up and nor do I consider it the
> responsibility of committers to monitor it.
You don't have to receive e-mail from it. Just take
On Mon, 12 Jul 2010 19:08:07 -0400
Terry Reedy wrote:
> On 7/12/2010 2:05 AM, "Martin v. Löwis" wrote:
> >> What I specifically want right now is Commit Authorization Privilege,
> >> especially for IDLE,
> >
> > Not sure who could grant that, but as far as I can: you have it.
>
> If I were approv
On Tue, 13 Jul 2010 15:20:23 +0100
Michael Foord wrote:
> On 13/07/2010 15:17, Reid Kleckner wrote:
> > On Mon, Jul 12, 2010 at 2:07 PM, Nick Coghlan wrote:
> >
> >> MRAB's module offers a superset of re's features rather than a subset
> >> though, so once it has had more of a chance to bake
On Tue, 13 Jul 2010 11:25:23 -0400
Alexander Belopolsky wrote:
> When pickle.py needs to import a module by name, it goes through a
> peculiar dance of
>
> __import__(module, level=0)
> mod = sys.modules[module]
>
> As far as I can tell, unless builtins.__import__ is over
On Wed, 14 Jul 2010 12:34:27 -0400
Terry Reedy wrote:
>
> So I can see that pushing to make it a business meeting would not be too
> welcome. What I would like is an online sprint with a temporary
> #python-triage channel, with at least one commit-developer present.
It should be noted that #py
On Wed, 14 Jul 2010 12:33:55 -0700
Brett Cannon wrote:
>
> So I started writing benchmark code in anticipation of needing to prove a
> minimal performance difference to justify bootstrapping importlib. Right now
> it only compares importing from sys.modules and built-in modules. You can
> run it
On Wed, 14 Jul 2010 19:24:28 -0400
Alexander Belopolsky wrote:
> I am reposting the same question again because it seems to have gone
> unnoticed. Antoine Pitrou and I had a brief discussion on the
> tracker, but did not reach an agreement on whether a more elaborate
> code is neede
On Thu, 15 Jul 2010 00:43:49 +0200
"M.-A. Lemburg" wrote:
> Is this intended or should I open a bug report for it:
>
> >>> m = memoryview('abc')
> >>> m == 'abc'
> True
> >>> str(m) == 'abc'
> False
> >>> str(m)
> ''
Well, I think this is intended. str(m) is the human-readable string
representat
On Wed, 14 Jul 2010 23:06:58 -0700
Brett Cannon wrote:
> >
> > In any case, here my results under a Linux system:
> >
> > $ ./python -m importlib.test.benchmark
> > sys.modules [ 323782 326183 326667 ] best is 326667
> > Built-in module [ 33600 33693 33610 ] best is 33693
> >
> > $ ./python -m imp
Hello Mark,
On Sun, 18 Jul 2010 00:45:09 +0100
Mark Lawrence wrote:
> On 17/07/2010 22:57, Terry Reedy wrote:
> > On 7/17/2010 8:41 AM, Mark Lawrence wrote:
> >
> >> IIRC Terry Reedy is also interested in moving IDLE forward.
> >
> > Interested, yes. But until either a) I can commit patches, or
On Wed, 21 Jul 2010 11:42:00 -0400
Jesse Noller wrote:
> On Wed, Jul 21, 2010 at 11:11 AM, Tim Golden wrote:
> [...snip...]
> > A messy discussion turned on the question of garbage collection of module
> > objects, and the order in which finalisers are called if at all, especially
> > when refere
On Thu, 22 Jul 2010 17:50:00 +0900
"Stephen J. Turnbull" wrote:
> Greg Ewing writes:
> > Glyph Lefkowitz wrote:
> >
> > > The selection of RuntimeError in this particular case seems
> > > somewhat random and ad-hoc,
>
> Well, I guess we'd have to catch the person who wrote the code and
> ask
On Thu, 22 Jul 2010 08:51:57 +0100
Brett Cannon wrote:
>
> That's an option. I just remember Tim bringing up something about that
> approach that didn't quite work as a complete replacement for __del__.
>
> Basically the whole setting a module's globals to None was done before gc
> came into the
2801 - 2900 of 4909 matches
Mail list logo
