Re: [Python-Dev] PEP 362 Third Revision

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 functio

Re: [Python-Dev] PEP 362 Third Revision

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

[Python-Dev] investigating bot failures for ElementTree

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 t

Re: [Python-Dev] PEP 362 Third Revision

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 wor

Re: [Python-Dev] PEP 362 Third Revision

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(). The

Re: [Python-Dev] PEP 362 Third Revision

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 f

Re: [Python-Dev] PEP 362 Third Revision

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

Re: [Python-Dev] PEP 362 Third Revision

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 paramete

Re: [Python-Dev] PEP 362 Third Revision

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 exac

Re: [Python-Dev] PEP 362 Third Revision

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 unimpleme

Re: [Python-Dev] PEP 362 Third Revision

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 t

Re: [Python-Dev] PEP 362 Third Revision

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 pa

Re: [Python-Dev] PEP 362 Third Revision

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

Re: [Python-Dev] PEP 362 Third Revision

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

Re: [Python-Dev] PEP 362 Third Revision

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

Re: [Python-Dev] PEP 362 Third Revision

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 abbreviati

Re: [Python-Dev] PEP 362 Third Revision

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 in

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

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 i

Re: [Python-Dev] PEP 362 Third Revision

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``) >>

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

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/g

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

> 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

Re: [Python-Dev] PEP 362 Third Revision

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 standar

Re: [Python-Dev] PEP 362 Third Revision

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_PO

Re: [Python-Dev] PEP 362 Third Revision

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

Re: [Python-Dev] PEP 362 Third Revision

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 di

Re: [Python-Dev] PEP 362 Third Revision

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

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

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

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

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 s

Re: [Python-Dev] PEP 362 Third Revision

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'.islow

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

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 stateme

Re: [Python-Dev] PEP 362 Third Revision

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'.

Re: [Python-Dev] PEP 362 Third Revision

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() Fa

Re: [Python-Dev] PEP 362 Third Revision

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'.islo

Re: [Python-Dev] PEP 362 Third Revision

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() >> T

Re: [Python-Dev] PEP 362 Third Revision

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

Re: [Python-Dev] PEP 362 Third Revision

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

Re: [Python-Dev] PEP 362 Third Revision

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 == 'v

Re: [Python-Dev] PEP 362 Third Revision

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 se

Re: [Python-Dev] PEP 362 Third Revision

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 d

Re: [Python-Dev] PEP 362 Third Revision

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

Re: [Python-Dev] PEP 362 Third Revision

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

Re: [Python-Dev] PEP 362 Third Revision

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 desc

Re: [Python-Dev] PEP 362 Third Revision

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

Re: [Python-Dev] PEP 362 Third Revision

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 si

Re: [Python-Dev] PEP 362 Third Revision

+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' attribut

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

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 g

Re: [Python-Dev] PEP 362 Third Revision

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

Re: [Python-Dev] PEP 362 Third Revision

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 an

Re: [Python-Dev] PEP 362 Third Revision

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 n

Re: [Python-Dev] PEP 362 Third Revision

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

Re: [Python-Dev] PEP 362 Third Revision

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

Re: [Python-Dev] PEP 362 Third Revision

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: 'pos

Re: [Python-Dev] PEP 362 Third Revision

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

Re: [Python-Dev] PEP 362 Third Revision

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: 'posi

Re: [Python-Dev] PEP 362 Third Revision

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 'posit

Re: [Python-Dev] PEP 362 Third Revision

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

Re: [Python-Dev] PEP 362 Third Revision

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", "v

Re: [Python-Dev] PEP 362 Third Revision

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' attr

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

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

Re: [Python-Dev] PEP 362 Third Revision

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 ___

Re: [Python-Dev] PEP 362 Third Revision

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

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

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

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

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:

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

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

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

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 collis

Re: [Python-Dev] PEP 362 Third Revision

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 d

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

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

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

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 ca

[Python-Dev] PyPI down?

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

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

Re: [Python-Dev] PEP 362 Third Revision

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 Cogh

Re: [Python-Dev] PEP 362 Third Revision

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 a

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

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

Re: [Python-Dev] PEP 362 Third Revision

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@py

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

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 require

Re: [Python-Dev] PEP 362 Third Revision

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.parti

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

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

[Python-Dev] deprecating .pyo and -O

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 (n

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

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

Re: [Python-Dev] PEP 362 Third Revision

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