Rel = Noreferrer

by ⋅ Link

Rel = Noreferrer

HTML5 added a lot of new features, and one of those is the new noreferrer keyword for the rel attribute. This keyword tells the browser that it should not collect or store HTTP referer information when the associated link is followed. Note that the attribute is spelled noreferrer, with two rs unlike the HTTP header, which has only one r. (How to Spell Referrer).

This is a useful keyword for web designers so that you can control what links you pass your site referrer information to.

Continue Reading Below

In other words, readers can click on the links, but the destination site will not see that they came from your site.

Using the Noreferrer Keyword

To use the noreferrer keyword, you put it in the rel attribute inside any A or AREA element.

As of 2013, the rel=noreferrer keyword is not supported in all browsers. If your website has a critical need to block this information, you should look at proxy servers and other solutions to block referrer information on your site.

Test Your Noreferrer Links

If you visit this page it should return a referrer of this web page.

See Also: When and Why to Hide Referrer Information

You can then add the noreferrer keyword to the link and test your browsers to see if they support it or not.

Here’s the HTML to put on your web page to test referrer and noreferrer links:

This link should have a referer
This link should not have a referrer
When you click on the first link, you should get a reply like:

http://webdesign.about.com/gi/o.htm?zi=1/XJ&zTi=1&sdn=webdesign&cdn=compute&tm=7&f=22&su=p284.13.342.ip_p504.6.342.ip_&tt=65&bt=3&bts=91&zu=http%3A//jenn.kyrnin.com/about/showreferer.html
Continue Reading Below

And when you click on the second link you should get a reply like:

You came here directly, or no referer was sent.
In my tests, Chrome and Safari both supported the rel=noreferrer attribute correctly, while Firefox and Opera did not. I have not tested Internet Explorer

11 PEP 357: The ‘__index__’ method

by ⋅ Link

11 PEP 357: The ‘__index__’ method

11 PEP 357: The ’__index__’ method
The NumPy developers had a problem that could only be solved by adding a new special method, __index__. When using slice notation, as in [start:stop:step], the values of the start, stop, and step indexes must all be either integers or long integers. NumPy defines a variety of specialized integer types corresponding to unsigned and signed integers of 8, 16, 32, and 64 bits, but there was no way to signal that these types could be used as slice indexes.
Slicing can’t just use the existing __int__ method because that method is also used to implement coercion to integers. If slicing used __int__, floating-point numbers would also become legal slice indexes and that’s clearly an undesirable behaviour.
Instead, a new special method called __index__ was added. It takes no arguments and returns an integer giving the slice index to use. For example:
class C:
def __index__ (self):
return self.value
The return value must be either a Python integer or long integer. The interpreter will check that the type returned is correct, and raises a TypeError if this requirement isn’t met.
A corresponding nb_index slot was added to the C-level PyNumberMethods structure to let C extensions implement this protocol. PyNumber_Index(obj) can be used in extension code to call the __index__ function and retrieve its result.

What is the difference between old style and new style classes in Python? – Stack Overflow

by ⋅ Link

What is the difference between old style and new style classes in Python? – Stack Overflow

From http://docs.python.org/2/reference/datamodel.html#new-style-and-classic-classes :

Up to Python 2.1, old-style classes were the only flavour available to the user. The concept of (old-style) class is unrelated to the concept of type: if x is an instance of an old-style class, then x.__class__ designates the class of x, but type(x) is always . This reflects the fact that all old-style instances, independently of their class, are implemented with a single built-in type, called instance.

New-style classes were introduced in Python 2.2 to unify classes and types. A new-style class neither more nor less than a user-defined type. If x is an instance of a new-style class, then type(x) is the same as x.__class__.

The major motivation for introducing new-style classes is to provide a unified object model with a full meta-model. It also has a number of immediate benefits, like the ability to subclass most built-in types, or the introduction of “descriptors”, which enable computed properties.

For compatibility reasons, classes are still old-style by default. New-style classes are created by specifying another new-style class (i.e. a type) as a parent class, or the “top-level type” object if no other parent is needed. The behaviour of new-style classes differs from that of old-style classes in a number of important details in addition to what type returns. Some of these changes are fundamental to the new object model, like the way special methods are invoked. Others are “fixes” that could not be implemented before for compatibility concerns, like the method resolution order in case of multiple inheritance.

Python 3 only has new-style classes. No matter if you subclass from object or not, classes are new-style in Python 3. It is however recommended that you still subclass from object.