Re: [Python-Dev] How to document functions with optional positional parameters?

[Serhiy Storchaka]

On 21.03.15 13:03, Victor Stinner wrote:

The \ is useful, it indicates that you cannot use keywords.


Wouldn't it confuse users?


If you want to drop \, modify the function to accept keywords.


Yes, this is a solution. But parsing keyword arguments is slower than 
parsing positional arguments. And I'm working on patches that optimizes 
parsing code generated by Argument Clinic. First my patches will handle 
only positional parameters, with keywords it is harder.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Needed reviews

[Serhiy Storchaka]

On 21.03.15 13:46, Nick Coghlan wrote:

On 19 March 2015 at 19:28, Serhiy Storchaka  wrote:

Here is list of my ready for review patches.  It is incomplete and contains
only patches for which I don't expect objections or long discussion.  Most
of them are relative easy and need only formal review.  Most of them wait
for a review many months.


It's worth noting that If there are changes you feel are genuinely low
risk, you can go ahead and merge them based on your own commit review
(even if you also wrote the original patch).


Yes, but four eyes are better than two eyes. I make mistakes. In some 
issues I hesitate about documentation part. In some issues (issue14260 
and issue22721) I provided two alternative solutions and need a tip to 
choose from them. While I am mainly sure about the correctness of the 
patch, I'm often hesitate about the direction. Is the bug worth fixing? 
Is the new feature worth to be added to Python?


Thanks Alexander, Amaury, Benjamin, Berker, Demian, Éric, Ethan, Martin, 
Paul, Victor and others that responded on my request.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 0-base and 1-base indexed iterables? Custom slicing rules?

[Stefan Richthofer]

Pascal allows to define custom indexing. The indexes are defined on array declaration

myArray : Array[1..5] of Integer;

see http://pascal-programming.info/lesson10.php

However, in pascal array-size must be set at compile time, wich is rather annoying, but allows for some optimizations.

 

Visual Basic uses both 0- and 1-based indexing throughout its API. Arrays are always 0-indexed, but there are various

index-taking methods that use 1-indexing. It actually feels like a mess and I never enjoyed using VB, partly (but in

significant part) because of this issue.

 

With some experience in these languages I can tell you, it is really really annoying to figure out the indexing style

each time you work with an array (that you did not create yourself, but was provided by some framework API).

(Even if you created it yourself, it will become hard to keep track when your project grows.)

People *will* abuse this feature if it exists and fragment API into different paradigms. Some migrate from Matlab

and will thus use 1-indexing versus those who "grew up" with numpy or whatever.

Believe it or not, array-indexing is already error-prone enough if you work with nested numpy arrays, apply various

dimension-changing functions, use extensive slicing over several dimensions with customs step-size, transpose

arrays frequently etc. Having to care about indexing style in addition would make it a real nightmare.
 

 

-Stefan


 

Gesendet: Sonntag, 22. März 2015 um 06:46 Uhr
Von: "pedro santos" 
An: python-dev@python.org
Betreff: [Python-Dev] 0-base and 1-base indexed iterables? Custom slicing rules?




Hi, I'm an Art and CG student learning Python and today's exercise was about positions in a tiled room. The fact that I had to check if a position was inside the room and given that in a 1x1 room, 0.0 was considered in and 1.0 was considered out, it kept me thinking about 0-base indexing iterables and slicing.

Read some articles and discussions, some pros and cons to each 0-base and 1-base, concerns about slicing, etc. But ultimately the question that got stuck in me and didn't found an answer was:
Why can't both 0-base and 1-base indexing exist in the same language, and why can't slicing be customized?

 

If I'm indexing the ruler marks, intervals, boundaries, dots, makes sense to start of at 0; rul=[0,1,2,3,4,5,6] would index every mark on my ruler so that accordingly rul[0]=0, rul[5]=5.
If I'm indexing the blue circles, natural number quantities, objects, spans, makes sense to start at 1; cir= [1,2,3,4,5] so that cir[1]=1 and cir[5]=5.

Now, a lot of the discussion was to do with slicing coupled with the indexing and I don't totally understand why.

