473,708 Members | 2,371 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

from __future__ import absolute_import ?


from __future__ import absolute_import

Is there a way to check if this is working? I get the same results with or
without it.

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17)
[MSC v.1310 32 bit (Intel)] on win 32
_Ron

Feb 2 '07 #1
7 20559
Ron Adam wrote:
>
from __future__ import absolute_import

Is there a way to check if this is working? I get the same results with
or without it.

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17)
[MSC v.1310 32 bit (Intel)] on win 32
If there are two modules 'foo', one at the toplevel and the other inside a
package 'bar',

from __future__ import absolute_import
import foo

will import the toplevel module whereas

import foo

will import bar.foo. A messy demonstration:

$ ls bar
absolute.py foo.py __init__.py relative.py
$ cat bar/absolute.py
from __future__ import absolute_import
import foo
$ cat bar/relative.py
import foo
$ cat foo.py
print "toplevel"
$ cat bar/foo.py
print "in bar"
$ python2.5 -c 'import bar.absolute'
toplevel
$ python2.5 -c 'import bar.relative'
in bar
Another example is here:

http://mail.python.org/pipermail/pyt...ry/422889.html

Peter
Feb 2 '07 #2
Peter Otten wrote:
If there are two modules 'foo', one at the toplevel and the other inside a
package 'bar',

from __future__ import absolute_import
import foo

will import the toplevel module whereas

import foo

will import bar.foo.
.... provided these imports are performed from modules within 'bar'.

Peter
Feb 2 '07 #3
Peter Otten wrote:
Ron Adam wrote:
> from __future__ import absolute_import

Is there a way to check if this is working? I get the same results with
or without it.

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17)
[MSC v.1310 32 bit (Intel)] on win 32

If there are two modules 'foo', one at the toplevel and the other inside a
package 'bar',

from __future__ import absolute_import
import foo

will import the toplevel module whereas

import foo

will import bar.foo. A messy demonstration:

$ ls bar
absolute.py foo.py __init__.py relative.py
$ cat bar/absolute.py
from __future__ import absolute_import
import foo
$ cat bar/relative.py
import foo
$ cat foo.py
print "toplevel"
$ cat bar/foo.py
print "in bar"
$ python2.5 -c 'import bar.absolute'
toplevel
$ python2.5 -c 'import bar.relative'
in bar
Another example is here:

http://mail.python.org/pipermail/pyt...ry/422889.html

Peter
Thanks, that helped, I see why I was having trouble.
work
|
|- foo.py # print "foo not in bar"
|
`- bar
|
|- __init__.py
|
|- foo.py # print "foo in bar"
|
|- absolute.py # from __futer__ import absolute_import
| # import foo
|
`- relative.py # import foo
* Where "work" is in the path.
(1)

C:\work>python -c "import bar.absolute"
foo not in bar

C:\work>python -c "import bar.relative"
foo in bar
(2)

C:\work>python -m "bar.absolu te"
foo not in bar

C:\work>python -m "bar.relati ve"
foo not in bar
(3)

C:\work>python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win
32
Type "help", "copyright" , "credits" or "license" for more information.
>>import bar.absolute
foo not in bar
>>import bar.relative
foo in bar
(4)

C:\work>cd bar

C:\work\bar>pyt hon -c "import bar.absolute"
foo in bar

C:\work\bar>pyt hon -c "import bar.relative"
foo in bar
(5)

C:\work\bar>pyt hon
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win
32
Type "help", "copyright" , "credits" or "license" for more information.
>>import bar.absolute
foo in bar
>>import bar.relative
foo in bar
>>>


Case (2) seems like it is a bug.
Why not also have (4), and (5) do the same as cases (1) and (3)?
in cases (4) and (5), that is the result I would expect if I did:

import absolute # with no 'bar.' prefix.
import relative
From what I understand, in 2.6 relative imports will be depreciated, and in 2.7
they will raise an error. (providing plans don't change)

Would that mean the absolute imports in (4) and (5) would either find the 'foo
not in bar' or raise an error?

If so, is there any way to force (warning/error) behavior now?

Cheers,
Ron

Feb 2 '07 #4
Ron Adam wrote:
Peter Otten wrote:
>Ron Adam wrote:
>> from __future__ import absolute_import

Is there a way to check if this is working? I get the same results with
or without it.

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17)
[MSC v.1310 32 bit (Intel)] on win 32

