date:20140320


R. David Murray added the comment:

Scanner isn't a public interface, so the real enhancement here would be to make 
it one, in which case adding fullmatch would make sense.  I don't know if 
making it public is a good idea or not.

--
nosy: +r.david.murray, twouters
type: behavior -> enhancement
versions: +Python 3.5 -Python 3.4

___
Python tracker 

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

[issue21001] Python 3.4 MSI installer doesn't work


R. David Murray added the comment:

Your IDE stopping support for the beta2 is rather strange, IMO.

The MSI works fine for other people, so I would suggest posting on python-list 
looking for help with figuring out what is going wrong on your particular 
system.  If you can isolate a bug to report here, that would be great.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue20906] Issues in Unicode HOWTO

2014-03-20 Thread Graham Wideman


Graham Wideman added the comment:

Marc-Andre: Thanks for your latest comments. 

> We could also have called encodings: "character set", "code page",
> "character encoding", "transformation", etc.

I concur with you that things _could_ be called all sorts of names, and the 
choices may be arbitrary. However, creating a clear explanation requires 
figuring out the distinct things of interest in the domain, picking terms for 
those things that are distinct, and then using those terms rigorously. (Usage 
in the field may vary, which in itself may warrant comment.)

I read your slide deck/time-capsule-from-2002,  with interest, on a number of 
points. (I realize that you were involved in the Python 2.x implementation of 
Unicode. Not sure about 3.x?)

Page 8 "What is a Character?" is lovely, showing very explicitly Unicode's two 
levels of mapping, and giving names to the separate parts. It strongly suggests 
this HOWTO page needs a similar figure.

That said, there are a few notes to make on that slide, useful in trying to 
arrive at consistent terms: 

1. The figure shows a more precise word for "what users regard as a character", 
namely "grapheme". I'd forgotten that.

2. It shows e-accent-acute to demonstrate a pair of code points representing a 
single grapheme. That's important, but should avoid suggesting this as the only 
way to form e-accent-acute (canonical equivalence, U+00E9).

3. The illustration identifies the series of code points (the middle row) as 
"the Unicode encoding of the string". Ie: The grapheme-to-code-points mapping 
is described as an encoding. Not a wrong use of general language. But 
inconsistent with the mapping that encode() pertains to. (And I don't think 
that the code-point-to-grapheme transform is ever called "decoding", but I 
could be wrong.)

4. The illustration of Code Units (in the third row) shows graphemes for the 
Code Units (byte values). This confusingly glosses over the fact that those 
graphemes correspond to what you would see if you _decoded_ these byte values 
using CP1252 or ISO 8859-1, suggesting that the result is reasonable or useful. 
It certainly happens that people do this, deliberately or accidentally, but it 
is a misuse of the data, and should be warned against, or at least explained as 
a confusion.

Returning to your most recent message:

> In Python keep it simple: you have Unicode (code points) and 
> 8-bit strings or bytes (code units).

I wish it _were_ that simple. And I agree that, in principle, (assuming Python 
3+) there should "inside your program" where you have the str type which always 
acts as sequences of Unicode code points, and has string functions. And then 
there's "outside your program", where text is represented by sequences of bytes 
that specify or imply some encoding. And your program should use supplied 
library functions to mostly automatically convert on the way in and on the way 
out.

But there are enough situations where the Python programmer, having adopted 
Python 3's string = Unicode approach, sees unexpected results. That prompts 
reading this page, which is called upon to make the fine distinctions to allow 
figuring out what's going on.

I'm not sure what you mean by "8-bit strings" but I'm pretty sure that's not an 
available type in Python 3+. Ie: Some functions (eg: encode()) produce 
sequences of bytes, but those don't work entirely like strs. 

---
This discussion to try to revise the article piecemeal has become pretty 
diffuse, with perhaps competing notions of purpose, and what level of detail 
and precision are needed etc. I will try to suggest something productive in a 
subsequent message.

--

___
Python tracker 

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

[issue21002] _sre.SRE_Scanner object should have a fullmatch() method

2014-03-20 Thread Gareth Gouldstone


Gareth Gouldstone added the comment:

I also encountered issue 20998, which explains the convoluted [^\W\d_] in place 
of [a-zA-Z] as I was investigating why case-insensitivity and quantifiers would 
not work together.

--

___
Python tracker 

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

[issue17846] Building Python on Windows - Supplementary info

2014-03-20 Thread Kathleen Weaver


Kathleen Weaver added the comment:

Does this mean that Python 3.4 doesn't use VS 2010?


hunks 1 & 2 (@@ -49,9 and @@ -216,7):
  Both changes should be reverted.  The change from 3.4 -> 3.3 reverts a very
  recent change made due to 3.4 becoming the newest maintenance branch.  If
  I'm not mistaken, the blank line after the Windows heading is important.

--

___
Python tracker 

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

[issue20984] 'Add/Remove Programs' dialog missing entries for 32-bit CPython 'current user only' installations on 64-bit Windows

2014-03-20 Thread A Hettinger


A Hettinger added the comment:

There was a request on the python-dev to check this on windows 8.
I confirm the same behavior.

Windows 8.1 Pro 64bit
Python 3.4.0 32bit (release)

Installed current user:
Does not show up in Add/Remove Programs
Installer correctly sees installation and can remove it
"wmic product" correctly sees installation

--
nosy: +oninoshiko

___
Python tracker 

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

[issue21002] _sre.SRE_Scanner object should have a fullmatch() method

2014-03-20 Thread Gareth Gouldstone


New submission from Gareth Gouldstone:

I believe that the SRE_Scanner object should have a .fullmatch() method for 
consistency with other re pattern-matching behaviour.

>>> rex = re.compile('([^\\W\\d_]{1,2}[0-9]{1,2}[^\\d\\W_]?)[ 
>>> \\t]*([0-9][^\\d\\W_]{2})')
>>> rex.scanner('bn20bs')
<_sre.SRE_Scanner object at 0x102006400>
>>> rex.scanner('bn20bs').search()   
<_sre.SRE_Match object; span=(0, 6), match='bn20bs'>
>>> rex.scanner('bn20bs').match()   
<_sre.SRE_Match object; span=(0, 6), match='bn20bs'>
>>> rex.scanner('bn20bs').fullmatch()   
>>> Traceback (most recent call last):
  File "", line 1, in 
