Re: constructor classmethods

[Steven D'Aprano]

On Thursday 03 November 2016 00:46, stest...@gmail.com wrote:

> Hi
> 
> I was hoping to canvas opinion on using classmethods as constructors over
> __init__.
> 
> We've got a colleague who is very keen that __init__ methods don't contain
> any logic/implementation at all, and if there is any, then it should be moved
> to a create() classmethod.

Is your colleague expecting the caller to directly call this create() method? 
In other words, is create() part of the public API for the users of the class, 
as in the following:

instance = MyClass.create(arg)

instead of this?

instance = MyClass(arg)


I think that's just being unconventional for the sake of being unconventional. 
The standard Python API for classes is to call the class name, we write:

x = float(arg)
d = dict(mapping, key=value)
obj = object()

rather than float.create(arg), dict.create(...) and object.create(). Go through 
the entire Python standard library, and you'll see that virtually ALL classes 
and types -- not just "primitives" like float and dict -- behave like this.

There are a handful of classes which provide an Alternate Constructor API, e.g. 
dict.fromkeys(sequence_of_keys). But that offers a distinct, separate API for 
creating dicts. Hence the *alternate* part.

The bottom line is, the standard way to call MyClass.create(arg) in Python is 
to leave out the ".create".

But perhaps create is meant to be part of the *internal* implementation, not an 
external API. In that case, things get a bit more interesting... see below.


> As a concrete example, one change proposed was to go from this:
> 
> ```
> def __init__(self, ...):
> self.queue = Queue.Queue()
> 
> to this:
> 
> def __init__(self, queue):
> self.queue = queue


That's the Dependency Injection design pattern. It's so trivially easy in 
Python that it hardly even deserves the name "Design Pattern". But trivial or 
not, it's very useful! You just have to write it the smart way.


> @classmethod
> def create(cls, ...):
> return cls(Queue.Queue())
> 

This is not the smart way. This requires the caller to either create their own 
queue (occasionally useful, but not something you want to do all the time) or 
else call a non-standard constructor method.

The smart way of doing optional dependency injection is like this:


def __init__(self, queue=None):
if queue is None:
queue = Queue.Queue()
self.queue = queue


In more complex cases I can see the wisdom of writing a separate method:

def __init__(self, widget=None):
if widget is None:
widget = self._build_widget(spam, eggs, cheese, tomato)
self.widget = widget

def _build_widget(self, a, b, c, d):
...
return widget


Note that the create method, _build_widget(), is flagged as private by the 
leading underscore. Users should not call it (or they do so at their own risk); 
subclasses may override or replace the _build_widget method.

That may be what your colleague is thinking about. If so, then I can see that 
it *may* be a useful technique in some cases. But my guess is that he is over-
engineering your classes and planning for things that will never happen. 
Remember KISS and YAGNI.

You can always come back and insert a _build_widget() method into your class 
when you need it.


> The rationale is that it decouples the class from the queue implementation
> (no evidence or suggestion that we would actually ever want to change impl in
> this case), and makes testing easier.
> 
> I get the underlying principal, and it's one that a strict OOp approach would
> suggest, but my gut feeling is that this is not a pythonic approach at all.

Being able to pass in an optional dependency (the queue, in your example above) 
is a useful, Pythonic thing to do. Making it optional is even more Pythonic. 

But factoring out the call to Queue.Queue() into its own method just for the 
sake of OO purity is not very Pythonic, and *requiring* the caller to call this 
create() method is anti-Pythonic.



-- 
Steven
299792.458 km/s — not just a good idea, it’s the law!

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

Re: Released: pip v9.0.0

[Ian Cordasco]

Pick check? ;-)

On Nov 2, 2016 2:27 PM, "Donald Stufft"  wrote:

> I’d like to announce the release of pip v9.0.
>
> This release features:
>
> * The 9.x series will be the last pip versions to support Python 2.6.
> * Support for Requires-Python (will require additional support in
> setuptools/PyPI) to allow releasing sdists that will be ignored by specific
> versions of Python (e.g. foobar 5.x doesn’t get downloaded on 2.6).
> * Ability to pass platform, Python version, implementation, etc into ``pip
> download`` to download wheels for other platforms.
> * Add a ``pick check`` command to check the state of installed
> dependencies.
> * Add new formats for ``pip list``, including a new columnar layout and a
> JSON format for ease of scripting.
>
> For a full list of changes, see https://pip.pypa.io/en/stable/news/ <
> https://pip.pypa.io/en/stable/news/>.
>
> —
> Donald Stufft
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-announce-list
>
> Support the Python Software Foundation:
> http://www.python.org/psf/donations/
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: advanced SimpleHTTPServer?

[justin walters]

On Wed, Nov 2, 2016 at 12:52 PM, Eric S. Johansson  wrote:

> So this brings me back to my question. What is missing in
> SimpleHTTPServer to keep it from being secure enough?
>

There's no way to vet requests. You can't stop a request from accessing
anything
in the directory that SimpleHTTPServer is running in. I'm sure an
enterprising
individual could also probably access the shell session SimpleHTTPServer
is running in as well. I haven't looked into the internals very much, but
it is possible
an attacker could use eval() to run a Python script sent in a request body.
Not
sure about that last one. I'll have to try it myself and report back.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: advanced SimpleHTTPServer?

[Eric S. Johansson]

On 11/2/2016 2:40 PM, Chris Warrick wrote:
> Because, as the old saying goes, any sufficiently complicated Bottle
> or Flask app contains an ad hoc, informally-specified, bug-ridden,
> slow implementation of half of Django. (In the form of various plugins
> to do databases, accounts, admin panels etc.)

That's not a special attribute of bottle, flask or Django. Ad hoc,
informally specified, bug ridden slow implementations abound.  We focus
too much on scaling up and not enough on scaling down. We (designers) 
also have not properly addressed configuration complexity issues.

If I'm going do something once, if it cost me more than a couple of
hours to figure it out, it's too expensive in general but definitely if
I forget what I learned. That's why bottle/flask systems meet and need.
They're not too expensive to forget what you learned.

Django makes the cost of forgetting extremely expensive. I think of
using Django as career  rather than a toolbox.

So this brings me back to my question. What is missing in
SimpleHTTPServer to keep it from being secure enough?


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

Re: advanced SimpleHTTPServer?

[justin walters]

On Wed, Nov 2, 2016 at 11:40 AM, Chris Warrick  wrote:

> The other frameworks are simple to set up, too. I’ve personally had
> Unicode issues with Bottle, and it doesn’t even do sessions. Unlike
> Flask, or of course Django.
>
> Because, as the old saying goes, any sufficiently complicated Bottle
> or Flask app contains an ad hoc, informally-specified, bug-ridden,
> slow implementation of half of Django.
>
> (In the form of various plugins to do databases, accounts, admin panels
> etc.)
>


I've found this to be the case whenever I see a Flask or Bottle project
that does anything
more than expose a data API. I think Flask is great for building small
applications or
microservices. Any more and you are essentially hacking together a bunch of
packages
that may or may not have been designed to work together.

I find that Django can suit almost any use case perfectly well. You can use
whatever part
of the framework you want and toss out/replace any part you don't want.
Plus, built in sessions
and authentication are fantastic time savers.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: advanced SimpleHTTPServer?

[Chris Warrick]

On 2 November 2016 at 17:56, Eric S. Johansson  wrote:
>> Instead, you should use a real web server, such as nginx or apache.
>> Those will do the first two properly, and the last one could be
>> handled by a simple-ish PHP script. Or a full-fledged app in Django or
>> Flask if you feel like it.
> or bottle.  why does everyone seem to forget bottle? simple to set up,
> easy to learn and useful for small to medium projects.

The other frameworks are simple to set up, too. I’ve personally had
Unicode issues with Bottle, and it doesn’t even do sessions. Unlike
Flask, or of course Django.

Because, as the old saying goes, any sufficiently complicated Bottle
or Flask app contains an ad hoc, informally-specified, bug-ridden,
slow implementation of half of Django.

(In the form of various plugins to do databases, accounts, admin panels etc.)

-- 
Chris Warrick 
PGP: 5EAAEA16
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Django Application Model Reference

[Dreyton Scott]

On Wednesday, November 2, 2016 at 1:40:35 PM UTC-4, Dreyton Scott wrote:
> Hello. I am currently creating a notification django application that will 
> need to be able to "hook" into another django application. What my app needs 
> is a way to retrieve all model classes in the connected application. Is there 
> a way to do this?

In a way such that my app (a) is connected to app (b). Have (a) retrieve all 
model class instances in the connected app (b). Is that possible?
-- 
https://mail.python.org/mailman/listinfo/python-list

Django Application Model Reference

[Dreyton Scott]

Hello. I am currently creating a notification django application that will need 
to be able to "hook" into another django application. What my app needs is a 
way to retrieve all model classes in the connected application. Is there a way 
to do this?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: advanced SimpleHTTPServer?

[Eric S. Johansson]

On 11/2/2016 12:15 PM, Chris Warrick wrote:
> SimpleHTTPServer is meant to be used for development and testing. It
> should not be used for anything remotely serious for security and
> speed reasons. 

Given that many people are trying to use SimpleHTTPServer for
"production" should teach us that the existing http servers are overly
complex or at the least, not meeting needs when folks are scaling down
services.  for example, I've written any number of "small" webapps with
a user base of 5-10. do I need apache+cgi/uwsgi+bottle? no.  I need
something like SimpleHTTPServer only more production ready.

serious Q: what would it take to make SimpleHTTPServer more secure.  It
is currently fast enough.  when I run bottle with it's derivative of 
SimpleHTTPServer, it is as fast as apache+uwsgi+bottle for 1-10 users
and much much easier to set up.

> Instead, you should use a real web server, such as nginx or apache.
> Those will do the first two properly, and the last one could be
> handled by a simple-ish PHP script. Or a full-fledged app in Django or
> Flask if you feel like it.
or bottle.  why does everyone seem to forget bottle? simple to set up,
easy to learn and useful for small to medium projects. 

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

Re: advanced SimpleHTTPServer?

[Chris Warrick]

On 2 November 2016 at 08:27, Ulli Horlacher
 wrote:
> "python -m SimpleHTTPServer" is really cool :-)
>
> But I need some more features:
>
> - some kind of a chroot, to prevent file access higher then the base
>   directory
>
> - a directory listing mit date and size information
>
> - an upload possibility
>
> I could modify /usr/lib/python2.7/SimpleHTTPServer.py by myself, but maybe
> someone already has implemented these features?
>
> Use case: users with notebooks in a foreign (WiFi) LAN want to exchange
> some files on-the-fly, quick-and-dirty. Using USB sticks is a no-go! :-)

SimpleHTTPServer is meant to be used for development and testing. It
should not be used for anything remotely serious for security and
speed reasons.

Instead, you should use a real web server, such as nginx or apache.
Those will do the first two properly, and the last one could be
handled by a simple-ish PHP script. Or a full-fledged app in Django or
Flask if you feel like it.

-- 
Chris Warrick 
PGP: 5EAAEA16
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Recursive generator in Python 3.5

[congloi1990]

Thank you so much, this all clear for me now
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: constructor classmethods

[Terry Reedy]

On 11/2/2016 9:46 AM, stest...@gmail.com wrote:

Hi

I was hoping to canvas opinion on using classmethods as constructors over 
__init__.

We've got a colleague who is very keen that __init__ methods don't contain any 
logic/implementation at all, and if there is any, then it should be moved to a 
create() classmethod.

As a concrete example, one change proposed was to go from this:

```
def __init__(self, ...):
self.queue = Queue.Queue()

to this:

def __init__(self, queue):
self.queue = queue

@classmethod
def create(cls, ...):
return cls(Queue.Queue())


Even with the above fixed to properly pass on the ... part, UGH!  It 
violate Occam's Razor and is harder to read. thi



The rationale is that it decouples the class from the queue implementation (no 
evidence or suggestion that we would actually ever want to change impl in this 
case),


It just moves the dependency to a different method.

> and makes testing easier.

If one wants to replace the the Queue with a MockQueue for testing, amd 
the class is named 'C', one can do


c = C(...)
c.queue = MockQueue()

or one can revise __init__ to allow for dependency injection

class C:
def __init__(self, ..., queue=None):
if queue is None:
queue = Queue.Queue

and the test can have

c = C(..., queue=MockQueue)


I get the underlying principal, and it's one that a strict OOp approach would 
suggest, but my gut feeling is that this is not a pythonic approach at all.


Perhaps your collegue uses languages that do not have default arguments, 
which make his alternative unnecessary for Python.



What do people feel about this?


AFAIK, the stdlib only has alternate constructor classmethods as 
specialized alternatives to __init__, not as replacements. Examples are 
dict.fromkeys, int.from_bytes, and other .fromxyz methods.  These are 
used when multiplexing the .__init__ API to include the alternate 
constructor args is considered worse than adding an extra method.


>>> int(30.3)
30
>>> int('30')
30
>>> int(b'30')
30
>>> int(b'30', 12)
36
>>> int.from_bytes(b'30', 'big')
13104
>>> int.from_bytes(b'30', 'little')
12339


--
Terry Jan Reedy

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

Re: constructor classmethods

[Ethan Furman]

On 11/02/2016 06:46 AM, stest...@gmail.com wrote:


I was hoping to canvas opinion on using classmethods as constructors over 
__init__.

We've got a colleague who is very keen that __init__ methods don't contain any 
logic/implementation at all, and if there is any, then it should be moved to a 
create() classmethod.


So every Python programmer who is used to creating new instances with 
`ThatThing()` will have to learn that some of your classes need to be 
`ThatThing.create()` ?

Horrible idea.

The purpose of classmethods that create the same kind of object is to provide 
constructors that take different things -- for example:

class date(object):

def __init__(self, year, month, day):
self.year = year
self.month = month
self.day = day

@classmethod
def from_stardate(cls, sd):
ad = sd - SOME_CONSTANT_VALUE
year = ...
month = ...
day = ...
return cls(year, month, day)

If the goal is to make testing easier, one way to do that is:

def __init__(self, ..., queue=None):
if queue is None:
queue = Queue.Queue()
self.queue = queue

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: constructor classmethods

[breamoreboy]

On Wednesday, November 2, 2016 at 1:47:00 PM UTC, stes...@gmail.com wrote:
> Hi
> 
> I was hoping to canvas opinion on using classmethods as constructors over 
> __init__.
> 
> We've got a colleague who is very keen that __init__ methods don't contain 
> any logic/implementation at all, and if there is any, then it should be moved 
> to a create() classmethod.
> 
> As a concrete example, one change proposed was to go from this:
> 
> ```
> def __init__(self, ...):
> self.queue = Queue.Queue()
> 
> to this:
> 
> def __init__(self, queue):
> self.queue = queue
> 
> @classmethod
> def create(cls, ...):
> return cls(Queue.Queue())
> 
> ```
> 
> The rationale is that it decouples the class from the queue implementation 
> (no evidence or suggestion that we would actually ever want to change impl in 
> this case), and makes testing easier.
> 
> I get the underlying principal, and it's one that a strict OOp approach would 
> suggest, but my gut feeling is that this is not a pythonic approach at all.
> 
> What do people feel about this?
> 
> Thanks
> 
> Steve

I suggest that you read this 
https://docs.python.org/3/reference/datamodel.html#object.__new__ before you do 
anything.

Kindest regards.

Mark Lawrence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: constructor classmethods

[Chris Angelico]

On Thu, Nov 3, 2016 at 12:46 AM,   wrote:
> We've got a colleague who is very keen that __init__ methods don't contain 
> any logic/implementation at all, and if there is any, then it should be moved 
> to a create() classmethod.
>
> I get the underlying principal, and it's one that a strict OOp approach would 
> suggest, but my gut feeling is that this is not a pythonic approach at all.
>
> What do people feel about this?

Will you ever call the normal constructor? If the class depends on a
queue, as in your example, what happens if you call it with the same
queue as another instance is using, or something other than a queue,
etc, etc, etc? What this model does is introduce a whole lot of new
bug possibilities, for no particular reason.

I'll split your rationale into two:

> The rationale is that it decouples the class from the queue implementation 
> (no evidence or suggestion that we would actually ever want to change impl in 
> this case),
>

Then don't bother. YAGNI. No benefit unless you actually know you want this.

> and makes testing easier.
>

This is an important consideration, but shouldn't infect the primary
API. Design __init__ for normal usage, and if you need a mock queue
for testing, design an alternative way to construct one with a mock
queue. One way is to subclass your class to make a "mocked_class",
which then uses a mocked queue and whatever else it needs; another way
would be a static "_create_for_testing" function. Or you could just
create one as normal, then reach inside and replace its queue, but
that seems a tad risky (at very least, I'd make a method
"_replace_queue_for_testing" in the main class, so you have a chance
of noticing the problem as you're editing).

Ideally, testing should be done on the exact same code that you're
running, because otherwise you risk proving nothing. Minimize the code
used specifically for testing, and try to isolate it where possible.
And only warp the code when you *know* you need to - don't craft your
class's API around "well, we *might* need this for testing".

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

constructor classmethods

[stestagg]

Hi

I was hoping to canvas opinion on using classmethods as constructors over 
__init__.

We've got a colleague who is very keen that __init__ methods don't contain any 
logic/implementation at all, and if there is any, then it should be moved to a 
create() classmethod.

As a concrete example, one change proposed was to go from this:

```
def __init__(self, ...):
self.queue = Queue.Queue()

to this:

def __init__(self, queue):
self.queue = queue

@classmethod
def create(cls, ...):
return cls(Queue.Queue())

```

The rationale is that it decouples the class from the queue implementation (no 
evidence or suggestion that we would actually ever want to change impl in this 
case), and makes testing easier.

I get the underlying principal, and it's one that a strict OOp approach would 
suggest, but my gut feeling is that this is not a pythonic approach at all.

What do people feel about this?

Thanks

Steve
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: advanced SimpleHTTPServer?

[Andrea D'Amore]

On 2 November 2016 at 08:27, Ulli Horlacher
 wrote:
> "python -m SimpleHTTPServer" is really cool :-)

> - some kind of a chroot, to prevent file access higher then the base
>   directory

Shouldn't that be done by chrooting the python process in the calling
environment?


-- 
Andrea
-- 
https://mail.python.org/mailman/listinfo/python-list

testfixtures 4.13.0 Released!

[Chris Withers]

Hi All,

I'm pleased to announce the release of testfixtures 4.13.0 featuring the 
following:


- Add support to compare() for ignoring broken __eq__
  implementations, such as that found in the Django ORM!

The package is on PyPI and a full list of all the links to docs, issue 
trackers and the like can be found here:


https://github.com/Simplistix/testfixtures

Any questions, please do ask on the Testing in Python list or on the 
Simplistix open source mailing list...


cheers,

Chris
--
https://mail.python.org/mailman/listinfo/python-list

Re: lxml and xpath(?)

[dieter]

Doug OLeary  writes:
> ...
> Any hints/tips/suggestions greatly appreciated especially with complete noob 
> tutorials for xpath.

You can certainly do it with "XPath" (look for the "following-sibling" axis).

You can also use Python (with "lxml"). If you have an element "e", then
"e.getnext()" gives you the sibling following "e" (or `None`).

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

advanced SimpleHTTPServer?

[Ulli Horlacher]

"python -m SimpleHTTPServer" is really cool :-)

But I need some more features:

- some kind of a chroot, to prevent file access higher then the base
  directory

- a directory listing mit date and size information

- an upload possibility

I could modify /usr/lib/python2.7/SimpleHTTPServer.py by myself, but maybe
someone already has implemented these features?

Use case: users with notebooks in a foreign (WiFi) LAN want to exchange
some files on-the-fly, quick-and-dirty. Using USB sticks is a no-go! :-)


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
-- 
https://mail.python.org/mailman/listinfo/python-list