Stable GUI

[Viktor]

Which GUI is the most stable one? I don't need any fancy looking
widgets (look and feel doesn't realy matter to me), I "just" need it
to be rock stable and fast...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Stable GUI

[Viktor]

Lars wrote:
> Maybe you should describe your particular application and the reasons
> why you really need lightspeed widget rendering ? Stability goes
> without saying:)

It's a GUI for some database input, output routines. It sopouse to wark
24h/day, and about 150 input-outputs/h.

Fast: Because it's going to work on some old machines PI or PII, so I
don't need any *lightspeed*, but I don't wan't to wait 5s to open a new
Frame or something like that.
Stable: I tought that thay are, but wxPython broke on some simple test
programs that came with wxPython-demo. Tkinter newer broke, but neather
the programs I wrote were somthing complicated.

Thanks

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

Re: Stable GUI + wxPython memory leak

[Viktor]

I just noticed that wxPython is leaking memory?! Playing with
wxPython-demo, I started with 19MB used, and ended whith almost 150MB
used?!
It's wxPython 2.5.3.1 running on Python 2.4.

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

Re: Stable GUI + wxPython memory leak

[Viktor]

Peter Hansen wrote:
> On which platform?

On Linux, and I'm watching the percentage of used memory with *top* or
*ps v* (I have 256 MB). The aplication started with 19% used and after
45 minutes playing I saw i eat up almost 70%.

I also noticed that:

>>> from Tkinter import *
>>> l = Listbox()
>>> l.pack()
>>> for i in range(20):
... l.insert('end', str(i)) # Occupy memory
...
>>> l.delete(0, 'end')  # Free the memory

Doesn't free the memory. The memory stays occupied. OK, when I do the
same thing again, no additional memory is occupied. He uses the same
memory allocated first time, but why doesn't he free it and why memory
isn't fread up even if I explicitly call

>>> l.distroy()
>>> del l
?!

Thank You.

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

PyGTK and pyexe

[Viktor]

Did anybody managed to "pack", a program that uses pygtk with pyexe?

The best result I got was:

Pango-ERROR **: file shape.c: line 75 (pango_shape): assertion faled:
(glyphs->num_glyphs > 0) aborting...

I'm using python2.4, pygtk-2.6.1-1.win32-py2.4, gtk-win32-2.6.4-rc1.

Thanks in advance.

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

Re: PyGTK and pyexe

[Viktor]

Nope, it doesn't work... I've tried that and the only thing I got was:

ImportError: could not import pango
ImportError: could not import pango
Traceback (most recent call last):
  File "test.py", line 5, in ?
  File "gtk\__init__.pyc", line 113, in ?
AttributeError: 'module' object has no attribute 'Font'

But it has:

>>> import pango
>>> dir(pango).index('Font')
71


The only way it works is with this setup.py:



from distutils.core import setup
import py2exe
import glob

opts = {
"py2exe": {
"includes": ["pango", "atk", "gobject", "gtk"],
"dll_excludes": ["iconv.dll", "intl.dll",
"libatk-1.0-0.dll", "libgdk_pixbuf-2.0-0.dll",
"libgdk-win32-2.0-0.dll", "libglib-2.0-0.dll",
"libgmodule-2.0-0.dll", "libgobject-2.0-0.dll",
"libgthread-2.0-0.dll", "libgtk-win32-2.0-0.dll",
"libpango-1.0-0.dll", "libpangowin32-1.0-0.dll"]
}
}

setup(
name = "test",
description = "Test GUI programm",
version = "0.1",
windows = [{
"script": "test.py",
"icon_resources": [(1, "test.ico")]
}],
options=opts,
data_files=[("pixmaps", glob.glob("pixmaps/*.png")),
("glade", glob.glob("glade/*.*"))
],
)



But it's not stand-alone, it needs GTK, and when I copy all the dlls
needed in the dist directory, I get the same message as before.

