On 17.06.2012 22:41, Guido van Rossum wrote:
Would it make sense to detect and reject these in 3.3 if the 2.7 syntax
is used?
Maybe we are talking about different things: The (new) proposal is that
the ur prefix in 3.3 is a syntax error (again, as it was before PEP
414). So, yes: the raw
On 6/17/2012 9:07 PM, Guido van Rossum wrote:
On Sun, Jun 17, 2012 at 4:55 PM, Nick Coghlan ncogh...@gmail.com
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 their
properly encoded (according to the
On 6/18/2012 12:43 AM, gmspro wrote:
What's the best way to debug python3 source code?
...
The pydev list is for development *of* future python releases. For
questions about development *with* current releases, please ask on
python-list or other user oriented forums.
--
Terry Jan Reedy
But the whole point of the reintroduction of u... is to support code
that isn't run through 2to3. Frankly, I don't care how it's done, but
I'd say it's important not to silently have different behavior for the
same notation in the two versions. If that means we have to add an extra
step to
What's the best way to debug python3 source code?
To fix a bug i need to debug source code(C files).
I use gdb to debug.
If the bug is presumably in C, then using gdb works fine for me.
But how can i get the exact file/point to fix the bug?
As usual: set breakpoints and watch points. In
On 6/18/2012 2:06 AM, Martin v. Löwis wrote:
Hm. I still encounter enough environments that don't know how to display
such characters that I would prefer to have a rock solid \u escape
mechanism.
If you want to use them under the revised PEP 414, you will have to
avoid making them raw, and
On Mon, Jun 18, 2012 at 3:59 PM, Martin v. Löwis mar...@v.loewis.de wrote:
On 17.06.2012 22:41, Guido van Rossum wrote:
Would it make sense to detect and reject these in 3.3 if the 2.7 syntax
is used?
Maybe we are talking about different things: The (new) proposal is that
the ur prefix in
On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett jimjjew...@gmail.com wrote:
*Every* Parameter attribute is optional, even name.
(Think of builtins, even if they aren't automatically
supported yet.) So go ahead
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
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.
Expect
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 changes,
On Mon, Jun 18, 2012 at 5:08 PM, Jim Jewett jimjjew...@gmail.com 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
@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
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 ncogh...@gmail.com wrote:
On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett jimjjew...@gmail.com wrote:
Instead of defining a BoundArguments class, just return
a copy of the Signature, with
On Mon, 18 Jun 2012 15:28:24 +0100
Mark Shannon m...@hotpy.org 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
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 ncogh...@gmail.com wrote:
On Mon, Jun 18, 2012 at 3:59 PM, Martin v. Löwis mar...@v.loewis.de
wrote:
On 17.06.2012 22:41, Guido van Rossum
On Sun, Jun 17, 2012 at 10:59 PM, Terry Reedy tjre...@udel.edu wrote:
On 6/17/2012 9:07 PM, Guido van Rossum wrote:
On Sun, Jun 17, 2012 at 4:55 PM, Nick Coghlan ncogh...@gmail.com
So, perhaps the answer is to leave this as is, and try to make 2to3
smart enough to detect such
On Mon, Jun 18, 2012 at 2:17 AM, Martin v. Löwis mar...@v.loewis.de 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
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
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 rdmur...@bitdance.comwrote:
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
On 6/18/2012 11:23 AM, Brian Curtin wrote:
On Mon, Jun 18, 2012 at 2:17 AM, Martin v. Löwis mar...@v.loewis.de 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
On 2012-06-18, at 1:35 PM, PJ Eby wrote:
On Fri, Jun 15, 2012 at 5:03 PM, R. David Murray rdmur...@bitdance.com
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.
On Mon, Jun 18, 2012 at 7:02 PM, Terry Reedy tjre...@udel.edu 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 solip...@pitrou.net wrote:
On Mon, 18 Jun 2012 15:28:24 +0100
Mark Shannon m...@hotpy.org 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
On Mon, 18 Jun 2012 21:31:27 +0200
Maciej Fijalkowski fij...@gmail.com wrote:
On Mon, Jun 18, 2012 at 5:04 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 18 Jun 2012 15:28:24 +0100
Mark Shannon m...@hotpy.org wrote:
But do they? The results of benchmarking would seem to suggest
Cool.
On Mon, Jun 18, 2012 at 10:19 AM, Terry Reedy tjre...@udel.edu 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
On Mon, Jun 18, 2012 at 11:09 AM, Yury Selivanov
yselivanov...@gmail.com 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
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
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
On Mon, Jun 18, 2012 at 10:37 AM, Yury Selivanov
yselivanov...@gmail.com wrote:
Jim,
On 2012-06-18, at 3:08 AM, Jim Jewett wrote:
On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett jimjjew...@gmail.com wrote:
Instead of
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
On Mon, 18 Jun 2012 13:46:25 -0700
Raymond Hettinger raymond.hettin...@gmail.com 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
Hi,
On Mon, Jun 18, 2012 at 9:10 PM, Maciej Fijalkowski fij...@gmail.com 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
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 cases.
Jim,
On 2012-06-18, at 5:06 PM, Jim Jewett wrote:
On Mon, Jun 18, 2012 at 10:37 AM, Yury Selivanov
yselivanov...@gmail.com wrote:
Jim,
On 2012-06-18, at 3:08 AM, Jim Jewett wrote:
On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Jun 16, 2012 at 1:56 PM, Jim
On 2012-06-18, at 4:25 PM, Guido van Rossum wrote:
On Mon, Jun 18, 2012 at 11:09 AM, Yury Selivanov
yselivanov...@gmail.com 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
On Mon, Jun 18, 2012 at 5:08 PM, Jim Jewett jimjjew...@gmail.com wrote:
On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan ncogh...@gmail.com 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).
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
yselivanov...@gmail.com wrote:
The rationale is that sometimes you need to modify signatures.
For instance, in decorators.
A decorator should make a modified copy, not
On Tue, Jun 19, 2012 at 7:06 AM, Jim Jewett jimjjew...@gmail.com 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
On 2012-06-18, at 9:29 PM, Nick Coghlan wrote:
On Tue, Jun 19, 2012 at 7:06 AM, Jim Jewett jimjjew...@gmail.com 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
On Tue, Jun 19, 2012 at 4:09 AM, Yury Selivanov yselivanov...@gmail.com 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
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,
if not
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.
2. If 'obj'
On 2012-06-18, at 9:36 PM, Nick Coghlan wrote:
On Tue, Jun 19, 2012 at 4:09 AM, Yury Selivanov yselivanov...@gmail.com
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
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
On Tue, Jun 19, 2012 at 12:00 PM, Yury Selivanov
yselivanov...@gmail.com 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
On 2012-06-18, at 10:06 PM, Nick Coghlan wrote:
On Tue, Jun 19, 2012 at 12:00 PM, Yury Selivanov
yselivanov...@gmail.com 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
On 6/18/2012 5:29 PM, Armin Rigo wrote:
On Mon, Jun 18, 2012 at 9:10 PM, Maciej Fijalkowski fij...@gmail.com 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.
On Tue, Jun 19, 2012 at 12:35 PM, Terry Reedy tjre...@udel.edu 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
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
54 matches
Mail list logo
