SIOC Post profile for "AI3:::Adaptive Information"
type: Document
description: A SIOC profile describes the structure and contents of a weblog in a machine readable form. For more information please refer to http://sioc-project.org/.
primary topic: CWPK #33: A Python Package, Part I: The Annotation Extractor
generator agent: http://rdfs.org/sioc/wp-sioc.php

CWPK #33: A Python Package, Part I: The Annotation Extractor
type: Post
has container: weblog
has creator: Mike Bergman
maker: Mike Bergman
created: 2020-09-10T16:12:12Z
content: Generalization, Packaging, and Complexity Compel More Powerful Tools Over the past installments of this Cooking with Python and KBpedia series, we have been building up larger and more complex routines from our coding blocks. This approach has been great for learning and prototyping, but does not readily support building maintainable applications. This is a natural evolution in any code development that is moving towards real use and deployment. It is a step that Project Jupyter is also taking in its efforts to transition from Notebook to JupyterLab (see here). Their intent is to provide a complete code development environment as well as one suitable for interactive notebooks. Recent announcements aside, we picked the Spyder IDE and installed it in CWPK #11 for these same functional reasons, and will stay with it throughout this series because of its maturity and degree of acceptance within the data science community. But, JupyterLab looks to be a promising development. Whatever the tool, there comes a time when code proliferation and the need to manage it to a release condition warrants moving beyond prototyping. Now is that time with our project. We will use the packaging of our extraction routines begun in the last installment as our example case for how to proceed. We will continue to use Jupyter Notebook to discuss and present code snippets, but that material is now to be backed up with methods, code files, and modules, hopefully in an acceptable Python way. We will be using Spyder for these development purposes and referring to it in our documentation with screen captures and discussion as appropriate. We will also be releasing Python files as our installments proceed. But the transition to working code is more complicated than changing tool emphasis alone. Note: Though we begin formal packaging of our routines in this installment, it is not until CWPK #46 that a sufficient number of modules are developed to warrant the actual release of the package. An obsess…
encoded: Generalization, Packaging, and Complexity Compel More Powerful Tools Over the past installments of this Cooking with Python and KBpedia series, we have been building up larger and more complex routines from our coding blocks. This approach has been great for learning and prototyping, but does not readily support building maintainable applications. This is a natural evolution in any code development that is moving towards real use and deployment. It is a step that Project Jupyter is also taking in its efforts to transition from Notebook to JupyterLab (see here). Their intent is to provide a complete code development environment as well as one suitable for interactive notebooks. Recent announcements aside, we picked the Spyder IDE and installed it in CWPK #11 for these same functional reasons, and will stay with it throughout this series because of its maturity and degree of acceptance within the data science community. But, JupyterLab looks to be a promising development. Whatever the tool, there comes a time when code proliferation and the need to manage it to a release condition warrants moving beyond prototyping. Now is that time with our project. We will use the packaging of our extraction routines begun in the last installment as our example case for how to proceed. We will continue to use Jupyter Notebook to discuss and present code snippets, but that material is now to be backed up with methods, code files, and modules, hopefully in an acceptable Python way. We will be using Spyder for these development purposes and referring to it in our documentation with screen captures and discussion as appropriate. We will also be releasing Python files as our installments proceed. But the transition to working code is more complicated than changing tool emphasis alone. Note: Though we begin formal packaging of our routines in this installment, it is not until CWPK #46 that a sufficient number of modules are developed to warrant the actual release of the package. An obsess…
topic: CWPK
topic: KBpedia
topic: Semantic Web Tools
links to: Cooking with Python and KBpedia
links to: Project Jupyter
links to: here
links to: Spyder
links to: IDE
links to: CWPK #11
links to: DRY
links to: CWPK #18
links to: cb1-1
links to: cb1-2
links to: cb1-3
links to: cb1-4
links to: cb1-5
links to: cb1-6
links to: cb1-7
links to: cb1-8
links to: cb1-9
links to: cb1-10
links to: cb1-11
links to: cb1-12
links to: cb1-13
links to: cb1-14
links to: cb1-15
links to: cb1-16
links to: cb1-17
links to: cb1-18
links to: CWPK #32
links to: cb2-1
links to: cb2-2
links to: cb2-3
links to: cb2-4
links to: cb2-5
links to: cb2-6
links to: cb2-7
links to: cb2-8
links to: cb2-9
links to: cb2-10
links to: cb2-11
links to: cb2-12
links to: cb2-13
links to: cb2-14
links to: cb2-15
links to: cb2-16
links to: cb2-17
links to: cb2-18
links to: cb2-19
links to: cb2-20
links to: cb2-21
links to: cb2-22
links to: cb2-23
links to: cb2-24
links to: cb2-25
links to: cb2-26
links to: cb2-27
links to: cb2-28
links to: cb2-29
links to: cb2-30
links to: cb2-31
links to: cb2-32
links to: cb2-33
links to: cb2-34
links to: cb2-35
links to: cb2-36
links to: cb2-37
links to: cb2-38
links to: cb2-39
links to: cb2-40
links to: cb2-41
links to: cb2-42

Mike Bergman
type: User

Mike Bergman
type: Person

Cooking with Python and KBpedia
label: CWPK listing

CWPK #30

Style Guide (PEP 8)

'docstring' Conventions (PEP 257)

Python Project Structure and Imports

The Best of the Best Practices (BOBP) Guide for Python

Structuring Your Project

KBpedia

direct download

notify me