Op 21/08/20 om 01:49 schreef Cameron Simpson:
On 16Aug2020 08:32, Marco Sulla wrote:
Sorry, didn't read well, Apart the other suggestion, you (or your
sysop) can create a private Pypi:
https://pypi.org/project/private-pypi/
Even simpler, you can put a code repo path into your requirements.
On 16Aug2020 08:32, Marco Sulla wrote:
>Sorry, didn't read well, Apart the other suggestion, you (or your
>sysop) can create a private Pypi:
>https://pypi.org/project/private-pypi/
Even simpler, you can put a code repo path into your requirements.txt
(or directly with pip via its "-e" option). E
Sorry, didn't read well, Apart the other suggestion, you (or your
sysop) can create a private Pypi:
https://pypi.org/project/private-pypi/
--
https://mail.python.org/mailman/listinfo/python-list
Does the word "public" mean world-wide, or perhaps only amongst your
work-colleagues?
Only among work-colleagues.
We only want that anyone writing and running python scripts on particular
hosts, can
easily import these modules/packages.
Of possible interest:-
Private Python package managem
Op 15/08/20 om 07:33 schreef dn via Python-list:
> On 14/08/2020 22:32, Antoon Pardon wrote:
>> Well the question is in the subject.
>>
>> I have a number of modules/packages which were until recently
>> personal use only. However python is getting more popular
>> at work and some of my work was co
On 14/08/2020 22:32, Antoon Pardon wrote:
Well the question is in the subject.
I have a number of modules/packages which were until recently
personal use only. However python is getting more popular
at work and some of my work was considered useful enough to
install in a public available spot.
https://www.google.com/search?channel=fs&client=ubuntu&q=publish+python+code
First result.
--
https://mail.python.org/mailman/listinfo/python-list
Well the question is in the subject.
I have a number of modules/packages which were until recently
personal use only. However python is getting more popular
at work and some of my work was considered useful enough to
install in a public available spot.
How should I approach this?
--
Antoon.
--
On Tuesday, 8 May 2018 13:05:58 UTC+5:30, Steven D'Aprano wrote:
> On Mon, 07 May 2018 09:53:45 -0700, Sharan Basappa wrote:
>
> > I am a bit confused between module and package in Python. Does a module
> > contain package or vice versa? When we import something in Python, do we
> > import a modu
On Mon, 07 May 2018 09:53:45 -0700, Sharan Basappa wrote:
> I am a bit confused between module and package in Python. Does a module
> contain package or vice versa? When we import something in Python, do we
> import a module or a package?
The term "module" in Python has multiple meanings:
- a pa
Sharan Basappa writes:
> One question. So, we can import the entire package or just a module in
> a given package. Is this correct?
Each time you ‘import foo’, you are getting a module.
> For example,
> import nltk
That results in a module object, and you can use the name ‘nltk’ to
reference t
MRAB, ChirisA,
One question. So, we can import the entire package or just a module in a given
package. Is this correct?
For example,
import nltk
import nltk.stem
--
https://mail.python.org/mailman/listinfo/python-list
On Monday, 7 May 2018 23:09:41 UTC+5:30, Chris Angelico wrote:
> On Tue, May 8, 2018 at 2:53 AM, Sharan Basappa
> wrote:
> > I am a bit confused between module and package in Python.
> > Does a module contain package or vice versa?
> > When we import something in Python, do we import a module or
On Tue, May 8, 2018 at 2:53 AM, Sharan Basappa wrote:
> I am a bit confused between module and package in Python.
> Does a module contain package or vice versa?
> When we import something in Python, do we import a module or a package?
You import a module.
A package is one particular form of modu
On 2018-05-07 17:53, Sharan Basappa wrote:
I am a bit confused between module and package in Python.
Does a module contain package or vice versa?
When we import something in Python, do we import a module or a package?
A module is a file. A package is a collection of one or more modules.
--
http
I am a bit confused between module and package in Python.
Does a module contain package or vice versa?
When we import something in Python, do we import a module or a package?
Thanks
--
https://mail.python.org/mailman/listinfo/python-list
Hi Folks,
I am trying to do the following.
I have a moderately complex python module/application X, whose source code i
have access to.
I run X with the following command
python x.py ...
Internally, x.py callls y.py, which in turn calls z.py, etc etc
x.py ---> y.py ---> z.py ---> u.py --
Big Stu writes:
> I'm hoping someone on here can point me to an example of a python
> package that is a great example of how to put it all together. I'm
> hoping for example code that demonstrates [good adherence to style and
> practice conventions]
I find the code base for Bazaar to be particu
Josh Holland writes:
> On 2010-01-28, exar...@twistedmatrix.com wrote:
> > Have you actually looked at any of the standard library?
> Not recently or in depth, no. I would have thought that it would be of
> high quality. I must have been mistaken.
Style conventions were introduced relatively la
On 07:49 pm, stu.dohe...@gmail.com wrote:
Have you actually looked at any of the standard library?
Jean-Paul
I'm looking at urllib2 right now and it is covering a bunch of the
bases I'm looking for. And grepping in the /usr/lib/python2.5/ folder
for import statements on various things I'm i
> Have you actually looked at any of the standard library?
>
> Jean-Paul
I'm looking at urllib2 right now and it is covering a bunch of the
bases I'm looking for. And grepping in the /usr/lib/python2.5/ folder
for import statements on various things I'm interested in is bringing
up some good exa
On 2010-01-28, exar...@twistedmatrix.com wrote:
> Have you actually looked at any of the standard library?
Not recently or in depth, no. I would have thought that it would be of
high quality. I must have been mistaken.
--
Josh "dutchie" Holland
http://www.joshh.co.uk/
http://twitter.com/jshholl
On 28 ene, 19:17, Big Stu wrote:
> I'm hoping someone on here can point me to an example of a python
> package that is a great example of how to put it all together. I'm
> hoping for example code that demonstrates:
>
> -Strict adherence to PEP 8
> -thorough use of Docstrings
> -Conventional direc
On Jan 28, 2:28 pm, Josh Holland wrote:
> On 2010-01-28, Big Stu wrote:
>
> > I'm hoping someone on here can point me to an example of a python
> > package that is a great example of how to put it all together. I'm
> > hoping for example code that demonstrates:
>
> Surely most of the Standard Li
On 07:28 pm, j...@joshh.co.uk wrote:
On 2010-01-28, Big Stu wrote:
I'm hoping someone on here can point me to an example of a python
package that is a great example of how to put it all together. I'm
hoping for example code that demonstrates:
Surely most of the Standard Library should satisf
On 2010-01-28, Big Stu wrote:
> I'm hoping someone on here can point me to an example of a python
> package that is a great example of how to put it all together. I'm
> hoping for example code that demonstrates:
Surely most of the Standard Library should satisfy all your
requirements?
--
Josh
I'm hoping someone on here can point me to an example of a python
package that is a great example of how to put it all together. I'm
hoping for example code that demonstrates:
-Strict adherence to PEP 8
-thorough use of Docstrings
-Conventional directory structure/package layout
-Appropriate use
On Jan 31, 12:27 am, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
> Python stores filename and line number information in code objects
> (only). If you have a reference to any code object (a method, a
> function, a traceback...) inspect can use it to retrieve that
> information.
Aside from general
Peter Schuller <[EMAIL PROTECTED]> writes:
> I *DON'T* want anything to depend on the physical location on disk.
Importing the code in the first place will — unavoidably, it seems to
me — depend on the file location from which to load the module.
After that, nothing depends on the physical locat
> It what sense will it not be? Why do you care so much about where the
> source code for Monkey is defined? If you actually want to read the
> source, you might need to follow the chain from "animal", see that Monkey
> is imported from "monkey", and go look at that. But the rest of the time,
>
> Well, all I will say is that many people on this list, myself
> included, do know Python internals, and we use the method we've been
> suggesting here, without problems.
Ok. That is useful to know (that it is being done in practice without
problems).
Thanks!
--
/ Peter Schuller
PGP userID: 0
On Jan 30, 4:31 am, Peter Schuller <[EMAIL PROTECTED]>
wrote:
> I don't know Python internals enough to state of believe with any
> authority wither, let's say, stomping __module__ and hacking
> sys.modules would be enough to *truly* do it correctly in a proper way
> such that it is entirely transp
On 30 ene, 12:00, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> I call that a bug in the inspect module. In fact, looking at the source
> for the findsource() function, I can see no fewer than two bugs, just in
> the way it handles classes:
>
> (1) it assumes that the only way to
On Tue, 29 Jan 2008 06:48:59 -0600, Peter Schuller wrote:
>> You can also put, in animal/__init__.py:
>> from monkey import Monkey
>> and now you can refer to it as org.lib.animal.Monkey, but keep the
>> implementation of Monkey class and all related stuff into
>> .../animal/monkey.py
>
> The pr
On Tue, 29 Jan 2008 13:44:33 -0600, Robert Kern wrote:
> Carl Banks wrote:
>> On Jan 29, 7:48 am, Peter Schuller <[EMAIL PROTECTED]> wrote:
You can also put, in animal/__init__.py:
from monkey import Monkey
and now you can refer to it as org.lib.animal.Monkey, but keep the
imp
>> The problem is that we are now back to the identity problem. The class
>> won't actually *BE* org.lib.animal.Monkey.
>
> The usage is the same; it works in all cases once you redefine
> __module__. Who cares what it really is?
The cases I listed were just examples. My point was that I wanted i
Carl Banks wrote:
> On Jan 29, 7:48 am, Peter Schuller <[EMAIL PROTECTED]>
> wrote:
>>> You can also put, in animal/__init__.py:
>>> from monkey import Monkey
>>> and now you can refer to it as org.lib.animal.Monkey, but keep the
>>> implementation of Monkey class and all related stuff into
>>> ..
On Jan 29, 7:48 am, Peter Schuller <[EMAIL PROTECTED]>
wrote:
> > You can also put, in animal/__init__.py:
> > from monkey import Monkey
> > and now you can refer to it as org.lib.animal.Monkey, but keep the
> > implementation of Monkey class and all related stuff into
> > .../animal/monkey.py
>
>
> You can reassign the class's module:
>
> from org.lib.animal.monkey import Monkey
> Monkey.__module__ = 'org.lib.animal'
>
>
> (Which, I must admit, is not a bad idea in some cases.)
Is there a sense whether this is truly a supported way of doing this,
in terms of not running into various uninte
> You can also put, in animal/__init__.py:
> from monkey import Monkey
> and now you can refer to it as org.lib.animal.Monkey, but keep the
> implementation of Monkey class and all related stuff into
> .../animal/monkey.py
The problem is that we are now back to the identity problem. The class
Carl Banks <[EMAIL PROTECTED]> writes:
> On Jan 25, 6:45 pm, Ben Finney <[EMAIL PROTECTED]>
> wrote:
> > "Gabriel Genellina" <[EMAIL PROTECTED]> writes:
> > > You can also put, in animal/__init__.py:
> > > from monkey import Monkey
> > > and now you can refer to it as org.lib.animal.Monkey, but ke
On Jan 25, 6:45 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> "Gabriel Genellina" <[EMAIL PROTECTED]> writes:
> > You can also put, in animal/__init__.py:
> > from monkey import Monkey
> > and now you can refer to it as org.lib.animal.Monkey, but keep the
> > implementation of Monkey class and all re
"Gabriel Genellina" <[EMAIL PROTECTED]> writes:
> You can also put, in animal/__init__.py:
> from monkey import Monkey
> and now you can refer to it as org.lib.animal.Monkey, but keep the
> implementation of Monkey class and all related stuff into
> .../animal/monkey.py
This (as far as I can unde
En Thu, 24 Jan 2008 11:57:49 -0200, Peter Schuller
<[EMAIL PROTECTED]> escribió:
> In this case my
> problem is more related to the "file == module" and "directory ==
> module" semantics, since I want to break contents in a single module
> out into several files.
You already can do that, just i
>> Not necessarily. In part it is the name, in that __name__ will be
>> different. But to the extent that calling code can potentially import
>> them under differents names, it's identity. Because importing the same
>> module under two names results in two distinct modules (two distinct
>> module o
En Thu, 24 Jan 2008 05:16:51 -0200, Peter Schuller
<[EMAIL PROTECTED]> escribió:
>>> I do *not* want to simply break out X into org.lib.animal.x, and
>>> have org.lib.animal import org.lib.animal.x.X as X.
>>
>>> While this naively solves the problem of being able to refer to X as
>>> org.lib.an
On Jan 23, 4:49 am, Peter Schuller <[EMAIL PROTECTED]>
wrote:
> I do *not* want to simply break out X into org.lib.animal.x, and have
> org.lib.animal import org.lib.animal.x.X as X. While this naively
> solves the problem of being able to refer to X as org.lib.animal.X,
> the solution is anything
>> I do *not* want to simply break out X into org.lib.animal.x, and
>> have org.lib.animal import org.lib.animal.x.X as X.
>
> Nevertheless, that seems the best (indeed, the Pythonic) solution to
> your problem as stated. Rather than just shooting it down, we'll have
> to know more about ehat actua
Peter Schuller <[EMAIL PROTECTED]> writes:
> Let me just shoot down one possible suggestion right away, to show
> you what I am trying to accomplish:
>
> I do *not* want to simply break out X into org.lib.animal.x, and
> have org.lib.animal import org.lib.animal.x.X as X.
Nevertheless, that seem
On Wed, 23 Jan 2008 03:49:56 -0600, Peter Schuller wrote:
> Let me just shoot down one possible suggestion right away, to show you
> what I am trying to accomplish:
>
> I do *not* want to simply break out X into org.lib.animal.x, and have
> org.lib.animal import org.lib.animal.x.X as X.
Then you
Hello,
In writing some non-trivial amount of Python code I keep running into
an organizational issue. I will try to state the problem fairly
generally, and follow up with a (contrived) example.
The root cause of my difficulties is that by default, the relationship
between a module hierarchy and t
aspineux wrote:
> import os.path
>
> file=open(os.path.join(os.path.dirname(__file__), 'hauteur.yaml'))
Thanks that worked ;)
--
http://mail.python.org/mailman/listinfo/python-list
The filename and its path is in global variable __file__ (that is
different in any source file)
try
import os.path
file=open(os.path.join(os.path.dirname(__file__), 'hauteur.yaml'))
On 30 mai, 22:22, EuGeNe Van den Bulke <[EMAIL PROTECTED]>
wrote:
> Hi there,
>
> I have a "problem" which co
Hi there,
I have a "problem" which could be a bad design on my behalf but I am not
sure so ...
I have a package WMI which contains a module hauteur.py which, when
imported, load data from a file located in WMI/data/. In hauteur.py I
call open('data/hauteur.yaml').
test.py
WMI/
hauteur.py
Christoph Haas wrote:
> Evening,
>
> I'm currently working on a larger Python project that consists of multiple
> programs and packages. As I need a few utility functions time and again I
> moved them all into a Utility package and created a class there.
...
> As I know that importing packages fro
Christoph Haas wrote:
> As I know that importing packages from multiple modules always keeps it a
> singleton I thought of something like this:
>
> Util.py:
>
> debugFlag = False
> vibranceLevel = 'good'
>
> def function1():
>global debugFlag
>print debugFlag
The global line is
Evening,
I'm currently working on a larger Python project that consists of multiple
programs and packages. As I need a few utility functions time and again I
moved them all into a Utility package and created a class there. Like this:
Util.py:
class Util:
def __init__(self, debugFlag=F
Ben Finney <[EMAIL PROTECTED]> wrote:
> "Panos Laganakos" <[EMAIL PROTECTED]> writes:
>
> > Is there a way to have a whole module package use the new-style
> > classes, without having to specify it per module-file or even worse,
> > per class defi
"Panos Laganakos" <[EMAIL PROTECTED]> writes:
> Is there a way to have a whole module package use the new-style
> classes, without having to specify it per module-file or even worse,
> per class definition?
TTBOMK, you do that with a single statement per module, bef
Is there a way to have a whole module package use the new-style
classes, without having to specify it per module-file or even worse,
per class definition?
Maybe by declaring the __metaclass__ in the module's __init__.py?
--
http://mail.python.org/mailman/listinfo/python-list
60 matches
Mail list logo