Update to Python 3. fixed some stuff

[Gteditor99]

[Gteditor99]

os.system("clear")
os.system("figlet Attack Starting")
print "[                    ] 0% "
time.sleep(5)
print "[=====               ] 25%"
time.sleep(5)
print "[==========          ] 50%"
time.sleep(5)
print "[===============     ] 75%"
time.sleep(5)
print "[====================] 100%"
time.sleep(3)

@Ha3MrX why would you add delay to your code?

Use:

os.system("pause")

[Tyler887]

os.system("cls") is controversial for the developer and breaks the program on Unix-like systems. The developer itself is using a Unix-like system (Kali Linux). Please use os.system("cls" if os.name == "nt" else "clear") to make this work on Un*x. Also, the pause command does not exist on Un*x and only on Windows (I executed this such command in WSL2 and it returns pause: command not found), so you are requesting the author to simply break it for Linux users (which includes the developer itself), and can totally break this program when building on MSYS2, WSL, etc. Instead of os.system("pause"), to make it cross-platform, use input("Press Enter to continue. . . ").

This program also works fine on Python 3 if you use 2to3, which is good at reading Python 2 code and changing the code to work for Python 3. However, on Windows, be sure to run the program on WSL. If the wsl command without arguments throws a help message, run wsl --install then shutdown /r /f /t 00.

Be sure this user is still stuck on Python 2 (most likely Python 2.7, which is more heavily used than other versions), and has not upgraded yet to a maintained version. I recommend upgrading to 3.10, which can be built from source (download gzipped tarball).

And now for something completely different... (There is no Python 2.8)

In all seriousness, there are important reasons why there won’t be a Python 2.8 release from the PSF, and why you should plan to migrate instead to Python 3 now.

Today, Python is more than 20 years old, and Guido and the Python community have learned a lot in those intervening years. Guido’s original concept for Python 3 was to make changes to the language primarily to remove the warts that had grown in the preceding versions. Python 3 was not to be a complete redesign, but instead an evolution of the language, and while maintaining full backward compatibility with Python 2 was explicitly off-the-table, neither were gratuitous changes in syntax or semantics acceptable. In most cases, Python 2 code can be translated fairly easily to Python 3, sometimes entirely mechanically by such tools as 2to3 (there’s also a non-trivial subset of the language that will run without modification on both 2.7 and 3.x).

Because maintaining multiple versions of Python is a significant drag on the resources of the Python developers, and because the improvements to the language and libraries embodied in Python 3 are so important, it was decided to end the Python 2 lineage with Python 2.7. Thus, all new development will occur in the Python 3 line of development, and there will never be a Python 2.8 release at all.

Here are some highlights of the significant improvements in Python 3. You can read in more detail on the differences between Python 2 (2000) and Python 3 (2006). There are also many good guides on porting code from Python 2 to Python 3.

Modified from PEP 404, which is released into the public domain, and therefore can be used and modified, without any conditions, not even retaining the copyright notice, and may be relicensed, whether dual-licensing or just changing the license.

Strings and bytes

Python 2’s basic original strings are called 8-bit strings, and they play a dual role in Python 2 as both ASCII text and as byte sequences. While Python 2 also has a unicode string type, the fundamental ambiguity of the core string type, coupled with Python 2’s default behavior of supporting automatic coercion from 8-bit strings to unicode objects when the two are combined, often leads to UnicodeErrors. Python 3’s standard string type is Unicode based, and Python 3 adds a dedicated bytes type, but critically, no automatic coercion between bytes and unicode strings is provided. The closest the language gets to implicit coercion are a few text-based APIs that assume a default encoding (usually UTF-8) if no encoding is explicitly stated. Thus, the core interpreter, its I/O libraries, module names, etc. are clear in their distinction between unicode strings and bytes. Python 3’s unicode support even extends to the filesystem, so that non-ASCII file names are natively supported.

This string/bytes clarity is often a source of difficulty in transitioning existing code to Python 3, because many third party libraries and applications are themselves ambiguous in this distinction. Once migrated though, most UnicodeErrors can be eliminated.

Numbers

Python 2 has two basic integer types, a native machine-sized int type, and an arbitrary length long type. These have been merged in Python 3 into a single int type analogous to Python 2’s long type.

In addition, integer division now produces floating point numbers for non-integer results.

Classes

Python 2 has two core class hierarchies, often called classic classes and new-style classes. The latter allow for such things as inheriting from the builtin basic types, support descriptor based tools like the property builtin and provide a generally more sane and coherent system for dealing with multiple inheritance. Python 3 provided the opportunity to completely drop support for classic classes, so all classes in Python 3 automatically use the new-style semantics (although that’s a misnomer now). There is no need to explicitly inherit from object or set the default metatype to enable them (in fact, setting a default metatype at the module level is no longer supported - the default metatype is always object).

The mechanism for explicitly specifying a metaclass has also changed to use a metaclass keyword argument in the class header line rather than a metaclass magic attribute in the class body.

Multiple spellings

There are many cases in Python 2 where multiple spellings of some constructs exist, such as repr() and backticks, or the two inequality operators != and <>. In all cases, Python 3 has chosen exactly one spelling and removed the other (e.g. repr() and != were kept).

Imports

In Python 3, implicit relative imports within packages are no longer available - only absolute imports and explicit relative imports are supported. In addition, star imports (e.g. from x import *) are only permitted in module level code.

Also, some areas of the standard library have been reorganized to make the naming scheme more intuitive. Some rarely used builtins have been relocated to standard library modules.

Iterators and views

Many APIs, which in Python 2 returned concrete lists, in Python 3 now return iterators or lightweight views.