AttributeError: '_sre.SRE_Scanner' object has no attribute 'fullmatch'

--
components: Regular Expressions
messages: 214317
nosy: Gareth.Gouldstone, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: _sre.SRE_Scanner object should have a fullmatch() method
type: behavior
versions: Python 3.4

___
Python tracker 

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

[issue20951] SSLSocket.send() returns 0 for non-blocking socket


Changes by Nikolaus Rath :


Added file: http://bugs.python.org/file34541/issue20951.diff

___
Python tracker 

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

[issue20951] SSLSocket.send() returns 0 for non-blocking socket


Changes by Nikolaus Rath :


Removed file: http://bugs.python.org/file34540/issue20951.diff

___
Python tracker 

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

[issue20951] SSLSocket.send() returns 0 for non-blocking socket


Nikolaus Rath added the comment:

I'd like to argue with the wise words of Nick Coghlan here:

--snip--
There's a great saying in the usability world: "You can't document your way out 
of a usability problem". What it means is that if all the affordances of your 
application (or programming language!) push users towards a particular logical 
conclusion ([...]), having a caveat in your documentation isn't going to help, 
because people aren't even going to think to ask the question. It doesn't 
matter if you originally had a good reason for the behaviour, you've ended up 
in a place where your behaviour is confusing and inconsistent, because there is 
one piece of behaviour that is out of line with an otherwise consistent mental 
model. 
--snip--

This was said in context of the bool(datetime.time) discussion, but I think it 
applies here as well. The rest of Python consistently raises an exception when 
something would block in non-blocking mode. This is reasonable behavior to 
expect. I agree that we shouldn't suddenly break this, but emitting a 
deprecation warning in Python 3.5, and changing the default in 3.6 seems 
reasonable to me. This is three years of transition time, and based on my 
random sampling so far, I doubt that there are a lot of affected modules or 
applications.

--

___
Python tracker 

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

[issue20951] SSLSocket.send() returns 0 for non-blocking socket


Changes by Nikolaus Rath :


Added file: http://bugs.python.org/file34540/issue20951.diff

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Donald Stufft added the comment:

> Again: the point is maintenance later, not breakage now.

Ok, well I don't agree that it's more maintenance later to be explicit and not 
include HIGH, but whatever it's not insecure at the moment so.

Attached is a patch against 3.5 for folks to review.

--
keywords: +patch
Added file: http://bugs.python.org/file34539/better-ciphers.diff

___
Python tracker 

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

[issue21000] json.tool ought to have a help flag

2014-03-20 Thread Martin Panter


Changes by Martin Panter :


--
nosy: +vadmium

___
Python tracker 

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

[issue21001] Python 3.4 MSI installer doesn't work

2014-03-20 Thread Ram Rachum


Ram Rachum added the comment:

Mark, perhaps you've misunderstood me. The MSI doesn't work at all, it doesn't 
even start the installation process, so I can't give any thought either to 
running my scripts nor to running the Python interpreter.

(By the way, I've been working happily with 3.4b2 so far, until my IDE stopped 
supporting it, which is why I need to move to 3.4 final urgently so I could 
keep working.)

--

___
Python tracker 

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

[issue21001] Python 3.4 MSI installer doesn't work

2014-03-20 Thread Mark Lawrence


Mark Lawrence added the comment:

How have you tried to run your scripts and/or the Python 3.4 interpreter?  What 
do you expect to see in Process Explorer?

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue21001] Python 3.4 MSI installer doesn't work

2014-03-20 Thread Ram Rachum


Ram Rachum added the comment:

Note: This happened on both of my computers, which leads me to believe that 
it's a problem with the MSI.

--

___
Python tracker 

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

[issue21001] Python 3.4 MSI installer doesn't work

2014-03-20 Thread Ram Rachum


New submission from Ram Rachum:

I'm trying to install Python 3.4 final on Windows 7 and it doesn't work. I'm 
using the x64 MSI.

Nothing happens after running the MSI. I used Process Explorer but I can't see 
any new process created. I tried restarting my computer, didn't help. I tried 
launching using `msiexec /i`, didn't work. 

I really need to use 3.4 urgently, so if you could create an exe installer, 
that would be nice.

--
components: Installation
messages: 214311
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Python 3.4 MSI installer doesn't work
type: behavior
versions: Python 3.4

___
Python tracker 

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

[issue15351] Add to unittest.TestCase support for using context managers

2014-03-20 Thread Martin Panter


Changes by Martin Panter :


--
nosy: +vadmium

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Antoine Pitrou added the comment:

> The Python ssl module is used for servers and clients. Ideally servers will
> have prefer server ciphers on, but that doesn't always happen and providing
> a modern level of security for end users is preferable. 

We should have specific defaults for servers in
create_default_context().

> The
> danger for breakage here is *tiny*, *miniscule*, almost non existent and the
> failure case is obvious and easy to fix.

Again: the point is maintenance later, not breakage now.

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Donald Stufft added the comment:

> > However I still content that using HIGH in the cipherstring actually
> > adds additional maintenance burden. In order to know if that
> > cipherstring is still safe you must run it against every target
> > OpenSSL you want to make secure to ensure that it doesn't allow a new
> > cipher that doesn't meet the security strength that was attempted to
> > be had with that cipherstring.

> I think that is a bit reverse. The main configuration point for ciphers
> should be the server, not the client. We set a cipher string to guide
> cipher selection in case the server lets us choose amongst its supported
> ciphers, but that's all.

The Python ssl module is used for servers and clients. Ideally servers will
have prefer server ciphers on, but that doesn't always happen and providing
a modern level of security for end users is preferable. 

> Besides, the ssl module doesn't promise a specific "security strength".
> The defaults are a best effort thing, and paranoid people should
> probably override the cipher string (and deal with the consequences).

These are not things that affect only paranoid people and expecting someone
to even know what OpenSSL is much less how to configure it and what they want
to configure it to in order to get modern levels of security is backwards. The
danger for breakage here is *tiny*, *miniscule*, almost non existent and the
failure case is obvious and easy to fix.