Pango-ERROR **: file shape.c: line 75 (pango_shape): assertion faled:
(glyphs->num_glyphs > 0) aborting...

By the way, I'm allways getting this message at the end:

The following modules appear to be missing
['gdk', 'ltihooks']

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

Re: PyGTK and pyexe

[Viktor]

I succeeded :)))

And the winner is:



from distutils.core import setup
import py2exe

opts = {
"py2exe": {
"includes": ["pango", "atk", "gobject", "gtk","gtk.glade"],
"dll_excludes": ["iconv.dll", "intl.dll",
"libatk-1.0-0.dll", "libgdk_pixbuf-2.0-0.dll",
"libgdk-win32-2.0-0.dll", "libglib-2.0-0.dll",
"libgmodule-2.0-0.dll", "libgobject-2.0-0.dll",
"libgthread-2.0-0.dll", "libgtk-win32-2.0-0.dll",
"libpango-1.0-0.dll", "libpangowin32-1.0-0.dll",
"libxml2", "libglade-2.0-0", "zlib1"]
}
}

setup(
name = "PyGTKTest",
description = "PyGTK Test Application",
version = "0.1",
windows = [{"script": "test.py", "icon_resources": [(1,
"test.ico")]}],
options=opts,
data_files=[("", ["test.glade"])]
)

...

Py2exe reports an error if I try to use --force (the command doesn't
exist), so I use only:

python setup.py py2exe --exclude
gobject,glib,gtk,glade,pango,atk,libglade,xml2,zlib

After that I make a new directory, say MyApp, copy the entire content
of
the GTK folder (I'm using the GTK Runtime Enviroment from
gladewin32.sourceforge.net) in MyApp, and then copy the content of the
dist folder into MyApp\bin.

Now I can uninstall GTK Runtime Enviroment, and Python, and it works
:).

But it's pretty big, what files can I remove? (OK, I know... locales,
man
pages, examples :), but what more - it's still > 20 MB?)

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

Function creation (what happened?)

[Viktor]

Can somebody give me an explanation what happened here (or point me to
some docs)?

Code:

HMMM = None

def w(fn):
print 'fn:', id(fn)
HMMM = fn
print 'HMMM:', id(HMMM)
def wrapper(*v, **kw):
fn(*v, **kw)
wrapper.i = fn
print 'wrapper:', id(wrapper)
return wrapper

class A:
@w
def __init__(self): pass

print 'A.__init__:', id(A.__init__)
print 'A.__init__.i:', id(A.__init__.i)
print 'HMMM:', id(HMMM)



Output:

fn: 10404208
HMMM: 10404208
wrapper: 10404272
A.__init__: 10376136
A.__init__.i: 10404208
HMMM: 505264624



Why did HMMM changed his id?!
--
http://mail.python.org/mailman/listinfo/python-list

Re: Function creation (what happened?)

[Viktor]

This completely slipped of my mind... :)

I'm trying to change the:
http://wordaligned.org/svn/etc/echo/echo.py

So if the function is method it prints ClassName.MethodName instead of
MethodName(self|klass|cls=<... ClassName>).

But it turned out that in the decorator, the wrapped function is
always just a TypeFunction (I cannot find out if the function is
method, classmethod, staticmethod or just a plain function - tried
with inspect also)... And what is most interesting, when I do:

def w(fn):
print 'fn:', id(fn)
return fn

class A:
@w
def __init__(self): pass

print 'A.__init__:', id(A.__init__)

It turns out that the function I receive in the wrapper (even when I
return the same function) is not the function which will finally be
attached to the class...

Is there a way to find out in the decorator "what will the decorated
function be"?
--
http://mail.python.org/mailman/listinfo/python-list

Re: Function creation (what happened?)

[Viktor]

I figured out the first two solutions, but the third looks like the
most cleaner, think I'll use that one...

Thank you everyone. :)

