What is the order of execution of __eq__ if one side inherits from the other? [duplicate]python equality precedenceHow do you remove duplicates from a list whilst preserving order?Python's behavior for rich comparison (Or, when Decimal('100.0') < .01)Override __mul__ from a child class using parent implementation: leads to problemsExtract file name from path, no matter what the os/path format'Queue' object has no attribute 'size'How can I save output tho the same file that I have got the data from, in Python 3Mako: def composition (at render time) not evaluating properlypython decorator for class methodsTrying Python 3 code for this simple Employee object and I'm stuckDelete First Node From Python Linked List

Was murdering a slave illegal in American slavery, and if so, what punishments were given for it?

Separate the element after every 2nd ',' and push into next row in bash

What is this dime sized black bug with white on the segments near Loveland Colorodao?

Department head said that group project may be rejected. How to mitigate?

Expand a hexagon

Difference in 1 user doing 1000 iterations and 1000 users doing 1 iteration in Load testing

How do we properly manage transitions within a descriptive section?

Good examples of "two is easy, three is hard" in computational sciences

How could Dwarves prevent sand from filling up their settlements

If you attack a Tarrasque while swallowed, what AC do you need to beat to hit it?

How to add a low pass filter to this non-inverting amplifier circuit?

How would a physicist explain this starship engine?

1950s or earlier book with electrical currents living on Pluto

Way of refund if scammed?

why "American-born", not "America-born"?

Mikrokosmos, BB 105, Vol. 1: No. 17 Contrary Motion (1) - Can't understand the structure

Warped chessboard

How can sister protect herself from impulse purchases with a credit card?

Existence of a model of ZFC in which the natural numbers are really the natural numbers

Why did Nick Fury not hesitate in blowing up the plane he thought was carrying a nuke?

Schwa-less Polysyllabic German Noun Stems of Germanic Origin

How can I use 400 ASA film in a Leica IIIf, which does not have options higher than 100?

Does a windmilling propeller create more drag than a stopped propeller in an engine out scenario?

Is being an extrovert a necessary condition to be a manager?



What is the order of execution of __eq__ if one side inherits from the other? [duplicate]


python equality precedenceHow do you remove duplicates from a list whilst preserving order?Python's behavior for rich comparison (Or, when Decimal('100.0') < .01)Override __mul__ from a child class using parent implementation: leads to problemsExtract file name from path, no matter what the os/path format'Queue' object has no attribute 'size'How can I save output tho the same file that I have got the data from, in Python 3Mako: def composition (at render time) not evaluating properlypython decorator for class methodsTrying Python 3 code for this simple Employee object and I'm stuckDelete First Node From Python Linked List






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








18
















This question already has an answer here:



  • python equality precedence

    1 answer



I recently stumbled upon a seemingly strange behavior regarding the order in which __eq__ methods are executed, if one side of the comparison is an object which inherits from the other.



I've tried this in Python 3.7.2 in an admittedly academic example. Usually, given an equality comparison a == b, I expect a.__eq__ to be called first, followed by b.__eq__, if the first call returned NotImplemented. However, this doesn't seem to be the case, if a and b are part of the same class hierarchy. Consider the following example:



class A(object):
def __eq__(self, other):
print("Calling A().__eq__".format(self))
return NotImplemented

class B(A):
def __eq__(self, other):
print("Calling B().__eq__".format(self))
return True

class C(object):
def __eq__(self, other):
print("Calling C().__eq__".format(self))
return False

a = A()
b = B()
c = C()

print("a: ".format(a)) # output "a: <__main__.A object at 0x7f8fda95f860>"
print("b: ".format(b)) # output "b: <__main__.B object at 0x7f8fda8bcfd0>"
print("c: ".format(c)) # output "c: <__main__.C object at 0x7f8fda8bcef0>"

a == a # case 1

a == b # case 2.1
b == a # case 2.2

a == c # case 3.1
c == a # case 3.2