--

___
Python tracker 

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

[issue10141] SocketCan support

2014-03-20 Thread Vinay Sajip


Vinay Sajip added the comment:

Sorry if I messed up - I just applied the same logic as I thought you had done 
earlier (replacing #ifdef HAVE_LINUX_CAN_H with #ifdef AF_CAN), and everything 
compiled OK after my changes.

Are you saying that an additional clause for CAN_RAW being defined should be 
added around where it is used? Would that sort things out? I'd rather not just 
revert my change, as that would mean I couldn't compile the SSL module.

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Antoine Pitrou added the comment:

> However I still content that using HIGH in the cipherstring actually
> adds additional maintenance burden. In order to know if that
> cipherstring is still safe you must run it against every target
> OpenSSL you want to make secure to ensure that it doesn't allow a new
> cipher that doesn't meet the security strength that was attempted to
> be had with that cipherstring.

I think that is a bit reverse. The main configuration point for ciphers
should be the server, not the client. We set a cipher string to guide
cipher selection in case the server lets us choose amongst its supported
ciphers, but that's all.

Besides, the ssl module doesn't promise a specific "security strength".
The defaults are a best effort thing, and paranoid people should
probably override the cipher string (and deal with the consequences).

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Donald Stufft added the comment:

Oh, Additionally Marc:

Even if some system administrator or some system out there does patch their 
OpenSSL to actually be safe by default Python changing it's cipher string only 
adds to the potential security (or at worst does nothing). If even one system 
(of which there are legion) does not do that patch then Python changing it's 
ciphers will protect that user.

The failure mode for a bad cipher is silent insecurity, the failure mode for 
not having a needed cipher is an obvious error.

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Donald Stufft added the comment:

Oh, additionally OpenSSL makes no promises what the meaning of "HIGH" will be 
in the future. So you can only look at what it means now and what it means in 
the past.

OpenSSL is not a good library and it's unfortunate that they don't attempt to 
make people secure by default.

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module

Donald Stufft added the comment:

Ok Antoine I've looked around.

Using a string like this:

ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:ECDH+RC4:DH+RC4:RSA+RC4:ECDH+HIGH:DH+HIGH:RSA+HIGH:!aNULL:!eNULL:!MD5:!DSS

The only *additional* ciphers that get added from the use of HIGH are various
Camellia ciphers. These ciphers are not known to be insecure at this point in
time so as of right now this is not an insecure cipher string.

However I still content that using HIGH in the cipherstring actually adds
additional maintenance burden. In order to know if that cipherstring is still
safe you must run it against every target OpenSSL you want to make secure to
ensure that it doesn't allow a new cipher that doesn't meet the security
strength that was attempted to be had with that cipherstring. If you use an
explicit cipher string then you know exactly which cipher suites Python will
use no matter what the OpenSSL claims is HIGH or not. This means that instead
of having to monitor all the various OpenSSL versions for new ciphers you only
have to periodically check that the suites that Python selected are still
secure.

Remember the "failure" mode for not having a cipher in the list is that a
different cipher is selected unless there are no other ciphers. A New cipher
being added to OpenSSL is not going to be the only cipher available in any
meaningful timeframe. The "failure" mode for having a bad cipher in the list is
possibly making the users of Python insecure. That's why an explicit approach
is preferred over an open ended approach. Because you don't have to audit a
moving target.

___
Python tracker

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

[issue20995] Use Better Default Ciphers for the SSL Module


Donald Stufft added the comment:

> > Again, Python is already forcing a set of ciphers. I don't know what sort of
> > Systems you use, but even RHEL 6.5 has *horrible* ciphers by in the OpenSSL
> > default set. Things like DES (not 3DES, DES) and 40bit RC4.
> 
> I wonder why RedHat doesn't bother changing the defaults.
> Did nobody ever report the issue to them, or are they more conservative
> than we are?

I don't know why. Probably because the OpenSSL defaults are not intended to
be secure so OpenSSL is working as intended. The users of OpenSSL are intended
to use the cipher selection string to secure themselves.

--

___
Python tracker 

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

[issue20686] Confusing statement about unicode strings in tutorial introduction

2014-03-20 Thread Georg Brandl


Georg Brandl added the comment:

First, entering a string at the command prompt like this is not considered 
"printing"; it's invoking the repr().

Then, when you say flexible, you say it as if it's a good thing.  In this 
context "flexible" means as much as "easy to produce mojibake" and is not 
desirable.

For all these use cases, there are ways to do the right thing with Unicode 
strings in Python 2 (e.g. using io.open instead of builtin open).  But making 
these the builtin case was the big gain of Python 3.

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Antoine Pitrou added the comment:

> Again, Python is already forcing a set of ciphers. I don't know what sort of
> Systems you use, but even RHEL 6.5 has *horrible* ciphers by in the OpenSSL
> default set. Things like DES (not 3DES, DES) and 40bit RC4.

I wonder why RedHat doesn't bother changing the defaults.
Did nobody ever report the issue to them, or are they more conservative
than we are?

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Donald Stufft added the comment:

> I disagree. Python only provides an interface to OpenSSL, so the OpenSSL
> system defaults should be used.

Python is already changing the OpenSSL defaults, also you're advocating that
Python should support 40bit encryption that can be brute forced in a matter of
days.

> Maintaining system security is an easier and more scalable approach than
> trying to properly configure half a dozen sub-systems which happen to use
> OpenSSL as basis for their SSL configuration. By forcing a specific
> set of ciphers, we're breaking this approach.

Again, Python is already forcing a set of ciphers. I don't know what sort of
Systems you use, but even RHEL 6.5 has *horrible* ciphers by in the OpenSSL
default set. Things like DES (not 3DES, DES) and 40bit RC4.

> By restricting the set of allowed ciphers you can also create the
> situation that Python in its default configuration cannot talk to
> certain web servers which use a different set of ciphers than the
> one you are proposing.

Of course, any restriction does that, that's not reason to also allow aNULL
or eNULL by default just because somewhere someone out there might be running
a server that only speaks them. Secure, Sane Defaults and the Ability to
override.

> We shouldn't do this in Python for the same reason we're not including
> a predefined set of CA root certificates with the distribution.

The difference here is that there are properly maintained alternatives to
Python including a predefined set of CA root certificates. This isn't the
case with OpenSSL. OpenSSL doesn't provide good defaults and I'm not aware of
a single OS which ships with OpenSSL that patches it to provide good defaults.

Python exposes this API, it's Python's job to properly secure it.

--

___
Python tracker 

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

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

2014-03-20 Thread Roundup Robot


Roundup Robot added the comment:

New changeset 89aa669dcc61 by Benjamin Peterson in branch 'default':
remove the ability of datetime.time to be considered false (closes #13936)
http://hg.python.org/cpython/rev/89aa669dcc61

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module

2014-03-20 Thread Marc-Andre Lemburg

Marc-Andre Lemburg added the comment:

On 20.03.2014 21:52, Alex Gaynor wrote:
> 
> It's also worth noting that users appear to be FAR more likely to have an up 
> to date Python than they are an up to date OpenSSL, meaning that if a change 
> needs to be made, we're much better situated to get that disseminated to 
> actual users than OpenSSL is

This depends a lot on the type of users you're looking at. Corporate
users won't upgrade their Python version easily. They will happily
install patched OpenSSL versions.

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module

2014-03-20 Thread Marc-Andre Lemburg

Marc-Andre Lemburg added the comment:

On 20.03.2014 23:36, Donald Stufft wrote:
> 
> Donald Stufft added the comment:
> 
> I'm still looking into what "HIGH" entails across all the various OpenSSLs 
> that are in production that I can access. That "FUD" was responding to the 
> attitude that it's not Python's job to do this. Python is exposing a security 
> sensitive API, it is it's job.

I disagree. Python only provides an interface to OpenSSL, so the OpenSSL
system defaults should be used.

Maintaining system security is an easier and more scalable approach than
trying to properly configure half a dozen sub-systems which happen to use
OpenSSL as basis for their SSL configuration. By forcing a specific
set of ciphers, we're breaking this approach.

By restricting the set of allowed ciphers you can also create the
situation that Python in its default configuration cannot talk to
certain web servers which use a different set of ciphers than the
one you are proposing.

We shouldn't do this in Python for the same reason we're not including
a predefined set of CA root certificates with the distribution.

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Donald Stufft added the comment:

I'm still looking into what "HIGH" entails across all the various OpenSSLs that 
are in production that I can access. That "FUD" was responding to the attitude 
that it's not Python's job to do this. Python is exposing a security sensitive 
API, it is it's job.

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Donald Stufft added the comment:

Oh and don't confuse me that I think Python's current situation is as bad as 
Ruby's was, but that attitude is dangerous and wrong :/

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Antoine Pitrou added the comment:

> Please let's not have a repeat of
> https://bugs.ruby-lang.org/issues/9424, Python is in a better place to
> workaround that than anyone else.

Please stop the FUD. I proposed an alternative, how is it insecure
according according to you?

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Donald Stufft added the comment:

> This doesn't parse. If the system OpenSSL isn't maintained properly, it's not 
> Python's job to workaround that. And we certainly don't have the required 
> knowledge and dedication anyway.

Please let's not have a repeat of https://bugs.ruby-lang.org/issues/9424, 
Python is in a better place to workaround that than anyone else.

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Antoine Pitrou added the comment:

By the way:

> Using the default or the "wide" open strings are inherently more
> dangerous because of the wide range of OpenSSL's that are in
> production use. It's hard without auditing every version of OpenSSL to 
> figure out what ciphers will be available in what circumstances

This doesn't parse. If the system OpenSSL isn't maintained properly, it's not 
Python's job to workaround that. And we certainly don't have the required 
knowledge and dedication anyway.

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Antoine Pitrou added the comment:

See http://bugs.python.org/issue20995#msg214249

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Donald Stufft added the comment:

Why? At best users will get yet another secure algorithm and at worst they'll 
get an insecure algorithm.

--

___
Python tracker 

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

[issue20218] Add methods to `pathlib.Path`: `write_text`, `read_text`, `write_bytes`, `read_bytes`


Antoine Pitrou added the comment:

Then I'd rather wait for other people to chime in and state whether they are 
interested in this feature.

--

___
Python tracker 

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

[issue20744] shutil should not use distutils

2014-03-20 Thread Derek Chiang


Derek Chiang added the comment:

Cool, thanks for doing this!

--

___
Python tracker 

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

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE

2014-03-20 Thread Matthew Barnett


Matthew Barnett added the comment:

FWIW, here's my own attempt at a patch.

--
Added file: http://bugs.python.org/file34538/issue20998.patch

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Antoine Pitrou added the comment:

> The string I'm proposing has been carefully crafted in order to get 
> the ciphers in a very particular order. That order is basically - 1)
> Security of the cipher itself 2) PFS 3) Performance while also
> maintaining compatibility both forwards and backwards.

