Re: Problem with python

[Grant Edwards]

On 2021-09-04, Hope Rouselle  wrote:
> Igor Korot  writes:
>
>> Hi,
>> Will this syntax work in python 2?
>
> If you say
>
>   print(something)
>
> it works in both.

But it doesn't always work the _same_ in both. If you're expecting
some particular output, then one or the other might not won't "work".

> So, stick to this syntax.

Only if you import print_function from __future__ in 2.x

--
Grant


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

Re: Problem with python

[Grant Edwards]

On 2021-09-04, Peter J. Holzer  wrote:
> On 2021-09-04 14:29:47 -0500, Igor Korot wrote:
>> Will this syntax work in python 2?
>
> Yes. It's just a redundant pair of parentheses.

Not really. With the parens, it doesn't produce the same results in
2.x unless you import the print function from the future:

 Python 3.9.6 (default, Aug  9 2021, 12:35:39)
 [GCC 10.3.0] on linux
 Type "help", "copyright", "credits" or "license" for more information.
 >>> print(1,2)
 1 2

 Python 2.7.18 (default, Jul 18 2021, 14:51:54)
 [GCC 10.3.0] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 >>> print(1,2)
 (1, 2)

 Python 2.7.18 (default, Jul 18 2021, 14:51:54)
 [GCC 10.3.0] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 >>> from __future__ import print_function
 >>> print(1,2)
 1 2




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

Re: Problem with python

[Terry Reedy]

On 9/4/2021 2:27 PM, Igor Korot wrote:

Hi, ALL,

[code]
igor@WaylandGnome ~/bakefile $ python
Python 3.9.6 (default, Aug  8 2021, 17:26:32)
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

from distutils import sysconfig


In 3.10, distutils and d.sysconfig are deprecated, with suggestions to 
use setuptools or sysconfig modules instead.



print sysconfig.get_python_inc()

   File "", line 1
 print sysconfig.get_python_inc()
   ^
SyntaxError: invalid syntax


In interactive mode, print is not usually needed.

>>> sysconfig.get_python_inc()
'C:\\Programs\\Python310\\include'


--
Terry Jan Reedy

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

Re: Problem with python

[Dennis Lee Bieber]

On Sat, 4 Sep 2021 22:41:12 +0200, "Peter J. Holzer" 
declaimed the following:

>Python 3 to be time well spent in 2021, especially not to someone who
>apparently just wants to report a bug to some unnamed project (whose
>maintainers may or may not care about Python2 compatibility).
>

Given the nature of the error reported by the OP... It may be closer to
state "whose maintainers may or may not care about" /Python3/
"compatibility"; the code appears to already be Python2 compatible 



-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/

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

Re: Problem with python

[Hope Rouselle]

Igor Korot  writes:

> Hi,
> Will this syntax work in python 2?

If you say

  print(something)

it works in both.  So, stick to this syntax.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem with python

[Peter J. Holzer]

On 2021-09-04 21:07:11 +0100, Rob Cliffe via Python-list wrote:
> Well, up to a point.
> In Python 2 the output from
>     print 1, 2
> is '1 2'
> In Python 3 if you add brackets:
>     print(1, 2)
> the output is the same.
> But if you transplant that syntax back into Python 2, the output from
>     print(1, 2)
> is '(1, 2)'.  The brackets have turned two separate items into a single
> tuple.

Yes. I was just talking about that specific case with a single function
call. I do not consider explaining the differences between Python 2 and
Python 3 to be time well spent in 2021, especially not to someone who
apparently just wants to report a bug to some unnamed project (whose
maintainers may or may not care about Python2 compatibility).

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


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

Re: Problem with python

[Rob Cliffe via Python-list]

Well, up to a point.
In Python 2 the output from
    print 1, 2
is '1 2'
In Python 3 if you add brackets:
    print(1, 2)
the output is the same.
But if you transplant that syntax back into Python 2, the output from
    print(1, 2)
is '(1, 2)'.  The brackets have turned two separate items into a single 
tuple.
If you want Python 2- and 3-compatibility you must find a work-around 
such as

    print('%d %d' % (1,2))
    print('%s %s' % (1,2))
    print(str(1) + ' ' + str(2))

Similarly
    'print' in Python 2 outputs a blank line.
    'print()' in Python 3 outputs a blank line.  In python 2 it prints 
a line containing a blank tuple: '()'.

A 2/3-compatible way of outputting a blank line is
    print('')

Best wishes
Rob Cliffe




On 04/09/2021 20:50, Peter J. Holzer wrote:

On 2021-09-04 14:29:47 -0500, Igor Korot wrote:

Will this syntax work in python 2?

Yes. It's just a redundant pair of parentheses.

 hp




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

Re: Problem with python

[Peter J. Holzer]

On 2021-09-04 14:29:47 -0500, Igor Korot wrote:
> Will this syntax work in python 2?

Yes. It's just a redundant pair of parentheses.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


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

Re: Problem with python

[Igor Korot]

Hi,
Will this syntax work in python 2?

Thank you.

On Sat, Sep 4, 2021 at 1:52 PM dn via Python-list
 wrote:
>
> On 05/09/2021 06.27, Igor Korot wrote:
> > Hi, ALL,
> >
> > [code]
> > igor@WaylandGnome ~/bakefile $ python
> > Python 3.9.6 (default, Aug  8 2021, 17:26:32)
> > [GCC 10.3.0] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
>  from distutils import sysconfig
>  print sysconfig.get_python_inc()
> >   File "", line 1
> > print sysconfig.get_python_inc()
> >   ^
> > SyntaxError: invalid syntax
> 
> > [/code]
> >
> > What is the proper way to fix this?
>
> Remember that in Python3 print became a function:
>
>  print( sysconfig.get_python_inc() )
>
> --
> Regards,
> =dn
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem with python

[Igor Korot]

Thx guys.
I submitted a bug report for the project that uses it.

On Sat, Sep 4, 2021 at 1:42 PM Joel Goldstick  wrote:
>
> On Sat, Sep 4, 2021 at 2:29 PM Igor Korot  wrote:
> >
> > Hi, ALL,
> >
> > [code]
> > igor@WaylandGnome ~/bakefile $ python
> > Python 3.9.6 (default, Aug  8 2021, 17:26:32)
> > [GCC 10.3.0] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> from distutils import sysconfig
> > >>> print sysconfig.get_python_inc()
> >   File "", line 1
> > print sysconfig.get_python_inc()
>
>  print( sysconfig.get_python_inc())
>
> Since python3 print is a function.
> >   ^
> > SyntaxError: invalid syntax
> > >>>
> > [/code]
> >
> > What is the proper way to fix this?
> >
> > Thank you.
> > --
> > https://mail.python.org/mailman/listinfo/python-list
>
>
>
> --
> Joel Goldstick
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem with python

[dn via Python-list]

