> Besides, Bob doesn't really seem to care about
> porting to py3k (he hasn't said anything about it until now, other than that
> he
> didn't feel competent to do it).
That is quite unfortunate, and suggests that perhaps the module
shouldn't have been added to Python in the first place.
I can un
Guido van Rossum python.org> writes:
>
> I'm kind of surprised that a serialization protocol like JSON wouldn't
> support reading/writing bytes (as the serialized format -- I don't
> care about having bytes as values, since JavaScript doesn't have
> something equivalent AFAIK, and hence JSON does
On Wed, Apr 8, 2009 at 7:51 PM, Guido van Rossum wrote:
>
> There was a remark (though perhaps meant humorously) in Michele's page
> about decorators that worried me too: "For instance, typical
> implementations of decorators involve nested functions, and we all
> know that flat is better than nes
On Thu, Apr 9, 2009 at 4:45 AM, Alexander Neundorf
wrote:
> I think cmake can do all of the above (cpack supports creating packages).
I am sure it is - it is just a lot of work, specially if you want to
stay compatible with distutils-built extensions :)
cheers,
David
__
On Wed, Apr 8, 2009 at 4:10 AM, Antoine Pitrou wrote:
> 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). This bytes support almost didn't work at
Martin v. Löwis v.loewis.de> writes:
>
> What does Bob Ippolito think about this change? IIUC, he considers
> simplejson's speed one of its primary advantages, and also attributes it
> to the fact that he can parse directly out of byte strings, and marshal
> into them (which is important, as you
On Wed, Apr 8, 2009 at 8:37 PM, "Martin v. Löwis" wrote:
--8<--
> > * Should we change the workflow for roundup to make this assignment
> > of license clearer (see Tobias's idea in the thread about a
> > click-though agreement).
>
> I think we do need something written; a lawyer ma
Assuming that Mark's and my changes in the py3k-short-float-repr branch
get checked in shortly, I'd like to deprecate PyOS_ascii_formatd. Its
functionality is largely being replaced by PyOS_double_to_string, which
we're introducing on our branch.
PyOS_ascii_formatd was introduced to fix the is
P.J. Eby wrote:
> Anyway, it's nice for decorators to be transparent to inspection when
> the decorator doesn't actually modify the calling signature, so that you
> can then use your decorated functions with tools like the above.
If anyone wanted to take PEP 362 up again, we could easily add a
__s
>> - registration to pypi
Alex> No idea what this is .
http://pypi.python.org/
It is, in some ways, a CPAN-like system for Python.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
On Wed, Apr 8, 2009 at 4:18 AM, David Cournapeau wrote:
...
>> I guess something similar could be useful for Python, maybe this is
>> what distutils actually do ?
>
> distutils does roughly everything that autotools does, and more:
> - configuration: not often used in extensions, we (numpy) are t
At 10:51 AM 4/8/2009 -0700, Guido van Rossum wrote:
I would like it even less if an API cared about the
*actual* signature of a function I pass into it.
One notable use of callable argument inspection is Bobo, the
12-years-ago predecessor to Zope, which used argument information to
determine
> * What is the scope of a patch that requires a contributor
> agreement?
Unfortunately, that question was never fully answered (or I forgot
what the answer was).
> * Do Google employees, working on company time, automatically get
> treated as contributors with existing contr
> 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). This bytes support almost didn't work at
> all, but there was a lot of C and Python code for it
> foo = set([1, 65537])
> foo.pop()
>> 1
> foo = set([65537, 1])
> foo.pop()
>> 65537
>
> You wrote a program to find the two smallest ints that would have a
> hash collision in the CPython set implementation? I'm impressed. And
> by impressed I mean frightened.
Well, Mark is th
On Wed, Apr 8, 2009 at 12:17 AM, Michele Simionato
wrote:
> On Wed, Apr 8, 2009 at 8:10 AM, Jack diederich wrote:
>> Plus he's a softie for decorators, as am I.
This worries me a bit.
There was a remark (though perhaps meant humorously) in Michele's page
about decorators that worried me too: "F
Someone listed this URL on c.l.py and I thought it would make a good
reference addition to PEP 374 (DVCS decision):
http://www.catb.org/~esr/writings/version-control/version-control.html
--
Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/
"...string iteration isn't a
Oops, didn't attach the entire thread, so see below:
On Wed, Apr 8, 2009 at 9:50 AM, Jim Baker wrote:
> A question that arose on this thread, which I'm forwarding for context (and
> we're quite happy about it too!):
>
>- What is the scope of a patch that requires a contributor agreement?
>
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). This bytes support almost didn't work at
all, but there was a lot of C and Python code for it neverthe
A question that arose on this thread, which I'm forwarding for context (and
we're quite happy about it too!):
- What is the scope of a patch that requires a contributor agreement?
This particular patch on #1188 simply adds obvious (in retrospect of course)
handling on SecurityException so
2009/4/8 Steve Holden :
> Paul Moore wrote:
>> 2009/4/8 Duncan Booth :
>>> Andrea Griffini wrote:
>>>
On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich
wrote:
> You wrote a program to find the two smallest ints that would have a
> hash collision in the CPython set implementation?
Paul Moore wrote:
> 2009/4/8 Duncan Booth :
>> Andrea Griffini wrote:
>>
>>> On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich
>>> wrote:
You wrote a program to find the two smallest ints that would have a
hash collision in the CPython set implementation? I'm impressed.
And by impr
2009/4/8 Duncan Booth :
> Andrea Griffini wrote:
>
>> On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich
>> wrote:
>>> You wrote a program to find the two smallest ints that would have a
>>> hash collision in the CPython set implementation? I'm impressed.
>>> And by impressed I mean frightened.
>>
Andrea Griffini wrote:
> On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich
> wrote:
>> You wrote a program to find the two smallest ints that would have a
>> hash collision in the CPython set implementation? I'm impressed.
>> And by impressed I mean frightened.
>
> ?
>
> print set([0,8]).pop(
Hi, Just noticed the new Python 2.6.2 docs now dont have any reference to
* PyCFunction_New
* PyCFunction_NewEx
* PyCFunction_Check
* PyCFunction_Call
Ofcourse these are still in the source code but Im wondering if this
is intentional that these functions should be for internal use only?
--
- Cam
On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich wrote:
> You wrote a program to find the two smallest ints that would have a
> hash collision in the CPython set implementation? I'm impressed. And
> by impressed I mean frightened.
?
print set([0,8]).pop(), set([8,0]).pop()
Andrea
_
Jack diederich wrote:
> On Wed, Apr 8, 2009 at 2:44 AM, Mark Dickinson wrote:
>> On Wed, Apr 8, 2009 at 7:13 AM, John Barham wrote:
>>> If you play around a bit it becomes clear that what set.pop() returns
>>> is independent of the insertion order:
>> It might look like that, but I don't think th
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). This bytes support almost didn't work at
all, but there was a lot of C and Python code for it nev
On Wed, Apr 8, 2009 at 2:44 AM, Mark Dickinson wrote:
> On Wed, Apr 8, 2009 at 7:13 AM, John Barham wrote:
>> If you play around a bit it becomes clear that what set.pop() returns
>> is independent of the insertion order:
>
> It might look like that, but I don't think this is
> true in general (a
On Wed, Apr 8, 2009 at 3:55 PM, Jeroen Ruigrok van der Werven <
asmo...@in-nomine.org> wrote:
> -On [20090408 05:24], Tennessee Leeuwenburg (tleeuwenb...@gmail.com)
> wrote:
> >It seems like the bug relates only to an older version of a 'weird'
> >operating
Mark Dickinson gmail.com> writes:
>
> On Wed, Apr 8, 2009 at 7:13 AM, John Barham gmail.com> wrote:
> > If you play around a bit it becomes clear that what set.pop() returns
> > is independent of the insertion order:
>
> It might look like that, but I don't think this is
> true in general (at l
On Wed, Apr 8, 2009 at 8:10 AM, Jack diederich wrote:
> Plus he's a softie for decorators, as am I.
I must admit that while I still like decorators, I do like them as
much as in the past.
I also see an overuse of decorators in various libraries for things that could
be done more clearly without t
32 matches
Mail list logo
