On Jun 14, 2012 2:31 PM, Alexandre Zani alexandre.z...@gmail.com 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?
On Wed, Jun 13, 2012 at 9:13 PM, R. David Murray rdmur...@bitdance.comwrote:
On Wed, 13 Jun 2012 20:46:50 +0200, Antoine Pitrou solip...@pitrou.net
wrote:
On Wed, 13 Jun 2012 11:20:24 -0700
Toshio Kuratomi a.bad...@gmail.com wrote:
On Wed, Jun 13, 2012 at 01:58:10PM -0400, R. David
On Wed, 13 Jun 2012 12:36:55 -0700
Ethan Furman et...@stoneleaf.us 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
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
On 2012-06-14, at 12:17 AM, Nick Coghlan wrote:
On Thu, Jun 14, 2012 at 1:06 PM, Yury Selivanov yseliva...@gmail.com 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,
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
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
On 14 June 2012 11:25, Antoine Pitrou solip...@pitrou.net 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?
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
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 yseliva...@gmail.com wrote:
On 2012-06-14, at
On Thu, 14 Jun 2012 12:58:16 +0100
Floris Bruynooghe f...@devork.be wrote:
On 14 June 2012 11:25, Antoine Pitrou solip...@pitrou.net 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
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
On Thu, 14 Jun 2012 14:14:54 +0200, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 14 Jun 2012 12:58:16 +0100
Floris Bruynooghe f...@devork.be wrote:
On 14 June 2012 11:25, Antoine Pitrou solip...@pitrou.net wrote:
Honestly, I think the best option would be to deprecate .pyo files as
On Thu, 14 Jun 2012 09:14:59 -0400
R. David Murray rdmur...@bitdance.com 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
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
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
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 sandro.t...@gmail.com
date:Wed Jun 13 23:58:35 2012 +0200
summary:
Issue #15060: fix
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 Tosisandro.t...@gmail.com
date:Wed Jun 13 23:58:35
On Thu, 14 Jun 2012 16:15:41 +0200, Georg Brandl g.bra...@gmx.net 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
On Thu, Jun 14, 2012 at 6:50 AM, Yury Selivanov yselivanov...@gmail.com 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
Thanks. :)
On Thu, Jun 14, 2012 at 4:50 AM, Yury Selivanov yseliva...@gmail.com 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,
-
On Wed, Jun 13, 2012 at 10:47 PM, R. David Murray rdmur...@bitdance.comwrote:
On Thu, 14 Jun 2012 11:48:08 +1000, Nick Coghlan ncogh...@gmail.com
wrote:
On Thu, Jun 14, 2012 at 6:06 AM, Terry Reedy tjre...@udel.edu wrote:
On 6/13/2012 2:46 PM, Antoine Pitrou wrote:
Not only
On 2012-06-14, at 10:50 AM, Alexandre Zani wrote:
On Thu, Jun 14, 2012 at 6:50 AM, Yury Selivanov yselivanov...@gmail.com
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
On Thu, 14 Jun 2012 07:50:42 -0700, Alexandre Zani alexandre.z...@gmail.com
wrote:
On Thu, Jun 14, 2012 at 6:50 AM, Yury Selivanov yselivanov...@gmail.com
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?
On 14 June 2012 15:50, Alexandre Zani alexandre.z...@gmail.com 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
On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov yselivanov...@gmail.comwrote:
[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'.
Brett Cannon wrote:
On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov yselivanov...@gmail.com
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
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
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 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
2012/6/14 Yury Selivanov 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 yselivanov...@gmail.com
wrote:
[SNIP]
Let's consider replacement of 'Parameter.is_*' set of attributes with
a single 'Parameter.kind'
On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote:
2012/6/14 Yury Selivanov 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 yselivanov...@gmail.com
wrote:
[SNIP]
Let's consider replacement of 'Parameter.is_*'
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
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.
On Thu, Jun 14, 2012 at 12:39 PM, Yury Selivanov yselivanov...@gmail.comwrote:
On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote:
2012/6/14 Yury Selivanov 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
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
+1
On Thu, Jun 14, 2012 at 9:16 AM, Yury Selivanov yselivanov...@gmail.com wrote:
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
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
On 6/14/2012 1:10 PM, Brett Cannon wrote:
On Thu, Jun 14, 2012 at 12:39 PM, Yury Selivanov
yselivanov...@gmail.com mailto:yselivanov...@gmail.com wrote:
On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote:
2012/6/14 Yury Selivanov yselivanov...@gmail.com
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
On Thu, Jun 14, 2012 at 9:06 AM, R. David Murray rdmur...@bitdance.com 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
On Thu, Jun 14, 2012 at 10:10 AM, Brett Cannon br...@python.org wrote:
On Thu, Jun 14, 2012 at 12:39 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote:
2012/6/14 Yury Selivanov yselivanov...@gmail.com:
On 2012-06-14, at 11:24 AM, Brett
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
On Thu, 14 Jun 2012 09:32:59 -0700
Benjamin Peterson benja...@python.org 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
Antoine Pitrou wrote:
On Thu, 14 Jun 2012 09:32:59 -0700
Benjamin Peterson benja...@python.org 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):
On Thu, 14 Jun 2012 12:46:38 -0700
Ethan Furman et...@stoneleaf.us 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
2012/6/14 Ethan Furman et...@stoneleaf.us:
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
On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 14 Jun 2012 12:46:38 -0700
Ethan Furman et...@stoneleaf.us wrote:
This is no different from what we have with strings now:
-- 'aA'.islower()
False
-- 'aA'.isupper()
False
-- 'a'.islower()
True
--
2012/6/14 Alexandre Zani alexandre.z...@gmail.com:
On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 14 Jun 2012 12:46:38 -0700
Ethan Furman et...@stoneleaf.us wrote:
This is no different from what we have with strings now:
-- 'aA'.islower()
False
--
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
On Thu, 14 Jun 2012 21:57:34 +0200, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 14 Jun 2012 12:46:38 -0700
Ethan Furman et...@stoneleaf.us wrote:
This is no different from what we have with strings now:
-- 'aA'.islower()
False
-- 'aA'.isupper()
False
-- 'a'.islower()
Floris Bruynooghe wrote:
On 14 June 2012 11:25, Antoine Pitrou solip...@pitrou.net 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
On 2012-06-14, at 4:24 PM, Benjamin Peterson wrote:
2012/6/14 Alexandre Zani alexandre.z...@gmail.com:
On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 14 Jun 2012 12:46:38 -0700
Ethan Furman et...@stoneleaf.us wrote:
This is no different from what we
On Fri, 15 Jun 2012 06:38:45 +1000
Steven D'Aprano st...@pearwood.info 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
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
On Wed, 13 Jun 2012 22:52:43 -0400
Yury Selivanov yselivanov...@gmail.com 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
On Thu, Jun 14, 2012 at 1:45 PM, Yury Selivanov yselivanov...@gmail.com wrote:
On 2012-06-14, at 4:24 PM, Benjamin Peterson wrote:
2012/6/14 Alexandre Zani alexandre.z...@gmail.com:
On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou solip...@pitrou.net
wrote:
On Thu, 14 Jun 2012 12:46:38
2012/6/14 Alexandre Zani alexandre.z...@gmail.com:
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
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:
On Thu, Jun 14, 2012 at 2:00 PM, Benjamin Peterson benja...@python.org wrote:
2012/6/14 Alexandre Zani alexandre.z...@gmail.com:
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
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
Note: I'm no-mail on python-dev
- Forwarded message from Sean Johnson seanjohnso...@gmail.com -
Date: Thu, 14 Jun 2012 03:48:55 -0400
From: Sean Johnson seanjohnso...@gmail.com
To: webmas...@python.org
Subject: Windows 3.2.3 64 bit installers are actually 3.2
The installers on
On 2012-06-14, at 4:53 PM, Antoine Pitrou wrote:
On Wed, 13 Jun 2012 22:52:43 -0400
Yury Selivanov yselivanov...@gmail.com wrote:
* bind(\*args, \*\*kwargs) - BoundArguments
Creates a mapping from positional and keyword arguments to
parameters. Raises a ``BindError`` (subclass of
On Thu, Jun 14, 2012 at 4:12 PM, Aahz a...@pythoncraft.com wrote:
Note: I'm no-mail on python-dev
- Forwarded message from Sean Johnson seanjohnso...@gmail.com -
Date: Thu, 14 Jun 2012 03:48:55 -0400
From: Sean Johnson seanjohnso...@gmail.com
To: webmas...@python.org
Subject:
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
2012/6/14 Nick Coghlan ncogh...@gmail.com:
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
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
On Jun 15, 2012 8:37 AM, Benjamin Peterson benja...@python.org wrote:
2012/6/14 Nick Coghlan ncogh...@gmail.com:
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
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
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
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
2012/6/14 Larry Hastings la...@hastings.org:
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
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
2012/6/14 Larry Hastings la...@hastings.org:
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
On Fri, Jun 15, 2012 at 11:37 AM, Yury Selivanov
yselivanov...@gmail.com 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
On Fri, Jun 15, 2012 at 1:20 PM, Benjamin Peterson benja...@python.org wrote:
2012/6/14 Larry Hastings la...@hastings.org:
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
On 06/14/2012 08:20 PM, Benjamin Peterson wrote:
2012/6/14 Larry Hastingsla...@hastings.org:
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
On 06/14/2012 08:41 PM, Nick Coghlan wrote:
On Fri, Jun 15, 2012 at 1:20 PM, Benjamin Petersonbenja...@python.org wrote:
2012/6/14 Larry Hastingsla...@hastings.org:
Also, it's more granular than that. For example, Python now understands
symbolic links on Windows--but only haphazardly at
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
78 matches
Mail list logo
