Re: [Python-Dev] [Python-checkins] r85739 - in python/branches/issue4388/Lib/test: script_helper.py test_cmd_line.py

2010-10-20 Thread Nick Coghlan 
On Wed, Oct 20, 2010 at 10:06 PM, victor.stinner
 wrote:
> Modified: python/branches/issue4388/Lib/test/test_cmd_line.py
> ==
> --- python/branches/issue4388/Lib/test/test_cmd_line.py (original)
> +++ python/branches/issue4388/Lib/test/test_cmd_line.py Wed Oct 20 14:06:46 
> 2010
> @@ -103,8 +103,15 @@
>         if sys.getfilesystemencoding() != 'ascii':
>             if test.support.verbose:
>                 import locale
> +                env = os.environ.copy()
> +                for key in ('LC_ALL', 'LC_CTYPE', 'LANG'):
> +                    try:
> +                        del env[key]
> +                    except KeyError:
> +                        pass
>                 print('locale encoding = %s, filesystem encoding = %s'
> -                      % (locale.getpreferredencoding(), 
> sys.getfilesystemencoding()))
> +                      % (locale.getpreferredencoding(), 
> sys.getfilesystemencoding()),
> +                      env=env)
>             command = "assert(ord('\xe9') == 0xe9)"
>             assert_python_ok('-c', command)

Isn't that "env=env" argument meant to be down in the call to
assert_python_ok, not in the print call? (your next checkin didn't
change this)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [patch] fpconst for python3

2010-10-20 Thread David Malcolm 
(my apologies, if necessary, for top-posting)

FWIW Neal asked about this on Fedora's development mailing list as well:
http://lists.fedoraproject.org/pipermail/devel/2010-October/144535.html

If I'm reading:
  http://pypi.python.org/pypi/fpconst/
correctly, that project hasn't had an upstream update in over four
years, and the upstream home page seems to be down.

I believe that there are a number of python 2 modules that are either
mature or "good enough", but need porting to work with python 3, and in
some of these cases, upstream may have either disappeared, or lost
interest.

I'm guessing that Neal has already made an effort to contact the
maintainer of fpconst.

IIRC, fpconst is a relatively simple module, and the fixes to port to
python 3 seem simple.

So IMHO this is on-topic for python.org (if not necessarily this list),
in that we have an interest in timely porting of Python 2 code to Python
3, and there has been discussion here on how to encourage people to port
their code.

We don't want each Linux distribution to do different patches to port
the code to Python 3: there ought to be some kind of clearing-house for
this kind of simple porting, so that python 3 stacks will work
consistently across the different distributions.

Whether or not that's python-dev, I'm not sure. Perhaps:
  http://mail.python.org/mailman/listinfo/python-porting
is a better list.

FWIW you can see the current status of Python 3 porting within Fedora
here:
  https://fedoraproject.org/wiki/Python3#Porting_status

Hope this is helpful
Dave

