how to make portable distribution of python 2.6?

[zaur]

All greetings!

How to make portable distribution of python 2.6?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to make portable distribution of python 2.6?

[zaur]

On 13 авг, 21:28, Thomas Jollans  wrote:
> On 2010-08-13 19:00, zaur wrote:> All greetings!
>
> > How to make portable distribution of python 2.6?
>
> I don't know, but what you're looking for probably already exists.
>
> Do you mean "portable" as in portable, i.e. "take this and build it for
> your system, it should work if your OS is supported"? Then you can get
> source tarballs from python.org
>
> http://python.org/download/
>
> Or do you understand "portable" the way that is fashionable in the
> Windows world nowadays for some reason, i.e. "look, Ma, already
> installed if you happen to use Microsoft Windows of roughly the right
> version!"
>
> Thenhttp://www.portablepython.com/is exactly where Google would have
> lead you had you searched.

I want to realize howto build my own portable python in order to use
them without installation.
I want also to be able install modules (numpy, matplotlib, pyqt,
etc...) when it is necessary.
This very usefull for teaching python in computer classes.
-- 
http://mail.python.org/mailman/listinfo/python-list

Object's nesting scope

[zaur]

Hi folk!

What do you think about idea of "object's nesting scope" in python?

Let's imaging this feature, for example, in this syntax:

obj=:
 

or

:
   

That's means that result object of  evaluation is used as
nested scope for  evaluation.

So is this idea useful?

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

Re: Object's nesting scope

[zaur]

On 26 авг, 17:13, "Diez B. Roggisch"  wrote:
> Whom am we to judge? Sure if you propose this, you have some usecases in
> mind - how about you present these

Ok. Here is a use case: object initialization.

For example,

person = Person():
  name = "john"
  age = 30
  address = Address():
 street = "Green Street"
 no = 12

vs.

person = Person()
person.name = "john"
person.age = 30
address = person.address = Address()
address.street = "Green Street"
address.no = 12

In this example any assignment is an equivalence of setting
attribute's address of the parent object.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Object's nesting scope

[zaur]

On 26 авг, 21:11, "Rami Chowdhury"  wrote:
> > person = Person():
> >   name = "john"
> >   age = 30
> >   address = Address():
> >      street = "Green Street"
> >      no = 12
>
> Can you clarify what you mean? Would that define a Person class, and an  
> Address class?
I suppose that someone already define classes Person ans Address.
For example, in this stupid way in a foreign module:

class Person(object):
   pass

class Address(object):
   pass

and the following statements

person = Person():
   name = "john"
   age = 30
   address = Address():
  street = "Green Street"
  no = 12

are constructing an instance as follows:

person = Person()
person.name = "john"
person.age = 30
address = person.address = Address()
address.street = "Green Street"
address.no = 12

> If you are expecting those classes to be already defined, please bear in  
> mind that if you want, you can do this:
>
> > > > class Person(object):
>
>         def __init__(self, name='Nemo', age=0, address=None):
>                 self.name = name
>                 self.age = age
>                 self.address = address
>
> > > > class Address(object):
>
>         def __init__(self, street=None, no=None):
>                 self.street = street
>                 self.no = no
>
> > > > otherperson = Person(
>
>                      name = 'Bob',
>                      age = 26,
>                      address = Address(
>                              street = 'Blue Street',
>                              no = 1
>                              )
>                      )
>
Yes, that's right. I aware about this way of instance initialization.

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

Re: Object's nesting scope

[zaur]

On 26 авг, 23:56, MRAB  wrote:
> zaur wrote:
> > On 26 авг, 21:11, "Rami Chowdhury"  wrote:
> >>> person = Person():
> >>>   name = "john"
> >>>   age = 30
> >>>   address = Address():
> >>>      street = "Green Street"
> >>>      no = 12
> >> Can you clarify what you mean? Would that define a Person class, and an  
> >> Address class?
> > I suppose that someone already define classes Person ans Address.
> > For example, in this stupid way in a foreign module:
>
> > class Person(object):
> >    pass
>
> > class Address(object):
> >    pass
>
> > and the following statements
>
> > person = Person():
> >    name = "john"
> >    age = 30
> >    address = Address():
> >       street = "Green Street"
> >       no = 12
>
> > are constructing an instance as follows:
>
> > person = Person()
> > person.name = "john"
> > person.age = 30
> > address = person.address = Address()
> > address.street = "Green Street"
> > address.no = 12
>
> [snip]
>
> Create factory functions:
>
> def new_address(**kwargs):
>      address = Address()
>      address.__dict__.update(kwargs)
>      return address
>
> def new_person(**kwargs):
>      person = Person()
>      person.__dict__.update(kwargs)
>      return person
>
> person = new_person(name="john", age=30,
> address=new_address(street="Green Street", no=12))

