Re: [Python-Dev] PEP 362 Third Revision

[Nick Coghlan]

On Jun 14, 2012 2:31 PM, "Alexandre Zani"  wrote:

> Why do we look at __wrapped__ only if the object is a FunctionType?
> Why not support __wrapped__ on all callables?

Fair question - duck typing here makes more sense to me, too.

>
> Why special-case functools.partial? Couldn't functools.partial just
> set __signature__ itself? Is that because of inspect's dependency on
> functools?

Got it in one. Really, it's the same reason we don't burden the builtin
callable machinery with it - to ensure the dependencies only flow in one
direction.

> Just a thought: Do we want to include the docstring? A function's
> docstring is often intimately tied to its signature. (Or at least, a
> lot of us try to write docstrings that effectively describe the
> function's signature)

No, combining the signature with other details like the name and docstring
is the task of higher level interfaces like pydoc.

Cheers,
Nick.

--
Sent from my phone, thus the relative brevity :)
___
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

Re: [Python-Dev] #12982: Should -O be required to *read* .pyo files?

[Maciej Fijalkowski]

On Wed, Jun 13, 2012 at 9:13 PM, R. David Murray wrote:

> On Wed, 13 Jun 2012 20:46:50 +0200, Antoine Pitrou 
> wrote:
> > On Wed, 13 Jun 2012 11:20:24 -0700
> > Toshio Kuratomi  wrote:
> > > On Wed, Jun 13, 2012 at 01:58:10PM -0400, R. David Murray wrote:
> > > >
> > > > OK, but you didn't answer the question :).  If I understand
> correctly,
> > > > everything you said applies to *writing* the bytecode, not reading
> it.
> > > >
> > > > So, is there any reason to not use the .pyo file (if that's all that
> is
> > > > around) when -O is not specified?
> > > >
> > > > The only technical reason I can see why -O should be required for a
> .pyo
> > > > file to be used (*if* it is the only thing around) is if it won't
> *run*
> > > > without the -O switch.  Is there any expectation that that will ever
> be
> > > > the case?
> > > >
> > > Yes.  For instance, if I create a .pyo with -OO it wouldn't have
> docstrings.
> > > Another piece of code can legally import that and try to use the
> docstring
> > > for something.  This would fail if only the .pyo was present.
> >
> > Not only docstrings, but also asserts. I think running a pyo without -O
> > would be a bug.
>
> Again, a program that depends on asserts is buggy.
>
> As Ethan pointed out we are asking about the case where someone is
> *deliberately* setting the .pyo file up to be run as the "normal"
> case.
>
> I'm not sure we want to support that, I just want us to be clear
> about why we don't :)


PyPy toolchain is an example of such buggy program. And oh any tests. I
would not be impressed if my python read .pyo files out of nowhere when not
running with -O flag (I'm trying very hard to never run python with -O,
because it's different python after all)
___
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

[Python-Dev] deprecating .pyo and -O

[Antoine Pitrou]

On Wed, 13 Jun 2012 12:36:55 -0700
Ethan Furman  wrote:
> 
> Currently, the alternative to supporting this behavior is to either:
> 
>1) require the end-user to specify -O (major nuisance)
> 
>or
> 
>2) have the distributor rename the .pyo file to .pyc
> 
> I think 1 is a non-starter (non-finisher? ;) but I could live with 2 -- 
> after all, if someone is going to the effort of removing the .py file 
> and moving the .pyo file into its place, renaming the .pyo to .pyc is 
> trivial.
> 
> So the question, then, is: is option 2 better than just supporting .pyo 
> files without -O when they are all that is available?

Honestly, I think the best option would be to deprecate .pyo files as
well as the useless -O option. They only cause confusion without
providing any significant benefits.

(also, they ironically make Python installs bigger since both .pyc
and .pyo files have to be provided by system packages)

Regards

Antoine.


___
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

Re: [Python-Dev] Tunable parameters in dictobject.c (was dictnotes.txt out of date?)

[Mark Shannon]

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 extensive testing and timings of 
many python apps.

In particular, it harms the speed of building-up all large dictionaries,
and it greatly harms apps with steady-size dictionaries with changing keys.

The previously existing parameter were well studied
and have been well-reviewed by the likes of Tim Peters.
They shouldn't be changed without deep thought and study.
Certainly, "I think a growth factor of x2 is best" is insufficient.


Indeed, "I think a growth factor of x2 is best" is insufficient,
but so is "based on extensive testing and timings of many python apps"
unless you provide those timings and apps.

So here is some evidence.
I have compared tip (always resize by x2) with a x4 variant
(resize split-dict x2 and combined-dicts x4).

All benchmarks from http://hg.python.org/benchmarks/
For my old 32bit machine, numbers are for the x4 variant relative to tip.

For the 2n3 suite (24 micro benchmarks)
Average speed up: None (~0.05% on average)
Average memory use +4%.

GC: 1% faster, no change to memory use.
Mako: 4% slower, 4% more memory
2to3: 3% faster, 32% more memory.

Overall: No change to speed, 5% more memory.

The results seem to indicate that resizing is now sufficiently fast
that changing from x4 to x2 makes no difference in terms of speed.
However, for some programs (notable 2to3) the change from x4 to x2 can
save a lot of memory.

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

Re: [Python-Dev] PEP 362 Third Revision

[Yury Selivanov]

On 2012-06-14, at 12:17 AM, Nick Coghlan wrote:

> On Thu, Jun 14, 2012 at 1:06 PM, Yury Selivanov  wrote:
>> On 2012-06-13, at 10:52 PM, Yury Selivanov wrote:
>>> 2. signature() function support all kinds of callables:
>>> classes, metaclasses, methods, class- & staticmethods,
>>> 'functools.partials', and callable objects.  If a callable
>>> object has a '__signature__' attribute it does a deepcopy
>>> of it before return.
>> 
>> 
>> Properly decorated functions are also supported.
> 
> I'd like to see the "shared state" decorator from the previous thread
> included, as well as a short interactive interpreter session showing
> correct reporting of the signature of functools.partial instances.


OK.  Below is how I want to update the PEP.  Do you want to include
anything else?


Visualizing Callable Objects' Signatures


Let's define some classes and functions:

::

from inspect import signature
from functools import partial, wraps


class FooMeta(type):
def __new__(mcls, name, bases, dct, *, bar:bool=False):
return super().__new__(mcls, name, bases, dct)

def __init__(cls, name, bases, dct, **kwargs):
return super().__init__(name, bases, dct)


class Foo(metaclass=FooMeta):
def __init__(self, spam:int=42):
self.spam = spam

def __call__(self, a, b, *, c) -> tuple:
return a, b, c


def shared_vars(*shared_args):
"""Decorator factory that defines shared variables that are
   passed to every invocation of the function"""

def decorator(f):
@wraps(f)
def wrapper(*args, **kwds):
full_args = shared_args + args
return f(*full_args, **kwds)
# Override signature
sig = wrapper.__signature__ = signature(f)
for __ in shared_args:
sig.parameters.popitem(last=False)
return wrapper
return decorator


@shared_vars({})
def example(_state, a, b, c):
return _state, a, b, c


def format_signature(obj):
return str(signature(obj))


Now, in the python REPL:

::

>>> format_signature(FooMeta)
'(name, bases, dct, *, bar:bool=False)'

>>> format_signature(Foo)
'(spam:int=42)'

>>> format_signature(Foo.__call__)
'(self, a, b, *, c) -> tuple'

>>> format_signature(Foo().__call__)
'(a, b, *, c) -> tuple'

>>> format_signature(partial(Foo().__call__, 1, c=3))
'(b, *, c=3) -> tuple'

>>> format_signature(partial(partial(Foo().__call__, 1, c=3), 2, c=20))
'(*, c=20) -> tuple'

>>> format_signature(example)
'(a, b, c)'

>>> format_signature(partial(example, 1, 2))
'(c)'

>>> format_signature(partial(partial(example, 1, b=2), c=3))
'(b=2, c=3)'


-
Yury
___
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

Re: [Python-Dev] Tunable parameters in dictobject.c (was dictnotes.txt out of date?)

[Kristján Valur Jónsson]

FYI, I had to visit those parameters for my PS3 port and cut down on the 
bombastic memory footprint of 2.7 dicts.
 Some the supposedly tunable parameters aren´t tunable at all.
See http://blog.ccpgames.com/kristjan/2012/04/25/optimizing-the-dict/
Speed and memory are most often conflicting requirements.  I would like to two 
or more compile time
settings to choose from:  Memory optimal, speed optimal, (and mix).

Cheers,
K
> -Original Message-
> From: python-dev-bounces+kristjan=ccpgames@python.org
> [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On
> Behalf Of Mark Shannon
> Sent: 13. júní 2012 21:37
> To: python-dev@python.org
> Subject: [Python-Dev] Tunable parameters in dictobject.c (was dictnotes.txt
> out of date?)
> 
> Raymond Hettinger wrote:
> >
> > On Jun 13, 2012, at 10:35 AM, Eli Bendersky wrote:
> >
> >> Did you mean to send this to the list, Raymond?
> >
> >
> > Yes.  I wanted to find-out whether someone approved changing
> > all the dict tunable parameters.   I thought those weren't supposed
> > to have changed.  PEP 412 notes that the existing parameters were
> > finely tuned and it did not make recommendations for changing them.
> 
> The PEP says that the current (3.2) implementation is finely tuned.
> No mention is made of tunable parameters.
> 
> >
> > At one point, I spent a full month testing all of the tunable
> > parameters using dozens of popular Python applications.  The values
> > used in Py3.2 represent the best settings for most apps.
> 
> Best in terms of speed, but what about memory use?
> 


___
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

Re: [Python-Dev] PEP 362 Third Revision

[Yury Selivanov]

On 2012-06-14, at 12:29 AM, Alexandre Zani wrote:
> Why do we look at __wrapped__ only if the object is a FunctionType?
> Why not support __wrapped__ on all callables?

Good idea ;)  I'll add this.

Thanks,
-
Yury
___
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

Re: [Python-Dev] deprecating .pyo and -O

[Floris Bruynooghe]

On 14 June 2012 11:25, Antoine Pitrou  wrote:
> Honestly, I think the best option would be to deprecate .pyo files as
> well as the useless -O option. They only cause confusion without
> providing any significant benefits.

+1

But what happens to __debug__ and assert statements?  I think it
should be possible to always put assert statements inside a __debug__
block and then create -O a simple switch for setting __debug__ to
False.  If desired a simple strip tool could then easily remove
__debug__ blocks and (unused) docstrings.

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Victor Stinner]

Sorry if I'm asking dummy questions, I didn't follow the discussion.

> * format(...) -> str
>    Formats the Signature object to a string.  Optional arguments allow
>    for custom render functions for parameter names,
>    annotations and default values, along with custom separators.

Hum, what are these "custom render functions"? Can you give an example?

> * is_keyword_only : bool
>    True if the parameter is keyword-only, else False.
> * is_args : bool
>    True if the parameter accepts variable number of arguments
>    (``*args``-like), else False.
> * is_kwargs : bool
>    True if the parameter accepts variable number of keyword
>    arguments (``**kwargs``-like), else False.

Hum, why not using a attribute with a string value instead of 3
attribute? For example:
 * argtype: "index", "varargs", "keyword" or "keyword_only"

It would avoid a possible inconsitency (ex: is_args=True and
is_kwargs=True). And it would help to implement something like a C
switch/case using a dict: argtype => function for functions using
signatures.

> * is_implemented : bool
>    True if the parameter is implemented for use.  Some platforms
>    implement functions but can't support specific parameters
>    (e.g. "mode" for ``os.mkdir``).  Passing in an unimplemented
>    parameter may result in the parameter being ignored,
>    or in NotImplementedError being raised.  It is intended that
>    all conditions where ``is_implemented`` may be False be
>    thoroughly documented.

