On Sun, Jul 15, 2012 at 8:08 AM, Mark Shannon m...@hotpy.org wrote:
Brett Cannon wrote:
On Sun, Jul 15, 2012 at 10:39 AM, Mark Shannon m...@hotpy.org
mailto:m...@hotpy.org wrote:
Nick Coghlan wrote:
Right, I agree on the value in being able to return something to
say
On Sat, Jul 14, 2012 at 4:21 PM, Alex Gaynor alex.gay...@gmail.com wrote:
On Sat, Jul 14, 2012 at 4:18 PM, Benjamin Peterson benja...@python.org
wrote:
2012/7/14 Alex Gaynor alex.gay...@gmail.com:
Proposal
This PEP proposes formally documenting ``__length_hint__`` for
On Fri, Jun 15, 2012 at 9:52 AM, Benjamin Peterson benja...@python.org wrote:
2012/6/15 Larry Hastings la...@hastings.org:
If I understand you correctly, you seem to be trying to apply
is_implemented to the problem of predicting which specific inputs to a
parameter would be valid. I don't
-1 implemented
It appears to target the problem of platform-dependent parameters.
However as was discussed previously, much more common than a parameter
simply not being supported on a platform is a parameter supporting
different values on different platforms. As such, I think that it
solves too
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
+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 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
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
--
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
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
On Wed, Jun 13, 2012 at 8: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,
'functools.partials', and callable objects. If a callable
On Tue, Jun 12, 2012 at 11:41 AM, Ethan Furman et...@stoneleaf.us wrote:
Terry Reedy wrote:
http://bugs.python.org/issue12982
Currently, cpython requires the -O flag to *read* .pyo files as well as
the write them. This is a nuisance to people who receive them from others,
without the
On Sun, Jun 10, 2012 at 11:13 PM, Benjamin Peterson benja...@python.org wrote:
2012/6/10 Alexandre Zani alexandre.z...@gmail.com:
I prefer the flags. Flags means I can just look at the Parameter
object. A type or kind or whatever means I need to compare to a
bunch of constants. That's more
On Sun, Jun 10, 2012 at 1:27 PM, Benjamin Peterson benja...@python.org wrote:
2012/6/10 Larry Hastings la...@hastings.org:
Can you make a more concrete suggestion? type strikes me as a poor choice
of name, as it makes one think immediately of type(), which is another, uh,
variety of type.
A comment on the way methods are handled. I have seen decorators that
do something like this:
import functools
def dec(f):
functools.wraps(f)
def decorated(*args, *kwargs):
cursor = databaseCursor()
return f(cursor, *args, **kwargs)
As a result, if the decorated function
On Thu, Jun 7, 2012 at 9:41 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Jun 8, 2012 at 2:20 PM, Alexandre Zani alexandre.z...@gmail.com
wrote:
A comment on the way methods are handled. I have seen decorators that
do something like this:
import functools
def dec(f
A question regarding the name. I have often seen the following pattern
in decorators:
def decor(f):
def some_func(a,b):
do_stuff using f
some_func.__name__ = f.__name__
return some_func
What are the name and fully qualified names in the signature for the
returned function?
On Tue, Jun 5, 2012 at 11:26 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le 05/06/2012 19:21, Alexander Belopolsky a écrit :
with timezone.utc added to datetime module
already the cost of supplying tzinfo to UTC datetime objects is low.
This is nice when your datetime objects are freshly
Good point.
On Tue, Jun 5, 2012 at 12:17 PM, Guido van Rossum gu...@python.org wrote:
On Tue, Jun 5, 2012 at 12:15 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Jun 5, 2012 at 3:01 PM, Antoine Pitrou solip...@pitrou.net wrote:
You could say the same about equally
20 matches
Mail list logo