a ≤ x < b is not so intuitive when dealing with objects ("I want balls 1 up to the the one before 3"), so on one side, you put the finger on what you want and on the other, on what you don't want. But this method does have the neat property of producing neighbor selections that border perfectly, as in [:a][a:b][b:c]. Although in inverse order(-1), the results can be unexpected as it returns values off-by-one from its counterpart like; L=[0,1,2,3,4,5] so that L[1:3]=[1,2] and L[3:1:-1]=[3:2]. So it's consistent with the rule a ≤ x < b, grabbing the lower limit item, but it can feel strange by not producing the same selection with inverse order.

a ≤ x ≤ b is a natural way to select objets ("I want the balls 1 up to 3"), so you're putting the finger on the things you want. If you inverse the order(-1) it's still very easy to grasp what are you picking because whatever you select it's included like: L=[0,1,2,3,4,5] so that L[1:3]=[1,2,3] and L[3:1:-1]=[3,2,1]. Problems seem to arrive though, when trying to do neighbor selections, where one would have to do [:a][a+1:b][b+1:c] to have the border perfectly. That terrible?

Even though one could see a ≤ x < b to be more adept to 0-base, and a ≤ x ≤ b to be more adept to 1-base, the way I see it, index base and slicing rules could be somehow independent. And one would index and slice the way it would fit the rationale of the problem or the data, because even slicing a 1-base indexed array with a ≤ x < b, would still produce an expected outcome, as in cir=[1,2,3,4,5] so that cir[1:3]=[1,2] or cir[:3]=[1,2].
Same thing applying a ≤ x ≤ b to a 0-base indexed array, as in rul[0,1,2,3,4,5] so that rul[:2]=[0,1,2] or rul[0:2]=[0,1,2].

Given that python is an example of human friendly code language, emphasizing readability, wouldn't having 0 and 1 base indexing and custom slicing methods, improve the thought process when writing and reading the code, by fitting them better to specific contexts or data?
Is there some language that provides both or each language picks only one?

Cheers

 

 
--






	
		
			
			
			
			
			Pedro Alpiarça dos Santos 
			Animator  3DModeler  Illustrator 
			>>  http://probiner.x10.mx/
			
		
	


 




___ Python-Dev mailing list Python-Dev@python.org htt

[Python-Dev] Installing Python to non-ASCII paths

[Paul Moore]

Something that hit me today, which might become a more common issue
when the Windows installers move towards installing to the user
directory, is that there appear to be some bugs in handling of
non-ASCII paths.

Two that I spotted are a failure of the "script wrappers" installed by
pip to work with a non-ASCII interpreter path (reported to distlib)
and a possible issue with the py.exe launcher when a script has
non-ASCII in the shebang line (not reported yet because I'm not clear
on what's going on).

I've only seen Windows-specific issues - I don't know how common
non-ASCII paths for the python interpreter are on Unix or OSX, or
whether the more or less universal use of UTF-8 on Unix makes such
issues less common. But if anyone has an environment that makes
testing on non-ASCII install paths easy, it might be worth doing some
checks just so we can catch any major ones before 3.5 is released.

On which note, I'm assuming neither of the issues I've found are major
blockers. "pip.exe doesn't work if Python is installed in a directory
with non-ASCII characters in the name" can be worked around by using
python -m pip, and the launcher issue by using a generic shebang like
#!/usr/bin/python3.5.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Installing Python to non-ASCII paths

[Tim Golden]

On 22/03/2015 14:44, Paul Moore wrote:

On which note, I'm assuming neither of the issues I've found are major
blockers. "pip.exe doesn't work if Python is installed in a directory
with non-ASCII characters in the name" can be worked around by using
python -m pip, and the launcher issue by using a generic shebang like
#!/usr/bin/python3.5.


That can become a more major blocker if "pip doesn't work" == "ensurepip 
doesn't work and blocks thus the installer crashes" as was the case with 
a mimetypes issue a little while back.


I'll create a £££ user (which is the easiest non-ASCII name to create on 
a UK keyboard) to see how cleanly the latest installer works.


TJG

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Installing Python to non-ASCII paths

[Tim Golden]

On 22/03/2015 15:12, Tim Golden wrote:

On 22/03/2015 14:44, Paul Moore wrote:

On which note, I'm assuming neither of the issues I've found are major
blockers. "pip.exe doesn't work if Python is installed in a directory
with non-ASCII characters in the name" can be worked around by using
python -m pip, and the launcher issue by using a generic shebang like
#!/usr/bin/python3.5.