I suppose that the value depends on the running platform? (For
example, you may get a different value on Linux and Windows.)

> Implementation
> ==
>
>    - If the object has a ``__signature__`` attribute and if it
>      is not ``None`` - return a deepcopy of it

Oh, why copying the object? It may impact performances. If fhe caller
knows that it will modify the signature, it can deepcopy the
signature.

>        - If it is ``None`` and the object is an instance of
>          ``BuiltinFunction``, raise a ``ValueError``

What about builtin functions (ex: len)? Do you plan to add a
__signature__ attribute? If yes, something created on demand or
created at startup?

It would be nice to have a C API to create Signature objects, maybe
from the same format string than PyArg_Parse*() functions. But it can
be implemented later.

Is it possible to build a Signature object from a string describing
the prototype (ex: "def f(x, y): pass")? (I mean: do you plan to add
such function?)

--

Except of these remarks, I like this PEP :-)

Victor
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Nick Coghlan]

Looks great!

One very minor quibble is that I prefer 'ns' to 'dct' for the namespace
parameter in a metaclass, but that doesn't really matter for the PEP.

--
Sent from my phone, thus the relative brevity :)
On Jun 14, 2012 9:45 PM, "Yury Selivanov"  wrote:

> On 2012-06-14, at 12:17 AM, Nick Coghlan wrote:
>
> > On Thu, Jun 14, 2012 at 1:06 PM, Yury Selivanov 
> wrote:
> >> On 2012-06-13, at 10:52 PM, Yury Selivanov wrote:
> >>> 2. signature() function support all kinds of callables:
> >>> classes, metaclasses, methods, class- & staticmethods,
> >>> 'functools.partials', and callable objects.  If a callable
> >>> object has a '__signature__' attribute it does a deepcopy
> >>> of it before return.
> >>
> >>
> >> Properly decorated functions are also supported.
> >
> > I'd like to see the "shared state" decorator from the previous thread
> > included, as well as a short interactive interpreter session showing
> > correct reporting of the signature of functools.partial instances.
>
>
> OK.  Below is how I want to update the PEP.  Do you want to include
> anything else?
>
>
> Visualizing Callable Objects' Signatures
> 
>
> Let's define some classes and functions:
>
> ::
>
>from inspect import signature
>from functools import partial, wraps
>
>
>class FooMeta(type):
>def __new__(mcls, name, bases, dct, *, bar:bool=False):
>return super().__new__(mcls, name, bases, dct)
>
>def __init__(cls, name, bases, dct, **kwargs):
>return super().__init__(name, bases, dct)
>
>
>class Foo(metaclass=FooMeta):
>def __init__(self, spam:int=42):
>self.spam = spam
>
>def __call__(self, a, b, *, c) -> tuple:
>return a, b, c
>
>
>def shared_vars(*shared_args):
>"""Decorator factory that defines shared variables that are
>   passed to every invocation of the function"""
>
>def decorator(f):
>@wraps(f)
>def wrapper(*args, **kwds):
>full_args = shared_args + args
>return f(*full_args, **kwds)
># Override signature
>sig = wrapper.__signature__ = signature(f)
>for __ in shared_args:
>sig.parameters.popitem(last=False)
>return wrapper
>return decorator
>
>
>@shared_vars({})
>def example(_state, a, b, c):
>return _state, a, b, c
>
>
>def format_signature(obj):
>return str(signature(obj))
>
>
> Now, in the python REPL:
>
> ::
>
>>>> format_signature(FooMeta)
>'(name, bases, dct, *, bar:bool=False)'
>
>>>> format_signature(Foo)
>'(spam:int=42)'
>
>>>> format_signature(Foo.__call__)
>'(self, a, b, *, c) -> tuple'
>
>>>> format_signature(Foo().__call__)
>'(a, b, *, c) -> tuple'
>
>>>> format_signature(partial(Foo().__call__, 1, c=3))
>'(b, *, c=3) -> tuple'
>
>>>> format_signature(partial(partial(Foo().__call__, 1, c=3), 2, c=20))
>'(*, c=20) -> tuple'
>
>>>> format_signature(example)
>'(a, b, c)'
>
>>>> format_signature(partial(example, 1, 2))
>'(c)'
>
>>>> format_signature(partial(partial(example, 1, b=2), c=3))
>'(b=2, c=3)'
>
>
> -
> Yury
___
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

Re: [Python-Dev] deprecating .pyo and -O

[Antoine Pitrou]

On Thu, 14 Jun 2012 12:58:16 +0100
Floris Bruynooghe  wrote:
> On 14 June 2012 11:25, Antoine Pitrou  wrote:
> > Honestly, I think the best option would be to deprecate .pyo files as
> > well as the useless -O option. They only cause confusion without
> > providing any significant benefits.
> 
> +1
> 
> But what happens to __debug__ and assert statements?  I think it
> should be possible to always put assert statements inside a __debug__
> block and then create -O a simple switch for setting __debug__ to
> False.  If desired a simple strip tool could then easily remove
> __debug__ blocks and (unused) docstrings.

I don't really see the point. In my experience there is no benefit to
removing assert statements in production mode. This is a C-specific
notion that doesn't really map very well to Python code. Do other
high-level languages have similar functionality?

Regards

Antoine.


___
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

[Python-Dev] PyPI down?

[MRAB]

It looks like PyPI is down. :-(
___
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

Re: [Python-Dev] deprecating .pyo and -O

[R. David Murray]

On Thu, 14 Jun 2012 14:14:54 +0200, Antoine Pitrou  wrote:
> On Thu, 14 Jun 2012 12:58:16 +0100
> Floris Bruynooghe  wrote:
> > On 14 June 2012 11:25, Antoine Pitrou  wrote:
> > > Honestly, I think the best option would be to deprecate .pyo files as
> > > well as the useless -O option. They only cause confusion without
> > > providing any significant benefits.
> > 
> > +1
> > 
> > But what happens to __debug__ and assert statements?  I think it
> > should be possible to always put assert statements inside a __debug__
> > block and then create -O a simple switch for setting __debug__ to
> > False.  If desired a simple strip tool could then easily remove
> > __debug__ blocks and (unused) docstrings.
> 
> I don't really see the point. In my experience there is no benefit to
> removing assert statements in production mode. This is a C-specific
> notion that doesn't really map very well to Python code. Do other
> high-level languages have similar functionality?

What does matter though is the memory savings.  I'm working with an
application where the difference between normal and -OO is around a 10%
savings (about 2MB) in program DATA size at startup, and that makes a
difference for an ap running in a memory constrained environment.

A docstring stripper would enable the bulk of that savings, but it is
still nice to be able to omit code (such as debug logging statements)
as well.

--David
___
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

Re: [Python-Dev] deprecating .pyo and -O

[Antoine Pitrou]

On Thu, 14 Jun 2012 09:14:59 -0400
"R. David Murray"  wrote:
> 
> What does matter though is the memory savings.  I'm working with an
> application where the difference between normal and -OO is around a 10%
> savings (about 2MB) in program DATA size at startup, and that makes a
> difference for an ap running in a memory constrained environment.
> 
> A docstring stripper would enable the bulk of that savings,

Probably indeed.

> but it is
> still nice to be able to omit code (such as debug logging statements)
> as well.

But does that justify all the additional complication in the core
interpreter, as well as potential user confusion?

Regards

Antoine.


___
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

Re: [Python-Dev] PEP 362 Third Revision

[Yury Selivanov]

On 2012-06-14, at 8:06 AM, Victor Stinner wrote:
> Sorry if I'm asking dummy questions, I didn't follow the discussion.
> 
>> * format(...) -> str
>>Formats the Signature object to a string.  Optional arguments allow
>>for custom render functions for parameter names,
>>annotations and default values, along with custom separators.
> 
> Hum, what are these "custom render functions"? Can you give an example?

That's how the function looks right now (I'm not sure we should load
the PEP with this):

def format(self, *, format_name=str,
format_default=repr,
format_annotation=formatannotation,
format_args=(lambda param: '*' + str(param)),
format_kwargs=(lambda param: '**' + str(param)),

token_params_separator=', ',
token_kwonly_separator='*',
token_left_paren='(',
token_right_paren=')',
token_colon=':',
token_eq='=',
token_return_annotation=' -> '):

'''Format signature to a string.

Arguments (all optional):

* format_name : A function to format names of parameters.  Parameter
  won't be rendered if ``None`` is returned.
* format_default : A function to format default values of parameters.
  Default value won't be rendered if ``None`` is returned.
* format_annotation : A function to format parameter annotations.
  Annotation won't be rendered if ``None`` is returned.
* format_args : A function to render ``*args`` like parameters.
  Parameter won't be rendered if ``None`` is returned.
* format_kwargs : A function to render ``**kwargs`` like parameters.
  Parameter won't be rendered if ``None`` is returned.
* token_params_separator : A separator for parameters.  Set to
  ', ' by default.
* token_kwonly_separator : A separator for arguments and
  keyword-only arguments.  Defaults to '*'.
* token_left_paren : Left signature parenthesis, defaults to '('.
* token_right_paren : Left signature parenthesis, defaults to ')'.
* token_colon : Separates parameter from its annotation,
  defaults to ':'.
* token_eq : Separates parameter from its default value, set to
  '=' by default.
* token_return_annotation : Function return annotation, defaults
  to ' -> '.
'''

I've designed it in such a way, that everything is configurable, so you
can render functions to color-term, HTML, or whatever else.

>> * is_keyword_only : bool
>>True if the parameter is keyword-only, else False.
>> * is_args : bool
>>True if the parameter accepts variable number of arguments
>>(``*args``-like), else False.
>> * is_kwargs : bool
>>True if the parameter accepts variable number of keyword
>>arguments (``**kwargs``-like), else False.
> 
> Hum, why not using a attribute with a string value instead of 3
> attribute? For example:
> * argtype: "index", "varargs", "keyword" or "keyword_only"
> 
> It would avoid a possible inconsitency (ex: is_args=True and
> is_kwargs=True). And it would help to implement something like a C
> switch/case using a dict: argtype => function for functions using
> signatures.

Originally, I thought the the line:

   if parameters.is_args

is better looking that:

   if parameters.kind == 'vararg'

But, I like your arguments regarding inconsistency and dispatch
through a dict (someone may find it useful).  Also, Larry gave
another one - who knows if we add another type of arguments in 
the future.

I guess if nobody really wants to keep 'is_args', we can alter the
PEP.

Let's consider replacement of 'Parameter.is_*' set of attributes with 
a single 'Parameter.kind' attribute, which will have the following 
possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.

(I think 'positional' is more intuitive than 'index'?)

>> * is_implemented : bool
>>True if the parameter is implemented for use.  Some platforms
>>implement functions but can't support specific parameters
>>(e.g. "mode" for ``os.mkdir``).  Passing in an unimplemented
>>parameter may result in the parameter being ignored,
>>or in NotImplementedError being raised.  It is intended that
>>all conditions where ``is_implemented`` may be False be
>>thoroughly documented.
> 
> I suppose that the value depends on the running platform? (For
> example, you may get a different value on Linux and Windows.)

Correct.

>> Implementation
>> ==
>> 
>>- If the object has a ``__signature__`` attribute and if it
>>  is not ``None`` - return a deepcopy of it
> 
> Oh, why copying the object? It may impact performances. If fhe caller
> knows that it will modify the signature, it can deepcopy the
> signature.

There was a discussion on this

Re: [Python-Dev] Tunable parameters in dictobject.c (was dictnotes.txt out of date?)

[Raymond Hettinger]

On Jun 14, 2012, at 4:32 AM, Kristján Valur Jónsson wrote:

>  I would like to two or more compile time
> settings to choose from:  Memory optimal, speed optimal, (and mix).

A compile time option would be nice.

The default should be what we've had though.
The new settings cause a lot more collisions
and resizes.  The resizes themselves have more
collisions than before (there are few collisions
when resizing into a quadrupled dict than into
a doubled dict).  

