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

On Jan 7, 2005, at 9:33 AM, Thomas Heller wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: This is my ctypes-like attempt at a high-level interface for struct. It works well for me in macholib: http://svn.red-bean.com/bob/py2app/trunk/src/macholib/ptypes.py Michael Hudson <[EMAIL

Re: [Python-Dev] PEP 246, redux

On Jan 10, 2005, at 16:38, Phillip J. Eby wrote: At 07:42 PM 1/10/05 +0100, Alex Martelli wrote: On 2005 Jan 10, at 18:43, Phillip J. Eby wrote: ... I am not saying we shouldn't have a tp_conform; just suggesting that it may be appropriate for functions and modules (as well as classic classes)

Re: [Python-Dev] Re: [Csv] csv module and universal newlines

On Jan 12, 2005, at 21:39, Skip Montanaro wrote: Jack> On MacOSX you really want universal newlines. CSV files produced Jack> by older software (such as AppleWorks) will have \r line Jack> terminators, but lots of other programs will have files with Jack> normal \n terminators. Wo

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

On Jan 13, 2005, at 20:03, Clark C. Evans wrote: Ok. I think we have identified two sorts of restrictions on the sorts of adaptations one may want to have: `stateless' the adaptation may only provide a result which does not maintain its own state `lossless' the adaptation pre

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

On Jan 14, 2005, at 19:02, Glyph Lefkowitz wrote: On Fri, 2005-01-14 at 10:07 -0500, Phillip J. Eby wrote: Maybe I'm missing something, but for those interfaces, isn't it okay to keep the state in the *adapted* object here? In other words, if PointPen just added some private attributes to store

Re: [Python-Dev] Getting rid of unbound methods: patch available

On Jan 17, 2005, at 18:33, Glyph Lefkowitz wrote: It's not the strongest use-case in the world, but is the impetus to remove unbound method objects from Python that much stronger? I like the fact that it's simpler, but it's a small amount of extra simplicity, it doesn't seem to enable any new use

Re: [Python-Dev] __str__ vs. __unicode__

On Jan 19, 2005, at 4:40, Walter Dörwald wrote: M.-A. Lemburg wrote: Walter Dörwald wrote: __str__ and __unicode__ seem to behave differently. A __str__ overwrite in a str subclass is used when calling str(), a __unicode__ overwrite in a unicode subclass is *not* used when calling unicode(): [...]

Re: [Python-Dev] Unix line endings required for PyRun* breaking embedded Python

On Jan 21, 2005, at 7:44, Jack Jansen wrote: On 21 Jan 2005, at 08:18, Stuart Bishop wrote: Just van Rossum wrote: Skip Montanaro wrote: Just re.sub("[\r\n]+", "\n", s) and I think you're good to go. I don't think that in general you want to fold multiple empty lines into one. This would be my pre

Re: [Python-Dev] Re: [PyCON-Organizers] PyCon: The Spam Continues ; -)

On Jan 25, 2005, at 12:29, David Ascher wrote: Steve Holden wrote: Modulo some SQLServer features we're using. Well free-text indexing would be my first guess. Anything else of interest? MySQL's free text indexing really sucks compared with SQL Server's, which to my mind is a good justification f

Re: [Python-Dev] Should Python's library modules be written to help the freeze tools?