On 05/09/2021 06.27, Igor Korot wrote:
> Hi, ALL,
> 
> [code]
> igor@WaylandGnome ~/bakefile $ python
> Python 3.9.6 (default, Aug  8 2021, 17:26:32)
> [GCC 10.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
 from distutils import sysconfig
 print sysconfig.get_python_inc()
>   File "", line 1
> print sysconfig.get_python_inc()
>   ^
> SyntaxError: invalid syntax

> [/code]
> 
> What is the proper way to fix this?

Remember that in Python3 print became a function:

 print( sysconfig.get_python_inc() )

-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem with python

[Mats Wichmann]

On 9/4/21 12:27 PM, Igor Korot wrote:

Hi, ALL,

[code]
igor@WaylandGnome ~/bakefile $ python
Python 3.9.6 (default, Aug  8 2021, 17:26:32)
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

from distutils import sysconfig
print sysconfig.get_python_inc()

   File "", line 1
 print sysconfig.get_python_inc()
   ^
SyntaxError: invalid syntax



[/code]

What is the proper way to fix this?


print is a function in Python 3.

print(sysconfig.get_python_inc())

Try:

>>> help(print)

for a quick check.

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

Re: Problem with python

[Joel Goldstick]

On Sat, Sep 4, 2021 at 2:29 PM Igor Korot  wrote:
>
> Hi, ALL,
>
> [code]
> igor@WaylandGnome ~/bakefile $ python
> Python 3.9.6 (default, Aug  8 2021, 17:26:32)
> [GCC 10.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from distutils import sysconfig
> >>> print sysconfig.get_python_inc()
>   File "", line 1
> print sysconfig.get_python_inc()

 print( sysconfig.get_python_inc())

Since python3 print is a function.
>   ^
> SyntaxError: invalid syntax
> >>>
> [/code]
>
> What is the proper way to fix this?
>
> Thank you.
> --
> https://mail.python.org/mailman/listinfo/python-list



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

Problem with python

[Igor Korot]

Hi, ALL,

[code]
igor@WaylandGnome ~/bakefile $ python
Python 3.9.6 (default, Aug  8 2021, 17:26:32)
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils import sysconfig
>>> print sysconfig.get_python_inc()
  File "", line 1
print sysconfig.get_python_inc()
  ^
SyntaxError: invalid syntax
>>>
[/code]

What is the proper way to fix this?

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

Re: PROBLEM WITH PYTHON IDLE

[Mats Wichmann]

On 5/14/20 5:15 AM, aduojo samson wrote:
> Hello, my name is Samson Haruna and I am from Nigeria.I have a problem with
> my python 3.8, any time I click on it to write my python code I get this
> error message "IDLE subprocess didn't make connection". I have uninstalled
> and reinstalled several times, I have even deleted and downloaded a new
> one, it works for some time then it stops giving me the above mentioned
> error message. what can I do.

Did you read the instructions in the link presented when it gives you
that error?

https://docs.python.org/3/library/idle.html#startup-failure

Does this help?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PROBLEM WITH PYTHON IDLE

[Souvik Dutta]

What is your os? Where have you downloaded it from? What type of package
did you download?
Souvik flutter dev

On Thu, May 14, 2020, 5:36 PM aduojo samson  wrote:

> Hello, my name is Samson Haruna and I am from Nigeria.I have a problem with
> my python 3.8, any time I click on it to write my python code I get this
> error message "IDLE subprocess didn't make connection". I have uninstalled
> and reinstalled several times, I have even deleted and downloaded a new
> one, it works for some time then it stops giving me the above mentioned
> error message. what can I do.
>
> Samson.A.Haruna
> 08106587039
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

PROBLEM WITH PYTHON IDLE

[aduojo samson]

Hello, my name is Samson Haruna and I am from Nigeria.I have a problem with
my python 3.8, any time I click on it to write my python code I get this
error message "IDLE subprocess didn't make connection". I have uninstalled
and reinstalled several times, I have even deleted and downloaded a new
one, it works for some time then it stops giving me the above mentioned
error message. what can I do.

Samson.A.Haruna
08106587039
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help Problem with python : python-3.8.3rc1-amd64

[Mats Wichmann]

On 5/11/20 9:25 PM, Michael Torrie wrote:
> On 5/11/20 8:33 PM, Buddy Peacock wrote:
>> I am trying to install python on my surface with windows 10, version 1903,
>> build 18362.778.  The installer seems to think everything worked. But there
>> is no Python folder anywhere on the system.  I looked in the root directory
>> as well as "Program Files" and "Program Files (x86)" and not in any users
>> folders either.  I have uninstalled and re-installed twice.  Once after
>> shutting down and restarting.  Your help would be appreciated as I am
>> taking an on-line programming class.
> 
> Unless you specifically selected "install for all users" it's probably
> going to be installed to your home directory under the hidden folder
> "AppData," specially "AppData\Local\Programs\Python."  Be sure to tell
> the installer to put python in your path--that way no matter where it
> is, from the command prompt you can just run "python" and it will fire
> up the interpreter. 

That's what the Python Launcher is for... instead of always having to
get the path to python itself into the Windows path - and change it each
time the version bumps, since the path includes the version number -
"py" goes in your path in a place it's always found, so "py" from a
command prompt works, with options to select a specific Python if you
have several installed.  Bonus: "py" works from PowerShell as well
("python" tends not to).

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

Re: Help Problem with python : python-3.8.3rc1-amd64

[Terry Reedy]

On 5/11/2020 11:34 PM, Michael Torrie wrote:

On 5/11/20 9:25 PM, Michael Torrie wrote:

On 5/11/20 8:33 PM, Buddy Peacock wrote:

I am trying to install python on my surface with windows 10, version 1903,
build 18362.778.  The installer seems to think everything worked. But there
is no Python folder anywhere on the system.  I looked in the root directory
as well as "Program Files" and "Program Files (x86)" and not in any users
folders either.  I have uninstalled and re-installed twice.  Once after
shutting down and restarting.  Your help would be appreciated as I am
taking an on-line programming class.


Unless you specifically selected "install for all users" it's probably
going to be installed to your home directory under the hidden folder
"AppData," specially "AppData\Local\Programs\Python."  Be sure to tell


In particular, C:\Users\Yourname\AppDate


the installer to put python in your path--that way no matter where it
is, from the command prompt you can just run "python" and it will fire
up the interpreter.  Additionally, "Idle" (the integrated development
environment) will probably be in your start menu.


There should also be a plain python icon in the Python3.8 group.  In any 
case,


>>> import sys; sys.executable
will give the path to the current python.exe.



Hmm, actually I think the AppData install path is if you install from
the Microsoft Store, which you could try.


That is the default for the python.org installer.


--
Terry Jan Reedy

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

Re: Help Problem with python : python-3.8.3rc1-amd64

[Michael Torrie]

On 5/11/20 9:25 PM, Michael Torrie wrote:
> On 5/11/20 8:33 PM, Buddy Peacock wrote:
>> I am trying to install python on my surface with windows 10, version 1903,
>> build 18362.778.  The installer seems to think everything worked. But there
>> is no Python folder anywhere on the system.  I looked in the root directory
>> as well as "Program Files" and "Program Files (x86)" and not in any users
>> folders either.  I have uninstalled and re-installed twice.  Once after
>> shutting down and restarting.  Your help would be appreciated as I am
>> taking an on-line programming class.
> 
> Unless you specifically selected "install for all users" it's probably
> going to be installed to your home directory under the hidden folder
> "AppData," specially "AppData\Local\Programs\Python."  Be sure to tell
> the installer to put python in your path--that way no matter where it
> is, from the command prompt you can just run "python" and it will fire
> up the interpreter.  Additionally, "Idle" (the integrated development
> environment) will probably be in your start menu.

Hmm, actually I think the AppData install path is if you install from
the Microsoft Store, which you could try.

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

Re: Help Problem with python : python-3.8.3rc1-amd64

[Michael Torrie]

On 5/11/20 8:33 PM, Buddy Peacock wrote:
> I am trying to install python on my surface with windows 10, version 1903,
> build 18362.778.  The installer seems to think everything worked. But there
> is no Python folder anywhere on the system.  I looked in the root directory
> as well as "Program Files" and "Program Files (x86)" and not in any users
> folders either.  I have uninstalled and re-installed twice.  Once after
> shutting down and restarting.  Your help would be appreciated as I am
> taking an on-line programming class.

Unless you specifically selected "install for all users" it's probably
going to be installed to your home directory under the hidden folder
"AppData," specially "AppData\Local\Programs\Python."  Be sure to tell
the installer to put python in your path--that way no matter where it
is, from the command prompt you can just run "python" and it will fire
up the interpreter.  Additionally, "Idle" (the integrated development
environment) will probably be in your start menu.

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

Help Problem with python : python-3.8.3rc1-amd64

[Buddy Peacock]

I am trying to install python on my surface with windows 10, version 1903,
build 18362.778.  The installer seems to think everything worked. But there
is no Python folder anywhere on the system.  I looked in the root directory
as well as "Program Files" and "Program Files (x86)" and not in any users
folders either.  I have uninstalled and re-installed twice.  Once after
shutting down and restarting.  Your help would be appreciated as I am
taking an on-line programming class.
Al (Buddy) Peacock, PMP, MCCT,  ITILv3, SMC, CSM, SPOC
(920) 740-3411
linkedin.com/in/buddypeacock 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: problem with python 3.8.1

[DL Neil via Python-list]

On 20/01/20 7:35 PM, coolguy 12336 wrote:

hi I can not install the py launcher and I really need it for something I
used repair and tried it again but it still didn't work.Do you know how to
fix my issue and if you do please email me back as soon as possible thank
you.



Hi, are you a student - if so, where?

This is a volunteer community. Help us to help you...

Which Operating System?
From where are you downloading Python?
What did you do (that appeared to work)?
What was the error message?
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

problem with python 3.8.1

[coolguy 12336]

hi I can not install the py launcher and I really need it for something I
used repair and tried it again but it still didn't work.Do you know how to
fix my issue and if you do please email me back as soon as possible thank
you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Installation problem with python 3.7 in windows 7 ultimate p.c(32 bit) showing unspecified error 0x80072ee7...

[eryk sun]

On 5/22/19, Sirso Bhatto  wrote:
>
>I am Shirsendu. I encountered a problem while installing python 3.7
> in my windows 7 ultimate p.c(32 bit) . It is showing an unspecified error
> of 0x80072ee7 when i am trying to initialize it in my pc. Please help me.

A status code with only the high bit set in the high nibble (e.g. 0x8)
is likely a failure code in the HRESULT [1] domain. 0x007 in the next
3 nibbles (i.e. the facility code) is the Windows API facility (i.e.
FACILITY_WIN32). This tells us that the lower 4 nibbles (16-bit word)
is a Windows system error code [2]. In this case, 0x2EE7 (12007) is
the WinINet error code [3] ERROR_INTERNET_NAME_NOT_RESOLVED, i.e. the
server name could not be resolved. It appears there's an issue with
your network connection or DNS configuration in this context. Try
using the offline executable installer [4], and make sure to clear the
option to install the debug binaries and symbols since those have to
be downloaded.

[1]: 
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/0642cb2f-2075-4469-918c-4441e69c548a
[2]: https://docs.microsoft.com/en-us/windows/desktop/Debug/system-error-codes
[3]: https://docs.microsoft.com/en-us/windows/desktop/WinInet/wininet-errors
[4]: https://www.python.org/ftp/python/3.7.3/python-3.7.3.exe
-- 
https://mail.python.org/mailman/listinfo/python-list

Installation problem with python 3.7 in windows 7 ultimate p.c(32 bit) showing unspecified error 0x80072ee7...

[Sirso Bhatto]

Hi..
   I am Shirsendu. I encountered a problem while installing python 3.7
in my windows 7 ultimate p.c(32 bit) . It is showing an unspecified error
of 0x80072ee7 when i am trying to initialize it in my pc. Please help me.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help? How do i solve this problem with Python List Concept

[Peter J. Holzer]

On 2019-05-11 22:02:39 +0100, Ben Bacarisse wrote:
> Donald Tripdarlinq  writes:
> > In the traditional Yoruba tribal Set-Up in Nigeria,West Africa the
> > tradition of inheritance is very important. Now, The relative position
> > of a child in the family counts when the issue of inheritance is
> > considered.
> >
> > Question: Now a farmer with 10 children died without leaving a will
> > and the Family "Ebi"(Which consist of the extended family) decided
> > that the property would be in proportion of their respective age. The
> > Children were born with 3 years intervals except the second to last
> > and the last born with the interval of 2 and 4 years respectively. Use
> > the concept of list to write a simple python program to generate the
> > individual children inheritance if the man left N230,000 Before his
> > death
> 
> You need a little more than that.  If the inheritance is to be in
> proportion to the ages, you need to know at least one actual age, rather
> than just the age gaps.

The iron law of school maths problems says that all problems must have a
nice solution. This usually means something like π or e, but in this
case we'll just settle for integers. 

So the sum of the ages of the children must be a divisor of 23.

We can easily work out that the sum must be
10n + 9*4 + 8*2 + (7 + 6 + 5 + 4 + 3 + 2 + 1) * 3
(the details are left as an exercise for the reader) and we can
therefore compute the age of the youngest child:

#!/usr/bin/python3

def f():
n = 0
while True:
s = 10 * n + 136
if 23 % s == 0:
print(n)
if s > 23:
return
n += 1
f()

This immediately returns an empty result. Which means that there is an
error in the problem statement. Finding the teacher's mistakes is of
course every students favourite pastime and teachers try to please their
students by making trivial mistakes, like swapping two numbers. And
indeed, if we swap the age gaps between the youngest children, we get
nice round numbers:

The youngest child is 5, the oldest 32, and the divisor is 1250.
So the youngest inherits 6250 NGN, the oldest 4 NGN, and the rest
are trivial to compute.

You owe the Oracle a first print of "Rechnung auff der Linihen und
Federn" and the first-born of a Nigerian princess. 

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


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

Re: Help? How do i solve this problem with Python List Concept

[Gregory Ewing]

Chris Angelico wrote:

Given that we're dealing with a Nigerian inheritance, your Python
program will probably need to start with "import smtplib", and the
list in question will be the addresses of the people to send your 419
to


Obviously it's a Nigerian homework scam.

"Dearest Sir,I am the youngest son of a wealthy Nigerian businessman
who died leaving the sum of N$230,000(two Hundred and thirty thousand
nigerianDollars) to be split between his 10 childern. I urgently need
your help to calculate the amount of my inheritance..."

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

Re: Help? How do i solve this problem with Python List Concept

[Chris Angelico]

On Sun, May 12, 2019 at 10:33 AM Donald Tripdarlinq
 wrote:
>
> In the traditional Yoruba tribal Set-Up in Nigeria,West Africa the tradition 
> of inheritance is very important. Now, The relative position of a child in 
> the family  counts when the issue of inheritance is considered.
>
> Question: Now a farmer with 10 children died without leaving a will and  the 
> Family "Ebi"(Which consist of the extended family) decided that the property 
> would be in proportion of their respective age. The Children were born with 3 
> years intervals except the second to last and the last born with the interval 
> of 2 and 4 years respectively. Use the concept of list to write a simple 
> python program to generate the individual children inheritance if the man 
> left N230,000 Before his death
>

Given that we're dealing with a Nigerian inheritance, your Python
program will probably need to start with "import smtplib", and the
list in question will be the addresses of the people to send your 419
to

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

Re: Help? How do i solve this problem with Python List Concept

[Ben Bacarisse]

Donald Tripdarlinq  writes:

> In the traditional Yoruba tribal Set-Up in Nigeria,West Africa the
> tradition of inheritance is very important. Now, The relative position
> of a child in the family counts when the issue of inheritance is
> considered.
>
> Question: Now a farmer with 10 children died without leaving a will
> and the Family "Ebi"(Which consist of the extended family) decided
> that the property would be in proportion of their respective age. The
> Children were born with 3 years intervals except the second to last
> and the last born with the interval of 2 and 4 years respectively. Use
> the concept of list to write a simple python program to generate the
> individual children inheritance if the man left N230,000 Before his
> death

You need a little more than that.  If the inheritance is to be in
proportion to the ages, you need to know at least one actual age, rather
than just the age gaps.  Maybe the exercise is to write a function that
takes the age of, say, the youngest child and then calculates the
inheritances?

Anyway, your starting point will be to work through an example on paper
so you are clear about what the calculations are.

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

Help? How do i solve this problem with Python List Concept

[Donald Tripdarlinq]

In the traditional Yoruba tribal Set-Up in Nigeria,West Africa the tradition of 
inheritance is very important. Now, The relative position of a child in the 
family  counts when the issue of inheritance is considered.

Question: Now a farmer with 10 children died without leaving a will and  the 
Family "Ebi"(Which consist of the extended family) decided that the property 
would be in proportion of their respective age. The Children were born with 3 
years intervals except the second to last and the last born with the interval 
of 2 and 4 years respectively. Use the concept of list to write a simple python 
program to generate the individual children inheritance if the man left 
N230,000 Before his death
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help? How do i solve this problem with Python List Concept

[Richard Damon]

On 5/11/19 5:02 PM, Ben Bacarisse wrote:
> Donald Tripdarlinq  writes:
> 
>> In the traditional Yoruba tribal Set-Up in Nigeria,West Africa the
>> tradition of inheritance is very important. Now, The relative position
>> of a child in the family counts when the issue of inheritance is
>> considered.
>>
>> Question: Now a farmer with 10 children died without leaving a will
>> and the Family "Ebi"(Which consist of the extended family) decided
>> that the property would be in proportion of their respective age. The
>> Children were born with 3 years intervals except the second to last
>> and the last born with the interval of 2 and 4 years respectively. Use
>> the concept of list to write a simple python program to generate the
>> individual children inheritance if the man left N230,000 Before his
>> death
> 
> You need a little more than that.  If the inheritance is to be in
> proportion to the ages, you need to know at least one actual age, rather
> than just the age gaps.  Maybe the exercise is to write a function that
> takes the age of, say, the youngest child and then calculates the
> inheritances?
> 
> Anyway, your starting point will be to work through an example on paper
> so you are clear about what the calculations are.
> 

Or your output needs to be a two dimensional table, where, say the
columns represent the shares for each of the children, and the rows are
the year (like the age of the youngest).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: problem with Python 3.6 + PyX

[skysign]

Please install below. in my case, it is resolved.

sudo apt install texinfo
sudo apt install texlive-binaries

2017년 2월 11일 토요일 오전 8시 49분 36초 UTC+9, stalker5 님의 말:
> Yes, I have a Tex engine on my system.
> How can i fix the problem with the PATH ?
> Even if i execute the .py script directly by python (I mean :not inside 
> a LateX file) pyx need to reach the TeX system ?
> Is there a config file  to fix the PATH ? Where ?
> 
> Thanks a lot !! Ciao
> --
> Olivier
> 
> > PyX requires TeX to render textual glyphs into the image. Do you have it
> > installed? If so, is it "reachable" by your $PATH variable?
> >
> > A quick test to re-render my PyX-based images with Python 3.6 didn't reveal
> > any problem...
> >
> > ciao, lele.
> >

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

Re: problem with Python 3.6 + PyX

[stalker5]

Yes, I have a Tex engine on my system.
How can i fix the problem with the PATH ?
Even if i execute the .py script directly by python (I mean :not inside 
a LateX file) pyx need to reach the TeX system ?

Is there a config file  to fix the PATH ? Where ?

Thanks a lot !! Ciao
--
Olivier


PyX requires TeX to render textual glyphs into the image. Do you have it
installed? If so, is it "reachable" by your $PATH variable?

A quick test to re-render my PyX-based images with Python 3.6 didn't reveal
any problem...

ciao, lele.



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

Re: problem with Python 3.6 + PyX

[Lele Gaifax]

stalker5  writes:

> I'm have a problem with this little program
> ...
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'tex'

PyX requires TeX to render textual glyphs into the image. Do you have it
installed? If so, is it "reachable" by your $PATH variable?

A quick test to re-render my PyX-based images with Python 3.6 didn't reveal
any problem...

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it  | -- Fortunato Depero, 1929.

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

problem with Python 3.6 + PyX

[stalker5]

Hello everybody !

I'm have a problem with this little program

#---début---
from pyx import *

g = graph.graphxy(width=8, x=graph.axis.linear(min=-15, max=15))
g.plot(graph.data.function("y(x)=sin(x)/x"))
g.writeEPSfile("function")
g.writePDFfile("function")
g.writeSVGfile("function")
#--- fin---

Python protest :

--begin error message

Running script: "/Users/draper/Documents/2016-2017/PYTHON/pyx test.py"
Traceback (most recent call last):
  File "/Users/draper/Documents/2016-2017/PYTHON/pyx test.py", line 5, 
in 

g.writeEPSfile("function")
  File "/usr/local/lib/python3.6/site-packages/pyx/canvas.py", line 50, 
in wrappedindocument

return method(d, file, **write_kwargs)
  File "/usr/local/lib/python3.6/site-packages/pyx/document.py", line 
185, in writeEPSfile

pswriter.EPSwriter(self, f, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/pyx/pswriter.py", line 
142, in __init__

page.processPS(pagefile, self, acontext, registry, pagebbox)
  File "/usr/local/lib/python3.6/site-packages/pyx/document.py", line 
132, in processPS

self._process("processPS", *args)
  File "/usr/local/lib/python3.6/site-packages/pyx/document.py", line 
78, in _process

bbox.set(self.canvas.bbox()) # this bbox is not accurate
  File "/usr/local/lib/python3.6/site-packages/pyx/graph/graph.py", 
line 181, in bbox

self.finish()
  File "/usr/local/lib/python3.6/site-packages/pyx/graph/graph.py", 
line 303, in finish

self.doaxes()
  File "/usr/local/lib/python3.6/site-packages/pyx/graph/graph.py", 
line 580, in doaxes

self.dolayout()
  File "/usr/local/lib/python3.6/site-packages/pyx/graph/graph.py", 
line 564, in dolayout

self.doaxiscreate(axisname)
  File "/usr/local/lib/python3.6/site-packages/pyx/graph/graph.py", 
line 240, in doaxiscreate

self.axes[axisname].create()
  File "/usr/local/lib/python3.6/site-packages/pyx/graph/axis/axis.py", 
line 591, in create
self.canvas = self.axis.create(self.data, self.positioner, 
self.graphtexrunner, self.errorname)
  File "/usr/local/lib/python3.6/site-packages/pyx/graph/axis/axis.py", 
line 250, in create
return _regularaxis._create(self, data, positioner, graphtexrunner, 
self.parter, self.rater, errorname)
  File "/usr/local/lib/python3.6/site-packages/pyx/graph/axis/axis.py", 
line 220, in _create

variants[0].storedcanvas = layout(variants[0])
  File "/usr/local/lib/python3.6/site-packages/pyx/graph/axis/axis.py", 
line 141, in layout

self.painter.paint(canvas, data, self, positioner)
  File 
"/usr/local/lib/python3.6/site-packages/pyx/graph/axis/painter.py", line 
192, in paint
t.temp_labelbox = canvas.texrunner.text_pt(t.temp_x_pt, 
t.temp_y_pt, t.label, labelattrs)
  File "/usr/local/lib/python3.6/site-packages/pyx/text.py", line 1428, 
in wrapped

return f(self, *args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/pyx/text.py", line 1459, 
in text_pt

return self.instance.text_pt(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/pyx/text.py", line 1278, 
in text_pt
left_pt, right_pt, height_pt, depth_pt = self.do_typeset(expr, 
self.texmessages_run_default + self.texmessages_run + texmessages)
  File "/usr/local/lib/python3.6/site-packages/pyx/text.py", line 1201, 
in do_typeset

self.do_start()
  File "/usr/local/lib/python3.6/site-packages/pyx/text.py", line 1344, 
in do_start

super().do_start()
  File "/usr/local/lib/python3.6/site-packages/pyx/text.py", line 1156, 
in do_start
self.popen = config.Popen(cmd, stdin=config.PIPE, 
stdout=config.PIPE, stderr=config.STDOUT, bufsize=0)
  File "/usr/local/lib/python3.6/site-packages/pyx/config.py", line 
190, in Popen

return subprocess.Popen(cmd, *args, **kwargs)
  File 
"/usr/local/Cellar/python3/3.6.0/Frameworks/Python.framework/Versions/3.6/lib/python3.6/subprocess.py", 
line 707, in __init__

restore_signals, start_new_session)
  File 
"/usr/local/Cellar/python3/3.6.0/Frameworks/Python.framework/Versions/3.6/lib/python3.6/subprocess.py", 
line 1326, in _execute_child

raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: 'tex'

-- end eroor message --

I search some solution, but without success.
Anybody have a idea ??

Thx a lot. Have a nice day.

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

Re: problem with python 3.5.0

[Mark Lawrence]

On 18/03/2016 16:56, nasrin maarefi via Python-list wrote:

HelloI installed the python 3.5.0(32bit) on 64bit win10 but I dont know how to 
install numpy pakage  for this? I did not find something good on internet. 
could you please guide me?where can I  find the suitable numpy for that? and 
where is the path and pip and?
best regards.



Download numpy-1.10.4+vanilla-cp35-none-win32.whl from 
http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy


From cmd.exe run:-

your\path\to\python3.5\scripts\pip install 
where\you\put\numpy-1.10.4+vanilla-cp35-none-win32.whl


If you like you could download numpy-1.11.0rc1+mkl-cp35-cp35m-win32.whl.
I don't know when the full release of numpy1.11 is due out.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

problem with python 3.5.0

[nasrin maarefi via Python-list]

HelloI installed the python 3.5.0(32bit) on 64bit win10 but I dont know how to 
install numpy pakage  for this? I did not find something good on internet. 
could you please guide me?where can I  find the suitable numpy for that? and 
where is the path and pip and?
best regards. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: problem with python 3.5.0

[Oscar Benjamin]

On 18 Mar 2016 17:42, "Mark Lawrence"  wrote:
>
> On 18/03/2016 16:56, nasrin maarefi via Python-list wrote:
>>
>> HelloI installed the python 3.5.0(32bit) on 64bit win10 but I dont know
how to install numpy pakage  for this? I did not find something good on
internet. could you please guide me?where can I  find the suitable numpy
for that? and where is the path and pip and?
>> best regards.
>>
>
> Download numpy-1.10.4+vanilla-cp35-none-win32.whl from
http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy
>
> From cmd.exe run:-
>
> your\path\to\python3.5\scripts\pip install
where\you\put\numpy-1.10.4+vanilla-cp35-none-win32.whl
>
> If you like you could download numpy-1.11.0rc1+mkl-cp35-cp35m-win32.whl.
> I don't know when the full release of numpy1.11 is due out.

FTR "pip install numpy" should now work on Windows and OSX.

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

Re: Hi Im having a problem with python it keeps telling me I need a python interpreter installed Im using windows 10. Can you help?

[Sibylle Koczian]

Am 13.03.2016 um 20:19 schrieb mrihustle12:


Sent from my Sprint Samsung Galaxy S® 6.



Not with this information, we'd need much more. The OS is necessary 
information, but not sufficient.


Have you got Python installed? If yes, which version? Where did you get 
it and how did you install it?


I rather suspect you try to run some application that would need Python, 
but Python itself is not installed. Right or wrong?


HTH
Sibylle


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

Hi Im having a problem with python it keeps telling me I need a python interpreter installed Im using windows 10. Can you help?

[mrihustle12]

Sent from my Sprint Samsung Galaxy S® 6.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem with Python 3.5.0

[Matt Wheeler]

On 11 October 2015 at 18:12, eetix letix  wrote:
> Hi,
>
> I'm sorry but the last version of Python (3.5.0) had a problem. I start and
> I meet this problem :
>
a=5
if a>0:
> . . . print("a is a positive.")
> . . . if a<0:
>  ^
> SyntaxError: invalid syntax

>
> Normally this should work but problem comes to the fact that Python
> considers "a" is a positive number and refuses to do the command >>>if a<0:

You're almost there, but your guess as to the reason for the error
isn't quite right.

It seems that the syntax in the Python shell is subtly different to
code in a module.
Because the second 'if' is a distinct statement from the first, the
python shell seems to require a second return.

However consider that perhaps using an 'else' or 'elif' instead of a
completely separate 'if'
And also consider that most people regard 0 to be positive, so you
probably meant (a>=0).

That means you can simplify to
if a>=0:
print("a is a positive")
else:
print("no need to evaluate a a second time")


> And the command \n is doesn't working :
>
 a="test\nto\nsee\nif\nit\nis\nworking"
 a
> 'test\nto\nsee\nif\nit\nis\nworking'

>
>
> Normally, \n should make that the text returns to the line but doesn't make
> it. And if y do :
>
 a="""test
> . . .  to
> . . .  see
> . . .  if
> . . .  it
> . . .  is
> . . .  working"""
a
> 'test\nto\nsee\nif\nit\nis\nworking'


\n is an escape sequence rather than a command
Have a look at what happens if you try print(a)


> Thanks to fix this problems and good luck ;)
>
>
> PS : I'm sorry for this really bad english but I'm french and I'm 14

Don't worry, it's certainly better than my French!



-- 
Matt Wheeler
http://funkyh.at
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem with Python 3.5.0

[Vincent Vande Vyvre]

Le 11/10/2015 19:12, eetix letix a écrit :

Hi,

I'm sorry but the last version of Python (3.5.0) had a problem. I 
start and I meet this problem :


>>>a=5
>>>if a>0:
. . . print("a is a positive.")
. . . if a<0:
 ^
SyntaxError: invalid syntax
>>>

Normally this should work but problem comes to the fact that Python 
considers "a" is a positive number and refuses to do the command >>>if 
a<0:


And the command |\n is doesn't working :

|
|>>> a="test||\nto||\nsee||\nif||\nit||\nis||\nworking"
|
|>>> a
|
|'||test||\nto||\nsee||\nif||\nit||\nis||\nworking'
>>>


|
Normally, \n should make that the text returns to the line but doesn't 
make it. And if y do :


>>> a="""test
. . .  to
. . .  see
. . .  if
. . .  it
. . .  is
. . .  working"""
>>>a
|'||test||\nto||\nsee||\nif||\nit||\nis||\nworking'
>>>


|
|Thanks to fix this problems and good luck ;)


|
|PS : I'm sorry for this really bad english but I'm french and I'm 14
|



Hi,

see:

>>> a = 5
>>> if a > 0:
... print('a is a positive')
...  # here, type a Enter
a is a positive
>>> elif a 

>>> a = "test\nto\nsee\nif\nit\nis\nworking"
>>> a
'test\nto\nsee\nif\nit\nis\nworking'
>>> print(a)
test
to
see
if
it
is
working
>>>

Clear ?

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

Re: Problem with Python 3.5.0

[Joel Goldstick]

On Sun, Oct 11, 2015 at 1:12 PM, eetix letix  wrote:

> Hi,
>
> I'm sorry but the last version of Python (3.5.0) had a problem. I start
> and I meet this problem :
>
> >>>a=5
> >>>if a>0:
> . . . print("a is a positive.")
> . . . if a<0:
>  ^
> SyntaxError: invalid syntax
> >>>
> Not sure what is going on above
>


> Normally this should work but problem
>  comes to the
> fact that Python considers "a" is a positive number and refuses to do the
> command >>>if a<0:
>
> And the command \n is doesn't working :
>
> >>> a="test\nto\nsee\nif\nit\nis\nworking"
> >>> a
> 'test\nto\nsee\nif\nit\nis\nworking'
> >>>
>
> In the interactive python shell, typing a name will give the
> representation of the variable.  So you will see the \n.  If you type
> print(a), you will get what you expected
>


> Normally, \n should make
>  that the text
> returns to the line but doesn't make it. And if y do :
>
> >>> a="""test
> . . .  to
> . . .  see
> . . .  if
> . . .  it
> . . .  is
> . . .  working"""
> >>>a
> 'test\nto\nsee\nif\nit\nis\nworking'
> >>>
>
>
> Thanks to fix this problems and good luck ;)
>
>
> PS : I'm sorry for this really bad english but I'm french and I'm 14
> 
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>


-- 
Joel Goldstick
http://joelgoldstick.com/stats/birthdays
-- 
https://mail.python.org/mailman/listinfo/python-list

Problem with Python 3.5.0

[eetix letix]

Hi,

I'm sorry but the last version of Python (3.5.0) had a problem. I start and
I meet this problem :

>>>a=5
>>>if a>0:
. . . print("a is a positive.")
. . . if a<0:
 ^
SyntaxError: invalid syntax
>>>

Normally this should work but problem
 comes to the
fact that Python considers "a" is a positive number and refuses to do the
command >>>if a<0:

And the command \n is doesn't working :

>>> a="test\nto\nsee\nif\nit\nis\nworking"
>>> a
'test\nto\nsee\nif\nit\nis\nworking'
>>>


Normally, \n should make
 that the text
returns to the line but doesn't make it. And if y do :

>>> a="""test
. . .  to
. . .  see
. . .  if
. . .  it
. . .  is
. . .  working"""
>>>a
'test\nto\nsee\nif\nit\nis\nworking'
>>>


Thanks to fix this problems and good luck ;)