Dicts get their efficiency from sparseness.
Reducing the mindict size from 8 to 4 causes
substantially more collisions in small dicts
and gets closer to a linear search of a small tuple.


Raymond___
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

Re: [Python-Dev] cpython (2.7): Issue #15060: fix typo in socket doc; Patch by anatoly techtonik

[Georg Brandl]

Am 13.06.2012 23:59, schrieb sandro.tosi:
> http://hg.python.org/cpython/rev/744fb52ffdf0
> changeset:   77417:744fb52ffdf0
> branch:  2.7
> parent:  77408:60a7b704de5c
> user:Sandro Tosi 
> date:Wed Jun 13 23:58:35 2012 +0200
> summary:
>   Issue #15060: fix typo in socket doc; Patch by anatoly techtonik
> 
> files:
>   Doc/library/socket.rst |  2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
> 
> 
> diff --git a/Doc/library/socket.rst b/Doc/library/socket.rst
> --- a/Doc/library/socket.rst
> +++ b/Doc/library/socket.rst
> @@ -38,7 +38,7 @@
>  :const:`AF_UNIX` address family. A pair ``(host, port)`` is used for the
>  :const:`AF_INET` address family, where *host* is a string representing 
> either a
>  hostname in Internet domain notation like ``'daring.cwi.nl'`` or an IPv4 
> address
> -like ``'100.50.200.5'``, and *port* is an integral port number. For
> +like ``'100.50.200.5'``, and *port* is an integer port number. For
>  :const:`AF_INET6` address family, a four-tuple ``(host, port, flowinfo,
>  scopeid)`` is used, where *flowinfo* and *scopeid* represents 
> ``sin6_flowinfo``
>  and ``sin6_scope_id`` member in :const:`struct sockaddr_in6` in C. For

I don't see the typo here, isn't "integral" the adjective form of "integer"?

Georg

___
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

Re: [Python-Dev] cpython (2.7): Issue #15060: fix typo in socket doc; Patch by anatoly techtonik

[MRAB]

On 14/06/2012 15:15, Georg Brandl wrote:

Am 13.06.2012 23:59, schrieb sandro.tosi:

 http://hg.python.org/cpython/rev/744fb52ffdf0
 changeset:   77417:744fb52ffdf0
 branch:  2.7
 parent:  77408:60a7b704de5c
 user:Sandro Tosi
 date:Wed Jun 13 23:58:35 2012 +0200
 summary:
   Issue #15060: fix typo in socket doc; Patch by anatoly techtonik

 files:
   Doc/library/socket.rst |  2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)


 diff --git a/Doc/library/socket.rst b/Doc/library/socket.rst
 --- a/Doc/library/socket.rst
 +++ b/Doc/library/socket.rst
 @@ -38,7 +38,7 @@
  :const:`AF_UNIX` address family. A pair ``(host, port)`` is used for the
  :const:`AF_INET` address family, where *host* is a string representing either 
a
  hostname in Internet domain notation like ``'daring.cwi.nl'`` or an IPv4 
address
 -like ``'100.50.200.5'``, and *port* is an integral port number. For
 +like ``'100.50.200.5'``, and *port* is an integer port number. For
  :const:`AF_INET6` address family, a four-tuple ``(host, port, flowinfo,
  scopeid)`` is used, where *flowinfo* and *scopeid* represents 
``sin6_flowinfo``
  and ``sin6_scope_id`` member in :const:`struct sockaddr_in6` in C. For


I don't see the typo here, isn't "integral" the adjective form of "integer"?


Yes, although it also means "necessary and important as a part of", and
as it's talking about a Python type (class), I think that "integer"
would be clearer, IHMO.
___
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

Re: [Python-Dev] cpython (2.7): Issue #15060: fix typo in socket doc; Patch by anatoly techtonik

[R. David Murray]

On Thu, 14 Jun 2012 16:15:41 +0200, Georg Brandl  wrote:
> Am 13.06.2012 23:59, schrieb sandro.tosi:
> > http://hg.python.org/cpython/rev/744fb52ffdf0
> > changeset:   77417:744fb52ffdf0
> > branch:  2.7
> > parent:  77408:60a7b704de5c
> > user:Sandro Tosi 
> > date:Wed Jun 13 23:58:35 2012 +0200
> > summary:
> >   Issue #15060: fix typo in socket doc; Patch by anatoly techtonik
> > 
> > files:
> >   Doc/library/socket.rst |  2 +-
> >   1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > 
> > diff --git a/Doc/library/socket.rst b/Doc/library/socket.rst
> > --- a/Doc/library/socket.rst
> > +++ b/Doc/library/socket.rst
> > @@ -38,7 +38,7 @@
> >  :const:`AF_UNIX` address family. A pair ``(host, port)`` is used for the
> >  :const:`AF_INET` address family, where *host* is a string representing 
> > either a
> >  hostname in Internet domain notation like ``'daring.cwi.nl'`` or an IPv4 
> > address
> > -like ``'100.50.200.5'``, and *port* is an integral port number. For
> > +like ``'100.50.200.5'``, and *port* is an integer port number. For
> >  :const:`AF_INET6` address family, a four-tuple ``(host, port, flowinfo,
> >  scopeid)`` is used, where *flowinfo* and *scopeid* represents 
> > ``sin6_flowinfo``
> >  and ``sin6_scope_id`` member in :const:`struct sockaddr_in6` in C. For
> 
> I don't see the typo here, isn't "integral" the adjective form of "integer"?

We had a discussion about this on IRC, and I believe it has now been
further updated to "...*port* is an integer.".  To a native speaker's ear,
"integral port number" sounds wrong, probably because the port number
has to be an integer, so it sounds like saying "an integral integer".

The important thing the doc needs to convey is that the *port* argument
actually needs to be an *integer*, as opposed to a string.

--David
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Alexandre Zani]

On Thu, Jun 14, 2012 at 6:50 AM, Yury Selivanov  wrote:
> On 2012-06-14, at 8:06 AM, Victor Stinner wrote:
>> Sorry if I'm asking dummy questions, I didn't follow the discussion.
>>
>>> * format(...) -> str
>>>    Formats the Signature object to a string.  Optional arguments allow
>>>    for custom render functions for parameter names,
>>>    annotations and default values, along with custom separators.
>>
>> Hum, what are these "custom render functions"? Can you give an example?
>
> That's how the function looks right now (I'm not sure we should load
> the PEP with this):
>
>    def format(self, *, format_name=str,
>                        format_default=repr,
>                        format_annotation=formatannotation,
>                        format_args=(lambda param: '*' + str(param)),
>                        format_kwargs=(lambda param: '**' + str(param)),
>
>                        token_params_separator=', ',
>                        token_kwonly_separator='*',
>                        token_left_paren='(',
>                        token_right_paren=')',
>                        token_colon=':',
>                        token_eq='=',
>                        token_return_annotation=' -> '):
>
>        '''Format signature to a string.
>
>        Arguments (all optional):
>
>        * format_name : A function to format names of parameters.  Parameter
>          won't be rendered if ``None`` is returned.
>        * format_default : A function to format default values of parameters.
>          Default value won't be rendered if ``None`` is returned.
>        * format_annotation : A function to format parameter annotations.
>          Annotation won't be rendered if ``None`` is returned.
>        * format_args : A function to render ``*args`` like parameters.
>          Parameter won't be rendered if ``None`` is returned.
>        * format_kwargs : A function to render ``**kwargs`` like parameters.
>          Parameter won't be rendered if ``None`` is returned.
>        * token_params_separator : A separator for parameters.  Set to
>          ', ' by default.
>        * token_kwonly_separator : A separator for arguments and
>          keyword-only arguments.  Defaults to '*'.
>        * token_left_paren : Left signature parenthesis, defaults to '('.
>        * token_right_paren : Left signature parenthesis, defaults to ')'.
>        * token_colon : Separates parameter from its annotation,
>          defaults to ':'.
>        * token_eq : Separates parameter from its default value, set to
>          '=' by default.
>        * token_return_annotation : Function return annotation, defaults
>          to ' -> '.
>        '''
>
> I've designed it in such a way, that everything is configurable, so you
> can render functions to color-term, HTML, or whatever else.
>
>>> * is_keyword_only : bool
>>>    True if the parameter is keyword-only, else False.
>>> * is_args : bool
>>>    True if the parameter accepts variable number of arguments
>>>    (``*args``-like), else False.
>>> * is_kwargs : bool
>>>    True if the parameter accepts variable number of keyword
>>>    arguments (``**kwargs``-like), else False.
>>
>> Hum, why not using a attribute with a string value instead of 3
>> attribute? For example:
>> * argtype: "index", "varargs", "keyword" or "keyword_only"
>>
>> It would avoid a possible inconsitency (ex: is_args=True and
>> is_kwargs=True). And it would help to implement something like a C
>> switch/case using a dict: argtype => function for functions using
>> signatures.
>
> Originally, I thought the the line:
>
>   if parameters.is_args
>
> is better looking that:
>
>   if parameters.kind == 'vararg'
>
> But, I like your arguments regarding inconsistency and dispatch
> through a dict (someone may find it useful).  Also, Larry gave
> another one - who knows if we add another type of arguments in
> the future.
>
> I guess if nobody really wants to keep 'is_args', we can alter the
> PEP.
>
> Let's consider replacement of 'Parameter.is_*' set of attributes with
> a single 'Parameter.kind' attribute, which will have the following
> possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.
>
> (I think 'positional' is more intuitive than 'index'?)
>

I disagree largely for readability reasons. As the PEP stands, I can
look at a Parameter object and immediately understand what the
different possible values are by just listing its attributes. The kind
attribute makes that harder.

Comparing with strings is error prone. If I do param.is_varargs
(adding an s at the end of the attribute name) I will see an attribute
error and know what is going on. If I do the same mistake with the
kind attribute param.kind == "varargs", the expression will just
always be False without any explanation.

>>> * is_implemented : bool
>>>    True if the parameter is implemented for use.  Some platforms
>>>    implement functions but can't support specific parameters
>>>    (e.g. "mode" for ``os.mkdir``).  Passing in an u

Re: [Python-Dev] PEP 362 Third Revision

[Alexandre Zani]

Thanks. :)

On Thu, Jun 14, 2012 at 4:50 AM, Yury Selivanov  wrote:
> On 2012-06-14, at 12:29 AM, Alexandre Zani wrote:
>> Why do we look at __wrapped__ only if the object is a FunctionType?
>> Why not support __wrapped__ on all callables?
>
> Good idea ;)  I'll add this.
>
> Thanks,
> -
> Yury
___
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

Re: [Python-Dev] #12982: Should -O be required to *read* .pyo files?

[Brett Cannon]

On Wed, Jun 13, 2012 at 10:47 PM, R. David Murray wrote:

> On Thu, 14 Jun 2012 11:48:08 +1000, Nick Coghlan 
> wrote:
> > On Thu, Jun 14, 2012 at 6:06 AM, Terry Reedy  wrote:
> > > On 6/13/2012 2:46 PM, Antoine Pitrou wrote:
> > >
> > >> Not only docstrings, but also asserts. I think running a pyo without
> -O
> > >> would be a bug.
> > >
> > > That cat is already out of the bag ;-)
> > > People are doing that now by renaming x.pyo to x.pyc.
> > > Brett claims that it is also easy to do in 3.3 with a custom importer.
> >
> > Right, but by resorting to either of those approaches, people are
> > clearly doing something that isn't formally supported by the core.
> > Yes, you can do it, and most of the time it will work out OK, but any
> > weird glitches that result are officially *not our problem*.
> >
> > The main reason this matters is that the "__debug__" flag is
> > *supposed* to be process global - if you check it in one place, the
>
> OK, the above are the two concrete reasons I have heard in this thread
> for continuing the current behavior:
>
>1) we do not wish to support running from .pyo files without -O
>   being on, even if it currently happens to work
>
>2) the __debug__ setting is supposed to be process-global
>
> Both of these are good reasons.  IMO the issue should be closed with a
> documentation fix, which could optionally include either or both of the
> above motivations.
>