On Jan 30, 2005, at 5:50 PM, Martin v. Löwis wrote: Tony Meyer wrote: The main question (to steal Thomas's words) is whether the library modules should be written to help the freeze tools - if the answer is 'yes', then I'll submit the above as a patch for 2.5. The answer to this question certa

Re: Moving towards Python 3.0 (was Re: [Python-Dev] Speed up function calls)

On Jan 31, 2005, at 10:43, Evan Jones wrote: On Jan 31, 2005, at 0:17, Guido van Rossum wrote: The "just kidding" applies to the whole list, right? None of these strike me as good ideas, except for improvements to function argument passing. Really? You see no advantage to moving to garbage collecti

Re: [Python-Dev] Patch review: [ 1098732 ] Enhance tracebacks and stack traces with vars

On Feb 9, 2005, at 6:25 PM, Michael Hudson wrote: "Phillip J. Eby" <[EMAIL PROTECTED]> writes: At 08:20 PM 2/9/05 +0100, BJörn Lindqvist wrote: Does Skip's idea have any merit? Yes, but not as a default behavior. Many people already consider the fact that tracebacks display file paths to be a pote

Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

On Feb 10, 2005, at 9:15 PM, Donovan Baarda wrote: On Tue, 2005-02-08 at 11:52 -0800, Gregory P. Smith wrote: The md5.h/md5c.c files allow "copy and use", but no modification of the files. There are some alternative implementations, i.e. in glibc, openssl, so a replacement should be sage. Any other

Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

On Feb 10, 2005, at 9:50 PM, Donovan Baarda wrote: On Thu, 2005-02-10 at 21:30 -0500, Bob Ippolito wrote: On Feb 10, 2005, at 9:15 PM, Donovan Baarda wrote: On Tue, 2005-02-08 at 11:52 -0800, Gregory P. Smith wrote: [...] One possible alternative would be to bring in something like PyOpenSSL <h

Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

On Feb 11, 2005, at 6:11 PM, Donovan Baarda wrote: G'day again, From: "Gregory P. Smith" <[EMAIL PROTECTED]> I think it would be cleaner and simpler to modify the existing md5module.c to use the openssl md5 layer API (this is just a search/replace to change the function names). The bigger problem i

Re: [Python-Dev] subclassing PyCFunction_Type

On Feb 16, 2005, at 11:02, Phillip J. Eby wrote: At 02:32 PM 2/11/05 -0800, Nick Rasmussen wrote: tommy said that this would be the best place to ask this question I'm trying to get functions wrapped via boost to show up as builtin types so that pydoc includes them when documenting the module c

Re: [Python-Dev] subclassing PyCFunction_Type

On Feb 16, 2005, at 11:43, Phillip J. Eby wrote: At 11:26 AM 2/16/05 -0500, Bob Ippolito wrote: >>> help(FakeBuiltin("name", "name(foo, bar, baz) -> rval")) Help on built-in function name: name(...) name(foo, bar, baz) -> rval If you wanted to be ev

Re: [Python-Dev] Fixing _PyEval_SliceIndex so that integer-like objects can be used

On Feb 18, 2005, at 4:36 PM, David Ascher wrote: On Fri, 18 Feb 2005 13:28:34 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: Would it be possible to change _PyEval_SliceIndex in ceval.c so that rather than throwing an error if the indexing object is not an integer, the code first checks to se

Re: [Python-Dev] rationale for the no-new-features approach

On Mar 9, 2005, at 8:03 AM, Skip Montanaro wrote: Anthony> Goal 4: Try and prevent something like Anthony> try: Anthony> True, False Anthony> except NameError: Anthony> True, False = 1, 0 Anthony> from e

Re: [Python-Dev] rationale for the no-new-features approach

On Mar 10, 2005, at 11:46 PM, Glyph Lefkowitz wrote: Bob Ippolito wrote: try: set except NameError: from sets import Set as set Syntactical variations notwithstanding, I think it's a common desire to want to run on at least the last few versions of Python, but take advanta

Re: [Python-Dev] rationale for the no-new-features approach

On Mar 11, 2005, at 2:26 PM, Skip Montanaro wrote: Bob> try: Bob> set Bob> except NameError: Bob> from sets import Set as set Bob> You don't need the rest. Sure, but then pychecker bitches about a statement that appears to have no effect. ;-) Well then fix PyChecker t

Re: [Python-Dev] itertools.walk()

On Mar 16, 2005, at 6:19, Raymond Hettinger wrote: Some folks on comp.lang.python have been pushing for itertools to include a flatten() operation. Unless you guys have some thoughts on the subject, I'm inclined to accept the request. Rather than calling it flatten(), it would be called "walk" and

Re: [Python-Dev] itertools.walk()

On Mar 16, 2005, at 8:37 AM, Nick Coghlan wrote: Bob Ippolito wrote: On Mar 16, 2005, at 6:19, Raymond Hettinger wrote: Some folks on comp.lang.python have been pushing for itertools to include a flatten() operation. Unless you guys have some thoughts on the subject, I'm inclined to accep

Re: [Python-Dev] Re: Shorthand for lambda

On Mar 23, 2005, at 1:16 PM, Ka-Ping Yee wrote: On Wed, 23 Mar 2005, Reinhold Birkenfeld wrote: What does you implementation do for this: somevar = False filter(_ and False, numbers) It fails. (For the same reason that __len__ doesn't work -- Python insists that __nonzero__ must return an int.) T

Re: [Python-Dev] Using descriptors to dynamically attach methods written in Python to C-defined (new-style) types

On Mar 25, 2005, at 6:13 PM, Travis Oliphant wrote: In updating Numeric to take advantage of the new features in Python, I've come across the need to attach a Python-written function as a method to a C-builtin. I don't want to inherit, I just want to extend the methods of a builtin type using a

Re: [Python-Dev] using SCons to build Python

On Mar 29, 2005, at 5:15 PM, Aahz wrote: On Sun, Mar 27, 2005, Adam MacBeth wrote: Has anyone ever considered using SCons to build Python? SCons is a great build tool written in Python that provides some Autoconf-like functionality (http://www.scons.org). It seems like this type of self-hosting wou

Re: [Python-Dev] threading (GilState) question

On Apr 9, 2005, at 11:15 AM, Michael Hudson wrote: "Gregory P. Smith" <[EMAIL PROTECTED]> writes: Under "Limitations and Exclusions" it specifically disowns responsibility for worrying about whether Py_Initialize() and PyEval_InitThreads() have been called: [snip quote] This suggests that I should

Re: [Python-Dev] threading (GilState) question

On Apr 10, 2005, at 2:48 PM, Michael Hudson wrote: James Y Knight <[EMAIL PROTECTED]> writes: On Apr 10, 2005, at 11:22 AM, Michael Hudson wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: Is there a good reason to *not* call PyEval_InitThreads when using a threaded Python? Well, it

Re: [Python-Dev] threading (GilState) question

On Apr 10, 2005, at 4:08 PM, Michael Hudson wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: On Apr 10, 2005, at 2:48 PM, Michael Hudson wrote: James Y Knight <[EMAIL PROTECTED]> writes: Here's the numbers. It looks like something changed between python 2.2 and 2.3

Re: [Python-Dev] Re: Re: Re: marshal / unmarshal

On Apr 11, 2005, at 12:33 AM, Fredrik Lundh wrote: Tim Peters wrote: [Fredrik Lundh] is changing the marshal format really the right thing to do at this point? I don't see anything special about "this point" -- it's just sometime between 2.4.1 and 2.5a0. What do you have in mind? I was under the i

Re: [Python-Dev] Unified or context diffs?

On Apr 13, 2005, at 11:17 PM, Anthony Baxter wrote: On Thursday 14 April 2005 07:26, Brett C. wrote: OK, it seems like everyone who cares enough to speak up has said so far that unified diffs are better I will change the docs some time between now and when I keel over dead to have people use unif

Re: [Python-Dev] Re: anonymous blocks

On Apr 21, 2005, at 6:28 AM, Fredrik Lundh wrote: Glyph Lefkowitz wrote: Despite being guilty of propagating this style for years myself, I have to disagree. Consider the following network-conversation using Twisted style (which, I might add, would be generalizable to other Twisted-like systems

Re: [Python-Dev] anonymous blocks (don't combine them with generator finalization)

On Apr 21, 2005, at 8:59 PM, Josiah Carlson wrote: Guido van Rossum <[EMAIL PROTECTED]> wrote: [Brett] I think I agree with Samuele that it would be more pertinent to put all of this effort into trying to come up with some way to handle cleanup in a generator. I.e. PEP 325. But (as I explained, a

Re: [Python-Dev] anonymous blocks (don't combine them with generator finalization)

On Apr 22, 2005, at 12:28 AM, Brett C. wrote: Bob Ippolito wrote: On Apr 21, 2005, at 8:59 PM, Josiah Carlson wrote: Guido van Rossum <[EMAIL PROTECTED]> wrote: [Brett] I think I agree with Samuele that it would be more pertinent to put all of this effort into trying to come up with some

[Python-Dev] site enhancements (request for review)

A few weeks ago I put together a patch to site.py for Python 2.5 that solves three major deficiencies: (1) All site dirs must exist on the filesystem: Since PEP 302 (New Import Hooks) was adopted, this is not necessarily true. sys.meta_path and sys.path_hooks can ha

[Python-Dev] zipfile still has 2GB boundary bug

The "2GB bug" that was supposed to be fixed in was not actually fixed. The zipinfo offsets in the structures are still signed longs, so the fix allows you to write one file that extends past the 2G boundary, but if any extend past that point you are screwed. I ha

Re: [Python-Dev] Re: anonymous blocks

On Apr 24, 2005, at 11:32 PM, Phillip J. Eby wrote: At 04:57 PM 4/24/05 -0700, Guido van Rossum wrote: So a block could return a value to the generator using a return statement; the generator can catch this by catching ReturnFlow. (Syntactic sugar could be "VAR = yield ..." like in Ruby.) [uncontro

Re: [Python-Dev] Re: anonymous blocks

On Apr 24, 2005, at 11:57 PM, Phillip J. Eby wrote: At 11:39 PM 4/24/05 -0400, Bob Ippolito wrote: On Apr 24, 2005, at 11:32 PM, Phillip J. Eby wrote: At 04:57 PM 4/24/05 -0700, Guido van Rossum wrote: So a block could return a value to the generator using a return statement; the generator can

[Python-Dev] Re: [Pythonmac-SIG] zipfile still has 2GB boundary bug

On Apr 25, 2005, at 7:53 AM, Charles Hartman wrote: Someone should think about rewriting the zipfile module to be less hideous, include a repair feature, and be up to date with the latest specifications . -- and allow *deleting* a file from a zipf

Re: [Python-Dev] site enhancements (request for review)

On Apr 26, 2005, at 1:12 AM, Greg Ewing wrote: Bob Ippolito wrote: A few weeks ago I put together a patch to site.py for Python 2.5 <http://python.org/sf/1174614> that solves three major deficiencies: > > [concerning .pth files] While we're on the subject of .pth files, what

Re: [Python-Dev] Re: [Pythonmac-SIG] zipfile still has 2GB boundary bug

On Apr 26, 2005, at 8:24 PM, Guido van Rossum wrote: Someone should think about rewriting the zipfile module to be less hideous, include a repair feature, and be up to date with the latest specifications . -- and allow *deleting* a file from a zipfi

Re: [Python-Dev] PEP 340: propose to get rid of 'as' keyword

On May 4, 2005, at 2:29 PM, Fredrik Lundh wrote: > Gustavo J. A. M. Carneiro wrote: > > >> I have not read every email about this subject, so sorry if this >> has >> already been mentioned. >> >> In PEP 340 I read: >> >> block EXPR1 as VAR1: >> BLOCK1 >> >> I think it

Re: [Python-Dev] New Py_UNICODE doc

On May 6, 2005, at 7:05 PM, Shane Hathaway wrote: > Nicholas Bastin wrote: > >> On May 6, 2005, at 5:21 PM, Shane Hathaway wrote: >> >>> Wait... are you saying a Py_UNICODE array contains either UTF-16 or >>> UTF-32 characters, but never UCS-2? That's a big surprise to >>> me. I may >>> need t

Re: [Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340

On May 7, 2005, at 1:45 AM, Michele Simionato wrote: > On 5/6/05, Steven Bethard <[EMAIL PROTECTED]> wrote: > >> FWIW, I'm +1 on this. Enhanced Iterators >> * updates the iterator protocol to use .__next__() instead >> of .next() >> * introduces a new builtin next() >> * allows continue-stat

Re: [Python-Dev] Python's Unicode width default (New Py_UNICODE doc)

On May 14, 2005, at 3:05 PM, Shane Hathaway wrote: > M.-A. Lemburg wrote: > >> It is important to be able to rely on a default that >> is used when no special options are given. The decision >> to use UCS2 or UCS4 is much too important to be >> left to a configure script. >> > > Should the choice

Re: [Python-Dev] Example for PEP 343

On May 17, 2005, at 9:02 PM, Raymond Hettinger wrote: >>> What's the advantage of using two calls to getcontext() vs. saving >>> > the > >>> context in a local variable? >>> >> >> I also prefer saving the context in a local variable but that is just >> > a > >> micro-optimization. The presentati

Re: [Python-Dev] Example for PEP 343

On May 17, 2005, at 10:36 PM, Guido van Rossum wrote: > On 5/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > >>> I think you're missing a decimal.setcontext(newcontext) before the >>> yield.. >>> >> >> Right. >> > > I don't see a call to setcontext() in the sin() example in the library > re

Re: [Python-Dev] Example for PEP 343

On May 17, 2005, at 11:39 PM, Guido van Rossum wrote: > [Raymond Hettinger] > >> However, for a general purpose wrapper, it is preferable to make a >> context copy and then restore the context after the enclosed is run. >> That guards against the enclosed block making any unexpected context >> ch

Re: [Python-Dev] sys.path in interactive session

On Jun 2, 2005, at 4:50 PM, Guido van Rossum wrote: > On 6/2/05, Reinhold Birkenfeld [EMAIL PROTECTED]> wrote: > >> While looking at bug #779191, I saw that sys.path's first element >> is '' in interactive sessions, but the current dir otherwise. Is this >> intentional? >> > > I've always liked i

Re: [Python-Dev] Thoughts on stdlib evolvement

On Jun 6, 2005, at 3:10 PM, Raymond Hettinger wrote: >>> If Fred were up for it, I think ElementTree would be a wonderful, >>> must-have addition. >>> > > > >> I might be missing fine details of the English language here >> (what does "to be up for something" mean?), however, I believe >> Element

Re: [Python-Dev] Thoughts on stdlib evolvement

On Jun 7, 2005, at 11:47 AM, Josiah Carlson wrote: > Ron Adam wrote: > [snip] > >> Having less in the core distribution means smaller complete >> applications >> to install when py2exe is used. There also needs to be some >> assurance >> that the standard library has as few bugs in it as pos

Re: [Python-Dev] Wishlist: dowhile

On Jun 13, 2005, at 10:20 PM, Greg Ewing wrote: > Phillip J. Eby wrote: > > >> By the way, whatever happened to "and while"? i.e.: >> >> while True: >> data = inp.read(blocksize) >> and while data: >> out.write(data) >> > > My favourite version of this is > >while

Re: [Python-Dev] Wishlist: dowhile

On Jun 14, 2005, at 1:25 AM, Raymond Hettinger wrote: By the way, whatever happened to "and while"? i.e.: while True: data = inp.read(blocksize) and while data: out.write(data) >>> >>> My favourite version of this is >>> >>>

Re: [Python-Dev] Wishlist: dowhile

On Jun 14, 2005, at 2:25 AM, Raymond Hettinger wrote: >> def readby(inp, blocksize=1024): >> while True: >> data = inp.read(blocksize) >> if not data: >> break >> yield data >> >> for data in readby(inp, blocksize): >> . . . >> > > readby() relies

Re: [Python-Dev] PEP 304 - is anyone really interested?

On Jun 23, 2005, at 10:11 PM, Greg Ewing wrote: > Skip Montanaro wrote: > >> I wrote PEP 304, "Controlling Generation of Bytecode Files": >> >> http://www.python.org/peps/pep-0304.html >> > > I would like to see some way of having bytecode files put > into platform/version dependent subdirecto

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

On Jun 26, 2005, at 8:54 PM, Phillip J. Eby wrote: > At 12:22 AM 6/27/2005 +0200, Dörwald Walter wrote: > >> Phillip J. Eby wrote: >> >>> [...] >>> I'm also not keen on the fact that it makes certain things >>> properties whose value can change over time; i.e. ctime/mtime/atime >>> and >>> size r

Re: [Python-Dev] Possible C API problem?

On Jun 27, 2005, at 6:48 PM, Delaney, Timothy (Tim) wrote: > Gary Robinson wrote: > > >> It's been around 7 years since I've used C, I've forgotten virtually >> everything I may have known about gdb, I've never worked with the >> C-python API before... meanwhile there is intense time pressure to

Re: [Python-Dev] Triple-quoted strings and indentation

On Jul 10, 2005, at 6:39 PM, Josiah Carlson wrote: > > Andrew Durdin <[EMAIL PROTECTED]> wrote: > >> >> On 7/11/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: >> >>> >>> You are wrong. Current string literals are explicit. They are >>> what you >>> type. >>> >> >> No they are not: >> > > Appar

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

On Jul 28, 2005, at 3:19 PM, Barry Warsaw wrote: > On Thu, 2005-07-28 at 20:15, Leif Hedstrom wrote: > > >> I'm definitely positive to a migration to Subversion, but I'd be >> really >> concerned about using plain text authentication mechanisms. >> > > We won't use plain text, but we may (or, w

Re: [Python-Dev] Generalised String Coercion

On Aug 7, 2005, at 7:37 PM, Martin v. Löwis wrote: > Guido van Rossum wrote: > >>> If stdin, stdout and stderr go to a terminal, there already is a >>> default encoding (actually, there always is a default encoding on >>> these, as it falls back to the system encoding if its not a >>> terminal,

Re: [Python-Dev] pdb: should next command be extended?

On Aug 11, 2005, at 3:02 PM, Anthony Baxter wrote: > On Monday 08 August 2005 20:13, Ilya Sandler wrote: > >>> At OSCON, Anthony Baxter made the point that pdb is currently one >>> of the >>> more unPythonic modules. >>> >> >> What is unpythonic about pdb? Is this part of Anthony's presentation

Re: [Python-Dev] PEP 347: Migration to Subversion

On Aug 20, 2005, at 6:14 AM, Guido van Rossum wrote: > I'm ready to accept te general idea of moving to subversion and away > from SourceForge. > > On the hosting issue, I'm still neutral -- I expect we'll be able to > support the current developer crowd easily on svn.python.org, but if > we ever

Re: [Python-Dev] Replacement for print in Python 3.0

On Sep 1, 2005, at 2:27 PM, Jack Diederich wrote: > On Thu, Sep 01, 2005 at 11:12:57PM +0200, Fredrik Lundh wrote: > >> Charles Cazabon wrote: >> >> >>> in fact, it does nothing for the program but merely has the >>> interesting >>> side-effect of writing to stdout. >>> >> >> yeah, real program

Re: [Python-Dev] reference counting in Py3K

On Sep 6, 2005, at 12:13 PM, Steve Holden wrote: > Nick Jacobson wrote: > >> While we're on the subject of Python 3000, what's the >> chance that reference counting when calling C >> functions from Python will go away? >> >> To me this is one of the few annoyances I have with >> Python. I know t

Re: [Python-Dev] Replacement for print in Python 3.0

On Sep 7, 2005, at 7:11 AM, Guido van Rossum wrote: > On 9/7/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > >> On Wed, 2005-09-07 at 05:23, Stephen J. Turnbull wrote: >> >> >>> But print-ng looks >>> like becoming the OOWTDI for a lot of applications. IMO it's >>> just too >>> early to give up

Re: [Python-Dev] Replacement for print in Python 3.0

On Sep 8, 2005, at 5:42 AM, Barry Warsaw wrote: > On Wed, 2005-09-07 at 15:07, Bob Ippolito wrote: > > >> I was also able to easily automate the process of extracting strings >> to create that spreadsheet. I wrote a simple script that parsed the >> Python modules an

Re: [Python-Dev] GIL, Python 3, and MP vs. UP

On Sep 20, 2005, at 5:43 PM, Guido van Rossum wrote: > On 9/20/05, John J Lee <[EMAIL PROTECTED]> wrote: > >> threading is not the only, nor the best, concurrency model. >> But maybe these chips designed with threading in mind blow that >> argument >> out of the water. I don't know enough to k

Re: [Python-Dev] Mapping Darwin 8.2.0 to Mac OS X 10.4.2 in platform.py

On Sep 21, 2005, at 11:26 PM, Guido van Rossum wrote: > The platform module has a way to map system names such as returned by > uname() to marketing names. It maps SunOS to Solaris, for example. But > it doesn't map Darwin to Mac OS X. I think I know how to map Darwin > version numbers to OS X ver

Re: [Python-Dev] Mapping Darwin 8.2.0 to Mac OS X 10.4.2 in platform.py

/usr/bin/sw_vers technically calls a private (at least undocumented) CoreFoundation API, it doesn't parse that plist directly :) On further inspection, it looks like parsing the plist directly is supported API these days (see the bottom of ): import plistlib dct = plistlib.Plist.fromFile('/Sy

Re: [Python-Dev] vendor-packages directory

On Sep 22, 2005, at 3:56 PM, Phillip J. Eby wrote: > At 12:04 PM 9/22/2005 -0700, Rich Burridge wrote: > >> Phillip J. Eby wrote: >> Recently I asked about the inclusion of a "vendor-packages" directory for Python on the Python mailing list. See the thread started at: >>>

Re: [Python-Dev] vendor-packages directory

On Sep 22, 2005, at 3:04 PM, Rich Burridge wrote: > Phillip J. Eby wrote: > >>> Recently I asked about the inclusion of a "vendor-packages" >>> directory for Python on the Python mailing list. >>> >>> See the thread started at: >>> >>> >>> http://mail.python.org/pipermail/python-list/2005-Septemb

Re: [Python-Dev] os.path.diff(path1, path2) (and a first post)

On Sep 22, 2005, at 8:58 PM, Trent Mick wrote: > [richard barran wrote] > >> So I have a question: do the previous mails mean that a relpath >> function might possibly be a usefull addition to os.path? >> > > Yes, it seems to have support. I'd like to throw in another late +1 here, I've written

Re: [Python-Dev] C API doc fix

On Sep 29, 2005, at 3:53 PM, M.-A. Lemburg wrote: > Perhaps a flag that fires up Python and runs platform.py > would help too. python -mplatform -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] Dropping bytes "support" in json

On Thu, Apr 9, 2009 at 1:05 PM, "Martin v. Löwis" wrote: >>> I can understand that you don't want to spend much time on it. How >>> about removing it from 3.1? We could re-add it when long-term support >>> becomes more likely. >> >> I'm speechless. > > It seems that my statement has surprised you,

Re: [Python-Dev] Dropping bytes "support" in json

On Fri, Apr 10, 2009 at 8:38 AM, Stephen J. Turnbull wrote: > Paul Moore writes: > >  > On the other hand, further down in the document: >  > >  > """ >  > 3.  Encoding >  > >  >    JSON text SHALL be encoded in Unicode.  The default encoding is >  >    UTF-8. >  > >  >    Since the first two char

Re: [Python-Dev] Dropping bytes "support" in json

On Mon, Apr 13, 2009 at 1:02 PM, "Martin v. Löwis" wrote: >> Yes, there's a TCP connection.  Sorry for not making that clear to begin >> with. >> >>     If so, it doesn't matter what representation these implementations chose >>     to use. >> >> >> True, I can always convert from bytes to str or

Re: [Python-Dev] Dropping bytes "support" in json

On Mon, Apr 27, 2009 at 7:25 AM, Damien Diederen wrote: > > Antoine Pitrou writes: >> Hello, >> >> We're in the process of forward-porting the recent (massive) json >> updates to 3.1, and we are also thinking of dropping remnants of >> support of the bytes type in the json library (in 3.1, again)

Re: [Python-Dev] Cost-Free Slice into FromString constructors--Long

On May 25, 2006, at 3:28 PM, Jean-Paul Calderone wrote: > On Thu, 25 May 2006 15:01:36 +, Runar Petursson > <[EMAIL PROTECTED]> wrote: >> We've been talking this week about ideas for speeding up the >> parsing of >> Longs coming out of files or network. The use case is having a >> larg

[Python-Dev] Returning int instead of long from struct when possible for performance

Python ints are a heck of a lot faster to work with than Python longs and have the additional benefit that psyco can optimize the hell out of int but can't do anything at all for long. This is important because psyco is currently in pretty wide-spread use amongst people who need to squeeze

Re: [Python-Dev] SQLite header scan order

On May 26, 2006, at 8:35 AM, Ronald Oussoren wrote: > The current version of setup.py looks for the sqlite header files in > a number of sqlite-specific directories before looking into the > default inc_dirs. I'd like to revert that order because that would > make it possible to override the vers

Re: [Python-Dev] [Python-checkins] r46300 - in python/trunk: Lib/socket.py Lib/test/test_socket.py Lib/test/test_struct.py Modules/_struct.c Modules/arraymodule.c Modules/socketmodule.c

On May 26, 2006, at 4:56 PM, Guido van Rossum wrote: > On 5/26/06, martin.blais <[EMAIL PROTECTED]> wrote: >> Log: >> Support for buffer protocol for socket and struct. >> >> * Added socket.recv_buf() and socket.recvfrom_buf() methods, that >> use the buffer >> protocol (send and sendto alread

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 28, 2006, at 4:31 AM, Thomas Wouters wrote: > > I'm seeing a dubious failure of test_gzip and test_tarfile on my > AMD64 machine. It's triggered by the recent struct changes, but I'd > say it's probably caused by a bug/misfeature in zlibmodule: > zlib.crc32 is the result of a zlib 'c

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 28, 2006, at 5:34 PM, Thomas Wouters wrote:On 5/29/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: On May 28, 2006, at 4:31 AM, Thomas Wouters wrote:>> I'm seeing a dubious failure of test_gzip and test_tarfile on my> AMD64 machine. It's triggered by the recent struct c

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 29, 2006, at 3:14 AM, Thomas Wouters wrote:On 5/29/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: Well, the behavior change is in response to a bug <http://python.org/sf/1229380>. If nothing else, we should at least fix the standard library such that it doesn't depend on str

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 29, 2006, at 12:44 PM, Guido van Rossum wrote: > On 5/29/06, Tim Peters <[EMAIL PROTECTED]> wrote: >>> I think we should do as Thomas proposes: plan to make it an error in >>> 2.6 (or 2.7 if there's a big outcry, which I don't expect) and >>> accept >>> it with a warning in 2.5. >> >> Th

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 29, 2006, at 1:18 PM, Bob Ippolito wrote: > > On May 29, 2006, at 12:44 PM, Guido van Rossum wrote: > >> On 5/29/06, Tim Peters <[EMAIL PROTECTED]> wrote: >>>> I think we should do as Thomas proposes: plan to make it an >>>> error in >

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 29, 2006, at 4:35 PM, Delaney, Timothy (Tim) wrote: > Thomas Wouters wrote: > >> If 2.5 warns and does the old thing, the upgrade path is easy and >> defendable. This is also why there are future statements -- I >> distinctly recall making the same argument back then :-) The cost of >> con

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 29, 2006, at 8:00 PM, Tim Peters wrote: > [Bob Ippolito] >>> ... >>> Actually, should this be a FutureWarning or a DeprecationWarning? > > Since it was never documented, UndocumentedBugGoingAwayError ;-) > Short of that, yes, DeprecationWarning. FutureW

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 30, 2006, at 2:41 AM, Nick Coghlan wrote: > Bob Ippolito wrote: >> On May 29, 2006, at 8:00 PM, Tim Peters wrote: >>> We certainly don't want to see two deprecation warnings for a single >>> deprecated behavior. I suggest eliminating the "struct

[Python-Dev] Converting crc32 functions to use unsigned

It seems that we should convert the crc32 functions in binascii, zlib, etc. to deal with unsigned integers. Currently it seems that 32- bit and 64-bit platforms are going to have different results for these functions. Should we do the same as the struct module, and do DeprecationWarning whe

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 30, 2006, at 10:47 AM, Tim Peters wrote: > [Bob Ippolito] >> What should it be called instead of wrapping? > > I don't know -- I don't know what it's trying to _say_ that isn't > already said by saying that the input is out of bounds for the form

Re: [Python-Dev] Converting crc32 functions to use unsigned

On May 30, 2006, at 11:19 AM, Guido van Rossum wrote: > On 5/30/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote: >> Bob Ippolito wrote: >> >> > It seems that we should convert the crc32 functions in binascii, >> > zlib, etc. to deal with unsigned integers. >&

Re: [Python-Dev] test_struct failure on 64 bit platforms

On May 31, 2006, at 12:49 AM, Neal Norwitz wrote: > Bob, > > There are a couple of things I don't understand about the new struct. > Below is a test that fails. > > $ ./python ./Lib/test/regrtest.py test_tarfile test_struct > test_tarfile > /home/pybot/test-trunk/build/Lib/struct.py:63: Deprecati

Re: [Python-Dev] test_gzip/test_tarfile failure om AMD64

On May 31, 2006, at 8:31 AM, Tim Peters wrote: > I'm afraid a sabbatical year isn't long enough to understand what the > struct module did or intends to do by way of range checking <0.7 > wink>. > > Is this intended? This is on a 32-bit Windows box with current trunk: > from struct import p

Re: [Python-Dev] Is implicit underscore assignment buggy?

On Jun 7, 2006, at 3:41 PM, Aahz wrote: > On Wed, Jun 07, 2006, Raymond Hettinger wrote: >> Fredrik: >>> >>> for users, it's actually quite simple to figure out what's in the _ >>> variable: it's the most recently *printed* result. if you cannot >>> see >>> it, it's not in there. >> >> Of cour

Re: [Python-Dev] Add pure python PNG writer module to stdlib?

On Jun 10, 2006, at 4:35 PM, Brett Cannon wrote:On 6/10/06, Johann C. Rocholl <[EMAIL PROTECTED]> wrote: I'm working on simple module to write PNG image files in pure python.Adding it to the standard library would be useful for people who wantto create images on web server installations without gd

Re: [Python-Dev] Add pure python PNG writer module to stdlib?

On Jun 10, 2006, at 10:52 PM, Johann C. Rocholl wrote: >>> Does anybody think it could go into stdlib before the feature >>> freeze for >> 2.5? >> >> Nope. To get added to the stdlib there needs to be support from the >> community that the module is useful and best-of-breed. Try >> posting o

Re: [Python-Dev] unicode imports

On Jun 16, 2006, at 9:02 AM, Phillip J. Eby wrote: > At 01:29 AM 6/17/2006 +1000, Nick Coghlan wrote: >> Kristján V. Jónsson wrote: >>> A cursory glance at import.c shows that the import mechanism is >>> fairly >>> complicated, and riddled with "char *path" thingies, and manual >>> string >>>

Re: [Python-Dev] unicode imports

On Jun 16, 2006, at 9:44 PM, Nick Coghlan wrote: > Bob Ippolito wrote: >> There's a similar issue in that if sys.prefix contains a colon, >> Python is also busted: >> http://python.org/sf/1507224 >> Of course, that's not a Windows issue, but it is everyw

Re: [Python-Dev] PyRange_New() alternative?

On Jun 22, 2006, at 11:55 AM, Ralf W. Grosse-Kunstleve wrote: > --- Georg Brandl <[EMAIL PROTECTED]> wrote: > >> Ralf W. Grosse-Kunstleve wrote: >>> http://docs.python.org/dev/whatsnew/ports.html says: >>> >>> The PyRange_New() function was removed. It was never >>> documented, never >> used

<    1   2   3   >