[Python-Dev] Why not support user defined operator overloading ?

[张佩佩]

Hello:
As far as I know, there is not a language support user defined operator 
overloading.
Python3 can overloading belowed operators.
-   negated
+   unchanged

-   minus
+   add
*   multiplication
/   division
//  true division
%   remainder
**  power
(Do I miss something ?)

If we can overloading these operators, why we can't overloading other operators?
(like .* often used in matrix, U in set operation)


Regards!
Peipei
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why not support user defined operator overloading ?

[Xavier Morel]

On 2013-09-29, at 14:51 , 张佩佩 wrote:

> Hello:
>   As far as I know, there is not a language support user defined operator 
> overloading.
> Python3 can overloading belowed operators.
> - negated
> + unchanged
> 
> - minus
> + add
> * multiplication
> / division
> //true division
> % remainder
> **power
> (Do I miss something ?)

~ invert (unary)
()call
. get attribute
[]get item
<>right shift
& binary and
^ xor
| binary or

And the inplace versions of most of these can be implemented separately,
which can probably be counted as supplementary operators.

> 
> If we can overloading these operators, why we can't overloading other 
> operators?
> (like .* often used in matrix, U in set operation)

This is more of a python-ideas subject.

And one of the reasons likely is that it would require significantly
reworking the grammar to handle a kind of user-defined opname (similar
to name, but for operator tokens), with user-defined priority and
associativity, and the ability to import operators (or define how and
when operators become available compared to their definition)

That's a huge amount of complexity with little to gain.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why not support user defined operator overloading ?

[Steven D'Aprano]

On Sun, Sep 29, 2013 at 08:51:37PM +0800, 张佩佩 wrote:
> Hello:
>   As far as I know, there is not a language support user defined operator 
> overloading.
> Python3 can overloading belowed operators.
[...]
> (Do I miss something ?)

Yes, many.

http://docs.python.org/3/reference/datamodel.html#special-method-names
http://docs.python.org/3/reference/datamodel.html#emulating-numeric-types


> If we can overloading these operators, why we can't overloading other 
> operators?
> (like .* often used in matrix, U in set operation)

http://www.python.org/dev/peps/pep-0211/
http://www.python.org/dev/peps/pep-0225/

There is a good argument for being able to overload element-wise and 
object-wise operators. However, I don't think it is good to be able to 
create arbitrary new operators, e.g. a X b for an X operator. We 
already have syntax for arbitrary functions, and they aren't limited to 
binary operators: X(a, b, c, d, ...) works better than a X b for most 
uses.




-- 
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio

[Guido van Rossum]

So, with the naming settled (asyncio it is), and lots of other things still
to do, I need a BDFL for PEP 3156. Any volunteers? If no-one volunteered
I'll have to accept my own PEP at some point, but I don't really *want* to
do that.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Why not support user defined operator overloading ?

[Stephen J. Turnbull]

张佩佩 writes:

 > If we can overloading these operators, why we can't overloading
 > other operators?  (like .* often used in matrix, U in set
 > operation)

AIUI, it's considered unpythonic.  Operators are considered to be part
of the *syntax* of Python, unlike Haskell, where infix syntax can be
used for any function, and operators can be called via function
syntax.  (The latter is true in Python as well, but it is very bad
form to do that, sufficiently verbose that it is hardly tempting, and
it can easily fail because Python operators are polymorphic, but the
implementations via class methods are not.)

I'm sure it also simplifies parsing.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio

[Antoine Pitrou]

On Sun, 29 Sep 2013 09:54:39 -0700
Guido van Rossum  wrote:
> So, with the naming settled (asyncio it is), and lots of other things still
> to do, I need a BDFL for PEP 3156. Any volunteers? If no-one volunteered
> I'll have to accept my own PEP at some point, but I don't really *want* to
> do that.

Well, if you don't mind my slight pro-callback tropism, I'm definitely
volunteering :-)

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] 2.6.9rc1

[Barry Warsaw]