PS : I'm sorry for this really bad english but I'm french and I'm 14

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

Re: stressing problem with Python < 3.3.3 / 2.7.6 and Mac OS 10.9 Mavericks

[Wolfgang Maier]

On 14.10.2014 22:30, Ned Deily wrote:

In article ,
  Wolfgang Maier  wrote:

I'm not a regular MacPython user, but today I had to build Mac wheels
for different versions of Python. To test the wheel files I set up a
fresh Mac OS 10.9 Mavericks and and installed Python 3.2, 3.3, 3.4 from
the python.org download page on it. Then I struggled for the rest of the
afternoon to try to figure out why Python 3.2 crashed when I used my
package in interactive mode until I finally realized that it's not the
package but Python that's responsible.

Turns out that I had run into http://bugs.python.org/issue18458 which
probably every MacPython user here is so familiar with that the download
page doesn't even mention it ? ;)

Seriously, I think the official download page for a OS shouldn't offer
me a version that will not work well with the latest version of that OS
without a warning. Why not add such a warning (like: versions below will
crash in interactive mode on Mac OS 10.9) in the list of downloads at
https://www.python.org/downloads/mac-osx/ between Python 2.7.6 (the
first version with the issue fixed) and Python 3.2.5 (the last affected
version).


Sorry you ran into that problem.  Unfortunately, that's a general
problem when using older versions of Python that are in
security-fix-only mode, e.g. those no longer in active maintenance mode.
Currently only 3.2.x and 3.3.x are in that category.

"The only changes made to a security branch are those fixing issues
exploitable by attackers such as crashes, privilege escalation and,
optionally, other issues such as denial of service attacks. Any other
changes are not considered a security risk and thus not backported to a
security branch."

https://docs.python.org/devguide/devcycle.html#security-branches

Fixes for new operating system releases do not fall in this category.
There are certainly other problems that one will run into on platform
releases newer than those supported and tested at the time of the final
maintenance release.  However, we did add a warning about this
particular issue to the release page of the final security release of
2.6.x.  That warning is now copied into the 3.2.6 release page.



Thanks for the fast response, Ned.

I fully understand how the issue arose and why it hasn't been fixed. No 
complaints about that.
I just thought that, if you cannot use the interactive interpreter on a 
standard version of the OS you're downloading for, that deserves a 
prominent mention.


The added warning in the 3.2.6 release page may have saved me a bit of 
searching *after* I figured out what's going on, but I wouldn't have 
discovered it *before* downloading.



In the future, if you encounter problems with the python.org website,
follow the Help link at the bottom of each page to the website issue
tracker.



Thanks for pointing that out. I thought such a link must exist, but 
posting to this list seemed simpler than looking for it. I'll remember 
it for next time.


Best,
Wolfgang
--
https://mail.python.org/mailman/listinfo/python-list

Re: stressing problem with Python < 3.3.3 / 2.7.6 and Mac OS 10.9 Mavericks

[Ned Deily]

In article ,
 Wolfgang Maier  wrote:
> I'm not a regular MacPython user, but today I had to build Mac wheels 
> for different versions of Python. To test the wheel files I set up a 
> fresh Mac OS 10.9 Mavericks and and installed Python 3.2, 3.3, 3.4 from 
> the python.org download page on it. Then I struggled for the rest of the 
> afternoon to try to figure out why Python 3.2 crashed when I used my 
> package in interactive mode until I finally realized that it's not the 
> package but Python that's responsible.
> 
> Turns out that I had run into http://bugs.python.org/issue18458 which 
> probably every MacPython user here is so familiar with that the download 
> page doesn't even mention it ? ;)
> 
> Seriously, I think the official download page for a OS shouldn't offer 
> me a version that will not work well with the latest version of that OS 
> without a warning. Why not add such a warning (like: versions below will 
> crash in interactive mode on Mac OS 10.9) in the list of downloads at 
> https://www.python.org/downloads/mac-osx/ between Python 2.7.6 (the 
> first version with the issue fixed) and Python 3.2.5 (the last affected 
> version).

Sorry you ran into that problem.  Unfortunately, that's a general 
problem when using older versions of Python that are in 
security-fix-only mode, e.g. those no longer in active maintenance mode. 
Currently only 3.2.x and 3.3.x are in that category.

"The only changes made to a security branch are those fixing issues 
exploitable by attackers such as crashes, privilege escalation and, 
optionally, other issues such as denial of service attacks. Any other 
changes are not considered a security risk and thus not backported to a 
security branch."

https://docs.python.org/devguide/devcycle.html#security-branches

Fixes for new operating system releases do not fall in this category.  
There are certainly other problems that one will run into on platform 
releases newer than those supported and tested at the time of the final 
maintenance release.  However, we did add a warning about this 
particular issue to the release page of the final security release of 
2.6.x.  That warning is now copied into the 3.2.6 release page.

In the future, if you encounter problems with the python.org website, 
follow the Help link at the bottom of each page to the website issue 
tracker.

-- 
 Ned Deily,
 n...@acm.org

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

stressing problem with Python < 3.3.3 / 2.7.6 and Mac OS 10.9 Mavericks

[Wolfgang Maier]

Hi,

I'm not a regular MacPython user, but today I had to build Mac wheels 
for different versions of Python. To test the wheel files I set up a 
fresh Mac OS 10.9 Mavericks and and installed Python 3.2, 3.3, 3.4 from 
the python.org download page on it. Then I struggled for the rest of the 
afternoon to try to figure out why Python 3.2 crashed when I used my 
package in interactive mode until I finally realized that it's not the 
package but Python that's responsible.


Turns out that I had run into http://bugs.python.org/issue18458 which 
probably every MacPython user here is so familiar with that the download 
page doesn't even mention it ? ;)


Seriously, I think the official download page for a OS shouldn't offer 
me a version that will not work well with the latest version of that OS 
without a warning. Why not add such a warning (like: versions below will 
crash in interactive mode on Mac OS 10.9) in the list of downloads at 
https://www.python.org/downloads/mac-osx/ between Python 2.7.6 (the 
first version with the issue fixed) and Python 3.2.5 (the last affected 
version).


Wolfgang

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

Re: Flask import problem with Python 3 and __main__.py

[Jon Ribbens]

On 2014-08-26, Terry Reedy  wrote:
> On 8/26/2014 12:03 PM, Jon Ribbens wrote:
>> Flask suggests the following file layout:
>>
>>  runflaskapp.py
>>  flaskapp/
>>  __init__.py
>>
>> runflaskapp.py contains:
>>
>>  from flaskapp import app
>>  app.run(debug=True)
>>
>> flaskapp/__init__.py contains:
>>
>>  from flask import Flask
>>  app = Flask(__name__)
>
> Unless there is something else in flaskapp, this seems senseless.  Why 
> not runflaskapp.py:
>
> from flask import Flask
> app = Flask(__name__)
> app.run(debug=True)

Because that's not how Flask apps work. I am showing a minimal test
case, obviously for any real app not only would __init__.py contain
more code, but there would be other files inside flaskapp/ too.
Then when deployed, 'runflaskapp.py' would either be changed or go
away entirely and the web server would just be pointed at 'flaskapp'.

>> Running this with 'python3 runflaskapp.py' works fine.
>
> You are either giving this in directory 'x' containing runflaskapp.py or 
> given a longer pathname. In either case, directory 'x' get prepended to 
> sys.path, so that 'import flaskapp' finds flaskapp in x.

Well, as I understand it actually the empty string is in sys.path,
which is taken by Python to mean 'the current directory'.

>> However it seems to me that a more Python3onic way of doing this
>> would be to rename 'runflaskapp.py' as 'flaskapp/__main__.py'
>> and then run the whole thing as 'python3 -m flaskapp'.
>
> In what directory?

In the same directory as above, i.e. the one containing 'flaskapp'.
It clearly does find 'flaskapp' initially, otherwise I would get
a different error message "/usr/bin/python3: No module named flaskapp".

> > Unfortunately this doesn't work:
>
> Because x does not get added to sys.path.

No, but the current directory does (effectively).

> Or put flaskapp in site_packages, which is on the import search path .

That's no use for development though.

The important part of my question is "why is running __main__.py
from inside flaskapp/ somehow different to running runflaskapp.py
from the parent directory?" It's probably a fairly Flask-specific
question.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Flask import problem with Python 3 and __main__.py

[Terry Reedy]

On 8/26/2014 12:03 PM, Jon Ribbens wrote:

Flask suggests the following file layout:

 runflaskapp.py
 flaskapp/
 __init__.py

runflaskapp.py contains:

 from flaskapp import app
 app.run(debug=True)

flaskapp/__init__.py contains:

 from flask import Flask
 app = Flask(__name__)


Unless there is something else in flaskapp, this seems senseless.  Why 
not runflaskapp.py:


from flask import Flask
app = Flask(__name__)
app.run(debug=True)


Running this with 'python3 runflaskapp.py' works fine.


You are either giving this in directory 'x' containing runflaskapp.py or 
given a longer pathname. In either case, directory 'x' get prepended to 
sys.path, so that 'import flaskapp' finds flaskapp in x.



However it
seems to me that a more Python3onic way of doing this would be to
rename 'runflaskapp.py' as 'flaskapp/__main__.py'

> and then run the whole thing as 'python3 -m flaskapp'.

In what directory?

> Unfortunately this doesn't work:

Because x does not get added to sys.path.


 $ python3 -m flaskapp
  * Running on http://127.0.0.1:5000/
  * Restarting with reloader
 Traceback (most recent call last):
   File "/home/username/src/flaskapp/__main__.py", line 1, in 
from flaskapp import app
 ImportError: No module named 'flaskapp'

Does anyone know why and how to fix it?


Since flaskapp/__main__.py is found and run, make the change suggested 
above that eliminates the flaskapp import.


Or put flaskapp in site_packages, which is on the import search path .

Pip, and I presume other installers, typically puts startup scripts in a 
directory that is on the system path. For Windows, this is 
pythonxy/Scripts.  But this is more than I would do for most local apps.


--
Terry Jan Reedy

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

Flask import problem with Python 3 and __main__.py

[Jon Ribbens]

Flask suggests the following file layout:

runflaskapp.py
flaskapp/
__init__.py

runflaskapp.py contains:

from flaskapp import app
app.run(debug=True)

flaskapp/__init__.py contains:

from flask import Flask
app = Flask(__name__)

Running this with 'python3 runflaskapp.py' works fine. However it
seems to me that a more Python3onic way of doing this would be to
rename 'runflaskapp.py' as 'flaskapp/__main__.py' and then run
the whole thing as 'python3 -m flaskapp'. Unfortunately this doesn't
work:

$ python3 -m flaskapp
 * Running on http://127.0.0.1:5000/
 * Restarting with reloader
Traceback (most recent call last):
  File "/home/username/src/flaskapp/__main__.py", line 1, in 
from flaskapp import app
ImportError: No module named 'flaskapp'

Does anyone know why and how to fix it?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie problem with Python pandas

[Roy Smith]

In article <_dudntfyxdvclhtnnz2dnuvz_ocdn...@giganews.com>,
 RueTheDay  wrote:

> On Sun, 06 Jan 2013 11:45:34 -0500, Roy Smith wrote:
> 
> > In article <_dudnttyxduonxtnnz2dnuvz_ocdn...@giganews.com>,
> >  RueTheDay  wrote:
> > 
> >> On Sun, 06 Jan 2013 08:05:59 -0800, Miki Tebeka wrote:
> >> 
> >> > On Sunday, January 6, 2013 5:57:17 AM UTC-8, RueTheDay wrote:
> >> >> I am getting the following error when running on Python 2.7 on
> >> >> Ubuntu 12.04:
> >> >> >>
> >> >> >>
> >> >> AttributeError: 'Series' object has no attribute 'str'
> >> > I would *guess* that  you have an older version of pandas on your
> >> > Linux machine.
> >> > Try "print(pd.__version__)" to see which version you have.
> >> > 
> >> > Also, trying asking over at
> >> > https://groups.google.com/forum/?fromgroups=#!forum/pydata which is
> >> > more dedicated to pandas.
> >> 
> >> Thank you!  That was it.  I had 0.7 installed (the latest in the Ubuntu
> >> repository).  I downloaded and manually installed 0.10 and now it's
> >> working.  Coincidentally, this also fixed a problem I was having with
> >> running a matplotlib plot function against a pandas Data Frame (worked
> >> with some chart types but not others).
> >> 
> >> I'm starting to understand why people rely on easy_install and pip.
> >> Thanks again.
> > 
> > Yeah, Ubuntu is a bit of a mess when it comes to pandas and the things
> > it depends on.  Apt gets you numpy 1.4.1, which is really old.  Pandas
> > won't even install on top of it.
> > 
> > I've got pandas (and numpy, and scipy, and matplotlib) running on a
> > Ubuntu 12.04 box.  I installed everything with pip.  My problem at this
> > point, however, is I want to replicate that setup in EMR (Amazon's
> > Elastic Map-Reduce).  In theory, I could just run "pip install numpy" in
> > my mrjob.conf bootstrap, but it's a really long install process,
> > building a lot of stuff from source.  Not the kind of thing you want to
> > put in a bootstrap for an ephemeral instance.
> > 
> > Does anybody know where I can find a debian package for numpy 1.6?
> 
> Go here:
> 
> http://neuro.debian.net/index.html#how-to-use-this-repository
> 
> and add one their repositories to your sources.
> 
> Then you can do use apt-get to install ALL the latest packages on your 
> Ubuntu box - numpy, scipy, pandas, matplotlib, statsmodels, etc.
> 
> I wish I found this a few days ago.

Cool, thanks!  Really glad you're a few days ahead of me :-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Newbie problem with Python pandas

[RueTheDay]

On Sun, 06 Jan 2013 11:45:34 -0500, Roy Smith wrote:

> In article <_dudnttyxduonxtnnz2dnuvz_ocdn...@giganews.com>,
>  RueTheDay  wrote:
> 
>> On Sun, 06 Jan 2013 08:05:59 -0800, Miki Tebeka wrote:
>> 
>> > On Sunday, January 6, 2013 5:57:17 AM UTC-8, RueTheDay wrote:
>> >> I am getting the following error when running on Python 2.7 on
>> >> Ubuntu 12.04:
>> >> >>
>> >> >>
>> >> AttributeError: 'Series' object has no attribute 'str'
>> > I would *guess* that  you have an older version of pandas on your
>> > Linux machine.
>> > Try "print(pd.__version__)" to see which version you have.
>> > 
>> > Also, trying asking over at
>> > https://groups.google.com/forum/?fromgroups=#!forum/pydata which is
>> > more dedicated to pandas.
>> 
>> Thank you!  That was it.  I had 0.7 installed (the latest in the Ubuntu
>> repository).  I downloaded and manually installed 0.10 and now it's
>> working.  Coincidentally, this also fixed a problem I was having with
>> running a matplotlib plot function against a pandas Data Frame (worked
>> with some chart types but not others).
>> 
>> I'm starting to understand why people rely on easy_install and pip.
>> Thanks again.
> 
> Yeah, Ubuntu is a bit of a mess when it comes to pandas and the things
> it depends on.  Apt gets you numpy 1.4.1, which is really old.  Pandas
> won't even install on top of it.
> 
> I've got pandas (and numpy, and scipy, and matplotlib) running on a
> Ubuntu 12.04 box.  I installed everything with pip.  My problem at this
> point, however, is I want to replicate that setup in EMR (Amazon's
> Elastic Map-Reduce).  In theory, I could just run "pip install numpy" in
> my mrjob.conf bootstrap, but it's a really long install process,
> building a lot of stuff from source.  Not the kind of thing you want to
> put in a bootstrap for an ephemeral instance.
> 
> Does anybody know where I can find a debian package for numpy 1.6?

Go here:

http://neuro.debian.net/index.html#how-to-use-this-repository

and add one their repositories to your sources.

Then you can do use apt-get to install ALL the latest packages on your 
Ubuntu box - numpy, scipy, pandas, matplotlib, statsmodels, etc.

I wish I found this a few days ago.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Newbie problem with Python pandas

[Roy Smith]

In article <_dudnttyxduonxtnnz2dnuvz_ocdn...@giganews.com>,
 RueTheDay  wrote:

> On Sun, 06 Jan 2013 08:05:59 -0800, Miki Tebeka wrote:
> 
> > On Sunday, January 6, 2013 5:57:17 AM UTC-8, RueTheDay wrote:
> >> I am getting the following error when running on Python 2.7 on Ubuntu
> >> 12.04:
> >> >>
> >> >>
> >> AttributeError: 'Series' object has no attribute 'str'
> > I would *guess* that  you have an older version of pandas on your Linux
> > machine.
> > Try "print(pd.__version__)" to see which version you have.
> > 
> > Also, trying asking over at
> > https://groups.google.com/forum/?fromgroups=#!forum/pydata which is more
> > dedicated to pandas.
> 
> Thank you!  That was it.  I had 0.7 installed (the latest in the Ubuntu 
> repository).  I downloaded and manually installed 0.10 and now it's 
> working.  Coincidentally, this also fixed a problem I was having with 
> running a matplotlib plot function against a pandas Data Frame (worked 
> with some chart types but not others).
> 
> I'm starting to understand why people rely on easy_install and pip.  
> Thanks again.

Yeah, Ubuntu is a bit of a mess when it comes to pandas and the things 
it depends on.  Apt gets you numpy 1.4.1, which is really old.  Pandas 
won't even install on top of it.

I've got pandas (and numpy, and scipy, and matplotlib) running on a 
Ubuntu 12.04 box.  I installed everything with pip.  My problem at this 
point, however, is I want to replicate that setup in EMR (Amazon's 
Elastic Map-Reduce).  In theory, I could just run "pip install numpy" in 
my mrjob.conf bootstrap, but it's a really long install process, 
building a lot of stuff from source.  Not the kind of thing you want to 
put in a bootstrap for an ephemeral instance.