On Tue, 2010-10-19 at 20:07 -0500, Benjamin Peterson wrote:
> fpconst developers?
> 
> 2010/10/19 Neal Becker :
> > Where should I send this patch?
> >
> > diff -u fpconst-0.7.2/fpconst.py fpconst-0.7.2.new/fpconst.py
> > --- fpconst-0.7.2/fpconst.py2005-02-24 12:42:03.0 -0500
> > +++ fpconst-0.7.2.new/fpconst.py2010-10-19 20:55:07.407765664 -0400
> > @@ -40,18 +40,18 @@
> >  ident = "$Id: fpconst.py,v 1.16 2005/02/24 17:42:03 warnes Exp $"
> >
> >  import struct, operator
> > +from functools import reduce
> >
> >  # check endianess
> > -_big_endian = struct.pack('i',1)[0] != '\x01'
> > -
> > +_big_endian = struct.pack('i',1)[0] != 1
> >  # and define appropriate constants
> >  if(_big_endian):
> > -NaN= struct.unpack('d', '\x7F\xF8\x00\x00\x00\x00\x00\x00')[0]
> > -PosInf = struct.unpack('d', '\x7F\xF0\x00\x00\x00\x00\x00\x00')[0]
> > +NaN= struct.unpack('d', b'\x7F\xF8\x00\x00\x00\x00\x00\x00')[0]
> > +PosInf = struct.unpack('d', b'\x7F\xF0\x00\x00\x00\x00\x00\x00')[0]
> > NegInf = -PosInf
> >  else:
> > -NaN= struct.unpack('d', '\x00\x00\x00\x00\x00\x00\xf8\xff')[0]
> > -PosInf = struct.unpack('d', '\x00\x00\x00\x00\x00\x00\xf0\x7f')[0]
> > +NaN= struct.unpack('d', b'\x00\x00\x00\x00\x00\x00\xf8\xff')[0]
> > +PosInf = struct.unpack('d', b'\x00\x00\x00\x00\x00\x00\xf0\x7f')[0]
> > NegInf = -PosInf
> >
> >  def _double_as_bytes(dval):
> >
> > ___
> > Python-Dev mailing list
> > [email protected]
> > http://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe: 
> > http://mail.python.org/mailman/options/python-dev/benjamin%40python.org
> >
> 
> 
> 

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [patch] fpconst for python3

2010-10-20 Thread Michael Foord 

 On 20/10/2010 17:43, David Malcolm wrote:

(my apologies, if necessary, for top-posting)

FWIW Neal asked about this on Fedora's development mailing list as well:
http://lists.fedoraproject.org/pipermail/devel/2010-October/144535.html

If I'm reading:
   http://pypi.python.org/pypi/fpconst/
correctly, that project hasn't had an upstream update in over four
years, and the upstream home page seems to be down.

I believe that there are a number of python 2 modules that are either
mature or "good enough", but need porting to work with python 3, and in
some of these cases, upstream may have either disappeared, or lost
interest.

I'm guessing that Neal has already made an effort to contact the
maintainer of fpconst.

IIRC, fpconst is a relatively simple module, and the fixes to port to
python 3 seem simple.

So IMHO this is on-topic for python.org (if not necessarily this list),
in that we have an interest in timely porting of Python 2 code to Python
3, and there has been discussion here on how to encourage people to port
their code.

We don't want each Linux distribution to do different patches to port
the code to Python 3: there ought to be some kind of clearing-house for
this kind of simple porting, so that python 3 stacks will work
consistently across the different distributions.

Whether or not that's python-dev, I'm not sure. Perhaps:
   http://mail.python.org/mailman/listinfo/python-porting
is a better list.

FWIW you can see the current status of Python 3 porting within Fedora
here:
   https://fedoraproject.org/wiki/Python3#Porting_status


Wow, that's very interesting. Whilst a lot of people on this list will 
have an interest in knowing about this it still isn't the right list for 
discussing it. The python-porting list *is* an entirely appropriate list 
and it would be great to see more traffic there.


What to do about "abandoned" PyPI packages that are still used, and 
defacto maintained by downstream packagers, is another 
(interesting/important/difficult) topic that is also off-topic for this 
list. catalog-sig is possibly the right place for that. Creating a new 
PyPI package for the port and forking the project is probably the best 
approach.


Michael Foord


Hope this is helpful
Dave

On Tue, 2010-10-19 at 20:07 -0500, Benjamin Peterson wrote:

fpconst developers?

2010/10/19 Neal Becker:

Where should I send this patch?

diff -u fpconst-0.7.2/fpconst.py fpconst-0.7.2.new/fpconst.py
--- fpconst-0.7.2/fpconst.py2005-02-24 12:42:03.0 -0500
+++ fpconst-0.7.2.new/fpconst.py2010-10-19 20:55:07.407765664 -0400
@@ -40,18 +40,18 @@
  ident = "$Id: fpconst.py,v 1.16 2005/02/24 17:42:03 warnes Exp $"

  import struct, operator
+from functools import reduce

  # check endianess
