python basics

[gowtham raman]

http://yellow937.webs.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: global vars across modules

[Thomas 'PointedEars' Lahn]

John Nagle wrote:

> On 4/22/2012 12:39 PM, mambokn...@gmail.com wrote:
>> Question:
>> How can I access to the global 'a' in file_2 without resorting to the
>> whole name 'file_1.a' ?
> 
>  Actually, it's better to use the fully qualified name "file_1.a".
> Using "import *" brings in everything in the other module, which often
> results in a name clash.
> 
>  Just do
> 
> import file_1
> 
> and, if desired
> 
> localnamefora = file_1.a

I think it is better to write

  from file_1 import a as localnamefora

instead, unless `localnamefora' should be the identifier of a 
(function-)local variable.




-- 
PointedEars

Please do not Cc: me. / Bitte keine Kopien per E-Mail.
-- 
http://mail.python.org/mailman/listinfo/python-list

ANN: eGenix mx Base Distribution 3.2.4 (mxDateTime, mxTextTools, etc.)

[eGenix Team: M.-A. Lemburg]

ANNOUNCING

   eGenix.com mx Base Distribution

  Version 3.2.4 for Python 2.4 - 2.7

   Open Source Python extensions providing
 important and useful services
for Python programmers.

This announcement is also available on our web-site for online reading:
http://www.egenix.com/company/news/eGenix-mx-Base-Distribution-3.2.4-GA.html



ABOUT

The eGenix.com mx Base Distribution for Python is a collection of
professional quality software tools which enhance Python's usability
in many important areas such as fast text searching, date/time
processing and high speed data types.

The tools have a proven record of being portable across many Unix and
Windows platforms. You can write applications which use the tools on
Windows and then run them on Unix platforms without change due to the
consistent platform independent interfaces.

Contents of the distribution:

 * mxDateTime - Easy to use Date/Time Library for Python
 * mxTextTools - Fast Text Parsing and Processing Tools for Python
 * mxProxy - Object Access Control for Python
 * mxBeeBase - On-disk B+Tree Based Database Kit for Python
 * mxURL - Flexible URL Data-Type for Python
 * mxUID - Fast Universal Identifiers for Python
 * mxStack - Fast and Memory-Efficient Stack Type for Python
 * mxQueue - Fast and Memory-Efficient Queue Type for Python
 * mxTools - Fast Everyday Helpers for Python

The package also include a number of helpful smaller modules in the
mx.Misc subpackage, such as mx.Misc.ConfigFile for config file parsing
or mx.Misc.CommandLine to quickly write command line applications in
Python.

All available packages have proven their stability and usefulness in
many mission critical applications and various commercial settings all
around the world.

For more information, please see the distribution page:

http://www.egenix.com/products/python/mxBase/



NEWS

The 3.2.4 release of the eGenix mx Base Distribution is the latest
release of our open-source Python extensions.

The new patch-level version includes a few important fixes:

 *  Fixed a compatibility problem with Python 2.7's distutils that was
introduced in Python 2.7.3
 *  mxDateTime: Fixed a possible double deallocation in the mxDateTime
C API import helper. Thanks to Daniele Varrazzo for reporting this.

If you are upgrading from eGenix mx Base 3.1.x, please also see the
eGenix mx Base Distribution 3.2.0 release notes for details on what
has changed and which new features are available:

http://www.egenix.com/company/news/eGenix-mx-Base-Distribution-3.2.0-GA.html

As always, we are providing pre-built binaries for all common
platforms: Windows 32/64-bit, Linux 32/64-bit, FreeBSD 32/64-bit, Mac
OS X 32/64-bit. Source code archives are available for installation on
all other Python platforms, such as Solaris, AIX, HP-UX, etc.

To simplify installation in Zope/Plone and other egg-based systems, we
have also precompiled egg distributions for all platforms. These are
available on our own PyPI-style index server for easy and automatic
download.

Whether you are using a pre-built package or the source distribution,
installation is a simple "python setup.py install" command in all
cases. The only difference is that the pre-built packages do not
require a compiler or the Python development packages to be installed.

For a full list of changes, please refer to the eGenix mx Base Distribution
change log at

http://www.egenix.com/products/python/mxBase/changelog.html

and the change logs of the various included Python packages.



DOWNLOADS

The download archives and instructions for installing the packages can
be found on the eGenix mx Base Distribution page:

http://www.egenix.com/products/python/mxBase/



LICENSE

The eGenix mx Base package is distributed under the eGenix.com Public
License 1.1.0 which is an Open Source license similar to the Python
license. You can use the packages in both commercial and non-commercial
settings without fee or charge.

The package comes with full source code



SUPPORT

Commercial support for this product is available from eGenix.com.
Please see

http://www.egenix.com/services/support/

for details about our support offerings.

Enjoy,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 25 2012)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...   

Re: Same code cause the different result.

[Kushal Kumaran]

On Wed, Apr 25, 2012 at 12:21 PM, 叶佑群  wrote:
> Hi, all
>
>    I have code as:
>
>     pobj = subprocess.Popen (["smbpasswd", user], stdin
> =subprocess.PIPE)
>     password += "\n"
>     pobj.stdin.write (password)
>     pobj.stdin.write (password)
>
>     the command smbpasswd will change the samba user's password, In shell
> this will run as below:
>
>             [root@localhost ~]# smbpasswd mytest1
>             New SMB password:
>             Retype new SMB password:
>             [root@localhost ~]#
>
>     but in python code, it always prompt to wait input the password, it is
> seems that pobj.stdin.write () doesn't work. It is anything wrong with my
> code? I have another block code that runs as expected:
>

Maybe smbpasswd does not read the password from stdin.  Some programs
prefer to open the terminal /dev/tty directly and read from it.  You
will not be able to use subprocess directly with such programs.  You
have some options:

- find out if the smbpasswd has an option that will make it read the
password from stdin

- use an expect-like library, such as pexpect

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

Re: Same code cause the different result.

[Jean-Michel Pichavant]

叶佑群 wrote:

Hi, all

   I have code as:
/pobj = subprocess.Popen (["smbpasswd", user], stdin 
=subprocess.PIPE)

password += "\n"
pobj.stdin.write (password)
pobj.stdin.write (password)/

the command smbpasswd will change the samba user's password, In 
shell this will run as below:


/[root@localhost ~]# smbpasswd mytest1
New SMB password:
Retype new SMB password:
[root@localhost ~]# /

but in python code, it always prompt to wait input the password, 
it is seems that pobj.stdin.write () doesn't work. It is anything 
wrong with my code? I have another block code that runs as expected:


/pobj = subprocess.Popen (["passwd", user], stdin = 
subprocess.PIPE)

password = password + "\n"
pobj.stdin.write (password)
pobj.stdin.write (password)/

It is so curious and I wonder why.It is the same result when 
substitute smbpasswd with pdbedit.
I'm totally *not* an expert in those kind of things but I remember 
someone saying that sometimes, and especialy when asking for password, 
unix program do not use stdin.


However, it looks like you can use an command line option to change the 
password:


http://lists.samba.org/archive/samba/2004-August/091019.html

Cheers,

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

Re: why () is () and [] is [] work in other way?

[Thomas Rachel]

Am 24.04.2012 15:25 schrieb rusi:


Identity, sameness, equality and the verb to be are all about the same
concept(s) and their definitions are *intrinsically* circular; see
http://plato.stanford.edu/entries/identity/#2


Mybe in real life language. In programming and mathematics there are 
several forms of equality, where identity (≡) is stronger than equality (=).


Two objects can be equal (=) without being identical (≡), but not the 
other way.


As the ≡ is quite hard to type, programming languages tend to use other 
operators for this.


E.g., in C, you can have

int a;
int b;
a = 4;
b = 4;

Here a and b are equal, but not identical. One can be changed without 
changing the other.


With

int x;
int *a=&x, *b=&x;

*a and *b are identical, as they point to the same location.

*a = 4 results in *b becoming 4 as well.


In Python, you can have the situations described here as well.

You can have a list and bind it to 2 names, or you can take 2 lists and 
bind them to that name.


a = [3]
b = [3]

Here a == b is True, while a is b results in False.


Thomas




And the seeming simplicity of the circular definitions hide the actual
complexity of 'to be'
for python:  http://docs.python.org/reference/expressions.html#id26
(footnote 7)
for math/philosophy: 
http://www.math.harvard.edu/~mazur/preprints/when_is_one.pdf


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

Re: why () is () and [] is [] work in other way?

[Nobody]

On Mon, 23 Apr 2012 10:01:24 -0700, Paul Rubin wrote:

>> I can't think of a single case where 'is' is ill-defined.
> 
> If I can't predict the output of
> 
> print (20+30 is 30+20)  # check whether addition is commutative print
> (20*30 is 30*20)  # check whether multiplication is commutative
> 
> by just reading the language definition and the code, I'd have to say "is"
> is ill-defined.

If anything is ill-defined, then it's "+" and "*", i.e. it's unspecified
whether the value which they return is a unique object or a reference to
some other object.

More accurately, the existence of "is", "is not" and "id" cause many other
constructs to have "ill-defined" behaviour.

>> "a is b" is true iff 'a' and 'b' are the same object. Why should 'is'
>> lie to the user?
> 
> Whether a and b are the same object is implementation-dependent.

And what's wrong with that? If you want a language which precisely
specifies all observable behaviour, you're going to end up with a rather
useless language. For a start, it can't have a time() function. For
similar reasons, you can't have networking or any form of preemptive
concurrency (which includes any form of inter-process communication on an
OS which uses preemptive multi-tasking).

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

Re: why () is () and [] is [] work in other way?

[Steven D'Aprano]

On Wed, 25 Apr 2012 13:42:31 +0200, Thomas Rachel wrote:

> Two objects can be equal (=) without being identical (≡), but not the
> other way.


>>> x = float('nan')
>>> y = x
>>> x is y
True
>>> x == y
False


By the way, in mathematics, ≡ normally means "is equivalent to", which is 
not quite the same as "identical to".

http://mathworld.wolfram.com/Equivalent.html



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

Re: why () is () and [] is [] work in other way?

[Chris Angelico]

On Thu, Apr 26, 2012 at 3:27 AM, Steven D'Aprano
 wrote:
> By the way, in mathematics, ≡ normally means "is equivalent to", which is
> not quite the same as "identical to".

That's perhaps because, in mathematics, nobody would even think of
asking if this 4 is the same as that 4. What sort of question is it?
Four is four! How could you tell one four from another? Mathematics is
not the same as programming, and the whole concept of objects in
memory simply isn't a mathematical one at all.

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

csv: No fields, or one field?

[Neil Cerutti]

Is there an explanation or previous dicussion somewhere for the
following behavior? I haven't yet trolled the csv mailing list
archive, though that would probably be a good place to check.

Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit
(Intel)] on win 32
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> next(csv.reader(['""\r\n']))
['']
>>> next(csv.reader(['\r\n']))
[]

I hoped or assumed that the 2nd invocation should have the same
result as the first. This is not defined anywhere except in a
comment in _csv.c, as far as I can tell. There is no test in
test_csv.py verifying the behavior, either, that I found.

I admit a blank, one-field csv record just isn't very
insteresting, but isn't this a special case that ought to be
documented? The reader requires a blank, one-field record to be
defined with a quoted field, but it doesn't say so in the
documentation.

csv.writer is commutative with the reader in this case though, as
it emits '""\r\n' if you ask it to writerow(['']). This is
surprising given the definition of QUOTE_MINIMAL, which fails to
mention this special case.

  csv.QUOTE_MINIMAL

  Instructs writer objects to only quote those fields which
  contain special characters such as delimiter, quotechar or any
  of the characters in lineterminator.

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

Re: csv: No fields, or one field?

[Kiuhnm]

On 4/25/2012 20:05, Neil Cerutti wrote:

Is there an explanation or previous dicussion somewhere for the
following behavior? I haven't yet trolled the csv mailing list
archive, though that would probably be a good place to check.

Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit
(Intel)] on win 32
Type "help", "copyright", "credits" or "license" for more information.

import csv
next(csv.reader(['""\r\n']))

['']

next(csv.reader(['\r\n']))

[]


This should be documented (I trust you when you say it isn't), but it 
makes a lot of sense:


>>> next(csv.reader(['']))
[]
>>> next(csv.reader(['""']))
['']
>>> next(csv.reader([',']))
['', '']
>>> next(csv.reader([',,']))
['', '', '']
...

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

Re: csv: No fields, or one field?

[Neil Cerutti]

On 2012-04-25, Kiuhnm  wrote:
> On 4/25/2012 20:05, Neil Cerutti wrote:
>> Is there an explanation or previous dicussion somewhere for the
>> following behavior? I haven't yet trolled the csv mailing list
>> archive, though that would probably be a good place to check.
>>
>> Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit
>> (Intel)] on win 32
>> Type "help", "copyright", "credits" or "license" for more information.
> import csv
> next(csv.reader(['""\r\n']))
>> ['']
> next(csv.reader(['\r\n']))
>> []
>
> This should be documented (I trust you when you say it isn't),
> but it makes a lot of sense:
>
> >>> next(csv.reader(['']))
> []
> >>> next(csv.reader(['""']))
> ['']
> >>> next(csv.reader([',']))
> ['', '']
> >>> next(csv.reader([',,']))
> ['', '', '']

It is definitely consistent and usable, once the quoting truck is
learned.

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

RE: Appending to []

[Prasad, Ramit]

> >> Then nested calls like
> >>
> >> a = [].append('x').append('y').append('z')
> 
> Sequential appends are nearly always done within a loop.

If not in a loop and you have multiple things already in an
iterable (or create the iterable inline) you can use extend

a= []
a.extend( [ 'x, 'y, 'z' ] ) 

Or if creating a new list just populate it inline.

a= [ 'x', 'y', 'z',]


> 
> >> would be possible with a containing the resulting list
> >>
> >> ['x', 'y', 'z'].

Ramit


Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423

--

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Strange __import__() behavior

[Frank Miles]

I have an exceedingly simple function that does a "named import".
It works perfectly for one file "r"- and fails for the second "x".

If I reverse the order of being called, it is still "x" that fails,
and "r" still succeeds.

os.access() always reports that the file is readable (i.e. "true")

If I simply call up the python interpreter (python 2.6 - Debian stable)
and manually "import x" - there is no problem - both work.  Similarly
typing the __import__("x") works when typed directly at the python
prompt.  Both 'x' and 'r' pass pychecker with no errors.  The same error
occurs with winpdb - the exception message says that the file could
not be found.  'file' reports that both files are text files, and there
aren't any strange file-access permissions/attributes.

Here's the function that is failing:

def named_import(fname, description) :
import  os
pname= fname + '.py'
print "ENTRY FILE", pname, ": acces=", os.access(pname, os.R_OK)
try :
X=__import__(fname)
x= [ X.cmnds, X.variables ]
except ImportError :
print "failed"
return x 

This is the first time I've needed to import a file whose name couldn't 
be specified in the script, so there's a chance that I've done something
wrong, but it seems very weird that it works in the CL interpreter and
not in my script.

TIA for any hints or pointers to the relevant overlooked documentation!

  -F


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

Re: Strange __import__() behavior

[Chris Kaynor]

On Wed, Apr 25, 2012 at 1:05 PM, Frank Miles  wrote:

> I have an exceedingly simple function that does a "named import".
> It works perfectly for one file "r"- and fails for the second "x".
>
> If I reverse the order of being called, it is still "x" that fails,
> and "r" still succeeds.
>
> os.access() always reports that the file is readable (i.e. "true")
>
> If I simply call up the python interpreter (python 2.6 - Debian stable)
> and manually "import x" - there is no problem - both work.  Similarly
> typing the __import__("x") works when typed directly at the python
> prompt.  Both 'x' and 'r' pass pychecker with no errors.  The same error
> occurs with winpdb - the exception message says that the file could
> not be found.  'file' reports that both files are text files, and there
> aren't any strange file-access permissions/attributes.
>
> Here's the function that is failing:
>
> def named_import(fname, description) :
>import  os
>pname= fname + '.py'
>print "ENTRY FILE", pname, ": acces=", os.access(pname, os.R_OK)
>try :
>X=__import__(fname)
>x= [ X.cmnds, X.variables ]
>except ImportError :
>print "failed"
>return x
>
> This is the first time I've needed to import a file whose name couldn't
> be specified in the script, so there's a chance that I've done something
> wrong, but it seems very weird that it works in the CL interpreter and
> not in my script.
>
> TIA for any hints or pointers to the relevant overlooked documentation!
>

My first suggestion would be to remove the try...except and let the actual
exception propagate up. That might provide enough information on its own
for you to figure out the issue, and if it does not, it will provide an
error message that would be extremely helpful to anybody else trying to aid
you in figuring out the issue.

My second suggestion is that it could be an issue with relative vs absolute
imports


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

Re: why () is () and [] is [] work in other way?

[Adam Skutt]

On Apr 25, 10:38 am, Nobody  wrote:
> On Mon, 23 Apr 2012 10:01:24 -0700, Paul Rubin wrote:
> >> I can't think of a single case where 'is' is ill-defined.
>
> > If I can't predict the output of
>
> >     print (20+30 is 30+20)  # check whether addition is commutative print
> >     (20*30 is 30*20)  # check whether multiplication is commutative
>
> > by just reading the language definition and the code, I'd have to say "is"
> > is ill-defined.
>
> If anything is ill-defined, then it's "+" and "*", i.e. it's unspecified
> whether the value which they return is a unique object or a reference to
> some other object.
>

Such a definition precludes meaningful operator overloading and is
highly problematic for floating-point numbers.  There's also no way to
enforce it, but I think you know that too. :)

Identity and equality are distinct concepts in programming languages.
There's nothing that can be done about that, and no particularly good
reason to force certain language behaviors because some "programmers"
have difficulty with the distinction.

Though, maybe it's better to use a different keyword than 'is' though,
due to the plain English
connotations of the term; I like 'sameobj' personally, for whatever
little it matters.  Really, I think taking away the 'is' operator
altogether is better, so the only way to test identity is:
id(x) == id(y)
Though I would prefer:
addr(x) == addr(y)
myself, again, for what little it matters.  The right thing to do when
confronted with this problem is teach the difference and move on.

As an aside, the whole problem with 'is' and literals is perhaps the
only really good argument for a 'new' keyword/operator like C++ and
Java have.  Then it's more explicit to the programmer that they've
created two objects (in this case, anyway).

> More accurately, the existence of "is", "is not" and "id" cause many other
> constructs to have "ill-defined" behaviour.
>
> >> "a is b" is true iff 'a' and 'b' are the same object. Why should 'is'
> >> lie to the user?
>
> > Whether a and b are the same object is implementation-dependent.
>
> And what's wrong with that? If you want a language which precisely
> specifies all observable behaviour, you're going to end up with a rather
> useless language. For a start, it can't have a time() function. For
> similar reasons, you can't have networking or any form of preemptive
> concurrency (which includes any form of inter-process communication on an
> OS which uses preemptive multi-tasking).

Fully specified does not mean fully deterministic. What makes a
specification of "Any value in the range 0 through N" less 'full' than
a specification of "X" or a constant?

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

Re: Strange __import__() behavior

[Kiuhnm]

On 4/25/2012 22:05, Frank Miles wrote:

I have an exceedingly simple function that does a "named import".
It works perfectly for one file "r"- and fails for the second "x".

If I reverse the order of being called, it is still "x" that fails,
and "r" still succeeds.

os.access() always reports that the file is readable (i.e. "true")

If I simply call up the python interpreter (python 2.6 - Debian stable)
and manually "import x" - there is no problem - both work.  Similarly
typing the __import__("x") works when typed directly at the python
prompt.  Both 'x' and 'r' pass pychecker with no errors.  The same error
occurs with winpdb - the exception message says that the file could
not be found.  'file' reports that both files are text files, and there
aren't any strange file-access permissions/attributes.

Here's the function that is failing:

def named_import(fname, description) :
 import  os
 pname= fname + '.py'
 print "ENTRY FILE", pname, ": acces=", os.access(pname, os.R_OK)
 try :
 X=__import__(fname)
 x= [ X.cmnds, X.variables ]
 except ImportError :
 print "failed"
 return x

This is the first time I've needed to import a file whose name couldn't
be specified in the script, so there's a chance that I've done something
wrong, but it seems very weird that it works in the CL interpreter and
not in my script.

TIA for any hints or pointers to the relevant overlooked documentation!


I can't reproduce your problem on my configuration.
Anyway, you should note that if x.pyc and r.pyc are present, __import__ 
will try to import them and not the files x.py and r.py.

Try deleting x.pyc and r.pyc.

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

Re: Strange __import__() behavior

[Terry Reedy]

On 4/25/2012 4:05 PM, Frank Miles wrote:

I have an exceedingly simple function that does a "named import".
It works perfectly for one file "r"- and fails for the second "x".

If I reverse the order of being called, it is still "x" that fails,
and "r" still succeeds.

os.access() always reports that the file is readable (i.e. "true")

If I simply call up the python interpreter (python 2.6 - Debian stable)
and manually "import x" - there is no problem - both work.


sys.path might be different in the two modes. In each, try

import sys; print sys.path

--
Terry Jan Reedy

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

Re: why () is () and [] is [] work in other way?

[Terry Reedy]

On 4/25/2012 4:49 PM, Adam Skutt wrote:


Identity and equality are distinct concepts in programming languages.
There's nothing that can be done about that, and no particularly good
reason to force certain language behaviors because some "programmers"
have difficulty with the distinction.

Though, maybe it's better to use a different keyword than 'is' though,
due to the plain English
connotations of the term; I like 'sameobj' personally, for whatever
little it matters.  Really, I think taking away the 'is' operator
altogether is better, so the only way to test identity is:
 id(x) == id(y)
Though I would prefer:
 addr(x) == addr(y)
myself, again, for what little it matters.


The fact that id(x) is machine_addr(x) in CPython is specific to 
CPython, not required by the language spec, and not true in 
implementations that move objects around when garbage collecting.


--
Terry Jan Reedy

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

Python 3 porting

[Barry Warsaw]

I want to take this opportunity to make folks aware of several Python 3
porting initiatives and resources.

In Ubuntu 12.10, we are going to be making a big push to target all the
applications and libraries on the desktop CDs to Python 3.  While this is a
goal of Ubuntu, the intent really is to work with the wider Python community
(i.e. *you*!) to help drive more momentum toward Python 3.

We can't do this alone, and we hope you will participate.  While we on Ubuntu
have our own list of priorities, of course we want to push as much of this as
possible upstream so that everyone can benefit, regardless of platform.  We
also want to help spread the word about Python 3, and how easy it can be to
support it.

One of the best ways to get involved is to join the 'python-porting' mailing
list:

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

which is *the* forum for discussion issues, getting help, and coordinating
with others on Python 3 ports of your favorite upstream projects.

I've also resurrected the #python3 IRC channel on Freenode, for those of you
who want to provide or receive more real-time help.

Web resources for porters include:

 * http://getpython3.com/
   General Python 3 resources, forkable on github

 * http://python3porting.com/
   Lennart Regebro's excellent in-depth porting guide

 * https://wiki.ubuntu.com/Python/3
   My quick guide for porting

 * https://wiki.ubuntu.com/Python/FoundationsQPythonVersions
   Detailed plans for Python 3 on Ubuntu 12.10

 * http://tinyurl.com/6vm3egu
   My recent blog post on Ubuntu's plans for Python 3

 * http://tinyurl.com/7dsyywo
   Ubuntu's top priorities for porting, as a shared Google doc spreadsheet

Many of these pages have additional links and resources for porting, and can
help you find packages that need resources in getting to Python 3.

At the Ubuntu Developer Summit in Oakland, California, May 7-11, 2012, we'll
also be holding some sessions on Python 3, so if you're in the area, please
come by.

http://uds.ubuntu.com/

Cheers,
-Barry


signature.asc
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: why () is () and [] is [] work in other way?

[Steven D'Aprano]

On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:

> Though, maybe it's better to use a different keyword than 'is' though,
> due to the plain English
> connotations of the term; I like 'sameobj' personally, for whatever
> little it matters.  Really, I think taking away the 'is' operator
> altogether is better, so the only way to test identity is:
> id(x) == id(y)

Four reasons why that's a bad idea:

1) The "is" operator is fast, because it can be implemented directly by 
the interpreter as a simple pointer comparison (or equivalent). The id() 
idiom is slow, because it involves two global lookups and an equality 
comparison. Inside a tight loop, that can make a big difference in speed.

2) The "is" operator always has the exact same semantics and cannot be 
overridden. The id() function can be monkey-patched.

3) The "is" idiom semantics is direct: "a is b" directly tests the thing 
you want to test, namely whether a is b. The id() idiom is indirect: 
"id(a) == id(b)" only indirectly tests whether a is b.

4) The id() idiom already breaks if you replace names a, b with 
expressions:

>>> id([1,2]) == id([3,4])
True



> Though I would prefer:
> addr(x) == addr(y)

But that's absolutely wrong. id(x) returns an ID, not an address. It just 
happens that, as an accident of implementation, the CPython interpreter 
uses the object address as an ID, because objects can't move. That's not 
the case for all implementations. In Jython, objects can move and the 
address is not static, and so IDs are assigned on demand starting with 1:


steve@runes:~$ jython
Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19)
[OpenJDK Client VM (Sun Microsystems Inc.)] on java1.6.0_18
Type "help", "copyright", "credits" or "license" for more information.
>>> id(42)
1
>>> id("Hello World!")
2
>>> id(None)
3


Other implementations may make other choices. I don't believe that the 
language even defines the id as a number, although I could be wrong about 
that.

Personally, I prefer the Jython approach, because it avoids those 
annoying questions like "How do I dereference the address of an 
object?" (answer: Python is not C, you can't do that), and IDs are 
globally unique and never reused for the lifetime of the process.


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

Re: why () is () and [] is [] work in other way?

[Roy Smith]

In article <4f9833ff$0$29965$c3e8da3$54964...@news.astraweb.com>,
 Steven D'Aprano  wrote:

> On Wed, 25 Apr 2012 13:42:31 +0200, Thomas Rachel wrote:
> 
> > Two objects can be equal (=) without being identical (≡), but not the
> > other way.
> 
> 
> >>> x = float('nan')
> >>> y = x
> >>> x is y
> True
> >>> x == y
> False

I love it.   Thanks for posting that.
-- 
http://mail.python.org/mailman/listinfo/python-list

Upgrading from 2.7 to 3.x

[deuteros]

I'm fairly new to Python I have version 2.7 installed on my computer. However 
my professor wants us all to use the latest version of Python. How do I go 
about upgrading? Do I just install the new version? Do I have to do anything 
with the old version already installed?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Upgrading from 2.7 to 3.x

[Xavier Ho]

What operating system are you running?

Cheers,
Xav



On 26 April 2012 13:08, deuteros  wrote:

> I'm fairly new to Python I have version 2.7 installed on my computer.
> However
> my professor wants us all to use the latest version of Python. How do I go
> about upgrading? Do I just install the new version? Do I have to do
> anything
> with the old version already installed?
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: why () is () and [] is [] work in other way?

[Adam Skutt]

On Apr 25, 8:01 pm, Steven D'Aprano  wrote:
> On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
> > Though, maybe it's better to use a different keyword than 'is' though,
> > due to the plain English
> > connotations of the term; I like 'sameobj' personally, for whatever
> > little it matters.  Really, I think taking away the 'is' operator
> > altogether is better, so the only way to test identity is:
> >     id(x) == id(y)
>
> Four reasons why that's a bad idea:
>
> 1) The "is" operator is fast, because it can be implemented directly by
> the interpreter as a simple pointer comparison (or equivalent). The id()
> idiom is slow, because it involves two global lookups and an equality
> comparison. Inside a tight loop, that can make a big difference in speed.

The runtime can optimize the two operations to be equivalent, since
they are logically equivalent operations.  If you removed 'is',
there's little reason to believe it would do otherwise.

>
> 2) The "is" operator always has the exact same semantics and cannot be
> overridden. The id() function can be monkey-patched.
>

I can't see how that's useful at all.  Identity is a fundamental
property of an object; hence retrieval of it must be a language
operation.  The fact Python chooses to do otherwise is unfortunate,
but also irrelevant to my position.

> 3) The "is" idiom semantics is direct: "a is b" directly tests the thing
> you want to test, namely whether a is b. The id() idiom is indirect:
> "id(a) == id(b)" only indirectly tests whether a is b.

The two expressions are logically equivalent, so I don't see how this
matters, nor how it is true.

>
> 4) The id() idiom already breaks if you replace names a, b with
> expressions:
>
> >>> id([1,2]) == id([3,4])
>
> True

It's not broken at all.  The lifetime of temporary objects is
intentionally undefined, and that's a /good/ thing.  What's
unfortunate is that CPython optimizes temporaries differently between
the two logically equivalent expressions.

As long as this holds:
>>> class A(object):
... def __del__(self):
...print "Farewell to: %d" % id(self)
...
>>> A() is A()
Farewell to: 4146953292
Farewell to: 4146953260
False
>>> id(A()) == id(A())
Farewell to: 4146953420
Farewell to: 4146953420
True

then there's nothing "broken" about the behavior of either expression.
I personally think logically equivalent expressions should give the
same results, but since both operations follow the rules of object
identity correctly, it's not the end of the world.  It's only
surprising to the programmer if:
1) They don't understand identity.
2) They don't understand what objects are and are not temporaries.

Code that relies on the identity of a temporary object is generally
incorrect.  This is why C++ explicitly forbids taking the address
(identity) of temporaries.  As such, the language behavior in your
case is inconsequential.  Making demons fly out of the programmer's
nose would be equally appropriate.

The other solution is to do what Java and C# do: banish id() entirely
and only provide 'is' (== in Java, Object.ReferenceEquals() in C#).
That seems just as fine, really,  Practically, it's also probably the
better solution for CPython, which is fine by me.  My preference for
keeping id() and removing 'is' probably comes from my background as a C
++ programmer, and I already said it matters very little.

> But that's absolutely wrong. id(x) returns an ID, not an address.
> It just
> happens that, as an accident of implementation, the CPython interpreter
> uses the object address as an ID, because objects can't move. That's not
> the case for all implementations. In Jython, objects can move and the
> address is not static, and so IDs are assigned on demand starting with 1:
>
> steve@runes:~$ jython
> Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19)
> [OpenJDK Client VM (Sun Microsystems Inc.)] on java1.6.0_18
> Type "help", "copyright", "credits" or "license" for more information.>>> 
> id(42)
> 1
> >>> id("Hello World!")
> 2
> >>> id(None)
>
> 3
>

An address is an identifier: a number that I can use to access a
value[1].  I never said that id() must return an address the host CPU
understands (virtual, physical, or otherwise).  Most languages use
addresses that the host CPU cannot understand without assistance at
least sometimes, including C on some platforms.

> Other implementations may make other choices. I don't believe that the
> language even defines the id as a number, although I could be wrong about
> that.

http://docs.python.org/library/functions.html#id says it must be an
integer of some sort.  Even if it didn't say that, it hardly seems as
a practical imposition.

>
> Personally, I prefer the Jython approach, because it avoids those
> annoying questions like "How do I dereference the address of an
> object?" (answer: Python is not C, you can't do that),

The right way to solve that question isn't to fix the runtime, but to
teach people what pointer semantics actually mean, m

Re: why () is () and [] is [] work in other way?

[Chris Angelico]

On Thu, Apr 26, 2012 at 1:50 PM, Adam Skutt  wrote:
> On Apr 25, 8:01 pm, Steven D'Aprano  +comp.lang.pyt...@pearwood.info> wrote:
>> 2) The "is" operator always has the exact same semantics and cannot be
>> overridden. The id() function can be monkey-patched.
>
> I can't see how that's useful at all.  Identity is a fundamental
> property of an object; hence retrieval of it must be a language
> operation.
> ...
> The other solution is to do what Java and C# do: banish id() entirely
> and only provide 'is' (== in Java, Object.ReferenceEquals() in C#).

The 'is' operator is a language feature. The id() function is not.

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

Re: csv: No fields, or one field?

[Tim Roberts]

Neil Cerutti  wrote:

>Is there an explanation or previous dicussion somewhere for the
>following behavior? I haven't yet trolled the csv mailing list
>archive, though that would probably be a good place to check.
>
>Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit
>(Intel)] on win 32
>Type "help", "copyright", "credits" or "license" for more information.
 import csv
 next(csv.reader(['""\r\n']))
>['']
 next(csv.reader(['\r\n']))
>[]
>
>I hoped or assumed that the 2nd invocation should have the same
>result as the first.

Really?  That's not at all what I would have expected.  The first line
contains one field.  The second line contains 0 fields.  It's consistent,
and syntactically valid.

>I admit a blank, one-field csv record just isn't very
>insteresting, but isn't this a special case that ought to be
>documented? 

But that's what you have in the first line, and the reader has returned to
you a list containing one (empty) string.

I just don't see your interpretation.  The results are exactly what I would
have expected.
-- 
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Upgrading from 2.7 to 3.x

[Stefan Behnel]

deuteros, 26.04.2012 05:08:
> I'm fairly new to Python I have version 2.7 installed on my computer. However 
> my professor wants us all to use the latest version of Python.

Did he/she explicitly tell you to install Python 3? 2.7 is the latest
version of Python 2.x, some people may mix that up.

OTOH, especially for educational purposes, Python 3 is likely the better
choice.


> How do I go 
> about upgrading? Do I just install the new version? Do I have to do anything 
> with the old version already installed?

You can keep the old version and install the new one next to it. However,
we cannot give more detailed help without knowing what operating system you
are using on your computer. In case it's Windows (which is the usual guess
when people fail to mention what they have, although it may include MacOS
these days), run the installer that you can download at http://python.org

Also note that there is a separate mailing list (the tutor list)
specifically targeted at new Python users:

http://mail.python.org/mailman/listinfo/tutor

Stefan

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

Re: why () is () and [] is [] work in other way?

[John Nagle]

On 4/25/2012 5:01 PM, Steven D'Aprano wrote:

On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:


Though, maybe it's better to use a different keyword than 'is' though,
due to the plain English
connotations of the term; I like 'sameobj' personally, for whatever
little it matters.  Really, I think taking away the 'is' operator
altogether is better, so the only way to test identity is:
 id(x) == id(y)


Four reasons why that's a bad idea:

1) The "is" operator is fast, because it can be implemented directly by
the interpreter as a simple pointer comparison (or equivalent).


   This assumes that everything is, internally, an object.  In CPython,
that's the case, because Python is a naive interpreter and everything,
including numbers, is "boxed".  That's not true of PyPy or Shed Skin.
So does "is" have to force the creation of a temporary boxed object?

   The concept of "object" vs. the implementation of objects is
one reason you don't necessarily want to expose the implementation.

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

Re: why () is () and [] is [] work in other way?

[Chris Angelico]

On Thu, Apr 26, 2012 at 3:48 PM, John Nagle  wrote:
>   This assumes that everything is, internally, an object.  In CPython,
> that's the case, because Python is a naive interpreter and everything,
> including numbers, is "boxed".  That's not true of PyPy or Shed Skin.
> So does "is" have to force the creation of a temporary boxed object?

Interesting point. Presumably the only types that can be unboxed are
those for which identity vs equality is pretty much immaterial, so the
question won't really matter. I'd be inclined to either have it return
False if either/both is unboxed, or else return True if both are equal
unboxed numbers, whichever is the most convenient to implement.

My opinion doesn't matter--
My opinion doesn't matter--
My opinion doesn't matter, matter, matter, matter, matter!
(WS Gilbert, "Ruddigore")

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