[issue6142] Distutils doesn't remove .pyc files

[Tarek Ziadé]

Tarek Ziadé  added the comment:

The clean command cleans up temporary files from 'build' command.

Your patch removes files that are not generated by the build command only
but by a normal usage of Python modules.

Why do you need to remove them precisely ?

--
components: +Distutils -Library (Lib)
versions: +Python 2.7, Python 3.1 -Python 2.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5230] pydoc reports misleading failure if target module raises an ImportError

[R. David Murray]

R. David Murray  added the comment:

Thanks.  The unit tests don't pass, though, at least not when I apply
the patch to trunk.  I get three failures.  So the patch isn't correct
as it stands.  'path' is the full module path (test.i_am_not_here in the
case of one of the test failures), but what appears in the error message
is just the name of the module that wasn't found.

Also consider the case where the import is 'import some.nested.module',
and the module that isn't found is 'nested'.  In fact it may be worth
writing an additional test for that case.

Also I'd recommend renaming badimport_module.py pydoc_badimport.py so as
to be parallel to the other pydoc auxiliary test files.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7

[Brodie Rao]

Changes by Brodie Rao :


--
nosy: +brodie

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5230] pydoc reports misleading failure if target module raises an ImportError

[Lucas Prado Melo]

Lucas Prado Melo  added the comment:

Ok.
New patch that passes the unit tests and with a new unit test covering
inexistant nested modules.

--
Added file: http://bugs.python.org/file14140/pydocs.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5230] pydoc reports misleading failure if target module raises an ImportError

[Lucas Prado Melo]

Changes by Lucas Prado Melo :


Removed file: http://bugs.python.org/file14138/pydocs.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6137] Pickle migration: Should pickle map "copy_reg" to "copyreg"?

[Matthias Kievernagel]

Matthias Kievernagel  added the comment:

Applied the patch
  http://bugs.python.org/file14124/compat_pickle.diff
to rev. 73106.
Patch applies fine, 'make test' passes
and it solves my problem.
(which is far from a complete test case though
 - only 5 small pickles)

Thanks,
Matthias Kievernagel

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5230] pydoc reports misleading failure if target module raises an ImportError

[Lucas Prado Melo]

Lucas Prado Melo  added the comment:

by the way, I was not acquainted with this unit test thing... sorry

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6142] Distutils doesn't remove .pyc files

[James]

James  added the comment:

Hi, the patch only removes them if one adds the --pyc option.
I think it is a good idea to have some option or target somewhere to
remove the types of files that can be regenerated because often
developers want to "get them out of the way". Example: I'll be working
on a project in my code directory, and it's nice to be able to do an "$
ls" without seeing extra files lying that clutter up the view. Perhaps
different people want to remove them for different reasons. I remember
searching for "remove .pyc" or something like it and it returned some
hits from other people wanting similar functionality. Thanks for your
time, I hope you include something like this patch in upstream.

_J

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5230] pydoc reports misleading failure if target module raises an ImportError

[R. David Murray]

R. David Murray  added the comment:

No need to apologize, and thank you for taking the time to learn this
stuff.  (Six months ago I didn't know how the python unit test suite
worked either...and I keep learning new things.)

For me your new test fails...and it isn't quite the one I had in mind.
The test fails because with your patch pydoc correctly reports that
there is no documentation for the non-existent temrinal module, while
your test is expecting it to report a missing module.

(This makes me wonder...is the existing behavior of pydoc optimal?  With
this patch in place would it be better to report that there is no such
module rather than that there is no documentation found?  But let's
ignore that issue for the moment since this patch is required even if we
were to change that message.)

The test I had in mind would be a file pydoc_badimport2.py containing:

import test.i_dont_exist.neither_do_i

In that case, your patch will fail, because the error message will
report that "i_dont_exist" can't be found.

It's funny how these seemingly simple things turn out to be not quite so
simple.  Perhaps we could extract the last token (the module name) from
the error message, and only do the "no doc" message if it is equal to
the last element of the path name.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6142] Distutils doesn't remove .pyc files

[R. David Murray]

R. David Murray  added the comment:

It seems to me that this functionality is similar to what a 'distclean'
target would do in a typical makefile.  Don't know if that perspective
helps any :)

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6142] Distutils doesn't remove .pyc files

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I don't think distutils should host whetever functionality useful to
developers. Distutils is for packaging and distributing Python software.

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6156] Error compiling valid regex

[Mykola Kharechko]

Mykola Kharechko  added the comment:

tests for this issue.

--
keywords: +patch
nosy: +crchemist
Added file: http://bugs.python.org/file14141/test_re.py.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5230] pydoc reports misleading failure if target module raises an ImportError

[Lucas Prado Melo]

Lucas Prado Melo  added the comment:

I didn't understand what you mean: what should be shown when pydoc tries
to generate documentation for a module with the bad import 'import
test.i_dont_exist.neither_do_i'?
I am not a native english speaker, so please excuse me if you don't
understand something I've written or the other way around.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6161] HTTPResponse not storing response body

[Guthur]

New submission from Guthur :

HTTPResponse does not store the HTTP response body while it does store 
the response headers, which in my opinion makes it rather useless as a 
HTTP response abstraction object. 

The only way to obtain the response body is to call HTTPResponse.Read
([amt]) and store the body seperately, this must also be carried out 
before the connection is closed, which makes no sense as the server 
serves both HEADERs and BODY together.

I can think of no real reason why this should be the case HTTP already 
provides a method for receiving just the headers with the HEAD request 
type.

Keynotes: HTTPResponse should store the body, if received, as well as 
the headers.

--
components: Library (Lib)
messages: 88648
nosy: Guthur
severity: normal
status: open
title: HTTPResponse not storing response body
type: behavior
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6156] Error compiling valid regex

[Mykola Kharechko]

Mykola Kharechko  added the comment:

patch that fix this

--
Added file: http://bugs.python.org/file14142/sre_compile.py.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6162] What should happen to signals when the main thread dies?

[Mark Florisson]

New submission from Mark Florisson :

As signals are only delivered to the main thread, what should happen
when the main thread dies? Currently, the signal mask is not unset in
any other thread, so when the main thread dies, all signals set in the
mask are simply ignored. Perhaps an other thread could be selected as
the main thread?

The accompanied file demonstrates this behavior.

--
components: Interpreter Core
files: ignore_signals.py
messages: 88650
nosy: eggy
severity: normal
status: open
title: What should happen to signals when the main thread dies?
type: feature request
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 
3.1, Python 3.2
Added file: http://bugs.python.org/file14143/ignore_signals.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6142] Distutils doesn't remove .pyc files

[James]

James  added the comment:

I could agree with R. David Murray, and I think that it's fine that this
be included under a dist clean command.
Ultimately I'm writing an application and I'm trying to use distutils
with it. I'll potentially run a: "$ setup.py build_ext -i" or whatever
it may be, and then I'll want to get rid of all the mess. So I'll want
to run a clean. If that clean won't get rid of .pyc for me in one
command, then i have to run a second shell script to clean my dir,
instead of sticking the two together. Which is why i think a clean --pyc
option is useful (off by default) and which I can easily enable in
setup.cfg with [clean] pyc=1
I think this is harmless. Anyone agree?

thanks!
_J

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6142] Distutils doesn't remove .pyc files

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I'm not sure why you call it a "mess". Generating a pyc file is the
normal way of operating when importing a Python module from source. It's
not just distutils.

And the fact that it's "harmless" does not justify adding a distutils
option for something which doesn't seem to have anything to do with
distutils...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Clay McClure]

Clay McClure  added the comment:

Since Python 2.7 and 3.1 have not yet shipped, I hope it's not too late 
to
continue this discussion. I have no vested interest in either ipaddr or
netaddr, but I am interested in seeing a well-designed and usable IP 
address
library included in the stdlib.

>From reading the comments in this issue, it seems most of the discussion
focused on netaddr's API. There seems to have been little discussion 
about
the merits of ipaddr's API, which is unfortunate given that ipaddr is 
the
library being included in the stdlib. There was some technical 
discussion on
the ipaddr and netaddr lists, but it amounted to each developer 
defending his
library, and neither party seemed willing to compromise on key design
decisions. At the end of the reconciliation period, ipaddr looks much 
the
same as it did before, albeit with prettier indentation.