Just for completeness, there is a third reason:

3) Would lead to an extra stat call per module when doing sourceless loads.

While minor, it could add up if you ship only .pyo files but never run with
-O.
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Yury Selivanov]

On 2012-06-14, at 10:50 AM, Alexandre Zani wrote:
> On Thu, Jun 14, 2012 at 6:50 AM, Yury Selivanov  
> wrote:
>> I guess if nobody really wants to keep 'is_args', we can alter the
>> PEP.
>> 
>> Let's consider replacement of 'Parameter.is_*' set of attributes with
>> a single 'Parameter.kind' attribute, which will have the following
>> possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.
>> 
>> (I think 'positional' is more intuitive than 'index'?)
>> 
> 
> I disagree largely for readability reasons. As the PEP stands, I can
> look at a Parameter object and immediately understand what the
> different possible values are by just listing its attributes. The kind
> attribute makes that harder.
> 
> Comparing with strings is error prone. If I do param.is_varargs
> (adding an s at the end of the attribute name) I will see an attribute
> error and know what is going on. If I do the same mistake with the
> kind attribute param.kind == "varargs", the expression will just
> always be False without any explanation.

Agree on this one, good point (although unit tests generally help to 
avoid those problems.)

-
Yury
___
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

Re: [Python-Dev] PEP 362 Third Revision

[R. David Murray]

On Thu, 14 Jun 2012 07:50:42 -0700, Alexandre Zani  
wrote:
> On Thu, Jun 14, 2012 at 6:50 AM, Yury Selivanov  
> wrote:
> > On 2012-06-14, at 8:06 AM, Victor Stinner wrote:
> >> Hum, why not using a attribute with a string value instead of 3
> >> attribute? For example:
> >> * argtype: "index", "varargs", "keyword" or "keyword_only"
> >>
> >> It would avoid a possible inconsitency (ex: is_args=True and
> >> is_kwargs=True). And it would help to implement something like a C
> >> switch/case using a dict: argtype => function for functions using
> >> signatures.
> >
> > Originally, I thought the the line:
> >
> >   if parameters.is_args
> >
> > is better looking that:
> >
> >   if parameters.kind == 'vararg'
> >
> > But, I like your arguments regarding inconsistency and dispatch
> > through a dict (someone may find it useful).  Also, Larry gave
> > another one - who knows if we add another type of arguments in
> > the future.
> >
> > I guess if nobody really wants to keep 'is_args', we can alter the
> > PEP.
> >
> > Let's consider replacement of 'Parameter.is_*' set of attributes with
> > a single 'Parameter.kind' attribute, which will have the following
> > possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.
> >
> > (I think 'positional' is more intuitive than 'index'?)
> >
> 
> I disagree largely for readability reasons. As the PEP stands, I can
> look at a Parameter object and immediately understand what the
> different possible values are by just listing its attributes. The kind
> attribute makes that harder.
> 
> Comparing with strings is error prone. If I do param.is_varargs
> (adding an s at the end of the attribute name) I will see an attribute
> error and know what is going on. If I do the same mistake with the
> kind attribute param.kind == "varargs", the expression will just
> always be False without any explanation.

I don't have strong feelings about this, but to me the fact that there
are values of the individual parameters that if they occur on the same
object at the same time would be invalid is a code smell.  If the thing
can be one and only one of a list of possible types, it makes sense to
me that this be indicated as a single attribute with a list of possible
values, rather than a set of boolean options, one for each type.

For the attribute error issue, we could have module attributes that give
names to the strings:

if parameter.kind == inspect.VARARG_KIND:
stuff

Or if we don't want that in the stdlib, the individual programmer who
cares about it can define their own constants.

--David
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Paul Moore]

On 14 June 2012 15:50, Alexandre Zani  wrote:
> Comparing with strings is error prone. If I do param.is_varargs
> (adding an s at the end of the attribute name) I will see an attribute
> error and know what is going on. If I do the same mistake with the
> kind attribute param.kind == "varargs", the expression will just
> always be False without any explanation.

Agreed. Particularly in this case, a lot of the possible values are
far from completely standardised terms, so misspellings are quite
possible. Apart from the varargs case mentioned, I'd have to look at
the docs to know what name was used for the kind of a "normal"
parameter.

To be honest, I'm not too keen in is_args/is_kwargs as names, but they
are short and match common usage. I could go with is_vararg and
is_kwarg (or is_varargs and is_kwargs, but I hate the abbreviation
varkwarg :-)) because they are closer parallels, but either way this
is trivial bikeshedding, not worth spending time on.

If anyone *really* wants a "kind" string, parameter_kind(param) isn't
hard to define in your app, and you can choose your own terms...

So my view is -1 to a "kind" parameter, and +1 to the current is_XXX
names simply because there's no point bikeshedding.

Oh, and +1 to the PEP as a whole :-)

Paul.
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Brett Cannon]

On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov wrote:

[SNIP]
>
>

> Let's consider replacement of 'Parameter.is_*' set of attributes with
> a single 'Parameter.kind' attribute, which will have the following
> possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.
>
> (I think 'positional' is more intuitive than 'index'?)
>
>
+1 if this change is made.

-Brett
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Ethan Furman]

Brett Cannon wrote:



On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov > wrote:
 
[SNIP]


 


Let's consider replacement of 'Parameter.is_*' set of attributes with
a single 'Parameter.kind' attribute, which will have the following
possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.

(I think 'positional' is more intuitive than 'index'?)


+1 if this change is made.


+1 to using 'kind', and another +1 to using 'kwarg' instead of 'varkwarg'.

~Ethan~
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Yury Selivanov]

On 2012-06-14, at 11:24 AM, Brett Cannon wrote:
> On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov  
> wrote:
>  
> [SNIP]
>  
> Let's consider replacement of 'Parameter.is_*' set of attributes with
> a single 'Parameter.kind' attribute, which will have the following
> possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.
> 
> (I think 'positional' is more intuitive than 'index'?)
> 
> 
> +1 if this change is made.

How about adding 'kind' and keeping 'is_*' attributes,
but making them read-only dynamic properties, i.e.:

   class Parameter:
   ...

   @property
   def is_vararg(self):
   return self.kind == 'vararg'

   ...

?

Thanks,
-
Yury

___
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

Re: [Python-Dev] PEP 362 Third Revision

[Ethan Furman]

Yury Selivanov wrote:

On 2012-06-14, at 11:24 AM, Brett Cannon wrote:

On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov  wrote:
 
[SNIP]
 
Let's consider replacement of 'Parameter.is_*' set of attributes with

a single 'Parameter.kind' attribute, which will have the following
possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.

(I think 'positional' is more intuitive than 'index'?)


+1 if this change is made.


How about adding 'kind' and keeping 'is_*' attributes,
but making them read-only dynamic properties, i.e.:

   class Parameter:
   ...

   @property
   def is_vararg(self):
   return self.kind == 'vararg'

   ...

?


I like it!  +1!

~Ethan~
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Benjamin Peterson]

2012/6/14 Yury Selivanov :
> On 2012-06-14, at 11:24 AM, Brett Cannon wrote:
>> On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov  
>> wrote:
>>
>> [SNIP]
>>
>> Let's consider replacement of 'Parameter.is_*' set of attributes with
>> a single 'Parameter.kind' attribute, which will have the following
>> possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.
>>
>> (I think 'positional' is more intuitive than 'index'?)
>>
>>
>> +1 if this change is made.
>
> How about adding 'kind' and keeping 'is_*' attributes,
> but making them read-only dynamic properties, i.e.:
>
>   class Parameter:
>       ...
>
>       @property
>       def is_vararg(self):
>           return self.kind == 'vararg'
>
>       ...
>
> ?

Seems a bit bloatly to me. (One way to do it.)


-- 
Regards,
Benjamin
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Yury Selivanov]

On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote:

> 2012/6/14 Yury Selivanov :
>> On 2012-06-14, at 11:24 AM, Brett Cannon wrote:
>>> On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov  
>>> wrote:
>>> 
>>> [SNIP]
>>> 
>>> Let's consider replacement of 'Parameter.is_*' set of attributes with
>>> a single 'Parameter.kind' attribute, which will have the following
>>> possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.
>>> 
>>> (I think 'positional' is more intuitive than 'index'?)
>>> 
>>> 
>>> +1 if this change is made.
>> 
>> How about adding 'kind' and keeping 'is_*' attributes,
>> but making them read-only dynamic properties, i.e.:
>> 
>>   class Parameter:
>>   ...
>> 
>>   @property
>>   def is_vararg(self):
>>   return self.kind == 'vararg'
>> 
>>   ...
>> 
>> ?
> 
> Seems a bit bloatly to me. (One way to do it.)

Yes, but on the other hand it solves "strings are error prone"
argument, keeps all 'is_*' attributes in sync, and makes them
read-only.

'kind' property may do validation on set, to diminish mistakes
probability even further.

-
Yury
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Ethan Furman]

Yury Selivanov wrote:

Hello,

The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/


It's possible to test Signatures for equality.  Two signatures
are equal when they have equal parameters and return annotations.


Possibly a dumb question, but do the parameter names have to be the same 
to compare equal?  If yes, is there an easy way to compare two 
signatures by annotations alone?


~Ethan~
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Yury Selivanov]

On 2012-06-14, at 12:03 PM, Ethan Furman wrote:

> Yury Selivanov wrote:
>> Hello,
>> The new revision of PEP 362 has been posted:
>> http://www.python.org/dev/peps/pep-0362/
>> It's possible to test Signatures for equality.  Two signatures
>> are equal when they have equal parameters and return annotations.
> 
> Possibly a dumb question, but do the parameter names have to be the same to 
> compare equal?  If yes, is there an easy way to compare two signatures by 
> annotations alone?

Yes, parameter names have be the same.

You need to write a custom compare function for Parameters,
that will check that two have (or both don't) equal
annotations and *kinds*, and then write a compare function
for Signatures, that will test return_annotations and
'parameters' collections.

All in all, shouldn't be longer than 10-15 lines of code.

Another "solution" to the problem could be adding a new 'annotations' 
read-only dynamic property to the Signature, that would iterate 
through parameters and produce a single dict.  But this solution
has a serious flaw, as signature of:

   def foo(a:int, *, b:int) -> float

is not equal to the signature of:

   def bar(a:int, b:int) -> float

and certainly not the signature of:

   def spam(*args:int, **kwargs:int) -> float

So the most correct approach here is the one I described in the
first place.


Thanks,

-
Yury
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Brett Cannon]

On Thu, Jun 14, 2012 at 12:39 PM, Yury Selivanov wrote:

> On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote:
>
> > 2012/6/14 Yury Selivanov :
> >> On 2012-06-14, at 11:24 AM, Brett Cannon wrote:
> >>> On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov <
> yselivanov...@gmail.com> wrote:
> >>>
> >>> [SNIP]
> >>>
> >>> Let's consider replacement of 'Parameter.is_*' set of attributes with
> >>> a single 'Parameter.kind' attribute, which will have the following
> >>> possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.
> >>>
> >>> (I think 'positional' is more intuitive than 'index'?)
> >>>
> >>>
> >>> +1 if this change is made.
> >>
> >> How about adding 'kind' and keeping 'is_*' attributes,
> >> but making them read-only dynamic properties, i.e.:
> >>
> >>   class Parameter:
> >>   ...
> >>
> >>   @property
> >>   def is_vararg(self):
> >>   return self.kind == 'vararg'
> >>
> >>   ...
> >>
> >> ?
> >
> > Seems a bit bloatly to me. (One way to do it.)
>
> Yes, but on the other hand it solves "strings are error prone"
> argument, keeps all 'is_*' attributes in sync, and makes them
> read-only.
>
> 'kind' property may do validation on set, to diminish mistakes
> probability even further.
>