I still think the ciphers list should be open-ended, i.e. have "HIGH" somewhere 
at the end.

--

___
Python tracker 

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

[issue18967] Find a less conflict prone approach to Misc/NEWS


R. David Murray added the comment:

I want no script asking me questions.  Post-facto errors for omissions are fine 
(and if I have to positively say no in the input file, that's fine).  tkinter 
is right out.
 
If you *also* want to make a script that asks questions (or even a tkinter ap), 
that's fine, but it should not be the main interface, it should be a wrapper.

One thing I really don't like about the separate file approach is that you lose 
the obvious chronology.  It's probably not a blocker, but it is definitely a 
disadvantage.

--

___
Python tracker 

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

[issue20636] Better repr for tkinter widgets

2014-03-20 Thread Terry J. Reedy


Terry J. Reedy added the comment:

After looking more at testing entire (Idle) dialogs and windows for sanity, I 
like the idea even more. A person can check that everything that is present 
looks ok, but code is at least as good as using a checklist to verify that what 
is present is exactly what should be present. For this, widgets should have 
meaningful and predictable names. Once widgets are given names, they should be 
used in the representation. The proposed

>>> top.winfo_children()
[>> top.winfo_children()
[]


As for Ezio's question: The new method is defined in class tkinter.Misc and 
only applies to instances of subclasses thereof -- BaseWidget, Widget, etc, in 
tkinter.__init__ and ttk.Widget. I suppose other code might subclass something, 
but as far as I know, Idle classes 'have a' widget rather than 'being a' 
widget. But if Misc or a subclass could be sensibly subclassed in C code, you 
could, to be safe, change "top.__class__.__module__" to "getattr(top.__class__, 
'__module__', 'module'). I believe 'self._w' is safe as an object without ._w 
is not a tk widget.

--

___
Python tracker 

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

[issue18967] Find a less conflict prone approach to Misc/NEWS


Zachary Ware added the comment:

The `hg commit -l ...` tricks are just for those who tend to use exactly the 
same text for commit message and NEWS, and I only point them out simply because 
I don't know how many people are even aware of the -l option :).  If you want 
to use a NEWS entry as a base for a commit message without the two being 
exactly the same, it's also fairly easy to do `news.py | hg commit -l - && hg 
commit --amend` which will open the commit message in your usual commit message 
editor (at the cost of rolling back and re-doing the commit).

I also just thought of adding a 'who wrote it' question, and I like the idea of 
using it to manage Misc/ACKS.  I'm also intrigued by the suggestion of using 
Tkinter (when available), and the WhatsNew management.  But as you said, one 
thing at a time :)

First thing is, decide what we're actually going to do.  news.py obviously 
needs a fair bit of work before we can use it regularly, which I don't mind 
doing, but only if it will actually be used ;)

--

___
Python tracker 

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

[issue18931] new selectors module should support devpoll on Solaris

2014-03-20 Thread Giampaolo Rodola'


Changes by Giampaolo Rodola' :


--
assignee:  -> giampaolo.rodola
components: +Library (Lib)
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue18931] new selectors module should support devpoll on Solaris

2014-03-20 Thread Giampaolo Rodola'


Giampaolo Rodola' added the comment:

I successfully tested this on Solaris 11.

--

___
Python tracker 

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

[issue17846] Building Python on Windows - Supplementary info

2014-03-20 Thread Kathleen Weaver


Kathleen Weaver added the comment:

I agree -- so should that be a separate patch since it's in cpython, not 
devguide?

Quoting:

Frankly, I don't see much added benefit from the new file.  It's mostly
duplication of PCbuild/readme.txt, and what little isn't already there should
be.  I would much rather see a patch making sure PCbuild/readme.txt is up to
date, and a link to http://hg.python.org/cpython/file/default/PCbuild/readme.txt
added to the devguide's existing compilation on Windows section.

--

___
Python tracker 

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

[issue18931] new selectors module should support devpoll on Solaris

2014-03-20 Thread Roundup Robot


Roundup Robot added the comment:

New changeset 0a51a516bc70 by Giampaolo Rodola' in branch 'default':
Fix issue 18931: selectors module now supports /dev/poll on Solaris.
http://hg.python.org/cpython/rev/0a51a516bc70

--

___
Python tracker 

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

[issue17846] Building Python on Windows - Supplementary info


Zachary Ware added the comment:

It will have to be a separate patch, but can be done in this issue.

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module

2014-03-20 Thread Alex Gaynor


Alex Gaynor added the comment:

It's also worth noting that users appear to be FAR more likely to have an up to 
date Python than they are an up to date OpenSSL, meaning that if a change needs 
to be made, we're much better situated to get that disseminated to actual users 
than OpenSSL is

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Donald Stufft added the comment:

Another bit of maintenance here:

If a new cipher suite is added to OpenSSL it won' be generally available for a 
long while so very few if any services are going to be willing to depend on 
*only* it. For the very rare and unlikely case that somebody does setup a 
service that requires some brand new cipher they can override this list easily.

Using the default or the "wide" open strings are inherently more dangerous 
because of the wide range of OpenSSL's that are in production use. It's hard 
without auditing every version of OpenSSL to figure out what ciphers will be 
available in what circumstances. It also means that if OpenSSL adds a new 
cipher that ends up being insecure that it will be picked up automatically. 
Therefore the strings I've posted take the opinion that a whitelist is more 
secure than a blacklist and whitelist the cipher suites to a very specific set 
that happen to be best practices at this current time.

The only *required* maintenance would be if one of the selected ciphers are 
found to be insecure. However that was already a required maintenance because 
(again) of the wide range of OpenSSL versions available and the fact that these 
strings don't *add* any new ciphers, only remove some and create an explicit 
priority.

--

___
Python tracker 

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

[issue18931] new selectors module should support devpoll on Solaris

2014-03-20 Thread Guido van Rossum


Guido van Rossum added the comment:

LGTM, but I don't have a Solaris box to test. I suppose one of you has tested 
this? Then okay to commit to the default (== 3.5) branch.

--

___
Python tracker 

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

[issue18967] Find a less conflict prone approach to Misc/NEWS

2014-03-20 Thread Brett Cannon


Brett Cannon added the comment:

So the `hg commit -l` bit is going to run afoul of the same group of people who 
didn't like my commit message reuse idea unless you explicitly try to make it 
very clear that e.g. the first line is for Misc/NEWS and the latter is for the 
commit. Otherwise we have typically not include the "thanks" bit of a commit in 
Misc/NEWS which would also water down the `-l` usage. I know it's not critical 
for this, but I just wouldn't worry about it as a big selling point (unless you 
get really fancy and let the entries vary and instead of using the file as the 
input to the commit you write to a temp file or pipe in stdout and use the 
script to generate both the file and execute the commit with the more thorough 
message as a separate thing).

BUT if people like the "one entry, one file" approach and seriously using the 
output for both Misc/NEWS and the commit message then I see the script for 
generating the entry asking the following questions (which could even use 
Tkinter =):

* Issue #s
* Did someone else help out with this; allows making sure they were not 
accidentally left out of Misc/ACKS and add them if necessary or at least that 
they are mentioned in the commit message
* One line explanation for NEWS
* Optional extra bits to go into the commit message
* Should this go into What's New (e.g. new feature, backwards-compatible 
breakage); can add a `WN` or `WhatsNew` to the file name or something so that 
if someone like David tries to update the What's New doc they can tell by the 
file name that it may be important to cover (and maybe even only add the marker 
if What's New is NOT edited to know it's more like a TODO item)

Another side-effect of marking entries as worthy of being in What's New is that 
it should be easy to tell what should potentially be added as an addendum to 
What's New and to highlight at the end of the doc so that every micro release 
people can notice what was added. Heck, the logical conclusion is to split up 
What's New into individual files with a placeholder of the issue that was 
marked as worthy of inclusion and then edit it before release and auto-generate 
What's New (but one thing at a time =).

Anyway, ignoring all of this unstructured brain dump of mine, I'm can support 
doing a separate file approach.

--

___
Python tracker 

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

[issue20996] Backport TLS 1.1 and 1.2 support for ssl_version

2014-03-20 Thread Nick Coghlan


Nick Coghlan added the comment:

Yes, I have been persuaded this fixes a security issue in the Python 2
ecosystem: the current barriers to good web security practices are too high.

I have been vocal in pointing out that Python 2 will remain a commercially
supported platform for at least another decade. However, for that to be a
valid claim, it needs to be possible to make effective use of modern web
protocols and security standards.

This is a PEP level discussion though - I'll get something up by tomorrow.

--

___
Python tracker 

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

[issue20980] In multiprocessing.pool, ExceptionWithTraceback should derive from Exception

2014-03-20 Thread Richard Oudkerk


Richard Oudkerk added the comment:

We should only wrap the exception with ExceptionWithTraceback in the process 
case where it will be pickled and then unpickled.

--
assignee:  -> sbt

___
Python tracker 

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

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE


Serhiy Storchaka added the comment:

Here is a patch.

--
keywords: +patch
stage: needs patch -> patch review
Added file: 
http://bugs.python.org/file34537/sre_fullmatch_repeated_ignorecase.patch

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module

2014-03-20 Thread Nick Coghlan


Nick Coghlan added the comment:

In terms of following closely, I'd be willing to encourage Red Hat's SRT to
keep an eye on this.

--

___
Python tracker 

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

[issue20990] pyflakes: undefined names, get_context() and main(), in multiprocessing

2014-03-20 Thread Richard Oudkerk


Changes by Richard Oudkerk :


--
assignee:  -> sbt

___
Python tracker 

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

[issue20744] shutil should not use distutils

2014-03-20 Thread A.M. Kuchling


Changes by A.M. Kuchling :


--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue18967] Find a less conflict prone approach to Misc/NEWS


Changes by Zachary Ware :


--
keywords: +patch
Added file: http://bugs.python.org/file34536/0607c4a2e890.diff

___
Python tracker 

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

[issue20744] shutil should not use distutils

2014-03-20 Thread Roundup Robot


Roundup Robot added the comment:

New changeset 681e20f8b717 by Andrew Kuchling in branch 'default':
#20744: don't try running an external 'zip' in shutil.make_archive()
http://hg.python.org/cpython/rev/681e20f8b717

--
nosy: +python-dev

___
Python tracker 

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

[issue18967] Find a less conflict prone approach to Misc/NEWS


Zachary Ware added the comment:

The earlier in a release cycle we switch NEWS methods, the better.  Does anyone 
have any thoughts to share about this, either on Brett's newsworthy.py, my 
news.py/news_release.py, or another approach entirely?

I've updated the playground branch of sandbox/new_news to mirror current 
default (3.5.0a0), and have added .news files in the NEWS.parts tree to match 
the current state of Misc/NEWS.  I've also linked the repository to this issue.

You can play with adding NEWS entries by running Tools/scripts/news.py and see 
how it looks put together by running Tools/scripts/news_release.py (or write 
Misc/NEWS and remove all parts with "Tools/scripts/news_release.py write").

Other interesting things to try:
- Create a .news file with news.py, then use `hg commit -l 
Misc/NEWS.parts//.news`
- Do the above in a single step: `Tools/scripts/news.py | hg commit -l -`

--
hgrepos: +228

___
Python tracker 

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

[issue20686] Confusing statement about unicode strings in tutorial introduction

2014-03-20 Thread Daniel U. Thibault


Daniel U. Thibault added the comment:

>>> mystring="äöü"
>>> myustring=u"äöü"

>>> mystring
'\xc3\xa4\xc3\xb6\xc3\xbc'
>>> myustring
u'\xe4\xf6\xfc'

>>> str(mystring)
'\xc3\xa4\xc3\xb6\xc3\xbc'
>>> str(myustring)
Traceback (most recent call last):
  File "", line 1, in 
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: 
ordinal not in range(128)

>>> f = open('workfile', 'w')
>>> f.write(mystring)
>>> f.close()
>>> f = open('workufile', 'w')
>>> f.write(myustring)
Traceback (most recent call last):
  File "", line 1, in 
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: 
ordinal not in range(128)
>>> f.close()

workfile contains C3 A4 C3 B6 C3 BC

So the Unicode string (myustring) does indeed try to convert to ASCII when 
written to file. But not when just printed.

It seems really strange that non-Unicode strings (mystring) should actually be 
more flexible than Unicode strings...

--

___
Python tracker 

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

[issue11352] Update cgi module doc


R. David Murray added the comment:

It looks like the non-doc stuff was accidental inclusions and should be 
ignored.  Or better, the patch author could address Berker and Jim's comments 
and resubmit a clean patch.

--

___
Python tracker 

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

[issue20744] shutil should not use distutils

2014-03-20 Thread A.M. Kuchling


A.M. Kuchling added the comment:

Yes, tests are only run after a change is committed and pushed into
Mercurial; this is done by BuildBot https://www.python.org/dev/buildbot/ .

So it's a good idea to run tests before submitting a patch or committing a 
change.  No matter how trivial a change seems, it should always be tested 
first.  Every programmer has a few stories of "this can't possibly fail" 
changes that fail, sometimes spectacularly.

(One of mine: I rewrote some C string-handling code for a product
that supported 4 or 5 different Unixes and processor architectures,
tried it on one of them, and concluded it was fine.  It segfaulted on
exactly one architecture.  Unfortunately this was discovered by a VP
who was demoing to a customer at the time.  I got a talking-to about
that one.)

Running the tests finds a simple problem: there's no longer an 'import
zipfile' statement.  I'll add the import inside the _make_zipfile()
function.  This is against PEP 8, strictly speaking, but it means
importing shutil doesn't always import zipfile; it'll only import the
module if it's actually needed.  (I'll probably do the same for the
import of tarfile.)

