Re: Looking for a way to include Pyhtho scripting INSIDE a python program

[Bryon]

On Apr 12, 10:16 pm, John Antypas <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I'm writing in tool in Python that manipulates various data objects read
> from various streams.  I wanted to give the user a chance to do advanced
> work that could not easily be done from a GUI.
>
> At first, I tried putting in a lightweight scripting language, and then
> I thought, why not include Python in itself -- it is certainly powerful
> enough.
>
> I had assumed I'd present the user with a text window in which they
> could type arbitrary python code.  I'd wrap that code around a function
> and pass that function a call of objects they could manipulate by
> calling the methods of that class.
>
> 1. How can a python program invoke ANOTHER interpreter?
> 2. How can I pass the class in as its argument and get the modified
> class back?
>
> I know I can do something very ugly -- call a C method that calls a new
> python interpreter but that seems VERY ugly.
>
> Help?
>
> Thanks.

I'm very new to python but I think this is what you're looking for

http://pydoc.org/2.5.1/__builtin__.html#-compile
-- 
http://mail.python.org/mailman/listinfo/python-list

Proposal about naming conventions around packaging

[Benoît Bryon]

Hi,

Here is a proposal about naming conventions around
packaging.

Main question is: would you accept it as a PEP?



Preliminary notes (not part of the proposal)


Before I start, here are some preliminary notes about the
context...


*
Situation
*

* first posted to distutils-sig list:
  http://mail.python.org/pipermail/distutils-sig/2012-May/018551.html

* then opened a ticket on CPython issue tracker:
  http://bugs.python.org/issue14899

* started to work in a fork...
  
https://bitbucket.org/benoitbryon/cpython/src/doc-package-names/Doc/packaging/packagenames.rst

* ... but this looks like a PEP. So, let's follow PEP 1
  and post a proposal here.


***
What follows is a draft
***

* First of all, I promise I did my best ;)

* I guess most points already have been discussed here or
  elsewhere. But since I couldn't find an official
  reference (i.e. a refused PEP), I believe consensus is
  possible.

* I splitted proposals in small sections, so
  that people can discuss or refuse some items while
  accepting others. If you see something that is not
  atomic, please propose a split.

* I tried to relate facts. But I feel like a newbie about
  some points, so, if you see something wrong or
  incomplete, please send information and/or sources.

* I tried to propose actions and take existing projects into
  account. In my humble opinion, motivations and proposals
  below seem reasonable enough. That's why I am posting
  here to get feedback from the community.

* Finally, I am not a native english speaker... feel free
  to improve vocabulary, grammar and so on :)

That said, let's go...

.. note::

   You can also get the following proposal online at
   
https://bitbucket.org/benoitbryon/cpython/src/doc-package-names/Doc/packaging/packagenames.rst

Thanks to Martin Aspeli for his article.
Thanks to early reviewers: Alexis Métaireau, Éric Bréhault,
Jean-Philippe Camguilhem and Mathieu Leplâtre.

Regards,
Benoit



###
Names in packaging: conventions and recipes
###

This document deals with:

* names of Python projects,
* names of distributions in projects,
* names of Python packages or modules being distributed,
* namespace packages.

It provides conventions and recipes for distribution authors.

Main use case is:

* as a developer, I want to create a project in order to distribute a package.
  So I have to choose names.  Which names are "good"?

* `The Zen of Python`_ says:

In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.

* So I need clear and official (i.e. obvious) guidelines or conventions that I
  can follow.

* Here are conventions, guidelines and recipes.

Guidelines for existing projects are also given.


***
Terminology
***

First of all, let's make sure there is no confusion...

Distribution name
  Distribution name is used by packaging utilities:

  * in :doc:`setup script`, it is the value passed as
``name`` to ``packaging.core.setup()``
  * it appears on `PyPI`_ if the package is registered on it
  * it can be used in `pip` requirements files
  * it can be used in `buildout` configuration files.

  Distribution term is introduced in :doc:`packaging docs`.

Egg name
  It is the same concept as distribution name. Technically, the egg is not the
  distribution. But they use the same name: it is declared as
  ``packaging.core.setup()`` name argument.

  "Egg" term is the legacy counterpart to "distribution". It was used by
  distutils and setuptools. It becomes deprecated with the new packaging
  module.

  This document focuses on distributions, not eggs.

Package and module names
  Package and module names are used in Python code. It is the string used in
  :ref:`import statements`.

  Remember that, from a file system perspective, packages are directories and
  modules are files.

  :ref:`Python packaging allows distributions to distribute several packages
  and/or modules`.

Project name
  Usually the name of the repository or folder in which distribution authors put
  their code. It generally is the directory name of the "distribution root",
  as defined in :ref:`packaging-term`.

Namespace packages
  It is common practice to use namespaces in package names. `PEP 420`_ brings
  this concept to core Python. When PEP 420 will be accepted, Python officially
  supports namespace packages.

As an example, consider `django-debug-toolbar`_:

* ``django-debug-toolbar`` is the distribution name. `It is declared in
  setup.py file
  
`_.

* ``debug_toolbar`` is the package name. It is what would appear in Django's
  INSTALLED_APPS setting or be used as ``i

Re: Remote/Pair-Programming in-the-cloud

[Bryon Tjanaka]

Depending on how often you need to run the code, you could use a google doc
and copy the code over when you need to run. Of course, if you need linters
and other tools to run frequently this would not work.

On Fri, Aug 2, 2019 at 4:50 PM Cameron Simpson  wrote:

> On 03Aug2019 11:39, DL Neil  wrote:
> >On 3/08/19 10:34 AM, Chris Angelico wrote:
> >>On Sat, Aug 3, 2019 at 7:30 AM DL Neil 
> wrote:
> >>>On 3/08/19 8:44 AM, Chris Angelico wrote:
> >>Google Hangouts, or a proprietary internal platform ("Owl") which does
> >>similar things but is better able to handle different bandwidth
> >>connections.
> >
> >Thanks. Will add to the mix...
>
> appear.in can also screen share along with its video conferencing, and I
> imagine Zoom might do so also. But a screen share is "read only" for the
> other party. You could both screen share of course, but it doesn't solve
> the keep-the-code-in-sync issue.
>
> Cheers,
> Cameron Simpson 
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 

[image: logo]

Bryon Tjanaka

*"Audentes fortuna iuvat"*
btjanaka.netgithub.com/btjanaka
-- 
https://mail.python.org/mailman/listinfo/python-list

Connect to Default Printer

[Bryon Fawcett]

Good afternoon.

Could you please advise me how to connect the python software to my default
printer.

Regards,

Bryon Fawcett.
-- 
https://mail.python.org/mailman/listinfo/python-list