I agree with Benjamin, it goes against TOOWTDI without enough of a
justification to break the rule. Just make the strings constants on the
Parameter class and you solve the lack of enum issue.
___
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

[Python-Dev] Announcing the python-static-type-checking google group

[Edward K. Ream]

Hello all,

GvR has asked me to announce the python-static-type-checking google
group http://groups.google.com/group/python-static-type-checking to
python-dev.

Consider it announced.  Anyone from python-dev who likes may become a member.

Here is the "About this group" posting:

Q
This group got its start as a response to GvR's Keynote address at
PyCon 2012, http://pyvideo.org/video/956/keynote-guido-van-rossum
specifically, his remarks about static type checking beginning in the
28'th minute.

Guido and I have been emailing about this topic for a day or so. These
emails will form the first few posts of this group.

This group is public, in the sense that anyone can see it, but initial
invitations will go only to those who have written significant python
tools related to type checking.  It will probably be best to have
group have a low profile at first.   Having said that, I encourage
members to invite others who may be able to contribute.  Experience
with other projects shows that crucial contributions may come from
unlikely sources.

Because of spam, this will be a moderated group.  New members must
request permission to post.
Q

Edward
--
Edward K. Ream email: edream...@gmail.com
Leo: http://webpages.charter.net/edreamleo/front.html
--
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Alexandre Zani]

+1

On Thu, Jun 14, 2012 at 9:16 AM, Yury Selivanov  wrote:
> On 2012-06-14, at 11:24 AM, Brett Cannon wrote:
>> On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov  
>> wrote:
>>
>> [SNIP]
>>
>> Let's consider replacement of 'Parameter.is_*' set of attributes with
>> a single 'Parameter.kind' attribute, which will have the following
>> possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.
>>
>> (I think 'positional' is more intuitive than 'index'?)
>>
>>
>> +1 if this change is made.
>
> How about adding 'kind' and keeping 'is_*' attributes,
> but making them read-only dynamic properties, i.e.:
>
>   class Parameter:
>       ...
>
>       @property
>       def is_vararg(self):
>           return self.kind == 'vararg'
>
>       ...
>
> ?
>
> Thanks,
> -
> Yury
>
> ___
> 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/alexandre.zani%40gmail.com
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Terry Reedy]

On 6/14/2012 6:00 AM, Nick Coghlan wrote:


 > Just a thought: Do we want to include the docstring? A function's
 > docstring is often intimately tied to its signature. (Or at least, a
 > lot of us try to write docstrings that effectively describe the
 > function's signature)

No, combining the signature with other details like the name and
docstring is the task of higher level interfaces like pydoc.


Idle tooltips are potentially two lines: the signature and the first 
line of the docstring. (Some builtins need a better first line, but 
thats another issue.)


--
Terry Jan Reedy

___
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

Re: [Python-Dev] PEP 362 Third Revision

[Terry Reedy]

On 6/14/2012 1:10 PM, Brett Cannon wrote:



On Thu, Jun 14, 2012 at 12:39 PM, Yury Selivanov
mailto:yselivanov...@gmail.com>> wrote:

On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote:

 > 2012/6/14 Yury Selivanov mailto:yselivanov...@gmail.com>>:
 >> On 2012-06-14, at 11:24 AM, Brett Cannon wrote:
 >>> On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov
mailto:yselivanov...@gmail.com>> wrote:
 >>>
 >>> [SNIP]
 >>>
 >>> Let's consider replacement of 'Parameter.is_*' set of
attributes with
 >>> a single 'Parameter.kind' attribute, which will have the following
 >>> possible values: 'positional', 'vararg', 'keyword-only',
'varkwarg'.
 >>>
 >>> (I think 'positional' is more intuitive than 'index'?)
 >>>
 >>>
 >>> +1 if this change is made.
 >>
 >> How about adding 'kind' and keeping 'is_*' attributes,
 >> but making them read-only dynamic properties, i.e.:
 >>
 >>   class Parameter:
 >>   ...
 >>
 >>   @property
 >>   def is_vararg(self):
 >>   return self.kind == 'vararg'
 >>
 >>   ...
 >>
 >> ?
 >
 > Seems a bit bloatly to me. (One way to do it.)

Yes, but on the other hand it solves "strings are error prone"
argument, keeps all 'is_*' attributes in sync, and makes them
read-only.

'kind' property may do validation on set, to diminish mistakes
probability even further.


I agree with Benjamin, it goes against TOOWTDI without enough of a
justification to break the rule. Just make the strings constants on the
Parameter class and you solve the lack of enum issue.


My opinion: I don't like the multiple radio-button attributes either. It 
is one attribute with multiple values. We use constants elsewhere. In 
the absence of an enum type that maps ints to a string, the constants 
should be strings for display and printing.


--
Terry Jan Reedy

___
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

Re: [Python-Dev] PEP 362 Third Revision

[Yury Selivanov]

On 2012-06-14, at 1:51 PM, Terry Reedy wrote:

> On 6/14/2012 6:00 AM, Nick Coghlan wrote:
> 
>> > Just a thought: Do we want to include the docstring? A function's
>> > docstring is often intimately tied to its signature. (Or at least, a
>> > lot of us try to write docstrings that effectively describe the
>> > function's signature)
>> 
>> No, combining the signature with other details like the name and
>> docstring is the task of higher level interfaces like pydoc.
> 
> Idle tooltips are potentially two lines: the signature and the first line of 
> the docstring. (Some builtins need a better first line, but thats another 
> issue.)

We've decided to make Signature to represent only
call-signature-part of objects.  Docstring, along with
object's name and docstring isn't part of it.

In any way, it's easy to get all information you need:

def introspect_function(func):
sig = signature(func)
return (func.__name__, func.__doc__, str(sig))

-
Yury
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Eric Snow]

On Thu, Jun 14, 2012 at 9:06 AM, R. David Murray  wrote:
> I don't have strong feelings about this, but to me the fact that there
> are values of the individual parameters that if they occur on the same
> object at the same time would be invalid is a code smell.  If the thing
> can be one and only one of a list of possible types, it makes sense to
> me that this be indicated as a single attribute with a list of possible
> values, rather than a set of boolean options, one for each type.
>
> For the attribute error issue, we could have module attributes that give
> names to the strings:
>
>    if parameter.kind == inspect.VARARG_KIND:
>        stuff
>
> Or if we don't want that in the stdlib, the individual programmer who
> cares about it can define their own constants.


On Thu, Jun 14, 2012 at 11:10 AM, Brett Cannon  wrote:
> I agree with Benjamin, it goes against TOOWTDI without enough of a
> justification to break the rule. Just make the strings constants on the
> Parameter class and you solve the lack of enum issue.

+1

-eric
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Alexandre Zani]

On Thu, Jun 14, 2012 at 10:10 AM, Brett Cannon  wrote:
>
>
> On Thu, Jun 14, 2012 at 12:39 PM, Yury Selivanov 
> wrote:
>>
>> On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote:
>>
>> > 2012/6/14 Yury Selivanov :
>> >> On 2012-06-14, at 11:24 AM, Brett Cannon wrote:
>> >>> On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov
>> >>>  wrote:
>> >>>
>> >>> [SNIP]
>> >>>
>> >>> Let's consider replacement of 'Parameter.is_*' set of attributes with
>> >>> a single 'Parameter.kind' attribute, which will have the following
>> >>> possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.
>> >>>
>> >>> (I think 'positional' is more intuitive than 'index'?)
>> >>>
>> >>>
>> >>> +1 if this change is made.
>> >>
>> >> How about adding 'kind' and keeping 'is_*' attributes,
>> >> but making them read-only dynamic properties, i.e.:
>> >>
>> >>   class Parameter:
>> >>       ...
>> >>
>> >>       @property
>> >>       def is_vararg(self):
>> >>           return self.kind == 'vararg'
>> >>
>> >>       ...
>> >>
>> >> ?
>> >
>> > Seems a bit bloatly to me. (One way to do it.)
>>
>> Yes, but on the other hand it solves "strings are error prone"
>> argument, keeps all 'is_*' attributes in sync, and makes them
>> read-only.
>>
>> 'kind' property may do validation on set, to diminish mistakes
>> probability even further.
>
>
> I agree with Benjamin, it goes against TOOWTDI without enough of a
> justification to break the rule. Just make the strings constants on the
> Parameter class and you solve the lack of enum issue.
>
> ___
> 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/alexandre.zani%40gmail.com
>

I don't think it really breaks TOOWTDI because you're talking about
two use-cases. In one case, you're checking if something is a
particular kind of parameter. In the other case, you're doing some
sort of dict-based dispatch. I also think is_args etc is cleaner to
use when doing a comparison:

if param.is_arg:

vs

if param.kind == param.ARG:

That said, it's not a huge deal and so I won't push this any more than
I already have.
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Ethan Furman]

Alexandre Zani wrote:

I don't think it really breaks TOOWTDI because you're talking about
two use-cases. In one case, you're checking if something is a
particular kind of parameter. In the other case, you're doing some
sort of dict-based dispatch. I also think is_args etc is cleaner to
use when doing a comparison:

if param.is_arg:

vs

if param.kind == param.ARG:


+1



That said, it's not a huge deal and so I won't push this any more than
I already have.


ditto

~Ethan~
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Antoine Pitrou]

On Thu, 14 Jun 2012 09:32:59 -0700
Benjamin Peterson  wrote:
> >
> > How about adding 'kind' and keeping 'is_*' attributes,
> > but making them read-only dynamic properties, i.e.:
> >
> >   class Parameter:
> >       ...
> >
> >       @property
> >       def is_vararg(self):
> >           return self.kind == 'vararg'
> >
> >       ...
> >
> > ?
> 
> Seems a bit bloatly to me. (One way to do it.)

Agreed with Benjamin.
Also, the "is_*" attributes are misleading: it looks like they are
orthogonal but only one of them can be true at any time.

Regards

Antoine.


___
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

Re: [Python-Dev] PEP 362 Third Revision

[Ethan Furman]

Antoine Pitrou wrote:

On Thu, 14 Jun 2012 09:32:59 -0700
Benjamin Peterson  wrote:

How about adding 'kind' and keeping 'is_*' attributes,
but making them read-only dynamic properties, i.e.:

  class Parameter:
  ...

  @property
  def is_vararg(self):
  return self.kind == 'vararg'

  ...

?

Seems a bit bloatly to me. (One way to do it.)


Agreed with Benjamin.
Also, the "is_*" attributes are misleading: it looks like they are
orthogonal but only one of them can be true at any time.


This is no different from what we have with strings now:

--> 'aA'.islower()
False
--> 'aA'.isupper()
False
--> 'a'.islower()
True
--> 'A'.isupper()
True

We know that a string cannot be both all-upper and all-lower at the same 
time; likewise we know a variable cannot be both positional and kwargs.


~Ethan~
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Antoine Pitrou]

On Thu, 14 Jun 2012 12:46:38 -0700
Ethan Furman  wrote:
> 
> This is no different from what we have with strings now:
> 
> --> 'aA'.islower()
> False
> --> 'aA'.isupper()
> False
> --> 'a'.islower()
> True
> --> 'A'.isupper()
> True
> 
> We know that a string cannot be both all-upper and all-lower at the same 
> time;

We know that because it's common wisdom for everyone (although who knows
what oddities the unicode consortium may come up with in the future).
Whether a given function argument may be of several kinds at the same
time is much less obvious to most people.

Regards

Antoine.


___
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

Re: [Python-Dev] PEP 362 Third Revision

[Benjamin Peterson]

2012/6/14 Ethan Furman :
> This is no different from what we have with strings now:
>
> --> 'aA'.islower()
> False
> --> 'aA'.isupper()
> False
> --> 'a'.islower()
> True
> --> 'A'.isupper()
> True
>
> We know that a string cannot be both all-upper and all-lower at the same
> time; likewise we know a variable cannot be both positional and kwargs.

