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,
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
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
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)
On Sun, Jan 31, 2010 at 11:16 AM, Guido van Rossum wrote:
> Whoa. This thread already exploded. I'm picking this message to
> respond to because it reflects my own view after reading the PEP.
>
> On Sun, Jan 31, 2010 at 4:13 AM, Hanno Schlichting wrote:
>> On Sun, Jan 31, 2010 at 1:03 PM, Simon C
On Sat, Mar 20, 2010 at 4:38 PM, Mark Dickinson wrote:
> On Sat, Mar 20, 2010 at 7:56 PM, Guido van Rossum wrote:
>> I propose to reduce all hashes to the hash of a normalized fraction,
>> which we can define as a combination of the hashes for the numerator
>> and the denominator. Then all we hav
On Tuesday, June 22, 2010, Brett Cannon wrote:
> [cc'ing Bob on his gmail address; didn't have any other address handy
> so I don't know if this will actually get to him]
>
> On Tue, Jun 22, 2010 at 09:54, Dirkjan Ochtman wrote:
>> It looks like simplejson 2.1.0 and 2.1.1 have been released:
>>
>
On Fri, Aug 27, 2010 at 8:25 AM, Guido van Rossum wrote:
> On Thu, Aug 26, 2010 at 5:05 PM, Yury Selivanov wrote:
>> On 2010-08-26, at 8:04 PM, Greg Ewing wrote:
>>> Even with your proposal, you'd still have to use a 'creepy
>>> abstraction' every time one of your coroutines calls another.
>>> Th
On Friday, November 5, 2010, wrote:
> On 12:21 am, m...@gsites.de wrote:
>
> Am 04.11.2010 17:15, schrieb anatoly techtonik:
>> pickle is insecure, marshal too.
>
> If the transport or storage layer is not save, you should cryptographically
> sign the data anyway::
>
> def pickle_encode(data
On Jul 12, 2006, at 2:23 PM, Jim Jewett wrote:
> Ka-Ping Yee writes:
>
>> A. The interpreter will not crash no matter what Python code
>> it is given to execute.
>
> Why?
>
> We don't want it to crash the embedding app (which might be another
> python interpreter), but if the sandboxed i
On Jul 13, 2006, at 12:37 AM, Wolfgang Langner wrote:
> On 7/13/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
>> Things that struck me as peculiar is the old:
>>
>> if __name__ == "__main__":
>> whatever()
>>
>> This is so out of tune with the rest of python it becomes a nuisan
On Jul 13, 2006, at 2:02 AM, Greg Ewing wrote:
> Jeroen Ruigrok van der Werven wrote:
>
>> - Open classes would be nice.
>
> What do you mean by "open classes"? Python
> classes already seem pretty open to me, by
> the standards of other languages!
I'm guessing he's talking about being like Ruby
On Jul 13, 2006, at 5:02 AM, Jeroen Ruigrok van der Werven wrote:
> Hi Bob,
>
> On 7/13/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>> Adding open classes would make it easier to develop DSLs, but you'd
>> only be able to reasonably do one per interpreter (unle
On Jul 13, 2006, at 1:53 PM, Giovanni Bajo wrote:
> [EMAIL PROTECTED] wrote:
>
>> (Aside: IMHO, the sooner we can drop old-style classes entirely, the
>> better.
>> That is one bumpy Python upgrade process that I will be _very_ happy
>> to do.
>
> I think python should have a couple more of futur
On Jul 17, 2006, at 11:25 AM, Armin Rigo wrote:
> Hi Bob,
>
> On Thu, Jul 13, 2006 at 12:58:08AM -0700, Bob Ippolito wrote:
>>> @main
>>> def whatever():
>>> ...
>>
>> It would probably need to be called something else, because main is
>&
On Jul 26, 2006, at 3:18 PM, John J Lee wrote:
> On Wed, 26 Jul 2006, Phillip J. Eby wrote:
> [...]
>> Actually, I would see more reason to include JSON in the standard
>> library,
>> since it's at least something approaching an internet protocol
>> these days.
>
> +1
If there's a consensus
On Jul 27, 2006, at 3:52 AM, Georg Brandl wrote:
> Armin Rigo wrote:
>> Hi Phillip,
>>
>> On Wed, Jul 26, 2006 at 02:40:27PM -0400, Phillip J. Eby wrote:
>>> If we don't revert it, there are two ways to fix it. One is to
>>> just change
>>> PEP 302 so that the behavior is unbroken by definitio
It seems that the pre-2.5 struct module has some additional
undocumented behavior[1] that didn't percolate into the new version:
http://python.org/sf/1530559
Python 2.4 and previous will coerce floats to integers when necessary
as such without any kind of complaint:
$ python2.4 -c "import s
On Jul 28, 2006, at 1:35 PM, Bob Ippolito wrote:
> It seems that the pre-2.5 struct module has some additional
> undocumented behavior[1] that didn't percolate into the new version:
> http://python.org/sf/1530559
>
> Python 2.4 and previous will coerce floats to integers when
On Aug 3, 2006, at 9:51 AM, M.-A. Lemburg wrote:
> Ralf Schmitt wrote:
>> Ralf Schmitt wrote:
>>> Still trying to port our software. here's another thing I noticed:
>>>
>>> d = {}
>>> d[u'm\xe1s'] = 1
>>> d['m\xe1s'] = 1
>>> print d
>>>
>>> With python 2.4 I can add those two keys to the dictiona
On Aug 3, 2006, at 6:51 PM, Greg Ewing wrote:
> M.-A. Lemburg wrote:
>
>> Perhaps we ought to add an exception to the dict lookup mechanism
>> and continue to silence UnicodeErrors ?!
>
> Seems to be that comparison of unicode and non-unicode
> strings for equality shouldn't raise exceptions in t
On Aug 3, 2006, at 9:34 PM, Josiah Carlson wrote:
>
> Bob Ippolito <[EMAIL PROTECTED]> wrote:
>> On Aug 3, 2006, at 6:51 PM, Greg Ewing wrote:
>>
>>> M.-A. Lemburg wrote:
>>>
>>>> Perhaps we ought to add an exception to the dict looku
On Aug 4, 2006, at 12:51 PM, Giovanni Bajo wrote:
> Paul Colomiets <[EMAIL PROTECTED]> wrote:
>
>> Well it's not recomended to mix strings and unicode in the
>> dictionaries
>> but if we mix for example integer and float we have the same
>> thing. It
>> doesn't raise exception but still it is n
On Aug 5, 2006, at 4:52 AM, Hernan M Foffani wrote:
> Currently, we have two running tracker demos online:
>
> Roundup:
> http://efod.se/python-tracker/
>
> Jira:
> http://jira.python.atlassian.com/secure/Dashboard.jspa
>>
>>
>> Is anyone looking at the Google Code Hos
On 9/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson schrieb:
> > "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> Out of curiosity: how do the current universal binaries deal with this
> >> issue?
> >
> > If I remember correctly, usually you do two completely independant
> >
On 9/22/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Michael Foord <[EMAIL PROTECTED]> wrote:
> >
> > Hello all,
> >
> > I have a suggestion for a new Python built in function: 'flatten'.
>
> This has been brought up many times. I'm -1 on its inclusion, if only
> because it's a fairly simple
On 9/22/06, Brian Harring <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 22, 2006 at 12:05:19PM -0700, Bob Ippolito wrote:
> > On 9/22/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > >
> > > Michael Foord <[EMAIL PROTECTED]> wrote:
> > > >
>
On 9/22/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Bob Ippolito" <[EMAIL PROTECTED]> wrote:
> > On 9/22/06, Brian Harring <[EMAIL PROTECTED]> wrote:
> > > On Fri, Sep 22, 2006 at 12:05:19PM -0700, Bob Ippolito wrote:
> > > > I
On 9/28/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Alex Martelli]
>
> >I've had use cases for "weakrefs to boundmethods" (and there IS a
> >Cookbook recipe for them),
> >
> Weakmethods make some sense (though they raise the question of why bound
> methods are being kept when the underlying
On 9/28/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > There are *definitely* use cases for keeping bound methods around.
> >
> > Contrived example:
> >
> >one_of = set([1,2,3,4]).__contains__
> >filter(one_of, [2,4,6,8,10])
>
> ISTM, the example shows the (undisputed) utility of regu
On 9/29/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Nick Craig-Wood wrote:
>
> > Is there any reason why float() shouldn't cache the value of 0.0 since
> > it is by far and away the most common value?
>
> 1.0 might be another candidate for cacheing.
>
> Although the fact that nobody has complained
On 9/30/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >I suspect the problem would typically stem from floating point values that
> >are
> >read in from a human-readable file rather than being the result of a
> >'calcul
On 9/30/06, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Christos Georgiou wrote:
> > Does anyone know why this happens? I can't find any information pointing to
> > this being deliberate.
> >
> > I just upgraded to 2.5 on Windows (after making sure I can build extensions
> > with the freeware
On 9/30/06, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Bob Ippolito wrote:
> > On 9/30/06, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> >> Christos Georgiou wrote:
> >>> Does anyone know why this happens? I can't find any information
On 10/6/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Ron Adam wrote:
>
> > I think what may be missing is a larger set of higher level string functions
> > that will work with lists of strings directly. Then lists of strings can be
> > thought of as a mutable string type by its use, and then wor
On 10/13/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> On Friday 13 October 2006 16:59, Fredrik Lundh wrote:
> > yeah, but *you* are doing it. if the server did that, Martin and
> > other trusted contributors could upload the files as soon as they're
> > available, instead of first transferring
On 10/15/06, Barry Scott <[EMAIL PROTECTED]> wrote:
> This may be down to my lack of knowledge of Mac OS X development.
>
> I want to build my python extension for Python 2.3, 2.4 and 2.5 on
> the same Mac.
> Build Python 2.3 and Python 2.4 has been working well for a long
> time. But
> after I ins
On 11/26/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> i found several places in my code where i use positive infinity
> (posinf) for various things, i.e.,
>
> def readline(self, limit = -1):
> if limit < 0:
> limit = 1e1 # posinf
> chars = []
> while lim
On 12/23/06, Jeremy Kloth <[EMAIL PROTECTED]> wrote:
> On Friday 22 December 2006 5:02 pm, Josiah Carlson wrote:
> > Jeremy Kloth <[EMAIL PROTECTED]> wrote:
> > > [[ This may be somewhat c.l.p.-ish but I feel that this crossed into
> > > CPython development enough to merit posting here ]]
> > >
> >
On 12/23/06, Jeremy Kloth <[EMAIL PROTECTED]> wrote:
> On Friday 22 December 2006 7:54 pm, Bob Ippolito wrote:
> > It's a whole lot more practical to just stop using mod_python and go
> > for one of the other ways of exposing Python code to the internet. I
> > be
On 12/23/06, Evgeniy Khramtsov <[EMAIL PROTECTED]> wrote:
> Mike Klaas пишет:
>
> > I'm not sure how having python execute code at an arbitrary time would
> > _reduce_ race conditions and/or deadlocks. And if you want to make it
> > safe by executing code that shares no variables or resources, then
On 2/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Thomas Wouters wrote:
>
> > *I* don't like the idea of something in the Python installation
> > deciding which reactor to use.
>
> I wouldn't mind if some way were provided of changing
> the reactor if you want. I'd just like to see a long
> ter
On 2/15/07, Baptiste Carvello <[EMAIL PROTECTED]> wrote:
> >> Ah, threads :-( It turns out that you need to invoke GetMessage in the
> >> context of the thread in which the window was created. In a different
> >> thread, you won't get any messages.
> >
> > I'd be interested to hear about other situ
On 3/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Guido> Since "idel timeout" is not a commonly understood term it would
> Guido> be even better if it was explained without using it.
>
> I think it's commonly understood, but it doesn't mean what the socket
> timeout is used for.
On Thu, Mar 24, 2011 at 11:46 AM, Jameson Quinn wrote:
>>
>> If you need this for **kw arguments maybe you're not using them right;
>> why not name your arguments if you're going to reference them by name?
>
> Good point.
>>
>> The JSON use case seems to be driven because this is the way
>> JavaSc
On Thu, Apr 14, 2011 at 2:29 PM, Raymond Hettinger
wrote:
>
> On Apr 14, 2011, at 12:22 PM, Sandro Tosi wrote:
>
>> The version we have in cpython of json is simplejson 2.0.9 highly
>> patched (either because it was converted to py3k, and because of the
>> normal flow of issues/bugfixes) while ups
On Friday, April 15, 2011, Antoine Pitrou wrote:
>>
>> > Since the JSON spec is set in stone, the changes
>> > will mostly be about API (indentation, object conversion, etc)
>> > and optimization. I presume the core parsing logic won't
>> > be changing much.
>>
>> Actually the core parsing logic
On Fri, Apr 15, 2011 at 2:20 PM, Antoine Pitrou wrote:
> Le vendredi 15 avril 2011 à 14:18 -0700, Bob Ippolito a écrit :
>> On Friday, April 15, 2011, Antoine Pitrou wrote:
>> >>
>> >> > Since the JSON spec is set in stone, the changes
>> >>
On Fri, Apr 15, 2011 at 4:12 PM, Antoine Pitrou wrote:
> On Fri, 15 Apr 2011 14:27:04 -0700
> Bob Ippolito wrote:
>> On Fri, Apr 15, 2011 at 2:20 PM, Antoine Pitrou wrote:
>> > Le vendredi 15 avril 2011 à 14:18 -0700, Bob Ippolito a écrit :
>> >> On Friday, Apri
On Saturday, April 16, 2011, Antoine Pitrou wrote:
> Le samedi 16 avril 2011 à 17:07 +0200, Xavier Morel a écrit :
>> On 2011-04-16, at 16:52 , Antoine Pitrou wrote:
>> > Le samedi 16 avril 2011 à 16:42 +0200, Dirkjan Ochtman a écrit :
>> >> On Sat, Apr 16, 2011 at 16:19, Antoine Pitrou wrote:
>>
On 5/21/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > I think the people who have responded to my comment read too much into it.
> > Nowhere do I think I asked Georg to write an equation typesetter to include
> > in the Python documentation toolchain. I asked that math capability be
> > con
es to install (in the cases where they do
require libraries, they link them in statically for the most part).
These days I don't have a lot of preference, I don't use either :)
On Mon, Aug 18, 2008 at 1:08 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Alternatively, I just go
On Mon, Aug 18, 2008 at 3:41 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Aug 18, 2008, at 6:13 PM, Fred Drake wrote:
>
>> On Aug 18, 2008, at 5:42 PM, Steve Holden wrote:
>>>
>>> Someone told me the other day that macports made for difficult
I'm out of town this week for a conference (ICFP/CUFP in Victoria) and
my hotel's connection has been bad enough such that I can't get any
Real Work done so I've managed to hammer on the json library's
decoding quite a bit instead. I just released simplejson 1.9.3 which
improves decoding performanc
On Wed, Sep 24, 2008 at 6:14 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sep 24, 2008, at 5:47 AM, Nick Coghlan wrote:
>
>> Bob Ippolito wrote:
>>>
>>> How much time do I
>>> have l
ound
> with it in Google App Engine opensource sandboxes (e.g., cfr.
> gae-json-rest -- I'll be delighted to add you to that project if you
> want of course;-) and that requires Python 2.5 and only pure-Python
> add-ons... thanks!
>
> Alex
>
>
> On Wed, Sep 24, 2008 a
try
and take care of that quickly after Python 2.6 is released.
On Wed, Sep 24, 2008 at 9:02 AM, Bob Ippolito <[EMAIL PROTECTED]> wrote:
> http://pypi.python.org/pypi/simplejson
>
> The _speedups module is optional.
>
> On Wed, Sep 24, 2008 at 8:42 AM, Alex Martelli <[EMAI
On Nov 29, 2004, at 2:04 PM, Gustavo Niemeyer wrote:
Today, while trying to internationalize a program I'm working on,
I found an interesting side-effect of how we're dealing with
encoding of unicode strings while being written to files.
Suppose the following example:
# -*- encoding: iso-8859-1 -
On Dec 9, 2004, at 4:20 PM, Barry Warsaw wrote:
On Thu, 2004-12-09 at 10:30, Phillip J. Eby wrote:
ISTR that for a long time, Visual Basic actually did the same thing.
A few
magazines mentioned the fact, but nobody really cared. However, if
this is
really a concern, bundle Pyrex as well. Both
I've included a lot of background information here, if you just want to
know the details
of the proposed change, skip to the bottom.
As some of you may know, Python 2.4's configure script and distutils
has some
tricky behavior with regard to the ``MACOSX_DEPLOYMENT_TARGET``
environment
variable
On Dec 10, 2004, at 1:05 PM, Phillip J. Eby wrote:
At 05:19 PM 12/10/04 +, Armin Rigo wrote:
Another note: can you report on whether building libpython24.a can be
skipped
for mingw? I'm thinking about the specific situation where we want
on-site
compilation of extension modules with a minima
On Dec 11, 2004, at 3:39 AM, Martin v. Löwis wrote:
Chui G. Tey wrote:
One good way of helping out is to provide an dynamic loading function
that third party modules could access the basic python functions such
as
PyArgParseTuple, PyString_AsString etc regardless of which python the
user is runnin
On Dec 12, 2004, at 11:02 AM, Martin v. Löwis wrote:
Bob Ippolito wrote:
I believe this is not implementable: How can the DLL know which
Python
DLL to use?
Well for py2app on Mac OS X, I wrote an executable stub that chooses
a Python runtime from an XML file, looks up and binds a few symbols
On Dec 12, 2004, at 1:09 PM, Martin v. Löwis wrote:
Bob Ippolito wrote:
Yes, of course, I was talking about the executable, not extensions.
On Mac OS X 10.3+, the linker flag -undefined dynamic_lookup allows
extensions to link to no Python whatsoever.
It's the same on SysV ELF shared libr
Merry Christmas to me! I actually purchased a Nokia Series 60 phone
when this was first announced, in hopes that this would be available
soon. A littler later than I'd have liked, but better than never :)
-bob
On Dec 22, 2004, at 9:19 PM, Guido van Rossum wrote:
Python runs on Nokia cell phone
On Dec 22, 2004, at 11:22 PM, Tim Delaney wrote:
Guido van Rossum wrote:
Python runs on Nokia cell phones (the high-end ones, anyway) and has
support from Nokia!
Pretty cool all around.
I couldn't find out which version of Python is supported - have they
told you?
Python 2.2.2 (#0, Dec 2 2004, 18
On Dec 23, 2004, at 12:36 AM, Timothy Fitz wrote:
1067760 -- float-->long conversion on fileobj.seek calls, rather than
float-->int. Permits larger floats (2.0**62) to match large
int (2**62) arguments. rhettinger marked as "won't fix" in
the original bug report; this seems l
On Dec 27, 2004, at 8:45 PM, Chris Barker wrote:
The versioning system that wxPython now has is quite nice, and seems
to fit most people's needs well. However, it's also quite new, and who
know what problems will arise. For those interested, here's a
synopsis.
http://wiki.wxpython.org/index.cgi
On Dec 27, 2004, at 8:43 PM, Josiah Carlson wrote:
Scott David Daniels <[EMAIL PROTECTED]> wrote:
I'm hoping to add BZIP2 compression to zipfile for 2.5. My primary
motivation is that Project Gutenberg seems to be starting to use BZIP2
compression for some of its zips. What other wish list things
On Dec 28, 2004, at 4:30 PM, [EMAIL PROTECTED] wrote:
Update of /cvsroot/python/python/dist/src/Mac/OSX
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9229
Modified Files:
fixapplepython23.py
Log Message:
Just passing -undefined dynamic_lookup isn't enough: we also need to
set
the MACOSX_D
On Dec 29, 2004, at 5:23 AM, Jack Jansen wrote:
On 29-dec-04, at 4:35, Bob Ippolito wrote:
This is the wrong fix. Distutils is dumber than you think. This
patch just breaks C++ compilation in a different way. The correct
solution is a patch to distutils of some kind.
from distutils
On Jan 1, 2005, at 5:33 PM, [EMAIL PROTECTED] wrote:
Update of /cvsroot/python/python/dist/src/Mac/OSX
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv14408
Modified Files:
fixapplepython23.py
Log Message:
Create the wrapper scripts for gcc/g++ too.
+SCRIPT="""#!/bin/sh
+export MACOSX
On Jan 2, 2005, at 4:28 PM, Jack Jansen wrote:
On 2-jan-05, at 4:40, Bob Ippolito wrote:
+SCRIPT="""#!/bin/sh
+export MACOSX_DEPLOYMENT_TARGET=10.3
+exec %s "[EMAIL PROTECTED]"
This script should check to see if MACOSX_DEPLOYMENT_TARGET is
already set. If
Quite a few notable places in the Python sources expect realloc(...) to
relinquish some memory if the requested size is smaller than the
currently allocated size. This is definitely not true on Darwin, and
possibly other platforms. I have tested this on OpenBSD and Linux, and
the implementati
On Jan 3, 2005, at 12:13 AM, Tim Peters wrote:
[Bob Ippolito]
Quite a few notable places in the Python sources expect realloc(...)
to
relinquish some memory if the requested size is smaller than the
currently allocated size.
I don't know what "relinquish some memory" means. If it
On Jan 3, 2005, at 2:16 AM, Tim Peters wrote:
[Bob Ippolito]
...
Your expectation is not correct for Darwin's memory allocation scheme.
It seems that Darwin creates allocations of immutable size. The only
way ANY part of an allocation will ever be used by ANYTHING else is if
free() is called
On Jan 3, 2005, at 11:15 AM, Guido van Rossum wrote:
Coming late to this thread.
I don't see the point of lying awake at night worrying about potential
memory losses unless you've heard someone complain about it. As Tim
has been trying to explain, here are plenty of other things in Python
that we *
On Jan 3, 2005, at 3:23 PM, bacchusrx wrote:
On Thu, Jan 01, 1970 at 12:00:00AM +, Tim Peters wrote:
Is there any known case where Python performs poorly on this OS, for
this reason, other than the "pass giant numbers to recv() and then
shrink the string because we didn't get anywhere near that
On Jan 3, 2005, at 4:49 PM, Tim Peters wrote:
[Tim Peters]
Ya, I understood that. My conclusion was that Darwin's realloc()
implementation isn't production-quality. So it goes.
[Bob Ippolito]
Whatever that means.
Well, it means what it said. The C standard says nothing about
performan
On Jan 4, 2005, at 5:00 AM, Thomas Heller wrote:
I'm working on refactoring Python/import.c, currently the case_ok()
function.
I was wondering about these lines:
/* new-fangled macintosh (macosx) */
#elif defined(__MACH__) && defined(__APPLE__) &&
defined(HAVE_DIRENT_H)
Is this for Mac OSX? D
On Jan 4, 2005, at 5:56 AM, Jack Jansen wrote:
On 3 Jan 2005, at 23:40, Bob Ippolito wrote:
Most people on Mac OS X have a lot of memory, and Mac OS X generally
does a good job about swapping in and out without causing much of a
problem, so I'm personally not very surprised that it cou
On Jan 4, 2005, at 7:42 AM, Jack Jansen wrote:
On 4 Jan 2005, at 11:41, Bob Ippolito wrote:
And finally: Is there any other way to find the true spelling of a
file
except than a linear search with opendir()/readdir()/closedir() ?
Yes, definitely. I'm positive you can do this with CoreSer
On Jan 4, 2005, at 1:23 PM, Skip Montanaro wrote:
I was suggesting that there is an ongoing discussion that should
continue on the compiler-sig.
Guido> I'd be fine with keeping this on python-dev too.
+1 for a number of reasons:
* It's more visible and would potentially get more people
in
On Jan 4, 2005, at 1:28 PM, Guido van Rossum wrote:
Let's get rid of unbound methods. When class C defines a method f, C.f
should just return the function object, not an unbound method that
behaves almost, but not quite, the same as that function object. The
extra type checking on the first argumen
On Jan 4, 2005, at 6:01 PM, Jack Jansen wrote:
On 4-jan-05, at 19:28, Guido van Rossum wrote:
The
extra type checking on the first argument that unbound methods are
supposed to provide is not useful in practice (I can't remember that
it ever caught a bug in my code)
It caught bugs for me a couple
On Jan 4, 2005, at 6:54 PM, Martin v. Löwis wrote:
Jack Jansen wrote:
First question: what is the Python 2.3.5 release schedule and who is
responsible?
Last I heard it is going to be released "in January", and Anthony
Baxter
is the release manager.
Second question: I thought this info was in a
On Jan 4, 2005, at 8:18 PM, Josiah Carlson wrote:
Tim Peters <[EMAIL PROTECTED]> wrote:
Guido wrote:
Let's get rid of unbound methods. When class C defines a method
[snip]
Really? Unbound methods are used most often (IME) to call a
base-class method from a subclass, like my_base.the_method(self, .
On Jan 5, 2005, at 3:33 AM, Martin v. Löwis wrote:
Bob Ippolito wrote:
It doesn't for reasons I care not to explain in depth, again. Search
the pythonmac-sig archives for longer explanations. The gist is
that you specifically do not want to link directly to the framework
at all
On Jan 5, 2005, at 16:15, Martin v. Löwis wrote:
Bob Ippolito wrote:
Then you haven't done the appropriate research by searching
pythonmac-sig.
Hmm.
> Do you even own a Mac?
Do I have to, in order to understand the issues?
But to answer your question: yes, I do.
Well, this issue
On Jan 5, 2005, at 16:58, Martin v. Löwis wrote:
Ronald Oussoren wrote:
It gets worse when you have a user-installed python 2.3 and a
user-installed python 2.4. Those will be both be installed as
/Library/Frameworks/Python.framework.
Yes, but one is installed in Versions/2.3, and the other in
Ver
On Jan 5, 2005, at 17:38, Martin v. Löwis wrote:
Bob Ippolito wrote:
Nope. The only way to link to a non-current framework version is to
forego any linker searching and specify the dyld file directly, i.e.
/Library/Frameworks/Python.framework/Versions/2.3/Python. The gcc
toolchain does not
On Jan 5, 2005, at 18:46, Martin v. Löwis wrote:
Bob Ippolito wrote:
I just dug up some information I had written on this particular topic
but never published, if you're interested:
http://bob.pythonmac.org/archives/2005/01/05/versioned-frameworks-
considered-harmful/
Interesting. I don&
On Jan 5, 2005, at 18:49, Martin v. Löwis wrote:
Jack Jansen wrote:
The "new" solution is basically to go back to the Unix way of
building an extension: link it against nothing and sort things out
at runtime. Not my personal preference, but at least we know that
loading an extension into one
On Jan 6, 2005, at 8:17, Michael Hudson wrote:
Ilya Sandler <[EMAIL PROTECTED]> writes:
A problem:
The current struct.unpack api works well for unpacking C-structures
where
everything is usually unpacked at once, but it
becomes inconvenient when unpacking binary files where things
often have to b
On Jan 6, 2005, at 14:59, Ronald Oussoren wrote:
On 6-jan-05, at 14:04, Jack Jansen wrote:
On 6 Jan 2005, at 00:49, Martin v. Löwis wrote:
The "new" solution is basically to go back to the Unix way of
building an extension: link it against nothing and sort things out
at runtime. Not my personal
On Jan 6, 2005, at 15:03, Bob Ippolito wrote:
On Jan 6, 2005, at 14:59, Ronald Oussoren wrote:
On 6-jan-05, at 14:04, Jack Jansen wrote:
On 6 Jan 2005, at 00:49, Martin v. Löwis wrote:
The "new" solution is basically to go back to the Unix way of
building an extension: link it again
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
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)
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
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
1 - 100 of 257 matches
Mail list logo