If there are two modules 'foo', one at the toplevel and the other inside
a package 'bar',

from __future__ import absolute_import
import foo

will import the toplevel module whereas

import foo

will import bar.foo. A messy demonstration:

$ ls bar
absolute.py foo.py __init__.py relative.py
$ cat bar/absolute.py
from __future__ import absolute_import
import foo
$ cat bar/relative.py
import foo
$ cat foo.py
print "toplevel"
$ cat bar/foo.py
print "in bar"
$ python2.5 -c 'import bar.absolute'
toplevel
$ python2.5 -c 'import bar.relative'
in bar
Another example is here:

http://mail.python.org/pipermail/pyt...ry/422889.html

Peter

Thanks, that helped, I see why I was having trouble.
work
|
|- foo.py # print "foo not in bar"
|
`- bar
|
|- __init__.py
|
|- foo.py # print "foo in bar"
|
|- absolute.py # from __futer__ import absolute_import
| # import foo
|
`- relative.py # import foo
* Where "work" is in the path.
(1)

C:\work>python -c "import bar.absolute"
foo not in bar

C:\work>python -c "import bar.relative"
foo in bar
(2)

C:\work>python -m "bar.absolu te"
foo not in bar

C:\work>python -m "bar.relati ve"
foo not in bar
(3)

C:\work>python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]
on win 32
Type "help", "copyright" , "credits" or "license" for more information.
>>import bar.absolute
foo not in bar
>>import bar.relative
foo in bar
(4)

C:\work>cd bar
A path below the package level is generally a good means to shoot yourself
in the foot and should be avoided with or without absolute import.
C:\work\bar>pyt hon -c "import bar.absolute"
foo in bar

C:\work\bar>pyt hon -c "import bar.relative"
foo in bar
(5)

C:\work\bar>pyt hon
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]
on win 32
Type "help", "copyright" , "credits" or "license" for more information.
>>import bar.absolute
foo in bar
>>import bar.relative
foo in bar
>>>

Case (2) seems like it is a bug.
I think so, too.
Why not also have (4), and (5) do the same as cases (1) and (3)?
The work/bar directory is the current working directory and occurs in the
path before the work directory. When bar.absolute imports foo python is
unaware that work/bar/foo.py is part of the bar package.
in cases (4) and (5), that is the result I would expect if I did:

import absolute # with no 'bar.' prefix.
import relative
From what I understand, in 2.6 relative imports will be depreciated, and
in 2.7
they will raise an error. (providing plans don't change)

Would that mean the absolute imports in (4) and (5) would either find the
'foo not in bar' or raise an error?
No, in 1, 3 -- and 2 if the current behaviour is indeed a bug. This is only
for the relative import which would have to be spelt

from . import foo

in an absolute-import-as-default environment;

import foo

would always be an absolute import.
If so, is there any way to force (warning/error) behavior now?
I don't know.

Peter

Feb 3 '07 #5
Peter Otten wrote:
Ron Adam wrote:
>>
work
|
|- foo.py # print "foo not in bar"
|
`- bar
|
|- __init__.py
|
|- foo.py # print "foo in bar"
|
|- absolute.py # from __futer__ import absolute_import
| # import foo
|
`- relative.py # import foo
* Where "work" is in the path.
(1)

C:\work>pyth on -c "import bar.absolute"
foo not in bar

C:\work>pyth on -c "import bar.relative"
foo in bar
(2)

C:\work>pyth on -m "bar.absolu te"
foo not in bar

C:\work>pyth on -m "bar.relati ve"
foo not in bar
(3)

C:\work>pyth on
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]
on win 32
Type "help", "copyright" , "credits" or "license" for more information.
> >>import bar.absolute
foo not in bar
> >>import bar.relative
foo in bar
(4)

C:\work>cd bar

A path below the package level is generally a good means to shoot yourself
in the foot and should be avoided with or without absolute import.
Seems so. :-/

>C:\work\bar>py thon -c "import bar.absolute"
foo in bar

C:\work\bar>py thon -c "import bar.relative"
foo in bar
(5)

C:\work\bar>py thon
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]
on win 32
Type "help", "copyright" , "credits" or "license" for more information.
> >>import bar.absolute
foo in bar
> >>import bar.relative
foo in bar
> >>>

