Re: [Python-Dev] Type of range object members

On Aug 15, 2006, at 7:06 PM, Guido van Rossum wrote: >> There's no particular reason that a short int must be able to store >> the entire range of C "long", so, as many bits can be stolen from it >> as desired. > > There isn't? Actually a lot of APIs currently assumen that. I thought we were talki

Re: [Python-Dev] 2.4 & 2.5 beta 3 crash

On Aug 17, 2006, at 1:26 AM, Neal Norwitz wrote: > Thanks Dino. > > The attached patch should fix the problem. Once RC1 is cut, I'll > check this in unless someone beats me to it. Since the compiler > changed, I can't backport this. If someone wants to make a similar > fix for 2.4 go for it. Th

Re: [Python-Dev] Caching float(0.0)

On Oct 3, 2006, at 8:30 AM, Martin v. Löwis wrote: > As Michael Hudson observed, this is difficult to implement, though: > You can't distinguish between -0.0 and +0.0 easily, yet you should. Of course you can. It's absolutely trivial. The only part that's even *the least bit* sketchy in this is

Re: [Python-Dev] Caching float(0.0)

On Oct 3, 2006, at 2:26 PM, Nick Maclaren wrote: > =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <[EMAIL PROTECTED]> wrote: >> >> py> x=-0.0 >> py> y=0.0 >> py> x,y > > Nobody is denying that SOME C90 implementations distinguish them, > but it is no part of the standard - indeed, a C90 implementatio

Re: [Python-Dev] PEP 355 status

On Oct 25, 2006, at 10:48 PM, Talin wrote: > That's true of textual paths in general - i.e. even on unix, textual > paths aren't guaranteed to be unique or exist. > > Its been a while since I used classic MacOS - how do you handle things > like configuration files with path names in them? You aren

Re: [Python-Dev] Feature Request: Py_NewInterpreter to create separate GIL (branch)

On Nov 4, 2006, at 3:49 AM, Martin v. Löwis wrote: > Notice that at least the following objects are shared between > interpreters, as they are singletons: > - None, True, False, (), "", u"" > - strings of length 1, Unicode strings of length 1 with ord < 256 > - integers between -5 and 256 > How d

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater

On Jan 10, 2007, at 6:46 PM, Benji York wrote: > Paul Moore wrote: >> How many other projects/packages anticipate *not* migrating to >> Py3K, I wonder? > > I certainly can't speak for the project as a whole, but I anticipate a > fair bit of work to port Zope 3 (100+ KLOC) to Python 3.0. I (anot

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater

On Jan 11, 2007, at 8:12 PM, Anthony Baxter wrote: > I'm plan to try and make the transition as painless as possible. I'm glad to hear it. > The goal is to have a first alpha sometime this year - there is > absolutely no chance of a 3.0 final this year. Duly noted. >> Basically: my plea is: ple

Re: [Python-Dev] The bytes type

On Jan 12, 2007, at 7:26 PM, Ron Adam wrote: > For me, the thing that will make porting 2.x to 3.x code easy is to > make python > 3.0 as clean and organized as you can with excellent > documentation. Half-way > and duel-way approaches will probably not help me as much as this. > > Most of the

Re: [Python-Dev] The bytes type

On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote: >> The benefit (to me, and to many others) of 3.x over 2.x is the >> promise >> of getting rid of cruft. >> If we're going to re-add cruft for the sake of temporary >> compatibility, we may as well just stick with 2.x. You have to >> take a >>

Re: [Python-Dev] The bytes type

On Jan 16, 2007, at 12:06 PM, Phillip J. Eby wrote: > At 07:47 AM 1/16/2007 -0800, Guido van Rossum wrote: >> I'm not keen on compromises in 3.0, but without specific proposals I >> don't see why we're arguing. So, please, what specific thing(s) are >> you proposing we do in 3.0? Please make a list

Re: [Python-Dev] The bytes type