That can become a more major blocker if "pip doesn't work" == "ensurepip
doesn't work and blocks thus the installer crashes" as was the case with
a mimetypes issue a little while back.

I'll create a £££ user (which is the easiest non-ASCII name to create on
a UK keyboard) to see how cleanly the latest installer works.


Tried with "Mr £££". The installer's fine but the installed pip.exe 
fails while "py -3 -mpip" succeeeds as Paul notes.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for comments: [issue22941] IPv4Interface arithmetic changes subnet mask

[Søren Løvborg]

Thanks for the feedback, and apologies for my late reply. I have to
say, I'm not entirely sold on the argument for raising an exception on 
subnet "overflow".


First, I'll note what happens if we overflow an IPv4Address:

>>> ipaddress.IPv4Address('255.255.255.255') + 1
Traceback (most recent call last):
...
ipaddress.AddressValueError: 4294967296 (>= 2**32) is not permitted
as an IPv4 address

Now, I used "IPv4Interface() + 1" to mean "Give me the IP next to the
current one in the current subnet", knowing from the context that the
address would be valid and available.

>>> host = ipaddress.IPv4Interface('10.0.0.2/24')
>>> peer = host + 1

In this context, I would welcome an exception, as it would certainly be 
an error if I overflowed the subnet.


However, there are also situations in which overflowing would be valid 
and expected, e.g. as a way to skip to the "same" IP in the next subnet:


>>> ip = ipaddress.IPv4Interface('10.0.0.42/24')
>>> ip + ip.network.num_addresses
IPv4Interface('10.0.1.42/24')

It's not even a hypothetical example; I've been working on a distributed 
embedded system where all the hosts have two (redundant) addresses 
differing only by their subnet; this could be a convenient way calculate 
one address from the other.


There's an additional issue with raising an exception, and that is that
it still won't catch overflow errors in my example use case:

>>> host = ipaddress.IPv4Interface('10.0.0.254/24')
>>> peer = host + 1
>>> peer
IPv4Interface('10.0.0.255/24')

This doesn't overflow and does not trigger an exception, but the
resulting peer address is still invalid (it's the subnet broadcast
address, not a host address). As such, the exception isn't even useful
as an error detection tool. (I'll not suggest raising an exception when 
hitting the broadcast or network address; that way lies madness.)


As for consistency with IPv4Address, I can argue either way:

Pro-exception:

"Overflowing an IPv4Interface raises AddressValueError just like with
IPv4Address."

Contra-exception:

"An IPv4Interface behaves exactly like an IPv4Address, except that it
also has an associated subnet mask." (This is essentially how the type
is currently documented).

Thoughts?

Best regards,
Søren Løvborg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Installing Python to non-ASCII paths

[Victor Stinner]

Hi Paul,

Please open an issue, I can take a look. Please describe a scenario to
reproduce the issue.

Victor