This is much less clear cut as there's no clause in the Unicode
standard saying (!islower()  or !isupper()) must be true.


-- 
Regards,
Benjamin
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Alexandre Zani]

On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou  wrote:
> On Thu, 14 Jun 2012 12:46:38 -0700
> Ethan Furman  wrote:
>>
>> This is no different from what we have with strings now:
>>
>> --> 'aA'.islower()
>> False
>> --> 'aA'.isupper()
>> False
>> --> 'a'.islower()
>> True
>> --> 'A'.isupper()
>> True
>>
>> We know that a string cannot be both all-upper and all-lower at the same
>> time;
>
> We know that because it's common wisdom for everyone (although who knows
> what oddities the unicode consortium may come up with in the future).
> Whether a given function argument may be of several kinds at the same
> time is much less obvious to most people.

Is it obvious to most people? No. Is it obvious to most users of this
functionality? I would expect so. This isn't some implementation
detail, this is a characteristic of python parameters. If you don't
understand it, you are probably not the audience for signature.

>
> Regards
>
> Antoine.
>
>
> ___
> 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/alexandre.zani%40gmail.com
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Benjamin Peterson]

2012/6/14 Alexandre Zani :
> On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou  wrote:
>> On Thu, 14 Jun 2012 12:46:38 -0700
>> Ethan Furman  wrote:
>>>
>>> This is no different from what we have with strings now:
>>>
>>> --> 'aA'.islower()
>>> False
>>> --> 'aA'.isupper()
>>> False
>>> --> 'a'.islower()
>>> True
>>> --> 'A'.isupper()
>>> True
>>>
>>> We know that a string cannot be both all-upper and all-lower at the same
>>> time;
>>
>> We know that because it's common wisdom for everyone (although who knows
>> what oddities the unicode consortium may come up with in the future).
>> Whether a given function argument may be of several kinds at the same
>> time is much less obvious to most people.
>
> Is it obvious to most people? No. Is it obvious to most users of this
> functionality? I would expect so. This isn't some implementation
> detail, this is a characteristic of python parameters. If you don't
> understand it, you are probably not the audience for signature.

Consequently, the "kind" model should match up very well with their
understanding that a parameter can only be one "kind" at a time.



-- 
Regards,
Benjamin
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Terry Reedy]

On 6/14/2012 3:46 PM, Ethan Furman wrote:

Antoine Pitrou wrote:



Also, the "is_*" attributes are misleading: it looks like they are
orthogonal but only one of them can be true at any time.


This is no different from what we have with strings now:

--> 'aA'.islower()
False
--> 'aA'.isupper()
False
--> 'a'.islower()
True
--> 'A'.isupper()
True


The analogy does not hold. These are not attributes. They are methods 
that scan the attributes of individual characters in the string. Also, 
for many alphabets, characters are both upper and lower case, unless you 
prefer no case or uncased. Then there is also titlecase.  Of course, 
multiple character strings can be mixed case. So str.casekind does not 
make much sense. So your example convinces me even more that 'kind' is 
the way to go ;-).


---
Letter upper/lower case, if they follow the unicode definition below, 
are primarily derived from 'Lu' and 'Ll', which are two of about 30 
possible general categories (one attribute). But they also use 
Other_Uppercase and Other_Lowercase.

'''
DerivedCoreProperties.txt
Lowercase 	B 	I 	Characters with the Lowercase property. For more 
information, see Chapter 4, Character Properties in [Unicode].

Generated from: Ll + Other_Lowercase

Uppercase 	B 	I 	Characters with the Uppercase property. For more 
information, see Chapter 4, Character Properties in [Unicode].

Generated from: Lu + Other_Uppercase
'''
But these are all implementation details depending on the particular 
organization of the unicode character database. Defining cross-alphabet 
'character' properties is a non-trivial endeavor, not at all like 
argument kind.


--
Terry Jan Reedy

___
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

Re: [Python-Dev] PEP 362 Third Revision

[R. David Murray]

On Thu, 14 Jun 2012 21:57:34 +0200, Antoine Pitrou  wrote:
> On Thu, 14 Jun 2012 12:46:38 -0700
> Ethan Furman  wrote:
> > 
> > This is no different from what we have with strings now:
> > 
> > --> 'aA'.islower()
> > False
> > --> 'aA'.isupper()
> > False
> > --> 'a'.islower()
> > True
> > --> 'A'.isupper()
> > True
> > 
> > We know that a string cannot be both all-upper and all-lower at the same 
> > time;
> 
> We know that because it's common wisdom for everyone (although who knows
> what oddities the unicode consortium may come up with in the future).

Indeed, there is at least one letter that is used in both upper case and
lower case, so the consortium could reasonably declare that it should
return True for both isupper and islower :).

I'm not going to claim that there was that much foresight in the creation
of those two methods.  I will, however, note that we aren't perfectly
consistent in the application of our rules.

--David
___
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

Re: [Python-Dev] deprecating .pyo and -O

[Steven D'Aprano]

Floris Bruynooghe wrote:

On 14 June 2012 11:25, Antoine Pitrou  wrote:

Honestly, I think the best option would be to deprecate .pyo files as
well as the useless -O option. They only cause confusion without
providing any significant benefits.


+1

But what happens to __debug__ and assert statements?  I think it
should be possible to always put assert statements inside a __debug__
block and then create -O a simple switch for setting __debug__ to
False.  If desired a simple strip tool could then easily remove
__debug__ blocks and (unused) docstrings.


So in other words, you want to keep the functionality of -O, but make it the 
responsibility of the programmer to write an external tool to implement it?


Apart from the duplication of effort (everyone who wants to optimize their 
code has to write their own source-code strip tool), that surely is only going 
to decrease the reliability and usefulness of Python optimization, not 
increase it.


-O may be under-utilized by programmers who don't need or want it, but that 
doesn't mean it isn't useful to those who do want it. -1 on deprecation.




--
Steven
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Yury Selivanov]

On 2012-06-14, at 4:24 PM, Benjamin Peterson wrote:

> 2012/6/14 Alexandre Zani :
>> On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou  wrote:
>>> On Thu, 14 Jun 2012 12:46:38 -0700
>>> Ethan Furman  wrote:
 
 This is no different from what we have with strings now:
 
 --> 'aA'.islower()
 False
 --> 'aA'.isupper()
 False
 --> 'a'.islower()
 True
 --> 'A'.isupper()
 True
 
 We know that a string cannot be both all-upper and all-lower at the same
 time;
>>> 
>>> We know that because it's common wisdom for everyone (although who knows
>>> what oddities the unicode consortium may come up with in the future).
>>> Whether a given function argument may be of several kinds at the same
>>> time is much less obvious to most people.
>> 
>> Is it obvious to most people? No. Is it obvious to most users of this
>> functionality? I would expect so. This isn't some implementation
>> detail, this is a characteristic of python parameters. If you don't
>> understand it, you are probably not the audience for signature.
> 
> Consequently, the "kind" model should match up very well with their
> understanding that a parameter can only be one "kind" at a time.

I myself now like the 'kind' attribute more than 'is_*' family.
Brett and Larry also voted for it, as well the majority here.

I'll amend the PEP this evening to replace 'is_args', 'is_kwargs',
and 'is_keyword_only' with a 'kind' attribute, with possible
values: 'positional', 'vararg', 'varkw', 'kwonly'.

Parameter class will have four constants, respectively:

 class Parameter:
 KIND_POSITIONAL = 'positional'
 KIND_VARARG = 'vararg'
 KIND_VARKW = 'varkw'
 KIND_KWONLY = 'kwonly'

'Parameter.is_implemented' will be renamed to 'Parameter.implemented'

Is everybody OK with this?  Thoughts?

I, for instance, like 'varkwarg' more than 'varkw' (+ it is more
consistent with **kwargs)

-
Yury
___
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

Re: [Python-Dev] deprecating .pyo and -O

[Antoine Pitrou]

On Fri, 15 Jun 2012 06:38:45 +1000
Steven D'Aprano  wrote:
> 
> Apart from the duplication of effort (everyone who wants to optimize their 
> code has to write their own source-code strip tool),

Actually, it could be shipped with Python, or even done dynamically at
runtime (instead of relying on separate bytecode files).

Regards

Antoine.


___
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

Re: [Python-Dev] deprecating .pyo and -O

[Steven D'Aprano]

Antoine Pitrou wrote:


Do other high-level languages have similar functionality?



Parrot (does anyone actually use Parrot?) has a byte-code optimizer.

javac -O is supposed to emit optimized byte-code, but allegedly it is a no-op.

On the other hand, the Java ecosystem includes third-party Java compilers 
which claim to be faster/better than Oracle's compiler, including emitting 
much tighter byte-code.


There are also Java byte-code optimizers such as Proguard and Soot.

By default, Perl doesn't write byte-code to files. But when it does, there are 
various "optimization back-ends" that you can use.


Until version 1.9, Ruby didn't even use byte-code at all.


--
Steven

___
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

Re: [Python-Dev] PEP 362 Third Revision

[Antoine Pitrou]

On Wed, 13 Jun 2012 22:52:43 -0400
Yury Selivanov  wrote:
> * is_implemented : bool
> True if the parameter is implemented for use.  Some platforms
> implement functions but can't support specific parameters
> (e.g. "mode" for ``os.mkdir``).  Passing in an unimplemented
> parameter may result in the parameter being ignored,
> or in NotImplementedError being raised.  It is intended that
> all conditions where ``is_implemented`` may be False be
> thoroughly documented.

I don't understand what the purpose of is_implemented is, or how it is
supposed to be computed.

> * bind(\*args, \*\*kwargs) -> BoundArguments
> Creates a mapping from positional and keyword arguments to
> parameters.  Raises a ``BindError`` (subclass of ``TypeError``)
> if the passed arguments do not match the signature.

Why a dedicated exception class? TypeError is good enough, and the
proliferation of exception classes is a nuisance.

Regards

Antoine.


___
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

Re: [Python-Dev] PEP 362 Third Revision

[Alexandre Zani]

On Thu, Jun 14, 2012 at 1:45 PM, Yury Selivanov  wrote:
> On 2012-06-14, at 4:24 PM, Benjamin Peterson wrote:
>
>> 2012/6/14 Alexandre Zani :
>>> On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou  
>>> wrote:
 On Thu, 14 Jun 2012 12:46:38 -0700
 Ethan Furman  wrote:
>
> This is no different from what we have with strings now:
>
> --> 'aA'.islower()
> False
> --> 'aA'.isupper()
> False
> --> 'a'.islower()
> True
> --> 'A'.isupper()
> True
>
> We know that a string cannot be both all-upper and all-lower at the same
> time;

 We know that because it's common wisdom for everyone (although who knows
 what oddities the unicode consortium may come up with in the future).
 Whether a given function argument may be of several kinds at the same
 time is much less obvious to most people.
>>>
>>> Is it obvious to most people? No. Is it obvious to most users of this
>>> functionality? I would expect so. This isn't some implementation
>>> detail, this is a characteristic of python parameters. If you don't
>>> understand it, you are probably not the audience for signature.
>>
>> Consequently, the "kind" model should match up very well with their
>> understanding that a parameter can only be one "kind" at a time.
>
> I myself now like the 'kind' attribute more than 'is_*' family.
> Brett and Larry also voted for it, as well the majority here.
>
> I'll amend the PEP this evening to replace 'is_args', 'is_kwargs',
> and 'is_keyword_only' with a 'kind' attribute, with possible
> values: 'positional', 'vararg', 'varkw', 'kwonly'.
>
> Parameter class will have four constants, respectively:
>
>     class Parameter:
>         KIND_POSITIONAL = 'positional'
>         KIND_VARARG = 'vararg'
>         KIND_VARKW = 'varkw'
>         KIND_KWONLY = 'kwonly'
>
> 'Parameter.is_implemented' will be renamed to 'Parameter.implemented'
>
> Is everybody OK with this?  Thoughts?
>
> I, for instance, like 'varkwarg' more than 'varkw' (+ it is more
> consistent with **kwargs)
>
> -
> Yury