On Jan 16, 2007, at 10:47 AM, Guido van Rossum wrote: > I'm not keen on compromises in 3.0, but without specific proposals I > don't see why we're arguing. So, please, what specific thing(s) are > you proposing we do in 3.0? Please make a list of specifics rather > than attempting at specifying a g

Re: [Python-Dev] The bytes type

On Jan 16, 2007, at 2:35 PM, Guido van Rossum wrote: >> Mainly I'd just like to see "allowing the ability to write code which >> is portable between 2.5 and 3.0" as an explicit goal of the python >> 3.0 release. I trust that if the developers agree upon that as being >> a goal, the right things wo

Re: [Python-Dev] The bytes type

On Jan 17, 2007, at 6:22 PM, Anthony Baxter wrote: > On Wednesday 17 January 2007 05:52, James Y Knight wrote: >> Yes, this is it. As a refinement: if the New Way can easily be >> backported to 2.5, > > Um - 2.5 is _done_. Released. In maintenance mode. New features

Re: [Python-Dev] with_traceback

On Feb 28, 2007, at 9:10 PM, Guido van Rossum wrote: > I am beginning to think that there are serious problems with attaching > the traceback to the exception; I really don't like the answer that > pre-creating an exception is unpythonic in Py3k. I'll say up front that I haven't been paying as muc

Re: [Python-Dev] with_traceback

On Mar 1, 2007, at 3:27 AM, Greg Ewing wrote: > James Y Knight wrote: >> The traceback won't necessarily be *useful*, > > Almost completely use*less*, I would have thought. > The traceback is mostly used to find out where > something went wrong, not where it went right (

Re: [Python-Dev] New Super PEP

On Apr 28, 2007, at 10:43 PM, Calvin Spealman wrote: > Abstract > > > The PEP defines the proposal to enhance the super builtin to work > implicitly > upon the class within which it is used and upon the instance the > current > function was called on. The premise of the new super usag

Re: [Python-Dev] New Super PEP

On Apr 29, 2007, at 9:07 PM, Greg Ewing wrote: > Guido van Rossum wrote: > >> Nearly always wrong? You must be kidding. There are tons of >> reasons to >> call your super method with modified arguments. E.g. clipping, >> transforming, ... > > That's a good point. Just because the *signature* is t

Re: [Python-Dev] best practices stdlib: purging xrange

On May 8, 2007, at 8:49 AM, Armin Rigo wrote: > On Tue, May 08, 2007 at 09:14:02AM +1000, Anthony Baxter wrote: >> I'd like to suggest that we remove all (or nearly all) uses of >> xrange from the stdlib. A quick scan shows that most of the usage >> of it is unnecessary. With it going away in 3.0,

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] 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] 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 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] 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] 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] 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] 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] 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] 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] 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] [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 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] 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 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] 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] 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] 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] 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] 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] 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] 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] 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 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 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 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 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 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 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] [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] [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

[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] 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

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] 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] 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] 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] 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] 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] 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] 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] Proposal for a new function "open_noinherit" to avoid problems with subprocesses and security risks

On Jun 24, 2007, at 2:19 PM, Martin v. Löwis wrote: > I don't see why it is a requirement to *open* the file in > non-inheritable mode. Why is not sufficient to *modify* > an open file to have its handle non-inheritable in > an easy and platform-independent way? Threads. Consider that you may for

Re: [Python-Dev] Add a -z interpreter flag to execute a zip file

On Jul 12, 2007, at 1:58 PM, Phillip J. Eby wrote: > I don't have any particular objection to using runpy for this, but I > believe that this shebang line won't actually work on certain non-BSD > OSes, such as most Linux versions, which allow you to have at most > *one* argument to a #! line, and w

Re: [Python-Dev] Regular expressions, Unicode etc.

On Aug 8, 2007, at 3:47 PM, Nick Maclaren wrote: > Firstly, things like backreferences are an absolute no-no. They > are not regular, and REs with them in cannot be converted to DFAs. > That could be 'solved' by a parser that kicked out such constructions, > but it would get screams from many user

Re: [Python-Dev] [Python-3000] Python 3000 Sprint @ Google