-_big_endian = struct.pack('i',1)[0] != '\x01'
-
+_big_endian = struct.pack('i',1)[0] != 1
  # and define appropriate constants
  if(_big_endian):
-NaN= struct.unpack('d', '\x7F\xF8\x00\x00\x00\x00\x00\x00')[0]
-PosInf = struct.unpack('d', '\x7F\xF0\x00\x00\x00\x00\x00\x00')[0]
+NaN= struct.unpack('d', b'\x7F\xF8\x00\x00\x00\x00\x00\x00')[0]
+PosInf = struct.unpack('d', b'\x7F\xF0\x00\x00\x00\x00\x00\x00')[0]
 NegInf = -PosInf
  else:
-NaN= struct.unpack('d', '\x00\x00\x00\x00\x00\x00\xf8\xff')[0]
-PosInf = struct.unpack('d', '\x00\x00\x00\x00\x00\x00\xf0\x7f')[0]
+NaN= struct.unpack('d', b'\x00\x00\x00\x00\x00\x00\xf8\xff')[0]
+PosInf = struct.unpack('d', b'\x00\x00\x00\x00\x00\x00\xf0\x7f')[0]
 NegInf = -PosInf

  def _double_as_bytes(dval):

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/benjamin%40python.org





___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [patch] fpconst for python3

2010-10-20 Thread Barry Warsaw 
On Oct 20, 2010, at 05:50 PM, Michael Foord wrote:

>Wow, that's very interesting. Whilst a lot of people on this list will have
>an interest in knowing about this it still isn't the right list for
>discussing it. The python-porting list *is* an entirely appropriate list and
>it would be great to see more traffic there.

Agreed.  python-porting (which I'd forgotten about but just subscribed to)
seems like the right place for cross-distro and other porting issues.  

We also have this top page in the wiki:

http://wiki.python.org/moin/PortingToPy3k

Right now it contains guides to porting Python code and C code, but I think it
should also contain pages that coordinate porting efforts for packages on
Cheeseshop and in distros.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support for async read/write

2010-10-20 Thread Glyph Lefkowitz 

On Oct 19, 2010, at 9:55 PM, [email protected] wrote:

>> Not only is the performance usually worse than expected, the behavior of 
>> aio_* functions require all kinds of subtle and mysterious coordination with 
>> signal handling, which I'm not entirely sure Python would even be able to 
>> pull off without some modifications to the signal module.  (And, as 
>> Jean-Paul mentioned, if your OS kernel runs out of space in a queue 
>> somewhere, completion notifications might just never be delivered at all.)
> 
> Just to be clear, James corrected me there.  I thought Jesus was talking 
> about the mostly useless Linux AIO APIs, which have the problems I described. 
>  He was actually talking about the POSIX AIO APIs, which have a different set 
> of problems making them a waste of time.

I know, I'm referring to the behavior of POSIX AIO.

Perhaps I'm overstating the case with 'subtle and mysterious', then, but the 
POISX 'aiocb' structure still includes an 'aio_sigevent' member which is the 
way to find out about I/O event completion.  If you're writing an application 
that uses AIO, basically all of your logic ends up living in the context of a 
signal handler, and as 

 puts it,

"When signal-catching functions are invoked asynchronously with process 
execution, the behavior of some of the functions defined by this volume of IEEE 
Std 1003.1-2001 is unspecified if they are called from a signal-catching 
function."

Of course, you could try using signalfd(), but that's not in POSIX.

(Or, you could use SIGEV_THREAD, but that would be functionally equivalent to 
running read() in a thread, except much more difficult.)

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support for async read/write

2010-10-20 Thread Glyph Lefkowitz 

On Oct 20, 2010, at 12:31 AM, Jeffrey Yasskin wrote:

> No comment on the rest of your claim, but this is a silly argument.
> The standard says the same thing about at least fcntl.h, signal.h,
> pthread.h, and ucontext.h, which clearly are useful.

It was meant to be tongue-in-cheek :).  Perhaps I should not have assumed that 
everyone else was as familiar with the POSIX documentation; I figured that most 
readers would know that most pages say that.

