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 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 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 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 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 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 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 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 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 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 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 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 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 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 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,
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
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
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
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 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
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 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
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 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 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 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 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, 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 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 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 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/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 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 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, 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/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/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/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/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/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:
>
> 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/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 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 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 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 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: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 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
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 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
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 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 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 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 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 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 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 7, 2006, at 1:08 PM, Guido van Rossum wrote:
> On 7/7/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>> I've been doing a bunch of Firefox extension programming in
>> Javascript
>> and suddenly a few of the recent topics here came together in my head
>> in a silent kapow of thoughts. This i
On Jul 6, 2006, at 5:04 PM, Ka-Ping Yee wrote:
> On Thu, 6 Jul 2006, Phillip J. Eby wrote:
>> As much as I'd love to have the nested scope feature, I think it's
>> only
>> right to point out that the above can be rewritten as something
>> like this
>> in Python 2.5:
>>
>> def spam():
>>
On Jul 1, 2006, at 10:45 AM, Ronald Oussoren wrote:
>
> On Jul 1, 2006, at 6:57 PM, [EMAIL PROTECTED] wrote:
>
>>
>> Ronald> Are you sure you're building on a 10.4 box? Both the
>> Ronald> macosx-10.3 thingy and lack of inflateCopy seem to
>> indicate that
>> Ronald> you're running
On Jun 28, 2006, at 1:05 PM, Gregor Lingl wrote:
> Martin v. Löwis schrieb:
>> Collin Winter wrote:
>>
>>> While I have no opinion on Gregor's app, and while I fully agree
>>> that
>>> new language features and stdlib modules should generally stay
>>> out of
>>> bug-fix point releases, xturtl
On Jun 28, 2006, at 10:54 AM, Brett Cannon wrote:On 6/28/06, Trent Mick <[EMAIL PROTECTED]> wrote: Brett Cannon wrote: Mark (and me a little bit) has been sketching out creating a "Python forMozilla/Firefox" extension for installing an embedded Python into anexisting Firefox installation on the pyx
On Jun 25, 2006, at 1:08 PM, Brett Cannon wrote:On 6/24/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: On Jun 24, 2006, at 2:46 AM, Nick Coghlan wrote:> Brett Cannon wrote:>> Yep. That API will be used directly in the changes to pymalloc and>> PyMem_*() macros (or at least th
On Jun 24, 2006, at 2:46 AM, Nick Coghlan wrote:
> Brett Cannon wrote:
>> Yep. That API will be used directly in the changes to pymalloc and
>> PyMem_*() macros (or at least the basic idea). It is not *only* for
>> extension modules but for the core as well.
>>
>> Existing extension modules
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
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
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
>>>
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
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
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
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
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
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.
>&
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
On Apr 21, 2006, at 5:58 PM, Alex Martelli wrote:
> On 4/21/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>...
>>> GMP is covered by LGPL, so must any such derivative work
>>
>> But the wrapper is just using GMP as a library, so
>> it shouldn't be infected with LGPLness, should it?
>
> If a lawye
On Apr 5, 2006, at 9:02 PM, Alex Martelli wrote:
>
> On Apr 5, 2006, at 8:30 PM, Greg Ewing wrote:
>
>> A while ago there was some discussion about including
>> elementtree in the std lib. I can't remember what the
>> conclusion about that was, but if it does go ahead,
>> I'd like to suggest that
On Apr 3, 2006, at 9:01 PM, Neal Norwitz wrote:
> On 4/3/06, Zachary Pincus <[EMAIL PROTECTED]> wrote:
>>
>> Sorry if it's bad form to ask about patches one has submitted -- let
>> me know if that sort of discussion should be kept strictly on the
>> patch tracker.
>
> No, it's fine. Thanks for r
On Mar 17, 2006, at 4:38 PM, Neal Becker wrote:
> "Martin v. Löwis" wrote:
>
>> Neal Becker wrote:
>>> Sorry, maybe I used confusing terminology.
>>>
>>> A reference is here: http://fedoraproject.org/wiki/Packaging/Python
>>> This is the current setup. For example, this is a standard macro
>>>
On Mar 17, 2006, at 12:40 AM, Martin v. Löwis wrote:
> Fredrik Lundh wrote:
>> I don't think many people embed setup.py scripts, so alternative
>> (e) would pro-
>> bably cause the least problems:
>>
>> e) sys.executable contains the full path to the program used
>> to invoke
>> this
On Mar 6, 2006, at 4:14 PM, Guido van Rossum wrote:
> On 3/6/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> [Neil Schemenauer]
>>> I occasionally need dictionaries or sets that use object identity
>>> rather than __hash__ to store items. Would it be appropriate to add
>>> these to the colle
On Feb 22, 2006, at 1:22 PM, Brett Cannon wrote:
> First off, thanks to Neil for writing this all down. The whole thread
> of discussion on the bytes type was rather long and thus hard to
> follow. Nice to finally have it written down in a PEP.
>
> Anyway, a few comments on the PEP. One, shoul
On Feb 22, 2006, at 4:18 AM, Fuzzyman wrote:
> Raymond Hettinger wrote:
>> from operator import isSequenceType, isMappingType
>> class anything(object):
>>> ... def __getitem__(self, index):
>>> ... pass
>>> ...
>> something = anything()
>> isMappingType(something)
>>>
On Feb 20, 2006, at 7:25 PM, Stephen J. Turnbull wrote:
>> "Martin" == Martin v Löwis <[EMAIL PROTECTED]> writes:
>
> Martin> Please do take a look. It is the only way: If you were to
> Martin> embed base64 *bytes* into character data content of an XML
> Martin> element, the resul
On Feb 20, 2006, at 6:48 PM, Guido van Rossum wrote:
> On OSX (10.4.4) the readline module in the svn HEAD fails compilation
> as follows. This is particularly strange since the buildbot is green
> for OSX... What could be up with this?
>
> building 'readline' extension
-lots of build junk-
In A
On Feb 19, 2006, at 5:03 PM, Raymond Hettinger wrote:
>>> @cmdloop.aliases('goodbye')
>>> @cmdloop.shorthelp('say goodbye')
>>> @cmdloop.usage('goodbye TARGET')
>>>
>>> to just:
>>>
>>> @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say
>>> goodbye',
>>> usage
On Feb 19, 2006, at 10:55 AM, Martin v. Löwis wrote:
> Stephen J. Turnbull wrote:
>> BTW, what use cases do you have in mind for Unicode -> Unicode
>> decoding?
>
> I think "rot13" falls into that category: it is a transformation
> on text, not on bytes.
The current implementation is a transforma
On Feb 17, 2006, at 8:33 PM, Josiah Carlson wrote:
>
> Greg Ewing <[EMAIL PROTECTED]> wrote:
>>
>> Stephen J. Turnbull wrote:
"Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
>>
>>> Guido> - b = bytes(t, enc); t = text(b, enc)
>>>
>>> +1 The coding conversion operation has al
1 - 100 of 257 matches
Mail list logo
