On 2012-06-14, at 11:21 PM, Nick Coghlan wrote:
> 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
>>> KEYWOR
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
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 ``BindEr
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
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
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
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&#x
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 hav
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_*&#
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
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
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, meth
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__'
ersion: $Revision$
Last-Modified: $Date$
Author: Brett Cannon , Jiwon Seo ,
Yury Selivanov , Larry Hastings
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 21-Aug-2006
Python-Version: 3.3
Post-History: 04-Jun-2012
Abstract
Python has always supported power
Nick,
I'm replying to your email (re 'functools.partial') in python-ideas here,
in the PEP 362 thread, as my response raises some questions regarding its
design.
> On 2012-06-07, at 11:40 PM, Nick Coghlan wrote:
>> On Fri, Jun 8, 2012 at 12:57 PM, Yury Selivan
On 2012-06-07, at 8:40 PM, R. David Murray wrote:
> IMO the __repr__ should make it clear that it is a signature object
> somehow.
+1.
-
Yury
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
On 2012-06-07, at 5:39 PM, Terry Reedy wrote:
> On 6/7/2012 4:54 PM, Yury Selivanov wrote:
>
>> I think we'll add a 'format' method to the Signature, that will work
>> like 'inspect.formatargspec'. 'Signature.__str__' will use it with
>
On 2012-06-07, at 3:54 PM, Terry Reedy wrote:
> On 6/7/2012 10:41 AM, Yury Selivanov wrote:
>> Hello,
>>
>> The new revision of PEP 362 has been posted:
>> http://www.python.org/dev/peps/pep-0362/
>>
>> Thanks to Brett, Larry, Nick, and everybody els
Eric,
On 2012-06-07, at 12:54 PM, Eric Snow wrote:
> On Wed, Jun 6, 2012 at 11:10 AM, 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
On 2012-06-07, at 10:45 AM, R. David Murray wrote:
> On Thu, 07 Jun 2012 07:00:29 -0700, Larry Hastings wrote:
>> On 06/06/2012 11:56 PM, Nick Coghlan wrote:
>>> I'd say return a copy in the first case to be safe against accidental
>>> modification. If someone actually wants in-place modification,
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Thanks to Brett, Larry, Nick, and everybody else on python-dev
for your corrections/suggestions.
Summary of changes:
1. We don't cache signatures in __signature__ attribute implicitly
2. signature() f
Nick,
On 2012-06-07, at 2:56 AM, Nick Coghlan wrote:
> On Thu, Jun 7, 2012 at 11:16 AM, Yury Selivanov
> wrote:
>> On 2012-06-06, at 9:00 PM, Nick Coghlan wrote:
>> So, the idea for the 'signature(obj)' function is to first check if
>> 'obj' has '
On 2012-06-07, at 9:28 AM, Michael Foord wrote:
> On 6 Jun 2012, at 18:28, Yury Selivanov wrote:
>> On 2012-06-06, at 1:13 PM, Alexandre Zani wrote:
>> Never copy attributes by hand, always use 'functools.wraps'. It copies
>> '__name__', '__qua
On 2012-06-06, at 9:00 PM, Nick Coghlan wrote:
> On Thu, Jun 7, 2012 at 10:52 AM, Eric Snow
> 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. Cer
On 2012-06-06, at 3:33 PM, Daniel Urban wrote:
> On Wed, Jun 6, 2012 at 8:35 PM, Yury Selivanov
> wrote:
>> On 2012-06-06, at 2:22 PM, Daniel Urban wrote:
>>>> I'll try to answer you with the following code:
>>>>
>>>> >>> def foo
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
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 PE
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 full
Eric,
On 2012-06-06, at 1:02 PM, Eric Snow wrote:
> On Wed, Jun 6, 2012 at 10:20 AM, Yury Selivanov
> 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
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
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 retr
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
Nick,
On 2012-06-05, at 9:45 PM, Nick Coghlan wrote:
> Specific proposals:
>
> - the goals of the PEP be expanded to include error checking of
> parameter binding for delayed calls and improve introspection of
> function wrappers that accept arbitrary arguments, rather than the
> more nebulous "i
On 2012-05-02, at 2:46 AM, Larry Hastings wrote:
> On 05/01/2012 01:12 PM, Brett Cannon wrote:
>> That would be great! First thing is addressing Guido's concerns from
>> http://mail.python.org/pipermail/python-dev/2012-March/117515.html and then
>> handling any issues you found. Not sure if Larr
On 2012-05-01, at 4:12 PM, Brett Cannon wrote:
>
> That would be great! First thing is addressing Guido's concerns from
> http://mail.python.org/pipermail/python-dev/2012-March/117515.html and then
> handling any issues you found. Not sure if Larry was asking about this out of
> curiosity or be
On 2012-05-01, at 7:57 AM, Georg Brandl wrote:
> With 3.3a3 tagged and the beta stage currently 2 months away, I would like
> to draw your attention to the following list of possible features for 3.3
> as specified by PEP 398:
>
> Candidate PEPs:
>
> * PEP 362: Function Signature Object
Regardi
On 2012-04-03, at 9:28 PM, Victor Stinner wrote:
> In the last version of my PEP, time.monotonic() is simply defined as "a
> monotonic clock (cannot go backward)". There is no more "... best ..." in its
> definition.
I like the last version of the PEP ;)
-
Yury
On 2012-04-03, at 8:33 PM, Steven D'Aprano wrote:
> 1) the os module should expose lightweight wrappers around whatever clocks
> the operating system provides;
+1. That should make it flexible enough to those who really need it.
> 2) the time module should NOT provide any further clocks other
On 2012-03-30, at 3:40 PM, Guido van Rossum wrote:
> I still think the name "monotonic" give the wrong impression; I would
> be happy calling it steady.
Simple google search comparison shows that people ask about 'monotonic'
clock in python, not 'steady'.
How about following Nick's (if I recall
On 2012-03-28, at 1:55 PM, Yury Selivanov wrote:
> nonlocal _time
nonlocal _tick
obviously.
P.S. And we can make it to raise an error after some N calls
to time() resulting in lesser time that is stored in the _tick
variable.
-
Yury
___
Python-
On 2012-03-28, at 11:35 AM, Nick Coghlan wrote:
> So, the primary use case is that we want to replace many of the
> time.time() calls in the standard library with time.monotonic() calls.
> To avoid backwards compatibility problems in the cross-platform
> support, that means time.monotonic() *must b
On 2012-03-28, at 10:45 AM, Nick Coghlan wrote:
> On Thu, Mar 29, 2012 at 12:27 AM, Yury Selivanov
> wrote:
>> What if system time jumps 1 year back? We'll have the same
>> monotonic time returned for this whole year?
>>
>> I don't think we sh
On 2012-03-28, at 10:36 AM, Nick Coghlan wrote:
> Monotonicity is fairly easy to guarantee - you just remember the last
> value you returned and ensure you never return a lower value than that
> for the lifetime of the process.
As I said in my previous mail - I don't think we should ever do that.
On 2012-03-28, at 10:17 AM, Nick Coghlan wrote:
> def _make_monotic:
> try:
> # Use underlying system monotonic clock if we can
> return _monotonic
> except NameError:
> _tick = time()
> def monotic():
> _new_tick = time()
>
On 2012-03-27, at 9:23 AM, Nick Coghlan wrote:
> time.try_monotonic() # Monotonic is preferred, but non-monotonic
> presents a tolerable risk
This function seems unnecessary. It's easy to implement it when
required in your application, hence I don't think it is worth
adding to the stdlib.
-
Yur
On 2012-03-23, at 7:25 PM, Victor Stinner wrote:
> - time.steady(): monotonic clock or the realtime clock, depending on
> what is available on the platform (use monotonic in priority). may be
> adjusted by NTP or the system administrator, may go backward.
>
> time.steady() is something like:
>
>
On 2012-03-23, at 7:28 PM, Brian Curtin wrote:
> This seems like it should have been a PEP, or maybe should become a PEP.
Why? AFAIK Victor just proposes to add two new functions: monotonic() and
steady().
time() and clock() do already exist and won't be changed.
-
Yury
On 2012-03-23, at 7:07 PM, Victor Stinner wrote:
> 2012/3/23 Yury Selivanov :
>> Why can't I use select & threads? You mean that if a platform does not
>> support monotonic clocks it also does not support threads and select sys
>> call?
>
> Python 3.3 now u
On 2012-03-23, at 1:27 PM, Victor Stinner wrote:
>> I want time.steady(strict=True), and I'm glad you're providing it and
>> I'm willing to use it this way, although it is slightly annoying
>> because "time.steady(strict=True)" really means
>> "time.steady(i_really_mean_it=True)". Else, I would ha
On 2012-03-23, at 4:40 PM, Glyph wrote:
> (I still object to the "time.steady" naming, because this is what people in
> the make-believe land of C++ call it. The people who live in the real world
> of C and POSIX all refer to it as "monotonic". And even the C++ purists slip
> up sometimes, c.f
On 2012-03-21, at 11:06 AM, Łukasz Rekucki wrote:
> FYI, the current paragraph font size on docs.python.org is 16px, while
> for http://www.python.org/~gbrandl/build/html/ it's 13px, so
> increasing that should help readability :) You can use @media queries
> to adjust it to screen resolution, whic
Well, I really hope that the PEP regarding frozendict will be accepted.
Especially due to the fact that the required changes are small.
With the recent projects like clojure-py, blog posts like
http://goo.gl/bFB5x (Python becomes a platform), your pysandbox,
it became clear that people start eval
If we need to decide to which function should be kept - I vote for monotonic.
It's extremely useful (even essential) to track timeouts in various schedulers
implementations, for example. Quick search also shows the demand for it, as
there are questions on stackoverflow.com and few packages on PyP
Guido, Brett,
I've tried to use the proposed signature object, however, I found that
the 'bind' method is incorrect, and came up with my own implementation
of the PEP: https://gist.github.com/2029032 (If needed, I can change
the licence to PSFL) I used my version to implement typechecking,
ar
Actually, I too noticed that you've dropped few crasher tests. I think
we need to keep them, to make sure that future development will not
introduce the same vulnerabilities. That's a common practice with
unit-testing.
On 2012-03-09, at 5:27 PM, Victor Stinner wrote:
> On 09/03/2012 22:32, Jim
On 2012-03-01, at 9:31 PM, Guido van Rossum wrote:
> That sounds *very* far-fetched. You're pretty much designing a new
> language variant. It's not an argument for burdening the original
Yeah, that's what we do ;)
> You should be able to prototype what you want using an advisory
> subclass (if y
On 2012-03-01, at 7:50 PM, Guido van Rossum wrote:
> I think you should provide stronger arguments in each case why the
> data needs to be truly immutable or read-only, rather than just using
> a convention or an "advisory" API (like __private can be circumvented
> but clearly indicates intent to t
On 2012-03-01, at 5:52 PM, Armin Ronacher wrote:
> Hi,
>
> On 3/1/12 10:38 PM, Yury Selivanov wrote:
>> Sorry if I sounded like 'attacking' you. I certainly had no such
>> intention, as I believe nobody on this list.
> Sorry if I sound cranky but I got that im
l review of all porting scenarios with
well-thought set of benchmarks, nobody would ever call your PEP
"polemic".
Thanks,
-
Yury
On 2012-03-01, at 4:12 PM, Armin Ronacher wrote:
> Hi,
>
> On 2/29/12 12:30 PM, Yury Selivanov wrote:
>> I see you've (or somebody) changed:
Vinay,
Thank you for the comprehensive summary. Big +1. I really
do hope that Nick and Armin will rectify the PEP. Otherwise,
many of its points are moot, and we need to raise a question
of rejecting it somehow.
On 2012-03-01, at 2:00 PM, Vinay Sajip wrote:
> Guido van Rossum python.org> wri
Actually I find fronzendict concept quite useful. We also have an
implementation in our framework, and we use it, for instance, in
http request object, for parsed arguments and parsed forms, which
values shouldn't be ever modified once parsed.
Of course everybody can live without it, but given th
place to put such polemic
and biased statements. Nobody asked you to express your *personal*
feelings and thoughts about applicability or state of python3 in the
PEP. There are blogs for that.
Thank you.
-
Yury
On 2012-02-28, at 11:29 AM, Yury Selivanov wrote:
> Hi Armin,
>
> Could you p
place to put such polemic
and biased statements. Nobody asked you to express your *personal*
feelings and thoughts about applicability or state of python3 in the
PEP. There are blogs for that.
Thank you.
-
Yury
On 2012-02-28, at 11:29 AM, Yury Selivanov wrote:
> Hi Armin,
>
> Could you p
Big +1.
Indeed, this whole Ellipsis approach is just an awful hack.
-
Yury
On 2012-02-26, at 8:30 PM, Benjamin Peterson wrote:
> PEP: 415
> Title: Implementing PEP 409 differently
> Version: $Revision$
> Last-Modified: $Date$
> Author: Benjamin Peterson
> Status: Draft
> Type: Standards Track
Hi Armin,
Could you please remove from the PEP the following statement:
"""As it stands, Python 3 is currently a bad choice for long-term
investments, since the ecosystem is not yet properly developed, and
libraries are still fighting with their API decisions for Python 3."""
While it may be a
Hello Mark,
First, I've back-ported your patch on python 3.2.2 (which was relatively
easy). Almost all tests pass, and those that don't are always failing on
my machine if I remember. The patch can be found here: http://goo.gl/nSzzY
Then, I compared memory footprint of one of our applications (
On 2012-02-03, at 7:23 PM, Terry Reedy wrote:
> On 2/3/2012 9:53 AM, Yury Selivanov wrote:
>> Re "raise ValueError from ..."
>
> The use cases for Ellipsis/... are 99.99% internal. The typical Python
> programmer will never see or have cause to worry about such a thi
#x27;raise from'
statement.
On 2012-02-03, at 2:03 PM, Ethan Furman wrote:
> Yury Selivanov wrote:
>> On 2012-02-03, at 1:20 PM, Guido van Rossum wrote:
>>> Please. Let's stop this. There is no known use case to ever write
>>> that. We're just not putti
On 2012-02-03, at 1:20 PM, Guido van Rossum wrote:
> Please. Let's stop this. There is no known use case to ever write
> that. We're just not putting specific measures to prevent it. Writing
>
a = ...
>
> Is likewise cute but not very informative. But it is valid syntax.
Well, right now you
related singleton in the exception
contexts? Is the policy of "think before adding a new builtin object"
really worth it in this concrete case?
On 2012-02-03, at 1:01 PM, Ethan Furman wrote:
> Yury Selivanov wrote:
>> I got it, and I think it's fine to use explicit __ca
Funny thing, it seems like you don't get it in the same way I did not
in the first place. His example is more like:
try:
try:
raise IndexError()
except:
raise CustomError() from __NoContext__
except CustomError as e:
# nevermind, let's see the whole thing after all
raise e from __
I got it, and I think it's fine to use explicit __cause__ reset,
using Ellipsis, or even some __NoException__ special object if
we decide to introduce one.
I'm against allowing 'from ...' syntax.
On 2012-02-03, at 12:29 PM, Ethan Furman wrote:
> Yury Selivanov wrote:
many of us eagerly want).
I'm -1 on adding 'raise from ...'.
On 2012-02-03, at 11:52 AM, Ethan Furman wrote:
> Yury Selivanov wrote:
>> Re "raise ValueError from ..."
>> So what does it mean now? Just resetting __cause__ to make __context__
>> printed?
Re "raise ValueError from ..."
So what does it mean now? Just resetting __cause__ to make __context__
printed? Can you show the down-to-earth snippet of code where such syntax
would be useful?
Speaking of Zen of Python - I think this stuff contradicts with it more than it
follows.
On 2012-0
In my opinion using Ellipsis is just wrong. It is completely
non-obvious not only to a beginner, but even to an experienced
python developer. Writing 'raise Something() from None'
looks less suspicious, but still strange.
Isn't 'raise Exception().no_context()' or
'raise Exception().no_cause(
Maybe it'd be better to put 'atomic' in the threading module?
On 2011-08-30, at 4:02 PM, Armin Rigo wrote:
> Re-hi,
>
> 2011/8/29 Armin Rigo :
>>> The problem is that many locks are actually acquired implicitely.
>>> For example, `print` to a buffered stream will acquire the fileobject's
>>> mu
On 2010-08-26, at 1:10 PM, Eric Smith wrote:
> On 8/26/10 12:48 PM, Yury Selivanov wrote:
>> On 2010-08-26, at 12:20 PM, Scott Dial wrote:
>>> BTW, attaching patches to
>>> emails on this list is generally the best way to have few look at your
>>> patch. :-p
On 2010-08-26, at 8:25 PM, Guido van Rossum wrote:
> On Thu, Aug 26, 2010 at 5:05 PM, Yury Selivanov wrote:
>> On 2010-08-26, at 8:04 PM, Greg Ewing wrote:
>>> Even with your proposal, you'd still have to use a 'creepy
>>> abstraction' every time one of
On 2010-08-26, at 8:04 PM, Greg Ewing wrote:
> Even with your proposal, you'd still have to use a 'creepy
> abstraction' every time one of your coroutines calls another.
> That's why PEP 380 deals with 'more than just return'.
Nope. In almost any coroutine framework you have a scheduler
or trampo
On 2010-08-26, at 6:11 PM, Nick Coghlan wrote:
> On Fri, Aug 27, 2010 at 1:00 AM, Yury Selivanov wrote:
>> In the above, GeneratorReturn error will be propagated stopping the program
>> execution.
>> Strictly speaking, the proposed change is just alters the current
On 2010-08-26, at 12:20 PM, Scott Dial wrote:
> On 8/26/2010 11:00 AM, Yury Selivanov wrote:
>> If we decide to postpone this feature till Python 3.3, than we'll push it
>> all back
>> The change is tiny, but it means really a lot.
>
> AFAICT, this change was th
Hello,
I want to bring up a "forbidden" topic, however, I believe I have some strong
points.
There are many ways of doing asynchronous programming in Python.
Multiprocessing,
Threads, Greenlets, Deferred Object (Callbacks) and Coroutines. The latter is
quite
a new approach, but it gets mor
> On 2010-08-23, at 10:37 PM, Guido van Rossum wrote:
> Yuri, I think you are making a good case (though I would like for you
> to be a good citizen and use the bug tracker to submit this for
> review). Benjamin, what do you think?
NP, issue #9666 ;-)
-
Yury
__
> On 2010-08-23, at 10:56 AM, Guido van Rossum wrote:
> On Mon, Aug 23, 2010 at 7:46 AM, Benjamin Peterson
> wrote:
>> 2010/8/23 Yury Selivanov :
>>> 1) I propose to change 'hasattr' behaviour in Python 3, making it to
>>> swallow only Attri
> On 2010-08-23, at 6:17 PM, Benjamin Peterson wrote:
> 2010/8/23 Yury Selivanov :
>>> On 2010-08-23, at 6:00 PM, Guido van Rossum wrote:
>>> On Mon, Aug 23, 2010 at 2:22 PM, Yury Selivanov
>>> wrote:
>> BTW, is it possible to add new magic method __hasattr
> On 2010-08-23, at 6:00 PM, Guido van Rossum wrote:
> On Mon, Aug 23, 2010 at 2:22 PM, Yury Selivanov wrote:
>> As I understand the only possible way to make 'hasattr' work as it name
>> indicates (i.e. just check if attribute exists, not run it), is to add
>&g
On 2010-08-23, at 5:22 PM, Yury Selivanov wrote:
> On 2010-08-23, at 5:02 PM, Michael Foord wrote:
>
>> On 23/08/2010 23:55, Benjamin Peterson wrote:
>>> 2010/8/23 Raymond Hettinger:
>>>> On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
>>>>
On 2010-08-23, at 5:02 PM, Michael Foord wrote:
> On 23/08/2010 23:55, Benjamin Peterson wrote:
>> 2010/8/23 Raymond Hettinger:
>>> On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
>>>
2010/8/23 Michael Foord:
> To me hasattr *looks* like a passive introspection function, and the fa
On 2010-08-23, at 4:33 PM, Raymond Hettinger wrote:
>
> On Aug 23, 2010, at 1:03 PM, Guido van Rossum wrote:
>
>>> But hasattr() has a far different set of use cases, so we should explore
>>> an alternate solution to the problem. The usual reason that people use
>>> hasattr() instead of getattr(
On 2010-08-23, at 3:47 PM, Raymond Hettinger wrote:
>
> On Aug 23, 2010, at 7:22 AM, Yury Selivanov wrote:
>
>> I know the issue has been discussed several times already, however I
>> couldn't find any reasonable explanation of its strange behaviour. The main
On 2010-08-23, at 10:46 AM, Benjamin Peterson wrote:
> 2010/8/23 Yury Selivanov :
>> 1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow
>> only AttributeError exceptions (exactly like 'getattr'). Probably, Python
>> 3.2 relea
uch python 2 code
converted with 2to3, we can introduce another 'hasattr' function defined in
2to3 module itself, and make it imported automatically in all files passed
through 2to3 transformation pipeline. This new function will mimic 'hasattr'
behaviour from python 2 and conve
501 - 592 of 592 matches
Mail list logo
