Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

Russell Owen wrote: > I agree that a policy is a good idea, and I suggest it be primarily based on > age, since we cannot assume Apple will release new versions of the OS on a > given timeline. > > I personally think too early to drop support for MacOS X 10.6 and am on the > edge about 10.5.

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

Russell E. Owen wrote: > In article , > Raymond Hettinger wrote: > > > On Sep 14, 2013, at 1:32 PM, Ned Deily wrote: > > > The > > > most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have > > > a mature clang but do not provide a 10.6 SDK. Even with using an SDK, > > >

Re: [Python-Dev] Status of packaging in 3.3

Nick Coghlan wrote: > On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrou wrote: > > Agreed, especially if the "proven in the wild" criterion is required > > (people won't rush to another third-party distutils replacement, IMHO). > > The existence of setuptools means that "proven in the wild" is ne

Re: [Python-Dev] JITted regex engine from pypy

Maciej Fijalkowski wrote: > On Sun, Jun 3, 2012 at 5:21 PM, "Martin v. Löwis" wrote: > > > On the minus side, the JIT only works on x86 and x86_64, on the plus > >> side, since it's 100% API compatible, it can be used as a _xxx > >> speedup module relatively easy. > >> > >> Do people have opini

Re: [Python-Dev] OS X buildbots missing

Antoine Pitrou wrote: > For the record, we don't have any stable OS X buildbots anymore. Sigh. That's me again. We are currently installing a virtual private cloud at our workspace, and I'm seeing a lot of intermittent failures in that server room. I need to work out a way in which buildbot r

Re: [Python-Dev] Status of Mac buildbots

Nadeem Vawda wrote: > Hi all, > > I've noticed that most of the Mac buildbots have been offline for a while: > > * http://www.python.org/dev/buildbot/all/buildslaves/parc-snowleopard-1 > * http://www.python.org/dev/buildbot/all/buildslaves/parc-tiger-1 > * http://www.python.org/dev/buildbot/all

Re: [Python-Dev] PEP 407 / splitting the stdlib

Nick Coghlan wrote: > On Thu, Jan 19, 2012 at 10:19 AM, Steven D'Aprano wrote: > > Brett Cannon wrote: > > Do we have any evidence of this alleged bitrot? I spend a lot of time on the > > comp.lang.python newsgroup and I see no evidence that people using Python > > believe the standard library i

Re: [Python-Dev] Hash collision security issue (now public)

Christian Heimes wrote: > Am 29.12.2011 12:13, schrieb Mark Shannon: > > The attack relies on being able to predict the hash value for a given > > string. Randomising the string hash function is quite straightforward. > > There is no need to change the dictionary code. > > > > A possible (*untes

Re: [Python-Dev] Fixing the XML batteries

Stefan Behnel wrote: > Bill Janssen, 09.12.2011 19:15: > > I think another thing that might go into "refreshing the batteries" is a > > feature comparison of BeautifulSoup and HTML5lib against the stdlib > > competition, to see what needs to be added/revised. Hav

Re: [Python-Dev] Fixing the XML batteries

Xavier Morel wrote: > On 2011-12-09, at 19:15 , Bill Janssen wrote: > > I use ElementTree for parsing valid XML, but minidom for producing it. > Could you expand on your reasons to use minidom for producing XML? Inertia, I guess. I tried that first, and it seems to work. I

Re: [Python-Dev] Fixing the XML batteries

Mike Meyer wrote: > On Fri, 09 Dec 2011 09:02:35 +0100 > Stefan Behnel wrote: > > > a) The stdlib documentation should help users to choose the right > > tool right from the start. > > b) cElementTree should finally loose it's "special" status as a > > separate library and disappear as an accel

Re: [Python-Dev] Unicode re support in Python 3

Michael Foord wrote: > Hey python-devers, > > As I'm sure many of you are aware, Armin Ronacher posted a blog entry > explaining the reasons he dislikes Python 3 in its current form. > > Whilst I don't agree with all of his complaints, he makes a fair point > about the re module Unicode support

Re: [Python-Dev] readd u'' literal support in 3.3?

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= wrote: > While this is true for FORTRAN, it is not for Python 1.5: no new > Python 1.5 code is written around the world, at least not every day. I don't know about that. I've seen a lot of Python 2 code which was apparently written by folks who learned

Re: [Python-Dev] EuroPython Language Summit report

