On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan wrote:
> On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett wrote:
>> *Every* Parameter attribute is optional, even name.
>> (Think of builtins, even if they aren't automatically
>>supported yet.) So go ahead and define some others
>>th
Hi all,
this is just a quick reminder that the feature freeze for 3.3
will start next weekend with the release of beta1. Since I
won't be able to shift that date for short periods (the next
possible date for me would be around July 16), I hope that
everybody has planned ahead accordingly.
Let m
> this is just a quick reminder that the feature freeze for 3.3
> will start next weekend with the release of beta1. Since I
> won't be able to shift that date for short periods (the next
> possible date for me would be around July 16), I hope that
> everybody has planned ahead accordingly.
Expe
> The default should be what we've had though.
> The new settings cause a lot more collisions
> and resizes.
Raymond, can you kindly point to an application that demonstrates this
claim (in particular the "a lot more" part, which I'd translate to
"more than 20% more").
I'm fine with reverting cha
On Mon, Jun 18, 2012 at 5:08 PM, Jim Jewett wrote:
> But perhaps they *should* know their relative position.
No, relative position is a property of the Signature - a parameter has
no position until it is made part of a signature.
> Also,
> positional_only, *args, and **kwargs should be able to r
@martin,
I'm working on this bug, http://bugs.python.org/issue15068
I tried this with gdb
(gdb)run
>>>from sys import stdin
>>>str=sys.stdin.read()
blabla
blabla
blabla
CTRL+D
CTRL+D
>>>CTRL+C
(gdb)backtrace
0xb7f08348 in ___newselect_nocancel () at ../sysdeps/unix/syscall-template.S:82
82 ../
Hi all,
We (=fijal and myself) finally released the beta-0.1 version of CFFI.
http://cffi.readthedocs.org/
It is a(nother) simple Foreign Function Interface for Python calling C
code. I talked about it with a few python core people during the
PyCon sprint; now it's done, with a pure Python part
Martin v. Löwis wrote:
The default should be what we've had though.
The new settings cause a lot more collisions
and resizes.
Raymond, can you kindly point to an application that demonstrates this
claim (in particular the "a lot more" part, which I'd translate to
"more than 20% more").
It is
Jim,
On 2012-06-18, at 3:08 AM, Jim Jewett wrote:
> On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan wrote:
>> On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett wrote:
>
>>>Instead of defining a BoundArguments class, just return
>>> a copy of the Signature, with "value" attributes added to
>>
On Mon, 18 Jun 2012 15:28:24 +0100
Mark Shannon wrote:
>
> But do they? The results of benchmarking would seem to suggest (at least
> on my test machine) that overly-sparse dicts are slower.
> Possibly due to increased cache misses.
Or, at least, they are not faster. See the synthetic experiment
Ok, banning ru"..." and ur"..." altogether is fine too (assuming it's fine
with the originators of the PEP).
On Sun, Jun 17, 2012 at 11:31 PM, Nick Coghlan wrote:
> On Mon, Jun 18, 2012 at 3:59 PM, "Martin v. Löwis"
> wrote:
> > On 17.06.2012 22:41, Guido van Rossum wrote:
> >> Would it make se
On Sun, Jun 17, 2012 at 10:59 PM, Terry Reedy wrote:
> On 6/17/2012 9:07 PM, Guido van Rossum wrote:
>
>> On Sun, Jun 17, 2012 at 4:55 PM, Nick Coghlan >
>
> So, perhaps the answer is to leave this as is, and try to make 2to3
>>smart enough to detect such escapes and replace them with the
On Mon, Jun 18, 2012 at 2:17 AM, "Martin v. Löwis" wrote:
>> this is just a quick reminder that the feature freeze for 3.3
>> will start next weekend with the release of beta1. Since I
>> won't be able to shift that date for short periods (the next
>> possible date for me would be around July 16
On 6/18/2012 7:10 AM, gmspro wrote:
I'm working on this bug, http://bugs.python.org/issue15068
Oh. From your first message, I thought you were asking about a personal
bug. I will mention that real names are customary on this list. (Unless
you have a good professional reason otherwise.) They
On 6/18/2012 9:14 AM, Armin Rigo wrote:
Hi all,
We (=fijal and myself) finally released the beta-0.1 version of CFFI.
http://cffi.readthedocs.org/
It is a(nother) simple Foreign Function Interface for Python calling C
code. I talked about it with a few python core people during the
PyCon spri
On 6/18/2012 11:12 AM, Guido van Rossum wrote:
Ok, banning ru"..." and ur"..." altogether is fine too (assuming it's
fine with the originators of the PEP).
The original PEP never proposed ur or ru , only u/U.
It turns out that ur is problematical even in 2.x, as its meaning is
changed by the
On Fri, Jun 15, 2012 at 5:03 PM, R. David Murray wrote:
> On Fri, 15 Jun 2012 22:48:42 +0200, Victor Stinner <
> victor.stin...@gmail.com> wrote:
> > > 1. Should we keep 'Parameter.implemented' or not. *Please vote*
>
> -1 to implemented.
>
> > I still disagree with the deepcopy. I read somewhere
On 6/18/2012 11:23 AM, Brian Curtin wrote:
On Mon, Jun 18, 2012 at 2:17 AM, "Martin v. Löwis" wrote:
this is just a quick reminder that the feature freeze for 3.3
will start next weekend with the release of beta1. Since I
won't be able to shift that date for short periods (the next
possible d
On 2012-06-18, at 1:35 PM, PJ Eby wrote:
> On Fri, Jun 15, 2012 at 5:03 PM, R. David Murray
> wrote:
> On Fri, 15 Jun 2012 22:48:42 +0200, Victor Stinner
> wrote:
> > > 1. Should we keep 'Parameter.implemented' or not. *Please vote*
>
> -1 to implemented.
>
> > I still disagree with the dee
On Mon, Jun 18, 2012 at 7:02 PM, Terry Reedy wrote:
> On 6/18/2012 9:14 AM, Armin Rigo wrote:
>
>> Hi all,
>>
>> We (=fijal and myself) finally released the beta-0.1 version of CFFI.
>>
>> http://cffi.readthedocs.org/
>>
>> It is a(nother) simple Foreign Function Interface for Python calling C
>>
On Mon, Jun 18, 2012 at 5:04 PM, Antoine Pitrou wrote:
> On Mon, 18 Jun 2012 15:28:24 +0100
> Mark Shannon wrote:
> >
> > But do they? The results of benchmarking would seem to suggest (at least
> > on my test machine) that overly-sparse dicts are slower.
> > Possibly due to increased cache miss
On Mon, 18 Jun 2012 21:31:27 +0200
Maciej Fijalkowski wrote:
> On Mon, Jun 18, 2012 at 5:04 PM, Antoine Pitrou wrote:
>
> > On Mon, 18 Jun 2012 15:28:24 +0100
> > Mark Shannon wrote:
> > >
> > > But do they? The results of benchmarking would seem to suggest (at least
> > > on my test machine) t
Cool.
On Mon, Jun 18, 2012 at 10:19 AM, Terry Reedy wrote:
> On 6/18/2012 11:12 AM, Guido van Rossum wrote:
>
>> Ok, banning ru"..." and ur"..." altogether is fine too (assuming it's
>> fine with the originators of the PEP).
>>
>
> The original PEP never proposed ur or ru , only u/U.
>
> It turn
On Mon, Jun 18, 2012 at 11:09 AM, Yury Selivanov
wrote:
> The rationale is that sometimes you need to modify signatures.
> For instance, in decorators.
A decorator should make a modified copy, not modify it in place (since
the signature of the decorated function does not change, and you have
no g
On Jun 18, 2012, at 12:35 PM, Antoine Pitrou wrote:
> You are right. I was thinking 50 nanoseconds (which for a - relatively
> high-end - 3GHz CPU puts us at 150 cycles).
The last guidance I read from Intel said that
a cache miss was roughly as expensive as a floating-point divide.
When a dicti
> But i can't get any clue which file to look at.
I personally wouldn't use gdb but strace to establish what system calls
are being made, and decide whether these system calls are correct or
not. If you then think that some call is being made that shouldn't,
set a breakpoint on the syscall functio
On Mon, Jun 18, 2012 at 10:37 AM, Yury Selivanov
wrote:
> Jim,
>
> On 2012-06-18, at 3:08 AM, Jim Jewett wrote:
>> On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan wrote:
>>> On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett wrote:
Instead of defining a BoundArguments class, just return
Raymond Hettinger wrote:
Sorry I can make a more detailed post right now. I'll make time in
the next couple of weeks to post some code and timings that
document the collision counts, total memory size, and its affect
on various dict use cases.
Is there some way to instrument dictionary spars
On Mon, 18 Jun 2012 13:46:25 -0700
Raymond Hettinger wrote:
>
> On Jun 18, 2012, at 12:35 PM, Antoine Pitrou wrote:
>
> > You are right. I was thinking 50 nanoseconds (which for a - relatively
> > high-end - 3GHz CPU puts us at 150 cycles).
>
> The last guidance I read from Intel said that
> a
Hi,
On Mon, Jun 18, 2012 at 9:10 PM, Maciej Fijalkowski wrote:
>> Make cffi less buggy (check the tracker for new test cases ;-), faster
>> (closer to swig type wrappers), and easier to use than ctypes, and I am sure
>> there will be interest.
>
> I would say it's already fulfilling those three,
On 18.06.2012 23:08, Steven D'Aprano wrote:
> Raymond Hettinger wrote:
>
>> Sorry I can make a more detailed post right now. I'll make time in
>> the next couple of weeks to post some code and timings that
>> document the collision counts, total memory size, and its affect
>> on various dict use
Jim,
On 2012-06-18, at 5:06 PM, Jim Jewett wrote:
> On Mon, Jun 18, 2012 at 10:37 AM, Yury Selivanov
> wrote:
>> Jim,
>>
>> On 2012-06-18, at 3:08 AM, Jim Jewett wrote:
>>> On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan wrote:
On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett
wrote:
>
On 2012-06-18, at 4:25 PM, Guido van Rossum wrote:
> On Mon, Jun 18, 2012 at 11:09 AM, Yury Selivanov
> wrote:
>> The rationale is that sometimes you need to modify signatures.
>> For instance, in decorators.
>
> A decorator should make a modified copy, not modify it in place (since
> the signat
On Mon, Jun 18, 2012 at 5:08 PM, Jim Jewett wrote:
> On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan wrote:
>> No. This is the full set of binding behaviours. "self" is just an
>> ordinary "POSITIONAL_OR_KEYWORD" argument (or POSITIONAL_ONLY, in some
>> builtin cases).
>
> Or no longer a "paramete
Yury Selivanov wrote:
On 2012-06-18, at 4:25 PM, Guido van Rossum wrote:
On Mon, Jun 18, 2012 at 11:09 AM, Yury Selivanov
wrote:
The rationale is that sometimes you need to modify signatures.
For instance, in decorators.
A decorator should make a modified copy, not modify it in place (since
On Tue, Jun 19, 2012 at 7:06 AM, Jim Jewett wrote:
> Correct; it should be redundant. Signature.kwargsparameter should be
> the same object that occurs as the nth element of
> Signature.parameters.values(). It is just more convenient to retrieve
> the parameter directly than it is to iterate thr
On 2012-06-18, at 9:29 PM, Nick Coghlan wrote:
> On Tue, Jun 19, 2012 at 7:06 AM, Jim Jewett wrote:
>> Correct; it should be redundant. Signature.kwargsparameter should be
>> the same object that occurs as the nth element of
>> Signature.parameters.values(). It is just more convenient to retrie
On Tue, Jun 19, 2012 at 4:09 AM, Yury Selivanov wrote:
> On 2012-06-18, at 1:35 PM, PJ Eby wrote:
>> Then just copy the signature itself; as currently written, this is going to
>> copy the annotation objects, which could produce weird side-effects from
>> introspection. Using deepcopy seems lik
On Mon, Jun 18, 2012 at 07:10:33PM -0400, Yury Selivanov wrote:
> It seems that we have the following options for 'signature(obj)':
>
> 1. If 'obj' has a '__signature__' attribute - return a copy of it,
> if not - create a new one.
>
> 2. If 'obj' has a '__signature__' attribute - return it,
> i
On 2012-06-18, at 9:50 PM, Steven D'Aprano wrote:
> On Mon, Jun 18, 2012 at 07:10:33PM -0400, Yury Selivanov wrote:
>
>> It seems that we have the following options for 'signature(obj)':
>>
>> 1. If 'obj' has a '__signature__' attribute - return a copy of it,
>> if not - create a new one.
>>
>
On 2012-06-18, at 9:36 PM, Nick Coghlan wrote:
> On Tue, Jun 19, 2012 at 4:09 AM, Yury Selivanov
> wrote:
>> On 2012-06-18, at 1:35 PM, PJ Eby wrote:
>>> Then just copy the signature itself; as currently written, this is going to
>>> copy the annotation objects, which could produce weird side-e
On Mon, Jun 18, 2012 at 02:09:17PM -0400, Yury Selivanov wrote:
> That's an excerpt from Signature.__deepcopy__:
>
> cls = type(self)
> sig = cls.__new__(cls)
> sig.parameters = OrderedDict((name, param.__copy__()) \
>for name, param in self.parameters.i
On Tue, Jun 19, 2012 at 12:00 PM, Yury Selivanov
wrote:
> On 2012-06-18, at 9:36 PM, Nick Coghlan wrote:
>> So keep the current copying semantics for Signature objects (i.e.
>> creating new copies of the Parameter objects as well), but call it a
>> shallow copy rather than a deep copy. Make it cle
On 2012-06-18, at 10:06 PM, Nick Coghlan wrote:
> On Tue, Jun 19, 2012 at 12:00 PM, Yury Selivanov
> wrote:
>> On 2012-06-18, at 9:36 PM, Nick Coghlan wrote:
>>> So keep the current copying semantics for Signature objects (i.e.
>>> creating new copies of the Parameter objects as well), but call
On 6/18/2012 5:29 PM, Armin Rigo wrote:
On Mon, Jun 18, 2012 at 9:10 PM, Maciej Fijalkowski wrote:
>> Me
Make cffi less buggy (check the tracker for new test cases ;-), faster
(closer to swig type wrappers), and easier to use than ctypes, and I am sure
there will be interest.
I would say it'
On Tue, Jun 19, 2012 at 12:35 PM, Terry Reedy wrote:
> Yes, because languages have no speed, only implementations do; and yes,
> because when CPython really is too slow for a particular task, it can be
> pushed onto C. But some people (pygame, others on python-list) have reported
> that for their
Martin approached me earlier and requested that I act as PEP czar for
397. I haven't been involved in the writing of the PEP and have been
mostly observing from the outside, so I accepted and hope to get this
wrapped up quickly and implemented in time for the beta. The PEP is
pretty complete, but t
Armin Rigo, 18.06.2012 23:29:
> On Mon, Jun 18, 2012 at 9:10 PM, Maciej Fijalkowski wrote:
>>> Make cffi less buggy (check the tracker for new test cases ;-), faster
>>> (closer to swig type wrappers), and easier to use than ctypes, and I am sure
>>> there will be interest.
>>
>> I would say it's a
> Agreed, I would expect the same. I would think taking out the word
> "only" and then flipping newer and older in the sentence would correct
> it.
Will change.
>> "On 64bit Windows with both 32bit and 64bit implementations of the same
>> (major.minor) Python version installed, the 64bit version
Is there any provision for keeping the compiled
C code and distributing it along with an application?
Requiring a C compiler to be present at all times
could be a difficulty for Windows.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://m
50 matches
Mail list logo