2015-03-22 15:44 GMT+01:00 Paul Moore :
> Something that hit me today, which might become a more common issue
> when the Windows installers move towards installing to the user
> directory, is that there appear to be some bugs in handling of
> non-ASCII paths.
>
> Two that I spotted are a failure of the "script wrappers" installed by
> pip to work with a non-ASCII interpreter path (reported to distlib)
> and a possible issue with the py.exe launcher when a script has
> non-ASCII in the shebang line (not reported yet because I'm not clear
> on what's going on).
>
> I've only seen Windows-specific issues - I don't know how common
> non-ASCII paths for the python interpreter are on Unix or OSX, or
> whether the more or less universal use of UTF-8 on Unix makes such
> issues less common. But if anyone has an environment that makes
> testing on non-ASCII install paths easy, it might be worth doing some
> checks just so we can catch any major ones before 3.5 is released.
>
> On which note, I'm assuming neither of the issues I've found are major
> blockers. "pip.exe doesn't work if Python is installed in a directory
> with non-ASCII characters in the name" can be worked around by using
> python -m pip, and the launcher issue by using a generic shebang like
> #!/usr/bin/python3.5.
>
> Paul
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Installing Python to non-ASCII paths

[Paul Moore]

On 22 March 2015 at 19:34, Victor Stinner  wrote:
> Please open an issue, I can take a look. Please describe a scenario to
> reproduce the issue.

The "issue" with the launcher seems to have bee a red herring. When I
set up a test case properly, it worked. I suspect I messed up writing
the shebang line in UTF8. Thanks anyway. (And the pip.exe issue is a
distlib issue, which I have reported).

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Needed reviews

[Nick Coghlan]

On 22 Mar 2015 19:22, "Serhiy Storchaka"  wrote:
>
> On 21.03.15 13:46, Nick Coghlan wrote:
>>
>> On 19 March 2015 at 19:28, Serhiy Storchaka  wrote:
>>>
>>> Here is list of my ready for review patches.  It is incomplete and
contains
>>> only patches for which I don't expect objections or long discussion.
Most
>>> of them are relative easy and need only formal review.  Most of them
wait
>>> for a review many months.
>>
>>
>> It's worth noting that If there are changes you feel are genuinely low
>> risk, you can go ahead and merge them based on your own commit review
>> (even if you also wrote the original patch).
>
>
> Yes, but four eyes are better than two eyes. I make mistakes. In some
issues I hesitate about documentation part. In some issues (issue14260 and
issue22721) I provided two alternative solutions and need a tip to choose
from them. While I am mainly sure about the correctness of the patch, I'm
often hesitate about the direction. Is the bug worth fixing? Is the new
feature worth to be added to Python?

Aye, agreed - those are the kinds of cases where I'd nudge folks for a
review as well. Committing directly is something I'd only do where I'm
already entirely confident the change is an improvement over the status quo.

However, now that I think about it further, it's very rare for me to be
completely confident in a change without another core dev at least giving a
+1 on the general idea.

> Thanks Alexander, Amaury, Benjamin, Berker, Demian, Éric, Ethan, Martin,
Paul, Victor and others that responded on my request.

Indeed! One of the things I'm actually hoping to achieve through PEPs like
474 & 462 is to get to a point where we can better acknowledge and thank
folks for all the work that goes into patch reviews :)

Cheers,
Nick.

>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] some minor questions about pep8

[Guido van Rossum]

On Fri, Mar 20, 2015 at 9:24 PM, Ian Lee  wrote:

> Guido,
>
> In that case would you be open to a patch to update the PEP accordingly?
>
Only if it totally eradicate __version__ and similar from the PEP.


> Additionally, does that official statement cover other dunder assignments
> (e.g. "__author__"?). If so I'll update the PEP8 tool accordingly.


What official statement? I'm not the Pope. :-)

--Guido