In case 1, I expect a.__eq__ to be called twice and this is also what I get:



Calling A(<__main__.A object at 0x7f8fda95f860>).__eq__
Calling A(<__main__.A object at 0x7f8fda95f860>).__eq__


However, in cases 2.1 and 2.2, b.__eq__ is always executed first, no matter on which side of the comparison it stands:



Calling B(<__main__.B object at 0x7f8fda8bcfd0>).__eq__ # case 2.1
Calling B(<__main__.B object at 0x7f8fda8bcfd0>).__eq__ # case 2.2


In cases 3.1 and 3.2 then, the left-hand side is again evaluated first, as I expected:



Calling A(<__main__.A object at 0x7f8fda95f860>).__eq__ # case 3.1
Calling C(<__main__.C object at 0x7f8fda8bcef0>).__eq__ # case 3.1
Calling C(<__main__.C object at 0x7f8fda8bcef0>).__eq__ # case 3.2


It seems that, if the compared objects are related to each other, __eq__ of the object of the child class is always evaluated first. Is there a deeper reasoning behind this behavior? If so, is this documented somewhere? PEP 207 doesn't mention this case, as far as I can see. Or am I maybe missing something obvious here?










share|improve this question















marked as duplicate by user2357112 python
Users with the  python badge can single-handedly close python questions as duplicates and reopen them as needed.