Derek, thanks for your patch!

--

___
Python tracker 

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

[issue11352] Update cgi module doc

2014-03-20 Thread Jim Jewett


Jim Jewett added the comment:

I have now also looked at cgi-doc.patch, and it is not strictly documentation 
changes.  I have no informed opinion on the the additional changes, but I don't 
think they should go in as "doc change".

--

___
Python tracker 

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

[issue18931] new selectors module should support devpoll on Solaris

2014-03-20 Thread Charles-François Natali


Changes by Charles-François Natali :


Added file: http://bugs.python.org/file34535/devpoll3_try_again.diff

___
Python tracker 

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

[issue20999] setlocale, getlocale succession --> ValueError or (None, None)


R. David Murray added the comment:

Have you tried experimenting with what locale is set to?  These look like 
locale configuration issues rather than platform issues.  Specifically, the C 
locale will produce the (None, None) result on linux.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue19861] Update What's New for Python 3.4


R. David Murray added the comment:

Oh, yeah, it should be.  Any further changes should be independent bug reports.

--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue21000] json.tool ought to have a help flag

2014-03-20 Thread Berker Peksag


Changes by Berker Peksag :


--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file34534/issue21000.diff

___
Python tracker 

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

[issue10141] SocketCan support

2014-03-20 Thread Charles-François Natali