Case (2) seems like it is a bug.

I think so, too.
This one is the reasons I had trouble figuring it out. I was using the -m
command option when I tried to test it.

There is a bug report on absolute/relative imports already. I'm not sure if
this particular item is covered under it or not. Doesn't sound like it as the
bug report address the relative aspects of it.

>Why not also have (4), and (5) do the same as cases (1) and (3)?

The work/bar directory is the current working directory and occurs in the
path before the work directory.
Yes. Unfortunately this is a side effect of using the os's directory structure
to represent a python "package" structure. If a package was represented as a
combined single file. Then the working directory would always be the package
directory.

When bar.absolute imports foo python is
unaware that work/bar/foo.py is part of the bar package.
Umm.... isn't the "bar" stuck on the front of "bar.absolu te" a pretty obvious
hint. ;-)

If you run the module directly as a file...

python bar/foo.py
or python foo.py

Then I can see that it doesn't know. But even then, it's possible to find out.
ie... just check for an __init__.py file.

Python has a certain minimalist quality where it tries to do a lot with a
minimum amount of resources, which I generally love. But in this situation that
might not be the best thing. It would not be difficult for python to detect if
a module is in a package, and determine the package location. With the move to
explicit absolute/relative imports, it would make since if python also were a
little smarter in this area.

>in cases (4) and (5), that is the result I would expect if I did:

import absolute # with no 'bar.' prefix.
import relative
From what I understand, in 2.6 relative imports will be depreciated, and
in 2.7
they will raise an error. (providing plans don't change)

Would that mean the absolute imports in (4) and (5) would either find the
'foo not in bar' or raise an error?

No, in 1, 3 -- and 2 if the current behaviour is indeed a bug. This is only
for the relative import which would have to be spelt

from . import foo
Was that a 'yes' for exampels 4 and 5, since 1,2 and 3 are 'no'?

in an absolute-import-as-default environment;

import foo

would always be an absolute import.
But what is the precise meaning of "absolute import" in this un-dotted case?

Currently it is:

"A module or package that is located in sys.path or the current directory".

But maybe a narrower interpretation may be better?:

"A module or package found in sys.path, or the current directory
and is *not* in a package."

If it's in a package then the dotted "absolute" name should be used. Right?
I guess what I'm getting at, is it would be nice if the following were always true.

from __import__ import absolute_import
import thispackage.mod ule
import thispackage.sub package

# If thispackage is the same name as the current package,
# then do not look on sys.path.
import otherpackage.mo dule
import otherpackage.su bpackage

# If otherpackage is a different name from the current package,
# then do not look in this package.
import module
import package

# Module and package are not in a package, even the current one,
# so don't look in any packages, even if the current directory is
# in this (or other) package.
If these were always true, :-) I think it avoid some situations where things
don't work, or don't work like one would expect.

In addition to the above, when executing modules directly from a directory
inside a package, if python were to detect the package and then follow these
same rules. It would avoid even more surprises. While you are editing modules
in a package, you could then run them directly and get the same behavior you get
if you cd'd out of the package and then ran it.

All in all, what I'm suggesting is that the concept of a package (type) be much
stronger than that of a search path or current directory. And that this would
add a fair amount of reliability to the language.

IMHO, of course. :-)

Cheers,
Ron
>If so, is there any way to force (warning/error) behavior now?

I don't know.

Peter
Feb 3 '07 #6
Ron Adam wrote:
Peter Otten wrote:
>Ron Adam wrote:
>>>
work
|
|- foo.py # print "foo not in bar"
|
`- bar
|
|- __init__.py
|
|- foo.py # print "foo in bar"
|
|- absolute.py # from __futer__ import absolute_import
| # import foo
|
`- relative.py # import foo
* Where "work" is in the path.
(1)

C:\work>pytho n -c "import bar.absolute"
foo not in bar

C:\work>pytho n -c "import bar.relative"
foo in bar
(2)

C:\work>pytho n -m "bar.absolu te"
foo not in bar

C:\work>pytho n -m "bar.relati ve"
foo not in bar
(3)

C:\work>pytho n
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win 32
Type "help", "copyright" , "credits" or "license" for more information.
>>import bar.absolute
foo not in bar
>>import bar.relative
foo in bar
(4)