On May 9, 3:24 pm, George Sakkis <[EMAIL PROTECTED]> wrote:
> The decorator does receive the correct function. The problem is that
> at this point __init__ is still a plain function, not a method, i.e.
> the sequence is:
>function -> decorated function -> method
>
> There are several workarounds if you really want to differentiate
> between functions and methods, none of them perfect:
>
> - Apply the decorator after the class has been built, i.e. after the
> functions have been wrapped in (unbound) methods:
> A.__init__ = w(A.__init__)
>
> - (Risky Hack): Guess whether a function is intended to be wrapped in
> a method by checking whether its first argument is named "self".
> Obviously this is not foolproof and it doesn't work for static/class
> methods.
>
> - Have two different decorators, one intended for plain functions and
> one for functions-to-be-methods (e.g. @deco, @decomethod).
>
> George

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

overiding assignment in module

[Viktor Marohnic]

Hello.
I would to do something like this.

container = []

p1 = point()
l1 = line()

and i would like to override = method of the module so that its puts
all objects into container.
how i can do something like that.
thanks for help,
viktor.

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

Re: overiding assignment in module

[Viktor Marohnic]

Ok thanks a lot. I think i got the point.
I also thought that it could be possible to do something like this
globals().__setitem__ = custom_setter
but __setitem__ is readonly

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

Py3K: Ensuring future compatibility between function annotation based tools

[Ferenczi Viktor]

There could be future compatibility issues between libraries using the new 
function annotation scheme: PEP 3107 -- Function Annotations
See also: http://www.python.org/dev/peps/pep-3107/

Let's assume two hypotetic libraries:
mashaller: provides JSON marshalling support
typechecker: provides runtime type checking

Let's write a simple function that uses both libraries:

from marshaller import marshall, JSON
from typechecker import check, Str

@marshall
@check
def splitter(s:Str) -> JSON:
return s.split(',')

The function get a singe string and returns JSON encoded list of it's comma 
separated parts. Both libraries can be used together without problems as long 
as all arguments and the return value are annotated by at most one annotator 
object. However, there could be frequent use cases, when multiple annotations 
for a single argument or return value is required:

@marshall
@check
def splitter(s:(JSON, Str)) -> JSON:
return s.split(',')

The above function does the same as the first one, but accepts a JSON encoded 
string. This solution works only if both libraries can cooperatively handle 
composite annotator objects and do not complain about unknown ones.
(Note, that the order of processing depends on the order of the decorators, 
not on the order of the annotators.)

Let me suggest the following recommendation for tool developers:

If you encounter a tuple as the annotator, then iterate it and process only 
the known ones while silently skipping all others. Keep all existing 
annotators if you include new ones. Create a tuple if you find an existing 
annotator and need to include a second one. Extend existing tuples by 
replacing them with new ones including new annotator(s).
(Possibly lists or dictionaries in place of tuples? I don't think so. Ideas?)

This way all annotation based tools will be compatible and should work 
seamlessly without imposing any unnecessary constraint.
Anybody with a better solution? Any comments?

Greetings, Viktor
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: doctest and decorators

[Ferenczi Viktor]

> I assume this is a FAQ, but I couldn't find much helpful information
> googling. I'm having trouble with doctest skipping my functions, if I'm
> using decorators (that are defined in a separate module). If I'm
> understanding what is happening correctly, it's because doctest checks if
> the function's func_global attribute is the same as the module's __dict__
> attribute. The decorator in question returns a wrapping function, though,
> so this check fails.
> What are some solutions to this? I can define __test__, but it seems rather
> cumbersome.

Please take a look at the documentation of the functools standard module in 
the Python manual, especially the wraps decorator. It could probably help.

Viktor
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: doctest and decorators

[Ferenczi Viktor]

> @functools.wraps

Correctly:

@functools.wraps(f)

Pass the function to be wrapped by the decorator to the wraps function.

Regards, Viktor
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: doctest and decorators

[Ferenczi Viktor]

> > @functools.wraps(f)
> > Pass the function to be wrapped by the decorator to the wraps function.
> Ooops, right. That doesn't change the fact that decorated functions get
> hidden from doctest though.

Run my test script (one file) with the -v (verbose) option. Without the -v 
option it does not show output. This fact is documented in the Python manual 
at the doctest module.

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
import functools

def simplelog(f):
@functools.wraps(f)
def new_f(*args, **kwds):
print "Wrapper calling func"
return f(*args, **kwds)
return new_f

@simplelog
def test():
"""
>>> test()
Wrapper calling func
'works!'
"""
return 'works!'

def fn():
"""
>>> fn()
'ok'
"""
return 'ok'

if __name__ == '__main__':
import doctest
doctest.testmod()
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 

Regard, Viktor
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Any syntactic cleanup likely for Py3? And what about doc standards?

[Ferenczi Viktor]

Hi!

> The reading I've done so far on Python 3 (alpha announcement, meta-PEP,
> some other PEPs) is generally encouraging, but there doesn't seem to be
> much on cleaning up the syntax, which has become uglier over time as
> features have been added on to an original syntax that wasn't designed
> to support them. It seems to me (from what little I've read--I admit
> that it's impossible to know for sure without experimenting quite a bit,
> for which I don't currently have the time) that new features such as
> multimethods might just make things more confusing (especially for
> newbies) in a lot of ways, without appropriate syntactic support.

There are some cleanups, such as the new class decorators and function 
annotation syntax. Both of them provides a common, much better solution 
instead of current weird solutions, such as metaclasses and specially 
formatted docstrings. Since Python currenty has a very nice syntax it cannot 
be cleaned up much further.

> Currently the most obvious example of this is Python 2.5's way of
> defining properties, which is ugly. leads often to writing of
> unnecessary code, and certainly doesn't make property code clear to a
> reader. Contrast this to the way properties (things that look like an
> instance variable but are actually bound to methods) are handled in Ruby
> and (IIRC, this also does a decent job) C#.
> On the other hand, it does seem that some new syntactic support for
> other features will be added, so perhaps I'm just missing whichever PEPs
> talk about going back and adding cleaner syntax for existing features...?

Class decorators allows clean implementation of properties.
Detailed description: http://www.python.org/dev/peps/pep-3129/
Lets use a hypothetic library providing properties, for example:

from property_support import hasProperties, Property

@hasProperties
class Sphere(object):
def setRadius(self, value):
... some setter implementation ...
radius=Property(default=1.0, set=setRadius, type=(int, float))
color=Property(default='black', allowNone=True)

This is a cleaner syntax if you need automatic default setter/getter 
implementations with type checking, default values, etc. You can optionally 
override/extend some of the default implementations. This could be 
implemented by a third party library using class decorators and need not be 
restricted by a strict syntax in the language itself. This is a good design 
choice from my point of view, since it does not require the introduction of 
new symbols into the syntax, fully dynamic and inspected at runtime.

> Finally, another thing I've perhaps missed, but I can't see anything in
> what I've gone through, about correcting of of what I see to be one of
> Python's most long-standing really serious flaws, which is the lack of
> an official standard documentation markup syntax for writing
> documentation in code. This isn't even a matter of getting something
> developed, it's simply a matter of Guido and the Powers That Be
> bestowing their benediction on one of the several adequate or better
> documentation toolsets out there, so that more of us (slowly) start
> using it. Eventually this will result in work on the toolset itself,
> more people will be willing to use it, and there'll be a nice virtuous
> circle. Given how much more capable D'Oxygen is than any of the
> Python-specific solutions, I'd vote for D'Oxygen myself, but I'd prefer
> to have almost anything fill in this vacuum, rather than continue things
> the way they are.

Maybe the community should ask Guido to suggest a
"preferred" tool for documenting Python code.

Regars, Viktor
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Any syntactic cleanup likely for Py3? And what about doc standards?

[Ferenczi Viktor]

Hello,

> > from property_support import hasProperties, Property
> >
> > @hasProperties
> > class Sphere(object):
> > def setRadius(self, value):
> > ... some setter implementation ...
> > radius=Property(default=1.0, set=setRadius, type=(int, float))
> > color=Property(default='black', allowNone=True)
> >
> > This is a cleaner syntax if you need automatic default
> > setter/getter implementations with type checking, default values,
> > etc.
>
> Well, I think @hasProperties is very ugly.  Such things always look
> like a dirty trick.  The programmer wonders why the language cannot
> detect by itself that there are properties in this class.

If you do not include the @hasProperties class decorator, then 
radius=Property(...) means that radius is a class attribute with a Property 
instance as it's value, nothing special. If you also include the class 
decorator, then it takes an additional meaning. In this case the decorator 
should remove the Property instance from the class and turn it into a real 
property. This is not magic. This is a possible use case of the new class 
decorator feature.

Properties are very useful, since ordinary attribute access can be 
transparently replaced with properties if the developer needs to add code 
when it's set or needs to calculate it's value whenever it is read.

As an additional benefit this could allow developers to implement change 
events for properties that allows any number of observers to monitor property 
changes. This could be very useful in GUI programming, for example.

Regards, Viktor
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Any syntactic cleanup likely for Py3? And what about doc standards?

[Ferenczi Viktor]

Hello,

> > from property_support import hasProperties, Property
> >
> > @hasProperties
> > class Sphere(object):
> >     def setRadius(self, value):
> >         ... some setter implementation ...
> >     radius=Property(default=1.0, set=setRadius, type=(int, float))
> >     color=Property(default='black', allowNone=True)
> >
> > This is a cleaner syntax if you need automatic default setter/getter
> > implementations with type checking, default values, etc

> I really distaste this "etc." in your description. In the end you
> promote endless lists of command line parameters to configure every
> possible function. I also doubt that the solution is more clean but
> arbitray instead.

Py3K does not enforce any particular use of the class decorator function. This 
was only an example.

> My own guess why properties are not promoted with more emphasis is
> that they lead to cargo cult programming i.e. everyone starts to use
> property syntax even when usual attributes are sufficient. So the
> syntax might even be intentionally ugly.

AFAIK there is no such a thing as "intentionally ugly" in the Python language. 
I've never read this sentence before in manuals, tutorials, etc.

Certainly, an attribute should be replaced by a property if and only if 
additional functionality is required, such as type or value checking, 
calculated value, ability to register observers for various events fired by 
the property and so on.

This is advanced Python programming, not "cargo cult".

Regards, Viktor

PS.: Use Python 1.5.2 if you do not need advanced features. ;-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Any syntactic cleanup likely for Py3? And what about doc standards?

[Ferenczi Viktor]

> > AFAIK there is no such a thing as "intentionally ugly" in the Python
> > language. I've never read this sentence before in manuals, tutorials,
> > etc.
>
> Perhaps not, but ...
>
>   http://mail.python.org/pipermail/python-dev/2005-September/056846.html
>

WOW, thats true! :-D

(AFAIK these creations are rather complicated than just plain ugly.)

Thanks for your comment.

Viktor
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Any syntactic cleanup likely for Py3? And what about doc standards?

[Ferenczi Viktor]

> > Properties are very useful, since ordinary attribute access can be
> > transparently replaced with properties if the developer needs to
> > add code when it's set or needs to calculate it's value whenever
> > it is read.
>
> I totally agree.  I like to use properties.  However, Python already
> has properties.  Their syntax is quite nice in my opinion, and
> rather explicit, too.  Their only flaw is that they are not
> "virtual" (in C++ speak).  In other words, you can't pass a "self"
> parameter to them.

Thanks for your comment. I'm going to elaborate on this issue. - Viktor
-- 
http://mail.python.org/mailman/listinfo/python-list

Creating classes and objects more than once?

[Viktor Kerkez]

Here is the situation:

$ ls
test
$ cd test
$ ls
__init__.py data.py
$ cat __init__.py

$ cat data.py
DATA = {}

$ cd ..
$ python
>>> import os
>>> from test.data import DATA
>>> DATA['something'] = 33
>>> os.chdir('test')
>>> from data import DATA as NEW_DATA
>>> DATA
{'something': 33}
>>> NEW_DATA
{}


Is this a bug?

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

Re: Creating classes and objects more than once?

[Viktor Kerkez]

But this means that there is no way to create a safe Singleton in
python, because the classes are also created twice.

This is the problem that I encountered. I created a complex
implementation of a Singleton pattern using metaclasses because I
needed the __init__ method to be called just once and I wanted to use
inheritance from the Singleton class. Here is the code:




class SingletonMetaclass(type):

'''Singleton Metaclass



This metaclass is used for creating singletons.

It changes the class __new__ method to maintain only one instance
of the

class, and tweaks the __init__ method to be executed only once
(when the

first instance of the class is created.



Usage:

>>> class MySingleton(object):

... """Real singleton class.

...

... You have to set the __metaclass__ attribute to
SingletonMetaclass,

... and define the __init__ function. Everythin else will be
done by

... metaclass.

... """

... __metaclass__ = SingletonMetaclass

... def __init__(self, data):

... print 'Initializing'

... self.data = data

...

>>> first = MySingleton('First initialization')   # Only this
actually happen

Initializing

>>> second = MySingleton('Second initialization') # This won't
happen

>>> first.data

'First initialization'

>>> second.data

'First initialization'

>>>

'''

def __new__(cls, name, bases, dct):

dct['__new__'] = SingletonMetaclass._dekorate_new()

dct['get_instance'] = SingletonMetaclass._decorate_get_instance
()

try:

dct['__init__'] = SingletonMetaclass._dekorate_init(dct
['__init__'])

except KeyError:

init_functions = [getattr(base, '__init__') for base in
bases if hasattr(base, '__init__')]

if init_functions:

dct['__init__'] = SingletonMetaclass._dekorate_init
(init_functions[0])

else:

raise Exception('Don\'t use SingletonMetaclass, use
inheritance from Singleton class!')

return type.__new__(cls, name, bases, dct)



@staticmethod

def _dekorate_init(function):

def wrapper(self, *args, **kwargs):

if not hasattr(self, '_singleton_initialized'):

function(self, *args, **kwargs)

setattr(self, '_singleton_initialized', True)

return wrapper



@staticmethod

def _dekorate_new():

def wrapper(cls, *p, **k):

if not hasattr(cls, '_instance'):

cls._instance = object.__new__(cls)

return cls._instance

return wrapper



@staticmethod

def _decorate_get_instance():

@classmethod

def wrapper(cls):

if not hasattr(cls, '_instance'):

return None

return cls._instance

return wrapper





class Singleton(object):

'''Singleton class



Inherit from this class if you want to have a singleton class.

Never use SingletonMetaclass!



Usage:

>>> class EmptySingleton(Singleton):

... """Singleton without __init__ method"""

... pass

...

>>> first = EmptySingleton()

>>> second = EmptySingleton()

>>> assert id(first) == id(second)

>>>

>>> class InitSingleton(Singleton):

... """Singleton with __init__ method"""

... def __init__(self, data):

... print 'Initializing'

... self.data = data

...

>>> first = InitSingleton('First initialization')   # Only this
actually happen

Initializing

>>> second = InitSingleton('Second initialization') # This won't
happen

>>> first.data

'First initialization'

>>> assert first.data == second.data

>>>

'''

__metaclass__ = SingletonMetaclass

def __init__(self):

pass





if __name__ == '__main__':

import doctest

doctest.testmod()




The problem started when the class gets imported in two different
ways, and the class gets created twice!??!

Do You have any suggestions how to solve this problem.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Creating classes and objects more than once?

[Viktor Kerkez]

A better way to do this was http://pastebin.com/m1130d1fe :)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Creating classes and objects more than once?

[Viktor Kerkez]

On Nov 28, 12:32 am, "Chris Rebert" <[EMAIL PROTECTED]> wrote:
> The Python position on singletons is generally to just use a module
> instead (preferred), or apply the Borg 
> pattern:http://code.activestate.com/recipes/66531/

The same problem appears if I use the module (as I pointed in the
first message of this thread). Also it will appear if I use the Borg
pattern because the class is created twice. :(
--
http://mail.python.org/mailman/listinfo/python-list

Re: Creating classes and objects more than once?

[Viktor Kerkez]

On Nov 28, 9:35 am, Carl Banks <[EMAIL PROTECTED]> wrote:
> However, I'm not so sure the effect of os.chdir() on the import path
> is a good idea.

I'm not actually using os.chidir(), I just used it here to create a
clearer example.

Here is the simplest representation of the problem:

http://www.ninjashare.com/904415


$ cd singleton_test
$ export PYTHONPATH=.
$ python application/main_script.py
Creating class Singleton
Creating class MySingleton
Creating class Singleton
Creating class MySingleton
$
--
http://mail.python.org/mailman/listinfo/python-list

how to zip a StringIO object?

[Nagy Viktor]

Hi,

I try to run the following code:

def generate_zip(object_list, template):
result = StringIO.StringIO()
zipped = zipfile.ZipFile(result, "w")
for object in object_list:
pdf = generate_pdf(object, template)
if not pdf:
raise IOError("Problem with generating invoice %d" %
object.pk)
zipped.writestr("invoice-%d.pdf" % object.pk, pdf)
zipped.close()
return result.getvalue()

where generate_pdf returns a valid pdf file's string content, more
precisely it returns a StringIO.getvalue() call containing the pdf
"string".

When I add this string to the zip file, I get a problem. Namely, the
zipped files are chmoded to non-readable when extracted. How can I
change this?

thanks,
V
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to install Python package from source on Windows

[Viktor Hagström]

I have followed this discussion since the beginning, and I have been intrigued. 
I recently read a relevant blog post that I'd like to share. It has arguments 
for both sides: http://nullprogram.com/blog/2017/03/30/.

2017-05-20 0:01 GMT+02:00 eryk sun 
mailto:eryk...@gmail.com>>:
On Fri, May 19, 2017 at 9:18 PM, bartc 
mailto:b...@freeuk.com>> wrote:
> On 19/05/2017 19:53, eryk sun wrote:
>>
>> On Fri, May 19, 2017 at 1:57 PM, bartc 
>> mailto:b...@freeuk.com>> wrote:
>
>
>>> The 'improvement' seems to involve making things more complicated rather
>>> than less.
>
>
>> You don't need a full Visual Studio 2015 installation. You can install
>> Visual C++ 2015 Build Tools [1], which includes MSBuild, and use the
>> x86 or x64 native tools command prompt. Install the WDK to get the
>> Windows debuggers windbg, cdb, kd, and ntsd.
>>
>> To build the external dependencies, you'll need svn and nasm in PATH.
>> You don't need git if you've downloaded the source manually. Ignore
>> the warning if it can't find git.
>>
>> [1]: http://landinghub.visualstudio.com/visual-cpp-build-tools
>
> TBH I've no idea what most of these things do. So if something goes wrong, I
> can't hack my way around them.
>
> (And things will go wrong; I've just tried to uninstall VS2017, as I think
> it was, and eventually it said 'Uninstall Failed'! I download msbuild tools
> you suggested. MSBUILD, I simply don't know how to use. CL, either it can't
> find it, or it crashes. So forget it.

MSBuild is a build tool for C/C++ and .NET projects that are defined
by XML project files. You need it to build CPython via pcbuild.proj.

Run the x64 or x86 native tools command prompt to set up the
command-line build environment (PATH, INCLUDE, LIB). Assuming
everything is set up right, you should have no problem running cl.exe
and link.exe.
--
https://mail.python.org/mailman/listinfo/python-list

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

Re: Cannot get any Python commands to work

[Viktor Hagström]

It seems like you are trying to run easy_install while running the Python 
interpreter. I am not familiar with easy_install, but my guess would be to run 
it outside the interpreter, in the command prompt.

2017-06-12 16:47 GMT+02:00 David Marquand 
mailto:dbmarqu...@gmail.com>>:
I am trying to learn Django and cannot get easy_install to work. Python working 
on PyDev fine.








PS C:\Windows\system32> python
Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 18:41:36) [MSC v.1900 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> easy_install --version
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'easy_install' is not defined
>>> python
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'python' is not defined
>>>

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

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

Re: Cannot get any Python commands to work

[Viktor Hagström]

It seems like you are trying to run easy_install while running the Python 
interpreter. I am not familiar with easy_install, but my guess would be to run 
it outside the interpreter, in the command prompt.

2017-06-12 16:47 GMT+02:00 David Marquand 
mailto:dbmarqu...@gmail.com>>:
I am trying to learn Django and cannot get easy_install to work. Python working 
on PyDev fine.








PS C:\Windows\system32> python
Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 18:41:36) [MSC v.1900 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> easy_install --version
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'easy_install' is not defined
>>> python
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'python' is not defined
>>>

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

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

Re: Compiling Python 3.6.1 on macOS 10.12.5

[Viktor Hagström]

>Why are you trying to compile Python manually? You should use Homebrew to
>install Python in 99% of cases. (The package is python3)

I'm not the person you answered, but I can explain why I do things that are not 
"optimal" or "easy" or "best".

I am interested, I want to learn something, I think it's fun to do things the 
hard way. I want to learn how it *really* works. I want to modify it, break it, 
and fix it again. And I think it would be good for this community to encourage 
that (as long as it doesn't hinder their progress).

2017-07-11 8:48 GMT+02:00 Chris Warrick 
mailto:kwpol...@gmail.com>>:
Why are you trying to compile Python manually? You should use Homebrew to
install Python in 99% of cases. (The package is python3)

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

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

Re: Compiling Python 3.6.1 on macOS 10.12.5

[Viktor Hagström]

>Why are you trying to compile Python manually? You should use Homebrew to
>install Python in 99% of cases. (The package is python3)

I'm not the person you answered, but I can explain why I do things that are not 
"optimal" or "easy" or "best".

I am interested, I want to learn something, I think it's fun to do things the 
hard way. I want to learn how it *really* works. I want to modify it, break it, 
and fix it again. And I think it would be good for this community to encourage 
that (as long as it doesn't hinder their progress).

2017-07-11 8:48 GMT+02:00 Chris Warrick 
mailto:kwpol...@gmail.com>>:
Why are you trying to compile Python manually? You should use Homebrew to
install Python in 99% of cases. (The package is python3)

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

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

Re: Compiling Python 3.6.1 on macOS 10.12.5

[Viktor Hagström]

>Why are you trying to compile Python manually? You should use Homebrew to
>install Python in 99% of cases. (The package is python3)

I'm not the person you answered, but I can explain why I do things that are not 
"optimal" or "easy" or "best".

I am interested, I want to learn something, I think it's fun to do things the 
hard way. I want to learn how it *really* works. I want to modify it, break it, 
and fix it again. And I think it would be good for this community to encourage 
that (as long as it doesn't hinder their progress).

2017-07-11 8:48 GMT+02:00 Chris Warrick 
mailto:kwpol...@gmail.com>>:
Why are you trying to compile Python manually? You should use Homebrew to
install Python in 99% of cases. (The package is python3)

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

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