On Tue, 8 Oct 2013 08:31:46 +1000
Nick Coghlan ncogh...@gmail.com wrote:
That said, with the current plan to lower the barrier to entry for PyPI
dependencies (I should have the 3.4 only ensurepip proposal written up some
time this week), I think it makes sense to let this one bake on PyPI for
Le Tue, 8 Oct 2013 08:21:43 +0200,
Antoine Pitrou solip...@pitrou.net a écrit :
I think there *is* a potentially worthwhile generalisation here,
but I'm far from sure is-a-dict is the right data model - for
composability reasons, it feels like a has-a relationship with an
underlying data
For the record, if you want to reduce memory footprint of Python on a
x86-64 bit, you can use the x32 ABI for which Debian/Ubuntu provide
some support.
(install the required base packages and use CFLAGS=-mx32 LDFLAGS=-mx32)
Regards
Antoine.
Le Sun, 6 Oct 2013 17:32:37 +0200,
Victor Stinner
On 8 Oct 2013 18:36, Antoine Pitrou solip...@pitrou.net wrote:
Le Tue, 8 Oct 2013 08:21:43 +0200,
Antoine Pitrou solip...@pitrou.net a écrit :
I think there *is* a potentially worthwhile generalisation here,
but I'm far from sure is-a-dict is the right data model - for
composability
Le Tue, 8 Oct 2013 22:12:02 +1000,
Nick Coghlan ncogh...@gmail.com a écrit :
It's OK if the key transforming API has to constrain the behaviour of
the underlying mapping or require an appropriately designed transform
function to handle more esoteric containers. Either would still be
better
On 8 Oct 2013 22:31, Antoine Pitrou solip...@pitrou.net wrote:
Le Tue, 8 Oct 2013 22:12:02 +1000,
Nick Coghlan ncogh...@gmail.com a écrit :
It's OK if the key transforming API has to constrain the behaviour of
the underlying mapping or require an appropriately designed transform
On Mon, Sep 30, 2013 at 6:54 AM, Donald Stufft don...@stufft.io wrote:
On Sep 30, 2013, at 9:09 AM, Eli Bendersky eli...@gmail.com wrote:
Hi all,
https://github.com/python/cpython is now live as a semi-official, *read
only* Github mirror of the CPython Mercurial repository. Let me know if
Le Tue, 8 Oct 2013 22:49:28 +1000,
Nick Coghlan ncogh...@gmail.com a écrit :
Well, you could ask the same question about OrderedDict,
defaultdict or Weak*Dictionary since neither of them use
composition :-)
We *did* ask the same question about those (except the Weak* variants,
simply due
On Sun, 06 Oct 2013 22:27:52 +0200, mar...@v.loewis.de wrote:
Quoting Benjamin Peterson benja...@python.org:
If you know that your application uses a lot of memory, it is
interesting to sometimes (when the application is idle) try to release
some bytes to not use all the system memory.
On Tue, Oct 8, 2013 at 8:33 AM, R. David Murray rdmur...@bitdance.comwrote:
PS: I have always thought it sad that the ready availability of memory,
CPU speed, and disk space tends to result in lazy programs. I understand
there is an effort/value tradeoff, and I make those tradeoffs myself
On Fri, Sep 13, 2013 at 10:40 PM, Antoine Pitrou solip...@pitrou.netwrote:
Hello,
Following the python-dev discussion, I've written a PEP to recap the
proposal and the various arguments. It's inlined below, and it will
probably appear soon at http://www.python.org/dev/peps/pep-0455/, too.
On 08/10/2013 19:02, Yuriy Taraday wrote:
On Fri, Sep 13, 2013 at 10:40 PM, Antoine Pitrou solip...@pitrou.net
mailto:solip...@pitrou.net wrote:
Hello,
Following the python-dev discussion, I've written a PEP to recap the
proposal and the various arguments. It's inlined below, and
2013/10/8 R. David Murray rdmur...@bitdance.com:
PS: I have always thought it sad that the ready availability of memory,
CPU speed, and disk space tends to result in lazy programs. I understand
there is an effort/value tradeoff, and I make those tradeoffs myself
all the time...but it still
On Tue, 08 Oct 2013 22:02:43 +0400, Yuriy Taraday yorik@gmail.com wrote:
There should be a way to avoid creation of the second dict when there is no
need to store original keys. For example, email.message module doesn't
store original headers as they are not needed. The same applies to web
On Tue, 08 Oct 2013 14:43:03 -0400, Benjamin Peterson benja...@python.org
wrote:
2013/10/8 R. David Murray rdmur...@bitdance.com:
PS: I have always thought it sad that the ready availability of memory,
CPU speed, and disk space tends to result in lazy programs. I understand
there is an
On Tue, Oct 8, 2013 at 10:17 PM, MRAB pyt...@mrabarnett.plus.com wrote:
If you don't need the original key, then you might as well just use a
transform function with a dict.
As I understood, storing original keys is not the purpose of TransformDict,
allowing hashing on something other then
2013/10/8 R. David Murray rdmur...@bitdance.com:
In this context, if we'd been *really* smart-lazy in CPython development,
we'd have kept the memory and startup-time and...well, we probably do
pretty well on CPU actually...smaller, so that when smartphones came
along Python would have been the
On Tue, 8 Oct 2013 23:36:05 +0400
Yuriy Taraday yorik@gmail.com wrote:
On Tue, Oct 8, 2013 at 10:17 PM, MRAB pyt...@mrabarnett.plus.com wrote:
If you don't need the original key, then you might as well just use a
transform function with a dict.
As I understood, storing original keys
On 9 October 2013 03:35, Guido van Rossum gu...@python.org wrote:
On Tue, Oct 8, 2013 at 8:33 AM, R. David Murray rdmur...@bitdance.comwrote:
PS: I have always thought it sad that the ready availability of memory,
CPU speed, and disk space tends to result in lazy programs. I understand
Let's agree to disagree then. I see your methodology used all around me
with often problematic results. Maybe devs should have two machines -- one
monster that is *only* usable to develop fast, one small that where they
run their own apps (email, web browser etc.).
On Tue, Oct 8, 2013 at 1:30
On 9 October 2013 07:38, Guido van Rossum gu...@python.org wrote:
Let's agree to disagree then. I see your methodology used all around me
with often problematic results. Maybe devs should have two machines -- one
monster that is *only* usable to develop fast, one small that where they
run
Greetings,
Currently, inspect() is dependent on dir().
Now that we can override what dir() returns on a class by class basis, we are seeing the side-effect of (possibly)
incomplete inspect results, with also leads to (possibly) incomplete help().
I would think we want inspect to be more
Sounds like you are suggesting we get a raspberry pi. All sorts of dumb
waste shows up when you run code on those.
El oct 8, 2013 4:46 p.m., Guido van Rossum gu...@python.org escribió:
Let's agree to disagree then. I see your methodology used all around me
with often problematic results. Maybe
R. David Murray wrote:
I can give you one data point: a mobile platform that (currently) uses
Python3, and does not use linecache because of how much memory it
consumes.
Wouldn't a sensible approach be to discard the linecache
when you've finished generating a traceback? You're not
likely to
I'd say that the effect overriding dir() has on help() is intentional. Not
sure about inspect -- it has other uses. However, the last time I used it I
was definitely hunting for stuff to document.
On Tue, Oct 8, 2013 at 2:29 PM, Ethan Furman et...@stoneleaf.us wrote:
Greetings,
Currently,
It's not actually so much the extreme waste that I'm looking to expose, but
rather the day-to-day annoyances of stuff you use regularly that slows you
down by just a second (or ten), or things that gets slower at each release.
On Tue, Oct 8, 2013 at 2:57 PM, Daniel Holth dho...@gmail.com wrote:
On 9 October 2013 09:10, Guido van Rossum gu...@python.org wrote:
It's not actually so much the extreme waste that I'm looking to expose,
but rather the day-to-day annoyances of stuff you use regularly that slows
you down by just a second (or ten), or things that gets slower at each
release.
I've contributed a new PEP to humanity. I include the RST for your
reading pleasure below, but you can also read it online here:
http://www.python.org/dev/peps/pep-0457/
Discuss,
//arry/
-
PEP: 457
Title: Syntax For Positional-Only Parameters
Version: $Revision$
Last-Modified:
On Wed, Oct 09, 2013 at 01:33:26AM +0200, Larry Hastings wrote:
This PEP proposes a syntax for positional-only parameters in Python.
Positional-only parameters are parameters without an externally-usable
name; when a function accepting positional-only parameters is called,
positional
On 08/10/2013 23:21, Tim Delaney wrote:
On 9 October 2013 09:10, Guido van Rossum gu...@python.org
mailto:gu...@python.org wrote:
It's not actually so much the extreme waste that I'm looking to
expose, but rather the day-to-day annoyances of stuff you use
regularly that slows you
On 10/08/2013 04:33 PM, Larry Hastings wrote:
I've contributed a new PEP to humanity. I include the RST for your reading
pleasure below, but you can also read it
online here:
http://www.python.org/dev/peps/pep-0457/
I like it! :)
Feedback below...
==
I love the 'x' mode open in recent versions of Python. I just discovered
that lzma.open doesn't support it. It seems there's an elif that explicitly
checks the modes allowed. I added x and xb to the choices and now it
seems to work as I would like.
patch.lzma.py
Description: Binary data
Please open a bug report on bugs.python.org so this doesn't get lost.
--
Eric.
On Oct 8, 2013, at 8:49 PM, Tim Heaney thea...@gmail.com wrote:
I love the 'x' mode open in recent versions of Python. I just discovered that
lzma.open doesn't support it. It seems there's an elif that
A very quick reply, more tomorrow.
On 10/09/2013 02:15 AM, Steven D'Aprano wrote:
I note that in your example above, you put the comma outside the square
bracket:
def addch([y, x,] ch, [attr], /):
which seems perfectly readable to me.
It becomes less readable / more tiresome with nested
On Tue, 08 Oct 2013 20:49:17 -0400, Tim Heaney thea...@gmail.com wrote:
I love the 'x' mode open in recent versions of Python. I just discovered
that lzma.open doesn't support it. It seems there's an elif that explicitly
checks the modes allowed. I added x and xb to the choices and now it
On 10/08/2013 05:15 PM, Steven D'Aprano wrote:
On Wed, Oct 09, 2013 at 01:33:26AM +0200, Larry Hastings wrote:
The obvious solution: add a new singleton constant to Python
that is passed in when a parameter is not mapped to an argument.
I propose that the value be called called ``undefined``,
2013/10/8 Larry Hastings la...@hastings.org:
This PEP proposes a backwards-compatible syntax that should
permit implementing any builtin in pure Python code.
This is rather too strong. You can certainly implement them; you just
have to implement the argument parsing yourself. Python's
Done.
http://bugs.python.org/issue19201
I guess I should have known that. Sorry to bother python-dev with this.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
I am -1 for the optional parameters and grouping stuff -
no need to make complicated stuff easier to do just because range semantics
is strange to start with.
(And one can implement a range-like funciton explictly parsing
the parameters if needed be.)
As for the / delimiting positional only
On Wed, Oct 9, 2013 at 12:22 AM, MRAB pyt...@mrabarnett.plus.com wrote:
On 08/10/2013 23:21, Tim Delaney wrote:
On 9 October 2013 09:10, Guido van Rossum gu...@python.org
mailto:gu...@python.org wrote:
It's not actually so much the extreme waste that I'm looking to
expose, but
On 10/8/2013 9:31 PM, Benjamin Peterson wrote:
2013/10/8 Larry Hastings la...@hastings.org:
This PEP proposes a backwards-compatible syntax that should
permit implementing any builtin in pure Python code.
This is rather too strong. You can certainly implement them; you just
have to implement
2013/10/8 Terry Reedy tjre...@udel.edu:
On 10/8/2013 9:31 PM, Benjamin Peterson wrote:
2013/10/8 Larry Hastings la...@hastings.org:
This PEP proposes a backwards-compatible syntax that should
permit implementing any builtin in pure Python code.
This is rather too strong. You can certainly
On 10/08/2013 08:09 PM, Benjamin Peterson wrote:
2013/10/8 Terry Reedy tjre...@udel.edu:
On 10/8/2013 9:31 PM, Benjamin Peterson wrote:
2013/10/8 Larry Hastings la...@hastings.org:
This PEP proposes a backwards-compatible syntax that should
permit implementing any builtin in pure Python
2013/10/8 Ethan Furman et...@stoneleaf.us:
On 10/08/2013 08:09 PM, Benjamin Peterson wrote:
2013/10/8 Terry Reedy tjre...@udel.edu:
On 10/8/2013 9:31 PM, Benjamin Peterson wrote:
2013/10/8 Larry Hastings la...@hastings.org:
This PEP proposes a backwards-compatible syntax that should
Am 09.10.2013 01:33, schrieb Larry Hastings:
I've contributed a new PEP to humanity. I include the RST for your reading
pleasure below, but you can also read it online here:
http://www.python.org/dev/peps/pep-0457/
...
* Documentation can clearly, unambiguously, and
On 10/08/2013 03:07 PM, Guido van Rossum wrote:
I'd say that the effect overriding dir() has on help() is intentional. Not sure
about inspect -- it has other uses.
However, the last time I used it I was definitely hunting for stuff to document.
If want help to be effected that is easy enough
On 10/08/2013 09:55 PM, Benjamin Peterson wrote:
2013/10/8 Ethan Furman et...@stoneleaf.us:
On 10/08/2013 08:09 PM, Benjamin Peterson wrote:
2013/10/8 Terry Reedy tjre...@udel.edu:
On 10/8/2013 9:31 PM, Benjamin Peterson wrote:
2013/10/8 Larry Hastings la...@hastings.org:
This PEP
On Tue, Oct 8, 2013 at 5:33 PM, Larry Hastings la...@hastings.org wrote:
I've contributed a new PEP to humanity. I include the RST for your reading
pleasure below, but you can also read it online here:
http://www.python.org/dev/peps/pep-0457/
Discuss,
The PEP doesn't mention anything
48 matches
Mail list logo