Just a quick reminder that I intend to cut 2.6.9rc1 tomorrow.

Here are the open issues still on my list:

- 16040 - nntplib: unlimited readline() from connection

  This one is waiting for a patch, but TBH if it doesn't make it into 2.6.9 I
  won't care too much.  I also don't mind reviewing and applying a patch
  between 2.6.9rc1 and 2.6.9 final.

- 16041 - poplib: unlimited readline() from connection

  This one has a patch for 2.7 which does not apply cleanly to 2.6.  I'm of a
  similar mind as with #16040 - if we can get a clean patch after 2.6.9rc1,
  then fine, but otherwise I'm okay with this one not making it into 2.6.9
  final.

All other related issues have been fixed in the 2.6 branch.

If anyone knows of any other issues that should be on the 2.6.9 radar, please
let me know asap.  Remember, 2.6.9 final is currently scheduled for October
28, and it will be the last official 2.6 release of the series.  After this,
we are retiring the 2.6 branch.  Speak now or forever hold your peace.

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why not support user defined operator overloading ?

[Ned Batchelder]

On 9/29/13 11:06 AM, Xavier Morel wrote:

This is more of a python-ideas subject.

And one of the reasons likely is that it would require significantly
reworking the grammar to handle a kind of user-defined opname (similar
to name, but for operator tokens), with user-defined priority and
associativity, and the ability to import operators (or define how and
when operators become available compared to their definition)

That's a huge amount of complexity with little to gain.


It isn't just a matter of a more complex parser: where would the parser 
get the information about these new operators?  The obvious first answer 
is that they would be defined as part of classes, but that means the 
operator definition is in an imported module some place.  The importing 
module couldn't even be parsed until the class was imported.  This is a 
completely different compilation and execution model than Python has now.


Now you can compile a Python module without any access to the modules it 
will eventually import.  Importing is a run-time operation.  If you want 
user-defined classes to be able to define new syntax, then importing has 
to happen at compile time.  That's a completely different language.


--Ned.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.6.9rc1

[Jyrki Pulliainen]

On Sun, Sep 29, 2013 at 8:11 PM, Barry Warsaw  wrote:

> Just a quick reminder that I intend to cut 2.6.9rc1 tomorrow.
>
> Here are the open issues still on my list:
>
> - 16040 - nntplib: unlimited readline() from connection
>
>   This one is waiting for a patch, but TBH if it doesn't make it into
> 2.6.9 I
>   won't care too much.  I also don't mind reviewing and applying a patch
>   between 2.6.9rc1 and 2.6.9 final.
>
> - 16041 - poplib: unlimited readline() from connection
>
>   This one has a patch for 2.7 which does not apply cleanly to 2.6.  I'm
> of a
>   similar mind as with #16040 - if we can get a clean patch after 2.6.9rc1,
>   then fine, but otherwise I'm okay with this one not making it into 2.6.9
>   final.
>
>
I added a patch for issue 16041 in 2.6. It's not too pretty, as I added
another test case class with just a slightly different server
implementation. This is mainly due to how the tests have been reworked for
2.7 and I didn't feel too comfortable of copying those tests back to 2.6.

- Jyrki


> All other related issues have been fixed in the 2.6 branch.
>
> If anyone knows of any other issues that should be on the 2.6.9 radar,
> please
> let me know asap.  Remember, 2.6.9 final is currently scheduled for October
> 28, and it will be the last official 2.6 release of the series.  After
> this,
> we are retiring the 2.6 branch.  Speak now or forever hold your peace.
>
> Cheers,
> -Barry
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/jyrki%40dywypi.org
>
>


-- 
- Jyrki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why not support user defined operator overloading ?