When looking for an IP address library for use in a network scanning and
discovery application I wrote last year, I decided against ipaddr 
because of
its conflation of address and network -- it seems strange to me to have 
one
class modeling both concepts.

After reading the technical discussion on the ipaddr and netaddr lists, 
it is
clear to me that ipaddr's designers have a somewhat limited 
understanding of
IP addressing, and have not designed an API that articulates IP concepts
particularly well. For example, see pmoody's earlier comments in this 
ticket:

> all addresses have a subnet, even if its an implied /32

This is not only incorrect, but it demonstrates a deep misunderstanding 
of
how IP works. IP addresses most certainly do not have a "subnet", or a 
mask
of any sort. An IPv4 address is simply a 32-bit number.

IPv4 *networks* have masks, of course, hence the name "netmask". These
network masks are used by the routing process to lookup the next hop (or
directly connected network) for an IP datagram by matching the 
datagram's
destination address against the networks and masks defined in the 
routing
table.

> specifying a network as ("1.1.1.0", "1.1.1.255") seems a lot more
> off-putting than "1.1.1.0/24".

Since networks are commonly represented in at least three forms, the API
should support at least these:

CIDR/prefix notation: "192.168.1.0/24"
address+mask notation: "192.168.1.0/255.255.255.0"
range notation: "192.168.1.0-192.168.1.255"

> I guess I don't see the utility in an address range of .1 - .22 
> (or something arbitrary, something which doesn't fall on a power-of-2
> boundary); when dealing with ranges of addresses, i've always only 
> wanted to/needed to manipulate sub-networks of addresses.

This statement demonstrates an extremely narrow view of the problem 
domain.
Access lists and DHCP pools are two common examples of where arbitrary
address ranges are useful.

At least three concepts deserve first-class treatment in any meaningful 
IP
address library:

* addresses
* ranges of addresses
* networks

To conflate these is a mistake.

My hope is that now that a library has been selected, it can be improved 
before Python 2.7 and 3.1 ship. Now is the best time to make
backwards-incompatible API changes; once ipaddr ships with the stdlib, 
we're
stuck with it. If it remains as-is, it will be deadweight for those app
developers like myself who prefer an API that more accurately reflects 
the
problem domain.

To this end, now that ipaddr is moving to Python stdlib, will Google's
contributor license agreement restriction be lifted? I would like to
contribute, but have not been able to secure a corporate CLA from my
employer.

Cheers,

Clay

--
nosy: +claymation

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6161] httplib: HTTPResponse not storing response body

[Guthur]

Changes by Guthur :


--
title: HTTPResponse not storing response body -> httplib: HTTPResponse not 
storing response body

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Gregory P. Smith]

Gregory P. Smith  added the comment:

On Mon, Jun 1, 2009 at 9:39 AM, Clay McClure  wrote:
>
> Since Python 2.7 and 3.1 have not yet shipped, I hope it's not too late
> to continue this discussion. I have no vested interest in either ipaddr or
> netaddr, but I am interested in seeing a well-designed and usable IP
> address library included in the stdlib.

Python 3.1 is as good as shipped.  It is in the release candidate
stage which means no code changes other than bug fixes can go in.

Improvements will have to wait for 2.7 and 3.2.  In the mean time I
suggest writing up improvements as either subclasses of the existing
ipaddr module (so that they can be used both with this standalone
project and with the version shipped in python 3.1).

>> specifying a network as ("1.1.1.0", "1.1.1.255") seems a lot more
>> off-putting than "1.1.1.0/24".
>
> Since networks are commonly represented in at least three forms, the API
> should support at least these:
>
> CIDR/prefix notation: "192.168.1.0/24"
> address+mask notation: "192.168.1.0/255.255.255.0"
> range notation: "192.168.1.0-192.168.1.255"

I think range notation parsing could be implemented pretty easily.

> Access lists and DHCP pools are two common examples of where arbitrary
> address ranges are useful.
>
> At least three concepts deserve first-class treatment in any meaningful
> IP address library:
>
> * addresses
> * ranges of addresses
> * networks
>
> To conflate these is a mistake.
>
> My hope is that now that a library has been selected, it can be improved
> before Python 2.7 and 3.1 ship. Now is the best time to make
> backwards-incompatible API changes; once ipaddr ships with the stdlib,
> we're stuck with it. If it remains as-is, it will be deadweight for those app
> developers like myself who prefer an API that more accurately reflects
> the problem domain.

Too late for 3.1.  But I see no reason for the existing API to be
considered bad.  There is always room for improvement.  I believe you
could add support for network address ranges on top of it without too
much difficulty.

Subclass the existing classes and inherit from a mixin that keeps
track of a start and end of range and extends the 'in' operator to
check if the comparison address is >= and <= the start and end
addresses.

> To this end, now that ipaddr is moving to Python stdlib, will Google's
> contributor license agreement restriction be lifted? I would like to
> contribute, but have not been able to secure a corporate CLA from my
> employer.

You can sign a Python Software Foundation contributor agreement
instead.  http://www.python.org/psf/contrib/contrib-form/  We've been
a bit relaxed on requiring these from people at times but it is a good
thing to do for Python's sake.

No Google CLA will ever be required to make changes to anything in the
python project itself.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> My hope is that now that a library has been selected, it can be improved 
> before Python 2.7 and 3.1 ship.

That is fairly unlikely. The 3.1 release candidate has been produced,
so the only options possible at this point are to either go ahead with
what is in the code, or withdraw the library from 3.1 if it can be
demonstrated to have severe flaws.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6161] httplib: HTTPResponse not storing response body

[Mykola Kharechko]

Mykola Kharechko  added the comment:

HTTPResponse can't store body because it can be huge (some film or
something else).

--
nosy: +crchemist

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6163] [HP-UX] ld: Unrecognized argument: +s -L

[Sridhar Ratnakumar]

New submission from Sridhar Ratnakumar :

this is also applicable to 3.1 (albeit the source is slightly changed)

Return a *list* of options otherwise these may be improperly interpreted as
one option with an embedded space. On /usr/bin/ld on a HP-UX/IA64 box this
results in:
ld: Unrecognized argument: +s -L

--
assignee: tarek
components: Distutils
files: distutils_hpux_libdir_option.patch
keywords: patch
messages: 88657
nosy: srid, tarek, trentm
severity: normal
status: open
title: [HP-UX] ld: Unrecognized argument: +s -L
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14144/distutils_hpux_libdir_option.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used for 'runtime_library_dirs'

[Sridhar Ratnakumar]

New submission from Sridhar Ratnakumar :

This is being successfully used in ActivePython.

--
assignee: tarek
components: Distutils
files: distutils_aix_blibpath.patch
keywords: patch
messages: 88658
nosy: srid, tarek, trentm
severity: normal
status: open
title: [AIX] Patch to correct the AIX C/C++ linker argument used for 
'runtime_library_dirs'
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14145/distutils_aix_blibpath.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6165] strftime incorrectly processes DST flag when passed time touples

[Jonathan]

New submission from Jonathan :

>>> import time
>>> time.strftime("%FT%T%z")
'2009-06-01T18:35:42+0100'
>>> # Expect to see +0100
>>> time.strftime("%FT%T%z",time.localtime())
'2009-06-01T18:35:42+'
>>> time.strftime("%FT%T%Z",time.localtime())
'2009-06-01T18:35:42BST'
>>> made_up_time = list(time.localtime())
>>> made_up_time
[2009, 6, 1, 18, 35, 48, 0, 152, 1]
>>> made_up_time[1] = 2
>>> made_up_time=tuple(made_up_time)
>>> time.strftime("%FT%T%z",made_up_time)
'2009-02-01T18:35:48+'
>>> # Expect to see GMT or UTC, whatever strftime wants to call it.
>>> time.strftime("%FT%T%Z",made_up_time)
'2009-02-01T18:35:48BST'
>>>

--
components: Extension Modules
messages: 88659
nosy: jonathan.cervidae
severity: normal
status: open
title: strftime incorrectly processes DST flag when passed time touples
type: behavior
versions: Python 2.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6165] strftime incorrectly processes DST flag when passed time touples

[Jonathan]

Jonathan  added the comment:

Actually, I didn't change the DST flag in the second test, the second
commented bug is invalid, only the first one is correct.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6165] strftime incorrectly processes DST flag when passed time touples

[Jonathan]

Jonathan  added the comment:

kludged_zone = ("+" if time.altzone < 0 else '-') +
time.strftime("%H%M",time.gmtime(abs(time.altzone)))
time_zone_format_string = time_zone_format.replace("%z", kludged_zone)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6156] Error compiling valid regex

[Georg Brandl]

Georg Brandl  added the comment:

Just taking out the "raise" seems questionable to me; are you sure there
are no valid errors that can be caught there?

--
nosy: +georg.brandl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6161] httplib: HTTPResponse not storing response body

[Guthur]

Guthur  added the comment:

But it must be somewhere, you don't make a seperate request to the 
server for the body, you just make the single HTTP request and the 
server serves that request.

Also this is surely aimed at developers, we can make the decision 
whether or not it is too large, and simply to, by making a HEAD request 
and checking the content-length header, and if its not available then 
don't continue with the request if we chose to take that action.

The point is that with out a body its not a HTTP response.

Admittedly some sort of streaming to file facility might be needed for 
the large requests, and that may require a significant effort to add.

Even if this can not be changed I think it should be clearly stated in 
the documentation that the request body needs to be explicitly read; I 
was trying to access it after making my request but of course it wasn't 
available, but the headers were and all status pointed to the request 
being served, which was rather confusing.

Thanks for the reply

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6166] encoding error for 'setup.py --author' when read via subprocess pipe

[Sridhar Ratnakumar]

New submission from Sridhar Ratnakumar :

I ran 'python setup.py --author' for the pypi package "ll-orasql-0.6"
(whose author name has non-ascii characters) under subprocess.Popen and
this is what I get:

Traceback (most recent call last):
  File "/home/sridharr/as/pypm/bin/python", line 39, in 
execfile(sys.argv[0])
  File "setup.py", line 50, in 
package_dir={"ll": ""}
  File "/opt/ActivePython-2.6/lib/python2.6/distutils/core.py", line
138, in setup
ok = dist.parse_command_line()
  File "/opt/ActivePython-2.6/lib/python2.6/distutils/dist.py", line
456, in parse_command_line
if self.handle_display_options(option_order):
  File "/opt/ActivePython-2.6/lib/python2.6/distutils/dist.py", line
704, in handle_display_options
print value
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in
position 8: ordinal not in range(128)

When ran under the console, this exception is not seen. Otherwise, the
return code is 1 and nothing (apart from the above exception) is printed.

How to reproduce?
=

Download `ll-orasql-0.6` from PyPI and run the following in the Python
shell:

>>> subprocess.Popen('python setup.py --author', stdout=subprocess.PIPE,
shell=True).stdout.read()

--
assignee: tarek
components: Distutils
messages: 88664
nosy: srid, tarek
severity: normal
status: open
title: encoding error for 'setup.py --author' when read via subprocess pipe
type: behavior
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6142] Distutils doesn't remove .pyc files

[James]

James  added the comment:

ps: included is a platform independent version of the code, so that it
doesn't depend on os.system() specific commands.

HTH,
_J

--
Added file: http://bugs.python.org/file14146/clean.py.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6142] Distutils doesn't remove .pyc files

[James]

James  added the comment:

Antoine: Okay sorry not a mess then.
I just figure that if i'm using the distutils tool for doing all the fun
things to my local source directory that I potentially used to do with
say a makefile, then would it not be beneficial to have a useful
-option- (as included in the patch). It won't affect any previous
distutils setups, and can only benefit future users. Why not?

_J

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6156] Error compiling valid regex

[Mykola Kharechko]

Mykola Kharechko  added the comment:

> are you sure there are no valid errors that can be caught there?
Sorry, No. See
http://svn.python.org/view/python/trunk/Lib/sre_compile.py?r1=17949&r2=17948&pathrev=17949
and http://osdir.com/ml/python.bugs/2000-10/msg00010.html links.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6142] Distutils doesn't remove .pyc files

[Tarek Ziadé]

Tarek Ziadé  added the comment:

The only reason I would see to clean .pyc file in distutils clean
command is if the build command (or any other command) would generate
them in the source tree, which is not the case.

That said, build_ext -i *does* create .so files in the source tree, so
we should provide a way to remove them I think.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue967161] pty.spawn() enhancements

[Fergus Henderson]

Fergus Henderson  added the comment:

#1 is a duplicate of issue 2489 ,
which has a patch attached.

According to the other discussion in this thread, #2 was a misunderstanding.

So I think we could close this bug as a duplicate.

--
nosy: +fergushenderson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6167] Tkinter.Scrollbar: the activate method needs to return a value, and set should take only two args

[Guilherme Polo]

New submission from Guilherme Polo :

Hi,

I've noticed some minor problems in Tkinter.Scrollbar that would be good
to be addressed. The activate method never returns a value and it also
doesn't accept to be called without an element -- which is accepted by
tcl. When an element is not especified, the current active element
should be returned. It's signature is also a bit strange, I don't see
why it has a parameter named "index" while it never takes an index but
an element.

The second problem is about the set method. It accepts any amount of
arguments, but it only needs to accept two. Passing a tuple in the form
of (number, number) to it isn't accepted, so I don't see much reason to
continue with an *args there.

--
components: Tkinter
files: Scrollbar_fixes.diff
keywords: patch
messages: 88670
nosy: gpolo
severity: normal
status: open
title: Tkinter.Scrollbar: the activate method needs to return a value, and set 
should take only two args
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14147/Scrollbar_fixes.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2489] Patch for bugs in pty.py

[Petr Splichal]

Changes by Petr Splichal :


--
nosy: +psss

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5230] pydoc reports misleading failure if target module raises an ImportError

[R. David Murray]

R. David Murray  added the comment:

It should generate:

  problem in pydoc_badimport2 - : No
module named i_dont_exist"

If you'd like I can do the final fixup and apply the patch.  I'm happy
to let you get it working if you want, though, and I appreciate the work
you've done so far either way.

--
stage: test needed -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Clay McClure]

Clay McClure  added the comment:

On Mon, Jun 1, 2009 at 1:09 PM, Martin v. Löwis  wrote:

>> My hope is that now that a library has been selected, it can be improved
>> before Python 2.7 and 3.1 ship.
>
> That is fairly unlikely. The 3.1 release candidate has been produced,
> so the only options possible at this point are to either go ahead with
> what is in the code, or withdraw the library from 3.1 if it can be
> demonstrated to have severe flaws.

False
>>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
True

ipaddr makes no distinction between two fundamentally different
concepts -- to my mind, that is a serious flaw.

ipaddr has many other quirks that, while not technically flaws, are
design warts that deserve to be fixed before its target audience is
amplified by its inclusion in the stdlib.

To those arguing for ipaddr's inclusion in the stdlib, how many of you
will actually use ipaddr to develop software? As an actual developer
of network scanning and discovery software, I can tell you that I
would rather roll my own library than use ipaddr as it exists today.

Clay

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Clay McClure]

Clay McClure  added the comment:

Strangely, the leading line of my last response was eaten by the bug 
tracker. It read:

>>> 1 == (1,)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6166] encoding error for 'setup.py --author' when read via subprocess pipe

[Tarek Ziadé]

Tarek Ziadé  added the comment:

This is not a bug in distutils, but how print works when executed
through subprocess. 

here's a demo:

Create a file called "test.py" with:

  # -*- coding: utf8 -*-
  print u''

Now another one called "test2.py" with:

  import subprocess

  subprocess.Popen('python test.py', stdout=subprocess.PIPE,
shell=True).stdout.read()

Now launch test2:

  $ python test2.py 
  Traceback (most recent call last):
  File "test.py", line 2, in 
print u''
  UnicodeEncodeError: 'ascii' codec can't encode characters in position 
0-3: ordinal not in range(128)

I don't know about the internals of print, and I am not sure this is a
bug, so I'll put Marc-André in the loop.

--
assignee: tarek -> 
components: +Unicode -Distutils
nosy: +lemburg

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[pmoody]

pmoody  added the comment:

On Mon, Jun 1, 2009 at 1:33 PM, Clay McClure  wrote:
>
> Clay McClure  added the comment:
>
> On Mon, Jun 1, 2009 at 1:09 PM, Martin v. Löwis  
> wrote:
>
>>> My hope is that now that a library has been selected, it can be improved
>>> before Python 2.7 and 3.1 ship.
>>
>> That is fairly unlikely. The 3.1 release candidate has been produced,
>> so the only options possible at this point are to either go ahead with
>> what is in the code, or withdraw the library from 3.1 if it can be
>> demonstrated to have severe flaws.
>
> False
 ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
> True
>
> ipaddr makes no distinction between two fundamentally different
> concepts -- to my mind, that is a serious flaw.

I don't see these a fundamentally different, I guess.  can you
demonstrate how this equivalency makes ipaddr unusable?

> ipaddr has many other quirks that, while not technically flaws, are
> design warts that deserve to be fixed before its target audience is
> amplified by its inclusion in the stdlib.

I haven't seen any new issues on code.google.com (and I haven't heard
of any being reported on the python bugtracker), so since you're using
this thread to report issues, can you elaborate?

> To those arguing for ipaddr's inclusion in the stdlib, how many of you
> will actually use ipaddr to develop software? As an actual developer
> of network scanning and discovery software, I can tell you that I
> would rather roll my own library than use ipaddr as it exists today.

have used it to develop software and will continue to use it to
develop software.

Cheers,
/peter

> Clay
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> ipaddr makes no distinction between two fundamentally different
> concepts -- to my mind, that is a serious flaw.

Do you have an application in mind where this lack of distinction
would prevent writing the application in a straight-forward way?
IOW, could you do something if they were distinct that you can't
do because they are not?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6168] Missing Shell menu in Linux IDLE

[Jason Gervich]

New submission from Jason Gervich :

The Shell menu is missing from the menu bar in the Edit Window of Ubuntu
Linux IDLE. It is described in the help but is not implemented. It is
there is the various windows versions I've seen.

Why is this missing and will it be fixed?

--
components: IDLE
messages: 88677
nosy: sirgimp
severity: normal
status: open
title: Missing Shell menu in Linux IDLE
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[R. David Murray]

R. David Murray  added the comment:

> >>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
> True

As a network engineer I don't see any inherent problem with that equality.
In fact I make use of that conceptual equality on a regular basis.

Further, if you were to add a specifically 'address-without-netmask'
type, the above equality would still be true, because then the above
would be comparing two addresses-with-netmasks and you would want to
apply the hostmask to a bare address for convenience.  To get inequality,
you'd be comparing two different object types...which comparison would
be False by default.

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5735] Segfault when loading not recompiled module

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Fixed with r73116

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6109] IDLE rendering issue with oriental characters on OSX

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3022] mailbox module, two small fixes

[R. David Murray]

R. David Murray  added the comment:

The iteritems problem was fixed in r71046 from issue2625.  The tests in
mailbox.patch all pass at this point, though it doesn't look like the
line with blanks issue has been addressed in the code.

--
nosy: +r.david.murray
versions: +Python 2.7, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6168] Missing Shell menu in Linux IDLE

[Roger Serwy]

Roger Serwy  added the comment:

Running IDLE from the Applications menu under Ubuntu will not have the
Shell menu. If you bring up a terminal and enter "idle", you will have
the Shell menu.

IDLE, when selected from the Application menu, is being run with the
"-n" command line by default in Ubuntu. You can remove this option by
editing the menu item for IDLE.

--
nosy: +serwy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4547] Long jumps with frame_setlineno

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Fixed with r73114 (trunk), r73117 (py3k), r73119 (2.6) and r73120 (3.0)

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6132] Implement the GIL with critical sections in Windows

[Mark Hammond]

Changes by Mark Hammond :


--
nosy: +mhammond

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2489] Patch for bugs in pty.py

[Fergus Henderson]

Fergus Henderson  added the comment:

The spawn change (the last hunk of the original patch) is a bug fix, not
an RFE.
It has two parts that fix two bugs:
  (1) a coding bug: spawn() would not wait for the invoked process to
finish.  This is fixed by the line that adds the call to os.waitpid().
  (2) a design bug: because previously spawn() didn't return a value,
there is no way to tell if the invoked process failed.  This is fixed by
the "return status" line.

Now I guess you can argue that (2) is an RFE.
But (1) is just a bug fix, not an RFE, IMHO.

Those are both separate from the other bug fixed in the patch:
  (3) Another coding bug: the bug in the _copy() loop that caused
it to spin using 100% CPU rather than blocking

It's a little tricky to write a test of the _copy() loop bug, for
several reasons.
(a) There currently isn't any test for pty.spawn, apparently since
"Cannot do extensive 'do or fail' testing because pty code is not too
portable."
(b) Also, for this bug the symptom is just that the code spins (using
100% CPU, if available) rather than blocking.  It's difficult to detect
that situation using portable code.

I can maybe figure out how deal with (a), but I'm not sure how to
address (b), especially since I don't know the intended portability goals.

I will split the patch up into two patches, one of which addresses
(1)+(2), and the other of which addresses (3).

I have addressed Guilherme Polo's suggestion about using "if not data".

--
Added file: http://bugs.python.org/file14148/pty.py.patch3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2489] Patch for bugs in pty.py

[Fergus Henderson]

Changes by Fergus Henderson :


Added file: http://bugs.python.org/file14149/pty.py.patch2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6137] Pickle migration: Should pickle map "copy_reg" to "copyreg"?

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Some comments on the patch:
- I don't understand why you create a static "twotuple" object rather
than simply using Py_BuildValue("(OO)", ...). Mutating tuples is bad.
- I don't think you need to call PyDict_Contains() before
PyDict_GetItem(). The latter will simply return NULL if the key isn't found.
- You should check whether the item fetched from the dictionary has the
right datatype (tuple for name_mapping, str for import_mapping). Anyone
can change (monkeypatch) _pickle_compat and make the interpreter crash.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6137] Pickle migration: Should pickle map "copy_reg" to "copyreg"?

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
components: +Library (Lib) -None
priority:  -> critical
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6169] Important comparison bug in ipaddr

[Michael Shields]

New submission from Michael Shields :

The open source version of ipaddr had an important comparison bug in 
which it was possible for x > y and x < y.  The fix for this should be 
applied to the Python standard library version as well.

http://code.google.com/p/ipaddr-py/source/detail?r=77

--
components: Library (Lib)
messages: 88685
nosy: shields
severity: normal
status: open
title: Important comparison bug in ipaddr
type: behavior
versions: Python 2.7, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Clay McClure]

Clay McClure  added the comment:

On Mon, Jun 1, 2009 at 5:02 PM, R. David Murray  wrote:

>> >>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
>> True
>
> As a network engineer I don't see any inherent problem with that equality.
> In fact I make use of that conceptual equality on a regular basis.

For an example of why 192.168.1.1 != 192.168.1.1/32, look no further
than ifconfig:

# ifconfig en0 192.168.1.1/32
# ifconfig en0
en0: flags=8863 mtu 1500
inet 192.168.1.1 netmask 0x broadcast 192.168.1.1
...

# ifconfig en0 192.168.1.1
# ifconfig en0
en0: flags=8863 mtu 1500
inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
...

Can you provide an example of when 192.168.1.1 does in fact equal
192.168.1.1/32?

> Further, if you were to add a specifically 'address-without-netmask'
> type, the above equality would still be true, because then the above
> would be comparing two addresses-with-netmasks and you would want to
> apply the hostmask to a bare address for convenience.  To get inequality,
> you'd be comparing two different object types...which comparison would
> be False by default.

I don't follow. Assuming hypothetical Address and Network classes, as
accurately models the problem domain, we would have:

False

That seems to me the correct behavior, since an address is in fact not
the same thing as a network.

Clay

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6161] httplib: HTTPResponse not storing response body

[Guthur]

Changes by Guthur :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6168] Missing Shell menu in Linux IDLE

[Jason Gervich]

Jason Gervich  added the comment:

Thank you. I tried it from the command line and you are right. IDLE runs
with the Shell menu.

1.Do you know why this is being done in Ubuntu? That is, why are they
setting up the menu this way?

2. Is it a bug or a "feature?" Should be reported a an Ubuntu bug?

How do I edit the IDLE menu item?

Thanks again, 

Roger

On Mon, 2009-06-01 at 22:09 +, Roger Serwy wrote:

> Roger Serwy  added the comment:
> 
> Running IDLE from the Applications menu under Ubuntu will not have the
> Shell menu. If you bring up a terminal and enter "idle", you will have
> the Shell menu.
> 
> IDLE, when selected from the Application menu, is being run with the
> "-n" command line by default in Ubuntu. You can remove this option by
> editing the menu item for IDLE.
> 
> --
> nosy: +serwy
> 
> ___
> Python tracker 
> 
> ___

--
Added file: http://bugs.python.org/file14150/unnamed

___
Python tracker 

___


  
  


Thank you. I tried it from the command line and you are right. IDLE runs with 
the Shell menu.

1.Do you know why this is being done in Ubuntu? That is, why are they setting 
up the menu this way?

2. Is it a bug or a "feature?" Should be reported a an Ubuntu bug?

How do I edit the IDLE menu item?

Thanks again, 

Roger

On Mon, 2009-06-01 at 22:09 +, Roger Serwy wrote:


Roger Serwy roger.se...@gmail.com> added the 
comment:

Running IDLE from the Applications menu under Ubuntu will not have the
Shell menu. If you bring up a terminal and enter "idle", you will have
the Shell menu.

IDLE, when selected from the Application menu, is being run with the
"-n" command line by default in Ubuntu. You can remove this option by
editing the menu item for IDLE.

--
nosy: +serwy

___
Python tracker rep...@bugs.python.org>
http://bugs.python.org/issue6168>
___




___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[pmoody]

pmoody  added the comment:

On Mon, Jun 1, 2009 at 4:41 PM, Clay McClure  wrote:
>
> Clay McClure  added the comment:
>
> On Mon, Jun 1, 2009 at 5:02 PM, R. David Murray  
> wrote:
>
>>> >>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
>>> True
>>
>> As a network engineer I don't see any inherent problem with that equality.
>> In fact I make use of that conceptual equality on a regular basis.
>
> For an example of why 192.168.1.1 != 192.168.1.1/32, look no further
> than ifconfig:
>
> # ifconfig en0 192.168.1.1/32
> # ifconfig en0
> en0: flags=8863 mtu 1500
>        inet 192.168.1.1 netmask 0x broadcast 192.168.1.1
>        ...
>
> # ifconfig en0 192.168.1.1
> # ifconfig en0
> en0: flags=8863 mtu 1500
>        inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
>        ...
>
> Can you provide an example of when 192.168.1.1 does in fact equal
> 192.168.1.1/32?

what this shows is that your copy of darwin defaults to a /24
prefixlen; ipaddr assumes a /32 prefixlen.  I don't see anything
particularly *more* intuitive with darwin, but in any event, it seems
to provide support for assuming a prefixlen when none is supplied.

>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links

[Sridhar Ratnakumar]

New submission from Sridhar Ratnakumar :

$ make frameworkinstall DESTDIR=[...]/py3_1rc1-macosx-apy31-rrun/image
running install_scripts
[...]
copying build/scripts-3.1/2to3 ->
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin
error:
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3:
Too many levels of symbolic links
make: *** [sharedinstall] Error 1


!
!

this appears to be a regression in 3.1rc1 (used to work with 3.1b2).
need to investigate further. will update this bug if I find anything
useful. (quick observation .. 'install_scripts' seem to be run twice)

--
assignee: tarek
components: Distutils
files: apy31-anole.log
messages: 88689
nosy: srid, tarek
severity: normal
status: open
title: Mac 'make frameworkinstall' error: 
[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file14151/apy31-anole.log

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links

[Sridhar Ratnakumar]

Changes by Sridhar Ratnakumar :


Removed file: http://bugs.python.org/file14151/apy31-anole.log

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

To explain further, the following section of script is run *twice* .. 
and thus explains the error "Too many levels of symbolic links"

mv 
"[...]/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3" 
"[...]]/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3-3.1"
ln -sf 
"[...]/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3-3.1" 
"[...]/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3"

The entire log file is here: http://double.activestate.com/t/apy31-anole.log

On 09-06-01 04:46 PM, Sridhar Ratnakumar wrote:
> >
> > make: [image_python] PythonLauncher build attempt 1 of 2 (see bug 44709)
> > make: [image_python] running 'cd build/py3_1rc1-macosx-apy31-rrun/python
> > &&  make frameworkinstallapps
> >
DESTDIR=/Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image'
> > [...]
> > make: [image_python] running 'cd build/py3_1rc1-macosx-apy31-rrun/python
> > &&  make frameworkinstall frameworkinstallextras
> >
DESTDIR=/Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image'
> > [...]
> >
> >
> > Note: the second make attempt uses 'frameworkinstallextras' as the extra
> > argument.
> >
> > .
> > .
> >
> > This appears to be breaking 3.1rc1 on Mac ("Too many levels of symbolic
> > links"):
> >
> > running install_scripts
> > [...]
> > copying build/scripts-3.1/2to3 ->
> >
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin
> > error:
> >
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3:
> > Too many levels of symbolic links
> > make: *** [sharedinstall] Error 1

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

Tarek, are you perchance aware of any change that went into distutils
since the last beta release that could have influenced the make behavior?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[R. David Murray]

R. David Murray  added the comment:

In pre-CIDR days, assuming a prefixlen of 24 for a 192.168.x.x address
made sense.  Nowadays it is better not to make that assumption.  So I
find ipaddr's default of 32 to be "safer" than using a class based default.

The larger point, however, is that there _is_ a mask associated with the
address in ifconfig.  There _must_ be one.  So that is not an example
that shows that a separate address class is useful.

As for the == thing, I agreed with you that address compared to network,
if you had an address class, would yield false.  My point was that

HypotheticalNetworkClass('192.168.1.1') ==
HypotheticalNetworkClass('192.168.1.1/32')

should yield True, because, as I said above, in a CIDR world using a
default of a hostmask for an otherwise unadorned address makes the most
sense.

As for an example of when the equivalence is useful, it is useful every
time I set up an access rule or route that applies to a single host. 
Otherwise, I _must_ give a specific netmask, because in real life the
classfull default is often not the correct netmask.  Most networking
software that I've dealt with requires explicit netmasks (often with a
shorthand to specify an ip/hostmask pair).  It is true that when a
netmask isn't required it generally defaults to the classful netmask,
but having such a default is becoming more rare with time, in my
experience (because of CIDR).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links

[Tarek Ziadé]

Tarek Ziadé  added the comment:

No, but I am running frameworkinstall right now under Mac to see if I
can reproduce the problem

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

To help with the repro, may I suggest running the following in the same
order:

   make frameworkinstallframework DESTDIR=image
   make frameworkinstallapps DESTDIR=image
   make frameworkinstall frameworkinstallextras DESTDIR=image

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6169] Important comparison bug in ipaddr

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1704474] test_optparse.py mod. for jython

[Greg Ward]

Greg Ward  added the comment:

I just took a look at the original patch uploaded by drtimcouper.  IMHO
it would be cleaner and simpler to modify optparse.py so that it behaves
as consistently as possible under Jython and CPython.  For example,
optparse should catch the ValueError raised when a user supplies a bad
integer input and raise a new exception with a consistent error message.
 That sort of thing.

drtimcouper: if you're still out there and reading this, would you mind
submitting a new patch?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1704474] optparse tests fail under Jython

[Greg Ward]

Changes by Greg Ward :


--
components: +Library (Lib) -Tests
title: test_optparse.py mod. for jython -> optparse tests fail under Jython

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links

[Tarek Ziadé]

Tarek Ziadé  added the comment:

I'll try tomorrow asap (sorry it's 2:30 am now here)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

also related to issue 5756

--
components: +2to3 (2.x to 3.0 conversion tool), Build

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1704474] optparse tests fail under Jython

[Philip Jenvey]

Philip Jenvey  added the comment:

This looks like it was against Jython 2.2? Jython 2.5 passes 2.5's 
test_optparse with only fixing __builtins__ and disabling the weakref test

So uses of __builtins__ should should be importing __builtin__ and use 
that instead. sys.platform.startswith('java') should be 
test_support.is_jython instead. And on 2.6/3.2 you can now decorate 
test_refleak with @test_support.impl_check('Relies on sys.getrefcount', 
cpython=True) to skip it

