Re: [Python-Dev] peps: Update PEP 399 to include comments from python-dev.

On Apr 12, 2011, at 7:50 PM, Tres Seaver wrote: > Trying to accelerate existing code which doesn't have the coverage is > insane: how can you know that the accelerator doesn't subtly change the > semantics without tests? But even if you do have 100% python source code branch coverage, that's not

Re: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

On Apr 6, 2011, at 4:44 PM, s...@pobox.com wrote: >Brett> How about the test suite needs to have 100% test coverage (or as >Brett> close as possible) on the pure Python version? > > Works for me, but you will have to define what "100%" is fairly clearly. > 100% of the lines get executed?

Re: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

On Apr 6, 2011, at 10:08 AM, Nick Coghlan wrote: > On Wed, Apr 6, 2011 at 5:57 AM, Raymond Hettinger > wrote: >> [Brett] >>> This PEP requires that in these instances that both >>> the Python and C code must be semantically identical >> >> Are you talking about the guaranteed semantics >> promi

Re: [Python-Dev] Embedded Python startup is slow

On Mar 24, 2011, at 11:58 AM, bruce bushby wrote: > My main concern was that a freshly compiled Python attempts to open 168 > non-existent files before starting. > > I understand that an interpreted language is probably not the best choice for > an embedded device (although it's very nice for p

Re: [Python-Dev] Proposal for Python 3.3: dependence injection

On Mar 24, 2011, at 12:40 PM, Jesus Cea wrote: > I want to test the dev community interest in modifying the stdlib to > ease dependence injection. > > The seminal idea was in > . > > A lot of stdlib modules use, deep inside, othe

Re: [Python-Dev] Python3: speed efficiency vs user friendliness (my first experience)

On Mar 22, 2011, at 7:57 AM, anatoly techtonik wrote: > For example, now I need to remember that on Windows I need to flush > output every time when I want the result of print() with end!='\n' to > appear on the screen immediately. And for the most of my legacy > scripts I used end='\n' when I want

Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective

On Mar 17, 2011, at 4:07 PM, Raymond Hettinger wrote: > Agreeing with Guido is always a good move :-) > > In addition, any new deprecations in Py3.x can be marked with py3k warnings > in Py2.7 point releases. That would give users the maximum chance to make > updates before porting, even if the

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

On Mar 15, 2011, at 10:14 PM, Lennart Regebro wrote: > On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou wrote: >> I don't know what other core devs, but I don't think this discussion is >> going anywhere. If porting the ZTK is a burden for you, perhaps you >> should try to find some financial suppo

Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL

On Mar 9, 2011, at 6:45 PM, Sandro Tosi wrote: > It seems introduced by the patch debian/patches/setup-modules-ssl.diff > with description "# DP: Modules/Setup.dist: patch to build _hashlib > and _ssl extensions statically" Indeed you're right -- out of the box, python still builds _ssl.so as a s

[Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL

It's well known that OpenSSL is incompatible with the GPL. [1] Python (from 2.6) is *always* linked against openssl, instead of waiting for you to "import ssl". Doesn't this mean it's now impossible (rather, a license violation) to distribute a GPL'd python program (or to use a GPL'd library in

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

On Mar 7, 2011, at 3:49 PM, Paul Moore wrote: > The launcher could also (as per Mark's suggestion) interpret a shebang > line in the script, so that scripts could specify their required > version without needing a different command,or multiple > version-specific extensions. Note that, on Unix, "py

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

On Mar 4, 2011, at 4:21 PM, Martin v. Löwis wrote: > and setting PYTHONPATH will continue to break installations). Indeed, it's really *quite* unfortunate that the proposal to make python3 use PYTHON3PATH instead of PYTHONPATH was rejected. James ___ P

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

On Mar 3, 2011, at 3:55 AM, Piotr Ożarowski wrote: > I don't really mind adding /usr/bin/python2 symlink just to clean Arch mess Is there any chance you would add the symlink in the next Debian stable point release? If both Debian and Python upstream added the python2 symlink in the next stable

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

On Mar 2, 2011, at 7:01 PM, Kerrick Staley wrote: > As an aside, this whole thing started when I tried installing ROS, only to > find that it made assumptions about /usr/bin/python, which points to python3 > on my Arch Linux system. Yep, exactly that kind of problem is why I think it's an absolu

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

On Mar 2, 2011, at 5:04 PM, Martin v. Löwis wrote: > Am 02.03.2011 20:49, schrieb James Y Knight: >> On Mar 2, 2011, at 12:14 PM, Barry Warsaw wrote: >>> I don't have a problem with adding such a symlink, and I think it >>> should be done by Informational PEP, no

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

On Mar 2, 2011, at 11:42 AM, R. David Murray wrote: > Well, I personally won't use a distribution that makes this choice. > For whatever that's worth :) This ***shouldn't*** be a choice distros have to make. There should be a standard upstream recommended way to install python, and that's also wh

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

On Mar 2, 2011, at 12:14 PM, Barry Warsaw wrote: > I don't have a problem with adding such a symlink, and I think it should be > done by Informational PEP, not Standards Track PEP. Since there will be no > Python 2.8, our own build system shouldn't ever be changed to add such a link, > but we can

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

On Mar 2, 2011, at 9:54 AM, Allan McRae wrote: > That way in ?? years when python-3.x is "the" python and python-2.x is > obsolete, and it is decided that /usr/bin/python will be python-3.x (which I > believe is the only logical outcome), But that's not the only logical outcome. A perfectly log

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

On Mar 2, 2011, at 8:23 AM, Sandro Tosi wrote: > On Wed, Mar 2, 2011 at 13:56, Piotr Ożarowski wrote: >> [Sandro Tosi, 2011-03-02] >>> On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski wrote: I co-maintain with Matthias a package that provides /usr/bin/python symlink in Debian and I can c

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

On Mar 1, 2011, at 5:06 PM, Guido van Rossum wrote: > On Tue, Mar 1, 2011 at 1:26 PM, Eric Smith wrote: >> On 3/1/2011 4:19 PM, Kerrick Staley wrote: >>> >>> Hello, >>> There is a need for the default Python2 install to place a symlink at >>> /usr/bin/python2 that points to /usr/bin/python, or

Re: [Python-Dev] Link to issue tracker

On Feb 23, 2011, at 4:00 PM, Brett Cannon wrote: > On Wed, Feb 23, 2011 at 12:38, James Y Knight wrote: > > On Feb 23, 2011, at 3:05 PM, Brett Cannon wrote: > >> >> >> On Wed, Feb 23, 2011 at 11:52, "Martin v. Löwis" wrote: >> Am 23.02.2011 19:

Re: [Python-Dev] Link to issue tracker

On Feb 23, 2011, at 3:05 PM, Brett Cannon wrote: > > > On Wed, Feb 23, 2011 at 11:52, "Martin v. Löwis" wrote: > Am 23.02.2011 19:30, schrieb Brett Cannon: > > I won't add the link back > > Why not? It's a useful link apparently. The "Developer's Guide" > link does not hint that it will be th

Re: [Python-Dev] w9xpopen.exe is still in 3.2

On Feb 20, 2011, at 4:10 AM, Martin v. Löwis wrote: > Am 20.02.2011 07:43, schrieb anatoly techtonik: >> Python definitely needs a development Roadmap to avoid things like >> w9xpopen.exe slipping off radar from release to release. We don't >> support Windows 9x since Python 2.6. What this file d

Re: [Python-Dev] short fetch for NEXTARG macro (was: one byte byte code arguments)

On Jan 31, 2011, at 7:45 AM, Antoine Pitrou wrote: > On Mon, 31 Jan 2011 13:28:39 +0100 > "Jurjen N.E. Bos" wrote: >> I just did it: my first python source code hack. >> I replaced the NEXTARG and PEEKARG macros in ceval.c using a cast to >> short pointer, and lo and behold, a crude measuremen

Re: [Python-Dev] PEP 393: Flexible String Representation

On Jan 27, 2011, at 2:06 PM, Stefan Behnel wrote: > "Martin v. Löwis", 24.01.2011 21:17: >> The Py_UNICODE type is still supported but deprecated. It is always >> defined as a typedef for wchar_t, so the wstr representation can double >> as Py_UNICODE representation. > > It's too bad this isn't in

Re: [Python-Dev] Import and unicode: part two

On Jan 26, 2011, at 11:47 AM, Victor Stinner wrote: > Not exactly. Gtk+ uses the glib library, and to encode/decode filenames, > the glib library uses: > > - UTF-8 on Windows > - G_FILENAME_ENCODING environment variable if set (comma-separated list > of encodings) > - UTF-8 if G_BROKEN_FILENAMES

Re: [Python-Dev] Import and unicode: part two

On Jan 26, 2011, at 4:40 AM, Victor Stinner wrote: > During > Python 3.2 development, we tried to be able to use a filesystem encoding > different than the locale encoding (PYTHONFSENCODING environment > variable): but it doesn't work simply because Python is not alone in the > OS. Except Python, a

Re: [Python-Dev] Mail archive line wrapping (Was: Import and unicode: part two)

On Jan 21, 2011, at 6:31 AM, Antoine Pitrou wrote: > On Thu, 20 Jan 2011 22:25:17 -0500 > James Y Knight wrote: >> >> On Jan 20, 2011, at 3:55 PM, Antoine Pitrou wrote: >>> (by the way, it would be nice if your text/mail editor wrapped lines at >>> 80 chara

Re: [Python-Dev] Import and unicode: part two

On Jan 20, 2011, at 3:55 PM, Antoine Pitrou wrote: > On Thu, 20 Jan 2011 15:27:08 -0500 > Glyph Lefkowitz wrote: >> >> To support the latter, could we just make sure that zipimport has a >> consistent, >> non-locale-or-operating-system-dependent interpretation of encoding? > > It already has,

Re: [Python-Dev] [Python-checkins] r87815 - peps/trunk/pep-3333.txt

On Jan 20, 2011, at 9:31 PM, Ezio Melotti wrote: >> Modified: peps/trunk/pep-.txt >> == >> --- peps/trunk/pep-.txt (original) >> +++ peps/trunk/pep-.txt Fri Jan 7 16:39:27 2011 >> @@ -310,9 +310,9 @@ >

Re: [Python-Dev] Import and unicode: part two

On Jan 19, 2011, at 11:39 PM, Toshio Kuratomi wrote: > Tangent: This is not true about Linux. UTF-8 is a matter of the > interpretation of the filesystem bytes that the user specifies by setting > their system locale. Setting system locale to ASCII for use in system-wide > scripts, is quite commo

Re: [Python-Dev] Import and unicode: part two

On Jan 19, 2011, at 6:44 PM, Toshio Kuratomi wrote: > This problem of which encoding to use is a problem that can be > seen on UNIX systems even now. Try this: > > echo 'print("hi")' > café.py > convmv -f utf-8 -t latin1 café.py > python3 -c 'import café' > > ASCII seems very sensible to me w

Re: [Python-Dev] Add sendfile() to core?

If you're gonna wrap sendfile, it might be nice to also wrap the splice, tee, and vmsplice syscalls on linux, since they're a lot more flexible. Also note that sendfile on BSD has a completely different signature to sendfile on linux. The BSD one has the rather odd functionality of a built-in wr

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

On Jan 7, 2011, at 6:51 AM, Victor Stinner wrote: > I don't understand why you are attached to this horrible hack > (bytes-in-unicode). It introduces more work and more confusing than > using raw bytes unchanged. > > It doesn't work and so something has to be changed. It's gross but it does work.

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

On Jan 6, 2011, at 8:16 PM, Glenn Linderman wrote: > On 1/6/2011 3:50 PM, And Clover wrote: >> >> ISO-8859-1 is the encoding specified by the HTTP RFC > > Please could I have the reference to that specification? I only recall ASCII > and UTF-8 in my readings of various things HTTP and HTML, f

Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable

On Dec 17, 2010, at 7:55 PM, Victor Stinner wrote: > Hi, > > In 2008, I proposed a patch to raise a Python exception on SIGSEVG signal. In > some cases, it's possible to catch the exception, log it, and continue the > execution. But because in some cases, the Python internal state is corrupted

Re: [Python-Dev] Remove HTTP 0.9 support

On Dec 16, 2010, at 3:14 AM, Senthil Kumaran wrote: > Even HTTP 0.9 says that response SHOULD start with status line, but > gives a suggestion that clients can "tolerate" bad server server > behaviors when they don't send the status line and in that the case > response is the body. > > http://ww

Re: [Python-Dev] gc ideas -- sparse memory

On Dec 3, 2010, at 10:50 PM, Terry Reedy wrote: > On 12/3/2010 7:46 PM, James Y Knight wrote: > >> Sure they are. This is what Java provides you, for example. If you >> have fixed, but potentially non-unique ids (in Java you get this >> using "identityHashCode()"

Re: [Python-Dev] gc ideas -- sparse memory

On Dec 3, 2010, at 7:05 PM, Terry Reedy wrote: > I left out that the id must be an int. > >> It's somewhat unfortuante that python has this constraint, instead of >> the looser: "objects have a fixed id during their lifetime", which is >> much easier to implement, and practically as useful. > > G

Re: [Python-Dev] gc ideas -- sparse memory

On Dec 3, 2010, at 6:04 PM, Terry Reedy wrote: > gc is implementation specific. CPython uses ref counting + cycle gc. A > constraint on all implementations is that objects have a fixed, unique id > during their lifetime. CPython uses the address as the id, so it cannot move > objects. Other impl

Re: [Python-Dev] PEP 384 accepted

On Dec 3, 2010, at 5:52 PM, Martin v. Löwis wrote: > Am 03.12.2010 23:48, schrieb Éric Araujo: >>> But I'm not interested at all in having it in distutils2. I want the >>> Python build itself to use it, and alas, I can't because of the freeze. >> You can’t in 3.2, true. Neither can you in 3.1, or

Re: [Python-Dev] ICU

On Dec 1, 2010, at 11:45 PM, Alexander Belopolsky wrote: > On Tue, Nov 30, 2010 at 3:13 PM, Antoine Pitrou wrote: >> >> Oh, about ICU: >> Actually, I remember you saying that locale should ideally be replaced with a wrapper around the ICU library. >>> >>> By that, I stand - however,

Re: [Python-Dev] PEP 384 final review

On Nov 29, 2010, at 8:58 AM, Nick Coghlan wrote: > The http read only URLs > didn't work (no diff returned, just "svn: OPTIONS of > 'http://svn.python.org/python/branches/pep-0384': 200 OK > (http://svn.python.org)"), That was the wrong url: you should've used http://svn.python.org/projects/py

Re: [Python-Dev] len(chr(i)) = 2?

On Nov 24, 2010, at 12:07 AM, Stephen J. Turnbull wrote: > By the way, to send the ball back into your court, I have this feeling > that the demand for UTF-8 is once again driven by native English > speakers who are very shortly going to find themselves, and the data > they are most familiar with,

Re: [Python-Dev] len(chr(i)) = 2?

On Nov 24, 2010, at 12:07 AM, Stephen J. Turnbull wrote: > Or you can give user programs memory indicies, and enjoy the fun as > the poor developers do things like "pos += 1" which works fine on > the ASCII data they have lying around, then wonder why they get > Unicode errors when they take substr

Re: [Python-Dev] len(chr(i)) = 2?

On Nov 23, 2010, at 6:49 PM, Greg Ewing wrote: > Maybe Python should have used UTF-8 as its internal unicode > representation. Then people who were foolish enough to assume > one character per string item would have their programs break > rather soon under only light unicode testing. :-) You put a

Re: [Python-Dev] len(chr(i)) = 2?

Why don't ya'll just call them "--unichar-width=16/32". That describes precisely what the options do, and doesn't invite any quibbling over definitions. James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/py

Re: [Python-Dev] Breaking undocumented API

On Nov 17, 2010, at 11:38 AM, Guido van Rossum wrote: > Deprecation doesn't *require* logging a warning or raising an > exception. You can also add a note to the docs, or if it is > undocumented, just add a comment to the code. (Though if it is in > widespread use despite being undocumented, a bett

Re: [Python-Dev] Breaking undocumented API

On Nov 17, 2010, at 10:30 AM, Guido van Rossum wrote: > On Wed, Nov 17, 2010 at 7:24 AM, James Y Knight wrote: >> On Nov 17, 2010, at 9:19 AM, Nick Coghlan wrote: >>> (and is a little trickier in the case of module level globals, since those >>> can't be depreca

Re: [Python-Dev] Breaking undocumented API

On Nov 17, 2010, at 9:19 AM, Nick Coghlan wrote: > (and is a little trickier in the case of module level globals, since those > can't be deprecated properly) People keep saying this, but there have already been examples shown of how to do it. I actually think that python should include a way to

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

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-obvious python code to do so... James ___ Python-Dev mailing lis

Re: [Python-Dev] Breaking undocumented API

On Nov 10, 2010, at 8:47 AM, Michael Foord wrote: > How about making this explicit (either pep 8 or our developer docs): > > If a module or package defines __all__ that authoritatively defines the > public interface. Modules with __all__ SHOULD still respect the naming > conventions (leading un

Re: [Python-Dev] Continuing 2.x

On Nov 8, 2010, at 6:08 PM, Lennart Regebro wrote: > 2010/11/8 James Y Knight : >> On Nov 8, 2010, at 4:42 AM, Lennart Regebro wrote: >>> So it can be done, but the question is "Why?" >> >> To keep the batteries included? > > But they'll

Re: [Python-Dev] Continuing 2.x

On Nov 8, 2010, at 4:42 AM, Lennart Regebro wrote: > Except for making releases that start backporting Python 3 features > and breaking backwards compatibility gradually (which may or may not > be a good idea) I don't see the point. There isn't much to do when it > comes to improving the language,

Re: [Python-Dev] Python-3 transition in Arch Linux

On Nov 6, 2010, at 9:41 AM, Martin v. Löwis wrote: > So I don't recall a decision that there shouldn't be a python2 > binary, The decision to make one would have to be an active decision, since Python has never installed one before. If there should be one, then the Python Makefile should make on

Re: [Python-Dev] Python-3 transition in Arch Linux

On Nov 4, 2010, at 8:43 PM, Stephen J. Turnbull wrote: > All of the Arch users I know expect Arch to occasionally do radical > things because they're the right things to do in the long run. But the previous consensus (at least, as I, and presumably many other people understood it) was that pytho

Re: [Python-Dev] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/

On Nov 3, 2010, at 11:25 AM, Eric Smith wrote: > On 11/3/10 10:53 AM, Eric Smith wrote: > >> The problem is that there is no unittest.loader in 2.4, and >> unittest.loader.TestLoader is the name that the 2.7 pickle creates. We >> see this problem every time we try and move anything in the stdlib

Re: [Python-Dev] Continuing 2.x

On Oct 27, 2010, at 10:22 PM, Kristján Valur Jónsson wrote: > Hello all. > > So, python 2.7 is in bugfix only mode. ‘trunk’ is off limit. So, where does > one make improvements to the distinguished, and still very much alive, 2.x > series of Python? > The answer would seem to be “one doesn’

Re: [Python-Dev] Support for async read/write

On Oct 19, 2010, at 6:44 PM, Martin v. Löwis wrote: >> So, in conclusion, I disagree that adding wrappers for these would be >> nice. It wouldn't. It would cause some people to think they would be >> useful things to call, and they would always be wrong. > > We are all consenting adults. If peopl

Re: [Python-Dev] Support for async read/write

On Oct 19, 2010, at 1:47 PM, exar...@twistedmatrix.com wrote: > Adding more platform wrappers is always nice. Keep in mind that the quality > of most (all?) aio_* implementations is spotty at best, though. On Linux, > they will sometimes block (for example, if you fail to align buffers > prop

Re: [Python-Dev] Distutils2 scripts

On Oct 8, 2010, at 5:24 PM, Gisle Aas wrote: > On Oct 8, 2010, at 9:22 , Jeroen Ruigrok van der Werven wrote: > >> +1 from me. I sincerely dislike the Perl-esque -m stuff. > > As a Perl/Python guy I have to object to calling the -m stuff Perl-esque. > This is a very Pythonish thing. In the P

Re: [Python-Dev] os.path.normcase rationale?

On Oct 3, 2010, at 9:18 AM, Dan Villiom Podlaski Christiansen wrote: > A simpler alternative would probably be the F_GETPATH fcntl. An example: That requires that you have permission to open the file (and to actually do so which might have other effects), while the File Manager's FSRef method doe

Re: [Python-Dev] os.path.normcase rationale?

On Sep 26, 2010, at 7:36 AM, Paul Moore wrote: > On 26 September 2010 09:01, Paul Moore wrote: >> On 25 September 2010 23:57, Greg Ewing wrote: >>> Paul Moore wrote: >>> Windows has (I believe) user definable filesystems, too, but the OS has "get me the real filename" style calls, >>

Re: [Python-Dev] os.path.normcase rationale?

On Sep 24, 2010, at 10:53 AM, Paul Moore wrote: > On 24 September 2010 15:29, Guido van Rossum wrote: >> I don't think we should try to reimplement what the filesystem does. I >> think we should just ask the filesystem (how exactly I haven't figured >> out yet but I expect it will be more OS-speci

Re: [Python-Dev] PEP 384 status

On Aug 29, 2010, at 8:16 AM, Nick Coghlan wrote: > However, since even platforms other than Windows aren't immune to > version upgrades of the standard C runtime Aren't they? I don't know of any other platform that lets you have two versions of libc linked into a single address space. Linux has h

Re: [Python-Dev] 'hasattr' is broken by design

On Aug 24, 2010, at 10:26 AM, Benjamin Peterson wrote: 2010/8/24 P.J. Eby : At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote: a) a "business" case of throwing anything other than AttributeError from __getattr__ and friends is almost certainly a bug waiting to happen, and FYI, best prac

Re: [Python-Dev] FHS compliance of Python installation

On Jun 26, 2010, at 4:35 PM, Matthias Klose wrote: On 26.06.2010 22:30, C. Titus Brown wrote: On Sat, Jun 26, 2010 at 10:25:28PM +0200, Matthias Klose wrote: On 25.06.2010 02:54, Ben Finney wrote: James Y Knight writes: Really, python should store the .py files in /usr/share/python

Re: [Python-Dev] versioned .so files for Python 3.2

On Jun 25, 2010, at 4:53 AM, Scott Dial wrote: On 6/24/2010 8:23 PM, James Y Knight wrote: On Jun 24, 2010, at 5:53 PM, Scott Dial wrote: If the package has .so files that aren't compatible with other version of python, then what is the motivation for placing that in a shared loc

Re: [Python-Dev] versioned .so files for Python 3.2

On Jun 24, 2010, at 5:53 PM, Scott Dial wrote: On 6/24/2010 5:09 PM, Barry Warsaw wrote: What use case does this address? Specifically, it's the use case where we (Debian/Ubuntu) plan on installing all Python 3.x packages into /usr/lib/python3/dist-packages. As of PEP 3147, we can do th

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

On Jun 22, 2010, at 5:14 PM, Craig Younkins wrote: I suggest rewording the documentation for the method making it more clear what it should and should not be used for. I would like to see the method changed to properly escape single-quotes, but if it is not changed, the documentation shoul

Re: [Python-Dev] bytes / unicode

On Jun 22, 2010, at 1:03 PM, Ian Bicking wrote: Similarly I'd expect (from experience) that a programmer using Python to want to take the same approach, sticking with unencoded data in nearly all situations. Yeah. This is a real issue I have with the direction Python3 went: it pushes you

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

On Jun 21, 2010, at 4:29 PM, M.-A. Lemburg wrote: Here's a little known fact: by changing the Python2 default encoding to 'undefined' (yes, that's a real codec !), you can disable all automatic string coercion in Python2. I tried that once: half the stdlib stops working if you do (for example

Re: [Python-Dev] HEADS UP: Compilation risk with new GCC 4.5.0

On May 12, 2010, at 10:01 AM, Jesus Cea wrote: On 12/05/10 15:39, James Y Knight wrote: While assuming the stack is 16byte aligned is undeniably an ABI-violation in GCC, at this point, it's surely simpler to just go along: the new unofficial ABI for x86 is that the stack must always be

Re: [Python-Dev] HEADS UP: Compilation risk with new GCC 4.5.0

On May 12, 2010, at 9:13 AM, Jesus Cea wrote: Short history: new GCC 4.5.0 (released a month ago), when compiling with - -O3, is adding MMX/SSE instructions that requires stack aligned to 16 byte. This is wrong, since x86 ABI only requires stack aligned to 4 bytes. If you compile EVERYTHI

Re: [Python-Dev] Fwd: broken mailing list links in PEP(s?)

On May 5, 2010, at 8:22 AM, Barry Warsaw wrote: On May 5, 2010, at 7:09 AM, Oleg Broytman wrote: On Wed, May 05, 2010 at 11:43:45AM +0100, Michael Foord wrote: http://mail.python.org/pipermail/python-list/2000-July/108893.html which are broken Pipermail's links aren't stable AFAIU. The n

Re: [Python-Dev] Mailing List archive corruption?

On Jan 19, 2010, at 11:07 AM, Barry Warsaw wrote: On Jan 19, 2010, at 03:50 PM, Vinay Sajip wrote: When I look at the mailing list archive for python-dev, I see some odd stuff at the bottom of the page: http://mail.python.org/pipermail/python-dev/2010-January/thread.html#95232 Anyone know

Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM

On Jan 8, 2010, at 4:14 PM, Tres Seaver wrote: I understood this proposal as a general processing guideline, not something the io library should do (but, say, a text editor). FWIW, I'm personally in favor of using the UTF-8 signature. If people consider them crazy talk, that may be because UTF-8

Re: [Python-Dev] GIL required for _all_ Python calls?

On Jan 7, 2010, at 3:27 PM, Martin v. Löwis wrote: I've been wondering whether it's possible to release the GIL in the regex engine during matching. I don't think that's possible. The regex engine can also operate on objects whose representation may move in memory when you don't hold the GIL (

Re: [Python-Dev] Drop support for ones' complement machines?

On Dec 1, 2009, at 11:08 AM, Martin v. Löwis wrote: >>> I'd rather prefer to explicitly list what CPython assumes about the >>> outcome of specific operations. If this is just about &, |, ^, and ~, >>> then its fine with me. >> >> I'm not even interested in going this far: > > I still am: with

Re: [Python-Dev] PyPI comments and ratings, *really*?

On Nov 12, 2009, at 5:23 PM, Masklinn wrote: On 12 Nov 2009, at 22:53 , James Y Knight wrote: On Nov 12, 2009, at 4:11 PM, Ben Finney wrote: I think Jesse's point (or, if he's not willing to claim it, my point) is that, compared to the mandatory comment system, it makes much *m

Re: [Python-Dev] PyPI comments and ratings, *really*?

On Nov 12, 2009, at 4:11 PM, Ben Finney wrote: I think Jesse's point (or, if he's not willing to claim it, my point) is that, compared to the mandatory comment system, it makes much *more* sense to have a mandatory field for “URL to the BTS for this project”. One might look at the "competiti

Re: [Python-Dev] Retrieve an arbitrary element from a setwithoutremoving it

On Nov 5, 2009, at 6:04 PM, geremy condra wrote: Perhaps my test is flawed in some way? Yes: you're testing the speed of something that makes absolutely no sense to do in a tight loop, so *who the heck cares how fast any way of doing it is*! Is this thread over yet? James ___

Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

On Nov 3, 2009, at 8:55 AM, sstein...@gmail.com wrote: And, as you point out, if 3.x doesn't start getting the crap beat out of it in the real world sooner rather than later, we may find ourselves, collectively with a stale 2.x, an under battle-tested 3.x, and nowhere to go. If that happen

Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

On Nov 3, 2009, at 12:06 AM, Guido van Rossum wrote: Though I imagine what it really needs is a "quirks mode" parser that is compatible with the HTML dialect accepted by, say, IE6. Maybe a summer of code project? Already exists: html5lib. http://code.google.com/p/html5lib/ Or if you want a fa

Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

On Nov 2, 2009, at 6:24 PM, sstein...@gmail.com wrote: +1 on 2.7 being the last of the 2.x series. Enough already! -1. (not that it matters) I, personally, haven't even written my first line of 3.x code, nor have I had any good reason to. Me neither. If I saw the actual end of

Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it

On Oct 25, 2009, at 2:50 AM, Terry Reedy wrote: Alex Martelli wrote: Next(s) would seem good... That does not work. It has to be next(iter(s)), and that has been tried and eliminated because it is significantly slower. But who cares about the speed of getting an arbitrary element from a

Re: [Python-Dev] Bug 7183 and Python 2.6.4

On Oct 22, 2009, at 3:53 PM, Robert Collins wrote: On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote: ... That being said, I can't this bug as a release blocker: people can either upgrade to super-current Boost, or stick with 2.6.2 until they can. Thats the challenge Ubuntu faces: http

Re: [Python-Dev] Bug 7183 and Python 2.6.4

On Oct 22, 2009, at 11:04 AM, Barry Warsaw wrote: On Oct 22, 2009, at 10:47 AM, Benjamin Peterson wrote: 2009/10/22 Barry Warsaw : So does anybody else think bug 7183 should be a release blocker for 2.6.4 final, or is even a legitimate but that we need to fix? I think it cannot hold up a

Re: [Python-Dev] Package install failures in 2.6.3

On Oct 5, 2009, at 2:21 PM, Brett Cannon wrote: I should also mention this bug was not unknown. I discovered it after Distribute 0.6 was released as I always run cutting edge interpreters. Never bothered to report it until Distribute 0.6.1 was released which Tarek fixed in less than a week.

Re: [Python-Dev] transitioning from % to {} formatting

On Oct 2, 2009, at 2:56 PM, Raymond Hettinger wrote: Do the users get any say in this? I imagine that some people are heavily invested in %-formatting. Because there has been limited uptake on {}-formatting (afaict), we still have limited experience with knowing that it is actually better, less

Re: [Python-Dev] transitioning from % to {} formatting

On Oct 1, 2009, at 6:19 PM, Steven Bethard wrote: I see how this could allow a user to supply a {}-format string to an API that accepts only %-format strings. But I still don't see the transition strategy for the API itself. That is, how does the %-format API use this to eventually switch to {}-f

Re: [Python-Dev] transitioning from % to {} formatting

On Oct 1, 2009, at 5:54 PM, Nick Coghlan wrote: I believe classes like fmt_braces/fmt_dollar/fmt_percent will be part of a solution, but they aren't a complete solution on their own. (Naming the three major string formatting techniques by the key symbols involved is a really good idea though

Re: [Python-Dev] transitioning from % to {} formatting

On Sep 30, 2009, at 1:01 PM, Antoine Pitrou wrote: Why not allow logging.Formatter to take a callable, which would in turn call the callable with keyword arguments? Therefore, you could write: logging.Formatter("{asctime} - {name} - {level} - {msg}".format) and then: logging.critical(name

Re: [Python-Dev] transitioning from % to {} formatting

On Oct 1, 2009, at 9:11 AM, Paul Moore wrote: This seems to me to be almost the same as the previous suggestion of having a string subclass: class BraceFormatter(str): def __mod__(self, other): # Needs more magic here to cope with dict argument return self.format(*other) __ =

Re: [Python-Dev] transitioning from % to {} formatting

On Sep 30, 2009, at 10:34 AM, Steven D'Aprano wrote: E.g. x = newstyle_formatstr("{} {} {}") x % (1,2,3) == x.format(1,2,3) == "1 2 3" Moving along, let's suppose the newstyle_formatstr is introduced. What's the intention then? Do we go through the std lib and replace every call to (say)

Re: [Python-Dev] transitioning from % to {} formatting

I'm resending a message I sent in June, since it seems the same thread has come up again, and I don't believe anybody actually responded (positively or negatively) to the suggestion back then. http://mail.python.org/pipermail/python-dev/2009-June/090176.html On Jun 21, 2009, at 5:40 PM, Eric

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4

On Sep 28, 2009, at 4:25 AM, M.-A. Lemburg wrote: Distributions should really not be put in charge of upstream coding design decisions. I don't think you can blame distros for this one From PEP 0261: It is also proposed that one day --enable-unicode will just default to the width o

Re: [Python-Dev] PEP 3144 review.

On Sep 27, 2009, at 3:18 PM, Peter Moody wrote: administrators) would use it, but it's doable. what you're claiming is that my use case is invalid. that's what I claim is broken. He's claiming your solution to address your use case is confusing, not that the use case is invalid. I'm not

Re: [Python-Dev] IO module precisions and exception hierarchy

On Sep 27, 2009, at 4:20 AM, Pascal Chambon wrote: Thus, at the moment IOErrors rather have the semantic of "particular case of OSError", and it's kind of confusing to have them remain in their own separate tree... Furthermore, OSErrors are often used where IOErrors would perfectly fit, eg.

Re: [Python-Dev] POSIX [Fuzziness in io module specs]

On Sep 18, 2009, at 8:58 PM, Antoine Pitrou wrote: I'm not sure that's true. Various Unix/Linux man pages are readily available on the Internet, but they regard specific implementations, which often depart from the spec in one way or another. POSIX specs themselves don't seem to be easily reachab

  1   2   3   >