On Aug 15, 2007, at 9:29 PM, Bill Janssen wrote: > I'd really like an excuse to implement server-side SSL support one of > these days. Could that be a sprint activity? Probably against 2.6 (I > doubt the Modules/_ssl.c file will change much for 3K). > > The idea is that if you call socket.ssl()

Re: [Python-Dev] Removing the GIL (Me, not you!)

On Sep 11, 2007, at 3:30 PM, Brett Cannon wrote: > We should probably document where all of these globals lists are > instead of relying on looking for all file level static declarations > or something. Or would there be benefit to moving things like this to > the interpreter struct so that thread

Re: [Python-Dev] Tracker summary emails

On Nov 21, 2007, at 5:58 PM, Paul Moore wrote: > Is it only me who thinks that the current daily summaries are a bit > frequent? Would it be possible to reduce the frequency to, say, once a > week? > > I can set up a filter to simply ditch the things, but I thought I'd > check what other people's v

Re: [Python-Dev] Python-Dev Digest, Vol 53, Issue 23

On Dec 9, 2007, at 5:52 AM, Giampaolo Rodola' wrote: >> def handle_expt(self): > > Like said above, this is called when arrived some OOB data. > I would change this into something like: "Called when some OOB data > arrived." Of course, that's not actually true. It's called for whatever the ex

Re: [Python-Dev] xmlrpclib and dates before 1900

On Apr 2, 2008, at 11:52 PM, Guido van Rossum wrote: > I'd like to see this fixed if possible, but I'm not sure how -- the C > level 'struct tm' has (year - 1900) in the tm_year member, and I'm not > sure that implementations are required to do anything with negative > values there. We'd have to re

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

On May 21, 2008, at 11:26 AM, Michael Foord wrote: And what about platforms like the JVM or CLR? Incidentally there were a small but vocal group of Pythonistas who were (are?) certain that IronPython is not Python because it doesn't have [all of...] the C extensions. It seems likely to b

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

On May 21, 2008, at 3:58 PM, Jean-Paul Calderone wrote: Plus, even if ctypes works, the code might be incorrect, because they had been assuming structure layouts and symbolic constants that have just a different definition on some other platform, causing the extension module to crash. Writing p

Re: [Python-Dev] UCS2/UCS4 default

On Jul 3, 2008, at 10:46 AM, Jeroen Ruigrok van der Werven wrote: -On [20080703 15:58], Guido van Rossum ([EMAIL PROTECTED]) wrote: Your seem to be suggesting that len(u"\U00012345") should return 1 on a system that internally uses UTF-16 and hence represents this string as a surrogate pair.

Re: [Python-Dev] small PATCH to fix os.fsync on OS X

On Aug 7, 2008, at 12:36 AM, Ian Charnas wrote: Hello heroes and heroins of the python universe, lend me your ears and I will tell you a tale that will make your platters spin! As noted by SQLite [1] and MySQL [2] developers, fsync on OS X does not actually flush a file to disk... instead OS X

Re: [Python-Dev] subprocess insufficiently platform-independent?

On Aug 25, 2008, at 9:52 PM, Greg Ewing wrote: Guido van Rossum wrote: If you call: subprocess.call(cmd, shell=False) Then it works on Linux, but fails on Windows because it does not perform the Windows %PATHEXT% search that allows it to find that "svn.exe" is the actual executable to be i

Re: [Python-Dev] FreeBSD 7 amd64 and large memory tests

On Sep 17, 2008, at 10:53 AM, Andrew MacIntyre wrote: Martin v. Löwis wrote: I haven't yet tried posting a query to a FreeBSD list, as it could simply be a bug on amd64, but I was wondering whether there was anything (other than deactivating tests and documenting use of ulimit -v on this p

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

On Sep 29, 2008, at 6:17 PM, Adam Olsen wrote: I suspect linux will eventually take this route as well. If ext3 had an option for UTF-8 validation I know I'd want it on. That'd move the error to the program creating bogus file names, rather than those trying to read, display, and manage them.

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