[Steven D'Aprano]

On Sun, Sep 29, 2013 at 03:35:27PM -0400, Ned Batchelder wrote:

> It isn't just a matter of a more complex parser: where would the parser 
> get the information about these new operators?  The obvious first answer 
> is that they would be defined as part of classes, but that means the 
> operator definition is in an imported module some place.  The importing 
> module couldn't even be parsed until the class was imported.  This is a 
> completely different compilation and execution model than Python has now.

The obvious place to define the operator's action is a class, but there 
is no need to define new syntax at runtime. The parser doesn't need to 
know the operator's action until runtime, no different from existing 
operators.

For avoidance of doubt, I'm not suggesting this as a concrete proposal, 
just as a hypothetical. But if somebody wants to take it seriously 
and write up a PEP, here are two possibilities to get you started:

* Unicode characters. It's 2013, and anyone still using an editor which 
only handles ASCII shouldn't be :-) There are dozens of non-alphanumeric 
characters in Unicode that are suitable as operators. Unless I've 
missed one, all the existing operators have category 'Sm', 'Sk', 
'Po', or 'Pd', so Python might parse any character in those categories 
as a potential operator. E.g. all of these are in category Sm:

∈ ∉ ≠ ⊂ ⊃ ⊕ ⊖ ⊗ ⊘

* ASCII digraphs. A more conservative approach would be to define custom 
operators as two characters, not one. Say, @X might be parsed as 
operator X.

In either case, having parsed "spam @X eggs" or "spam ⊂ eggs", the 
interpreter could do this:

call spam.__op__('X', eggs)  # or '⊂'
if that doesn't succeed, call eggs.__rop__('X', spam)
raise OperatorError

none of which need happen until runtime, same as existing operators.

If you want to also support unary operators (prefix or postfix) then the 
parsing rules presumably will become more complicated, but the basic 
principle remains: the parser needs a pre-defined "template" to 
recognise what looks like an operator, and that can be baked into the 
language definition. The actual meaning of the operator can be 
determined at run time.

Make no mistake, this is still a big change to Python's semantics. But 
it doesn't require Python to redefine syntax on the fly.


-- 
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio

[Larry Hastings]

On 09/27/2013 11:33 PM, Guido van Rossum wrote:
I've been looking at my progress with Tulip and the 3.4 release 
schedule (PEP 429) and it looks like I will have to do some kind of 
sprint to get it into the release in time for beta 1, which is planned 
for Nov 24. Ideally I'd get it into alpha 4, which is scheduled for 
Oct 20 -- that's in about three weeks, and probably too tight.


Even Nov 24 is aggressive, because the PEP (PEP 3156) hasn't even been 
discussed formally, let alone accepted! Fortunately I'm pretty happy 
with most of the APIs defined in the PEP -- there are some holes but I 
expect no big changes at this point.


My guess is, a lot of people would be disappointed if Tulip missed 3.4.  
I suspect the community would rather we slip the beta a little if it 
meant it the difference between Tulip and no Tulip.  I just hope you 
make it easy on me and beat the deadline ;-)


Cheers,


//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [RELEASED] Python 3.4.0a3

[Larry Hastings]

On behalf of the Python development team, I'm pleased to announce the
third alpha release of Python 3.4.

This is a preview release, and its use is not recommended for
production settings.

Python 3.4 includes a range of improvements of the 3.x series, including
hundreds of small improvements and bug fixes.  Major new features and
changes in the 3.4 release series so far include:

* PEP 435, a standardized "enum" module
* PEP 442, improved semantics for object finalization
* PEP 443, adding single-dispatch generic functions to the standard library
* PEP 445, a new C API for implementing custom memory allocators
* PEP 446, changing file descriptors to not be inherited by default
   in subprocesses


To download Python 3.4.0a3 visit:

http://www.python.org/download/releases/3.4.0/


Please consider trying Python 3.4.0a3 with your code and reporting any
issues you notice to:

 http://bugs.python.org/


Enjoy!