Does anybody know where I can find a debian package for numpy 1.6?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Newbie problem with Python pandas

[RueTheDay]

On Sun, 06 Jan 2013 08:05:59 -0800, Miki Tebeka wrote:

> On Sunday, January 6, 2013 5:57:17 AM UTC-8, RueTheDay wrote:
>> I am getting the following error when running on Python 2.7 on Ubuntu
>> 12.04:
>> >>
>> >>
>> AttributeError: 'Series' object has no attribute 'str'
> I would *guess* that  you have an older version of pandas on your Linux
> machine.
> Try "print(pd.__version__)" to see which version you have.
> 
> Also, trying asking over at
> https://groups.google.com/forum/?fromgroups=#!forum/pydata which is more
> dedicated to pandas.

Thank you!  That was it.  I had 0.7 installed (the latest in the Ubuntu 
repository).  I downloaded and manually installed 0.10 and now it's 
working.  Coincidentally, this also fixed a problem I was having with 
running a matplotlib plot function against a pandas Data Frame (worked 
with some chart types but not others).

I'm starting to understand why people rely on easy_install and pip.  
Thanks again.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Newbie problem with Python pandas

[Miki Tebeka]

On Sunday, January 6, 2013 5:57:17 AM UTC-8, RueTheDay wrote:
> I am getting the following error when running on Python 2.7 on Ubuntu 
> 12.04:
> >>
>
> AttributeError: 'Series' object has no attribute 'str'
I would *guess* that  you have an older version of pandas on your Linux machine.
Try "print(pd.__version__)" to see which version you have.

Also, trying asking over at 
https://groups.google.com/forum/?fromgroups=#!forum/pydata which is more 
dedicated to pandas.
-- 
http://mail.python.org/mailman/listinfo/python-list

Newbie problem with Python pandas

[RueTheDay]

I'm working my way through the examples in the O'Reilly book Python For 
Data Analysis and have encountered a snag.

The following code is supposed to analyze some web server log data and 
produces aggregate counts by client operating system.

###
import json # used to process json records
from pandas import DataFrame, Series
import pandas as pd
import matplotlib.pyplot as plt
import numpy as np

path = '/home/rich/code/sample.txt'
records = [json.loads(line) for line in open(path)] #read in records one 
line at a time
frame = DataFrame(records)

cframe = frame[frame.a.notnull()]
operating_system = np.where(cframe['a'].str.contains
('Windows'),'Windows', 'Not Windows')
by_tz_os = cframe.groupby(['tz', operating_system])
agg_counts = by_tz_os.size().unstack().fillna(0)
indexer = agg_counts.sum(1).argsort()
count_subset = agg_counts.take(indexer)[-10:]
print count_subset


I am getting the following error when running on Python 2.7 on Ubuntu 
12.04:

>>
Traceback (most recent call last):
  File "./lp1.py", line 12, in 
operating_system = np.where(cframe['a'].str.contains
('Windows'),'Windows', 'Not Windows')
AttributeError: 'Series' object has no attribute 'str'
>>>

Note that I was able to get the code to work fine on Windows 7, so this 
appears to be specific to Linux.

A little Googling showed others have encountered this problem and 
suggested replacing the np.where with a find, as so:


operating_system = ['Windows' if a.find('Windows') > 0 else 'Not Windows' 
for a in cframe['a']]


This appears to solve the first problem, but then it fails on the next 
line with:


Traceback (most recent call last):
  File "./lp1.py", line 14, in 
by_tz_os = cframe.groupby(['tz', operating_system])
  File "/usr/lib/pymodules/python2.7/pandas/core/generic.py", line 133, 
in groupby
sort=sort)
  File "/usr/lib/pymodules/python2.7/pandas/core/groupby.py", line 522, 
in groupby
return klass(obj, by, **kwds)
  File "/usr/lib/pymodules/python2.7/pandas/core/groupby.py", line 115, 
in __init__
level=level, sort=sort)
  File "/usr/lib/pymodules/python2.7/pandas/core/groupby.py", line 705, 
in _get_groupings
ping = Grouping(group_axis, gpr, name=name, level=level, sort=sort)
  File "/usr/lib/pymodules/python2.7/pandas/core/groupby.py", line 600, 
in __init__
self.grouper = self.index.map(self.grouper)
  File "/usr/lib/pymodules/python2.7/pandas/core/index.py", line 591, in 
map
return self._arrmap(self.values, mapper)
  File "generated.pyx", line 1141, in pandas._tseries.arrmap_int64 
(pandas/src/tseries.c:40593)
TypeError: 'list' object is not callable
>

The problem looks to be with the pandas module and appears to be Linux-
specific.

Any ideas?  I'm pulling my hair out over this.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problem with Python GUI checklist, Tkinter

[Terry Reedy]

On 3/7/2011 12:49 PM, Mathew Coyle wrote:


Everything seems to roll along fine, a few tweaks are still needed, but
an issue I cannot resolve has come up. It seems that the checklist items
are being selected and added twice to the list, once for a mouse button
click, and again for a mouse button release. I thought it would be a
simple tag or bind somewhere, like the Python Tk buttons, to limit the
selection to the mouse button click only, but I cannot find it anywhere
in the documentation.


I am just learning also. Many (most) widgets have a 'command' option for 
responses to (left) mouse clicks. When available, I suggest using that 
instead of explicit binding. Let tk get the bind right ;-).


There is a tracker issue posted by someone else who had problem with 
explicit click binding. He succeeded with 'command = xxx' but failed 
with supposedly equivalent explicit binding of 'xxx'. I do not know if 
really equivalent or if tk or tkinter have bug.


--
Terry Jan Reedy

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

Problem with Python GUI checklist, Tkinter

[Mathew Coyle]

Hi all,

I am trying to create a checklist which allows users to select a specific 
feature of a dataset in a database, and export that feature out of the database 
to their PC. This is my first GUI attempt, and I don't imagine my issue is too 
complicated, mostly just my inexperience.

Everything seems to roll along fine, a few tweaks are still needed, but an 
issue I cannot resolve has come up. It seems that the checklist items are being 
selected and added twice to the list, once for a mouse button click, and again 
for a mouse button release. I thought it would be a simple tag or bind 
somewhere, like the Python Tk buttons, to limit the selection to the mouse 
button click only, but I cannot find it anywhere in the documentation.

I am using Python 2.6.5, Tk 8.5 and I've attached the code as it stands now.

Any assistance would be appreciated, thanks.

Mathew Coyle
GIS Analyst
Information Technology
Alberta-Pacific Forest Industries Inc.
Phone: 780.525.8556
Fax: 780.525.8388
E-mail: mathew.co...@alpac.ca

[cid:image001.png@01CBDCB3.8837DC10]

<>

PUexport_tool.py
Description: PUexport_tool.py
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problem with python 3.2 and circular imports

[Frank Millman]

"Rafael Durán Castañeda"  wrote...


Thank you for your answer Frank, I think I've found the problem. I was
calling modules from inside subpackages, and I need to use them from
outside, so I have package in PYTHONPATH. is that correct? But now I have
another question: Can I execute an script inside subpackage1 importig
modules from subpackage2?


Hi Rafael

I am no expert, so I cannot answer you directly.

In my case, my program started as a single module.

As it grew, I started to split some parts off and store them in separate 
modules in the same directory. I placed 'import' statements in the main 
module, and it worked.


Then I found the need for some modules to refer to objects in other modules, 
so I needed 'import' statements within the modules. I found myself hitting 
problems with circular imports from time to time, but with some help from 
this group and re-reading the docs I got over this hurdle.


Only recently has my project got big enough to start thinking about 
packages. It adds complexity, but by reading the docs again, and thinking 
carefully about the structure, I have so far managed to handle the problems 
that occur.


I found the 'modules' chapter in the tutorial a good place to start. Once 
you have fully grasped the contents, PEP 328 is a good resource for 
understanding what has changed in python 3.x.


BTW, this group prefers 'bottom posting'. You will see that I have placed my 
response below yours. If you want to reply to this, please follow the same 
practice.


Hope this helps to get you started.

Frank


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

Re: Problem with python 3.2 and circular imports

[Rafael Durán Castañeda]

Thank you for your answer Frank, I think I've found the problem. I was
calling modules from inside subpackages, and I need to use them from
outside, so I have package in PYTHONPATH. is that correct? But now I have
another question: Can I execute an script inside subpackage1 importig
modules from subpackage2?

2011/3/4 Frank Millman 

>
> On February 28 2011 Rafael Durán Castañeda wrote
>
>  I'm stil totally stuck with relative imports, i' ve tried the example tree
>> from PEP 328 without any result:
>>
>> package/
>>   __init__.py
>>   subpackage1/
>>   __init__.py
>>   moduleX.py
>>   moduleY.py
>>   subpackage2/
>>   __init__.py
>>   moduleZ.py
>>   moduleA.py
>>
>> Assuming that the current file is either moduleX.py or
>> subpackage1/__init__.py, following are correct usages of the new
>> syntax:
>>
>> from .moduleY import spam
>> from .moduleY import spam as ham
>> from . import moduleY
>> from ..subpackage1 import moduleY
>> from ..subpackage2.moduleZ import eggs
>> from ..moduleA import foo
>> from ...package import bar
>> from ...sys import path
>>
>> I always get:
>>
>> Traceback (most recent call last):
>>  File "moduleY.py", line 1, in 
>>   from ..moduleA import a
>> ValueError: Attempted relative import in non-package
>>
>>
>>
> Hi Rafael
>
> I only just noticed your message now. For some reason it did not appear on
> google.groups.
>
> I just tried it and it worked for me. This is what I did.
>
> I set up the above structure. I added a 'def spam()' to moduleY, 'def
> eggs()' to moduleZ, and 'def foo()' to moduleA.
>
> I pasted all of the 'from ... import ...' lines above into moduleX.
>
> In the same directory that contains the subdirectory 'package' I create a
> test script containing the following line -
>   import package.subpackage1.moduleX
>
> To begin with it failed on the last two lines starting with 'from ...' [how
> do you indicate three dots followed by etc etc, which would normally be
> indicated by three dots!]. The traceback said 'Attempted relative import
> beyond toplevel package'.
>
> I did not want to investigate too deeply so I just commented those lines
> out, and now it runs with no errors. I even put a couple of print statements
> (or must I call them print functions now) into the modules being imported,
> and the messages do appear, so the modules are being imported.
>
> HTH
>
> Frank Millman
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problem with python 3.2 and circular imports

[Frank Millman]

On February 28 2011 Rafael Durán Castañeda wrote


I'm stil totally stuck with relative imports, i' ve tried the example tree
from PEP 328 without any result:

package/
   __init__.py
   subpackage1/
   __init__.py
   moduleX.py
   moduleY.py
   subpackage2/
   __init__.py
   moduleZ.py
   moduleA.py

Assuming that the current file is either moduleX.py or
subpackage1/__init__.py, following are correct usages of the new
syntax:

from .moduleY import spam
from .moduleY import spam as ham
from . import moduleY
from ..subpackage1 import moduleY
from ..subpackage2.moduleZ import eggs
from ..moduleA import foo
from ...package import bar
from ...sys import path

I always get:

Traceback (most recent call last):
 File "moduleY.py", line 1, in 
   from ..moduleA import a
ValueError: Attempted relative import in non-package




Hi Rafael

I only just noticed your message now. For some reason it did not appear on 
google.groups.


I just tried it and it worked for me. This is what I did.

I set up the above structure. I added a 'def spam()' to moduleY, 'def 
eggs()' to moduleZ, and 'def foo()' to moduleA.


I pasted all of the 'from ... import ...' lines above into moduleX.

In the same directory that contains the subdirectory 'package' I create a 
test script containing the following line -

   import package.subpackage1.moduleX

To begin with it failed on the last two lines starting with 'from ...' [how 
do you indicate three dots followed by etc etc, which would normally be 
indicated by three dots!]. The traceback said 'Attempted relative import 
beyond toplevel package'.


I did not want to investigate too deeply so I just commented those lines 
out, and now it runs with no errors. I even put a couple of print statements 
(or must I call them print functions now) into the modules being imported, 
and the messages do appear, so the modules are being imported.


HTH

Frank Millman


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

Re: Problem with python 3.2 and circular imports

[Rafael Durán Castañeda]

I'm stil totally stuck with relative imports, i' ve tried the example tree
from PEP 328 without any result:

package/
__init__.py
subpackage1/
__init__.py
moduleX.py
moduleY.py
subpackage2/
__init__.py
moduleZ.py
moduleA.py

Assuming that the current file is either moduleX.py or
subpackage1/__init__.py, following are correct usages of the new
syntax:

from .moduleY import spam
from .moduleY import spam as ham
from . import moduleY
from ..subpackage1 import moduleY
from ..subpackage2.moduleZ import eggs
from ..moduleA import foo
from ...package import bar
from ...sys import path

I always get:

Traceback (most recent call last):
  File "moduleY.py", line 1, in 
from ..moduleA import a
ValueError: Attempted relative import in non-package


2011/2/27 Frank Millman 

>
> "Steven D'Aprano"  wrote in message
> news:4d6a56aa$0$29972$c3e8da3$54964...@news.astraweb.com...
>
>  On Sun, 27 Feb 2011 12:08:12 +0200, Frank Millman wrote:
>>
>>  Assume the following structure -
>>>
>>> main.py
>>> /pkg
>>>__init__.py
>>>mod1.py
>>>mod2.py
>>>
>>> main.py
>>>from pkg import mod1
>>>
>>> mod1.py
>>>import mod2
>>>
>>> mod2.py
>>>  import mod1
>>>
>>
>>
>> If you change the "import mod*" lines to "import pkg.mod*" it works for
>> me in Python 3.1 and 3.2.
>>
>> According to my understand of PEP 328, "from . import mod*" should work,
>> but I agree with you that it doesn't.
>>
>> If you get rid of the circular import, it does work. So I suspect a bug.
>>
>>
>>
> Thanks, Steven.
>
> I confirm that 'import pkg.mod* works. Unfortunately I am using
> sub-packages as well, which means that to refer to an object in the
> sub-package I need to use w.x.y.z every time, which gets to be a lot of
> typing! I will stick to my hack of putting the package name in sys.path for
> now, unless someone comes up with a better idea.
>
> Frank
>
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problem with python 3.2 and circular imports

[Frank Millman]

"Steven D'Aprano"  wrote in message 
news:4d6a56aa$0$29972$c3e8da3$54964...@news.astraweb.com...

