I'm not sure Droping imports is the best way to go, since every python
script/app will import common modules right on the start and it will still
seem like the interpeter boot is slow.
making modules load faster seems like a better approch
On Thu, Oct 10, 2013 at 3:18 AM, Eric Snow wrote:
> O
On 10/09/2013 03:36 PM, Nick Coghlan wrote:
On 10 Oct 2013 08:07, "Ethan Furman" wrote:
On 10/09/2013 02:46 PM, Nick Coghlan wrote:
On 10 Oct 2013 03:39, "Ethan Furman" wrote:
My apologies. I am actually talking about the module. I meant
inspect.get_members() and inspect.classify_class_att
On 10/10/13 11:57, Nick Coghlan wrote:
PEP title: Representation of positional-only parameters
Something like "Notation for documenting positional-only parameters"
would make it even clearer that this is not a proposal for adding
to the syntax of the language.
--
Greg
On 10/10/13 09:51, Larry Hastings wrote:
Perhaps we could add (egad, no, I can't believe I'm saying this) a new
built-in function that tells you whether or not a local variable has been
assigned to yet?
def range([start,] stop, [step], /):
if not bound(start):
start = 0
Registration is now open for PyCon US 2014. Are there any plans yet
for the language summit? Just the day (e.g. Thursday April 10) will
suffice. Then we can make arrangements appropriately. Thanks.
-eric
___
Python-Dev mailing list
Python-Dev@python.
On Wed, Oct 9, 2013 at 8:30 AM, Christian Heimes wrote:
> The os module imports MutableMapping from collections.abc. That import
> adds collections, collections.abc and eight more modules. I'm not sure
> if we can do anything about it, though.
Well, that depends on how much we want to eliminate t
2013/10/3 Victor Stinner :
> I worked on the implementation of the tracemalloc module and its PEP
> 454. I consider that this third version of the PEP is ready for a
> final review.
>
> What should be done to finish the PEP?
I splitted the module into two parts. Do you prefer the new API?
Module:
On Wed, Oct 09, 2013 at 04:15:36PM +0200, Larry Hastings wrote:
> >- parameters in optional groups should just have an implied "=None"
> >that can be overriden if desired.
> >
>
> No no no! You can't have a default value, and you definitely couldn't
> use None.
>
> range() decides what its ar
On 10 Oct 2013 00:17, "Larry Hastings" wrote:
>
>
> On 10/09/2013 11:46 AM, Nick Coghlan wrote:
>>
>> Generally, it needs to be a bit clearer that the intent of the PEP isn't
to say "let's do this", it's to be explicit that acceptance of the Argument
Clinic PEP severely constrains the design space
On Wed, Oct 9, 2013 at 12:20 PM, Eric Snow wrote:
> For me the allure of positional-only arguments lies in the following:
>
> 1. not having to roll my own *args handling;
> 2. not having to clutter up my code with the *args handling;
> 3. not having to handle positional-or-keyword params with *arg
On 10 Oct 2013 08:07, "Ethan Furman" wrote:
>
> On 10/09/2013 02:46 PM, Nick Coghlan wrote:
>
>> On 10 Oct 2013 03:39, "Ethan Furman" wrote:
>>>
>>>
>>> My apologies. I am actually talking about the module. I meant
>>> inspect.get_members() and inspect.classify_class_attrs(), which,
>>> as nea
On 10/09/2013 02:46 PM, Nick Coghlan wrote:
On 10 Oct 2013 03:39, "Ethan Furman" wrote:
My apologies. I am actually talking about the module. I meant
inspect.get_members() and inspect.classify_class_attrs(), which,
as near as I can tell, are the only two functions in inspect that
attempt t
On Wed, Oct 09, 2013 at 09:46:00PM +0100, Mark Shannon wrote:
> There is no need to create an "undefined" value.
> Rather than define a parameter by assigning a fake value, just don't
> define it. We already do this for non-parameter locals and it could be
> extended to parameters.
>
> 'range'
On Wed, Oct 09, 2013 at 02:25:18PM -0400, Terry Reedy wrote:
> Unlike Georg, I think '/' is plausibly ok. You should, however,
> explicitly say in the PEP that it was selected not randomly but by rough
> analogy. Division (/) is the inverse of multiplication (*), and
> positional-only is sort o
On 10 Oct 2013 03:39, "Ethan Furman" wrote:
>
> On 10/09/2013 09:40 AM, Brett Cannon wrote:
>
>> On Tue, Oct 8, 2013 at 5:29 PM, Ethan Furman wrote:
>>>
>>>
>>> Currently, inspect() is dependent on dir().
>>
>>
>> What's inspect()? I don't know of any global with that name and you are
obviously no
On 9 Oct 2013 01:07, "Antoine Pitrou" wrote:
>
> 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 a
On Wed, 09 Oct 2013 20:38:55 +0200
Georg Brandl wrote:
> Am 07.10.2013 20:41, schrieb antoine.pitrou:
> > http://hg.python.org/cpython/rev/2aee9c41bb79
> > changeset: 86140:2aee9c41bb79
> > branch: 3.3
> > parent: 86136:bd16e333
> > user:Antoine Pitrou
> > date:Mon
On 10/09/2013 10:46 PM, Mark Shannon wrote:
There is no need to create an "undefined" value.
Rather than define a parameter by assigning a fake value, just don't
define it. We already do this for non-parameter locals and it could be
extended to parameters.
'range' would be defined thus:
def
On 09/10/13 00:33, 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/
Overall I'm in favour.
As a motivation for positional only parameters, consi
On 10/09/2013 08:25 PM, Terry Reedy wrote:
I am sure that he has rejected any backward-incompatible change, as
would I. Allowing keyword passing *is* compatible, so I would not
guess about that.
I don't know where to look for this discussion, and I read it quite some
time ago. So I this is
On 10/09/2013 07:50 PM, Eli Bendersky wrote:
I'm not sure what you call "parsing". This?
>>> def myfoo(*args): a, b = args; print("%s, then %s" % (a, b))
From the Argument Clinic PEP (436):
The primary implementation of Python, "CPython", is written in a
mixture of Python and C. One imp
Am 07.10.2013 20:41, schrieb antoine.pitrou:
> http://hg.python.org/cpython/rev/2aee9c41bb79
> changeset: 86140:2aee9c41bb79
> branch: 3.3
> parent: 86136:bd16e333
> user:Antoine Pitrou
> date:Mon Oct 07 20:38:51 2013 +0200
> summary:
> Fix macro expansion of _PyE
On 9 October 2013 18:00, Ethan Furman wrote:
> On 10/09/2013 09:05 AM, Paul Moore wrote:
>>
>>
>> I remain -1 on forcing "Python syntax" to support all of these odd
>> corner cases (and positional-only is already a corner case,
>> range/addch are seriously so).
>
>
> Considering the prevalence of
On Wed, Oct 9, 2013 at 11:38 AM, R. David Murray wrote:
> It seems to me, then, that the solution for the
> handle-the-ugly-existing-practice-groups issue is to make case (3)
> (pydoc prototype) match the convention that we have arrived at for the
> documentation: multiple signature lines to repr
On 10/9/2013 1:05 PM, Larry Hastings wrote:
First, if you're proposing to change the signature of range()... well,
good luck. Any proposals I made like that got shot down almost
immediately. I /think/ Guido said somewhere "range isn't changing.
deal with it.", though I admit I don't have a ref
On Wed, Oct 9, 2013 at 8:53 AM, Larry Hastings wrote:
> But that's not how addch works. addch counts how many arguments it
> received; if it is called with one or two, it does one thing, and if it's
> called with three or four it does something else. You can't duplicate these
> semantics with
>
Am 09.10.2013 19:00, schrieb Ethan Furman:
> On 10/09/2013 09:05 AM, Paul Moore wrote:
>>
>> I remain -1 on forcing "Python syntax" to support all of these odd corner
>> cases (and positional-only is already a corner case, range/addch are
>> seriously so).
>
> Considering the prevalence of positi
On Tue, Oct 8, 2013 at 4: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/
>
>
>
Hi Larry,
My comments below. TL;DR I'm -1, but trying t
On 10/09/2013 09:05 AM, Paul Moore wrote:
I remain -1 on forcing "Python syntax" to support all of these odd
corner cases (and positional-only is already a corner case,
range/addch are seriously so).
Considering the prevalence of positional-only functions and methods, I don't think they can be
On Wed, 09 Oct 2013 17:05:12 +0100, Paul Moore wrote:
> On 9 October 2013 16:07, Larry Hastings wrote:
> > On 10/09/2013 04:38 PM, Paul Moore wrote:
> >
> > For that matter, why does the syntax used by Argument Clinic have to
> > be the same as whatever future syntax is used in Python? If indeed,
On 10/09/2013 09:40 AM, Brett Cannon wrote:
On Tue, Oct 8, 2013 at 5:29 PM, Ethan Furman wrote:
Currently, inspect() is dependent on dir().
What's inspect()? I don't know of any global with that name and you are
obviously not talking about the module.
My apologies. I am actually talking a
On 10/9/2013 7:45 AM, Anders J. Munch wrote:
Larry Hastings wrote:
> I look forward to an alternate suggestion. This is the least-bad
> thing I could come up with.
How about a naming convention instead, where using a leading
underscore in a parameter name is a hint that it is positional-onl
Sorry if I meddle, but wouldn't be better to include a module in the
standard library that provides functions and classes to help parsing
*args and **kwargs?
This way you can avoid defining a new syntax, new builtin objects and so on.
___
Python-Dev mail
On 10/09/2013 06:48 PM, Terry Reedy wrote:
On 10/9/2013 9:51 AM, Larry Hastings wrote:
range() in
PyPy accepts keyword parameters, and in fact this works:
range(9, step=2)
That's way illegal in CPython.
But Georg's point is that it does not have to be illegal in CPython.
Range, in part
On Oct 06, 2013, at 11:41 AM, Benjamin Peterson wrote:
>What is the usecase for minimizing the memory usage of Python in the
>middle of a program?
There are environments where Python is being actively discouraged in part due
to its memory footprint. For example, we can't use Python on Ubuntu Tou
On 10/9/2013 9:51 AM, Larry Hastings wrote:
Again, I don't expect this syntax to be implemented any time soon. But
this does raise a mild sore point: Maciej and Armin Rigo tell me that
PyPy's implementation of range() looks like this:
def range(x, y=None, step=None):
The "None" above is no
On Tue, Oct 8, 2013 at 5:29 PM, Ethan Furman wrote:
> Greetings,
>
> Currently, inspect() is dependent on dir().
>
What's inspect()? I don't know of any global with that name and you are
obviously not talking about the module.
___
Python-Dev mailing li
On 9 October 2013 16:07, Larry Hastings wrote:
> On 10/09/2013 04:38 PM, Paul Moore wrote:
>
> For that matter, why does the syntax used by Argument Clinic have to
> be the same as whatever future syntax is used in Python? If indeed,
> any ever is? What benefit do we get given the cost (rushing in
On 10/09/2013 08:09 AM, Larry Hastings wrote:
On 10/09/2013 04:45 PM, Anders J. Munch wrote:
How about a naming convention instead, where using a leading
underscore in a parameter name is a hint that it is positional-only.
For example, the docstring of sorted:
sorted(iterable, key=None, r
2013/10/9 Larry Hastings :
> On 10/09/2013 04:24 PM, Benjamin Peterson wrote:
>
> My proposed syntax is a little complex--but complex is better than
> complicated and inconsistent and undocumented and inconvenient, which is
> what we have now.
>
> Certainly the argument conventions of these functio
On 10/09/2013 04:45 PM, Anders J. Munch wrote:
Larry Hastings wrote:
> I look forward to an alternate suggestion. This is the least-bad
> thing I could come up with.
How about a naming convention instead, where using a leading
underscore in a parameter name is a hint that it is positional-o
On 9 October 2013 15:53, Larry Hastings wrote:
> My goal in writing the PEP was to codify existing practice, which meant
> reflecting these (annoying!) corner cases accurately.
That's fair. But I would argue that we very much don't want to
encourage anyone ever duplicating that practice with new
Am 09.10.2013 16:53, schrieb Larry Hastings:
> On 10/09/2013 04:26 PM, Georg Brandl wrote:
>>> I realize you are -1 on the proposal in general, but I'd be very interested
>>> if
>>> you could propose an alternate approach where I didn't need "a new spelling
>>> for
>>> None" as you put it.
>> I t
On 10/09/2013 04:38 PM, Paul Moore wrote:
For that matter, why does the syntax used by Argument Clinic have to
be the same as whatever future syntax is used in Python? If indeed,
any ever is? What benefit do we get given the cost (rushing in a
syntax that nobody is actually convinced we even need
On 10/09/2013 04:24 PM, Benjamin Peterson wrote:
My proposed syntax is a little complex--but complex is better than
complicated and inconsistent and undocumented and inconvenient, which is
what we have now.
Certainly the argument conventions of these functions are not
undocumented, so wonder wha
Larry Hastings wrote:
> I look forward to an alternate suggestion. This is the least-bad
> thing I could come up with.
How about a naming convention instead, where using a leading
underscore in a parameter name is a hint that it is positional-only.
For example, the docstring of sorted:
sorte
On 10/09/2013 04:26 PM, Georg Brandl wrote:
I realize you are -1 on the proposal in general, but I'd be very interested if
you could propose an alternate approach where I didn't need "a new spelling for
None" as you put it.
I think I would make Steven's proposed syntax mandatory: let the impleme
Le Wed, 9 Oct 2013 15:40:08 +0100,
Paul Moore a écrit :
> On 9 October 2013 15:30, Larry Hastings wrote:
> > Only if I can stop writing other PEPs and replying to their
> > discussion threads!
>
> So once again, why is this new PEP needed? :-)
Procrastination perhaps ;-)
> Paul
__
On 9 October 2013 15:30, Larry Hastings wrote:
> Only if I can stop writing other PEPs and replying to their discussion
> threads!
So once again, why is this new PEP needed? :-)
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.
On 9 October 2013 13:38, Benjamin Peterson wrote:
>> Generally, it needs to be a bit clearer that the intent of the PEP isn't to
>> say "let's do this", it's to be explicit that acceptance of the Argument
>> Clinic PEP severely constrains the design space for possible solutions if we
>> ever *did*
On Oct 9, 2013 4:04 AM, "Paul Moore" wrote:
> But if the intention is that any attempt to add the functionality to
> Python will be constrained to use the syntax here, surely that means
> we need to have all of the usability arguments and bikeshedding *now*.
> otherwise the opportunity is lost?
I
Am 09.10.2013 14:54, schrieb Christian Heimes:
> Am 09.10.2013 14:39, schrieb Benjamin Peterson:
>> There's also the increasing number of modules (Python or otherwise)
>> that have to be loaded on startup.
We can easily peel off about 11 modules (re, sysconfig and their
dependencies) with some cha
On 10/09/2013 03:36 PM, Antoine Pitrou wrote:
I think it would be better to exercise [Argument Clinc] first as an internal
tool,
eliminate any possible quirks and issues, and *then* perhaps expose it
as a public API.
By the way, do you think it'll be ready for 3.4?
Only if I can stop writing
Am 09.10.2013 15:56, schrieb Larry Hastings:
> On 10/09/2013 07:15 AM, Georg Brandl wrote:
>> We have quite a large
>> amount of C functions with positional-only parameters. Adding a "/"
>> to each of those is a) a tedious task and b) probably not helpful for
>> a lot of people:
>
> I volunteer t
2013/10/9 Larry Hastings :
>
> On 10/09/2013 03:31 AM, 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
On 10/09/2013 11:46 AM, Nick Coghlan wrote:
Generally, it needs to be a bit clearer that the intent of the PEP
isn't to say "let's do this", it's to be explicit that acceptance of
the Argument Clinic PEP severely constrains the design space for
possible solutions if we ever *did* implement Pyt
On Wed, Oct 9, 2013 at 8:15 AM, Georg Brandl wrote:
>
> [...]
>
> Rather, I would try to make as many C functions as possible "regular",
See http://bugs.python.org/issue8706 and http://bugs.python.org/issue8350
Best Regards,
Ezio Melotti
___
Python-De
On 10/09/2013 07:15 AM, Georg Brandl wrote:
We have quite a large
amount of C functions with positional-only parameters. Adding a "/"
to each of those is a) a tedious task and b) probably not helpful for
a lot of people:
I volunteer to ensure that the "/"s are added if this PEP is accepted.
On 10/09/2013 07:48 AM, Eric Snow wrote:
The PEP doesn't mention anything about inspect.Signature, which
already supports positional-only parameters. It should.
Well, inspect.Signature support for positional-only parameters is
currently insufficient to express all of Python's builtins. As I
On 10/09/2013 03:31 AM, 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 pars
Am 09.10.2013 15:32, schrieb Larry Hastings:
> On 10/09/2013 02:38 PM, Benjamin Peterson wrote:
>> Why does a syntax need to be reserved? Documentation conventions and
>> the syntax of internal tools like argument clinic may be changed any
>> time we like.
>
> If Argument Clinic is accepted, and s
Le Wed, 09 Oct 2013 15:32:10 +0200,
Larry Hastings a écrit :
> On 10/09/2013 02:38 PM, Benjamin Peterson wrote:
> > Why does a syntax need to be reserved? Documentation conventions and
> > the syntax of internal tools like argument clinic may be changed any
> > time we like.
>
> If Argument Clini
On 10/09/2013 02:38 PM, Benjamin Peterson wrote:
Why does a syntax need to be reserved? Documentation conventions and
the syntax of internal tools like argument clinic may be changed any
time we like.
If Argument Clinic is accepted, and ships with Python, my expectation is
that it would cease
Am 09.10.2013 14:39, schrieb Benjamin Peterson:
> There's also the increasing number of modules (Python or otherwise)
> that have to be loaded on startup.
I have gathered some stats:
Python 3.4:
>>> len(sys.modules)
56
>>> len(list(name for name in sys.modules
if name not in sys.buil
Le Wed, 9 Oct 2013 08:39:40 -0400,
Benjamin Peterson a écrit :
> 2013/10/9 Antoine Pitrou :
> > Le Wed, 9 Oct 2013 10:29:30 +0200,
> > Antoine Pitrou a écrit :
> >> Le Tue, 8 Oct 2013 15:43:40 -0400,
> >> Benjamin Peterson a écrit :
> >>
> >> > 2013/10/8 R. David Murray :
> >> > > In this contex
2013/10/9 Antoine Pitrou :
> Le Wed, 9 Oct 2013 10:29:30 +0200,
> Antoine Pitrou a écrit :
>> Le Tue, 8 Oct 2013 15:43:40 -0400,
>> Benjamin Peterson a écrit :
>>
>> > 2013/10/8 R. David Murray :
>> > > In this context, if we'd been *really* smart-lazy in CPython
>> > > development, we'd have kep
2013/10/9 Nick Coghlan :
> The PEP needs to state more clearly up front (preferably in the title) that
> it's about *reserving* a Python level syntax that matches the syntax we
> worked out for Argument Clinic at PyCon US. Explicitly stating that the
> requirements that drive the Argument Clinic de
On 10/09/2013 02:22 PM, Peter Otten wrote:
py> type.__subclasses__(type)
[, ]
The underlying problem seems to be that there is no helper function to
bypass the instance attribute.
Note that the problem is specific to the "type" type, which is its own
metatype. With other types that get __sub
Steven D'Aprano wrote:
> On Wed, Oct 09, 2013 at 12:20:18PM +0200, Antoine Pitrou wrote:
>>
>> Hello,
>>
>> Just noticed the following quirk:
>>
>> >>> type.__subclasses__()
>> Traceback (most recent call last):
>> File "", line 1, in
>> TypeError: descriptor '__subclasses__' of 'type' objec
On Wed, Oct 09, 2013 at 12:20:18PM +0200, Antoine Pitrou wrote:
>
> Hello,
>
> Just noticed the following quirk:
>
> >>> type.__subclasses__()
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: descriptor '__subclasses__' of 'type' object needs an argument
>
> Yet it wou
Le Wed, 9 Oct 2013 10:29:30 +0200,
Antoine Pitrou a écrit :
> Le Tue, 8 Oct 2013 15:43:40 -0400,
> Benjamin Peterson a écrit :
>
> > 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
> > >
Hello,
Just noticed the following quirk:
>>> type.__subclasses__()
Traceback (most recent call last):
File "", line 1, in
TypeError: descriptor '__subclasses__' of 'type' object needs an argument
Yet it would be nice to know about the subclasses of type.
Regards
Antoine.
On 9 October 2013 10:46, Nick Coghlan wrote:
> The PEP needs to state more clearly up front (preferably in the title) that
> it's about *reserving* a Python level syntax that matches the syntax we
> worked out for Argument Clinic at PyCon US. Explicitly stating that the
> requirements that drive t
The PEP needs to state more clearly up front (preferably in the title) that
it's about *reserving* a Python level syntax that matches the syntax we
worked out for Argument Clinic at PyCon US. Explicitly stating that the
requirements that drive the Argument Clinic design are to support the
signature
Le Wed, 09 Oct 2013 11:01:01 +1300,
Greg Ewing a écrit :
> 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 linec
Le Tue, 8 Oct 2013 15:43:40 -0400,
Benjamin Peterson a écrit :
> 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 w
On 10/09/2013 03:57 AM, Joao S. O. Bueno wrote:
def a([b],/,**kw):
print (b)
does calling "a(b=5)" should raise a TypeError, or put "5" in
"""kw["b"]""" and leave
"b" as "undefined" ?
The latter. This is how they are "similarly to *args and **kwargs":
>>> def foo(*a, **kw):
...
On Wed, 09 Oct 2013 01:33:26 +0200
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/
Only skimmed through the PEP, but -1 on the whole id
78 matches
Mail list logo