--
Larry Hastings, Release Manager
larry at hastings.org
(on behalf of the entire python-dev team and 3.4's contributors)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why not support user defined operator overloading ?

[张佩佩]

Hello:
I agree with Steven D'Aprano.
Here is an example:

class A(object):
def __init__(self, value):
self.value = value
def add(self, other):
return self.value + other.value
__magic_method__ = {'+':add}

a1 = A(1)
a2 = A(2)

We only need a macro expand
a1 + a2
to
a1.__magic__method__['+'](a, b)

the later can be execute on Python.

Regards
peipei
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio

[Eric V. Smith]

On 9/27/2013 9:14 PM, Brett Cannon wrote:

> I don't see any issue with redirecting the discussion. python-tulip@ is
> acting like a SIG for the module, so no real precedent beyond it not
> being hosted as a mail.python.org  list. 

I'm sure I'm in the minority, but I'd like the discussion to take place
on a python.org mailing list. I don't want to log in to a Google
property, and I don't trust them with the mailing list archives.

I know my voice counts less than active Tulip discussion participants,
but now at least I feel better for having said something.

-- 
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why not support user defined operator overloading ?

[Greg Ewing]

Steven D'Aprano wrote:
there 
is no need to define new syntax at runtime. The parser doesn't need to 
know the operator's action until runtime


It does need to know the operator's precedence and
associativity, though, which means either declaring
it somewhere, or having some kind of fixed rule.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio

[Guido van Rossum]

On Sun, Sep 29, 2013 at 5:40 PM, Eric V. Smith  wrote:

> On 9/27/2013 9:14 PM, Brett Cannon wrote:
>
> > I don't see any issue with redirecting the discussion. python-tulip@ is
> > acting like a SIG for the module, so no real precedent beyond it not
> > being hosted as a mail.python.org  list.
>
> I'm sure I'm in the minority, but I'd like the discussion to take place
> on a python.org mailing list. I don't want to log in to a Google
> property, and I don't trust them with the mailing list archives.
>
> I know my voice counts less than active Tulip discussion participants,
> but now at least I feel better for having said something.
>

I wish you'd said something a looong time ago when it would have been easy
to move the list. Even if we moved it now we'd have split archives. Also,
I'm not sure where the paranoia comes from. FWIW I'm less worried about
Google reading my personal email than about the python.org webmasters
reading it.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio

[Guido van Rossum]

On Sun, Sep 29, 2013 at 10:16 AM, Antoine Pitrou wrote:

> On Sun, 29 Sep 2013 09:54:39 -0700 Guido van Rossum 
> wrote:
> > So, with the naming settled (asyncio it is), and lots of other things
> still
> > to do, I need a BDFL for PEP 3156. Any volunteers? If no-one volunteered
> > I'll have to accept my own PEP at some point, but I don't really *want*
> to
> > do that.
>
> Well, if you don't mind my slight pro-callback tropism, I'm definitely
> volunteering :-)
>

I don't mind it, and if there's not too much objection from the community
you've got the job!

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Completed: Google Summer of Code 2013 IDLE Unit Testing and Improvements

[Todd V. Rovito]