--
nosy: +pjenvey

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6171] Class Browser selection in Ubuntu

[Jason Gervich]

New submission from Jason Gervich :

When sing IDLE in Ubuntu (Jaunty) if you open the Class Browser and
double click on a class or function name, the corresponding section is
highlighted in the code in the Editor Window. 

If you again double click on another class or function name, the new
code section should be highlighted in the Editor Window but isn't.
Nothing happens. You have to first close the Class Browser window,
reopen it and double click on another name to select it the Editor Window.

In the Windows versions, successive double clicking will highlight the
desired selection in the Class Browser window.

--
messages: 88699
nosy: sirgimp
severity: normal
status: open
title: Class Browser selection in Ubuntu
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Clay McClure]

Clay McClure  added the comment:

On Mon, Jun 1, 2009 at 4:54 PM, Martin v. Löwis  wrote:

> Do you have an application in mind where this lack of distinction
> would prevent writing the application in a straight-forward way?
> IOW, could you do something if they were distinct that you can't
> do because they are not?

Consider applications that use ipaddr.IPv4 objects to configure
network interfaces:

ifconfig: 255.255.255.0/32: bad value

That's because ipaddr wrongly appends a prefix length to all
ipaddr.IPv4 objects, even those representing addresses, which do not
have prefix lengths.

Consider applications that need to validate addresses (or networks,
but not both) supplied as user input:

address = ipaddr.IP(input)

if isinstance(address, ipaddr.IPv4):
if address.prefixlen != 32:
raise TypeError("Expecting IP address, not network")
elif isinstance(address, ipaddr.IPv6):
if address.prefixlen != 128:
raise TypeError("Expecting IP address, not network")

Given its myriad quirks, it is really rather surprising that ipaddr is
being considered for inclusion in the Python stdlib.

Clay

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6172] 'make framework...' fails on Mac ([...]/bin/pythonw3.1: No such file or directory)

[Sridhar Ratnakumar]

New submission from Sridhar Ratnakumar :

This happens with 3.1rc1

$ make frameworkinstallframework DESTDIR=image1
[...]
cc  -o pythonw ./Tools/pythonw.c \
   
-DPYTHONWEXECUTABLE='"/Library/Frameworks/Python.framework/Versions/3.1/Resources/Python.app/Contents/MacOS/Python"'
/usr/bin/install -c -s pythonw
"image1/Library/Frameworks/Python.framework/Versions/3.1/bin/pythonw3.1"
install:
image1/Library/Frameworks/Python.framework/Versions/3.1/bin/pythonw3.1:
No such file or directory
make[1]: *** [install_pythonw] Error 71
make: *** [frameworkinstallapps] Error 2
$

--
components: Build, Macintosh
messages: 88701
nosy: srid
severity: normal
status: open
title: 'make framework...' fails on Mac ([...]/bin/pythonw3.1: No such file or 
directory)
versions: Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6168] Missing Shell menu in Linux IDLE

[Roger Serwy]

Roger Serwy  added the comment:

You'll need to modify the IDLE menu item to remove the "-n" using
Ubuntu's menu modification tool, usually found under System->Preferences.

Presently, using a subprocess only allows for one instance of IDLE
running on a machine, whereas running with no subprocess allows for many
instances of IDLE. This architecture is by design.

Check out Ubuntu bug 338379.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[pmoody]

pmoody  added the comment:

On Mon, Jun 1, 2009 at 5:47 PM, Clay McClure  wrote:
>
> Clay McClure  added the comment:
>
> On Mon, Jun 1, 2009 at 4:54 PM, Martin v. Löwis  
> wrote:
>
>> Do you have an application in mind where this lack of distinction
>> would prevent writing the application in a straight-forward way?
>> IOW, could you do something if they were distinct that you can't
>> do because they are not?
>
> Consider applications that use ipaddr.IPv4 objects to configure
> network interfaces:
>
> ifconfig: 255.255.255.0/32: bad value
>
> That's because ipaddr wrongly appends a prefix length to all
> ipaddr.IPv4 objects, even those representing addresses, which do not
> have prefix lengths.

I'm not sure what you're trying to do here, can you elaborate?

> Consider applications that need to validate addresses (or networks,
> but not both) supplied as user input:
>
> address = ipaddr.IP(input)
>
> if isinstance(address, ipaddr.IPv4):
>    if address.prefixlen != 32:
>        raise TypeError("Expecting IP address, not network")
> elif isinstance(address, ipaddr.IPv6):
>    if address.prefixlen != 128:
>        raise TypeError("Expecting IP address, not network")

i'm not sure what's onerous about this code.  you're missing a
try/except around ipaddr.IP(), but otherwise it seems fine.

> Given its myriad quirks, it is really rather surprising that ipaddr is
> being considered for inclusion in the Python stdlib.

it's actually already been included, but that's beside the point.  I'm
now asking you a second time to submit bug reports if there are issues
which you see; perhaps these 'myriad of quirks' can be fixed, perhaps
not.  yelling here doesn't actually do anything productive.

> Clay
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5230] pydoc reports misleading failure if target module raises an ImportError

[Lucas Prado Melo]

Lucas Prado Melo  added the comment:

Thanks :)
It seems that the error message carried by the ImportError object comes
from Python/import.c:1504.
What should we do:
a) Edit Python/import.c
b) Change the ImportError object
c) Anything else.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Clay McClure]

Clay McClure  added the comment:

On Mon, Jun 1, 2009 at 4:51 PM, pmoody  wrote:

> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
>> True
>>
>> ipaddr makes no distinction between two fundamentally different
>> concepts -- to my mind, that is a serious flaw.
>
> I don't see these a fundamentally different, I guess.  can you
> demonstrate how this equivalency makes ipaddr unusable?

Fortunately, it's not up for debate: RFC-791 defines an IP address as
a 32-bit number, with no provision for a mask. Networks are defined by
their address and their mask. To correctly model them in an
object-oriented system, we would say that a Network has-a Address,
certainly not that a Network is-a Address.

> I haven't seen any new issues on code.google.com (and I haven't heard
> of any being reported on the python bugtracker), so since you're using
> this thread to report issues, can you elaborate?

I will go ahead and open issues on code.google.com.

> have used it to develop software and will continue to use it to
> develop software.

I'd like to hear from application developers outside of Google. The
two that have commented on this issue seem not to prefer ipaddr's API.

Clay

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Clay McClure]

Clay McClure  added the comment:

On Mon, Jun 1, 2009 at 7:51 PM, pmoody  wrote:

>> For an example of why 192.168.1.1 != 192.168.1.1/32, look no further
>> than ifconfig:
>>
>> # ifconfig en0 192.168.1.1/32
>> # ifconfig en0
>> en0: flags=8863 mtu 1500
>>        inet 192.168.1.1 netmask 0x broadcast 192.168.1.1
>>        ...
>>
>> # ifconfig en0 192.168.1.1
>> # ifconfig en0
>> en0: flags=8863 mtu 1500
>>        inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
>>        ...
>
> what this shows is that your copy of darwin defaults to a /24
> prefixlen; ipaddr assumes a /32 prefixlen.  I don't see anything
> particularly *more* intuitive with darwin, but in any event, it seems
> to provide support for assuming a prefixlen when none is supplied.

The example demonstrates one case where the strings '192.168.1.1' and
'192.168.1.1/32' are not equivalent -- it wouldn't be hard to find
other examples -- yet you seem to think that (a) this is
Darwin-specific behavior, and that (b) this discrepancy is acceptable
and does not constitute a design flaw.

You're wrong on both fronts, since in fact all IP implementations
understand classful addressing (as per RFC-791), not just Darwin, and
your insistence on the equality of '192.168.1.1' and '192.168.1.1/32'
means that your library is unusable in applications that pass
ipaddr.IPv4 objects to ifconfig.

Clay

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Clay McClure]

Clay McClure  added the comment:

On Mon, Jun 1, 2009 at 8:05 PM, R. David Murray  wrote:

> In pre-CIDR days, assuming a prefixlen of 24 for a 192.168.x.x address
> made sense.  Nowadays it is better not to make that assumption.  So I
> find ipaddr's default of 32 to be "safer" than using a class based default.

Sorry, but why should you determine what is better for my application?