Original idea isn't about how to organize my code in order to
initialize these custom objects.
The idea is about to use object's dictionary as nested scope.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Object's nesting scope

[zaur]

On 27 авг, 18:34, Carl Banks  wrote:
> On Aug 26, 5:51 am, zaur  wrote:
>
>
>
> > Hi folk!
>
> > What do you think about idea of "object's nesting scope" in python?
>
> > Let's imaging this feature, for example, in this syntax:
>
> > obj=:
> >      
>
> > or
>
> > :
> >    
>
> > That's means that result object of  evaluation is used as
> > nested scope for  evaluation.
>
> > So is this idea useful?
>
> It might be marginally useful to save typing.
It also allow to structure the code.

> The idea has been
> discussed in various forms here quite a bit over the years.  I doubt
> there's any chance it'll be accepted into Python, because it goes
> against one of the main design points of Python: that attributes
> should always be accessed explicitly.
I don't in general consider this idea as a way for implicit access to
object's attributes.
Idea is about to use in some way object's dictionary as nested scope
in a code block.

I agree though that using this only for saving typing or implicit
attribute access isn't a good idea.

> Having said that, the syntax you propose is awful. :) Normally when
> this is proposed they use a keyword such as "using":
>
> p = Person()
> using p:
>     name = "Carl Banks"
>     location = "Los Angeles"
>
> or, perhaps to save a line (even though it'd be a minor syntax abuse):
>
> using Person() as p:
>     name = "Carl Banks"
>     location = "Los Angeles"
I don't propose concrete syntax for using object's dictionary as
nested scope.
I used current only to explain the idea.

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

Re: Object's nesting scope

[zaur]

On 27 авг, 19:19, Carl Banks  wrote:
> On Aug 27, 8:01 am, zaur  wrote:
>
> > On 27 авг, 18:34, Carl Banks  wrote:
> > > The idea has been
> > > discussed in various forms here quite a bit over the years.  I doubt
> > > there's any chance it'll be accepted into Python, because it goes
> > > against one of the main design points of Python: that attributes
> > > should always be accessed explicitly.
>
> > I don't in general consider this idea as a way for implicit access to
> > object's attributes.
>
> That's what is it regardless of what you consider it.
>
> > Idea is about to use in some way object's dictionary as nested scope
> > in a code block.
>
> Which is implicitly accessing the object's attributes.
>
> Carl Banks

In my opinion idea of using object's dictionary as nested scope is
more about structuring code blocks rather than just saving typing and
implicit attribute access.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Object's nesting scope

[zaur]

On 28 авг, 16:07, Bruno Desthuilliers  wrote:
> zaur a écrit :
>
>
>
> > On 26 авг, 17:13, "Diez B. Roggisch"  wrote:
> >> Whom am we to judge? Sure if you propose this, you have some usecases in
> >> mind - how about you present these
>
> > Ok. Here is a use case: object initialization.
>
> > For example,
>
> > person = Person():
> >   name = "john"
> >   age = 30
> >   address = Address():
> >      street = "Green Street"
> >      no = 12
>
> > vs.
>
> > person = Person()
> > person.name = "john"
> > person.age = 30
> > address = person.address = Address()
> > address.street = "Green Street"
> > address.no = 12
>
> Err... Looks like you really should read the FineManual(tm) -
> specifically, the parts on the __init__ method.
>
> class Person(object):
>     def __init__(self, name, age, address):
>         self.name = name
>         self.age = age
>         self.address = address
>
> class Address(object):
>     def __init__(self, street, no):
>         self.no = no
>         self.street = street
>
> person = Person(
>     name="john",
>     age=30,
>     address = Address(
>         street="Green Street",
>         no=12
>     )
> )

What are you doing if 1) classes Person and Address imported from
foreign module 2) __init__ method is not defined as you want?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Object's nesting scope

[zaur]