Charles-François Natali added the comment:

Vinay, your change just reverted this: http://bugs.python.org/issue20065

Basically, AF_CAN being defined doesn't imply that CAN_RAW is defined.

So compilation will now fail - again - on those hosts.

--
status: closed -> open

___
Python tracker 

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

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE


Changes by Serhiy Storchaka :


--
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 3.5

___
Python tracker 

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

[issue21000] json.tool ought to have a help flag

2014-03-20 Thread Benjamin Peterson


New submission from Benjamin Peterson:

I current get this behavior:
% python3 -m json.tool -h
Traceback (most recent call last):
  File "/usr/lib64/python3.3/runpy.py", line 160, in _run_module_as_main
"__main__", fname, loader, pkg_name)
  File "/usr/lib64/python3.3/runpy.py", line 73, in _run_code
exec(code, run_globals)
  File "/usr/lib64/python3.3/json/tool.py", line 40, in 
main()
  File "/usr/lib64/python3.3/json/tool.py", line 21, in main
infile = open(sys.argv[1], 'r')
FileNotFoundError: [Errno 2] No such file or directory: '-h'

Instead of that, json.tool should show a helpful message expalining what it 
does in response to the -h or --help flags.

--
components: Library (Lib)
keywords: easy
messages: 214261
nosy: benjamin.peterson
priority: normal
severity: normal
stage: needs patch
status: open
title: json.tool ought to have a help flag
type: enhancement
versions: Python 3.5