> The larger point, however, is that there _is_ a mask associated with the
> address in ifconfig.  There _must_ be one.  So that is not an example
> that shows that a separate address class is useful.

Again, you're wrong. The mask that you see in ifconfig is associated
with the network to which the interface is attached, not the interface
address. You also see a broadcast address in the ifconfig output, but
certainly you don't believe that the broadcast address is a property
of the interface address? No, of course not; it's a property of the
network to which the interface is attached -- just like the mask.

That's why we call it a "netmask".

> As for an example of when the equivalence is useful, it is useful every
> time I set up an access rule or route that applies to a single host.

Host routes are routes like all others -- they have a destination
address and a mask. That a host route has a prefix length of 32 does
not imply that the host route is equivalent to the host address.
You're confusing the two concepts.

> Most networking
> software that I've dealt with requires explicit netmasks (often with a
> shorthand to specify an ip/hostmask pair).

By "ip/hostmask" pair, you actually mean "ip/netmask" pair, and yes,
this is a convenient notation for expressing two distinct but related
concepts: an address, and a mask. Addresses do not have masks;
networks do. I am not sure how to be any more clear about that point,
yet you still seem not to understand.

> It is true that when a
> netmask isn't required it generally defaults to the classful netmask,
> but having such a default is becoming more rare with time, in my
> experience (because of CIDR).

I'm not advocating classful routing, I'm merely stating (emphatically
and without ambiguity) that addresses and networks are different:
networks have masks; addresses do not. The ipaddr library forces a
mask on me every time I specify an address. In my view, that is a
design flaw.

Clay

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6168] Missing Shell menu in Linux IDLE

[Jason Gervich]

Jason Gervich  added the comment:

Again, thanks for your prompt explanation.

It's odd, but when I went to use Ubuntu's menu modification tool, the
command displayed in the dialog didn't show the -n option.

But when I added the Python launcher to the panel and viewed the launch
command via the properties dialog, the -n was there and I was easily
able to remove it. 

So if I run Python from the modified icon in the panel, it launches
without the -n option. But if I run it from the Application Menu, it
runs without the -n option. It seems to me that the -n option should be
available when viewing it from the menu modification tool, but it's not.

I guess Windows doesn't have this problem with running IDLE with a
subprocess. I was able to run several instances of the IDLE shell with
the Shell menu displayed.

On Tue, 2009-06-02 at 00:53 +, Roger Serwy wrote:

> Roger Serwy  added the comment:
> 
> You'll need to modify the IDLE menu item to remove the "-n" using
> Ubuntu's menu modification tool, usually found under System->Preferences.
> 
> Presently, using a subprocess only allows for one instance of IDLE
> running on a machine, whereas running with no subprocess allows for many
> instances of IDLE. This architecture is by design.
> 
> Check out Ubuntu bug 338379.
> 
> --
> 
> ___
> Python tracker 
> 
> ___

--
Added file: http://bugs.python.org/file14152/unnamed

___
Python tracker 

___


  
  


Again, thanks for your prompt explanation.

It's odd, but when I went to use Ubuntu's menu modification tool, the command 
displayed in the dialog didn't show the -n option.

But when I added the Python launcher to the panel and viewed the 
launch command via the properties dialog, the -n was there and I 
was easily able to remove it. 

So if I run Python from the modified icon in the panel, it launches without the 
-n option. But if I run it from the Application Menu, it runs without the -n 
option. It seems to me that the -n option should be available when viewing it 
from the menu modification tool, but it's not.

I guess Windows doesn't have this problem with running IDLE with a subprocess. 
I was able to run several instances of the IDLE shell with the Shell menu 
displayed.



On Tue, 2009-06-02 at 00:53 +, Roger Serwy wrote:


Roger Serwy roger.se...@gmail.com> added the 
comment:

You'll need to modify the IDLE menu item to remove the "-n" using
Ubuntu's menu modification tool, usually found under System->Preferences.

Presently, using a subprocess only allows for one instance of IDLE
running on a machine, whereas running with no subprocess allows for many
instances of IDLE. This architecture is by design.

Check out Ubuntu bug 338379.

--

___
Python tracker rep...@bugs.python.org>
http://bugs.python.org/issue6168>
___




___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Clay McClure]

Clay McClure  added the comment:

On Mon, Jun 1, 2009 at 9:03 PM, pmoody  wrote:

>> ifconfig: 255.255.255.0/32: bad value
>>
>> That's because ipaddr wrongly appends a prefix length to all
>> ipaddr.IPv4 objects, even those representing addresses, which do not
>> have prefix lengths.
>
> I'm not sure what you're trying to do here, can you elaborate?

Let's say I have a UI that prompts users for two pieces of
information: interface address, and network mask. I then take those
two strings and make ipaddr.IPv4 objects out of them. This lets me
validate their correctness, and lets me perform convenient
calculations and tests (things the ipaddr library has done well).
Next, I take the IPv4 objects, coerce them to strings, and pass them
to ifconfig to configure an interface.

Assuming the user has supplied this information:

Interface address = '192.168.1.1'
Network mask = '255.255.255.0'

the following would get passed to ifconfig:

ifconfig en0 192.168.1.1/32 netmask 255.255.255.0/32

Clearly this is not what we expect, nor even legal. The principle of
least surprise is violated here, if nothing else.

We could work around this, of course, but why should we have to work
around our libraries when simply fixing them isn't that hard?

>> if isinstance(address, ipaddr.IPv4):
>>    if address.prefixlen != 32:
>>        raise TypeError("Expecting IP address, not network")
>> elif isinstance(address, ipaddr.IPv6):
>>    if address.prefixlen != 128:
>>        raise TypeError("Expecting IP address, not network")
>
> i'm not sure what's onerous about this code.  you're missing a
> try/except around ipaddr.IP(), but otherwise it seems fine.

Your definition of onerous apparently differs from mine :)

In my own applications, when I'm expecting a network, I use an
IPNetwork class, and when I'm expecting an address, I use an IPAddress
class. This means I can simply rely on the class constructors to do
the type checking for me. With ipaddr, I have to do the validation
myself. Simple isinstance() testing and duck typing don't work because
networks and addresses are represented (wrongly) by the same class.

> it's actually already been included, but that's beside the point.  I'm
> now asking you a second time to submit bug reports if there are issues
> which you see; perhaps these 'myriad of quirks' can be fixed, perhaps
> not.  yelling here doesn't actually do anything productive.

Rest assured, I've opened one issue and will open one or two more
before the night is out.

I'm sorry that you think "yelling" is unproductive. I happen to think
that healthy debate breeds better code.

Cheers,

Clay

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[pmoody]

pmoody  added the comment:

On Mon, Jun 1, 2009 at 7:38 PM, Clay McClure  wrote:
>
> Clay McClure  added the comment:
>
> On Mon, Jun 1, 2009 at 9:03 PM, pmoody  wrote:
>
>>> ifconfig: 255.255.255.0/32: bad value
>>>
>>> That's because ipaddr wrongly appends a prefix length to all
>>> ipaddr.IPv4 objects, even those representing addresses, which do not
>>> have prefix lengths.
>>
>> I'm not sure what you're trying to do here, can you elaborate?
>
> Let's say I have a UI that prompts users for two pieces of
> information: interface address, and network mask. I then take those
> two strings and make ipaddr.IPv4 objects out of them. This lets me
> validate their correctness, and lets me perform convenient
> calculations and tests (things the ipaddr library has done well).
> Next, I take the IPv4 objects, coerce them to strings, and pass them
> to ifconfig to configure an interface.
>
> Assuming the user has supplied this information:
>
> Interface address = '192.168.1.1'
> Network mask = '255.255.255.0'
>
> the following would get passed to ifconfig:
>
> ifconfig en0 192.168.1.1/32 netmask 255.255.255.0/32

I suppose that might be the case if you didn't know how to use ipaddr.
 knowing that ipaddr accepts an ipaddress/netmask, I'd pass it

my_ip = ipaddr.IP('%s/%s' % (ipaddress, netmask))

and then check for any exceptions.  I'd then ifconfig en0 str(my_ip)