On 29 авг, 08:37, "Gabriel Genellina"  wrote:
> En Fri, 28 Aug 2009 15:25:55 -0300, zaur  escribió:
>
>
>
> > On 28 авг, 16:07, Bruno Desthuilliers  > 42.desthuilli...@websiteburo.invalid> wrote:
> >> zaur a écrit :
>
> >> > Ok. Here is a use case: object initialization.
>
> >> > For example,
>
> >> > person = Person():
> >> >   name = "john"
> >> >   age = 30
> >> >   address = Address():
> >> >      street = "Green Street"
> >> >      no = 12
>
> >> > vs.
>
> >> > person = Person()
> >> > person.name = "john"
> >> > person.age = 30
> >> > address = person.address = Address()
> >> > address.street = "Green Street"
> >> > address.no = 12
>
> >> Err... Looks like you really should read the FineManual(tm) -
> >> specifically, the parts on the __init__ method.
>
> >> class Person(object):
> >>     def __init__(self, name, age, address):
> >>         self.name = name
> >>         self.age = age
> >>         self.address = address
>
> >> class Address(object):
> >>     def __init__(self, street, no):
> >>         self.no = no
> >>         self.street = street
>
> >> person = Person(
> >>     name="john",
> >>     age=30,
> >>     address = Address(
> >>         street="Green Street",
> >>         no=12
> >>     )
> >> )
>
> > What are you doing if 1) classes Person and Address imported from
> > foreign module 2) __init__ method is not defined as you want?
>
> Welcome to dynamic languages! It doesn't matter *where* the class was  
> defined. You may add new attributes to the instance (even methods to the  
> class) at any time.
>
> 1)
> person = Person()
> vars(person).update(name="john",age=30,address=Address())
> vars(person.Address).update(street="Green Street",no=12)
>
> 2)
> def the_initializer_i_would_like(person, name, age):
>    person.name = name
>    person.age = age
>
> person = Person()
> the_initializer_i_would_like(person, name="john", age=30)
>
> 3)
> def the_initializer_i_would_like(self, name, age):
>    self.name = name
>    self.age = age
>
> Person.init = the_initializer_i_would_like
> person = Person()
> person.init(name="john", age=30)
>
> 4)
> def a_generic_updater(obj, **kw):
>    try: ns = vars(obj)
>    except Exception: ns = None
>    if ns is not None:
>      ns.update(kw)
>    else:
>      for name in kw:
>        setattr(obj, name, kw[name])
>
> person = Person()
> a_generic_updater(person, name="john", age=30)
>
> --
> Gabriel Genellina

I know about these ways of object initializing. What I said is about
using object's dictionary as nested scope in code block. Object
initialization is just one use case.
So we say about different things.
-- 
http://mail.python.org/mailman/listinfo/python-list

Is behavior of += intentional for int?

[zaur]

Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "copyright", "credits" or "license()" for more information.
>>> a=1
>>> x=[a]
>>> id(a)==id(x[0])
True
>>> a+=1
>>> a
2
>>> x[0]
1

I thought that += should only change the value of the int object. But
+= create new.
Is this intentional?

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

Re: Is behavior of += intentional for int?

[zaur]

On 29 авг, 20:25, "Günther Dietrich"  wrote:
> Paul McGuire  wrote:
> >What exactly are you trying to do?
>
> I think, he wants to kind of dereference the list element. So that he
> can write
>
> >>> a += 1
>
> instead of
>
> >>> long_name_of_a_list_which_contains_data[mnemonic_pointer_name] += 1
>
> Regards,
>
> Günther

That's right. I thought that int as object will stay the same object
after += but with another integer value.
My intuition said me that int object which represent integer value
should behave this way.
But by design python's integer behave differently.

I fond that NumPy's 1-d types behaves as objects with mutable values.

>>> from numpy import *

>>> a=array([1])
>>> id(a)
10912544
>>> a += 1
>>> id(a)
10912544
>>> a
array([2])
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Object's nesting scope

[zaur]

On 30 авг, 03:22, "Gabriel Genellina"  wrote:
> En Sat, 29 Aug 2009 04:34:48 -0300, zaur  escribió:
>
>
>
> > On 29 авг, 08:37, "Gabriel Genellina"  wrote:
> >> En Fri, 28 Aug 2009 15:25:55 -0300, zaur  escribió:
> >> > On 28 авг, 16:07, Bruno Desthuilliers  >> > 42.desthuilli...@websiteburo.invalid> wrote:
> >> >> zaur a écrit :
>
> >> >> > Ok. Here is a use case: object initialization.
>
> >> >> Err... Looks like you really should read the FineManual(tm) -
> >> >> specifically, the parts on the __init__ method.
>
> >> > What are you doing if 1) classes Person and Address imported from
> >> > foreign module 2) __init__ method is not defined as you want?
>
> >> Welcome to dynamic languages! It doesn't matter *where* the class was  
> >> defined. You may add new attributes to the instance (even methods to  
> >> the class) at any time. [...4 examples...]
>
> > I know about these ways of object initializing. What I said is about
> > using object's dictionary as nested scope in code block. Object
> > initialization is just one use case.
> > So we say about different things.
>
> Well, you asked how to proceed in certain cases and I showed several ways  
> it can be done right now, without requiring a new scope. You'll have to  
> think of another use case.
>
> Attribute lookup is explicit in Python, and that's a very good thing. If  
> you follow the python-ideas thread posted earlier, you'll see the kind of  
> problems an implicit attribute lookup would cause. The "with" statement is  
> necesary (and a good thing) in Pascal, but not in Python.
>
> Zope2 departs from this explicitness: it has a  construct  
> (similar to what you propose), and I hate it profoundly every time I have  
> to edit a DTML file - I can never tell *where* an attribute comes from.  
> Another related "feature" is acquisition, a stack of namespaces where  
> objects "inherit" attributes from their containers. Same thing, a complete  
> waste of time every time I have to track a bug.
>
> Unless you can find a very compeling use case, I don't think this feature  
> will become part of the language anytime soon...
>
> --
> Gabriel Genellina