___
Python tracker 

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

[issue20999] setlocale, getlocale succession --> ValueError or (None, None)

2014-03-20 Thread albertjan


New submission from albertjan:

->> see also issue #18378

# Result applies to Python 2.7.2 and Python 3.3.4
# Mac OS X Mountain Lion 10.9.1 on Virtualbox with a Linux Debian AMD-64 host
fomcls-Mac-Pro:~ fomcl$ uname -a
Darwin fomcls-Mac-Pro.local 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 
00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_6

>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'C/UTF-8/C/C/C/C'
>>> locale.getlocale()
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py",
 line 515, in getlocale
return _parse_localename(localename)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py",
 line 428, in _parse_localename
raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: UTF-8


# below another configuration (no hackintosh)



conda 2.7:

Python 2.7.6 |Continuum Analytics, Inc.| (default, Jan 10 2014, 11:23:15)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'C'
>>> locale.getlocale()
(None, None)

conda 3.3:

Python 3.3.5 |Continuum Analytics, Inc.| (default, Mar 10 2014, 11:22:25)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'C'
>>> locale.getlocale()
(None, None)

Regular 2.7:

Python 2.7.5 (default, Aug 25 2013, 00:04:04)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'C'
>>> locale.getlocale()
(None, None)
>>>


Regular 3.3  (broken installation??)
Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
Segmentation fault: 11



### finally, the expected result (on Linux)


antonia@antonia-HP-2133 ~ $ uname -a
Linux antonia-HP-2133 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:32:08 UTC 
2012 i686 i686 i686 GNU/Linux
Python 2.7.3 (default, Feb 27 2014, 19:39:10) [GCC 4.7.2] on linux2
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'en_US.UTF-8'
>>> locale.getlocale()
('en_US', 'UTF-8')

--
assignee: ronaldoussoren
components: Macintosh
messages: 214260
nosy: albertjan, ronaldoussoren
priority: normal
severity: normal
status: open
title: setlocale, getlocale succession --> ValueError or (None, None)
type: behavior
versions: Python 2.7, Python 3.3

___
Python tracker 

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

[issue20744] shutil should not use distutils

2014-03-20 Thread Arfrever Frehtes Taifersar Arahesis


Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue20939] test_geturl of test_urllibnet fails with 'https://www.python.org/' != 'http://www.python.org/'

2014-03-20 Thread Arfrever Frehtes Taifersar Arahesis


Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue20168] Derby: Convert the _tkinter module to use Argument Clinic


Serhiy Storchaka added the comment:

Here is updated patch.

--
versions: +Python 3.5 -Python 3.4
Added file: http://bugs.python.org/file34533/tkinter_clinic_2.patch

___
Python tracker 

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

[issue17188] Document 'from None' in raise statement doc.

2014-03-20 Thread Arfrever Frehtes Taifersar Arahesis


Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE

2014-03-20 Thread Nathan West


Changes by Nathan West :


--
type:  -> behavior

___
Python tracker 

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

