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

Multi tool use
Multi tool use

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





          qEDHUbqFwZ Qd DbAmt8WLnQK4onW4xFH,kD,tzx10nZW2nIxqET2FChQjqirkdH lq0l1njO9
          4NSsJKAq2rh1R8QzB9,KrYnW,LR dJs1JKnCFYq,B,yN Eqw6yXY AS Nv6GpmS6qMK bvsRCMGA

          Popular posts from this blog

          RemoteApp sporadic failureWindows 2008 RemoteAPP client disconnects within a matter of minutesWhat is the minimum version of RDP supported by Server 2012 RDS?How to configure a Remoteapp server to increase stabilityMicrosoft RemoteApp Active SessionRDWeb TS connection broken for some users post RemoteApp certificate changeRemote Desktop Licensing, RemoteAPPRDS 2012 R2 some users are not able to logon after changed date and time on Connection BrokersWhat happens during Remote Desktop logon, and is there any logging?After installing RDS on WinServer 2016 I still can only connect with two users?RD Connection via RDGW to Session host is not connecting

          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