Michael Foord wrote: > Thanks. Support for Unicode character classes was one of the > improvements needed in the re module reported from the language summit > - > so I wonder if the changes in regex are sufficient. I guess it depends on what you're asking -- what does "support for Unicode chara

Re: [Python-Dev] EuroPython Language Summit report

Michael Foord wrote: > The new regex library has some great improvements: > > http://bugs.python.org/issue2636 > > It also has users and committed maintainers, so I hope we can bring it > into 3.3. It wasn't easy to tell from skimming the change notes that > Unicode character classes are am

Re: [Python-Dev] open(): set the default encoding to 'utf-8' in Python 3.3?

Terry Reedy wrote: > > Making such default encodings depend on the locale has already > > failed to work when we first introduced a default encoding in > > Py2, so I don't understand why we are repeating the same > > mistake again in Py3 (only in a different area). > > I do not remember any prop

Re: [Python-Dev] open(): set the default encoding to 'utf-8' in Python 3.3?

M.-A. Lemburg wrote: > How about a more radical change: have open() in Py3 default to > opening the file in binary mode, if no encoding is given (even > if the mode doesn't include 'b') ? +1. > That'll make it compatible to the Py2 world again and avoid > all the encoding guessing. Yep. Bill

Re: [Python-Dev] Snow Leopard buildbot failing again...

Antoine Pitrou wrote: > On Mon, 27 Jun 2011 10:01:13 PDT > Bill Janssen wrote: > > I see that parc-snowleopard-1 went down again. I've done a software > > update, rebooted, and installed the latest buildslave, 0.8.4. I can > > ping dinsdale.python.org successful

Re: [Python-Dev] Snow Leopard buildbot failing again...

I also find interesting, because it seems a good explanation of why the build slave might go into the zombie state of attempting to reconnect to the master. Bill ___ Python-Dev mailing list Python-Dev@python.org htt

Re: [Python-Dev] Snow Leopard buildbot failing again...

exar...@twistedmatrix.com wrote: > On 05:01 pm, jans...@parc.com wrote: > >I see that parc-snowleopard-1 went down again. I've done a software > >update, rebooted, and installed the latest buildslave, 0.8.4. I can > > ping dinsdale.python.org successfully from the machine. However, > > when I >

[Python-Dev] Snow Leopard buildbot failing again...

I see that parc-snowleopard-1 went down again. I've done a software update, rebooted, and installed the latest buildslave, 0.8.4. I can ping dinsdale.python.org successfully from the machine. However, when I start the buildslave, I get this: $ buildslave start ~/buildarea/ /Library/Python/2.6/s

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

Nick Coghlan wrote: > And no, the fact that methods can be treated as attributes is not a > minor detail. It is *fundamental* to Python's object model that > *methods are not a special case of attribute access*. All attributes > work the same way, it is just the way functions implement the > desc

Re: [Python-Dev] Stable buildbots update

Ned Deily wrote: > In article <87zkmcalt8@uwakimon.sk.tsukuba.ac.jp>, > "Stephen J. Turnbull" wrote: > > Are you saying you expect Mac OS X 10.4 "Tiger" to go green once the > > bots update? If so, I'm impressed, and "thank you!" to all involved. > > Apple and MacPorts have long since wash

Re: [Python-Dev] Stable buildbots update

Tarek Ziadé wrote: > Yes, I am aware of this. I have fixed today most remaining issues, and > fixing the final ones right now. Just FYI: the "AMD64 Snow Leopard" buildbot and "PPC Leopard" buildbots are now green, but the "PPC Tiger" buildbot is still failing for all branches because of packagi

Re: [Python-Dev] Python 3.x and bytes

Georg Brandl wrote: > We do have > > bytes.fromhex('deadbeef') Sort of reminds me of Java's Integer.parseInt(), and not in a good way. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubsc

Re: [Python-Dev] Simple XML-RPC server over SSL/TLS

Éric Araujo wrote: > Hi, > > > But what I would like to know, is if is there any reason why XML-RPC can't > > optionally work over TLS/SSL using Python's ssl module. I'll create a > > ticket, and send a patch, but I was wondering if it was a reason why this > > was not implemented. > > I think

Re: [Python-Dev] funky buildbot problems again...

exar...@twistedmatrix.com wrote: > On 08:31 pm, jans...@parc.com wrote: > >My Intel Snow Leopard 2 build slave has gone into outer-space again. > > > >When I look at it, I see buildslave taking up most of a CPU (80%), and > >nothing much else going on. The twistd log says: > > > >[... much omitte

Re: [Python-Dev] funky buildbot problems again...

Michael Foord wrote: > On 07/04/2011 21:31, Bill Janssen wrote: > > My Intel Snow Leopard 2 build slave has gone into outer-space again. > > [snip...] > > So it's been spinning its wheels for 3 days. > > > > Sure looks like the connection attempt is faili

[Python-Dev] funky buildbot problems again...

My Intel Snow Leopard 2 build slave has gone into outer-space again. When I look at it, I see buildslave taking up most of a CPU (80%), and nothing much else going on. The twistd log says: [... much omitted ...] 2011-04-04 08:35:47-0700 [-] sending app-level keepalive 2011-04-04 08:45:47-0700 [-

Re: [Python-Dev] funky buildbot

My Intel Snow Leopard buildbot failed again last night. Here's what I see in twistd.log. Any of this look familiar to some one? Failed at about 19:58 (PST?). I don't see any reason for these failures, but they seem to happen about once a week. This is the standard Snow Leopard Python 2.6.1, and

Re: [Python-Dev] funky buildbot

David Bolen wrote: > There used to be a way to request a "ping" from the master side (I > think on the same page you could manually run a build from) that I > would used to force it to recognize a slave was really down, but after > the web interface got rearranged a while back, I can't seem to fi

Re: [Python-Dev] funky buildbot

David Bolen wrote: > Bill Janssen writes: > > > I'm trying to get a new buildbot in the swim of things, and it keeps > > getting into this state where the buildslave process seems caught in an > > endless loop. Perhaps someone here knows why? > > Do you ha

[Python-Dev] funky buildbot

I'm trying to get a new buildbot in the swim of things, and it keeps getting into this state where the buildslave process seems caught in an endless loop. Perhaps someone here knows why? It's a new Mac Mini running the latest Snow Leopard, with Python 2.6.1 (the /usr/bin/python) and buildslave 0.

Re: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py

Giampaolo Rodolà wrote: > Although I don't use it, it seems that Twisted managed to do this by > splitting the concepts of "transport" and "protocol" / "application" > and by using zope.interface. You might want to look at the ILU core, too, just for ideas. Somewhat to my surprise, the link htt

Re: [Python-Dev] Python merge module

Martin v. Löwis wrote: > The Installer COM object is the platform standard > mechanism, and that's what msilib uses. I really see no need to move > away from that - it can create arbitrary MSI files. I've used it to package UpLib for Windows -- see http://uplib.parc.com/hg/uplib/file/e29e36f751f

Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.

Steven D'Aprano wrote: > s...@pobox.com wrote: > > > I realize the world is passing me by and that I'm rapidly turning into a > > dinosaur w.r.t. distributed version control, but as you write/update the > > developer's guide remember that proficiency in Python does not necessarily > > equate to

Re: [Python-Dev] PEP 3333: wsgi_string() function

P.J. Eby wrote: > Right. Also, it should be mentioned that none of this would be > necessary if we could've gotten a "bytes of a known encoding" type. Indeed! Or even "string using a known encoding"... > If you look back to the last big Python-Dev discussion on > bytes/unicode and stdlib API

Re: [Python-Dev] Using logging in the stdlib and its unit tests

Glenn Linderman wrote: > 1) simple example for one file programs, include an example of > specifying output severity threshold. I'm with Antoine here on my > expectations. Yes, once I put logging.basicConfig(stream=sys.stdout, level=logging.DEBUG) in my main(), I got what I thought I'd ge

Re: [Python-Dev] Using logging in the stdlib and its unit tests

Guido van Rossum wrote: > And yet, I have helped many people who were baffled by exactly what > Bill observed: logging.info() didn't do anything. Maybe the default > should be INFO? Yeah, I was curious enough to read the code and find out why. But many won't. By the way, I tried reading the 2.

Re: [Python-Dev] Using logging in the stdlib and its unit tests

Glenn Linderman wrote: > On 12/10/2010 12:06 AM, Vinay Sajip wrote: > >> > This simplistic easy usage somewhat echo's Glenn's comment on this > >> > thread > > about logging seeming way to daunting as presented today. It needn't be. > >> > > > Indeed, and the very first code sample in the lo

Re: [Python-Dev] constant/enum type in stdlib

Isaac Morland wrote: > On Tue, 23 Nov 2010, Antoine Pitrou wrote: > > > Le mardi 23 novembre 2010 à 12:32 -0500, Isaac Morland a écrit : > >> On Tue, 23 Nov 2010, Antoine Pitrou wrote: > >> > >>> We already have a bunch of bizarrely unrelated stuff in collections > >>> (such as Callable), so we

Re: [Python-Dev] Help deploying a new buildbot running OpenIndiana/x86

Jesus Cea wrote: > On 17/11/10 17:23, Antoine Pitrou wrote: > > There is no incoming connection; however, a bunch of outgoing > > connections are made to various hosts by various tests, so it's better > > if there's no overzealous firewall in-between. For those of us who can't do that, there's a

Re: [Python-Dev] Stable buildbots

Ned Deily wrote: > In article <30929.1289879...@parc.com>, Bill Janssen > wrote: > > > Both the Tiger buildbots are suddenly failing 3.x on test_cmd_line. > > Looking at the changes since the last success, I can't see anything > > which would obviously

Re: [Python-Dev] Stable buildbots

Both the Tiger buildbots are suddenly failing 3.x on test_cmd_line. Looking at the changes since the last success, I can't see anything which would obviously affect that... Any suspects? Here's what's failing: == ERROR: test_run

Re: [Python-Dev] [Python-checkins] r86441 - python/branches/py3k/Lib/test/test_nntplib.py

Antoine Pitrou wrote: > On Sat, 13 Nov 2010 07:30:05 -0500 > James Y Knight wrote: > > On Nov 13, 2010, at 7:08 AM, Antoine Pitrou wrote: > > > Funny, it shows that the NNTP SSL tests don't check the certificate, > > > then. > > > > Unsurprising, given that you need 140 lines of pretty non-obvi

Re: [Python-Dev] Continuing 2.x

Kristján Valur Jónsson wrote: > Let's move the current 'trunk' into /branches/afterlife-27. Open it > for submissions from people such as myself that use 2.7 on a regular > basis and are willing to give it some extra love. Though I'm not personally convinced it's a good idea, I can see where so

Re: [Python-Dev] PPC Leopard buildbot failing sqlite test for Python 3.2

R. David Murray wrote: > On Sat, 16 Oct 2010 13:14:20 -0700, Bill Janssen wrote: > > There was a test added to the sqlite suite between 3.1 and the current > > 3.x trunk, TestInTransaction. It's failing pretty consistently on the > > PPC Leopard buildbot (

[Python-Dev] PPC Leopard buildbot failing sqlite test for Python 3.2

There was a test added to the sqlite suite between 3.1 and the current 3.x trunk, TestInTransaction. It's failing pretty consistently on the PPC Leopard buildbot (2.7 and 3.1 are testing OK). Calling sqlite3.sqlite_version returns 3.4.0. A couple of things come to mind: * Does this require a dif

[Python-Dev] PPC Tiger is back up

I've moved the OS X buildbot parc-tiger-1 (PPC Tiger) to new hardware, a MDD dual-G4 PowerMac with more memory. Should move considerably faster. Enjoy! Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/pytho

Re: [Python-Dev] sad state of OS X Python testing...

Sorry to drop out like that -- I've been having some email issues. Stephen, great job; thanks for providing that Snow Leopard buildbot. I think what we're missing now is an Intel Leopard buildbot. 35% of Mac users are still running Leopard. I'm running it myself on some machines, due to the NIS

[Python-Dev] PPC Tiger buildbot going down for an upgrade

I've found a dual-processor G4 to run the PPC Tiger buildbot on (it's currently an old e Mac), and I plan to take this buildbot down tomorrow, Wednesday, to upgrade. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.or

[Python-Dev] sad state of OS X Python testing...

Folks, I was looking at the buildbots again. Do you realize that we have no OS X Snow Leopard buildbot? No Intel Leopard buildbot? Well over half of Mac users are using Snow Leopard, and we're not testing on that platform. In fact, the only Intel OS X machine we're testing on is a Core Duo, not

[Python-Dev] the "PPC Leopard" buildbot is back online

I've finished upgrading the PPC Leopard builder to a dual 2 GHz G5 machine. Tests should run a bit faster now that the eMac is out of the loop :-). I'm looking for a faster machine for the PPC Tiger buildbot. Bill ___ Python-Dev mailing list Python-Dev

[Python-Dev] PPC Leopard build slave going down for an upgrade

I'm replacing the PPC Leopard build slave with a dual 2GHz G5 machine... Bill ___ 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%40m

Re: [Python-Dev] Rework nntlib?

Interesting. I personally use nis and poplib quite a bit, but I can see how that would be very location-dependent. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python

Re: [Python-Dev] Rework nntlib?

Jesse Noller wrote: > no one seems to take the betas or alphas for serious test drives (to > be expected) with real code I wonder if there's some way to improve that situation -- perhaps by some engineering of the Python packaging, or some such? Bill

Re: [Python-Dev] Python Language Summit EuroPython 2010

Tim, thanks for this write-up! Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

Michael Foord wrote: > On 20/07/2010 14:43, Nick Coghlan wrote: > > On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Aprano > > wrote: > > > >> I'm -0 on adding an argument to os.makedirs, +0 on adding a variant > >> function to os, and +0.5 on adding the variant to the shutil module. > >>

Re: [Python-Dev] Removing IDLE from the standard library

Stephen Hansen wrote: > On Sun, Jul 11, 2010 at 4:53 PM, Steve Holden wrote: > > > Stephen Hansen wrote: > > > On Sat, Jul 10, 2010 at 9:23 PM, Guilherme Polo > > > wrote: > > > > > > By "never had a problem" do you mean using some of the latest > > versions > > >

Re: [Python-Dev] Can ftp url start with file:// ?

Fred Drake wrote: > On Sat, Jul 10, 2010 at 11:56 PM, Senthil Kumaran wro= > te: > > I see the reason. But I doubt if this is a reliable approach. =A0Also > > when the scheme begins with file:// it should not be confused with > > ftp, so I think, that portion of code in urllib which work that wa

Re: [Python-Dev] Removing IDLE from the standard library

Tal Einat wrote: > Although several people say that they think having IDLE in the stdlib > is important, the fact is that IDLE is considered quite unimportant by > most of the Python community. Having IDLE in the stdlib may be > convenient for a few people, but most never use it and don't care >

Re: [Python-Dev] Can ftp url start with file:// ?

Tim Lesher wrote: > On Fri, Jul 9, 2010 at 12:41, Bill Janssen wrote: > > > So, FTP is *not* the "default protocol". On the other hand, if > > actually begins with "ftp.", it's a pretty good guess that FTP will > > work. > > >

Re: [Python-Dev] Can ftp url start with file:// ?

Senthil Kumaran wrote: > On Fri, Jul 09, 2010 at 02:23:40PM +1000, Steven D'Aprano wrote: > > > Is this is valid ftp url? > > > > > > # file://ftp.example.com/blah.txt (an ftp URL) > > > > > > My answer is no. When we have the scheme specifically mentioned as > > > file:// it is no point in consi

Re: [Python-Dev] OS X buildbots: why am I skipping these tests?

Martin v. Löwis wrote: > > The whole "unexpected" skipping is somewhat of a mess. In an ideal > > situation modules that are optionally built should be allowed to skip, > > While this may be the wide-spread interpretation, it is definitely *not* > the original intention of the feature. > > When

Re: [Python-Dev] OS X buildbots: why am I skipping these tests?

exar...@twistedmatrix.com wrote: > Could the test be rewritten (or supplemented) to use a pty? Most or > perhaps all of the same operations should be supported. Buildbot seems to be explicitly not using a PTY. From the the top of the test output: make buildbottest in dir /Users/buildbot/build

Re: [Python-Dev] OS X buildbots: why am I skipping these tests?

Martin v. Löwis wrote: > > Seems to work fine. So this I don't understand. Any ideas, anyone? > > Didn't we discuss this before? Possibly, but I don't recall doing so. > The buildbot slave has no controlling > terminal anymore, hence it cannot open /dev/tty. If you are curious, > just patch

Re: [Python-Dev] OS X buildbots: why am I skipping these tests?

Guido van Rossum wrote: > On Tue, Jun 29, 2010 at 7:55 PM, Bill Janssen wrote: > > My Leopard and Tiger PPC buildbots are momentarily green!  But I'm > > looking into why I'm skipping some tests.  My buildbots are up-to-date > > OS-wise and very vanilla, w

[Python-Dev] OS X buildbots: why am I skipping these tests?

My Leopard and Tiger PPC buildbots are momentarily green! But I'm looking into why I'm skipping some tests. My buildbots are up-to-date OS-wise and very vanilla, with the latest applicable Xcode. 4 skips unexpected on darwin: test_gdb test_ioctl test_readline test_ttk_guionly Three of these

Re: [Python-Dev] thoughts on the bytes/string discussion

Guido van Rossum wrote: > On Fri, Jun 25, 2010 at 1:43 PM, Glyph Lefkowitz > wrote: > > > > On Jun 24, 2010, at 4:59 PM, Guido van Rossum wrote: > > > > Regarding the proposal of a String ABC, I hope this isn't going to > > become a backdoor to reintroduce the Python 2 madness of allowing > > eq

[Python-Dev] thoughts on the bytes/string discussion

Here are a couple of ideas I'm taking away from the bytes/string discussion. First, it would probably be a good idea to have a String ABC. Secondly, maybe the string situation in 2.x wasn't as broken as we thought it was. In particular, those who deal with lots of encoded strings seemed to find

Re: [Python-Dev] os.getgroups() on MacOS X Was: red buildbots on 2.7

See also http://gimper.net/viewtopic.php?f=18&t=3185. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytes / unicode

Guido van Rossum wrote: > So I propose that we drop the discussion "are URLs text or bytes" and > try to find something more pragmatic to discuss. > > For example: how we can make the suite of functions used for URL > processing more polymorphic, so that each developer can choose for > herself h

Re: [Python-Dev] bytes / unicode

Tres Seaver wrote: > Stephen J. Turnbull wrote: > > > We do need str-based implementations of modules like urllib. > > Why would that be? URLs aren't text, and never will be. The fact that > to the eye they may seem to be text-ish doesn't make them text. This URLs are exactly text (strings,

Re: [Python-Dev] red buildbots on 2.7

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? Thanks to some action by Ronald, my two PPC OS X b

Re: [Python-Dev] Use of cgi.escape can lead to XSS vulnerabilities

Craig Younkins wrote: > cgi.escape never escapes single quote characters, which can easily lead to a > Cross-Site Scripting (XSS) vulnerability. This seems to be known by many, > but a quick search reveals many are using cgi.escape for HTML attribute > escaping. Did you file a bug report? Bill

Re: [Python-Dev] red buildbots on 2.7

Alexander Belopolsky wrote: > On Mon, Jun 21, 2010 at 9:26 PM, Bill Janssen wrote: > .. > > Though, isn't that behavior of urllib.proxy_bypass another bug? > > I don't know. Ask Ronald. Hmmm. I brought up the System Preferences panel on my Mac, and sure enough,

Re: [Python-Dev] red buildbots on 2.7

Alexander Belopolsky wrote: > Oh, I thought that was about http://bugs.python.org/issue8455 . > > On Mon, Jun 21, 2010 at 9:05 PM, Alexander Belopolsky > wrote: > > On Mon, Jun 21, 2010 at 6:39 PM, Paul Moore wrote: > > .. > >> Yes, looks like it's a bug in the test. http://bugs.python.org/iss

Re: [Python-Dev] red buildbots on 2.7

Antoine Pitrou wrote: > OS X is only "a supported and important platform" if we have dedicated > core developers diagnosing or even fixing issues for it (like we > obviously have for Windows and Linux). Otherwise, I don't think we have > any moral obligation to support it. Fair enough. That bei

Re: [Python-Dev] red buildbots on 2.7

Antoine Pitrou wrote: > 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 does

Re: [Python-Dev] red buildbots on 2.7

Benjamin Peterson wrote: > 2010/6/21 Bill Janssen : > > They are at the end of the buildbot list, so off-screen if you are using > > a normal browser.  You have to scroll to see them. > > But not on the "stable" view and that's the only one I loo

Re: [Python-Dev] red buildbots on 2.7

Antoine Pitrou wrote: > Benjamin is not qualified to fix OS X bugs AFAIK (if you are, Benjamin, > then sorry for misrepresenting you :-)). Actually, neither are most of > us. Right. I was thinking that the release manager should however be responsible for not releasing while there are red build

Re: [Python-Dev] red buildbots on 2.7

Benjamin Peterson wrote: > 2010/6/21 Bill Janssen : > > 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

[Python-Dev] red buildbots on 2.7

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 test_py3kwarn, test_urllib2_localnet, test_uuid. On OS X Tiger

Re: [Python-Dev] email package status in 3.X

Giampaolo Rodolà wrote: > 2010/6/17 Bill Janssen : > > > There's a related meta-issue having to do with antique protocols. > > Can I know what meta-issue are you talking about exactly? Giampaolo, I believe that you and I have already discussed this on one o

Re: [Python-Dev] email package status in 3.X

Nick Coghlan wrote: > My personal perspective is that a lot of that code was likely already > broken in hard to detect ways when dealing with mixed encodings - > releasing 3.x just made the associated errors significantly easier to > detect. I have to agree with this, and not just about encoding

Re: [Python-Dev] Future of 2.x.

Barry Warsaw wrote: > On Jun 09, 2010, at 04:42 PM, M.-A. Lemburg wrote: > > >Many of them are not keen on having to maintain Python2 for much > >longer, but some of them may have assets codified in Python2 > >or interests based Python2 that they'll want to keep for > >more than just another 5 y

Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs

Antoine Pitrou wrote: > 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: > > >> > > >> >>> b'abc'.transform("hex

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

Martin v. Löwis wrote: > Peter Portante wrote: > > Does anybody think that by having problems with the new GIL that it might > > further weaken the adoption rate for 3k? -peter > > No, to the contrary. By having the new GIL being superior to the old > implementation, the adoption rate for 3k wil

Re: [Python-Dev] pybuildbot.identify?

Martin v. Löwis wrote: > Bill Janssen wrote: > > Matthias Klose wrote: > > > >> On 19.05.2010 18:09, Bill Janssen wrote: > >>> The PPC buildbots are running pretty well, now that I've opened a few > >>> more ports, but I'd like to f

Re: [Python-Dev] pybuildbot.identify?

Matthias Klose wrote: > On 19.05.2010 18:09, Bill Janssen wrote: > > The PPC buildbots are running pretty well, now that I've opened a few > > more ports, but I'd like to find this script "pybuildbot.identify" that > > they keep complaining abou

[Python-Dev] pybuildbot.identify?

The PPC buildbots are running pretty well, now that I've opened a few more ports, but I'd like to find this script "pybuildbot.identify" that they keep complaining about, and install it. I've poked around the Python sources, but haven't found it. Anyone know where to get it from? Thanks. Bill _

Re: [Python-Dev] Summing up

Nick Coghlan wrote: > B. some more thought should be given to incorporating the new GIL into > 2.7. However, this requires two things: > - an update to the patch in 7753 to either retain the old GIL for > platforms not supported by the new GIL or else to make the new GIL a > configure option >

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

Antoine Pitrou wrote: > On Sun, 16 May 2010 15:13:44 PDT > Bill Janssen wrote: > > > > So the patch to the threading code would presumably, for those OSs where > > the capability exists, try to put all created threads in the same > > affinity set. > > Thi

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

Terry Reedy wrote: > On 5/17/2010 2:59 PM, Bill Janssen wrote: > > Yes, it would. As soon as I have working 3.x versions of BeautifulSoup, > > PIL, ReportLab, JCC, pylucene, pyglet, nltk, email, epydoc, feedparser, > > dictclient, docutils, hachoir, mutagen, medusa,

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

Martin v. Löwis wrote: > > I'd hate to let a fundamental flaw like this go through simply because > > someone somewhere somewhen set a completely synthetic deadline. > > No, it's not like that. We set the deadline so that we are able to > cancel discussions like this one. It would be possible to

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

Antoine Pitrou wrote: > 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 >

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

Antoine Pitrou wrote: > Well, if instead of gnashing your teeth, you had contributed to the > issue, perhaps a patch would have been committed by now (or perhaps > not, but who knows?). If you stay silent, you cannot assume that > someone else will stand up for *your* opinion (and the fact that n

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

Bill Janssen wrote: > use it. Whether or not use explicitly know you are using threads > (because some other package may be using them under the covers). Of course, I meant to say, "Whether or not *youse* explicitly know you are using threads (because some other package may be using

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

Antoine Pitrou wrote: > Well, 2.7rc1 is scheduled in less than three weeks now. IMO any patch > changing fundamental threading properties is a no-no (even the processor > affinity proposal). Unfortunately, our "fundamental threading properties" are broken for multicore machines. And multicore s

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

Antoine Pitrou wrote: > On Sun, 16 May 2010 15:13:44 PDT > Bill Janssen wrote: > > > > So the patch to the threading code would presumably, for those OSs where > > the capability exists, try to put all created threads in the same > > affinity set. > >

  1   2   3   4   5   6   >