[issue20994] Disable TLS Compression


Donald Stufft added the comment:

Here's the same patch for Python 2.7, it's basically the same thing just at a 
different location.

--
Added file: http://bugs.python.org/file34532/disable-ssl-compression-2.7.diff

___
Python tracker 

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

[issue20998] fullmatch isn't matching correctly under re.IGNORECASE

2014-03-20 Thread Nathan West


New submission from Nathan West:

I have the following regular expression:

In [2]: regex = re.compile("ME IS \w+", re.I)

For some reason, when using `fullmatch`, it doesn't match substrings longer 
than 1 for the '\w+':

In [3]: regex.fullmatch("ME IS L")
Out[3]: <_sre.SRE_Match object; span=(0, 7), match='ME IS L'>

In [4]: regex.fullmatch("me is l")
Out[4]: <_sre.SRE_Match object; span=(0, 7), match='me is l'>

In [5]: regex.fullmatch("ME IS Lucretiel")

In [6]: regex.fullmatch("me is lucretiel")


I have no idea why this is happening. Using `match` works fine:

In [7]: regex.match("ME IS L")
Out[7]: <_sre.SRE_Match object; span=(0, 7), match='ME IS L'>

In [8]: regex.match("ME IS Lucretiel")
Out[8]: <_sre.SRE_Match object; span=(0, 15), match='ME IS Lucretiel'>

In [9]: regex.match("me is lucretiel")
Out[9]: <_sre.SRE_Match object; span=(0, 15), match='me is lucretiel'>

Additionally, using `fullmatch` WITHOUT using the `re.I` flag causes it to work:

In [10]: regex = re.compile("ME IS \w+")

In [11]: regex.fullmatch("ME IS L")
Out[11]: <_sre.SRE_Match object; span=(0, 7), match='ME IS L'>

In [12]: regex.fullmatch("ME IS Lucretiel")
Out[12]: <_sre.SRE_Match object; span=(0, 15), match='ME IS Lucretiel'>

My platform is Ubuntu 12.04, using Python 3.4 installed from Felix Krull's 
deadsnakes PPA (https://launchpad.net/~fkrull/+archive/deadsnakes).

--
components: Regular Expressions
messages: 214257
nosy: Lucretiel, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: fullmatch isn't matching correctly under re.IGNORECASE
versions: Python 3.4

___
Python tracker 

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

[issue19861] Update What's New for Python 3.4


Zachary Ware added the comment:

Thanks for the #3158 addition, David :)

We've been a week with no more major changes; is this issue done?

--

___
Python tracker 

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

[issue20996] Backport TLS 1.1 and 1.2 support for ssl_version

2014-03-20 Thread Arfrever Frehtes Taifersar Arahesis


Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue20887] stdlib compatibility with pypy, test_zipfile.py

2014-03-20 Thread Arfrever Frehtes Taifersar Arahesis


Arfrever Frehtes Taifersar Arahesis added the comment:

Garbage collection still closes files, but Python >=3.2 might print 
ResourceWarnings.

--
nosy: +Arfrever

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module

2014-03-20 Thread Arfrever Frehtes Taifersar Arahesis


Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue20994] Disable TLS Compression

2014-03-20 Thread Arfrever Frehtes Taifersar Arahesis


Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue20994] Disable TLS Compression


Donald Stufft added the comment:

This is a simple patch, it simple disables TLS Compression by default. If a 
user wants to add it back they can create their own SSLContext and do


ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
ctx.options &= ~ssl.OP_NO_COMPRESSION

This should be able to apply against 3.2+ although it would only be 3.3+ that 
ssl.OP_NO_COMPRESSION is available to disable it, although a user could still 
hard code the constant in themselves.

This still leaves 2.7 out in the open here, what I'd like to do is just disable 
it and if someone really *needs* TLS Compression they can use pyopenssl to get 
that back. This is a reversal of the current situation where in order to get 
the safer value you have to use pyopenssl.

--
keywords: +patch
Added file: 
http://bugs.python.org/file34531/disable-ssl-compression-default.diff

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module


Donald Stufft added the comment:

Yea I noticed that, so I was doing some more testing, here's what I think we 
should be using (It Adds back in RC4):

ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:ECDH+RC4:DH+RC4:RSA+RC4!aNULL:!MD5:!DSS

This gives us everything that DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2 does 
except for the ciphers list here 
https://gist.github.com/dstufft/251dbeb8962e2182e668 on my OpenSSL 1.0.1f 
install.

Antoine, your cipher string priortizes ECDHE RC4 over DHE AES or even just 
plain AES. The string I'm proposing has been carefully crafted in order to get 
the ciphers in a very particular order. That order is basically - 1) Security 
of the cipher itself 2) PFS 3) Performance while also maintaining compatibility 
both forwards and backwards.

RC4 is in a precarious condition and it's use should be heavily discouraged. It 
is still required in some cases which is why my revised default cipher 
suggestion includes it, but at the end as a last fall back. At that point if 
RC4 gets selected it's the servers fault and the client did everything it could 
except refuse.

I still do believe that this should be the default ciphers while my original 
string should be the "restricted" ciphers that create_default_context() uses.

--

___
Python tracker 

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

[issue20887] stdlib compatibility with pypy, test_zipfile.py

2014-03-20 Thread mattip


mattip added the comment:

As far as I know, cpython3 dropped the assumption that garbage collection 
closes files, so python3's version of this test should already handle the 
issue, no?

--

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module

2014-03-20 Thread Alex Gaynor


Alex Gaynor added the comment:

That's because of the set of ciphersuites offered by the server (see 
https://www.ssllabs.com/ssltest/analyze.html?d=linuxfr.org), it's not an 
inevitable property of TLS. For example jenkins.cryptography.io (see 
https://www.ssllabs.com/ssltest/analyze.html?d=jenkins.cryptography.io) offers 
ECDHE suites without any RC4 at all.

--

___
Python tracker 

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

[issue20636] Better repr for tkinter widgets


Serhiy Storchaka added the comment:

Are there any questions or objections?

--
assignee:  -> serhiy.storchaka

___
Python tracker 

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

[issue20995] Use Better Default Ciphers for the SSL Module