Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On Tue, Oct 8, 2013 at 9:02 PM, Terry Reedy wrote: > I am for having a way to succintly properly describe the signature of C in > the manual and docstrings and help output. As it is now, the only safe thing > to do, without trial and exception, is to assume positional only unless one > knows other

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On Tue, Oct 8, 2013 at 5: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/ > > > Discuss, The PEP doesn't mention anything about inspect.

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/08/2013 09:55 PM, Benjamin Peterson wrote: 2013/10/8 Ethan Furman : On 10/08/2013 08:09 PM, Benjamin Peterson wrote: 2013/10/8 Terry Reedy : On 10/8/2013 9:31 PM, Benjamin Peterson wrote: 2013/10/8 Larry Hastings : This PEP proposes a backwards-compatible syntax that should permi

Re: [Python-Dev] inspect() and dir()

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

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

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 > c

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

2013/10/8 Ethan Furman : > On 10/08/2013 08:09 PM, Benjamin Peterson wrote: >> >> 2013/10/8 Terry Reedy : >>> >>> On 10/8/2013 9:31 PM, Benjamin Peterson wrote: 2013/10/8 Larry Hastings : > > > This PEP proposes a backwards-compatible syntax that should > permit imple

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/08/2013 08:09 PM, Benjamin Peterson wrote: 2013/10/8 Terry Reedy : On 10/8/2013 9:31 PM, Benjamin Peterson wrote: 2013/10/8 Larry Hastings : This PEP proposes a backwards-compatible syntax that should permit implementing any builtin in pure Python code. This is rather too strong. Yo

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

2013/10/8 Terry Reedy : > On 10/8/2013 9:31 PM, Benjamin Peterson wrote: >> >> 2013/10/8 Larry Hastings : >>> >>> 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

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/8/2013 9:31 PM, Benjamin Peterson wrote: 2013/10/8 Larry Hastings : 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 parsin

Re: [Python-Dev] On the dangers of giving developers the best resources

On Wed, Oct 9, 2013 at 12:22 AM, MRAB wrote: > On 08/10/2013 23:21, Tim Delaney wrote: > >> On 9 October 2013 09:10, Guido van Rossum > > wrote: >> >> It's not actually so much the extreme waste that I'm looking to >> expose, but rather the day-to-day annoyances o

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

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 p

Re: [Python-Dev] lzma and 'x' mode open

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: https://mail.python.o

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

2013/10/8 Larry Hastings : > 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 call/signature syntax is a

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

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``, a

Re: [Python-Dev] lzma and 'x' mode open

On Tue, 08 Oct 2013 20:49:17 -0400, Tim Heaney 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 > seems to work

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

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 gro

Re: [Python-Dev] lzma and 'x' mode open

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 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 > t

[Python-Dev] lzma and 'x' mode open

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 _

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

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... == N

Re: [Python-Dev] On the dangers of giving developers the best resources

On 08/10/2013 23:21, Tim Delaney wrote: On 9 October 2013 09:10, Guido van Rossum 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 down by just a sec

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

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 argum

[Python-Dev] PEP 457: Syntax For Positional-Only Parameters

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: $D

Re: [Python-Dev] On the dangers of giving developers the best resources

On 9 October 2013 09:10, Guido van Rossum 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. > Veering of

Re: [Python-Dev] On the dangers of giving developers the best resources

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 wrote: > Sounds like you

Re: [Python-Dev] inspect() and dir()

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 wrote: > Greetings, > > Currently, inspect() is depen

Re: [Python-Dev] Reduce memory footprint of Python

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 be

Re: [Python-Dev] On the dangers of giving developers the best resources

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" escribió: > Let's agree to disagree then. I see your methodology used all around me > with often problematic results. Maybe devs should h

[Python-Dev] inspect() and dir()

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 thoro

Re: [Python-Dev] On the dangers of giving developers the best resources

On 9 October 2013 07:38, Guido van Rossum 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 their own apps (

Re: [Python-Dev] On the dangers of giving developers the best resources

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 PM,

Re: [Python-Dev] On the dangers of giving developers the best resources

On 9 October 2013 03:35, Guido van Rossum wrote: > On Tue, Oct 8, 2013 at 8:33 AM, R. David Murray wrote: > >> 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,

Re: [Python-Dev] PEP 455: TransformDict

On Tue, 8 Oct 2013 23:36:05 +0400 Yuriy Taraday wrote: > On Tue, Oct 8, 2013 at 10:17 PM, MRAB 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, >

Re: [Python-Dev] Reduce memory footprint of Python

2013/10/8 R. David Murray : > 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 first high level

Re: [Python-Dev] PEP 455: TransformDict

On Tue, Oct 8, 2013 at 10:17 PM, MRAB 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 provided key itself is. Thi

Re: [Python-Dev] Reduce memory footprint of Python

On Tue, 08 Oct 2013 14:43:03 -0400, Benjamin Peterson wrote: > 2013/10/8 R. David Murray : > > 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 th

Re: [Python-Dev] PEP 455: TransformDict

On Tue, 08 Oct 2013 22:02:43 +0400, Yuriy Taraday 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 > frameworks pars

Re: [Python-Dev] Reduce memory footprint of Python

2013/10/8 R. David Murray : > 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 makes me sad. Then,

Re: [Python-Dev] PEP 455: TransformDict

On 08/10/2013 19:02, Yuriy Taraday wrote: On Fri, Sep 13, 2013 at 10:40 PM, Antoine Pitrou 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 it will probabl

Re: [Python-Dev] PEP 455: TransformDict

On Fri, Sep 13, 2013 at 10:40 PM, Antoine Pitrou 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 it will > probably appear soon at http://www.python.org/dev/peps/pep-0455/, too. > > Regards > >

[Python-Dev] On the dangers of giving developers the best resources

On Tue, Oct 8, 2013 at 8:33 AM, R. David Murray wrote: > 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 i

Re: [Python-Dev] Reduce memory footprint of Python

On Sun, 06 Oct 2013 22:27:52 +0200, mar...@v.loewis.de wrote: > > Quoting Benjamin Peterson : > > >> 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 embed

Re: [Python-Dev] PEP 455: TransformDict

Le Tue, 8 Oct 2013 22:49:28 +1000, Nick Coghlan 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 to age).

Re: [Python-Dev] Semi-official read-only Github mirror of the CPython Mercurial repository

On Mon, Sep 30, 2013 at 6:54 AM, Donald Stufft wrote: > > On Sep 30, 2013, at 9:09 AM, Eli Bendersky 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 you > have any problems/co

Re: [Python-Dev] PEP 455: TransformDict

On 8 Oct 2013 22:31, "Antoine Pitrou" wrote: > > Le Tue, 8 Oct 2013 22:12:02 +1000, > Nick Coghlan 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

Re: [Python-Dev] PEP 455: TransformDict

Le Tue, 8 Oct 2013 22:12:02 +1000, Nick Coghlan 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 than categorica

Re: [Python-Dev] PEP 455: TransformDict

On 8 Oct 2013 18:36, "Antoine Pitrou" wrote: > > Le Tue, 8 Oct 2013 08:21:43 +0200, > Antoine Pitrou 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 lik

Re: [Python-Dev] Reduce memory footprint of Python

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

Re: [Python-Dev] PEP 455: TransformDict

Le Tue, 8 Oct 2013 08:21:43 +0200, Antoine Pitrou 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 store