Nick Coghlan wrote:
On Fri, Mar 9, 2012 at 6:19 PM, Mark Shannon wrote:
The Python API would be changed, but in a backwards compatible way.
exec, eval and __import__ would all gain an optional (keyword-only?)
"builtins" parameter.
No, some APIs effectively define *protocols*. For
mespace triple.
When globals is different from the previous frame? When you call a
function from a different module maybe?
Do you have an idea of the speedup of your optimization?
No. But it won't be slower.
Cheers,
Mark
___
Python-Dev
On 09/03/2012 12:57, Mark Shannon wrote:
No. But it won't be slower.
Cheers,
Mark
Please prove it, you have to convince a number of core developers
including, but not limited to, the BDFL :).
--
Cheers.
Mark Lawrence.
___
Python-Dev ma
Guido van Rossum wrote:
Mark, did you do anything with my reply?
Not yet.
I noticed the difference when developing my HotPy VM
(latest incarnation thereof) which substitutes a sequence of low-level
bytecodes for the high-level ones when tracing.
(A bit like PyPy but much more Python-specific
st wear the costs of the existing scheme in the stdlib and
avoid breaking the code already out there? IOW, who exactly will
benefit from this, and how does the cost of them supporting the existing
scheme compare to the cost of the breakage to multiple 3rd parties?
Mark
about in order to find the ones I
can review.
There does not seem to be a way to filter search results in the tracker.
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
On 15/03/2012 3:03 AM, Lindberg, Van wrote:
On 3/14/2012 1:32 AM, Mark Hammond wrote:
As per comments later in the thread, I'm -1 on including
"python{py_version_short}" in the lib directories for a number of
reasons; one further reason not outlined is that it would potential
[resending - original reply went only to Van]
On 15/03/2012 10:15 AM, Lindberg, Van wrote:
> On 3/14/2012 5:39 PM, Mark Hammond wrote:
>> Can you offer any examples of 3rd party tools which could unify code
>> in this scheme, and particularly, where this scheme would cause them
On 16/03/2012 8:57 AM, VanL wrote:
On 3/14/2012 6:30 PM, Mark Hammond wrote:
So why not just standardize on that new layout for virtualenvs?
That sounds like the worst of all worlds - keep all the existing special
cases, and add one.
I'm not so sure. My concern is that this *will*
bin" instead of "Scripts" makes the virtualenv
more consistent across platforms and doesn't impose any additional
special-casing for Windows (just slightly changes the existing
special-case :)
Thanks,
Mark
___
Python-Dev mail
- that the Python executable would remain in the same
place for installed Pythons in the interests of b/w compat, but change
it in the virtual env in an effort to keep Van happy when working in
such environments. I now fully concede that was a dumb idea
considerations apply equally to the
Windows installs and we just live with this platform difference.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
On 17/03/2012 12:07 PM, Brian Curtin wrote:
On Fri, Mar 16, 2012 at 19:53, Mark Hammond wrote:
For the sake of brain-storming, how about this:
* All executables and scripts go into the root of the Python install. This
directory is largely empty now - it is mainly a container for other
On 17/03/2012 12:25 PM, Carl Meyer wrote:
Hi Mark,
On 03/16/2012 05:53 PM, Mark Hammond wrote:
* All executables and scripts go into the root of the Python install.
This directory is largely empty now - it is mainly a container for other
directories. This would solve the problem of needing 2
tual change not happening until 3.5.
"""
While I'm still unclear on the actual benefits of this, Martin's
approach strikes a reasonable compromise so I withdraw my objections.
Thanks,
Mark
___
Python-Dev mailing list
Python-Dev@p
On 21/03/2012 1:08 AM, Lindberg, Van wrote:
On 3/20/2012 5:48 AM, Mark Hammond wrote:
While I'm still unclear on the actual benefits of this, Martin's
approach strikes a reasonable compromise so I withdraw my objections.
Ok. I was out of town and so could not respond to most of
vated. So even if an installer does arrange
elevation, unless that installer also compiles all .pyc and .pyo files
at install time, Python would fail to generate the .pyc files on first
use. While Python will probably fail silently and still continue to
work
On 21/03/2012 9:45 AM, R. David Murray wrote:
On Wed, 21 Mar 2012 09:09:38 +1100, Mark Hammond
wrote:
On 21/03/2012 5:50 AM, Merlijn van Deen wrote:
I asked a question about this on IRC, to which the response was that
there were two main reasons to install python in c:\pythonxy:
1 - issues
On 22/03/2012 1:22 AM, Lindberg, Van wrote:
Mark, MAL, Martin, Tarek,
Could you comment on this?
Eric is correct - tools will be broken by this change. However, people
seem willing to push forward on this and accept such breakage as the
necessary cost.
MAL, in his followup, asks what the
e" above. What would the instructions above now say?
That the user should re-install Python ensuring to set that checkbox?
Cover both cases, including how the user can tell if it is on the PATH
and how to fix it otherwise? Something else?
Breakage of existing tools: Mark Hammond, Paul Moore, and Tim
which only use the old key would break
without warning. The fact they need to change at all is unfortunate,
but the timescale proposed means we can at least say we warned them.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
On 23/03/2012 7:10 PM, Paul Moore wrote:
On 23 March 2012 03:20, Brian Curtin wrote:
Breakage of existing tools: Mark Hammond, Paul Moore, and Tim Golden have
all expressed that they have existing tools that would break and would need
to be adjusted to match the new location of the python.exe
nt but I'm with (I think) Terry Reedy and Steven D'Aprano in
that hires is an English word, could you please substitute highres and
HIGHRES, thanks.
--
Cheers.
Mark Lawrence.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
API. Rather short term pain and long term gain than vice
versa.
Just my 2p worth.
--
Cheers.
Mark Lawrence.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
and will think about it, night all.
--
Cheers.
Mark Lawrence.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
113381/)
Now PEP 419 proposes adding (yet) another field to the frame object.
Please don't.
Clean, concise data structures lead to clean, concise code.
which we all know is a "good thing" :)
Cheers,
Mark.
___
Python-Dev mailing list
Pytho
a struct within the frame. The aim is clarity;
locals, globals and builtins form a trio, so should be implemented as such.
On Mon, Apr 9, 2012 at 11:56 AM, Mark Shannon wrote:
The frame object is a key object in CPython. It holds the state
of a function invocation. Frame objects are allocated
Guido van Rossum wrote:
On Mon, Apr 9, 2012 at 3:51 AM, Mark Shannon wrote:
f_namespaces would be part of the frame, replacing f_builtins, f_globals
and f_locals. The indirection of an external object hurts performance,
so it would have to be a struct within the frame. The aim is clarity
placement of frame->f_state
with PyThreadState_GET() at one place in _PyEval_CallTracing)
Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opt
tests (except for 1 test in test_pprint which relies on dict/set
ordering, see http://bugs.python.org/issue13907)
Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
.
Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
urllib2net leaked [432, 432, 432] references, sum=1296
test_urllibnet leaked [103, 103, 103] references, sum=309
These seem to have been introduced by changeset 6e5855854a2e: “Implement
PEP 412: Key-sharing dictionaries (closes #13903)”.
I'm investigating at the moment
t.
If any of these change then the semantics of the language changes.
Cheers,
Mark
benjamin.peterson wrote:
http://hg.python.org/cpython/rev/971865f12377
changeset: 76518:971865f12377
branch: 3.2
parent: 76506:f7b002e5cac7
user:Benjamin Peterson
date:Tue Apr 24 11:06:25 201
Benjamin Peterson wrote:
2012/4/24 Mark Shannon :
I'm not happy with this fix.
It's not perfect, but it's an improvement.
Admittedly code like:
class S(str):
__getattr__ = str.__add__
s = S('a')
print(S.b)
My typo, should be:
print(s.b)
(Instance not class)
T
Benjamin Peterson wrote:
2012/4/24 Mark Shannon :
I'm not happy with this fix.
It's not perfect, but it's an improvement.
Actually, I think it is probably correct.
I've been trying to break it by assigning various unusual
objects to special attributes and it seems OK so
r in tests for tempfile.TemporaryDirectory,
although I don't know what is special about that code.
I'll investigate further when I have time.
Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
int "peak blocks: %d, peak mem: %d"%allocator.peak()
Take a look at the benchmark suite at
http://hg.python.org/benchmarks/
The test runner has an -m option that profiles memory usage,
you could take a look at how that is implemented
Cheers,
Mark.
_
I missing something obvious?
A URL for the code repository (with an open-source license),
so code can be reviewed.
It is hard to review and update a giant patch.
Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
ly)".
monotonic is an adjective, whereas adjusted is (part of) a verb. I think
both should be adjectives. Does "adjusted" mean that it has been
adjusted, that it can be adjusted or it will be adjusted?
Cheers,
Mark.
___
Python-Dev ma
two
parts?
1. language & library changes.
The details are important here, so that the PEPs should probably be
fairly prominent.
2. Performance enhancements
People want to know how much faster 3.3 is or how less memory it uses.
Who cares which PEP does what (apart from the authors)?
Or maybe
Nick Coghlan wrote:
On Wed, May 2, 2012 at 7:55 PM, Mark Shannon wrote:
Or maybe three parts?
New features.
Behavioural changes (i.e. bug fixes)
Performance enhancements
The release PEPs are mainly there for *our* benefit, not end users.
For end users, it's the What's New doc
e changes (with links to the
relevant PEPs) separately to library extensions and optimizations.
If the reader is interested in new features, then information about
optimisations are just clutter. And vice-versa.
Cheers,
Mark.
___
Python-Dev mailing
congruent to 1, 2 or 4 modulo 5, we're safe.
Is the gain from this kind of micro-optimization really worth the cost
of replacing obviously correct code with code whose correctness needs
several minutes of thought?
Mark
___
Python-Dev mail
On Mon, May 7, 2012 at 12:35 PM, Mark Dickinson wrote:
> will almost always be one less than a power of 2 and powers of 2 are
> always congruent to 1, 2 or 4 modulo 5, we're safe.
Bah. That should have read "1, 2, 3 or 4 modulo 5".
_
ass either a class method or a
static method will cause a direct call to type.build_class() to fail as
neither class method nor static method are callable.
Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
Nick Coghlan wrote:
On Wed, May 9, 2012 at 5:57 PM, Mark Shannon wrote:
As a consequence of this, making build_class either a class method or a
static method will cause a direct call to type.build_class() to fail as
neither class method nor static method are callable.
We'll make su
at I'm a good judge of Pythonicness :)
Finally, could you remind me how the proposed type.define differs from
builtins.__build_class__?
I can't see any difference (apart from parameter ordering and the extra
name parameter in builtins.__build_class__).
Cheers,
Mark.
_
Nick Coghlan wrote:
On Thu, May 10, 2012 at 6:11 PM, Mark Shannon wrote:
Finally, could you remind me how the proposed type.define differs from
builtins.__build_class__?
I can't see any difference (apart from parameter ordering and the extra name
parameter in builtins.__build_class__).
on strategy - whether we
redirect to the C machinery as originally proposed (either via
__build_class__ or a new _types module) or just reimplement the
algorithm in pure Python. The latter is actually quite an appealing
concept, since it becomes a cross-check on the native C version.
+1
s.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/mark%40hotpy.org
___
Python-
uiltin_TypeOf(func), "d,d->d") == 0)
cfunc = Py_ExtendedFunctionBuiltin_GetFunctionPtr(func);
else
goto feature_not_provided;
for (;;)
/* Loop using cfunc */
[snip]
Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
Dag Sverre Seljebotn wrote:
On 05/16/2012 02:47 PM, Mark Shannon wrote:
Stefan Behnel wrote:
Dag Sverre Seljebotn, 16.05.2012 12:48:
On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote:
Agreed in general, but in this case, it's really not that easy. A C
function call involves a c
Robert Bradshaw wrote:
On Wed, May 16, 2012 at 8:40 AM, Mark Shannon wrote:
Dag Sverre Seljebotn wrote:
On 05/16/2012 02:47 PM, Mark Shannon wrote:
Stefan Behnel wrote:
Dag Sverre Seljebotn, 16.05.2012 12:48:
On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote:
Agreed in general, b
uot; is probably only 2-3 ns,
and there could very easily be multiple such functions, defined in
different modules, in a chain, in order to build up a formula.
Such micro timings are meaningless, because the working set often tends
to fit in the hardware cache. A level 2 cache miss can tak
-O0 builds (which is how I have managed to retrieve the detailed stack
Please submit a report to the tracker for this.
(Add me to the nosy list if you can)
Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
preferred option: bring PEP 397 up to scratch as a specification
for the behaviour of the Python launcher (perhaps with Vinay stepping
up as a co-author to help Mark if need be), find a BDFL delegate (MvL?
Brian Curtin?) and submit that PEP for acceptance within the next few
weeks. The updated PEP 3
of python-dev's general sentiment in this
space.
-eric
[1] http://bugs.python.org/issue14673
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/option
sys.version
and moved it to sys.implementation?
Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Nick Coghlan wrote:
On Fri, Jun 1, 2012 at 9:49 PM, Mark Shannon wrote:
What is wrong with something like the following (for CPython)?
class SysImplemention:
"Define __repr__(), etc here "
...
sys.implementation = SysImplemention()
sys.implementation.name
Nick Coghlan wrote:
On Fri, Jun 1, 2012 at 11:17 PM, Mark Shannon wrote:
import imp
tag = imp.get_tag()
sys.implementation = SysImplementation()
sys.implementation.name = tag[:tag.index('-')]
sys.implementation.version = sys.version_info
sys.implementation.hexversion = sys.hexvers
been available on pypi for years.
Umpteen bugs against the original re module have been fixed. If regex
can't now go into the standard library, what on earth can?
--
Cheers.
Mark Lawrence.
___
Python-Dev mailing list
Python-Dev@python.org
s type (C is int),
even though the declared metaclass is 'silly'.
I assume it is too late to change the name of the 'metaclass' keyword to
'factory', but we could use that terminology in the docs.
Cheers,
Mark
___
Python-Dev
Steven D'Aprano wrote:
Brett Cannon wrote:
PEP: 362
Title: Function Signature Object
Version: $Revision$
Last-Modified: $Date$
Author: Brett Cannon , Jiwon Seo ,
Yury Selivanov , Larry Hastings <
la...@hastings.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2
stand.
--
Cheers.
Mark Lawrence.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
as it has historical
information and results of previous experiments.
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
d not have been changed.
Parameters for tuning code and the code itself are unlikely to be
orthogonal. While I did strive to minimise the impact of the changes on
combined-table dicts, the performance characteristics have necessarily
changed.
Cheers,
Mark.
___
Raymond Hettinger wrote:
On Jun 13, 2012, at 2:37 PM, Mark Shannon wrote:
I think that for combined tables a growth factor of x2 is best,
but I don't have any hard evidence to back that up.
I believe that change should be reverted.
You've undone work that was based on extensi
faster for these very small dictionaries.
However, a 4 entry table fits into a single cache line (for a 64 byte cache
line on a 32 bit machine) which may save a lot of cache misses.
But this all conjecture. Whatever the reason, the current parameters give
the bes
without the 32bit compilers installed. But (b)
is really only a theoretical problem so I think in practice it would be
fine either way.
Thanks to Martin for updating it - I agree it is vastly improved!
Cheers,
Mark
On 19/06/2012 2:31 PM, Brian Curtin wrote:
Martin approached me earlier and
On 22/06/2012 8:14 AM, Brian Curtin wrote:
On Wed, Jun 20, 2012 at 11:54 AM, Brian Curtin wrote:
As the PEP czar for 397, after Martin's final updates, I hereby
pronounce this PEP "accepted"!
Thanks to Mark Hammond for kicking it off, Vinay Sajip for writing up
the code, Martin
, bad experience for
developers, everybody is annoyed and as a result such nice language as
Python loses points on TIOBE (and convenient chunk() functions to
munch-munch on the sequence data).
Wheew. :-F
Can I safely assume that you are volunteering to do the work required?
--
Cheers.
Mark Lawr
Don't want to return any value or "don't know": return NotImplemented
b) For infinite iterators: raise an OverflowError
c) All other cases: return an int or a type with a __index__() method.
Cheers,
Mark.
___
Python-Dev mailing list
Python-
70
coding: utf-8
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/mark%40hotpy.org
___
Python-Dev mailing l
Brett Cannon wrote:
On Sun, Jul 15, 2012 at 10:39 AM, Mark Shannon <mailto:m...@hotpy.org>> wrote:
Nick Coghlan wrote:
Right, I agree on the value in being able to return something to
say "this cannot be converted to a concrete container".
I s
ing of lists is too slow, then we should reconsider the 9/8 factor
and/or look to tweak the resizing code.
Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
meaning to what's already a valid
length value seems wrong.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 17/07/2012 23:20, Victor Stinner wrote:
http://psyco.sourceforge.net/ says:
"News, 12 March 2012
Psyco is unmaintained and dead. Please look at PyPy for the
state-of-the-art in JIT compilers for Python."
Victor
A search on pypi for JIT compilers gives no matches.
--
Che
On 18/07/2012 06:55, mar...@v.loewis.de wrote:
Zitat von Mark Lawrence :
On 17/07/2012 23:20, Victor Stinner wrote:
http://psyco.sourceforge.net/ says:
"News, 12 March 2012
Psyco is unmaintained and dead. Please look at PyPy for the
state-of-the-art in JIT compilers for Python.&quo
on't forget the old saying about blaming your tools ;)
If HotPy (version 2) were to have an (optional) JIT I would expect it to be
LLVM based.
The JIT can run in a separate thread, while the optimised code continues to run
in the interpreter, patching in the machine code when it is complete.
C
tor protocol allows sequences,
notably lists,
to be initialised from iterators with only a single resize operation.
This allows sequences to be intialised quickly, yet have a small growth factor,
reducing memory use.
'''
Cheers,
Mark.
__
Maciej Fijalkowski wrote:
On Wed, Aug 1, 2012 at 10:46 AM, Mark Shannon wrote:
While the idea behind PEP 424 is sound, the text of the PEP is rather vague
and missing a lot of details.
There was extended discussion on the details, but none of that has appeared
in the PEP yet.
So Alex, how
Hi all,
I keep an eye open for this but can't find one for Saturday 03/08/2012.
Have I missed it, has it been stopped, has something gone wrong with
its production or what?
--
Cheers.
Mark Lawrence.
___
Python-Dev mailing list
Pytho
timizers for static
compilers.
All for the price of adding a single method to SourceLoader.
What a bargain :)
Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyth
ing
bigfloat.
I'm afraid I don't have the exact scripts that I used any more;
they're sitting on the hard drive of a defunct computer that's
awaiting resurrection.
Mark
[1] http://www.multiprecision.org/
[2] http://code.google.com/p/gmpy/
___
how to define optional formal parameters under the heading
"keyword arguments".
I submit that the word 'positional' in the TypeError message
exacerbates this confusion, and that little would be lost by simply
dropping it from the exception message.
Thoughts?
Mark
on that f only requires one argument.
Perhaps this simply isn't worth worrying about, especially since the
current error messages are all but certain to make it into the 3.3
release.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
x27;t have a good alternative suggestion. If we could find a
suitable word and bless it in the documentation, it might make it
easier to make clear and accurate statements about Python's function
calling.
Mark
___
Python-Dev mailing list
Python-De
On Thu, Sep 20, 2012 at 4:14 PM, Benjamin Peterson wrote:
> 2012/9/20 Mark Dickinson :
>> And excepting optional ones, too, right? E.g., the c in
>>
>> def foo(a, b, c=1, *args, d):
>> pass
>>
>> can be passed to by position, but isn't
x27;s contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlBf+0cACgkQN9GcIYhpnLBqfgCglbN63XUr2m4Ya4ff8Hza1Axl
SgMAniQZRJi8uYfeqltf5/G4QV/+SdWT
=KXTo
-END PGP SIGNATURE-
Yes, but apart from all that, what have the python devs ever done
naive extremely simple approach reference it on pypi?!?!
--
Cheers.
Mark Lawrence.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
;
> Certainly 3.x, but not 2.7.
+1 for relaxing the check in 3.x.
The cmath code uses "PyArg_ParseTuple(args, "D", ...) for this;
perhaps it's the "D" format for PyArg_ParseTuple that should be
relaxed. It seems more than reasonab
We might also want to consider having PyComplex_AsCComplex check for
__float__, again for consistency with the 'complex' constructor:
>>> class A(object):
... def __float__(self):
... return 42.0
...
>>> a = A()
t redundancy like:
>
> def __complex__(self):
> return complex(value)
>
> or
>
> def __complex__(self):
> return value + 0j
I've opened bugs.python.org/issue16290 to track this.
--
Mark
___
Python-De
gt; Also PyComplex_AsComplex() should perhaps enforce that.
It already does. `complex_new` doesn't use `PyComplex_AsCComplex`.
--
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
complicated enough that it's not
at all evident that anyone thought 'float' was appropriate; that it's
accepted may have just been a side-effect of the implementation.
--
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://
Original Message
Subject: Python 3.3 can't sort memoryviews as they're unorderable
Date: Sun, 21 Oct 2012 12:24:32 +0100
From: Mark Lawrence
To: python-l...@python.org
Newsgroups: gmane.comp.python.general
http://docs.python.org/dev/whatsnew/3.3.html states &
On 24/10/2012 13:19, Nick Coghlan wrote:
(Oops, originally replied only to Mark)
Is a 3x3 array greater or less than a 2x4 array or another 3x3 array?
The contents of a 1D memory view may be sortable, but the "logical
structure" part isn't, and neither is any multi-dimensi
On 25/10/2012 15:06, Stefan Krah wrote:
Mark Lawrence wrote:
I can't say that this gives me a great deal of confidence. It strikes me
that a lot of code has been written, tested and released without having
anything like a requirement. For example when is any given memoryview
equal to o
starts up quite a lot faster thanks to embedding all the modules
in the executable: http://www.egenix.com/products/python/PyRun/
Freezing all the core modules into the executable should reduce start up
time.
Cheers,
Mark
___
Python-Dev mailing list
On 27/10/12 21:59, Antoine Pitrou wrote:
On Sat, 27 Oct 2012 21:40:26 +0100
Mark Shannon wrote:
On 27/10/12 20:21, Antoine Pitrou wrote:
It would be interesting to know *where* the module import time gets
spent, on a lower level. My gut feeling is that execution of Python
module code is the
1201 - 1300 of 1370 matches
Mail list logo
