Feeds

Learning Python can be difficult. You can spend time reading a textbook or watching videos, but then struggle to actually put what you've learned into practice. Or you might spend a ton of time learning syntax and get bored or lose motivation. How can you increase your chances of success? By building Python projects. That way […] The post Python Projects for Beginners: The Best Way to Learn appeared first on Dataquest.

Planet Python is now syndicating the posts about Python of my blog. Thanks to the project maintainer Bruno Rocha for letting me join.You may think of Planet Python as the all-you-can-eat source of Python content.It’s an aggregator of dozens of blogs, podcasts, and other resources on the Python programming language. It syndicates posts that cover Python or are of interest to the Python community. Planet Python is a terrific resource for learning the language and keeping up with what’s going on in its ecosystem. I highly recommend that you subscribe to the RSS feed of Planet Python.If you’re reading this on Planet Python, hi there!About meI’m Paolo Amoroso, an Italian astronomy and space popularizer, a Google expert, and a podcaster. I’m a Python beginner as I started learning the language in December 2018. But I have been a hobby programmer since the home computer revolution of the early 1980s. And I have always had a soft spot for programming languages, paradigms, and compilers.My programming backgroundAfter reading extensively about and experimenting with as many languages as I could, in the 1990s I settled with the ones of the Lisp family, particularly Common Lisp, Scheme, and Emacs Lisp. I was also a Computer Science student (but didn't graduate) and contributed to a few open source Lisp projects.Although I first got in touch with Python in the early 1990s, I started learning it in some depth only in December 2018. My main motivation was to leverage its massive “batteries included” ecosystem of libraries, tools, and resources for my hobby and personal projects. And, of course, to have fun.What I post aboutIn the Python posts of my blog, the ones you’ll get via Planet Python, I will cover my experiences with learning and using the language, the books I read, the tools I use, and the projects I do. But, if you’re curious, feel free to look around to see what else I post about on my blog.I plan to use Python for coding projects related to my interests, especially astronomy and space, or to make simple personal tools and apps.Thanks again for having me here!This post by Paolo Amoroso was published on Moonshots Beyond the Cloud.

There have been a few thoughts about PyCon US 2019 that have been bouncing around my head, wanting to come out. Today, I want to talk about the opportunity to meet your Python heros, and why you should start planning on attending next year.Read more...

This has previously been published on opensource.com. The Zen of Python is loose enough and contradicts itself enough that you can prove anything from it. Let's meditate upon one of its most famous principles: "Explicit is better than implicit." One thing that traditionally has been implicit in Python is the expected interface. Functions have been documented to expect a "file-like object" or a "sequence." But what is a file-like object? Does it support .writelines? What about .seek? What is a "sequence"? Does it support step-slicing, such as a[1:10:2]? Originally, Python's answer was the so-called "duck-typing," taken from the phrase "if it walks like a duck and quacks like a duck, it's probably a duck." In other words, "try it and see," which is possibly the most implicit you could possibly get. In order to make those things explicit, you need a way to express expected interfaces. One of the first big systems written in Python was the Zope web framework, and it needed those things desperately to make it obvious what rendering code, for example, expected from a "user-like object." Enter zope.interface, which was part of Zope but published as a separate Python package. The zope.interface package helps declare what interfaces exist, which objects provide them, and how to query for that information. Imagine writing a simple 2D game that needs various things to support a "sprite" interface; e.g., indicate a bounding box, but also indicate when the object intersects with a box. Unlike some other languages, in Python, attribute access as part of the public interface is a common practice, instead of implementing getters and setters. The bounding box should be an attribute, not a method. A method that renders the list of sprites might look like: def render_sprites(render_surface, sprites): """ sprites should be a list of objects complying with the Sprite interface: * An attribute "bounding_box", containing the bounding box. * A method called "intersects", that accepts a box and returns True or False """ pass # some code that would actually render The game will have many functions that deal with sprites. In each of them, you would have to specify the expected contract in a docstring. Additionally, some functions might expect a more sophisticated sprite object, maybe one that has a Z-order. We would have to keep track of which methods expect a Sprite object, and which expect a SpriteWithZ object. Wouldn't it be nice to be able to make what a sprite is explicit and obvious so that methods could declare "I need a sprite" and have that interface strictly defined? Enter zope.interface. from zope import interface class ISprite(interface.Interface): bounding_box = interface.Attribute( "The bounding box" ) def intersects(box): "Does this intersect with a box" This code looks a bit strange at first glance. The methods do not include a self, which is a common practice, and it has an Attribute thing. This is the way to declare interfaces in zope.interface. It looks strange because most people are not used to strictly declaring interfaces. The reason for this practice is that the interface shows how the method will be called, not how it is defined. Because interfaces are not superclasses, they can be used to declare data attributes. One possible implementation of the interface can be with a circular sprite: @implementer(ISprite) @attr.s(auto_attribs=True) class CircleSprite: x: float y: float radius: float @property def bounding_box(self): return ( self.x - self.radius, self.y - self.radius, self.x + self.radius, self.y + self.radius, ) def intersects(self, box): # A box intersects a circle if and only if # at least one corner is inside the circle. top_left, bottom_right = box[:2], box[2:] for choose_x_from (top_left, bottom_right): for choose_y_from (top_left, bottom_right): x = choose_x_from[0] y = choose_y_from[1] if (((x - self.x) ** 2 + (y - self.y) ** 2) <= self.radius ** 2): return True return False This explicitly declares that the CircleSprite class implements the interface. It even enables us to verify that the class implements it properly: from zope.interface import verify def test_implementation(): sprite = CircleSprite(x=0, y=0, radius=1) verify.verifyObject(ISprite, sprite) This is something that can be run by pytest, nose, or another test runner, and it will verify that the sprite created complies with the interface. The test is often partial: it will not test anything only mentioned in the documentation, and it will not even test that the methods can be called without exceptions! However, it does check that the right methods and attributes exist. This is a nice addition to the unit test suite and -- at a minimum -- prevents simple misspellings from passing the tests. If you have some implicit interfaces in your code, why not document them clearly with zope.interface?

We are excited to announce a new release of Red Hat Dependency Analytics, a solution that enables developers to create better applications by evaluating and adding high-quality open source components, directly from their IDE. Red Hat Dependency Analytics helps your development team avoid security and licensing issues when building your applications. It plugs into the developer’s IDE, automatically analyzes your software composition, and provides recommendations to address security holes and licensing problems that your team may be missing. Without further ado, let’s jump into the new capabilities offered in this release. This release includes a new version of the IDE plugin and the server-side analysis service hosted by Red Hat. Support for Python applications Along with Java (maven) and JavaScript (npm), Dependency Analytics now offers its full set of capabilities for Python (PyPI) applications. From your IDE, you can perform the vulnerability and license analysis of the “requirements.txt” file of your Python application, incorporate the recommended fixes, and generate the stack analysis report for more details. Software composition analysis based on current vulnerability data An estimated 15,000 open source packages get updated every day. On average, three new vulnerabilities get posted every day across JavaScript (npm) and Python (PyPi) packages. With this new release, the server-side analysis service hosted by Red Hat automatically processes the daily updates to open source packages that it is tracking. The hosted service also automatically ingests new vulnerability data posted to National Vulnerability Database (NVD) for JavaScript and Python packages. This allows the IDE plugin and API calls to provide source code analysis based on current vulnerability and release data. Analyze transitive dependencies In addition to the direct dependencies included in your application, Dependency Analytics now leverages the package managers to discover and add the dependencies of those dependencies, called “transitive” dependencies, to the dependency graph of your application. Analysis of your application is performed across the whole graph model and recommendations for fixes are provided across the entire set of dependencies. Recommendations about complementary open source libraries With this release, Dependency Analytics looks to recommend high-quality open source libraries that are complementary to the dependencies included in your application. The machine learning technology of the hosted service collects and analyzes various statistics on GitHub to curate a list of high-quality open source libraries that can be added to the current set of dependencies to augment your application. You can provide your feedback about the add-on libraries by clicking on the “thumbs-up” or “thumbs-down” icons shown for each recommendation. Your feedback is automatically processed to improve the quality of the recommendations. IDE plugin support The Dependency Analytics IDE plugin is now available for VS Code, Eclipse Che, and any JetBrains IDE, including IntelliJ and PyCharm. We will continuously release new updates to our Dependency Analytics solution so you can minimize the delays in delivery of your applications due to last-minute security and licensing related issues. Stay tuned for further updates; we look forward to your feedback about Dependency Analytics. The post What’s new in Red Hat Dependency Analytics appeared first on Red Hat Developer.

Yesterday we had our webinar on React, TypeScript, and Test-Driven Development (TDD.) And…we had a special guest! Ekaterina Prigara, PMM for WebStorm, co-hosted and fielded most of the questions. Which was lucky for us: she really-really-really knows not just our IDE’s web development story, but all of these crazy technologies in the world of JavaScript. The recording is now available. As a programming note, I’m giving this webinar next week for IntelliJ IDEA and in November for Rider. But I also plan to do a second part for PyCharm next month, as we only covered half of the tutorial material. What We Covered This session was particularly enjoyable with its focus on staying in “the flow”, using both TDD and type information to “fail faster”, and letting the IDE do your janitorial work for you. 5m10s: Project Setup 11m56s: Project Cleanup 24m16s: Testing 35m24s: Debugging During Testing 53m26s: Debugging with Chrome 55m23s: TSX and ES6 Feedback Solicited! This is a departure from our normal format: all material published in advance (including narrated videos), repeating the same webinar topic across multiple topics, and splitting into two parts. It’s also less a survey-oriented webinar and more of a deep-dive tutorial-is webinar, from both the aspect of focusing on technologies and driving the IDE for those technologies. Let us know what you think! Would you like more of these? Shorter and in more parts? I say this because I’m wrapping up a similar multi-part “Visual Testing with pytest” tutorial and I’d like some kind of multi-webinar approach, if it’s considered valuable.

Your task is to find the first element of an array that is not consecutive. E.g. If we have an array [1,2,3,4,6,7,8] then 1 then 2 then 3 then 4 are all consecutive but 6 is not, so that’s the first non-consecutive number. If the whole array is consecutive then return None. The array will always have at least 2 elements1 and all elements will be numbered. The numbers will also all be unique and in ascending order. The numbers could be positive or negative and the first non-consecutive could be either too! Solution : Take out the first number in the array, then continue to add one to that number, if one of the summation outcomes is not the same as the next number in the array then the program will return that next number or else the program will return None if no non-consecutive number has been found. def first_non_consecutive(arr): seed = arr.pop(0) for num in arr: seed += 1 if num != seed: return num return None Any thoughts about the above solution? Please comment below. If you like any post on this website, please share on social media to help this site gets more readers!