How about keyword instead of kwonly? I find kwonly clear when
side-by-side with varkw, but ambiguous standalone.

I like the idea of using args and kwargs just because those are the
defacto standard way we refer to that type of argument.
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Benjamin Peterson]

2012/6/14 Alexandre Zani :
> How about keyword instead of kwonly? I find kwonly clear when
> side-by-side with varkw, but ambiguous standalone.
>
> I like the idea of using args and kwargs just because those are the
> defacto standard way we refer to that type of argument.

That conflates the name of the parameter with what it does.


-- 
Regards,
Benjamin
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Ethan Furman]

Yury Selivanov wrote:

I'll amend the PEP this evening to replace 'is_args', 'is_kwargs',
and 'is_keyword_only' with a 'kind' attribute, with possible
values: 'positional', 'vararg', 'varkw', 'kwonly'.

Parameter class will have four constants, respectively:

 class Parameter:
 KIND_POSITIONAL = 'positional'
 KIND_VARARG = 'vararg'
 KIND_VARKW = 'varkw'
 KIND_KWONLY = 'kwonly'

'Parameter.is_implemented' will be renamed to 'Parameter.implemented'

Is everybody OK with this?  Thoughts?

I, for instance, like 'varkwarg' more than 'varkw' (+ it is more
consistent with **kwargs)


+1

I like these names, and the similarity between 'vararg' and 'varkw'.  I 
would also be happy with 'args' and 'kwargs'.


~Ethan~
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Alexandre Zani]

On Thu, Jun 14, 2012 at 2:00 PM, Benjamin Peterson  wrote:
> 2012/6/14 Alexandre Zani :
>> How about keyword instead of kwonly? I find kwonly clear when
>> side-by-side with varkw, but ambiguous standalone.
>>
>> I like the idea of using args and kwargs just because those are the
>> defacto standard way we refer to that type of argument.
>
> That conflates the name of the parameter with what it does.

Agreed, but also easily understood.
>
>
> --
> Regards,
> Benjamin
___
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

Re: [Python-Dev] deprecating .pyo and -O

[Martin v. Löwis]

> I don't really see the point. In my experience there is no benefit to
> removing assert statements in production mode. This is a C-specific
> notion that doesn't really map very well to Python code. Do other
> high-level languages have similar functionality?

It's not at all C specific. C# also has it:

http://msdn.microsoft.com/en-us/library/ttcc4x86(v=vs.80).aspx

Java makes it a VM option (rather than a compiler option), but it's
still a flag to the VM (-enableassertions):

http://docs.oracle.com/javase/1.4.2/docs/tooldocs/windows/java.html

Delphi also has assertions that can be disabled at compile time.

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/archive%40mail-archive.com

[Python-Dev] FWD: Windows 3.2.3 64 bit installers are actually 3.2

[Aahz]

Note: I'm no-mail on python-dev

- Forwarded message from Sean Johnson  -

> Date: Thu, 14 Jun 2012 03:48:55 -0400
> From: Sean Johnson 
> To: webmas...@python.org
> Subject: Windows 3.2.3 64 bit installers are actually 3.2
> 
> The installers on both this page:
> 
> http://www.python.org/getit/releases/3.2.3/
> 
> and
> 
> http://www.python.org/download/
> 
> For the x86-64 MSI Installer are both builds for version 3.2, not 3.2.3 (even 
> though the filename says 3.2.3).
> 
> I just tried for about 30 minutes to find out why the input() bug mentioned 
> here:  http://bugs.python.org/issue11272 was occuring in what I thought was 
> the latest release - then I realized that my terminal windows stated version 
> 3.2, not 3.2.3 after several uninstalls/installs.

- End forwarded message -

-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

https://en.wikipedia.org/wiki/Mary_Anning
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Yury Selivanov]

On 2012-06-14, at 4:53 PM, Antoine Pitrou wrote:
> On Wed, 13 Jun 2012 22:52:43 -0400
> Yury Selivanov  wrote:
> 
>> * bind(\*args, \*\*kwargs) -> BoundArguments
>>Creates a mapping from positional and keyword arguments to
>>parameters.  Raises a ``BindError`` (subclass of ``TypeError``)
>>if the passed arguments do not match the signature.
> 
> Why a dedicated exception class? TypeError is good enough, and the
> proliferation of exception classes is a nuisance.


Agree.  Will fix this.

Thanks,

-
Yury
___
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

Re: [Python-Dev] FWD: Windows 3.2.3 64 bit installers are actually 3.2

[Brian Curtin]

On Thu, Jun 14, 2012 at 4:12 PM, Aahz  wrote:
> Note: I'm no-mail on python-dev
>
> - Forwarded message from Sean Johnson  -
>
>> Date: Thu, 14 Jun 2012 03:48:55 -0400
>> From: Sean Johnson 
>> To: webmas...@python.org
>> Subject: Windows 3.2.3 64 bit installers are actually 3.2
>>
>> The installers on both this page:
>>
>> http://www.python.org/getit/releases/3.2.3/
>>
>> and
>>
>> http://www.python.org/download/
>>
>> For the x86-64 MSI Installer are both builds for version 3.2, not 3.2.3 
>> (even though the filename says 3.2.3).
>>
>> I just tried for about 30 minutes to find out why the input() bug mentioned 
>> here:  http://bugs.python.org/issue11272 was occuring in what I thought was 
>> the latest release - then I realized that my terminal windows stated version 
>> 3.2, not 3.2.3 after several uninstalls/installs.

I think you're doing something wrong, either installing a different
file than you just downloaded or not allowing it to overwrite an
existing 3.2 installation. Both links have 3.2.3 labeled installers
which I just downloaded, and both of them install 3.2.3 executables.
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Nick Coghlan]

I like the idea of a kind attribute, I don't like the current names for the
possible values.

At the very least, "positional only" needs to be supported to handle
nameless parameters in C functions (or those that unpack *args internally)

The level of abbreviation used also seems unnecessary and internally
inconsistent.

My proposal:
POSITIONAL- positional only
NAMED_POSITIONAL - normal parameter
VAR_POSITIONAL - *args
KEYWORD - keyword only
VAR_KEYWORDS - **kwds

--
Sent from my phone, thus the relative brevity :)
On Jun 15, 2012 7:07 AM, "Ethan Furman"  wrote:

