MRAB pyt...@mrabarnett.plus.com writes:
datetime objects would consist of the UTC time, time zone and DST.
“time zone” information always entails DST information doesn't it? It
isn't proper time zone information if it doesn't tell you about DST.
That is, when you know the full time zone
On Wed, Jun 6, 2012 at 12:51 PM, Yury Selivanov yselivanov...@gmail.com wrote:
As for moving Signature object to `functools`, we had this discussion with
Brett, and here is what he suggested:
Functools contains code that transforms what a function
does while inspect is about
On Wed, Jun 6, 2012 at 1:48 PM, PJ Eby p...@telecommunity.com wrote:
On Tue, Jun 5, 2012 at 8:14 PM, Nick Coghlan ncogh...@gmail.com wrote:
On reflection, I'm actually inclined to agree. The next version of the
PEP will propose the addition of type.__decorate__(). This new method
will be
On Wed, Jun 6, 2012 at 1:28 AM, PJ Eby p...@telecommunity.com wrote:
To be clear, what I specifically proposed (as I mentioned in an earlier
thread) was simply to patch __build_class__ in order to restore the missing
__metaclass__ hook. (Which, incidentally, would make ALL code using
Ben Finney ben+pyt...@benfinney.id.au writes:
Georg Brandl g.bra...@gmx.net writes:
list of possible features for 3.3 as specified by PEP 398:
Candidate PEPs:
[…]
* PEP 3143: Standard daemon process library
Our porting work will not be done in time for Python 3.3. I will update
On Wed, Jun 6, 2012 at 5:09 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Jun 6, 2012 at 1:28 AM, PJ Eby p...@telecommunity.com wrote:
To be clear, what I specifically proposed (as I mentioned in an earlier
thread) was simply to patch __build_class__ in order to restore the missing
Just to add my 2 cents to this discussion as someone who's worked
with mxDateTime for almost 15 years.
I think we all agree that users of an application want to input
date/time data using their local time (which may very well not be
the timezone of the system running the application). On output
Hello all,
I'm wondering whether this is the appropriate place to discuss
(global) static type analysis, a topic Guido mentioned around the 28
min mark in his PyCon 2012 keynote,
http://pyvideo.org/video/956/keynote-guido-van-rossum
This is a topic that has interested me for a long time, and it
On Wed, 6 Jun 2012, Nick Coghlan wrote:
2. Signature.bind introduces the ability to split the bind arguments
to parameters operation from the call object operation
Has anybody considered calling bind __call__? That is, the result of
calling the signature of a procedure instead of the
On 2012-06-06, at 9:28 AM, Isaac Morland wrote:
On Wed, 6 Jun 2012, Nick Coghlan wrote:
2. Signature.bind introduces the ability to split the bind arguments
to parameters operation from the call object operation
Has anybody considered calling bind __call__? That is, the result of calling
On 2012-06-06, at 2:48 AM, Nick Coghlan wrote:
However, looking at the code, I think the split that makes sense is
for a lower level functools.signature to *only* support real function
objects (i.e. not even method objects).
At the inspect layer, inspect.signature could then support
On Jun 06, 2012, at 05:55 PM, Ben Finney wrote:
The PEP document currently says it targets “3.x”. I'll leave it in that
state until we're more confident that the current work will be on track
for a particular Python release.
Do I need to do anything in particular to be explicit that PEP 3143 is
Brett Cannon wrote:
PEP: 362
Title: Function Signature Object
Version: $Revision$
Last-Modified: $Date$
Author: Brett Cannon br...@python.org, Jiwon Seo seoji...@gmail.com,
Yury Selivanov yseliva...@sprymix.com, Larry Hastings
la...@hastings.org
Status: Draft
Type: Standards Track
On Wed, Jun 6, 2012 at 5:31 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Jun 6, 2012 at 5:09 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Jun 6, 2012 at 1:28 AM, PJ Eby p...@telecommunity.com wrote:
To be clear, what I specifically proposed (as I mentioned in an earlier
thread)
Steven D'Aprano wrote:
Brett Cannon wrote:
PEP: 362
Title: Function Signature Object
Version: $Revision$
Last-Modified: $Date$
Author: Brett Cannon br...@python.org, Jiwon Seo seoji...@gmail.com,
Yury Selivanov yseliva...@sprymix.com, Larry Hastings
la...@hastings.org
Status: Draft
On 06/06/2012 08:38 AM, Steven D'Aprano wrote:
What's the fully qualified name of the function, and why is it needed?
Please see PEP 3155.
args is just a common name for the parameter, not for the kind of
parameter. *args (or *data, *whatever) is a varargs parameter, and so
the attribute
Steven,
On 2012-06-06, at 11:38 AM, Steven D'Aprano wrote:
Brett Cannon wrote:
Python has always supported powerful introspection capabilities,
including introspecting functions and methods. (For the rest of
this PEP, function refers to both functions and methods). By
examining a function
On 06/06/2012 09:05 AM, Larry Hastings wrote:
Is there a use-case for is_implemented?
Yes, see issue 14626.
I should add, there are already some places in the standard library
where is_implemented would be relevant. The mode argument to os.mkdir
comes immediately to mind; on Windows it
On Wed, Jun 6, 2012 at 10:20 AM, Yury Selivanov yselivanov...@gmail.com wrote:
On 2012-06-06, at 11:38 AM, Steven D'Aprano wrote:
Functions already record their name (twice!), and it is simple enough to
query func.__name__. What reason is there for recording it a third time, in
the Signature
Larry Hastings wrote:
[...]
Changes to the Signature object, or to any of its data members,
do not affect the function itself.
which leaves the possibility that __signature__ may no longer match
the actual argument spec, for some reason. If you remove
getfullargspec, people will have to
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?
Eric,
On 2012-06-06, at 1:02 PM, Eric Snow wrote:
On Wed, Jun 6, 2012 at 10:20 AM, Yury Selivanov yselivanov...@gmail.com
wrote:
On 2012-06-06, at 11:38 AM, Steven D'Aprano wrote:
Functions already record their name (twice!), and it is simple enough to
query func.__name__. What reason is
On Wed, Jun 6, 2012 at 12:16 PM, Steven D'Aprano st...@pearwood.infowrote:
Larry Hastings wrote:
[...]
Changes to the Signature object, or to any of its data members,
do not affect the function itself.
which leaves the possibility that __signature__ may no longer match the
actual
On 06/06/2012 09:16 AM, Steven D'Aprano wrote:
Nevertheless, the world is full of doorknobs, and people will have to
deal with their code.
I'm having a hard time seeing it. Can you propose a credible situation
where
* some programmer would have a reason (even a bad reason) to modify
On 2012-06-06, at 1:13 PM, Alexandre Zani wrote:
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
BoundArguments Object
=
Result of a ``Signature.bind`` call. Holds the mapping of arguments
to the function's parameters.
The Signature.bind function has changed since the previous version of
the PEP. If I understand correctly, the 'arguments' attribute is the
same as
Sorry I missed answering these on my first pass.
On 06/06/2012 08:38 AM, Steven D'Aprano wrote:
What to do about parameters which are partly implemented? E.g.
mode='spam' is implemented but mode='ham' is not.
Parameter objects aren't sophisticated enough to represent such a
situation. If
Daniel,
On 2012-06-06, at 1:39 PM, Daniel Urban wrote:
BoundArguments Object
=
Result of a ``Signature.bind`` call. Holds the mapping of arguments
to the function's parameters.
The Signature.bind function has changed since the previous version of
the PEP. If I
BoundArguments Object
=
Result of a ``Signature.bind`` call. Holds the mapping of arguments
to the function's parameters.
The Signature.bind function has changed since the previous version of
the PEP. If I understand correctly, the 'arguments' attribute is the
same as
On 2012-06-06, at 2:22 PM, Daniel Urban wrote:
I'll try to answer you with the following code:
def foo(*args):
...print(args)
bound_args = signature(foo).bind(1, 2, 3)
bound_args.arguments
OrderedDict([('args', (1, 2, 3))])
You can't invoke 'foo' by:
On 6/6/2012 7:40 AM, nick.coghlan wrote:
PEP 422 rewrite to present an idea that a) isn't crazy and
b) it turns out Thomas Heller proposed back in 2001
+There is currently no corresponding mechanism in Python 3 that allows the
+code executed in the class body to directly influence how
On Wed, Jun 6, 2012 at 8:35 PM, Yury Selivanov yselivanov...@gmail.com wrote:
On 2012-06-06, at 2:22 PM, Daniel Urban wrote:
I'll try to answer you with the following code:
def foo(*args):
... print(args)
bound_args = signature(foo).bind(1, 2, 3)
bound_args.arguments
On 2012-06-06, at 3:33 PM, Daniel Urban wrote:
On Wed, Jun 6, 2012 at 8:35 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
On 2012-06-06, at 2:22 PM, Daniel Urban wrote:
I'll try to answer you with the following code:
def foo(*args):
...print(args)
bound_args =
On Jun 7, 2012 3:11 AM, Steven Dapos;Aprano st...@pearwood.info wrote:
Larry Hastings wrote:
[...]
Changes to the Signature object, or to any of its data members,
do not affect the function itself.
which leaves the possibility that __signature__ may no longer match the
actual argument
On Jun 7, 2012 12:20 AM, Yury Selivanov yselivanov...@gmail.com wrote:
I agree, that we shouldn't make 'functools' be dependent on 'inspect'
module.
Moreover, this is not even currently possible, as it creates an
import-loop
that is hard to untie. But how about the following:
1. Separate
+1 on the PEP. FWIW, it may be useful to note that not only has the
pattern of having a class-level init been proposed before, it's actually
used: Zope has had __class_init__ and used it as a metaclass alternative
since well before Thomas Heller's proposal.
And in my case, about 80% of my
On 6/6/2012 7:24 AM, Edward K. Ream wrote:
Hello all,
I'm wondering whether this is the appropriate place to discuss
(global) static type analysis, a topic Guido mentioned around the 28
min mark in his PyCon 2012 keynote,
http://pyvideo.org/video/956/keynote-guido-van-rossum
I think either
On Wed, Jun 6, 2012 at 5:40 AM, nick.coghlan python-check...@python.org wrote:
+
+Alternatives
+
+
Would it be worth also (briefly) rehashing why the class instance
couldn't be created before the class body is executed*? It might seem
like a viable alternative if you haven't
Yury Selivanov wrote:
I like the idea of 'foo(a)' and 'bar(a)' having the identical signatures,
however, I don't think it's possible. I.e. we can't make it that the
'signature(foo) is signature(bar)'. We can implement the __eq__ operator
though.
+1 to __eq__.
I don't think we should care
Larry Hastings wrote:
inspect.getfullargspec is currently unable to introspect builtin
functions and methods. Should builtins gain a __signature__ so they
can be introspected?
If function signatures are useful, then they're useful, and the
implementation language for the function is
Brett Cannon wrote:
On Wed, Jun 6, 2012 at 12:16 PM, Steven D'Aprano st...@pearwood.infowrote:
Larry Hastings wrote:
[...]
Changes to the Signature object, or to any of its data members,
do not affect the function itself.
which leaves the possibility that __signature__ may no longer match
On Wed, Jun 6, 2012 at 6:07 PM, Eric Snow ericsnowcurren...@gmail.comwrote:
On Wed, Jun 6, 2012 at 5:40 AM, nick.coghlan python-check...@python.org
wrote:
+
+Alternatives
+
+
Would it be worth also (briefly) rehashing why the class instance
couldn't be created before the
On 6/6/2012 6:38 PM, Steven D'Aprano wrote:
redundant. Even so, getfullargspec is not doing any harm. We're not
*adding* complexity, it's already there, and breaking currently working
code by deprecating and then removing it is not a step we should take
lightly. API churn is itself a cost.
Yury Selivanov wrote:
We can implement the __eq__ operator though.
+1
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Wed, Jun 6, 2012 at 12:35 AM, Terry Reedy tjre...@udel.edu wrote:
On 6/5/2012 4:24 PM, Tarek Sheasha wrote:
Hello,
I have been working for a long time on cross-compiling python for
android I have used projects like:
http://code.google.com/p/android-python27/
I am stuck in a certain
On Thu, Jun 7, 2012 at 8:38 AM, Steven D'Aprano st...@pearwood.info wrote:
Brett Cannon wrote:
This is also Python, the language that assumes everyone is an consenting
adult.
Exactly, which is why I'm not asking for __signature__ to be immutable. Who
knows, despite Larry's skepticism (and
On Wed, Jun 6, 2012 at 11:28 AM, Yury Selivanov yselivanov...@gmail.com wrote:
Never copy attributes by hand, always use 'functools.wraps'. It copies
'__name__', '__qualname__', and bunch of other attributes to the decorator
object.
We'll probably extend it to copy __signature__ too; then
On Thu, Jun 7, 2012 at 10:52 AM, Eric Snow ericsnowcurren...@gmail.com wrote:
Furthermore, using __signature__ as a cache may even cause problems.
If the Signature object is cached then any changes to the function
will not be reflected in the Signature object. Certainly that's an
unlikely
On 2012-06-06, at 9:00 PM, Nick Coghlan wrote:
On Thu, Jun 7, 2012 at 10:52 AM, Eric Snow ericsnowcurren...@gmail.com
wrote:
Furthermore, using __signature__ as a cache may even cause problems.
If the Signature object is cached then any changes to the function
will not be reflected in the
On Wed, Jun 6, 2012 at 10:10 PM, Yury Selivanov yselivanov...@gmail.com wrote:
On 2012-06-06, at 3:33 PM, Daniel Urban wrote:
On Wed, Jun 6, 2012 at 8:35 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
On 2012-06-06, at 2:22 PM, Daniel Urban wrote:
I'll try to answer you with the following
50 matches
Mail list logo