The same can be said about multiple inheritance.
However, multiple inheritance is a powerful tool in the hands of
someone who can properly and effectively use it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is behavior of += intentional for int?

[zaur]

On 29 авг, 23:03, Steven D'Aprano  wrote:
> On Sat, 29 Aug 2009 11:11:43 -0700, zaur wrote:
> > I thought that int as object will stay the same object after += but with
> > another integer value. My intuition said me that int object which
> > represent integer value should behave this way.
>
> If it did, then you would have this behaviour:
>
> >>> n = 3                     # bind the name n to the object 3
> >>> saved_id = id(n)          # get the id of the object
> >>> n += 1                    # add one to the object 3
> >>> assert n == 4             # confirm that it has value four
> >>> assert id(n) == saved_id  # confirm that it is the same object
> >>> m = 3                     # bind the name m to the object 3
> >>> print m + 1               # but object 3 has been modified
>
> 5
>
> This would be pretty disturbing behaviour, and anything but intuitive.
>
> Fortunately, Python avoids this behaviour by making ints immutable. You
> can't change the object 3 to have any other value, it will always have
> value three, and consequently n+=1 assigns a new object to n.
>
> --
> Steven

This behavior is because small integers are cached internally. See

Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a=1
>>> c=1
>>> d=1
>>> e=1
>>> id(a),id(c),id(d),id(e)
(16793992, 16793992, 17067336, 17067276)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is behavior of += intentional for int?

[zaur]

On 30 авг, 15:49, Carl Banks  wrote:
> I think they (Derek and zaur) expect integer objects to be mutable.
>
> It's pretty common for people coming from "name is a location in
> memory" languages to have this conception of integers as an
> intermediate stage of learning Python's object system.  Even once
> they've understood "everything is an object" and "names are references
> to objects" they won't have learned all the nuances of the system, and
> might still (not unreasonably) think integer objects could be mutable.
>
> However, it'd be nice if all these people didn't post here whining
> about how surprising and unintuitive it is and instead just said, "ah,
> integers are immutable, got it", quietly to themselves.
>
> Carl Banks

Very expressive.

I use python many years. And many years I just took python int as they
are.
I am also not think about names as reference to objects and so on.

So this isn't the case.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is behavior of += intentional for int?

[zaur]

On 29 авг, 16:45, zaur  wrote:
> Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
> [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
> Type "copyright", "credits" or "license()" for more information.>>> a=1
> >>> x=[a]
> >>> id(a)==id(x[0])
> True
> >>> a+=1
> >>> a
> 2
> >>> x[0]
>
> 1
>
> I thought that += should only change the value of the int object. But
> += create new.
> Is this intentional?

As a result of this debate is not whether we should conclude that
there should be two types of integers in python: 1) immutable numbers,
which behave as constant value; 2) mutable numbers, which behave as
variable value?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is behavior of += intentional for int?

[zaur]

On 1 сен, 03:31, Steven D'Aprano  wrote:
> On Mon, 31 Aug 2009 10:21:22 -0700, zaur wrote:
> > As a result of this debate is not whether we should conclude that there
> > should be two types of integers in python: 1) immutable numbers, which
> > behave as constant value; 2) mutable numbers, which behave as variable
> > value?
>
> What can you do with mutable numbers that you can't do with immutable
> ones, and why do you want to do it?
>
> --
> Steven

Mutable numbers acts as variable quantity. So when augmented
assignment is used there is no need to create a new number object in
every binary operation.

But when I looked now into source of python int (longobject.c) I
realized that direct implementation of mutable int will not give any
benefit against defining proxy int class, which supports mutability.
-- 
http://mail.python.org/mailman/listinfo/python-list

Python Object Notation (PyON)

[Zaur Shibzoukhov]

Python Object Notation (PyON<http://code.google.com/p/pyon/wiki/GettingStarted>
)

Python 2.6/3.0 now has a module ast. This opens up new opportunities. One of
them is the possibility of introducing human readable/writable literal
object notation, based on the syntax of the python language.

I would like to know what do you think about this?

Best regards,
Zaur
--
http://mail.python.org/mailman/listinfo/python-list

Application of "with" statement in py3k. Property defining/redefining.

[Zaur Shibzoukhov]

http://szport.blogspot.com/2008/04/application-of-with-statement-in-py3k.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Application of "with" statement in py3k. Property defining/redefining.

[Zaur Shibzoukhov]

http://szport.blogspot.com/2008/04/application-of-with-statement-in-py3k.html
-- 
http://mail.python.org/mailman/listinfo/python-list