> Thanks,
>
> ~ Ian Lee
> On Mar 20, 2015 8:55 PM, "Guido van Rossum"  wrote:
>
>> FWIW, I think __version__, __author__ etc. were bad ideas. Almost nobody
>> manages these correctly. Note that the PEP 8 section starts with less than
>> an endorsement: "If you *have* to have Subversion, CVS, or RCS crud in
>> your source file, do it as follows."
>>
>> That said, if an official answer is required, common sense would suggest
>> that __version__ should go before the imports. (I would put it before the
>> docstring too, except then the docstring wouldn't be a docstring any more.
>> Go figure.)
>>
>> On Fri, Mar 20, 2015 at 6:38 PM, Ben Finney 
>> wrote:
>>
>>> Lewis Coates  writes:
>>>
>>> > In pep8 there are two conflicting statements, both
>>> >
>>> > https://www.python.org/dev/peps/pep-0008/#version-bookkeeping
>>> > https://www.python.org/dev/peps/pep-0008/#imports
>>> >
>>> > Stipulate that they should be "at the top of the file after any module
>>> > comments and docstrings." Which of these takes precedence?
>>>
>>> I don't know an official answer. The convention I've observed is
>>> overwhelmingly in one direction: import statements come before any
>>> assignment statements.
>>>
>>> > Secondly, we also have an "__author__", and "__project__" variables, I
>>> > assume these would be put with the version information as well?
>>>
>>> Yes.
>>>
>>> --
>>>  \ “Welchen Teil von ‘Gestalt’ verstehen Sie nicht?  [What part of |
>>>   `\‘gestalt’ don't you understand?]” —Karsten M. Self |
>>> _o__)  |
>>> Ben Finney
>>>
>>> ___
>>> Python-Dev mailing list
>>> Python-Dev@python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>>
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/ianlee1521%40gmail.com
>>
>>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Installing Python to non-ASCII paths

[Nick Coghlan]

On 23 Mar 2015 00:45, "Paul Moore"  wrote:
>
> Something that hit me today, which might become a more common issue
> when the Windows installers move towards installing to the user
> directory, is that there appear to be some bugs in handling of
> non-ASCII paths.
>
> Two that I spotted are a failure of the "script wrappers" installed by
> pip to work with a non-ASCII interpreter path (reported to distlib)
> and a possible issue with the py.exe launcher when a script has
> non-ASCII in the shebang line (not reported yet because I'm not clear
> on what's going on).
>
> I've only seen Windows-specific issues - I don't know how common
> non-ASCII paths for the python interpreter are on Unix or OSX, or
> whether the more or less universal use of UTF-8 on Unix makes such
> issues less common.

POSIX is fine if the locale encoding is correct, but can go fairly wrong if
it isn't. Last major complaints I heard related to upstart sometimes
getting it wrong in cron and for some daemonized setups (systemd appears to
be more robust in setting it correctly as it pulls the expected setting
from a system wide config file).

"LANG=C" also doesn't work well, as that tells CPython to use ASCII instead
of UTF-8 or whatever the actual system encoding is. Armin Ronacher pointed
out "LANG=C.UTF-8" as a good alternative, but whether that's available or
not is currently distro-specific. I filed an upstream bug with the glibc
devs asking for that to be made standard, and they seemed amenable to the
idea, but I haven't checked back in on its progress recently.

> But if anyone has an environment that makes
> testing on non-ASCII install paths easy, it might be worth doing some
> checks just so we can catch any major ones before 3.5 is released.

I'd suggest looking at the venv tests and using them as inspiration to
create a separate "test_venv_nonascii" test file that checks:

* creating a venv containing non-ASCII characters
* copying the Python binary to a temporary directory with non-ASCII
characters in the name and using that to create a venv

More generally, we should likely enhance the venv tests to actually *run*
the installed pip binary to list the installed packages. That will
automatically test the distlib script wrappers, as well as checking the
installed package set matches what we're currently bundling.

With those changes, the buildbots would go a long way towards ensuring that
non-ASCII installation paths always work correctly, as well as making it
relatively straightforward for other implementations to adopt the same
checks.

Cheers,
Nick.

>
> On which note, I'm assuming neither of the issues I've found are major
> blockers. "pip.exe doesn't work if Python is installed in a directory
> with non-ASCII characters in the name" can be worked around by using
> python -m pip, and the launcher issue by using a generic shebang like
> #!/usr/bin/python3.5.
>
> Paul
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Installing Python to non-ASCII paths

[Glenn Linderman]

On 3/22/2015 8:12 AM, Tim Golden wrote:
I'll create a £££ user (which is the easiest non-ASCII name to create 
on a UK keyboard) to see how cleanly the latest installer works. 


You can also copy/paste.  A path with a Cyrillic, Greek, Chinese, 
Tibetan, Japanese, Armenian, and Romanian character, none of which are 
in the "Windows ANSI" character set, should suffice...  Here ya go...


ț硕բ文བོདΘ

In my work with Windows, I've certainly seen that £ is much more 
acceptable to more programs than ț or these other ones.
 

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons

[Cameron Simpson]

On 21Mar2015 14:29, Donald Stufft  wrote:

On Mar 21, 2015, at 7:52 AM, Nick Coghlan  wrote:
On 19 March 2015 at 07:51, Donald Stufft  wrote:

I’ve long wished that the OS had it’s own virtual environment. A lot of problems
seems to come from trying to cram the things the OS wants with the things that
the user wants into the same namespace.


I'm more wanting to go in the other direction and suggest to folks
that if they're not *scripting the OS*, then the system Python isn't
what they want, and they should be using at least a virtual
environment, preferably an entirely separate software collection that
they can upgrade on their own timeline, independently of what they
system does.


It’s likely easier to get the OS to move it’s own things to a virtual
environment than it is to convince every single person who uses an OS
to never install globally.


I agree.

And just as a data point, this cropped up on the Fedora list yesterday:

 I broke Yum (by messing with Python libs)
 http://www.spinics.net/linux/fedora/fedora-users/msg458069.html

TL;DR: OP used pip on his system python. Yum broke. Probably hampered his 
attempts to repair, too.


Cheers,
Cameron Simpson 

The mind reigns, but does not govern.   - Paul Valery
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com