On Sep 30, 2008, at 5:40 PM, Martin v. Löwis wrote: On Windows, we might reject bytes filenames for all file operations: open(), unlink(), os.path.join(), etc. (raise a TypeError or UnicodeError) Since I've seen no objections to this yet: please no. If we offer a "lower-level" bytes filename

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

On Sep 30, 2008, at 6:21 PM, Martin v. Löwis wrote: IOW, Java hasn't solved the problem in the last 10 years. Java is already really bad at being a small little language to write cooperating tools in. I'd never even attempt to write a little pipeline filter in Java -- I've already pretty mu

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

On Sep 30, 2008, at 10:06 PM, [EMAIL PROTECTED] wrote: However, Martin, I can promise you that I will _never_ ask for any convenience functions related to bytes as a result of this decision. I want bytes to come back from filesystem APIs because I intend to have a wrapper layer which knows

Re: [Python-Dev] [Python-3000] Proposed Python 3.0 schedule

On Oct 6, 2008, at 8:52 PM, Benjamin Peterson wrote: I'm not sure we do. Correct me if I'm wrong, but the "big ticket", issue bytes/unicode filepaths, has been resolved. And looking at the tracker, I only see 18 release blockers. Well, if you mean that the resolution decided upon is to "simply

Re: [Python-Dev] [Python-3000] Proposed Python 3.0 schedule

On Oct 7, 2008, at 3:47 AM, Martin v. Löwis wrote: - Having os.getcwdb isn't much use when you can't even run python in the first place when the current directory has "bad" bytes in it. That's not true: it *is* of much use. Python will live in /usr/bin, which has a nicely-decodable path. Curr

Re: [Python-Dev] [Python-3000] Proposed Python 3.0 schedule

On Oct 7, 2008, at 4:45 PM, Adam Olsen wrote: So what does Qt do when given a file name already using those PUA? Looks like they get passed through untouched when decoded, but will get translated into invalid names upon encoding. Well, I'd say that looks like a bug. It should probably decode th

Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.

On Oct 30, 2008, at 1:31 PM, Eric Smith wrote: Guido van Rossum wrote: No offense taken. The V8 experience makes me feel much more optimistic that they might actually pull this off. (I'm still skeptical about support for extension modules, withougt which CPython is pretty lame.) The need

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Dec 4, 2008, at 6:39 PM, Martin v. Löwis wrote: I'm in favour of a different, fifth solution: 5) represent all environment variables in Unicode strings, including the ones that currently fail to decode. (then do the same to file names, then drop the byte-oriented file operations again)

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Dec 5, 2008, at 5:27 AM, Ulrich Eckhardt wrote: Using the byte variant is equally fubar, because e.g. on MS Windows it is not supported, except through a very lossy roundtrip through the locale's codepage, limiting your functionality. Yeah, IMO whole mess could have been avoided by keepin

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Dec 5, 2008, at 7:48 PM, Nick Coghlan wrote: You can't display a non-decodable filename to the user, hence the user will have no idea what they're working on. Non-filesystem related apps have no business trying to deal with insane filenames. Sigh, same arguments, all over again. Again, *bot

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Dec 9, 2008, at 6:04 AM, Anders J. Munch wrote: The typical application will just obliviously use os.listdir(dir) and get the default elide-and-warn behaviour for un-decodable names. That rare special application I guess this is a new definition of rare special application: "an applicat

Re: [Python-Dev] Forking and pipes

On Dec 9, 2008, at 2:26 PM, Lars Kotthoff wrote: Dear list, I recently noticed a python program which uses forks and pipes for communication between the processes not behaving as expected. The minimal example program: [snip] This prints out "foo" twice although it's only written once to

Re: [Python-Dev] datetime.date.today() raises "AttributeError: time"

On Dec 10, 2008, at 5:55 AM, Lennart Regebro wrote: Turns out, I created an empty time.py in /tmp, just to see the error message. By buildout will when creating eggs from checked out modules, copy them to a directory under /tmp, and evidently run python from /tmp to create the eggs. So that pro

Re: [Python-Dev] Trap SIGSEGV and SIGFPE

On Dec 11, 2008, at 11:08 AM, Jeffrey Yasskin wrote: On Thu, Dec 11, 2008 at 1:34 AM, Victor Stinner <[EMAIL PROTECTED]> wrote: But if -as many people wrote- Python is totally broken after a segfault, it is maybe not a good idea :-) While it's true that after a segfault or unexpected longj