But, that was the result of a string of many different searches attempting to 
find someone explaining why this was a good idea or why anyone would want to 
use it.  I think in this case, it's accurate.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support for async read/write

2010-10-20 Thread Jeffrey Yasskin 
On Wed, Oct 20, 2010 at 2:55 PM, Glyph Lefkowitz
 wrote:
>
> On Oct 20, 2010, at 12:31 AM, Jeffrey Yasskin wrote:
>
> No comment on the rest of your claim, but this is a silly argument.
> The standard says the same thing about at least fcntl.h, signal.h,
> pthread.h, and ucontext.h, which clearly are useful.
>
> It was meant to be tongue-in-cheek :).  Perhaps I should not have assumed
> that everyone else was as familiar with the POSIX documentation; I figured
> that most readers would know that most pages say that.

Oops, sorry. My joke-detector failed.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distutils2 scripts

2010-10-20 Thread Floris Bruynooghe 
Hi

Sorry for the late response

On 8 October 2010 13:02, Fred Drake  wrote:
> I'm in favor of add a top-level setup module that can be invoked using
> "python -m setup ...".

I'd say +1 for this option.  It has the advantage that it's very clear
which python environment you're installing (or whatever other valid
action) the package into.  For a stand-alone script this might not
always be as clear.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distutils2 scripts

2010-10-20 Thread Michael Foord 

 On 21/10/2010 00:33, Floris Bruynooghe wrote:

Hi

Sorry for the late response

On 8 October 2010 13:02, Fred Drake  wrote:

I'm in favor of add a top-level setup module that can be invoked using
"python -m setup ...".

I'd say +1 for this option.  It has the advantage that it's very clear
which python environment you're installing (or whatever other valid
action) the package into.  For a stand-alone script this might not
always be as clear.

Versioned scripts would also allow that without requiring the extra 
typing...


Michael


Regards
Floris




--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distutils2 scripts

2010-10-20 Thread Ron Adam 



On 10/12/2010 09:59 AM, Barry Warsaw wrote:

On Oct 12, 2010, at 12:24 PM, Greg Ewing wrote:


Giampaolo Rodolà wrote:


If that's the case what would I type in the command prompt in order to
install a module?
"C:\PythonXX\pysetup.exe"?
If so I would strongly miss old "setup.py install".


Another thing bothers me about this. With the current scheme,
if you have multiple Pythons available, it's easy to be sure
that you're installing into the right one, because it's the
one that you use to run setup.py. Whereas if installation is
performed by a different executable, there's a possibility
of them being out of sync.

So I think I'd prefer some scheme involving 'python -m ...'
or some other option to Python itself, rather than a separate
executable.


This is why I suggested that 'setup.sh' (or whatever) take a --python-version
option to select the python executable to use.

Whatever solution is implemented definitely needs to take the
multiple-installed pythons into account.


On Ubuntu, I use python, python2.7, python3.1, python3.2 and that is what I 
type to use that particular version.  The -m option seems to me to be the 
easiest to do and works with all of these.


python2.7 -m setup
python3.2 -m setup

I don't see why that isn't an acceptable solution to this? 

It's not any different than doing ...

python3.2 -m test.regrtest
python3.2 -m pydoc -g
python3.2 -m idlelib.idle
python3.2 -m this
python3.2 -m turtle
python3.2 -m timeit -h
python3.2 -m trace --help
python3.2 -m dis filename.py
python3.2 -m zipfile

There are probably others I don't remember or know about.

The point is, without the handy '-m', you have to know where the file is, 
or set environment variables, or create .bat and/or .sh files, and those 
takes a lot more work.  So why not just embrace it and move on?


Ron






___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distutils2 scripts

2010-10-20 Thread Nick Coghlan 
On Thu, Oct 21, 2010 at 11:01 AM, Ron Adam  wrote:
> There are probably others I don't remember or know about.

"python -m site" is another handy one if you're trying to debug sys.path issues

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com