On Sun, 27 Feb 2011 12:08:12 +0200, Frank Millman wrote:


Assume the following structure -

main.py
/pkg
__init__.py
mod1.py
mod2.py

main.py
from pkg import mod1

mod1.py
import mod2

mod2.py
  import mod1



If you change the "import mod*" lines to "import pkg.mod*" it works for
me in Python 3.1 and 3.2.

According to my understand of PEP 328, "from . import mod*" should work,
but I agree with you that it doesn't.

If you get rid of the circular import, it does work. So I suspect a bug.




Thanks, Steven.

I confirm that 'import pkg.mod* works. Unfortunately I am using sub-packages 
as well, which means that to refer to an object in the sub-package I need to 
use w.x.y.z every time, which gets to be a lot of typing! I will stick to my 
hack of putting the package name in sys.path for now, unless someone comes 
up with a better idea.


Frank


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

Re: Problem with python 3.2 and circular imports

[Steven D'Aprano]

On Sun, 27 Feb 2011 12:08:12 +0200, Frank Millman wrote:

> Assume the following structure -
> 
> main.py
> /pkg
> __init__.py
> mod1.py
> mod2.py
> 
> main.py
> from pkg import mod1
> 
> mod1.py
> import mod2
> 
> mod2.py
>   import mod1


If you change the "import mod*" lines to "import pkg.mod*" it works for 
me in Python 3.1 and 3.2.

According to my understand of PEP 328, "from . import mod*" should work, 
but I agree with you that it doesn't.

If you get rid of the circular import, it does work. So I suspect a bug.



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

Re: Problem with python 3.2 and circular imports

[Frank Millman]

"Ben Finney"  wrote in message 
news:87aahh6401@benfinney.id.au...

"Frank Millman"  writes:


Assume the following structure -

main.py
/pkg
   __init__.py
   mod1.py
   mod2.py

main.py
   from pkg import mod1

mod1.py
   import mod2

mod2.py
 import mod1


What are you expecting the result to be?



Simply that mod1 can refer to objects in mod2, and mod2 can refer to objects 
in mod1.



If it's about sharing objects between the modules, why not break the
circular dependency: factor out the common code to a module that both
the others import?


Any comments or suggestions will be appreciated.


Special cases aren't special enough to break the rules. If you think you
have a practical reason to do so, it would be best to make it explicit
when asking for help about this.



I am trying to understand what 'the rule' is. Your advice above suggests 
that you are one of those who recommend that circular imports are best 
avoided altogether. In an ideal world I would agree. However, the fact is 
that, no doubt due to a mental block I have, I do find myself in this 
situation from time to time, and I have not seen anything in the 
documentation or other literature that says it is absolutely wrong. 
Therefore, while I do try to avoid circular imports where possible, I would 
also like to know how to manage it in situations where I don't see a simple 
alternative.


From everything I have read about how the import mechanism works, I don't 
understand *why* the above construct fails. That is actually what I am 
asking for help with.


Thanks

Frank


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

Re: Problem with python 3.2 and circular imports

[Ben Finney]

"Frank Millman"  writes:

> Assume the following structure -
>
> main.py
> /pkg
>__init__.py
>mod1.py
>mod2.py
>
> main.py
>from pkg import mod1
>
> mod1.py
>import mod2
>
> mod2.py
>  import mod1

What are you expecting the result to be?

If it's about sharing objects between the modules, why not break the
circular dependency: factor out the common code to a module that both
the others import?

> Any comments or suggestions will be appreciated.

Special cases aren't special enough to break the rules. If you think you
have a practical reason to do so, it would be best to make it explicit
when asking for help about this.

-- 
 \   “The long-term solution to mountains of waste is not more |
  `\  landfill sites but fewer shopping centres.” —Clive Hamilton, |
_o__)_Affluenza_, 2005 |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Problem with python 3.2 and circular imports

[Frank Millman]

Hi all

I thought I was getting the hang of circular imports, but after upgrading to 
python 3.2 I am stumped again. I know some people think that circular 
imports are always bad, but others suggest that, provided you understand the 
potential problems, they can be acceptable.


Assume the following structure -

main.py
/pkg
   __init__.py
   mod1.py
   mod2.py

main.py
   from pkg import mod1

mod1.py
   import mod2

mod2.py
 import mod1

Using python 2.6, running main.py works.

After running 2to3.py on the above directory, mod1.py was changed to 'from . 
import mod2' and mod2.py was changed to 'from . import mod1'.


With python 3.2, it now fails with the following traceback -

Traceback (most recent call last):
 File "main.py", line 1, in 
   from pkg import mod1
 File "pkg\mod1.py", line 1, in 
   from . import mod2
 File "pkg\mod2.py", line 1, in 
   from . import mod1
ImportError: cannot import name mod1

I have read the relevant peps and various other material, understood them to 
a certain extent, tried several alternatives, but could not find a solution.


I have found a hack that works, but I don't like it very much. I added the 
following to '__init__.py' -

 import os
 import sys
 sys.path.insert(0, os.path.dirname(__file__))

This adds the package name into the search path.

Then I changed mod1.py and mod2.py back to the original 'import mod2' and 
'import mod1'.


It works, but it seems to be defeating the purpose of PEP 328, which I 
thought was an improvement.


Any comments or suggestions will be appreciated.

Frank Millman


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

Re: How to debug a problem with python crashing under windows

[Terry Reedy]

On 2/4/2011 11:41 AM, Miki Tebeka wrote:

With crashing I mean, that windows pops up a screen saying, that
python.exe failed.
I do not have any usable trace on stdout / stderr.

What are the best means to analyze such errors?

You can use sys.excepthook to catch uncaught exceptions. See 
http://pythonwise.blogspot.com/2008/12/crashlog.html for example ;)



There likely is no uncaught exception, since such should produce a 
visible stack trace, certainly if the app is run from a Command Prompt 
window.


Victor Stinner is working on a module for 3.3 that will try to catch 
crashes and produce some report before everything is gone. It may be up 
on PyPI before that.


--
Terry Jan Reedy

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

Re: How to debug a problem with python crashing under windows

[Miki Tebeka]

> With crashing I mean, that windows pops up a screen saying, that
> python.exe failed.
> I do not have any usable trace on stdout / stderr.
> 
> What are the best means to analyze such errors?
You can use sys.excepthook to catch uncaught exceptions. See 
http://pythonwise.blogspot.com/2008/12/crashlog.html for example ;)

HTH,
--
Miki
-- 
http://mail.python.org/mailman/listinfo/python-list

How to debug a problem with python crashing under windows

[gelonida]

Hi,

I have a python application, which occasionally crashes.

With crashing I mean, that windows pops up a screen saying, that
python.exe failed.
I do not have any usable trace on stdout / stderr.

What are the best means to analyze such errors?

Is there any way to get something like a core dump and to look at it
after the application died?

Thanks in advance for any idea.
-- 
http://mail.python.org/mailman/listinfo/python-list

possible circular import problem with python-3, but not python-2

[Darren Dale]

I am attempting to contribute to the h5py project by porting the code
for python-3. The code is available in a branch at github:
http://github.com/darrendale/h5py/tree/py3k . That code uses cython to
wrap the hdf5 library.

So far, only a few minor changes have been needed (relative imports,
changes concerning strings/bytes), and I have been able to generate
the c sources, build and install h5py for py3k. But I can't actually
import the library. On Snow Leopard, using the python-3 installed via
MacPorts:

>>> import h5py
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/darren/.local/lib/python3.1/site-packages/
h5py-1.3.1.dev-py3.1-macosx-10.6-x86_64.egg/h5py/__init__.py", line
34, in 
from . import h5, h5a, h5d, h5f, h5fd, h5g, h5l, h5o, h5i, h5p,
h5r, h5s, h5t, h5z
  File "h5t.pxd", line 17, in init h5py.h5a (h5py/h5a.c:5248)
  File "h5p.pxd", line 23, in init h5py.h5t (h5py/h5t.c:16481)
  File "h5t.pxd", line 17, in init h5py.h5p (h5py/h5p.c:9297)
ImportError: No module named h5t

That looks like it might be a circular import problem, but it works
fine with python-2.6. I'm at a loss on how to proceed, could anyone
please offer a suggestion?

Thanks,
Darren
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Python-Dev] problem with python 3.1

[James Mills]

(Posting to python general discussion).

On Thu, Sep 16, 2010 at 10:17 AM, João Vitor  wrote:
> I made a program that, according to my teacher, is correct but is not
> running properly.
> The program is really simple:
> import math
> x = input ("Coloque o valor do primeiro cateto:")
> y = input ("Coloque o valor do segundo cateto:")
> z = x**2
> w = y**2
> soma = z + w
> h = math.sqrt (soma)
> print = "O valor da hipotenusa é:", h
> But after I put the value of x and y this error appears:
> Traceback (most recent call last):
>   File "C:/lista03.py", line 4, in 
>     z = x**2
> TypeError: unsupported operand type(s) for ** or pow(): 'str' and 'int'
> My teacher said the program ran normally in his computer, but in my it
> doesn't!
> why?

You're teacher has clearly overlooked that you must convert the values
of x and y to
int's using either:

x = int(input(...))

or

x = int(x)

You cannot perform (most) mathematical operators where the operands
are of different types (in Python)
eg: str and int

cheers
James

PS: Please post questions like this to either the tutor or general
python mailing list(s).

-- 
-- James Mills
--
-- "Problems are solved by method"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[Philip Semanchuk]

On Jul 7, 2010, at 11:26 PM, Terry Reedy wrote:


On 7/7/2010 5:29 AM, geremy condra wrote:

On Tue, Jul 6, 2010 at 1:37 AM, Terry Reedy  wrote:

On 7/5/2010 9:00 PM, Philip Semanchuk wrote:

On Jul 5, 2010, at 6:41 PM, Chris Rebert wrote:

On Mon, Jul 5, 2010 at 3:38 PM, Philip Semanchu


I ported two pure C extensions from 2 to 3 and was even able to  
keep a
single C codebase. I'd be willing to contribute my experiences  
to a

document
somewhere. (Is there a Wiki?)



Indeed there is: http://wiki.python.org/moin/



Thanks. I don't want to appear ungrateful, but I was hoping for
something specific to the 2-to-3 conversion. I guess someone has to
start somewhere...


There is an existing 2to3 and other pages for Python code  
conversion. I do
not know of any for CAPI conversion. The need for such has been  
acknowledged
among the devs but if there is nothing yet, we need someone with  
specialized
experience and a bit of time to make a first draft. If you start  
one, give
it an easy to remember name C2to3? 2to3Capi? You choose. And link  
to it from

the 2to3 pag
In his post on this thread, Martin Loewis volunteered to list what  
he knows

from psycopg2 if someone else will edit.



I'm not sure why I don't have this post, but I'm happy to help edit
etc if Martin
wants to put together a rough draft.


Since I wrote that, someone pointed out the the Python How-to  
collection includes Porting Extension Modules to 3.0
by Benjamim Peterson. So all Pyilip or Martin need to do is read  
that and suggest additions.


That document is here:
http://wiki.python.org/moin/PortingExtensionModulesToPy3k

It took me a while to find. It's a shame it's not better known; I  
looked for such a document before I started porting sysv_ipc and  
posix_ipc and didn't find this one.


Thanks for the pointer.

Cheers
Philip


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

Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[Giampaolo Rodolà]

2010/7/8 Michele Simionato :
> On Jul 7, 10:55 pm, Carl Banks  wrote:
>> On Jul 7, 1:31 am, Paul McGuire  wrote:
>> > I just
>> > couldn't get through on the python-dev list that I couldn't just
>> > upgrade my code to 2.6 and then use 2to3 to keep in step across the
>> > 2-3 chasm, as this would leave behind my faithful pre-2.6 users.
>
> This is a point I do not understand. My recent module plac is meant to
> work from Python 2.3 to Python 3.1 and to this goal I make use of 2to3
> at the *client* side.
> Users of Python 2.X get the original code with no magic whatsoever;
> users of Python 3.X
> get the same code, but at installation time 2to3 is run by the
> setup.py script. The mechanism requires distribute to be installed,
> but I would say that having distribute is a must for Python 3.X users;
> Python 2.X users do not need anything, so the approach is backward
> compatible. I thought this was the recommended way of using 2to3 and
> so far is working for me.
>
>            M. Simionato
> --
> http://mail.python.org/mailman/listinfo/python-list
>

I used the same approach (2.x default code base which gets translated
by 2to3 at installation time) and I managed to do this with distutils
alone by doing a little hack in setup.py.
Take a look at:
http://code.google.com/p/psutil/source/browse/tags/release-0.1.3/setup.py#11

Regards,

--- Giampaolo
http://code.google.com/p/pyftpdlib
http://code.google.com/p/psutil
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[Steven D'Aprano]

On Wed, 07 Jul 2010 14:10:57 -0700, Brendan Abel wrote:

> The entire fact that 3.x was *designed* to be incompatible should tell
> you that supporting 2.x and 3.x with a single code base is a bad idea,
> except for the very smallest of projects.

I don't see that follows at all. If the incompatibilities are designed to 
be mechanically translatable (e.g. "x.keys()" -> "list(x.keys())" then 
you can start with a single code-base and run the translator.

If only there were some sort of Python program that could be used to 
translate code from 2 to 3... 

*wink*



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

Re: The real problem with Python 3 - no business case for conversion

[Ben Finney]

"Martin v. Loewis"  writes:

> > The point, one more time with feeling, is that the incompatibilities
> > between 2.x and 3.x will *increase* over time.
>
> I think this is unfounded, and actually false.

Since many other people have responded with similar sentiments, I can
only think I must have been expressing myself very poorly today. I agree
with everything you say here, but it doesn't go against what I've been
saying.

If I cared about the issue more, I might have another crack at putting
my meaning into words; but those who want to support a broad stride of
Python versions are more motivated than I to figure it out, so instead I
depart the field.

-- 
 \ “People's Front To Reunite Gondwanaland: Stop the Laurasian |
  `\  Separatist Movement!” —wiredog, http://kuro5hin.org/ |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[Martin v. Loewis]

> I just
> couldn't get through on the python-dev list that I couldn't just
> upgrade my code to 2.6 and then use 2to3 to keep in step across the
> 2-3 chasm, as this would leave behind my faithful pre-2.6 users.

Not sure whom you had been talking to. But I would have tried to explain
that you don't *have* to port to 2.6 to use 2to3 - it will
work just as fine with 2.3 code, and earlier.

> - No use of sets.  Instead I defined a very simple set simulation
> using dict keys, which could be interchanged with set for later
> versions.

This I don't understand. IIUC, you want to support 2.3 and later.
Now, 2.3 already has a set module, even though set is not a builtin.
So you could use sets just as well.

> - No generator expressions, only list comprehensions.

Ok. Not sure how this causes problems, though - just don't use them, then.

> - No use of decorators.  BUT, pyparsing includes a decorator method,
> traceParseAction, which can be used by users with later Pythons as
> @traceParseAction in their own code.

Of course, users of older Python versions could explicitly wrap
the functions with the decorator if they wanted to.

> - No print statements.  As pyparsing is intended to be an internal
> module, it does no I/O as part of its function - it only processes a
> given string, and returns a data structure.

If you don't need them, fine. If you do, I'd just let 2to3 transform them.

> - Python 2-3 compatible exception syntax.  This may have been my
> trickiest step.  The change of syntax for except from
> 
> except ExceptionType, ex:
> 
> to:
> 
> except ExceptionType as ex:
> 
> is completely forward and backward incompatible.  The workaround is to
> rewrite as:
> 
> except ExceptionType:
> ex = sys.exc_info()[0]

Likewise, and more importantly so: use 2to3. It can be done this way,
but I find the 2to3 solution much cleaner.

> But in
> the meantime, I am still able to support all versions of Python NOW,
> and I plan to continue doing so (albeit "support" for 2.x versions
> will eventually mean "continue to offer a frozen feature set, with
> minimal bug-fixing if any").

The same would have been possible if you had chosen to use 2to3.

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

Re: The real problem with Python 3 - no business case for conversion

[Martin v. Loewis]

> The point, one more time with feeling, is that the incompatibilities
> between 2.x and 3.x will *increase* over time.

I think this is unfounded, and actually false.

Instead, the incompatibilities will *decrease* over the next few years.
Suppose you support 2.x and 3.x from a single code base. Today, you
might support 2.3 up to 3.1. In a year, you might drop 2.3, and start
support 3.2. That will lead to a reduction of incompatibilities: you
can start using 2.4 features, and drop work-arounds for 2.3 limitations.
Likewise when you then, later, drop 2.4.

As a specific example, since 2.5, the modules in the email package are
in lower case, in compliance with PEP 8. 2.x has backwards compatibility
so that you can continue to use the uppercase module names, which you
need for 2.3/2.4 compat. In 3.x, you can't use these spelling anymore,
so your code might use try/except as a work-around. When you drop 2.4,
you can drop the work-around.

> If you now have a code base that is relatively easy to maintain for both
> Python 2.x and 3.x, that is a result of much back-porting efforts and of
> a new-feature moratorium that is currently in effect. Enjoy that
> situation as you may, because it is guaranteed not to last.

On the contrary: it's getting better. The back-porting efforts only
become available in 2.6, and you would have to support at least 2.5
today (at least, that's how many maintainers feel). Only when you
can drop 2.5 support, you can actually start *using* these backport
features, allowing you to make the 2.x and 3.x code more similar.

Eventually, the difference will get larger again. Hopefully, by that
time, 2.7 got out of use.

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

Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[Martin v. Loewis]

> Python 3.x will continue to change.  The incompatibilities between 3.x
> and 2.x will only become more numerous.  If your goal is to support
> 2.x, and 3.x, you'd be best supporting them separately.

I don't think that's a particularly good approach. Having a single code
base for both likely reduced the maintenance burden significantly
compared to a code fork.

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

Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[Michele Simionato]

On Jul 7, 10:55 pm, Carl Banks  wrote:
> On Jul 7, 1:31 am, Paul McGuire  wrote:
> > I just
> > couldn't get through on the python-dev list that I couldn't just
> > upgrade my code to 2.6 and then use 2to3 to keep in step across the
> > 2-3 chasm, as this would leave behind my faithful pre-2.6 users.

This is a point I do not understand. My recent module plac is meant to
work from Python 2.3 to Python 3.1 and to this goal I make use of 2to3
at the *client* side.
Users of Python 2.X get the original code with no magic whatsoever;
users of Python 3.X
get the same code, but at installation time 2to3 is run by the
setup.py script. The mechanism requires distribute to be installed,
but I would say that having distribute is a must for Python 3.X users;
Python 2.X users do not need anything, so the approach is backward
compatible. I thought this was the recommended way of using 2to3 and
so far is working for me.

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

Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[Martin v. Loewis]

Am 07.07.2010 23:10, schrieb Brendan Abel:
 One thing that would be very useful is how to maintain something that
 works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
 versions below 2.6 is out of the question for most projects with a
 significant userbase IMHO. As such, the idea of running the python 3
 warnings is not so useful IMHO - unless it could be made to work
 better for python 2.x < 2.6, but I am not sure the idea even makes
 sense.
> 
> The entire fact that 3.x was *designed* to be incompatible should tell
> you that supporting 2.x and 3.x with a single code base is a bad idea,
> except for the very smallest of projects.  This is the point where a
> project should fork and provide two different versions.

I completely disagree. My personal experience is that this is well
possible even for large code bases, and I would recommend having a
single code base for 2.x and 3.x *in particular* for large projects,
which probably need to support 2.x users for quite some time, but
simultaneously need to support 3.x users.

Regards,
Martin

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

Re: The real problem with Python 3 - no business case for conversion

[Terry Reedy]

On 7/7/2010 10:49 PM, Ben Finney wrote:


Yes, that's what I meant. Python 3 is deliberately under no obligation
to support code that works in Python 2. If something needs fixing, and
that fix would involve breaking Python 2 code, then that's not a
consideration any more.


Code that works in 3.1 *is* 3.1 code. Leaving aside bug fixes and 
additions that makes code that once raised an exception do something 
instead, I do not know that 3.1 broke and 3.0 code and I do not know of 
any deprecations in 3.1 that will become removals in 3.2.



The predictable result is that Python 3 will continue to gain
backward-incompatible changes in future.


For the core syntax, not too likely. In any case, the usually 3 version 
pending-deprecation, deprecation, removal process would apply. Some of 
the library modules that do not work well for 3.1 will see more changes.



On the other hand, the door appears closed for Python 3 adding more
stuff that breaks Python 2 code.


What gives you that idea? Can you reference a specific statement from
the PYthon developers that says that?


3.0 was stated to be a special case. I will let you look.

--
Terry Jan Reedy

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

Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[Zooko O'Whielacronx]

Dear Paul McGuire:

Thank you very much for these notes!

See also a few other notes:

Michael Foord: 
http://www.voidspace.org.uk/python/weblog/arch_d7_2010_03_20.shtml#e1167
Ned Batchelder:
http://nedbatchelder.com/blog/200910/running_the_same_code_on_python_2x_and_3x.html

I was wondering if it would be useful to have a library that
implements these hacks so that people like me who prefer to maintain a
single codebase instead of using a tool like 2to3 could easily adopt
them.

Oh look! Here is one:

http://pybites.blogspot.com/2010/06/six-python-23-compatibility-helpers.html

:-)

Regards,

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

Re: The real problem with Python 3 - no business case for conversion

[Terry Reedy]

On 7/7/2010 9:14 PM, Ben Finney wrote:


The point, one more time with feeling, is that the incompatibilities
between 2.x and 3.x will *increase* over time.


For the purpose of maintaining least-common-denominator multi-version 
code, it is only deletions and semantic changes that matter. Feature 
additions will be more common, at least for awhile. The problem of 
backporting 3.x code that uses 3.x features definitely will increase.



--
Terry Jan Reedy

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

Re: The real problem with Python 3 - no business case for conversion

[geremy condra]

On Wed, Jul 7, 2010 at 11:32 PM, Ben Finney  wrote:
> geremy condra  writes:
>
>> On Wed, Jul 7, 2010 at 9:14 PM, Ben Finney  
>> wrote:
>> > [backward-]incompatibilities between 2.x and 3.x will *increase*
>> > over time.
>>
>> ...and? I don't get to use features from 2.7, why would I expect to
>> use features from 3.3?
>
> Conversely, why would you support Python 3.1?

Because in 10 years the percentage of people who have Python 2.x
installed will be the same as the percentage that have Python 1.x
installed today.

>> > Indeed, the feature moratorium is designed in part to help
>> > slow-moving codebases migrate to Python 3.x before Python resumes
>> > its normal pace of change again. If you're choosing to use that time
>> > to further entrench codebases for Python 2.x, I think that's a
>> > short-sighted choice.
>>
>> I welcome the day that I can stop supporting 2.x. Until then, I have
>> to support both and your argument is irrelevant.
>
> Why do you have to support Python 3 at all?

See above.

> Will you expect to continue
> maintaining a single code base that supports PYthon 2.x and Python 3.2,
> then 3.3, and so on?

Yes, with the occasional feature or bugfix. Is there an alternate
interpretation I'm missing?

> The only point being made here is to answer the question of why people
> are saying that a single code base for both 2.x and 3.x is a maintenance
> burden. If, in your case, at the present time, that's not the case, then
> good for you! But it will get increasingly harder to do, and the reasons
> why have now been explained. Apply them as you see fit.

I see you stating that it will become harder but I don't see why that
should be the case.

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

Re: The real problem with Python 3 - no business case for conversion

[Paul Rubin]

Ben Finney  writes:
>> On the other hand, the door appears closed for Python 3 adding more
>> stuff that breaks Python 2 code.
>
> What gives you that idea? Can you reference a specific statement from
> the PYthon developers that says that?

It's just logic.  As I understand it, future versions of Python 3 are
supposed to not break programs that work under current versions of
Python 3.  So any Python 2 program that is a valid Python 3 program
today has to stay valid.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[Terry Reedy]

On 7/7/2010 4:31 AM, Paul McGuire wrote:

[snip interesting report on how Paul suppost pyparsing for 2.3 to 3.1]

Thank you for this.

Do you think such cross-version support would have been easier or harder 
if the major changes and deletions in 3.0 has been spread over several 
versions, such as 2.5 - 2.7. In other words, suppose the Python 3 idea 
never occurred to anyone and


2.5 dropped the old int division and finished the unification of int and 
long.


2.6 dropped classic classes and switched range, filter, and map to their 
iterator versions.


2.7 made unicode the text type

This is not purely a hypothetical question since the issue of spreading 
or bunching changes may arise again in the future.


--
Terry Jan Reedy

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

Re: The real problem with Python 3 - no business case for conversion

[Ben Finney]

geremy condra  writes:

> On Wed, Jul 7, 2010 at 9:14 PM, Ben Finney  wrote:
> > [backward-]incompatibilities between 2.x and 3.x will *increase*
> > over time.
>
> ...and? I don't get to use features from 2.7, why would I expect to
> use features from 3.3?

Conversely, why would you support Python 3.1?

> > Indeed, the feature moratorium is designed in part to help
> > slow-moving codebases migrate to Python 3.x before Python resumes
> > its normal pace of change again. If you're choosing to use that time
> > to further entrench codebases for Python 2.x, I think that's a
> > short-sighted choice.
>
> I welcome the day that I can stop supporting 2.x. Until then, I have
> to support both and your argument is irrelevant.

Why do you have to support Python 3 at all? Will you expect to continue
maintaining a single code base that supports PYthon 2.x and Python 3.2,
then 3.3, and so on?

The only point being made here is to answer the question of why people
are saying that a single code base for both 2.x and 3.x is a maintenance
burden. If, in your case, at the present time, that's not the case, then
good for you! But it will get increasingly harder to do, and the reasons
why have now been explained. Apply them as you see fit.

-- 
 \ “I'm a born-again atheist.” —Gore Vidal |
  `\   |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[Terry Reedy]

On 7/7/2010 5:29 AM, geremy condra wrote:

On Tue, Jul 6, 2010 at 1:37 AM, Terry Reedy  wrote:

On 7/5/2010 9:00 PM, Philip Semanchuk wrote:

On Jul 5, 2010, at 6:41 PM, Chris Rebert wrote:

On Mon, Jul 5, 2010 at 3:38 PM, Philip Semanchu



I ported two pure C extensions from 2 to 3 and was even able to keep a
single C codebase. I'd be willing to contribute my experiences to a
document
somewhere. (Is there a Wiki?)



Indeed there is: http://wiki.python.org/moin/



Thanks. I don't want to appear ungrateful, but I was hoping for
something specific to the 2-to-3 conversion. I guess someone has to
start somewhere...



There is an existing 2to3 and other pages for Python code conversion. I do
not know of any for CAPI conversion. The need for such has been acknowledged
among the devs but if there is nothing yet, we need someone with specialized
experience and a bit of time to make a first draft. If you start one, give
it an easy to remember name C2to3? 2to3Capi? You choose. And link to it from
the 2to3 pag
In his post on this thread, Martin Loewis volunteered to list what he knows
from psycopg2 if someone else will edit.



I'm not sure why I don't have this post, but I'm happy to help edit
etc if Martin
wants to put together a rough draft.


Since I wrote that, someone pointed out the the Python How-to collection 
includes Porting Extension Modules to 3.0
by Benjamim Peterson. So all Pyilip or Martin need to do is read that 
and suggest additions.


Since it is part of the doc set, I presume an issue could be opened on 
the tracker.


--
Terry Jan Reedy

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

Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[David Cournapeau]

On Wed, Jul 7, 2010 at 10:55 PM, Carl Banks  wrote:
> On Jul 7, 1:31 am, Paul McGuire  wrote:
>> On Jul 6, 3:30 am, David Cournapeau  wrote:> On Tue, Jul 
>> 6, 2010 at 4:30 AM, D'Arcy J.M. Cain  wrote:
>>
>> > One thing that would be very useful is how to maintain something that
>> > works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
>> > versions below 2.6 is out of the question for most projects with a
>> > significant userbase IMHO. As such, the idea of running the python 3
>> > warnings is not so useful IMHO - unless it could be made to work
>> > better for python 2.x < 2.6, but I am not sure the idea even makes
>> > sense.
>>
>> This is exactly how I felt about my support for pyparsing, that I was
>> trying continue to provide support for 2.3 users, up through 3.x
>> users, with a single code base.  (This would actually have been
>> possible if I had been willing to introduce a performance penalty for
>> Python 2 users, but performance is such a critical issue for parsing I
>> couldn't justify it to myself.)  This meant that I had to constrain my
>> implementation, while trying to incorporate forward-looking support
>> features (such as __bool__ and __dir__), which have no effect on older
>> Python versions, but support additions in newer Pythons.  I just
>> couldn't get through on the python-dev list that I couldn't just
>> upgrade my code to 2.6 and then use 2to3 to keep in step across the
>> 2-3 chasm, as this would leave behind my faithful pre-2.6 users.
>>
>> Here are some of the methods I used:
>>
>> - No use of sets.  Instead I defined a very simple set simulation
>> using dict keys, which could be interchanged with set for later
>> versions.
>>
>> - No generator expressions, only list comprehensions.
>>
>> - No use of decorators.  BUT, pyparsing includes a decorator method,
>> traceParseAction, which can be used by users with later Pythons as
>> @traceParseAction in their own code.
>>
>> - No print statements.  As pyparsing is intended to be an internal
>> module, it does no I/O as part of its function - it only processes a
>> given string, and returns a data structure.
>>
>> - Python 2-3 compatible exception syntax.  This may have been my
>> trickiest step.  The change of syntax for except from
>>
>>     except ExceptionType, ex:
>>
>> to:
>>
>>     except ExceptionType as ex:
>>
>> is completely forward and backward incompatible.  The workaround is to
>> rewrite as:
>>
>>     except ExceptionType:
>>         ex = sys.exc_info()[0]
>>
>> which works just fine in 2.x and 3.x.  However, there is a slight
>> performance penalty in doing this, and pyparsing uses exceptions as
>> part of its grammar success/failure signalling and backtracking; I've
>> used this technique everywhere I can get away with it, but there is
>> one critical spot where I can't use it, so I have to keep 2 code bases
>> with slight differences between them.
>>
>> - Implement __bool__, followed by __nonzero__ = __bool__.  This will
>> give you boolean support for your classes in 2.3-3.1.
>>
>> - Implement __dir__, which is unused by old Pythons, but supports
>> customization of dir() output for your own classes.
>>
>> - Implement __len__, __contains__, __iter__ and __reversed__ for
>> container classes.
>>
>> - No ternary expressions.  Not too difficult really, there are several
>> well-known workarounds for this, either by careful use of and's and
>> or's, or using the bool-as-int to return the value from
>> (falseValue,trueValue)[condition].
>>
>> - Define a version-sensitive portion of your module, to define
>> synonyms for constants that changed name between versions.  Something
>> like:
>>
>>     _PY3K = sys.version_info[0] > 2
>>     if _PY3K:
>>         _MAX_INT = sys.maxsize
>>         basestring = str
>>         _str2dict = set
>>         alphas = string.ascii_lowercase + string.ascii_uppercase
>>     else:
>>         _MAX_INT = sys.maxint
>>         range = xrange
>>         _str2dict = lambda strg : dict( [(c,0) for c in strg] )
>>         alphas = string.lowercase + string.uppercase
>>
>> The main body of my code uses range throughout (for example), and with
>> this definition I get the iterator behavior of xrange regardless of
>> Python version.
>>
>> In the end I still have 2 source files, one for Py2 and one for Py3,
>> but there is only a small and manageable number of differences between
>> them, and I expect at some point I will move forward to supporting Py3
>> as my primary target version.  But personally I think this overall
>> Python 2-3 migration process is moving along at a decent rate, and I
>> should be able to make my switchover in another 12-18 months.  But in
>> the meantime, I am still able to support all versions of Python NOW,
>> and I plan to continue doing so (albeit "support" for 2.x versions
>> will eventually mean "continue to offer a frozen feature set, with
>> minimal bug-fixing if any").
>>
>> I realize that pyparsing is a simple-minded module in comparison to
>> others

Re: The real problem with Python 3 - no business case for conversion

[Ben Finney]

Paul Rubin  writes:

> Ben Finney  writes:
> > The point, one more time with feeling, is that the incompatibilities
> > between 2.x and 3.x will *increase* over time.
>
> The issue is less the "incompatibilities" than the -backwards-
> incompatibilities.

Yes, that's what I meant. Python 3 is deliberately under no obligation
to support code that works in Python 2. If something needs fixing, and
that fix would involve breaking Python 2 code, then that's not a
consideration any more.

The predictable result is that Python 3 will continue to gain
backward-incompatible changes in future.

> On the other hand, the door appears closed for Python 3 adding more
> stuff that breaks Python 2 code.

What gives you that idea? Can you reference a specific statement from
the PYthon developers that says that?

-- 
 \ “Not to be absolutely certain is, I think, one of the essential |
  `\ things in rationality.” —Bertrand Russell |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion

[geremy condra]

On Wed, Jul 7, 2010 at 9:14 PM, Ben Finney  wrote:
> geremy condra  writes:
>
>> On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel <007bren...@gmail.com> wrote:
>> > Python 3.x will continue to change.  The incompatibilities between
>> > 3.x and 2.x will only become more numerous.  If your goal is to
>> > support 2.x, and 3.x, you'd be best supporting them separately.
>>
>> I maintain two projects that have to work from 2.5 to 3.1. On one of
>> them (~5kloc) we took the separate support route, and on the other
>> (~30kloc) I decided to keep a single codebase. IME the maintenance
>> burden on the former is substantially higher than the latter.
>
> The point, one more time with feeling, is that the incompatibilities
> between 2.x and 3.x will *increase* over time.

...and? I don't get to use features from 2.7, why would I expect to
use features from 3.3?

> If you now have a code base that is relatively easy to maintain for both
> Python 2.x and 3.x, that is a result of much back-porting efforts and of
> a new-feature moratorium that is currently in effect. Enjoy that
> situation as you may, because it is guaranteed not to last.

I have to target the oldest version of Python I want to support. New
features are irrelevant. I'm not sure why I should need to explain
that to you.

> Indeed, the feature moratorium is designed in part to help slow-moving
> codebases migrate to Python 3.x before Python resumes its normal pace of
> change again. If you're choosing to use that time to further entrench
> codebases for Python 2.x, I think that's a short-sighted choice.

I welcome the day that I can stop supporting 2.x. Until then, I have to
support both and your argument is irrelevant.

> Python 2.7 is the last 2.x, no further 3.x features will be back-ported.
> New 3.x features will begin to appear after the moratorium ends. The
> combination of those two means that *the single-codebase burden will
> only increase over time* as Python 3.x diverges further from what Python
> 2.x can support.

See above.

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

Re: The real problem with Python 3 - no business case for conversion

[Paul Rubin]

Ben Finney  writes:
> The point, one more time with feeling, is that the incompatibilities
> between 2.x and 3.x will *increase* over time.

The issue is less the "incompatibilities" than the -backwards-
incompatibilities.  Yes, Python 3 may introduce forward
incompatibilities by adding features absent from Python 2.  But it will
be possible to maintain a common codebase simply by not using those
features.  On the other hand, the door appears closed for Python 3
adding more stuff that breaks Python 2 code.

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

Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[Carl Banks]

On Jul 7, 2:10 pm, Brendan Abel <007bren...@gmail.com> wrote:
> > > > One thing that would be very useful is how to maintain something that
> > > > works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
> > > > versions below 2.6 is out of the question for most projects with a
> > > > significant userbase IMHO. As such, the idea of running the python 3
> > > > warnings is not so useful IMHO - unless it could be made to work
> > > > better for python 2.x < 2.6, but I am not sure the idea even makes
> > > > sense.
>
> The entire fact that 3.x was *designed* to be incompatible should tell
> you that supporting 2.x and 3.x with a single code base is a bad idea,
> except for the very smallest of projects.  This is the point where a
> project should fork and provide two different versions.

Well, I think it could be a reasonable thing to maintain a single
codebase in 2.x and use 2to3 (and/or a custom translator) to translate
to 3.x version for quite a while.

For the humble library I maintain, I plan to release a Python 3
version as soon as a Python 3 version of numpy is released, maintain a
single codebase (translating from 2 version to 3) for awhile, then at
some point fork them and maintain them separately.

Given that I add features about once every 2 years I don't think it'll
be too much of a burden, though.


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

Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[Fuzzyman]

On Jul 5, 1:34 am, sturlamolden  wrote:
> On 5 Jul, 01:58, John Nagle  wrote:
>
> >      Exactly.
>
> >      The "incompatible with all extension modules I need" part
> > is the problem right now.  A good first step would be to
> > identify the top 5 or 10 modules that are blocking a move to
> > Python 3 by major projects with many users.
>
> The big danger is Python 2.x becoming abandonware (2.7 being the final
> release) before major projects are ported. Using Python 2.x for new
> projects is not advisable (at least many will think so), and using 3.x
> is not possible. What to do? It's not a helpful situation for Python.

But Python 2.3, 2.4 & 2.5 are *already* abandonware and see *major*
use in many systems and businesses. Python development has always gone
ahead of what *some* people use - and they don't seem to mind that
they're using essentially abandoned versions of Python.

Now that 2.7 is out I *might* be able to persuade my current company
to migrate to 2.6 on the servers, and they're far faster at adopting
tech than many companies I know.

All the best,

Michael Foord
--
http://www.voidspace.org.uk
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[MRAB]

geremy condra wrote:

On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel <007bren...@gmail.com> wrote:

On Jul 7, 3:00 pm, MRAB  wrote:

Brendan Abel wrote:

One thing that would be very useful is how to maintain something that
works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
versions below 2.6 is out of the question for most projects with a
significant userbase IMHO. As such, the idea of running the python 3
warnings is not so useful IMHO - unless it could be made to work
better for python 2.x < 2.6, but I am not sure the idea even makes
sense.

The entire fact that 3.x was *designed* to be incompatible should tell
you that supporting 2.x and 3.x with a single code base is a bad idea,
except for the very smallest of projects.  This is the point where a
project should fork and provide two different versions.

I wouldn't say that 3.x was designed to be incompatible. It was designed
to tidy the language, and the incompatibilities are an unfortunate
result.

You're missing the point, and arguing semantics.  It's a good thing I
didn't misspell anything.

Python 3.x will continue to change.  The incompatibilities between 3.x
and 2.x will only become more numerous.  If your goal is to support
2.x, and 3.x, you'd be best supporting them separately.


I maintain two projects that have to work from 2.5 to 3.1. On one of
them (~5kloc) we took the separate support route, and on the other
(~30kloc) I decided to keep a single codebase. IME the maintenance
burden on the former is substantially higher than the latter. Is the
difference in difficulty perhaps domain-related, or a result of a
certain style of coding? Could you give us some more details about
what you were working on that caused you to conclude this?


In my work on the regex module I use a single codebase and generate the
sources for Python 2.5-2.7 and for Python 3.1 from it. It works easily
enough for me.
--
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion

[Ben Finney]

geremy condra  writes:

> On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel <007bren...@gmail.com> wrote:
> > Python 3.x will continue to change.  The incompatibilities between
> > 3.x and 2.x will only become more numerous.  If your goal is to
> > support 2.x, and 3.x, you'd be best supporting them separately.
>
> I maintain two projects that have to work from 2.5 to 3.1. On one of
> them (~5kloc) we took the separate support route, and on the other
> (~30kloc) I decided to keep a single codebase. IME the maintenance
> burden on the former is substantially higher than the latter.

The point, one more time with feeling, is that the incompatibilities
between 2.x and 3.x will *increase* over time.

If you now have a code base that is relatively easy to maintain for both
Python 2.x and 3.x, that is a result of much back-porting efforts and of
a new-feature moratorium that is currently in effect. Enjoy that
situation as you may, because it is guaranteed not to last.

Indeed, the feature moratorium is designed in part to help slow-moving
codebases migrate to Python 3.x before Python resumes its normal pace of
change again. If you're choosing to use that time to further entrench
codebases for Python 2.x, I think that's a short-sighted choice.

Python 2.7 is the last 2.x, no further 3.x features will be back-ported.
New 3.x features will begin to appear after the moratorium ends. The
combination of those two means that *the single-codebase burden will
only increase over time* as Python 3.x diverges further from what Python
2.x can support.

-- 
 \  “Programs must be written for people to read, and only |
  `\incidentally for machines to execute.” —Abelson & Sussman, |
_o__)  _Structure and Interpretation of Computer Programs_ |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[geremy condra]

On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel <007bren...@gmail.com> wrote:
> On Jul 7, 3:00 pm, MRAB  wrote:
>> Brendan Abel wrote:
>>  One thing that would be very useful is how to maintain something that
>>  works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
>>  versions below 2.6 is out of the question for most projects with a
>>  significant userbase IMHO. As such, the idea of running the python 3
>>  warnings is not so useful IMHO - unless it could be made to work
>>  better for python 2.x < 2.6, but I am not sure the idea even makes
>>  sense.
>>
>> > The entire fact that 3.x was *designed* to be incompatible should tell
>> > you that supporting 2.x and 3.x with a single code base is a bad idea,
>> > except for the very smallest of projects.  This is the point where a
>> > project should fork and provide two different versions.
>>
>> I wouldn't say that 3.x was designed to be incompatible. It was designed
>> to tidy the language, and the incompatibilities are an unfortunate
>> result.
>
> You're missing the point, and arguing semantics.  It's a good thing I
> didn't misspell anything.
>
> Python 3.x will continue to change.  The incompatibilities between 3.x
> and 2.x will only become more numerous.  If your goal is to support
> 2.x, and 3.x, you'd be best supporting them separately.

I maintain two projects that have to work from 2.5 to 3.1. On one of
them (~5kloc) we took the separate support route, and on the other
(~30kloc) I decided to keep a single codebase. IME the maintenance
burden on the former is substantially higher than the latter. Is the
difference in difficulty perhaps domain-related, or a result of a
certain style of coding? Could you give us some more details about
what you were working on that caused you to conclude this?

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

Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")

[Brendan Abel]

On Jul 7, 3:00 pm, MRAB  wrote:
> Brendan Abel wrote:
>  One thing that would be very useful is how to maintain something that
>  works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
>  versions below 2.6 is out of the question for most projects with a
>  significant userbase IMHO. As such, the idea of running the python 3
>  warnings is not so useful IMHO - unless it could be made to work
>  better for python 2.x < 2.6, but I am not sure the idea even makes
>  sense.
>
> > The entire fact that 3.x was *designed* to be incompatible should tell
> > you that supporting 2.x and 3.x with a single code base is a bad idea,
> > except for the very smallest of projects.  This is the point where a
> > project should fork and provide two different versions.
>
> I wouldn't say that 3.x was designed to be incompatible. It was designed
> to tidy the language, and the incompatibilities are an unfortunate
> result.

You're missing the point, and arguing semantics.  It's a good thing I
didn't misspell anything.

Python 3.x will continue to change.  The incompatibilities between 3.x
and 2.x will only become more numerous.  If your goal is to support
2.x, and 3.x, you'd be best supporting them separately.


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