In April 2013 we challenged students to not spend their summer idle around the 
swimming pool but rather spend their time on IDLE and make a difference.  IDLE 
is Python’s Integrated Development Environment (IDE) that is shipped with each 
Python release (http://en.wikipedia.org/wiki/IDLE_(Python)).  Since IDLE ships 
with Python it is often the first IDE a new Python programmer uses.  The Python 
development community wants to make IDLE an awesome experience especially for 
people that are learning Python.   Despite the fact that IDLE originally 
shipped in 1998 it had no unit test cases, making it difficult to confidently 
update the code and ship new versions.  For this Google Summer of Code project 
our students Jayakrishnan Rajagopalasarma 
(http://123works.blogspot.com/search/label/GSoC%202013) and Phil Webster 
(http://weblog.philwebster.net/tag/gsoc/) had to not only create the unit tests 
but assist with design of the unit test framework 
(http://bugs.python.org/issue15392).   By the end of the summer of 2013 Phil 
and Jayakrishnan have worked on five patches that have been committed to the 
CPython open source project.  In addition the team has started work on an 
additional five issues (at bugs.python.org) but have not completed them yet.  
Jayakrishnan explored an idea to add automatic PEP8 checking to IDLE 
http://bugs.python.org/issue18704.  Our hope is that both JayKrish and Phil 
continue to contribute to Python even now that GSoC is complete. 

 The team wishes to thank Google and the Python Software Foundation for this 
opportunity to contribute to Python.  Thanks to all the Python Core Developers 
that helped review and commit issues for the students.  Special thanks goes to 
Terry Reedy who provided outstanding feedback on issues and performed all of 
the student’s commits.  Finally thanks to Terri Oda for being a great GSoC 
administrator for the Python Software Foundation and helping by assigning an 
awesome co-mentor J.H. Hawley.


 

The complete list of closed issues is below:

http://bugs.python.org/issue18279

http://bugs.python.org/issue18189

http://bugs.python.org/issue18425

http://bugs.python.org/issue18226

http://bugs.python.org/issue18489

 

The complete list of started issues is below:

http://bugs.python.org/issue18292

http://bugs.python.org/issue18910

http://bugs.python.org/issue18409

http://bugs.python.org/issue18410

http://bugs.python.org/issue18592

  

 ___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why not support user defined operator overloading ?

[张佩佩]

On 2013/9/30 8:53 Greg Ewing wrote:
> It does need to know the operator's precedence and
>associativity, though, which means either declaring
>it somewhere, or having some kind of fixed rule

I suggest all user defined operator are at lowest priority.

Regards
peipei
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Fix http.server's request handling case on trailing '/'.

[Senthil Kumaran]

On Fri, Sep 13, 2013 at 7:49 AM, Eric V. Smith  wrote:
>> Patch contributed by Vajrasky Kok. Addresses Issue #17324
>
>> +trailing_slash = True if path.rstrip().endswith('/') else False
>
> Wouldn't this be better just as:
>   trailing_slash = path.rstrip().endswith('/')

I noticed this email late. Corrected it now.

Thanks,
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why not support user defined operator overloading ?

[Eli Bendersky]

Can you guys please move this discussion to python-ideas? python-dev is the
wrong mailing list.

Eli


On Sun, Sep 29, 2013 at 6:02 PM, 张佩佩  wrote:

> On 2013/9/30 8:53 Greg Ewing wrote:
> > It does need to know the operator's precedence and
> >associativity, though, which means either declaring
> >it somewhere, or having some kind of fixed rule
>
> I suggest all user defined operator are at lowest priority.
>
> Regards
> peipei
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/eliben%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (merge 3.3 -> default): merge from 3.3

[Senthil Kumaran]

On Wed, Sep 11, 2013 at 11:14 PM, Antoine Pitrou  wrote:
> On Thu, 12 Sep 2013 07:57:25 +0200 (CEST)
> senthil.kumaran  wrote:
>>
>> +<<< local
>>  Optional argument random is a 0-argument function returning a
>>  random float in [0.0, 1.0); if it is the default None, the
>>  standard random.random will be used.
>> +===
>> +Optional arg random is a 0-argument function returning a random
>> +float in [0.0, 1.0); by default, the standard random.random.
>> +
>> +Do not supply the 'int' argument.
>> +>>> other
>
> Can you fix this?

Had done it earlier. (http://hg.python.org/cpython/rev/1398dfb59fd9 )
I missed responding back.  Sorry for the trouble.

Thanks,
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why not support user defined operator overloading ?

[Ned Batchelder]

On 9/29/13 9:02 PM, 张佩佩 wrote:

On 2013/9/30 8:53 Greg Ewing wrote:

It does need to know the operator's precedence and
associativity, though, which means either declaring
it somewhere, or having some kind of fixed rule

I suggest all user defined operator are at lowest priority.


Peipei, this is an interesting discussion, but doesn't belong on 
Python-Dev.  The Python-Ideas mailing list is for exactly this kind of 
topic.


--Ned.


Regards
peipei
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/ned%40nedbatchelder.com


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com