> Yury Selivanov wrote:
>
>> I'll amend the PEP this evening to replace 'is_args', 'is_kwargs',
>> and 'is_keyword_only' with a 'kind' attribute, with possible
>> values: 'positional', 'vararg', 'varkw', 'kwonly'.
>>
>> Parameter class will have four constants, respectively:
>>
>> class Parameter:
>> KIND_POSITIONAL = 'positional'
>> KIND_VARARG = 'vararg'
>> KIND_VARKW = 'varkw'
>> KIND_KWONLY = 'kwonly'
>>
>> 'Parameter.is_implemented' will be renamed to 'Parameter.implemented'
>>
>> Is everybody OK with this?  Thoughts?
>>
>> I, for instance, like 'varkwarg' more than 'varkw' (+ it is more
>> consistent with **kwargs)
>>
>
> +1
>
> I like these names, and the similarity between 'vararg' and 'varkw'.  I
> would also be happy with 'args' and 'kwargs'.
>
> ~Ethan~
> __**_
> 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/**
> ncoghlan%40gmail.com
>
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Benjamin Peterson]

2012/6/14 Nick Coghlan :
> I like the idea of a kind attribute, I don't like the current names for the
> possible values.
>
> At the very least, "positional only" needs to be supported to handle
> nameless parameters in C functions (or those that unpack *args internally)
>
> The level of abbreviation used also seems unnecessary and internally
> inconsistent.
>
> My proposal:
> POSITIONAL- positional only
> NAMED_POSITIONAL - normal parameter

Probably POSITIONAL should be the normal one, and there should be
ONLY_POSITIONAL for the weirdos.


-- 
Regards,
Benjamin
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Ethan Furman]

Nick Coghlan wrote:
I like the idea of a kind attribute, I don't like the current names for 
the possible values.


At the very least, "positional only" needs to be supported to handle 
nameless parameters in C functions (or those that unpack *args internally)


The level of abbreviation used also seems unnecessary and internally 
inconsistent.


My proposal:
POSITIONAL- positional only
NAMED_POSITIONAL - normal parameter
VAR_POSITIONAL - *args
KEYWORD - keyword only
VAR_KEYWORDS - **kwds


I could live with this, too -- as long as we lose the 'S' on 
'VAR_KEYWORDS'.  :)


~Ethan~
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Nick Coghlan]

On Jun 15, 2012 8:37 AM, "Benjamin Peterson"  wrote:
>
> 2012/6/14 Nick Coghlan :
> > I like the idea of a kind attribute, I don't like the current names for
the
> > possible values.
> >
> > At the very least, "positional only" needs to be supported to handle
> > nameless parameters in C functions (or those that unpack *args
internally)
> >
> > The level of abbreviation used also seems unnecessary and internally
> > inconsistent.
> >
> > My proposal:
> > POSITIONAL- positional only
> > NAMED_POSITIONAL - normal parameter
>
> Probably POSITIONAL should be the normal one, and there should be
> ONLY_POSITIONAL for the weirdos.

I did think about that, but it's both inaccurate and internally
inconsistent without further changes.

Normal parameters can be specified by index (as a positional argument) or
by name (as a keyword argument). Thus, the distinctions to be made are
between "positional only", "positional or keyword" and "keyword only". If
positional only parameters are allowed to have names for documentation
purposes (as I believe they should), then using the "positional" kind for
the "positional or keyword" case is just plain wrong.

In addition, if the "only" isn't considered implied in the positional case,
then it can't be implied in the keyword case, either. That gives the other
set of internally consistent names I thought of:
POSITIONAL_ONLY
POSITIONAL_OR_KEYWORD
VAR_POSITIONAL
KEYWORD_ONLY
VAR_KEYWORD

I slightly prefer the first set I posted, but would be fine with this more
explicit approach, too.

Cheers,
Nick.

--
Sent from my phone, thus the relative brevity :)
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Yury Selivanov]

On 2012-06-14, at 7:16 PM, Nick Coghlan wrote:

> POSITIONAL_ONLY
> POSITIONAL_OR_KEYWORD
> VAR_POSITIONAL
> KEYWORD_ONLY
> VAR_KEYWORD

I like those.  A bit too lengthy and verbose, but the names
are consistent.

-
Yury
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Larry Hastings]

On 06/14/2012 05:06 AM, Victor Stinner wrote:

* is_implemented : bool
True if the parameter is implemented for use.  Some platforms
implement functions but can't support specific parameters
(e.g. "mode" for ``os.mkdir``).  Passing in an unimplemented
parameter may result in the parameter being ignored,
or in NotImplementedError being raised.  It is intended that
all conditions where ``is_implemented`` may be False be
thoroughly documented.

I suppose that the value depends on the running platform? (For
example, you may get a different value on Linux and Windows.)


Exactly.  I expect it to vary mainly by platform.


//arry/
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Larry Hastings]

On 06/14/2012 01:53 PM, Antoine Pitrou wrote:

* is_implemented : bool
 True if the parameter is implemented for use.  Some platforms
 implement functions but can't support specific parameters
 (e.g. "mode" for ``os.mkdir``).  Passing in an unimplemented
 parameter may result in the parameter being ignored,
 or in NotImplementedError being raised.  It is intended that
 all conditions where ``is_implemented`` may be False be
 thoroughly documented.

I don't understand what the purpose of is_implemented is, or how it is
supposed to be computed.


It's computed based on locally available functionality.  Its purpose is 
to allow LBYL when using functionality that may not be available on all 
platforms.  See issue 14626 for a specific use-case--which is why I 
pushed for this.


When all the chips fall into place, I expect to have some code that 
looks like this:


   os.chown.__signature__.parameters['fd'].is_implemented =
   sysconfig.get_config_var('HAVE_FCHOWN')

That's oversimplified (and almost certainly not spelled correctly) but 
you get the general idea.  os.chown will soon sprout an "fd" parameter, 
but it will only work on platforms where we have fchown().  Using it 
will result in a NotImplementedError.  But some folks want to LBYL.



//arry/
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Benjamin Peterson]

2012/6/14 Larry Hastings :
>
> On 06/14/2012 01:53 PM, Antoine Pitrou wrote:
>
> * is_implemented : bool
> True if the parameter is implemented for use.  Some platforms
> implement functions but can't support specific parameters
> (e.g. "mode" for ``os.mkdir``).  Passing in an unimplemented
> parameter may result in the parameter being ignored,
> or in NotImplementedError being raised.  It is intended that
> all conditions where ``is_implemented`` may be False be
> thoroughly documented.
>
> I don't understand what the purpose of is_implemented is, or how it is
> supposed to be computed.
>
>
> It's computed based on locally available functionality.  Its purpose is to
> allow LBYL when using functionality that may not be available on all
> platforms.  See issue 14626 for a specific use-case--which is why I pushed
> for this.

In that case wouldn't be nicer to have os level attribute ala
os.path.supports_unicode_filenames?

os.supports_atfunctions

is gobs nicer than

os.chown.__signature__.parameters['fd'].is_implemented

Not "implementing" all parameters (whatever exactly that means) is not
a very common case for a function, so I don't see what it needs to
pollute a signature object for every Python function.



-- 
Regards,
Benjamin
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Larry Hastings]

On 06/14/2012 07:49 PM, Benjamin Peterson wrote:

In that case wouldn't be nicer to have os level attribute ala
os.path.supports_unicode_filenames?

os.supports_atfunctions

is gobs nicer than

os.chown.__signature__.parameters['fd'].is_implemented

Not "implementing" all parameters (whatever exactly that means) is not
a very common case for a function, so I don't see what it needs to
pollute a signature object for every Python function.


We can safely agree to disagree here.

Also, it's more granular than that.  For example, Python now understands 
symbolic links on Windows--but only haphazardly at best.  The 
"follow_symlinks" argument works on Windows for os.stat() but not for 
os.chmod().



//arry/
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Benjamin Peterson]

2012/6/14 Larry Hastings :
> Also, it's more granular than that.  For example, Python now understands
> symbolic links on Windows--but only haphazardly at best.  The
> "follow_symlinks" argument works on Windows for os.stat() but not for
> os.chmod().

Then indeed it's more granular than a parameter being "implemented" or
not. A parameter may have a more restricted or extended meaning on
different operating systems. (sendfile() on files for example).


-- 
Regards,
Benjamin
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Nick Coghlan]

On Fri, Jun 15, 2012 at 11:37 AM, Yury Selivanov
 wrote:
> On 2012-06-14, at 7:16 PM, Nick Coghlan wrote:
>
>> POSITIONAL_ONLY
>> POSITIONAL_OR_KEYWORD
>> VAR_POSITIONAL
>> KEYWORD_ONLY
>> VAR_KEYWORD
>
> I like those.  A bit too lengthy and verbose, but the names
> are consistent.

In this case, I'm willing to trade a bit of verbosity for accuracy. It
also suggests a possible, more explicit name for the attribute:
"binding".

Parameter.binding - describes how argument values are bound to the parameter

POSITIONAL_ONLY - value must be supplied as a positional argument [1]
POSITIONAL_OR_KEYWORD - value may be supplied as either a keyword
or positional argument [2]
KEYWORD_ONLY - value must be supplied as a keyword argument [3]
VAR_POSITIONAL - a tuple of positional arguments that aren't bound
to any other parameter [4]
VAR_KEYWORD - a dict of keyword arguments that aren't bound to any
other parameter [5]

[1] Python has no explicit syntax for defining positional only
parameters, but they may be implemented by processing the contents of
a VAR_POSITIONAL parameter and customising the contents of
__signature__. Many builtin and extension module functions (especially
those that accept only one or two parameters) accept positional-only
parameters.
[2] This is the standard binding behaviour for functions
implemented in Python
[3] Keyword only parameters are those which appear after a "*" or
"*args" entry in a Python function definition. They may also be
implemented by processing the contents of a VAR_KEYWORD parameter and
customising the contents of __signature__.
[4] This corresponds to a "*args" parameter in a Python function definition
[5] This corresponds to a "**kwds" parameter in a Python function definition

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Nick Coghlan]

On Fri, Jun 15, 2012 at 1:20 PM, Benjamin Peterson  wrote:
> 2012/6/14 Larry Hastings :
>> Also, it's more granular than that.  For example, Python now understands
>> symbolic links on Windows--but only haphazardly at best.  The
>> "follow_symlinks" argument works on Windows for os.stat() but not for
>> os.chmod().
>
> Then indeed it's more granular than a parameter being "implemented" or
> not. A parameter may have a more restricted or extended meaning on
> different operating systems. (sendfile() on files for example).

I agree with Benjamin here: I'd like to leave the flag out for now. I
can see there could be a legitimate use case for something *like*
that, but:

1. Context-specific function annotations may be a better answer
2. Context-specific "info" containers (such as sys.flags,
sys.int_info, sys.float_info, time.get_clock_info) may be a better
answer
3. A multi-valued attribute or an arbitrary string attribute
(parameter docstrings, anyone?) may be a better answer

There's no need to enshrine a flag for a currently ill-defined concept
in the initial version of the API. If it still seems like a good idea
by the time 3.4 rolls around, then we can add it than as a new
attribute on inspect.Parameter objects

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Larry Hastings]

On 06/14/2012 08:20 PM, Benjamin Peterson wrote:

2012/6/14 Larry Hastings:

Also, it's more granular than that.  For example, Python now understands
symbolic links on Windows--but only haphazardly at best.  The
"follow_symlinks" argument works on Windows for os.stat() but not for
os.chmod().

Then indeed it's more granular than a parameter being "implemented" or
not. A parameter may have a more restricted or extended meaning on
different operating systems. (sendfile() on files for example).


If you can suggest a representation that can convey this sort of subtle 
complexity without being miserable to use, I for one would be very 
interested to see it.  I suggest that "is_implemented" solves a 
legitimate problem in a reasonable way; I wasn't attempting to be all 
things to all use cases.



//arry/
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Larry Hastings]

On 06/14/2012 08:41 PM, Nick Coghlan wrote:

On Fri, Jun 15, 2012 at 1:20 PM, Benjamin Peterson  wrote:

2012/6/14 Larry Hastings:

Also, it's more granular than that.  For example, Python now understands
symbolic links on Windows--but only haphazardly at best.  The
"follow_symlinks" argument works on Windows for os.stat() but not for
os.chmod().

Then indeed it's more granular than a parameter being "implemented" or
not. A parameter may have a more restricted or extended meaning on
different operating systems. (sendfile() on files for example).

I agree with Benjamin here: I'd like to leave the flag out for now. I
can see there could be a legitimate use case for something *like*
that, but:

1. Context-specific function annotations may be a better answer
2. Context-specific "info" containers (such as sys.flags,
sys.int_info, sys.float_info, time.get_clock_info) may be a better
answer
3. A multi-valued attribute or an arbitrary string attribute
(parameter docstrings, anyone?) may be a better answer


I disagree that 2. would be better.  I would prefer a standardized way 
of introspecting the availability of functionality to a collection of 
unique approaches stored in unpredictable locations.  I disagree with 1. 
for much the same reason, though I like it more than 2.--at least it's 
bound directly to the function.


Regarding 3., "parameter docstrings" suggest docstrings, which suggest 
not-machine-readable.  The purpose of having it at all is so one can 
LBYL programmatically--if human-readable documentation is sufficient 
then we don't need this at all.


As for "multi-valued attribute", I take it you're suggesting something 
more complex than "is_implemented".  As I just said in a reply to 
Benjamin: I can't come up with a representation that's all things to all 
people.  I contend "is_implemented" solves a legitimate problem in a 
reasonable way.  If you can propose a superior representation, one that 
can convey more complex situations without becoming miserable to use, 
I'd like to see it.


However, you appear to be saying you don't know what such a 
representation would be--you only conjecture that it *might* exist.  I 
can't debate hypothetical representations.  Furthermore, I suggest that 
if such a representation is possible, that it would be implementable in 
current Python.  So again I ask: please suggest a superior 
representation.  I would be genuinely interested in seeing it.  Failing 
that, I'd prefer to restrict the discussion to whether or not the use 
case merits adding the flag.


(I apologize in advance if I have misrepresented your position.)



There's no need to enshrine a flag for a currently ill-defined concept
in the initial version of the API. If it still seems like a good idea
by the time 3.4 rolls around, then we can add it than as a new
attribute on inspect.Parameter objects


I disagree with the description "ill-defined".  I would be very 
surprised indeed if either you or Benjamin genuinely didn't understand 
exactly what "is_implemented" represents.  If you're suggesting that the 
documentation is inadequate we can certainly address that.


Perhaps you meant "ill-concieved"?


//arry/
___
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

[Python-Dev] investigating bot failures for ElementTree

[Eli Bendersky]

Hi,

I committed a significant patch to _elementtree, which causes some bots to
fail on test_xml_etree[_c]. I'm currently investigating the possible cause
of this - and will be disabling a couple of tests in the suite temporarily,
since the problems are most likely due to the ugly monkey-patching the
test_xml_etree is based on.

Eli
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Victor Stinner]

>> I don't understand what the purpose of is_implemented is, or how it is
>> supposed to be computed.
>
> It's computed based on locally available functionality.  Its purpose is to
> allow LBYL when using functionality that may not be available on all
> platforms.  See issue 14626 for a specific use-case--which is why I pushed
> for this.
>
> When all the chips fall into place, I expect to have some code that looks
> like this:
>
> os.chown.__signature__.parameters['fd'].is_implemented =
> sysconfig.get_config_var('HAVE_FCHOWN')

(Do you mean "fd" or "dirfd"?)

I don't like such function, how can it be portable? How do you decide
in your program if you can use it on any platform or not? I prefer to
have a clear distinction between chown() et fchown() for example. So
you can simply test hasattr(os, "fchown") and decide what to do if the
function is not supported.

How do you decide if the parameter is supported or not? For example,
some platforms may not support all available values for a parameter.
Dummy example, maybe not the best one: clocks supported by
time.clock_gettime() heavily depends on the platform.

Victor
___
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

Re: [Python-Dev] PEP 362 Third Revision

[Larry Hastings]

On 06/14/2012 11:37 PM, Victor Stinner wrote:

os.chown.__signature__.parameters['fd'].is_implemented =
sysconfig.get_config_var('HAVE_FCHOWN')

(Do you mean "fd" or "dirfd"?)


I meant "fd".  "dir_fd" is contingent on fchownat().  But it was only an 
example anyway.




I don't like such function, how can it be portable?


I suggest that's a separate discussion; please see issue 14626.



How do you decide in your program if you can use it on any platform or not?


I can suggest two ways:
1) Attempt to use it and catch NotImplementedError.
2) Check the "is_implemented" flag for that parameter in the function's 
signature, assuming that detail is accepted as part of PEP 362.


Thank you for independently confirming the legitimacy of the use case 
for "is_implemented".  ;-)




How do you decide if the parameter is supported or not?


Please see my example above for one plausible approach.  I assume the 
code would look different for other implementations.




For example, some platforms may not support all available values for a 
parameter.


This is the third time this has been brought up today by my count.  
Rather than repeat myself, I ask that you read my remarks elsewhere in 
this thread.



//arry/
___
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