StackExchange.ready(function()
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();

);
);
);
May 7 at 20:00


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
























    18
















    This question already has an answer here:



    • python equality precedence

      1 answer



    I recently stumbled upon a seemingly strange behavior regarding the order in which __eq__ methods are executed, if one side of the comparison is an object which inherits from the other.



    I've tried this in Python 3.7.2 in an admittedly academic example. Usually, given an equality comparison a == b, I expect a.__eq__ to be called first, followed by b.__eq__, if the first call returned NotImplemented. However, this doesn't seem to be the case, if a and b are part of the same class hierarchy. Consider the following example:



    class A(object):
    def __eq__(self, other):
    print("Calling A().__eq__".format(self))
    return NotImplemented

    class B(A):
    def __eq__(self, other):
    print("Calling B().__eq__".format(self))
    return True

    class C(object):
    def __eq__(self, other):
    print("Calling C().__eq__".format(self))
    return False

    a = A()
    b = B()
    c = C()

    print("a: ".format(a)) # output "a: <__main__.A object at 0x7f8fda95f860>"
    print("b: ".format(b)) # output "b: <__main__.B object at 0x7f8fda8bcfd0>"
    print("c: ".format(c)) # output "c: <__main__.C object at 0x7f8fda8bcef0>"

    a == a # case 1

    a == b # case 2.1
    b == a # case 2.2

    a == c # case 3.1
    c == a # case 3.2


    In case 1, I expect a.__eq__ to be called twice and this is also what I get:



    Calling A(<__main__.A object at 0x7f8fda95f860>).__eq__
    Calling A(<__main__.A object at 0x7f8fda95f860>).__eq__


    However, in cases 2.1 and 2.2, b.__eq__ is always executed first, no matter on which side of the comparison it stands:



    Calling B(<__main__.B object at 0x7f8fda8bcfd0>).__eq__ # case 2.1
    Calling B(<__main__.B object at 0x7f8fda8bcfd0>).__eq__ # case 2.2


    In cases 3.1 and 3.2 then, the left-hand side is again evaluated first, as I expected:



    Calling A(<__main__.A object at 0x7f8fda95f860>).__eq__ # case 3.1
    Calling C(<__main__.C object at 0x7f8fda8bcef0>).__eq__ # case 3.1
    Calling C(<__main__.C object at 0x7f8fda8bcef0>).__eq__ # case 3.2


    It seems that, if the compared objects are related to each other, __eq__ of the object of the child class is always evaluated first. Is there a deeper reasoning behind this behavior? If so, is this documented somewhere? PEP 207 doesn't mention this case, as far as I can see. Or am I maybe missing something obvious here?










    share|improve this question















    marked as duplicate by user2357112 python
    Users with the  python badge can single-handedly close python questions as duplicates and reopen them as needed.

    StackExchange.ready(function()
    if (StackExchange.options.isMobile) return;

    $('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
    var $hover = $(this).addClass('hover-bound'),
    $msg = $hover.siblings('.dupe-hammer-message');

    $hover.hover(
    function()
    $hover.showInfoMessage('',
    messageElement: $msg.clone().show(),
    transient: false,
    position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
    dismissable: false,
    relativeToBody: true
    );
    ,
    function()
    StackExchange.helpers.removeMessages();

    );
    );
    );
    May 7 at 20:00


    This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.




















      18












      18








      18









      This question already has an answer here:



      • python equality precedence

        1 answer



      I recently stumbled upon a seemingly strange behavior regarding the order in which __eq__ methods are executed, if one side of the comparison is an object which inherits from the other.



      I've tried this in Python 3.7.2 in an admittedly academic example. Usually, given an equality comparison a == b, I expect a.__eq__ to be called first, followed by b.__eq__, if the first call returned NotImplemented. However, this doesn't seem to be the case, if a and b are part of the same class hierarchy. Consider the following example:



      class A(object):
      def __eq__(self, other):
      print("Calling A().__eq__".format(self))
      return NotImplemented

      class B(A):
      def __eq__(self, other):
      print("Calling B().__eq__".format(self))
      return True

      class C(object):
      def __eq__(self, other):
      print("Calling C().__eq__".format(self))
      return False

      a = A()
      b = B()
      c = C()

      print("a: ".format(a)) # output "a: <__main__.A object at 0x7f8fda95f860>"
      print("b: ".format(b)) # output "b: <__main__.B object at 0x7f8fda8bcfd0>"
      print("c: ".format(c)) # output "c: <__main__.C object at 0x7f8fda8bcef0>"

      a == a # case 1

      a == b # case 2.1
      b == a # case 2.2

      a == c # case 3.1
      c == a # case 3.2


      In case 1, I expect a.__eq__ to be called twice and this is also what I get:



      Calling A(<__main__.A object at 0x7f8fda95f860>).__eq__
      Calling A(<__main__.A object at 0x7f8fda95f860>).__eq__


      However, in cases 2.1 and 2.2, b.__eq__ is always executed first, no matter on which side of the comparison it stands:



      Calling B(<__main__.B object at 0x7f8fda8bcfd0>).__eq__ # case 2.1
      Calling B(<__main__.B object at 0x7f8fda8bcfd0>).__eq__ # case 2.2


      In cases 3.1 and 3.2 then, the left-hand side is again evaluated first, as I expected:



      Calling A(<__main__.A object at 0x7f8fda95f860>).__eq__ # case 3.1
      Calling C(<__main__.C object at 0x7f8fda8bcef0>).__eq__ # case 3.1
      Calling C(<__main__.C object at 0x7f8fda8bcef0>).__eq__ # case 3.2


      It seems that, if the compared objects are related to each other, __eq__ of the object of the child class is always evaluated first. Is there a deeper reasoning behind this behavior? If so, is this documented somewhere? PEP 207 doesn't mention this case, as far as I can see. Or am I maybe missing something obvious here?










      share|improve this question

















      This question already has an answer here:



      • python equality precedence

        1 answer



      I recently stumbled upon a seemingly strange behavior regarding the order in which __eq__ methods are executed, if one side of the comparison is an object which inherits from the other.



      I've tried this in Python 3.7.2 in an admittedly academic example. Usually, given an equality comparison a == b, I expect a.__eq__ to be called first, followed by b.__eq__, if the first call returned NotImplemented. However, this doesn't seem to be the case, if a and b are part of the same class hierarchy. Consider the following example:



      class A(object):
      def __eq__(self, other):
      print("Calling A().__eq__".format(self))
      return NotImplemented

      class B(A):
      def __eq__(self, other):
      print("Calling B().__eq__".format(self))
      return True

      class C(object):
      def __eq__(self, other):
      print("Calling C().__eq__".format(self))
      return False

      a = A()
      b = B()
      c = C()

      print("a: ".format(a)) # output "a: <__main__.A object at 0x7f8fda95f860>"
      print("b: ".format(b)) # output "b: <__main__.B object at 0x7f8fda8bcfd0>"
      print("c: ".format(c)) # output "c: <__main__.C object at 0x7f8fda8bcef0>"

      a == a # case 1

      a == b # case 2.1
      b == a # case 2.2

      a == c # case 3.1
      c == a # case 3.2


      In case 1, I expect a.__eq__ to be called twice and this is also what I get:



      Calling A(<__main__.A object at 0x7f8fda95f860>).__eq__
      Calling A(<__main__.A object at 0x7f8fda95f860>).__eq__


      However, in cases 2.1 and 2.2, b.__eq__ is always executed first, no matter on which side of the comparison it stands:



      Calling B(<__main__.B object at 0x7f8fda8bcfd0>).__eq__ # case 2.1
      Calling B(<__main__.B object at 0x7f8fda8bcfd0>).__eq__ # case 2.2


      In cases 3.1 and 3.2 then, the left-hand side is again evaluated first, as I expected:



      Calling A(<__main__.A object at 0x7f8fda95f860>).__eq__ # case 3.1
      Calling C(<__main__.C object at 0x7f8fda8bcef0>).__eq__ # case 3.1
      Calling C(<__main__.C object at 0x7f8fda8bcef0>).__eq__ # case 3.2


      It seems that, if the compared objects are related to each other, __eq__ of the object of the child class is always evaluated first. Is there a deeper reasoning behind this behavior? If so, is this documented somewhere? PEP 207 doesn't mention this case, as far as I can see. Or am I maybe missing something obvious here?





      This question already has an answer here:



      • python equality precedence

        1 answer







      python python-3.x






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited May 7 at 16:26









      John Kugelman

      252k55411463




      252k55411463










      asked May 7 at 12:20









      AndreasAndreas

      964




      964




      marked as duplicate by user2357112 python
      Users with the  python badge can single-handedly close python questions as duplicates and reopen them as needed.

      StackExchange.ready(function()
      if (StackExchange.options.isMobile) return;

      $('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
      var $hover = $(this).addClass('hover-bound'),
      $msg = $hover.siblings('.dupe-hammer-message');

      $hover.hover(
      function()
      $hover.showInfoMessage('',
      messageElement: $msg.clone().show(),
      transient: false,
      position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
      dismissable: false,
      relativeToBody: true
      );
      ,
      function()
      StackExchange.helpers.removeMessages();

      );
      );
      );
      May 7 at 20:00


      This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.









      marked as duplicate by user2357112 python
      Users with the  python badge can single-handedly close python questions as duplicates and reopen them as needed.

      StackExchange.ready(function()
      if (StackExchange.options.isMobile) return;

      $('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
      var $hover = $(this).addClass('hover-bound'),
      $msg = $hover.siblings('.dupe-hammer-message');

      $hover.hover(
      function()
      $hover.showInfoMessage('',
      messageElement: $msg.clone().show(),
      transient: false,
      position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
      dismissable: false,
      relativeToBody: true
      );
      ,
      function()
      StackExchange.helpers.removeMessages();

      );
      );
      );
      May 7 at 20:00


      This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
























          1 Answer
          1






          active

          oldest

          votes


















          18














          From the official documentation for __eq__ :




          If the operands are of different types, and right operand’s type is a direct or indirect subclass of the left operand’s type, the reflected method of the right operand has priority, otherwise the left operand’s method has priority.







          share|improve this answer























          • Thanks for the documentation reference! This doesn't explain the reasoning behind this, though. Are there any drawbacks, if the left operand would always have priority?

            – Andreas
            May 7 at 12:41






          • 2





            Yes, that means that subclasses can't override __eq__ which breaks the abstraction. It would create some very "interesting" polymorphic dispatch if __eq__ would have gotten precedence on the superclass rather than the subclass.

            – Benjamin Gruenbaum
            May 7 at 13:47











          • @BenjaminGruenbaum: Strictly, it could still work if A recognized that B was a subclass and returned NotImplemented... but that would violate Open/Closed because it would require A to explicitly know about and support subclassing, and would require subclasses to override __eq__ whether they want to or not. Overall, a very Bad Thing.

            – Kevin
            May 7 at 16:58

















          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          18














          From the official documentation for __eq__ :




          If the operands are of different types, and right operand’s type is a direct or indirect subclass of the left operand’s type, the reflected method of the right operand has priority, otherwise the left operand’s method has priority.







          share|improve this answer























          • Thanks for the documentation reference! This doesn't explain the reasoning behind this, though. Are there any drawbacks, if the left operand would always have priority?

            – Andreas
            May 7 at 12:41






          • 2





            Yes, that means that subclasses can't override __eq__ which breaks the abstraction. It would create some very "interesting" polymorphic dispatch if __eq__ would have gotten precedence on the superclass rather than the subclass.

            – Benjamin Gruenbaum
            May 7 at 13:47











          • @BenjaminGruenbaum: Strictly, it could still work if A recognized that B was a subclass and returned NotImplemented... but that would violate Open/Closed because it would require A to explicitly know about and support subclassing, and would require subclasses to override __eq__ whether they want to or not. Overall, a very Bad Thing.

            – Kevin
            May 7 at 16:58















          18














          From the official documentation for __eq__ :




          If the operands are of different types, and right operand’s type is a direct or indirect subclass of the left operand’s type, the reflected method of the right operand has priority, otherwise the left operand’s method has priority.







          share|improve this answer























          • Thanks for the documentation reference! This doesn't explain the reasoning behind this, though. Are there any drawbacks, if the left operand would always have priority?

            – Andreas
            May 7 at 12:41






          • 2





            Yes, that means that subclasses can't override __eq__ which breaks the abstraction. It would create some very "interesting" polymorphic dispatch if __eq__ would have gotten precedence on the superclass rather than the subclass.

            – Benjamin Gruenbaum
            May 7 at 13:47











          • @BenjaminGruenbaum: Strictly, it could still work if A recognized that B was a subclass and returned NotImplemented... but that would violate Open/Closed because it would require A to explicitly know about and support subclassing, and would require subclasses to override __eq__ whether they want to or not. Overall, a very Bad Thing.

            – Kevin
            May 7 at 16:58













          18












          18








          18







          From the official documentation for __eq__ :




          If the operands are of different types, and right operand’s type is a direct or indirect subclass of the left operand’s type, the reflected method of the right operand has priority, otherwise the left operand’s method has priority.







          share|improve this answer













          From the official documentation for __eq__ :




          If the operands are of different types, and right operand’s type is a direct or indirect subclass of the left operand’s type, the reflected method of the right operand has priority, otherwise the left operand’s method has priority.








          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered May 7 at 12:25









          LenormjuLenormju

          31414




          31414












          • Thanks for the documentation reference! This doesn't explain the reasoning behind this, though. Are there any drawbacks, if the left operand would always have priority?

            – Andreas
            May 7 at 12:41






          • 2





            Yes, that means that subclasses can't override __eq__ which breaks the abstraction. It would create some very "interesting" polymorphic dispatch if __eq__ would have gotten precedence on the superclass rather than the subclass.

            – Benjamin Gruenbaum
            May 7 at 13:47











          • @BenjaminGruenbaum: Strictly, it could still work if A recognized that B was a subclass and returned NotImplemented... but that would violate Open/Closed because it would require A to explicitly know about and support subclassing, and would require subclasses to override __eq__ whether they want to or not. Overall, a very Bad Thing.

            – Kevin
            May 7 at 16:58

















          • Thanks for the documentation reference! This doesn't explain the reasoning behind this, though. Are there any drawbacks, if the left operand would always have priority?

            – Andreas
            May 7 at 12:41






          • 2





            Yes, that means that subclasses can't override __eq__ which breaks the abstraction. It would create some very "interesting" polymorphic dispatch if __eq__ would have gotten precedence on the superclass rather than the subclass.

            – Benjamin Gruenbaum
            May 7 at 13:47











          • @BenjaminGruenbaum: Strictly, it could still work if A recognized that B was a subclass and returned NotImplemented... but that would violate Open/Closed because it would require A to explicitly know about and support subclassing, and would require subclasses to override __eq__ whether they want to or not. Overall, a very Bad Thing.

            – Kevin
            May 7 at 16:58
















          Thanks for the documentation reference! This doesn't explain the reasoning behind this, though. Are there any drawbacks, if the left operand would always have priority?

          – Andreas
          May 7 at 12:41





          Thanks for the documentation reference! This doesn't explain the reasoning behind this, though. Are there any drawbacks, if the left operand would always have priority?

          – Andreas
          May 7 at 12:41




          2




          2





          Yes, that means that subclasses can't override __eq__ which breaks the abstraction. It would create some very "interesting" polymorphic dispatch if __eq__ would have gotten precedence on the superclass rather than the subclass.

          – Benjamin Gruenbaum
          May 7 at 13:47





          Yes, that means that subclasses can't override __eq__ which breaks the abstraction. It would create some very "interesting" polymorphic dispatch if __eq__ would have gotten precedence on the superclass rather than the subclass.

          – Benjamin Gruenbaum
          May 7 at 13:47













          @BenjaminGruenbaum: Strictly, it could still work if A recognized that B was a subclass and returned NotImplemented... but that would violate Open/Closed because it would require A to explicitly know about and support subclassing, and would require subclasses to override __eq__ whether they want to or not. Overall, a very Bad Thing.

          – Kevin
          May 7 at 16:58





          @BenjaminGruenbaum: Strictly, it could still work if A recognized that B was a subclass and returned NotImplemented... but that would violate Open/Closed because it would require A to explicitly know about and support subclassing, and would require subclasses to override __eq__ whether they want to or not. Overall, a very Bad Thing.

          – Kevin
          May 7 at 16:58





          Popular posts from this blog

          Club Baloncesto Breogán Índice Historia | Pavillón | Nome | O Breogán na cultura popular | Xogadores | Adestradores | Presidentes | Palmarés | Historial | Líderes | Notas | Véxase tamén | Menú de navegacióncbbreogan.galCadroGuía oficial da ACB 2009-10, páxina 201Guía oficial ACB 1992, páxina 183. Editorial DB.É de 6.500 espectadores sentados axeitándose á última normativa"Estudiantes Junior, entre as mellores canteiras"o orixinalHemeroteca El Mundo Deportivo, 16 setembro de 1970, páxina 12Historia do BreogánAlfredo Pérez, o último canoneiroHistoria C.B. BreogánHemeroteca de El Mundo DeportivoJimmy Wright, norteamericano do Breogán deixará Lugo por ameazas de morteResultados de Breogán en 1986-87Resultados de Breogán en 1990-91Ficha de Velimir Perasović en acb.comResultados de Breogán en 1994-95Breogán arrasa al Barça. "El Mundo Deportivo", 27 de setembro de 1999, páxina 58CB Breogán - FC BarcelonaA FEB invita a participar nunha nova Liga EuropeaCharlie Bell na prensa estatalMáximos anotadores 2005Tempada 2005-06 : Tódolos Xogadores da Xornada""Non quero pensar nunha man negra, mais pregúntome que está a pasar""o orixinalRaúl López, orgulloso dos xogadores, presume da boa saúde económica do BreogánJulio González confirma que cesa como presidente del BreogánHomenaxe a Lisardo GómezA tempada do rexurdimento celesteEntrevista a Lisardo GómezEl COB dinamita el Pazo para forzar el quinto (69-73)Cafés Candelas, patrocinador del CB Breogán"Suso Lázare, novo presidente do Breogán"o orixinalCafés Candelas Breogán firma el mayor triunfo de la historiaEl Breogán realizará 17 homenajes por su cincuenta aniversario"O Breogán honra ao seu fundador e primeiro presidente"o orixinalMiguel Giao recibiu a homenaxe do PazoHomenaxe aos primeiros gladiadores celestesO home que nos amosa como ver o Breo co corazónTita Franco será homenaxeada polos #50anosdeBreoJulio Vila recibirá unha homenaxe in memoriam polos #50anosdeBreo"O Breogán homenaxeará aos seus aboados máis veteráns"Pechada ovación a «Capi» Sanmartín e Ricardo «Corazón de González»Homenaxe por décadas de informaciónPaco García volve ao Pazo con motivo do 50 aniversario"Resultados y clasificaciones""O Cafés Candelas Breogán, campión da Copa Princesa""O Cafés Candelas Breogán, equipo ACB"C.B. Breogán"Proxecto social"o orixinal"Centros asociados"o orixinalFicha en imdb.comMario Camus trata la recuperación del amor en 'La vieja música', su última película"Páxina web oficial""Club Baloncesto Breogán""C. B. Breogán S.A.D."eehttp://www.fegaba.com

          Vilaño, A Laracha Índice Patrimonio | Lugares e parroquias | Véxase tamén | Menú de navegación43°14′52″N 8°36′03″O / 43.24775, -8.60070

          Cegueira Índice Epidemioloxía | Deficiencia visual | Tipos de cegueira | Principais causas de cegueira | Tratamento | Técnicas de adaptación e axudas | Vida dos cegos | Primeiros auxilios | Crenzas respecto das persoas cegas | Crenzas das persoas cegas | O neno deficiente visual | Aspectos psicolóxicos da cegueira | Notas | Véxase tamén | Menú de navegación54.054.154.436928256blindnessDicionario da Real Academia GalegaPortal das Palabras"International Standards: Visual Standards — Aspects and Ranges of Vision Loss with Emphasis on Population Surveys.""Visual impairment and blindness""Presentan un plan para previr a cegueira"o orixinalACCDV Associació Catalana de Cecs i Disminuïts Visuals - PMFTrachoma"Effect of gene therapy on visual function in Leber's congenital amaurosis"1844137110.1056/NEJMoa0802268Cans guía - os mellores amigos dos cegosArquivadoEscola de cans guía para cegos en Mortágua, PortugalArquivado"Tecnología para ciegos y deficientes visuales. Recopilación de recursos gratuitos en la Red""Colorino""‘COL.diesis’, escuchar los sonidos del color""COL.diesis: Transforming Colour into Melody and Implementing the Result in a Colour Sensor Device"o orixinal"Sistema de desarrollo de sinestesia color-sonido para invidentes utilizando un protocolo de audio""Enseñanza táctil - geometría y color. Juegos didácticos para niños ciegos y videntes""Sistema Constanz"L'ocupació laboral dels cecs a l'Estat espanyol està pràcticament equiparada a la de les persones amb visió, entrevista amb Pedro ZuritaONCE (Organización Nacional de Cegos de España)Prevención da cegueiraDescrición de deficiencias visuais (Disc@pnet)Braillín, un boneco atractivo para calquera neno, con ou sen discapacidade, que permite familiarizarse co sistema de escritura e lectura brailleAxudas Técnicas36838ID00897494007150-90057129528256DOID:1432HP:0000618D001766C10.597.751.941.162C97109C0155020