C:\work>cd bar

A path below the package level is generally a good means to shoot
yourself in the foot and should be avoided with or without absolute
import.

Seems so. :-/

>>C:\work\bar>p ython -c "import bar.absolute"
foo in bar

C:\work\bar>p ython -c "import bar.relative"
foo in bar
(5)

C:\work\bar>p ython
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win 32
Type "help", "copyright" , "credits" or "license" for more information.
>>import bar.absolute
foo in bar
>>import bar.relative
foo in bar
>>>

Case (2) seems like it is a bug.

I think so, too.

This one is the reasons I had trouble figuring it out. I was using the -m
command option when I tried to test it.

There is a bug report on absolute/relative imports already. I'm not sure
if
this particular item is covered under it or not. Doesn't sound like it as
the bug report address the relative aspects of it.

>>Why not also have (4), and (5) do the same as cases (1) and (3)?

The work/bar directory is the current working directory and occurs in the
path before the work directory.

Yes. Unfortunately this is a side effect of using the os's directory
structure
to represent a python "package" structure. If a package was represented
as a
combined single file. Then the working directory would always be the
package directory.

When bar.absolute imports foo python is
unaware that work/bar/foo.py is part of the bar package.

Umm.... isn't the "bar" stuck on the front of "bar.absolu te" a pretty
obvious
hint. ;-)

If you run the module directly as a file...

python bar/foo.py
or python foo.py

Then I can see that it doesn't know. But even then, it's possible to find
out.
ie... just check for an __init__.py file.

Python has a certain minimalist quality where it tries to do a lot with a
minimum amount of resources, which I generally love. But in this
situation that
might not be the best thing. It would not be difficult for python to
detect if
a module is in a package, and determine the package location. With the
move to explicit absolute/relative imports, it would make since if python
also were a little smarter in this area.
I have not used the new import behaviour seriously, but -- I think I like
it :-)
>>in cases (4) and (5), that is the result I would expect if I did:

import absolute # with no 'bar.' prefix.
import relative
From what I understand, in 2.6 relative imports will be depreciated,
and in 2.7
they will raise an error. (providing plans don't change)

Would that mean the absolute imports in (4) and (5) would either find
the 'foo not in bar' or raise an error?

No, in 1, 3 -- and 2 if the current behaviour is indeed a bug. This is
only for the relative import which would have to be spelt

from . import foo

Was that a 'yes' for exampels 4 and 5, since 1,2 and 3 are 'no'?
(4) and (5) are misconfiguratio ns, IMHO.
>in an absolute-import-as-default environment;

import foo

would always be an absolute import.

But what is the precise meaning of "absolute import" in this un-dotted
case?

Currently it is:

"A module or package that is located in sys.path or the current
directory".

But maybe a narrower interpretation may be better?:

"A module or package found in sys.path, or the current directory
and is *not* in a package."
You'd have to add a not-in-package test to every import - I don't think it's
worth the effort.
If it's in a package then the dotted "absolute" name should be used.
Right?
Either that or the full path. The dotted path makes it easy to move the
module between packages.
I guess what I'm getting at, is it would be nice if the following were
always true.

from __import__ import absolute_import
import thispackage.mod ule
import thispackage.sub package

# If thispackage is the same name as the current package,
# then do not look on sys.path.
import otherpackage.mo dule
import otherpackage.su bpackage

# If otherpackage is a different name from the current package,
# then do not look in this package.
import module
import package

# Module and package are not in a package, even the current one,
# so don't look in any packages, even if the current directory is
# in this (or other) package.
If these were always true, :-) I think it avoid some situations where
things don't work, or don't work like one would expect.

In addition to the above, when executing modules directly from a directory
inside a package, if python were to detect the package and then follow
these
same rules. It would avoid even more surprises. While you are editing
modules in a package, you could then run them directly and get the same
behavior you get if you cd'd out of the package and then ran it.

All in all, what I'm suggesting is that the concept of a package (type) be
much
stronger than that of a search path or current directory. And that this
would add a fair amount of reliability to the language.
I think if you go that way, ultimately you will need some kind of package
registry. I expect that the new import behaviour will get you 99 percent
there with one percent of the hassle. But we will see...