Re: [Python-Dev] 2.4 news reaches interesting places

On Dec 9, 2004, at 1:31 PM, Phillip J. Eby wrote: Isn't it funny, by the way, that people don't go around talking about how slow Jython is? At least, I haven't seen it to the extent that I've seen with CPython. People talk about how slow CPython is, is because they are writing code targeted for

[Python-Dev] Re: super() harmful?

I'm not sure why super got dragged into this, but... On Jan 4, 2005, at 9:02 PM, Guido van Rossum wrote: I think that James Y Knight's page misrepresents the issue. Quoting: But __init__ *is* special, in that it is okay for a subclass __init__ (or __new__) to have a different signature than the ba

[Python-Dev] Re: super() harmful?

On Jan 5, 2005, at 1:23 PM, Guido van Rossum wrote: The issue of mixing super() and explicit calls to the superclass's method occur with any method. (Thus making it difficult/impossible for a framework to convert to using super without breaking client code that subclasses). Well, client classes wh

[Python-Dev] Re: super() harmful?

On Jan 5, 2005, at 6:36 PM, Guido van Rossum wrote: The idea of calling both __init__ methods doesn't work if there's a diamond; if there *is* a diamond (or could be one), using super() is the only sane solution. Very true. So then don't use it. You couldn't have diamonds at all before 2.2. With *c

Re: [Python-Dev] buffer objects [was: an idea for improving struct.unpack api]

On Jan 6, 2005, at 7:22 AM, Thomas Heller wrote: (*) Which brings me to the questions I have in my mind for quite some time: Why is readinto undocumented, and what about the status of the buffer object: do the recent fixes to the buffer object change it's status? I, for one, would be very unhappy i

Re: [Python-Dev] Re: super() harmful?

On Jan 6, 2005, at 5:45 PM, Delaney, Timothy C (Timothy) wrote: Well, there's my autosuper recipe you've seen before: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/286195 which does basically what Philip descibes ... You missed the most important part of the example -- the automatic argu

[Python-Dev] Re: super() harmful?

On Jan 6, 2005, at 12:13 PM, Guido van Rossum wrote: So it has nothing to do with the new paradigm, just with backwards compatibility. I appreciate those issues (more than you'll ever know) but I don't see why you should try to discourage others from using the new paradigm, which is what your artic

Re: [Python-Dev] Concurrency and Python

On Jan 7, 2005, at 2:44 PM, Edward C. Jones wrote: Is Python a suitable language for concurrent programming? Depends on what you mean. Python is not very good for shared-memory concurrent programming. (That is, threads). The library doesn't have enough good abstractions for locks/synchronizatio

Re: [Python-Dev] PEP 246, redux

I'd just like to share a use case for transitive adaption that I've just run into (I'm using Zope.Interface which does not support it). Make of this what you will, I just thought an actual example where transitive adaption is actually necessary might be useful to the discussion. I have a frame

Re: [Python-Dev] PEP 246, redux

On Jan 13, 2005, at 12:46 PM, Clark C. Evans wrote: My current suggestion to make 'transitive adaption' easy for a application builder (one putting togeher components) has a few small parts: - If an adaptation is not found, raise an error, but list in the error message two additional things:

Re: [Python-Dev] PEP 246: lossless and stateless

On Jan 15, 2005, at 6:02 PM, Simon Percivall wrote: On 2005-01-15, at 23.50, Just van Rossum wrote: Phillip J. Eby wrote: But it _does_ perform an implicit adaptation, via PyObject_GetIter. First, that's not implicit. Second, it's not adaptation, either. PyObject_GetIter invokes the '__iter__' met

<    1   2   3   >