> Clearly this is not what we expect, nor even legal. The principle of
> least surprise is violated here, if nothing else.
>
> We could work around this, of course, but why should we have to work
> around our libraries when simply fixing them isn't that hard?
>
>>> if isinstance(address, ipaddr.IPv4):
>>>    if address.prefixlen != 32:
>>>        raise TypeError("Expecting IP address, not network")
>>> elif isinstance(address, ipaddr.IPv6):
>>>    if address.prefixlen != 128:
>>>        raise TypeError("Expecting IP address, not network")
>>
>> i'm not sure what's onerous about this code.  you're missing a
>> try/except around ipaddr.IP(), but otherwise it seems fine.
>
> Your definition of onerous apparently differs from mine :)
>
> In my own applications, when I'm expecting a network, I use an
> IPNetwork class, and when I'm expecting an address, I use an IPAddress
> class. This means I can simply rely on the class constructors to do
> the type checking for me. With ipaddr, I have to do the validation
> myself. Simple isinstance() testing and duck typing don't work because
> networks and addresses are represented (wrongly) by the same class.

so ipaddr doing this validation for the user actually could make some
sense, but this could be fixed by something as easy

  ipaddr.IP(ip, network=False)
or
  ipaddr.IP(net, network=True)

anyway (more below)...

>> it's actually already been included, but that's beside the point.  I'm
>> now asking you a second time to submit bug reports if there are issues
>> which you see; perhaps these 'myriad of quirks' can be fixed, perhaps
>> not.  yelling here doesn't actually do anything productive.
>
> Rest assured, I've opened one issue and will open one or two more
> before the night is out.

cool, I see that you did that. as an aside, this probably isn't the
best place for continued discussion on ipaddr. ipaddr has already been
shipped with python, so i'm not sure that debate on it's inclusion is
able to influence that decision.  All of the folks who've worked on
ipaddr + the python committer are on ipaddr-py-...@googlegroups.com
(looks like you are too), so might I suggest we continue this
discussion there?

> I'm sorry that you think "yelling" is unproductive. I happen to think
> that healthy debate breeds better code.

I think debate is healthy, too.  but I measure my success at a debate
by my ability to convince other people of my side. I find I have
better success when I listen other people and respond with respect.
yelling promotes neither of those.

Cheers,
/peter

> Cheers,
>
> Clay
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6169] Important comparison bug in ipaddr

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
priority:  -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6081] str.format_from_mapping()

[Evan Behar]

Changes by Evan Behar :


--
nosy: +ebehar

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Consider applications that need to validate addresses (or networks,
> but not both) supplied as user input:
> 
> address = ipaddr.IP(input)

If that is a frequent need, it would be reasonable to add an API

address = ipaddr.IP(input, allow_mask=False)

which would raise an exception if a mask was specified (as an
old-style bit mask, or in CIDR form).

> if isinstance(address, ipaddr.IPv4):
>if address.prefixlen != 32:
>raise TypeError("Expecting IP address, not network")
> elif isinstance(address, ipaddr.IPv6):
>if address.prefixlen != 128:
>raise TypeError("Expecting IP address, not network")

With the current API, you don't need to write it in such a quirky
way. Instead

if address.numhosts != 1:
   raise TypeError("Expecting IP address, not network")

would do as well.

> Given its myriad quirks

Well, you deliberately make it appear more quirky than it actually is.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> I will go ahead and open issues on code.google.com.

If you want to see them fixed in Python, please report them to this
tracker.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Clay McClure]

Clay McClure  added the comment:

On Tue, Jun 2, 2009 at 1:21 AM, Martin v. Löwis  wrote:

>> I will go ahead and open issues on code.google.com.
>
> If you want to see them fixed in Python, please report them to this
> tracker.

I'd like to see the issues fixed upstream, and the library removed
from Python until it is satisfactory to the developers who will
actually use it. To my knowledge, every developer (outside of Google)
who has commented on the issue has indicated a preference for a
different API.

Thanks,

Clay

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6169] Important comparison bug in ipaddr

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Thanks!

Fixed in trunk r73135 and py3k r73136.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6173] Minor typo in socket.py

[Pablo Torres Navarrete]

New submission from Pablo Torres Navarrete :

Index: socket.py
===
--- socket.py   (revision 73134)
+++ socket.py   (working copy)
@@ -16,7 +16,7 @@
 gethostbyname() -- map a hostname to its IP number
 gethostbyaddr() -- map an IP number or hostname to DNS info
 getservbyname() -- map a service name and a protocol name to a port number
-getprotobyname() -- mape a protocol name (e.g. 'tcp') to a number
+getprotobyname() -- map a protocol name (e.g. 'tcp') to a number
 ntohs(), ntohl() -- convert 16, 32 bit int from network to host byte order
 htons(), htonl() -- convert 16, 32 bit int from host to network byte order
 inet_aton() -- convert IP addr string (123.45.67.89) to 32-bit packed
format

--
components: Library (Lib)
files: socket.patch
keywords: patch
messages: 88715
nosy: ptn
severity: normal
status: open
title: Minor typo in socket.py
versions: Python 2.6
Added file: http://bugs.python.org/file14153/socket.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6174] What's new in 2.6, wrong indentation in code sample

[Joe Amenta]

New submission from Joe Amenta :

In the final example in the multiprocessing package on
http://docs.python.org/3.0/whatsnew/2.6.html#pep-371-the-multiprocessing-package
a part of the code is not properly indented.  There should be one more
level of indentation starting at "#Mark pool as closed".

Patch adds that level of indentation.

--
assignee: georg.brandl
components: Documentation
files: docdiff.patch
keywords: patch
messages: 88716
nosy: georg.brandl, joe.amenta
severity: normal
status: open
title: What's new in 2.6, wrong indentation in code sample
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14154/docdiff.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Gregory P. Smith]

Gregory P. Smith  added the comment:

> Consider applications that need to validate addresses (or networks,
> but not both) supplied as user input:
>
> address = ipaddr.IP(input)
>
> if isinstance(address, ipaddr.IPv4):
>    if address.prefixlen != 32:
>        raise TypeError("Expecting IP address, not network")
> elif isinstance(address, ipaddr.IPv6):
>    if address.prefixlen != 128:
>        raise TypeError("Expecting IP address, not network")

Support for this can be added (its too late for Python 3.1).  User
input validation is a good use case.  For now I suggest the simpler
code:

if '/' in input:
raise TypeError("Expecting IP address")
address = ipaddr.IP(input)

Or for a more pedantic test prior to calling ipaddr.IP.

if re.match('^[0-9a-fA-F:.]+$', input):
raise TypeError("Invalid characters in IP address")

Please file a feature request on bugs.python.org for this one if you
haven't already.  We could add optional parameter(s) to ipaddr.IP to
enable only accepting host addresses or network addresses in the
future.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> I'd like to see the issues fixed upstream, and the library removed
> from Python until it is satisfactory to the developers who will
> actually use it. To my knowledge, every developer (outside of Google)
> who has commented on the issue has indicated a preference for a
> different API.

That's not true - I'm outside of Google, and have not indicated such
a preference.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6173] Minor typo in socket.py

[Pablo Torres Navarrete]

Changes by Pablo Torres Navarrete :


--
versions: +Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[Clay McClure]

Clay McClure  added the comment:

On Tue, Jun 2, 2009 at 2:18 AM, Martin v. Löwis  wrote:

>> I'd like to see the issues fixed upstream, and the library removed
>> from Python until it is satisfactory to the developers who will
>> actually use it. To my knowledge, every developer (outside of Google)
>> who has commented on the issue has indicated a preference for a
>> different API.
>
> That's not true - I'm outside of Google, and have not indicated such
> a preference.

You've indicated no preference either way, and have said:

"I personally have no plans for using this library, or any other IP
address library"

I should think you would seek the opinion of those developers who
actually do have plans to use an IP address library. As far as I can
tell, every developer in that category, outside of Google, that has
commented on this issue here or in python-dev has advocated a
different API.

Clay

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3959] Add Google's ipaddr.py to the stdlib

[pmoody]

pmoody  added the comment:

> I should think you would seek the opinion of those developers who
> actually do have plans to use an IP address library.

That's what this has been doing for the last 8 1/2 months.

> As far as I can
> tell, every developer in that category, outside of Google, that has
> commented on this issue here or in python-dev has advocated a
> different API.

Is there some sort of conspiracy theory-ish reason that a google
software engineer might be somehow unfairly influenced?

Cheers,
/peter

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com