Peter
Feb 9 '07 #7
Peter Otten wrote:
Ron Adam wrote:
>Peter Otten wrote:
>>Ron Adam wrote:

work
|
|- foo.py # print "foo not in bar"
|
`- bar
|
|- __init__.py
|
|- foo.py # print "foo in bar"
|
|- absolute.py # from __futer__ import absolute_import
| # import foo
|
`- relative.py # import foo
>>>(4)
>>>C:\work\bar> python -c "import bar.absolute"
foo in bar
>>>(5)
>>> >>import bar.absolute
foo in bar
(4) and (5) are misconfiguratio ns, IMHO.
But it's a very common configuration. So it will most likely cause problems for
someone.

From what I understand these will probably do what I want in python 2.6, which
is either import the foo not in bar, or give an error if foo not in bar doesn't
exist instead of importing foo in bar.

>>in an absolute-import-as-default environment;

import foo

would always be an absolute import.
But what is the precise meaning of "absolute import" in this un-dotted
case?

Currently it is:

"A module or package that is located in sys.path or the current
directory".

But maybe a narrower interpretation may be better?:

"A module or package found in sys.path, or the current directory
and is *not* in a package."

You'd have to add a not-in-package test to every import - I don't think it's
worth the effort.
No, you only need to test the (first) module you explicitly run is in a package.
For any imports after that, the absolute import code can exclude any of the
package directories for un-dotted top level absolute imports. It may be a
performance net gain because there is less disk searching.

>All in all, what I'm suggesting is that the concept of a package (type) be
much
stronger than that of a search path or current directory. And that this
would add a fair amount of reliability to the language.

I think if you go that way, ultimately you will need some kind of package
registry. I expect that the new import behaviour will get you 99 percent
there with one percent of the hassle. But we will see...
It won't need a registry.

Check the python-ideas list for further discussion on this.

Cheers,
Ron

Feb 9 '07 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
1972
by: Logan | last post by:
Is there a list with all 'from __future__ import ...' statements (which lists all the statements, in which version of Python the feature was introduced and in which version of Python it will become the default behavior)? I guess, normally such a list is not necessary because a new feature needs its 'from __future__ import ...' statement only in the present version of Python and will become default in the next version. But e.g. 'from...
8
1585
by: Jacek Generowicz | last post by:
I have some code, which makes copious use of the @decorator syntax which was introduced in Python2.4. Now I find myself in a situation where I have to run the code under Python 2.3. However, I would like to keep developing the code with the new syntax. How could I best automate the process of making the syntax digestible by Python2.3 ?
3
5425
by: Mudcat | last post by:
I have a directory structure that contains different modules that run depending on what the user selects. They are identical in name and structure, but what varies is the content of the functions. They will only need to be run once per execution. Example (directory level): Sys1: A B C
5
2184
by: mark_galeck_spam_magnet | last post by:
Hi, why does complain name 'compileFile' not defined. But works. Why? (I did read the tutorial, it seems to say "import module" should work. Thank you, Mark
2
1858
by: mithrond | last post by:
i can't use "from __future__ import ..." statement import two statesments in the same time. for the simple code: from __future__ import with_statement, division with file('url.txt','r') as f: for line in f: print line it can't run until i change the first sentence to below from __future__ import with_statement
7
10758
by: samslists | last post by:
Am I the only one that thinks this would be useful? :) I'd really like to be able to use python 3.0's print statement in 2.x. Is this at least being considered as an option for 2.6? It seems like it would be helpful with transitioning.
1
2150
by: Malcolm Greene | last post by:
Is there any consensus on what "from __future__ import" options developers should be using in their Python 2.5.2 applications? Is there a consolidated list of "from __future__ import" options to choose from? Thank you, Malcolm
0
1053
by: Tim Golden | last post by:
Malcolm Greene wrote: Well, that bit's easy: import __future__ print __future__.all_feature_names TJG
3
6114
by: notnorwegian | last post by:
import Tkinter from Tkinter import * i have a program where if i comment out either of those import- statements i get an error. i thought they meant the same thing and from was supposed to be just to imort just a specific function and the * imports everything in the module. but aparently the above statements have diffrent meaning and i cant
0
8788
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
8697
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
9159
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
9061
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
9001
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
1
6615
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
1
3151
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
2508
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
2097
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.